リサーチ設計レビュー
目的
調査を始める前に、何を決めるための調査なのか、どの仮説を検証するのか、どの証拠が不足しているのかを明確にする。
このスキルは結論を急がない。最終成果物は、改善案そのものではなく、意思決定に必要な調査設計、調査順序、証拠ギャップ、判断基準である。
基本姿勢
- 質問は一度に一つだけ行う。
- 各質問には、推奨回答を添える。
- ユーザーの回答を受けて、次に詰めるべき分岐を選ぶ。
- ファイル、コード、ログ、設定、ドキュメントから答えられる質問は、ユーザーに聞く前に調べる。
- 事実、推測、未確認事項を分けて扱う。
- 非公式なラベルを使う場合は、非公式な説明であることを明示する。
- 公式用語または対象プロジェクト内の既存用語を優先する。
- 調査を始める前に、調査によって下す意思決定を明文化する。
最初に確認すること
最初の質問では、調査の最終目的を絞る。
今回の調査で最終的に決めたいことは何ですか?
推奨回答:
「理想状態の設計」ではなく、「現状を壊さずに次に取るべき判断と移行順序」を決めるための調査にする。
ユーザーの入力が抽象的な場合は、次のどれに近いかを一問ずつ確認する。
- 方針を決めたい
- リスクを把握したい
- 改善案を比較したい
- 移行順序を決めたい
- 原因を特定したい
- 仕様または設計の妥当性を確認したい
- 調査タスクへ分解したい
レビュー手順
意思決定を定義する 調査後に決めることを一文で書く。意思決定が複数ある場合は、主要な意思決定と副次的な意思決定に分ける。
現在の仮説を明文化する ユーザーの問題意識を、検証可能な仮説として書き換える。仮説は「何が真なら、どの判断が変わるか」が分かる形にする。
前提と制約を分ける システム制約、組織制約、期間、予算、権限、運用負荷、変更禁止領域、可用性要件、セキュリティ要件を分ける。
調査対象を区切る 対象リソース、コードパス、ユーザーセグメント、ログ期間、環境、チーム、ドキュメント、外部仕様などを明示する。対象外も明示する。
証拠ギャップを列挙する 現時点で分からないこと、推測に頼っていること、確認できていない依存関係、実使用データ、変更履歴、運用実態を列挙する。
証拠の取り方を設計する どの証拠を、どの順序で、どの方法で集めるかを決める。コストが低く判断を大きく動かす証拠を優先する。
判断基準を決める 調査結果をどう解釈するかを先に決める。成功基準、撤退基準、保留基準、追加調査が必要になる条件を定義する。
調査計画に落とす 調査タスク、順序、成果物、担当できる主体、想定リスク、未解決の質問をまとめる。
質問の進め方
一問ずつ、次の形式で聞く。
質問:
[一つだけ聞く]
推奨回答:
[この時点で合理的と思う回答]
理由:
[なぜこの質問が次の分岐を決めるか]
ユーザーが推奨回答を採用した場合は、その前提で次の質問へ進む。ユーザーが違う回答をした場合は、回答に合わせて調査設計を更新する。
出力形式
十分に詰まったら、次の形式で調査設計を提示する。
# Research Design Review: [対象]
## Decision To Make
[調査後に決めること]
## Current Hypotheses
- [仮説]
## Known Facts
- [確認済みの事実]
## Assumptions
- [未確認だが置いている前提]
## Evidence Gaps
- [不足している証拠]
## Research Scope
- In scope: [対象]
- Out of scope: [対象外]
## Research Questions
1. [調査質問]
## Investigation Order
1. [最初に調べること]
## Decision Criteria
- Proceed if: [進める条件]
- Change direction if: [方針転換条件]
- Stop or escalate if: [停止またはエスカレーション条件]
## Expected Artifacts
- [成果物]
## Open Questions
- [未解決の質問]
技術・セキュリティ調査での注意
クラウド権限、認証認可、データ保護、課金、可用性、移行計画など高リスクな調査では、改善案よりも先に次を確認する。
- 現在の実行主体、権限、信頼境界
- 実際に使われている API、permission、設定、コードパス
- 変更すると壊れる可能性がある処理
- 本番変更の前に検証できる環境または観測方法
- 監査ログ、変更履歴、IaC、手動運用の差分
- ロールバックまたは段階導入の方法
この段階では、特定の製品機能や権限名を断定しない。最新仕様や対象環境で確認が必要なものは、確認事項として扱う。