何故教えるのか、何を教えるのか、どうやって教えるのか 〜 「新入社員研修の作り方〜完全版〜」のプレゼンを実況中継風に再現 #nds57
で次のように予告していました。
私の発表です。前職で行った新入社員研修をどう作っていくかについて、動機や課題を聴衆と共有しつつ、その手法や対策などについてお話ししました。
このセッションの内容については、実況形式で後日別エントリとしてアップします。
本エントリーでは、予告通り当日発表したスライドとともに、実況中継風にセッションを再現します。
「地方の中小SIerに置ける新入社員研修」を題材としていますが、内容は「いかに教育をデザインするか」に主眼を置いています。どのような分野でも役立つ内容ですので、ぜひご覧ください。
それではどうぞ!
新入社員研修の作り方 〜完全版〜
それでは、「新入社員研修の作り方 〜完全版〜」というタイトルで発表します。よろしくお願いします。
ちなみに「完全版」とあるのは、過去のNDSで2回、LTとしてお話しさせていただいているからです。1
ようやくちゃんとした発表にすることができて、嬉しく思います。
イントロダクション
まず簡単に自己紹介させてもらいます。最近市内のSIer「(株)ジェイマックソフト」から「クラスメソッド(株)」に転職して、今は在宅のフルリモートで働いています。
端的に行って最高です!
あと、先日NDSの公式ポッドキャストNDS FMの第5回に出演させていただきました。2
こちらでも今日お話しするような新入社員研修の話などしていますし、他の回も面白い話がたくさんありますので、ぜひお聞きください!
セッションの内容を始める前に、みなさんにお願いです。このセッションに限らず、ぜひ何らかの形でフィードバックをお願いします。それは良いことでも悪いことでも構いません。
「好きの反対は無関心」とも言われるように、反応が何もないことが一番寂しいです。ぜひ#nds57とつけてつぶやいたり、「懇親会で僕と握手!」していただいたり、blogやQiita、Facebookに書いたりしてください。お願いします。
それでは、今回の話に入っていきましょう。「前職のSIerで教育担当となった後、新入社員研修をどのように作って言いったのか」についてお話しようと思います。
ちなみに、今回するお話はSIerだけでなく一般的に通用するものだと思っています。新入社員の教育担当となったのは数年前ですが、それからこれまで改善しながらやってきたことのエッセンスをお伝えできればと思います。
Agendaは次の通りです。
何故教えるのか
まず、「何故教えるのか」です。新入社員研修がどうして必要なのか、その背景と動機を最初にみなさんと共有したいと思います。
そもそも、新卒社員とはどういう人たちでしょうか?教育を施すためには、彼らについて知らなければなりませんよね。
そこで、彼らが就職する組織の選び方に注目しましょう。ここで大事なのは、いわゆる「都会」と「地方」ではその選び方がまったく違うということです。
都会では選択肢が多いこともあり、主に「この業種で働きたい!」「この組織で働きたい!」というのが強い動機になります。それに対して、地方では「この地域で働きたい!」という気持ちが強いと感じています。3
その結果「新卒が入社時に持っていると期待できるスキル・知識」の違いが如実に現れます。
都会では「業種」や「組織」に対する思いで組織を選ぶため、その組織で働くために最低限必要なスキル・知識を持っていなければ、そもそも採用されません。
それに対して地方では、「地域」に対する思いで組織を選びます。例えば「この地域にある組織のうち、デスクワークでそこそこ給料が良いところ」といった感じです。その結果どうなるかというと、前職のような企業を選んで応募しますが、大半が初心者として採用されます。
そして、都会と地方の圧倒的な母数の違いもあり、地方では自分の組織を選んでくれる人材が希少なリソースになります。そのため、初心者でもしっかり育てていかないと、必要な人材が確保できません。
賛否両論あるとは思いますが、これが地方の現実です。ここから目をそらしてはいけません。
「何故教えるのか」についてまとめると、この地域で働こうという希少なリソースである人材を育てることが、その組織のためだけでなく、結果的に地域の力になるということです。
ですので、使い潰すのではなく、ちゃんと育ててあげたいと私は考えています。
何を目的にするのか
何故教えるのかという背景が共有できたところで、今度は「何を目的として」教えるのかについて考えていきましょう。
それには、新入社員に今後どのようなことを期待するのか考えるのが近道です。
私が考えたのは次の3つです。実務に入って最初の業務で成果を出すこと、数年後には中核メンバーとしてバリバリ働いてもらうこと、そしてゆくゆくは自分の経験を元に後輩を教え、導いてもらうことです。
このことから、新入社員研修の目的が見えてきます。
まず、最初の業務に必要な「最低限の知識・スキル」を身に付けること。次に、研修の後も「自ら学んで成長」して行けるように、学び方を身に付けること。最後に、評価や更新の教育のため、自らの「成果を伝えられる」ようになること。この3つです。
何を教えるのか
何故教育が必要で、どのような目的で行うのかがわかったところで、今度は実際に「何を教えるのか」を考えていきましょう。
先ほど「目的」のところでも触れましたが、それは一言で言えば「業務遂行のために必要となるスキル・知識」です。
しかし、言葉にすれる簡単なようですが、実際その「スキル」と「知識」はどうやって見出せば良いのでしょうか?
そのヒントとなるツールが職務記述書(Job description)です。
簡単に説明すると、先ほど述べた「業務遂行に必要なスキル・知識」を詳細に記述し、明文化したものと言えます。4
次に疑問となるのは、そのようなツールである「職務記述書」をどうやって作れば良いかということです。これは、ちゃんとやるには本当に手間がかかるのですが、とりあえずということであれば、@liliputさんという方がblogにまとめてくださっている方法が良いでしょう。5
ざっくりと説明すると、まずステークホルダー全員に集まってもらって、業務に必要だと思うスキル・知識を付箋にガーッと書き出してもらいます。そして次に、その付箋の内容をカテゴリー別に分けたり、ダブりを無くしたり、大きいものを分割したりして整理するという方法です。詳しくはぜひこのblogエントリを読んでみてください。
この方法を参考に、前職では各事業所の教育担当者やPC管理をやっているような有識者にアンケートを実施して、職務記述書を作成しました。その項目の一例を挙げるとこんな感じになります。
日本語の読み書きから始まり、文章作成の基本、PC操作、プログラミング、テスト、設計、…という感じで、まだまだ続きます。
で、ご覧の通り「超多い!」んですね。当たり前なのですが、普段当たり前にやっているようなことでも、それを言語化して明記しようとすると、こんな感じになります。
もちろん、こんなにたくさんのことを教えるのは無理がありますから、新入社員研修で教えるべき範囲を絞り込まないといけません。
絞り込む基準としては、先ほどから何度か言っていますが「最初の業務に必要なスキル」に着目します。例えば、「顧客の業務を理解して要件に落とし込む」なんてスキルは、新入社員に当然求めるスキルではないので省けます。
こうやって、職務記述書の項目から、新入社員研修に収まらない部分をどんどん枝切りしています。切り落とした枝については、放っておくのではなく、中途教育やOJT(On the Job Training)でカバーしましょう。
そうして枝切りするとこんな感じになります。
「OOP原則」や「業務を要件に落とし込む」といった、新入社員には荷が重いものを切り落としてみました。
とはいえ、それでもまだまだ多いです……
ここまでをまとめると、とにかく教えるべきことは多いんです。それをいかに絞り込むかが大事なんですが、それ以上に「教えるべきことがたくさんある」ということを、教育側は大前提として理解しておく必要があります。
特に昨今は技術やビジネスの進歩のスピードが早いので、全部教えることなんて到底できません。それでも、必要なものを絞りつつ、なるべく多くのことをしっかりと教えなければならないということは、改めて肝に命じておきましょう。
どうやって教えるのか
さて、何を教えるかがこれで決まりました。今度はそれらのことをどうやって教えるかについて考えましょう。
「何を教えるのか」で話した通り、教えるべきことは非常にたくさんあります。したがって、限られた時間でそれらを教えるためには、行き当たりばったりに教えるのではなく何らかの戦略が必要になります。
教育のデザイン
これは、言い換えれば「教育をデザインする」ことと言えます。そのためのツールがインストラクショナルデザインです。6
インストラクショナルデザインは「教えることの科学と技術」とあるように、「教えること」を科学的に捉え、いかに効率的に再現性のある手法に落とし込むかを研究した学問です。
人は有史から技術と知識を、世代を超えて受け継いできました。したがって、インストラクショナルデザインにも見られるように、教えるための体系だてられた手法が、すでに存在しています。
このような高速道路があるということをまずは認識しましょう。そして、教える立場としては、それを利用しない手はありませんよね。
ではその高速道路はどうやって使えばよいでしょうか。それには、先人に学ぶのが一番です。例えば、長岡出身の連合艦隊司令長官「山本五十六」は、こんな有名な言葉を残しています。7
やってみせ、言って聞かせて、させてみせ、 ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、 任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、 信頼せねば、人は実らず。
ご覧のように「やってみせ」から始まっていますね。
他にも、慶應義塾大学の「井庭 崇先生」がまとめたラーニング・パターンにも、No.5に「『まねぶ』ことから」というパターンがあります。8
つまり、まずはやって見せることが何よりも大事だということです。
ニワトリなんかのヒナが生まれて最初に見たものを母親だと思い込むように、新入社員も最初に変なものを見たらそれが正解だと思ってしまいます。
そうならないよう、最初に課題を与えていきなり取り組ませるより、先に「どうやって問題に取り組めばよいのか」の良い例を最初に見せることで、変な癖をつけさせないのが重要です。
そして、「やってみせ」の後に「させて」みた成果物については、徹底的にレビューをしてあげましょう。
ここでしっかりとコストをかけないと、実務に入ってから変な成果物を生み出されてしまいます。そうなると、時間も制約もある中で、他の社員の時間も奪ってしまうことにより、余計にコストがかさんでしまいます。それに比べれば、ある程度「失敗すること」が織り込んである研修のうちにコストをかける方が、よっぽどマシですよね。
そして、このレビューの際に気をつけて欲しいのが、しっかりと褒めることです。レビューをするときは、つい悪いところに目が行ってしまいがちですが、ひたすら指摘されるばかりだと気持ちがいいものではありませんよね。そうならならないように、良いところはちゃんと褒めてあげましょう。
また、良いところが見つからなくても、まずは認めるだけでも違います。変なところがあったら、最初にそう考えた理由を聞いて「認めて」あげる。その上で、「直した方がいい理由と解決手段」を必ずセットで教えてあげてください。
教育という場面ではどうしても「教育担当者」と「新入社員」の間に上下関係のようなものができてしまいます。この時、上から下にただ指摘をするだけでは、不条理を押し付けることになり、精神的なプレッシャーを与えてしまいます。
なお、教育でなく議論を目的とする時ならば、「対案なき指摘」に意味がある場面もあります。しかし、教育というコンテクストでは、議論ではなく教えることが目的なので、それを省くことに意味はありません
どんな手段で教えるか
さて、やって見せることから始めてレビューをしっかりするのが大事ということがわかりましたが、今度はどんな手段で教えれば良いかについて考えましょう。
前職では、主に3つの手段を目的別に使い分けていました。
「講習」は、半日〜1日程度の時間を使って、講師の経験を元に対象領域全体のさわりを教えるために行いました。具体的には、マナー講習やテストのやり方などでこの方法を使いました。
「座学」は書籍や独自に書き下ろしたテキストなどを使い、体系的な知識を学ばせる目的で使いました。これは、文章作成の基本やツールの概念説明、プログラミング、ネットワーク、データベースなど、あらゆるもので使いました。
そして「実習」は、実践を通じて座学で学んだ知識をスキルに昇華させ、活きた問題への対処方法を身につけるために行いました。例えば、テスト設計やプログラミングなどでこの方法を使いました。
この中で、座学にある「独自テキスト」について、詳しくお話ししましょう。
そもそも、なぜそんな面倒なことをしたのかと思うでしょう。その理由の一番大きなものは
ちょうどいいものがない
からです。
既存の書籍やWeb記事などのテキストは、学ばせたいことに対して網羅的すぎたり、分量が多すぎたりと、余計なことがたくさん書かれています。
例えば、ネットワークの知識を教えたいと思っても、ネットワークエンジニアでもなければ、「OSI 7階層」や「IPアドレスとポートってものがあってね」くらいで良いわけです。でも、既存のテキストでは「TCPというプロトコルがあって、そのパケットの構造はこうです」みたいに詳細な部分まで書いてあるので、新入社員にいきなり読ませるには向いていないんです。
ですので、基本的なプロトコルと、ネットワークのトラブルシューティングに使えるpingコマンドなどの使い方を、さらっと学べるテキストを自分で書くしかないわけです。
そんなモチベーションで書いたテキストを、書いた理由と一緒に紹介します。
テキスト名 | 書いた理由 |
---|---|
VCS入門 | VCSの触りをさっと学べる書籍がなかった |
Subversion入門 for Windows | SVNの操作を視覚的に学べるテキストがなかった |
GUIプログラミング入門 for Windows Forms | GUIアプリを依存関係、PDSなどを意識しながら作成する方法を学べるテキストがなかった |
DBプログラミング入門 by ODP.NET | SQLコマンド発行やトランザクション管理、O/Rマッパーの使い方をまとめて学べるテキストがなかった |
バッチプログラミング入門 by C# | コンソールアプリの作り方を体系的に学べるテキストがなかった |
車窓からのTDD by C# | IDEを活用しながらTDDの基本を学べるテキストがなかった |
Windowsフォームによる業務プログラミングチュートリアル | ある程度の規模を持つ業務システムを作成する際に意識すべきことを学べるテキストがなかった |
システム開発者のためのネットワーク入門 | ネットワークの概念と基本的なネットワークコマンドの使い方を学べるテキストがなかった |
どんな順番で教えるか
こういった手段を使い分けながら研修を進めていくわけですが、今度は「どんな順番で教えていけば良いか」で悩むことになります。その答えは「研修後に従事する業務の成果に近い方から」です。どういうことなのか、詳しく見ていきましょう。
ここでは、馴染みのある方も多い「ウォーターフォール・プロセス」で説明します。もちろん、他の開発プロセスでも、考え方は一緒です。
前職の場合、開発プロセスは大きくこの7つのフェーズに区切られていました。9
- 基本設計
- 概要設計
- 詳細設計
- プログラミング(製造)
- 単体テスト
- 結合テスト
- 総合テスト
そして、「1. 基本設計」「2. 概要設計」「3. 詳細設計」に対応するテストが、それぞれ「7. 総合テスト」「6. 結合テスト」「5. 単体テスト」になります。
これらのフェーズのうち、新入社員が研修を終えて最初に担当するのは、だいたい「4. プログラミング」と「5. 単体テスト」ですので、この2つのフェーズを詳しく見てみましょう。
この2つのうち、「成果」つまりシステムの出荷により近いフェーズは「5. 単体テスト」です。ですので、ここの作業に必要なスキル・知識から教えていきます。
例えば、「5. 単体テスト」フェーズで最初に行うのは「単体テスト設計」で、この作業に必要なスキルを順番にあげると次のようになります。
- 設計文書を書くのに必要な「文章作成法」
- 仕様理解や設計者とのやりとりに必要な「コミュニケーションスキル」
- 成果物の管理に必要な「VCSの概念・使い方」
- 単体テスト設計に必要な「テスト技法」
その次に「単体テスト実施」を行います。こちらに必要なスキルは次のとおりです。
- 単体テスト実施に必要なドキュメントの書き方
- 検出した障害について過不足なく伝えるための障害票の書き方
- ...
このような感じで、単体テストに必要な教育を進めていきます。
なお、最初に単体テスト設計・実施を学ばせる課題では「詳細設計書とあらかじめバグを仕込んだBMI計算機アプリを渡し、テスト設計、実施で事前に想定したバグを検出させる」というものを行いました。これによって、単体テスト設計・実施に集中して基本を教えることができます。
それが終わると、今度は「4. プログラミング」フェーズに必要なスキル・知識の教育に移ります。ここで初めてプログラミング言語や構造化定理、リーダブルコード、ネットワーク、データベースといったものが登場します。
では、どうして成果に近いところから教えることにしたのでしょうか。それは大きく2つの理由からです。
1つは最初に取り組むステップが小さくなるからです。ステップが小さければ小さいほど、すぐに課題の成果が得られるため、達成感を得やすくなります。また、フィードバックサイクルが小さくなるので、それに応じて指摘事項を直すコストも小さくなり、負担になりにくいです。
もう1つは、汎用的な知識・スキルから始められるからです。なんでもそうなのですが、専門的な知識はそれを理解できる土台があることで、初めて理解できるようになるものです。ですので、土台である「論理的思考力」「文章作成力」といった汎用的な知識・スキルを先に教えるためには、成果に近いところから始めると都合が良いのです。
こうやって、順番に教えていきますが、大事なことが1つあります。それは
一度に取り組むことを1つだけにする
ことです。
人間は複数のことを一度に取り組むようにはできていません。ましてや、これから仕事を覚えようとする新入社員ができるはずはありません。
ですので、なるべく個々の課題に集中して取り組める環境を作るよう努力しました。例えば、座学と実習が並行しないように全ての課題が直列になったスケジュールを組んだり、先ほど言ったような「テストはテストだけ」というように課題を考えたりしました。
さて、ここでどうやって教えるのかについて、まとめておきます。
まず、効率の良い教え方は先人に学びましょう。そのとき大事なのは、最初は良いものを見せて「まね」をさせることです。
次に、課題は成果に近いところから始めて、小さなステップで進めましょう。これは、すぐに達成感を味わわせることと、フィードバックをすぐに反できるようにするためです。
最後に、一度に取り組む課題を1つだけにして、各個撃破を目指しましょう。人は複数のことを一度にすることは苦手です。教育では1つ1つに集中して取り組める環境を作りましょう。
研修をふりかえる
これまでに話したような感じで研修を行ってきましたが、今後のためにふりかえりが必要です。新入社員、教育担当それぞれの視点で、研修をどうふりかえったかお話しします。
まず、新入社員です。新入社員のふりかえりは、研修内容の固定化を目的として行います。
1つは「報告」という形でのふりかえりです。各課題を終えたタイミングでの成果の報告を始め、日次、週次、月次での報告を行ってもらいます。成果に対する報告をすることで、課題で行った作業やその結果を自分の中で再構築し、より深い理解へとつなげてもらいます。日次、週次、月次の報告は、研修の進捗状況という定量的なものだけでなく、「体調」「心配事」「不安なこと」などの定性的なものをすくい上げる意味もあります。
そしてもう1つが、研修の最後に行う「研修成果発表」です。教育担当以外の上司、先輩社員の前で、「研修で得たこと・学んだこと」について、プレゼン形式で発表してもらいます。これにより研修全体をおさらいすることができますし、プレゼンテーション術の基本も学ばせることができる一石二鳥の課題なので、非常にオススメです。
今度は教育側の視点でのふりかえりです。こちらは、次年度以降の研修カリキュラムの改善に向けた情報収集が目的です。
1つは研修に関する「アンケート」の実施です。教育を受けた新入社員はもとより、世話役の先輩社員や各事業所の教育担当者、さらには配属グループ長や最初にアサインされたプロジェクトのリーダーまで、幅広く実施します。これによって、各課題の妥当性や課題の洗い出しをするとともに、教育を含む新入社員を受け入れる体制までフィードバックを得られます。特に実務のプロジェクトリーダーのフィードバックは「研修に足りないもの」を知ることができますので、ぜひ実施しましょう。
もう1つは課題に対する予定・実績工数の分析です。これを行うことで、課題の難易度やスケジュールの妥当性を判断する材料になります。ただ、対象となる母集団の数がそんなに多くない(多くても10人程度)なので、あまり統計的な数字に踊らされないようには注意が必要です。また、数年に一度はあり得ない速度で研修を終えたり、その逆に全くついてこれない新入社員が出てくることがあります。こういった人の予実工数については、外れ値として扱うことも重要です。
今後に向けて
最後に、これまで数年間にわたって改善を続けてきた新入社員研修ですが、その中で見えてきた課題についてお話しします。
その課題は大きく3つです。1つは最初に枝切りしたスキル・知識をどう教えるかです。これは中途教育やOJTで行うことになるでしょうが、具体的には考えられていません。
2つ目は研修の進み方にはばらつきがあるので、それをどうするかです。これについては、頑張ってばらつきを抑えるか、開き直って受け入れるかになると思います。
3つ目は教育担当となる社員の偏りをどうするかです。限られた社員しか行えない役割は、その社員がいなくなったら継続できなくなってしまうという「リスク」になります。これについては、教育担当を各事業所で複数人体制にするか、「教育の教育」で担当できる社員を増やすかになるかと思います。
これらの課題への対策ですが、
あとは後任の担当者がなんとかしてくれるはずですので、私は課題の提示だけにとどめておきます。
まとめ
それではまとめに入ります。
まず、何と言っても新入社員研修は非常に大事だということです。これは特に、人というリソースが少ない地方では、よりその重要性が高まると思っています。
ただ、教育には非常にコストがかかるということを理解しておかないといけません。それでも、人への投資は設備に比べればかなり割りが良いと、私は信じています。ですので、人類の歴史で積み重なった「良い教育を施す方法」を学美、教育を行いましょう。それには先人が作った高速道路に学び、活用していきましょう。
そして、行なった教育については必ずふりかえりを行い、継続して改善を続けていかなければなりません。技術や社会情勢の変化に対応していきましょう。
質疑応答
研修期間は?
Q.新人研修期間は?A.3ヶ月半 #nds57
— Yuichi Ohara (@y_ohr) September 29, 2018
研修に使う言語は?
Q.題材言語は?A.色々つまみ食いよりは、一つの言語を掘り下げた方が効果的 #nds57
— Yuichi Ohara (@y_ohr) September 29, 2018
C#の教育をやっておくと、Java(文法が似てる)やhttps://t.co/5WIyaZaTOS(ランタイムが同じ)の学習に繋げやすい。考えたことなかったけど面白い観点だ。 #nds57
— なかざん@技術書典【う76でした】 (@Nkzn) September 29, 2018
今後の課題に対する対応策何か思いつくことある?
- 個人的には「教育の教育」が良いかなと思っている
- 中途教育と兼ねて実施可能
- 「ばらつき」については「受け入れる」のがいいのではないか
- 前後一月くらいなら誤差の範囲だと思う
- その外はそれこそ「外れ値」なので対応コストが見合わない
セッションをふりかえって
このセッションを通じて、私が数年にわたって継続して取り組んできた「新入社員教育」について、その知見を明文化することができました。
途中
題材は教育だけど、これほぼ科学なのでは。#nds57
— Yu Watanabe (@yuw27b) September 29, 2018
このような発言もいただいた通り、「教育」は「科学」という面があります。今回の内容は「地方SIerの新入社員」に対する教育でしたが、ここで得られた知見はどの分野にも応用が可能だと思っています。
今後、このクラスメソッドで教育するような機会があるかもしれません。その時は、このセッションの内容を思い出しつつ、新たに「なぜ教育するのか」からしっかり考え、取り組んでいきたいと思います。
落ち穂拾い
これ、 #nds57 で言い忘れた https://t.co/tO8M4IoOxE
— 白い高野さん (@masaru_b_cl) September 30, 2018
新入社員への接し方として、向こうから相談が来るのを待っているのも一つの手です。しかし、一旦「何がわからないのか、わからない」状況に陥ると、一見悩んでいるようにも見えて実態は何もできていないため、無駄な時間を過ごすことになります。
この時間がなるべく短くなるように、こまめな声がけをするのは大事だと思います。そうすることで、新入社員も自分の状況・問題を言語化しようとするので、その段階で思考が整理され問題が解決してしまうこともよくあります。10
- 第51回&第52回 長岡IT開発者勉強会に参加しました #nds51 #nds52 | be free 、 第41回 長岡IT開発者勉強会に顔出してきた #nds41 | be free ↩
- NDSのポッドキャスト「NDS FM」の第5回に出演しました #ndsfm | Developers.IO ↩
- 「この地域で働かざるを得ない」も広義には「この地域で働きたい」に含みます ↩
- 職務記述書とは - 人材マネジメント用語 Weblio辞書 ↩
- 2時間で書ける!職務記述書の作成方法 - エルの楽園 ↩
- インストラクショナルデザイン ー 教えることの科学と技術 ー ↩
- 山本五十六名言集 | 山本五十六.net ↩
- ラーニング・パターン (Learning Patterns) No.5 「まねぶ」ことから ↩
- この他に要求定義、要件定義などもありますが、今回は省いています。 ↩
- 「テディベア効果」や「ラバーダッキング」として有名です。参考:ポーギーに話す ↩