OJTは終了後に一人で仕事を進められる人材を育てるのが目的だが、1 OJT期間の後半になっても全くその気配がない場合もある。なぜそうなってしまうのかを考えていた。トレーナーが「（意図せず）仕事を取り上げてしまう」のが原因の一つではないか、と最近は考えている。
仕事を取り上げてしまう例
自分はソフトウェア開発を仕事としている。例もソフトウェア開発に関する仕事を取り扱う。
実例やインターネット上の例を観測していると、良かれと思って親切にする行為が実は…みたいなパターンが多い気がする。
- 依頼をトレーナーが整理した後にトレーニーに投げる
- 例）トレーナーがチケットの詳細を書いてトレーニーに割り当てる
- 例）バグ修正対応のとき、トレーナーが調査して修正方針を立ててしまう
- 本人がするべきコミュニケーションを代行してしまう
- 例）別担当の〇〇さんに聞かないとわからない → トレーナーが聞いてきてしまう
- トレーニーの代わりに説明してしまう
- 質問に回答するとき
- 特に多いのは何かしらのレビュー的な場や進捗報告系の会議
- 困っているときにすぐ正解（らしきもの）を教えてしまう2
トレーナーは「トレーニーの仕事が進められるようにサポートした。実務は任せている」と言う。自分はそうは思わない。仕事を取り上げて「作業を渡している」ように見える。
なんで取り上げちゃダメなの
OJTの目的に即していないから
最初に述べたように、OJTの目的は「終了後は一人立ちすること」である。チケットを書く仕事があるのなら、OJT終了時点で「他者が読んでも理解できるチケットの記載」ができる状態になっていなければならない。
一人でチケットを書いたことがない人間がいきなり「他者が読んでも理解できるチケット」を書けるのだろうか？そんなことはない。まずは取り組んでみて、「第三者から見るとわかりにくい」などフィードバックを得て修正…またフィードバック…と繰り返して書けるようになる3 ものである。
ただ面倒を見ればOKではない。ちゃんと目的が達成されないのであればトレーナーに非がある。
やり切った！という実感が持てないから
これは結構深刻なことである。トレーニーは「取り上げられた」とは思っていないが「何もできない気がする」と不安になる。時間が経てば経つほどひどくなる。理由は「自分は〇〇をやったんだぞ！」という実感がないからで、これはタスクへの関与が途中から・中途半端なときに発生する。
『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』の4章にも、裁量を与えないとモチベーションが下がってしまうよ、と記載がある。
「オートノミー（自分の職務に対する裁量権がある程度与えられて自主性を発揮できる状態）」は、モチベーションを生む重要な要因です。細かすぎる上司のチームには覇気がなく、しかるべき結果がなかなか出せないことが多いのですが、まさにこのオートノミーの不足こそがその原因です。 - 4.4 すごい上司、ひどい上司――細かすぎる上司と、任せ上手な上司 より
取り上げないようにするには
最初から最後までトレーニーが担当（委任）することが必要だと考えている。
最初から = 依頼を受けてくるところから任せる。聞き方やそれを人に伝える工夫は初めから実施しないと知見を得られない。
タスクに取り組む際「こういう目的であなたに任せたい」と伝える。OJT面の目的（例：要件を分解して実装し、テストを書けるようになってほしい）を伝えると良い。仕事を通じて何を学んでほしいか？あらかじめ伝えておくと、トレーニーも自分ごととして捉えやすい。モチベーション高く取り組めると学習効果も上がりやすい。
慣れていない場合や経験がない仕事の場合、ペアで実施する or 強制的にチェックポイントを設ける。「聞きにきてね」は成立しない。聞き方もコツがあるが、これはまた別途まとめようと思う。
また、絶対に外してはいけない（バグ埋め込みなど）箇所以外はトレーニーの意思を尊重する。具体的な例は次のとおり。
- メソッド・関数名 → う〜んと思っても、本人の意思を尊重する
- 後から見返したときに微妙となれば、こういう理由でよくなかったね、と反省の材料にする
- アプリケーションの仕様 → なぜこれがいいと思う？と突っ込んで確認する
- 明らかにまずい点・気になる点がなければ本人の意思を尊重する
- 失敗しても再度修正すれば良い
- テストが足りない → 不足分を指摘してやってもらう
- デグレードを防ぐ = ユーザーに迷惑をかけない方を優先
自主性を持てるようにするにはある程度の裁量が必要。人に迷惑がかからない範囲なら失敗させる。次の機会に改善できれば良い。
早い段階で「自分は〇〇をやったぞ！」と思えるかどうか、が鍵なのかな〜と思った。
