プログラマーの成長を考えないSIerの仮説は間違っている

Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで

熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。

というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは

• プログラマーのスキルレベルは一定で成長しない
• プログラマーは容易に交換可能なリソースである
• プログラマーは単純労働者である

というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。
COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境において、上記の前提が成り立たないことは実際に現場で開発した経験のあるプログラマーなら実に明白なことだと思うのですが。
とっくの昔に

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

などの本でプログラマーは知的労働者であるということが書かれていますし、有名な

人月の神話

でも、プログラマーが交換可能なリソースであるという仮説は神話として否定されています。
私としては、プログラマーのスキルレベルが一定という仮説に特に疑問を持ちます。スキルが低いプログラマーがいるから初心者でもわかるようにオブジェクト指向は使わないようにするなどという発想は、ちょうどドラクエでずっとレベル3くらいで固定だからずっとスライムしかいないフィールドで戦わせているようなものであり、実に面白みもなく無意味です。ドラクエだとレベルの高いキャラクターと低いキャラクターでパーティーを組ませて、強い敵と戦わせることで、レベルの低いキャラクターのレベルは一気に上がって、最後には差がどんどん縮まっていくようになっているのですが、プログラマーだってハイスキルのプログラマーとペアやチームを組んで、開発する機会を与えれば、多少敷居の高いツールやフレームワークでも難なく習得していくことが実際は多いと思います。実際、Javaもオブジェクト指向もまったく初めてというプログラマーで最初はまったく戦力にならなかった人が1ヶ月後にはJUnitのクラスを一人で書き3ヵ月後にはSpring MVCで画面のコントローラを実装できるようになるといったようなことは何度も経験しています。基本的にプログラミングが好きでこの仕事をしている人が多いのですから、レベルの高いプログラマーと一緒に仕事をして、オブジェクト指向など正しい考え方を身につける機会を与えれば通常はぐんぐん実力が伸びていきます。*1もちろん、中にはどのように指導しても成長せず、非常にやる気もセンスもないプログラマーもいるかもしれませんが、私の経験上そのような人*2は20人に1人もいないくらいであり、そういう人にレベルを合わせる必要はぜんぜんないと考えます。どうしてもプログラマーに向かない人は、テストの打鍵とかドキュメント整理など他にもいろいろタスクは与えられますから、そのような人のためにわざわざオブジェクト指向を捨てることはないのです。
プログラマーの成長を考えるなら、既にプログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してで指摘したように

さらに、付け加えるとこのような事前開発は、技術リスクの軽減効果だけでなく、開発メンバーのスキルアップという教育面での効果も高いです。事前開発を通してツールの使い方やフレームワークの使い方をそのプロジェクトの文脈で学ぶことができるのですから非常に効果的な教育ができます。

アーキテクト（上級プログラマー）を中心とした小規模なチームで事前開発を行うというやり方をぜひお勧めしたいです。要件定義が完全に終わらなくても、システムの核となるユースケースは初期の段階からおよそ決まっているはずですから、この中心となるユースケースを実現するためのベースラインアーキテクチャーを構築するフェーズを設けて、ここでアーキテクトのスキルをプログラマーにトランスファーします。このフェーズは比較的少数精鋭なのでアジャイル的に行うことができ、したがってJava EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのグラフの領域②で仕事ができるはずです。そして、画面、帳票、バッチ、マスターメンテナンスなど一通りの仕組みを作ってまだ人手が足りなかったら多くのプログラマーを後から追加して横展開すればよいのです。この場合、事前開発に参加したハイスキルのプログラマーが開発リーダーとして他のプログラマーをペアプロやレビューを通して指導します。このような開発スタイルを行う場合、現状のSIerフレームワークはアーキテクトにとって実に邪魔になることが多いです。
このように事前のアジャイル的な開発と、大規模なウォーターフォール開発を組み合わせる手法は「改良型ウォーターフォール」とも呼ばれるようですね。どうしてもっと普及しないのでしょうか？この場合、ポイントはスキルも高くて指導力もあるアーキテクトの存在にかかっていると思います。そんなアーキテクトはいないという声が聞こえてきそうですが、きちんと評価して、また、若手の技術力も育てていくようにすればそういう仕事をしたいプログラマーはたくさんいると思います。

*1:私の趣味ということもありますが、私がアーキテクトを担当した案件ではJPAやSpring MVCなどオブジェクト指向的で結構敷居が高いといわれるフレームワークを使った開発が多かったですが、最後まで技術力が問題になったという人はほとんどいません。むしろ、業務知識などがネックなることが多かったように思います。

*2:現在のスキルが低いという意味ではなくて潜在能力が極端に低いという人