ソフトウェア開発の属人性

ここらへんとかここらへんの話題にコメント。
ソフトウェア開発における「製造」工程については、多くの人が間違った認識を持っている。ソフトウェア開発はコードを書くまでが設計であって、ソースコードをもとに実行可能モジュールをビルドする作業が製造にあたる。例えば Java の場合では、ソースコードがあれば、コンパイラを使わなくても手作業でバイトコードの羅列である class ファイルを作ることができる(そんなことをやるような暇人は滅多にいないだろうけど)。この作業には属人性はない。
では、誰もが同じソースコードを書けるようにするためには、何をインプットにすればいいのだろうか？そんな問い自体無駄だ。同じ人に書かせた場合でさえ同じソースコードを書いてくれることは期待できないのだから。極端な話、ソースコードを渡した場合でさえ、同じソースコードをアウトプットしてくれるとは限らない。人間がソースコードを書く限りは製造にはなり得ない。
そういう意味からすると、ソースコードを生成する作業を「製造」工程にしてしまう方法はないわけではない。その解は、MDA だ。Executable UML を書けば、ツールがソースコードを自動生成するようになる。ツールは必ず同じソースコードを生成する。
で、バランスの話。それは、10月13日の日記で紹介した「アジャイルと規律」に書かれている。バランスがあーだこーだと議論するよりも、この本を読む方が早い。
属人性を最小限にまで減らすってことは、プロジェクトメンバー全員のスキルを「サイテー」だと仮定することにある。とてもえらい誰かが、スキル「サイテー」の人が理解できるレベルにまでソフトウェアの設計をブレークダウンした仕様書を書いてあげればよい(メンバー全員が、仕様書を正しく読み取るスキルを持っているという仮定も暗に含んでしまっていることにも注意)。でもそれは仕様書を書くためのコストが膨大過ぎて非現実的な話だ。少し現実的な方向で考え直す。プロジェクトメンバーのスキルを「サイテー」よりはある程度高いところにあると仮定すればよい。そうすれば、仕様書に書かなければならない情報量をかなり減らせる。メンバーに求めるスキルを高くすればするほど仕様書を減らせる。言い換えれば行間を増やすってことになる。その行間こそが暗黙知であり属人性だってこと。
さて、現実的なソフトウェアプロジェクトから属人性を完全に切り離すのは可能だろうか？