ソフトウェア開発における「製造」工程については、多くの人が間違った認識を持っています。
多くの人は仕様書を書くことが設計で、仕様書の内容をソースコードに表現することを製造と呼んでいる場合が多いようですが、その認識は間違っています。
ソフトウェア開発はソースコードを書くまでが設計です。
一般的な工業製品においての製造工程というのは、決められた手順に従って作業をすれば、誰もが同じ（またはほぼ同等の）成果物を得られることが期待されているプロセスのことです。
その前提で考えると、ソフトウェア開発の場合は、ソースコードをもとに実行可能モジュール等をビルドする作業が製造にあたると言えるでしょう。誰がやっても同じ結果が得られるのですから。例えば Java の場合では、ソースコードがあれば、コンパイラを使わなくても手作業でバイトコードの羅列である class ファイルを作ることができます。そんなことをやるような人はほとんどいないだろうけど、この作業には属人性はないと言えます。（ニーモニックをマシン語にハンドアセンブルするといった作業もこれにあたりますが、インターネット老人会の人しかわかんないですね）
では、誰もが同じソースコードを書けるようにするためには、何をインプットにすればいいでしょうか？
そんな問い自体無駄だというのは、プログラミングの経験がある人ならすぐに分かるでしょう。さすがに、Hello Worldを出力するコードを書くというレベルであれば、多くの人が同じソースコードを書くことが期待できますが、それでさえも、全員が同じコードを書くとは思えません。
Hello Worldではなく、もう少し複雑なプログラムを書くことを考えてみましょう。同じ仕様所を用意して、同じ人に書かせた場合でさえ同じソースコードを書いてくれることは期待できないと思います。プログラマは経験を積み重ねるので、1回目に作ったときよりも2回目の方が洗練されたソースコードを書くだろうと思われます。
極端な話、ソースコードを渡した場合でさえ、同じソースコードをアウトプットしてくれるとは限らないでしょう。スキルが高いプログラマならば、元のソースコード内にある不適切な部分を修正したソースコードをアウトプットする可能性が高いです。
つまり、人間がソースコードを書く限りは、そのプロセスは「製造」にはなり得ないということです。
しかし、ソースコードをアウトプットする工程を「設計」ではなく「製造」工程にする方法もあります。その解のひとつが、MDA （Modeling Driven Architecture）です。例えば、Executable UMLというツールがあります。Executable UMLでUML図を書けば、ツールがソースコードを自動生成してくれます。言うまでもないですが、UMLは仕様書です。そのUMLをソースコードに出力できるレベルまで細かく定義できるのが Executable UML です。ツールは必ず同じソースコードを生成するので、ソースコードを生成する工程は製造工程だと言えます。非常に短時間なので、工程表の中には現れないと思われますが。
ソースコードをアウトプットする作業から属人性をなくすことは不可能だということはわかりました。
では、ソースコードの属人性をもっと緩やかにして、ソースコードが異なっても同じ動作をすれば、その範囲の属人性は無視することにしてみます。ソースコード以前の設計についての属人性を最小限にまで減らすということについて考えてみましょう。
プロジェクトが作ろうとしているシステムの仕様を、チームメンバー全員がきちんと理解するというのが目標です。
その前提条件は、プロジェクトのチームメンバー全員のソフトウェア開発のスキルを「激しい初心者」（仮にFランクとします）だと仮定することにあります。
ソフトウェア開発の設計に関してとてもえらい誰かが、スキルFランクの人が理解できるレベルにまでソフトウェアの設計をブレークダウンした仕様書を書けばいいのですここでも注意が必要なのですが、メンバー全員が、仕様書を正しく読み取るスキルを持っているという仮定も暗に含んでしまっています。また、仕様書を正しく読み取るスキルがあっても仕様書の書き方によっては誤読する可能性もあります。誤読させないように書くスキルと、誤読しないスキルが要求されています。とにかく、スキルFランクの人のために仕様書を書くには、コストが膨大過ぎて非現実的な話なのです。そんなことをするくらいなら、偉い人がさっさと作った方が早いですよね。
もう少し現実的な方向で考え直してみましょう。プロジェクトメンバーのスキルをEランクは確保できていると仮定すればいいのです。ソフトウェア開発の知識に関して未経験者レベルのFランクの人は除外するとして、Eランクの人は情報処理技術者試験の基本情報技術者試験に合格しているレベルだと想定しましょう（かなりハードルが高くなります）。そうすれば、仕様書に書かなければならない情報量をかなり減らせます。
ただ、満点でなくても試験には合格するので、完璧ではありませんし、合格した時点では覚えていても、その後に忘れてしまうこともあります。仕様書を読んでも理解できないところは（仕様書に書かれていない部分を）コミュニケーションで補足していく必要があります。
事細かな仕様書を書かないということにすると、当然のことですが仕様書を読む人には最低限の知識を要求するわけです。
では、仕様書の冒頭部分に「○○に関する知識があることを前提とする」みたいに書いておくという手もあります。
この場合は、仕様書を書く人に「最低限の知識とは何か？」という条件を明文化する能力が要求されるのですが、仕様書を書く側としては、知ってて当たり前なレベルのことなので、それらの知識をひとつひとつ思い出して「○○に関する知識があることを前提とする」みたいなことを書くのは意外と難しいのです。知ってて当たり前だと思っているので。例えば仕様書をUMLを使いつつ作るとすると、「UMLに関する知識」くらいは書けますが、「MVCアーキテクチャに関する知識」とか「デザインパターンに関する知識」とか、いきなりいくつもの関連した周辺知識も要求する場合もあるので、すべてを思い出して羅列するのも難しいわけです。また、仕様書の内容によって、要求する知識のレベルも違うので、どこまでの知識があることを前提としているのかを明文化することも難しいわけです。
要するに、開発メンバーの最低ラインのスキルが高いほど、仕様書に書く内容を減らせるのです。言い換えれば行間を増やすってことになります。その行間こそが暗黙知であり、暗黙知そのものが属人性になってしまうのです。
例えば、ひとつの方法として開発メンバーのスキルの最低ラインに合わせて仕様書を作るという案が考えられます。その場合は、かなり冗長になってしまいコストもかなりかかります。最低ラインの人も、プロジェクトが進むにつれてスキルアップしますので、書かなくてもよかったことまで書くことにもなります。仕様書にかけるコストを下げるためには、もっと多くの前提知識があると仮定して仕様書を作ればいいのですが、前提知識を満たしてないメンバーに対しては、個別に解説したり、勉強してもらう必要があるということです。
つまるところ、コストを下げるために要求される暗黙知そのものが属人性といえるので、ソフトウェア開発の現場から属人性をなくすのは不可能なわけです。属人性をなくすのが不可能ならば、属人性やチームメンバーの特性をうまく活用してチーム内で役割分担をすることが、プロジェクトを最速でゴールさせるという考えましょうってことですね。
どこまで仕様書で明文化するのかという問題に対しては、プロジェクトごとに異なります。目標は、仕様書を作ることによって、プロジェクト全体のコストを最小化することです。
要は、バランスの話です。詳しくは、「アジャイルと規律」という本に書かれています。この本は超絶にいい本なので、ソフトウェア開発に関わる人はぜひ一読すべきだと思います。
アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～
2004年に、はてなダイアリに書いた元ネタ→ ソフトウェア開発の属人性