日程計画の「い・ろ・は」 （2/2）
前回は、日程計画の中でも実行計画の「い・ろ・は」を挙げて終わりました。
実行計画とは文字通り、ゴールを達成するためにいつ、だれが、何をどう実行に移すのかの計画のことで、成功のポイントは計画作成に担当者を巻き込むことでした。
そして、実行計画の「い・ろ・は」として、以下の3つを挙げました。
タスク（詳細化された個々の作業）間の依存関係を明らかにする。
ひとつのタスクに複数の担当者を割り当てない。
「いつまでに完了する」ではなく、「いつ始められる」と「何時間かかる」「どのくらいの期間かかる」で日程を構成する。
今回はこの続きです。ひとつひとつについて、少し詳しく説明していきましょう。
1. タスク（詳細化された個々の作業）間の依存関係を明らかにする。
それぞれのタスクの間には依存関係が存在するものです。こっちのタスクが終わらないとあっちのタスクを始められないといった具合です。プロジェクトマネジメントの世界では4つの依存関係の存在が知られています。
・ 終了・開始（FS） 一方のタスクが終了すれば他方のタスクを開始できる
・ 終了・終了（FF） 一方のタスクが終了すれば他方のタスクも終了できる
・ 開始・開始（SS） 一方のタスクが開始すれば他方のタスクも開始できる
・ 開始・終了（SF） 一方のタスクが開始すれば他方のタスクは終了できる
マイクロソフトが提供するプロジェクトマネジメントツール Microsoft Project でも、この4つの依存関係がサポートされています。
期限に間に合うことばかりを意識して計画すると、本来は終了・開始の依存関係にあるべきタスクが、一方の終了を待たずに始まるようなウソの計画になっていたりします。一見して期限に間に合っているように見えますが、実は矛盾を含んでおり、実現性が担保されていません。
また、計画の詳細度が粗すぎると、タスク間の節目を明らかにすることができません。たとえば、「このタスクが途中まで終わったら次のタスクが始まる」というような格好になってしまいます。“途中まで” というあたりに曖昧さが残ってしまうわけです。
大日程計画や中日程計画ならいざ知らず、実行計画でこのようなことになった場合は、さらなる詳細化が必要だと考えてください。
2. ひとつのタスクに複数の担当者を割り当てない。
計画に慣れていない人は、ひとつのタスクに複数の担当者を割り当ててしまいます。“大は小を兼ねる” 的な発想が見え隠れしますが、これでは計画に曖昧さが残ってしまいます。
野球では複数の人が譲り合ってポテンヒットになってしまうことを“お見合い”と呼びますが、このような計画の立て方をやっていると、仕事上でも、まさにこの“お見合い”が発生してしまいます。
ひとつのタスクに複数の担当者を割り当てているシーンに遭遇すると、私は「どのように役割分担するのですか？」と尋ねることにしています。多くの場合、尋ねられた相手は答えに詰まります。具体的な役割分担のイメージはなく、単に「ふたり割り当てておけばなんとかなるだろう」程度にしか考えていない場合がほとんどです。
このような場合、私はタスクをふたつに分けることをお勧めしています。なぜなら、ふたりが同時にタスクに着手し、同時に終了することなどないからです。タスクを担当者ごとに分けて計画しておけば、それぞれの進捗状況に合わせて計画を更新できます。分けたタスクのうちの一方だけが終了すれば、他方のタスクが終わるのを待たずに、後続のタスクを開始できることだってあります。タスクをふたつに分けておくことで、実態に沿ったリアルな計画を維持することができるわけです。
3. 「いつまでに完了する」ではなく、「いつ始められる」と「何時間かかる」「どのくらいの期間かかる」で日程を構成する。
計画に慣れていない人は、「○月○○日までには終了します」というふうに終了日で計画を立てたがります。私の周りにもよくいます。
私の問い掛けに「このタスクは○月○○日までには終了します」と答えた人の○月○○日は、たいていの場合、与えられた期限です。つまりこの担当者は「期限までにおわればいいでしょ」と言っているようなものです。
これでは、前倒しは期待できません。そればかりか、いつもギリギリの状況なので、ちょっとしたトラブルで納期を踏み越えてしまいます。
私はMicrosoft Projectのプロなので、ちょっとしたこぼれ話を披露しましょう。
Microsoft Project のタスクには、自動的に「できるだけ早く」という属性がついています。これによって、前のタスクが早く終われば後続のタスクは早く始めるというふうにシミュレーションされます。いわゆる、計画の前倒しです。
私がマイクロソフトでMicrosoft Project のエバンジェリスト（伝道師）をやっていたころ、私の同僚が米国人の開発者に「なぜ、できるだけ早くがデフォルトで設定されるのか」と尋ねたそうです。彼は不思議そうな顔をして「だって、プロジェクトは早く終わるに越したことはないでしょ」と即答したといいます。
これは、計画の本質です。
計画で大切なのは見積りです。何時間かかるのか、どのくらいの期間かかるのか、これが見積です。ひとつひとつのタスクの見積値を積み上げていって、結果的に期限を達成できそうなのかを評価します。
もしも期限を踏み越えていたなら、計画者は計画の前倒しを図らなければなりません。このやり方をすれば「あと○○日短縮すれば期限に間に合う」という具体的な目標値が明らかになります。計画者は人を追加するなり、タスクの成果物を見直してボリュームを減らすなり、手分けしてタスクを同時並行でこなすなりして、目標を達成できるまで手を尽くします。
ここで大切なのは、問題発覚の直前になってから手を打つのではなく、そのずっと以前の計画段階に手を打つことができるということです。
これこそが計画する意義です。
よく、期限から逆算して計画を立てたがる人がいますが、私はお勧めしません。この方法では、計画の過程で非現実性や曖昧さが紛れ込みやすいからです。無意識のうちに、期限に間に合うように計画を調整してしまうのです。
まずは積み上げ、期限に間に合わなければ意図して打開策を練る、これが一番のやり方です。
先ほど、見積りの方法には「何時間かかるのか」と「どのくらいの期間かかるのか」の2種類があると書きました。このふたつを比べると、計画精度が高いのは時間で見積もったほうです。期間見積りには見積りする人の思惑が働きがちですが、作業時間見積りにはそれが働きづらいからです。
タスクの成果物ややるべきことを具体的にイメージし、作業時間で見積もる。
これが計画上手への近道です。
説明が長くなりましたが、日程計画の「い・ろ・は」、ぜひ実践してみてください。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
この記事が気に入ったらサポートをしてみませんか？