Lego4Scrumを紙コップでやってみよう

Lego4Scrum を紙コップでやってみよう プロジェクトに参加したときの頭の使い方と セルフマネジメントの術を学ぶ。 Yuki Izumoto ＠ silkyfeel 新人研修

プロフィール • 泉本優輝（Yuki Izumoto） • 1988年生まれ • Microsoft MVP for Mixed Reality (いま世界で47人、MSMVP 11年目） • 昔は会社作ったりしてた。 今はデザイナー、エンジニア、コンサル、フォトグラファーのフリーランス • NJのDXGでお手伝い中

今日のタイムテーブル • 09:00-10:30 プロジェクトマネジメントについての座学とワークショップ準備 • 10:30-12:00 ワークショップ前半 • 12:00-13:00 お昼休み • 13:00-15:00 ワークショップ後半 • 15:00-15:45 講評

AGENDA • 座学 • 今日のワークショップについて • マネジメントとウォーターフォールと人月の神話 • AgileとScrum • カンバン、Kept、LFT • ワークショップ • LEGOでScrumを体験してみる

今日のおもちかえり • マネジメントについて考えるきっかけを持つ。 • 振られた作業に対して、意味を考える思考回路を持つ。 • 自身の作業を管理する手段を学ぶ。 • 自身の作業管理をチームで管理する手法を体験する。 • 変化に強い考え方を持つ。

注意事項 • わからないワード・単語があれば、手を挙げる必要もないので遠慮なく聞いて ください。 • 同じことをいつ何度聞いてもらってもOKです。自身が理解していないことは他 の参加者も理解が追いついていないと思っていてOKです。

今日のワークショップについて

マネジメント

マネジメントの必要性 • １人でする仕事には限界がある。 • 家建てる？ 道路つくる？ -> 予算取り、計画、客折衝、施工、納品、１人できる？ -> 無理。 • アプリつくる？ -> 見積もり、客折衝、コンサル、仕様定義、デザイン、設計、開発、納品、 請求、ぜんぶ１人でできる？ -> そのためのスキルセットを１人で揃えられる？ -> 無理じゃないけど結構大変。 • 仮にできたとして、１人だったらマネジメントはいらない？ -> むしろ超重要

マネジメントの必要性 • １人で仕事しないといけないプロジェクトは少ない（はず。。。。 • 大体はプロジェクトチームを立てよう、の流れになる。 • プロジェクトのマネジメントは重要。 • 規模が大きければ大きいほど、プロジェクトマネジメントは難しい。 • 規模が大きければ大きいほど、人がたくさん必要になる。 • 人が多ければ多いほど、チームマネジメントも難しくなる。

マネージャには程遠いのに マネジメントの知識がいま必要なの？

セルフマネジメントの重要性 • 最初は具体的な手順を教えてくれる。でもしばらく経つとそうもいかない。 • そもそもマネジメントが苦手なマネージャーも世の中にはいる。。。。 • 計画性がないとか、横槍がおおいとか、思いつきで五月雨に作業オーダーす るとか、MTGの立て方が下手だとか・・・ • 仕方ない。 -> いまの僕らの立場でなんとかなる問題じゃない。 • 受け身に言われたことだけやってると、自分が手を動かしてるのに内容を理解 できていないとかもあったりする。

セルフマネジメントの重要性 • だから、自分にアサインされた作業を、自分でコントロールする術を学びまし ょ、が今回の目標。 • マネージャーからオーダーされた作業を、いかにタスク分解できるか？ • いまなにをしていて、なにに困っていて、なにを考えていて、次どうするのか を可視化する術を学びましょ。 • 正しく伝えてくれるチームメンバーは、マネージャーとしてもありがたい。 • 重宝される人になりましょ、バイネームでアサインされるようになりましょ、 が今回の目標。

ウォーターフォールと人月の神話

ウォーターフォール • 全体工程を決める。 • 上の手順で確実に決める。 • 下の手順で確実に作る。 • 手戻りを想定しない。 要件定義 基本設計 詳細設計 開発 単機能テスト • 決められた納期工期を確実に遂行する。 結合テスト システムテスト

fi https://www. rstpenguin.co.jp/ganttchart/

ウォーターフォール • 表通り遂行できれば、わかりやすい。 • 作りたいものがはっきりわかっていて、 超長期プロジェクトに有効。 • 下に行けば行くほど、上のミスに取り返 要件定義 基本設計 詳細設計 開発 しがつかない。 単機能テスト • トラブルに弱い。 • 変更時の再調整が大変。 工程表の反映も大変。 結合テスト システムテスト

人月の神話 1000 • １人の月あたりの作業量が10。 • 総作業量が1000。 • だから100人月かかる。 25 • ４人いれば１ヶ月の作業量が40。 ヶ • ってことは25ヶ月でおわるね？ 月 10 10 10 10 • じゃあ10人いれば１0ヶ月でおわる？ １００人いれば１ヶ月でつくれる？ 0

人月の神話 1000 10 10 10 10 10 10 10 10 10 10 0 10ヶ月

人月の神話 1000 20 5 2 9 13 93 x 10ヶ月 = ???? 8 1 0 14 10 11

スケジュール、トラブル、人の違い、 相性、仕様の変更、納期の短縮 全部計算して、工程立てて！！！

無理！！！

だから、 ウォーターフォールじゃない アジャイルな考え方を体験しましょ

それを LEGOで 紙コップで 諸般の事情でLEGOが手に入りませんでした…

アジャイル

ウォーターフォール プロジェクト のはじまり 要件定義 基本設計 詳細設計 開発 単機能テスト 結合テスト システムテスト プロジェクト のおわり

アジャイル テスト 計画 プロジェクト のはじまり テスト 実 行 計画 行 実 プロジェクト のおわり

スクラム り 振 ２週間 ュー 実 行 レビ スプリント１ 計画 り 返 ュー レビ り 振 り 返 スプリント２ 計画 実 行 ２週間

スクラム • チームで効率的にプロジェクトを進めることができるフレームワーク。 • 長い期間を短い期間に区切って、都度、計画と振り返り、ズレを修正する。 • 短い期間で都度ズレを修正することで、見積もり制度を上げていく。 -> セルフマネジメント • １つの課題をチーム全員で取り組む。 • 短い期間の中で新しい手法を試す。 -> 業務Hack。 • 成果があれば継続する。失敗すれば期間内でやめる。 早い失敗は早い学びになる。 -> チーム内学習 • Fail fast, Learn fast.

スクラムイベント • １スプリントの中で、それぞれの内容についてのMTGのタイミングを決める。 • 朝回（朝でなくても昼でも） • 昨日できたこと、今日やること、その障害を短く、その他共有、１人３分程度を毎日 • スプリントアラインメント • 次のSprintでやることを決める会、長い時間を確保してしっかり決める • スプリントレトロスペクティブ • チーム内でのチームとしてのSprintの振り返り、Kpt、Lern, Fun, Thanks • スプリントレビュー • 成果の振り返り、正しいものを正しくつくれているか

マネジメントのポイント • 可視化 -> ツールの仕事 • スケジュール、要件、タスク、ログ、レポートを集めて、必要に応じたビジュアルで 見れるようにする。 • 細分化 -> 人の仕事 • 要件から作業に分解して、期日と担当者を決める。 • 定量化 -> 人とツールの仕事 • タスクの難易度を数値に置き換える。 • 定期的に期間を区切って、その期間にできることを決めて遂行する。を繰り返す。 • 定例化 -> 人の仕事 • 定量化した作業の報告、朝回、トラブル共有のタイミングを決めておく。

可視化、細分化、定量化、定例化 をスクラムイベントに当てはめる

可視化、細分化、定量化、定例化 をスクラムイベントに当てはめる を、実際にやってもらう。

スクラムマスター • いきなり、はいどーぞ。は、むずかしいと思う。 • ので、メンバーがそれぞれのチームを回りながらスクラムマスターやる。 • ちゃんと、スクラムイベントが回せてるか、マネジメントのポイントにあった イベントになってるか、をアドバイスする。 • スクラムマスターはチームがちゃんとスクラムできるチームに育てる役割。 チームに成長と、自らトラブルに気づけるように自浄作用ももたらす役割。 • スクラムイベントそれぞれのタイミングと時間はこちらで管理するので、 安心して。

カンバン、Kpt、LFT を、模造紙につくる。

カンバン ToDo Doing Done

カンバン • タスクボード • やらないといけないことを、ToDoにポストイットで書いて貼る。 • やってることをToDoから、Doingにポストイットを移動させる。 • やり終わったことをDoingから、Doneにポストイットを移動させる。 • かんたん。

Kpt Keep Problem Try

Kpt • Keep、Problem、Tryの略。 • プロジェクトをすすめる上での手段手法を模索する。 • 作業中に困ったことを、いつでもどんどんProblemに貼り出す。 • レトロスペクティブ（振り返り）で、そのProblemに対してのアプローチを 書いて、対象のProblemと重ねて、Tryに貼る。 • Tryを実践してみてうまくいけば、Keepに移動する。 ダメだったらもう一度Problemに戻す。

LFT Learning Fun Thanks

LFT • Learning、Fun、Thanksの略。 • プロジェクトをすすめる上での、学びと感情価を書き出す。 • 学びや良いと思ったことは、Lerningに書いて貼る。 • 面白いとか楽しい興味深いと思ったことは、Funに書いて貼る。 • 誰かに助けてもらったりフォローもらったりしたら、Thanksに書いて貼る。

やることはかんたん。 やるとむずかしい。

最後に

まちづくり。 • Lego4Scrumに倣って、まちづくりをしてもらう。 • どんな街をだれのために作るか、そのモックアップを紙コップで作ってもらう。 • レゴの用意が大変だったから。。

どんな街をだれのために。 • ペルソナ • だれのために • ユーザーストーリー • どんな価値のある街を想定して、どんなシチューションを想定したのか • コンセプト • その街のコンセプトは、”ペルソナ”だけじゃなく、”みんな”に対して価値を 提供できるものになっているのか

評価ポイント 1. ユーザーストーリーとコンセプトがしっかり考えられているか。 2. Kpt、LFTがどれぐらい書かれているか。 • うまくスプリントを回して、ちゃんと振り返りができているか。 3. カンバンがきちんと運用されているか。 4. モックが上記を満たして作られているか。

1スプリントは30分 1. 最初のスプリントはこれだけに専念する。 1. コンセプト、ユーザーストーリーを考えて、書き出して。 2. それに対して、カンバンにToDoを書き出して。

1スプリントは30分 2. そこから、スプリントをループさせる 1. アラインメント、５分 （やることを、カンバンのToDoからDoingに変える） 2. 開発、手を動かしてまちづくり、６分 （やってることが終わったら、都度DoingからDoneへ） 3. レトロスペクティブ、５分 （チームの作業を振り返って、Kept、LFTを書く） 4. リファインメント、５分 （そのスプリントを振り返って、カンバンに新しい作業をToDoに書く） 5. 開発、６分 6. レビュー、３分 （成果物、モックを振り返って、コンセプトとユーザーストーリーに沿っているか、チームで議論する）

タイムテーブル • 10:30-12:00 ワークショップ前半。 • 初回スプリントに30分、実スプリントを２回。 • 13:00-15:00 ワークショップ後半。 • 午後の１スプリントは、プランニングポーカーの紹介と振り返り。 • 13:30から、実スプリントを３回。 • 15:00-15:45 講評 • 休憩はチームで適宜どうぞ。

スタート

プランニングポーカーの紹介 • そのタスクの”主観難易度”を”チームの相対”で書く。 • 人によって作業の難易度は違う、だから主観でよい。 • 数字にはフィボナッチ数列を使う（隣り合った数字を足した数字に数列） • １，２、３，５、８，１３，２１，３４、５５ • 例えば、ここから梅田までの移動にかかる手間を３とする。 京都まで移動するのに、どれぐらい手間が掛かりそうか。 • チームで大きく難易度が離れた場合、なぜそう思ったかの議論をして、もう一回 数字を出す。チームで数字の合意を得たら記載する。