設計と製造は違う人はあまりやらない

要求仕様分析なり、要件定義なりはシステム部があればそこがやるし、委託してベンダーがやることはあるけれども、基本的にはそこから先がいわゆる開発の仕事であって、要件がめちゃくちゃだよっていう後戻りはあるかもしれないけれども、外部設計以降の工程で工程ごとに違う人が担当している(と言ってもブラックボックステストは違う人がやるべきだろうとは思うけれど)ことはあまりないのではと思う僕は幸せなエンジニアなんだろうけれどもね。

よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

「上流工程」と「実装やテスト」って詳細設計は一体。実装は詳細設計の内であるのは確かだけれども。ちなみに人月単価が安いのは当たり前、とは言いたくないけれど…仕方がない。とりあえずは。

一度固定した文書は次のフェーズで変更するとなると、手戻り工数が莫大になってしまうので、通常は、前工程で決めたことは、後工程で変更はしない。後工程で変更しないという前提で文書を作るので、

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

それは作成された文書が変更に対して脆弱なだけではないかと。通常、やばそうなところはどうにでもなるようにしておくべきだし、それでもダメだったらそれはエンジニアが無能か、ユーザーがよっぽどのバカかで、フェーズ分けの問題ではない。もちろん、フェーズが変わったことを理由に無駄な要求を跳ね除ける前提で、システムが目的を達成するために本当にどうしても必要な要求だけを(ユーザーには内緒で)分別しておくのはエンジニアの良心と自己防衛だ。

当初予定していた利用環境やユーザの要求というのも時間とともに変化するので、実装が終了した時点では仕様そのものが陳腐化するという事もすくなくない。ひらたく言うと、一生懸命つくっていたのに使えないものができてしまったということである。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

平たく言うと、時間とともに変化するものをしっかりとちょん切るのがウォーターフォールモデル開発。これは単なる失敗にすぎない。

通常は上流の方が単価が高く、下流の方が単価が安いので、だれも下流をやりたがらない。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

上流は単価が高いけれども、会社のリーダークラスの能力がある人間が一人とか二人程度の単位で拘束されたりするので、開発に繋がらない限り会社としてのメリットはそんなにないからあまりやりたがらない。いや、やるからには開発までまとめてやらないと勿体無い。どんな少数精鋭の会社なのかと小一時間…
下流工程は、スケールメリットも出るし、単価の安い人を連れてきて利ざやを稼ぐことも出来る(ああ女工哀史…)。

下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

単価の問題ではなく能力の問題。経験豊富なベテランを上流に売り込めない会社はクズ。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

まあ少なくとも設計者とレビューアーは同一人物であることが望ましいですね。ただ、仕様の決定ってのは詳細仕様だよね。もし部品の仕様を指すのであればこのことは上流と下流が分離していることを意味しているし、上流を機能単位で完全に会社別に分けてしまう大規模プロジェクトは失敗の臭いがプンプンとする。

実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

これは真実だ。しかし、その根本原因は設計がしょぼい事であり、あるいは実装がしょぼい事であり、分離することによる弊害の証左にはなり得ない。

日本のソフトウェア開発の現場の国際競争力のなさというのがあるとしたら、ITゼネコンをよしとした、上流下流工程を是認したソフトウェア生産方法論にあるのではないか。

http://blog.miraclelinux.com/yume/2007/10/post_4e54.html

必死で下流工程をオフショアに投げようとしている現状を見るにつけ、開発の標準化の大切さを思い知らされます…嘘です。オフショアは詳細設計と開発を分離する一番悪いところの工程分離になりがちで、その点から言うとこのエントリ全体の主旨は納得感があるのですが。

ともかく、上流と下流と言う大雑把な話でもなく、ユーザー要望をどう要件に、要件をどう設計に、設計をどう実装に結びつけるか、と言うことを考えるのがシステムエンジニアの役割であって、それぞれの作業が適切に行われていれば、ある程度人が入れ代わっても問題ありません。大体実装の段階では設計者だけじゃ手が回らないんだしさ、そういう手の代わりをする人は単価が安くなりがちだし、結果として工程の単価は下がるわな。
この人のブログは結構面白いんだけど、今回に関しては、あまり上手くいったところを見たことがないだけなんじゃないかな、と思ったりします。