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

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

具体的には、
サービス要件→業務要件→システム要件との順で示されるシステム要件と、システム構成（機能とデータの流れ）から見えてくるシステム制約を
擦り合わせることで、実現性のあるスコープを確定させ、
要件定義完了時には、ＱＣＤバランスをいったん確立すべきと述べました。

ところが、実は
システム要件を提示すべき主体（要件オーナー）のうち、
要件定義工程に、参加していない部門やチームがあり、
前述のＱＣＤバランスには、不確実性が潜んでいます。

例えば、
次のような要件とそのオーナーです。

・サービス要件：企画部門、サービス部門、営業部門
　　　　　　　：実際の利用ユーザ
　　　　　　　（利用ユーザ固有の要件が前提となる場合）
・保守要件：保守部門や運用部門、
・セキュリティ要件：情報セキュリティ部門、
・法規制要件：法務部門　など

それぞれについて、少し補足いたします。

サービス要件のオーナー①

サービス要件（ユーザに提供するサービスをどのようにするか）は、
企画部門、サービス部門、営業部門等の分掌（権限と責任の範囲）ですが、

実際のシステム開発プロジェクトで、
それらの部門がプロジェクトに参加することは、あまりありません。

なぜならば、
サービス要件は、企画／サービス／営業部門から業務部門へ提示され、
業務要件とシステム要件は、業務部門からシステム部門へと提示されるものとの立て付けのためです。

いいかえると、
要件は、企画／サービス／営業部門から業務部門にバトンタッチ済みで、
企画／サービス／営業部門の役割は、すでに完了済み。
との立て付けのためです。

ところが、
実際には、第３２回、３５回であつかったように、業務部門は、
システム部門に提示すべき要件の詳細度を、理解できていません。
（これはプロセスと組織の問題で、業務部門が悪いのではありません）

同様に、
企画部門、サービス部門、営業部門は、
業務部門がシステム要件を検討するにあたって、
どの程度の詳細なサービス要件を示すべきかを理解していません。
（これもプロセスと組織の問題で、各部門が悪いのではありません）

そのため、
サービス要件の詳細度が足りておらず、
システム要件に落とし込む前に、サービス要件の見直しが必ず発生します。

いいかえると、
業務部門は、企画／サービス／営業部門から提示される
ざっくりとした、曖昧な粒度のままのサービス要件を受入れるしかなく、

さらに、
業務部門はそれを前提に業務要件を定義することになるため、

結果的に、
システム要件に落とし込む前に、サービス要件の見直しが必ず発生します。

にもかかわらず、
企画／サービス／営業部門がプロジェクトの要件定義に
直接参加することはほとんどありません。なぜでしょうか。

それは、
サービス要件の記載内容や、その詳細度に基準がないため、

ざっくりとしていて、あいまいなものでも、
サービス要件を定義した時点で、上流の部門の役割は終えたことに
なってしまうためです（たいていの場合、完了基準がありません）。

場合によっては、
結構な期間をサービス要件の検討期間にあてたにもかかわらず、

ほとんど具体的な内容は決まらず、
時間切れで、その時点の内容がサービス要件として、
業務部門に引き継がれる事態となってしまうこともあります。

実際には、
システム制約によってサービス要件が実現できなかったり、

そもそも、
非機能要件（利用者に対する性能要件やセキュリティ要件など）は、
業務部門ではなくサービス部門側で定義すべきものであるにも関わらず、
サービス要件では、一切定義されていないこともあります。
（これもプロセスと組織の問題で、各部門が悪いのではありません）

このような問題に対する対策としては、
企画／サービス／販売部門も必ずプロジェクトの枠組に参加者として加え、

定常的なコミュニケーションと意思決定のプロセスを設定しておき、
サービス要件の具体化や見直しが必要な場面で、随時、
要件オーナーとして、機能するようにしておくことが必要です。

ちなみに、
個人的な経験の範囲では、
そこまで環境が整っているプロジェクトを見かけたのは、
いまのところ、一度だけです💦

本稿前半で例示した、
他の要件のオーナーについては、次の回になってしまいます。
申し訳ありません…

次の記事（３９回）