CTO×新執行役員 技術と組織、両輪で加速する「新体制」
2026/3/2
このたび、坂本 和大が10Xのエンジニアリング管掌 執行役員に就任しました。
坂本は2020年の入社以来、エンジニアとして自ら開発を牽引する傍ら、マネジメントとしても現在のエンジニア組織の基盤構築に尽力してきました。
本記事では、新執行役員の坂本(@kazu0620)と、CTO兼Founderの石川(@_ishkawa)による対談をお届けします。
聞き手は、10XのSWEでありEMでもある二川(@futabooo)です。二人と苦楽を共にしてきた二川の視点から、10Xのエンジニア組織のこれからについて率直に切り込んでもらいました。
KLabを経て、Sansanにて『Eight』のモバイルアプリ開発にエンジニアリングマネージャー / プロダクトマネージャーとして携わる。2020年3月に10Xに入社。エンジニアが所属するプロダクト本部にて開発チームのEMを担う。
面白法人カヤック、LINE、メルカリでソフトウェアエンジニアとして複数のモバイルアプリの立ち上げを経験。その後、メルカリで同僚だった矢本と10Xを創業し、CTOとして技術戦略とプロダクト開発全般を担当。
エウレカでAndroidアプリ開発とアジャイル開発に精通し2020年7月に10Xに入社。現在はEMとしてチームで成果を出すことを目的として必要なことをなんでもやる。
エンジニアリング管掌とCTOの役割分担は「技術の石川、組織の坂本」
二川：3月に坂本さんがエンジニアリング管掌執行役員に就任しました！ただ、10Xにはすでに石川さんというCTOがいます。そこでまずは、「エンジニアリング管掌ってなんですか？」と、CTOとの住み分けについて伺いたいです。
石川：あえて他の組織に例えるなら、エンジニアリング管掌執行役員はVPoE（エンジニアリング組織のマネジメント責任者）に近いですかね。
1年ほど前から、成果管理や採用、組織づくりといったエンジニアリング組織のマネジメントは坂本さんが担ってきました。一方で僕は、技術的な課題の解決策を探索したり、プロトタイプを実装したりと手を動かしてきたんです。
もっと簡単に言い換えると、エンジニアリング組織の運営に責任を持つのが坂本さん。技術的な成果に責任を持つのが僕、という感じです。
二川：役割を分けたことで、どんなメリットを感じていますか？
坂本：以前は、石川さんが技術だけでなく、組織にも責任を持っていました。でも、組織の部分を僕が引き受けるようになったことで、シンプルに石川さんの時間が増えたんです。その結果、会社としてより大きな課題に技術で向き合えるようになった。たとえば、モバイルアプリのアーキテクチャや、商品パイプラインの新しい実装の検証など、実際に成果も出始めているんですよ。
石川：坂本さんが組織を回してくれているからこそ、僕は技術的な探索に集中できるんですよ。
ビジネス上の要請や技術的負債の影響で、単純には解決しきれない課題も出てきます。そうした時に、組織としてチームの体制を強化するアプローチと、チームとは独立して技術的な解決を探索するアプローチの両方を持てるようになりました。
二川：1年かけてその組織体制を実行・検証した結果、良いバランスだと実感できたから、正式にこの体制で進めていくことが決まった、と。
石川：そうですね。役割は変わっていなくて、実態に合わせて役職名がついたという感じです。
過去の試行錯誤が、今のちょうどいいバランスをつくった
二川：今の10Xの開発組織全体についてもどんな体制なのかを説明してもらっていいですか。
坂本：大きく分けると業務とか機能の単位で一定の領域を受け持ってアプリケーションの開発を行うチームと、横串の課題を取り扱って組織全体を横断的に支援する種のチームで組織を構成しています。
具体的には、前者は店舗チームやお取引チーム、後者は品質管理チームやSREチームなどがこれに該当します。チーム名の「店舗」や「お取引」が対象とする業務や領域を表している感じですね。
二川：3年ほど前に、今の構造に変えたんですよね。
坂本：そうですね。もともとは、パートナー企業ごとにチームを作っていたので、今の組織構造とはかなり違うものでした。
石川：当時はStailerのネットスーパー事業を始めて1〜2年の頃。大手のパートナー（※10Xでは取引先企業をパートナー企業と呼んでいます）にも導入いただいていた一方で、プロダクトとしてはまだ発展途上でした。新規の機能開発と運用にどうコストを配分するか、自分たちのシステムがどこまでを担うのかといった、ソフトウェアとしての戦略を十分に描けていなかったんです。
二川：その体制で、実際にどんな問題が起きたんですか？
坂本：プラットフォームとして共通の仕組みを育てたいのに、パートナーごとの個別対応に寄った実装がどんどん増えていってしまったんです。事業が目指す方向と組織の形にギャップが生じると、それを立て直すコストが後からどんどん大きくなる。それは10Xで働いてきた中で、特に強く実感したことでした。
石川：パートナー企業の要望に一つひとつすべてに丁寧に応えようとすると、プロダクトが断片化していき、運用コストが膨らみ、結果的にはプラットフォームとしての価値が下がっていってしまうんです。
二川：なるほど……。今振り返ると、当時「こうしておけばよかった」と思うことはありますか？
石川：パートナー企業ごとに個別対応を重ねていった結果、「ここから先はStailerとしては対応しない」という線引きが曖昧なまま、システムが膨らんでいきました。もし初めから、どこまでを自分たちのプロダクトをプラットフォームとして作り込み、どこからはパートナー企業側の運用に委ねるのかを明確にできていたら、今よりもずっとシンプルなシステムになっていたと思います。ただ、初期にパートナー企業の要望に応えず自分たちのスタンスを押し通していたら、事業として成り立たなかった可能性もあるから、難しいですよね。
坂本：もう少し細かい話をすると、初期は技術的な意思決定の進め方にも課題がありました。スピードを優先していたので、「なぜこの技術を選んだのか」「他の選択肢と比べて何が良かったのか」といった判断の根拠を、あまり残していなかったんです。そうすると、後からシステムに問題が見つかった時に、当時の意図がわからないので、直すべきなのか、あえてそうしているのかの判断がつかない。
結果として、手戻りや調査に余計な時間がかかってしまうことがありました。
その反省から、今はDesign Docを書いて、チーム内でレビューを経てから開発に入る進め方を導入しています。「なぜこう作ったのか」が記録に残っていれば、後からその判断が妥当だったのかを検証できますから。
「長い目で見て、いいソフトウェアを作る」10Xの開発組織が目指すもの
二川：うまくいかなかった時期の試行錯誤が、今の組織体制やプロセスにつながっているのですね。ここからは、どういう開発組織にしていきたいかを聞いていきたいです。
坂本：10Xは、長い時間をかけて「小売」というドメインに向き合おうとしている会社です。だから、短期的に早く何かを作れるということよりも、長い時間で見た時に成果を最大化できる組織を作りたいと思っています。
石川：小売事業は、地域の生活インフラとして長く続いていくものです。その営みに対してソフトウェアが関わる意義を考えると、短期的にガッと成果が出るよりも、安定して成果が出続けることの方が大切だと考えています。それを実現するには、システムそのものが安定していて、内部の運用コストもしっかり抑えられている状態を作る必要がある。開発組織のあり方も、そこに合わせていくことになります。
坂本：代表の矢本さんはよく「組織は事業に準ずる」と言っているのですが、まさにそうで。事業を取り巻く状況が変わったり、僕らの事業に対する理解が深まった時に、組織のあり方も変わっていく。「これが正解」というスナップショットが一瞬あったとしても、その先正解が変わる可能性はいくらでもあります。だからこそ、長い時間をかけてでも、事業の形に最適な組織に変わり続けられる状態を作っていきたいですね。
二川：「安定」や「長く続ける」がキーワードとして出てきましたが、具体的に今のStailerにはどんなチャレンジをしているのでしょうか。
坂本：正直なところ、Stailerのシステムが今の時点で完全に安定しているかというと、まだまだ課題はあります。たとえば今は、いろんなモデルと密結合した巨大な「注文」というモデルが存在しています。こうしたモデルをイベント駆動の仕組みで疎にしていく取り組みを進めているところです。（参考記事：https://product.10x.co.jp/entry/2025/04/10/150702）
プラットフォームとして一気通貫でネットスーパーを提供するためのシステムは広範で複雑になる。
ただ、こうした「安定していないものを、どう安定させるか」に向き合えるのは、エンジニアとしてすごく価値のある経験だと思っていて。2年先、5年先のStailerの基盤を、自分たちの手で作っていける。それは、面白いチャレンジなんじゃないかな、と思います。
石川：うちの場合「とにかく手のかからない良いソフトウェアを作る」ということ自体が重要なチャレンジなんです。事業を伸ばしながら同時にソフトウェアのコンディションを良くしていくことに本気で向き合える環境って、そんなに多くないんじゃないかな、と。そこにこそ今10Xが求めているものがあるので、ペダルをかなり踏めるんですよね。そういうことに価値を感じる方には、すごくいいチャレンジの機会なんじゃないかなと思います。
二川：全社のオフサイトMTGでも石川さんと矢本さんが「寝てても儲かりたい」という話をしていましたよね（笑）。
石川：これは真面目な話なんです（笑）。業務を支えるソフトウェアの本質的な価値の一つは、人の手を介さなくても仕事が回るようになることだと思っています。そこに向き合い切って、ソフトウェアがある場合とない場合で価値の差をくっきり大きく残せるかどうか。それが僕たちエンジニアリングチームのチャレンジですね。
坂本：もう少し深掘りすると、良いソフトウェアを作ろうとした時に、そもそも何をソフトウェアで解決して何を解決しないのか、スコープをどこに置くかを決めるところから始まるんです。そこからどう解くかを考えて、ものを作る。その広い領域のエンジニアリングに取り組んで、ちゃんと世の中に価値をもたらせるというのは、面白いチャレンジだと思っています。
個人ではなく「チームの成果」を軸に評価する理由
二川：ここまで、長い目で見て安定したシステムを作るという方向性を伺ってきました。その方針のもとで、エンジニアの評価はこれからどうなっていくのでしょうか？
坂本：まさに今整えているところなのですが、骨格をお話ししますね。まず会社として出た成果、もっと具体的に言うと予算の超過やその年の粗利の増加分が原資となり、それをチームやメンバーに報酬として配分するという仕組みです。
プロダクト本部としてのポイントは、個人ではなくチーム単位で成果を評価するところですね。
二川：どうやってチームの成果を見るのでしょうか。
坂本：2週間に1回、プロダクト本部と開発チームで「チェックイン」というミーティングをしています。「この2週間でこういう成果を出そうと思っている」というコミットメントを出して、実際にどこまでできたかをすり合わせる。それを半年間繰り返して、チームごとに「コミットメントを上回る成果を出してくれた」「やや上振れが少なかった」といった評価をして、予算を配分していきます。
二川：先ほどの「長い目で見て安定したシステムを作る」という方針と、この評価の仕組みはどうつながるんですか？
坂本：たとえば、短期間で作れたけど、その後保守にすごく手がかかったり障害が起きたりするシステムを作ってしまうと、リリース以降のコミットメントを達成できなくなるんです。2週間ごとにトラッキングし続けているので、半年、1年と見た時に成果を最大化しようとすると、結果的に長期的に安定して手のかからないシステムを作る方が評価につながっていく。結果として、事業の方針と評価が自然につながる仕組みになっているんです。
二川：チーム単位の評価ということは、個人の目標設定はないのでしょうか。
坂本：そうですね。個人の目標を設定すると、どうしても「自分の目標をいかに達成するか」に意識が向きがちになってしまう。それよりも、会社として設定した目標をどうやってチームで最大化するかに目を向けてほしいんです。
チームの成果が上がることが、会社全体の成果につながり、それが自分の報酬にも反映される。その流れに意識が向くような制度にしたいと思っています。
二川：ちょっと嫌な言い方ですが、一般的にはチーム単位だと「自分は頑張っているのに、なかなか評価につながらない」という不満も出てきそうですが……。
坂本：大事なのは、頑張りがチームとしての成果につながっていない原因を一緒に探ることだと思っています。頑張っても成果が出ないのは、何かしら構造的なブロッカーがあるから。それをチームとしてどうなくせるか、個人としてどう動けるかを一緒に話して、頑張りが成果につながりやすい構造に変えていく。
それがこの評価のフィードバックサイクルの中でやっていきたいことです。
また、チーム単位で評価するというのもあくまで原則ではあります。例えばチームの中でも特定の個人が圧倒的に高いパフォーマンスを出しているといったケースのように、チームの評価と個人の評価が必ずしも一致しない場合はあると思ってます。
二川：なるほど、個別の課題をひとつずつ解決していくというよりは、エンジニアが成果を出しやすい仕組みそのものを作っていく。組織の体制も、開発のプロセスも、評価の仕組みも、全部そこにつながっているんですね。
この先10年、10Xの開発組織はどうなっていく?
二川：最後に、石川さん、坂本さんの2人に聞きたいです。10Xのエンジニア組織がこの先5年10年続く良い組織であるために、「変えていきたいこと」と「守り続けたいこと」ってありますか？
石川：守っていきたいのは、社会に求められる価値をソフトウェアの力で創造するという価値観ですね。
逆に変えていきたいことは、会社がどんな価値をどんな方法で出すかですかね。事業を長く続ける前提だと、その間に会社を取り巻く環境が変化しますよね。直近だとLLMの登場でソフトウェア開発はすっかり変わりましたし、小売企業を取り巻く経済的な環境も変わっています。
その結果、我々が実現できるソフトウェアも変化していますし、社会に求められる価値も変わってきています。こうした変化を適切に読んで、社会に価値を提供し続けたいと思います。
坂本： 先に変え続けたい方から話すと、業務の複雑さや本当に解くべき課題に向き合う時間を増やすための変化を、常に起こし続けたいなと思ってます。
僕らが扱う小売のドメインって課題の幅も広いし、それぞれが奥深いんですよね。例えば大量の商品データを日々入稿するシステム、商品を店舗でピッキングするオペレーション、配送のルーティング、小売の基幹システムとの外部連携。それぞれの領域で、業務が抱える複雑さや課題を理解して、ソフトウェアでうまく表現する必要があります。
そうした、ドメインや業務の本質的な課題だけに向き合えるのが理想だと思っています。
でも現実には、不具合を調査するとか、障害の対応をするとか、歴史的経緯で読みづらいコードになってる部分がある、みたいな取り扱う業務の本質とは少しズレた課題にも一定の時間を取られることがあります。
これまで保守性への投資を続けて来てだいぶ改善はしていますが、まだ理想とは遠いというのが現状です。
また、事業が成長すれば新しい課題も生まれると思います。なのでこれからもエンジニアが向き合うべき複雑さにしっかりフォーカスする時間を増やす状況を作るための変化を起こし続けたいです。そのためには、ソフトウェアの変化も必要だし、それを作る組織の変化も必要になるだろうなと思ってます。
守り続けたいことは、エンジニア全員が成果に強く向き合っているカルチャーですかね。10Xの開発組織のメンバーは、みんな単に言われたものを作るんじゃなくて、何のために作るのか・作ったものがどんな事業機会や成長に結びつくのか、といったことを真剣に考えて日々の仕事に取り組んでいるなと思ってます。
場合によっては作らず解決する、みたいな判断をすることもあったり。こうした、技術を手段として使って、事業の成果にしっかりと繋げる、物事を前に進めるといったカルチャー。こうした部分は組織がこれから成長したとしても守り続けたいなと思ってます。
二川： お二人の話を聞いて、改めて10Xは「技術を手段として、いかに事業価値を最大化するか」に真剣な組織だなと再認識しました。 この「新体制」で、さらに大きな価値を届けていきましょう。 今日はありがとうございました！
10Xでは一緒に働くメンバーを募集中です！
10Xでは未来をより良くする事業・組織のために、仲間を募集しています。
詳細はこちらをご覧ください。
