段階的詳細化とは、プロジェクト、ないしプロジェクトマネジメントの特性です。
「段階的に詳細化される」といった意味を超えてPMBOK®ガイドで再定義される重要用語の一つです。
段階的に詳細化されるものは何かと言うと、それは計画です。
スコープであれば、まず解決したい課題や要求を括りだし、そこから具体的なモノや機能の設計に落とし込んでいく過程。
スケジュールであれば、大日程計画から、月、週の計画へと落とし込んでいく過程です。
これだけだと、どこが再定義?
と言いたくなるかもしれませんね。
PMBOK®ガイドにはこうあります。
「プロジェクトの進捗に従い、入手情報がより詳細で具体化し、得られる見積り精度が向上するに伴って、計画を継続的に改善、および詳細化していくこと」
段階的詳細化を手順的なものと捉えた方、それは違うんです。
プロジェクトが前に進むことによって初めて可能になる計画作業の連続だということです。
メッセージは後半部分にあります。
「見積り精度の向上に伴って計画を継続的に改善していく」
見積もりとは、作業量や、所要期間や、必要コストなどの予測。
精度とは実績との差の小ささ。
プロジェクトの初期には、まとめていくらといった大雑把だったものが、進むに連れて、細分化され、実績から大きくは外れないようになって来るわけです。
それは放っておいて自然とそうなるわけではなく、計画を改善し続けることによって成し遂げられるというわけです。
とは言っても、昨日策定した計画を、何もしないで今日改善できるわけではありません。
改善のトリガはフィードバック。
何かをすることで初めて得られる情報です。
PMBOK®ガイドはこう続けます。
「プロジェクトマネジメントの計画はプロジェクトのライフサイクルを通して段階的に詳細化される 」
プロジェクトのライフサイクルというのは、立ち上げてから終結までの全期間を指します。
つまり、PMBOKは計画を改善する時期を限定していません。
どころか、限定しないことに強いメッセージがあります。
ちなみに、記事タイトルの「死ぬまで」というのはもちろんプロジェクトが。
いつでも改善する。
繰り返し改善する。
プロジェクトが終わるまで。
ここで、素朴な疑問が湧くかもしれません。
計画フェーズというものがあるでしょと。
そこで計画はフィクス(固定)するでしょと。
無制限に計画を変更するなんてあり得ないでしょと。
分かります。
分かります。
言いたいこと分かりますが、もう少し我慢してください。
プロジェクトを以下のように捉えていないでしょうか?
・計画フェーズで計画を策定し、確定する。
・実装フェーズで計画を実現してプロジェクトが終わる。
・プロジェクトが終わったときに残っているのは計画フェーズで策定した計画そのものである。
1番目、2番目はいいとして、問題は3番目。
そうしたいのはやまやまですが、実際はこうではありませんか?
・プロジェクトが終わったときに手元にある計画は、計画フェーズで策定した計画とは別ものである。
なぜこうなるんでしょう?
計画フェーズが終わってから、プロジェクトが終わるまでの間に何が起きたのでしょうか?
訊くまでもありませんね。
計画の変更です。
実装フェーズの最中に計画の変更を余儀なくされたわけです。
と、こういう言い回しは従来型のプロジェクトマネジメント。
PMBOKとは異質です。
何が異質かというと計画の変更がネガティブなこと。
段階的詳細化の意図はそこにあります。
変更はネガティブではありません。
スコープの変更はニーズに近づけるためのものだし、スケジュールやコストの変更は計画に矛盾を生じさせないためのものです。
つまるところ変更はプロジェクトを成功させるためのものなわけです。
将来を正確に予測出来るなんてことはないんですから、プロジェクトに変更が発生するのは当たり前。
記事の冒頭にあるとおり、段階的詳細化はプロジェクトの特性だと言ってるわけです。
日本に四季があるのと同じ。
この特性自体を問題にしている人はいないでしょうか?
「なにも決まっていないじゃないか!」
「また変更か?」
PMBOKの答えはシンプルです。
「だってそれ、プロジェクトでしょ?」
プロジェクト・ライフサイクルのどこかのタイミングで計画が完成するわけではありません。
段階的詳細化はコンセプト
段階的詳細化はコンセプトです。
計画はいつも未完成。
これはあくまで、そういうつもりでいること、考え方を示しているに過ぎません。
コンセプトを理解して受け入れて、どう対処するかがプロジェクトマネジメント。
プロジェクトでは、計画フェーズで計画は一旦フィクスします。
あるいは計画に合意して契約を交わします。
では、この後、プロジェクトは段階的詳細化とどう折り合いをつけていけばいいのでしょうか?
それが変更のマネジメントです。
詳しくは4章以降に譲りますが、変更を無政府状態にせず、計画が矛盾なく常に一貫性を保てるための仕組みを作り、それを確実に実行していく活動の総称です。
現実の話として、プロジェクトが進むにつれて、変更を反映するのにコストが掛かるようになり、計画の改善は難しくなっていきます。
でも、そのことと段階的詳細化は矛盾しません。
フィードバックが得られれば変更が起案される。
繰り返しますがこれは特性です。
単に、進捗に応じて変更のマネジメントがタイトになっていくだけのことなわけです。
現実のプロジェクトにおいて変更がネガティブに捉えられるのは、こうしたセオリーがないがしろにされてしまっている稚拙なマネジメントに慣れてしまっているからです。
例えば、スケジュールやコストを見直さずに、スコープの変更だけを計画に押し込む。
その結果、計画の一貫性が損なわれ、品質が落ちたり、スタッフが疲弊したりするわけですが、これはマネジメントが機能していないことの問題です。
変更をネガティブに捉えている人にとって、段階的詳細化は一種のパラダイム・シフトと言っていいかもしれません。
変更の発生は問題ではなく、計画に矛盾が生じているのに変更されないことこそ問題だということ。
計画フェーズが終わった時点で、計画が完成したと見るか?、はたまた変更の可能性を孕んだ計画と見るか?で、プロジェクトマネジメントは全く違ったものとなります。
日本の四季に文句を言う人はいません。
季節の変わり目に衣替えするのと同様に、段階的詳細化を当たり前のこととして準備する。
私たちにできることはこれだけです。
本気になったら、講座でお会いしましょう!
Fatal error: Uncaught Error: Call to undefined function wp_related_posts() in /home/wp735437/art-of-pm.com/public_html/wp-content/themes/twentyfourteen_child/content.php:81 Stack trace: #0 /home/wp735437/art-of-pm.com/public_html/wp-includes/template.php(812): require() #1 /home/wp735437/art-of-pm.com/public_html/wp-includes/template.php(745): load_template('/home/wp735437/...', false, Array) #2 /home/wp735437/art-of-pm.com/public_html/wp-includes/general-template.php(206): locate_template(Array, true, false, Array) #3 /home/wp735437/art-of-pm.com/public_html/wp-content/themes/twentyfourteen/single.php(24): get_template_part('content', '') #4 /home/wp735437/art-of-pm.com/public_html/wp-includes/template-loader.php(106): include('/home/wp735437/...') #5 /home/wp735437/art-of-pm.com/public_html/wp-blog-header.php(19): require_once('/home/wp735437/...') #6 /home/wp735437/art-of-pm.com/public_html/index.php(17): require('/home/wp735437/...') #7 {main} thrown in /home/wp735437/art-of-pm.com/public_html/wp-content/themes/twentyfourteen_child/content.php on line 81