このブログ記事は、芝本秀徳著『誰も教えてくれない計画するスキル』を参考に、物語形式でプロジェクト計画の実践方法を解説したものです。
前回のあらすじと新たな挑戦
プロセス設計を終えた山田太郎率いるプロジェクトチーム。WBSで成果物を定義し、マイルストーンで重要な節目を設定し、プロセスフローで作業の流れを設計した。しかし、まだ重要な要素が欠けていた。
「素晴らしいプロセスフローができましたが、一つ問題があります。」月曜日の朝、プロジェクトルームで山田が切り出した。「これには時間の概念がありません。」
村上が首を傾げた。「時間の概念？」
「そうです。」山田は壁に貼られたプロセスフローを指差した。「情報収集から分析、文書化と流れは分かりますが、それぞれにどれくらい時間がかかるのか、いつ始めていつ終わるのかが見えません。」
李が理解を示した。「確かに、これでは『10月1日の本番稼働』に間に合うかどうか分かりませんね。」
「その通りです。」山田は新しい模造紙を広げた。「今日から、プロセスフローに時間軸を加えて、ガントチャートを作成します。」
「ガントチャート？」村上が質問した。
山田は説明を始めた。「20世紀初頭にヘンリー・ガントという人が考案した、スケジュールを視覚的に表現する手法です。横軸に時間、縦軸にタスクや成果物を配置し、作業期間を棒グラフで表します。これにより、いつ何をするのか、全体の時間的な流れが一目で分かるようになります。」
「なるほど、時間の地図のようなものですね。」村上が納得した。
「素晴らしい例えです！」山田が賛同した。「プロセスフローが作業の流れを示す地図なら、ガントチャートは時間の流れを示す地図。両方あって初めて、プロジェクトの全体像が見えてきます。」
フェーズで区切る：大きな塊から始める
山田はホワイトボードに向かった。「まず、プロセス全体をフェーズごとに分割します。細かいプロセス一つ一つをスケジュール化する前に、大きな塊で考えるんです。」
チームは完成したプロセスフローを眺めた。要件定義から本番稼働まで、膨大なプロセスが連なっている。
「マイルストーンを思い出してください。」山田が提案した。「要件定義承認、基本設計承認、開発完了...これらがフェーズの区切りになります。」
李が気づいた。「つまり、マイルストーンからマイルストーンまでが一つのフェーズということですか。」
「その通りです。」山田は縦線でプロセスフローを区切り始めた。「要件定義フェーズ、設計フェーズ、開発フェーズ、テストフェーズ、移行フェーズ。まずはこの5つの大きなフェーズで考えましょう。」
村上が質問した。「でも、きっちり区切れるんでしょうか？例えば、設計が終わらないと開発が始められないとか...」
「鋭い指摘です。」山田が応じた。「実は、フェーズは完全に独立しているわけではありません。重なる部分もあります。」
山田は図を修正した。設計フェーズの後半と開発フェーズの前半が少し重なるように描いた。「例えば、基本設計が固まれば、詳細設計と並行して開発環境の構築を始められます。」
「なるほど！」村上が理解した。「フェーズは区切りつつも、効率的に重ねられる部分は重ねるんですね。」
チームで議論を重ね、各フェーズの境界線を定めていった。完全に前フェーズが終わらないと始められない部分と、並行して進められる部分を見極める。この作業だけで1時間以上かかったが、全体の時間短縮につながる重要な検討だった。
「フェーズ分割ができました。」山田がまとめた。「要件定義フェーズが4月から5月中旬、設計フェーズが5月上旬から6月末、開発フェーズが6月中旬から8月末、テストフェーズが8月中旬から9月末、移行フェーズが9月中旬から10月初旬。約2週間ずつ重なりがあります。」
高橋マネージャーが見学に来ていた。「フェーズが重なることで、全体期間が短縮できるんですね。順番に実施したら6ヶ月以上かかるところが、5ヶ月強で収まっている。」
「はい、ただし」山田が注意を促した。「重なる部分は調整が複雑になります。設計変更が開発に影響したり、手戻りのリスクもあります。でも、適切に管理すれば、大幅な期間短縮が可能です。」
成果物に日付を入れる：楽観と現実の間で
フェーズ分割が終わり、次は各成果物の完成予定日を設定する段階に入った。
「では、各フェーズ内の成果物に具体的な日付を入れていきましょう。」山田がWBSを参照しながら言った。
村上が積極的に提案した。「要件定義書は2週間もあれば作れそうですね。5月1日完成でどうでしょう？」
李が現実的な指摘をした。「ちょっと待ってください。要件定義書を作るには、現状調査、ヒアリング、分析、文書化、レビュー、修正...これらすべてのプロセスが必要です。2週間では厳しいのでは？」
「李さんの言う通りです。」山田が補足した。「スケジュールを立てる時は、必要な作業量を正確に見積もることが大切です。」
「でも、どうやって見積もればいいんでしょう？」村上が困惑した。
山田は見積もりの方法を説明した。「いくつかの方法があります。まず、過去の類似プロジェクトの実績を参考にする方法。私たちの会社では、通常、要件定義に3〜4週間かかっています。」
「でも、今回はAI需要予測機能という新しい要素もありますよね。」李が付け加えた。
「その通り。新しい要素がある場合は、類推見積もりという方法を使います。」山田は説明を続けた。「既存の在庫管理機能の要件定義が2週間だったとして、AI機能の複雑さを考慮して1.5倍すると3週間。さらに...」
村上が割り込んだ。「さらに？」
「バッファです。」山田は重要なポイントに触れた。「すべてが順調に進むことはまずありません。病欠、会議の長期化、手戻り...様々な要因で遅延が発生します。」
チームで各成果物の作業量を見積もり、さらに20%のバッファを追加していった。要件定義書は4週間、基本設計書は3週間、詳細設計書は4週間...
「こうして見ると、かなりタイトですね。」村上が全体を眺めて言った。
李も同意した。「でも、成果物単位でスケジューリングすることで、進捗が明確に分かりますね。『要件定義フェーズ50%完了』では曖昧ですが、『要件定義書完成』なら明確です。」
山田はまとめた。「成果物ベースのスケジューリングの利点はまさにそこです。完成・未完成がはっきりし、遅延も早期に発見できます。」
依存関係という現実：パズルを解く
各成果物に日付を入れ終わった山田チーム。しかし、李が重大な問題を発見した。
「山田さん、これはおかしいです。」李がスケジュールを指差した。「詳細設計書の完成が7月15日で、プログラム開発の開始も7月15日になっています。」
「何が問題なんですか？」村上が尋ねた。
李が説明した。「設計書を読んで理解する時間が必要です。それに、設計書が完成しないと開発は始められません。これを依存関係と言います。」
山田は重要な局面だと感じた。「李さんの指摘通りです。単純に日付を入れただけでは、実行不可能なスケジュールになってしまいます。」
チームは依存関係の洗い出しを始めた。設計書がないと開発できない、テスト環境がないとテストできない、移行ツールがないとデータ移行できない...次々と依存関係が明らかになった。
「これは複雑なパズルですね。」村上がため息をついた。
「そうです。でも、解き方があります。」山田はクリティカルパスの概念を再度説明した。「以前マイルストーン設定で学んだクリティカルパス、覚えていますか？」
「遅れが許されない経路でしたね。」村上が思い出した。
「その通り。依存関係を考慮すると、必ずクリティカルパスが存在します。」山田は赤ペンで重要な経路をなぞった。「要件定義→基本設計→データベース設計→移行ツール開発→移行テスト→本番移行。この経路が最も時間がかかり、1日でも遅れるとプロジェクト全体が遅れます。」
李が別の問題を指摘した。「リソースの競合もありますね。私が詳細設計とデータ分析設計を同時期に担当することになっていますが、物理的に無理です。」
山田は調整を始めた。「では、データ分析設計を1週間後ろにずらしましょう。その間、村上さんが設計の一部をサポートしてください。」
このような調整を繰り返し、実行可能なスケジュールへと修正していった。依存関係を線で結び、リソース競合を解消し、全体のバランスを取る。まさにパズルを解くような作業だった。
「ようやく実現可能なスケジュールになりました。」山田が達成感を込めて言った。「依存関係を無視したスケジュールは絵に描いた餅です。現実的な制約を考慮することが、実行可能な計画の鍵なんです。」
締切からの逆算：現実との対峙
スケジュールがほぼ完成した時、スマートストアの田中部長から緊急の連絡が入った。
「山田さん、実は10月1日の本番稼働は絶対厳守なんです。」電話の向こうで田中部長の声が響いた。「10月は年末商戦の準備が始まります。それまでに新システムが稼働していないと、大変なことになります。」
山田はスケジュールを見直した。現在の計画では、すべてが順調に進んでも10月10日が本番稼働日だった。
「これは困りました。」山田がチームに状況を説明した。「今までは開始日から積み上げるフォワードスケジューリングで計画していましたが、10月1日から逆算するバックワードスケジューリングが必要です。」
「逆算ですか？」村上が聞いた。
「そうです。」山田は模造紙を裏返し、新しいスケジュールを描き始めた。「10月1日に本番稼働するには、9月25日には移行作業が完了している必要がある。そのためには9月20日にはユーザー受入テストが終わっていなければならない...という具合に、ゴールから逆算していきます。」
李が計算した。「逆算すると、要件定義を4月25日までに完了させる必要があります。でも、今日は既に4月15日...」
チームは各フェーズの短縮可能性を検討し始めた。要件定義で1週間、設計で1週間、開発で2週間...しかし、品質を犠牲にしての短縮は本末転倒だ。
「スコープの調整も考えましょう。」山田が提案した。「必須機能と追加機能を明確に分け、第一弾では必須機能のみをリリースする。」
高橋マネージャーも議論に加わった。「年末商戦で最も重要なのは在庫の正確な把握です。AI需要予測は第二弾でも構いません。」
このような調整を経て、10月1日の本番稼働が可能なスケジュールが出来上がった。必須機能に絞り、フェーズの重なりを最大化し、チーム全員の協力を前提とした、挑戦的だが実現可能な計画だった。
「逆算することで、本当に必要なものが見えてきました。」村上が感想を述べた。「締切を守るために何を優先すべきか、明確になりました。」
見える化の瞬間：壁一面のガントチャート
翌日、山田チームは巨大な模造紙にガントチャートを清書した。横軸には4月から10月までのカレンダー、縦軸には全ての成果物とプロセスが並ぶ。
「では、色分けしていきましょう。」山田が色ペンを配った。「青は要件定義関連、緑は設計関連、黄色は開発関連、オレンジはテスト関連、紫は移行関連です。」
チームで手分けして、各タスクの期間を色付きの帯で表現していった。さらに、担当者ごとに帯の中に模様を入れた。山田は横縞、村上は縦縞、李は斜線、という具合だ。
「クリティカルパスは赤い線で強調しましょう。」李が提案した。赤い線が、ガントチャート上を蛇のように這っていく。
「マイルストーンも忘れずに。」村上が赤い菱形のマークを主要な節目に配置した。要件定義承認、基本設計承認、プロトタイプ完成...
完成したガントチャートは、プロジェクトルームの壁一面を覆った。4メートル×2メートルの巨大な時間の地図だ。
「壮観ですね...」村上が息を呑んだ。
李も感嘆した。「プロジェクト全体が一望できます。誰が、いつ、何をするのか、すべて見える。」
スマートストアのメンバーも見学に来た。佐藤課長が驚いた。「これはすごい！私たちがいつ何をすればいいのか、一目瞭然です。」
田中部長も満足そうだった。「10月1日の本番稼働に向けて、着実に進んでいることが分かります。これなら安心して任せられます。」
山田はチーム全員を集めた。「このガントチャートは私たちの約束です。全員でこのスケジュールを守り、プロジェクトを成功させましょう。」
生きたスケジュール：2週間後の現実
プロジェクトが始動して2週間。定例の進捗会議で、山田はガントチャートの前に立った。
「現在の進捗を確認しましょう。」山田は実績を赤ペンで記入し始めた。計画の帯の下に、実績の帯を描いていく。
「現状調査は予定通り完了しました。」村上が報告した。「でも、ヒアリングが少し遅れています。スマートストアの担当者が急な出張で...」
李も報告した。「データ分析の準備は順調ですが、想定より複雑で、追加で3日必要です。」
山田は冷静に対応した。「スケジュールは生きています。現実に合わせて調整しましょう。」
ガントチャート上で、遅れているタスクは赤く、進んでいるタスクは青く色を付けた。全体の状況が視覚的に把握できる。
「ヒアリングの遅れは、分析フェーズの効率化でカバーできそうです。」李が提案した。「ヒアリング中に並行して分析の準備を進めています。」
村上も工夫を報告した。「出張中の担当者とはオンラインでヒアリングしました。むしろ、集中して話せて効率的でした。」
週次でスケジュールを更新することで、小さな遅れが大きな遅延になることを防いだ。また、前倒しで進んでいる作業を見つけ、リソースを遅れている作業に振り向けることもできた。
「見える化の効果を実感しています。」高橋マネージャーがコメントした。「以前なら『なんとなく遅れている』という不安を抱えていましたが、今は『ヒアリングが2日遅れだが、全体への影響は軽微』と具体的に把握できます。」
第6章のまとめ：時間を制する者がプロジェクトを制す
プロジェクト開始から1ヶ月。山田はチームとの定例会議で、スケジュール化から学んだ教訓を振り返った。
「この1ヶ月で、私たちは時間を味方につける方法を学びました。」山田が語り始めた。
村上が最初に発言した。「フェーズで大きく区切ることの重要性を学びました。いきなり細かいタスクをスケジュール化するより、まず大きな流れを作ることが大切なんですね。」
李も続いた。「成果物に日付を入れる際は、楽観的になりすぎず、作業量を正確に見積もることが重要でした。バッファの大切さも身に染みました。」
「依存関係の考慮も欠かせませんでした。」村上が付け加えた。「最初は面倒に感じましたが、これを無視すると実行不可能な計画になってしまう。」
李がまとめた。「そして、締切からの逆算。フォワードスケジューリングで間に合わない時は、バックワードで本当に必要なものを見極める。」
山田は満足そうに頷いた。「素晴らしいまとめです。そして何より、ガントチャートによる見える化が、チーム全体に安心感と一体感をもたらしました。」
「壁のガントチャートを見るたびに、自分の仕事の意味を実感します。」村上が言った。「全体の中での自分の役割が明確で、モチベーションが上がります。」
李も同意した。「進捗も一目瞭然。問題の早期発見と対策が可能になりました。」
山田は窓の外を眺めながら言った。「次はいよいよ最後のステップ、タスク分解です。この大きなスケジュールを、日々の具体的な作業に落とし込んでいきます。」
夕日がプロジェクトルームを橙色に染めていた。壁一面のガントチャートも、夕日を受けて輝いている。それは単なるスケジュール表ではなく、チーム全員の決意と約束が込められた、プロジェクト成功への道筋だった。
時間を味方につける。それは、時間に追われるのではなく、時間を管理し、コントロールすることだ。山田チームは、その術を確実に身につけていた。
読者の皆様へ
第6章では、プロセスフローをガントチャートでスケジュール化する具体的な手順を物語形式でお届けしました。
スケジュール化の要点は以下の通りです：
- プロセスをフェーズごとに分割する
- 成果物に日付を入れる（作業量を正確に見積もり、バッファを考慮）
- 依存関係を洗い出し、調整する
- 締切から逆算して現実的な計画を立てる
- ガントチャートで見える化する
スケジュールは一度作って終わりではありません。定期的に更新し、現実に合わせて調整することで、生きたスケジュールとなります。
次回の最終章では、このスケジュールを日々の作業レベルまで分解し、確実に実行するための「タスク分解」について学びます。お楽しみに！