#実例 IT研修の内製の講師と外部の講師の違いを実践例からみつめる

Table of Content

ここしばらくはIT講師案件を請けておりましたが、その中で得た知見で「発注者が受注者に求めるもの」と「受注者が考える、発注者にとって良いもの」の食い違いが浮き彫りになったので、再発防止策はどうすべきか考えました。

発端

「こんなんだったら頼むんじゃなかった」

という言葉を、発注側責任者の方から直接いただく事になったのは初めてでした。
ご依頼いただいたからには当然、一番良いパフォーマンスを出せるように尽力する事は当然です。
現場の私や営業チーム、バックアップメンバーともに最高の仕事をしていました。

しかしながら、クライアントから厳しいご意見をいただいてしまう事はあります。

結果的にはクライアントより上記を撤回していただいて、「とても親身になってご対応いただけて助かりました。またお願いします」と嬉しい声を頂戴する事ができました。
が、過程で残念に感じさせてしまった事は深く反省し、今後策を考えるべきだと私は思っています。

対象読者

  • IT研修を発注するか検討されている企業担当者さま
  • IT研修会社の営業ご担当者さま
  • 研修講師(経験者の方)

今回は講義の仕方が云々〜とか、受講生(今回は法人様の新卒採用者が担当なので、以下新人と呼びます)との距離や付き合い方といった実務的なお話をするつもりはありません。
講義の内容にも改善点はありましたが、今回は講義の内容も良かったとご評価いただいているものとします。(そして、実際に講義自体へのフィードバックは良いものでした)

営業ご担当者さまへのお願い

外部講師をフリーランスで募る際は、運営理念や思い(研修方針)をお伝えいただいていると思いますが、可能であれば成約に至った経緯もご展開いただきたいです。
フリーランスとして受注している立場ですと、本契約に至った経緯を知らないと発注側と認識の相違が生じやすく、また研修方針について契約時の状況を知らない事には、クライアントへの対応を誤る恐れがあります。
当然ですが、基本的には発注責任者→外部講師への直接的な要請はできませんが、講師によっては業務円滑化のために一部黙認している事があります。
ないとは思いますが、外部講師のアテンドが終わったら研修会場のトラブルは発注責任者←→講師で解決させるような運用はご容赦ください。。
(残念ながら、こういった対応をされていた営業ご担当者さまがいます。)

(発注を検討されている方向け)前提知識

研修会社のパッケージには、大きくオープン研修と専門研修の2つがあります。

  • オープン研修
    • 研修の人数が少ない時に他社も交えて一つのクラス(10名〜)を作って指導する研修会場を想定しております。
  • 専門研修
    • 研修の人数が多い場合は、1社(またはグループ会社)しか存在しない状態でクラスを作って指導する研修会場を想定しています。
スタイル 人数/社 アピールポイント メリット デメリット
オープン研修 少ない 他社も交えて研修するため、会社を超えた関係づくりが可能 コストを抑えられる 研修内容が委託業社に一任され、要望を出しにくい
専門研修 多い 社内メンバーが研修の様子を確認しやすい 1. 研修内容を相談しやすい
2. 研修会場を指定できる
カスタマイズできる内容に見解の相違や思い違いが多い

運用の傾向として、オープン会場は技術力の向上を目的にされる事が多く、1〜3ヶ月の技術研修を経て実務研修を施す事が多いです。
専門研修は、カスタマイズできる幅が広い事から「技術研修をしながら実務指導も行う」事が可能です。

本当に必要だったもの

身も蓋もなく言えばコミュニケーションエラーです。教育事業に双方が携わっているはずなのに、見解の相違のため起こった問題と言えます。
外部講師が未経験なのは論外ですが、内製講師が不在だった場合に今回のような問題が防げたのか?というのがポイントになります。

視点 要望 課題 原因 実対応 結果 すべきだったこと
外部講師(受注側) 新人が社会人として、エンジニアとして自走できるようにする 発注責任者(今回は内製講師)と新人に積極的な講義参加を促せていない 発注側責任者との具体的な研修の進め方や講義方針の認識が一致していない 講義日誌を展開(to責任者)、研修日報や研修時間に質問や講義振り返りの時間を設ける(to新人) 実務研修はそこそこに、実践力のキャッチアップと定性評価を発注側への展開 教材の概要を箇条書きで共有し、フィードバックをいただく
内製講師(発注側) 新人が新しい業務・プロジェクト発足時にも対応できるスキルを得ること 依頼に対して得た成果として、新人が実務で対応できるレベルのスキルを習得できていないように感じられる。 外部講師との連携がうまくいっていない 毎週定期ミーティングを実施(to新人、to受託社) 実感として、自分で指導した方が良かったように感じた 指導方針や要望を棚卸しし、外部講師に引き継ぐ

参考ということで、発注側が意識しておいた方が良かった点を書き含めましたが、発注側がエンジニアではない(教育・人材開発・人事部など)であるケースもありますので、これらの方は現場業務あるいはパッケージの技術・開発要件を棚卸ししていただけるだけで効果が見られると思われます。

実例から見る、教育傾向による研修の仕上がり

法人の新卒の社会人・IT研修を想定しています。

  • ご担当者さま属性: 非エンジニア
  • 人数: 20名前後
  • 配属先: 設計開発部
  • サブ講師: なし

研修の考え方について、以下の差があります。

現場(知識)を優先

内製のパッケージをお持ちの場合は、技術力<業務知識であることが多いため、外部研修の効果はあまり高くない傾向があるように思われます。
とはいえ、ご依頼いただく背景としては現場エンジニアの研修・指導スキルが低いか人数が多いため教えきれないというものがあります。
もしご担当者さまがエンジニアであれば、直接ご指導いただいたほうが効果が高くなりやすいです。
チーム内で1名か2名を4~6月までを指導期間に充てて、7~3月までを業務期間としていただいてスケジューリングができることが理想です。
最初の1回だけ教材選定で試行錯誤するので負荷が非常に大きくなりますが、一週間ぐらい読み込んで不足分を補足資料で対応する、というのが最もコストパフォーマンスが高い方法です。

問題は、技術レベルは当然としてコミュニケーションもかなりレベルの高いスキルを求められる上に進んで指導したがるエンジニアがいるかどうか、社内調整がとても大変である事は言うまでもありません…。

実力(応用)を優先

まずはじめに、座学で詰め込むやり方と実習をする方法と2種類があります。
多くのスクール事業で座学→演習問題、最後に総合演習としているケースが多いように思いますが、座学→演習のリズムが少なくとも一週間以上続いていると、途中でコケた時または理解が浅いながらも講義だけは進んでしまい、結果として新人の理解度が低かったり外部研修の評価値が低くなってしまう事が多いです。
講師の裁量が大きくなればなるほど、こういった問題に講師(現場)で解決する事ができますが、カリキュラムをガチガチに組みすぎると、知識優先型の講義になる傾向が高いです。

具体的に言えば、座学→演習のリズム自体は良いのですが、どこかしらのタイミングで区切って総合演習(個人orチーム)と、総合演習の模範解答との比較と解説の時間を手厚く入れた方が理解度が高まる傾向にあります。
特に実務に近いチーム演習を実施する場合は、講師をSE/PMとしてチーム全員(特に苦手意識を持っている新人)をメインPGにして(これは講師から任命しないとうまくいかないです)、どうやって実装できるかをチーム全員で相談していくように促すようにします。
これは私見ですが「チームメンバーにはそれぞれ何らかのリーダーの肩書を与えて責任感を持ってもらいたい」とご相談いただくクライアントさまが多いのですが、昨今の新人はほぼ全員が就活戦争を勝ち抜き、その横または上級生で就活に失敗する人を見ているので研修期間中(入社直後)においては責任感がない方はほぼ見ないです。
また、開発に専念してほしいので肩書制は採用すべきではないと考えています。

ただし、肩書を通じて開発以外にも必要な作業(ドキュメンテーション)がある事を理解してもらうという意味では共感しています。
そのため、総合演習の納品物に設計書などを含め、書き方をそれぞれのチームで考えてドキュメントレビューをチームを超えて実施する事も検討します。

こういった方面に時間を使いたいので、座学→演習の時間が少なくなり、結果として知識量が足りないと感じられる方もいらっしゃいます。
正直、実務にそぐわない(レガシーシステムを運用されているなど)知識を研修で詰め込んで先入観を持ってしまうより、知識面は実務でご対応いただいて長いプロジェクト経験を一ヶ月の短いスパンで仮想的に作って経験してもらう事を目的にしていただいた方が良いでしょう。

おすすめの研修方針

まずは外部講師を入れる前(4月)に実務面やマナー研修を実施していただいて、実力強化演習として外部研修を5,6月に実施するのが最もパフォーマンスが高い方法です。

参考:個人が研修を受けたい場合

個人開発を支援する、という観点であればプログラミングスクールに入っても仕方ないです。
未経験者が実務で個人開発をする事はほとんどないです。今の御時世だとシステムも高度化しすぎて専門性の高いエンジニアでなければ戦力外と言われるようになりました。
特にクラウド環境は一種のパラダイムシフトが発生しており、今まではサーバーの仕組みを知らないとインフラ構築出来なかったのが、AWSやGCPなどそれぞれのサービスやそれぞれの設定を知らないとインフラ構築ができない時代になりました。
つまり、サーバーの仕組み+AWSの2つを勉強しないと行けなくなったので単純にインフラエンジニアのハードルが昔と比べて高くなってしまったんですよね。

同様に、執筆時点では人気のWeb系アプリエンジニアも、どこのスクールでもServiceWorkerについて教えていません。
下手するとデバッグの方法もマニュアル(教材)にないので、実務志向なんてあったもんじゃないです。

シェアする