SE業界をやっていると、新人育成も大事な仕事の１つです。
僕は新人には、手取り足取り教えます。基礎が大事ですからホワイトボードとかを使って教えます。後は、その新人が興味を持っているものに例えて説明したりしています。
そこまでは比較的誰でも出来るのです。
で、ある程度できるようになってきた人に教える（ステップアップさせる）のが大変なんですよね。
基礎ができたら、お客様の要件をシステムに合理的に落とし込むところが肝となります。
設計するスキルも確かに重要なのですが現場に出るとそれだけではすみません。
結果的にお客様との会話も必要なスキルとなります。会話しながら、自分の頭の中でシステム化しながら、要件の中で無理（矛盾）が出た段階で、お客様にそれを説明するのが大変なんです。
本当基礎から教えていくのであれば、「変数のスコープ」とかも教えられるんですけれども（言語によって”変数のスコープ”は大きなポイントとなります。）、ちゃんと教えようとすればするほど、若い人は「うわー、この人、面倒臭いなぁ。」って思われてしまうんですよね。仕様書を書く人はスコープまでは書かないですから。
僕が本当に育てて伸びると思った人には、まず社内の関係を教えます。
僕が「育つ」と思った人にいつも言うのが、「部下に文句を言うな、言うなら上司に言え！」です。
完全に、出世コースを離れる教えですが、職人を育てるには必要なのです。ここが、辛いところ。その人の人生を決めてしまう訳ですからね。
これは一握りで、大抵はマネージャーの仕事を教えます。
SEの業界ではマネジメントがうまくいけば出世するという風習がまだ残っています。大企業になればなるほどその傾向が強いです。
で、実際にそれを実装（実現）するのが職人。職人は自分のスキルを誇らない（やれて当たり前をノルマにする。）ので、上司アピールも難しいんですよ。
実際、マネージャーがへっぽこでも、職人の棟梁がある程度見渡せばプロジェクトは回ります。
僕は、職人兼マネージャーで火消しをしたこともありました。
でも、評価されるのはマネージャーなんですよ。でも、職人はそこに異論を示しません。それが職人なのです。「火が消えれば良かったではないか。」それが職人。
職人は転職しても生きていけます。「手に技（職）を持っている」ので。
マネージャーは「300人規模のプロジェクトをマネージメントしてきた。」位しか言うことないですからね。デバッグも出来ないですから。滑稽なものです。中小企業にそんな大きなプロジェクト管理する必要ないですし、そんな事より手を動かしてくれよ。ってなもんです。
僕は６時間デバッグとかやりますからね。必要に応じればどこまでもデバッグします。原因は必ずあるのですから。それがプログラムの良い所。
それが自社製のプログラムではなくても、お客様に正しい事を説明するにはそういう能力も必要です。
あと、親会社としては、マネジメント以外にも技術がないと発注先から、「口だけで割り取って行きやがって。」って思われますから。ちゃんと技術が持っている人がいないとナメられてしまうのも事実なのです。
まぁ、本当に上手くいくためにはお客様のわがままを上手く説得する事なんですけどね。日本だとなかなか上手くいかない。「声が大きい人」の意見が通る世界ですから。
そこと十分戦えるスキルが必要なんですよね。
私はもう41歳。
若者よ！俺の屍を越えていけ！！
