「即戦力」について考えてみましょう。

　転社するなら、「即戦力」が、大きな評価点の１つになるのは確かでしょうね。転社の前提となる「即戦力」については、論点の対象外とします。というのは、中途採用は、「即戦力」として雇われるから。

　論点にしたいのは、「新規採用と即戦力の関連」です。
　新卒の人たちに対して、即戦力を期待することは無理なことですが、新卒の人たちを、「早く （したがって、速く） 一人前にしたい」という焦りがないか、という点を論点にしたい。

　技術というのは、いきなり、新しい形として現れることは、まず、ない。
　前の時代に使われていた技術を改善した形として現れるか、あるいは、それを打ち消すように、反対の観点に立って提示された形として現れる。たとえば、Java を習得するなら、Ｃ＋ のシンタックスを知っていたほうが理解しやすいでしょうし、ＲＤＢの技術を研修するなら、ＮＤＢ （あるいは、階層構造型ＤＢ） の知識があれば理解しやすいでしょう。

　自らが、いま、使っている技術の特徴や設計思想を理解しようとすれば、当然ながら、その技術の前提になった （あるいは、その技術が相対する） ほかの１つの技術を、おおまかでも良いから、理解しておかなければならないでしょうし、さらに、時代を遡って、そういう技術の原点となった思想 （理論） を検討吟味することは、学習 （あるいは、教育指導） のなかで配慮されてしかるべきでしょう。
　１つの技術を、できるかぎり、正確に習得するためには、２つの技術を知らなければならない。なぜなら、１つの概念は、対比して理解するしかないから。
　そして、自らの技術に関して、改善しなければならない点を認めたとき、技術の設計思想を検討吟味しなければならないのですが、設計思想を検討する対象として、技術の「原点」になった文献を、すぐに、言及できるかどうか、という点は、エンジニアの実力を判断するための１つの材料となるでしょうね。

　学習というのは、促成栽培のできない領域です--地味な・着実な やりかた しかない。
　したがって、一人のエンジニアを育てるためには、「長い目でみる （give a long time）」ことを前提にしなければならない。
　ところが、「早く （したがって、速く） 一人前にしたい」という焦りがあれば、「手っ取り早く、わかりやすい」 やりかた を、教育研修プログラムにしてしまう。技術の変化が速い、という錯覚を抱いているので、焦りになるのでしょう。技術は、いったん、導入されたら、１０年ほどは、消えることがない。したがって、技術の変化は、想像されているほど、速い訳ではない。変化が速いと錯覚しているのは、技術が改善されるからであって、技術そのものは、早々、変化していない。たとえば、Java は、1990年代のなかば頃に出ていますから、すでに、１０年弱前の技術ですし、SmallTalk が転換点となったのは、1980年頃ですから、２０数年ほど前に現れたし、ＲＤＢも、（コッド論文は、1970年に提示されていますが） プロダクトとしてマーケットに現れた時期は、1980年代ですから、２０数年前の技術です。

　エンジニアの実力を評価する際、僕は、専門技術に関して、詳細な質問をしない--なぜなら、エンジニアが、自らの専門技術を習得していることは、当然だから。僕が、エンジニアの実力を評価するために用意している質問点は、「専門技術と相対する技術 および 専門技術の原点となっている理論」に関する質問点です。そういう質問をしてみれば、たいがい、エンジニアの実力を判断することができます。

　
　（2004年4月5日）