はじめに
こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。
主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。
トレードオフが生じる場面
今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。
- 画面に表示するテキストをA案にするかB案にするか
- 要望を受けているけど仕様が複雑になりそうな機能を開発するか
- 教育アプリのユーザー体験を、親御さまの安心感に寄せるか、お子さまの利便性に寄せるか
プロダクト開発を行っていると、大なり小なりトレードオフが生じます。なるべく両立できるように試行錯誤すべきですが、最善を尽くしても、どこかで利害が相反することはあります。このような場面では意思決定が求められます。
意思決定のアンチパターン
意思決定の訓練を積む機会が多くなかった人にとっては、未知の仕事になるでしょう。上司や依頼者に指示を仰ぐだけの働き方をしていると、いざ自分が意思決定をしないといけない場面に出くわしたとき、途方に暮れてしまうはずです。
お恥ずかしながら筆者自身も多くのアンチパターンを踏んでいます。個々の例については枚挙に暇がありません。
- ボタンのテキストを決めようとしたが、その画面で提供したい体験があいまいだった
- 仕様案をAではなくBに決めたが、技術検証によってB案が不可能だと判明した
- 特定機能のUXを「今」追求するかがあいまいな状態で案件を進めてスケジュールが遅延した
さらに厄介なのが「意思決定のフローが決まっていない」というアンチパターンです。新しいトレードオフが生じるたびに「このトレードオフに対してどのように向き合ったら良いのだろうか」と悩むことになります。毎回一から悩んでいては案件を前進できません。
筆者がこのようなアンチパターンに陥ってしまったのは、意思決定を特別なものだと思いこんでいたからです。特別なものに対処するために、勘やセンス、ひらめきに頼ろうとしました。「意思決定は特殊技能」という思い込みです。しかし、試行錯誤を経ることで「意思決定はプログラミングと同じだ」とマインドセットを切り替えられるようになりました。
ソフトウェアエンジニアがソースコードを書くときには「Aの書き方にするか？ Bの書き方にするか？」「ライブラリAを使うか？ ライブラリBを使うか？」といった意思決定を積み重ねているはずです。日々実践していることなのです。プロダクトマネジメントにおける意思決定も同じで、再現可能なスキルと言えます。意思決定の流れを言語化すれば、一定の水準までは担保できるように思います。
意思決定のフローチャート
筆者が周囲のプロダクトマネージャーとディスカッションして整理した「意思決定のフロー」は以下のようになります。
活躍しているプロダクトマネージャーは、明示的であれ、暗黙的であれ、何らかの意思決定フローを持っているはずです。意思決定のフローが決まりさえすれば、相談を受けたときにスムーズに返せるようになります。
