梅雨入りしてからあまり雨が降らない日が続きましたが、今朝の南関東地方は曇り空であけましたが予報は晴れです。あまり暑くならないようですが、体調管理に気を付けたいものです。
さて前回は通常のテーマをお休みして「メッセージ」という映画について、観た感想をお送りしましたが、今回は再びいつものテーマに戻って議論を薄めていきます。
まず一回お休みしたので、前回のおさらいを簡単にやっておきます。前回の本文は こちら です。
WBSの構造化について、例によってチャーハンをモデルに詳しくご説明しました。その中でレベル１からレベル３までの各構成要素と、具体的な行動に結び付けるためのアクティビティについて考えました。
この中で重要なのは、WBSを作り始める前にプロジェクト全体の方針や前提条件を明確にしておくことでした。
チャーハンの例では、具材冷蔵庫の残り物を使うという方針を挙げました。この方針によって、どんなチャーハンを作るかは残り物次第で決定されることになります。つまり方針によって、目標と行動がある程度規定されてしまうわけです。
もし、エビチャーハンを作るという方針立てれば、冷蔵庫にエビがなければエビを買いに行くというアクティビティがWBSには必要になります。
このようにWBSを作成する場合必要になるいくつかの情報があります。その最たるものが「プロジェクトの目的」であり「目標（成果物）」であるわけです。
それに加えて、「目標」を達成するための方針（前提条件）と制約条件があります。
前提条件と制約条件の違いは、プロジェクトマネジメントにおいてはよく議論のテーマとなるものですが簡単に言うと、前提条件はプロジェクト自らが設定する規定で、制約条件はプロジェクトの外から要求されプロジェクトの行動に影響を及ぼすものです。ときどきこの２つがごちゃごちゃになってしまうことがあるので、ちゃんと区別するように気をつけることが必用です。
チャーハンの例はちょっとややこしいのですが、前提条件は「基本的に冷蔵庫にある残りもので作る」であり、制約条件は「冷蔵庫の中身」ということになります。この場合、前提条件と制約条件が密接に関係しています。
もし冷蔵庫の中に玉子が入っていなかったら、制約条件の例外として買いにいくことになるのはお分かりですね。
ITアプリケーション開発プロジェクトで言うと、「パッケージを導入」するか「自社で開発するか」や「ウォーターフォール型開発」か「アジャイル型開発」でいくかなどが方針となります。他にもセキュリティレベルや、インフラ方針、メンテナンス方針など多くの前提条件が必用となります。
これに対して制約条件として、現行ハードウェアの保守契約期限やセキュリティ要件、承認決済における組織のルール、法的な基準などとなります。
このようにWBSを考える場合、一般的にそのタスクに対して影響を与える事象が沢山存在します。これを計画プロセスの前にしっかりとまとめておくことが必要です。
通常はこのような重要事項は「プロジェクト憲章」に明記し、プロジェクトのキックオフ時点でプロジェクトの内外（ステークホルダー）に宣言することになります。前提事項、制約事項はプロジェクト実施中に変更を余儀なくされる場合があるので、しっかり変更管理を行います。変更の過程はステークホルダーに丁寧に説明し、理解を得る必要があるのは言うまでもありません。
また特に前提条件と制約条件には、プロジェクトが作り出すアウトプットに影響するものがあります。特に官庁の公的な決まり事、法律による規定などはクリティカルな影響を及ぼすので事前の確認はしっかり行うことが必要で、時には専門家の助言が必用となる場合もあります。
次回はWBSのタスク間（成果物同士の関係性）について考えたいと思います。