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

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

機能間のデータの流れ

前回 ３３回 スコープの不確実性②（https://note.com/think_think_ab/n/nf06d472ea82f）では、

業務フローをユーザ部門だけで作成すると、
システムでは実現性のない業務フローになる可能性があるため、
システム部門が深く関わりましょう。

でも、その際、
業務フローを漫然とみていても、
業務フローへの適切な指摘はできない。と述べました。

では、
どのような視点で業務フローを見ればよいのでしょうか。

そもそも、
業務フローに対して何を指摘すべきなのでしょうか。

実は、
前回でも述べたように、
業務フローは人手とシステムの役割分担です。

もう少し補足すると、業務フローにおいて、
システムの役割（システムにやらせたいこと）は、
システムに対する要件（システム要件）として定義されていますが、

システム部門が指摘すべきは、
システムにやらせたいこと（システム要件）に対する
システムではできないこと（システム制約）です。

ここでのシステム制約には、
システムではできないこと以外に、
システムでやるには大変なことも含みます。

余談：
要件と制約は、問題解決の検討にあたって必ず必要な要素で、
要件と制約の間に現実解が存在します。これはまた別な機会に説明します。

では、
システムではできないこと、あるいは、
システムでやるには大変なこと、
とは、いったいどのようなことでしょうか。

そもそも、
システムはどのような要素から成り立っていて、
システム実現の難しさはどこにあるのでしょうか。

ちなみに、
あたりまえのことで気が引けますが、
システムは、機能とデータからなりなっています。

さらに補足すると、
機　能は、組織でいうところの縦割り的なものであり、
データは、それら組織をつなぐ、横ぐし的なものです。

そして、実は、システム実現の難しさは、
その縦割り組織をつなぐ横ぐし的なもの、

いいかえると
「機能間のデータの流れ」に存在します。

「機能間のデータの流れ」に無理があると、
　システムの実現性は格段に難しくなります。

それは、なぜでしょうか。

それは、
機　能が、一つの組織の中に閉じるものであるのに対し、
データは、複数の組織にまたがるものだからです。

言いかえると、
機　能は、いち部門との確認・調整だけでよいですが、
データは、複数部門との確認・調整が必要になります。

第２９回 マトリクス組織
（https://note.com/think_think_ab/n/n2d035be0e0f7）でも
　述べましたが、

組織は、
縦割りの場面では、ものすごく機能しますが、
横ぐしの場面では、ものすごく機能しません。（笑）

「機能間のデータの流れ」のシステム実現の難しさは、
　技術的な問題ではなく、こうした組織的な問題が理由です。

実は、そもそも、
業務フローの確認・調整自体が、
サービス部門、ユーザ部門とシステム部門間の調整ですが、

ビジネス側の
「組織間の 業 務  の流れ」が表であるのに対し、前述の
「機能間のデータの流れ」はの裏の存在であたります。

要件定義は、
表では、サービス部門・ユーザ部門側でも、複数の部門が関わりますし、
裏では、システム部門側も、複数の部門が関わります。

いいかえると
要件定義は「大いなる部門間調整の工程」といえます。

実は、
要件定義で部門間調整が終わると、
システム要件は機能ごとに分割されるため、

次の設計工程からは、
ひとつひとつの機能に相対する部門との調整に閉じることになります。

余談：機能とデータの実現性を左右する要素
　　　機能 → 技術的な要素が大きい
　　　データ（組織間のデータの流れ） → 組織的な要素が大きい

ちなみに、
要件定義工程で「機能間のデータの流れ」を確定できず、

放置されたままになると、
次の設計工程以降も、断続的に複数組織間の調整が発生し、
調整管理だけで、プロジェクトは不安定なものになりますし、
何よりも推進スピードが格段に下がってしまいます。（涙）

具体的には、
要件定義の工程では、
ユーザ部門を含め複数部門が集まることは定例的な位置づけですが、

要件定義後の工程で、
ユーザ部門を含め複数部門が集まるのはスポット的な位置づけで、
問題が発生したときになるため、日程調整から既に大変なことです。（涙）

組織の調整能力は、
なぜか過大に評価されてしまうことが多いですが、

お互いの遠慮が働いたり、関係組織が多いと、その複雑さゆえに、
解決できないことも出てきます…ので、実はあまり期待できません…

お話をもとに戻します💦

ここまで、
・業務フローに対してシステム部門が指摘すべきはシステム制約である。
・システムを構成するのは機能とデータであるが、
　前述のシステム制約とは「組織間のデータの流れ」である。
と述べてきました。

では、業務フローを眺めると、
機能間のデータの流れに無理がないか、見えてくるでしょうか。
残念ながら、なかなか見えてきません。

では、どうすればよいのでしょうか。

すみません。また次回に続くことになってしまいました。
※要件定義はなかなか奥深く、言語化が難しいです💦

次の記事（３５回）