こんにちは！バクラク事業部 電子帳簿保存のエンジニアリングマネージャーをしている菊池 (@kichion)です。最近3歳の息子に「パパァ〜、そんなこともできないのぉ〜、ふふふっ」となじられることに快感を覚えているこの頃です。
この記事はLayerXテックアドカレ（概念）の50日目の記事です。昨日は id:sadayoshi_tada さんの「re:Invent2023 で登場した AWS Backup Restore testing でリストア検証を手軽に始める」をお届けしました。11月から始まったテックブログのリレーもゴールです。
私は2023年4月に入社して、7月にエンジニアリングマネージャーとしてプレイヤーとしても活動するような立ち回りを行ってきました。そんな中で「立ち上がりが早い！」と評価頂けており、改めて入社した直後からどういう活動をしていたのかを振り返る機会があったのでその内容を書き残そうと思います。 年の瀬でこの記事をご覧になっている方の中には「来年から新天地で頑張ります…！」と意気込んでいる人もいるでしょう。そんな方々の糧になれば幸いです。
オンボーディングの目的
船や飛行機への搭乗を意味する「on-board」を由来とした入社員の受け入れをサポートする取り組みをオンボーディングといい、新入社員を早期に戦力化・定着率向上が目的にされています。概ね3ヶ月程度の期間でOJTやコンテンツ消化をしてもらいこの目的が達成されるようにします。
オンボーディングしてもらう難しさ
しかし、新入社員が「戦力になったか？」「定着したか？」なんてことは気にせず対象の期間が終わってしまうこともあったり、それぞれのスキルやコンテキストにあったオンボーディングコンテンツが充実しているかどうかは企業のフェーズによりけりです。また、前職との企業文化の違いで苦労したり、採用ポジションがリーダーやマネージャーと言った人たちで無意識にお手並み拝見のようになってしまって達成できなかったという話も少なくありません。
オンボーディングの完了定義も曖昧で、なんとなく「コミュニケーション量を増やす」「コンテンツを多く用意して消化してもらう」と言った受け入れコスト増な施策が多くなってしまう問題もはらんでいると思います。
エンジニアのオンボーディング
ソフトウェアエンジニアのオンボーディングでは以下の知識獲得に多くの時間を費やします。
- 使用開発言語の知識
- ドメイン知識
- プロダクト固有の問題
- チームでの運用方法の理解
特に「ドメイン知識」や「プロダクト固有の問題」は範囲が広くなったり暗黙知が多いため、獲得に時間と機会を多く要します。オンボーディングをする側とされる側の両方向からこの溝をどう埋めるか？が早期の立ち上がりで重要です。
行っていた取り組み
バクラクで使用されている開発言語については前職までの経験で充足していましたし、配属された電子帳簿保存のプロダクトはチーム組成から日が浅く、運用方法もこれから積み上げていくというフェーズだったのでオンボーディングはほぼ必要のない状態でした。
データ構造の俯瞰から始める
データとデータモデルは知識の宝庫です。RDBを使用している場合はデータベース・テーブル群を俯瞰して見ることでドメインモデルの解像度が高くなるケースも多く、歴史的経緯で歪んだユビキタス言語を見つけることもできます。例えば、バクラク電子帳簿帳簿では「フォルダ」という機能は存在しませんが、開発の試行錯誤の最中に「フォルダ」が生まれて今は別の名前で機能提供されているというのがわかったりします。また、各テーブルで表現される関連やID群を列挙するだけでもプロダクトの登場人物がインデックスされて、仕様を詰めたりする材料になります。ドメイン知識やプロダクト固有の情報を収集し、プロダクトチームで飛び交う単語と実装のマッピングを最優先することでその後の「わからない」を減らすことができます。
あえて重たいタスクを持つ
今の自分でも無理なく消化できるタスクを持つというのも大事ですが、ここではあえて消化不良を起こしそうくらい重たいタスクを持つことにしました。重たい = 緊急度・重要度が高い場合も多く、そこに隠れたプロダクトの思惑やユーザの強いニーズを実感しやすいためです。 バクラク電子帳簿帳簿の「拡張機能」の実装がそれに該当し、以下のような仕様でした。
- 書類の項目を自由に追加できる
- 項目の種別も選択できる
単純に自由度の高い設計と実装で解決することもできますが、スコープのコントロールを誤ると顧客に使われないだけでなく技術的な負債として末代まで呪われる可能性があります。明確にスコープを定めるために
- 顧客の要望を的確に捉える
- 顧客の達成したい状態を見定める
- 必要十分な機能提供を定義する
- その後に拡張する場合でもネックにならないように設計する
と言った視点が必要になるため、広くインプットする必要があります。個人的に「パラシュート勉強法」に近いやり方が知識の定着率も高くなると考えているため、いろいろやらなければならない状態を作ることが重要でした。
エラー・インシデントにすぐに反応する
エラー通知やインシデントは見ているだけで憂鬱になります。しかし、プロダクトの現状を赤裸々に見れるタイミングでもあるので積極的に反応をしました。エラーやインシデントが多く発生しているということは顧客が使っている機能が品質上の問題があるので中長期的な改善の優先度が上がります。アーキテクチャ特性や構造を実感できるポイントでもあるのでわからないなりにソルバーとして問題に向き合うことは積極的に行いました。
社内外を問わずお問い合わせ内容を多く見る
社内のセールスでやりとりされているSlackのやり取りなども多く見るようにします。同じ箇所への質問が多い場合はプロダクトの認知負荷やドメインの認知負荷が高く、解決するしないに関わらず向き合わなければならない難しさがあります。不具合かも？と言った報告でも認知負荷が高い、仕様バグ、ほんとに不具合を早期に発見できる大事なアラートです。お問い合わせに向き合うことはプロダクトとその顧客の解像度をより高めてくれます。
プロダクトが求められていることを言語化してみる
上記の立ち回りで少しでも洞察が得られてくると「プロダクトの広がりとしてこんな方向もありでは…？」という発想が生まれてきます。その拙い内容をSlackで素朴な疑問 = そぼぎ*1として投げ込んであえてカオスを生み出します。すると、「その道はすでに通った」「新しい発想だがこういう部分とコンフリクトする」などの意見をもらえて今の結果に至る経路を感じることができます。その積み上げをチームとして認識することでよりロスの少ないコミュニケーションが行えるようになると考えています。
以下のnoteが個人的に好きで、上記の発想に至るきっかけをもらえています。 note.com
オンボーディングを支える施策の数々
上記の個人的な取り組み以前にLayerXでは多くの情報が公開されており、プロダクトや顧客の解像度を上げるためのハードルは低いです。その思想は羅針盤の中でも上位に位置する「情報を透明・オープンにする」から来ています。
汎用メモ
整理の必要がないデータベースで、公開できることなら何でも書くことができ、全員がアクセス権限を持ちます
技術的なメモから採用関連の学び、「面白いとは何か」というポエム調のものまであります。それぞれの思考や経緯なども書き残されているのでたくさんのヒントが積み上がっています。
商談動画
顧客の承諾を得て録画されている商談の動画も数多く残されており、機能リリースに対して喜ばれている姿や熱量高く要望をしている生々しい姿も見れます。各プロダクトごとに本当に数多くの動画が残されており、必要に応じて必見級の動画が共有されたりもするので真摯に向き合ってくださっているセールス・CSの方には感謝しかないです。
ADR・Design Docs
LayerXでは技術選定や技術的な決定に即してADRやDesign Docsを残すようになっているので、なぜこの技術選定なのか？に対しての検索が容易です。各サービスが独立している状態だが連携するというコンパウンドスタートアップならではの情報摂取も必要になるので非常に大切なストック情報です。以下のDevOpsチームのブログでも垣間見える施策があります。
まとめ
オンボーディングされる側としての立ち回りと弊社のオンボーディングを支える施策について紹介させていただきました。情報を多く摂るという側面でエンジニアに関わらず参考になれば良いなと思っています。LayerXとしてオンボーディングすべてが良好というわけではなく情報量が多くなっているので見る側の選球眼のようなものが試されている状態は事実あるのです。まだまだ仕組みとして充実させていく部分が多いですが、やりがいは多いと思います。本記事を通して活躍される方が社内外増えたら嬉しいです。
LayerXではお客様のハタラクをバクラクにするプロダクトを一緒に開発する仲間を大募集中です！LayerX Casual Night というプロダクトやチーム、技術の話をゆる〜く行うイベントも開催しておりますので、興味を持たれた方はぜひご参加ください！次回は2024/1/30(火)開催で、日本酒 Nightです。
*1:そぼぎについては弊社のmiyachan-sanがnoteでまとめてくれています「そぼぎ」「雑」「シュッ」｜miyachan
