IT戦士、育てます。 - 半端な日記

6月から今年の新人教育を担当することになった。
なぜ6月からなのかは、うちの会社では新人の1年目は以下のようなスケジュールになっている為だ。

4,5月は社外でJava言語の研修
6月は自社に戻りシステム開発の真似事を行う。具体的には、簡単な、いわゆるマスタメンテ系システムを題材として「設計＞開発＞テスト」の流れを経験してもらう。
7月以降は正式に各グループに配属され、各々実業務へ

つまり、教育担当といっても実際に毎日付いて指導するのは6月の1ヶ月間だけで、それ以降は週に一度くらいのペースで様子を見に行くくらいのもの。

前回の記事では、IT業界に入社した新人の各々が「能動的に」学習していくべきだ　という趣旨の内容を書いた。*1
しかし実際はそうではない新人も多い。
前回の記事ではやや過激に「それができなければ辞めるべき」と言った事も書いたが、正直なところこれはこの時期の新人の方々へ向けての記事内では書くべきではなかったと思っている。
新人には入社する前から既に採用広告費や職場説明会、採用面接、内定後研修や懇親会といったコストが掛かっている。
入社してからも会社は新人の研修費や給料を支払っている。
ここでいきなり「この仕事は自分には向いていないようなので辞めさせていただきます。」と言われては会社としてはとても大きな損失だ。
よって、新人を受け入れる側はせっかく入社してきた人材を「プロ意識を持ち能動的に考え自身の能力向上に努める技術者」へと育てなければならない。

今回、新人教育という大役を仰せつかったので、良い機会と思い上位者から見た新人の育て方について思うところをいくつか簡単に挙げてみる。
ちなみに、ここで言う上位者は何も「教育担当」という役割を与えられたものを指すのではなく、新人から見た先輩社員つまり2年目以降の社員全員のことを指している。
また、私の会社は受託開発メインの会社なので一部の内容は受託開発前提の内容になっている。

まずは基本を身につけてもらう

前回も書いたが、昨今はIDE（統合開発環境）の発達によりプログラムが楽に書けるようになった為か
知識の乏しいプログラマが多くなったように思う。
俗に言う「コピペプログラマ」というやつだ。
どこかのWEBサイトを検索し、そのプログラミング言語の最新バージョンでは推奨されなくなった古いAPIをそのまま使ってみたり、
WEBアプリケーションを構築しているのに最低限のHTTPステータスコードも知らなかったり。

基本を身につけるためには、まずはフレームワークやライブラリ等をなるべく使わず、泥臭いコードを書く経験が必要だと私は思っている。
私自身がこの業界に入った時点で、既にJava開発ではeclipseというIDEがあったし、いまだに多く使われているStrutsというフレームワークもあった。
だが、研修の時点ではエディタはUnix上のviだったし、アプリケーションも素のServletで作ったし、コンパイルもコマンドラインで行った。
DB周りもORマッパーなどは使わず、ひたすらカーソルをループして値を一つ一つ取得してオブジェクトに詰め込んだ。
※ただ、今年も同じやり方でやるかはわからない。開発はeclipseを使い、最後にコマンドラインでのコンパイルを経験してもらうなど考え中・・・。

このように一度レガシーのAPI環境で開発しておくと、その後何かしらのフレームワークを使用する際に内部でどんなことをやっているか大体想像が付くようになる。
そもそも、フレームワークの目的の一つとして、泥臭いコードを簡略化しブラックボックス化することが挙げられると思うが、
システム開発会社の正社員の立場の人間はブラックボックスのままにしていてはいけない。
ブラックボックスのままにしておくと、いずれ自分が開発の中心となり新しいフレームワークを始めて採用し、
「なぜか動かない」という様な状況になった時にどうしていいか分からず一切身動きができなくなる。

if文とfor文しか書けないプログラマに価値は無いし、それを技術者とは呼ばない。

可能な限りの多くの情報を与える

上位者は、部下に対してプロジェクトに関する情報を可能な限り多く与えるべきだ。

プロジェクトの引き合い、いきさつ
どのようなお客様なのか
金額的にどのくらいのプロジェクトなのか
そもそもどのようなプロジェクトなのか、お客様はこのプロジェクトに何を期待して（求めて）いるのか
担当機能は誰がどのような場面でどのような目的で使うのか
お客様の要望は今回のタイミングですべて取り込めているのか（継続的案件なのか）
etc...

これらの情報を与えた上で、設計書に疑問点や何か気付いたことがあれば細かいことでもいいから一言掛けるように伝える。
これは、以下の「考えることを促す」ことに繋がる。

考えることを促す

家電製品や自動車は設計図が完璧にできていて、設計図の通りに製造すればそれが製品となる。
つまり、設計図の段階で開発は終わっている。*2
しかし、IT業界の設計書はそうではない。IT業界の「プログラミング」と製造業の「製造」はまったくの別物だ。
IT業界の設計書には大概積み残しや凡ミスがある。*3
何も考えずロボットの如く設計書の通りにプログラミングをしていると、少し意識していれば誰もが気付くであろう
明らかな設計書の凡ミスでさえ見過ごしてしまう。
そして挙句の果てには「設計書にこう書いてあったので。」などと自信満々に言い放ち周りを落胆させてしまう。

プログラミングができなければ設計はできない。
設計ができなければ見積りもできない。
見積りができなければ契約もできない。

システム開発のあらゆる工程はリンクしている。

なによりも、考える力が無ければ要件定義もできない。
要件定義ができないということは、お客様の要望を形にすることができない。
上位者は、このことを部下に認識付けなければならない。

「スポット要員」のケアも忘れずに

プロジェクトの稼動がピークの時期など、一時的に一部機能だけのスポット要員がアサインされることも多い。
こういった者にも、できる限り上に書いたような情報を与えるべきだ。
また、こういった要員はそのプロジェクトのリリースを見届けることなく、担当の機能の開発が完了すればまた元の現場へと戻ってしまう。
それでも、そのプロジェクトが無事にリリースできたのであればきちんとその報告をしてあげる。
「作ってもらった機能、ちゃんと動いてるよ。」などと声を掛けてあげる。
もし不具合や不適切なプログラムの記述（APIの使い方など）があった場合でも、きちんと報告する。
失敗は成長する為のチャンスだ。
黙っていたら「あれで良かったんだ。」と思ってしまい、せっかくの成長の機会を逃してしまう。

高度なテクニックを見せ付けても伝わらない

私が新人の時は、教育してくださった先輩がなかりのvi使いでWindows機にViViを入れて普段のエディタにもしていた。
Unix/Linuxにもものすごく精通していて、私はそれを見て単純に「カッコイイ！自分もこうなりたい」と思った。
それ以来、席が隣だったので時間を見つけてはその華麗なキーボード捌き見ては技を盗んだし、
自宅にLinux環境を入れてコマンドやシェルの練習もした。
だが、すべての人間が同じような反応をするとは限らない。
私の場合、私の父が別の業界ではあるけど技術職として勤めていた会社を辞め、個人事業主の技術者として働いているのを小さい頃から見ていたので
このことが現在の私にいい意味で大きく影響していると思う。

普通の新人にいきなりこれ見よがしにと高度なテクニックを見せ付けても「ポカーン」とさせてしまうばかりか逆に不安感を煽ってしまうかもしれない。
相手がどのようなタイプかを正しく把握し、同じ目線で順序だてて教えていく必要があると思う。

部下は基本的には「かまってちゃん」

人間は基本的にはかまって欲しい生き物だと思う。
きちんとできる部下なので、信頼の意味を込めて放っておくという人が時々居る。
しかし、部下からしてみれば「自分のことを見てくれていないのか」という気持ちになりモチベーションの低下に繋がる。
また、自分が教えていないことを部下がいつの間にかできるようになっていた場合、
どんなに細かいことでも、軽くでいいからほめてあげる。
あるいは「どこで知ったの？」などと言及してあげる。
本当にすごく小さなことだけど、こういったことを積み重ねることで部下との信頼関係が生まれ、
部下は「きちんと自分のことを見てくれている」と感じ、モチベーションは向上する。

「教えてもらっていない」は「教えなくて良い」理由にはならない

私の偏見かもしれないが、就職難の時代やそれ以前に入社された方々は
「俺はそんなこと教えてもらっていない。すべて自分で調べるか、先輩の仕事を見て盗んだものだ。」
という。
だからといってそのことが今、自分の部下に対して「教えなくて良い」理由にはならない。
私はその時代を見ていないので浅はかかもしれないが、当時の方々は就職難の中やっとの思いで内定を勝ち取ったという状況で
とにかくがむしゃらに「やるしかない」という状態だったのではないか。

しかし、今はそうではない。上司の背中を見て自動的に部下が育つ時代ではない。
自分と同じレールの上を無理に走らせようとしても脱線するだけだ。
時代が違うのだから、古い方が今の時代に合わせるべきだ。
当然、何から何まで手取り足取り教えるというわけではない。
課題やきっかけを与え、背中を押してあげれば良い。

辞めたくないから「辞めたい」という

人は辞めたくないから「辞めたい」という。
死にたくないから「死にたい」という。
辞める人は「辞めさせていただきます」とはっきりと言うし、本当に死にたい人は黙って死ぬ。
だが、いずれにせよ、事が起こる前に「辞めたい」「死にたい」といったシグナルがあったはずだ。
上位者はそれを敏感に、真摯に受け止めなければならない。

『またか。「辞めたい」という奴ほど辞めないんだよな。』
などと心の中でため息を付きつつ、まともに取り合わないのは最悪の上司と言える。
きちんと話を聞き、企業側、部下の考え方双方の問題点を洗い出し精査するべきだ。

今の時代、インターネットに繋げば無数の転職サイトにアクセスできる。
そして隣の芝は青く見える。
「辞めたい」という部下はこれからもどんどん出てくるだろう。

おわりに

以上、自分なりに思うところを書いてみた。
実際に人を育てるというのはそうそう簡単な事ではないとは重々承知している。
あらゆる手段を尽くしても伝わらない、成長してくれないこともあるかもしれない。
自分の教え方が悪いのか、相手に適正が無いのか、原因はいろいろとあると思う。
いずれにせよまずは6月の1ヶ月間、自分自身にとってもいい経験になるだろう。
不安ももちろんあるが、不思議と楽しみだ。

*1:IT技術者に限らず、自分自身の仕事に関連する知識や経験は進んで積むべきだ。例えば、自動車販売店の営業の方は、まずは自社の販売車種について熟知しなければならないだろうがそれだけではい。他メーカーの最新情報も常に把握していかなければならないし営業職とはいえある程度の自動車整備の知識や資格も持っている必要があるだろう。また、営業技術の勉強の為に他メーカーの販売店へ客として出向くこともあるかもしれない。

*2:不具合があればファームウェアアップデートや無償交換、リコールが行われるけど

*3:ウォーターフォール型開発のこう行った手戻りのリスクを解消すべくアジャイルなどの開発手法があるが、ここでは触れない。