新しい会社に入社して3ヶ月が経過した。
所属先はクオーターごとに評価のフィードバックを得ることができる。マネージャーや複数のチームメンバーからは、スムーズにオンボーディング(ないし、キャッチアップ)ができたという意見を貰った。
オンボーディングに関してやったことは前職のときから実践しており、今の会社で目新しいことはやっていないのだけど、評価をしてもらうことができた。
エンジニアになった当初はどのようにオンボーディングしていくかかなり悩んだので、スムーズにできるようになったことは嬉しいし、せっかくなのでノウハウを書き留めておく。
前置き：昔の自分はどうだったか？
自分は3年前にIT業界未経験、エンジニア未経験の状態でこの世界に入った。
ビジネスのことも技術のこともわからず、仕事をまともに進めることができなかった。
アサインされたタスクを自分なりに進めてみるものの、最後の方までやったあとで仕様と齟齬があることが判明し、1からやり直しになることもあった。
とにかく戦力になれている感覚がなく、周りに迷惑をかけてばかりで、無性に申し訳無さと恥ずかしさを感じていた。エンジニアになったことを後悔すらしたこともあった。
この申し訳無さと恥ずかしさをできるだけ短期間で解消するべく、試行錯誤をして今の考えに至った。
オンボーディングについては昔から考えていて、エンジニア1年目の前職時代に記事を書いた。
blog.agile.esm.co.jp
この記事の内容と今の考えに乖離があるわけではないが、当時より少しパワーアップした現段階で同じテーマについてより深く書いていきたい。
初めの3ヶ月は負荷を上げる
初めの1~3ヶ月のオンボーディング期間で、チームメンバーから得られる信頼が決まると言っても過言ではないと思う。この信頼によってこの後の仕事の進めやすさが絶大に変わる。
そのため、オンボーディング期間は業務外の時間もキャッチアップに充てることがある。短期的な負荷は高まるが、オンボーディングがスムーズにできれば長期的に働きやすくなる実感があるため、そこは割り切ってやっている。
もちろん、業務時間内だけで完結できればよいのだけれども、自分は要領が悪い方なので、要領が悪いなりに周りの人より時間を多く注ぐというアプローチで解決している。
膨大なインプットとアウトプットを意識する
オンボーディング期間は新しい知識が膨大に必要となる。このために、参画したプロジェクトのドキュメントや担当サービスのソースコードはすべて読んでおく。
これらのインプットは今後のために重要ではある一方、加えてアウトプットをすることで高いインプットへ昇華できる。
環境構築のドキュメントを例にすると、
- 環境構築で詰まった点と解消法を追記する
- 公式のドキュメントやわかりやすい解説記事のリンクを貼る
- リンク切れのリンクを貼り替える
など、色々とできることはある。これらを修正した旨をチームメンバーへ共有し、自分の対応の方向性についてフィードバックを得ることで、環境構築に対してより高い解像度で理解をできる。単にドキュメントを読むよりもインプット効率が高いし、チームへのアウトプットも兼ねられる。
こまめに作業方針の相談をする
新しい会社では、自分の携わってきた業務とは異なる前提が適用されていることが多い。
特に初期のタスクでは認識の齟齬が起きやいため、タスクがアサインされたら作業を棚卸して、チームへ方針の相談をする。
「この方針で進めようと思っておりそのためにはA,B,Cの3つの作業が必要と認識しているが、齟齬ないでしょうか？」
といった形で確認する。すると、チームメンバーからは作業漏れや方針のズレを指摘してもらえたり、会社固有のお作法を教えてもらえたりして、このあとの作業の手戻りを大幅に減らすことができる。
今の会社の場合、大きな機能開発の場合はDesign Docを作るという文化があり、こうしたことを教えてもらった。
データとドメインの関係性を理解する
データストア(RDBやNoSQL)のデータ構造とドメインの関係性を理解しておくと、仕様や実装面からディスカッションに参加しやすくなる。
Graphvizなどを使って、DBスキーマからER図を自動で生成するのもおすすめ。
スキーマファイルからテーブル構造を把握し、テーブル間のリレーションやテーブルやカラムの持つドメイン的な意味を一通り理解しておく。
自分の場合は、理解したことをアウトプットとして残すためにTable Listというドキュメントを社内向けに作成した。このドキュメントは、対象のアプリケーションのすべてのテーブルを網羅しており、
- カラムとドメインの関連性
- テーブルを操作・参照するビジネス要件
などを記載したもので、自分の次にオンボーディングをする方にとって有用であると考え作成した。
チーム内からの評判は概ね良好で、「このドキュメントを参照したら他チームからの問い合わせにすぐ応えられた」、なんていうフィードバックをもらうことまでできた。
依存ライブラリの調査をする
アプリケーションを開発する場合、依存ライブラリを使用するケースが多い。
機能改修をする際に、ライブラリの使い方がよくわらかない、誤認していた等によって開発を効率的に進められないと困る。
なので、使い方がわからない依存ライブラリはすべて調べておく。
Goならば、 go.modファイルを見ればすべての依存ライブラリが記載されているので、一通り公式ドキュメントを読み、よくわからなければ解説記事を読み、また公式ドキュメントを読むといったこと繰り返す。
依存ライブラリの使い方がわかった上で、アプリケーションにおいてどのように使うのかがわからないときは、同僚を捕まえて根掘り葉掘り聞く。
特に、
- Test
- Mock
- Lint
- Web Framework
- Generating Code
あたりのライブラリを知っておく効用は高い。
Goだと、godocコマンドでlocalにドキュメント用のサーバーを立ち上げて全体感を把握するのもよい。
技術スタックについて幅広くインプットする
幅広く技術を知っておくことで、既存のソースコードに対して今後のリアーキテクチャ案やリファクタリング案が浮かぶことが多い。これによって、技術的なディスカッションに深く入っていくことができる。
これは、自分が今後テックリードのロールを目指しているために実践していることとも言える。
自分の場合は、下記の技術についてそれぞれ技術書数冊と関連のドキュメントを読んだ。
改善提案をする
新規参画者ならではの視点で、改善提案できることはいくつもある。
もちろん、既存のやりかたにもメリットはあるので、伝え方には気をつける。
自分の場合はスクラムイベントの振り返りの場でこうした課題やアイディアを共有するようにしている。
すでに、
- Jiraのチケット運用
- ドキュメントのレビューフロー
- GitHub ActionsによるCI/CD
などについての課題感を共有し、改善までやりきった。
ペアプログラミングによって開発プロセスを効率的に共有できる。
会社やチームごとにソフトウェアの開発プロセスは異なることが多い。そこで、ペアプログラミングをしてもらい機能開発からデプロイまで含めた一連の開発フローを体験させてもらう。
今のチームではペアプログラミングが常習化していなかったので、「このデプロイ作業一緒に見させてもらえないですか？」といった具合に、先輩の作業を見させてもらう場を積極的に作ったりした。
Kubernetes環境にSpinnakerを利用してデプロイする作業があるのだけど、ペア作業で見させてもらったおかげで、「デプロイするのは案外簡単だな」ということがわかった。
参考
エンジニアのオンボーディングというテーマを考えるにあたり、特に参考にさせてもらった記事はこちら。
https://qiita.com/jnchito/items/017487cd882091494298
https://note.com/hik0107/n/n1d7b93c57cdd
最後に
エンジニアとしてのオンボーディングについて、複数の会社で通用するような再現性の高いやり方が定着してきた。
今のやり方に執着せず、常にアップデートしていきたい。
