【Stailerの現在地】保守性改善からプラットフォームの道へ

10Xでは、現在ソフトウェアエンジニアの採用を行っています。
今回は改めてStailerの開発状況や体制、現在の取り組み、そして今だからこその挑戦や面白さをCTOの石川さん、ソフトウェアエンジニアの坂本さん、片山さんの3人に語ってもらいました。

Stailer開発の現状の取り組み

片山：久しぶりの記事なので、まずはStailerの現状について話しましょうか。直近の2024年度はどのような流れでプロダクト開発を進めてきましたか？

石川：保守性の改善に取り組んできました。プロダクト本部には約40人が所属していますが、その多くがプロダクト本部としてサービスの保守や運用を一定レベルまでコントロールするため、保守性に関連する業務に集中しています。

まず、開発にどれくらいリソースを割いているのか、保守・運用にどれくらいリソースを割いているのかを可視化しました。その後アラートについても突発的なものと定常的なものを区別し、開発チームへの依頼数や、障害発生・アラート対応、未解決のエラーを可視化して、その結果を基に各チームで対応してきたのが上期の主な流れです。

上期のプロダクト本部内の開発チームの体制

なぜ今、保守性に取り組んでいるのか

片山：保守・運用で時間を割いている業務について、もう少し詳しく説明してもらえますか？

石川：Stailerにおける具体的な保守・運用の内容について説明しますね。まずネットスーパーのオペレーションにおいて、Stailerが扱うデータに期待される流れがあります。そのデータの流れは約9割はうまく機能していますが、範囲が広く、その複雑さが故に考慮し切れていないイレギュラーなケースが発生したり、手動オペレーションでカバーする箇所があったりします。

例えば、片山さんの所属する店舗チームでは、これまで配達エリア移管（店舗に所属している配達エリアを、他の店舗に引っ越して店舗のキャパシティを調整する運用）が発生していましたよね。

片山：そうですね。例えば、パートナー（10Xでは、契約先の小売企業様をパートナーと呼んでいます）の店舗で対応できない不具合や、まだ管理機能としてリリースされていない運用依頼はソフトウェアエンジニアにエスカレーションされています。

それがプラットフォームとして機能化されることで、パートナーの皆さんが現場で対応できるようになり、タイムリーにやりたいことを実現できるようになる。また、我々も機能開発に集中できるようになるんですね。

保守性に踏み切る決断

坂本：保守性が最高の状態を「新機能開発以外の作業がほとんどない状態」としてみると、1年前はそこからかなり遠い状態でした。当時はアラート対応や「今週はこれを対応してください」という差し込みの依頼が頻繁に飛び交っていました。

一旦、新機能開発を止めて保守性に投資するという判断は正しかったと思います。CEOの矢本さんとCTOの石川さんをはじめ、プロダクトをよく理解している経営陣がいることがこの判断の背景にあります。10Xの強みだなと感じた意思決定でした。

片山：当時を振り返ると、毎週発生するオペレーションが多かったのが現場の実感です。保守性に投資する時間があった結果、今は落ち着いて新機能開発に集中できるようになりました。

石川：CTOという立場からの俯瞰した視点でも、保守性を向上させるためには利用者が自走できるようになることが重要でした。また、保守性の投資は、モデリングを深く考えるきっかけになる、というメリットがあったと思います。

例えばエリア移管の際に、「このデータをこうしてほしい」だけだと機能化しても単に運用コストを下げることしかできません。一方で本来は、「実際にその作業をやっていくために気をつけなきゃいけないものは何か」「どういう動機でやろうとしているのか」「どのようなインターフェースであるべきなのか」等を考える必要があります。

よりソフトウェアをうまく作る上で、開発組織としての学びになった部分がありました。運用コストを減らす、という経営課題が出発点でしたが、保守性の向上がソフトウェアをよりうまく作ることにつながるという実感を得ました。

片山：そもそも保守や運用に力を入れるべきだという考えは、どこから来たのでしょうか？経営が保守や運用にリソースを割くべきだと感じたタイミングが知りたいです。

石川：自分自身が開発者だからこそ、今のままでは各チームが元気に開発できる状態ではないと感じた瞬間があったんです。その状況を見て、ネットスーパーのプラットフォームとして目指したいところに早くたどり着くためには、まず開発が順調に進む状態を整える必要があると考えました。また、その状態が整っていないことは経営課題だと思いました。

保守・運用の次ステップ

片山：保守や運用が一段落しつつある中で、次の課題やチャレンジは何ですか？

坂本：1年前から進めてきた保守・運用の取り組みがようやく成果を見せ、新しい開発が以前よりも早く進められる状態になりました。

次のチャレンジとして取り組み始めているのが、プラットフォーム機能の強化です。これまでStailerはプラットフォームとして、ネットスーパーが標準として備えるべき機能を数多く作り提供してきました。一方で「標準的なネットスーパーでは必要とされないが、特定のパートナーでのみ強い需要がある機能」といった類の要求については、どうしても優先度が落ち、後手に回ってきてしまっていました。

プラットフォームとしてはより多くのパートナーで必要とされる機能を優先して作りたい一方で、パートナーの立場に立つと個別性はあるが極めて重要な要求をしている、というケースがあります。こうした要求を、Stailerの中ですべて実現しようとすると多大なコストがかかり、本来優先すべき機能の開発ができなかったり、事業としての成立が難しくなるリスクがあります。

そこで、プラットフォーム機能を強化することで、Stailerアプリケーションの境界の外側で個別の機能や振る舞いを追加できないか？というのが今僕らが取り組んでいるチャレンジです。

こうしたプラットフォーム機能の強化では、決まったインタフェースに沿ってStailerの外側、あるいは中間層で動作するシステムを開発することによって、Stailerに特定の機能を足したり振る舞いを変えたりといったことができるような世界を作ることを目指しています。

プラットフォームの進化とその背景

片山：以前からプラットフォームはキーワードでしたが、最近になって解像度が上がってきている感じがします。どのようなプロセスでここにたどり着いたのでしょうか？

石川：数多くの企業とビジネスを進め、商談を重ねてきた中で、従来の方法では対応しきれないと感じたことです。一方で、パートナーはお金を払ってでも機能を拡張したいと考えている部分があります。私たちがその対応を受けきれないと、ビジネスリスクになってしまう。それが、プラットフォーム構築に対する強い動機の一つです。

この動機自体は以前から存在していましたが、最近になってその解像度がはっきりと上がってきました。これまでは緊急性や優先度を十分に上げられなかったのですが、今の状況ではプロダクトに対する投資をしやすくなったと感じています。

以前は「プラットフォームを作るよりも、まず目の前の課題を解決しなければならない」という状況でしたが、改めてこの分野に力を入れることが、今の私たちにとっての正しい選択だと判断しています。

プラットフォームだからこその面白さ

片山：プラットフォームを構築する上で、何が面白いと感じますか？特に、Stailerのような事業や領域でプラットフォーム化することの面白さは何ですか？

石川：1つは、全国のスーパーやドラッグストアにアクセスできることです。このプラットフォーム構造を持たなければ、全国に価値を届けることはできないので、その点がやりがいを感じるポイントです。もう1つは、技術的な面白さです。ソフトウェアを作るのは、現実の課題をどのようにモデリングし、構造化するかという作業です。

これはN=1の問題ではなく、小売企業と一緒に進めている事業に対して、普遍的な解決策を見出そうとすること。また、対処療法的ではなく、ネットスーパーが円滑に回るために、どの部分がどのように機能するのかを正しく理解することが重要です。事業やオペレーションを正確に理解することはとても難しく、4年間取り組んできても常に新しい発見があります。難易度の高いものに向き合うこと自体が面白いですし、課題を解くことも楽しいです。

坂本：今後プラットフォームとしてインターフェースを公開した際、利用者の個人やスタートアップだけでなく、システム開発企業とも連携するようになると想定しています。

買い物を便利にするというテーマを、自分たちだけでなく、他の多くの企業と連携して実現するのは楽しみですし、今以上の課題解決や便利さを届けることができると思っています。スタートアップだけでなく、大企業とも連携・協力してより大きな課題を解決しようとしている点が面白いですね。

現時点のチャレンジ・課題とやりがい

片山：逆に難しさや現状の課題についても教えて下さい。

石川：そうですね、難しい点はたくさんあります。設計自体も難しいですし、問題を正確に理解することも難しいです。ただ、それ以上に自分たちが描いているプラットフォームのビジョンを維持することが一番難しいと感じています。

目の前にいるユーザーやパートナーからの要望をできる限り応えたい気持ちがあります。しかし、すべての要望をそのまま鵜呑みにしても、すべての人が求めるものを作ることはできません。パートナーのみならず、社内のビジネスチーム、プロダクトマネージャー、ソフトウェアエンジニアの意見を調整しつつ規律を守ることが非常に難しいです。

坂本：私の実体験でも同じことを感じます。目の前の声を聞くのは良いことですが、聞きすぎると身動きが取れなくなります。これがまさに保守性の話です。

別のプロダクトであれば、ユーザーの声を拾うのが正しいかもしれませんが、たくさんのパートナーが参加するプラットフォームビジネスでは、それを聞きすぎてしまうと、それが後々負債となってしまいます。教科書的な理屈では最初から理解していたつもりですが、実際に3年ほどやってみてようやく分かってきました。

ただ、この難しさが、同時に面白さにもつながります。プラットフォーム的な取り組みを単にやってみるのではなく、プラットフォーム化しなければビジネスとして成立しないことが分かってきたのです。だからこの取り組みは、ビジネス的な要求から来ているチャレンジであり、それがさらに面白さを感じる部分です。

直近の取り組み

片山：直近の話題として、どういった取り組みを始めようとしているのでしょうか？また、開発チームにはどのような目標を持ってもらいたいと考えていますか？

石川：プラットフォームの文脈で言えば...うーん、どう表現すれば良いかな。ネットスーパーやドラッグストアの運営を進める中で、プラットフォームとして果たすべき役割を見直しています。最初は何でもやっていた感覚がありますが、これでは全国にプロダクトを届けるのは難しいです。

全ての要望に応えることはできませんが、どの機能が日本全国に価値を届ける上で不可欠かを見つけ出し、プロダクトの形を整えていくことが大事です。つまり、プロダクトの価値を再確認し、どのように代替できるかを議論し、それに対する答えを出していくことがチームの役割だと思っています。

役割分担の側面もありますが、重要なのは、達成したいプロダクトの状態に向けて、適切にモデリングし直すことです。単に新しい機能を作る能力よりも、利用者がより安全に使えるように、精度を上げていくことが求められています。実際に、今の店舗チームでもそのような取り組みが進んでいます。

片山：Stailerとしての取り組みと、Stailerがシステム開発企業に機能追加してもらう部分を明確にするための探索ですね。チームとして見えている部分のモデリングを行い、境界線をどのように定義しているのでしょうか？境界線を引く決定は誰が行っているのですか？

石川：これはインタラクティブなプロセスだと思っています。チームとして事情がある場合、それを共有して話し合いながら進めています。特定の誰かが決定するわけではなく、最終的にはチーム全体で持ちます。経営課題や戦略から、CTOとして「こうすべき」という支援はしますが、実際のプロダクトの実装はチームが決めます。

片山：大きな企業構造の変化が起こるとき、どう決定するか、実装するかは難しい問題です。インタラクティブなプロセスは良いと思いますし、ドメインに詳しいメンバーと一緒に考えるのは良いことだと思います。

オフィスイベント時の様子

一緒に働きたい人・求める人物像

片山：そのような状況で、どんな人にメンバーとして加わってもらいたいですか？

坂本：たくさんのパートナーと仕事をしてきたからこそ、共通した要素や抽象化できるものが見えてきました。すでに材料があるので、それをどう抽象化し、どのように扱うかを考えるのが好きな人が良いですね。

素直に全ての声を聞き続けるだけでは、全員を支援することは難しいです。声を聞いた結果、「ちょっと違う方向に進んだ方が良いのでは？」と感じた時には、あえて別のスタンスを取ることができる人が理想です。目の前の声だけでなく、プラットフォームやプロダクト全体を俯瞰し、どう解決できるかを議論できる人が必要です。もちろん、「腕力で全部解決してやるぞ！」という意気込みを持った人も歓迎します。

石川：うーん、被らないところを挙げると…(笑)
そうですね、Stailerの事業を進めていく上で、事業課題に対して適切にソフトウェアを作れる人が良いです。大規模でなくても、モノを作って、それがうまく動くと嬉しいじゃないですか。そういう感覚を共有し、さらにその感覚を広く伝播できる人が望ましいです。

単純なクラス1つでも、思い通りに動くと嬉しいものですが、大規模なソフトウェアを作る場合、チームにはいろんな得意分野やスタイルを持つ人たちが集まって、適切に動くものをつくります。チームメンバーとインタラクションしながら進めていける能力を持った人が来てくれると嬉しいな、と思います。

片山：私も、そういった人と一緒に働けたら嬉しいです！久しぶりのブログ記事だから、なんだか緊張感と固さがありましたね(笑)　伝えきれなかった部分もあるので、そのあたりはカジュアル面談や選考過程で話せたらと思います！

保守性だけにとどまらない！各開発チームの取り組みはこちらから

10X Product Blog

10Xでは一緒に働くメンバーを募集中です！

10Xでは未来をより良くする事業・組織のために、ソフトウェアエンジニアを募集しています。
詳細はこちらをご覧ください。
10X 募集職種一覧