調査スパイク — 判断の危険を潰すまで走り切る

なぜこの skill があるか

調査は成果物が情報そのもので、次の判断や工程に渡って初めて価値になる。ふつうのストーリーと同じ型で扱うと、「問いに答えた」で完了にしてしまう。

そして「問いに答える」ために調べると、最初に思いついた枠を一つ裏付けたところで手が止まる。枠の外で判断が壊れていても気づけない。

この skill の核は「問いに答える」ではなく「判断の危険を潰す」。

調査そのものが小さな一巡になっている。計画を立てて合意するまでは依頼者と対話し、調べ出したら自走し、最後に報告する。

扱う調査、扱わない調べ物

扱うのは、それ自体が成果物になる調査。 ある問いを潰さないと次の判断・見積もりができない、というときの調べ物。

下調べは止めない。 どちらのモードで進めるかを決めるための情報集めや、手を動かす流れの中でその場で消費される確認は、この skill の対象ではない。そのまま進めてよい。

調査の計画を立てて合意する

ここは対話。要件を固めるときと同じ深さで、依頼者と認識を揃えてから調べ始める。対話の進め方そのものは dialogue-principles を呼ぶ。

計画に置くものは 3 種類あって、埋め方が違う。

• 土台 — 依頼者に聞いて埋める。埋まるまで確かめどころを建てない
• 確かめどころ — こちらが出し切って、依頼者に足してもらう
• 持ち越してよいもの — この調査の結果を誰が使うか。分からなければ持ち越す。ここで止めない

土台 — 幹から枝へ聞く

いきなり枝葉を聞くと、答えは返ってくるが的がずれる。この順で進む。

1. 何を決めるための調査かを聞く（依頼文に書かれていれば、そこから読む）
2. ゴールの像を返す — 「こういうことがわかればいいですか」と自分の理解を言葉にして、直してもらう。ここだけは聞く工程ではないので、依頼文がどれだけ詳しくても省けない
3. 既に調べたこと、分かっていることを聞く
4. 動かせない条件・やってはいけないことを当て切る — 併せて、ゴールに向けて他に足りないものも一つずつ聞く

ゴールの像は往復のたびに変わる。変わったら、像を返し直すところまで戻る。

なぜこの順か。 何を決めるためかが無いと的が定まらない。ゴールの像を返さないと、以降の問いが全部ずれた的に向く。既に調べたことを聞かないと、相手が知っていることを発見として差し出すことになる（調べる範囲もそのぶん減らせない）。制約はゴールが定まる前に開いて聞いても的が無く答えようがないが、遅れて出てくると組んだ枠ごと崩れるので、定まった直後に当てる。

問い方。 選択肢を作って選ばせない。選択肢を出した時点で枠はこちらのものになり、依頼者は実態が外にあっても「最も近いもの」を選ぶしかなくなる。一度に何問も出さず、一つ聞いて、返ってきたものを踏まえて次を聞く。往復は増えるが、外れた土台の上に建てた計画を建て直すより速い。

確かめどころ — 出し切って、ファイルに見せる

土台が埋まったら、ゴールの像を確かめどころに割り、確かめどころごとに 何が確かめられていればその判断をしてよいか まで降ろす。これが完了の基準になる。docs/working/<題名>/調査計画.md に書く。

確かめどころを自分一人の想像力で決めないため。頭の中で意図を揃えても依頼者には見えないので、足しようがない。出し切ってから「他にありますか」と聞ける形にする。

落ちるのはたいていここ。調べる側は自分が思いついた角度しか計画に入れられず、現場の実態は依頼者の側が持っている。出さないままだと、後から指摘されて初めて穴が空く。

書き方は「壊れる道」ではなく「何が確かめられていればよいか」で。判断が外れる形は壊れることだけではない。前提が違った、情報が古かった、規模が変わると成り立たない、も同じくらい起きる。破壊の語彙で書くと、そこが視界から落ちる。

自走に入ってよいのは、合意を受け取ってからだけ

合意はこちらが宣言するものではない。「合意できました」「計画を確定しました」と自分で言って進まない。判子を自分で押せる形になっていると、揃っていなくても通る。

走り出す直前に、前段をもう一度通す。ひとつでも当てはまるなら、まだ入らない。

• 計画そのものに同意する言葉を、依頼者から受け取っていない — 別の論点への回答・沈黙・話題の移動を、同意に読み替えない
• ゴールの像に、依頼者の直しが入っていない — 自分の中で像が固まったことを、合意と読み替えない
• 土台 — 何を決めるための調査か・既に調べたこと・動かせない条件 — に、依頼者の言葉で埋まっていないものが残っている
• 依頼者が食い違いを表明した項目が残っている — 自分の判断で「後で決める」に変換して通さない
• 計画をファイルに出して、依頼者に見せていない

調べる

合意を受け取ったらここからは自走。終わってから報告する。

• 反証で開く: 裏付けを一つ取って閉じない。判断が外れる条件の方を確かめにいく
• ミニマムから小さく速く回す: 作り込まない、捨てる前提。最初は条件をそぎ落とした状態で試す。散らかった現実の状態から始めると、何が効いたのか切り分けられない。利用者の現実の条件は、反証で当たりにいく対象の一つとして後から寄せる
• 事実と推測を分けて積む: 観測したことと、そこからの解釈を区別する。集計値や自己申告を鵜呑みにしない
• 実験の場を実資産から隔離する: 使い捨ての作業領域で試す。実データ・実環境を対象にする実験は、依頼者の確認を取ってから行う

最後の一つは、この skill が「判断が外れる条件を確かめにいけ」＝壊れる方を実際に試す方向に促すため。試せば本当に壊れる。

ここで書くコードは資産にしない

調査のために書くコードは使い捨て。実装の規律（テストを先に書く、リファクタする、commit して積む）には載せない。調査が終わったら捨てる。

残すのは分かったことだけで、確かめるために書いたものは残さない。

調べ方は 2 つ

• 読む・探す: 一次情報で裏を取る。要約や又聞きで止めない
• 仮説を明示して試す: 何が起きると思っているかを先に書いてから動かす

単発の「動かして見てみる」も暗黙の仮説を持っている。明示しないと、その仮説を反証しにいけない。

調べたことを計画に反映する

記録用の別文書は作らない。調査計画のファイルに、分かったことを反映していく。

この文書は、あとから自分が読み返して文脈を取り戻すためのもの。この文書自体をそのまま人に渡すことはないので、見せるための整形はしなくてよい。

会話の順に追記していくと、報告の控えになって言葉がぶれる。計画に反映する形なら、確かめどころごとに区切られて上書きされる。

計画に書いた「これが確かめられていれば判断してよい」の横に分かったことが並ぶので、終わっているかどうかが自分で見て分かる。

どこで終わるか

終わりは 2 通り。どちらも報告に出す。

• 合意した意図を達成できる状態に到達した
• 達成できないと分かった — 判断そのものが成り立たない、前提が違った、など。前提を変えるところから議論が要るので、報告して依頼者に返す

完了の基準は計画で合意したもの。自分で基準を作り直して自分で完了にしない。

報告する

ここだけは書式を守る。

調べている間は実況してよい（何をしているか見えないと依頼者が困る）。ただし報告はそれと地続きにしない。はっきりした区切りを立てて、どこからが報告かを示す。 実況がそのまま流れ込むと、過程を読み返さないと要点に届かない報告になる。

ここから報告                    ← 区切り

## 結論
問いへの答え / それが平易に何を意味するか / どこまで調べ切ったかの確信の度合い（残っているリスクを含む）

## 詳細
何をどう調べたか

## 証拠
生データで裏を取ったものだけ

## 次の一手（軽く）
提案は出す。判断は依頼者に残す

抽象度を上から下へ。結論を先に置き、読み手が途中で降りられるようにする。

報告のあと

書き起こすかどうかと、誰向けかを依頼者に確認する。誰が読むか分からないと引き継ぎ文書は書けない。

作ると決まったら、引き継ぎ文書を書く skill（handoff-docs）を呼ぶ。