あるサブシステムの設計レビューをしている中で、「サブシステム間通信のルールが増えて工数が増大している」という話を耳にします。「仕様が増えたんだな、仕方がない」と思ってはいけません。この一言はサブシステム間調整がうまく行っておらず、無駄な通信が発生しているのではないか？と疑います。

整合がとりにくい場合
サブシステム間でのデータの受け渡しはシンプルであるべきなのですが、単純な基本設計から他サブシステムの要件を理解して、それぞれのサブシステムが自分の要件に合わせて、設計した後にサブシステム間の通信手順を実装しようとする場合、往々にして遠慮や調整の面倒などの関係から言われた相手の仕様に合わせて、困難な開発を進めてしまうことがあります。

ほとんどの場合技術力に自信のあるサブシステムが、「俺たちのほうで何とかしてやるよ！」という男気でやってしますことが多いです。調整よりも技術で解決する方を選んでしまうわけです。

通信サブみたいに担当がいたとしても彼らはデータの受け渡すためのインターフェースを提供するだけで、アプリケーションレベルのシーケンスには関知しないのが一般的です。

技術力のあるPMとしてはデータがどのように流れているのかをヒアリングするなどして理解してサブシステム間で最適な状態に調整して進めることが重要です。

ボトムアップ開発の問題点
本来はシステム全体のアーキテクチャはアーキテクトが責任を持って設計して、その手のデータの流れなどをすっきりさせたうえで、インターフェースを最適化して、共通チームなり各サブシステムのアプリケーション開発チームなりに割り振るのが最適です。

アーキテクトがいないようなボトムアップ型開発の場合、（要は、お客様から全体の機能仕様書が出てきた段階で、各サブシステムに割り振って検討を始めたような場合、バラバラに機能を積み上げ、最後にサブシステム間の調整をそれぞれで行ってつなげるという進め方をした場合。）全体整合がとられていなかったり、あるサブシステムが勘違いで置いた前提条件を正として、みんなが無理にそれに合わせるような設計をしたりすることが多くなります。

結果、それぞれのサブシステムでインターフェース作成工数が膨れて予定を上回り、収益率が悪化することがあります。

このような場合はあとからでも全体整合をとる必要があります。

システムアーキテクチャーウオークスルー(SHAWAT)です。