第3章育て方サイクル総論
1周のストーリー
成果物は一度で完成しません。だから、育てるための決まった手順——4ステップのサイクル——を回します。
そしてこのサイクルを、本メソッドは人だけで回すとは考えていません。AIとともに成果物を育てる——4ステップのそれぞれに、人の隣で働くAIがいます。何をしてもらうかは、ステップごとに違います。
| ステップ | やること | AIにさせること | いつ |
|---|---|---|---|
| 【たたく】 | 叩き台の執筆 | 執筆をサポートさせる | 成果物を書くとき |
| 【深める】 | SE・発注者との議論、論点整理／ADR記録 | 議論と論点整理をサポートさせる | 論点が出たとき |
| 【広げる】 | 業務のシナリオを成果物の上で歩かせ（シミュレーション）、足りないところを探す | シナリオを創作して歩かせ、人への気づきを出させる | 節目に立ち止まって |
| 【確かめる】 | 決めたことが成果物で守られているかの検算 | 食い違いや、判断できない箇所を指摘させる | 決定が増えたとき・変更が来たとき・成果物が書かれた、直されたとき |
まず叩き台を書く（【たたく】）。叩き台には必ず未決と論点が残るため、SE・発注者と議論して決め、決めた理由をADRに残す（【深める】）。個々の論点を潰しても俯瞰したときの抜けは残るため、視点を引いて検査する（【広げる】）。そして、決めたことがその後も守られているかを検算する（【確かめる】）。この1周で成果物はひとつ成熟し、次の周でさらに育ちます。
後ろの2つは、どちらも検査です。【広げる】は成果物と運用場面を突き合わせます。一方【確かめる】は成果物と決定を突き合わせます。特に、【広げる】は、順調に進んでいるように見えるときこそ、意図的に立ち止まる機会を作る目的があります。
一つの文書の書き方（体裁・命名）は、どちらの検査でも問いません。書き手が書いた直後に整えるものです（4章）。
4ステップを貫いて、決定の記録＝ADRがあります。【深める】で生まれ、【確かめる】で検算の基準になります。
決めるのは、常に人である。AIが出してよいのは、【たたく】では叩き台、【深める】では論点の整理、【広げる】と【確かめる】では問いと指摘までとする。決定・合否・修正案は、AIに出させない。
AIに何をさせ、何をさせないかの線引きは、この規範に尽きます。検査側の共通規律としての明細は9章、任せ方の勘所は【たたく】の章に置きました。なお、ここでいうAIは特定の製品を指しません——プロジェクトの文書群を材料として渡したAIが担える形で、本書は書いています。
本書が厚く書くのは、後半の2ステップである
先に断っておきます。【たたく】と【深める】を、本書は深くは説明しません。叩き台を書くこと、関係者と議論して決めること——これは読者のみなさんがこれまで培ってきたものそのものであり、本書が教え直すようなものではないからです。本書がそこに足すのは、決めたことと、決めた理由を記録に残すという一点だけです（5章）。
本書が厚く書くのは、【広げる】と【確かめる】のほうです（8章・10章）。俯瞰して抜けを探す、決めたことが守られているかを全体と突き合わせる——やったほうがよいと分かっていながら、人手では割に合わなかった作業です。AIが担えるようになって、ようやく現実的になりました。
小さく回して、視野を広げる
サイクルは小さい単位から回し始め、小さく回したものを広い単位で見直す。いきなり全体を相手にしない。
全体を一度に相手にすると、叩き台は薄くなり、シミュレーションのシナリオは一般論になり、論点は散ります。だから業務フロー1本のような小さい単位で回します。単位の切り方と段数はプロジェクトが決めます（例：業務フロー→業務ドメイン→全体。導入の進め方は14章）。
小さく回すと、単位ごとに決めたことがばらばらにならないかが気になります。けれども、単位をまたぐための引き継ぎの作業は、新しく作りません。今ある仕組みが、そのまま受け渡しを担います。
- 決まったことは、ADRとして台帳に残ります。上の単位の書き手が引くのは、自分の成果物に当たるADRと「横断」のADRです。下の単位だけに当たるADRまでは引きません（4章）。
- 決まらなかったことは、節目の棚卸しが拾います。
- 単位どうしの食い違いは、広い単位で【広げる】を回すと見つかります。歩かせるシナリオが、複数の単位の成果物をまたぐからです。見つかったら上の単位の【深める】で決め、下の単位の決定を置き換えます。下の単位だけの例外なら、下に残して構いません。
工程をまたぐとき
4ステップ（【たたく】・【深める】・【広げる】・【確かめる】）を、要件定義・外部設計の両方に同じ手順で適用する。工程が変わっても手順は変わらない。
変わるのは、【広げる】のレンズだけです。
工程をまたぐときも、仕組みは増えません。要件定義の決定は現役のまま残ります。外部設計でADRを起こすのは、設計の側で新しい決定が出たときだけです。要件定義で決めきれずに持ち越したものは、工程の節目の未決型ISSUEの棚卸しが拾います（5章）。
決定は、成果物を経由して次工程へ伝える。成果物は直前工程の成果物を参照し、他工程のADRを直接参照しない。
この形にしておくと、方針が成果物に反映されていなければ外部設計に届きようがありません。反映漏れが、構造として見えるようになります。ADRどうしのリンク（置換など）と、同じ工程の中の単位どうしは、この決まりの対象外です。
変更が来たときも、同じサイクル
ここまでの1周は、新規作成を前提に描きました。しかし仕様は変わります——変更要求が来たときも、同じ4ステップを別の入り方で回します。入口は【深める】であり、新しい台帳も新しい検査も増やしません。変更の受け付け・影響範囲の特定・既存の決定の置換・反映の追い切りは、11章で扱います。