エンジニアは転職機会が比較的多い。
オンボーディングの方法は各社まちまちだろうが、入社側の心づもりは自分の中で一貫して育てられる。

最近、自身含めて周辺で入社してすぐの動きに関しての話題が多かったので、今の考えをまとめておきたい。

ドキュメントがよくわからない、抜けている

これはほぼ必ず聞く。
オンボーディングドキュメントのメンテナンスは後回しにされることが多い。
採用が活発で、利用頻度が高ければ毎回聞かれることをドキュメント化するメリットがあるが、そうでない場合は聞いてもらったほうがコスパが良いので内容が古くなりがちになる。

この背景を踏まえると、「ドキュメントおかしかったので直しておきました。レビューお願いします。」みたいなコミュニケーションは受け入れ側からすると非常にありがたい動きになる。

少なくとも指摘すると、修正されて後続の人が困りにくくなる。
ただし、この場合も指摘にとどまらず、教えてもらって自分で修正作業も請け負う姿勢の方が価値は高いと思う。

この話はそのドキュメントが今後もそのまま使えるかどうかという長期的な部分は半分運に任せて、そういった姿勢でコミュニケーションを取ることでチームに馴染むのが早くなるという効果を短期的に期待できるかもしれない。

誰に・どこに質問したらいいのかわからない

気の利く人が偶然いてくれたり、採用時のメンター制度がしっかりしてる場合を除き、入社すぐの細かい疑問の解決方法に悩む場面をよく見る。

times 的なチャネルや日報に今日の作業内容と疑問の一覧を投稿することで、一定の解決につながる可能性がある。
他人のオンボーディングに完全につきっきりにはなれないが、気にはしてくれる優しい人は結構いる。
そういった人が自身の業務を終わらせて、日報を見たときに疑問が書いてあれば答えてくれる可能性がある。

また、そういった新しい視点での疑問は、製品ドメイン知識が当たり前になってしまった人からは不可逆な視点で実は価値が高いこともある。常識になってしまったことを疑う機会にする人や、何らかの発信のネタにしようと思い立つ人もいるかもしれない。

エンジニア以外の職種の人含め、聞こうと思っていたけど聞けていなかったことだった可能性もある。オープンに質問して回答を得るというのは、往々に自分以外にも効果がある。

まとめ

新しい人の集団に入ることは、どんな人にとっても大変なことだと思う。
重要なのはプラスの「かもしれない」をちゃんと認識しながら自分の行動の価値を上げることにある。

迷ったり、正論を指摘するだけで止まったりして現実は変わらないので、その瞬間小さなストレスを感じても行動に移すことが大切になる。このストレスのコストを相殺するメリットの可能性を考えれば動けるのではないだろうか。

実際にそのメリットがあったかどうかはどちらでもいい。行動の結果、最初は多少の迷惑がかかっても自分が動けるようになることが会社のメリットなのだし、なんなら迷惑よりもプラスの効用を生む機会にもできるという認識を持つのが大事だと思う。