仮説検証の実践プロセス — 「解像度を上げる」を読んで自分なりに整理した

この記事について

馬田隆明さんの「解像度を上げる」を読んで、仮説検証のプロセスについて自分なりに考えが整理できたので、メモとしてまとめました。

プロダクト開発や業務改善で「何が問題なのか分からない」「やってみたけど効果がなかった」という状況は珍しくありません。思いつくままに解決策を実行しても、なぜうまくいかなかったのかを振り返れず、次の打ち手に繋がらないことが多いです。

以下は、馬田さんのフレームワークをベースに、自分がプロダクト開発チームで実際に運用してきた仮説検証プロセスを整理したものです。

仮説検証で目指すアウトプット

最終的に目指すのは、以下の形式で説明できる状態です。

「〇〇が原因で△△が起きている。だから□□をすれば解決する。なぜなら☆☆だから」

この一文が作れるということは、課題の原因を特定し、解決策の根拠を持ち、検証によって裏付けが取れている状態です。逆に言えば、この形にならないうちは、まだ解像度が足りていないということになります。

「解像度を上げる」のフレームワーク

このスライドで特に腹落ちしたのが、課題の解像度を4つの軸で捉えるという考え方です。

• 深さ: なぜそれが起きるのか？根本原因まで掘り下げる
• 広さ: 他にどんな選択肢があるか？複数の角度から検討する
• 構造: 要素間の関係性はどうなっているか？因果関係を整理する
• 時間: いつから起きているか？今後どう変化するか？

この4軸を意識しながら、自分のチームでは以下のステップで仮説検証を進めていました。

STEP 0 — 現状の確認

まずは現状を正確に把握します。感覚ではなくデータで状態を捉えることが重要です。

確認すべきポイントは以下の通りです。

• 件数: 問題は何件起きているのか？
• 発生箇所: どの工程・どの機能で起きているのか？
• パターン: 特定の条件下で集中していないか？

このステップでは、思いつくまま課題を列挙して構いません。まずは課題を出し切ることが目的です。

優先度調整 — RICE SCOREで選ぶ

課題が出揃ったら、どれから取り組むかを決めます。自分のチームでは RICE SCORE を使って優先度を付けていました。

RICE = (Reach × Impact × Confidence) / Effort で算出し、スコアの高いものからアサインしていきます。

参考: RICE: プロダクトマネージャーのためのシンプルな優先順位付け方法

STEP 1 — 課題の原因調査

アサインされた課題に対して、深さを掘るアプローチで原因を調査します。

確認すべきことは以下の3点です。

• 再現性: 発生当時から状況が変わっていないか？今も再現するか？
• 原因: なぜ起きるのか？
• 発生条件: 特定の条件があるか？あるならどういう条件か？

調査の手段

• ログをたどる: 実行ログや計測データから、どの工程で何が起きているかを追跡する
• 手元で再現させる: 実際に問題が起きる状況を手元で作り、動作を観察する

エンジニアとしての強みの一つに「手を動かせる」ことがあります。状況を再現できる環境をさっと準備したり、デバッグコードを仕込んでみたりと、技術的なスキルを活かして調査を進められるのはエンジニアの大きなアドバンテージです。

大事なのは、手が止まらないようにすることです。分からなければその時点でチームに相談します。「悩む」のではなく「考える」ことが重要です。

参考: 「悩む」から「考える」へ切り替えよう！上手な悩みの解消方法とは？

プロジェクトの目的は「正しい原因を探すこと」ではなく「課題を解決すること」です。原因について厳密に探すというよりも、「こうなんじゃない？」くらいの確度のものでいいので出しましょう。

この時点で、「〇〇が原因で△△が起きてるかも？」 までを埋めます。

STEP 2 — 解決策の仮説出し

課題の深掘りができたら、次はどうやったら解決できるかを考えます。ここでは深さよりも広さを重視して進めます。

• 一つの解決策にとらわれず、いろいろな角度から検討する
• アイデアが出ないときはインプットを増やす（チームでブレスト、他社事例の調査など）
• 「他にどんな選択肢があって、なぜこの方法を選ぶのか」を意識する

これはソフトウェア設計で代替案を考えるプロセスと似ています。設計に絶対的な正解があるわけではなく、要件・制約・状況によって最適解は変わります。トレードオフを分析した上で、複数の選択肢の中から最適なものを選ぶのが重要です。

あれこれ考えて 「〇〇が原因で△△が起きてる。だから□□をすれば解決するのでは？」 という仮説を作ります。

仮説レビュー — 何を検証するか決める

出てきた仮説を Confidence（確度） と Effort（工数） で分類します。

• Confidence が高い仮説 → そのままチケット化して実装に進む
• Confidence が低い仮説 → STEP 3 で検証してから判断する

STEP 3 — 仮説検証

不確実な仮説について、根拠を集めます。

「〇〇が原因で△△が起きてる。だから□□をすれば解決するのでは？」

↓

「〇〇が原因で△△が起きてる。だから□□をすれば解決する！」

くらいに言えるまでの確度を目指します。

最小コストで検証する

仮説を確かめる最も確実な方法は「実際にやってみること」ですが、それには時間がかかります。本実装に入る前に、最小コストで検証する方法をまず考えます。

馬田さんの「MVP の作り方」にあるように、手作業型MVPで十分検証できるケースは多いです。

検証の実例

自分が実際に経験した2つの例を紹介します。

例1: 削除したはずのデータが復活するバグ

ORMを使ったアプリケーションで、関連データを削除したはずなのに、別の処理が走ると削除したデータが復活するという問題が起きました。

1. 仮説: ORMの自動更新機能が、レコード保存時に関連データをUpsertしているのでは？
2. 検証方法: 実行されるSQLをログ出力して、削除後の保存処理で何が起きているか確認
3. 結果: 保存時にORMが自動的にアソシエーションを再作成していることを確認。自動更新をスキップするオプションを指定することで解決

（詳細: GORMのアソシエーションの自動更新で削除した関連が復活していた）

例2: 日時比較が期待通り動かない

Railsで期間判定のコードを書いたところ、対象期間内のはずなのに false が返ってくる問題が発生しました。

1. 仮説: 比較対象の型が異なるのでは？（TimeとDateの混在）
2. 検証方法: コンソールでそれぞれの型を出力して確認
3. 結果: Time.zone.now（TimeWithZone）と Date.new（Date）で型が違っていた。型を揃えることで正しく動作

（詳細: Railsで日時比較をする際に型が違って焦った話）

いずれも、本格的な修正に入る前に「なぜそうなるのか」を小さく確認するだけで原因が特定できた例です。

検証結果の解釈

検証の結果、当初の課題が解決されたならば、組み立てたロジックが正しかったことになります。

「〇〇が原因で△△が起きてる。だから□□をすれば解決する。なぜなら☆☆だったから」

逆に、意図した結果にならなかった場合は、「〇〇が原因で△△が起きてる」か「□□をすれば解決する」のどちらかが間違っています。STEP 1 または STEP 2 に戻って考え直します。

整理してみて

自分なりにプロセスをまとめると以下のようになりました。

1. 現状確認: データで問題を把握し、課題を列挙する
2. 優先度付け: RICE SCORE で取り組む順番を決める
3. 原因調査: 深さを掘って「なぜ？」を明らかにする
4. 仮説出し: 広さを持って複数の解決策を考える
5. 仮説レビュー: 確度と工数で実装 or 検証を判断する
6. 仮説検証: 最小コストで検証し、根拠を固める

実際にこのサイクルを回してみると、「やってみたけどダメだった」で終わらず、どこから間違っていたのかを考察でき、次の打ち手に繋がると感じています。

馬田さんのフレームワークで特に役立っているのは「深さ」と「広さ」の使い分けです。原因調査では深さを掘り、解決策では広さを持つ。このメリハリを意識するだけで、思考の質が変わりました。