研修を終えた新人たちが現場にやってくる。皆さんの中には、先輩エンジニアとして彼らを指導する人も多いのではないだろうか。新人を迎え、指導するために必要なのは、相手を知り、自分を知ること。新人と自分との間にあるギャップを意識し、成長の手助けをしよう。それが先輩エンジニアとしての心得だ。
研修を終えたばかりの新入社員を迎え入れるには、いまの自分が彼らに比べてどう成長したか、つまり新入社員と皆さんとの間にあるギャップを知っておくことが重要です。
「前編 新人はスケジューリングをしない」では、「学校と社会のギャップ」についてお話ししました。後編に当たる今回は、「理論と実践のギャップ」をご紹介します。
社会人として仕事をする中では重要なのにもかかわらず、新入社員にとってはとかく面倒くさいものの代表として、「ホウレンソウ(報告・連絡・相談)」が挙げられるでしょう。
新人研修中でも訓練の意味で日報や週報を新入社員に提出させる会社は多いと思いますので、「報告」の仕方に関しては新人もある程度理解しているでしょう。ですが、新人研修は研修カリキュラムのスケジュールを研修担当者が管理しているわけですから、いわゆる「進ちょく報告」のたぐいは経験していないと考えた方がよいでしょう。
システム開発に携わるエンジニアの場合、報告の中でも特に重要なのがこの進ちょく報告です。エンジニアの進ちょく報告には、次のような内容が含まれるでしょう。
皆さんには当たり前のようにできている報告でも、新入社員がいきなり実践するのはなかなか難しいものです。例えば1の進ちょく率などは、弊社で研修を行った際に新入社員に報告させても、「?」となるばかりでほとんど要領を得ませんでした。
もしその新入社員が実装を担当しているとすれば、担当しているクラス数に対してのコーディングが終了したクラス数の割合を求めれば、かなり粗いですがおおよその進ちょく率を求めることができます。新入社員はそのような判断基準を持ち合わせていないので、皆さんからこのあたりの算出基準を教えるとよいでしょう。
そのほかの「連絡」や「相談」の重要性に関しても、新人研修中にはなかなか実感を伴う経験ができないので、配属後もピンときていない新入社員が多いことでしょう。
連絡に関して、弊社で研修をするときは、とにかく「確実に伝わる手段を取ること」を教えています。顧客の中には時々、メールの返信がすぐに帰ってこないと文句をいってくる人がいますが、メールはもともとリアルタイムで内容を送受信するインフラではありません。このようなことをいう人は、連絡のための適切な伝達手段を取っていないことになります。良識のある顧客ならば、急ぐ連絡は電話でしてくれるはずです。
相談に関して、新入社員が一番悩むのが「相談するタイミング」です。パターンとして、新入社員ができるだけ自分で調べて解決しようと頑張るあまり、半日、1日と作業が止まってしまうことがよくあると思います。新入社員から質問がなければ、そのときは先輩は仕事がはかどりますが、新入社員が質問すべきところを質問せずにずっと悩んでいた場合、結果的には先輩の仕事が増えてしまいます。やはり適切なタイミングで相談してもらう必要があるでしょう。
とはいえ、適切なタイミングの判断基準が分からないことが新入社員の悩みどころなので、「30分悩んで何もできなければ相談する」というような、数値化したタイミングを提示してみるのはどうでしょうか。
弊社が新入社員の研修を請け負う場合、仕上げとして必ず新入社員にチームを組ませ、仮想のシステム構築案件をさせるようにしています。このときに多いパターンとして、「設計〜実装はとても熱心かつ丁寧にやっているが、テストや納品物の整理になるととたんに力が抜けて雑な作業になってしまう」というものがあります。
「エンジニアはドキュメンテーションが嫌い」というのはこの業界の定説ですし、テスト工程の作業が面倒なのもある意味当たり前の話です(だからこそエンジニアはテストをできるだけ自動化したいと願い、工夫します)。この業界に入ったばかりの新入社員では、この傾向はなおのこと強いのです。彼らにとっては実装が最も楽しい作業であり、実装こそエンジニアの本当の仕事、ほかの作業は面倒なものという意識は、皆さん以上に強いといえます。
私自身も、新入社員のときは雑なテストをしてよく怒られた記憶があります。新人研修でもテストやドキュメンテーションの重要性は教えられてくるはずなのですが、現場の先輩である皆さんが実地の経験を基に話をするのも1つの方法です。
もし皆さんが開発案件を2〜3年経験しているとしたら、きっと1回くらいは、テストが不十分で納品直前にバタバタしてしまったプロジェクトを知っていることでしょう。そのときの経験を話してあげれば、新入社員にとって研修だけでは分からない生きた知識となり、面倒な作業の重要性を認識させることができるのではないでしょうか。
開発現場の先輩社員はなぜ徹夜や休日出勤をしてまで納期を守ろうとするのか、新入社員にはピンとこないだろうと思います。
数年前、とある会社で新入社員研修をしたときのことです。連休が明けて研修会場(顧客のオフィスにある会議室)に行ってみたら、机の配置は変わり、部屋全体が散らかり気味、しかも研修用のマシンが使われていて、研修で使う予定のないソフトウェアが入っていたことがありました。新入社員たちは初めはあっけにとられていましたが、この会議室が連休中何に使われていたのかに気付くと、皆一様に不安な顔つきになったものです。「実際の開発では連休にも作業をしないといけないのか」とでもいいたそうでした(しかも、受託開発案件は4月カットオーバーだったり、5月の連休明けにカットオーバーだったりすることが多いですよね)。
納期を守ることの重みを示す、分かりやすい例といえます。このことを新入社員に理解させるのには、「エンジニアにとって納期は絶対だ」と鉄則化することも必要ですが、納期を守らないとどんな不利益があるのかを説くことも良い方法ではないでしょうか。
前回の「ギャップ3 新人は開発案件がどうやって利益を得ているか知らない」でお話ししましたが、担当者が作業をすれば、それだけでコストが発生します。納期をオーバーして作業をすれば、ほとんどの場合そのプロジェクトは赤字になり、利益にならないと分かっている作業をし続けることになってしまいます。納期を守ることは、顧客の信用を保つという倫理的側面もあるのですが、会社としての利益を確保するという企業活動の根本にかかわる部分が大きいというところを新入社員に理解させることが重要でしょう。
エンジニアが開発案件で解析が困難な問題や難しいバグに直面したとき、真っ先に思うことは何でしょう。「逃げ出したい」。それももちろん1つの回答ですが、「作り直したい」と思うことはないでしょうか。
しかしながら、首尾よく作り直しができる案件はごくまれである、というのは皆さんもよくご存じのことかと思います。ほとんどの場合、納期の問題で作り直している時間がとても確保できないとか、すでに運用に入っていてもう作り直しがきかず、現状のモジュールで何とか対応しなくてはいけない、というのが普通でしょう。
私たちでさえ作り直したいと思うのですから、新入社員ではその傾向はますます顕著です。きつい、難しい、理解しにくいと分かっているコードをメンテナンスするのは、いうまでもなくとても苦しい作業です。
弊社で新入社員研修を請け負う際には、カリキュラムにシステム開発を設計から実装、テストまでひと通り体験させる仮想プロジェクトの運営を入れています。新入社員の作成した設計をレビューした段階で「これはやり直した方がよい」と思っても、あえてやり直しをさせず、そのまま最後まで設計させ、実装させることがあります(新入社員にしてみれば、「気付いているのになぜ指摘してくれないのか」と反感を覚えるところでもあるのですが)。
実際の業務では、やり直したいと思った時点ではすでに作り直しができない状況になっていることの方が多く、そのことを少しでも新入社員に経験させたいという目的があるのです。作り直しのできない状況で現実的なソリューションを少しずつ積み上げていく経験は、そのときはつらいですが、後々の開発できっと役に立つだろうと思っています。
「これは作り直した方が早いよ」というのはエンジニアがよくこぼす愚痴ですが、同じような局面はおそらくビジネスのあらゆるところに存在しているのです。きついと分かっている局面を耐えて乗り切るエンジニアの忍耐強さは、ビジネスパーソンとしての普遍的な忍耐強さにつながる、大事なスキルであるといってよいでしょう。
ここまで2回にわたって、先輩社員の皆さんの参考になるような、新入社員と皆さんの間に存在するギャップのパターンをご紹介してきました。
新入社員がそのギャップを意識し、自分を成長させるためには、ギャップを埋めるためのお手本となる存在が必要です。そうです、もちろんそれは、OJTなどで新入社員の面倒を見ることになる皆さん自身なのです。
数年前、ある会社で若手〜中堅の社員の研修を請け負ったときには、2〜3年目のエンジニアの中にも、まともに進ちょく報告が書けない人が多くいました。これでは、もし彼らのもとに新人が入ってきても、正しい進ちょく報告が書けるようになる可能性は薄いといわざるを得ないでしょう。
新入社員の進むべき方向は皆さんが示さねばなりませんし、間違ったときにそれをしかるのも、もちろん皆さんの役目です。
まずは、自分がここに挙げたようなギャップをまだ持ち続けていないか、新入社員が見てまねしたい存在となっているか、確認するところから始めていきましょう。本稿が少しでも皆さんの参考になれば幸いです。
中越智哉
株式会社テンアートニアプリケーションビジネスユニットテクニカルソリューション トレーニンググループコンサルタント
1974年北海道生まれ。1999年北海道大学大学院 電子情報工学専攻修士課程修了後、同年4月テンアートニ入社。開発案件・トレーニング講師を担当。2000年12月より、@IT Java Solutionフォーラムにて「Java Solution FAQ」を執筆(2001年11月、同連載をもとに書籍「Javaプログラミング FAQ」出版)。その後、基幹系業務システム開発SEなどを経て、現在は教育事業(コース開発および講師)・コンサルティングに従事。
Copyright © ITmedia, Inc. All Rights Reserved.