こんにちは。Lamb です。
「これもやってくれると思っていた」は、構築後に聞くとかなり重い言葉です。
インフラの要件定義では、必要な機能を聞き出すことに意識が向きがちです。
でも、後工程で本当に効いてくるのは、機能の数よりも「どこまでやるか」「何を優先するか」「いつ、誰が決めるか」の共通認識です。
私は、認証機能と運用範囲の認識が顧客とずれ、構築以降に追加対応が必要になった経験があります。
この記事では、そのときの経験をもとに、対策や考え方と、要件定義の最初に確認したい7項目を実務で使える形に整理します。
➕️ 結論：最初に確認したい7項目
| # | 確認項目 | 合意したいこと |
|---|---|---|
| 1 | 目的と成功条件 | 何のための案件で、何をもって成功とするか |
| 2 | スコープ | 新規・変更・継続・対象外の境界 |
| 3 | 現行環境と依存関係 | 既存構成、契約、規程、他チームとの関係 |
| 4 | 要望への対応境界 | 対応・一部対応・非対応・＋α |
| 5 | 優先順位 | 必須か、代替可能か、見送り可能か |
| 6 | 運用・非機能要件 | 構築後に誰が、どの水準で運用するか |
| 7 | マイルストーンと意思決定者 | いつ、誰が、何を確認して次へ進むか |
この7項目を設計から運用まで一続きで合意します。特に重要なのが、「新しく作る」「変更する」「そのまま使う」「やらない」を同じ表に置くことです。やることだけでなく、やらないことにも×を付けます。
☑️ なぜ、案件後半になるほど効いてくるのか
案件の初期段階では、ここまで整理しても作業量は大きく変わらないかもしれません。
しかし構築以降は、少しの遅れが致命的になりやすくなります。以前に合意した内容も、時間がたつほど曖昧になります。
要件の境界が見えないまま進むと、追加要望を既存スコープとして受け入れ、スコープクリープが起きます。構築後に「これもやってくれると思っていた」と判明すれば、それまでに積み上げた品質・コスト・納期、つまりQCDへの影響は小さくありません。
初期に境界を整理する価値は、要件定義を早く終えることではなく、後半でリスクが表面化する前に見つけることにあります。
☑️ 実際に起きた顧客との認識ずれ
ある案件では、要望されたコストの範囲では細やかな認証機能まで実装することが難しく、認証・認可も運用整備も必要最低限に留めていました。
一方で顧客側は、「認証機能が実装され、運用も滞りなく行える状態になる」と認識していました。
どちらか一方の理解不足というより、次の境界を合意物として残せていなかったことが問題でした。
- 何を実装するのか
- 今回は実装しない機能は何か
- 運用開始までに、誰がどこまで整備するのか
- 顧客要望のうち、満たすもの、満たさないもの、追加対応になるものは何か
認識のずれが表面化した後は、クラッシングを実行し、後続タスクのマイルストーンとクリティカルパスを調整しました。
クラッシングは、コストとスケジュールのトレードオフを見ながら期間を短縮する方法です。人員追加や残業などで短縮を図るため、一般的にコストが増えます。
一方、ファストトラッキングは、本来順番に行う作業を並行化する方法です。期間短縮を期待できる一方で、手戻りやリスクが増えやすくなります。
参考：PMI「Managing crashed and fast-tracked projects」
いずれも、認識のずれを埋めるために最初から使いたい打ち手ではありません。
☑️ 1. 目的と成功条件
「何を導入するか」の前に、なぜ導入するか、何をもって成功とするかを合わせます。
- 解消したい業務課題
- 必須となる期限
- 成功を判断する指標
- 品質・コスト・納期のうち、最優先するもの
目的が曖昧だと、個別要望の採否を判断できません。
☑️ 2. スコープ
スコープは、やることだけを書いても不十分です。設計から運用までを通して、次の4区分で整理します。
| 区分 | 意味 | 記載例 |
|---|---|---|
| 新規 | 今回、新しく開発・構築する | 新認証基盤の導入 |
| 変更 | 既存から変更する | パスワードポリシーの変更 |
| 継続 | 既存のまま利用する | 現行の監視通知先 |
| 対象外 | 今回は実施しない | 高度な権限管理、24時間運用 |
役割分担も同じです。担当する項目へ○、担当しない項目へ×を付けます。
空欄は後で都合よく解釈される余地になります。決まっていないなら「未定」と書き、決定期限と決定者を添えます。
☑️ 3. 現行環境と依存関係
現行の構成、制約、契約、関連システムを確認します。
- ネットワーク、サーバー、クラウド、認証基盤
- 既存システムとの接続
- ライセンスや保守契約
- セキュリティ規程
- 他チームの作業や承認への依存
要件単体では実現可能でも、既存環境や外部作業がボトルネックになることがあります。
☑️ 4. 要望への対応境界
顧客のニーズや要望を、回答の状態まで含めて一覧化します。
| 要望 | 今回の対応 | 判定 | 補足 |
|---|---|---|---|
| 基本的なログイン | 必要最低限の認証を実装 | 対応 | 対象ユーザーを明記 |
| 細やかな権限制御 | 今回は実装しない | 非対応 | 将来拡張候補 |
| 運用手順 | 基本手順のみ作成 | 一部対応 | 24時間運用は対象外 |
| 追加の監査機能 | 別見積もり | 提案 | 費用と納期を再提示 |
「対応する・しない・一部対応・提案」を分けることで、同じ言葉を別の粒度で理解する事故を減らせます。
☑️ 5. 優先順位
必要機能は、要件書の中で優先度を明示します。
- 高：今回の目的達成に必須。満たせない場合は案件判断が必要
- 中：重要だが、代替策や次期対応を検討できる
- 低：余力があれば対応。納期やコストを圧迫するなら見送る
すべてを「重要」にすると、遅延時に何も選べません。優先順位は、平常時の並び順ではなく、リスク発生時の判断材料です。
☑️ 6. 運用・非機能要件
構築物だけでなく、構築後に誰がどう使い続けるかを決めます。
- 可用性、性能、バックアップ、監視
- 障害時の連絡先と対応時間
- アカウント発行、権限変更、棚卸し
- 手順書、教育、引き継ぎ
- 保守範囲と問い合わせ窓口
認証やセキュリティの判断は、案件内の合意だけで完結させず、組織の規程や専門担当者の確認につなげます。
☑️ 7. マイルストーンと意思決定者
「いつまでに何を終えるか」だけでなく、「誰が、何を確認し、どの状態なら次へ進むか」を合わせます。
マイルストーンは、一度決めて終わりではありません。クローズまで定期的に棚卸しと読み合わせを行い、自分たちの担当範囲だけでなく、案件全体の進捗とずれを確認します。
- 要件確定日
- 設計レビュー日
- 顧客確認・承認日
- 構築開始条件
- テスト完了条件
- 運用引き継ぎ条件
- 変更時の決裁者
これにより、後半で小さな遅れがクリティカルパスへ波及する前に、優先順位や順序を調整しやすくなります。
☑️ そのまま使える確認チェックリスト
- 目的と成功条件を一文で説明できる
- 新規・変更・継続・対象外を区分した
- やらないことに×を付けた
- 顧客要望ごとに、対応・一部対応・非対応・提案（＋α）を示した
- 必要機能に高・中・低の優先度を付けた
- 運用開始後の担当と作業を決めた
- マイルストーン、完了条件、意思決定者を決めた
- 定期的な棚卸しと読み合わせの場を設定した
- 変更がQCDとクリティカルパスへ与える影響を確認した
☑️ まとめ
要件定義の目的は、要望を漏れなく並べることではありません。案件の最後まで同じ境界と優先順位で判断できる状態を作ることです。
初期の作業量は大きく変わらなくても、案件後半で合意が曖昧になったとき、小さな遅れが重大になったときに効いてきます。
リスクが発生してから追加コストで押し込むのではなく、発生前に見つけて調整する。そのために、やることとやらないこと、優先順位、要望への回答、マイルストーンを見える形で残しておきます。
次は、基本設計書レビューで確認したい7つの観点で、要件定義の内容を設計・運用・障害対応へつなげる方法を整理します。