見出し画像

4社統合で揺れたエンジニア組織が、再び動き出すまで─「STORES がひとつになるまで」#3

「分かれていたものを、ひとつの価値へ。」── STORES はこの春、事業・組織・プロダクトを統合し、新たなステージへ進みました。“コンパウンド化”に挑んだ3年間の試行錯誤。その裏側と学びを、CxOやVPたちが語る「STORES がひとつになるまで」シリーズ第3弾です。今回は、COO佐藤大介の視点をお届けします。

PROFILE
佐藤 大介・・・執行役員 COO(Chief Operating Officer)

高校在学中に起業・上場を経験。その後、グリーやリクルートグループなどでグローバル・国内の開発組織を統括。2017年にクービックへ参画し、開発責任者・取締役を務める。クービックがヘイ(現 STORES)にグループ入りした2020年より、STORES 予約・決済の開発責任者に。2022年にVPoE、2023年にVPoP、2025年より執行役員COO(現任)

僕が関わると、組織はザワつく

こんにちは、STORES COOをしている佐藤大介です。「さとだい」と呼ばれることが多いです。僕が関わると、たいてい組織はザワザワします。「また、さとだいが来たぞ」と、冗談半分で言われたりもしますが、実際、僕が入ると現場がザワつくことはよくあると思います。

ザワザワは変化が始まるサイン、と捉えています。むしろ、そのザワザワが起きない限り、大きな変化は起こせない。そういう意味で、僕は「ザワザワ」を起こす役回りになることが多かったかもしれません。

STORES が「ひとつの体験」を届けるための組織統合では、特にエンジニア組織は「痛み」を伴う変革を選びました。結果、すべてのメンバーに残ってもらうことはできませんでしたが、組織全体のプルリクエスト数は約3倍に増え、総出力としては大きく伸びました。

僕のキャリアを振り返っても、自分が得意だと思っているのは「組織の横糸を繋ぐこと」です。高校生で起業し、M&Aと上場を経験。その後、GREE、Quipper(スタディサプリ)などでプロダクト組織をマネジメントし、これまでに6回のPMI(合併後統合)を経験してきました。

PMIを経験して学んだのは、「曖昧にしていると、結局みんな去っていく」という現実です。複数の企業文化や価値観が衝突するとき、妥協点を探して曖昧にするよりも、明確な方向性を示した方が長期的には良い結果に繋がります。特に高成長フェーズでは、この決断の有無が将来の組織形成に大きく影響します。

STORES は今日に至るまで、4社(ストアーズ・ドット・ジェーピー、コイニー、クービック、ショップフォース)が統合しています。各社が異なる文化、プロセス、価値観を持ち、それらが混在していました。曖昧なままでは、組織として力を出し切れないことも、時間とともに見えてきました。

もし、「異なる開発文化を持つ組織」を統合しようとしているマネージャーやリーダーの方がいたら、僕自身の経験から伝えたいことがあります。統合のプロセスには確かに痛みが伴いますが、その先には、より大きな力を発揮できる組織が待っています。統合は簡単ではありません。だからこそ、自分たちが何を大切にするのかを、改めて確かめる機会にもなります。

4つの会社、4つの文化が交わる

STORES は、異なるルーツを持つ4社がひとつになった組織です。それぞれに背景と開発文化の違いがありました。2020年、僕は Coubicの開発マネージャーとしてSTORES (当時のhey)にジョインしました。Coubicは2013年に自分で立ち上げたサービスです。2020年から、自分が作った事業を含め、複数の事業が一つにまとまっていく過程に、深く関わることになりました。

2018年にSTORES.jpとCoineyが統合し、2020年に STORES ブランドへ一本化。さらに、CoubicとSHOP FORCEも加わり、現在の体制になりました。

画像
4つの会社が、ひとつのSTORESに統合されるまでの沿革

この4社は、事業背景も開発スタイルも根本的に異なっていました。PMIでよく見られる状況ですが、特にエンジニア組織の統合には独自の難しさがあります。

たとえば、STORES.jpとCoineyは、ECやキャッシュレス市場の追い風を受け、急成長していました。事業が自然に伸びるフェーズにあり、しっかり運用できるチームが求められていたように思います。一方、Coubicは予約特化型SaaSとして、常に新機能を開発し、PMF(Product Market Fit)を探索する成長段階にありました。トライアンドエラーを高速に繰り返せるチームが必要でした。

画像
ざっくり整理した、4社の開発カルチャー感(あくまで個人的な観察メモです)

事業の成長フェーズが異なれば、開発スタイルも違う。この違いを前提に、組織をひとつにまとめる難しさに向き合う必要がありました。さらにコロナ禍によって、各社の働き方の違いも際立ちました。

heyはリモートワーク推進でしたが、Coubicは元々が出社文化。全員がリモートに切り替わったことで、「他のチームは何をやっているのか」が見えにくくなりました。こうした分断は、統合途上の組織では、致命的にもなり得ます。

ぶつかる価値観──チームの危機

当時のエンジニア組織は、明確な二極化が進んでいました。

一方には「自分から考え、決めて行動していきたい(許可を求めるな、謝罪せよ的)」エンジニアたち。顧客課題を理解し、プロダクトの方向性を考え、積極的に変化を起こしていく集団。スタートアップらしいDNAを持ち、常に新しいことにチャレンジしたいタイプです。

もう一方には「たくさんの議論とコンセンサスに基づく要件を受けてしっかり応えたい」エンジニアたち。指示された要件を確実に実装し、プロダクトの安定稼働を大切にし、品質とプロセスを重視するタイプです。どちらも正解であり、どちらも必要な人材です。ただ、この相反する価値観を持つ人たちが一つのチームにいると、お互いにフラストレーションが溜まっていきました。

さらに、プロダクトごとの収益貢献にも大きな差がありました。STORES.jpが全体の半分以上を占め、CoineyとCoubicが残りを分け合う構造。どの開発スタイルを基準にすべきか、答えは簡単には出ませんでした。

その混乱の中で、特に STORES 決済(Coiney)チームには綻びが見え始めていました。マネージャーが次々と離れ、「この会社はどこへ向かうのか」という不安が広がっていました。ビジネス要件をチームに伝えても、エンジニアたちは「本当にこれでいいのか」と疑問を持ち、マネージャーはその板挟みで疲弊していく……そんな悪循環が生じていました。

2つの問いで、本音を引き出す

状況を打開するため、僕はまず STORES 決済(Coiney)チームに入り、現場を観察しました。そこで、組織がざわつき始めました。

見えてきたのは、単なる作業効率や技術的な課題ではなく、「この会社は何を目指すのか」という根本的な迷いでした。組織統合の過程で、会社の「アイデンティティ」が揺らいでいたのです。

そこからの取り組みは、シンプルなものでした。
全エンジニアと1on1で向き合うこと。
2ヶ月かけて、各チームを順番に回り、すべてのメンバーと対話しました。
同時に採用プロセスにも関与し、1日4〜5件のカジュアル面談をこなす日々が続きました。あらゆる面談で、同じ2つの問いを投げかけました。

「なぜ今、ここにいるのか」
「ここで、何がしたいのか」

たったこれだけ。
シンプルな問いだけれど、簡単には答えられない。

この問いにどう答えるかで、その人の価値観、モチベーション、未来への期待がすべて見えてきます。特に「何で仕事してるの?」という問いは、その人のハッピーが何かを知るためには不可欠でした。人はハッピーに繋がらない仕事では、長期的にパフォーマンスを発揮できないからです。

感覚だけに頼らないため、データ分析も行いました。GitHubのコミット数やプルリクエスト数を追い、人によるアウトプットの違いと、その数字の背景にある価値観の違いを可視化しました。感情に流されず、事実ベースで組織を見つめ直すための手段でした。

こうして見えてきたリアルをもとに、代表の佐藤裕介や、CTOの藤村大介たちと、何度も議論を重ねました。チームの現状を共有しながら、

「今、この組織はどうありたいのか。」
「これから、どこへ向かうべきか。」

方向性について対話を続けました。時間はかかりましたが、この地道な積み重ねが、後の変革の土台になりました。

価値観を軸に、チームをつくり直す

「どうありたいのか」

僕たちが選んだ道は明確でした。オーナーさんたちに価値を届け続けるために、「お客様の課題を解き続ける」「常に進化する」ことを組織の中心に据える。エンジニアの役割は、単なるプログラミングではありません。

課題解決こそが仕事であり、コードはそのための手段にすぎない。
必要ならチームを作り、他部門と連携し、時に役割を超えてどんな立場であっても課題に向き合う。それが STORES における「エンジニア」の定義です。

また、「できないとされている課題を、どうやって解いていくか」もスタートアップの本質だと考えました。今日のやり方を、明日には「もっと良くできた」と更新し続ける組織を目指しました。

働き方については、「リモートか、出社か」という二項対立ではなく、 結果にコミットするために、各自が最適な方法を工夫することにしました。この新しい価値観に共感したマネージャーたちを中心に、チームの再編成を進めました。ほぼすべてのチームでマネージャーが入れ替わり、 メンバーからプレイングマネージャーになる人もいれば、元マネージャーが役割を変えメンバーとして支えるケースもありました。チームそのものを、「変化する組織」へとつくり直したのです。

エンジニア組織の進化 ──アウトプットは3倍に

組織の形を変えるには、それ相応の覚悟が必要でした。

組織が大きく変わるとき、どんなに丁寧に進めても、すべての人にとって心地よい変化にはなり得ません。「2つの問い」を投げ続ける中で、エンジニア組織の約半数が離れる結果を迎えました。ただ、長期的には残る人も、離れる人も、それぞれにとって良い結果になると信じていました。

残るメンバーにとっては、共感できる価値観の下で働けることでモチベーションが高まります。離れたメンバー一人ひとりにも、感謝しかありません。彼らは STORES のこれまでを支えてくれた、大切な仲間です。

この変革後、組織全体のプルリクエスト数は3倍に増えました。明確な方向性の下で、共通の価値観を持つメンバーが力を合わせた結果です。

マネジメントスタイルも大きく変えました。「個別に目標設定を細かくする」というよりも、「このチームはこの半期に何をするべきか」、チーム単位で目指すべき方向を明確にし、メンバーに考えてもらうことを基本とし、自律的に動ける形を目指しました。詳細な指示に依存するのではなく、方向性を示して自律的に動けるチームの方が”複雑な課題”に対応できるからです。

画像
明確な価値観のもとで、総アウトプットはおよそ3倍に。

プロダクトを“つなぐ”ために、組織を変える

この組織変革は、単なる効率化のためではありませんでした。
目指したのは、「STORES」というひとつの体験の実現です。

複数の異なるプロダクトを持つ STORES 。それらを単なる集合体ではなく、お客様にとって一つのプラットフォームとして機能させるために、エンジニア組織も「自分の担当プロダクト」という枠を超える必要がありました。

変革後のエンジニア組織は、プロダクト間の垣根を越え、お客様の課題に向き合う集団へと進化しました。異なるプロダクト間でデータを連携し、ユーザー体験を統合する。表面的なブランド統合やID連携ではなく、プロダクトの深層でつながる体験を設計する。

サポートも一つのソフトウェアとして支援し、クロスセルを見据えた新しいプライシングも可能になりました。これは、異なる開発文化を持つ組織が、ひとつの価値観のもとに統合されたからこそ実現できた成果です。

この「ひとつの STORES」というビジョンを実現するために、5年間をかけて統合をやりきったのです。

画像
“お店のフロントオフィス”を支える、STORES プラットフォームの簡略図

“今ここ”だけで終わらないチームをつくる

僕は、2025年からCOOとして、より広い視野で組織づくりに取り組んでいます。エンジニア組織での経験を活かしながら、いまはビジネス組織の文化やプロセスにも向き合っています。簡単ではありませんが、対話を重ね、課題を見つけ、明確な方向性を示す、その基本は変わりません。

これまで僕自身、難しい課題に挑戦し、たくさん成功も失敗もする中で、少しずつ成長してきました。それは幸いに仕事環境・仲間に恵まれ、「できるか分からないチャレンジ」をさせてもらえる機会・期待をいただいたからだと思っており、STORES の仲間たちにも、そんな経験をしてほしいと考えています。

もし、ここを巣立ったメンバーが、次の場所でリーダーシップを発揮するなら、それもまたいい循環です。(ここで得たスキルや視点は、きっと次のキャリアでも力になるはず)

チームで価値を生み出し続けるために、何を大切にして働くのか。スタートアップでは、この“問い”に向き合い続けることこそが、結局、一番の力になると思っています。

(編集協力:長谷川賢人、写真:出川光)

\ STORES では一緒にはたらく仲間を募集中です!/

いいなと思ったら応援しよう!

ピックアップされています

経営メンバー

  • 29本

STORES の事業とプロダクト

  • 20本

STORES がひとつになるまで

  • 3本

#エンジニア 系記事まとめ

  • 1,234本

#スタートアップ 記事まとめ

  • 1,781本
4社統合で揺れたエンジニア組織が、再び動き出すまで─「STORES がひとつになるまで」#3|STORES note
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1