再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ

ソフトウェア開発者からプロダクトマネージャーへの転身に必要なマインドセット 第4回

　本連載は、ソフトウェア開発者からプロダクトマネージャーに転身した、ゆずたそ（@yuzutas0）さんが自身の経験を振り返り、切り替えるべきだったと考えるマインドセットを紹介していく連載です。第4回は、プロダクトマネージャーにとって欠かせない「意思決定」に関する問題を取り上げます。（編集部）

はじめに

　こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。

　主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。

トレードオフが生じる場面

　今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。

• 画面に表示するテキストをA案にするかB案にするか
• 要望を受けているけど仕様が複雑になりそうな機能を開発するか
• 教育アプリのユーザー体験を、親御さまの安心感に寄せるか、お子さまの利便性に寄せるか

　プロダクト開発を行っていると、大なり小なりトレードオフが生じます。なるべく両立できるように試行錯誤すべきですが、最善を尽くしても、どこかで利害が相反することはあります。このような場面では意思決定が求められます。

意思決定のアンチパターン

　意思決定の訓練を積む機会が多くなかった人にとっては、未知の仕事になるでしょう。上司や依頼者に指示を仰ぐだけの働き方をしていると、いざ自分が意思決定をしないといけない場面に出くわしたとき、途方に暮れてしまうはずです。

　お恥ずかしながら筆者自身も多くのアンチパターンを踏んでいます。個々の例については枚挙に暇がありません。

• ボタンのテキストを決めようとしたが、その画面で提供したい体験があいまいだった
• 仕様案をAではなくBに決めたが、技術検証によってB案が不可能だと判明した
• 特定機能のUXを「今」追求するかがあいまいな状態で案件を進めてスケジュールが遅延した

　さらに厄介なのが「意思決定のフローが決まっていない」というアンチパターンです。新しいトレードオフが生じるたびに「このトレードオフに対してどのように向き合ったら良いのだろうか」と悩むことになります。毎回一から悩んでいては案件を前進できません。

　筆者がこのようなアンチパターンに陥ってしまったのは、意思決定を特別なものだと思いこんでいたからです。特別なものに対処するために、勘やセンス、ひらめきに頼ろうとしました。「意思決定は特殊技能」という思い込みです。しかし、試行錯誤を経ることで「意思決定はプログラミングと同じだ」とマインドセットを切り替えられるようになりました。

　ソフトウェアエンジニアがソースコードを書くときには「Aの書き方にするか？ Bの書き方にするか？」「ライブラリAを使うか？ ライブラリBを使うか？」といった意思決定を積み重ねているはずです。日々実践していることなのです。プロダクトマネジメントにおける意思決定も同じで、再現可能なスキルと言えます。意思決定の流れを言語化すれば、一定の水準までは担保できるように思います。

意思決定のフローチャート

　筆者が周囲のプロダクトマネージャーとディスカッションして整理した「意思決定のフロー」は以下のようになります。

意思決定のフローチャート

　活躍しているプロダクトマネージャーは、明示的であれ、暗黙的であれ、何らかの意思決定フローを持っているはずです。意思決定のフローが決まりさえすれば、相談を受けたときにスムーズに返せるようになります。