コメント欄で書くには長すぎたので、こっちで回答する。全然まとまってない。
簡略化すると｢人月商売は単価下げるしか原価下げられる要素が無い｣→｢単価安い所に出す｣→｢うまくいかないのでヘルプ工数投入｣→｢誰得？｣という話だと理解。
今から約４年前、まだはてなーになる前に僕はこんなエントリを書いた。
たぶん、だいたいおなじコトを問題認識していると思う。逆に言えば、なんにもかわってない。長いから暇な時にでもご一読ください。
いくら研究開発費を投資してプロセスを改善したとしても、意志決定が行われるレベルで単金を下げる選択肢がある限りは現場のプロセスは改善されないのです。売値を劇的に上げるか、原価を劇的に下げるかを実現した者こそが、この閉塞を打ち破るのかもしれませんね。
プロセス改善のインセンティブと値切りの誘惑 - GeekFactory
本筋から言えば開発プロセスの見直しによって必然性の無い工数を減らすことが先で、単価下げるのはその場しのぎなんだから全く解決にならねーだろというお気持ち、わかります。僕もそう思ったし。
これは、ずっと僕が言っているSIっていう業態でシステム開発のプロセスを変えるってことがどれほど難しいかって話だと思うよ。
受託開発の組織体は良くも悪くも個別最適の集合体のような業態なので、実はあんまり共有できる資産が無いと思うんだよ。マクロなプロセスでしかないと思う。ミクロの情報は多分吸い上げてもナレッジにならないかも。お客様の業務を知りましょうっても個別最適にしかなってないでしょ。小売と製造で共有できる業務知識とは、って聞かれても特に思いつかない・・・。
で、カネかけて研究開発やる以上は普遍性を加味する必要があるので、単純に考えれば大まかなWebアプリフレームワークと運用保守ツールぐらいしか共有できないと思うし、研究開発で超Cooooooooooolな何かを作っても、現場が｢うち、SAPの運用やってんのよ。ごめん、要らない。｣って言われたらどーしようもないし・・・。結局、毎年違う分野で技術検証だけして終わる、みたいな。気のせいか。気のせいだよね。えへへ。
それに外に出して当たり前になっているから、外に出せるまでにノウハウをためるのに時間がかかるのも、開発プロセスが変わらない原因の１つじゃないかな。ほっとけばもう次が出ちゃうし、何かを変えて会社に定着するにはでかい所は２～３年ぐらいかかるよ。中小は１日で変えられるけど。
なので、各案件ごとで個別最適を出し続ける受託メインのSIerで閉塞感を超えるには、SIerは垂直統合するしかない気がするんだよね。あんまり外に出しすぎるとフランケンシュタインみたいになる恐怖感アリ。ゆりかごから墓場まで全部やります、という会社になるべき。内製回帰派になったのはそういうのも一因にあるよ。全部自分たちでやる会社になる為にはまず会社の組織構造から抜本的に見直さなければならないんで、IBMのガースナー並の改革を実施しなくてはならない可能性大ですが・・・・。
売上が飛躍的に伸びなくても利益を伸ばすことは原価を圧縮すれば可能で、人月をベースに考えれば期間を圧縮して人数を削ってその分のカネを単価に回して技術者にカネを与える。ひがさんのプログラミングファーストはこういう方向だよね。売上1億で儲けが3000万と、売上20億で儲けが3000万と、どっちがいいかって話。結局コストで食われたら意味無いじゃんっていう。分母と分子なら分母を変えるほうが影響がでかいし、コスト削減は自助努力でがんばれる部分が大きいから、まずそっちからみんな手をつける。売上に影響されない要素を作ったほうが経営基盤が磐石になるから。
かといって原価＝だいたい人件費だから、原価削ると技術者リストラしなくちゃいけないんじゃね？っていう所に追い詰められるかもね。人月ってそーゆーのもツライとこ。
とりあえず、そんなところで。
気が向いたらまとめ直します。
