はじめに
2022/1/1に株式会社プレックス(以下、プレックス)の2人目のエンジニアとして入社した種井です。
今回入社エントリを兼ねて、入社直後に行ったオンボーディング改善の取り組みを紹介しようと思います。
自己紹介
新卒でソーシャルゲームの会社の入社し、主にソーシャルゲームのサーバーサイドエンジニアとして開発・運用、新規事業部でiOSエンジニアとして開発に携わりました。
プレックス1人目のエンジニア、石塚とは新卒の同期でもあります。入社エントリ
その後、大学時代からの知人3名で会社を創業し、4年ほどスポーツ領域で事業検証や開発を繰り返しました。(スポーツ動画投稿プラットフォーム、クラブチーム向けSaaSなど)
退職した頃、石塚から声をかけてもらい、1ヶ月ほど業務委託として業務を行った後、今回プレックスに入社することを決めました。
プロフィール
出身: 三重県
実家: お寺
趣味: ランニング
今年の目標: バイクの大型免許を取ること,地元の駅伝で区間賞を取ること
入社を決めたポイント
石塚が入社エントリで紹介している内容とほぼ同意見です。
ここは、お互い一度起業した経験があることが大きいと思います。
- 物流・インフラ領域への興味・関心
- プロダクト開発に至るまでの事業検証のプロセスと解像度の高さへの共感
- 理念である「日本を動かす仕組みを作る」の通り、実際の業務上でも、会社文化としての仕組みづくり(組織や業務上の)への意識が高いこと
- 声をかけてもらった際に面談を重ねる中で、代表黒崎や石塚から、なぜ自分なのか、自分に対してどのような動きを期待しているのかを丁寧に伝えてもらったこと
などが入社を決めたポイントです。
本記事のテーマであるオンボーディング改善の取り組みも「仕組みづくり」の組織文化色が出ているかと思います。
オンボーディング改善の取り組み
今回、取り組んだオンボーディング改善は
入社後のオンボーディング期間を終えた後、1スプリント分をメインの開発から外れて、オンボーディング中で出た課題の改善時間として使ってもらう
というものです。
自分自身が受けたオンボーディングがきっかけでした。
入社前に事業や開発に関する資料やドキュメントを共有してもらい、事前に一読した上で入社後のオンボーディングを受けました。
既存のドキュメントでもスムーズにスプリントや、実装に入ることはできましたが、業務を行う中で自分がつまずいた点、次に新しい方が入った場合につまずきそうな点がいくつか出てきたので、その都度、改善案をメモに残しました。
週次の1on1(開発チームでは週次でPOやEMと1on1を実施しています。)で石塚にメモした内容を共有し、やっておいたほうがよさそうな改善項目に関してはタスクとしてバックログに残していきました。
1ヶ月間業務委託として実際に業務を行う中で、入社の意思が固まりました。最終週の石塚との1on1で入社の意思を伝え、入社が決まり次第、POや石塚にバックログに残した改善タスクをこのタイミングで実施してみたいと伝えたところ、快く「実際にやってみよう」と言ってもらうことができました。
その後、実施方法に関して議論を重ね、入社したメンバーが1スプリント分外れてオンボーディングを改善する取り組みを実際に行うことになりました。
具体的には、以下のようなステップで実施しました。
- 開発チーム全体でMTGを行い、オンボーディングへのフィードバックと改善タスクを共有する
- ビジネスサイドの改善タスクや歴史的背景の濃いものなど、自身で対応しにくいものはそれぞれ詳しいメンバーに担当を依頼する
- 1スプリント分、改善タスクのみを行う(2.で割り振りのあった各担当者もそのスプリント中に改善タスクを組み込みます)
その結果、開発業務が1スプリント分進まなくなるデメリットはあるものの
- 新しいメンバーしか気づけない課題やその解決策を入社直後でも挙げやすくする
- オンボーディングは発生する機会が少なく、改善サイクルを回しづらいので、少ない機会を最大限活用したい
- プレックスのエンジニア組織も今後拡大していきたいため、オンボーディング改善により開発までにかかるコストをなるべく下げたい
ことからチーム内で「デメリットを考慮しても、取り組みとして今後もやっていきたい」ということになり、今後も入社するメンバーに同じくオンボーディング改善を実施してもらうことになりました。
今回実施したオンボーディング改善の取り組み
ここでは、開発にとりかかりやすい仕組みづくりの観点で、自分が実際に行った改善の一部を紹介していきます。
今回、自分の意識した点としては
- 開発の始めやすさ
- 開発に必要なドメイン知識の取り出しやすさ
です。
一連の開発フローのドキュメント化
現在 PlexJob(ドライバー向け求人サービス) では1週間単位のスプリントで開発を行っています。
タスクの起票、スプリントMTGからリリースまでの一連の流れや各業務で必要になるツールの導入方法などを「開発ガイド」としてドキュメントにしました。
ドメイン知識のドキュメント化
PlexJobでは、システムの提供先のステークホルダーが多いこと、複数の社内システムとの連携が必要になることから、暗黙知となっているドメイン知識が多く、都度詳しそうなメンバーから説明を受ける必要がありました。
自分が実際にヒアリングを行った内容と既存メンバーが暗黙知と認識しているドメイン知識を以下のようなドキュメントにまとめました。
- ドメインモデル図
- ビジネスサイドと開発のかかわる業務の背景や手順の書き出し
ここで、ドメインモデル図を使用したのは以下のような背景があります。
- 現在社内で行っている DDD勉強会*1 で取り上げられたドメインモデル図が業務知識を表現する際に非常に分かりやすいと感じたこと
- 勉強会で学んだ内容を実際の業務にアウトプットする機会として適当であると判断したこと
また、ドメインモデル図を表現する方法に関しては、NotionのMermaid記法を使用しました。その他の作図ツールも検討しましたが
- 作図ツールとドキュメントツールを分けたくなかった
- Notionが丁度、Mermaid記法に対応した
ことから、結果的にNotionで一元管理することにしました。
以下、参考例
テストデータの整備
seedデータ(PlexJobではサーバーサイドのフレームワークとしてRailsを使用)としてマスタ系のテーブルのデータは用意されていたものの、ユーザーに紐づくデータは担当した際の要件に応じて、都度ステージング環境のDBを参考に自分でデータを作成する必要があり、不便に感じました。
ドメインモデル図により、各モデルに関する知識が明らかになったので、要件毎のデータを表現しやすくなりました。
そのため、自分が開発する中で必要になったドメイン知識や今回ドキュメントにしたドメイン知識を中心に、できるだけ、db:setupした段階でユースケース毎の初期データとして制約/ルール毎のテストデータが用意され、環境構築が完了した段階で実際の運用データに近い形から触り始められるようにしました。
目新しいことはありませんが、自分がオンボーディング改善として行ったものを紹介させていただきました。
次回のオンボーディング時に新しいメンバーからまた、今回の改善に対するフィードバックや更なる改善案が出ることが楽しみです。
今後も引き続き開発内外の仕組みづくりを実施していきたいと思います💪
業務委託や副業で携わりやすい環境があること
最後にはなりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。
自分自身、1ヶ月の業務委託を通じて入社を決めましたが、オンボーディングを始め、「まずは業務から、会社や開発チームを知った上で判断してみる」という方でも携わりやすい仕組みが整っています。
是非、少しでも興味を持っていただけた方は業務委託や副業からでもご応募いただけると幸いです。
*1:毎週火曜日にドメイン駆動設計 モデリング/実装ガイドをテーマにDDDの勉強会を開催しています
