育成体制について
最近、エンジニア不足の煽りを受けてか、新人エンジニア育成に力を入れることが多くなってきたと感じます。私も過去にIT関連の知識がゼロに近い若手の育成を何度か経験しておりますので、その際に管理者の立場で気をつけている内容をなるべく具体的にまとめて記事したいと思います。同じ組織を管理する立場の方の一助となれば幸いです。
あくまで育成体制の管理に関する記事の為に、メンターの立場での指導方法についてはあまり触れておりません。また本記事は初めて計画的な育成体制を立ち上げる方向けとして記載しております。その為に既に現場にフィットした手法を確立されている方、経験豊富でご自身の手法を確立されている方には本記事は参考にならないかと存じます。
まずは体制の全体像を決定！
開発プロジェクトが発足すると通常は自社のプロジェクト標準に従って開発がスタートしますが、育成に関するプロジェクトについては結構、担当者任せになっているケースは多いのではないでしょうか。
もし、現場に実績のある育成標準が無く、かつ何を開始しようか迷っている方は、まずは立ち上げ、計画、実行＆監視、終結のフェーズに分割して検討することをお勧め致します。そして、次にPMBOKの知識エリア全体像に、育成に関する各カテゴリをあてはめると計画が立てやすくなります。具体的には以下のような育成フローを作成します。
PMBOK知識エリア全体像に当てはめた例
IT業界は幅広いので一概には決められませんが、図の横軸には「立ち上げ」「計画」「監視」「終結」の段階に分割するとある程度フィットします。一方で縦軸の１～５のカテゴリは社内の文化や担当者にあわせて柔軟に取捨選択して、変換していくと良いと思います。
①立ち上げプロセス
①－１ 育成プロジェクト立ち上げ
育成プロジェクトを立ち上げる際には、まず全体計画の概要を決定します。この資料は上長にも提示することになるでしょうから、目標から期限、指導範囲なども記述して資料へまとめておきます。
-
育成する目的と目標の設定
上長から経営戦略に基づいた人材育成の目的や目標が提示されている場合は良いのですが、そのような基準が無い場合、もしくは育成基準が抽象的で不明瞭な場合はとりあえず以下の目標を設定しておくと無難でしょう。- 優先度が高く、頻度の高い社内業務を確実にこなせる（周囲のメンバの負担削減）
- 社会人としての最低限のビジネススキルやマナーを有している（メンバとの協調性）
- エンジニアとして基礎となる必要な技術を有している（企業資産であるスキルの蓄積）
-
指導範囲
指導範囲については現在担当している業務、そしてエンジニアとしてそもそも必要な知識（技術）の２つの軸を考えて決定します。そして、事前に新人の経歴やスキル情報を把握し、育成目的や目標を加味して項目を増減させます。 -
育成期間と育成レベル
大まかな育成期間を設定します。育成は先が読めないので、悩みすぎず以下のようにおおよその計画を立てておきます。
段階１．ITや仕事の基礎を理解し、成長しながら多少の戦力になれる（１年目～２年目）
段階２．なんとか組織の一員として業務を捌くことが出来る（２年目～３年目）
段階３．業務は問題なく担当できて、一部レビューアなどにもなれる（３年目～４年目） -
育成担当の決定
担当は「管理者（自分）」「メンター」そして「新人」で検討します。あまり多くのメンバを介入させると、メンバ同士のコミュニケーションルートが増えて稼働が増加する上に、又聞きによる真偽不明な報告があがる可能性もある為に、基本は少数人数で進めます。
指導者であるメンターの選定は、やはり技術や業務的なノウハウを有している担当者を指名します。これにより正しい知識を新人へ伝えることが出来る他に、新人がその姿勢に感化されて自発的に動く様変化する可能性もあります。もし稼働に余裕があれば、是非そのような人物を割り当てたいところです。
担当者を決めたらRACI図のようにおおよその役割を決めておきます。ここでは表で記載していますが、実際はメンターと簡単なルールの意識合わせだけ行えば良いと思います。
育成分担の例
| 担当者 | 育成状況の管理 | 技術スキル指導 | 業務スキル指導 | 社会人マナー |
|---|---|---|---|---|
| 管理者 | ○ | × | × | ○ |
| メンター | × | ○ | ○ | ○ |
②計画プロセス
②－１ 育成計画書作成
「①－１」で取り決めた内容に従い、具体的な指導方法を決定します。漏れや重複が無いようにメンターだけでなく管理職の行う業務もルール化しておきます。
-
管理職の指導ルールの例
- 社内提出物やセキュリティの指導、社内ルールの遵守については管理職が指導を行う
- 新人の振る舞いにビジネスマナー上で問題がある場合は随時、管理職が指導を行う
- メンターの指導が適切かどうかも、管理職は月に1度レビューの場に同席して確認を行う
-
メンターの指導ルールの例
- 作業を行う前に、事前に新人に対して業務資料を読ませておき、メンターへの質問の用意をさせる
- 新人へレクチャーを行う際、実際の操作をなるべく新人に実践させる
- メンターは指導後にオープンクエスチョンを主とした質問を行い理解度を確認する
- 指導した内容を新人がメモを取り、それらを適切に利用できているか確認を行う
ここは職場に応じてかなり変動する箇所になりますので、職場内の文化や業務内容、メンバに応じて柔軟に決定します。またルールを作成する際は過去の指導役のメンバ、過去の育成対象のメンバにヒアリングを行います。一通りルールが完成したらメンターと意識合わせして正式に決定します。
②－２ 必要スキル計画の作成
ここでは指導する為の必要スキルを抽出します。職場に業務習得リスト等があれば良いのですが、もし何も無い場合は業務必須スキル、エンジニアとして必要なスキルの2つの軸を観点に抽出を行います。このあたりはWBSの作成と同じ要領となります。
業務系スキルの観点・・・日々の業務で使用し、プロジェクトを推進する為のスキル。
技術系スキルの観点・・・エンジニアとして成長していく為に必要となるスキル。
※「①－１」で会社が定めた計画がある場合、それに沿ったスキルを抽出する
2つの観点から必要スキルを抽出しているイメージ図
抽出したスキルを箇条書きにしてまとめ、それぞれの順序性を考慮して並び替えを行い、必要となる習熟スキルリストを作成します。
②－３ 指導スケジュール計画の作成
ここではスケジュールを決定します。②－２で育成に必要なスキルを抜き出したので、そこで作成したリストを元に日数を割り当ててスケジュールを作成します。
ただ、職場によっては正確なスケジュールを立てることが困難となります。例えばSESでの現場では育成対象者のスキルを問わず、一人前に育てる育成期限が一律に定められているケースもあり、一方で炎上している開発プロジェクトではそもそも育成に充分な稼働を割くことが出来ない場合もあるでしょう。このような時はあくまで可能な範囲で目安としてのスケジュールを立てて育成を進めます。
もし何人か育成を重ね過去のデータが集まった場合、以下のような項目を加味して類推見積りを行うと多少は正確なスケジュールが見積もれるかとは思います。
-
スケジュールの見積もりについて検討する項目の例
- 新人の学習意欲や積極性の有無
- 新人のITスキルやビジネススキル
- メンターの指導意欲や積極性の有無
- メンターのITスキルや指導能力
- 習熟対象となるドキュメントの量
- 習熟対象となるツール類の量
- 習熟対象となる業務の難易度
-
理解度のレベルについて
スケジュールを立てる上で、各育成項目に対して、以下のような評価レベルを定めておき、可視化しておくことで育成状況の把握がしやすくなります。習得した内容を失念することもあるので、もし下のランクで言う「C」のように理解が不十分だとメンターが感じた場合は評価を保留して後日再レクチャーを行う必要があります。
A：作業は完璧、他者へも説明できる
B：作業するだけならなんとか可能
C：一人で作業不可
②－４ コミュニケーション方針の計画
次にメンターや新人との具体的なコミュニケーション方針を計画します。ここで育成状況の確認を行う際の面談ルールも決定しておきます。面談の一番の目的は何かしらの問題で育成が頓挫、長期化しかねないリスクを発見することになります。また、その新人の意欲やモチベーションなど長期的な成長に繋がる可能性の有無も見えてくることがあります。
-
面談の運用ルールの例
- メンターから管理者へ育成報告は週に1回行う
- 育成報告の前営業日の午前中までに育成報告資料を提出する
- 管理者と新人の育成面談は週に1回とする
- 管理者は新人に対して、メンターとの人間関係、健康状態、仕事への不安等のヒアリングを行う
- 管理者は面談で問題が発生した際、場合によって公平な視点を持つ第三者へのヒアリングも行う
-
日報の要否について
新人の考えを把握する為に日報を書かせてそれを振り返るルールを採用している職場を見かけます。もし日報での報告業務を採用する場合、その効果については充分に確認した方が良いでしょう。過去に「新人とのコミニュケーションを取るツール（日報）を用意しておけば新人が意見を書いてくれるはずだ」という管理者からの一方的な思い込みで日報が用意されていた職場を見たことがありますが、日報が形骸化されており効果が無いどころか、優秀なメンターの稼働を消費するだけの負の遺産になっておりました。もし日報を採用しており、それが形骸化しているのであれば即刻廃止し、別の手法で新人がアウトプット出来るようなルールを検討すべきだと考えます。
②－５ 育成リスクの特定
育成を続けていくと様々な要素により、育成計画そのものが脅かされるリスクも発生します。発生する可能性があるリスクは事前にリスト化しておき、発生した場合の対処も決定をしておきたいものです。実際に全ての対策を事前に立てることは不可能ですが、中には未然に防止出来たり、また発生した時に即座に判断を下す基準となります。
育成リスクの例
| 項目 | 優先度 | 対処内容 |
|---|---|---|
| 体調不良による離脱 | 中 | スケジュールの延期 |
| メンターの指導力不足 | 中 | メンターの交代 |
| 周囲のメンバとの人間関係悪化 | 高 | 別プロジェクトへの異動 |
| 新人の学習意欲が低い（軽度） | 低 | 育成メニューの変更 |
| 新人の学習意欲が低い（重度） | 高 | 別プロジェクトへの異動 |
※職場に応じて変動する為に優先度、対処内容は仮の値を入れております
ある程度良く見かけ、かつ厄介なのが「周囲のメンバとの人間関係悪化」「新人の学習意欲が低い（重度）」の２つではないでしょうか。前者は場合にもよりますが、一度壊れた関係を修復することは困難な為にプロジェクトの異動を検討せざるを得ない状況にも陥ります。後者についても場合によっては厳しい判断に迫られるかもしれません。いくら現場の優秀なメンターが丁寧に教えても、教わる側の自発的な学習意欲が著しく欠けているとなると長期的な成長は望めないためです。
これらについては新人やメンターとの面談や日々の会話だけでなく、周囲のメンバの会話でも話が耳に入ってくることがあります。特に管理者とメンバの経験が長く信頼関係を構築出来ていれば共に食事や雑談をしている際にそうした話を聞かせてくれるでしょう。
③実行及び監視プロセス
③－１育成指示、コントロール
育成状況が進みだしたら、各問題点に対する管理、変更を行います。問題が発生した場合は事前に定めた②－５に沿って出来るだけ早く対処を行います。始めは指導や役割の交代など出来るだけ大きな影響を与えない対処方法を検討します。
しかし状況が改善せずに悪化の一途を辿っている場合は話が異なってきます。組織を預かる立場として、可能な限り体制を維持したいと感じることがあるかもしれませんが、もし改善する見込みが無い場合、その状態を引っ張れば引っ張る程、現場のメンバが疲弊していきます。難しい判断を迫られることが多いと思いますが、ある程度の期間を観察して、状況が改善していなければ担当の交代、要員の異動なども考える必要があるでしょう。
また、育成状況についても、上長と月に1回程度報告を行い育成状況を共有しておきます。特に問題が発生しかけている時は、要員交代や要員の追加などを要請する為に定期的に育成状況を共有しておきます。
③－２必要スキルの妥当性監視
ここでは指導を開始してからスキルが順調に身についているか、確認を行います。実際に管理者が②-3のような育成関連の成果物に目を通したり、指導の場に同席したりすることも効果的ですが、それに加えて習熟状況のチェックテストを行うこともお勧めします。テストは実際に過去の業務で発生した作業をピックアップし、メンターと管理職が居合わせる中で、新人に作業をシミュレーションしてもらいます。ちなみにGoogle内のSREチームでもディザスタロールプレイング1として育成方法にも取り入れられておりますが、以下の例はそれを参考として少しアレンジしたものとなります。
習熟チェックテストの例
-
準備段階
- 事前にチェック項目及び評価水準を定めておく
- 評価水準に応じた過去の業務（シナリオ）を用意する
- 適切な制限時間を設定する
- 当時の業務の登場人物をなるべく再現し、確認者役が存在する場合はメンターを配置させる
-
実施段階
- 事前に定めたチェックリストに沿った振る舞いが行えているかチェックを行う
- 作業毎の経過時間を控えておく
-
評価段階
- 新人のチェック項目に応じて達成できた点、出来なかった点のフィードバックを行う
- メンターが確認者の立場の場合、メンターのサポート面も適切かフィードバックを行う
- 各チェックポイントの作業時間は適切か、評価を行う
- 新人、メンター、管理職がそれぞれの立場から、作業の改善点や優れていた点を評価する
- 人間性の批判は行わず、技術視点や業務視点での中立的な意見を心がける
- 新人に演習内で使用したドキュメントやルール、ツールの改善案もあれば拠出させる
準備から実施、そして評価まで複数人の稼働がかかることが難点ではありますが、管理職が居合わせる中で、新人が実際の業務と同様に責任を持って作業を進める事はロールプレイングとは言えど、かなりの緊張感を与えます。それにより、管理職に配慮されたような聞き心地の良い習熟報告ではなく、素の状態でのスキルを自分の目で確認することが可能となります。
③－３指導スケジュールの監視
ここでは育成がスケジュール通りに進んでいるか把握を行います。②－３で定めた通り、事前に理解度のランクを振り分けておき、理解した実績がどれだけ増加しているか、という観点で確認をしていきます。
育成期限が定められているが、どうしても計画通りに進まないケースも発生します。苦しいところですが、その場合は難易度が低い作業を多めに割り当てながら、シフトに入ってもらい育成はそのまま継続します。
③－４コミュニケーション実施と管理
ここでは②－４で計画したコミュニケーションが、適切に行われているか把握を行います。主に面談での報告を受け、それを元に重大な問題が発生していないか確認を行い、また随時、新人やメンターへコンタクトを取りながら問題の発生有無や進捗なども把握します。
それと日々、ITエンジニアとして自発的に学習を行う心がけも伝えておくようにしておくと良いでしょう。優秀なエンジニアの方々を見ると、成長する為に必ずと言って良いほど自身の成長に繋がる行動や学習を行っております。もし見込みのある新人が入ってきた場合、労働基準法に沿った上で、優れたメンターからエンジニアのそうした心がけを教えておきたいものです。
③－５育成リスク発生監視
②－５で特定したリスクが発生していないか、日々の業務や会話の中で確認します。突発的な病欠が増加している、新人やメンターが自信を無くしている、不平不満を相談される、というような状況が発生したら注意が必要となります。また、③－２で記載した習熟チェックテスト様子でも問題点が判ることもあります。
④終結プロセス
育成が終了したら、次回の育成計画に向けて、メンターと一緒に今回の育成の課題や改善点を拠出します。育成には正解が無いケースも多いので、改善案の採否に迷ったら、短い期間お試しで実施してみるのも良いでしょう。また可能であれば別プロジェクトの参考となるように上長へフィードバックもしたいところです。社内の育成ノウハウがたまり、また現場目線での求めているスキル像が明確になれば企業の重要な情報資産となるはずです。
終わりに
ここまで長々と記載してきましたが、やはり育成は困難なミッションであると常に感じます。新人がエンジニアとして長期的に成長するか否かは人事部門が採用した時点で決まることもあり（好きじゃないとやってられない業種でもあるので）、また指導する技術や方向性は企業の目指す長期的な経営戦略や顧客の需要にも影響されるでしょう。理想を目指すのであれば会社全体という組織の中で、目指す経営ビジョン、人事採用基準、組織構造、評価基準など含めて様々なバランスを取って育成に取り組む必要があるのかもしれません。
ただ仮に出来るところが少なくとも、新人の育成は将来の会社の成長に直結する重要な業務であることも事実です。難しいながらも試行錯誤して日々改良を加え、より良い育成体制を作ることが大切だと考えています。
-
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
オライリー・ジャパン 28章より ↩