無能な上司の心配事
http://satoshi.blogs.com/life/2006/03/post_8.html#comment-15223017
コメント欄より．
気にしているのはリスクだと思います。
気にするだけなら馬鹿でもできる．
若くて高度な技術力を持ったエンジニアは、たしかに何も言わなくても何でもソツ無くやってくれてありがたい反面、
いくら優秀でも何も言われなければ何もできませんよ．
「早くしろ，そういうことは 早く言え．」
という川柳にある通り，コミュニケーションスキルに欠ける上司はお荷物以外の何物でもない．
じゃあその人（たち）が途中でごっそり居なくなったら（病気になってぶっ倒れたら、もっと待遇の良い会社に引き抜かれたら）どうなるのか？その開発プロジェクトは一気に危機的な状況に陥るかもしれませんね。
それは多重下請け構造とは何の関係もない議論だ．確かに少数精鋭の開発で，その少数のコアメンバーが抜けると危機的状況になるのは事実だが，多重下請け構造はその解決策にはなっていない．*1
多重下請け構造においては誰も抜けなくてもプロジェクトは危機的状況に陥るし，引き抜かれなくても多くの人間が抜けているし，その結果さらに輪をかけて危機的状況に陥っている．人を追加すればそれでうまくいくというのも『幻想』に過ぎない．*2
結局こういう議論が出てくるのは，現実が分かってない人間が開発を論じているせいなのだろう．人数を増やせば増やしたこと自体が大きなリスクになる．設計と実装を分離すれば，分離したことが致命的なリスクになる．その致命的リスクをカバーするために要員の追加が必要になり，追加した要員自体がまたリスクを増大させる．こうして多重下請け構造や設計と実装の分業ははリスクを雪だるま式に増大させることになる．
そうして増大したリスクは一部の中心メンバーの負担となり，その中心メンバーに万が一のことがあれば*3，プロジェクトは一気に危機的状況に陥る．またそういう命がけの仕事であることが分かっているので，そういう修羅場からは有能な人から辞めていき，現場の技術力低下を促進する．現場の技術力が下がればなお一層リスクは増大する．あとは悪循環．
実際には多重下請け構造はリスクを増やしこそすれ，減らすことはない．しかし開発の現場を知らない素人マネージャーはそういうリスクを理解する能力がないため，今日も同じ失敗を繰り返していることだろう．*4
品質はどうでしょう？開発の全工程を少数精鋭固定メンバで実施すると、仕様から設計に落とし込む際に、プログラムコーディングの都合の良いように仕様を解釈したり、考慮漏れが発生しやすくなるというリスクがあります。
これもウソだ．*5
上の記述は仕様が完璧であることを前提にしているが，仕様が完璧であるなど誰が決めた？単に都合の良いように仕様を曲解すればそれはバグだが，しかし実際には仕様自体が曖昧だったり，仕様自体に洩れや抜けがあることの方が多いだろう．だいたい良い仕様書を書くのはプログラムを開発するよりも時間がかかるものなのだ．開発経験も満足にない設計者が短期間で作る設計書やら仕様書やらが使い物になるわけがない．
「設計書を書くコスト」と「設計書を解読するコスト」と「設計書のミスを修正するコスト(設計者の失敗の尻拭いをするコスト)」などがそのまま１００％（以上）の無駄になる．「設計者などいない方がマシ」というのはこういうことだ．*6
つまり、昨今の多様化、複雑化した要求仕様から設計して、製造して、試験するという一連の作業をそこそこの生産性で品質よくトータルに実施するというのを、「上司たち」はオーバーワークじゃないかと思うわけです。
それは多重下請け構造とそれに伴うウォーターフォールモデルの致命的欠陥を示しているに過ぎない．システムが複雑化すればするほど，多重下請け構造とウォーターフォールが致命的なボトルネックとなっているのだ．
それと「設計した人が製造もやった方が良い」というのは別問題だと思っています。
プログラミングは「製造」ではない．
まずいのは、新人から上級マネージャまたは上級エンジニアに至るまでのキャリアパスが曖昧になっていて、各段階での育成方法が確立していない、下手をすると議論すらされていないという状況下で、多くの人が不況にもがき、解決に向けて投資もままならない・・・という現状に不安を感じているということじゃないでしょうか。
論点がズレている．
開発者が上級マネージャになるわけじゃない．上級エンジニアは今の日本企業じゃほとんど幻想．キャリアパスが『曖昧』なのではなく『存在しない』のが問題とされているのだ．
*1:この議論は，その昔にあった経営リスクを回避するための「経営多角化」の議論と似ているな．その昔は一つの分野に重点を置きすぎると，その商売がダメになったときのリスクが大きくなるので複数の分野に幅広く展開した方が有利だと，まことしやかに語られていた．でも実際には複数の分野に手を広げても，それぞれの分野でNo2,No3になるのがやっとということの方が多くなってきた．これは国際化もその一因かもしれない．しかもNo1とNo2以下では収益率が大きく違うことが多く，複数分野でNo2以下に甘んじるよりも，一つの分野に全経営資源を集中してNo1を取った方が良いというのが，最近の傾向だと理解している．IBMのHDDやThinkpadの売却などがその例の一つ．逆に「総合」なんとかという感じの手広くやっている所は，苦しい戦いを強いられている．もちろん米国産牛肉の輸入禁止で大打撃を受けた「吉野屋の牛丼」のようなリスクもあるが，だからと言って「経営多角化」はその解決策にはならない．
*4:１＋１＝２は算数では正解だ．開発では１００＋１００＝２００にはならない．１００＋１００＝１００のこともあるし，１００＋１００＝５０のこともある．
*5:自称『設計者』などだけが，そのような主張をしているだけ．
*6:感覚的にいうと，こんな感じ．
合計で1億円の予算があるとします．設計書の作成に3千万を使いました．設計書の解読と書き直しに3千万使いました．3千万使って実装しました．最終段階まで来ると設計書に矛盾があり，設計書通りに実装しようとしてもそのままでは実現できないことが判明しました．そこから1千万使って設計書の矛盾を修正しました．4千万使って実装をやり直しました．それからテストとデバッグを行いました．
さて最初に作られた設計書の適性価格はいくらでしょうか？
