SREチームの中村です。2019年は弊社のエンジニア採用はありがたいことに好調で、たくさんのエンジニアに入社していただきました。2018年比で人数としては2倍近くになっています。
2019年のエンジニア採用戦略についてはVP of Engineeringによる以下の記事に詳しく載っていますのでぜひ御覧ください。
一緒にプロダクトを前に進める仲間が増えることは非常に嬉しいことです。しかし、新規メンバーを迎える側である我々が考えておくべき点がいくつかあります。
新しいエンジニアを迎えるときに考えておくこと
弊社が提供するプロダクト群はバーティカルSaaSです。バーティカルSaaSとしてのトレタについては、弊社代表の以下の記事に詳しく載っていますので、詳細はそちらを御覧ください。
バーティカルSaaSは特定の産業の課題に深くフォーカスしなければなりません。弊社の場合では、プロダクトを開発するエンジニアは「外食」という産業の構造理解が必須です。
よって、コードに書かれていること以外の部分で知っておかなければならない知識がたくさんあります。そのため、我々が作っているプロダクトの背景知識や存在意義、構築されているシステムの情報を整理しなければなりません。
具体的にプロダクト・システム観点から整理する情報を考えてみます。
個々のプロダクトがどのような課題を解決しているか？
「予約台帳」というプロダクトと「トレタNow」というプロダクトが解決している課題はそれぞれ異なります。新規メンバーに対して、個々のプロダクトが解決している課題について最初にインプットしてもらうことで、実際のプロダクトコードが「どんなユーザのどの課題を解決しているのか」について、具体的にイメージできるようになります。
プロダクト群がどのように連携しているか？
弊社は「課題解決を積み重ねた」プロダクト開発を行っています。つまり、「予約台帳」というプロダクトを基盤として、「トレタCC」や「トレタNow」というプロダクトが連携してさらなる価値を生むという戦略です。
これは、裏側ではプロダクトを構築するシステムやデータが相互に連携していることを意味します。よって新規メンバーに、「プロダクト間の連携方法はどうなっているか」、「データの流れはどうなっているか」を把握してもらう必要があります。
サービスの契約フロー
弊社のサービス契約フローでは、お客様がサービス契約となってから実際に飲食店で利用開始していただくまでにいくつかのステップが存在します。
例えばトレタの「アカウント発行」の業務は社内で行うので、それらはどのチームがどのような作業を実施しているのかについて社内向け管理画面を用いて理解する必要があります。社内向け管理画面は社内のほぼすべての人が利用する大事なアプリケーションで、この社内業務理解はSaaSアプリケーション開発者にとって非常に重要です。社内業務を改善することによって、お客様へのサービスのデリバリー時間を短縮することができます。
プロダクトごとのリクエストの質やピークタイム
主にSRE向けですが、各プロダクトが解決している課題や想定ユーザなどの情報をインプットしておくと、それぞれのリクエストの質やバッチの処理時間などがおおよそイメージできるようになります。
- 「法人数」や「店舗数」、「予約数」などのコアとなるデータのサイズ
- 毎日12時と18時周辺に予約確認する店舗が多いため、リクエストが多くなる
- 定期バッチ群がどんな処理を行っているか。キューイングされるジョブ数はどれくらいか
などの情報が該当します。
入社してから最初のPull Requestを作るまでの時間を短くする
これは一番わかりやすいと思います。各プロダクトコード内の開発環境やテストデータ、CIが継続的にメンテナンスされていると、新規メンバーもスムーズに開発に入れますし、モチベーションが高いまま最初のPull Requestを作ることができます。まずプロダクトにcommitしてもらい、達成感を感じてもらうのも大事だと思います。
Engineering Onboardingの設計
上記に考えたことを片手間で教えるのは難しい規模の組織になってきたので、情報を整理し、体系的にインプットする場を作る必要がありました。
そこで、今年から入社していただいた全エンジニアを対象に、Engineering Onboardingを実施するようにしました。具体的な施策としては以下を行いました。
プロダクト・技術スタック構成図の作成
まず最初に、個々のプロダクトの説明と、プロダクト群がどのように相互に接続されているかを表現したドキュメントを作成しました。このドキュメントは社内esaのトップページからリンクしてもらい、新規メンバーが必ず見る記事として育てることを目標にしました。
あえてプロダクトの詳細説明を書かずに「どんな課題を解決しているのか」のみを述べるようにしています。プロダクトの詳細な説明の記事や、プロダクトのURL、GitHubリポジトリへのリンクを乗せることで、「この記事から最低限全サービスの情報へアクセス可能」な状態を継続的に維持することを目指します。
開発・本番環境アクセス権限・各種SaaSアカウント発行整理
現在SREチーム主導で、開発チームで利用しているSaaSアカウントの権限管理やプランの整理を行っています。メインのプラットフォームとして使っているAWSは以下の記事によってAWS SSOが使えるようになったので、管理がとても簡単になりました。
まだ手動でinvitationを行う必要があるBugsnagやNew RelicなどのSaaSは、「社内の誰に問い合わせるのか」を整理しました。
アプリケーションコードやDBのリファクタリング
使われていないコードやDBのカラムは存在するだけで認知負荷が高まるので、可能な限り削除しました。また、DBの各カラムに「なんのためのデータ」なのかコメントを追加し、理解するための情報量を増やしました。
開発環境の整備
GitHubリポジトリのREADMEを読んで、そのままコマンドを実行すれば開発がすぐ可能になるようにdocker-composeやCIの整備を行いました。
Onboarding TODOリストの作成
この記事を読んで書いてある通りに進めればセットアップが完了します。と言えるようなドキュメントを作成しました。タスクリスト形式になっており、記事をコピーして自分で埋めていく形です。
- よく使うslackのチャンネルに入ってもらう
- 発行するSaaSアカウントの依頼
- プロダクト・技術スタック構成図への案内
- 開発環境の構築
- 開発用トレタアカウントの作成
- staging・productionのサーバ情報確認
Onboarding Process
今までは新規メンバーの入社時オリエンテーションが終わったあと、開発チームのメンバーがメンターになり一緒にセットアップを進めていたのですが、現在は以下のフローが確立してきました。
- 入社時オリエンテーション終了
- Onboarding TODOの記事をコピーし、タスクリストを埋めていく
- Engineering Onboardingへの参加
3ステップ目の「Engineering Onboarding」ですが、上記で作成したプロダクト・技術スタック構成図を使いながら、私から新規メンバーに対して全体的なプロダクト群に関する情報をインプットしてもらう会を行っています。
1時間 * 5回ほどに分けて、チームやプロダクト・システム構成について理解してもらいます。現在は私以外のメンバーも説明側と参加してもらっているので、一人あたりの負担はかなり軽減してきました。
まとめ
プロダクトが継続的に開発され歴史が積み重なってくると、コードを読んだり単純なドキュメントだけでは理解できない部分も多くなってきます。組織の面で見ても、人の入れ替わりがあったりすると、口頭で伝えられてきた歴史的経緯もどこかの時点失われてしまいます。
そのため、ある一定以上成長したスタートアップでは、Engineering Onboardingを整備して体系的なプロダクトについての説明を継続的に行っていくことが、安定して開発するために必要です。
今回の記事執筆時点では情報を整理しやすい部分から手を付けていきました。今後はさらにセットアップの自動化や各チームの自律性を高めて、スケールしやすいOnboardingを構築したいと考えています。
