開発プロジェクトのWBS・ガントチャート・かんばん作成

• 日程: Day 9 / セッション 3
• 時間: 11:10-12:40（90分）
• 形式: 実習（ハンズオン実習、AIサポートあり）
• ゴール:

  • 行動: 自チームの開発について全タスクを洗い出し、WBS・ガントチャート・かんばんを作成できる
  • 条件: Day5-8の設計書を入力にして、AIにクリティカルパスをレビューしてもらいながら
  • 基準: 90分以内に、（1）WBSが3階層以上で末端30件以上、（2）ガントチャートでDay10-17に収まる、（3）かんばんが役割別に担当者割当済み、（4）Day14中間発表のマイルストーンが置かれている
• 学習形式: AI協働型（ハンズオン実習、グループワーク）

直前のセッションで身近なテーマでかんばんを作りました。手法そのものは身についたはずです。

ここからは本番。自チームの開発プロジェクトで同じことをやります。違いはひとつ、入力が設計書になるということ。

設計書（画面一覧・機能一覧・テーブル定義書・CRUD図・機能設計書）を見ながら、「この機能を実装するには何時間？」「誰が担当する？」を1つずつ決めていきます。難しそうに聞こえますが、設計が良くできていれば、タスク分解は自然と進みます。

そして守るべき3つの制約があります。

• 期間は Day10-17 の 7日間（実装6日＋プロトタイプ1日）
• Day14は中間発表（ここで「動くもの」がないとつらい）
• Day17で実装完了（Day18からは発表準備）

この箱の中に収まる計画を作ります。

設計書のどこを見ればタスクが見えるか、対応表で示します。

設計書1行＝タスク1つ以上が原則です。設計書にない機能を勝手に実装してはいけませんし、設計書にある機能を忘れてもいけません。設計書とタスクの一覧を突き合わせて漏れチェックすることが品質を守ります。

Day1で決めた役割をもう一度思い出します。

• PM（プロジェクトマネージャ）
• リーダ
• サブリーダ
• デザイン担当
• 開発担当

各役割が主に担当するタスク種別の例。

役割は専属担当ではなく主担当です。全員が自分の役割以外のタスクも経験することで、相互補完が効きます（Day1で学んだ「相互学習による個人能力の拡大」）。

クリティカルパスは、「これが遅れたら全体が遅れる」一本の経路です。開発プロジェクトでよくあるクリティカルパスは下のようなものです。

この線上のタスクは1日も遅らせられません。逆に、この線から外れたタスク（CSSの細かい調整・エラーメッセージの文言修正など）は遅れても全体に影響しません。

マイルストーンは、節目を明示する印です。本研修では以下を必ず置きます。

クリティカルパスという考え方は、1950年代にデュポン社のエンジニアたちが化学プラントの建設プロジェクトを効率化するために編み出した手法（CPM: Critical Path Method）が始まりです。当時、何百という工事タスクのどれを優先すべきかが分からず、ある日決定的に重要な「最長経路」だけを最適化すればよいと気づいたのです。70年経った今もソフトウェア開発で使われ続けているのは、「全部頑張る」は不可能で、「肝心なところを外さない」が現実解だからです。

クリティカルパス上のタスクには**バッファ（予備時間）**を持たせます。本研修では「Day13までに中間発表用の動くもの」を目標にしておくと、Day14に余裕が生まれます。

自チームの開発プロジェクトについて、以下を作成してください。

• 設計書（画面一覧・機能一覧・テーブル定義書・CRUD図・機能設計書）を見ながら、必要なタスクをすべて付箋・スプレッドシート・カードに書き出す
• 1人あたり最低10枚以上書く（5人チームなら50枚以上の素材ができる）
• AIに「以下の設計書からタスクを洗い出してください」と渡して、自分たちの洗い出しと突き合わせる

• 洗い出したタスクを階層構造に整理する（3階層以上）
• 例: 「予約システム実装」→「予約機能」→「予約登録・予約変更・予約キャンセル」→末端タスク
• 末端タスクは「半日以内に完了」の粒度
• 30件以上の末端タスクが目安

• WBSの末端タスクをDay10-17の時間軸に配置
• 依存関係（〜が終わらないと〜は始められない）を矢印で示す
• 中間発表（Day14）までに「動くもの1セット」が完成するように配置
• 担当者ごとに行を分けると、並行作業が見える

• 各タスクを「カード」化（前セッションの4要素＋担当役割）
• Todo列に、Day11の朝に取りかかる順序で並べる
• 全タスクが「担当者・所要時間・成果物・終了条件・役割」を持つ

• AIにWBSとガントチャートを見せて以下を聞く

  • 「このガントチャートでクリティカルパスはどれですか？」
  • 「Day14の中間発表に間に合うリスクはありますか？」
  • 「漏れているタスクはありますか？」

• タスクの洗い出し: 末端タスク30件以上
• WBS: 3階層以上の階層図
• ガントチャート: Day10-17の時間軸、担当者別の行、依存関係、中間発表マイルストーン入り
• かんばん: 全タスクが4要素＋役割を持ち、Todo列に並んでいる

• 完璧を目指さない。7割で動かして、走りながら更新する前提で作る
• 各タスクに「これが遅れたら誰に影響するか」を一言メモすると、依存関係が見える
• バッファタスク（明示的に「予備時間」と書いたカード）をDay13とDay17に置くと、リカバリが効く
• 「実装」だけでなく「テスト」「ドキュメント更新」「資料準備」も忘れない
• AIに「私たちの開発テーマは〇〇です。WBSが妥当か評価してください」と全体レビューを頼む

• 「以下のテーブル定義書から、必要な実装タスクを末端レベルで列挙してください」
• 「私たちの計画では、Day14の中間発表でログイン機能と予約一覧を見せる予定です。Day13までに動かすには、どのタスクを最優先すべきですか？」
• 「メンバーAの担当タスクが10枚、Bが3枚と偏っています。どう調整するのが良いですか？」
• 「『デザイン調整』というタスクは何時間を見積もるのが現実的ですか？理由も教えてください」

• 末端タスク30件以上ある
• 全タスクに担当者がいる（「全員」「未定」はない）
• 全タスクに終了条件が「〜が完成している」形式で書かれている
• ガントチャートがDay10-17に収まっている
• Day14の中間発表前に「動くもの1セット」が並んでいる
• Day17で全タスク完了予定
• バッファタスクが最低1件入っている
• AIにレビューしてもらい、指摘されたリスクを文書化した

このセッションでは、自チームの開発プロジェクトについて、WBS・ガントチャート・かんばんを完成させました。

明日からの実装期間（Day11-17）では、このかんばんを毎日朝会と終会で動かします。

• 朝会: 今日やるTodoを宣言、Doingに移す
• 終会: 終わったDoingをDoneに動かす、新しいTodoを並べる

計画は生き物です。やってみて違ったら更新する、想定外が起きたら相談して修正する。この柔軟さと記録の両立が、チーム開発を成功させます。

最後に、完成したかんばんをチームで声に出して読み合わせしてください（話す＆行う）。「明日の朝、〇〇さんは△△から始めます」と1人ずつ宣言できれば、計画は身につきます。

以下の問いに答えられるか確認してみましょう。

• 自チームのクリティカルパスはどのタスクの連なりですか？
• Day14の中間発表で「動くもの」として何を見せる予定ですか？
• 計画が遅れ始めたら、最初に何をしますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 関連用語: バーンダウンチャート、ベロシティ、スプリントレビュー
• 発展課題: バーンダウンチャート（残タスク数を時間軸でプロット）を毎日更新してみる
• 参考: 実装期間中、毎日の終会でかんばんを更新します。Day14中間発表ではこのかんばんを使って進捗報告します