プロジェクトマネジメント〜WBSとかんばん

• 日程: Day 9 / セッション 1
• 時間: 9:30-10:00
• 形式: 座学
• ゴール: WBS（Work Breakdown Structure）によるタスク分解の手順と、かんばんの3状態（Todo/Doing/Done）によるタスク管理を説明できる
• 学習形式: 対話型解説、デモンストレーション

Day 8までで、みなさんは外部設計書と内部設計書を完成させました。設計図はそろいました。
明日からはいよいよ実装です。

ここで1つ問いかけです。
「実装、何から始めますか？」

「えーと、まずDBを作って……いや画面から……？」と迷ったら、それが今日のテーマです。
設計書があっても、作業の順番と分担が決まっていなければ、チームは動けません。

• 誰が・何を・いつまでにやるのか
• 今どこまで進んでいるのか
• 間に合いそうか、間に合わなそうか

これを「見える化」する技術がプロジェクトマネジメントです。
今日は3つの道具、WBS・ガントチャート・かんばんを手に入れます。

実装期間はDay 10〜17の実働約8日。この限られた時間を乗り切る地図を、今日のうちに作ります。

プロジェクトとは「期限までに目的を達成する活動」です。
そして人間は、大きすぎる仕事をそのままでは扱えません。

これは料理に例えると分かりやすいです。
「カレーを作る」と言われても、手は動きません。でも、

• 材料を買う
• 野菜を切る
• 肉を炒める
• 煮込む
• 盛り付ける

と分ければ、すぐ動けます。しかも「野菜を切るのは私、肉を炒めるのはあなた」と分担もできます。

この「大きな仕事を、管理できる小さな単位に分解する」手法が WBS（Work Breakdown Structure：作業分解構成図） です。

WBSの手順はシンプルです。

1. 成果物・大きな工程を最上位に置く（例: カレー完成）
2. それを中分類に分ける（例: 買い出し / 調理 / 仕上げ）
3. さらに「1人が数時間で終わる」程度の作業（タスク）まで分ける
4. 漏れ・重複がないか確認する（Day 1で学んだ MECE の出番です）

「カレーを作る」はタスクとして大きすぎるので該当しません。「野菜を切る」は1人が30分で終えられるので、ちょうどよいタスクです。なぜなら、タスクは担当者を割り当てられ、終わったかどうか判定できる大きさである必要があるからです。

ここで少し考えてみてください。「旅行の準備」をWBSで分解すると、どんなタスクが出てくるでしょうか？ 頭の中で3つ挙げてみましょう。次のセッションの予行演習になります。

• タスクの大きさの目安は「1人が数時間〜1日で完了できる」こと
• 「実装する」のような巨大タスクは分解不足のサイン。進捗が何日も「作業中」のままになる
• 分解したら必ずMECEチェック。「漏れ」は後で爆発し、「重複」は二度手間になる
• WBSは作業の構造を表すもの。順番や日程はまだ決めない（それは次のガントチャートの仕事）

WBSの起源は1960年代、アメリカのアポロ計画やポラリス・ミサイル開発と言われています。「人類を月に送る」という史上最大級のあいまいな目標も、何十万ものタスクに分解されたからこそ実現しました。月面着陸も、元をたどれば「ネジを締める」レベルのタスクの集合だったわけです。みなさんの開発も同じ。「すごいシステムを作る」は、分解すれば「テーブルを1つ作る」から始まります。

WBSでタスクが出そろったら、次は「いつやるか」です。
タスクを横棒で時間軸に並べた図を ガントチャート と呼びます。

ガントチャートを書くと、2つの大事なことが見えてきます。

• 依存関係: 「材料を買う」前に「煮込む」ことはできない。前のタスクの成果物を使うタスクは、順番が固定される
• クリティカルパス: 開始から完了までの「一番時間がかかる経路」。この経路上のタスクが遅れると、プロジェクト全体が遅れる

上の例では「献立→買い出し→野菜を切る→煮込む→盛り付け」がクリティカルパスです。「肉を炒める」が10分遅れても全体は遅れませんが、「煮込む」が10分遅れると夕食は10分遅れます。

ここで問いかけです。みなさんの開発で、絶対に最初にやらないと後が全部止まるタスクは何でしょうか？ 思い浮かべてみてください（ヒント: データの置き場所がないと、登録機能は作れません）。

• ガントチャートは「WBSのタスク＋時間軸＋依存関係」でできている。WBSなしにいきなり書こうとすると漏れる
• クリティカルパス上のタスクを最優先で着手する
• 計画は必ずずれる。ずれたら直すのが正しい使い方。「計画通りに進める」より「ずれにすぐ気づく」ことが目的

ガントチャートの名前は、考案者ヘンリー・ガント（1861-1919）にちなんでいます。100年以上前、第一次世界大戦の造船管理で使われた手法が、今もそのままIT業界の現役ツールです。プログラミング言語は数年で流行が変わるのに、ガントチャートは1世紀生き残っている。「人間が時間と作業を理解する方法」は、技術が進んでも変わらないということですね。

ガントチャートは「計画」を見るのに優れていますが、日々の「今、誰が何をしているか」を見るには重い道具です。
そこで日々の管理には かんばん を使います。

かんばんのルールは驚くほどシンプルです。
タスクを付箋（カード）にして、3つの列のどれかに貼るだけ。

カードには次の4点を書きます。これが今日の演習の核になります。

• 担当者: 誰がやるのか
• 所要時間: どれくらいかかる見込みか
• 成果物: 何ができたら終わりか
• 終了条件: どういう状態になったら「Done」に動かしてよいか

「資料を準備する」は終了条件として該当しません。「発表用スライド10枚が完成し、リーダーのレビューを通過している」なら該当します。なぜなら、前者は人によって「終わった」の判断が変わるのに対し、後者は誰が見ても判定できるからです。

• Doingに置けるカードは1人1枚までが原則。あれもこれも同時にやると、全部が中途半端になる
• 「90%できてます」が一番危険。かんばんの世界に90%はない。DoneかDoneでないか、だけ
• Doneの判定基準＝終了条件を、カードを書く時点で決めておく。後から決めると甘くなる

「かんばん」は日本語そのままで世界に通じる言葉です。起源はトヨタ自動車の生産方式。工場で部品箱に付けた「看板」で生産指示を伝えた仕組みを、2000年代にソフトウェア開発者が応用しました。今ではシリコンバレーのエンジニアも「Kanban」と呼びます。寿司、カラオケ、かんばん——海外で通じる日本語の仲間です。ちなみにトヨタ社内では「看板が外れる」ことが生産の合図でした。みなさんはカードを「動かす」ことが進捗の合図になります。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「WBSとガントチャートとかんばんの関係を、運動会の準備に例えて説明して」
• 「クリティカルパスって何？ もっと簡単な例で教えて」
• 「タスクの粒度がちょうどいいか、どうやって判断するの？」
• 「実務のチームでは、かんばんにどんなツールを使っているの？」

今回学んだことを一言でまとめると、**「大きな仕事はWBSで分解し、ガントチャートで時間に並べ、かんばんで日々動かす」**です。

• WBS: 仕事を管理できる大きさに分解する（MECEに）
• ガントチャート: タスクを時間軸に並べ、依存関係とクリティカルパスを見る
• かんばん: Todo/Doing/Doneの3状態で「今」を見える化する
• カードには担当者・所要時間・成果物・終了条件を書く

3つは別々の道具ではなく、WBS→ガントチャート→かんばんという流れでつながっています。

次のセッションでは、身近な疑似プロジェクト（発表会・宴会・海外旅行）を題材に、実際にかんばんを作ってみます。

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

• WBSとは何か、何のために行うか説明できますか？
• タスクのちょうどよい大きさの目安は？
• ガントチャートで分かる「クリティカルパス」とは何ですか？
• かんばんの3つの状態と、カードに書くべき4項目を言えますか？
• 「終了条件を曖昧にしない」とは、具体的にどう書くことですか？

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

• 参考リンク: PMBOKガイド（プロジェクトマネジメントの国際標準）の概要解説記事、Trello・GitHub Projectsなどのかんばんツール紹介ページ
• 発展課題: 「WIP制限（Work In Progressの上限）」とは何か、なぜかんばんで重要なのかをAIに聞いてまとめてみましょう

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