この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー18日目（シリーズ2）の記事です。

はじめに

こんにちは。コインチェックでプロダクトマネージャーとして働いているたなしょ（@tana_sh0）と申します。
普段は暗号資産交換サービスのプロダクトマネジメントを担当したり、新サービスや新規通貨の取り扱いPJに従事しています。
今年2月には企画したCoincheckリワードをリリースすることができました。

本日は私が担当したCoincheckつみたてを急造したスクラムチームで爆発的にグロースすることができた背景にある施策優先度をはじめとする意思決定の体制について紹介させていただきます。

先日人生で初めてイベント登壇させていただいたfindy社が主催する「プロダクトマネージャーLT Night 〜アウトカムを最大化する施策優先度の意思決定〜」で多く反応いただいた部分を中心に書いていこうと思います。

まず業態やフェーズ、開発体制によってプロダクトマネジメントの様相は大きく異なると思いますので、私が担当したプロダクトの概要をざっくりと記載します。

余談ですが、PdMのキャリアを考える上でも担当するプロダクトがtoC or toBであったり、どういったフェーズなのかということは大きな考慮ポイントになると思います。

施策優先度を決めるにあたり悩んだこと

スクラム開発を取り入れるとチームで意思決定した際に、私はCoincheckつみたてのプロダクトオーナーを任されました。
それまでは会社としてプロダクトマネジメントの意識もあまりなく、チームとして意思決定の体制もゼロから考える必要がありました。

その際に以下のようなことに悩みました。

• どうやって施策優先度の意思決定をするか

• 上司・部下と言った明確な権力勾配がない中で、どのようにしてPdMが最終的な意思決定をする信任をチームから得るか

意思決定において重要な「権限」

意思決定の仕組みを定めることはもちろん重要ですが、意思決定においてはそれだけでは不十分で、「誰が決めるのか？」を決める必要があります。
なぜなら意思決定権の所在が不明瞭な場合、不必要な妥協が生まれたり、いつまでも意思決定ができないという状況が発生します。

不必要な妥協というのは例えば、新製品の議論をしている際に「熱いうどん派」と「冷たいうどん派」がそれぞれ50%ずついて、結局妥協してぬるいうどんを作ってしまうようなイメージです。

意思決定権を持つ者は議論で意見が割れた際には情報を整理し結論を「判断」することだけではなく、不確実な状態であっても自分の意志を持った「決断」が必要になります。

大抵の場合、この意思決定権はPdMやPOが保有すると思います。

では、PdMである自分が意思決定者になる場合、チームメンバーは一定の定められた権限を持った上司ではない自分になぜ従うのでしょうか？
この問いを解消するために意思決定において何を重視するか定めました。

意思決定において何を重視するか

意思決定の構成要素として、正しさ・納得感・早さの3つがあると考えており、これらはトレードオフの関係にあります。
私のチームは「納得感」「早さ」を重視し、「正しさ」の優先度は低く置きました。

「正しさ」はスクラムにおいては目的不確実性（ユーザーに本当に使われるか？）と定義でき、この目的不確実性は結局のところ社内でどれだけ議論やテストをしても解消できないのです。
唯一の方法としては素早くリリースして、ユーザーの反応を見ることが賢明であると判断しました。（もちろん全く議論しない、テストしないというわけではありません。）
Meta社のマーク・ザッカーバーグCEOが書いたdone is better than perfectの思想でもあります。

「納得感」はチームメンバーの意思決定に納得できること、少なくとも大きなハレーションが起きないことです。
「早さ」は素早く意思決定でき、素早くリリースできることです。
しかしこの2つも場合によってはトレードオフの関係にあります。

「納得感」と「早さ」を両立するために

納得感と早さの両立のために、それぞれ以下を課題としました。

納得感：プロダクトの方向性や前提条件などをチームで認識統一する
早さ：意思決定基準と意思決定者を明確にする

それぞれのアクションもざっと記載してみます。

納得感：プロダクトの方向性や前提条件などをチームで認識統一する

プロダクトマネジメントの方向性やグロースの方針などの策定にメンバー全員が関わり、また毎日確認することで意思決定の背景となる前提条件をチーム全員が認識できる状態を整えました。
メンバー自身が土台作りに携わったという事実や、そもそもここで決めた方針とズレる施策の意思決定は基本的には行われないため、メンバー全員が一定の納得感を持って進めることが可能となります。
またチーム内で認識を統一できていることで、権力勾配がない中でPdMが意思決定をしてもハレーションが起きづらくなります。

具体的には以下の①②が策定、③が認識統一のアクションです。
①チームメンバー全員でバリュープロポジションキャンバスやインセプションデッキを実施し、PdMがプロダクトビジョンを策定し、チーム内で合意した。

②グロースに向けたターゲットとなるKPIを決定し、プロダクトのほぼ全てのKPIを表示するダッシュボードを作成した。（アナリストが対応）

③毎日朝会でプロダクトビジョンを読み上げ、全員でKPIを確認し、強制的にインプットできる環境にした。

繰り返しになりますが、③についてはメンバー全員の意識に方針や現状を刷り込めるため、チーム全体のマインドを統一することにとても効果的であったと思います。
発声は社内でも推進されており、様々な部門の会議で実行されています。

早さ：意思決定基準と意思決定者を明確にする

施策の優先度の決め方を設定しました。
具体的にはICEスコアを導入し、PdMがスコアを参考に意思決定できるという体制にしました。
またJIRAで誰でもアイデアを起票できる状態とし、起案時にImpactとConfidenceの数値を入力する形にしました。

具体的なプロセスとしては、毎週JIRAをメンバーで確認し、スコアの調整を行い、最終的にPdMがスコアを”参考”にして優先度を決定しました。
「スコアは参考」という形であえて基準を曖昧にしたことで、実際の優先度について全メンバーが意見でき、また最終的にPdMが”決断”の余地が持てる状態になっています。

ICEスコアのランキングをそのまま優先度とすると、以下のような柔軟な意思決定が困難になる問題が生じます。

• ランクは低いが問題解決やストック収益の期待が高い施策や、起案者の問題意識やユーザー憑依からの熱量を信じた施策を実行できない

• 工数が低い施策に偏りが生じ、中長期的に収益を積み上げられるが開発コストがかかる施策の意思決定がしづらい

• ランクは高いが不可逆なのですぐに意思決定できない施策を見送れない

• ランキングに違和感を覚えても意見できない、スコア調整でバランスを取るのが面倒

ICEスコアについての詳細な説明は省きますが、私たちのチームでは以下のような形でスコアリングしました。

• 各数値を10段階で入力し、平均値でランクづけ

• IはKPIの改善見込み（主に他施策との相対評価）

• Cは社内外の事例や社内の定性・定量データなど

• Eは開発コストの簡易見積もり

やや余談ですが、振り返ると各スコアは5段階で良かったと思います。
結局ランクは参考でしかないので、数値を細かく考えてもそこまでメリットがないためです。

またICEスコアにReach（影響人数）を考慮したRICEスコアもフレームワークとしてよく挙げられますが、RはIに含有されると考えたので、私たちのチームではシンプルなICEを採用しました。

この意思決定体制により、具体的な意思決定に活かせた事例を紹介できればと思います。

意思決定事例：申し込みフローの入れ替え

この施策を実施する前のCoincheckつみたての申し込み完了のフローはLP訪問→銀行口座設定→プラン・金額設定という順番でした。
申し込み完了率の改善に向け、この順番をLP訪問→プラン・金額設定→銀行口座設定に入れ替えるというアイデアがありました。

行動経済学の「一慣性の法則」の観点からもImpactやConficenceのスコアが高めにつけられた施策でした。
ただフローを丸々入れ替えるということでEaseは最大値に近い数値で開発コストがかなりかかるという心理的なハードルもあり、なかなか意思決定がしづらかったという状態でした。

今後相場変動やプッシュマーケティングによってさまざまなモチベーションのユーザーの流入が増えたとしても転換率を高められ、中長期の収益改善に貢献する施策であると判断し、優先的に着手するという意思決定ができました。
また大通りを改善するというマインドのもと、メンバー全体の熱量も高く、感情的な面からも前向きな決断ができたと思います。

この施策により申し込み完了率を約2倍にすることができました。

最後に

全員が様々な検討プロセスに関わり、また意思決定権をPdMが持ち決断できる状態にすることで、納得感と早さを両立することができました。
また毎朝の方針やKPIの確認を通じて、グロース意識がチームに定着したことで、アイデア創出のコミュニケーション量も増えたように思います。

また気軽にコミュニケーションを取れることになったためか、デザイナーやエンジニアをアイデア検討の段階から巻き込み、一気にプロトタイプまで作ってしまう、といったことも行われるようになりました。

ちなみにですが、決断はストレスが半端ではないです。
・「正しさ」の重要度は低くおいていると言いつつ、リリースして学びのない失敗をしたらどうしよう
・せっかく考えてくれたアイデアを却下しなければならない
といったストレスがあります。

決断はある種センスも求められるかと思いますので、日々多様なプロダクトに触れ、ユーザー理解の促進をしてセンスを磨いていきたいと考えています。
また他人を不快にさせない傾聴や尊重、言葉遣いといったバーバル・ノンバーバルなコミュニケーションスタイルも非常に重視しています。（例えば強く主張することと、強い口調で主張することは別物です。）

意思決定の苦悩は様々あるかと思いますが、この記事で誰かのお悩みを解決できれば幸いです。

参考

最後になりますが、私たちのスクラムチームでは以下の文献を参考にして実践しました。

note

グロースの逆説 : メルカリで分析とサービスグロースをやる前に知りたかったこと
大通りの改善というマインドセットをチームに持ち込めました。

意思決定のROIという考え方
意思決定において何を優先するのかということを考えられました。

書籍

Mike Cohn著「アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～」
職種横断で社内で勉強会をして、エンジニア・PdMなどの相互理解を促進できました。

広木 大地著「エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング」
不確実性について理解できました。目的不確実性についてはPdMも理解しておくべきだと考えています。

Don McGreal著「プロフェッショナルプロダクトオーナー　プロダクトを効果的にマネジメントする方法」
一言では言い表せないのですが、PdMとして1年ほど働いたり、仕事で行き詰まったら読むと良いと思います。