めそらぼ - mesolabs.com

以下のエントリに全面的に同意。但し、一つだけ欠けてる視点があったためそのことについて書こうと思う。

それは、我々は会社員であるということ。

「高機能なフレームワーク」の功罪？

そのための一歩は、ものすごく当たり前のことだけど、「疑問を持とうとする」ってメソッドなのかなあと。
浅いようで深いような、根本的。これは「適性」と関連することかもしれません。企業にとって有益なプログラマ（人材）とそうでないプログラマ（人材）の境界は、極論するとそのあたりにあるのかも。
歩きつづける　ゆり　咲きつづける

現在、会社組織内で行われているJava Webアプリケーション開発において、フレームワークを一切使わないことなど考えられない。
それは生産性の高さだけではなく、生産物の品質を保証するものでもあるからだ。

だからこそ、高機能フレームワークは使えるがJavaは「書けない」君でも重宝される。
だが、上司・先輩はその彼に対して、彼が絶対的に信じているそのフレームワークに疑問を持てと言わなくてはならない。
なぜなら、部下の可能性を広げるのが彼らの使命であり、フレームワークに疑問を持つことがその第一歩に繋がるからだ。

「そのフレームワークの、原理・思想・アーキテクチャについて説明してくれ」と言うだけで、高機能フレームワークは使えるがJavaは「書けない」君に「疑問を持つ」メソッドを実装することができる。
ただし、そのメソッドの実装がどれほどの品質かは、元エントリにもある「適性」というやつに左右されるかもしれない。だが少なくとも実装させることはできるはずだ。

「疑問を持つ」メソッドが@Deprecatedもしくはfinalizeされてしまっている上司・先輩では、部下にそのメソッドを実装させることは難しいだろう。
そのような上司・先輩が上にいたら(ry
逆に、自分自身が、例えプログラマからリーダーやマネージャになろうとも、そのメソッドを実装し続けていくことが肝要である。

と、(dankogai風に)書いてみたものの、上司・先輩に「俺の可能性を広げてくれ～」と100%頼りきってる奴もどうかとおもうけどね。
まあでも実際そういう奴も育てていかないと自分の首を絞めることになってしまうのもまた事実だったりするのが辛いとこ。