解像度の高め方

解像度 = 深さ * 広さ* 構造化 * 時間

深さについて

課題の表面で判断せず、真なる原因を探るべき

顧客の意見ではなく事実を聞く

顧客がほしいものが本当に顧客がほしいものとは限らない

顧客自身の解像度が低いため

事実をもとに、真なるところを探す

深さレベルは7くらいまで深堀りを進めるべき

適宜調査なりを駆使しつつ

深さレベル2とかまでは、とにかく情報量を増やして全体観を知るべき

事実 → 洞察をwhy so ?を繰り返すことで行い、深さレベルを上げる

ひたすら文章に書いて、精緻化する

文章化によって、不透明な部分が明らかになったりする

広さについて

前提を疑う（ゼロベース思考）

そもそも〇〇

いくつか問いのパターンを持つと良い

視座を変える

視座をあげれば広く見えるが細かいとこは見えにくくなるし

視座をさげれば細かいとこが見えやすくなるが、全体観がわかりにくくなる

自分より2レイヤー上のポジションの人間の視座になってみると良い

体験してみるのも良い

レンズをいっぱいもつ

同じ事実も、レンズ（自分が持ってる理論、視点）を変えることで、見え方が変わる

理論厨になる

深堀りするべき箇所の再考

構造について

切り口をもって、分類し、重要なものを見極める

分ける → 比べる → 関係づける → 省く

「分ける」は目的にあった分け方をする

「比べる」は同じ抽象度同士で比較する

更に、重要度（影響度）が高いものを見極める

「 関係づける 」は、共通項を考えてグルーピングしたりしてつながりを見出す

「省く」は、目的に応じていらないものを捨てたり粗くしたりすること

時間について

時間の流れを意識する

課題は時間とともに移ろう

歴史を振り返る

全体をステップ（工程）にわけて、どこのステップに闇が混じってるかを考えたりする

= 時間が切り口となっている

ボトルネックが全体のどこにあるかを考える

パフォーマンスチューニングとかと同じだ

時間に関わらず、全体を段階分けして、どこにボトルネックがあるかを探すアプローチは良さそう

各段階で何が問題で何が問題じゃないのか。何が事実なのか。そもそも問題はその段階に存在しているのか。

解像度の上げかた

情報を得る → 思考する → 行動する　のサイクルを早く回す

なので、何事においてもMVPを早く出すことは↑のサイクルを早く回すことに貢献するので、積極的にやるべき

実装方針だけ早く共有するとか

進捗だけ早く共有するとか

大枠だけ早く共有するとか

粘り強く時間をかけ続ける

とりあえずまずは型に沿ってやってみる

課題について

取り組む課題の選び方

課題の大きさが大きい

課題の大きさ = 課題の強度 * 課題の頻度

課題の強度 = 課題が起きた時の痛み

課題の頻度 = SSIA

合理的なコストで現実的に解決しうる

課題の取り組み方

課題を分割して小さくして、一番クリティカルなものから取り組む

解決策について

深さ

課題の大きさ以上の便益は得られない

最低限どこまでできていればOK（どこまで課題を解決できていればOK）を決める

先にプレスリリース的な感じで完成後の状態を細かく詳細に書いておくと、解決策と、その背景にある課題の深みが増す

how(どうやって?)を繰り返して深さを上げていく

行動可能な粒度になるまで

解決策の発案方法

専門知識をつける

プロトタイプをつくる

広さ

道具にこだわりすぎない

特定の道具にこだわりすぎると、視野が狭くなる

ただし、自分で色んな道具を使えるようになっておくことは大事

自分にできないことを選択肢から除外しない

ヘルプだせばOK

もしくは札束で殴る

常に一定のリソースを探索に費やして、アンテナを貼ることが大事

解決策の真の価値を問い続ける

解決策が解決する課題は何なのか

課題を解決した先に何があるのか

構造化

欠点はシステムに必ずあるので、スコープを削ってクリティカルなものを捨てに行く

トレードオフをあえて作る

課題の解像度が高ければ、何を捨てていいかがわかる

何かを対価に、確実に何か取りに行くべき

何かを捨てることで、解決策に独自性を出す

捨てることこそ大事

ピラミッド構造などにして、解決策と課題の論理的関係性をはっきりさせる

課題と解決策の色々な組み合わせを知っておく

引き出しが増える

予算やガイドラインなどといった、制約を持たせて解決策に一貫性をもたせる