要件定義は、システム開発の最初にして、最も重要な工程の一つです。ただし、実際の現場で行われている要件定義は、教科書的に説明される、
「お客様にヒアリングして、何を作るかを決める工程」
とは少し違います。特に入札案件や大規模SI案件では、要件定義の前に、RFP、質問回答一覧、提案書、見積前提がすでに存在します。
つまり、受注後の要件定義は、白紙から要件を聞く工程ではありません。
RFPや提案内容を前提に、お客様とベンダーの認識差を潰し、設計・構築・テストできる水準まで内容を確定していく工程です。
この記事では、要件定義の実態を、業務要件だけでなく、非機能要件、RFP、スコープ、見積前提、合意形成の観点から整理していきます。
お客様の要望をそのまま作ってはいけない理由
要件定義で初心者SEが誤解しやすいことがあります。
それは、
「お客様が言ったことを、そのままシステムにすればよい」
と考えてしまうことです。
もちろん、お客様の要望を聞くことは重要です。システムは、お客様の業務課題を解決するために作るものだからです。しかし、現場ではお客様の言葉をそのまま受け取るだけでは、かなり危険です。
たとえば、お客様から次のように言われたとします。
- 止まらないシステムにしたい
- 普通に使える速度にしてほしい
- 安全にしてほしい
- 必要なログを残してほしい
- 既存システムと連携してほしい
一見すると、どれも自然な要望です。
しかし、このままでは設計できません。
「止まらない」とは、
- サーバ1台が壊れても止まらないという意味なのか
- データベース障害でも業務継続したいのか
- データセンター障害まで想定するのか
- 「普通に使える速度」とは、画面応答3秒以内なのか
- 10秒でも許容されるのか
- ピーク時でも同じ水準を求めるのか
- 「必要なログ」とは、障害調査用に数日分あればよいのか
- 監査対応で7年分必要なのか
- オンラインですぐ検索できる必要があるのか
- アーカイブ保管でよいのか
- 「既存システムと連携」とは、ファイルを受け取るだけなのか
- 文字コード変換が必要なのか
- 異常データの再取込やリカバリ手順まで必要なのか
このように、お客様の言葉は自然に聞こえても、そのままでは設計・構築・テストできる水準になっていないことが多いです。だから要件定義では、お客様の要望をそのまま受け取るのではなく、
その要望が、システムとして何を意味するのか
を具体化する必要があります。
現場の要件定義は「白紙から聞く工程」ではない
ここで、もう一つ大事な現場感があります。
要件定義というと、初心者向けの説明では、
「お客様にヒアリングして、何を作るかを決める工程」
と説明されることが多いです。これは考え方としては間違っていません。
ただし、実際のプロジェクト、特に企業向け・公共系・大規模SIの案件では、受注後の要件定義でゼロから要件を聞くわけではありません。多くの案件では、要件定義に入る前に、すでに次のようなものが存在しています。
・RFP
・質問回答一覧
・提案書
・見積書
・見積前提条件
・スコープ定義
・非機能要件の前提
・サイジング前提
・移行・運用・セキュリティの前提
RFPとは、Request for Proposal の略です。
日本語では、提案依頼書、または提案要求書と呼ばれます。
簡単にいうと、お客様がベンダーに対して、
「こういうシステムを作りたいので、提案してください」
と示す資料です。
公共案件であれば、官報公示や入札公告を経て、RFPが示されることがあります。また、大規模案件では、お客様側にコンサルティング会社や外部アドバイザーが入り、RFP作成を支援していることもあります。
そのため、RFPは一見すると、きれいに整理されているように見えます。
業務要件、非機能要件、移行方針、運用条件、セキュリティ要件などが、もっともらしく整理されていることもあります。しかし、実際の現場では、RFPに書かれている内容だけで、そのまま設計・構築・テスト・運用まで迷いなく進められるとは限りません。
ここで、実際のプロジェクトがどのような流れで要件定義まで進むのかを、ざっくり図で見てみます。
ここから先では、教科書的な「要件定義とは何か」ではなく、RFP、質問回答、提案書、見積前提をもとに、実際の現場でどう認識差を潰していくのかを具体的に見ていきます。
図のように、実際のプロジェクトでは、次のような流れで進むことが多いです。
- RFP公示・提示
- ベンダー受領・読み込み
- 質疑応答
- 提案・見積提示
- 開札・受注
- 要件定義
- ユーザー承認
つまり、要件定義は、受注後に初めてお客様の要望を聞く工程ではありません。
RFP、質問回答一覧、提案書、見積書、見積前提条件、スコープ定義、非機能要件の前提、サイジング前提、移行・運用・セキュリティの前提。
これらがすでに存在している状態で始まります。ベンダーは、RFPを受領したあと、その内容を読み込みます。そして、分からない点、曖昧な点、見積に影響する点を、質問期間中に質問します。
この質問回答は非常に重要です。
なぜなら、質問回答の内容が、その後の提案内容や見積前提に大きく影響するからです。
たとえば、RFPに、
「高い可用性を確保すること」
と書かれていたとします。
一見すると、それらしい要件に見えます。
しかし、このままでは見積も設計もできません。
- サーバ1台障害時の業務継続を求めているのか
- DB障害時の自動切替まで求めているのか
- データセンター障害まで想定しているのか
- 計画停止は許容されるのか
- 復旧時間の目標は何時間なのか
- データロスはどこまで許容されるのか
こうした点を確認しなければ、構成もコストも決まりません。
同じように、RFPに、
「ログは改ざん防止のために保護すること」
と書かれていた場合も、そのままでは設計できません。
何のログを対象にするのか。
保護するために必要な改ざん防止方法は何か。
何年分保管するのか。
オンラインで検索できる必要があるのか。
アーカイブ保管でよいのか。
監査対応でどこまで求められるのか。
こうした点を確認しないと、ディスク容量、バックアップ容量、ストレージ性能、運用コストを見積もれません。
つまり、受注前の段階で、ある程度の要件確認はすでに行われています。
そして、その質問回答を踏まえて、ベンダーは提案書を作り、見積価格を提示します。
この時点で、システム基盤であれば、すでに一定のサイジングが行われています。
たとえば、次のような前提です。
・Web/APサーバを何台にするか
・DBサーバをどの程度のスペックにするか
・CPU、メモリをどれくらい積むか
・ディスク容量をどれくらい見込むか
・ログ保管容量をどう見積もるか
・バックアップ領域をどれくらい確保するか
・冗長化構成をどこまで入れるか
・DRやバックアップサイトを含めるか
・監視、ジョブ、運用設計をどこまで含めるか
・移行作業をどこまで含めるか
・セキュリティ対策をどこまで対象にするか
これらは、すべて見積金額に直結します。
CPU、メモリ、ディスク、ネットワーク、バックアップ領域、監視製品、運用体制、移行作業量。
どれも無料ではありません。そのため、受注後の要件定義で突然、
- やっぱり全データを7年間オンライン保管したい
- データセンター障害でも止めたくない
- 外部連携先のゲートウェイやルーターまでセキュリティ対策の対象にしたい
- 既存運用でやっている手作業の補正も全部システム化してほしい
と言われると、当初の見積前提が崩れます。
ここが、現場の要件定義で非常に難しいところです。
だからこそ、受注後の要件定義では、RFP、質問回答一覧、提案書、見積前提をもとに、
お客様とベンダーの認識差を潰し、スコープを確定し、設計可能な水準まで内容を具体化し、最後にお客様と合意する
ことが重要になります。
受注後の要件定義で本当にやっていること
では、受注後の要件定義工程では何をしているのでしょうか。
実務的には、RFP、質問回答一覧、提案書、見積前提をもとに、
お客様とベンダーの認識差を潰し、設計・構築・テストできる水準まで内容を確定する
作業をしています。別の言い方をすると、受注後の要件定義は、
「要件をゼロから作る工程」
ではなく、
RFPと提案内容を前提に、認識差を潰し、スコープと前提条件を確定する工程
です。
システム基盤であれば、非機能要求グレードのようなフレームワークを使って、可用性、性能、拡張性、運用・保守性、移行性、セキュリティなどの観点を整理することがあります。
ここで重要なのは、単にテンプレートを埋めることではありません。
RFPや提案書に書かれた内容を、プロジェクトの特性に合わせてテーラリングしながら、次のようなことを確認していきます。
・今回の対象範囲はどこまでか
・提案時の前提とずれていないか
・質問回答の内容が要件に反映されているか
・お客様の期待とベンダーの見積前提に差がないか
・設計で決めるべきことは何か
・テストで確認すべきことは何か
・運用で引き継ぐべきことは何か
・スコープ外とするものは何か
・追加費用・追加期間が必要なものは何か
・最終的に誰が承認するのか
この最後の「誰が承認するのか」も重要です。
要件定義の成果物は、SE同士のメモではありません。最終的には、お客様側の業務担当者、情報システム部門、運用担当者、セキュリティ部門、場合によっては決裁権者が確認し、
「この内容で設計・構築・テストに進んでよい」
と合意するための資料です。だからこそ、受注後の要件定義では、曖昧な表現を残さず、設計できる粒度まで落とし込む必要があります。
要件定義とは、単にお客様の要望を聞く工程ではありません。
RFP、質問回答、提案書、見積前提をもとに、認識差を潰し、スコープを確定し、設計可能な水準まで内容を具体化し、最後にお客様と合意する工程です。
では、「認識差を潰す」とは、具体的に何をするのでしょうか。
一言でいえば、RFPに書かれている言葉と、実際の業務・既存システム・運用実態とのズレを確認していく作業です。RFPには、きれいな言葉で要件が書かれています。
- 既存システムと連携すること
- 現行データを移行すること
- 必要なログを保管すること
- 既存運用を踏まえること
- セキュリティを確保すること
一見すると、それらしい記載です。
しかし、現場では、この一文の裏側に大量の確認事項があります。
たとえば、「既存システムと連携すること」と書かれていた場合。
それは、単に
- ファイルを受け取ればよいという意味なのか
- 受信エラー時の再取込まで必要なのか
- 文字コード変換は必要なのか
- 外部システム側の処理完了をどう検知するのか
- ファイル件数やレコード件数の突合は必要なのか
- 異常データがあった場合、業務担当者が確認してから再実行するのか
ここまで確認しなければ、設計できません。
特に移行や外部連携では、文字コードや文字集合の問題が最後に表面化することがあります。
たとえば、RFPには「既存データを移行すること」としか書かれていない。
しかし実際に既存データを見てみると、Shift_JIS前提のクライアントで入力されたデータ、Unicode系のDB、外字、異体字、JIS2004の字形差、ベンダー独自の変換ルールが混在している。こういうことは珍しくありません。
「氏名」や「住所」は、特にトラブルが起きやすい項目です。
高橋の「髙」、崎の異体字、吉の異体字、旧字体、外字、機種依存文字。
業務担当者から見れば、
「画面に表示されているのだから、新システムでも当然表示できるでしょう」
という感覚です。
しかし、システム側から見ると、そう単純ではありません。
- クライアントはWindows
- 既存ファイルはShift_JIS
- 新システムのサーバはLinux
- DBはOracle
- アプリはUnicode前提
- 画面表示はブラウザ
- 帳票はPDF
- 外部連携先は別の文字コード
このような構成では、どこでどの文字コードに変換されるのか、どの文字を許容するのか、変換不能文字をどう扱うのかを決めておかないと、移行テストや本番切替直前で問題になります。
実際、昔のプロジェクトでは、移行データに含まれる人名・住所の文字が新システムで正しく扱えず、移行前にデータ補正や変換ルールの見直しが必要になることがありました。
これは単なる文字化けの話ではありません。
- 業務データを正しく引き継げるか
- お客様の名前を正しく表示できるか
- 帳票に正しい文字で出力できるか
- 外部システムに正しい形式で連携できるか
- 監査上、元データとの差異を説明できるか
- こうした話につながります。
つまり、RFPに「データ移行」と書かれていても、それだけでは不十分です。
要件定義では、次のようなことを確認する必要があります。
- 移行対象データは何か
- 移行元の文字コードは何か
- 新システムの文字コードは何か
- 外字や異体字をどう扱うか
- 変換不能文字が出た場合にどう補正するか
- 補正判断は誰が行うか
- 移行前後の件数・金額・コード値をどう突合するか
- 本番移行前にどこまで実データで検証するか
ここまで確認して初めて、
「現行データを移行する」
というRFP上の一文が、設計・構築・テストできる水準になります。
RFPに書いてあることが、必ずしも現場の実態とは限らない
さらに厄介なのは、RFPが必ずしも現場実態を完全に表しているとは限らないことです。
「現場の要件定義は『白紙から聞く工程』ではない」でも触れましたが、大規模案件ではコンサルティング会社などがRFP作成を支援しているケースが少なくありません。そのため、一見するときれいに整理されているように見えます。
しかし、実際に要件定義をスタートさせると、業務担当者や運用担当者から次のような話がポロポロと出てくるのが現実です。
- 「実は月末だけ手作業で補正しています
- この外部ファイルはJISだけでなくUnicodeも混ざります
- 異常データは一度止めて、担当者が確認してから再取込しています
- この連携は年1回しか動きませんが、止まるとかなり困ります
- セキュリティ対策は新システムだけでなく、接続先のゲートウェイも含めて考えてほしい
RFPには「既存システムと連携する」としか書かれていない。
しかし実態としては、文字コード変換、例外データ処理、再取込手順、運用確認、エラー通知まで必要だった。
こういうことは普通に起こります。
RFPと現場実態にズレがある場合に重要なのは、
それは今回の契約・見積範囲に含まれているのか
を冷静に確認することです。
お客様の要望だからといって、すべてを無条件に受け入れると、プロジェクトは簡単に赤字化します。逆に、すべてを「スコープ外です」と突っぱねるだけでは、信頼関係を失います。
だから要件定義では、次の観点で整理していきます。
- RFPに書かれているか
- 質問回答で確認済みか
- 提案書に含めているか
- 見積前提に入っているか
- 契約範囲に含まれるか
- 追加要件として扱うべきか
- 代替案で対応できるか
- 運用回避で許容できるか
ここが、要件定義の腕の見せ所です。
余談ですが、就職活動中の人や初級SE向けに「💡 Column」を紹介します。
「💡 Column」ITコンサルとSIerのSEは、似ているようで違う
就職活動中の人や初級SEは、ITコンサルとSIerのSEを同じような職種として見ていることがあります。
どちらもシステム開発に関わります。どちらもお客様と話します。どちらも要件定義に関わることがあります。ただし、実際の立ち位置は少し違います。
ITコンサルは、お客様側に近い立場で入り、業務改革、システム化構想、IT投資方針、グランドデザインを整理する役割を担うことが多いです。
一方、SIerのSEは、RFP、提案書、見積前提、契約範囲をもとに、要件を設計・構築・テストできる水準まで具体化し、実際にシステムとして成立させる役割が中心になります。ここを誤解すると、就職後にギャップが出ます。
もっと経営に近い仕事だと思っていた。業務改革の提案が中心だと思っていた。実際には設計書、テスト、調整、レビューが多かった
というミスマッチは珍しくありません。
どちらが上、どちらが下という話ではありません。ITコンサルは、システム化の方向性を描く。SIerのSEは、その要件を現実のシステムとして成立させる。役割が違います。
この違いは、就職前に知っておいたほうがよい重要な話です。
「お客様の言うままではNG」の本当の意味
ここまでを踏まえると、
お客様の言うままではNG
という言葉の意味が少し変わって見えるはずです。
これは、お客様の要望を無視するという意味ではありません。
むしろ逆です。
お客様の要望を本当に実現するために、次のことを行います。
・曖昧な言葉を具体化する
・RFPとの整合性を見る
・提案書・見積前提と照合する
・スコープを明確にする
・非機能要件として定義する
・設計・テスト・運用に落とせる粒度にする
・追加要件なら追加要件として扱う
・必要なら代替案を提示する
たとえば、お客様が、
「止まらないようにしてほしい」
と言ったとします。
これに対して、
「わかりました。止まらないようにします」
で終わらせるのは危険です。
実務では、次のように確認します。
- サーバ1台の障害時も業務継続するという意味でしょうか
- データベース障害時は、手動切替でも許容されますか
- 計画停止は許容されますか
- 復旧時間の目標は1時間以内でよいですか
- データロスはどこまで許容されますか
- この水準は、提案時の構成で実現できる範囲です
- データセンター障害まで対象にする場合は、別途DR構成が必要です
このように、要望をシステムの言葉に翻訳していきます。
これが要件定義です。
特にシステム基盤では、曖昧な要望をそのまま受けると、CPU、メモリ、ディスク、ネットワーク、冗長化、バックアップ、監視、運用体制、テスト計画、費用にすべて影響します。
だからこそ、要件定義では、
お客様の言葉をそのまま作るのではなく、システムとして実現可能な条件に具体化する
ことが重要です。
初心者SEが要件定義で見るべきポイント
初心者SEが要件定義に参加すると、最初は会議の内容が難しく感じると思います。
- 業務用語も出ます
- システム用語も出ます
- お客様の要望も出ます
- ベンダー側の制約も出ます
- 契約や見積前提の話も出ます
その中で、まず意識してほしいのは次の3つです。
1. 曖昧な言葉をそのままにしない
要件定義では、曖昧な言葉がたくさん出ます。
- 早く
- 簡単に
- 使いやすく
- 止まらない
- 安全に
- 既存どおり
- 必要な範囲で
- 適切に
- 原則として
- 柔軟に対応
こうした言葉が出たら、注意してください。
そのまま設計に進むと、後で解釈が分かれます。
- 「早く」とは何秒なのか
- 「止まらない」とは、どの障害まで想定するのか
- 「既存どおり」とは、現行システムのどの仕様を指しているのか
- 「必要な範囲」とは、誰が判断するのか
- こうした曖昧な言葉を放置しないことが、要件定義では非常に重要です
初心者SEでも、会議の中でこうした表現に気づけるようになると、要件定義の理解は一段深くなります。
2. 数字に落とせるものは数字に落とす
要件は、できるだけ数字に落とすことが重要です。
たとえば、
- 「早く表示する」ではなく、
- 「通常時は3秒以内に表示する」
- 「多くのユーザーが使う」ではなく、
- 「同時利用者数は1,000人を想定する」
- 「長期間ログを保管する」ではなく、
- 「操作ログは7年間保管する」
- 「早く復旧する」ではなく、
- 「障害検知から1時間以内の復旧を目標とする
このように数字に落とすことで、設計、見積、テストができるようになります。逆に言えば、数字に落ちていない要件は、後工程で揉めやすいです。特にシステム基盤では、数字がないとサイジングできません。
CPU、メモリ、ディスク容量、バックアップ容量、ネットワーク帯域、ログ保管容量、監視閾値、復旧時間目標などは、すべて設計や見積に影響します。
だからこそ、
- なんとなく早く
- できるだけ止めない
- 必要な分だけ残す
という表現を、そのままにしてはいけません。
3. 誰が決める話なのかを意識する
要件定義では、すべてをSEだけで決めるわけではありません。
- 業務担当者が決めること
- 情報システム部門が決めること
- 運用担当者が決めること
- セキュリティ部門が決めること
- 監査部門に確認すべきこと
- ベンダーが技術提案すべきこと
- 契約や予算の範囲で判断すべきこと
これらが混ざります。
たとえば、画面項目や承認ルートは、お客様である業務担当者の判断が必要です。
一方、サーバ構成や冗長化方式は、基盤担当の技術提案が必要です。
ログ保管期間は、監査部門やセキュリティ部門の確認が必要になることがあります。
運用手順は、実際に運用する担当者の確認が必要です。
つまり、要件定義では、
- これは誰が決める話なのか
- 誰に確認すれば合意できるのか
- 最終的な決裁権者は誰なのか
を意識することが大切です。
これができると、会議で出た宿題や確認事項の意味が分かりやすくなります。要件定義は、単に要望を聞く場ではありません。
関係者の認識をそろえ、設計できる粒度まで内容を具体化し、最終的に合意するための工程です。
要件定義の成果物は「合意の記録」である
要件定義の成果物は、単なる説明資料ではありません。
お客様とベンダーが、
- 今回のシステムでは、ここまでを実現する
- この条件で設計・構築・テストを進める
- この範囲は今回のスコープに含める
- この範囲は対象外、または追加要件として扱う
と合意した記録です。
だからこそ、要件定義書には曖昧な表現を残してはいけません。
- できるだけ早く
- 必要に応じて対応
- 原則として実施
- 既存どおり
- 適切に設定
こうした表現は、後工程で解釈が分かれやすいです。
- 設計者は、要件定義書を見て設計します
- 開発者は、要件定義や設計を見て実装します
- テスト担当者は、要件をもとに確認観点を作ります
- 運用担当者は、要件と設計をもとに手順を作ります
- 要件定義が曖昧だと、その曖昧さが後工程にそのまま流れていきます
だから要件定義の成果物は、
「何となく決めたことのメモ」
ではありません。
プロジェクト関係者が同じ前提で先に進むための、合意の記録です。
まとめ：要件定義は認識差を潰す工程である
要件定義で曖昧さを残すと、その曖昧さは後工程にそのまま流れ込みます。
設計で迷い、構築で前提が崩れ、テストで確認漏れが出る。最終的には、コストの増加と責任の押しつけ合いに行き着きます。
だからこそ、要件定義はシステム開発の最初にして、最も重要な工程の一つです。
今回の記事では、要件定義を「白紙から要望を聞く工程」ではなく、RFP、質問回答、提案書、見積前提をもとに認識差を潰していく工程として整理しました。
要件定義の見え方が、少しでも立体的になればうれしいです。
次の記事では、要件定義で必ず出てくる機能要件と非機能要件の違いを整理しています。「機能が動くこと」と「本番で使えること」がなぜ違うのか、現場目線で解説しています。
機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。
コメント