第8章広げる ── シナリオを歩かせる

【広げる】とは、何をする検査か——シナリオを歩かせる

成果物がひととおり揃ってきたら、俯瞰した視点から「足りているか」を確かめます。それが【広げる】です。

シナリオが歩く道は、業務の流れです。タスクごとに担う主体・開始条件・事後条件を持った業務の流れがあって、はじめてシナリオは歩けます。

トレーサビリティを確認するような検査は、書かれているものどうしのつながりの切れ目や食い違いは見つけられても、そもそも書かれていないものには届きません。シナリオを歩かせると、書かれていないところで止まります。この技法そのものは要件工学で確立されたもので（付録_出典）、本書が変えたのは、シナリオを作って歩かせる役をAIに担わせた点です。

【広げる】は、節目に立ち止まって回します。意味を問う検査なので、同じ成果物を二度検査しても、同じ指摘が返るとは限りません。指摘を採るかどうか、どこに記録するかは、人が決めます。

歩かせると、何が見えるか

たとえば、次のような空白です。

• どの成果物にも持ち主のいない属性。 閾値の切り替えを予約する前提になっているはずの「キャンペーン期間」が、業務の定義にも情報の一覧にもユースケースにも、どこにも定義されていません。
• 設計が置いた単位の、外側にある実務。 「注文ごと」を前提に送料を設計したが、同じ顧客が同じ日に分けて注文した場合の扱いに、どの成果物も触れていません。
• 権限が一方向にしか設計されていません。 閾値を変更する操作は与えられているが、誤って切り替えたときに、すぐ元へ戻す手段がありません。

いずれも、記述どうしの食い違いではなく、そもそも書かれていないことに特徴があります。

シミュレーションを、どう回すか

AIにシナリオを創作させる

AIに業務シナリオを創作させること（担当者の異動と引き継ぎ、キャンペーン期間中に受注が締め日をまたぐ、急ぎの値下げで承認を省きたくなる、等）は、「AIは答えを生成しない」という共通の規律からの、意図した例外です。例外はシナリオという一点だけで、範囲を次のように固定します。

成果物どうしの参照がきれいに繋がっていても、書かれていないものは残ります。だから、シナリオを歩かせて疑います。

AIに、どう任せるか

この検査は、AIにサポートさせて回します。効くかどうかは、任せ方で決まります。

• 答えではなく、問いを出させる。 「ここは○○とすべき」まで書かせると、人はその案の当否を考えはじめ、空白そのものを見なくなります。出させるのは「歩かせたらここで止まった」「読み取れなかった」までです。
• 思いついた順に作らせず、種を渡して狙いを持たせる。 シナリオの当たり外れは、種（次節）を渡すかどうかで大きく変わります。
• 実際に読ませ、読んだ箇所を言わせる。 記憶と一般常識で歩かせると、検査しているのは成果物ではなく、AIの常識になります。

シナリオの種

成果物は必ず暗黙の前提の上に書かれていて、その前提のうち最も支配的なのは時間です。成果物が描けるのは、1本の線の中の時間だけです。業務の流れは1回のプロセス実行を、ユースケースは1回の相互作用を、状態遷移は1つの対象の一生を描きます。実務で流れているのは、その線の外側の時間です。多数の案件（受注や申請のような、1件ずつの業務）が違う速度で並行し、その間に対象者は入れ替わり、担当者は異動し、期限のほうが先に来ます。シミュレーションが歩かせるのは、この外側の時間です。

この6つを全部回せば網羅できる、というものではありません。プロジェクトに合わせて、足したり削ったりしてください。自分で種を増やすときは、「この成果物が置いている時間の前提は何か」を問います。いつ時点の写しか、どれだけの長さを想定しているか、何本が同時に走っている想定か、です。

種はシナリオを作るときに使い、レンズは歩かせたシナリオを見るときに使います。種を見る目として使うと、レンズがひと通り当てて終わる照合リストに戻ってしまいます。

どれだけ回すか——軽く始めて、増やす

件数と深さは、プロジェクトの規模や成果物の状態に合わせて、検査のたびに調整します。

深くすれば論点は増えますが、人が捌く量も増えます。検査の大きさを決めるのは、AIの出力量ではなく、人が判断しきれる量です。

出てきた論点は、人が振り分けて初めて未決型ISSUEになります。AIが未決を量産することはありません。

歩かせたシナリオは、その後どうなるか

シミュレーションの成果は、その場の指摘で終わりません。登場人物・時系列・前提が具体化されたシナリオは、すでに試験シナリオに転用できる状態になっているはずです。また、書かれていなかったイベントや例外が見つかれば例外の一覧が充実し、そこから例外系の試験シナリオが立ちます（12章）。シミュレーションのコストは、テスト設計の前倒しとして回収されます。AIに渡すものと返ってくるものの実際の形は、付録の通し例にあります。

手元にあるなら、試してみてほしい

シミュレーションは、大がかりな準備をしなくても試せます。たとえば intra-mart の業務フロー（BPM）のエクスポートファイルは、そのままAIが読み取れます。これと各タスクのユースケースさえあれば、シナリオを歩かせることはできます。手元にあるなら、ぜひ一度試してみてください。

試すと、もうひとつのことが分かります。AIに渡す材料（成果物）が揃っていないと、思惑どおりにはならない、ということです。レーンを歩かせれば、その主体が何者かを説明する主体の一覧が欲しくなります。業務ルールと業務の流れ・ユースケースが整合しているかを見ようとすれば、突き合わせる業務ルールそのものが要ります。何が足りないかは、歩かせてみると分かります。

辿れる状態で回す

【広げる】は、成果物どうしの参照が辿れる状態（トレーサビリティがある状態）で回すと効きます。参照は書き手が保ち、節目にAIなどで全体を確かめます（【たたく】の章とADRの台帳の章で見たとおりです）。参照が途切れたままだと、返ってくるのは「読み取れない」の山になります。ただし、参照が揃う前でもシミュレーションは回せます。導入の初期は、ここから始められます。

参照が辿れれば、歩かせる前に、参照に沿って意味が噛み合っているかも見られます。「このタスクの事後条件と、次のタスクの開始条件」「この業務ルールと、それを実現するはずのユースケース」のように、照らす相手が参照で決まっている問いです（意味のペア照合）。問いと歯止めは、次の章のレンズのものをそのまま使います。照らす相手が決まらないもの、つまり書かれていないものには、シナリオを歩かせないと届きません。

混ぜると、照合の機械的な気づきばかりが積み上がり、シミュレーションの気づきが埋もれます。