フロントローディング

自分の身近でソフトウェアのフロントローディングということばをよく聞くようになったのだけれど疑問点もいくつかある。
フロントローディングというのは、コレ。

製造業において、不具合その他の要求による手戻りを防ぐため、製品企画開発段階で品質をつくりこむことによる、負荷の前倒し現象のこと。負荷の前倒しによって総コストを下げ、製品リリースの時間を短縮する。
あくまでも現象。負荷の前倒し現象。
障害的な不具合回避や製造工程/生産ラインでのつくりやすさも鑑みて製品を開発しなければならない。そのため企画開発段階で品質とコストをつくり込むという考え方が源流管理。その源流管理の考えかたに基づく開発方式、いわゆるコンカレントエンジニアリングによって発生する現象が負荷（工数負荷/設計変更件数等によって代表される負荷）の前倒し現象＝フロントローディング。フロントローディングを手法と呼ぶのは誤り。
ソフトウェアにおけるフロントローディングといわれているのはコレ

企画/設計/コード/テストといったいわゆるウォーターフォール的に工程をとらえれば、かつフロントローディングを現象ではなく、手法と捕らえればこういう誤解(!)もありうるだろう。
要求/要件を追加し続けるシステム開発や改版を重ね続けるソフトウェア製品の工程とはなんだろう。企画/設計/コード/テストのそれぞれを工程と考えるのは無理がある。
そもそも工程とは、

一つの工程内で付加価値が発生しなければならない。

一つの工程その品質が検証できなければならない。

製造業的工程であってもソフトウェア開発的工程であってもこの2つは必須である。
自動車であれば(かなりモデル化しているが)

ハンドル取り付け＝曲がれる
ブレーキ取り付け＝止まれる

ソフトウェアであればやはり、顧客にとっての価値を発生する１機能単位のつくりこみ手順（設計/コード/テストの一連の手順）であろう。あるいは1つのVersionが一つの工程といえるだろう。
そういう工程が、『ふつう（だと考えられる）ソフトウェア開発工程』であろう。
誤解された『ソフトウェア開発のフロントローディング』と『ふつうのソフトウェア開発工程』をマップするとこんな風になってしまう。

Versionを重ねる度に、フロントローディングの波が現れる。そしてその波は『付加価値が発生せず品質の検証もできないOldType』の工程を採用している限り、波長は長くなり続け、振幅も大きくなり続ける。
ミクロにはフロントローディングであってもマクロにはフロントローディングにはならないのだ。1つの大きな波にさざなみを立てているだけにすぎない。
そうならないため、『ふつうのソフトウェア開発工程』を採用し振幅と波長を維持し続けるプロセスを維持しなければならない。
そのためには何が必要か...？！