プロジェクトは解決策の追求である

スティーブン・コヴィーはその著書で「結果を想定して始める」と述べています。それでは、最終的な解決策の追求以外に、プロジェクトの結果とは何なのでしょうか？

ソフトウェアプロジェクトの目的を概念化する一番の方法は、WBS（WorkBreakdown Structure）を作ることです。WBS はプロジェクトの全体スコープを成果物†にまで細分化し、階層的に展開したものです。組織図が会社を部門やさらには作業チームへと分割して示しているのとよく似ています。成果物はさらに小さな構成要素、作業パッケージ††レベルにまで分割されます。

WBS を作るときには、チームメンバーやスポンサー、その他ステークホルダーも参加させましょう。そうすることで、プロジェクト作業を明確に定義して、参加者全員のニーズを表現することができます。なぜチームメンバーを参加させると思いますか？

タスクを実際にやるチームメンバー以外に、やるべき作業について詳しい人はいるのでしょうか？

プロジェクト・マネジャーがすべてのプロジェクト作業に関するリストを作れるのは自分だけだと考えているなら、そのプロジェクトは失敗する運命にあります。

WBS を作るときには、チームはそうしたプロジェクトマネジャーの「いつものやり方」に異議を申し立てることができます。それどころか、何がプロジェクトを構成する作業になるのか、チームメンバーが進んで共通の意見をまとめるべきです。こうしたやり方にすると、チームメンバーはもっと積極的にプロジェクトに参加するようになります。結局のところ、自分が設計にかかわったプロジェクトの方が楽しく仕事ができるのです。

WBS のアクティビティはどれくらい小さく分割すべきだと思いますか？

これはいじわるな質問です。WBS にはアクティビティは出てきません。なぜならWBSでは作業パッケージレベルまでしか分割されないためです。作業パッケージは部門やグループ、ベンダー、下請業者にアサインされます。彼らは効率よく品質プロセスにしたがって実行するために、作業パッケージをさらに必要なアクティビティやマイルストーンへと分割します。ここで重要なことは、作業パッケージ（最も低レベルにある作業）にアサインされた人が、さらに小さなプロジェクト計画を作り、それをマスタースケジュールに反映させるということです。

以後、WBS はプロジェクトにおけるあらゆる計画、実行、監視、コントロール機能の中心となります。プロジェクトの内外にいる人たちとの簡単なコミュニケーションツールとしての役割も果たします。WBS をグラフィカルに表現したものがプロジェクトの解決策のイメージになります。イメージが完成すると、ようやく詳細な計画、スケジュール、予算管理が始まります。プロジェクト作業が明確に定義されて初めて、計画、予算、スケジュールが立てられるようになるのです。

WBS はブレインストーミングのツールとしても非常に役立ちます。プロジェクト全体をグラフィカルに表現することによって、仕事で怠慢なところ、冗長なところ、充実しているところが簡単にわかり、プロジェクトの利用価値を高めやすくします。（プロジェクト内外の）潜在的なリスクを特定するために、WBS を活用しましょう。

事前に少し時間をとって、すべてのステークホルダーと協力して明確なWBS を用意し、理解し、合意すること、それがプロジェクトの優劣の決め手となるのです。