Patterns for HR Developing Technical Training

Ayana Chandler / Rakuten Inc. / Agile Japan Executive Committee Kotaro Ogino / Rakuten Inc. Yasuo Hosotani / Agile Tour Osaka Committee

Abstract When HR is in charge of developing technical training, they do not have the technical expertise related to the content, and usually request external vendors to create the material.　However when using external vendors, the content depends on the vendor, and is often difficult to customize the content to match your companies situation. Also due to rapid change in technology the training must be able to flexibly adapt to changes. We propose pattern languages where HR involves internal engineers and uses agile methodology to produce and continuously improve effective training material that meets company needs. With these patterns, the author in HR succeeded to develop 22 training courses in DevOps training program over half a year by involving 40 engineers. This was the program with the highest demand in the company. During that period, about 300 engineers from 32 organizations in the company participated in the DevOps training and based on their feedback, we kept implementing improvements. As a result, the median of NPS(Net Promoter Score) increased from 6 to 31.

1. はじめに

　人事が技術研修開発をする場合、研修対象の技術に関する専門知識がないために

外部委託に研修を行ってもらう場合が多い。しかし、外部委託を利用すると、研修

内容が委託先に依存してしまい、自社の状況に合った内容にしづらいという問題が

ある。また、技術の変化は速いため、研修もそれに順応して変化できるよう考慮し

なければならない。

　本論文では、人事が社内のエンジニアを巻き込み、アジャイルの手法で自社の

ニーズに合わせた効果的な研修を開発し、継続的に改善するためのパターンラン

ゲージを提案する。

　人事である筆者はこのパターンランゲージを用いて、社内で最も需要が高かった

DevOps研修プログラムで、40人のエンジニアを研修開発に巻き込み、半年間で22個の研修作成に成功した。その半年間に32組織約300名の社内エンジニアがDevOps研修に参加し、エンジニアたちのフィードバックを元に研修の改善を繰り返した結

果、NPS(ネットプロモータースコア)の中央値が6から31まであがった。

　下図は、ともに研修を作り上げたエンジニアの考えを元に、研修開発に基づくア

イディアを図式化したものである。

2. 　研修開発の体制 　本論文では、研修開発に関わる下記の人々を、「研修開発チーム」と呼ぶ。ま

た、ここでは、それぞれの役割を「スクラムガイド」における「スクラムチーム」

に置き換えて紹介する。(図参照) 研修開発チーム：スクラムチーム 2-1. プログラム責任者：プロダクトオーナー 　必要とされている研修を見極めそのトピックにおける研修プログラム全体をデザ

インする人を現場のエンジニアからアサインする。DevOps、AI、セキュリティーなど、分野ごとにそれぞれの専門家が担当し、各プログラムの中に複数の研修を開発

する。　 　技術力が高く、社内の事情も世の中の技術の流行にも詳しい人物であることが望

ましい。 2-2.トレーナーチーム： 開発チーム 　プログラム責任者が提示する研修を開発し、実施する。基本的には研修ごとにト

レーナーは別のエンジニアになるが、同一人物が複数の研修を担当することもあ

る。 　研修内容における専門性が高く、トレーナーとしてのプレゼン能力やファシリ

テーション能力がある人物であることが望ましい。 　 2-3. 研修担当人事：スクラムマスター 　研修プログラムが滞りなく開発されるように、プログラム責任者とトレーナー

チームを支援する。定例会議や振り返り会議などの実施やステークホルダーとの調

整をする。組織に研修を広める。 　多くの人と関わり、同時に調整をしていく必要があるため、コミュニケーション

能力やマネジメント能力のある人物が望ましい。

3. パターン一覧　　　

　本論文にて提案するパターンの一覧を以下に示す。

　「Fearless Change」のパターンが研修開発に応用されているものが多いため、関連する「Feareless Change」のパターンがある場合は併記する。

パターン名 要約 Fearless Change の 関連パターン　

研修バックログ<1> 開発すべき研修をリストアップ

し、優先順位をつけ、完成したも

のから実施する。 実施したものからフィードバック

が得られ、修正が効く。

ステップバイステップ(3)、予備調査(4)、やってみる(17)

完成前トライアル

<2>

研修完成前に、小さくトライアル

を実施し、フィードバックを元に

改善する。 一発目の研修の質があがる。

小さな成功(2)、ステップバイステップ

(3)、予備調査(4)、やってみる(17)、お試し期間(47)

受講者の声<3> 毎回研修後に受講者アンケートを

実施し、定量的な評価方法も採用

する。 受講者の意見を参考に、他の研修

とも比較をし、改善点が出せる。

なし

みんなで振り返り

<4>

毎回研修後に振り返りミーティン

グを実施し、研修開発チーム全員

が参加する。 研修する度に研修の質があがる。

小さな成功(2)、ふりかえりの時間(5)　

改善ダッシュボード

<5>

振り返りミーティングででできた

改善策は、改善ダッシュボードに

まとめる。 後から見返せる。他のトレーナー

に共有できる。

次のアクション(9)、体験談の共有(32)

再構築する勇気<6>

思い切ってプログラム全体を再構

築することもある。 研修プログラム全体の改善がなさ

れる。

なし

柔軟カスタマイズ

<7> チーム単位で研修依頼がある場合

は、そのチーム向けにカスタマイ

ズした研修を提供する。 チームにより合った研修になり、

効果が上がる。

テイラーメイド(26)

ブルドーザーで人を

巻き込む<8> 社内外のエンジニアをたくさん巻

き込み、研修開発チームに入って

もらう。 同時進行で多くの研修が開発でき

る。

エバンジェリスト(1)、協力を求める(6)、みんなを巻き込む(33)

構わず突進<9> コミュニケーションに対して消極

的な人も含め、どんな人とも積極

的に関わっていく。 仲間、支持者が増える。

協力を求める(6)、みんなを巻き込む(33)、恐れは無用(46)

無邪気な無知<10> 自分が知らないことやわからない

ことを相手に隠さない。好奇心を

伝え、教えてもらう。 自分の知識が増える。相手との信

頼関係も築かれる。

協力を求める(6)、感謝を伝える(18)、恐れは無用(46)　

愛される自己主張

<11> 技術に関する知識が足りなくても

自分から意見することを厭わな

い。 自分のアイディアが反映され、コ

ンテンツ開発に関われる。

体験談の共有(32)

相方絶対論<12> 社内外の技術動向に詳しい専門知

識のあるエンジニアをプログラム

責任者におき、企画/開発/運営の相方になってもらう。 苦手な部分を補ってもらい、開発

が進みやすくなる。

協力を求める(6)、コネクター(8)、達人を味方に(14)、イノベーター(16)、達人のレビュー(31)、メンター(37)、相談できる同志(39)

イノベーター発掘

<13> 社内のイノベーター(新しい技術などを積極的に導入している人)を発掘し、トレーナーに誘う。 研修を通して最新の技術やベスト

プラクティスを他のエンジニアに

共有される。

コネクター(8)、イノベーター(16)、勉強会(25)、橋渡し役(43)

ぼっちにさせない

<14> トレーナーをひとりぼっちにさせ

ない。相方（もしくはチーム）体

制を促す。 協力し合いながら研修開発を行え

る。

協力を求める(6)、定期的な連絡(24)、みんなを巻き込む(33)、相談できる同志(39)

コンウェイの法則打

破<15> 研修開発にあたり、組織を越えて

研修開発チームを作る。 内容が偏らなくなる。研修以外で

も情報交換やコラボレーションが

生まれる。

みんなを巻き込む(33)、橋渡し役(43)

社外エキスパートの

お墨付き<16> 社外のエキスパートにも研修開発

に関わってもらう。 社内の状況に寄り添いつつも一般

化された研修になる。

外部のお墨付き(12)、達人を味方に(14)、達人のレビュー(31)、みんなを巻き込む(33)

トレーナーベネ

フィット<17> トレーナーたちが成長できる工夫

をする。 やりがいを感じてもらえる。ト

レーナーになりたい人が増える。

何か食べながら(9)、グループのアイデン

ティティ(13)、感謝を伝える(18)、個人的な接触(20)

プロモーターを味方

に<18>

SNSのでの宣伝やイベントの開催を通して味方を増やし、宣伝して

もらう。 研修の認知度があがり、支持者が

増える。

アーリーアダプター

(11)、種をまく(22)、勉強会(25)、著名人を招く(27)、経営層の支持者(28)、アーリーマジョリティー(30)、みんなを巻き込む(33)、将軍の耳元でささやく

(48)

4. パターンの説明 　以下にそれぞれのパターンについて説明する。 研修バックログ<1> 1. 状況　 　研修プログラム内には研修開発チームが開発すべき研修が複数ある。 2. 問題 　数が増えると優先順位や開発状況がわかりづらくなるだけでなく、全研修の完成

を待つと、開発期間が長くなってしまう。技術の変化は速いので、全研修の完成を

待っていては、研修の内容が最新のものを保てなくなってしまう。 3. フォース 　　 　一般的な研修プログラムは全て完成してから実施する。 4. 解決方法 　開発すべき研修をバックログに入れ、優先順位や開発進捗をカンバン方式で表示

する。研修開発チーム全員が共通の認識を持ち、優先度の高い研修やすぐに開発で

きる研修から開発に着手し、完成した研修から順次実施する。 5. 結果状況 　研修開発着手から実施までの期間を短くできる。初期段階から順次フィードバッ

クを集められ、その後完成する研修の参考にできる。

完成前トライアル<2> 1. 状況　 　研修開発チームが研修を開発している間は、受講者の反応は見れない。 2. 問題 　ニーズに合った良い研修内容に開発できているのかどうか、確認ができない。

ニーズに合わないものを開発していたとしても気づかないことがある。 3. フォース 　　 　一般的な研修は、完成してから実施する。 4. 解決方法 　大きく始める前に、小さくトライアル研修を実施する。その分野の専門家が多い

トレーナーの所属部署や、将来的に受講者となる可能性の高い部署などを対象に行

い、フィードバックをもらう。 5. 結果状況 　トライアル受講者のフィードバックから良い点と改善点が見え、その研修をより

良い状態で完成でき、一発目の研修から質の高い研修を実施できる。

受講者の声<3>

1. 状況　 　完成した研修は、繰り返し実施する。 2. 問題 　完成した研修でも、より良くできる可能性があるが、研修開発チームだけでは気

づけない部分もある。 3. フォース 　受講者アンケートは定性的な評価になってしまうことが多い。 4. 解決方法 　受講者アンケートの実施により、研修開発チームだけでは気づけない改善点を発

掘する。全研修で同じ内容の質問を設け、NPSなど定量的な評価方法も用いることにより、他の研修との比較もする。 5. 結果状況 　全研修で比較ができるため、どのような研修が受講者満足度が高いのかを分析す

しやすくなり、満足度の高い研修の良い点を他の研修に取り組むことができる。

みんなで振り返り<4> 1. 状況　 　研修実施後は、次回の研修に向けて、振り返りミーティングを実施する。 2. 問題 　トレーナーだけの視点では、改善すべき部分が限られてしまう。 3. フォース 　　 　明らかなデータを元にした複数人の合意がないと、改善を怠ってしまう。 4. 解決方法 　受講者アンケートを元に、研修担当人事もプログラム責任者も含む研修開発チー

ムが全員で振り返りミーティングを実施し、継続すべき点と改善点を議論し、参加

者全員の合意の元に改善点のバックログを作る。次回までに改善できるように、〆

切や担当も決める。 5. 結果状況 　他の研修の事例等も用い、あらゆる角度から改善アイディアが出る。全員でバッ

クログを作成するため、次回までに改善することに対して責任感が生まれる。この

繰り返しにより、研修の質が毎回あがる。

改善ダッシュボード<5> 1. 状況　 　毎回研修後の振り返りミーティングで継続すべき点と改善点があげられる。 2. 問題 　研修開発チーム全員は改善点について同じ認識を持っているべきだが、量が多い

と認識にずれが生じる。 3. フォース 　 　特にプログラム責任者と研修担当人事は他にも沢山の研修を見ているため、情報

が錯綜する。　 4. 解決方法 　毎回の振り返りミーティングの内容を改善ダッシュボードにまとめ、毎回議論し

た継続すべき点と改善点の一覧を見える化する。 5. 結果状況 　研修開発チーム全員が同じ認識を持てる。他の研修のトレーナーにも共有でき、

良い改善方法が広まる。

再構築する勇気<6> 1. 状況　 　計画していた研修プログラムに沿って研修を開発し、できたものから実施してい

るが、受講者満足度があまり高くない。 2. 問題 　複数の研修の振り返りを通し、研修プログラム全体の構造が間違っていたのでは

ないかという結論にいきついてしまう。 3. フォース 　　 　計画した研修プログラム全体の構造を途中で抜本的に変更するには抵抗がある。 4. 解決方法 　受講者の声や振り返りで出た結論を重視し、プログラム全体の再構築を行う。計

画した時間や失敗してしまったことはマイナスにも見えるが、気づけたことになっ

てより良いものを作れることを重視する。 5. 結果状況 　研修プログラム全体を見直したことによって、全研修が改善され、より受講者満

足度の高い研修が実施できる。 　　

柔軟カスタマイズ<7> 1. 状況　 　とあるチームから、チーム全員で研修を受講したいとの依頼がある。 2. 問題 　研修では一般的なスキルは身につくが、それだけだとチーム全員で受講するメ

リットは少ない。 3. フォース 　既存の研修をそのまま提供するだけでは、そのチームが抱えている問題の直接解

決にはなりづらい。 4. 解決方法 　事前にチームの状況や研修を通して改善したい点をヒアリングし、チームの状況

に合わせて、研修をカスタマイズする。別の研修を組み合わせたり、内容を変更し

たりすることにより、チームが抱えている問題を解決できるようにする。 5. 結果状況 　チームの状況に合った研修内容になり、研修を通してチームが抱えている問題を

解決できる。 　　

ブルドーザーで人を巻き込む<8> 1. 状況　 　研修担当人事は技術の専門知識がないので、ひとりで技術研修を作成することは

できない。 2. 問題 　社外の専門家に講師を依頼すると、自社の状況に内容を合わせづらい。 3. フォース 　社内の優秀なエンジニアに講師を依頼すると、優秀なエンジニアは特に忙しいの

で研修の開発に時間をそこまで割けない。 4. 解決方法 　社内外両方のエンジニアをたくさん巻き込み、負担を分散させ、同時進行で大量

の研修開発を進行させる。 5. 結果状況 　短期間で社内の状況に合った技術研修が完成する。

構わず突進<9> 1. 状況 　研修担当人事は協力者や支持者を増やしたいが、エンジニアは近寄りがたい。 2. 問題 　エンジニアは、人事の行動にあまり関心がないだけでなく、否定的なことさえあ

る。 3. フォース 　　 　多くのエンジニアは通常業務が忙しく、他の仕事を増やしたくない。 4. 解決方法 　そっけなくされても、構わず積極的に話しかけ続け、実現したい具体的内容と熱

意を伝える。何度も冷たく接しられても心を折らず、何度もアプローチする。 5. 結果状況 　積極的に話しかけ続けると、耳を傾けてくれるようになり、熱意が伝わり、協力

してくれるようになる。

無邪気な無知<10> 1. 状況　 　研修担当人事は、技術の話がわからない。 2. 問題 　エンジニアと仲良くなりたいが、技術の話ができないので、話が盛り上がらな

い。 3. フォース 　技術のことを知らないことを認めるのが恥ずかしい。 　 4. 解決方法 　隠さず素直に知らないことを伝えると、心を開いてもらえる。好奇心を示し、わ

からないことを質問し、色々教えてもらい、勉強する。 5. 結果状況 　続けていると最初はわからなかったことがわかるようになり、技術研修について

エンジニアと議論できるようになる。その姿勢が認められると、信頼してもらえる

ようになる。

愛される自己主張<11> 1. 状況　 　研修担当人事は、技術に関する知識がないので、研修の内容に関われない。 2. 問題 　技術の知識がないからと議論に参加しないと、エンジニアと距離ができてしま

う。 3. フォース 　自分より知識がある人に対して、自分の意見を主張するのは抵抗がある。 4. 解決方法 　実際は、技術以外の部分では、人前での話し方や受講者のケアの仕方など、全研

修を見続けている自分の方が多く体験している部分があるという事実に目を向け

る。エンジニアでは気づけない部分で、自分のアイディアを伝え、アドバイスす

る。 5. 結果状況 　エンジニアだけではなかった新しい視点が追加され、研修がより良くなる。研修

担当人事も開発に関わった感じが出て、研修開発チームに一体感が生まれる。

相方絶対論<12> 1. 状況　 　社内外の技術動向に詳しい専門知識のあるエンジニアをプログラム責任者にお

く。 2. 問題 　プログラム責任者だけに任せていると、協力体制は生まれない。 3. フォース 　　 　プログラム責任者も優秀なエンジニアなので、通常業務で忙しい。 4. 解決方法 　プログラム責任者が企画開発に集中できる環境を用意するよう、研修担当人事は

調整や申請まわりを率先して対応する。プログラム責任者には、研修プログラムを

デザインしてもらったり、誰をチームに誘うべきかを判断してもらう。研修担当人

事はそれを資料に起こしたり、打ち合わせを企画運営したり、紹介してもらった人

をうまく巻き込んだりする。 5. 結果状況 　相方との支え合う関係性ができると、開発がスムーズに進む。運用や人間関係な

どトラブルが起こりそうな部分でも自然とお互い苦手な部分を補うようになる。

イノベーター発掘<13> 1. 状況　 　トレーナーは研修担当人事とプログラム責任者で探さないといけない。 2. 問題 　現場のマネージャーに紹介してもらおうとすると、エンジニアにとって研修開発

は通常業務に追加される業務となるため、あまり能力の高くない暇なエンジニアが

選ばれそうになる。 3. フォース 　　 　社内の状況をよく知っていて技術力もある人にトレーナーを頼みたい。 4. 解決方法 　新しい技術などを積極的に導入している「イノベーター」と呼ばれるようなエン

ジニアが、トレーナーに向いている。技術力が高いだけじゃなく、ベストプラク

ティスを共有することに興味がある人多く、勉強会やSNSでの発信を積極的に行っている。また、イノベーター同士繋がっていることが多い。プログラム責任者にイ

ノベーターを紹介してもらい、イノベーターにイノベーターを紹介してもらう。 5. 結果状況 　技術力が高くかつ推進力のあるイノベーターがトレーナーになり、研修を通して

最新の技術や社内のベストプラクティスが、広まるようになる。

ぼっちにさせない<14> 1. 状況　 　トレーナーは、研修開発の中でも具体的コンテンツとなる資料やハンズオン環境

の開発など、タスクがたくさんあって大変だが、それを通常業務をやりながらこな

さなければならない。 2. 問題 　１人でやると内容や負担が偏ってしまう可能性がある。 3. フォース 　つらい。 忙しいとモチベーションが下がる。通常業務が優先され、研修開発は後回しになってしまう。 4. 解決方法 　各研修において、トレーナーを相方やチーム体制にする。複数名で研修開発をす

ると、タスクを分担でき、責任感が生まれる。辛いときはお互いに励まし合いなが

ら、完成という同じ目標を持って、明るく開発を進められる。 5. 結果状況 　ひとりぼっちで研修を開発するよりも圧倒的に短い期間で完成することができ

る。

コンウェイの法則打破<15> 1. 状況 　大きな組織ではチームごと・レイヤーごとにアーキテクチャーが異なり、それら

を越えてのコミュニケーションはなされないことが多い。 2. 問題 　新しいノウハウやベストプラクティスが他のチームに展開されない。 3. フォース 　自分から積極的に他のチームと絡もうとするエンジニアは少ない。 4. 解決方法 　通常のチームやレイヤーを越えて、研修開発チームを作る。研修開発をとおし

て、必然的に他のチームや他のレイヤーの人とコミュニケーションをとるようにな

る。 5. 結果状況 　チームをまたがるため、研修内容が偏らなくなる。今まで関わりのなかった人た

ちがノウハウを共有し合い、より良い研修ができる。通常業務についても情報交換

し合う関係性が、組織を越えてできる。

社外エキスパートのお墨付き<16> 1. 状況　 　社内のエンジニアが講師をやる場合、指導経験はないことが多い。 2. 問題 　社内の状況に合った研修を開発できるが、一般的なコンテンツに自信がなかった

り、研修の作り方や教え方に自信がない場合がある。 3. フォース 　トレーナーという立場だと他の人の意見を求めにくい。 　　 4. 解決方法 　研修担当人事が、社外のエキスパートとトレーナーが話せる場を設けたり、必要

であれば一緒に研修開発をしてもらえうように促す。 5. 結果状況 　社内のトレーナーにより、社内の事例やニーズにも対応している上に、社外エキ

スパート、プロ講師お墨付きの研修が完成する。

トレーナーベネフィット<17> 1. 状況　 　トレーナーは通常業務で忙しい中、研修の開発と実施に協力する。 2. 問題 　やりがいを感じなければ続ける気が起こらない。 3.フォース 　　 　わかりやすいベネフィットも欲しい。 4. 解決方法 　研修担当人事は、「トレーナー経験」というキャリアの魅力をトレーナーをして

ほしいエンジニアに伝える。本人だけでなく、その上司にも理解をしてもらい、評

価に加えてもらえるよう依頼する。 　また、トレーナーだけが集まる情報交換の場やトレーナー向けの研修、外部のエ

キスパートと話す機会、社外カンファレンス参加への機会など、特別な機会をでき

る限りアレンジする。 5. 結果状況 　上司の理解を得ると、評価に反映されるし、業務の調整をしてもらえることもあ

る。トレーナーをやらなければ経験できなかった機会を提供すると、やりがいを感

じてもらえる。

プロモーターを味方に<18> 1. 状況 　研修を開発しても、実施するだけでは認知度は上がらない。　 2. 問題 　人やチームによって好まれる情報収集手段が違う。 3. フォース 　　 　イベントのほうが気軽に参加できる人もいる。 4. 解決方法 　あらゆるSNSツールを駆使して宣伝をしたり、イベントを開催したりして、研修の認知度をあげる。味方を増やし、宣伝してもらう。権力者やアーリーアダプター

には直接アピールし、味方になってもらう。 5. 結果状況 　SNSを見た人やイベントに参加した人、権力者やアーリーアダプターが拡散源となり、アーリーマジョリティへの展開され、認知度が上がり、支持者が増える。

5. 結論と今後の課題

　このように、専門知識がない人でも、その分野の人を巻き込むことによって、研

修を迅速に開発することができる。アジャイルに開発していくことにより、改善を

繰り返していく仕組みもできる。 　しかし、研修を頻度高く継続していくためにはトレーナーたちの日々の業務の時

間を削って研修実施に時間を費やしてもらう必要がある。イノベーターである彼ら

の時間の多くを研修実施にかけるのは難しく、新しいトレーナーを育てる仕組みを

作り、現場の負担になりすぎないようにするのが今後の課題である。 参考文献:

1. Manns, M. L. & Rising, L. (2004). Fearless Change: Patterns for Introducing New Ideas. Addison Wesley Professional. (邦訳: 川口恭伸監訳『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』, 丸善出版, 2014年)

2. Schwaber, K. & Sutherland, J. (2017). The Scrum Guide. (邦訳: 角征典訳『スクラムガイド』)