価値が共有されないのは多重請負のせいか？

前のエントリに関連します。価値の共有が難しい理由は多重請負開発の弊害である場合もあると思います。記事やブログでも多重請負の弊害として指摘していることが多いように感じます。

では多重請負を解消すると、すべてにおいて価値が共有されるかというと必ずしもすべてがうまくいくとは限りません。もちろん利用者と開発者が対話しやすくなったり、利用の様子を近くで見ることができるようになると価値の共有が促進されます。しかし、そもそも価値が明確化されておらず、そのせいで共有もできていない場合もあります。開発部門の管理職が他部門との連絡会議で聞いたことがありうっすらと理解しているだけということもあります。もちろん開発部門には共有されていません。社内システムであれば、そうした価値が共有されていなくても「同じ組織にいるんだから」という気持ちで、なんとなくわかっているという考えに陥りやすいように感じています。トラブルが起こってはじめて、平凡なように見えていて実は大事だったということがわかることもあります。

多重請負を解消して価値の共有がスムーズになるのは、次のような場合です。委託元ではソフトウェアやシステムの価値が共有されており、誰に聞いてもだいたい同じ回答が返ります。しかし明文化されていなかったり伝達されていないため、委託元以外の組織ではどういう価値があるかわからないということになります。

製造業での「製造ラインが止まる」、金融業での「システム停止」といったトラブルを避けるため、ラインが止まらないような仕組み、システム停止しないような仕組みに大きな価値があることは共有されやすいように思います。しかし、社内で使われている案件管理システムの停止、拠点のネットワークの不通による影響（すなわち安定して稼働しているときの価値）が共有されていないことは少なくありません。もちろん、共有されてさえいれば、そうした停止が防げるわけではありませんが、共有されていなければ大事なことが軽んじられる可能性が増えます。

案件管理システムと拠点ネットワークの事例の詳細は拙著「なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー 」の改訂版で追記しています。ソフトウェアやシステムの価値が高い部分（つまり期待通り動作しないと大きな被害につながる部分）をレビューで重点的に確認するための具体例を挙げています。

事例の案件管理システムはグローバル企業の案件管理で時差の異なる国で案件に関する情報が参照されたり追加されたりして業務が進んでいくシステムです。システムが停止するとメールや電話による代替手段が必要になりますが、非効率になるため、影響が大きくなります。そのため、停止を防ぐための仕組みが実現できているかをレビューで重点的に確認するというものです。

改訂版がお手元にある方は、2章の60～80ページにある2つの事例（多拠点の情報端末管理システム、案件管理システム）の部分ですのでご覧ください。お手元になく、ちょっと見てみようという方は、書店や日経ITproストアのページ（こちら）、Amazonのページ（こちら）から。