前提
必要な情報を全て集めてから物事に取り掛かることは膨大な非効率を生む。
必要な情報が足りていない段階で、どこまでが必要な情報かは自分では判断がつかないため、当然いつまで経っても終わりが見えないのだか、その不可能なことを無理やり行おうとする中で、膨大な時間の消費や、答えの出ない試行錯誤による精神的な疲弊を生む。
必要な情報を集めきってから取り掛かることはそもそも不可能だと認めた上で、効率よく進める方法を選択する。
それがいわゆる仮説思考のアプローチ。
必要最低限の情報と、自分の持っている経験・情報をもとに、仮説というその時点での答えを出す。
そして、それを検証する中で、仮説に不備があればなんらかの不整合が発生するので、そうしたらそのことを踏まえて仮説を修正する。
この 仮説立て→検証→仮説の修正→検証 のループを回すことで、最小限のインプットで物事を遂行できる。
流れ
- 仮説ベースで結論を出す
- 背景
- 要件
- 進め方
- 必要最低限のインプット(一次情報・ざっくり全体構造, これらがわかっている場合はスキップ)
- 現状分析
- 具体的な対処法(現状の何をどう変えたら要件を満たせるか, 具体的なイメージをビジュアルでまとめきる, 手が止まらずに検証できる具体度)
- 各種設計
- 疑似実装
- 検証
- 変更範囲
- 影響範囲
- 実装
- 検証時
- 仮説に不備があることが発見された場合、仮説の修正→再度検証
- 発見されなかった場合、完了

ポイント
マインド
全体
- 強引にでも仮説で最終的な結論を出してから動くことを徹底する。試行錯誤は禁止。
- 仕事を受ける立場である以上、コンプリート・スタッフ・ワークをする(自分が受けた仕事を完遂せよ、いかなるときにも)。すべての仕事は結果がすべてである。努力は一切評価されない。
- 1回の完成度よりも回転数を重視する。(1回で完成させるのを目指すのは超非効率なので辞める。仮説駆動×回転数によって、理論上最小限の労力で物事を遂行する。)
- 細かいことは意図的に無視し、今持っている知識から導き出せる仮説を元にアウトプットしきる(60%程度の完成度になるはずだが問題ない。)(焦る必要はない。落ち着いて行える処理スピードでいい。ただ、やることが減るので全体的な工数を少なく完成できるという話。)。
- 完成度が十分かどうかは、検証段階で考慮不足などに気づくことで検知できる。
- その情報を踏まえて何回転もさせることで、十分な完成度まで持っていく。
仮説立て
- 手を動かす前に、手が止まらずに検証できる具体度の仮説を立てきる・強引にでもスタンスを取る。やってみないとわからないとは決して言わない。
- 仮説を立てるのに必要な最低限の情報は、まず一次情報・次にざっくり全体構造で十分。
検証
- 闇雲にやってはいけない。いきなり飛び込まない。
- サブイシューの中には、必ず最終的な結論や話の骨格に大きな影響力を持つ部分がある。そこから手を付け、荒くてもいいからそれが本当に検証できるかについて答えを出す。
- それが終わったあとは、バリューが同じくらいであれば、早く終わるものから手を付ける。
実行したときの感想
- 適当にやっていい。60％のできでやっていい、というよりも、最低限のインプットと仮説ベースで行えば、1サイクルあたりそれくらいの完成度になるだけという話。そしてそれで問題ないという話。検証段階で完成度が合格点以上か未満かはわかる。未満だった場合は、そこまでの経験を元に同じサイクルを回せば、2,3回転でだいたいうまくいくという話。