2023 年エンジニアリングチームの振り返り
Overview
Belong CTO の福井です。 2023 年もそろそろ終わりが近づいてきましたので、今年のエンジニアリングチームの取り組みを振り返りたいと思います。
Belong のエンジニアリングは社外向けのサービスだけでなく社内のユーザー向けのサービスも多く開発しており、
各種ツールからデータ基盤まで含めると外から見えるよりも多くの事でエンジニアリングの取り組みがあります。
本記事では以下のトピックに触れます。
- Belong のサービスの進化
- にこスマや内部的なシステムの発展
- パートナーとの連携
- エンジニアリングチーム内での取り組み
2023 年のエンジニアリングチーム
今年エンジニアリングチームではメンバーが 6 人増えました。 正社員以外も含めると 30 人弱の体制で設計・開発から運用までの全ての工程を行っています。 メンバー数は順調に増えていますが、ビジネスもどんどん成長しており、行いたいビジネスをサポートするためのチーム体制を実現するためにはエンジニアの人数はまだまだ足りない状態です。
サービスの成長
にこスマファミリー
にこスマ関連のサービスは外部からも見えるサービスです。これらのサービスでは以下の発展を遂げました。
にこスマ は以下に挙げるポイントがわかりやすい進化です。
- i18n (英語化) 対応
- こだわり検索機能追加
- オススメ順の商品表示
にこスマは非日本語話者の方でも中古スマホを購入しやすいサービスになりました。 また、従来から存在した色や状態などの検索条件以外に、ホームボタンの有無や撮影モード、防水機能(性能)など、 スマホに詳しい方がこだわって検索したいという需要にも応えられる検索機能が追加されました。
スマホの買取サービスである にこスマ買取 では買取開始時のページの UI が大きく変わりました。
以下に挙げるような進化をしており、お客様の「結局自分の売りたいスマホはいくらになるの?」という疑問に対して素早く応えられる様になり、 UX が向上しています。
- グレーディングの簡易化
- 8 つあったグレーディング項目を 3 つに簡略化
- スマホ価格の早期取得
- モデル情報と状態に基づいた査定前の一般的な価格の可視化
- モデル選択から実際の価格を見るまでの手順の簡略化
この変更の影響もあってか買取申込数は順調に伸び続けており、2023 年の年始と比べると 12 月の現時点で 5 倍以上の取引量となっています。
また、「スマホは下取りに出すだけでなく売れるもの」という意識が広まり、スマホの買取に関する認知が高まっていることも関連していると考えています。
にこスマ買取はこれからも成長を続けるという期待は大きいです。
内部システム
また内部的には、モノリシックなサービスとして開発を開始した在庫管理システムをマルチサービスとして切り分け始めており、今季は販売に関わるドメインを分離しました。
マルチサービスという表現は、マイクロサービスほど小さくはないものの、モノリシックなサービスよりは責任範囲が小さくなるように一定のドメインごとにサービスを分離することを指しています。
この理由としては、チーム規模を考えると単機能のマイクロサービスにするとリポジトリの管理や DB の分離、リリース作業など各種管理のオーバーヘッドがマイクロサービス化によるメリットを上回ってしまうため、
サービスとしてはある程度の規模を保ちつつもビジネスドメインとして妥当な境界でサービスを分離した方がチームとして動きやすいと考えたためです。
ここで分離した販売ドメインに対応するサービスは「売る」という行為により特化した機能を加え、在庫を扱うビジネスでは必ず考える必要のある在庫回転率を改善するために高度な仕組みを導入しました。
Belong の個人顧客向けの端末販売は自社サービスのにこスマに加えて、Amazon や楽天など各種 EC モールなどでも出店しています。
このとき、サービスによって在庫の持ち方が異なるため、在庫の効率的な割り当てに課題がありました。
今回導入した販売特化サービスは在庫の状態を考慮しつつ Belong の販売戦略に特化した在庫の割り当てができ、販売のさらなる成長を担う「エンジン」として動くことを期待しており、すでに効果が現れ始めています。
ここでは詳細には触れませんが、社内の複雑なコンテキストを考慮した上で発展的なアプローチを取り、継続的にそれを進化させられるのは自社開発を行っているからこそできることであり、今後も継続したいと考えています。
また、今年 Belong のデータプラットフォームチーム立ち上げ の記事で触れたデータ統合分析基盤は順調に成長しており、作成したデータ基盤で作られたデータの実利用も開始されました。
これに加え、Belong では Looker の利用を開始しており、社内・外への発展的なデータ提供も可能になりました。
現状は上記記事で引用されているデータ利用需要のピラミッドにおけるデータの学習や最適化(LEARN/OPTIMIZE
)のフェーズ部分にあると考えており、
今後データの分析・利用を更に発展させビジネスの拡大に貢献することを念頭においてチームは動いていきます。
パートナーシップの拡大
Belong のサービスは自社のみではなくパートナー企業様との連携も積極的に行っています。
にこスマ買取ではこれまでに IIJ、Amazon Japan、NTT ドコモ (敬称略、連携順)などを一部の例として、キャリアや大手家電量販店、EC サイトといった携帯買取サービスの需要が高いサービスの運営会社との連携を行っています。 今季はこれらのパートナーに加えて、以下のように携帯のメーカーや C2C マーケートの運営会社もパートナーに加わりました。
- SHARP
- Motorola
- HTC
- メルカリ (スマホかんたん買取)
これらの連携は弊社の優秀な BizDev のメンバーの働きが大きい部分もありますが、エンジニアリングチームとして安定して信頼性の高いサービスを提供できていることも要因としてあります。
また、メルカリ社とはスマホかんたん買取に加え、あんしんデータ消去の提供も開始しており、 中古スマホ取引のエコシステムをより良いものにするためのサービスを共に作り上げています。
エンジニアリングチームの仕組みの成長
チーム内の仕組みも成長しており、エンジニアリングチームのメンバーが自らの体験を良くするための仕組みを作り上げています。
Zero Touch Production (ZTP) への投資
ZTP は Building Secure Reliable Systems でも触れられていますが、 本番環境を安全に変更するための考え方です。
具体的には、本番環境のアクセス権限をもつ人が直接変更を加えるのではなく、自動化あるいはツールを介した間接的な操作により予測可能で制御された本番環境の変更を実現することを指します。
Belong では基本的には Google Cloud の環境は Terraform で管理しており、CI/CD を行いつつ様々な自動化を行っていますが、リリース作業やインシデントの対応を行うときに本番環境のリソースを触りたい場合があります。
これまでは私が権限を持ち、リクエストされた gcloud コマンドを実行することで権限の付与やリソースの変更を行っていましたが、これには属人性などガバナンスの課題がありました。
そこで Slack で必要な権限などをリクエストし、EM などが承認すると自動的にタスクが実行される仕組みを作りました。
現状は完全に 「Zero Touch」にまでは出来ていない部分もありますが、エンジニアリングとしてはこの様な部分にも投資を行い、チームの成長に伴って必要な仕組みを作り上げています。
エンジニアリングチームの生産性可視化
今季はエンジニアリングチームの生産性を定量的にも可視化するために、Four Keys に関わる指標と、 GitHub のプルリクエスト (以下 PR) の情報を可視化する仕組みを作りました。 この構成については別記事でも触れたいと考えていますが、Four Keys の項目のうちデプロイの頻度と変更のリードタイムは GitHub にある情報を活用し、変更障害率とサービス復元時間は別途自分たちで管理しているインシデント関連の DB から情報を利用しています。
GitHub の PR の情報の可視化に関しては、以下のような情報を個別の PR や、期間内の総計を計算し 1 PR ごとの平均に均すなどして可視化しています。 このようなことを行うサービスは既に存在しトライアルなども行いましたが、私達の見たいデータを生み出すためには開発プロセスをそのサービスに合わせる必要がある点、また見たい情報が必要最小限見えたら十分でそれ以上の機能が必要ない点から、 GitHub の API を利用して自分たちで作成しました。
- PR を作成した数
- レビューコメントの数
- 被レビューコメントの数
- Approval を出した数
- PR を作成してからクローズするまでの時間
この情報を BigQuery に流し込み Looker Studio で可視化することで、個々人の比較、チーム間の比較、チームやリポジトリでのフィルタリングなどを可能にしています。
このデータは意図的に操作可能な情報であるため、ここから得られる情報を業績評価などに用いることはしません。
この取り組みは、意図的に操作した結果生まれるデータではなく、より自然発生的に生まれるデータの状態を取り込み、以下のような観点で会話をし、エンジニアがより生産的に動くための改善につなげることを意図しています。
- チーム間の傾向の比較をし、良い傾向を持つチームのプロセスを他に反映する
- シニアメンバーとジュニアメンバーの傾向の違いを分析し、目標となる動き方を理解する
- 傾向に変化があったときにそのメンバーの状態をマネージャーが把握し、必要なフォローアップや周知をおこなう
LLM に関する取り組み
今年は LLM の利用が世界的に大きく広まった年でした。 Belong エンジニアリングチームにおける AI サービスの利用 で触れたように、 エンジニアリングチームでは GitHub Copilot を導入したり、OpenAI の API を利用した Slack 上でのチャットボットを作成したりしています。
また、セールスフォースのデータを利用しつつ RAG を行うことで見込み顧客の情報を拡充・整理したりなど、ビジネスに直接繋がるような取り組みも行っています。 カスタマーサポートの分析・強化や、例えばスマホ情報の Q&A など LLM を活用できそうな部分は Belong 内でも多くあるので、今後も積極的に活用していきたいと考えています。
おわりに
本記事では 2023 年のエンジニアリングチームの取り組みを振り返りました。 年初からの想定通りに進んだ部分やそうでない部分など様々なことがありましたが、全体としてはビジネス及び、エンジニアリングチームとしての成長を実感できる年でした。
来年のプランニングを行っていますが、Belong はまだまだ成長を続けていきます。 ビジネスとしてはもちろん、エンジニアリングチームの規模もまだまだ大きくなる予定です。
2024 年は IC として活躍するエンジニアのポジションを更に増やす予定であり、それに加えてエンジニアリングマネージャー (EM) の採用も拡大する予定です。
現状の組織の体制としては Tech Lead Manager (TLM)、 TL として技術に関わるリーダーの役割とピープルマネージャーとして人のマネジメントをする役割の二足のわらじを履くケースが多いです。
これには、マネージャーにはメンバーのテクニカルスキルを適切に理解して欲しいこともあり、エンジニアとして活躍していた人のなかで人との関わりの部分も上手な人がマネージャーをすると健全なチームになるという私の考えと、
開発を続けたいという本人の希望、純粋に開発者が足りていないという状況など色々な理由があります。
EM の技術への理解は今後も重要視はしますが、ビジネスの拡大や人数の増加に伴いこれまでとは組織のありかたや状態も変化してきているため、エンジニアリングマネージャーとして開発関連以外の部分、特に採用や組織づくりであったり、
人材育成などの領域をリードするマネージャーメンバーも増やしたいと考えています。
これからも成長に伴う変化に対応した開発体制や組織の構築・改善に継続的に投資していきます。 成長を続ける Belong での開発や組織づくりに興味がある方はぜひお声がけいただけると嬉しいです。
エンジニアリングチームの紹介: エンジニアリングチーム紹介ページ