意思決定に至るまでのプロセスを大事にしたい

2024年10月24日 14:09

書き出し - 意思決定ってできる？

マネーフォワードPdMのtktです。
プロダクトマネージャーに限らず、プロダクト開発において様々な場面で意思決定を行う場面が発生します。
意外と「自分は意思決定が苦手だ」と考えるメンバーが多いようだったので、今回は私が意思決定に対して考えることについて書いておきます。

結論

結論から言うと意思決定自体は誰がやっても良いと思っています。
何故なら、意思決定するまで通常ロジカルの積み上げを行なっていきます。一般的にロジカルというのは国を跨いでも共通言語（のはず）なので、必要な情報がそろって順番に積み上げを行なっていけさえすれば、最終的な選択は大体1つに絞られるはずです。
そのため誰が意思決定するかによって最終的に選択する結論に大きな変化は生じないためです。

しかしだからこそ、意思決定に至るまでのプロセスとしてどういうロジックでその決断になったのかは何よりも重要であると考えています。

私の日常的な開発がどうなっているか

私がPdMとして参加する開発チームでは基本、開発メンバー全員でタスク優先順位や仕様、実装のやるやらなどを毎朝のリファインメントで決めており、私が先行して意思決定する回数はなるべく減らしています。
リスクを内包する決断には何故その決断に至ったかを明記してもらい、自分が責任を取るというプロセスとして作って進めています。
良い循環になっており、全員が一定納得した状態で開発実装を回せています。

もちろん最初からこの開発スタイルができたわけではなく、最初はなかなかメンバー間での意思決定は手こずっていました。
特に自身が意思決定することに不安を感じるメンバーが多く、何故不安に思うのかヒアリングして考えた結果、「チームで次のアクションをどうするか決めること」と「選択を失敗した時に責任を取ること」を混合しているからだと理解しました。

その上でチームに「次のアクションはメンバーそれぞれの専門性を活かして情報収集をしたのち、チーム全体で決めよう。プロダクトがどうなってしまうかの責任はPdMが取る。ただし、意思決定にいたるまでのロジックは必ずわかる場所にわかりやすいように書き留めておくことが必要。」と伝えました。

なんでそう伝えたのか

次のアクションを決めるにあたってまず必要なのは情報です。
この情報はPdM含めたチームメンバーそれぞれの専門性や立場などを活かして収集しておき、チーム内で整理された状態にする必要があります。
情報が整理されていれば、誰がネクストアクションを決めても良いのです。

もちろん一般的に言う”決裁者”にどういうロジックでその結論に至ったかを説明して納得させる義務はあります。
この部分は個々人のスキルやチーム内外の状況によって難易度が変わってしまう可能性があるので、一定仕組み化してしまえば良いだろうと考えています。

そのためには意思決定するまでにロジックを通しておく必要がある。
少なくとも第三者に説明できるレベルまで言語化構造化できていなければ、それは決めたことになりません。

もし、それでもどうすれば良いか決めきれない時は情報が足りないということです。
そうなると「じゃあ次は何の情報があれば決め切れるのかを決めよう」となればその会議は5分で終わり、1時間メンバーそれぞれが情報収集した後にすぐに非同期的に意思決定ができますね。

「これはキメの問題ですね」というのはまやかし

「これは一定キメですね」というのはよく聞くし、自分も（本心ではないが）使うことがあります。
実際、”キメの問題”というのは存在しません。
ただ単に、「情報収集するコスト>意思決定したあとに見込めるアウトプットバリュー」の時に、便宜上納得させるためだけに使っているまやかしの言葉です。

つまり
1. その時意思決定に至れないほど情報が収集しておらず、その必要な情報を収集するのに時間がかかることが確定している時
また
2.頑張って意思決定しても最終的に出てくるアウトプットがそこまで大きな価値を生むわけではない時
に使いがちな言葉なのですが、これを悪用して情報収集をせずに"キメの問題"にしてしまうのは必要な工程をすっ飛ばしていますので気をつけた方がいいでしょう。

そのため、キメの問題とするのではあれば、何故キメの問題としたのかのロジックは作っておかないといけないです。

終わりに

意思決定までのロジックを作ることをプロダクトに関わる人は全員大切にして欲しいなあ。おわり。