アジャイルなプロダクト作りとロードマップ運用の両立
コインチェック株式会社（以下コインチェック）のCrypto Asset事業本部というところで副本部長をしています。大村ことSotaです。コインチェックのスクラム関連の発信の５番手を務めます。
この記事では、私たちCrypto Asset事業本部がアジャイルなプロダクト作りと、いわゆる「ロードマップ」の維持管理をどのように両立させているかを紹介します。
ロードマップとアジャイルの両立は、多くのスクラムマスターが対応に苦慮してきた問題ではないでしょうか？レトロスペクティブで「結局上に言われたことしかやっていない💢」とか、「これウォーターフォールをアジャイルっぽくやってるだけじゃない？」という振り返りが出た際に、それを裁くことに苦労したことはありませんか？「納期を優先して中途半端なリリースをするのか？」というチームの声に、どう答えれば良いのか分からず困っているマネージャーの方はいませんか？
そんなあなたに、私たちが実践している「ロードマップ」と「アジャイルプロセス」の（ギリギリの？）両立についてお伝えしたいと思います。
1. ロードマップとアジャイルの「絶妙」な関係
まずは、ロードマップやアジャイルを巡る教科書的な知識をザッとおさらいしていきます。実践的な内容にとっとと触れたい方は3節から読んでください。
まず、今回の記事における「ロードマップ」の定義から始めましょう。今回の記事では、特に断りを入れない限り、「ロードマップ」を、「納期と共にリリース予定の機能群が列挙されたドキュメント」と定義します。一般的に運用されているロードマップとは多少の粒度の相違があるかもしれませんが、大枠は捉えられているのではないでしょうか。
多くの場合、アジャイルやその思想を継承するプロダクトマネジメントのメソドロジーでは、こうした「ロードマップ」を維持管理することに慎重な立場を取ります。「機能」はある時点で存在する価値伝達の手段にすぎず、それは絶えざる仮説検証を通じて常に最新化していくべき（作っては捨てるを繰り返すべき）だとするアジャイルの精神に、「ロードマップ」の方法論が矛盾するように見えることが原因です。
この矛盾について正鵠を射た理解を促すために、議論の補助線を引いていきます。アジャイルを巡る言説の中では、機能や施策そのものを「アウトプット」、アウトプットを通じて届けようとする価値を「アウトカム」とする対比を設定し、後者を重視すべきだという主張がなされます。本来「アウトプット」はその「目的」たる「アウトカム」を届ける「手段」にすぎず、「アウトプット」自体を「目的」化する思考は、「手段」の「目的」化という転倒を導くためです。
例えば、コインチェックは「新しい価値交換を、もっと身近に」というミッションを掲げており、その手段として暗号資産交換事業と付随するプロダクト群が存在しています。各プロダクトはそれぞれに全社ミッションを上位概念とするビジョンを持っており、またビジョンを実現する手段として売買や送金などの機能群が存在します。機能群はさらにソースコードや企画・マーケティングなどの概念に分解されていきますが、常に上位概念からのカスケードダウンが可視化されている状態である必要があります。
「手段」が「目的」化した状態とは、こうしたカスケードダウン構造の中で、下位概念が上位概念の実現を「目的」とする「手段」であることが忘却された状態を指します。プロダクトは全社ミッションを、機能群はプロダクトビジョンを実現するために市場に向けて投げ打つものであり、各階層のそれ自体が「目的」となることは決してありません。反対に、「アウトカム」ベースの思考とは、常にある階層の上位概念が目的として参照/意識されている状態を意味しています。
しかし、ロードマップは、機能単位での羅列という形式そのものが、素朴な「アウトプット」ベースの思考を導きます。機能のリリースを定められた順序と納期でこなしていくことが最も重要だと意識され、その上位概念であるプロダクトのビジョンやミッションを意識する契機が失われがちになるからです。このように、「アウトプット」ベースの思考とは、ある階層（プロダクト/機能）が、上位概念を実現するための「目的」であることが忘却された状態を指しています。
アジャイルの真髄は、高速な仮説検証を通じて常に最適な「手段」を市場に提供できる状態を実現することにあります。多くの場合、「アウトプット」ベースの思考は、「手段」が固定されることで、多くの機会損失を生み出す原因となります。なぜなら、市場環境や顧客ニーズの変化に柔軟に対応できなくなるからです。この問題を解決するためには、「アウトカム」ベースの思考へのシフトが不可欠です。そのため、ロードマップを固定的なものとして扱う思想は、アジャイルの「アウトカム」重視の価値観に相違するアンチパターンであると、私を含め多くのアジャイル実践者が考えているはずです。
2.ロードマップを巡るカルマ
そもそも、ロードマップを作る目的はなんでしょうか。
何の意味もなければ辞めてしまえば良いわけですが、そうは問屋が卸さないのが難しいところです。この質問に対する私の答えは、「外部ステークホルダーが現場と円滑にコミュニケーションを行うため」というものです。
アジャイルを導入し実践している現場であっても、チーム内で完結する案件はそう多くないはずです。例えば、経営陣が意志を持ってコミットメントするリリース、tier1の顧客に納期を約束した機能、外部提携先との共同リリース、法や規制で必ず対応が求められている事項など、開発案件の中にはチームの外部から差し込まれる要件が一定量発生します。そうした案件は関係者の関心も高く、頻繁に「今どうなってるの？」とか、「いつまでに終わるの？」といった質問に晒されることでしょう。
外部から差し込まれる案件は、多くの場合一定の納期までに完了することを求められます。そのため、進捗が可視化され定期的にレポートされる状態を作る必要があります。この際、ロードマップは、現場と外部のコミュニケーションツールとして活用できます。ロードマップには、外部ステークホルダーとのコミュニケーションにおいて、「ここを見ておけば大事なこととそのステータスが全部載っているツール」として利用できるメリットがあるということです。
しかし、このようにロードマップを現場と外部のコミュニケーションツールとして利用すると、ロードマップに記載されている機能の一覧を「納期通り」にリリースすることが、プロダクトチームのコミットメントとして受け取られてしまいがちです（INSPIREDにも書いてありましたね）。こうなると、納期と機能がセットとなってチームへのプレッシャーを産み、機能リリースの目的化（＝手段の目的化＝アウトプットベースの思考）が更に強まってしまいます。
また、トップダウンで策定されたロードマップをひたすらこなしていくことを求められれば、チームはプロダクトに対するオーナーシップや自律性が侵害されていると感じることでしょう。「これのどこがアジャイルなんだ！」というクレームが出てくるうちはまだマシで、最悪の場合チームメンバーはプロダクトを育てることに対する内発的な動機づけを失ってしまいかねません。こうなるとチームからはコミットメントもやり切る力も自走力も失われ、「何を言ったって仕方ない」という学習性無気力が蔓延します。さて、困りました。
このようなロードマップを巡る困難には、アジャイルの方法論が抱えるある課題が顕現しています。それは、「チームの外部で決まったタスクをどのようにアジャイルのプロセスに組み込むべきか」というものです。アジャイルを実践する現場の多くで、同じ問題が発生していると思います。チームの内発性やオーナーシップを重視するアジャイルな組織作りと、外から大いなる力を持って差し込まれるロードマップとのバランシングは、ヨーロッパの火薬庫と呼ばれていたバルカン半島ばりに緊張感のある問題として意識されていることでしょう。
さて、ずいぶんと前置きが長くなりました。
ここから先は、私の所属しているCrypto Asset事業本部がどのように「ロードマップ」とアジャイルの並立に取り組んでいるのかを紹介していきます。組織課題への取り組みは常にWIPであり、朝令暮改上等の気持ちで運用しています。それでも現時点で私たちがベストだと思っているやり方として、ご紹介します。
3.Crypto Asset事業本部のロードマップ運用
ここから先は、実際にCrypto Asset事業本部がロードマップの運用ドキュメントとして公開しているものを加工して記載します。前提、Crypto Asset事業本部はコインチェックのプロダクト（暗号資産交換事業やNFT販売所、OnRampサービスなど）の開発チームが揃っている本部です。以下本文です。
Crypto Asset事業本部では、事業継続上必須となる開発案件や、部室横断的に取り組む必要がある開発案件をマネジメントするために、ロードマップを運用します。ロードマップ運用の目的は、重要度の高い案件（開発を含むものと含まないものがある）の進捗を適切に把握し、遅延リスクを適時に検知し必要な対応を行うこと、および横断的なリソース調整が必要となる案件を早期に検出し調整を効率的に行うこと、と定義します。
3.1 ロードマップ案件の定義
ロードマップには、以下のいずれかを満たす案件*が全て記載されます。
①：法令により、当社が期日までに対応することを義務付けられている案件（以下、法令対応案件）
②：経営戦略遂行上、事業本部長が期日までに完遂することが必須であると判断している案件（以下、経営戦略案件）
③：部または本部を跨いだ稼働が必要となるため、ロードマップを通じて共通認識を持つことで、その進行が円滑になると考えられる案件（以下、横断案件）
*以下、ロードマップ上に記載されるべきものの定義を満たす案件をロードマップ案件と呼びます
3.2 ロードマップ案件のスコープ
ロードマップ案件のスコープは以下の通り定義されます
(N)Q末時点で確定している、(N+1)Qおよび(N+2)Qに開始する案件
例：FY24 1Q末時点で、FY24 2QおよびFY24 3Qに開始する案件の一覧がロードマップに記載されます
3.3 ロードマップ案件の洗い出し
ロードマップ案件は前Q末までに一覧化します。締め切りについてCrypto Asset事業本部長からアナウンスがありますので、それまでに以下の要領で一覧化と関連部署との調整を行います。
① 法令対応案件
主管部門が、法令対応が必要となる案件の有無を、法務・コンプライアンス本部と連携して確認し、ロードマップを記載します。
② 経営戦略案件
Cryoto Asset事業本部長および副本部長が、主管部室に対して対象となる案件を指示します。主管部門が、指示のもとで、ロードマップを記載します。
③ 横断案件
主管部門が起案し、関連部室との調整を行い、ロードマップを記載します。
3.4 ロードマップ案件の報告
ロードマップに記載された案件のうち法令対応案件、経営戦略案件については、Crypto Asset事業本部長および副本部長へ以下の報告を行うことを必須とします。報告の形態は問いません。Slack上で報告を行う場合は本部長宛にメンションをください。会議招集する場合は必ず本部長を召集してください。
開始報告
プロジェクト計画書テンプレートの内容を記載して、ロードマップに記載したプロジェクト開始日当日までに送付してください。
進捗報告
スケジュールに対して進捗がオンスケジュールで進んでいるかをプロジェクト計画書に記載した報告日と頻度で報告してください。
Crypto Asset事業本部長および副本部長は、進捗報告を受けた案件について、進捗が芳しくない場合にはその理由をプロジェクトマネージャーまたはプロジェクトオーナーに確認するとともに、進捗を妨げる要因を解消し、プロジェクト進行をサポートすることを責務とします。
3.5 ロードマップ案件のレビュー・品質担保
2024年7月より、開発を含むロードマップ案件は以下の観点で開発・人事本部のレビューを通過することを必須とします。
サービス仕様：開発・人事本部長（CTO）
開発仕様が確定した段階でCTOにレビュー依頼を出してください。
品質保証：QAE G
必ず開発プロセスのどこかでQAE Gの関与を得てください。
3.6 ロードマップ案件の変更
ロードマップ案件の期限やスコープの変更は、以下のプロセスを経由することとします。
①：期中に開始するロードマップ案件を変更する場合
Crypto Asset事業本部長に変更内容と理由を説明し、承認を得て変更します。
すでに期中に入っている場合、主管部室がロードマップ案件を変更することはできません（編集権限自体をロックします）。必ずCrypto Asset事業本部長に報告し、変更内容と理由を説明して承認を得てください。
②：次Qに開始するロードマップ案件を変更する場合
各案件のオーナーが、関連部門と調整の上、ロードマップを変更します。
4. 1年間やってみた結果
この運用に魂を込めたポイントは、ロードマップに記載する案件の種類を明確に３種類に限定したことです。私の目論見としては、ロードマップとして納期とコミットメントが求められる外部からの差し込み案件を全体の3割(多くても4割)に抑え、残りの7割の時間でアジャイルなプロダクト開発を回す、という形を想定していました。これでチームの内発的動機づけを奪わないながらもやるべきことをやるという動きができる想定でした。
また、ロードマップ案件に対して、ガチガチな納期管理をするわけではなく、あくまでアジャイル的なリリースプランニングの手法で柔軟に設定・変更できるようにしたつもりではありました。
上記のやり方でロードマップ案件とアジャイルなプロダクト開発の両立を目指そうとして1年回してみたところ、以下のような振り返りが出ました。
良かった点
経営陣や内部監査などの外部ステークホルダーとのコミュニケーションに活用するという当初の目的は果たした
重要な案件の個数と進捗の可視化によって、経営レイヤーでの振り返りにも使える材料になった
反省が必要な点
ロードマップ案件3割とはいかず、実際は7割くらいになってしまい、バランシングの困難さを知った
納期やステータス管理についてのオペレーショナルエクセレンスが不足しており、すでに常に最新情報であるという状態を保つのが難しかった
特に反省の1点目は、結局現場のメンバーからも「結局何がしたいんだお前は？💢」と叱られ続けていました。コインチェックは金融事業者のため、法令対応で妥協することは当然できませんし、経営的なアジェンダの変更もあったりと、期中は常に差し込みとの戦いでした。
しかし、私は問題（トップダウンでやることでいっぱいになっていること）を適切に可視化して、問題として提起できる状態にすることがマネジメントの価値であり、ロードマップがなかったらその状況を問題化することもできなかったと思います。要するに、ロードマップの数と費やした工数を踏まえて、色々大変です！というコミュニケーションができたことは成果だったと思います。現在、経営陣との合意のもとで、ロードマップアイテムの数を減らす取り組みを進めています。
以上も踏まえて、自分としては、及第点くらいの運用ができたのではないかな〜と思っています。
5. さいごに
コインチェックは、プロダクトチームを盛り上げてくれるメンバーを大募集しています。暗号資産業界に関心がある方、勢いのある開発組織に身を置きたい方、その他なんでも興味関心を持ってくれた人は、カジュアル面談からでも是非お話ししましょう。是非、指名してください！対戦お願いします！
参考文献