BlogPodcastThreadsしずかなインターネット
BlogPodcastThreadsしずかなインターネット
Top/Post

10Xはどのようにロードマップを運用していくのか

前回は10Xがどのようにプロダクト機能のロードマップを検討し、そして事業を推進するために具体的にどのようなロードマップを想定しているかを書きました。こちらの記事を読んでみてください。
 
そして続編となる今回は、 Stailer アプリケーションロードマップに対し、全社的にどのようにインプットとなる情報を与え、統合し、ガバナンスを構成し、意思決定し、開発していくかという運用方法や意思決定機関について記載したいと思います。
 
なぜこんなことを発信するのかって？それはあなたと一緒にこのロードマップを前に進めたいからですよ。最高のプロダクトチームを作りたいんです。そのために、まずは関心を持ってもらいたいから筆を執っています。

前提: アプリケーションとプラットフォームの分離

Stailer上において厳格なシステム上では「アプリケーション」と「プラットフォーム」の明確な分離や責任分解領域が存在しておらず、より明確にしていく途上にあります。このあたりについての私の考えはぜひ以下の記事を読んでみてください。
Stailerはどういった"プラットフォーム"になるのか
「Stailerの課題はなんですか？」と問われたら、最近は「スケーラビリティです」と答えています。 一つ一つが一球入魂のパートナーとの事業推進にかかる負担を軽減し、より高い成果を型として10Xがアウトプットするにはどうすれば良いか。この問いに対するストレートな答えが「プラットフォームとしての進化」にあると思っています。 本論の前に「 noteがFacebookやTwitterにならないためには、と考えてみた (2020) 」のなかで引用されていた「 The Bill Gates Line By Ben Thompson (2018)」というエントリに非常に感銘を受けたため、これを使ってプラットフォームとは何かという概念を揃えておきたいと思います。 The Bill Gates Line 」のエントリの始点は「GAFA等のBig Techが提供するサービスは必ずしもすべてがプラットフォームではない」というところにあります。そこでプラットフォームという概念と、対比として生まれるのがアグリゲーターという概念です。 プラットフォームとアグリゲーターという2つの概念については以下のように書かれています。 This is ultimately the most important distinction between platforms and aggregators: platforms are powerful because they facilitate a relationship between 3rd-party suppliers and end users; aggregators, on the other hand, intermediate and control it.
https://yamotty.tokyo/post/20220605
 
この記事で触れたように、Stailerとしては下図の「リリース・運用の完全な外部化」にて記述されている分離状態を目指しています。今はこの図を左から右に向けて頑張って移動しようと頑張っているんですね。
 
それは端的には以下のようなイシュー攻略を目指していると言えます。
  • プラットフォーム: アプリケーションを提供するための各機能のI/Fが分離され、プラグインとして内包される
  • アプリケーション: プラットフォームが搭載するプラグインを活用し、実際にユーザーへ提供される
 

ロードマップに沿った開発のスコープ

本ロードマップを通じて行われる「アプリケーションの開発」とは以下の実現を目的とします。
 
💡
ロードマップ開発のスコープ
  1. プラットフォーム上に特定のアプリケーションを生成するためのプラグイン(API)を開発する
  1. APIは社内・外部のディベロッパーにに公開できるように設計する
  1. APIの仕様書はすべてドキュメンテーションする
  1. 上記を通じて、ディベロッパーはStailer APIを通じてユーザーへ実際にアプリケーションの提供・運用することができる
 
これはBezosの7rulesに酷似していますが、大いに参考にしております。
AmazonのAPI設計方針 (The Bezos Mandate) - Qiita
The Bezos Mandate という文書があります。日本語に訳すと「ベゾスのお達し」とか「ベゾスの勅令」でしょうか。 言わずと知れたAmazon.comのCEO、 ジェフ・ベゾスが 開発チームに通達した内容です。 これが（元Amazon.com従業員によって）公開されたのは2011年ですが、ベゾスがこのお達しを出したのは 2002年前後です。17年経過した現在でも真理をついているどころか ようやく時代がベゾスに追いついたか という感想です。 この記事ではThe Bezos Mandateの紹介と、僭越ながら補足説明も行います。 原文は元Amazon.com従業員のGoogleエンジニア（公開当時）、 Steve Yeggeによって公開されました。 Google+に Stevey's Google Platforms Rant というタイトルで、Amazon.comと比べたGoogleに対する不満として投稿されたのですが、残念ながらGoogle+の閉鎖に伴い元記事も消えてしまったようです。 幸いなことに、元記事は様々な場所から引用されており、"Stevey's Google Platforms Rant"で検索するとたくさんのページがヒットします。 検索で最初にヒットした このページ を紹介しておきます。 お達しの内容は以下の通りです。 All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces.
https://qiita.com/shimataro999/items/a6c1ee4708bb2112610e

ステークホルダーへ示す期待値

Stailer上に搭載されるアプリケーション開発に関与する3つのステークホルダーと適切な期待値のアライメントを行うことを目的としています。
ステークホルダーロードマップ策定・運用を通じて提供したい価値
パートナー企業・期待機能がプラットフォームに含まれているかどうか、含まれる予定があるかどうかを判断できる ・その内容に応じて適切なアクションができる ・自社の要求をアプリケーション開発者へ適切にフィードバックできる
アプリケーション開発者 (10X/3P)・パートナーとの間でアプリケーションに対する期待値を適切にハンドリングできる ・アプリケーションのカスタマイズとプラットフォームへの機能追加を明確に分離できる ・プラットフォーム開発者へ追加すべき機能について適切なフィードバックができる
プラットフォーム開発者 (10X)・全社のアプリケーション要求に関する情報を統合できる ・事業とアプリケーション開発の優先度をアラインできる ・適切なガバナンスを通じて意思決定ができる

ロードマップへのインプット

アイテムの追加のためのインプット

ロードマップVer.1に対して、日々新たな要求が発生すると考えられます
  • 新規パートナーから導入の条件となる新たな機能開発への要求
  • 既存パートナーから事業成長のために必要となる機能への要求
  • 10Xのグロース戦略や顧客体験の改善に向けた機能への要求
こういった要求については、各本部で適切なガバナンスの元に要求をデータベース化して管理し(以下、イメージ)、要求をStailerアプリケーションロードマップへ対して反映させる判断ができるような機構を構築します。

優先度判断のためのインプット

ロードマップに掲載されたアイテムに対しては「優先度を判断できるメタ情報」を付与し、意思決定していくことになります。具体的には以下のような情報を各アイテムに付与することで、優先度の判断材料を拡充していきます。
  • 期待できる事業インパクト
  • 10Xの事業価値へのインパクトの見積もり
  • 要求するパートナーとその要求背景
 
なお特に2点目の事業価値との連携はCorporate Strategyチームと連携をとり、全社の企業価値を以下のような地図に描き、この各要素に対してどのように影響するかを機能毎に関連付けるという作業をしています。
 
図はCFOが一晩で創ってくれました(ジェバンニかよ)。
 

開発担当判断のためのインプット

10Xは資産を開発する機能本部と、資産を活用して顧客と向き合い事業を推進する事業本部のマトリクスの構成をとっています。ロードマップの開発はこのいずれの本部も担当しうる内容です(以下、フローチャート)。アイテムごとに担当する開発本部を判断するために「機能追加に必要な情報をパートナーへのDeep Diveなしに、10Xのみで補完できるかどうか」についてインプットします。
 

ロードマップの意思決定フロー

大きく4つのステップでロードマップに対する意思決定を行います。全体の流れはこんな感じの運用を2022/9より本格スタートさせていきます。

各種判断基準

アイテム追加基準および優先度判断基準については、具体例を元にそれぞれデータベースを貯めていき、判断軸をブラッシュアップしていきます。
  • アイテム追加基準: 基準項目のすべてが「Yes」の場合にロードマップへ追加されます
  • アイテム優先度判断基準: 基準項目のすべてを埋めた上で、「事業・利用者の体験」へ対するROIから総合的に判断されます
 

プロダクトマネジメントの仕事

ここまでStailerアプリケーションロードマップの運用方法について紹介させていただきましたが、これと合わせて10Xにおけるプロダクトマネジメントのミッションも改めて設定し直しているのでそちらにも最期に触れさせてください。以下のようにセットしています。
 
💡
Stailerのアプリケーション(機能)ロードマップの策定・実現・顧客への提供を通じ、事業価値(10X 粗利)および顧客価値(ToC&ToE の事業および体験価値)を最大化する
 
そうです、つまりこのロードマップを前へ進めるのがプロダクトマネジメントなんだ、と宣言しているんです。
 
10X社が扱っているプロダクトは非常に優秀なチームによって絶えず拡大し続けていますが、その投資対効果を握るのがPMのおしごとになります。様々なメンバーと協調しながら、骨太なプロダクトを推進するプロダクトマネジメントに関心がある皆さん、ご応募をお待ちしております。
 
そして私はこの会社を世界に通ずるプロダクトカンパニーにするつもりです(ここ大事)。その両翼を担いたいという野心的な方、まだポジションはオープンしていないものの、CPOというポジションを準備しようと検討しております。柔らかい段階ではありますがぜひお話してみたい、という方、お待ちしております。