Belongに入社してからのオンボーディング体験について
kurita-kはじめに
初めまして、2025 年 11 月より Backend Engineer として入社した kurita-k です。オンボーディングの流れについては先行記事がありますので、本記事では少し違う角度からオンボーディングについて紹介できればと思います。
Belong の Operation Engineering チームは、受付管理、生産管理、ロケーション管理、検品管理、配送管理、販売管理といったビジネスドメインを担当しています。私はその中でも販売管理システム (社内では SaleEngine と呼称しています) に特化したチームに配属されることになりました。SaleEngine は Operation Engineering 全体と密接に関係しているため、まずは Operation Engineering チームの本体でオンボーディングを行ってもらうことになりました。
知識のキャッチアップ
私はこれまで toC 向けのモバイル Web サービス、EC サービス、toB 向けの不動産サービスなどの経験があり、ユーズドスマートデバイスのエコシステムという Belong のビジネスドメインは初めての領域でした。
幸いなことに、Belong ではチーム間での情報共有を大切にする文化があり、開発の資料を残すことが習慣化されているため、ドキュメントが豊富に用意されていました。関連するドキュメントや紹介動画を閲覧し、NotebookLM で生成されたドメインクイズなども駆使してキャッチアップを進めました。
ただ、過去の経験があれば比較的スムーズに適応できると思っていましたが、どこまでキャッチアップをするのかの区切りをつけるのが難しく感じました。ある程度の理解の土台を築けましたが、ドメインが深いので今後も何度か立ち戻って学習することになりそうです。 深いドメイン知識が必要とされるのは、Belong の魅力の一つだと感じています。
具体的なオンボーディングタスクを通じて
Operation Engineering チームでのオンボーディングタスクは、在庫管理システム側の一機能のバリデーションの依存性を整理するものでした。複数のレイヤーに関連して改善の余地があったため、主にアプリケーションレイヤーとドメインレイヤーを中心に段階に分けていくつかのリファクタリングを行いながら、プロジェクトのアーキテクチャについて学んでいきました。
私は開発言語としては PHP が一番キャリアが長く、Go は未経験でしたが、PHP での実装と比較しながら Go でのクリーンアーキテクチャや DDD（ドメイン駆動設計）のポイントを学べたのは良い経験でした。リファクタリングを更に進めることも可能でしたが、最終的には複数のレイヤーにハードコードされた定義からデータベース駆動型の検証に置き換えることをゴールとしました。
同時に、Belong での SDLC（ソフトウェア開発ライフサイクル）を学び、開発プロセスの全体像を経験することができました。
オンボーディング期間で見えてきた課題と今後について
オンボーディングを通じて、いくつかの改善点や現状を把握することができました。
- クリーンアーキテクチャ × DDD（ドメイン駆動設計）のアプローチを目指しているが、まだ不十分な状態であること
- Unit テストでのデータの扱い、テスト用の DI コンテナの扱いに課題があること
- スクラムなどの開発手法の構築途中であり、また CI/CD などの既存の開発基盤も継続的に改善していく必要があること
一方で、私が配属される SaleEngine をはじめとした新しいプロジェクトでは、こうした課題を踏まえてより良いアーキテクチャと開発体験への新しい試みにチャレンジしています。また、新しいプロジェクトで得られた知見は既存のプロジェクトにも逆輸入され、組織全体で改善が進んでいます。システムの改善に終わりはありませんが、レバレッジが効きそうな箇所から投資をして改善し続けていければと考えています。
最後に
本記事では、Belong エンジニアチームでのオンボーディング体験について紹介しました。
まだ整っていない部分もありますが、Belong は成長を続けている会社です。オペレーションセンターのオペレーションを支え、共に改善を続けていけるエンジニアを募集しています。 本記事を読んで Belong に興味を持たれた方は是非 Entrance Book をご覧ください！