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

• 日程: Day 9 / セッション 3
• 時間: 11:10-12:40
• 形式: 実習
• ゴール: 自チームの開発について全タスクを洗い出し、WBS・ガントチャート・かんばんを時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで、疑似プロジェクトを使ってかんばん作りを体験しました。
今度は本番です。自分たちの製品を、Day 10〜17の実装期間で完成させるための計画を作ります。

ここで考えてみてください。
みなさんの実装に使える時間は、実際どれくらいあるでしょうか？

Day 10〜17は8日間。ただしDay 10はプロトタイプ作成、Day 14は中間発表です。
1日3時間のうち朝会・終会を除くと、実装に使えるのは1日約2.5時間。
つまり正味の実装時間は合計でも15時間程度——映画7〜8本分しかありません。これが現実です。

限られた時間で完成させるには、「何となく頑張る」ではなく、
今日作るWBS・ガントチャート・かんばんが命綱になります。
このセッションの成果物は、明日からDay 17まで毎日使い続けます。研修で一番「使い倒される」成果物です。

疑似プロジェクトとの最大の違いは、タスクの種が既に手元にあることです。
Day 5〜8で作った設計書を思い出してください。

• 画面一覧 → 画面を作るタスクの種
• 機能一覧・機能設計書 → 機能を作るタスクの種
• テーブル定義書 → DB（データ置き場）を作るタスクの種

つまり「タスクの関係を常に意識する」——前のタスクの成果物を利用する、という本研修の心がけがそのまま効いてきます。
設計書とWBSを突き合わせれば、漏れはかなり防げます。

ただし、設計書に載らないタスクもあります。たとえば：

• 開発環境の準備（実行環境・ツールのセットアップ）
• テストデータの作成
• 動作確認・テスト
• 中間発表の資料作成とデモ準備

「画面一覧の画面を全部タスク化したから完璧」は該当しません。環境構築やテストが漏れているからです。「設計書由来のタスク＋設計書に載らない作業タスク」まで含めて初めてMECEなWBSになります。

• WBSの大分類は「環境構築 / DB構築 / 機能実装 / テスト / 中間発表準備」あたりが定番
• 機能実装は画面単位・機能単位に分解する。「ログイン画面の表示」「ログイン処理」のように
• 1タスクの目安は2.5時間（1日の実装時間）以内。それを超えるものは分解する

ソフトウェア業界には「ホフスタッターの法則」というジョークのような法則があります。いわく「作業はいつも予測より長くかかる。ホフスタッターの法則を考慮して見積もった場合でも」。認知科学者ダグラス・ホフスタッターが自著の執筆遅延から生んだ言葉です。プロでも見積もりは外れるのだから、新人のみなさんが外れるのは当然。大事なのは外れないことではなく、外れたとすぐ分かる仕組み（かんばんと終会）を持つことです。

タスクが出そろったら、Day 10〜17のカレンダーに並べます。
このとき絶対に外せない点が2つあります。

1つ目: Day 14は中間発表。 ここで「動くもの」を最低1つデモします。
つまり実質、Day 13までに核となる機能を1つ動かすのが最初の目標です。
このような「ここまでに必ずこの状態になる」という節目をマイルストーンと呼びます。

2つ目: クリティカルパスを見つける。 多くのチームでは、
「環境構築 → DB作成 → データ登録機能 → データ表示機能」が最長経路になりがちです。
この経路上のタスクは最優先・最初に着手します。

ここで問いかけです。もし計画段階で「全タスクの合計時間」が「使える時間」を超えていたら、どうしますか？
答えは「徹夜」ではありません。機能を削るのです。ペルソナの課題解決に直結する「核となる体験」を守り、なくても成立する機能（あったら便利系）を後回しリストに移します。これは負けではなく、プロの判断です。

• マイルストーン: Day 14中間発表（デモできる機能1つ以上）、Day 17実装完了
• クリティカルパス上のタスクから着手する。「簡単そうなもの」からではない
• 全員の作業負荷を見比べ、特定の1人にクリティカルパスが集中しないようにする
• 計画が時間に収まらないなら機能を削る。削る候補も今日決めておくと、後で揉めない

ソフトウェア工学の古典『人月の神話』（1975年）には「ブルックスの法則」が登場します。「遅れているプロジェクトに人を追加すると、さらに遅れる」。新メンバーへの説明や連携のコストが、追加された労働力を食いつぶすからです。みなさんのチームは人数固定なので、遅れたときの選択肢は「時間を増やす」ではなく「タスクを削る・順番を変える」。50年前にIBMの大型コンピュータ開発で得られた教訓が、そのまま使えます。

演習中、AIをプロジェクト計画のレビュアーとして使いましょう：

• 「この機能一覧で、実装タスクの洗い出しに漏れはない？ 環境構築系も含めてチェックして」
• 「このタスク一覧でクリティカルパスはどこになりそう？」
• 「実装経験が浅い場合、『ログイン機能』の実装は何時間くらい見ておくべき？」
• 「実働6日でこのタスク量は現実的？ 削るならどの機能が候補？」

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

1. タスクの洗い出し（20分）

   • 外部設計書・内部設計書を広げ、画面・機能・テーブルからタスクを抽出する
   • 設計書に載らないタスク（環境構築・テストデータ・テスト・中間発表準備）を追加する
   • WBSとして大分類→タスクの階層に整理し、MECEを確認する
2. ガントチャート作成（20分）

   • タスクをDay 10〜17に割り付ける
   • 依存関係を線で結び、クリティカルパスに印を付ける
   • マイルストーンを置く: Day 14中間発表（デモ可能な機能1つ以上）、Day 17実装完了
   • 時間が足りない場合は、削る機能を決めて「後回しリスト」に移す
3. かんばん作成（20分）

   • 全タスクをカード化する（担当者・所要時間・成果物・終了条件の4項目）
   • Todo/Doing/Doneの3列に配置（現時点では全てTodo）
   • Day 11の朝会で最初に動かすカードを決めて印を付ける
4. AIレビューと最終確認（5分）

   • タスク一覧と計画をAIに見せ、漏れ・無理な詰め込みを指摘してもらう

• 「タスクの洗い出し」（WBS形式で階層化されたタスク一覧）
• 「WBS」
• 「ガントチャート」（Day 10〜17、依存関係・クリティカルパス・マイルストーン入り）
• 「かんばん」（4項目記入済みカード、Todo/Doing/Done の3列）

この4点はDay 11以降、毎日の朝会・終会で使います。チーム全員がいつでも見られる場所に置いてください。

• タスク出しに詰まったら、画面遷移図を指でなぞりながら「この画面を出すには何が要る？」と1画面ずつ確認すると漏れが見つかります
• 所要時間の見積もりに自信がなくて当然です。AIに「初心者がこの機能を作る場合の時間」を聞き、さらに1.5倍しておくと安全です
• クリティカルパスが分からなければ、AIに依存関係付きのタスク一覧を渡して「最長経路はどれ？」と聞けます
• 「全機能を実装する計画」になっていたら危険信号。中間発表までに動かす機能を1〜2個に絞り、残りに優先順位を付けましょう
• 終了条件の書き方を忘れたら、前セッションの成果物（疑似プロジェクトのかんばん）を見返してください。同じ書き方です
• 計画は明日から毎日更新するものです。今日の時点で完璧を目指しすぎないこと。60分で「全タスクが見えている状態」を優先しましょう

今回学んだことを一言でまとめると、**「設計書からタスクを洗い出し、中間発表から逆算した実行可能な計画に落とす」**です。

• タスクの種は設計書にある。ただし環境構築・テスト・発表準備は設計書の外にある
• Day 14中間発表をマイルストーンに、クリティカルパスから着手する
• 時間が足りなければ機能を削る。核となる体験を守る
• かんばんは今日から研修終了まで、チームの「現在地」を示し続ける

これでDay 9までの設計・計画フェーズは完了です。
次回Day 10は、プロトタイプ作成。画面遷移図が「動く紙芝居」になります。いよいよ作るフェーズの始まりです。

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

• 自チームのクリティカルパスはどのタスクの連なりか、言えますか？
• Day 14の中間発表までに「動かす」と決めた機能は何ですか？
• 時間が足りないと分かったとき、最初にやるべきことは何ですか？（ヒント: 徹夜ではない）
• 明日の朝、最初にDoingへ動かすカードはどれですか？

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

• 参考リンク: Mermaidのganttチャート記法ドキュメント（テキストでガントチャートを管理したいチーム向け）、GitHub Projects・Trelloの使い方ガイド
• 発展課題: 「ベロシティ」というアジャイル開発の用語をAIに聞いてみましょう。Day 11以降、自チームの1日あたりの完了タスク数を記録すると、計画の精度が上がっていきます

このセクションは、受講者が理解を深めることをサポートする参考情報です。