(たぶん)似て非なる開発プロセスのモデル

「methaneの日記」に、「ソフトウェア開発をビル建設に例えるな」というエントリがあります。
(http://d.hatena.ne.jp/methane/20060710/1152536164 )ぜひ全文を読んで頂きたいのですが、とりあえず、雰囲気を掴んでもらうために、部分的に引用させてもらいます。

「ソフトウェア開発において、「建築」に相当する作業は、ビルド。英語ではどっちもbuild。どっちも、すでにちゃんとした設計書がある状況で、それを実際のモノにする作業。」

「逆に、プログラミング（＝大まかな設計～コーディング～テスト）に相当するのは、建物の設計。」

何人かのソフトウェア・エンジニアに感想をきいてみたのですが、「その通り」や「まぁ、そうとも言えるね。」といった反応だったので、当事者であるソフトウェア・エンジニアにとっては、意外な話しではなさそうです。
しかし、メカやエレキにとって、自明の理というわけにはいかないでしょう。 彼等が、ソフトウェアの開発プロセスを説明される時に、Ｖ字モデルが登場することが多いのが、その理由です。V字モデルは、要件定義,基本設計,詳細設計,コーディング,機能テスト,システム・テストの各段階を、コーディングがVの字の底になるように並べたものです。これを、素直に見てしまうと、「詳細設計終了時点で設計作業は完了して、残るは作り込みだけ。」と、例えばメカのエンジニアがそれまでの経験をもとに理解したとしても何の不思議もありません。そこに、突然、コーディング～テストが設計作業の一部(それも重要な一部)だと言われると面食らうでしょうし、ソースコードが設計書に相当しますなどと言われるとV字モデルでの説明との差を越えるのに時間がかかることになります。その他にも、メカニカル開発で言うデザイン・レビューやモデル検証が、ソフトウェア開発では想像を絶する頻度で行われていると理解した方がいい事や、設計書=ソースコードさえ完成していれば、ビルド=生産/建築は、自動的に且つほとんど瞬時に行なわれること、品質の定義も別物と見たほうがいいかもかもしれないことなど、メカ/エレ/ソフトの開発プロセスは、外見的に似ているにも関わらず、実際に行っていることや、制約条件などが、まったく異なっていることを理解し、理解してもらうために必要なことは、枚挙に暇がない、といったところです。当然、プロセス間の連携を図るための情報も、情報のやり取りのタイミングも、見直してみる必要があります。まぁ、竹を木だと言い張ってみたり、木に竹を接ぐことに苦労するよりも、木も竹も花も、それぞれが引立つような生け方を工夫するべきなのだろうと考えています。もとより簡単な話ではありません。