漏れのないスケジュール作成法

タイムマネジネントは、スケジュールマネジメントと呼ばれるように、スケジュールの作成は前提条件です。

完璧なスケジュールが作成できれば、あとは完成を待つだけなので、プロジェクトマネジメントなんて必要ありません。

逆に言えば、プロジェクトマネジネントが必要ということは、完璧なスケジュールではないことを意味しています。

それでも、段取り八分と言われる通り、計画の完成度がプロジェクトの成否を大きく左右することに間違いありません。

本当のWBSを知ってますか

スケジュールを作成するために必要な要素は次の３つです。

どれも大変で、重要ですが、作業定義をしなければ他２つは出来ません。

作業定義に使うツールがWBS（Work Breakdown Structure）ですが、少し間違って覚えている方も多いようです。

WBSと聞いて、以下の図のようなものをイメージしていませんか？

これも間違いではありませんが、正しくありません。

正しくは、ツリー構造で作成した、以下の図です。

どちらも、書いてある内容は同じですが、視覚的には全然違います。

リスト形式の方では、行が多くなるにつれて、親子関係が見えづらくなります。

その結果、定義した作業ですべてを網羅できてきているのかが確認しにくくなります。つまり、作業定義に漏れが発生する可能性が高いということです。

一方、ツリー構造の方では、親子関係が一目でわかりますので、子の作業をすべて完遂すれば、親の作業が完了できるかを確認することが容易になります。

この例の場合では、以下の手順で作業を定義します。

上位の階層から一通りのツリーができたら、今度は、下位の階層から上位階層に遡って、検証します。

このとき、疑問文にして問いかけるのがポイントです。

例で説明すると

このように、ツリー構造でWBSを検討すると、検討している人の頭の中を整理しやすいですし、レビューアにチェックしてもらうときも、確認しやすくなり、作業定義の漏れを防ぐことができます。

作業定義をする際は、１００点満点を目指さないようにしましょう。

正確には、１００点満点の作業定義が完成したと思わないことです。

満足のいく作業定義ができても、良くて９０点、せいぜい７０点くらいだと思うことが肝心です。

それは、現時点では想定できないことがこの先に発生する可能性が高いからです。

想定外のことが発生したときに、作業定義が完璧であると、完璧を崩してから再構成することになり、心理的な負担が大きく、躊躇することでしょう。

躊躇している間に、事態はますます悪化し、取り返しのつかない結果になるかもしれません。

一方、未完成だと思っていれば、想定外のことが発生した場合でも、「やっぱり、未完成だから、こういうことも起きるよな」と、心理的な負担は軽く、すぐに、計画を修正するアクションを起こすことができます。

もっと言えば、未完成だから、これからどうやって完成させていくかを考え続けることになりますので、想定外のことが起こる予兆に気づきやすくなるというメリットもあります。