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

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

では、どうすれば、
機能間のデータの流れにおける無理がわかるのでしょうか。

実は、機能間のデータの流れは
機能をどう配置して、データをどのように流すかを示す、
システム要件の実現方式（アーキテクチャー）そのものです。

そのため、
機能間のデータの流れにおける無理は、
システム要件の実現方式を示す資料を作成するとわかります。

いざ、作成してみると
・データストアにあてにする項目がなかったり、
・項目はあっても、データの更新タイミングがあわなかったり、
・項目はあっても、データの精度が求めるレベルではなかったり、
・項目はあっても、管理部門の承認を得る必要があったり、
・更新タイミングや精度もOKでも、変換しないと使えなかったり、
・望みのデータを得るには、複数のデータストアの項目が必要だったり、
・そもそも業務フローがざっくりすぎて、実現方式に落とし込めないとか、
と、、、さまざまなことが起こります。

システム要件の実現方式について、
機能とデータの粒度で、機能間のデータの流れを検討するだけで、
様々なシステム制約（システムで簡単にできないこと）が見えてきます。

機能とデータの粒度でのシステム構成の検討はシステム側の役割ですが、
実は、ユーザ側にも担っていただくべき役割（責任）があります。

それは、分岐条件の提示（可視化）です。

具体的には、
サービスメニューやオペレーション（業務）の要件の中にある
○○の場合はこうだけど、□□の場合はこう、といった分岐です。
（これらの要件は、システム側で事前に把握できません）

分岐をシステムで実現するためには、
分岐を識別するための項目（データ）が必要になります。

たった一つの項目でも、
システム構造（機能とデータの流れ）を大きく左右することがあります。

分岐の識別を
システム要件にせずに、手作業とする選択肢もありますが、

手作業とするのであれば、要件定義の期間中に分岐時を可視化し、
その分岐対応は手作業の役割と明確にすることが必要です。

短期要件と長期要件のトレードオフ

実は、上述の
システムの実現方式の検討にあたり、留意すべき点が一つあります。

それは、
実現方式（アーキテクチャー）をできるだけシンプルに保ち、
むやみに複雑にしないことです。

ビジネス効果の小さい業務要件によるシステム要件を受けて、
むやみにアーキテクチャーを複雑にしてしまうと、

システムは柔軟性を失い、
結果的に、業務の柔軟性をも損なうことになってしまいます。

短期的な要件と長期的な要件のトレードオフです。

短期的な要件を代表するステークホルダーは目の前にいますが、
長期的な要件を代表するステークホルダーは不在のため、

所以、
知らず知らずのうちに、アーキテクチャーは複雑化し、
知らず知らずのうちに、業務の柔軟性が損なわれていきます。

こうした流れで、
システムは硬直化し、業務も硬直化していきます。

それでも、
プロジェクトメンバーのシンプルなアーキテクチャーに対する
こだわりは優先順位が下がってしまいます。

なぜならば、
アーキテクチャーが複雑になってしまうことが原因で
何かが問題になる頃は、プロジェクトは完了しているからです。

プロジェクト完了後に、
継続的にアーキテクチャーを見直していくプロセスは、
リファクタリングと呼ばれますが、機能している組織を
いまのところ、見たことがありません…

余談ですが、リファクタリングが機能しない理由は、
短期的なビジネス効果に結びつきにくいリファクタリングには
予算がつきにくい。ということと。

リファクタリングは、
デグレードを防ぐためのテストの自動化が前提ですが、

プロジェクト中は、
長期的な要件より、短期的な要件が優先されるため、
プロジェクト期間中に、テスト自動化のしくみを構築できないためです。

お話を戻しますが、
短期的な要件と長期的な要件のトレードオフは、
本記事でも繰り返し述べていますが、
これらは組織の設計上の問題（いわゆる縦割組織の問題）のため、
関係するメンバーの能力や問題意識の問題ではありません。

次の記事（３６回）