「ソフトウェアは工業製品ではない」まつもとゆきひろ氏講演

　やっぱりそうですよね。ソフトウェア開発の方からこういう声が上がるのを待ってた。最初からソフトウェア業界にいた人は知らない方が多いと思いますが他業界から来た技術者から見るとフェーズの区分が異質に見えます。

　ちなみにハードウェア業界ではプログラミングは「設計」フェーズです。むしろドキュメント上で行われているのは全て基本仕様と要件定義で、詳細設計といいますかもっと具体的にマスク設計、回路設計、シミュレーション設計、ツール設計、テスト設計等のように呼んでいたと記憶しています。製造業の「設計」フェーズのみ切り離したものをソフトウェア開発と呼ぶのは非常に納得できます。また設計物ごとの分業はありますが知識の共有や周辺技術の理解も非常に重要なため案件ごとに担当をローテーションします。ローテーションを行うことで品質の安定化も進み業務の引継ぎの訓練にもなります(引継ぎ受けるほうは勉強大変ですが)。SE/PGのような役割の分担はなく全員E(エンジニア)です。

　もちろん「製造」というのは工場で製品を作っている段階です。ソフトウェアで一般的な業界で製造に当たるのはCD/DVDをプレスするときと納品先のコンピュータに実装するとき他にはマニュアルなどの紙媒体の製本です。ソフトウェア業界ではこれを「納品」と呼びますが、そもそも「設計」までが仕事なのでこの工程を「納品」と呼ぶことは正しいと思います。そう考えるとソフトウェア会社で「製造」フェーズに大きな人月単価が見積に出てくるのは変な感じです。会社名も○○ソフトとかでなくて○○設計所って名前なら意識変われるかな？

　元々「設計」しかないのにさらにそれを製造メーカーと同じように細分化するから分業の仕方に無理が出ていると思う。

ちょっと引用

ソフトウェアは書くものであって、読むことの重要性は、あまり意識していなかった人が多いのではないか。しかし、ソフトウェア開発においてキーボードを叩いている時間は短いのです。むしろ考える時間、読んでいる時間が長い

これは事実です。設計書とコーディングは成果物がドキュメントかソースかの違いなので人を分けないほうが効率はあがります。人数的に足りない場合はコーディング領域での縦割りはあっても設計の階層で分けないほうがいい(外注は階層が増えるのでコスト要求が厳しくなりますね)。むしろソースで設計内容を表現できるのが望ましいし紙製本で欲しい場合に自動生成できると尚良い。手作りドキュメントは仕様書程度にとどめておいても十分だと思います。

またハードウェア業界の話に戻りますが、ハードウェアでは研究開発と量産開発という分け方はありました。研究開発は基礎研究から次世代の製品の設計まで行い実験を繰り返し技術を積み上げていきます。量産開発の方は顧客から仕事を受注し要求をまとめ、研究開発の成果を量産設計に適用し歩留まり向上のノウハウを蓄積しながら開発を進めます。日本のソフトウェア業界はこの研究開発に当たる部分を社内に持っているところが少ないと思います。それだけにオープンソースが研究開発の役割を担っているので大変ありがたいです。

「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演 － ＠IT
http://www.atmarkit.co.jp/news/200904/10/matz.html