いきなりですが自分は「問題の解像度上げたがり」です。
プロダクトマネジメントをする上で直面する様々な粒度の問題に対して、解像度を上げずにはいられないのです。
敵陣の陣形を把握しないまま適当に砲撃をするような、つまり「漠然とした問題に漠然とした対応をする」のが苦手で、敵陣の陣形を分析してからどの攻撃方法をどこにぶつけるのが最適なのかを見極めてから攻撃を仕掛けたいタイプです。
以前少し複雑なプロダクトを設計している最中に、ユーザーのステータスが複数個増えるような仕様変更があった時の話です。チームメンバーは「処理パターンが増えるだけだから簡単だ♪」みたいな雰囲気だったのですが、超絶ネガティブ思考な自分は「辻褄が合わないパターンが出てくるはずだ…」と不安を感じたため、[ステータス×画面(導線)×処理内容]を全網羅したマトリクス図を作りました。
マス目は50×100ぐらいになり、チームメンバーからは「見るのも嫌だ」「よくそんなの作れるな」と言われる始末。しかしこれの結果、辻褄の合わないパターンが見つかったため、仕様変更内容が変わり未然に問題の肥大化を防げたのです。
解像度を上げることは「新たに発生する問題の作業コストの不確実性を減らすこと」と同義だと思っています。
漠然としたまま進めても問題が顕在化しない可能性もありますが、とんでもなく大きな作業コストを伴う問題が顕在化する可能性もあります。まさにハイリスクハイリターン、不確実性が大きい状態です。
解像度を上げる作業を入れることによって、その分の作業コストは発生しますが、未然に問題を防げるし防げなかったとしても解像度が上がっている状態は作られるため、後に顕在化する問題に関する作業コストの不確実性を小さくできます。まさにローリスクローリターンです。
基本的にこの解像度を上げる作業はどんな問題に対してもやるべきだと思うのですが、注意すべきは解像度を上げる作業の「作業コスト対効果」が小さい場合はやらない方がいいという点です。
例えば解像度を上げる作業にあまりにも作業コストがかかってしまうと、最終的にいくら不確実性を小さくしたところで効果は得られません。検討ばっかりでなかなか進まないプロジェクトはこの状態になってしまっている恐れがあります。]
また解像度を上げる作業をしても不確実性を小さくできない場合も意味がありません。これは新規事業などが当てはまるかなと思います。新規事業自体が不確実性の大きいもので、仮説だらけの状態で解像度を上げても不確実性は小さくできないので、とりあえず進んでみて問題を顕在化させてしまった方が早かったりします。
至極当然な話をしているとは思いますが、いつまでも問題が解決しなかったり次から次へと問題に襲われているようなケースでは、問題に対するアプローチをうまく選択できていないのではないかと思います。
対峙する問題を解像度は十分か、不十分である場合このタイミングで解像度を上げる必要があるか、このまま進むべきなのかをしっかり考えた戦略立案が重要だと思う今日この頃です。
自戒も込めて。
※この記事は自身のnote記事からの転載です。