レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

分離や分散は問題に対する解決策などではなく、問題そのものとなる

上流工程と下流工程で発注するベンダーを変える(分離発注)ことにより、競争によってコスト削減を目指す。これは、まぁわかりますね。ありそうでなかったのがSI業界における分割発注です。

元請けに頼まず、複数の下請けに対して分割で発注するわけです。下請けにとって見れば、元請けがマージンととらないから、利益率が上がる。発注元にしてみれば、元請けに余分なマージンを払わなくてすむ分、コスト削減ができる。

分離発注と分割発注で大手SIerが没落? - yvsu pron. yas

ひがさんの日記より、

上流と下流で、ベンダーを変えるという(分離発注)に、僕はメリットを感じないですね。

プログラミングファーストのほうが、未来はあると思う。


そもそも、ドキュメントベースのコミュニケーションには限界があると考えているからです。

上流工程の成果というのは、ドキュメントに落としきれるものではなく、


ヒアリングや分析によってエンジニアに貯まっていく
「要件の背景にあるナレッジ」のほうがよっぽど重要だと思うのです。



うちの会社も、基本設計の途中から引き継いだりしたことがありますが、

先方さんが思っていたよりも、見積り工数は肥大化しました。

当初見積もった会社の「計画」まで引き継いで開発しろといわれても、

絶対に不可能と回答するでしょう。いくつか理由は考えられますが、


「人に貯まっていたはずのナレッジを、取り直す必要がある」というのも1つの大きな理由です。


例えば、帳票1つとって考えてみましょう。

ヒアリングの打ち合わせの中で、この帳票は今まで遅くて使いにくかったから、

今回から項目数を減らして簡易なものにして欲しい。」

という要望があったとします。

しかし、上流工程の成果物のドキュメントには、

「項目削減された状態の帳票レイアウト」が、

「要件」もしくは「仕様」として記載されるでしょう。



「この帳票は今まで遅くて使いにくかったから、今回から項目数を減らして簡易なものにして欲しい。」

という言葉を聴いているのと、聴いていないのでは、

プログラムに対する作り方って変わりませんか?

「項目数」が重要なのではなく、パフォーマンスが重要なのに

隠れてしまうということです。(これは一例で、もっと多くのナレッジが失われることになります。)



そういう話の背景まで、上流の会社からわざわざ別の競合会社に伝達されることがあるとは思えません。

もしかしたら、議事録にこういった話の流れが書き記されているかもしれませんが、

その議事録を読み直すことがあるのでしょうか?

情報システム部がSIをやるとしても、そこまで細かい暗黙値が連携できるでしょうか。



そもそも、結合やシステムテストでは、

また上流を定義したメンバーが活躍しなければいけない場が出てくると思うのです。



それに保守では、仕様などはソースコードを読めば判りますが、

「なぜそうなっているのか?」という要件が非常に重要になります。


それをドキュメントで書くとしたら、、、と考えても

そんなことは不可能だと感じます。

僕は書籍の執筆もしていますが、文字での伝達は低いところに限界があるとひしひしと感じるからです。

ドキュメントはコミュニケーションのツールではありますが、

コミュニケーションそのものを代替するものでなく、

人間に貯まる知を代替できるものでもないと思うからです。


「分離」や「分散」は問題に対する解決策などではなく、
問題そのものとなることのほうが多い

と開発現場のあらゆる「分離」「分散」について、感じます。