GeekFactory

int128.hatenablog.com

手順どおりにやるだけでソフトウェアを製造できるようになるのか?

ユーザー企業がイノベーション・エンジンとして動くようなそんな仕組みが絶対必要になると思う。(中略)僕が考えられるオプションとしては「内製回帰」か「人材サービス前提からSaaS型の業務アプリ開発への転換」の2つかな。

http://d.hatena.ne.jp/gothedistance/20080529/1212033139

しばらくid:gothedistanceの記事をチェックしていなかったのですが、私の先日の記事は二番煎じだったようです。素晴らしい考察です。脱帽。

もう少し引用させてもらいます。

個人に依存して良いことは限られています。業務システムには運用があって、いくら開発時に「超生産性高い技術者」が颯爽と現れ短期間でカットオーバーできたとしても、もうその技術者は戻ってこないわけで。それ、誰が面倒見るのよ、と。

http://d.hatena.ne.jp/gothedistance/20080529/1212033139

開発時に超生産性高い技術者が颯爽と現れるところは、カオス化して手が付けられなくなったプロジェクトです。火消しと呼ばれる人たちは好きで保守性の低いコードを書いているわけではなく、圧縮された工期の中で仕方なくやっているだけです。そのような技術者を責めるのは間違いです。優秀な技術者はスケーラブルな設計をして、保守性の高いコードを書く人です。非エンジニアな人はよく勘違いをしますが、他人が理解できないトリッキーな実装を好む人は「優秀な技術者」ではありません。

いまのSIerで問題なのは、優秀な技術者を増やして保守性を向上させるのではなく、誰が製造しても同じコードができるようにして保守性を向上させようとしていること。その手段がプログラミング言語を日本語に直したプログラム設計書であったり、猿でもできる手順書であったりします。ただし、プログラム設計書や手順書は不幸な現実を改善するためのエンジニアリングの結果であって、推進している人たちを責めるつもりはありません。

根本的な問題は、手順どおりにやるだけでソフトウェアを製造できるほど技術が進歩していないことです。そもそも私は無理だと思っています。仮に実現してもソフトウェアの複製コストはゼロなので。そろそろ、製造業の手法がソフトウェア開発に通用しないことを認める時期ではないでしょうか。研究部門にはこの矛盾を感じている人はいるかもしれませんが、大企業の方針に背くことはできません。

単価の高い少数の人が管理をして、単価の低い多数の人が手順どおり作業をすることは、経営者から見れば理想的でしょう。しかし、ソフトウェア開発はそれを100%可能にするほど進化していません。大規模開発が知識集約化するとは到底思えません。エンジニアリングが進むほど、作業はより労働集約的なものになります。知識集約化を期待できるのは、今まで人ができなかったことをITで実現する領域な気がします。その領域こそユーザ企業が主体的に挑戦してほしいと思います。

追記

この手のエントリは書きづらい。なぜなら、自分が今まで関わってきたソフトウェアエンジニアリングの根底を否定することになるから。あるべき姿は何だろうか。