プラットフォーム化ヘの歩み
この記事は🎄10X プロダクトアドベントカレンダー2023 の最終日の記事です。24日目の昨日は石田(wapa5pow)さんによる「CSVの内容を検証するtable-validatorというnpmパッケージを作りました」 でした。渋い。
はじめに - プラットフォーム化への狼煙
2022年より、Stailerは明確に「プラットフォーム」へ進化することを社内外へ開示してきました。2022年6月にはプラットフォームの定義をアグリゲーターとの比較の中で整理し、Stailerの目指す方向性を考察してきました。
プラットフォームは、「ユーザーに対して3rd Partyがユーザー体験をコントロールするためのツルハシを提供」することに徹し、ユーザー体験へ間接的に関与する
加えて、2022年11月には特にStailerが主戦場とする巨大なエンタープライズ企業向けのプラットフォームに強く求められる要求や、エンプラ向けのプラットフォームとして進むべき方向性を考察しました。
今年2023年は、このときに描いた方向へ向けて、試行錯誤しながらも着実に歩みを進める1年だったと言えます。本記事ではStailerのプラットフォーム化へ向けた本年の歩み、そして現在地を記したいと思います。
プラットフォームとしての内部方針を提示
Stailerをプラットフォームとして開発していくための内部方針を作成し、開示しました。
この指針を10Xが必要とした背景は大きく2つあります。
- 機能的個別性の発散が増加し続けており、全社で強い制約をもつ必要
- 機能的個別性に頼らずに事業をスケールする形態へ、事業活動全体が進化する必要
見ての通り、指針レベルではかなり強く個別性の排除を謳っています。これに伴い「既存機能の個別性も今すぐに排除すべきなの？」といった議論も発生しています (非常に良い議論だと思っています)。
方針を示す時に、「分かりづらく、どちらへ進むかわからない」よりは「どんなネガがあっても、どこへ進むかは明確なもの」を出そうと思っていました。まずまず機能しているように実感しています。
専門性ごとの開発チームへ移行
Stailerではこの3年、「既存システムのフルリプレイス」案件を多数扱ってきました。
フルリプレイスは新規にネットスーパー事業・システムを導入するケースと比較して100xほど難易度が高く、その理由は「どの機能 (ユーザーストーリー)にも利用者がついている」ためです。中には捨てきれない・開発なしでは対応しきれないストーリーが必ず存在します。
こういった事情もあって、「パートナーに対して要求を解消する開発チームを組成してアサインする」という状況を長らく継続してきました。これは当時の逆コンウェイの本則としては一定正しかったと思います。
しかし2023年4月にはこれを大きく変更しました。
「専門性ごとに開発チームを組成し、パートナーの関心を専門性ごとに分離して扱う」という順序の逆転を起こしたのです。これはプラットフォームを事業の主軸にし、多種多様なパートナーを迎え入れられるようにしていく、という事業のパラダイムの変更でもあり、そこへ向けた組織の再設計と言えます。
これを踏み切った背景には以下があります。
- 一定の必要機能がStailer上に揃い、一部は枯れ始めてきたこと
- 品質と運用をチームで担保する姿へ変化する必要があったこと
- ドメインの専門性を固定されたチームへ閉じ込め、開発認知不可を下げる必要があったこと
移行後はドメインを複数に分割する際の責任分界点をどこにするか、境界が曖昧なソースコードのオーナーシップをどうするか、開発チームへの要求をどのように伝達すべきか、という様々なインターフェースのあり方で慌ただしく模索してきました。
本組織へ移行したことによって、「チーム専門性」「運用安定性」「品質への長期的な取り組み」といったリターンは確実に得られており、この方向を更に進化させていくことに会社としての自信を深められたように思います。
チーム移行はどんなときでも難しいものですが、Engineering ManagerのとProduct Managerが丁寧にプロジェクトを推進してくれました。
品質フォーカスが強く進んだ
Stailerはパートナーの「事業」をまるごと預かる事業であり、かつ中長期でネットスーパーが成長し続けていくことへBetしているため、非常に高い品質が求められます。しかしその「品質」とは具体的に何なのか、我々は正しく解像度を持てていなかったように思います。
今年はこの「品質」というものについて大きく2つのアプローチで理解・改善が進みました。
SLO
1つはStailerを利用される方にとっての最も重要なユーザーストーリー = Critical User Journeyを言語化し、これに基づくメトリクス (SLO) を定め、モニタリング・改善するという取り組みです。経営直下に特別チームを組成し、PMの江波さんにリードをしてもらいながら推進してきました。
Stailerにとって「高いアップタイム・レスポンスパフォーマンス」を約束すべきコア of コアはなにか、について理解が深まり、また客観的な数字を通じて状態把握ができるようになりました。ダッシュボードによる可視化が肝要ですが、babarot率いるSREチームがDATADOG上で数日で実装し、あっという間に全社展開…驚嘆したものです。
独自の品質定義
もう一つは今年の秋に発表した中期経営方針をもとに、これを達成するために必要な「プロダクト品質のGap」を洗い出すという作業です。具体的にはISO/IEC 25010 に定められる品質の8項目に対し、あるべき姿と現状の差分を言語化を進めました。
この結果、最も大きなGapは「保守性」であるという結論に。更に保守性を深掘りしていくと、「運営自律性」や「システム運用効率性」、「テスト容易性」といった独自のキーワードが浮かび上がりました (By CTO)。
こういった独自の用語で品質をキャプチャしていくこと自体が、品質に向き合う第1歩で重要なことだ！というのを品質管理部のブロッコリーさんからバックアップいただけたことは私個人としても自信になりました。
さらに定義するだけでなく、2023年下期は全社の最重要イシューの一つとして全社Focusに定めて、各チームの運営自律性やシステム運用効率性を可視化し、モニタリングし、改善する取り組みを進めています。
今思うと、昨年記述した「プラットフォームは(中略)ユーザー体験へ間接的に関与する」という定義はまさに運営自律性そのものです。中長期で、パートナー事業そのものを担うStailerだからこそ出てくるキーワードであると思います。
品質とは終わりなき旅であり、まだ何も成し遂げたわけではないですが、中長期で発展するプラットフォームを創るために「品質が最重要である」と宣言し、「全社で取り組めていること」には少なからず誇りを感じています。
内外の責任分界が切れ始めた
「Stailerはどういった”プラットフォーム”になるのか」では、最終的にプラットフォームはコアとアプリケーションに分離し、10Xはコアの開発に、アプリケーションは3rd Partyの開発者が担える(ex. Shopify App Store) 状態が目指すべき方向性のひとつなのではないか？と考えていました。
正直、このアイデア自体はまだ活きているものの、ネットスーパーという「事業」がまだ枯れていないことから、到達には探索的な道のりが必要だと評価しています。
一方で、ここへ進む道のりとしてコアとアプリケーションの分離や、内部で担う責任と、外部システムの連携部分で担う責任を分離する、ということはトライが進み始めています。その最たる例が、パートナーの基幹システムと連携して構築している「マスターデータを生成システム」です。
この記事では重要なマスタの一つである「商品マスタ」がどのように構築されているかが記述されていますが、元となるソースデータはパートナーから受領しています (下図)。
このパートナーのシステムとのデータのやり取りに置いてStailerサイドで果たす責務とパートナーサイドで果たす責務を分界するための整理を進め始めています。
これまではこういった責務もStailerが一手に引き受けることでスピードが早いものの、過剰な運用コストも引き取ってしまう、といった反省がありましたが、中長期的に・両者が健全に事業を運営していく上で責任分界とは極めて重要であり、推進しているところです。
総じて
2022年に「プラットフォーム化」を宣言してから約1年半をかけて取り組んできたことを私の目線で記述しました。プラットフォーム化は開発チームが独立して頑張ればいい、というものではなく、全社的な取り組みによってしか進まない、というのが私の感想です。
例えばこの文章の中でも何度も出てきた「品質」を改善するには、ソースコードや運用のあり方、パートナーとの期待値調整、契約書の作り方など、ありとあらゆるものを見直さなければいけません。誰か一人やチームの努力に頼るのでなく、経営として意志決定をし、ベクトルを創り出して痛みを伴いながら初めてその方向へ向かうことができるという類のものだといえます。
こういった取り組みを経て、「Stailerというプラットフォームはパートナーとの長期的・共同成長が重要であり、そのための最重要ドライバーは”品質”である」と確信しています。
あらゆるインターフェースで「プラットフォーム化」に向けた取り組みが進行している真っ最中ですが、10Xなら、「エンタープライズ・プラットフォーム」で掲げた5つの要点を満たせるような進化を、必ず実現するだろうと信じています。