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

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

実現方式をデザインする役割

第３６回 スコープの不確実性⑤（https://note.com/think_think_ab/n/n6e8e1909d515）では、

要件定義が終了する際には、業務フローとあわせて、
システム要件の実現方式を示す資料が必要と述べました。

いいかえると
機能とデータの流れを示した資料（以降、「システム構成図」）を
作成する（デザインする）必要があると説明しました。

ちなみに、
プロジェクト範囲全体を対象に
機能間のデータの流れに無理がないことを見通すには
システム構成図は、できるだけ一枚に収めることが望ましいです。

では、
システム構成図は誰が作成する（デザインする）のでしょうか。

・アーキテクトでしょうか。
・システム部門でしょうか。
・ＰＭ、ＰＭＯでしょうか。
・ユーザ部門でしょうか。

本来であればアーキテクトですが。残念なことに、
たいていのプロジェクトでは、アーキテクトは配置されていません。

さらに残念なことに
多くのプロジェクトでは、
機能とデータの流れを示したシステム構成図は
後述する難しさのためか、作成されていないことが多く、

そのため、
システム構成図（システムの実現方式を示す資料）といっても、

それがどのようなものか、
システム側のメンバーでもイメージできない場合があります。

こうした理由から、
繰り返しになりますが、多くのプロジェクトには
機能とデータの流れを示すシステム構成図がありません。
（サーバ構成などのシステム構成図と呼ばれる資料はありますが、
　機能とデータの流れを示すシステム構成図はない、という意味です）

また、システム構成図とは、
最も大きなシステムの構成要素である機能とデータの粒度で、
システム要件の実現方法を示すもので、特定のフォーマットはありません。

資料の目的は、
必要な機能とデータは何か、
機能間のデータの流れに無理がないか、を確認することなので、
それができる資料であれば、様式は問われません。

難しいのは、様式がないということです。
データフローやＵＭＬが比較的近い表現ですが、
１枚ものにするには、さらに工夫が必要になってきます。

よりデザインの力が求められます。

実現方式を可視化するために必要な能力

余談ですが、実は、
上述のシステム構成図を作成する（デザインする）ためには、
以下の３つの能力が必要です。

・理解力：業務とシステムの両方の言葉が理解できて使えること
・設計力：抽象と具体の両方の概念を理解し、自在に使えること
・表現力：機能とデータという抽象的なものを可視化できること

いいかえると、
「業務 vs システム」、「抽象 vs 具体」という、
　それぞれ対極の関係にある領域のため、一般的には、
　トレードオフとなる能力の両方の能力を持つことが必要なため、

該当の条件を満たすリソース調達そのものが
問題となることがあります。

よくあるパターンとしては、
・理解力はあるが、設計力や表現力がない
・設計力はあるが、理解力や表現力がない
・表現力はあるが、理解力や設計力がない
などのパターンです。

できるだけ、
これらの能力を兼ね備えたリソースの調達・配置が望ましいですが、

それができない場合、
少なくとも、そこにリスクがあるということを理解して、
運営するだけでも、その後に発生する問題に対する対処が
変わってくると思います。

リソースの調達は、
内部重用でも、コンサルなどの外部調達でもよいですが、

リソースの配置は、
横ぐし調整の立場が求められるため、
　アーキテクト、
（アーキテクトが不在の場合は）ＰＭ、
（ＰМにはスキルがない場合は）ＰＭＯ、
（ＰМＯにスキルがない場合は）システム部門
　との順での検討が望ましいです。

個人的には、
アーキテクト不在、ＰМにスキルがないプロジェクトで、
ＰМＯとして、システムの実現方式（システム構成図）を
担当した（デザインした）ケースがありました。

このパターンは、お客様の意向で、
システム部門の予算で、ユーザ部門側に立つという特殊な条件でしたが、
システム部門側ではなく、ユーザ部門側に立つことは、
ユーザ部門側とVSの関係にならず済む、という意味でとても有効でした。

繰り返しになりますが、
システムの実現方式を機能とデータの流れの粒度で示す
システム構成図は以下の観点で必ず必要です。

・設計工程以降の前提となる、スコープ（量）の決定
・設計工程以降の前提となる、全量ＷＢＳ（日程）の決定
・設計工程以降の前提となる、ＱＣＤバランスの確認

スコープに潜む
これらの不確実性が残されたまま設計工程に進んでしまうと、
プロジェクト期間中、ずっとＱＣＤバランスが脅かされることになります。

要件定義完了の瞬間は、
スコープが確定し、ＱＣＤバランスが確認できる最初の瞬間です。

そして、
ＱＣＤがバランスしていない場合、
スポンサーを含むステークホルダーに対して、
大きな交渉（予算増やスコープの縮小、リリース延期など）のできる
最後のタイミングです。

このタイミングで、
ＱＣＤバランスが確認できないと、
大きな交渉のできる正式なタイミングを逸してしまいます。

特に、
このタイミングであれば、
ＱＣＤがバランスしない理由を開発以外に求められますが、

このタイミングを逃してしまうと、
ＱＣＤがバランスしない場合の交渉は絶望的に難しくなります。

なぜならば、
ＱＣＤがバランスしない理由の多くは、
実現性リスクが顕在化した場合で、大抵の場合、開発側に責任があります。

ユーザ部門からすると、
「できないことがあるのであれば、要件定義の段階でキチンと言ってよ」
　との立場です。

そういう意味で、大きな交渉ができなくなります。

残念ながら、大抵の場合、
他部門と交渉することなく、開発部門が自部門で飲み込もうとするか、
理由を他部門の責任にするためのシナリオ検討・調整で問題領域の
推進が留まります💦

（これらの行動は組織人としては、至って普通の振る舞い方です。
　問題の原因はプロセスの組み立て方にあるので、
　個人の能力や問題意識を責めることはできません。）

繰り返しになりますが、
要件定義の工程中に、システム要件の実現方式の検討を並行して裏で進め、
システム制約があれば、要件定義の期間中に、ユーザ側（企画部門、サービス部門、業務部門）にタイミングを逃さずに伝えることです。

そのためには、
・システム要件の実現方式を示す資料（システム構成図）と
・それをデザインして、
　可視化（資料化）できる能力を兼ね備えたリソースが必要になります。

次の記事（３８回）