みなさんこんにちは。株式会社Belong採用責任者の吉川です。

Belongは、「大切な人に誇れる、次なる価値を届けよう。」というミッションを掲げ、中古スマホのエコシステムを構築すべくtoB/toC向けにサービスを展開しています。

さらなる事業拡大に向けて、積極採用を進めているエンジニアチーム。そこで今回は、CTOの福井さんにエンジニアの組織体制や特徴について語っていただきました。

気づき、学びは全てシェア。

ーー現在のBelongのエンジニア組織体制について教えてください。

現在、バックエンドエンジニアが4名、フロントエンジニアが2名、SREが2名、プロジェクトマネージャー1名、そしてCTOの私の10名体制です。現状はフラットな組織体制ですが、今後組織を拡大するにあたり、リーダー的ポジションも作っていきたいと考えています。

チームとしては、現在4つのチームを置いています。

・GSnA（Growing Service and API）チーム
素早い対応が求められる API や外部で利用されるサービスを扱うチームです。

・Operations Engineeringチーム
在庫管理システムなど、サービス展開のコアとなる当社の社内システムの開発チームです。

・SREチーム
あらゆるプロダクトに関して、DevOps、IaC、SLI/SLO の設定という観点から横断的に運用をサポートする部署です。最近では、CircleCIのOrbsやTerrafrom のモジュールを自社用にカスタマイズして、全プロダクトで活用できるようにしています。

・「にこスマ」チーム
中古スマホ通販「にこスマ」のプロダクト開発チームです。toC向けプロダクトを扱っています。

今後は、データを統合的に扱うDWHチームも作りたいと考えています。

ーーエンジニアチームの特徴を教えてください。

チームの連携が強いという点です。弊社には「Be United」というバリューがありますが、「一致団結して、助け合う」という意味で、個人ではなくチーム力を高めようという意識を強く持った組織です。

規模が小さいながらも優秀なエンジニアが揃っており、自動化などにも積極的に挑戦しています。その中で、自分が得た技術やノウハウをチームに還元しようとする意識が強いです。

たとえば、現時点ではGSnAチームが技術的に強いのですが、他のチームでもその技術を活用できるように積極的にライブラリを共有しています。何かを共有することは、正直ひと手間かかることですが、長期的にみて組織を強くするためには必要なことだと思っています。

ジュニアメンバーからすると、チーム間の連携が強いことで、シニアメンバーから、コードレビューやフィードバックなどで学ぶ機会を多く持つことができます。

シニアメンバーや組織からしても、社内で文脈が共有されているためメンバーの配置変更が容易なうえ、開発のレバレッジがかかり、長期的なメリットは大きなものと感じています。

また、全てのチームで「フィードバック」を重要としており、エンジニアが作るサービスは社内外用関係なくクオリティの向上を目指しています。

なにか提案や意見を発する際は、必ずフィードバックを得るようメンバーに伝えていますし、私自身もメンバーからフィードバックをもらうようにしています。

一方方向のコミュニケーションではなく、チームの皆が同意の上、納得感を持って開発を進められるような文化形成を心がけています。

※弊社の開発組織カルチャーはこちら↓

チームを超えた連携で、さらなる技術力の向上を

事業を拡大してきた中で、「動くこと」を優先としスピーディーに進めた開発があることは事実です。つまり、メンテナンスや機能改善の必要性が出てきています。

Belongでは基本的に2週間で1スプリントとしていますが、3〜4スプリントに1回はリファクタリングにリソースを充ています。SREも2名在籍しており、現在の規模感で運用改善を疎かにせず着手できている点は、Belongの良さだと思います。

プロダクトの数も増えてきており、私がすべて把握することも難しいのが現状です。DDD（データ駆動設計）などの共通の概念を持ちやすい手法を活用しながら、属人化をなくしていき、課題の解決に向けて進めていきたいです。

ーー課題を解決するためにどんなアプローチを進めていますか？

チームの連携という意味では、MTG時には必ず、

①事前にアジェンダを用意する
②テキストで議事録を残す

この2点は徹底しています。

MTGの時間内で本質的な議論をした上で、誰がいつ見ても確認できるようクリアな状態を意識しています。特にリモートワークが主流になってきており会話がその場に居ない人に伝わらない状況が起こりやすいので、オフラインの会話もメモに残すなど情報の非対称性を意識的に排除することで、属人的な業務が減りチーム・メンバー間の連携が取りやすくなると考えています。

また、エンジニアのスキルアップも欠かせません。週1でテックトークを開催したり、チームを超えて技術のインプットをする時間をとるなど、組織内のコミュニケーションは活発に行っています。その他、書籍の購入やコードレビューなどで知識の向上に対する投資は積極的に実施しています。

※チームで集まった時の写真です。

どんなエンジニアでも、活躍できるフィールドがある

ーーBelongのエンジニア組織の魅力を教えてください。

プロダクトの裾野が広く、toB/toC双方のサービスを手がけていることです。つまり、社内でできないことは少ないのではないかと思っています。

エンジニアとしては、Operetionsチームを含めると、toB toC to社内の3つのステークホルダーが存在します。そして、それぞれ特徴も異なります。toBプロダクトでは高い堅牢性が求められ、安定稼働することを念頭において開発を進める必要があります。toCプロダクトではデザイン性やアクセス量に対処する力が求められますね。

to社内のプロダクトでは、堅牢性はもちろん必要ですが、社外向けのプロダクトと比較しフィードバックを受けやすいこともあり、技術的なチャレンジをしやすい環境です。どんなエンジニアにおいても、自分の力を伸ばせる環境ではないかと思います。

仮に、エンジニアを下記のように4分類したとします。

たとえば、「ギークタイプ」のエンジニアであれば各種サービスにおいて、マイクロサービスで可用性・弾力性の高いアーキテクチャ設計や、DDD を用いたプログラムの設計など技術的難易度の高い課題に取り組んだり、toCのプロダクトで大規模トラフィックを捌くような開発をすることが出来ます。

「マネジメントタイプ」の場合、”ピープルウェア”と呼ばれるように難しい人の管理や、プロジェクト進行で持ち味を発揮でき、toB, toC それぞれのプロダクトでロードマップを達成するために活躍できます。

「サービスタイプ」は、作っているものがサービスとしてどうあるべきかという議論を経営陣も含めたPMチームと密に行い、実際のサービス開発に落とし込むことにやりがいを感じていただくことができるのではないでしょうか。特に、今なら立ち上げ過程にある toB の SaaS プロダクトで構想段階からの議論に参加ができます。

また、「ユーザーファースト」のエンジニアであれば、Operationチームで社内のフィードバックを間近でキャッチアップしつつプロダクトに落とし込むこともできますし、toC サービスでユーザーの行動データを元に改善を加えることもできます。

上記はあくまでも一例でありますが、それぞれが強みを発揮できる。そんな開発組織であると思います。サービスのバリューチェーンが長く、ワンストップで事業を展開しているBelongだからこその環境なのではないかと思っています。

ーー最後に、ここまで読んでくださった方へのメッセージをお願いします。

Belongは現在はCTO直下の組織体制ですが、今後は組織構築を進めていきます。組織構築をした後も、「Be United」のバリューのもとで、チーム間を超えて連携する体制を築いていく所存です。Belongはあらゆるエンジニアが挑戦できる環境です。ぜひ一度、カジュアルにお話ししませんか？

みなさまにお会いできるのを楽しみにしております。