「この2年弱でStailerに対してパートナー企業から求められる価値や役割、そして追い求めるべきエンジニア組織のあり方も変わってきました」

Stailerの提供開始から約2年。取締役CTOの石川洋資（@_ishkawa）はこう振り返ります。小売チェーンがECを立ち上げるためのプラットフォーム・Stailerは現在、スーパーマーケットやドラッグストアを中心に8パートナーに導入されるなど、活用の幅が広がっています。

本記事では、この期間にStailerに起きた変化、そして今後追い求めていくエンジニア組織のあり方について、石川に話してもらいました。

Stailerの提供開始から約2年で変わってきた「求められる価値」

──2020年5月にStailerを提供開始してから、約2年弱が経過しました。エンジニアの視点から見た、現在のStailerの状況について教えてください。

石川：Stailerの提供を始めてから1年くらいは、とにかく事業機会を掴みに行くことを考えていました。私たちが提供するサービスは価値があるのかどうか検証しながら、求められる事業機会に対して応えられるシステムになっているのかどうか。店舗オペレーションや配送を管理する機能など、提供する価値を広げることで、事業機会を掴みに行っていたという感じです。

この1年くらいは事業機会を掴めている手応えは感じており、今はどちらかと言えばStailerがパートナー企業の事業成長を支えるサービスになれているかを確認するフェーズです。具体的には（サービスとしての）信頼性がどれくらい確保されているか、（決済や注文管理、配送といった）各ドメインに対する開発の要求に対して、どれだけ応えていけるかが重要になってきており、2年前とは求められる価値が大きく変わってきています。

振り返ると、1年目は実現可能かどうかを探索するフェーズで、2年目は実現可能であることがわかったのでサービスのクオリティを高めていくフェーズという感じです。

Stailerの初リリース時のサービス紹介

──振り返ってみて「これでいける」と思ったタイミングはあったのでしょうか？

石川：サービスの提供を開始した段階で、10Xとしては「ある程度はいけるのではないか」という見込みはあったのですが、パートナー企業も含めてお互いが「これでやっていける」という確信を持てるようになったのは最近のこと。今年の4月くらいですかね。
初期からご一緒していたとあるパートナー企業が、Stailerを本格活用して自社のネットスーパーを成長させていく方針に舵を切る判断をしたことも、10Xにとっては大きな出来事でした。

──先ほど「求められる価値が大きく変わってきている」とのことでしたが、エンジニア視点では何か変わったことはあったのでしょうか。

石川：最初の段階ではシステムを密結合状態（システムの構成要素間の結びつきや互いの依存関係、関連性などが強い状態のこと）にし、あくまで“ひとつのシステムをみんなでつくる”という感じで開発をしていました。ただ開発が進んでいくにつれて、Stailerはひとつの形にとどめておくには、あまりにもドメインが広い状態になってきました。

具体的には（パートナー企業の）基幹システムと連携して在庫データを作成するところから始まり、実際にお客さんが商品を見て注文を入れ、注文された商品を店舗スタッフがピッキングし、ドライバーが商品を配達して、最終的に売上を基幹システムに戻すといったように、複数のドメインに分かれています。また、注文ひとつとっても在庫のチェックやクレジットカード会社との連携やポイントカードシステムとの連携もある。

そうした各ドメインが分離ができていない状態で開発を進めていくと、どうしても（どこかのドメインでミスが起きたらサービス全体がダメになってしまうという）リスクが高い状態に陥ってしまいますし、新しいメンバーが入ってきたときの認知コストも高い状態にもなってしまいます。そうした副作用が見通せない状態になっているのが、いまの10Xのエンジニア組織で起きていることです。これを解決していかなければと思っています。

また、開発者としては自分たちが開発したシステムに関しては運用も含めてオーナーシップを持つことが良いとされているのですが、現在の状態ではオーナーシップを持つにはドメインが広すぎる。何かを改善しようと思っても認知コストが高く開発が難しい状態なっているので、ドメインを分割していくことがいま、エンジニア組織がやるべきことです。

──ドメインを分割するというのは、つまりマイクロサービス化するということですか？

石川：マイクロサービス化も手段のひとつではあります。ただ、10Xは最初のステップとしてモジュラーモノリスを採用しようとしており、そこから発展していったらマイクロサービス化することもあり得るかなと思っています。

ドメイン分割の先にある、エンジニアとしてのチャレンジとは？

──ドメインを分割した先にシステム自体は今後どうなっていくのでしょうか。

石川：Stailerには注文の管理や店舗側のオペレーション管理、配送のオペレーション管理といったドメインがあります。それぞれのドメインを分割し、独立させることでサービスの品質を上げ、それによってパートナー企業のビジネス的な要求により早く応えられるようになる、他のシステムとの連携がよりスムーズになると思います。

また、10Xとしてはドメインを分割することで開発者の認知コストを下げることに加えて、開発による影響範囲を限定的にでき、開発者がドメインに対してオーナーシップを持って継続的に改善できるようになるといったメリットがあります。

──技術的なチャレンジになりそうなことはありますか？

石川：Stailerは“プラットフォーム”を標榜してサービスを提供していますが、本当にプラットフォームになりきれるかがチャレンジになると思っています。具体的には、どこまでをプラットフォームの標準的な機能として備えていき、どこまでをStailerを使って開発する人たちの責務にしていくか。責任分解の設計をうまくやる、ということです。

そのために必要となるのが、前述したドメインの分割です。例えば、すべての小売チェーンが同じオペレーションやシステムを使いたいわけではありません。「うちではこういうオペレーションにしたい」「うちはこういうサービス形態にしたい」といった要望が出てくる。そうなったときにドメインを分割しておくことで、機能の一部だけ利用することも可能になります。ドメインが独立した状態になり、連携可能なインターフェースを持つことで外部のシステムとの連携があったときに、そこの繋ぎこみをパートナー側ができるようになるかもしれません。それを現するためにはドメインが独立した状態にあり、開発者がオーナーシップを持ってインターフェースを設計できるようにしなければなりません。

Stailerの仕組みについて編集部にわかりやすく解説してくれるCTO

現在、10Xでは数年後に数十パートナーを獲得する、という具体的な数値を社内目標にしているのですが、数十パートナーが同じシステムを使うことはなく、それぞれの企業で固有の要件も出てくるはずです。その際に固有の要件はなるべく外に出せる状態にしておく必要があります。そうしなければ、サービスインのボトルネックが10Xの開発人員の調達になってしまう可能性がある。そこをボトルネックにしないためにも、外で持てるものは外で持てるようにすべきです。

最終的には、基本的に自分たちが何もやらない形でも小売チェーンがECを開始できる状態にすることが、プラットフォームとして成立した状態なのかなと思います。今までは人員を張ってがんばれば何とかなる状態でしたが、パートナー企業が増えていくとそうはいきません。これからは戦い方を変えていかなければいけないと思っています。

10Xは出社自由。エンジニアはリモート派が多いですが、オフィス出社派も。

CTOが考える「これからのエンジニア組織のあり方」

──今後、エンジニア組織も変わっていくのでしょうか。

石川：現在、エンジニア組織にはパートナーと向き合いながらサービスを開発・運営していく「パートナーソリューションズチーム」、パートナーとは直接対面しないけれどサービスに必要な機能を開発していく「サービスプラットフォームチーム」、最後が前者2つの開発チームを支え、運営の生産性を上げていくための取り組みを実施する「プラットフォームデベロップメントチーム」という3つのチームに分かれています。

この3つのチームの区分け自体は変わらないと思いますが、今後はよりクリティカルに独立したドメインを開発・運営していくチームが生まれていきます。

ドメインの開発・運営の部分はStailerを運営していく中で非常に重要な役割です。例えば、注文内容の1つの間違いも、決済金額の1円の間違いも、配送の1件の間違いも、サービス上は致命的な問題となる。かなり高い品質が求められますし、影響範囲も大きいからこそ慎重に扱っていかなければいけないと思っています。

だからこそ、ドメインの開発・運営に関しては固定されたチームが固定されたドメインを開発していくのが好ましい。パートナーに向き合うチームは存在し続けると思いますが、彼らはドメインのチームが公開するインターフェースを活用して、システムの組み替えを行っていきます。今まではそこが一体となっていたのですが、ドメインの開発・運営チームが存在することで、アプリ開発の速度を上げてもサービスが壊れる心配もないので、開発スピードも上げていくことができると思っています。

──個々のエンジニアの開発体験はどうしていきたいと思っていますか？

石川：自分がオーナーシップを持っている範囲と自分が認知しなければいけないことが一致していて、そこに対して素早く開発できる。そして、品質を上げていくことに対してモチベーション高く保てている状態が望ましいと思っています。

また、この2年でサービスとして求められる価値が増えました。2年前はとにかく価値があるものを素早くつくれることが最優先だったのですが、今は信頼性が高いことも求められていますし、信頼性をいかにして担保しているのか、再現性や取り組みが説明可能になっているかという観点も必要になってきています。そのために、プロセスの整備やモニタリングの仕組みの整備、テスト体制の拡充などに取り組んでいるところです。

このように求められる価値が変わってきているからこそ、今の10Xにはさまざまなバックグラウンドのエンジニアが増えてきています。 CTOとして、それぞれが自分の強みを生かして活躍してもらえる環境をつくっていきたいですね。

──いま、どんなエンジニアを求めていますか？

石川：今まではモバイルアプリ系のフロントエンド出身の人が多かったのですが、最近はバックエンドの経験がある人は特に採用したいと思っています。Stailerが成長していく鍵を握っているのが、バックエンドのアーキテクチャの移行だと思っているので、ぜひ少しでも興味のあるバックエンドのエンジニアには10Xに来てほしいです。

各ドメインに特化したバックエンドエンジニアもそうですが、バックエンドのシステム間の連携や外部システムとの連携の整合性をとっていくためのアーキテクチャを考える人も必要ですし、それぞれの信頼性を上げていくSREも必要です。そういう意味では、ここから面白いフェーズに入りますし、面白い機会はたくさんあると思っています。

7月には初の開発オフサイトを開催

──10Xでエンジニアとして開発する面白さはどこにありますか。

石川：生活に紐づくものだからこそ、使えることが当たり前。それを積み重ねることが信頼になりますし、価値にもなる。ネットスーパーがまだまだ定着していない要因として、お客様が期待する当たり前に到達できていないことが挙げられると思っています。

スーパー行ったら当たり前にお店がやっているし、当たり前に欲しいものがある。そういう意味では、ネットスーパーはまだまだこれからな部分が多い。

そうしたときに「信頼性」はひとつの当たり前を提供するものだと思っています。ここをきちんと担保していくことが、お客さんや人々の生活を変えていくものになる。そして、そこに取り組んでいく価値はあると思っています。

──最後に石川さんが考える理想のエンジニア組織について教えてください。

石川：開発の原点になるのはビジネス的な要求だと思っています。その要求に応えるシステムをつくることで、さらなる要求がくる。そして、その要求に応えていく。基本的にはこの繰り返しでサービスが開発されていきます。それを踏まえたときに、理想はビジネス的な要求に対して、その時々で適切な形で応えられていることです。要求に応えていくためのベストなかたちを継続的に探索できている。それが理想のエンジニア組織だと思っています。

そして、ビジネス的な要求のレベルが上がってきたときには、いろんなタイプの人材が必要になります。10Xのエンジニア組織では、一緒に働く人たちが得意なことに向き合う機会を提供し続けることで、個人もそうですがチーム全体でも最大限のパフォーマンスが発揮できるような環境にしていければと思っています。

一緒に働く仲間を募集しています！

10Xのミッション・バリューに共感いただける方からのご応募をお待ちしています！

カジュアル面談のお申し込み
採用情報