Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

スクラムのフレームワークでKAIZENを体験しよう comeback japan 2017

262 views

Published on

comeback japan 2017で実施したワークショップの内容および様子をまとめてアップしました。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

スクラムのフレームワークでKAIZENを体験しよう comeback japan 2017

  1. 1. スクラムのフレームワークで KAIZENを体験しよう ~悩める宮司を助けられるのは!?~ 2017/05/14 グロースエクスパートナーズ株式会社 G‘s LounGeにて
  2. 2. 注意事項 本書に書かれていることは、ワークショップをやるためのフィクションです。実在の神社の写真などが掲載されています が、一切関係はありません。 また、本ワークショップは、松浦豪一が個人で作成したもので、富士通株式会社及び、富士通マーケティングを代 表するものではありません。 このワークショップを参考にしていただくのはかまいませんが、運営側のノウハウはかかれていません。そのまま実施す るのは避けてください。ご協力できることがあるかもしれませんので、ご相談ください。 参考資料は以下のとおりです。 ① これだけ! KPT,天野 勝,ISBN978-4-7991-0275-6 ② リーンソフトウェア開発と組織改革,Mary and Tom Poppendieck, 訳:依田智夫,依田 光江,ISBN978-4-04-868741-6 ③ チーム脳の作り方,清宮 普美代, ISBN978-4-87290—405-5 ④ プロジェクトファシリテーション 価値と原則編,㈱永和システムマネジメント 平鍋 健児,天野 勝 ⑤ アジャイル開発プロジェクトマネジメントに対応する人材育成 ―改善によって成長を期待するマネジメント―,松浦豪一, 情報処理学会デジタルプラクティス Vol.7 No.3 (July 2016) 2
  3. 3. アジェンダ 本ワークショップでは、スクラムを実践するなかで、アジャイルの基本である改善を 体験してもらうことを目的としています。想定でスクラムチームを運営してもらいま す。 • 背景 • 模擬プロジェクトのポイント • 流れの説明 • スプリント1 • 休憩 • スプリント2 3
  4. 4. 背景:模擬プロジェクトで担当の会社を決めたい!! 私は神社の宮司です。神社の修繕を考えています。伝統を守 りつつも、たくさんの方に親しんでもらえる神社を作りたいです。 担当会社選びのポイントは、柔軟な発想と対応力です。今回、 スクラムを採用します。模擬プロジェクトをスクラム行い、参加者 を評価したいと考えております。内容は以下のとおりです。 • ユーザーストーリーに従い、ドミノと折り紙で模型神社を作成 し、スプリントごとにプレゼンテーションしてもらいます。 • 評価は、模型の出来栄えだけでなく、アイデア、マネジメント 能力を評価して選定します。(工作は、下手でも良いが、 利用者視点での取り組みを重要視します) • 模擬プロジェクトは、進めていくなかでメンバを交代する場合 があります。スクラムの知識にばらつきがあると思いますので、 ファシリテーターを配置します。 4
  5. 5. 模擬プロジェクト(スクラム)のポイント • すべてのミーティングは立って行い、タイムボック スを守って行う。常に問題対私たちの構図を作 り、対話することを重視する。 (リーダーシップでコマンドコントロールしない) • すべての作業はペアプログラミングとし、会話しな がら行う。 • KPTを使ったふりかえりにより、チームで発生 した問題を改善する。 時間が限られているため、スクラムの説明はできるだけ 省略しました。運営方法が分からないと困るため、経験 者を配置して実施しました。スクラムを勉強した場合は 各自学習ください。富士通も研修を実施してます。 5
  6. 6. 問題対私たちの構図を使ったミーティング VMボード F VMボード F VM(Visual Management)ボードに向かって全員が半円のように並びます。 自然に問題となるVMボードをみて話すことができます。Fとなっている部分はファシリテータです。 ※ポイント 肩と肩が触れないぎりぎりの距離で並びます。 腕組みしたりしてはいけません。 アジェンダに従い、テンポよく行います。 ・ぎりぎりに近づくと、他人事は言えなくなります。 ・傍観する人は列を外れ、文句を言いたい人は腕組みをします。 ・テンポよくやると、とまどいやためらいが顕在化され、 そのうち解消されます。 6
  7. 7. 模擬プロジェクトの流れ スクラムを知らない人も含まれるため、流れを簡単に説明しま す。 • スプリントの流れ • ユーザーストーリー • スパイク&計画ミーテイング • 朝会&開発 • タスクボード • スプリントレビュー&ふりかえり 7
  8. 8. スプリントの流れ 5日目(20分) 朝会(2分)レビュー(3分) ふりかえり(15分) 2日目から4日目(10分×3) 朝会(5分) 開発(5分) 1日目(30分) スパイク(5分) 計画ミーティング(25分) 8
  9. 9. スプリント#1 スプリント#1説明しながら実施します。 1. ユーザーストーリー 2. スパイク&計画ミーテイング 3. 朝会&開発 4. タスクボード 5. スプリントレビュー&ふりかえり
  10. 10. ユーザーストーリー 私は宮司として、拝殿が欲 しい。なぜなら、たくさん の人に参拝してほしいから。 私は宮司として、水を使っ た施設が欲しい。 なぜなら、参拝者に楽しん でほしいから。 私は宮司として、花壇が欲 しい。なぜなら、リラック スできる場所にしたいから。 • ドミノは何色を使ってもよいが水を イメージできると良い。 • 5つ以上倒れること。 • 一度倒したらそのままで良い。 (完成時点で随時レビューできる) • ドミノを3つ以上使うこと。 • 最低3段になっていること。 • スプリントレビューまで維持するこ と。 • 息を吹きかけても倒れないこと。 • ドミノを3つ以上使うこと。 • 綺麗ないろどりになっていること。 • 花びらの形には特にこだわらない。 人の高さ ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 10
  11. 11. スパイク&計画ミーティング  スパイク(5分) 1. スプリントバックログ(タスク)の見積もりをやりやすくするた めに、タスクの一部を洗い出して実際にやってみる。 2. どんな作業でも良い。 3分くらいのタスクで実施して時間を測定する。 「ドミノを20個ならべて倒す」 3. チームで作業結果を共有する。  計画ミーティング(25分) 1. スプリントのゴールをプロダクトオーナー(以下、POと略す) と共有する。ストーリーレベルで合意(今回は3つのストーリー を実施する) 2. 不明点を確認しながらタスクを洗い出す。 3. タスクの実施時間を決める。 4. バーンダウンチャートを作成する。・・・今回は作成しない ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 3つのストーリーを やってくださいで合意 した。 水の施設は波を 表現してください。 11
  12. 12. タスクボード 私は宮司として、拝殿が 欲しい。なぜなら、たく さんの人に安全な状態で 参拝してほしいから。 私は宮司として、水を 使った施設が欲しい。 なぜなら、参拝待ちで楽 しんでほしいから。 私は宮司として、花壇が 欲しい。なぜなら、リ ラックスできる場所にし たいから。 • ドミノは何色を使ってもよいが 水をイメージできると良い。 • 5つ以上倒れること。 • 一度倒したらそのままで良い。 (完成時点で随時レビューできる) • ドミノを3つ以上使うこと。 • 最低3段になっていること。 • スプリントレビューまで維持す ること。 • 息を吹きかけても倒れないこと。 • ドミノを3つ以上使うこと。 • 綺麗ないろどりになっているこ と。 • 花びらの形には特にこだわらな い。 ユーザー ストーリー todo doing done ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 12
  13. 13. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 ユーザストーリーの 確認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 13
  14. 14. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 14
  15. 15. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード はみ出てます 近すぎます デカすぎです 優先順位が低いも のが先に完成した 作ること、タスクをこなす だけではなく、利用者視点 が必要です。 15
  16. 16. スプリントレビュー&ふりかえり (続く)  朝会(2分) 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. 問題点を共有する。 4. タスクの追加・削除をする。  スプリントレビュー(3分) 1. リリース可能なものをデモする。結果はPOからスクラムマスタ に伝える。 2. 随時リリースしたものについては、POからフィードバックをも らう。 次ページへ続く ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード とまどい、ためらいなく、 テンポ良くできていました。 16
  17. 17. スプリントレビュー&ふりかえり(続き)  ふりかえり(15分) 1. (実施したTryをKeepに移動、解消したProblemをはずす) 2. KeepとProblemを各自で黙々と付箋紙に書く(相談しない)。 ※問題を一般化しないで、具体的にかく。何時、何がおきた。 Keepは一人1件だす。 3. Keepから一人一件ずつ貼りながら説明する。同じ場合は「同じ です」だけ言って貼る。同じでない場合は似ていても説明する。 4. Problemも同様に一人一件ずつ貼りながら説明する。Keepと同 じやり方をする。 5. Tryを各自で付箋紙に書く。 6. Tryも同様に一人一件ずつ貼りながら説明する。 7. 実施するTryを決める。(3つ程度) ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード せいの!! で決めました TRYは、解決 したいことで はなく、解決 するための行 動を書いてく ださい。 17
  18. 18. KPTボード Keep Problem TryKeepを補強 するTry 前後関係の ないTry Problemを 解決するTry 心構え・グラウンドルール 1.積極的に話すこと 2.当事者意識を持つこと 3.議題に集中すること 4.一人で話しすぎないこと (人の発言をさえぎることは禁止) 話していない人にも想いあり 5.問題に向かってはなすこと ユーザストーリーの確 認 1日目 スパイ ク&計画ミー ティング タスクボード 2日目 朝会& 開発 3日目 朝会& 開発 4日目 朝会& 開発 5日目 スプリ ントレビュー& ふりかえり KPTボード 18
  19. 19. 休憩10分
  20. 20. スプリント#2 スプリント#2はできるだけとおしで実施 します。 1. 計画ミーテイング・・・25分 2. 朝会&開発 ・・・ 朝会5分 開発 5分 3. スプリントレビュー&ふりかえり ・・・ レビュー3分 ふりかえり15分
  21. 21. 計画ミーティング  交代メンバへの説明(5分) 前回の様子やふりかえりの内容を交代メンバに説明した。  計画ミーティング(25分) 1. スプリントのゴールをプロダクトオーナー(以下、POと略す) と共有する。ストーリーレベルで合意(今回は3つのストーリー を実施する) 2. 不明点を確認しながらタスクを洗い出す。 3. タスクの実施時間を決める。 4. バーンダウンチャートを作成する。・・・今回は作成しない 1日目 計画ミーティング 2日目 朝会&開発 3日目 朝会&開発 4日目 朝会&開発 5日目 スプリントレビュー& ふりかえり 2名のメンバ交代をしました。 水の施設は渦を表現してくだ さい。 21
  22. 22. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 1日目 計画ミーティング 2日目 朝会&開発 3日目 朝会&開発 4日目 朝会&開発 5日目 スプリントレビュー& ふりかえり 前回と同じことで小 さく改善するように 実施しました。 前回とは、まったく違うや り方でちがうものを作って いました。 22
  23. 23. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 1日目 計画ミーティング 2日目 朝会&開発 3日目 朝会&開発 4日目 朝会&開発 5日目 スプリントレビュー& ふりかえり 早めにリリース しました。 優先順位どおり に作っています。 別環境で作って 運搬する方式を とりました。 運搬の仕組みづ くりに時間がか かかっています。 23
  24. 24. 朝会&開発  朝会(5分) 司会は毎日交代、開発メンバが日替わりで行う。 1. 前回までの作業をペアごと説明する。 2. バーンダウンチャートを更新する。・・・今回は省略 3. ペアを決める。 4. 1日の作業の進め方を説明する。 5. 問題点を共有する。 6. タスクの追加・削除をする。  開発(5分) 開発はペアプログラミングで行う。 • ドライバとナビゲータに別れる。ナビゲータは作業内容を説 明し、指示をする。ドライバは指示にしたがって作業する。 • 二人で一つの作業を行う。補助する程度は手伝っても良いが、 二人が別々の作業をやってはいけない。 • ペアは毎日交代する。ドライバとナビゲータは何時交代して も良い。 1日目 計画ミーティング 2日目 朝会&開発 3日目 朝会&開発 4日目 朝会&開発 5日目 スプリントレビュー& ふりかえり ここまでで時 間切れとなり ました。 24
  25. 25. ワークショップのまとめ  2回目のスプリントでは、Aチームは1回目に少しだけ工夫を加える形 をとりました。Bチームはまったくちがう方式をとりました。  Aチームの方がユーザ視点のものづくりなっていたうえで、すべて 完成していました。  Bチームは完成させたものを移動させる方式をとっていましたが、 その時間か1日の大半になってしまいました。(ムダが多くなった と思います)  Bチームはより価値の高いものを作るアプローチをしていましたが、1 つのストーリーをリリースできませんでした。POと会話がなく、良い 物を作ろうと自分達で決めてやっていましたが、それが要求よりも過剰 なものだとムダの可能性があります。リリースを優先し、フィードバッ クをもらい、コミュニケーションすることでゴールを探すべきでしょう。 指摘する余地があるくらいの成果物でも良いと思います。  人の移動や要求の変化に対応できたのは、全員で計画し、全員でペアプ ログラミングで開発する方法をとっていたからです。今回実践した KAIZENノウハウが活かされたと思います。 25
  26. 26. 謝辞 このワークショップを実施する機会を与えて いだだいた、AgileJapan および Comeback Japanの関係者に感謝の 意を表します。ワークショップ作成に協力し ていただいた和田さん、ワークショップ実施 に協力していただいた大脇さん、内藤さん に、心より感謝いたします。今回の企画に 参加していただいた方々にお礼申し上げ ます。ワークショップ運営側がとても勉強に なりました。最後にこのテキストを作成する にあたって、神社・花の写真の提供などア ドバイスをいただいた妻に感謝しています。 皆様ありがとうございました。

×