要件監査とは何か：カバレッジと逸脱、そして実例で見る仕組み

「何を作ると合意したのか」がなぜ難しい問いなのか

どのチームも、開いているタスクの数は答えられます。しかし、要件ごとに、開いているタスクを合わせれば約束したものになるのかを答えられるチームはごくわずかです。2つの事実は別の場所にあります。要件は、数か月前に書かれたPRD、提案書、契約書、Notionのページにあります。作業はトラッカーにあり、拾った人が名前を付けた課題に分割されています。誰も両者を結びつけず、その隙間は顧客、ローンチ、新しいメンバーが見つけるまで見えません。

隙間は3つの形で広がります。

• 抜け落ち。 要件は合意されたが、作業に変換されなかった。バックログにないので、どのボードにも遅れとして表示されない。
• 静かな書き換え。 承認後に要件が編集された。たいていは作りやすいものに合わせるためで、生きている文書は「満たしている」と言い、元の文言は消えている。
• 静かな削除。 要件が削除された。文書は短くなり、誰もそうすべきだと決めていない。

要件監査は、この3つすべてを見えるようにします。用語集のエントリに正式な定義があります。要件トレーサビリティ監査、要件カバレッジと呼ばれることもあります。

3つの要素：ベースライン、カバレッジ、逸脱

ベースライン。 要件ベースラインは、承認された時点の要件を凍結し番号を付けた写しです。各要件の識別子、文言、優先度、受け入れ基準を含みます。生きている文書は変わり続けますが、ベースラインは変わりません。ベースラインのエントリで実践をより詳しく扱っています。ベースラインがなければ監査の対象がありません。残っている唯一の要件は、すでに逸脱したものだからです。

カバレッジ。 ベースラインの各要件について、裏付ける作業はどういう状態か。有用な監査は少なくとも次の状態を区別します。

タスクがすべてキャンセルされた要件は、3回試みられていても作業なしであり、正直な監査は両方を述べます。

逸脱。 逸脱はベースラインの文言と今日の文言を比較します。凍結後に要件の文言が変わっていれば、監査はそれを示し、両方のバージョンを表示します。ベースラインを評価すると言いながら新しい文言に対してカバレッジを報告するのは誤解を招くため、良い監査は常に凍結した文言に対して測り、その隣に生きている文言を示します。

実例：PRDの記述と、出荷されたものの違い

小さく現実的なケースです。4人のチームが顧客ポータルのPRDに14件の要件で合意し、9月2日にベースライン1として凍結します。ローンチは10月30日。その2週間前に、誰かが監査を実行します。

11件は進行中か完了。残りの3件はそうではありません。

• REQ-006「顧客は請求書をCSVとPDFでエクスポートできる」。 カバレッジ：作業完了。逸脱：あり。生きている文言は「顧客は請求書をCSVでエクスポートできる」になっています。開発者がPDFライブラリを扱いにくいと感じた時点でPDFの半分は落とされ、要件はそれに合わせて編集されました。PDFを求めた顧客には誰も伝えていません。
• REQ-009「顧客が請求書に異議を申し立てると管理者にメールが届く」。 カバレッジ：作業なし。合意はあったが、誰も課題を起票せず、バックログに行がありません。ボードは存在する課題しか知らないので、すべて緑のままでした。
• REQ-013「ローンチ時にポータルは2言語に対応する」。 カバレッジ：その後削除。3週目にチャットで行われたスコープの話し合いの中で、生きているPRDから外されました。決定は正しかったかもしれませんが、記録は誰も見つけられないメッセージです。

これらはどれもスプリントレビューには現れません。REQ-006はデモされ、完成して見えました。REQ-009はタスクとして存在したことがありません。REQ-013は静かに要件でなくなっていました。監査は3つの見えない隙間を3つの決定に変えました。REQ-009の作業を起票する、REQ-006を復元するか正式に再交渉する、REQ-013の決定を書き残してベースライン2に反映する、です。

監査がモデルによるプロジェクトの読み取りではなく、記録から計算されるべき理由もここにあります。言語モデルに「REQ-009はカバーされているか」と尋ねると、メール通知に似たものを探し、領収書に関する関連課題を見つけてしまうかもしれません。要件と課題の明示的なリンクから計算したカバレッジは、端的に「作業なし」と答えます。それがチームに必要な答えでした。

要件監査とコードスキャン、コードレビューの違い

「監査」と聞くと、スキャナーがソースコードを読む様子を思い浮かべる人が多いでしょう。それは別の活動で、別の問いに答えるものです。

3つは互いの代わりになりません。すべてのスキャンを通過したコードベースでも、顧客が対価を払った機能が欠けていることはあります。すべての要件がカバーされている要件監査でも、セキュリティホールを出荷することはあります。両方を気にするチームは両方を行います。

要件監査を正直に保つ注意点が2つあります。第一に、「作業完了」は「要件充足」ではありません。完了した課題は誰かがタスクを終えたことを示すだけで、結果が受け入れ基準を満たすことの証明ではありません。確認は人がする必要があります。第二に、監査の質はリンクの質で決まります。課題が要件に紐づいていなければ、すべての要件が「作業なし」と表示され、役に立ちません。リンク付けは先行コストであり、それが監査を可能にするコストでもあります。

要件監査を手作業で行う方法

ツールは必要ありません。必要なのは規律とスプレッドシートです。

1. ベースラインを凍結する。 承認された要件をシートに写し、行ごとに安定したID（REQ-001、REQ-002）、正確な文言、優先度、受け入れ基準を記録します。日付と承認者を記録します。このシートは二度と編集しません。
2. 作業を要件に紐づける。 トラッカーで、すべての課題にそれが仕える要件を示すフィールドかラベルを付けます。要件IDのない新しい作業は、バグか、雑務か、スコープの肥大化です。どれかを決めます。
3. カバレッジを計算する。 REQの各行について、課題とその状態を列挙します。上の表から状態を割り当てます。まず作業なしの行を数えます。そのリストが監査の主な発見です。
4. 逸脱を確認する。 生きている要件文書を凍結したシートの隣に置きます。文言が異なる行と、生きている版に存在しない行に印を付けます。
5. 決定を書く。 隙間ごとに、作業を起票する、再交渉する、正式に取り下げる、のいずれかを選びます。取り下げたものは理由とともに記録し、ベースライン2を凍結します。
6. 節目ごとに繰り返す。 顧客レビュー、ローンチ、請求、引き継ぎの前に。ほとんどの小さなチームには月1回で十分です。

手作業版は機能します。弱点はステップ2です。人が忙しくなるとリンクはすぐに劣化し、誰も更新しないシートは誰も信頼しない監査を生みます。

ツールはどうするか、Atrixは何をするか

規制産業向けの要件管理ツールのいくつかは、何十年も前からトレーサビリティを提供しています。通常は要件とテスト、タスクのマトリクスという形です。航空宇宙、医療、自動車のチーム向けに作られ、価格もそれに応じたものです。

小さなプロダクトチームにとって現実的なのは、要件と課題を同じ場所に置き、リンクを維持してくれるトラッカーです。これは私たちが自分たちのプロジェクトのためにAtrixに組み込んだもので、何をするのかを正確に述べておく価値があります。エージェントのDevelop実行がブリーフから要件を書き、あなたが編集して承認し、Auditモードがベースラインを凍結します。以後、監査はベースラインの各要件について上の5つの状態を報告し、文言が変わっていれば逸脱フラグと生きている文言を示します。すべての状態はモデルの判断ではなく行から計算されるので、監査はAI実行を消費せず、2回実行しても同じ答えを返します。GitHubとVercelのプロジェクトを連携すると、リポジトリとデプロイのシグナルが隣に加わります。

何をしないかも同じくらい重要です。Atrixはコードをスキャンせず、静的解析を実行せず、脆弱性を見つけません。機能ページにそう書いています。コード監査が必要なら、それは別のサービスで、私たちの側では製品ではなく代理店の人間の監査者が担います。作ったものが合意と一致しているかを知りたいなら、それが製品の仕事です。

FAQ

要件監査とコード監査の違いは何ですか

要件監査は合意した要件を存在する作業と比較し、カバレッジと逸脱を報告します。コード監査はソースコードを基準に照らしてバグ、セキュリティ、品質を調べます。前者は「合意したものを作ったか」に、後者は「コードは健全か」に答えます。どちらも相手の代わりにはなりません。

要件トレーサビリティとは何ですか

トレーサビリティは、各要件からそれを実装する作業、テスト、コードへのリンクと、その逆方向のリンクの集まりです。要件監査はこれに依存します。課題から要件へのリンクがなければ、カバレッジは計算できません。

スコープの逸脱とは何ですか

スコープの逸脱、または要件の逸脱は、明示的な決定なしにプロジェクトが届けるべきものが徐々に変わることです。実装に合わせて要件が書き換えられる、静かに落とされる、承認なしに追加される、などです。監査は凍結したベースラインと生きている要件を比較して検出します。

要件はどのくらいの頻度で監査すべきですか

固定の暦ではなく節目ごとに。顧客レビュー、ローンチ、引き継ぎ、大きな請求の前です。リンクを最新に保っているチームは数分でオンデマンドに監査でき、手作業のチームはたいてい月1回が限度です。

タスクが完了していれば要件は満たされていますか

いいえ。完了したタスクは誰かが作業を終えたことを示すだけで、結果が受け入れ基準を満たすことは示しません。良い監査はこの状態を「作業完了」とラベル付けし、基準に照らした検証は人に委ねます。

AIは要件監査を実行できますか

AIは要件を書いて洗練でき、作業を要件に紐づける手助けもできます。監査そのものは記録から計算すべきです。何かが「カバーされている」かについてのモデルの意見は実行ごとに変わり、顧客に対して弁護できないからです。Atrixは要件の作成にエージェントを使い、監査の計算には素のデータを使います。

次のステップ

まず要件監査の用語集エントリで定義と状態を確認し、最初のベースラインを凍結してください。リンクと監査の維持を任せたいなら、Atrixの要件監査があなた自身の課題から実行します。