ごもブロ

都内でWEBディレクター/PMをやってるごもくのブログ。読んだ本から買ったモノ、日常のできごとを自由に書きますよ。ちなみにMBA保持者!

MENU

営業出身ディレクターの僕が新人プログラマーの研修をした時の話

こんにちは!ごもくです。

今日は僕が新卒プログラマーの新人研修をした際のことをお話しします。

数年前の夏から翌年春にかけて、僕は新卒で入社してきたプログラマーの研修を担当していました。その時に気づいた考えやナレッジを共有して、同じような立場の人の役に立てばいいな〜と思います。

なかなかの長文ですが、最後までお読みいただけると幸いですm(_ _)m

f:id:Gomoku:20170517205113j:plain

 

研修担当になるまで

担当したのは男性プログラマーで文系学部(情報系ではない)を卒業したばかりのZくん。

僕が所属しているWEB開発部門はほとんど新卒を採用していません。中途採用がほとんどです。それは会社が純粋な開発会社ではなく、顧客と様々な取引をしている中の一つとしてWEB開発を行っているためです。新人を育てて一人前にするというにはヒト、カネのリソースが足らず、数年かけて一人前にするということができません。

僕が彼の担当になったのは、会社の研修を終えた後の現場研修から。春に入社し、夏の手前まで会社の全体研修があり、その時にもプログラミング研修を行っています

プログラミングの基礎は一通り教えているはずでしたが、期待した成長のレベルに達しておらず、これ以上の成長をどうするかわからない状態の中で私のところに担当が回ってきました。

話を聞いたところPHPの基礎的な内容はある程度理解できているものの、項目数が増えたり、複雑な処理を行ったりする場合にはきちんと処理ができていませんでした。

そうした状況で可能な限り早く成長してもらい、すぐにでも戦力となるプログラマーになることが求められました。

研修の立て直しと計画立案

さて、それには教育ROIを最大にしなければなりません。ROI(Return On Investment)とはファイナンスや新規事業立ち上げ・評価など様々な場面で使われる指標です。

教育ROI=Zくんのアウトプット÷(メンター2名の人日+Zくんの人日)*100

  • 結果が0の場合=Zくんのアウトプットとコストが同じ
  • 結果が1以上の場合=アウトプットがコストを上回る
  • 結果が0以下の場合=アウトプットがコストを下回る

難しく書いていますが、結局はメンターとZくんの時間(コスト)に対して、どれだけのアウトプット(利益)があったかどうかなのです。

つまり、費用対効果のことなんですね。

そのため選択肢は2つ。とにかく先行投資を行いZくんに早く成長してもらってアウトプットを高めるか、我々メンター陣の使う時間を少なくすること、の2つです。そして議論した結果、部内にてZくんにいち早く成長してもらうということで合意しました。

それは我々に過去の新人教育のナレッジが少なく、この状態でメンター2名の時間を少なくすることはZくんの成長そのものを阻害し、新人教育の長期化が懸念されたためです。

これは現時点で多量の資源を投下しても後から回収できればいいという判断で、私もそれに合意したのですが、自分とAさんの仕事量は減らないので、今振り返ってみると結構きつかったんですけどね...。

教育体制の構築

これまで僕は新人研修を担当したこともありましたが、それらは社会人一般の常識や心構えといった内容が多く、専門職に対するアプローチは経験がありません。

そこで協力を仰いだのがZくんと年齢の近かったAさんです。

Aさんは中途入社だったものの、前職でPHPを使ったECサイトの構築・運用を経験しており、プログラマー1年目〜2年目に必要なスキルを教育できる人でした。

そして、そうしたスキルセットに加えて、Aさんには何よりもコミュニケーション能力があったのです。

コミュニケーション能力は非常に曖昧な言葉で一概にコレと定義できるわけではないのですが、僕が考えるコミュニケーション能力は

  • ロジックで話ができるか(因果関係に妥当性があるか)
  • 適切な言語表現ができるか(多種多様なボキャブラリーを持っているか)
  • 専門知識があるか(今回の場合はプログラミング)

の3点に集約されます。

企業内でのコミュニケーションであれば、4点目としてその会社のカルチャーにフィットしている、ビジョンを理解しているということが挙げられるかもしれません。

ちなみに、プログラマーAさんひとりがメンターとならなかった理由として、研修の計画立案やスケジューリングなどをする人間、必要に応じて上司に成果報告を人間がいる必要があったためです。

ヒアリング

研修体制が決まったら、Zくんから今まで何を学んで、自分が何ができるのかについてのヒアリングを行いました。

過去の研修については日報を元にして振り返りをしてもらい、今まで作ってきた成果物に関してはAさんの方でチェックしてもらうことにします。

その結果わかったことは、Zくんは2点に課題があるということがわかりました。

  • プログラミングへの理解不足:論理的に考えてコードを記述することができず、そのため複雑な処理の対応ができない
  • 業務イメージがついていない:仕様理解の段階でなんらかの欠落があり、成果物がどのように稼働するかがわからない

そのため、研修に関しては、業務一般理解+社会人として必要な考え方を学ぶことと、プログラミングの専門性向上の 2つを柱に進めることにしました。いわゆるT字型とか三角型の研修と言われるようなやり方ですね。

僕はその中で業務理解と社会人としての能力底上げを担当しました。

f:id:Gomoku:20170514093831p:plain

研修方針の策定

さて、ヒアリングと大方針を掲げた後、詳細計画を作ることにしました。ちなみにこの研修計画はとても重要です。内容もそうですが、研修計画を立てること自体にも意味があります

Zくんがどのような研修をしているかについては、一部のプログラマーの中で共有されていたものの、全体で共有されておらず、ある意味でブラックボックスとなっていました。そこで、Zくん本人とメンター2名、そして上長と共有することで、Zくんの成長を見える化・管理する必要があったのです。

そしてドロップアウトを防ぐためでもあります。

以前に「できる社員はやり過ごす」の記事でも取り上げましたが、先行きの見えない研修は対象者を不安にさせ、もうこの会社では伸びないなと感じる時に会社を退社してしまいます。新卒社員に長く所属してもらえるための努力も求められていました。

さて、 ヒアリングや面談を繰り返し、研修を決定することにしました。その研修方針は自分で学び、自分で成長できる人にするです。あまりにも普通に思われるかもしれません。ただ、それができていない人がいるのも事実です。指示待ちの人間にはなって欲しくない。基本的なことで、普通のことですが、これは社会人1年目や2年目に教えておかないと、あとでとんでもない間違いになってしまう可能性がある最重要項目です。

一方で、この目標の裏には問題解決を自分でできるようになる人になるという意味も込められています。ゴールと自分自身の現在地のギャップをきちんと見定め、そこに向かってトライ&エラーを繰り返せる人になってほしいと思いったのです。

実際にやったこと 

実際の研修内容は以下のようになります。最初からこの全てを行ったわけではなく、都度PDCAを回して最終的にはこの形に仕上げました。

以下の表の「業務理解」と「一般事務」が三角形の横の広がりで、プログラムが専門性を深めるための三角形の縦の広がりです。

f:id:Gomoku:20170514113226p:plain

KPIとPDCAサイクルの設定 

今回の施策については数値化が難しく、KPIに関してはほぼ定性的なものになりました。

ですので、KPIというよりもチェックリストに近い形になっています。その際に参考にしたのは厚生労働省が定めているモデル評価シートでした。このモデルシートはプログラマーに必要な能力がチェックリストとして定められており、業界標準がない中で非常に参考になりました。

PDCAサイクルに関しては週1回の課会、後に述べる月1回の面談にて管理していました。これについては後ほど詳述します。

業務理解

部署目標からの落とし込みやZくんの貢献点については面談初回に設定したため、継続的に行ったのは運用状況の理解です。

顧客との打ち合わせには2〜3度参加してもらっていましたが、社内部署との打ち合わせには積極的に参加し、どういった打ち合わせが行われているのか、今この場で何が決められているのかを理解してもらうようにしました。

一方、面談について、他社さんの新卒研修・インターンなどの資料を読ませていただくと、週に1度の頻度で一対一面談を行っているという記事がたくさんありました。

ただ、僕が所属している企業はワンフロアに全ての開発者がいるようになっており、会話についても比較的行いやすい状況になっています。週に1度の課会でも報告は上がっており、必要に応じて3人で食事などもしていたので、がっつりとした一対一の面談は月1回程度としました。

面談ではその月のフィードバックと、成果物のレビューをAさんから、以下に記述するビジネスケーススタディを行いました。もちろん目標の共有やKPIのチェックなども行いました。

一般事務

一般事務に関しては、ワード・エクセルの使い方をマスターするための議事録作成や資料作成をアサインしました。

一般に、議事録の作成はとりあえず新人がやるものとして理解されています。私が彼に議事録作成をアサインしたのは、課内にどのようなタスクがあり、誰が、何を、いつまでにやらなければいけないかというプロジェクトの全体像を理解してもらうためでした。

加えて、後から見返して伝わる一般文書を作るという意味もあります。一般文書でもプログラミングのコードでも、後から見直して意味が理解できなければ作るだけ無駄です。

議事録は作り終わったら僕がレビューをし、わかりやすくなるために文書や体裁の修正をフィードバックしました。

また、各業務を遂行する前にどういったプランで行うかを口頭ベースで確認しました。タスクの分解を行い、どれだけ業務理解しているかを確認するためです。

そして、企業に所属する社会人としての一般的な感覚を養うためにMBAで使われているビジネスケーススタディの方法を導入しました。

ケーススタディトヨタやローソン、ホンダなど国内外様々な企業の概要をまとめた16ページ〜20ページ程度の資料を使って自分が経営者であるなら、会社をどう運営するのかを考えディスカッションするものです。判例を読んで議論をするロースクールと同じですね。

ケースに関しては、慶應大学、一橋大学早稲田大学や日本語版ハーバードビジネスレビューなどから入手しました。

ここでの狙いは経営者感覚を養うというよりも、フレームワークMECEの理解です。ケースから読み取れることを都度抜き出して教えたフレームワークに落とし込んでもらい、その企業の分析と、それに対するアクションを考えてもらうようにしました。

フレームワークを利用することによって分析に抜け漏れがなくなり、そこから自分ならこうするという提案を考えることで語彙力をつけるとともに、ロジカルシンキングの力や目標を分解して段取りを作る力を養います。

プログラミング研修

プログラミング研修に関しては、そのほとんどをAさんに任せていました。自分の専門外のことを教えられるのがダブルメンター制度の利点であると思います。

ただし、仕様伝達時の理解度レベルの確認や進捗に関してはディレクター側にて管理しており、様々な報・連・相を常時受けるようにしました。「今忙しいからあとで」ということを極力少なくなるようにしたのです。

インテルのCEOであるアンドリュー・グローブも「HIGH OUTPUT MANAGEMENT」の中で、部下がふたりきりで相談があると言ったら、どんなに急ぎの仕事でもそれを後回しにして部下のために時間を作れと述べています。

同書内では、部下が辞めたいと言い出した状況を想定しているのですが、僕はこれを報・連・相の時点でも行うようにしました。僕自身が彼の仕事の障害になるというのは本末転倒ですし、何よりも彼のやりやすい環境を作ってあげることが僕の仕事だからです。

リバースメンタリングの実践

さて、そうしたZくんですが、スケジュールに遅れが目立つようになり、施策を見直すことになりました。スケジュール遅延の原因はプログラミングに関する理解度によるものが大きく、その点をテコ入れをする必要がありました。

Aさんによれば、同じ箇所でつまづくことが多く、何度も同じ内容でAさんのところに質問に来ていたようです。

Zくんには面談で聞いてみたのですが、要領を得る回答はもらえず、こちらである程度の仮説を立ててそれを検証していくしかありませんでした。

そして、Zくんに教えた内容を、きちんと定着してもらうためにはアウトプットしかないという結論に達しました。それはコードを何千行と書く写経ではなく、教育者になってもらったのです。いわゆるリバースメンタリングです。

リバースメンタリングは部下から上司への教育という意味を持ちます。元々は米GE社で若手社員が上司にインターネットを教えるというところからスタートしています。その狙いは、企業にいて広い視野を持てなくなった上司が、感覚が鋭敏な部下から最先端の内容を教えてもらう点にあります。

例えば、新卒の子達に影響のあるインスタグラマーやスマホアプリの利用状況を上司が教えてもらうというのもリバースメンタリングの一種です。

僕が行ったリバースメンタリングは厳密にはGEと同じ方式ではないのですが、新卒社員のインプットにもこのリバースメンタリングは非常に効果的だと感じています。

自分自身がきちんと理解できていないと他人に伝えることはできない、とよく言います。リバースメンタリングはその一助となり、かつ前述したコミュニケーション能力3つの要素を全て使う内容なのです。

メンタリングの対象者は僕です。幸い(?)なことに、僕はディレクターといっても営業出身であるためプログラミングやWEB技術に関してはかなり疎いです。なんで僕がディレクターをやっているのかと、自分も周囲も不思議に思うくらいです。実際にコードを書いたこともありません。

そこで、社会人一般の基礎的な内容に関しては僕からZくんへのメンタリングとし、プログラミングに関してはZくんから僕へのリバースメンタリング方式にしました。 彼にプログラミングの知識が定着するとともに、僕が技術的な内容への理解を深めることによって、より技術者と話しやすくするという狙いもありました。

「Zくんが2年目になった時に1年目に対するメンターとして立ってもらえば、同じ効果が得られるのでは?」と考える方もいらっしゃると思います。これはおっしゃる通りです。ただ、自社の場合には新卒が定期的に入ってくる環境ではなく、次の新卒がいつ入ってくるかわかりません。

そうした状況にあって同じような状況を再現するためには、このようなリバースメンタリングの方法が最適だと判断しました。

研修以外で担当してもらったこと

また、Zくんには研修の内容以外にも部署内で様々なことを担当してもらいました。

飲み会の幹事

こちらもありがちですが、段取りの重要性を理解してもらうために依頼しました。外部ツール(調整さんなど)を利用してもOKで、会社から近場で選ぶことを条件にしました。学生の時にもやっているので、ここはスムーズですね。

飲み会に来ない人のためのランチミーティングの幹事

こちらは飲み会に来ない人のためのランチミーティングです。ピザなどを用意して会社の大きめの会議室で行いました。オフショアでお願いしている東南アジアの地点もスカイプで繋いで関係部署全体がコミュニケーションできるようにしました。

飲み会の幹事の時にもそうですが、雑用をやらされているという気持ちを可能な限りなくすことに注意しています。

僕が新卒のころを思い返すと、緩めのペースで仕事が進み、そして雑用を多くされていた時に自分は雑用しかできないくらいのスキルなんだと思いがちになっていたので、可能な限り彼の自尊心や自己効用感を引き出しました。

単純にいうと自信をつけてあげて仕事や会社への心理的障壁を下げるための業務です。

社外勉強会への参加

早めに退社してもらい、他社さんでやっている勉強会にも参加してもらいました。

勉強会参加の理由として、技術トレンドやビジネストレンドの教育については自社内で完結することは難しく、他社さんの先端事例を学んでもらうことで、自社内で教育できないことを学んでもらうきっかけにしたかったためです。

プログラミング関連からWEBビジネス、広告など、WEBに関係して興味のある勉強会には積極的に顔を出してもらうようにしました。社外で友人もでき、美味しいご飯も食べられるので、本人自身はとても満足していたようです。

主催の企業様ありがとうございます!

結果

私が行った施策は以上です。

その後、彼はいくつかの成果物を納品し、戦力として数えられるまでになりました。

初期の段階で仕様を細かく詰めていてあげればある程度のことは自分でできるようになり、簡単な仕事についても安心して任せるようになりました。

メンター、メンタリング対象者という関係も終わり、今では純粋にディレクターとプログラマーという関係になっています。

 

今回、様々な施策を行って僕が学んだことは、心理的安全の確保でした

心理的安全に関してはninjinkunさんのブログに詳しく書いてあるのですが、チームでなんでも言い合える環境を作り、協働できるような環境を作り上げることです。

Zくんに対して研修している際に、彼が僕に対して「緊張」していることが多々ありました。

それはメンターや研修担当者が入れ替わることで彼自身も何か自分に解決し難い課題があるのではないかと察していたり、スケジュールの遅延が目に見えることで自信がなくなっていったようです。

しかし、そこをなんとか受け止めるために、可能な限り心理的安全を確保するようにしました。

もうベタなことをやるかありませんでした。最近話題になった映画や漫画の話をしたり、昼食も一緒に取るようにしたり、一緒に勉強会に参加したりしました。

数ヶ月経ってからはなんとか彼の方も緊張を解いてきてくれて、普通に話せるようになり、ここまでやってようやくチームの成員としてきちんと迎え入れられたような気持ちになりました

 

以上が僕が行った新人プログラマー研修の全てです。

Zくん自身もモチベーションを高く保っていてくれていますし、このまま次代のエースとなってくれればメンターとして最上の喜びだと思います。

広告を非表示にする