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

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

スコープの不確実性に対する考え方

スコープの不確実性①〜⑤（第３２〜３５回 ）では、
第３１回 ３大不確実性でのべた以下の スコープの不確実性 を受けて、
スコープを定義する要件定義の問題について扱ってきました。

スコープの不確実性
・曖昧な基準：要件をどこまで定義すれば、定義が十分かの基準が曖昧。
・曖昧な責任：その基準の明確化責任が、ユーザ側なのか開発側か曖昧。
・異なる言葉：文化や言葉の違いでユーザ側と開発側の会話が合わない。

前述のスコープの不確実性に対して
各回では要件定義における次のような考え方を述べてきました。

第３２回：定義の十分性は次工程の主体であるシステム側が責任をもつこと
第３３回：業務からシステムに対するシステム要件は業務フローで示すこと
第３４回：システムから業務に対するシステム制約は業務フローで示すこと
第３５回：システム制約は実現方式（機能間のデータの流れ）検討でわかる

第３２回：https://note.com/think_think_ab/n/n8957f15a84f1
第３３回：https://note.com/think_think_ab/n/nf06d472ea82f
第３４回：https://note.com/think_think_ab/n/ne320f8c90e6b
第３５回：https://note.com/think_think_ab/n/nc29d8c515950

要件定義の成果物の十分性①

さて、これまでの回では、
要件定義における主な成果物を業務フローとしましたが、

ではなぜ、業務フローで十分なのでしょうか。
画面仕様も、処理仕様もユーザ側の要件といえば、要件です。
要件定義の工程でできるだけ詳細化したほうが良いのではないでしょうか。

実は、
要件定義工程と設計工程では、検討に必要な組織的な軸が異なります。

要件定義工程では、横ぐし的な検討ですが、
設計工程に入ると、縦わり的な検討に変わります。

具体的には、設計工程に入ると、
業務フローで定めた各画面や機能毎のユーザ部門との検討に変わりますし、
システム部門側もそれぞれの画面や機能毎の担当者が立つことになります。

したがって、
要件定義のアウトプット、すなわち設計工程のインプットとしては、
システム要件をどのような画面や処理理に分ければよいかが決定できれば、
アウトプットとしては十分ということになります。

逆にいうと、
そこから先の要件の詳細化は設計工程のなかで定義されることになります。

そのため、繰り返しになりますが、
要件定義終了時に、以下の資料が必要となります。
・システムの要件がわかるもの：業務フロー
・要件の実現方式がわかるもの：実現方式（アーキテクチャー）の資料

前述で、要件定義の成果物に
業務フローに加えて、実現方式の資料を追加しています。
なぜでしょうか。

実は、
システム要件をどのような画面や処理理に分ければよいかは、
業務フローからだけではわからないからです。

業務フローで示されたシステム要件の実現方式（機能とデータの流れ）を
示す資料があって、はじめてわかることなのです。

要件定義の成果物の十分性②

もうひとつ、
要件定義の成果物に対しては、
プロジェクトにとってとても重要な要件（意味）があります。

それは、
要件定義でスコープが決まったということは、

プロジェクトにとって、
ＱＣＤバランスを確認できる、
ほぼ正確なＱがようやく決定したということです。

このタイミングを逃さずに、あらためて、
そのスコープの全量をＷＢＳに落とし込む必要があり、

その際に、
対象となるスコープが機能とデータの流れの粒度で可視化されている
必要があります。

参考：
第８回 ＷＢＳ：https://note.com/think_think_ab/n/n7273ad5d465d
第１９～２２回（タスクの全量性①～④）　
第１９回 ：https://note.com/think_think_ab/n/n54caeae17ac9
第２０回 ：https://note.com/think_think_ab/n/ncaa8f782c5a5
第２１回 ：https://note.com/think_think_ab/n/n3ce2219683c2
第２２回 ：https://note.com/think_think_ab/n/n37d13b88a9fb

すなわち、
要件定義のアウトプットに求められる要件は、以下の条件となります。
・システム要件の実現に必要な機能とデータの流れが可視化されていること
・機能とデータの流れから、タスクの全量がＷＢＳに落とし込められること

実は、
このことは第３回 不確実性の早期排除（https://note.com/think_think_ab/n/n99a4697ec282）で述べた実現性確認
　の前倒しと同義です。

しかしながら、
実際のプロジェクトでは、次のようなことが起こりがちです。
・実現方式の検討を、完全に要件定義の後にしてしまっている。
・そのため、システム制約が見えてくるのが要件定義の後になってしまう。
・結果、設計工程でも横ぐし調整が発生し、推進スピードが上がらない。

これらの原因は、いずれも組織的な問題によるものです。

組織的な問題については、以下の回をご参照ください。

第４回 組織の脆弱性：
https://note.com/think_think_ab/n/ne54aee1bde0a
第５回 各部門の効率が優先：
https://note.com/think_think_ab/n/na7e9722a50cc
第２９回 マトリクス組織：
https://note.com/think_think_ab/n/n2d035be0e0f7

次の記事（３７回）