エンジニアリングマネージャーをしています、芦川です。
2025-02-26 にD-Plus Tokyo #11~受けてよかった！自分が受けたい！オンボーディング Part2にて、社内で実施している業務ドメイン知識のオンボーディングの話をしてきましたので、ブログも書きたいと思います。（発表スライドはこちらです。）
20年も同じ会社にいれば、そこで初めて実感することがいくつかあります。今回もその中の1つで、プロダクトの寿命の長さや、プロダクトに関わるエンジニアの期間などの観点も含めて、オンボーディングの大事さについて触れたいと思います。
結論
この図が最も伝えたいことなので、先に示しておきます。
- プロダクトを開発し、お客様に長くご利用いただくために、より便利な機能や体験を提供していきます。
- より便利な機能や体験というものは、メールを送ったり、物流を通してモノを送ったり、決済手段を増やしたりと、プロダクトの周辺にものが増えてきます。これは、要するに、業務ドメイン知識です。
- 一方で、一般的にエンジニアはプロダクト全体の寿命に比べると携わる期間は短いものです。なので、これからもそのプロダクトを成長させるためには、開発に早く携われるようにしないといけません。
- プロダクトを成長させるための開発は、単なるコーディング・テスト・デプロイという単純なものではなく、現在のお客様の体験を理解し、それを支えている仕組みを知らないといけません。つまり、周囲のものも含めて業務ドメイン知識の吸収が必要です。
- そこで、業務ドメイン知識のオンボーディングが必要になり、うまくこの循環が回れば、よりプロダクトを成長させるサイクルを早くできると考えることができます。
で、業務ドメイン知識のコンテンツの作り方については記事後半にありますので、もしよろしければ、ご参考ください。
さてここからは、スライドからの抜粋と補足説明をしていきたいと思います。
ニフティの歴史は長く、10年以上続いているプロダクトも多数あります
ISP事業は、すでに社会インフラとなっているのも関係しそうですが、長らくお客様にお使いいただける傾向があります。
そして、ISP的な仕組みの業務ドメイン知識とは別に、プロダクトが成長していくと、その周辺にいろいろなシステムが増えていきます。上の図はイメージですが、他にもSMSを送ったり、決済手段が増えたりといろいろあります。
そもそもオンボーディングで目指したいレベルは？
徐々にオンボーディングの話に移りますが、まず目指したいレベル感を明確にしてみると、単なる「開発できるようになる」ではなく、「お客様のために開発できるようになる」をどうせなら目指したいと思います。お客様のために、というからには、お客様が現在どんな体験をしていて、それをささえる周辺のシステムはどのようになっているかわかっている状態が望ましいです。
プロダクトの寿命と1人のエンジニアが携わる期間について
で、次は時間軸で考えてみたいと思います。ある1つのプロダクトの寿命というものを時間軸として切り取り、そこに会社やエンジニアのそれぞれの時間軸をタイムラインとしてプロットしてみます。
ある１つのプロダクトの寿命に比べ、1人のエンジニアが関わる時間は一般的に短く、イメージとしてはこんな感じかと思います。キャリアチェンジや入退社など様々な理由で、結果としてこのようになります。
なので、今いるエンジニアは将来入ってくるエンジニアのことを思い、ソースコード、ドキュメントを作ることが大事であり、読みやすいコード、シンプルな設計、意図がわかるドキュメントなど、いろいろ残しておかないといけないことになります。何をどう残すかみたいな話はいろいろ話したいことがあるのですが、今日の主題はここではなく、新たにジョインする人の話にフォーカスすると、そういうものをいち早く吸収して、プロダクトを成長させるための知識を得ないといけなく、その早さが大事になるということがわかります。
目指したい好循環
つまり、これまで説明したことをあわせると、こういう循環ができると思います。
プロダクトが成長すると、周辺にものが増えてきます、これは業務ドメイン知識と同義です。エンジニアはプロダクト時間軸に対してかなり早く入れ替わりが発生するため、よりプロダクトを成長させる開発ができるようには、早く育てる必要があります。で、オンボーディングで目指したいのは、ただ単に開発とテストとデプロイができるようになることだけではなく、プロダクトをグロースさせるために必要な周辺知識を知ってほしいと思います。つまり、どんなお客様が使っているのか？お客様体験をささえている周辺の仕組みはどのようになっているのか、ということです。それらを知っていることで、プロダクトの成長を見据えた開発、もっとアイデアが出たり何かを効率化したり、ということができてくるのかな、と考えています。
以上が、ドメイン知識のオンボーディングをすることにより、エンジニアの成長を早め、継続的にプロダクトの成長を促す好循環をもたらしていく、という説明でした。
どうやってドメイン知識のオンボーディングコンテンツを作ったか？
ここからはオンボーディングコンテンツ作成の話です。上のスライドにあるような順番で作成していきました。社内にいるドメイン知識のマスターたち（一番知ってそうな方）にお声がけしていき、それぞれのドメインでの担当者を決めて約1時間くらいの講義 / 小テスト 形式で、コンテンツを作成していただきました。さらにすべての講義については録画をすべて取り、今後ジョインする方々がすぐに閲覧できるようにしました。コンテンツについては、たいてい社内に既存のドキュメントがあるため、そこへのリンク集のような形で話の流れをまとめてもらう1ページのような想定です。
とてもじゃないですが、細かいところまで知ろうとすると非常に時間がかかることになり難しくなると思うので、浅く広く知ってもらうことを重視する考え方です。濃さの調整ですが、あるドメイン知識の講義時間を1時間確保するので、その中で伝えられる程度にしてください、と先に時間制限を設けました。
コンテンツはでき次第、講義を開催していき、既存メンバーに対して教育していきます。
結果的に、各ドメイン知識ごとに、ドキュメントの URL やビデオ集のページが作成されます！
すばらしい、これは宝です。
あとは、新しくジョインしていただいた方に漏れなくこのコンテンツが伝わるよう、Slackワークフローを使って自動的にメッセージが飛ぶように仕掛けました。
最後に
長期的なプロダクトの成長を支えるためには、技術力と業務知識の両方が不可欠です。特に、プロダクトの寿命が長く、複雑な業務知識が必要な場合、この両輪のバランスが重要になってきます。
私の経験から、効果的なオンボーディングとは、単なる技術スキルの学習ではなく、プロダクトを取り巻く業務全体への理解を深める機会なのだと思います。プロダクトを成長させるエンジニアは、コードを書くスキルと同じくらい、ビジネスや業務への深い理解が求められていると思います。
というところで、以上、プロダクトの成長を継続的に促すには「技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話」でした。
