「知っていること」「使えること」「請負稼業」「自社プロダクト稼業」
何の技術にしろ、アンテナ張りまくらないと乗り遅れるという現象は（メインフレームの威光が弱まり）オープンシステム流行以降顕著になったのではないか。 また、プロジェクト管理手法が数多登場したり、IT業界以外でも新会計基準やSOX法などが登場したりして、別にプログラミングに限った話ではない気がする。 ただ、下手をすると、半年もすれば技術動向は変わってしまうので、IT業界は他業界に比較しキャッチアップの必要性はなおのこと大きいのだろうが。
Java だと流行の変わり目とかは雑誌とかでばんばん特集されたりするのである程度空気が読みやすいんだろうけど、Perl の場合その辺の通な人の blog 読んでたりとか他の Perl ハカーな人のコード見てたら気づくとかそんなんなので、正直素人にはオススメできない。 その辺 PHP とか他のメジャーな言語はどうなんでしょうね。
効果的なキャッチアップについて。 要素技術については、勉強会への参加が一番てっとり早い気がする。 日本でも殆ど知られていない技術のプレゼンがあったり、新技術の採用実績についての話が聞けたり、懇親会ではざっくばらんに情報交換ができたりする。 （熱心な方はわざわざホテルを予約して地方から参加したりもするのだが、とはいってもやはり都市圏中心）
個人的な経験則。 某Java案件の面接の機会があって、そこのPMと話をしたのだが、 「自分はCOBOLしかやっていないのでよく分からないのですよ。DOAとか分かりますか？」 と言われてアゼンとしたことがある。 進捗管理を徹底し、きちんとプロジェクト管理さえしてくれれば、技術に疎い人間がPMをやっても別に問題ない（別にプログラムリーダ的存在は必要）のだろうが、現場に身を置かなければ時代についていけないのだな、としみじみと思った。
情報をキャッチアップでき、「知っていること」にしたとしても、それを「使えること」にしなくては技術を体得したとは言い難い。 「知っていること」と「使えること」には大きな隔たりがある。 （これがよく理解されていない案件に関わると大変な目にあう） ブログ等による自社ノウハウの開示がなぜ成立するのか？技術流出のリスクはないのか？という議論で、しばしエンジニアと非エンジニアに温度差が生じるのは、実はこういう隔たりを自明のものとしているか否かなのだろう。
ところで「知っていること」を「使えること」に転化させる為の仕組みについて。 ASPでもいいしパッケージでもいいのだが、「自社プロダクト稼業」（自社プロダクト保有企業）の場合、こういった転化させる仕組みはむしろ必須になるかと思われる。 プロダクトへの継続的な改善が必要なわけだし、経営的にもこれは意味のあることだろし、その為の投資は正当化される。
一方、「請負稼業」（自社プロダクトがない）の場合は･･･、社員教育がどうのこうのと言いつつも、「使えること」しか必要とされないことが多いのではないか。 長期的な客先常駐により、プロダクトへの継続的アサインもあるにはあるのだが、自社には還元されえぬもの･･･、そもそもコアパッケージがないのにR&Dって何よ？な部分もあると思うので、経営的に意味があるのかないのかは不明瞭。 また受注開発にしても、契約形態を考慮すれば、R&D的振る舞いがユーザに対して正当化されるとも思えない。 そもそも「プロダクトの品質改善」という目に見える分かりやすい形も存在しないので、計測不可能なのではないかな、とは思う。 （継続的プロダクトにアサインが出来たとしても、出向先での権限が限られているとか、改善へのインセンティブがないとか）
とりあえず人月単価こそが絶対的指針であり、契約以上のものは求められないとするならば、こういった分野でのR&D的試みは個々のエンジニアの「サービス」に終始してしまうのではないか。
人材を学習可能な自律的存在として捉えるか，採掘と搾取の対象として捉えるのか．これは企業理念の問題であると同時に，産業構造とインセンティブ・メカニズムの問題でもある．
例えば各論レベルでは、SIerの人材育成の限界というか構造欠陥に対し、「見切りをつける」（知的労働者には「組織を移る力」がある、転職します。）という結論が出てしまっているだろう。
「請負稼業」と「自社プロダクト稼業」には大きな隔たりがある。 そして、「請負稼業」から「自社プロダクト稼業」へ民族大移動が起こっているのが現状か。 （一部特権的大企業及び系列企業を除けば）
それから、請負稼業に拘りつつも、新しい契約モデルへの願い的エントリー。 コモディティ化と人月
