確か一昨年（2021年）の7月だったと思う...新卒が配属される前日の夕方ごろに、OJTのメンターになって欲しいと連絡があった。今思えば何も準備できていなかったが、OJTで僕ができる限りやろうと思ったことを残しておこうと思う。
OJTで実施したこと
チームで開発しているシステムは、明らかに初心者に厳しく学習コストがとても高いもの難易度が高いアーキテクチャだった。 ある程度の力量があるとはいえ、いきなり現場に入れて稼働をとることは不可能だと考え可能な限り現場に溶け込めるようにした。
- 定期的に実施したこと
- 朝会
- 1on1
- 振り返り
- 開発関連
- 本番環境に近いRepositoryでの課題
- 小さい案件に着手する
- チームで触れる技術の勉強会
- コミュニケーション関連
- 新卒の子専用のチャンネルの作成
- わからないことを否定しない
定期的に実施したこと
新卒の子のコンディションと進捗、育成状態、仕事を振ることができるかどうか見極めるために、定期的に実施していた。 僕自身は、無駄な時間を使うことに大反対だった（会社的には多かった）ので、作業に集中できるように必要最低限だがフォローできる状態を作っていた。
朝会
最初は、研修用の課題があったのと、人事から課題が出ていたため進捗を把握する意図で行っていた。 ただ、新卒の子は自分で時間管理ができていた（僕が朝会の存在が嫌いだった）ので、確か3週間たったあたりには不要と判断してやめた。
今振り返ってみて
最初は朝会が必要だと思うけど、業務に割り当てられるタイミングで専用の朝会は解除しても良いと思う。性格や作業の進め方次第でも検討しても良いと思う。主に、0~10までの説明がないと動けない人は必須で行なったほうが良い。
1on1
1on1では、以下のことを確認するために毎週行っていた。
- メンタル状況の確認
- モチベーションによる影響の確認
- プライベートでの出来事による影響
- 新卒が持っている全社的な業務による、本業務への影響の確認
- タスクの細かい進捗確認
- 抱えている疑問の確認
メンタルの状態や自分が触れていない範囲外のことはしっかり確認するようにしていた。技術的な疑問などは、別途時間を取った上で説明をしていた。タスクについては、すぐに解消できるように適宜Slackのハドルを使いサポートをしていた。
今振り返ってみて
とても話しやすい雰囲気があったと聞いていたので、心理的安全性は担保されていたと考えられる。一年後にヒアリングしてみたら、この時のサポートがあったから信頼しているとの話も聞いたのでやって良かったと思う。本音で話せる先輩がいるって大事だよね😌
振り返り
振り返りは週一で行い、必ずゲストを召喚して3人（自分、新卒の子、関係者）で行うようにしていた。
振り返りには、KPTではなくProud & Sorryをやっていた。内容は必ずドキュメントとして残し上司が閲覧できる状態を作っていた。
KPTは、改善する振り返りのツールとして優秀ではあるが Kの部分が一時的なもので機能していないことが多かった。KPTは自身に対して目を向けているものであったため今回は採用しなかった。
Proud & Sorryとは？
友人に教えてもらったもので、私自身どこから生まれたものなのかが全くわからない。
目的として、自己開示と理解、自身の自己肯定感を高め、関係者への理解、参加者からの意見をもとに改善に努めることに狙いがある。
つまり、関係者を観察させ、承認をすることでチームへの所属意識を芽生えさせたいということ。
進め方
- ProudとSorryを付箋か箇条書きで記入する（大体 10min）
- Proudでは、 自分自身の行動で良かったこと、関係者の動きで感謝したい良かったことを箇条書きか付箋にして記載する
- Sorryでは、 自分自身の行動で悔しかった、後悔していることを箇条書きか付箋にして記載する
- 参加者全員のProud & Sorryを一人一人読み上げ、コメントを加える
- コメントを文章に残せるとなおよし
今振り返ってみて
個人的には上手く機能していたと思っている。ゲストは毎週人を変えて様々な意見を得られる状態を作り出すことができていたし、毎回新しい意見が出て新卒の子が吸収できる状態が出来上がっていた。ただ、普段からこのようなものに意見を真面目に書かないや、人と向き合わない人は呼ばないほうが良いなと思った。力を入れない人から得られるフィードバックはない。
開発関連
もちろんエンジニアの新卒なので開発できるようにならないといけないのでそのサポートはたくさん行なった。
本番環境に近いRepositoryでの課題
これまでの研修で使われていた本番環境で利用しているコードの一部を持ってきたもの。自分の方で研修資料を用意できなかったので臨時で使用した。
今振り返ってみて
うん、微妙！新卒にいきなりこれを使って勉強してね！と言われて出来るかと言われると微妙...しかもメンテされていない....。 なので次年度のために新しく研修用のRepositoryを作成して、本当に初心者が学べる環境を作った。その上で、新しいリポジトリを使うようにした。
小さい案件に着手する
当たり前の話だけど、研修の資料が終わったら業務を行なってもらうことにした。チケットには影響範囲と大凡の修正箇所のヒントを記載して、期間的に余裕のあるタスクをアサインした。 最初は、頭出しのミーティングを行い、修正箇所を一緒に探すフェーズを用意した。徐々に自分で考えるように促し出来るようにした。
今振り返ってみて
当時見ていた子にはとても良かった。というのも、少し教えたら自分で考えて、疑問があれば質問ができる子だったからとてもやりやすかった。 その後 0 ~ 10まで説明しないと動けない子の場合には上手くマッチしなかった。その子の時は、チケットにヒントではなく答え記入してなぜここを修正するのかを頭出しのミーテインングで処理の流れを含めて説明するようにした。 この時初めて、人間には話を汲み取る能力に差があることを知った。その後、この能力差に苦しめられることになる。
チームで触れる技術の勉強会
自分のタスクに余裕がある時に、週一ペースで自分が知っている技術の話をざっくばらんにした。自分のチームには、このようなメンバーが学ぶような教材が全くなく業務をする上で覚えていくしかなかった。その影響でこれまでの新卒は、現場で学んだこと以上のこと知らなかったし、学ぶこともなかった。
- フロントエンドの歴史
- ブラウザ歴史
- CSSの歴史
- バージョンと設計
- JSの歴史
- MVCなどのアーキテクチャの話
- オブジェクト指向とSOLID
- アクセシビリティの話
- HTTPとHTTPS関連の話
- コーディング規約
今振り返ってみて
結論から述べると、かなり好評だった。（他のメンバーも参加したいというほどに）ただ、資料を用意せず口頭で話したので、まとまりがない説明となってしまったことは反省すべきと思っている。その副作用？として、どのサイトを参考にしているのかや、調べ方を教える機会になっている事実もあるが...副作用のおかげで、OSS関連で疑問があった時の調査力は抜群に持っている状態であった。
コミュニケーション関連
新卒の子専用のチャンネルの作成
Slack上のオープンなチャンネルで、新卒の子が質問できるチャンネルを作った。新卒である間はここで、積極的に質問をして業務に必要な知識を得る状態を作ろうとした。また、ここで行なった質問は来期の後輩が検索できるようになる意図もある。 質問に対して急ぎであれば極力ハドルで行うようにしていた。定期的なミーティングであればZoomで良いが、ハドルは即時に行う会話にはとても強力だった。 個人的な理由ではあるが、このチャンネルの告知は行わなかった。告知して人が集まると人目を気にして発言がしづらくなることが過去にあったからだ。みんなに触れた方が良いという人もいるが、それは別の場でやれば良い。
振り返ってみて
ハドルで書いた内容を文字に起こせば良して認識の確認のようなものができる状態にできれば良かったと後悔している。ハドルで大事なことを伝えたが、Slack上のやり取りとして残っていないので、解決方法や知識が検索できない問題があった。
わからないことを否定しない
教育関連の書籍であればどこでも出てきそうな話である。質問の返答に「なぜわからないの？」や「前にも説明したよね？」のようなことは、絶対に言わなかった。内心何度も思ったとしても我慢して言わなかった。言った瞬間に、この人に質問するのやめようと思うからだ。私自身が、質問しなくなった原因でもあったので絶対に行わないようにした。おかげさまで、疑問点があれば調べた上で質問を積極的にしてくれるようになった。若干責められている姿勢を感じることがあるが、認識の齟齬で事故が起こる仕事なのでちょうど良いのかもしれない。
終わりに
この記事を新卒のOJTが終わった2年前からずっとドラフトに入れたまま書いていた。何度か手直しをし、文章も何度も変わっている。おかげで書くのが遅くなった。この記事をずっと公開しない間に、新卒の子が今年の新卒を見ることになった。私がその子のためにやったことを実践しチームに合わせてアップデートしている。あの頃のあの子も今はとても頼もしい先輩として大きく成長した。
