一部、研修現場の実態について言及していますが、筆者の経験談によります。
対象者
- 引き継ぎ資料を書く必要がある人
- 手順書など運用マニュアル作成の担当者
- 後進育成の担当者
書かないこと
- 良いマニュアルや教材の書き方の解説や例示
- 資料作成に必要なスキル
- 特に教材で副収入を得る方法
ナレッジ管理は難しい
新しいプロジェクトに参画した際に渡されたドキュメントやソース、Gitlogを読んでも何をやっているかわからない、という体験を一度はした事があるのではないだろうか？
何らかの手順書であれば、そもそもどういった状況で実施すれば良いのだとか、そもそも何のトラブルシューティングなのか、ひどい時にはログイン情報（IDとパスは書いてあるが、接続先が不明とか接続設定が不明とか）が欠損していて、結局知っている人のメモ書きになってしまっている、というケースが多いように思う。
特にドキュメント類は最初期に書かれた内容が全く更新されておらず、最終更新日＝作成日という事も珍しくない。
また、ドキュメント自体にもレビューはされておらず、リモートワークだとオンボーディングが全くされていないために参画するまでに非常に苦労した、という事もあるあるだと思う。
多くの企業ではオンボーディングの課題を解消するための措置として、慣れるまでは出社して以降はリモートに切り替える、という運用をされているだろう。
問題は「出社してもオンボーディングがまともにされていない」という点に目を向けられているか、は気にしておきたい。
オンボーディングの課題調査と対策（トップダウン）
- オンボーディングの課題がある事を認識しているか
という点を気にしている方はあまり多くないように思う。
- 一般論としてのオンボーディングの重要性
については一定の懸念があるというのが、私が感じた部分である。
つまり、「オンボーディングは重要だけど課題は分からない（感じない）」という状況になってしまっているのである。
今回の問題点を改めて見直すと「オンボーディングを想定した引き継ぎが出来ているか」を誰も評価できないという状態が浮かび上がってくる。
本来であればドキュメントレビューや、ドキュメントだけを正とした作業手順として作業をした時に暗黙知が使われていないかなどの炙り出しが必要なのだが、実態としてドキュメントレビューの時間を割けなかったり、ドキュメント作成者もドキュメントの手順が正しい事 （常に最新であること） を確認しながら書く事は少ないです。
重要な部分は「ドキュメントは陳腐化する事を意識して書いていない」という点で、ドキュメント中にも作成更新日や開発環境などのバージョンがドキュメントにないため、新規参画者と既存メンバー間で余計にコミュニケーションが拗れたりする事があります。
受講者向けに改めて強調すると、こう言った部分でもコミュニケーションスキル（ここでは課題解決力とイコールで考えて差し支えない）が求められる事を認識しよう。
オンボーディングの課題調査と対策（ボトムアップ）
シンプルに、オンボーディングの課題の有無についてヒアリング・回答を通知する仕組みを作っておけばよい。
内容が難しいので一問一答式で自由記述式にして、現状存在する課題についてキャッチアップできるようにすると良い。
たとえばGoogleFormとSpread Sheetで入力・データ管理をして、内容をRedmineなど課題管理ツールまたはnotionなど「情報がない」という事実をナレッジ管理ツールに流し込んでやれば既存メンバーには課題として、新規メンバーには回答先と、更新通知が送られるようになる、という方法も可能だ。
このケースはDevOpsではないが、思想としては近いものがあるので敢えて明記するが、開発チームはプロジェクトを介して課題を解決する、という事に心血を注ぐ事には敏感だ。
が、なぜか開発チーム自体の課題を解決する、という事に対しては気が回らない事が多いので、まずはしっかりと地盤固めが出来ているか確認しよう。
教材作成を考える
ナレッジ管理の例でも見たが、教材開発も本質的には同じ課題である。
たとえばトップダウンを講師→受講生、ボトムアップを受講生→講師とすると、講師が受講生のレベルの想定を誤ると使い物にならない教材を作る事になるし、受講生から講師に教材の要望ができた方が講師視点で見えない問題を解決しやすくなる。
逆を言えば、適切なドキュメント（手順書などマニュアル）作成スキルはそのまま教材開発にも活かせる。
特に教材開発は引き継ぎ資料以上に「分からないユーザーに対して意識をする」事がしやすいように思う。
（先述の通り、教材作成だろうが引き継ぎ資料作成だろうが、対象者は「分からない人」であるべきだ）
本質的にはマニュアル作成と教材作成は同じだが、特に教材作成ならではの課題や留意点にフォーカスしていきたい。
カリキュラム設計：ゴールを明確にする
教材開発以前の課題として、そもそも受講者がカリキュラム完了後にどのようになってほしいのか、という点を考える必要がある。
教材とは、あくまでカリキュラムを完了するための手引きであり、カリキュラムを完了する事で達成すべき目標があるはずなのだ。
受講生の仕上がりが悪い場合は、カリキュラムの習熟度が低いのかカリキュラム自体に問題があるのかを分析する必要はあるし、極端な話をすると過去に設定したカリキュラムのゴール自体を変えなければならない、というケースは考えうる。
このように、まずカリキュラムのゴールが正しくない場合は、どんなに素晴らしい教材を作ったとしても受講者が期待する目標を達成する事は難しいだろう。
カリキュラム分析：受講生の目標と一致しているか
これはよくある勘違い（受講者からすると、事前に聞いていた内容や考えていた状況と現状が異なる）になるが、当該コースを受講する事が受講者が考えていたゴールとして適切かどうか、という点だ。
これが新卒研修だと、受講者ではなく人事担当者や現場が期待する結果と言い換えても良い。（ただし、研修内容が受講社員が期待した内容であるかどうかはヒアリングを含めたフォローアップは必須）
これはZ世代だから、とかではなくリスキリングでも同じだが、受講生だけでなく講師も、また担当者も「その研修で得たスキルをどのように活用していけるか、全員が同じ方向を見ているか」が明確になっているかどうかは常に確認しておく必要がある事は常に留意されたい。
特に新卒研修でカリキュラムのオーダー（カスタマイズ）ができる立場にある方なら尚更である。
研修プランとカリキュラム
マニュアル・教材作成とはやや脱線するが、「教育指導における要求定義と教育パッケージの機能要件」が合わない事を認識してほしいので、敢えて言及したい。
さて、見出しの「研修プラン」と「カリキュラム」は一見同じ事を言っているようだが、前者は新卒採用社目線で、後者は研修会社目線での研修方針と捉えてもらえれば良い。
なぜわざわざ分けたかというと、実態として前者と後者は営利関係である以上、完全一致する事はないと認識してほしい。
というのも、研修プランにはドメインの話（業界特殊性）が絡んでくるが、一般に教育パッケージはあくまで汎用性（専門技術の中でも、様々な業種に対して一意に定まりやすいもの）に富んでいる、というギャップがある事を認識されたい。
たとえば「うちの会社ではこうやってます」という運用があった場合にカリキュラム内で想定されていなければ、指導内容に対して注文や補足を入れる必要が当然に出てくる。
こう言った問題について多くの場合は認識されておらず（発注サイドが未知である問題）、受注側（研修会社の営業担当）も現場講師の力量に依存しており、双方にとって未知になってしまっているという問題がある。
ちなみに、外部講師が上記のような課題について当然認識しているわけがない事もご認識いただきたい。
誤解を恐れずに言えば、多くの研修講師は指導技術について学んでおらず、加えて言えば研修会社は講師向けに大まかな研修業務の概要説明や、担当講師へ教材の読み込みを促す事はできるが、講師に受発注時の背景など経緯説明をする事がなかったり断片的な情報しか伝えていない事が大半で、全体としてナレッジだけではなく要件ですら不明瞭のまま研修プロジェクトが進行してしまっているのが実態である。
研修プランに合わせてカリキュラムをカスタマイズする場合は議事録やカスタマイズの経緯なども残すようにしないと、受発注側で適切なゴールを見据えていたとしても、現場の指導がズレてしまうとやはり仕上がりもうまくいかないケースが発生しうる。
今回は講師が指導するケースを想定したが、これはtoCのプログラミングスクールでも同様である。
必ずしもフルカスタマイズをせず、敢えて既存教材（カリキュラム）を活用する事を検討する
先にお詫びをしておくが、本稿または筆者は「特定の技術要件に特化した教材」を複数組み合わせて「カスタマイズカリキュラム」と主張するサービスや行為を批判する意図はない。
分かりやすいのは、Udemyなどの公開教材をビジネスプランとしてユーザーライセンス単位などで使い放題にする、というアプローチだろうか。
指導側としても
- 既に体系化された指導用教材を使う事で、講義を実施するほど教材の品質や講師の練度が高まる
- 同じ教材を様々なクライアントで使用することで、特定のクライアントで発生した要望を全体に展開する事ができる
というメリットがあり、
- 常に最新化された教材またはサービスを享受できる
- より低コストで研修を実施できる
というメリットがある。
つまり、100点の研修を期待するとコスト面や教材を含めた環境整備で非常に苦心をするため、いったんは80点ぐらいを目指して、足りない部分を自社で補足するという使い方が最もコスト・タイムパフォーマンス面では良い事が多い。
そのためには「研修会社に丸投げしよう」ではなく「研修会社のカリキュラムで出来ない事を見極める」という視点でお打ち合わせに臨んでいただきたい。
ここまでが問題なければ、ようやく教材開発
まずは現存している資料をブラッシュアップして問題を解決していく事を考えてほしい。
既に存在しているものがあれば、保守を前提に運用策定をしていく事が最も低コストの作業になる。
その上で、足りないものを追加していくのが良い。
特に独自性を出したいものや著作権の問題があるものに絞って教材を作成していくべきだ。
というのも、言葉の通り0から1を生み出すより、1を探して100にした方が（日本人の）作業負荷が低く、トータルの品質が高くなるためである。
（説明のため、1→100と表記したが、実際は50→100とか60→80のようなケースになる）
とはいえ、1に先述の問題があると使えないので、1の問題がある部分を改変または除外した内容にするなど「既存の内容を活用する」という方針は維持したい。
なぜゼロベースを避けるかというと、教材についても実際のシステム開発と同じで、変更点に対しては「テスト」が発生する（して然るべきである）からである。
特に導入済みの教材である場合は、講師の教育コストが別途発生するため影響が大きい、と言えば教材刷新のリスクについてイメージしやすいだろうか。
分かりやすい例でいえば、教材を更新する（新規作成も含む）ということは、当該箇所への誤字や脱字、表記ゆれや誤解を招く表現、乱丁や落丁を含めた問題などが発生するリスクを生み出す行為であるからだ。
また、同じ教材でも指導講師によって使い方が異なるため、指導方法についても注視しなければならない。
一般に教材とは、独学で使うものか講師が指導する前提で作るものかで当然内容やレイアウトが異なるため、受講生目線で教材を使って勉強しやすいものかどうか、という点以外にも気にするべき事項がある事をご留意されたい。
まとめ
- 引き継ぎのドキュメントや教材作成の課題はほぼ共通である（特に目的を明確にすること）
- 資料を使う人のペルソナを立てて、内容はペルソナに寄り添うべき
- 教材作成時は、教材を作るまでの過程や課題を認識すべき
- 可能であればドキュメントレビューをすべき
後半は教材の話が多くなったが、引き継ぎもオンボーディングに必要な資料であるという認識を強く持っていただくと品質が高めやすいと思う。
読者各位におかれましては、ぜひ後任や後進に向けて、少しずつでも良い環境を整備していただく事を願う。
補足：人材不足の原因は何か？
※別の記事で改めて掘り下げて扱うが、先出し版。
まず本質的に、採用が出来ないのか離職率が高いのか、で当然取るべきアプローチが変わってくる。
たとえば、
- 採用も多いが離職も多い: 採用を強化するより離職対策をすべき
- そもそも採用が出来ない
- 応募がない
- 応募はあるけど応募者が要件を満たしていない
などなど、問題をバイナリツリーに細分化するだけでもアプローチが違ってくる事に気づくだろう。
今回の引き継ぎマニュアルや教材（研修）は採用後のアプローチなので、採用前の課題に対してはリーチしていない。