要件定義
このノートの問いがそのまま復習カードになり、忘れかけたころに出題されます。
シラバス Ver.6.5 の小分類 23「要件定義」（大分類 3：システム戦略／中分類 7：システム企画）。
2026-08-05 にシラバス本文と突合済み。
0. 何を押さえるか
システムに何を求めるかを、作る前に言葉にする工程です。
シラバスでこの小分類には用語例が置かれておらず、
問われるのは考え方と順序です。
最重要は機能要件と非機能要件の区別です。
| 何を定めるか | 例 | |
|---|---|---|
| 機能要件 | システムが何をするか | 受注を登録する、請求書を出力する |
| 非機能要件 | どのように動くか | 3 秒以内に応答する、24 時間動く、10 年分保存する |
非機能要件は書き落とされやすく、しかも後から直すのが最も高くつきます。
「動くけれど遅くて使えない」は、機能要件だけを満たした結果として起きます。
1. 業務要件定義の進め方
根拠: シラバス 3-7-23
要件定義は誰が主体になって行うか？
利用部門（業務を実際に行う人）が主体。
情報システム部門やベンダーは支援する側。
何が必要かを一番よく知っているのは現場だからで、
作る側が決めると「作れるもの」に業務が引きずられる。
ただし現場は「今のやり方」を前提に語りがちなので、
そのまま写すと現行業務の問題点ごとシステム化してしまう。
要件定義の進め方を順に説明せよ。
- 利用者の要求を調査する（ヒアリング・アンケート・現場観察）
- 調査内容を分析する（要望と、その背景にある本当の課題を分ける）
- 現行業務を分析する（今どうやっているか、どこに無駄があるか）
- 業務要件を定義する（システム化後の業務の姿を決める）
- 機能要件・非機能要件を定義する
- 要件を合意する（利用部門・情報システム部門・経営で確認する）
合意まで含めて要件定義。 書いただけで確認していなければ、
後から「そんなつもりではなかった」になる。
機能要件と非機能要件の違いは？
| 何を定めるか | |
|---|---|
| 機能要件 | システムが何をするか（業務上必要な処理・データ・帳票） |
| 非機能要件 | どのように動くか（性能・可用性・拡張性・セキュリティ・運用のしやすさ） |
非機能要件を落とすと、動くが使えないものができる。
しかも性能や可用性は構造に関わるので、後から直すと作り直しに近くなる。
要件定義で「現行業務の分析」をするのはなぜか？
今のやり方をそのまま写さないため。
現場の要望は「今の作業を楽にしてほしい」という形で出るが、
その作業自体が不要かもしれない。
現行を分析してなぜその手順があるのかを明らかにし、
残すもの・やめるもの・変えるものを決める。
これをせずに要件をまとめると、無駄な業務ごと自動化することになる。
要件の合意は、なぜ文書で残す必要があるか？
後の工程すべてが、この文書を前提に進むから。
設計・開発・テストは要件定義の内容が正しいものとして進む。
口頭の了解しか無いと、完成後に認識の違いが表面化し、
作り直しの費用と責任の所在が争いになる。
調達の際には、この文書が提案依頼書（RFP）の中身になる。