エンジニア,PdM,Growth,Bizそれぞれの視点から Stailerのプラットフォーム化の現在と未来

2022/3/25

10Xが開発・運営を行う「Stailer」。2021年より、ネットスーパーのモバイルUXだけではなく、チェーンストアのためのWhole Productとなるべくプラットフォーム化を進めています。
今回は、多くのパートナーへ向けてサービス提供を推進するPartner Launch Teamの4名のリーダーに、それぞれの観点からStailerのプラットフォーム化に向けた歩みを紹介してもらいました。

坂本和大 @kazu0620 | Software Engineer
KLabでのソーシャルゲーム開発・個人でのモバイルアプリ開発の経験を経た後、Sansanへ。『Eight』のモバイルアプリ開発にエンジニアリングマネージャー / プロダクトマネージャーとして携わる。現在Partner Launchチームのリーダーを務める

浦祐介 @ysk_ur | Product Manager
グリー株式会社でデータアナリストに携わった後、ランサーズ株式会社にて新規事業責任者を経験。その後、株式会社ZOZOテクノロジーズにてPdMチームのマネージャーとして、広告事業の立ち上げ、PdMチームの組成、AI導入の推進、大型リニューアルなどを担当。2021年5月に10Xへ入社。PdMとしてPartner Launchチームのリーダーを務める

松田慎太郎 @mattsun10919298 | Growth
株式会社ブレインパッドにデータアナリストとして入社。その後株式会社メルカリにてBusiness Intelligence Teamにてプロダクト改善のための分析やアナリティクス組織の運営を担当。その後三井不動産株式会社にてデータ活用プロジェクトの推進・データ活用基盤の運用に従事。2021年8月より10XにGrowthとして入社。データマネジメント領域のサポートを通じて、Stailerのプラットフォーム化に貢献している

田村治顕 @TamuraHaruaki | Business Development
マッキンゼーアンドカンパニーにて、マネージャーとして主に製造業・農業等のtoB領域におけるオペレーション改善・組織変革・戦略策定支援等に従事。料理とテニスが趣味。BizDevとして、サービスローンチまでのサポートを担う

本記事は、2022年3月7日に公開した、CEO矢本（@yamotty3）のPodcast「Zero Topic」のエピソードを記事化したものとなります。ぜひPodcastも併せてお聞きください。

■Zero Topic | #218 Partner Launch TeamによるStailerのプラットフォーム化のこれまでとこれから (Apple Podcast / Spotify)

提供にかかるコストが100→3に進化！Stailerをプラットフォーム化するまで。開発、PdM、データ、BizDevそれぞれの視点

Stailerの歩みはプロダクト部門紹介資料もご覧ください

矢本：まず坂本さん、Stailerのプラットフォーム化の歴史について、エンジニアリングの側面を簡単に教えてもらえますでしょうか。

坂本：プラットフォーム化を目指すとなった昨年の段階では、まだ特定のパートナーに強くひもづいたプログラムが多くありました。

それを複数のパートナーでも使えるように、より抽象度を高めて「プラットフォームとしてStailerにある機能はどのパートナーでも使える」という状態を目指し、直近の改修を行っています。そうした開発を通じて、徐々にStailerがプラットフォームとして成り立ってきています。

矢本：特定のパートナーに紐づいたプログラムを、別の会社にも提供するとなった時、以前かかっていた手間を100とすると、今はどれくらいなんでしょう？

坂本：モノによっては3〜5、というレベルまで減っています！まだ、10〜20かかっているものもありますが、下がってきていますね。Stailerにすでに搭載されている機能であれば、開発コストはほぼ0で提供できることが増えてきていると思います。

矢本：すごい進化ですよね！そのシフトにあたっての苦労はあったんでしょうか。

坂本：最初は僕もキャッチアップできてない時期があり、どの機能がどのパートナーに紐づいた機能なのか、把握できていませんでした。機能としてはStailerにあるのだから、別のパートナーのサービスでも動くだろうと思っていたら、理想の挙動をしない……ということが結構あって。

その課題に対応すべく、まずはStailerにあるべき機能・あるべき動きを抽象化して定義し、これはこのパートナーのための特別な機能である、と整理をする。そのうえで、プログラムに直接ハードコーディングされていたコードを、パートナーごとの個別設定のファイルに移す、という実装を行いました。例えば、あるパートナーで配達がある場合、プログラムの中のいろんな箇所に「このパートナーのときは配達をする」と記述されていたのを、パートナーごとの設定ファイルでのみ「宅配をするかどうか」と定義するように変える、という感じです。

現場に赴きパートナーデモや現地調整などを行う

矢本：どのパートナーがどの機能を使うのか、膨大な機能のマネージが必要になってくると思うのですが、浦さんはPdMとして、どのように取り組まれたのでしょうか。

浦：もともと社内にあったStailerの機能リストを整理して、どのパートナーにどの機能を提供しているのか一覧でわかる状態にしました。このリストは適宜メンテナンスを行い、プラットフォーム自体に機能が追加されたら、パートナーのテーブルに追加されるようになっているようになっています。たとえば「合計◯円以上で配送料が無料」「内税か外税か」等、機能ではないが、パートナーごとに異なる細かい設定をNotionページに一覧で管理できるようにしています。

矢本：Growthの松田さんはデータマネジメントの文脈で最初の段階から入っていましたよね。現在にかけて、どう変化していったか教えていただけますか。

松田：まずStailerにおけるデータマネジメントってどういうことをやっているのか説明しますね。たとえば「ネットスーパーでトマトが買える」を実現するためには、それぞれの小売事業者の方が持っている「今日はトマトが15個あり、1つの値段は128円」というデータをStailerに連携させることが必要です。これだけ聞くと簡単に思えるのですが、ネットスーパーの特徴として、店舗ごとに在庫やラインナップが異なり、大量の商品があり、それぞれのSKUごとに毎日値段が変動したり、特売もあったり……そうした値段や在庫の変動に、柔軟に対応していかねばならないのが難しい点です。

で、初期の頃のデータマネジメントはStailerがサーバーサイドで採用しているDartのコード内で、データ連携を表現していました。メリットは、サーバーサイドがDartなので親和性が高いところでしたが、同時にデメリットもあり、データ連携のコードの仕様を変えたり運用内のミスが見つかった際に原因の特定が困難ということがありました。さらにパートナーが増えていく未来を考えた時に大きな課題があり、データ連携のコーディングを各社に最適化する形は、横展開しづらいという状況が見えていました。

その課題解決のため私が入社した2021年の8月頃から「dbt」という、データパイプラインを作るツールへの切り替えを行いました！これにより、SQLが書ければデータパイプラインがかなり簡単に、さらに見通しよく作ることができるようになりました。また、既存のコードから独立した形でパイプラインを作ることができるのも強みですね。エラー箇所の特定も容易になり、改修も柔軟にできるようになりました。

Stailerアプリの検証を行う様子

矢本：dbtの導入によって、開発ボリュームが増えがちな商品マスタの構築を、エンジニアだけでなくGrowthチームでも独立して対応できるようになり、プロジェクト推進の効率が圧倒的に上がりましたね。

田村さんの担当するBizDev領域でも大きな変化があるのかなと思います。特定のパートナーに個別に作り込んでいるところからプラットフォーム化まで、Biz観点ではどのような変遷がありましたか？

田村：BizDevとしては、パートナーが実現したいことの抽象度をどうやって適切にあげていくのかという点に対して、コミュニケーションとドキュメンテーションに気を配っていました！

約1年前、まだパートナー数が少なく特定のパートナーに紐づいた開発をおこなっていた頃は、10X側も裏側のオペレーションやネットスーパーに必要な機能の解像度がまだ低かったと思います。小売の裏側にディープに入り込み、ネットスーパーの実現にあたって何が必要かつぶさに観察し、必要なことに並べる。そうして具体にフォーカスした開発をしていました。

現在は、いろんなパートナー企業に対して、汎用的に使えるものを開発していく必要があります。BizDevとしては、あるパートナーからの要望をそのまま受けるのではなく、他のパートナーに対して適用可能な形にするべく、実現したいことを1段抽象化し、何を達成したいのか、より鋭敏に考える必要が出てきました。

たとえば複数のパートナーから、「個人だけでなく法人向けに配送をしたい」という要望をいただいたことがあります。法人配送を実現するにあたっては、決済手段・誰が運ぶのか等……パートナーによって別々のサービス設計になるため各社に最適化しようとすると、どうしても個別開発になってしまう。そこでBizDevとプロダクトで連携し、「法人配送にあたってはどういう機能が最低限必要なのか」という共通の仕様をまず用意。そのうえで、パートナーごとに変動する部分は個別の対応を付加していく、という形になりました。

プラットフォーム化に合わせて変化した開発プロセスとは

矢本：Stailerのプラットフォーム化にあたって、BizDev / PdM / データ / 開発それぞれのレイヤーで、どう裾野を広げるかということをお話してきました。ここでまたミクロな話に戻っていきたいのですが、開発プロセスにも変化があったのではないでしょうか。今どんな形で開発全体をマネージしているか、坂本さん教えてください。

坂本：元々は、パートナーごとにタスクを管理しようとしていましたが、結局特定のパートナーのローンチまでのスケジュールを算出するためには、全てのタスクを直列に並べて管理しないと、いつ何ができるのか不透明になりやすい、という課題がありました。すべてのタスクを並列で進められればもちろん理想なのですが、現実的には限られたリソースの中で優先度の高いものから順に手を付けるしかないのですよね。そうすると、直列にタスクが並んだ状態でないといま僕らは順調なのか、ヤバいのか、という状況が見えづらかったんです。

現在は、パートナーローンチチームで、単一のBackLogを作って管理しています。必要なタスクを登録し、さらに優先度順に並べておくことでリストを上からこなしていけば、あるべき状態にたどり着けるようにしています。

また、Backlogの1つ1つのIssueに対しては、見積もりを振っています。この見積もりは相対で出すようにしており、「基準となるタスクが3ポイントとすると、このタスクは何ポイントか」と毎回チームで見積もっています。加えて、1週間でどれくらいのポイントを消化できた=予想通りに進捗できたのか、を計測しています。過去3週のポイント消化数を踏まえて、これからの2〜3週でどれくらいのポイントが消化できるのか目処がつくようになりました。特定の期間で、どのマイルストーンを達成できるのかわかっている状態になったのが、ここ半年間で取り組んだことの大きな成果ですね！

矢本：すごく健全ですね。浦さん、PdM観点だとどうでしょうか。

ネットスーパー立ち上げに必要なスタッフアプリもすべて開発している

浦：サービスリリースにあたっては、事前に判明していた大きなマイルストーン以外にも、細かい調整が度々発生するんですよね。特に、「最新のアプリをパートナーに提供し事前研修を実施する」「各種データの繋ぎこみテストをする」といったタイミングがあります。

こうした予定も判明した時点でBacklog上で先に記入し「この時期にはこれが必要」と見える化しています。全体の流れを可視化することで、デザイナーにとっては「このタイミングで開発チームが動くから、その前にチケットを消化する」、開発チームとしても「研修やデータ検証を行うから、その前にリリースする」など、開発に関わるメンバーが動きやすくなった実感があります。

矢本：内部の認識とパートナーのスケジュールが一致できるようになり、効率化がすすみましたね！このフローは、データマネジメントにも影響を及ぼしたと思うのですが、Growthとして効果はありましたか。

松田：見通しがよくなったのと、関係者との認識合わせがしやすくなりました！見通しについては、バックログ（タスクリスト）の上からやって行けばいい状態になっており、チームの中で「今週はここまでやればいいんだ」、という共通の認識を共有できるためで、安心して仕事に取り組めるようになりました。

また周囲との連携については、上記のバックログの内容をBizチームと認識合わせしています。Biz側から見た「今週はここまで進捗したい」というラインと、私たちのチームのバックログをあわせることで、会社として「何をどこまでやるのか」が明確になりました。これにより、ボールを落としたり、期限の認識が違ったり、というトラブルを未然に防げるようになったのは大きな収穫ですね。

職種を超えて議論を行うことも

矢本：BizDevの田村さんの目線でもパートナーに対しての影響はありましたか？

田村：大きな変化があったなと思っています。我々のプロジェクトマネジメントの確実性が上がることで、パートナーへの説明責任をより果たせる様になりました。もちろん、最初に引いたスケジュール通りに物事が進むことがベストですが、プロジェクト進行においてはどうしても不確実性があります。何か想定外のことが起き、パートナーとコミュニケーションすることは当然必要です。

その際、現状把握とシミュレーションの精度があがったことでパートナーと問題解決ができる幅がぐっと広がった実感があります。日程を後ろに倒すのか、ある機能のリリースの優先度を下げて間に合わせるのか、はたまた別のソリューションがあるのか...それぞれの根拠を元にオプションをテーブルに並べられ、パートナーとフェアに話ができる様になりました。信頼関係に繋がる大きな影響だと考えています。10X内でも、対パートナーという意味でも、プロジェクトの透明性が上がり物事が進めやすくなりました！

矢本：パートナーとのコミュニケーションに変化はありましたか？

田村：1年前はStailerの機能がまだ少なかったので、ドキュメントをもとに、パートナーと仕様をすりあわせプロダクト開発をしていました。今はStailerプラットフォームという土台があるので、早い段階で現地デモを行い実アプリを一緒に見ながら作業もできる。Stailerで実現できる一連の流れをパートナーにもお見せした上で、不足している機能や、オペレーションの制約条件にあわせた調整をしています。さらに、リリース前にマストな機能を考え、本当にエッセンシャルな開発に絞ってパートナーと合意して進められます。パートナーにとっても、何が必要か、という理解度がぐっと上がった状態です。

矢本：浦さんは相当な回数の現地デモの経験があると思いますが、ギャップの抽出の整理にあたっての工夫があればお話いただけますか。

スタッフアプリの開発風景

浦：以前はパートナーとはStailerの機能をまとめたドキュメントをもとにお話ししていました。ただ、ドキュメントでプロダクトのことを理解してもらえるのはごく一部だと思っていて。最近は、パートナーとの議論のなるべく早い段階で実際にデモを行うステップを取り入れ、パートナーごとのアプリを作って現地で試してみるようになりました。実際にプロダクトを見ながら大小さまざまなリクエストを伺います。

デモを通して、色々なリクエストがでてきます。たとえば最近だと「スタッフアプリにJANコード表示してほしい」という要求が、4社で別々に出てきました。4社から要望として出てくるなら、オペレーションとしての重要度が明確なので、それはもうプラットフォームの機能の取り込みましょう、という判断をしたり。

矢本：インプットの津波みたいな状況の中で、何をマストとしていくのかの判断をするのは相当大変ですよね。

Stailerのこれから。StailerのVersion.2ではどの山を登るのか

矢本：これまで、個別のパートナーに向けて開発していたVersion.0だとして、今プラットフォーム化を進めているのはVersion.1。これから進むVersion.2はどこを目指すのか。各自の視点で語ってもらえますか？

坂本：開発的には2点あると思っています。1つはさっきまでお話したような、将来的にStailer共通機能として取り込むべきだが、まだないものを抽象化して、Stailerに実装することです。設定を変えれば動くようになる機能を増やし、マストなものに対応していく方向ですね。

もう1つはその逆で「これはあきらかに共通化できないな」というパートナー固有の仕様をうまく取り込めるようにしていく方向です。たとえばプラグインのような形で、この規格に沿った計算ロジックを作れば、簡単にStailerに取り込める、という感じです。この2軸を同時に両方やっていくというのが、開発目線でのVersion.2なのかなと考えています。

矢本：先方が何かを表現したい時、APIに沿ってやればある程度までは先方で完結できる、という世界線ですよね！

坂本：最終的にはそこまで考えています、でもそれはVersion.3かも（笑）

職種を超えてプロダクトを理解し、開発を推進している

矢本：データマネジメントの観点で、松田さんはどうでしょうか。

松田：複数のパートナーがローンチしようとしても受け切れる体制を作ることをが目指したいです。そのために、データパイプライン作成効率をあげることと、リソースを増やすことの2点が重要と考えています。まず効率改善のために、今のデータパイプラインのアーキテクチャをより進化したものにしたいと思っています。ボタンを押せば基本的なデータパイプラインのアーキテクチャができる or テンプレをコピペすれば大体できる、という状態が理想ですが、これは今後試行錯誤していきたいトピックですね。

また二点目のリソースの観点においては、チームの運営もより洗練されたものにしていきたいです。小売事業者様のデータはかなり個別性が高く、スーパーなのかドラッグストアなのかでも違っています。これらのマネージを一人でやりきるのは難しく、並列化して扱える様にするため、業務委託の方々と仕事をしています。現状、メンバーとの効率的なやりとりのために、スクラム開発を試しています。こちらもよりスムーズに運用するために試行錯誤しています。

矢本：田村さんの目線で全体プロセスや体制の検討をしてもらっていますよね。

田村：Bizとしては、組織と業務プロセスという2つの観点で取り組んでいます。パートナーローンチチームは、今後、今よりももっとたくさんのパートナー企業に対して、効率的・安定的に事業を立ち上げるということを目指しています。将来的に今の2〜3倍のパートナーを同時に抱えるとなった場合、現状の体制のままだと破綻するリスクがあります。

組織面についてはクロスファンクショナルなチームをいくつか抑えていく必要があるのではと考えています。多くのパートナーは、四半期の1回リリースを迎えるタイミングがあります。例えば、2022年の1〜3月に3社がサービスローンチする場合、だいたい同じタイミングでデモ実施〜ギャップ抽出〜要件定義〜開発〜リリースになります。同じスケジュールで進むプロジェクトの場合は単一のチームで進めるほうが効率的なのでは、と考えています。

業務プロセスでは、キャッチアップ用のドキュメントをつくっています。これはパートナーに対し、プロジェクトの立ち上げ時にお見せするドキュメント一覧で、「必要なデータはこれなので準備してください」「次はこれについて議論しましょう」という必要事項が数十個ずつ書かれており、これらを全てクリアすれば、サービスをリリースができるようなイメージです。このドキュメントを見れば誰でもわかる、という状態にすることで、対パートナーだけではなく、社内メンバーのオンボーディングも改善できると考えています。そういった改善でスケーラビリティを確保していきたいです。

矢本：浦さんには、BizDevと開発の間に入って繋いでいくという観点で、どういう進化をしていきたいか、伺えればと思います

浦：今のパートナー数は1桁ですが、今後の成長を考えるにあたって、数百社のパートナーを迎えられるのか？という視点は常に持つようにしています。今後は、機能をつくるPdMも、プラットフォーム全体を改善するPdMもどちらも必要になってきます。属性に応じたPdMアサインができると、よりスケーラブルな体制を作っていけるのではと考えています。

10Xオフィスで議論を交わすCEO矢本とPdM浦

矢本：ありがとうございます、StailerのVerison.2の姿が見えてきましたね。すでに出来上がっているものではなく、これからまだまだ作り上げていく余地があり、10Xは引き続き仲間を募集をしています！

Version.10くらいになった暁には、Zoomでパートナーと会話をし、チェックリストを埋め、ボタンをポチッとするとアプリが完成するような状態になってますかね。翌日には現地デモを実施でき、ローンチまでの必要事項が洗い出されている、という状態。これはVersion.10か、それともVersion.100くらいでしょうか...（笑）

浦：それはもうちょっと早いほうがいいんじゃないでしょうか。Version.5とか？（笑）

矢本：そうですね！4月に、パートナーローンチチームの詳細を話すイベントをやりますので、こちらもぜひご参加ください。今日はパートナーローンチチームの4名に来てもらい、Stailerについて話してもらいました。

4名：ありがとうございました！