要件定義は「お客様にヒアリングして、何を作るかを決める工程」と説明されることがあります。
ただし、特に入札案件や大規模SIでは、それだけではありません。受注する前に、すでにRFP、質問回答一覧、提案書、見積書、見積前提条件などが存在しているからです。
つまり、受注後の要件定義は白紙から要望を聞く工程ではありません。
RFPや提案内容を前提に、お客様とベンダーの認識差を確認し、スコープを確定し、設計・構築・テストできる水準まで具体化して合意する工程です。
この記事では、RFP・質問回答・見積前提を踏まえ、認識差を潰しながらスコープと責任分界を確定する要件定義の実務を、3つの失敗事例とともに整理します。
お客様の要望をそのまま作ってはいけない
要件定義で初心者SEが誤解しやすいのが、
「お客様が言ったことを、そのままシステムにすればよい」
という考え方です。
もちろん、お客様の要望を聞くことは重要です。
しかし、たとえば次のような要望が出たとします。
止まらないシステムにしたい
普通に使える速度にしてほしい
安全にしてほしい
必要なログを残してほしい
既存システムと連携してほしい
一見すると自然な要望ですが、このままでは設計できません。
「止まらない」とは、サーバ1台の障害までなのか。データベース障害でも業務継続するのか。データセンター障害まで想定するのか。
「普通に使える速度」とは、画面応答3秒以内なのか、10秒でも許容されるのか。ピーク時にも同じ性能を求めるのか。
「必要なログ」とは、障害調査用なのか、監査用なのか。数日保存すればよいのか、7年間必要なのか。
「既存システムと連携する」とは、ファイルを受け取るだけなのか。エラー時の再取込、文字コード変換、件数突合、リカバリまで必要なのか。
要件定義では、こうした言葉を、
システムとして何を意味するのか
まで具体化します。
現場の要件定義は「白紙から聞く工程」ではない
企業向け・公共系・大規模SI案件では、要件定義に入る前に、すでに多くの前提があります。
たとえば、
RFP
質問回答一覧
提案書
見積書
見積前提条件
スコープ定義
非機能要件の前提
サイジング前提
移行・運用・セキュリティの前提
などです。
RFP（Request for Proposal：提案依頼書）は、お客様がベンダーに対して、
「こういうシステムを作りたいので、提案してください」
と示す資料です。
RFPに書かれる主な内容
ベンダーはRFPを読み、曖昧な点や見積に影響する点を質問します。その質問回答を前提に提案書を作り、構成を検討し、価格を提示します。
そのため、実際の流れは概ね次のようになります。
RFP提示
→ 質疑応答
→ 提案・見積
→ 受注
→ 要件定義
→ お客様承認
RFPから要件定義までの流れ
つまり、要件定義を始める時点ですでに「この条件なら、この構成・金額で実現できる」というベンダー側の前提が存在しています。
ここを無視して、受注後に新しい要望をすべて取り込めば、見積前提は簡単に崩れます。
たとえば、
「ログは7年間、すべてオンラインで検索できるようにしたい」
「データセンター障害でも業務を継続したい」
「これまで手作業だった補正も全部システム化したい」
という話が要件定義で初めて出てくれば、ストレージ、サーバ、ネットワーク、冗長化、運用、開発工数などに影響します。
だから要件定義では、
RFPに何が書かれていたか。
質問回答で何を確認したか。
何を提案し、何を前提に見積もったか。
を照合する必要があります。
要件定義で確認する3つのこと
私が実際のプロジェクトを振り返ると、要件定義では大きく3つを明確にする必要があります。
何を実現するのか。
誰が決めるのか。
どこまでを誰の責任とするのか。
この3つのどれかが曖昧だと、後工程で認識差や手戻りが起きやすくなります。
どれか一つでも曖昧なまま後工程へ進むと、設計段階で問題が表面化します。
実際に、私はそれを何度も経験しました。
「何を実現するか」を実現方式まで具体化する
要件定義では、お客様の要求を確認するだけではなく、その要求をシステムとしてどのように実現するのかまで具体化する必要があります。
たとえば、
「L7レイヤーの攻撃に対応すること」
という要求があったとしても、それだけでは設計できません。
どこで攻撃を検知・遮断するのか。どの製品やサービスを使うのか。採用するシステム構成で本当に実現できるのか。
こうしたところまで確認して、初めて後工程へ進める要件になります。
実際にあった話①｜RFPの一文が、基本設計後の製品追加になった
以前担当した大規模なAWS案件で、RFPに、
「L7レイヤーの攻撃に対応すること」
というセキュリティ要件がありました。
RFP上は、わずか一文です。
ところが、基本設計を完了した後、セキュリティ製品の詳細な設計を進める中で問題が発覚しました。
当時採用していた閉域接続構成では、想定していたAWS WAFを適用できないことが分かったのです。
しかし、RFPに明記されている要件なので、
「この構成ではできません」
で終わらせることはできません。
代替方式を探し、最終的にはSymantec ProxySGのWAF機能を追加して対応することになりました。
RFPで求められたL7攻撃対策について、当初はAWS WAFでの対応を想定していたが、採用構成では適用できず、Symantec ProxySGのWAF機能を追加して代替対応した。
問題は、単に製品を一つ追加すれば終わりではなかったことです。
当初予定していなかった製品・ライセンスの追加購入が必要になり、設計と検証も追加で発生しました。
しかも、すでに基本設計は完了し、お客様へ納品・承認済みでした。
ウォーターフォール型の大規模プロジェクトでは、一度フィックスした基本設計を勝手に変更することはできません。
影響を整理し、正式な変更管理を発出し、設計書を変更し、関係者の承認を取り直す必要があります。
費用についても当初見積には入っておらず、最終的には予備費を使って対応しました。
今回は予備費で吸収できましたが、要件定義で見落とした対応がすべて予備費で収まるとは限りません。
追加費用としてお客様と調整できなければ、ベンダー側のコストとしてプロジェクトの採算に直接影響します。
RFPのたった一行を実現方式まで詰め切れなかった結果、後工程では製品追加、設計変更、変更管理、追加費用まで連鎖したわけです。
振り返れば、要件定義の段階で「L7攻撃対策をどこで、どの方式で実現するのか」まで具体化し、採用予定の構成で実現できることを確認しておくべきでした。
RFPに書かれた文言を、そのまま要件として引き継ぐだけでは不十分だったということです。
要件定義で曖昧さを残す怖さは、ここにあります。
前工程で発見できていれば、基本設計変更や正式な変更管理まで発展する前に対応できた可能性があります。
「誰が決めるか」を決めるのも要件定義
要件そのものを決めるだけでは十分ではありません。
その要件を誰が決めるのか
も明確にする必要があります。
特に大規模システムでは、複数のサブシステムを横断して共通化すべき要件があります。
たとえば、
- 監視
- 性能
- 信頼性
- セキュリティ
- ログ
- 運用
などです。
個別のサブシステムだけでは決められない要件について、誰が全体方針を決め、どの範囲まで共通化するのかを明確にしておかないと、各チームがそれぞれの判断で設計することになります。
実際にあった話②｜共通要件を決められず、各サブシステムが個別設計した
多数のサブシステムから構成される大規模プロジェクトで、それらを横断して統括するシステム共通チームが設置されていました。
本来であれば、監視、性能、信頼性など、システム全体で考え方をそろえる必要があるものについては、共通チームが方針を整理し、各サブシステムへ展開する想定でした。
ところが、各サブシステム固有の事情が強く、共通チームで要件をまとめ切れませんでした。
議論を進めても、
「そこは各サブシステムで決めてください」
という形で判断が各チームへ戻される状態になりました。
最終的にはプロジェクトとして、監視設計、信頼性設計、性能設計を各サブシステムが個別に行うことになりました。
当然、設計思想や基準にもばらつきが生まれます。
後から全体をレビューし、整合を取ろうとすると、大量の調整に加えて追加のコストが必要になります。
本来は共通チームが監視・性能・信頼性などの方針を整理して全体へ展開するが、整理できないと各サブシステムが個別設計になり、基準や設計思想がばらつく。
この経験からも、
要件定義では「何を決めるか」だけでなく、「誰が決めるか」「どの範囲を共通化するか」まで決める必要がある
と考えています。
「どこまでを誰の責任とするか」を明確にする
外部システムや顧客組織内のネットワークと接続する場合、責任分界には大きく2つあります。
1つ目は、技術的な責任分界です。
- どのポートを開けるのか
- どの通信を許可するのか
- どこで監視するのか
- 障害時にどこまでを誰が切り分けるのか
2つ目は、調整上の責任分界です。
- 誰が接続条件を提示するのか
- 誰が顧客内部の関係部門と調整するのか
- 誰が相手側ベンダーと調整するのか
- その調整作業は契約範囲に含まれているのか
実際のプロジェクトでは、技術条件よりもむしろ、「誰が誰と調整するのか」が曖昧なことで工程が止まることがあります。
実際にあった話③｜顧客内部の調整までベンダー側に流れてきた
顧客組織内に複数の管理部門やベンダーが関係する大規模システムで、顧客側ネットワークとの接続が必要になったことがあります。
本来であれば、顧客側でネットワークポリシーやセキュリティ条件を整理し、接続条件を提示してもらったうえで、こちらが設計を進めます。
ところが、実際には誰が条件を整理し、誰がネットワーク管理部門と調整するのかが明確になっていませんでした。
結果として、当社側が顧客内部の企画部門と調整し、さらにその先にいるネットワークベンダーと直接調整する場面まで頻発しました。
契約上、当社が顧客内部のシステム企画やベンダー統括まで担う前提ではありません。
それでも、誰かが調整しなければシステム接続そのものが進みません。
こうなると、契約上のスコープと、実際にプロジェクトを前へ進めるために必要な作業との間にズレが生じます。
本来は顧客側で条件整理と内部調整を行う想定だったが、実際には責任分界が曖昧で、ベンダー側が顧客企画部門やネットワークベンダーと直接調整する状態になった。
外部接続では、
「どこにつなぐか」だけでなく、「誰が条件を出し、誰が誰と調整するのか」
まで明確にする必要があります。
「認識差を潰す」は、実務ではどうやるのか
「認識差を潰す」と言うだけでは抽象的です。
実際のプロジェクトでは、RFPや提案書を見ながら要件定義書だけを直接書いていくわけではありません。
RFP、質問回答、提案内容、見積前提などを確認しながら、不明点や判断が必要な事項を「確認項目」や「残課題」として起票し、回答と検討結果を積み上げながら要件を確定していきます。
私が実際に担当したプロジェクトでも、「確認項目一覧」や「残課題管理台帳」のような資料を使い、
- 何が分かっていないのか
- 誰に確認するのか
- どのような回答があったのか
- 追加で何を検討する必要があるのか
- 最終的にどう対応するのか
を管理していました。
RFPの一文を、設計できる要件まで具体化する
RFPには、きれいな言葉で要求が書かれています。
たとえば、
- 現行データを移行すること
- 既存システムと連携すること
- 必要なログを保存すること
- セキュリティを確保すること
といった記載です。
しかし、その一文をそのまま設計に使うことはできません。
たとえば、
「現行データを移行すること」
と書かれていても、実際には、
- Shift_JISとUnicodeが混在していないか
- 外字や異体字をどう扱うか
- ベンダー独自の変換ルールがないか
- 変換できない文字をどう補正するか
- 誰が補正判断をするのか
- 移行前後をどう突合するのか
RFPの一文の裏には、設計に進むための確認事項が数多くあります。
まで確認する必要があります。
つまり、要件定義ではRFPの文言を転記するのではなく、
その要求を設計・構築・テストできる水準まで分解する
必要があります。
RFPと現場の実態が一致しているか確認する
もう一つ重要なのが、RFPに書かれた内容と、実際の業務や運用が一致しているとは限らないということです。
現場に確認すると、
「実は月末だけ手作業で補正している」
「異常データは担当者が確認してから再取込している」
「この連携は年1回しか使っていない」
といった話が後から出てくることがあります。
このとき、単純に、
「では、その作業もシステム化しましょう」
とはなりません。
確認すべきなのは、
その対応が今回の契約・見積範囲に含まれているか
です。
そのため、
- RFPに書かれているか
- 質問回答で確認しているか
- 提案書に含まれているか
- 見積前提に入っているか
- 契約範囲に含まれるか
- 追加要件として扱うべきか
- 運用で代替できないか
を整理します。
ここで初めて、顧客の要望とベンダーの認識差が見えてきます。
確認項目と残課題を使って、判断の経緯を残す
実際に使った課題管理表の内容を簡略化すると、次のようなイメージです。
課題管理表で確認した項目と合意内容を簡略化した例
ここで重要なのは、最初の要求どおりに機能を作ることが必ずしも正解ではないという点です。
「帳票の使用量を管理する」という要求でも、目的を確認すると、すべてをシステム機能として実装する必要がない場合があります。
一方で、「データを連携する」という一文でも、
全件か差分か
→ 差分をどう判定するか
→ 元データに判定材料があるか
→ エラー時はどうするか
と掘り下げて初めて、設計できる要件になります。
つまり要件定義では、
RFP → 質問回答・提案・見積前提 → 確認項目・残課題 → 回答・技術検討 → 対応方針 → 確定要件
という経緯を追えるようにしておくことが重要です。
こうして判断の経緯まで追える状態にしておくことは、後から変更理由を説明するうえでも重要です。
実務では、一度質問して終わるとは限りません。
回答を受けて追加の技術検討が必要になったり、性能や容量を再試算したり、別部門への確認が必要になったりします。
そのため、トレーサビリティで本当に重要なのは、単にRFPと要件定義書の項番を対応させることではありません。
「なぜ最終的にこの要件・方式になったのか」という判断の経緯まで追えることです。
要件定義の成果物は「合意の記録」
確認項目一覧や残課題管理台帳は、要件を決めていくための資料です。
しかし、これら自体が要件定義のゴールではありません。
確認と検討を重ね、
- 何を実現するのか
- どう実現するのか
- どこまでを今回の対象とするのか
- 誰が何を担うのか
を決めた結果を、最終的な要件として整理したものが要件定義の成果物です。
プロジェクトによって資料構成や名称は異なりますが、たとえば、
- 業務要件
- 機能要件
- 非機能要件
- 外部インターフェース要件
- データ・移行要件
- 運用要件
- セキュリティ要件
- スコープ・前提条件
- 課題・未決事項
などを整理します。
合意内容を文書として残すことで、「言った・言わない」の認識違いも防ぎやすくなります。
重要なのは、資料の名前ではありません。
要件定義の途中では多くの議論や検討をしますが、後工程へ渡すときに必要なのは、
「最終的に何をすることに決めたのか」
です。
たとえば、
「古いデータを定期的に切り離す必要があるのではないか」
という議論があっても、検討の結果、
「必要期間はオンラインで保持し、年次切替処理は設けない」
と決めたのであれば、それが設計者へ渡す確定要件です。
一方で、後から、
「なぜこの方式にしたのか」
を確認する必要が出たときには、確認項目一覧や残課題管理台帳をたどれば、判断の経緯を確認できます。
つまり、
要件定義書は「最終的な合意」を残す資料。
確認項目・課題管理資料は「そこに至った判断の経緯」を残す資料。
という役割分担です。
この2つがつながっていることで、初めて後工程の設計者やテスト担当者も、同じ前提で作業を進められます。
だから要件定義書は、
「何となく決めたことのメモ」ではなく、プロジェクト関係者が同じ前提で次工程へ進むための合意の記録
なのです。
初心者SEが要件定義で見るべき3つのポイント
初心者SEが最初からすべての要件を理解するのは難しいと思います。
それでも、会議では次の3つを意識すると、かなり見え方が変わります。
1．曖昧な言葉をそのままにしない
「早く」
「安全に」
「止まらない」
「既存どおり」
「必要な範囲で」
といった言葉が出たら注意します。
その言葉が、設計やテストで判断できる水準になっているかを考えます。
その場で決められない場合でも、そのまま流さず、課題・未決事項として残して次回までに具体化します。
2．数字にできるものは数字にする
- 「早く表示する」ではなく「通常時3秒以内」。
- 「多くのユーザー」ではなく「同時利用者1,000人」。
- 「長期間ログを保存」ではなく「7年間保存」。
性能、容量、復旧時間、データ保持期間などは、数字にしなければ設計も見積もテストもできません。
さらに、数値だけでなく、「通常時かピーク時か」「平均値か最大値か」といった条件もセットで確認します。
3．誰が決める話なのかを見る
会議で出てくる論点には、
業務部門が決めるもの
情報システム部門が決めるもの
運用部門が決めるもの
セキュリティ部門が決めるもの
ベンダーが技術提案するもの
プロジェクト全体で判断するもの
があります。
だから、
これは誰が決める話なのか。
誰に確認すれば確定するのか。
どの範囲で共通化すべきなのか。
を見ることが重要です。
判断者が決まっていない論点は、内容だけでなく「誰が、いつまでに決めるのか」まで課題として管理します。
まとめ｜要件定義は「何を、誰が、どこまで」を決める工程
要件定義は、お客様の要望を聞いて要件定義書に転記する工程ではありません。
特に大規模SIでは、
RFP、質問回答、提案書、見積前提をつなぎながら、認識差を潰し、スコープと責任分界を確定する工程
です。
そのとき重要なのが、
何を実現するのか。
誰が決めるのか。
どこまでを誰の責任とするのか。
の3つです。
今回紹介した3つの経験も、振り返ればそれぞれこの3軸の問題でした。
WAFの事例は、「何を実現するのか」を実現方式まで具体化し切れなかった問題です。その結果、基本設計後に製品追加、設計変更、変更管理、追加費用が発生しました。
共通要件の事例は、「誰が決めるのか」を整理し切れなかった問題です。その結果、本来はシステム全体でそろえるべき監視、信頼性、性能の設計を各サブシステムが個別に行うことになりました。
外部接続の事例は、「どこまでを誰の責任とするのか」が曖昧だった問題です。その結果、契約上は想定していなかった顧客内部や別ベンダーとの調整まで、こちら側で担うことになりました。
要件定義で残した曖昧さは、後工程で消えるわけではありません。
むしろ、設計、製品追加、追加費用、変更管理、関係者調整という形で、より大きな問題になって戻ってきます。
要件定義で曖昧さを残せば、そのツケは後工程で払うことになります。
だからこそ、要件定義では要望をそのまま受け取るのではなく、設計・構築・テストできる条件まで具体化し、誰が決めるのか、どこまでが責任範囲なのかまで含めて、関係者で合意しておく必要があります。
関連記事
要件定義の次工程や、要件を設計・テストへどうつなげるのかについては、以下の記事で詳しく解説しています。
- 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
要件定義で整理する「機能要件」と「非機能要件」の違いを、実務で使える視点から解説しています。
- 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
要件定義で決めた内容を、システム全体の構成や方式へ落とし込む基本設計について解説しています。
- 詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
基本設計で決めた方式を、実際に構築できる設定値や設計内容まで具体化する工程を解説しています。
- Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方
要件定義・基本設計・詳細設計の内容が、後工程のテストとどう対応するのかを整理しています。
- システム開発全体の流れを最初から確認したい方は、こちらも参考にしてください。
システム開発の流れを現場目線で理解する【前編】
- シリーズ全体は、「実務で使えるシステム開発方法論」にまとめています。
コメント