OJTトレーナーとしてやらないように気をつけていること

OJTトレーナーとして気をつけていることを整理した。今度は避けていることも整理しておく。

やらないように気をつけていること

放置しない
必要以上に介護しない
次のアクションが見えないフィードバックをしない

放置する

本やドキュメントのURLを共有して「みておいて」系はやらないように意識した。仕事を始めたばかりのメンバーとのコミュニケーションは大変だが、これをさぼると自分に返ってくる。採用するのは戦力になるメンバーを増やすため。すると、最終的に目指すべき状態は一人で仕事を最初から最後まで進められることであるはず。放置すればするほど時間が無駄になっていく。¹

最初は定期的に確認ポイントをもうけ、強制的に状況を確認した方が良い。明後日の方向に進むと切り戻しが大変である。

放置した結果の具体的な事例はこのすみ堂さんのエンジニアアンチパターンNEXT11章の内容を参照した。

必要以上に介護しない

具体例として、バグのチケットがトレーニーに割り当てられたときを考える。バグを修正するフローは大まかに6つに立てられる。

原因調査
修正案を立てる
修正
テスト
レビュー
- 1~4についての説明
- 質問に対する受け答え
リリース

ここで、3だけトレーニーに実施してもらう、という仕事の割り当て方は絶対やらないように気をつけた。理由は放置すると同様で、最後に一人で仕事ができるようになる = 1〜6までの経験が必要だからである。 6については環境次第で、OJT終了後のちゃんと責任を持てる状態となった後の方が良いと思う。ただ、1〜5はトレーニーに最初から全て任せる。タスクに慣れたらではないのがポイント。

やったことがない仕事であれば、今までトレーナーが行った仕事を例に出し「自分はこのように調査する」と説明する。そして「過去の取り組みを見ながらやってみて」と伝えて見守る。最初は試行錯誤したり、非効率的なやり方をしたりするかもしれない。しかしグッと堪えてメモを取っておく。途中で強制的に軌道修正すると、自分がやったんだぞ！感がなくなってしまう。それがないと自信がつかず、いつまでたっても自立できない。

重要なのはトレーナーが普段から「人に参考にしてもらえるクオリティで仕事をする」こと、「その仕事の経緯を人から見える状態にしておくこと」だと思う。チケットを使っているのであれば、検討事項のメモやタスクをTODO分解してコメントに残すと良い。最初に参考情報として送ると、トレーニーも自然と真似するようになる。より良い方法を見つけていたらトレーナーも真似できる。

資産を作るつもりで仕事をすれば、仕事自体のクオリティも上がる。自分が楽をするために仕事をする気持ちで取り組むと良い。

次のアクションが見えないフィードバックをしない

振り返りなどでトレーニーに指摘をする場合、改善内容が分かりにくいフィードバックをしないように心がけている。逆の立場で考えると分かりやすいが、何を修正するべきかわからないとどうしようもない。自分がトレーニーだったら「なんかうるさいなあ…結局どうすればいいんだ」で終わってしまう。

例えば真っ白なPull Requestが出てきて注意する場合、次のフィードバックは最悪である。

Pull Requestを出すときはしっかり内容を書いてください。

これは内容がないフィードバックである。しっかりってなんだよ、と思ってしまう。しっかり・ちゃんと、などは何か説明しているようでしていない。5W1Hを記載する。

Pull Requestには次の内容を含めてください。

仕様変更を行う際、変更内容を見返すことは多いです。
このとき「何を、どのような意図で変更したのか」がわからないと仕様変更時にコードを修正して良いのか判断できず、困ってしまいます。

## 変更内容

このPull Requestでどんな変更が行われるか説明します。
今回の変更では「〜〜〜〜」のような内容を記載することが望ましいです。

## 動作確認内容

どのようなテストを実施したか記載します。
変更後にあるべき動作要件を理解しているか、動作要件を満たしているかを確認するために利用します。
ここは検討して記載いただきたいです。

## 補足

気になる点や重点的に確認してもらいたい点があれば記載します。
GitHubのコメント機能を使っても良いでしょう。

## 参考リンク

- https://applis.io/posts/how-to-write-git-pull-request
- https://notepm.jp/template/pull-request

修正すべき点には「なぜそうしてほしいのか」理由を含める。