「みはじの法則」で考える、炎上しないプロジェクトの進め方

「みはじの法則」は、「み:みちのり(=距離) 」、「は:速さ」、「じ:時間」 の関係を表す、算数の公式です。

小学校の課程で教わり、多くの人が日常的に実用しているであろうお馴染みの「みはじの法則」ですが、そこにプロジェクトマネジメントの概念を当てはめてみると、プロジェクトが炎上するメカニズムをシンプルに理解することができます。

この記事では、プロジェクトはどのようにして炎上状態に陥るのか、プロジェクトを炎上させないために何を守ればよいのかについて、「みはじの法則」を使って考えてみたいと思います。

はじめに、「みはじの法則」について簡単におさらいしておきましょう。

「みはじの法則」は、みちのり(=距離)、速さ、時間 の関係を表した公式です。

それぞれ、

• 速さ × 時間 = みちのり(距離)
• みちのり(距離) ÷ 時間 = 速さ
• みちのり(距離) ÷ 速さ = 時間

という関係が成り立つことを示しています。

これを使って、「徒歩のたかしくんが目的地に着くのは何時頃か？」とか「先に出た徒歩のたかしくんを、ひろしくんが自転車で追いかけたら、追いつくのは何分後か？」みたいな練習問題をたくさん解かされたような気がするのは古き良き思い出です。大人になって思い返してみれば、たかしくんやひろしくんが目的地へ向かって走る様と、あるプロジェクトがゴールへ向かって進捗する様とは、まるでそっくり。きっと同じ公式で考えることができるはず。

ということで、「みはじの法則」に、プロジェクトマネジメントの概念を当てはめて、図にしてみました。

プロジェクトは、何かしらの成果物を完成することをゴールとして進捗します。例えば、何らかのプロダクトを開発するプロジェクトなら、そのプロダクトが成果物です。調査が目的のプロジェクトなら、調査レポートが成果物となるかもしれません。

プロジェクトがスタートしてから、これらの最終成果物ができるまでを「みちのり(=距離)」と捉えることができます。

成果物は、最終成果物だけではない場合もあります。プロダクトを開発する前段階として必要になる設計書などの中間成果物も、成果物に含まれます。形には残らなくても、メンバー同士でミーティングが必要なら、それも含んで考えられるかも知れません。

成果物は、プロジェクトが進行する間に発生するすべてのタスクを足し上げた全体のこと だと言い換えても良さそうです。

プロジェクトが進捗する「速さ」には、道具や機械の性能だったり、技術の進歩などが関わることがありますが、ほとんどの場合に最も重要な要素は "人員の時間" であると考えて良いでしょう。つまり、人/月 のことです。

プロジェクトが開始した時点から、プロジェクトが完了する時点までの期間を「時間」と考えることができます。

プロジェクトには、完了するべき期限が設定されることが多いと思います。企業では、決算期に合わせて設定されることがあります。GW商戦、夏休み商戦、クリスマス商戦・・・などに向けたプロジェクトでは、それが期限となり、逆算してスケジュールが組まれます。

図の真ん中には、「未知の不確定要素」を置きました。本家の「みはじの法則」にはこんなものは登場しませんが、現実のプロジェクトではよく発生します。

プロジェクトの当初の計画では想定されていなかったが、実際に進めてみるとわかってくる予定外の出来事や障壁、想定から漏れていた大きなタスクなどです。これが明らかになると、当初の計画時点では成立していたはずの「みはじの法則」が成立しなくなり、調整する必要がでてきます。プロジェクトマネジメントは、この「未知の不確定要素」との戦いであると言っても過言ではないでしょう。

よくある炎上プロジェクトがどのようにして炎上に至るかを、「みはじの法則」で説明してみたいと思います。

古典的なウォーターフォールモデルのプロジェクトでは、プロジェクトの前半を 要件定義 や 設計 といった計画の工程に当てます。この工程の中で、多くの場合はまず 何を作るのか？ と いつまでに作るのか？(期限) が決められます。これで「み:成果物」と「じ:期間」がわかるので、そこから どんな人員が何人必要か？ という「は:資源」を求めて、公式が成立するように計画を整合させていきます。

「未知の不確定要素」については、計画フェイズのうちに徹底的な調査をして、可能な限り把握するように努めます。もしも本当に、これであらゆる未知の要素を把握しきれるなら、おそらくプロジェクトは計画どおりに安全に完了できることでしょう。しかし実際には、計画のフェイズを終えて、実際にプロジェクトが進行しだすと、把握しきれていなかった問題がぽろぽろと見えてくるものです。

「未知の不確定要素」が顕在化すると、それまで成立していた「みはじの法則」が崩れます。崩れたままでは進めないので、「み」「は」「じ」のいずれかの値を変更して、再び成立するように調整し直す必要が生じます。

ではまず、「じ:期間」の調整を試みましょう。期間の調整は、すなわち期限の延長です。期限を延長できる場合は、すべてのスケジュールを少し後ろにずらすだけでほぼ整合するので、簡単です。

しかし、期限を遅らせるべき理由に下手な説明をつければ担当者は人事的な評価を損なうかもしれず、できれば避けたいと思うでしょう。クリスマス商戦に向けたプロジェクトなら、納期を1ヶ月遅らせることは、プロジェクトの存在意義そのものの否定となる可能性が高いです。

期限の後ろ倒しを阻む大人の事情はたくさんあり、なかなか一筋縄では通りません。

「じ:期間」の調整に失敗したので、次は「み:成果物」の調整を試みましょう。成果物は、工程を減らせば小さくできます。つまり、機能を削るなどです。工数に大きなインパクトのある機能をごっそり削るような意思決定ができれば、再び「みはじの法則」を成立させることができそうです。

しかし、要件定義のフェイズでよくよく検討して計画を立てているので、削れるような機能は概ね既に削られています。

残った重要機能のなかから苦し紛れにいくつかの小さな機能を削っても、全体の整合性に影響するほどのインパクトは出せず、十分な調整はできません。

最後に残ったのは「は:資源」すなわち "人員" です。

追加で参加してくれるヘルプ人員を連れてきて、作業スピードを加速させます。仕事の内容によっては、これで解決する場合も、まぁ、なくはないでしょう。

しかし、後から新しいメンバーが参加するとき、チームの状況やそれまでの仕事の流れを伝えたり、チームの仕事のスタイルに慣れたりすることに時間を割く必要があり、いきなりトップスピードで参加することはできません。これには、新しいメンバーだけではなく、既存のメンバーの時間も使うことになり、その間は予定していたタスクが停滞することになります。その後のコミュニケーションコストや管理コストも増加します。このため、例えばシステム開発などのクリエイティブな仕事の場合には、かえってスピードが落ちることに繋がる場合が多いです。

「み:成果物」も「じ:期間」も調整できない。よって、「は:資源」すなわち "人員" で調整しなければならない。しかし、新しい人員を追加することはできない。

となると、できることは限られています。

既存のプロジェクトメンバーで、残業して作業時間を増やします。または、休日稼働で作業時間を増やします。それでも足りなければ、深夜に徹夜で...。

これで、みんながイメージするいわゆる 炎上プロジェクト のできあがりです。

プロジェクトの炎上状態をどう定義するかは様々あるかもしれませんが、メンバーが徹夜で働いていたら、誰の目にも明らかに炎上していると映るでしょう。

このような炎上のプロセスを考えると、「未知の不確定要素」によって崩された「みはじの法則」を、人員の調整で整合させなければならない状況に陥った時に、プロジェクトは炎上する と考えることができます。

一方、「未知の不確定要素」をゼロにすることは不可能です。ということは、その皺寄せを人員以外の方法で吸収できれば、炎上は避けることができる とも言えるでしょう。

伝統的なウォーターフォールモデルが疑問視されて以降、アジャイルやスクラムや様々な新しい手法が考えられてきました。私はそれらを解説できるほど詳しくないので、あまりいい加減なことを書くと専門の方に怒られそうですが...、要するに、人員資源「は:資源」を固定して、「未知の不確定要素」の調整には「じ:期間」または「み:成果物」で対応する という点が本質であるように思います。

スクラム の体制を組んだプロジェクトでは、短い間隔で頻繁にプロダクトをリリースします。週に1回水曜日に、あるいは毎日17:00にと、定期的な周期でリリース予定があらかじめ組まれています。

もし、プロジェクトに予定外のトラブルがあって、予定した日のリリースに間に合わない場合、「来週に延ばそうか」と気軽に言いやすい環境が作られています。これによって、「じ:期間」による調整が可能になりました。

しかし、それでも、前述のクリスマス商戦のような問題がある場合は解決できません。その場合は、残る「み:成果物」で調整することになります。

「み:成果物」を調整に使うということは、機能や制作物の一部をあきらめるということです。ということは、残タスクのうちの全てが、絶対に必要な必須要件しかない状況では、調整ができないことになります。

つまり、「あったら嬉しいけど、なくても成立する要求」を、あらかじめプロジェクトに折り込んでおく必要があります。

そしてもう1つ重要なことは、必ず重要度の高い必須要件から着手し、完了していくことです。

ここで優先順位を間違えると、プロジェクトの中盤で落とせない必須要件しか残っていなくて、調整の余地がない という事態に繋がります。

いまいちど思い出しましょう。「み:成果物」も「じ:期間」も調整できない状況に陥ったら、残業、休日稼働、徹夜しか打ち手がなくなる ということを。

この記事では、「みはじの法則」を使って、プロジェクト炎上のメカニズムと、炎上を回避するために守るべきことについて考えてきました。

主な要点をまとめてみます。

• 「み:みちのり(距離)」を「成果物」、「は:速さ」を「資源(リソース)」、「じ:時間」を「期間」 に見立てて、プロジェクトマネジメントを「みはじの法則」に当てはめて考えることができる。
• プロジェクトには「未知の不確定要素」が埋まっており、これによって計画時には成立していた「みはじの法則」が崩されることがある。
• 「みはじの法則」が崩れたときは、「み:成果物」「は:資源」「じ:期間」のいずれかを調整して、再び成立するようにしなくてはならない。
• 「じ:期間」または「み:成果物」のいずれかに、調整の余地を残しておけば、炎上は避けられる。「は:資源」で調整せざるを得ない状況に陥ったとき、プロジェクトは炎上する。
  

様々な要素が作用し合って、プロジェクトマネジメントは複雑で難しいものに見えますが、「み」「は」「じ」の3つの要素で捉えることができれば、かなりシンプルに考えられるのではないかと思い、書いてみました。いかがでしたでしょうか？

この記事が、みなさんのプロジェクトのお役に立てたなら幸いです。