なぜプロジェクトマネジメントが機能しないのか 32 スコープの不確実性①

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。本記事では、まだＰМＢОＫには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン：https://note.com/think_think_ab/m/m0e070db46016

不確実性の早期排除の流れ

第３１回（https://note.com/think_think_ab/n/n42f052372164）では、
プロジェクトにとっての３大不確実性として、

１．スコープの不確実性
２．実現性の不確実性
３．チーム間の整合性の不確実性　をあげました。

これらの不確実性を早期に排除するだけで（簡単ではありませんが💦）、
プロジェクトのＱＣＤがバランスする可能性は格段に高まります。

例えば、
プロジェクトの前半（例：要件定義完了まで）のうちに
スコープの不確実性（前述１）と実現性の不確実性（前述２）を排除し、

あとは、
継続的に発生するチーム間の不確実性（前述３）、
いわゆる課題を、ＡＳＡＰで解決していく流れのイメージです。

これらは、当初より、← 地味ですがココ重要です。
不確実性の早期排除との観点で、
プロジェクトマネジメントを正しく機能させることで可能になります。

逆に、
前述のような流れで不確実性を早期に排除できない場合、

プロジェクト後半の設計・開発・テスト工程で、
断続的にリスクが顕在化し、プロジェクトが不安定になります。

プロジェクト後半は、
ただでさえ、もともとさまざまな課題が発生する工程のため、

プロジェクト前半で排除できる不確実性が放置されてしまい、
プロジェクト後半に断続的に比較的粒の大きな課題が発生すると、

管理と調整が複雑になり（※エントロピーの法則）、
管理面でプロジェクトが破綻しかかる可能性があります。涙

※参考：エントロピーの法則
　２７回（https://note.com/think_think_ab/n/n7db9269ae413）参照

スコープの不確実性

スコープは、
プロジェクト前半の要件定義工程で、定義されますが、

実は、
要件定義工程は、プロジェクト全体の工程の中でも、
唯一、生産性で測れない工程で、その扱いは意外に難しいです。

具体的には、
設計や開発、テストなどの工程は、
対象となる成果物（機能数や試験項目数等）の量が決まれば、

成果物１つあたりの生産性を目安にして、
必要なリソースや期間を、おおむね計算することが可能です。

一方、
要件定義工程は、成果物そのものを定める工程のため、
目安となるものがなく、どの程度のリソース、どの程度の期間を
かければよいのかがよくわかりません。

やっかいなのは、
ある一定以上の期間を過ぎると効用がでにくくなるため、
ただ期間をかければ、かけるほどよいわけではないことです。

要件定義の期間は、諸説ありますが、
一般的には、プロジェクト全体期間の10～30%と言われています。

プロジェクト期間が１年間とすると、
おおむね１か月強～４か月の間です。他の工程もありますので、

例えば、３か月とすると、
要件定義（３か月）→設計（３か月）→開発（３か月）→テスト（３か月）
といったイメージでしょうか。

では、
要件定義の主体は誰でしょうか。

一般的にはサービス部門、あるいはユーザ部門とされますが、
実は「要件定義」に対する「要件」を持っているのは開発部門になります。
（少しメタ的な表現で気が引けますが💦）

具体的には、
要件定義工程のアウトプットを受けとって、
次の設計工程を担うのは開発部門のため、

要件定義のアウトプットに対する要件、
すなわち「何をどこまで定義すべきか」、との「要件」は、
サービスやユーザ部門ではなく、開発部門が持っていることとなります。

一方、
実際のプロジェクトでは、
要件定義後半あたりから、次のような会話が出始めます。

開発部門から
「サービス部門（あるいはユーザ部門）が要件をなかなか出してくれない」

サービスやユーザ部門から
「開発部門が、何をどこまで定義すればよいか、なかなか示してくれない」

いいかえると、

ユーザ部門は、システム部門側の
（要件定義のアウトプットに対する）要件を理解できず、

システム部門は、ユーザ部門側の
（プロジェクトのアウトプットに対する）要件を理解できてない。

という状態です。

では、どうすればよいのでしょうか。
（すみません。次回に続きます💦…）

次の記事（３３回）