クリティカルパス最長ルートが最短を生む理由

こんにちは。あなたが今回シェアしてくれたこの資料、一緒に深く読み解いていきましょうか。 はい、よろしくお願いします。 今回のテーマは、プロジェクト管理のまあ心臓部とも言えるアローダイアグラムとクリティカルパス。 ええ。手元にあるのは資格試験の学習者向けに書かれた対話形式のテキストですね。 これがプロジェクト計画の手法を身近な例えで解説してくれてて、すごくわかりやすいのですよね。 そうですね、とっつきやすいですよね。 で、今回の私たちの探求なんですけど、単に用語を覚えるんじゃなくて、なぜプロジェクトで最も時間がかかる道筋が、 逆に成功への最短ルートになるのかっていう、この一見すると逆説的な考え方の面白さ、これを一緒に解き明かせたらなと思ってます。 ええ、これは単なる計画の立て方っていう話に留まらないんですよね。プロジェクトっていう絶えず変化する生き物みたいなものを どう動かしてどこに神経を集中させるべきか、そのマネジメントの勘所を掴むための非常に重要な思考ツールと言えますね。 では早速、その本質から。資料にある料理の例え、ここから始めましょうか。 はい。お米を炊くのに40分、同時におかずを作るのに20分かかります。さて、最短で何分後に食事ができますか？ もちろん答えは長い方、つまり40分ですよね。ですよね。 おかずが20分で出来上がっても、肝心のお米が炊けるのを待たないと食卓には並べられませんから。 このあまりに当たり前の考え方が、実はプロジェクト計画の基本なんだと。たくさんの作業が複雑に絡み合うプロジェクトも突き詰めればこの料理の同じで、 結局全体の終了時間を決めるのは一番時間がかかる一連の作業ルートだということなんですね。 この一番重要なルート、何か特別な名前があるんですか？ はい。それを専門用語でクリティカルパスと呼びます。 クリティカルパス。ええ、日本語にすると「重大な経路」とか「致命的な道筋」といったところでしょうか。 このクリティカルっていう言葉のニュアンスが非常に重要なんです。そこなんですよ。 資料の中の学習者も同じ疑問を口にしてますけど、普通は最短を目指すのになぜ最長が大事なんですかと。 ええ。プロジェクトを1日でも早く終わらせたいのに、一番時間がかかる道のりに注目するって、なんだか直感に反する気がしますよね。 その逆説こそがこの手法の肝なんです。クリティカルパスがなぜ最重要かと言うと、そこには余裕というものが一切ゼロだからです。 余裕がゼロ。はい。この道筋の上にある作業がたった1日遅れただけで、 プロジェクト全体の完成が1日遅れることが確定してしまう。他のもっと短い時間で終わる作業の道筋には、 多少の遅れを吸収できる遊びの時間があるんですけど、あーなるほど。 このクリティカルパスにはそれが全くない。だからこそプロジェクトマネージャーが最優先で監視し管理すべき、プロジェクトの命運を握る道になるんです。 なるほど。プロジェクト全体のスケジュールを守りたければ、この一番長い道のりから一瞬も目を離すなと、そういうことなんですね。 そういうことです。その遊びとか余裕についてももう少し掘り下げたいんですけど、また料理の例えに戻りますが、 40分のお米炊きと20分のおかず作り、ここに20分の時間の差がありますよね。ええ。 おかず作りの方は炊き上がりを待つ待ち時間が20分ある。この余裕のことを資料ではスラックと呼んでいますね。 その通りです。クリティカルパス上の作業は、定義上このスラックがゼロの作業の連なりということになります。 理屈はよくわかります。でも実際の現場を想像するとどうなんでしょう。おっ、あのチームは20分のスラックがあるぞなんてわかったら、 上から「じゃあこの仕事も追加でやっといて」とか。ありますね。 もっと前倒しで終わらせよう、みたいなプレッシャーがかかって、せっかくの余裕なんてあっという間に消えちゃいそうな気もするんですけど。 鋭い指摘ですね。そしてそこが凡庸なマネージャーと優れたマネージャーの分水嶺なんです。ほう。 凡庸なマネージャーはスラックを単なる空き時間と見なして、そこに追加のタスクを詰め込もうとする。 結果、全ての作業が余裕ゼロ、つまり全ルートがクリティカルパスのような状態になってしまう。うわあ。 これではどこか一つでトラブルが起きただけで、プロジェクト全体が即座に破綻します。まさに火薬庫の上を歩いているような状態ですね。 一方で優れたマネージャーは、スラックを単なる空き時間ではなくて極めて重要な戦略的資源として捉える。 むしろ積極的に守ろうとします。資源ですか？ 時間的な余裕さそのものが、お金とか機材のような資源になると。ええ。それはまるで銀行に預けてあるお金みたいに、 いざという時に引き出して使えるというイメージでしょうか。まさにその通りです。具体的な例を挙げましょう。 例えばあなたのプロジェクトのクリティカルパス上にサーバーの構築という作業があって、機材トラブルで遅れそうだとします。はい。 一方で操作マニュアルの作成という作業には10日間のスラック、つまり余裕がある。普通のマネージャーは「マニュアル班は順調だな、よろしい」で終わります。 ええ、まあそうですよね。でも優れたマネージャーはその10日間を戦略的予備兵力と見るんです。 予備兵力。マニュアル班の中に技術に詳しいライターがいることを見抜いて、 「すまないが1日だけサーバー構築のテストを手伝ってくれないか」と頼む。マニュアル作成はあと9日の余裕があるのでびくともしません。 でもその1日の応援でクリティカルパス上の遅れを取り戻せるかもしれない。うわあ、面白い。 このスラックという名の予備兵力、自在に動かせるかどうか。これがプロジェクトの勝敗を分けるんです。 余裕を可視化することはリスク管理の第一歩なんですよ。スラックはただのバッファーじゃなくて、攻めに使える手駒でもあるんですね。 そうなんです。そう考えるとどの作業にどれだけスラックがあるかを正確に把握しておくことがいかに重要かよくわかります。 でもこの考え方を人に当てはめると、クリティカルパス上の担当者は相当なプレッシャーですよね。ええ、本当に。 自分の遅れが即全体の遅れになるわけですから。ええ。だからこそ話はここから単なるチャートの話ではなく、もっと生々しい現場の知恵へと繋がっていきます。 ぜひ聞きたいです。多くの経験豊富なプロジェクトマネージャーが、冗談めかして、でも本気で言う鉄則があるんです。はい。 それは「クリティカルパス上のメンバーには絶対に無理をさせない、なんなら風邪も引かせない」というものです。 ははっ、風邪も引かせない、でもすごくよくわかります。でしょう。その人が1日休むだけで、プロジェクト全体が1日遅延するんですから。 もはやタスク管理じゃなくて、最優先ラインを担う人のコンディション管理こそがプロジェクト成功の鍵だっていう現場のリアルな感覚ですね。 そうなんです。この話は特にIT業界で有名なある法則と繋げると、さらにその重要性が理解できます。ほう。 ブルックスの法則という言葉聞いたことありますか？名前だけは。確かプロジェクトが遅れているからといって人を増やしても解決しないというような話でしたっけ？ その通りです。遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れるというまあ恐ろしい経験則です。なぜだと思いますか？ んー、新しい人が来てもすぐには戦力にならないから、とかでしょうか。それもありますね。理由は大きく二つ。 一つは新メンバーへの教育コストです。現状とか技術的な背景を説明するために、既存の優秀なメンバーの時間が奪われてしまう。ああ、なるほど。 そしてもう一つ、こちらがより深刻なんですけど、コミュニケーションの複雑さが爆発的に増えるからです。コミュニケーションの複雑さ？ 例えば3人のチームならコミュニケーションの経路は3本です。でも人を倍の6人にすると経路はなんと15本にまで増える。 6人で15本。ええ。人が増えれば増えるほど、調整のための会議とか連絡が増えて、かえって全体の効率が下がってしまうんです。 なるほど。単純な足し算じゃないんですね。私も若い頃プロジェクトが炎上して、「とにかく人手が足りません」って上司に泣きついて、 メンバーを倍にしてもらったことがあるんです。おお。 結果ですか？見事に火に油を注ぎました。新メンバーへの説明で元のメンバーの時間が見事に奪われてもう大混乱でした。 ブルックスの法則は教科書で読むのと身をもって体験するのとでは重みが全く違います。 それは壮絶な経験ですね。つまりクリティカルパスが遅れているからといって、じゃあ人を増やそうと安易に考えても、問題は解決しないどころか悪化する可能性すらあると。 ええ。だからこそそもそも遅れさせないための予防的なマネジメント。さきほどのキーマンに風邪も引かせないという考え方が極めて重要になるわけですね。 そういうことです。問題が起きてから人を投入する対処療法ではなくて、問題が起きないように最も重要なラインを人含めていかに守り抜くか、 それこそがクリティカルパスマネジメントの本質なんです。 いやー、スケジュール管理の冷たいテクニックだと思っていたものが、一気に人間臭い生々しいマネジメントの話になりました。ええ。 ちなみにこのアローダイアグラムという図、最初に複雑に絡み合うと言いましたけど、この図を書く上で何か特別なルールはあるんですか？ 資料に「ダミー作業」という不思議な言葉が出てきましたが。ええ、いくつかルールがありますね。 それらはプロジェクトの現実を図の上で矛盾なく再現するための工夫なんです。ダミー作業というのは点線で描かれる矢印で、作業時間はゼロです。 時間ゼロの作業？はい。これはこの作業が終わらないと次の作業には進めませんよという、作業の前後関係、 つまり依存関係だけを示すためのいわばルール上の矢印ですね。 あーなるほど。例えば設計が終わらないと開発は始められない、といった時間の掛からない純粋な前後関係を表現するために使います。なるほど。 そしてもう一つ計算のルールです。複数の作業が合流する地点、資料では結合点と呼んでいますが、ここでの時間の考え方が面白いなと。 最初の料理の例えを思い出してみてください。おかず作り20分とお米炊き40分が、食事というイベントで合流します。 食事はいつから始められますか？遅い方、つまり40分後ですね。まさにそれがルールです。 複数の作業が合流する地点では、最も時間がかかる作業、つまり一番遅く終わる作業に合わせる。これだけです。あーそっか。 資料では少し専門的な言葉で「最早結合点時刻は合流する作業の最大値をとる」なんて書いてありますけど、要は「全員揃うまで待つ」というごく当たり前のことを言っているに過ぎません。 本当ですね。そう考えると一見難しそうな図とか計算式も、分解してみれば私たちの日常的な感覚に基づいているんですね。 その通りです。複雑に見える図も一つ一つのルールは現実の感覚に根ざしているんです。よくわかりました。 では今回の探求をまとめてみましょうか。はい。 まず一つ目は、クリティカルパスとはプロジェクト内で最も時間がかかり、一切の余裕、つまりスラックがない最重要経路であるということ。 そしてプロジェクト全体の納期はこのクリティカルパスの長さによって決まる。 ええ、そこがプロジェクトのアキレス腱になるわけですね。そして二つ目は、この経路の管理とは単なるスケジュール管理ではないということ。 ええ、そこに関わる人的資源、キーパーソンをいかに守り、最高のパフォーマンスを発揮してもらうことかという、より深いレベルでのリスク管理であること。 ブルックスの法則の話からもその重要性が身に染みてわかりました。計画手法という冷たいツールに見えて、その本質は非常に人間的な洞察に基づいている、 そこが面白いところですね。では最後に、いつものようにここまでの話を踏まえて、 さらに思考を深めるための問いをあなたに投げかけて終わりにしたいと思います。はい。 今回の資料では、プロジェクトの計画段階でクリティカルパスを見つけ出す静的なパズルとして描かれていました。 ええ、そうでしたね。しかしご存知の通り、実際のプロジェクトは常に変化する生き物です。 今日まで安全だと思われていたスラックがたっぷりある作業が、たった一つの予期せぬトラブルで大幅に遅延して、 明日にはそれが新たなクリティカルパスに変わってしまう。そんなことは日常茶飯事です。 確かに、一度見つけたら終わりじゃないんですね。クリティカルパス自体が動的に変化していく。 そうです。だとしたらプロジェクトマネジメントにおける本当のスキルとは、一度だけパズルの正解を見つけることではないのかもしれません。 むしろこのプロジェクトというシステム全体を常に監視し、どこかの作業の遅れが他にどう影響するのか、 クリティカルパスが変化する兆候はないか、そのダイナミズムを捉え続けることにあるのではないでしょうか。うん、うん。 そこであなたへの問いです。あなたのプロジェクトやあなたの仕事において、今安全だと思われている余裕のある作業の中に、 明日の火種となるものは眠ってはいないでしょうか。