判断の質を担保するためにやっていること

プロダクト開発の仕事で判断する時に気をつけていることなど。

TL;DR

・ファクトチェック
・軽重緩急の切り分け
・動機と文脈の把握
・施策の有効性の明確化
・実行前のシミュレーション
・その他テクニックなど

---

ファクトチェック

まず事柄が事実なのか、事実かどうかさらに確認が必要な状態なのかを把握する。

例えば、エンジニアの言う「できません」は結構曖昧だったりする。

実際には

・現代の技術では実現不可
・今いるメンバーの技量では実現が難しい
・やればできるけどコストや時間がめっちゃ必要になる
・エンジニア自身の信念的なものとして実行に加担することはないのでこのプロジェクトでは実現不可

などがある。

プロダクトとしてはコストがかかっても解決すべきものとか時間がかかっても向き合わないといけないものを拾っていかないといけないので、事実をできるだけ正確に把握する。

軽重緩急を切り分ける

起こった事柄が自分たちのプロダクトに与える影響が大きいのか小さいのか、誰が判断すべきものか、今すぐに対処が必要かどうかを切り分ける。

自分で切り分けられないなら上司や先輩や関係しそうな人に伝える。

杞憂で終わるかもしれないけど、重大な問題が放置されて致命傷になることを考えれば気にせず発信すべき。

動機と文脈の把握

事柄の原因を調べる際に5W1Hは基本として、できるだけ「動機」と「文脈」を把握する。

「動機」は解決手段とワンセット。問題の起点となる動機がはっきりしていれば解決手段のずれは是正できる。

「文脈」は関係する組織や人などのステークホルダーを洗い出すために必要。関係者を巻き込むことでプロジェクトの推進力とか安定させるエネルギーが増えることが期待できる。

施策の有効性を明確にする

コストと費用対効果、誰が喜ぶのか、やって意味があるのか、どのぐらいの人が喜ぶのか。ゴールや目標値はあるのか。

無駄な一手を打つということは、その一手分、他の施策が遅れることを意味する。あと手応えがないと作り手も成功体験を感じづらいので注意。

プロダクト開発でやりたいことはたくさんあるので、実行に移すのはできるだけ有効なものにしたい。

実行前のシミュレーション

施策を実行に移す前に、実行した場合に起こる影響を事前に予測しておく。

・時間経過で別の問題が発生しないか
・連動するものに影響を与えないか
・失敗した時になにが起こるのか
・同じような問題を抱えている箇所は他にないか

誤った手を打つと、その失敗を取り戻すために何倍ものエネルギーが必要になることがある。

限られた資源をいかに有効に使うかということと、やらかして傷ついた関係者の人的ダメージコントロールという作業が発生するといった負のスパイラルを未然に防ぎたい。

テクニックなど

意図的な楽観と悲観
感情や先入観が判断に与える影響は非常に大きい。

なので楽観的な視点と悲観的な視点の両面からの解釈と、自身の解釈を比較することでバイアスを是正する。

得るものと失うもの
価値観を反転させて評価してみることで新たな気づきを得られることがある。

例えば新機能をリリースした時、重大な問題が起こった時など、単純に一喜一憂するのではなく、何かを得た時は代わりに失われたものを、何かを失った時は代わりに得られたものが何かについて考える。

過去の判断に縛られない
人間の心理には「一貫性の原理」という脆弱性が存在し、時に経験則を装った雰囲気を出しながら判断を歪めてくることがあるので注意が必要。

順と奇、上中下策
ざっくりでも良いので施策はあえてオーソドックスなものと奇抜なものの両方を考える。

また解決手段としてスーパーリッチなものと最安で解決できるやり方、またそれらの中間を取った案を並べてみる。

一つのルートだけで考えると比較ができないので、できるだけ複数のルートを考え、その中から選択したり組み合わせて最適解を見つけるようにする。

与えられた選択肢を疑ってみる
他者から二択などを与えられた場合、どちらも相手の手の内であることがある。

「与えられた選択肢に応じるかどうか」をまず考える。

別方面からの突破の可能性を探る
扱っている問題の内側に解がない問題もある。

自分たちだけで無理なら他部署や外部の人を頼る。

個人的には「人間は問題というものの内側に閉じ込められやすいもの」だと思っている。

学び・気づき
抽象度を上げて捉え直すことで他のことにも適用できる要素を見出せることがある。

自分なりのデザインパターンとかフレームワークとして整理していくことで、判断力が底上げされていくイメージ。

---

主に一緒に働くチームメンバーに向けて書いたけど、読んだ方のなにかの足しになれば良いなーと思います。