機能ロードマップというアンチパターン
導入
こんにちは。コインチェックCTO室に相変わらずご厄介になっています、sotaです。
コインチェックはプロダクトマネジメントにも（当然）力を入れています。PdM組織も立ち上げて、優秀な同僚たちが、一生懸命プロダクトを良きものにしようと頑張ってくれています。私も、技術組織論の観点から、良いプロダクトを作るためにどんなチームづくりをすれば良いのかということを真剣に考えています。
というか、正確にはあんまりにもプロダクトマネジメントのことを知らないので、考える準備をしています。とりあえず、手始めにもはや聖書っぽくなっているこれらの本を読みました。全部とっても良かったです。いつかちゃんと書評を書きます。
あとは、MeetyでPdMをされている方に突撃してプロダクトマネジメントのいろはを教わったり、プロダクトマネジメントの外部団体の勉強会にお邪魔したりしています。もはや迷惑系会社員です。みなさん、ご迷惑おかけしております。（この後、ちゃんとした書き物を出す時、改めてお礼のご連絡をさせていただきますmm！）
あと３冊くらい読むと、プロダクトマネジメントのことはじめくらいにはなるかな…ボクのプロダクトマネジメントはこれだ！とか語ってもいいかな…と思料している一方、鉄は熱いうちにという言葉もあります。新しい知識を仕入れたばかりの時って、脳が興奮して、むやみやたらと周りに語りたい瞬間ってありますよね。
というわけで、今のところかなり頭に残っている”ロードマップ”について、INSPIREDを通じて学んだことを記しておきます。4000字程度ですのでお付き合いください！
1. 機能ロードマップというアンチパターン
1.1 機能ロードマップをめぐる”ありふれた光景”
突然ですが、あなたのチームには”ロードマップ”と呼ばれるエクセルファイルとかスプレッドシートがありませんか？その”ロードマップ”なる書類は、XX月XX日までに▲▲という機能をリリースするという形式で記載されており、なんなら各機能にどの部門から何人月の人的資源を利用するということまでが、丁寧に織り込まれていませんか？
あなたがエンジニアやデザイナーである場合、その”ロードマップ”はいわゆる上流を担う部署や、エグゼクティブ・管理職が決めていて、あなたの元に降りてきた時には既に完成していて、期初に実現可能性の確認とリソース調整だけが要求されていたりしませんか？
あなたが上流を担う部署に所属していたり、エグゼクティブ・管理職である場合、開発メンバーやデザイナーに、”この機能を実現したいのだが、いつまでにどのくらいの工数で実現できるか”という質問とともに、既に完成したドキュメントとしてロードマップを渡していませんか？
INSPIREDにはアンチパターンとして、”機能ロードマップ”を作成していることが挙げられています（そのほかにも耳の痛いアンチパターンがた〜〜くさん挙げられています）。なお、このエントリは一文残らず、INSPIREDから内容を微調整しつつ、引用しています（主にchapter 22, 23です）
1.2 機能ロードマップの不都合な真実
なぜ機能ロードマップを作ることがダメなのか、本書では2つの不都合な真実が明かされます。1つは、そもそも我々が想定する機能は、ほとんどが顧客に受け入れられないということ。もう1つは、たとえ顧客に受け入れられる価値ある機能であっても、それが形になるまでには相応の時間を要すること。要するに顧客に受け入れられるかわからない、そして立てた計画はきっと守れない。
また、機能ロードマップは悪しきoutput志向カルチャーを醸成します。既に決められた機能を、決められたスケジュール通りにリリースすることがプロダクトチームの目的になります。余談ですが、このようなチームのmorale低下が広がった状態を、私は個人的に社内受託カルチャーの蔓延と呼んでいます（この単語だけが本章における私のオリジナルです）
”既に決められた機能を、決められたスケジュール通りにリリースする”こと自体は、パッと見聞きするかぎりでは、何が問題なのかいまいちわからないかもしれません。output志向も、何か強いコミットメント？を感じますし、耳触りが良く聞こえます。
しかし、本当にそれで良いのでしょうか。
プロダクトチームが本当に責任を負うべきなのは、既に決められた機能をリリースすること（outputすること）ではなく、リリースした機能が意図した価値を顧客もたらすこと、つまりビジネス価値を発揮すること(outcomeを得ること）ではないでしょうか。顧客が必要としているのは、機能ではなく価値です。機能は価値を伝達する手段に過ぎません。
機能ロードマップは、プロダクトチームのコミットを、本来あるべきビジネス価値の提供（outcome）から、手段であるはずの機能のリリース自体へと後退させる（output）ことで、社内受託カルチャーの蔓延を加速させます。全員がただ、”誰かに言われたことをやる”だけになってしまう状態を導くのです。
1.3 機能ロードマップの”マネジメント”
それだけではありません。機能ロードマップの存在は、そのチームをとりまく組織構造についてもっともっと多くを語っています。そもそも機能ロードマップを求めているのは、管理職やエグゼクティブではありませんか？彼/彼女らは、全社的な優先順位がきちんと実際の開発計画に反映されているのか、それはスケジュール通りに進んでいるのかを定期的に確認することを求めているはずです。
また、年間を通じてどのような機能をリリースするかを決めておかないといけないということは、それだけ一つの機能をリリースすることへの調整コストがかかるということを意味します。
このようなチームにおいて、プロダクトマネージャが実際に行っている仕事は、ロードマップの進捗管理・報告と、ステイクホルダーを収集しての会議のファシリテートに終始しがちです。ここで行われているのは、プロダクトマネジメント、というよりは、ロードマップ管理というのが適切でしょう。
先ほども言いましたが、私たちプロダクトチームが顧客に届けるべきなのは、機能ではなくて価値なのですが、ここまでくると機能をリリースすることが目的化し、その状態が硬直化してしまいます。
1.4 不確実性と向き合う覚悟を持とう
機能自体を届けることが目的であれば、もちろん今まで述べた状況に何ら問題はありません。あなたが受託会社で働いていたり、向こう10年くらい顧客ニーズが変わらないことが予想されるニッチな業界でプロダクト開発をしているのであれば、機能ロードマップを上から順々にクリアしていくことで、十分な付加価値を発揮することができるでしょう。
また、法令対応など、期限と実現すべき機能が明確に決まっているような場合も、ウォーターフォール的な開発手法は力を発揮してくれます。
しかし、もしあなたが不確実性の高い市場の中に身を置き、プロダクトの価値を届けるために、あらゆる機能を高速でリリースし改善していく必要があるのであれば、機能ロードマップは相棒としてあまりにも力不足です。開発工程だけをアジャイルやリーンにしてもダメで、もっともっと上から、全てをアジャイルにしなければ、市場の変化にはとても追いつけません。年初に作成したロードマップはあっという間に陳腐化し、プロダクトは不確実性の波に飲み込まれてしまいます。
では、わたしたちはこのロードマップをとりまく不条理な現実に、どう向き合うべきなのでしょうか。
2. 価値ロードマップというオルタナティブ
2.1 経営陣の仕事は、実現したい”価値”と”結果”を伝えること
まず、わたしたちはなぜロードマップを作りたいのでしょうか。ロードマップが届けるべき価値とはなんなのでしょう。INSPIREDから要約して抽出すると、ロードマップを欲する根底にあるニーズは、下記のようになります。
①会社の優先順位が、実際の開発現場まで浸透しているか確認したい
②日付をもって正確にコミットするべき案件の進捗を追いたい
これが経営陣のニーズだとすると、機能ロードマップ以外の形でどのように満たすことができるでしょうか。それは、”機能”ではなく、”価値”の形でロードマップを書くことなのです。”価値”が難しければ、”解決すべき課題”や、”目標”だけを決め、それをどのように実現するかは現場に任せるべき、ということです。
前提として、現場は、プロダクトマネージャとエンジニアおよびデザイナーを最小構成としたプロダクトチームを指します。詳細は書籍に譲りますが（びっちりプロダクトチームはかくあるべしが書いてあります）、スクラムチームの単位が分かり良いでしょう。スクラムチームはフィーチャーチームで領域横断的に組成されており、要件の発見からデリバリまでを一気通貫で担う能力を有している必要があります。
この図にある通り、プロダクトチームが発見とデリバリを継続的に短サイクルで実施し続けることが、不確実性の高い市場で価値を届ける機能をリリースするために、何よりも重要です。もちろん、この議論にはプロダクトの状況を熟知しているエンジニアや、デザイナーを交えることが必須です。チームにとって、実現すべき要件が上から降ってきたものではなく、自分たちが現場で見つけた要件であることが重要だからです。
2.2 一番大事なことは、常に現場で起こっている
先述した通り、機能ロードマップの多くはいわゆる”上流”過程で決定し、それを実現する責任を負う現場には実現可能性の検証くらいしか介在する余地が残されていません。しかし、提供した機能の9割は期待通りに利用されないというプロダクトマネジメントの定石に従えば、年初に決めた機能を1年かけて作っていくという重厚長大なプランニングは、少なくとも不確実性の高い市場におけるソフトウェアプロダクトのグロースには不向きであると言えるでしょう。
プロダクトにとって一番大事なことは、常に現場で起こっています。ソフトウェアのパフォーマンスや、顧客の動きの微細な変化、A/Bテストの分析結果、これらを具に見ているのは現場でプロダクトを育てているチームメンバーたちです。
経営陣やマネジメントが実現すべき価値や結果（WHAT)を見極めるプロフェッショナルであるとすれば、実現したい価値や結果を”どのように”実現するのかのプロダクトグロースのHOWのプロフェッショナルは、間違いなくプロダクトチームのメンバーです。
それゆえ、要件を発見するタイミングにプロダクトチームが介在していることが何よりも重要です。それがプロダクトチームの自律性を保ち、価値発揮へのhigh-integrityコミットメント（自ずからのコミット）を生み出すことにもつながります。
以上を踏まえて、経営陣/マネジメントレイヤとプロダクトチームの役割分担としては次のようになっているのが望ましいと言えます
経営陣/マネジメント：
発揮したい価値/得たい結果を定義し、プロダクトチームにコミュニケーションを取る
プロダクトチーム：
価値/結果を達成できる機能を発見するための、高速PDCAサイクルを回し、そして効果あるリリースを行う
3. さいごに
こういうことを書いたり言ったりすると、納期のコミットメントから逃げたいだけじゃないか！とか、じゃあどうやって計画立てるんですか！採用とかリソース調整だって考えないといけないんですよ！と憤怒をもって返されがちです。
いえいえ、納期にコミットメントするのは明確に重要ですし、大規模アジャイルの各種フレームワークでは、リリースプランニングを行う手法だってきちんと定義されています。
ちゃんとアジャイルをやってみよう！ということです。
というわけで、ひよっこスクラムマスターのプロダクトマネジメント入門の進捗報告を、ロードマップという切り口でお届けしてみました！Adios！
この記事が気に入ったらサポートをしてみませんか？