現場導入のための要件定義

Ch.1 ベンダーに正確に伝える

RFP・要件定義書の書き方。機能要件は「ユースケース×CRUD」で表現し、非機能要件は「性能・可用性・セキュリティ・運用」を漏らさない。曖昧な日本語表現を避け、「Yes/Noで判定できる粒度」まで分解する。

Ch.2 現場導入のための要件定義

ベンダー視点だけで書くと、現場で「こんなはずじゃなかった」が起きる。これを防ぐ俯瞰ツールが3つ。

• ─CRUD図 — 各画面で誰がC/R/U/Dできるかをマトリクス化
• ─ステータス遷移図 — 業務フロー上の状態と遷移条件を全部洗う
• ─操作可能期間 — 締め後／月次後／年度跨ぎでの操作可否

「機能要件＝TOBE」の罠

「機能要件」と聞くと画面と項目を書きがちだが、機能要件はTOBE業務フローそのもの。画面・項目はTOBEを実装する手段でしかない。TOBEから逃げて「画面イメージ」を作り始めると、現場で「使えない」が起きる。要件定義の出発点は常にTOBE業務フロー。

AI組み込み時の非機能要件

AI機能は「動けば良い」では済まない。次の4点を要件として明文化する。曖昧なまま走ると、運用後に「精度が低い」「説明できない」で業務が止まる。

• ─精度の許容範囲（適合率・再現率・誤検知時の業務影響）
• ─誤判定時の業務フロー（人間判断への戻し経路を必ず描く）
• ─説明責任（なぜその判断になったかを業務担当者に示せるか）
• ─再学習サイクル（モデル更新の頻度／検証フロー／ロールバック条件）

ROIフェーズ分け

要件を全部一気に作るとROIが悪い。パレート観点で「効くもの上位2割」を Phase 1、残りを Phase 2 に分ける。Phase 1の効果検証→Phase 2の優先順位再考、という順で進めると、現場合意も取りやすい。

現場で頻発する3大忘却

実プロジェクトで「要件定義の最終レビュー時に必ず通読」している抜け漏れカタログから、特に頻発する3つ。これを書いていないと、本稼働後に必ず炎上する。

• ─マスタメンテナンス機能 — 「仕入先マスタが追加できない」「商品マスタの更新は誰が？」が本稼働後に問題化。各マスタについて誰が／どんな画面で／C・U・Dできるかを要件に書く
• ─データ移行要件 — 本稼働直前に「過去データはどうする？」でリリース延期。移行対象一覧／いつ・どうやって・誰が／検証期間（最低1週間）を要件に
• ─印刷・帳票出力 — 本稼働後に「監査用にA4で出したい」「請求書フォーマットで」が要求。画面操作のみ想定せず、紙ベース業務まで想像する

「正常系」だけ書く罠と、3つの異常系

機能要件を書くとき、「うまくいくケース」だけ想像してしまうのが最頻出失敗。各機能要件には必ず3つの異常系を考えてユースケースの Alternative Flow を書く。

• ─入力エラー（不正値／必須未入力／フォーマット違反）
• ─システムエラー（外部API断／DB障害／タイムアウト）
• ─業務上の異常（権限不足／同時実行衝突／状態遷移違反）

性能・ピーク・ログを数値化する

非機能要件を「サクサク動く」「快適に」など定性で書くと、本稼働後に「遅すぎて使えない」が起きる。次は必ず数値化する。

• ─性能：主要機能ごとに「○秒以内」を定義／ピーク時の同時アクセス数／バッチ完了時刻
• ─ピーク負荷：月初・月末・繁忙期に集中する業務を明記し、平均ではなくピーク（3倍負荷）で設計
• ─ログ・監査証跡：何の操作をログに残すか／保存期間（業界規制で7年など）／改ざん防止
• ─バックアップ：頻度（日次／週次）／RTO（復旧目標時間）／RPO（復旧目標時点）