PMBOKにおける変更プロセス：どうすれば要求は速やかに達成されるか？

特に日本でプロジェクトマネジメントというと、進行管理とかディレクションと同列に語られることが多い。（実際見積もり項目としても定義が曖昧なことが多い）

それらはプロジェクトマネジメントの中の個々のワークフローであったり、定義された個々のワークフローを進める仕事でしかない。

PMBOKはもう一つ上の概念で、プロジェクトの開始〜終了までの全プロセスが言語で定義されている。分かりやすいのは変更管理の項目。

特にWebの世界はなんか簡単に変えられそうだからしばしばプロジェクト途中での要件変更が発生するんですが、PMBOKでは変更の際のプロセスについても定義されている。

そうなのだ。本来は要求（=依頼）がきたら検討して承認されて、はじめて実施できるものなのだ。それが実際には要求⇨実施へと飛んでしまう（間のプロセスはそもそも計算されていない）ことが多い。

全てに１営業日かかると換算しても、正しくプロセスを遂行すると変更依頼〜完了まで、短くても１週間くらいはどうしたってかかるのだ。

もう一点大事なポイントを付け加えておくと、変更要求の精度が高いほどこの時間は縮められる。検討段階での確認やり取りが減るからだ。

そこから導き出される、依頼する際のポイントは、どのように伝えれば素早く5W1Hを定義できるかということ。

変更ではない初期提案やプランニング業務の場合は違ってくるが、実施確定済みプロジェクトに対して変更を行う場合は、5W1Hに基づいてコストを算出し、追加プロジェクトとして承認され、はじめて動き出す。

そのため、まずはじめの段階で5W1Hの枠組みをどこまで書けるかがそのスピード感を左右する。

これはまず依頼側が理想を伝えたうえで、受託側が現実に落とすもの

Webサイト上なのか外部なのか

Whyから導き出される部分なので、主に受託側がリードして考える領域か

Webでいうと、ドメイン管理者が違う場合商流含め変わってくる。それに応じてワークフローやスケジュールも変わってくる。これも見えているなら明確に伝えておいた方が速い。

これは依頼側が主に考える事項であると思う。

それを基に、受託側でも懐疑的に見たうえでなぜが正しいか、精査する必要がある。

ここが受託側が最も力を発揮できる部分である。逆にいうと、5Wがしっかり定義されてはじめてここが見えてくる。5Wが曖昧な場合ここの手法が無限通りでき、膨大な提案資料が出来上がり迷走することになる。

このように、5W1Hのうちほとんどは依頼主側の意向、特にWhyによって決まることが多い。

そのため、まずなぜそれをしたいのかを正確に伝え、その上で方法論を議論していく必要があるのだ。

ちなみに5W1Hは使い古された手法だが、未だにあらゆるものの整理に役立てることができる。この辺りの整理法はまたそのうち。

鼻