第9章広げる ── レンズと歯止め

要件定義の4つのレンズ

要件定義では、シナリオを歩かせながら、次の4つのレンズで見ます。

レンズごとに、何を問い、何を問わないか（歯止め）を示します。歯止めを決めておかないと、指摘がきりなく増える可能性があります。

業務との整合

業務のゴールと、それを実現するはずのユースケースの目的が、意味として噛み合っているかを見ます。ゴールに要るのに、存在しない・繋がっていないユースケースはないか。業務ルールに繋がらない要件（要件の孤立）と、要件に反映されていない業務ルール（業務ルールの孤立）を、両方向から見ます。業務ルールが、「〜する」「〜を対象外とする」と事実だけを述べ、理由を欠いたまま書かれていないかも見ます。

実例

• 単価をマスタで管理しながら、受注明細で単価を上書きできる設計になっています。この裏に「客先ごとの個別値引き」という業務ルールが隠れていないか。
• ユースケースの目的が「在庫を引き当てるため」とユースケース名の言い換えになっていて、理由が空になっていないか。

境界・責任範囲

仕事の受け渡しを見ます。業務の流れでは、タスクからタスクへ仕事が渡っていきます。渡すときに、次の担当者が仕事を始められる状態が用意されているかを見ます。

たとえば、販売企画担当が送料無料の閾値を切り替えるタスクには、「キャンペーン計画に閾値が記録されている」という開始条件があります。では、この計画はどのタスクが作るのでしょうか。業務の流れのどこにも作るタスクがなければ、切り替えのタスクは始められません。

見るときは、各タスクの開始条件から手前へさかのぼります。タスクは分岐・合流するので、手前から順に追うより、「このタスクの開始条件を、どこが満たすのか」から見るほうが、抜けを拾えます。状態が用意されても、次の担当者がそれを知る手段がなければ、仕事は始まりません。知る手段が検討されているかも見ます。

もう1つ、どの担当者がどのデータにどこまで触れてよいか（権限）の線引きに、業務上の理由があるかも、このレンズで見ます。

実例

• 「在庫を引き当てる」の完了は、「出荷できる状態」を意味するか。
• 「申請者／業務申請データ／参照可・更新可／自身が作成した申請のみ、提出後は更新不可」——この線引きに業務理由があるか。

このレンズの背後には、「仕様の全域をAIと一致させることは不可能だが、責任の境界を一致させることは可能」という考え方があります。SIとは、責任の境界を合意・設計・検証する仕事だからです。

検証可能性

何をもって終わったと言えるかを見ます。業務の流れのタスクごとに、終わったとき何ができていればよいかが、読んで分かるかです。

たとえば「閾値の変更を確認する」というタスク。「確認した」とだけ書いてあると、後から、本当に終わったのかを確かめられません。「新しい閾値が、指定した日から有効になっている」と、終わったときに成り立っている状態（事後条件）で書かれていれば、確かめられます。「適切に」「必要に応じて」のように、判断を読む人に任せる言葉があるときも、確かめられません。

状態（「申請中」「承認済み」など）を並べた成果物があるなら、事後条件がその状態の名前で書けているかも見ます。状態の細かさがばらばら（「承認待ち」と「部長承認待ち」が並んでいる）だと、どこまで進んだのかが確かめられません。

終わった状態を書き直そうとすると、隠れていた業務ルールが出てくることがよくあります。「出荷を手配する」を書き直そうとすると、「在庫がある品は、受注日から3営業日以内に出荷する」という約束が出てくる、といった具合です。

実例：「希望納期を守れるか判定する」。何をもって守れると判断するのか。後で、果たされたかを確かめられる具体さになっているか。

正常系偏重

うまくいかなかった場合を見ます。あるタスクの終了が、次のタスクの開始条件を必ずしも満たさないつなぎ目で、うまくいかない場合が検討され、例外の一覧に整理されているか。例外の一覧にある例外が、業務の流れやユースケースに反映されているかも、逆向きに見ます。処理が完了・中止・失敗した後の受け取り手、後始末、並行する別のプロセスへの影響も見ます。

実例

• 欠品で在庫を引き当てられないケースは検討されたか。
• 類似の別処理では「対象0件」が例外として検討されているのに、この処理では検討されていない——この食い違いそのものを拾う。

外部設計の3つのレンズ

3つは、時間の上に並びます。

要件定義のレンズとは、正常系偏重と機能例外、境界・責任範囲とトランザクション境界が対応します。

トランザクション境界

複数の更新が、業務として同時に成立しなければならない範囲が、明確になっているかを見ます。たとえば、入金の登録と売掛金の消し込みは、片方だけが成立すると帳簿が合わなくなります。こうした範囲がどこまでか、途中で失敗したら何が巻き戻るのかが、はっきり書かれているか、です。

ここが書かれていないと、実装する側（AIでも人でも）は、更新をひとまとめにする範囲を自分で決めてしまいます。どちらも一見正しく動くので、片方だけが成立する不具合は、本番で帳簿が合わなくなるまで気づかれません。

実例：「承認と在庫引当は同時に成立する必要がある」。コミット後に非同期で走る連携は、失敗しても元の確定を巻き戻さない——その線引きが書かれているか。

機能成立性

この設計で、要件の機能が時間の中でも成立するかを見ます。自機能が参照するデータは、自機能の外で変わります。一覧に出した時点、操作する時点、確定する時点で、前提が同じとは限りません。シナリオの種の「並行して走る」「対象集合の鮮度」が、外部設計に降りてきた姿です。

実例

• 一覧に表示した対象が、確定しようとした時点では対象外になっている（他者が先に処理した、状態が進んだ、削除された）。
• マスタが改定された後に過去の伝票を再表示したとき、改定前の値を保持するのか、現在値を引くのか。

機能例外

うまくいかなかったことが、設計として明言されているか。中心にあるのは、戻せるのか、戻せないのかです。取り消し・訂正ができる設計なら、その手順と権限が書かれているか。できない設計なら、できないことが設計判断として書かれ、合意されているか。それでも戻したい場面に、運用としてどうするか（打ち消しの伝票、管理者による是正、再申請の導線）が設計に含まれているか。

戻せないこと自体は悪くありません。黙って戻せないことが問題です。書かれなかった箇所が、運用開始後に発覚します（1章）。

実例

• 確定した伝票を誤って確定した。取消機能はあるか。ないなら、打ち消しで対応するのか、管理者が直すのか、運用として諦めるのか——どれかが書かれているか。
• 外部システムへ送信済みのデータを取り消すとき、送信先との整合はどう取るのか。

どのレンズでも、AIに守らせること

AIが「ない」と言い切ると、人はそれを事実として受け取りやすくなります（「なぜ今このメソッドか」の章で見た、自信のある口調や自動で出てきたものを疑わなくなるバイアスです）。けれども実際には、別の成果物に、別の言葉で書かれていることがあります。どこを、どんな言葉で探したかが添えてあれば、人が確かめ直せます。

同じ根本原因が複数箇所に現れているなら、対象箇所を列挙する形で1つの指摘にまとめます。逆に1つの指摘文に独立した論点が混在しているなら分割します。

レンズは、育てて使う

この章のレンズと歯止めは、ベースラインです。回した結果を見て、プロジェクトや組織で育ててください（育て方は14章）。プロジェクトの業界や業務に固有の見るものを足すこともできます。