第4章たたく ── 叩き台の執筆

この章で語ることは、多くありません。叩き台を書くことは、これまで培ってきた仕事そのものだからです。本メソッドは、そこに新しい手順を足しません。

何を書くのか

あなたが書くものは、これまでの要件定義・外部設計で作ってきたものと変わりません。一般的には、要件定義なら業務の定義、業務の流れ、業務イベントと例外、ユースケース、要求事項、主体（アクター）の一覧、情報（エンティティ）の一覧、権限と情報の取扱い、外部インタフェース、用語集——といった成果物が並びます。外部設計なら、ユースケースの設計、状態の定義と遷移、画面、データの入出力、権限（外部設計版）といったものになります。

成果物の数・名前・分け方は、プロジェクトの標準に合わせてください。本書が求めるのは、次の2点です。

こう書いた業務の流れは、後の【広げる】で業務のシナリオを歩かせるときの道になります。タスクとタスクの受け渡し、タスクの終わり、タスクのつなぎ目が、そこで検査されるようになります。

たとえば、ユースケースは業務の流れのどのタスクを実現するのか、要求事項はどのユースケースから出てきたのか、画面はどのユースケースのためのものか。書いた人の頭の中にあるこのつながりを、成果物の上に書いておきます。これが、Trusted Spec の条件③（辿れる）の中身です。

このつながりが表すのは、何を根拠に書いたかです。どちらを先に書いたかは問いません。

検査のために、何を揃えておくか

書いたものは、この後【広げる】と【確かめる】にかけられます。どちらも、書かれたものを読み直す作業です。読み直すときの手掛かりは、書くときにしか置けません。そこで、書き方の様式はプロジェクトの標準のままにして、検査が手掛かりにする要素だけを、ここで挙げておきます。

実際の成果物のどこにどう現れるかは、付録に例があります。

表の語は、次の意味で使っています。プロジェクトの標準が別の名前を使っているなら、そちらで読み替えてください。

• 主体：タスクを担う人・役割・組織・システム（「アクター」と呼ばれることが多い）。
• 開始条件・事後条件：そのタスクを始めてよい状態と、終わったときに成り立っている状態。テスト工程では事前条件・事後条件と呼びます。
• 業務ルール：業務上の取り決め。「何のため」の根拠の側にあたります。
• 状態の定義：情報がとりうる業務上の段階と、その意味。

関係する決定を、どう読み、どう残すか

叩き台を書くとき、すでに決まっていることがあります。前の工程で決めたこと、この工程の前の周で決めたことです。業務ルールに関する決定は、理由と一緒にADRという記録に残っています（2章）。最初の1周では、ADRはまだほとんどありません。周を重ねるほど増えていきます。

ADRには、その決定を受けて後の成果物が満たすべき状態（制約）と、それがどの成果物に当たるか（影響範囲）が書いてあります。特定の成果物に絞れない決定には、「横断」と書いてあります。

そのために、書く前に、それらのADRと上流の成果物を読みます。制約を記憶や推測で使わない、ということです。

たとえば販売業務のユースケースを書くなら、「販売業務のユースケース」に当たるADRと、「横断」のADRを読みます。あわせて、そのユースケースのもとになった要求事項を読みます。ADRが増えてきたら、影響範囲ごとにADRを引ける一覧（索引）を作っておくと、引くのが楽になります（7章）。

読んだ決定のうち、理由があって書かれた一文を、ADRを知らない人が善意で書き換えてしまうことがあります。そういう記述には、脇にADRのIDを書いておくと防げます。

注記は、付けるところを絞って構いません。付けていなくても、決定が守られているかの検査は届きます。検査は、決定の側から、当たる成果物を引くからです。ADRが後で置き換わっても、注記は書き換えずに済みます。元のADRから、新しいADRへ辿れます。

AIに、どこまで書かせるか

叩き台は、AIに書かせることができます。ただし、出てきたものは人が判断するための「たたき」です。

出力をそのまま成果物にすれば、1章で見たAI補完を、誰も確かめないまま通すことになります。人が読み、直し、決まっていないことを「未決」として残す——ここからサイクルが始まります。

線引きの理由は、ひとつです。AIは流暢に書きますが、その内容が正しいとは限りません。根拠のない補完や、一般論での埋め合わせが混ざっていても、見栄えは良い。だから、判断は人がします。

AIに、どう任せるか

どれも、任せ方しだいで効き目が変わります。

• いきなり清書させない。先に観点を出させ、人が選ぶ。最初から文章にさせると、採らなかった選択肢が文面から消え、後から「なぜこう書いたのか」を問えなくなります。候補を並べさせ、人が採否を決めてから書かせます。
• 書かせる前に、文脈を渡す。書き方の約束事、用語集、これまでの成果物、それに自分の成果物に当たるADR。制約を記憶や推測で使わないのは、書き手が人でもAIでも同じです。
• 埋めたところを、埋めたと言わせる。AIは、根拠が見つからない箇所も黙って埋めます。だから最初に「根拠が見当たらなかった箇所を挙げよ」と指示しておきます。挙がったものは、未決の候補として【深める】へ渡ります。
• 業務の正誤を含まない照合は、素直に任せる。用語の不統一や、成果物間の記述のずれは、量が多く、人が最も取りこぼします。ここはAIのほうが確実に速い。

書いたあと、何を見直すか

参照が辿れる状態にしておく

成果物どうしのつながりは、IDでの参照として書かれます。この参照は、書いたときには繋がっていても、直しているうちに切れていきます。消した要求事項を、ユースケースがまだ指している。同じ主体が、成果物によって別の名前で呼ばれている。そうなると、【広げる】でシナリオを歩かせても、途中で道が切れてしまいます。

自分の書いた文書を見るだけでは、どこからも参照されていない要素は見つかりません。全体は、節目にAIに照合させます。