工程分割のメリット

工程を分割せずにすむなら分割しない方がよい

このエントリの草稿をしたためている時に、この原則が当てはまらない、
つまり、工程を分割する積極的理由が存在する
ケースを発見してしまいました。

それは、
前工程の成果物をチェックして、
事前に何を作ろうとしているか確認すること
によって、後工程でのより大きな手直しのリスクを回避する
ということです。

しかし、このメリットが成り立つためには、当然の前提条件があります。
それは、
前工程の成果物をチェックするコストが
後工程の手直しによる潜在的コストより小さい
という条件です。私の意見としては、最近のオープン系のシステム開発に
おいて、この前提条件が成り立つケースは少なくなっているのでは
ないかと思います。ゆえに、オープン系のシステム開発に限っていうと、
やはりほとんどの場合、「工程を分割せずにすむなら分割しない方が良い」
ということは正しいと思います。

なぜ、私が、
前工程の成果物をチェックするコストが
後工程の手直しによる潜在的コストより小さい
ということが成り立たないと思うのか?それにはもちろんいくつか理由があります。

3つほどあります。

1つは要求が複雑化しているため、上流工程で
前もって何をつくろうとしているのか確認するコストが増加している
ということが言えると思います。

2つめはシステム構成の複雑さの増加という問題です。
システムに必要なこと全てをメインフレームが面倒を
見てくれていた時代と異なり、現在ではシステムは実に様々な
構成要素から成り立っています。サーバ側で基本的なものだけでも、
OS, RDBMS, アプリケーションサーバ、様々なライブラリやフレームワークを
組み合わせて構築する必要があります。
その結果、システム構築上の技術的な問題点を
設計段階で全て洗い出すことは難しくなっているとおもいます。
つまり、いくら前工程でコストをかけても
後工程での手戻りのリスクを減らせるとはかぎらない状況が生まれている
と思います。

3つめは技術の進歩による、生産性の向上
という問題です。新しい技術の登場は常に開発者の悩みの種でしたが、
でも、それでも新しい技術が登場するたびに、ソフトウェア開発の生産性は
確実に上がり、開発者から単純作業を奪っていると思います。特に、
本番環境と同じプログラムが手元のPCでも
実行できるようになったことおよび、
xUnitのようなテスティングフレームワークによって
回帰テストのコストが下がったことによって、
下流工程における手直しのコストがどんどん下がっている
と感じています。

以上の理由により、現状では多くの場合、
上流工程での品質確認のコストより下流工程での手直しの
コストの方が少ない、つまり、
動いているソフトウェアを確認した方が早い状況が生まれている
と思っています。