[要求仕様の美学]

2008年11月20日(木)福田 修

　前回（要件定義作業を容易にするシステム化企画書の意義：第1回）は、要求仕様書の作成を容易にするシステム化企画について述べた。今回は、要求仕様書に記載すべき項目を考えていく。

　要求仕様書は、RFP(Request for Proposal＝提案依頼書）の主要な一部分となる（図1）。このため、システム化企画書をまとめてから要求仕様書を作成するという手順は、発注のための一連の作業として欠かしてはならないものとなる。

　要求仕様書の主な用途は大きく3つある（図2）。第1に、システム化の当事者が自らの役割を遂行する際の判断材料になる。第2に、要求仕様書は取得者と供給者の間で合意し、開発委託契約を結ぶために必要になる。第3に、要求仕様書は利用者のニーズを供給者に知らせる媒体になる。

当事者の役割から見た要求仕様の必須項目

　さて、こうした3つの用途を持つ要求仕様書には、どのようなことを記載すべきなのだろうか。まずはそれを、システム化における判断材料という観点から考察する。それには、システム化にかかわる当事者の役割を洗い出すことが有効だ（図3）。

1. システム利用者→経営者

　システム利用者は「業務で困っているが、どう変えれば改善できるか」といった業務の見直し策を考える。さらに、そうした変革内容とその効果を明確に関連づけ、経営者に変革の必要性を説明する。

　経営者は、業務変革が必要かどうか判断する。

2. システム利用者→ システム部門（発注者）

　システム利用者は、上記業務の変革内容を実際にどのように実施するかをシステム部門に伝える。

　システム部門はシステム化の対象範囲を示し、効果に裏づけされたシステム投資上限額を設定する。その一方で、業務変革のスケジュールに合わせたシステム開発計画も策定する。

3. システム部門→経営者

　システム部門は、システム化に関する費用の妥当性を経営者に示し、予算を確保する。

　経営者は、システムの効果や課題への対応、投資額が適切かを判断する。

4. SE（供給者）→供給側の経営者

　SEは、契約に基づいて提示された仕様書の内容を、自社で達成できるか経営者に判断してもらう。経営者は、仕様書の内容を実現するため、システム開発費用やシステム導入時に発生する費用、運用保守を自社で受け持つ場合の費用などが適正か判断して、その仕事を請けるか否かを判断する。

5. SE→プログラマー

　SEは要求仕様書に基づき、システム開発における設計書や開発プロジェクト全体を表す計画書を作成する。

　プログラマーは、SEが作成した設計書を基にプログラムを開発する。

6. プログラマー→テスター

　テスターは、プログラマーが開発したシステムをテストする。プログラマーやテスターが要求仕様書を見る機会はほとんどないと思うかもしれない。しかし、設計書の内容や完成度について疑問を感じることもあるだろう。そんなとき、まず参照すべきは要求仕様書である。

　システム化にかかわる当事者の役割や判断内容を見てきた。これらをまとめると、要求仕様書には次ページ図4の事項を記載すべきである。

見積もりギャップやリスクを明記する

　次に、開発委託契約の観点から要求仕様書に含めるべき項目を考える。

　契約は、取得者と供給者の間の合意事項である。合意事項とはいつ、いくらで納品してもらえるかであり、その対象を表すのが要求仕様書である。供給者は、利用者のニーズやシステム化のイメージを要求仕様書からくみ取ってシステムの範囲を決め、システム化費用を算定する。

　取得者が想定するシステム化の費用や仕様と、供給者が要求仕様書を見て提示する見積もり内容にギャップがあると、契約は成立しない。契約を成立させるには、取得者側があきらめるところや、供給者側があきらめるところがあるかもしれない。システム化範囲を狭めたり、開発生産性を上げたりといったことだ。要求仕様書には、こうしたギャップや落としどころを明記して双方の合意を得ることが重要である（図5）。

　供給者がそれを見てリスクを判断できるかどうかも、要求仕様書のポイントである。供給者側は開発にともなうリスク回避策を常に模索している。要求仕様書には、瑕疵担保や保証といった運用後の対応に関する内容も含めて記載する必要がある。

●Next：エンドユーザーのニーズが盛り込まれた要求仕様書