rfp-auditor

name	rfp-auditor
description	RFP要件に対する成果物のマッチ・アンマッチ・ヌケモレをチェックするスキル。プロジェクトのsource/配下の原典資料を参照し、エビデンスに基づく妥当性検証を行う。
user-invocable	true
argument-hint	<チェック対象ファイルパス> [チェックモード: full|quick|numbers]
allowed-tools	Read, Grep, Glob, Bash, Write, Task

RFP要件チェッカー

概要

本スキルは source/ 配下のRFP資料・現行システム設計書をエビデンスソースとして活用し、 プロジェクト内の成果物（コード、提案書等）とRFP要件を突合する。 単なるチェックリスト照合ではなく、原典資料を実際に参照して妥当性を検証する。

判定カテゴリ:

• マッチ（適合）: 成果物がRFP要件を充足。原典資料との整合性も確認済み
• アンマッチ（不適合）: 成果物が要件と矛盾・乖離。原典との差異を具体的に指摘
• ヌケモレ（未対応）: 要件に対応する記述/実装が存在しない

---

チェック手順（6ステップ）

Step 1: チェックリスト読み込み

references/rfp-requirements-checklist.md を読み込む。 RFPから抽出された要件項目がカテゴリ別に構造化されている。

推奨カテゴリ構成:

カテゴリ	内容
A	機能要件（必須提案範囲）
B	機能要件（オプション/参考価格範囲）
C	非機能要件
D	インターフェース要件
E	提案書構成要件
F	デモ・PoC要件
G	重要ビジネス数値

カテゴリ構成はプロジェクトのRFP構造に応じて調整すること。案件開始時に references/rfp-requirements-checklist.md を生成する手順は references/README.md を参照。

Step 2: ドキュメントカタログ参照

references/docs-catalog.md を読み込む。 このファイルには source/ 配下の全資料が分類されており、各要件IDに対応するエビデンスソースが逆引きマップとして整理されている。

案件開始時に references/docs-catalog.md を生成する手順は references/README.md を参照。

Step 3: チェック対象の特定

ユーザーが指定した成果物を特定する。指定がない場合はユーザーに確認する。

成果物タイプ	重点チェックカテゴリ	主要エビデンスソース
デモアプリ（demo-app/）	F, A（該当機能）	要件定義フォルダ, インターフェース定義フォルダ
提案書本体	E, G	RFP別紙フォルダ, 添付資料フォルダ
アーキテクチャ設計書	A, C, D	基盤設計フォルダ, インターフェース定義フォルダ, バッチ基本設計フォルダ
移行計画書	C（移行関連項目）, E	要件定義フォルダ内の移行計画書
見積書	E（費用関連項目）	RFP別紙の見積回答シート
セキュリティ関連	A（セキュリティ項目）, C（セキュリティ項目）	添付資料のセキュリティ管理規定フォルダ
インターフェース設計書	D	インターフェース定義フォルダ, 添付資料フォルダ
バッチ設計書	A（処理フロー関連）	バッチ基本設計フォルダ, ジョブ設計フォルダ, 詳細設計フォルダ
提案戦略書	E, G, A, B	RFP本紙, 添付資料フォルダ

Step 4: エビデンス収集（原典参照）

このステップが本スキルの核心。 各要件のチェック前に、docs-catalogの逆引きマップに従い、関連する原典資料を実際に読み込む。

参照手順

1. docs-catalogの逆引きマップでチェック対象の要件カテゴリに対応するファイルを特定
2. 原典資料を実際に読み込み、要件の具体的な記述・数値・仕様を把握
3. 原典の記述を引用しながら成果物との突合を行う

読み込み時の注意

• 日本語ファイル名は Read ツールで直接読み込める
• 大量ファイルがある場合はINDEXファイルやサマリファイルを優先参照
• チェック対象に応じて深さを調整:
  • 概要チェック: INDEX、一覧、サマリのみ
  • 詳細チェック: 個別定義書まで掘り下げ

カテゴリ別の重要参照パターン

チェック内容	必読ファイル	確認ポイント
IF数の妥当性	インターフェース定義フォルダ内の一覧ファイル	受信/配信のIF本数とシステム数
バッチ処理フロー	バッチ基本設計フォルダ, ジョブ設計フォルダ	フロー数、処理順序
テーブル構造	テーブル定義フォルダ内の一覧ファイル	階層構造（ステージング/加工/集計等）
セキュリティ要件	添付資料のセキュリティ管理規定フォルダ	規程への準拠
ビジネス数値	添付資料フォルダ配下のビジネス基礎数値ファイル	利用者数、データ容量、処理量
業務フロー	添付資料フォルダ配下の業務フローファイル	処理フローの詳細
見積回答	RFP別紙フォルダ配下の見積テンプレート	費目構造、回答形式

Step 5: 突合実行

各要件IDに対して以下を判定する:

1. 成果物を精読し、該当要件に対応する記述・実装を探す
2. 原典資料と突合し、成果物の記述が原典の要件を正しく反映しているか検証:
   • 数値の整合性（利用者数、データ容量、フロー数等）
   • 用語・名称の一致（システム名、IF名、テーブル名等）
   • 仕様の網羅性（全フローがカバーされているか等）
3. 以下の基準で判定:
   • マッチ: 要件を充足 + 原典との整合性確認済み
   • アンマッチ: 記述はあるが要件/原典と矛盾・乖離
   • ヌケモレ: 対応する記述/実装なし
4. 判定根拠を3点記載:
   • 成果物内の該当箇所（ファイルパス:行番号）
   • 原典資料の該当箇所（source/パス:行番号 or 引用）
   • 判定理由

Step 6: 結果出力

## RFP要件チェック結果

### チェック概要
- **チェック対象**: [成果物ファイル/ディレクトリ一覧]
- **参照した原典資料**: [実際に読み込んだsource/配下ファイル一覧]
- **チェック日時**: YYYY-MM-DD
- **チェック深度**: 概要/詳細

### サマリ
| カテゴリ | 総数 | マッチ | アンマッチ | ヌケモレ | 充足率 |
|---------|------|--------|-----------|---------|-------|
| A. 機能要件（必須） | xx | xx | xx | xx | xx% |
| ... | ... | ... | ... | ... | ... |
| **合計** | **xx** | **xx** | **xx** | **xx** | **xx%** |

### 詳細結果

#### マッチ（適合）
| 要件ID | 要件概要 | 成果物箇所 | 原典エビデンス | 備考 |
|--------|---------|-----------|--------------|------|

#### アンマッチ（不適合）
| 要件ID | 要件概要 | 問題箇所 | 原典エビデンス | 乖離内容 | 推奨対応 |
|--------|---------|---------|--------------|---------|---------|

#### ヌケモレ（未対応）
| 要件ID | 要件概要 | 優先度 | 原典で確認した要件詳細 | 推奨対応 |
|--------|---------|-------|---------------------|---------|

### エビデンスサマリ
[参照した原典資料ごとに、そこから得られた主要な事実・数値をリスト]

### 重要な発見事項
[特に注意すべきアンマッチやヌケモレをハイライト。原典との具体的な差異を記載]

### 推奨アクション
[優先度順にソートした対応推奨事項。原典のどの記述に基づく推奨かを明記]

---

チェック時の注意事項

• RFPの文脈は常にプロジェクトの提案製品の視点で解釈する
• 現行システム構成を正しく把握し、何が置き換え対象で何がスコープ外かを明確にする
• フェーズ分割がある場合、必須提案範囲とオプション/参考価格範囲を区別する
• 業界固有の要件（データ保管地域、セキュリティ規定準拠、SLA/SLO等）を特に厳しくチェック
• デモアプリの場合、プラットフォーム未接続時のモックフォールバックが実装されているか確認
• チェック対象がコードの場合、UIテキストの言語要件も確認
• 原典資料の数値を必ず確認し、成果物で引用されている数値との一致を検証
• 接続先システム名は原典のシステム略称との一致を確認

クイックチェックモード

全要件の詳細チェックが不要な場合、以下のクイック版を使用:

1. サマリチェック: INDEX/一覧ファイルのみ参照し、大枠の充足率を算出
2. 数値チェック: G（ビジネス数値）の項目のみを原典と照合
3. 差分チェック: 前回チェック結果からの変更点のみ確認