OJTをやっていると方法を説明する・やって見せる機会が何回も出てくる。例えばGitでコンフリクトしたとき解消する方法だったり、エラーが起きていて解消できないため手伝う（解消する）、ツールの使い方を示すなど。ここで手順だけ教えて「次は一人でできるよな」と期待してしまうと失敗しやすい。
なぜうまくいかないのか
仕事の環境は不確実性が高い。2回全く同じパターンで対処できることはほとんどないため。少しでも違うと方法（手順）が再利用できないためやったことがないからできない、となってしまう。また説明する羽目になり全く改善が見られない状況が続いてしまう。
やる気がないのか？と感じてしまうが、トレーニー側は「次もできるようにならないと！」という気持ちがある1。トレーナー側が説明した手順を一から十までメモを取ったり、覚えようと試みる。しかし、手順をどうして使うのか？なぜその手順だとうまくいくのか？は頭に入っていない。手順を覚えることに夢中だから頭に入らない。
すると、場面が変わっているのに教えてもらった手順で押し通そうとしてしまう。手順と掠ってもいないと経験がないためお手上げになってしまう。それは期待していた効果と違うため、OJTトレーナー側と認識の齟齬が生じてトラブルになる。
どうすれば回避できるか
トレーナー側が工夫して回避するしかない。トレーニーは自分が手順を覚えようとしていることに気づかないため。まず重要なのは、手順を覚えようとしていないか見極めることである。どんなときも常に同じ方法で仕事を進めている場合、手順を遂行することに夢中になっていることが多い。場面が違うのでやり方を変えないといけないか、は経験がないとわからない。普段からトレーニーを観察する必要がある。
観察して兆候が見られた場合、トレーナー側に原因がないか内省する。説明のとき方法だけ提示していないか？をチェックする。Gitのコンフリクト解消を例にすると、手順だけしか説明していない場合と考え方も説明している場合には次のような差分がある。
手順だけ説明している場合
- コンフリクト解消に必要なコマンドだけ説明している
- コンフリクトを解消したら
git commitするなど、手順だけ説明している
- コンフリクトを解消したら
- コンフリクト解消をするときは片方または両方のブランチの変更を取り込む説明だけしている
- どこを確認するか、は手順の一種である
- コンフリクトしたとき初めに何を確認するべきか伝えている
- 何を、の部分しか頭に残らない
手順と考え方を説明している場合
- コンフリクトの解消手順だけではなく、なぜその流れになるのか説明している
- 順番にも意味があることを失敗例を交えつつ説明する
- コンフリクトを解消する際、どのような状態を目指さなければいけないかを説明している
- 自分の変更と、元々入っている変更を落としてはいけないこと・落としても良いのはわざと自分が変更を入れた部分のみであることを理由を添えて説明している
- コンフリクトしたときは初めに何を確認すべきか説明した後、なぜそれが必要なのか説明している
- 確認内容と理由をセットで説明する
同じ内容でも、理由や怠ったことによるデメリットを説明する。これを何回も繰り返すと、他の場面でも応用が効く。理由をセットにして説明するのが重要である。逆に理由を説明できないものを偉そうに講垂れてはいけないとすら思う。
理由と言って思いつかない場合、方法を実施したときにどんないいことがあるのか？どんな悪いことが起きるのか？を伝えると捉え直すと良い。それがないのであれば、個人の好みの範疇なので好きにするのが良い。
手順だけ説明して満足してしまうことが多いが、それだと本当の意味で身についてはいないため「何で説明したのにできないんだろう」となってしまいがち。理由を納得してもらえるまで説明し続けるのが必要。書いていて感じるが、OJTは根気との勝負だなと感じる。時代の流れに合わせて忌避されるのもわかる気がする。
- 話がややこしくなるので、あることにする。ない人はまた別の問題である。↩
