要求仕様書とは？ RFP・要件定義書との違いを解説

システムやソフトウェアの開発において、どのような機能が必要であるかを明確にする文書として「要求仕様書」というものがあります。
この記事では、なぜ要求仕様書を作る必要があるのか、その設計方法、書き方といった作成の上での注意点だけではなく、似たような言葉である「要求定義書」と「RFP」との違いをわかりやすく解説します。

「要求仕様書」には、次の2つの側面があります。

1. 発注側の要求、希望などを記述した仕様書
2. 発注側の要求や希望の中でも、システム開発で必要なものを示した仕様書

要求仕様書は、開発をする前に作成するべき文書として、システムやソフトウェア開発によって実現したい要望を明確化するために作成されます。

要求仕様書と似ている言葉として、要件定義書、提案依頼書（RFP）があります。それぞれの文書がもたらす意味や目的などは、大幅に異なりますのでそれぞれの違いを説明していきましょう。

提案依頼書（REP）のサンプルをご用意しております。ダウンロードの上、ぜひご活用ください。
RFP（提案依頼書）サンプル

要件定義書は、発注側による要求仕様書からシステムの要件を明確にし、開発を進めるための基本的な文書のひとつです。システムの要件とは、システムが満たすべき機能や性能、制約条件などのことを指します。システムを開発するための設計書の前段階であり、システム開発において欠かせない文書といえます。

要求仕様書と要件定義書の違いは、作成主体が異なることです。
要求仕様書は主に発注側が作成し、一方、要件定義書は受託側のシステム開発会社が、要求仕様書で定義されたシステムの要望を基に、システムの仕様を詳細に記述する文書です。要件定義書は、システムの開発中に作成され、開発者やテスターが参照する文書として利用されます。

提案依頼書は企業が外部の業者に対して、商品やサービスの提案を求める際に使用される文書です。「Request for Proposal」の頭文字を取って「RFP」と呼ばれることもあります。外部業者へ発注しようとしている企業の担当者が、外部業者から提案をもらうために必要な要件をまとめた書類のことです。

RFPと要求仕様書の違いは、提案の求め方です。要求仕様書は、企業が自社で開発するソフトウェアやシステムの要件や仕様を明確にするために使用されます。
一方、RFPは、外部業者からの提案を求めるために使用される文書であり、提案内容や提出期限、提案方法、評価方法などを明確に記載する必要があります。きちんとしたRFPは、外部業者側はどのような要件に基づいて提案すれば良いのかが明確になるので、自社の課題に沿った内容の提案を組み立てしやすくなるとともに、正確性の高い見積もりを導き出すことにもつながります。

仕様書を作成する目的はシステムが必要とする要件や機能を明確にすることにより、システム開発の効率性と品質を向上させることです。特に工程を細かく分けて、上流工程から下流工程へと順番に進めていくウォーターフォール型の開発手法の場合、開発の進捗を管理するための重要な指標となるため、要求仕様書の作成は重要であるといえるでしょう。

一方、作るシステムの概要が決まったらすぐに開発工程に入り、機能ごとに「計画→設計→実装→テスト」のサイクルを繰り返しながら進めるアジャイル型の開発手法では、要件の変更に柔軟に対応することが求められます。そのため要求仕様書は開発チームと顧客とのコミュニケーションの手段として機能するよう、より柔軟性のある形で作成します。

要求仕様書に必要となる作成工程は下記の通りになります。

1. 要求収集
2. 要求分析
3. 要求定義
4. 要求仕様記述

上記を順番で行うことにより、質の高い要求仕様書を作成できるでしょう。いずれの項目も重要度が高いため、社内のステークホルダー（利害関係者）とすり合わせをした上で慎重に行うことが求められます。
それぞれ手順について詳しく解説していきます。

まず、その開発対象のソフトウェアに何を実行させたいか、どのような役割を担わせたいかを、ステークホルダーからヒアリングし要件を集めます。ユーザー、開発者、マネージャー、エンドユーザー、ビジネス担当者、法的要件、技術的要件などの多数の観点の情報を収集することが望まれます。
ここでは、関係者のニーズや問題点、必要な機能、予算、スケジュールだけではなく、法的要件、技術的要件なども押さえておきましょう。

システム開発発注でありがちなのは具体的なシステムの動作などについては要求するものの、セキュリティ面や品質について決めてないというパターンです。
システムにおいてセキュリティ面や品質は非常に重要な要素であり、これらを正確に決めることでより良いシステムを開発することができます。過去の発注ノウハウを活かすこともおすすめです。

要求分析では、収集された要件を分析し、独自の要件を決めていきます。それぞれの要件が重要かどうか、また抜けている部分がないか、完全性の検証を行いながら優先順位をつける必要があります。
特に矛盾する要件、抜けている要件がある場合には、関係者に再度確認を行い、より重要な要件を優先するようにします。チェックリストなどを用いて要求を洗い出したり、矛盾点を探るために関係者とワークショップを開いたり、細かい検証が可能になります。

要求定義の段階では、要求分析で得られた情報やデータを元に、実際にソフトウェアを開発する人たちに要求を理解させるための文書を作成します。要件を定義するために、ユースケース図、フローチャート、状態遷移図、ワイヤーフレーム、シーケンス図などを使用することがあります。

この段階で開発側に理解させる文書を作ることができれば、さらにスムーズに工程が進むため、細かい作りこみが重要です。

ここまで固まった要求を元に、要求仕様の記述を行います。要求と設計の橋渡しとなる文書を作成するため、システムが使われる領域に適したルールに従いながら、システムの作成/修正を指示するような形で作られるケースがほとんどです。

これは要求仕様作成の最終工程となり、システムの作成や修正といった非常に重要な部分のため、今までの工程を振り返りながら記述することが重要といえるでしょう。

次に要求仕様書の書き方について紹介いたします。

• 背景・現状の課題
• 目的
• 機能
• 開発体制
• 開発スケジュール

多くの要求仕様書では、以上の項目を文書に残します。それぞれの項目の詳細について細かく解説していきます。

システムを導入する背景と課題を明確にします。課題には、既存のシステムの問題点、業務の非効率性、顧客からの苦情などが含まれます。
このセクションは、新しいシステムを導入する必要性を強調し、導入することで解決できる問題を明確にすることを意識しましょう。

このセクションは、システムを導入する主な理由を明確にし、組織全体が共有する目標の定義ともいえます。新しいシステムの導入により達成したいゴールを定義しましょう。
目的には、業務プロセスの改善、コスト削減、品質向上、新規ビジネスチャンスの獲得、競争優位性の獲得などが含まれます。例えば「管理システムを開発して、顧客情報をより有効活用したい」というように具体的に記載することが望まれます。

機能には、新しいシステムで提供する必要がある主要な機能や特徴をリストアップします。これには、ユーザーインターフェイス（UI）、データ入力、データの管理、検索・分析機能、レポート作成、アクセス制御、その他の必要な機能が含まれます。
またソフトウェア、ハードウェア、サービスの種類に応じて、様々なレベルで記述します。このセクションで、システムをどのように機能させるかを明確にし、システムの利用者が期待する機能を満たすための要望を定義しましょう。

開発体制では、PM（プロジェクトマネージャー）の決定を優先しながらプロジェクトのために必要な人員、役割、責任といったリソースやその役割を定義します。
その際、スキル、必要なトレーニング、コミュニケーションフローなども併せて定義することが良いでしょう。この際、自社にリソースがない、スキルを持った人材がいないという場合は、早急にアウトソーシングなどの調達手段で、優秀なエンジニアをチームに入れることがおすすめです。

開発スケジュールは、プロジェクトの開始から終了までの時間枠や各フェーズのスケジュールを定義します。
具体的には、各フェーズの開始日と終了日、各タスクの期限や担当者、成果物の提出期限、テストスケジュール、納品日などを記載していきます。
スケジュールの作成には、目的や機能、開発体制、リソースの可用性、予算、リスク評価などを考慮し、適切にバランスをとることが重要です。
最終的には、開発チームやステークホルダーと合意の上で策定し、定期的に監視・管理することが必要でしょう。プロジェクトの成功に不可欠な要素ともいえます。

最後に要求仕様書作成の注意点について少し解説いたします。

プロジェクトの成功において、まずシステムがどのような機能を持ち、どのような性能を発揮するかを明確かつ詳細に記載する必要があります。これはシステムが期待どおりに機能するかどうかを正確に判断するためだけではなく、目的を明確にすることで、開発チームやステークホルダーの理解を高めることにつながるからです。

不必要な機能を含めたり、不要な詳細を含めたりすると、システムを低下させる可能性があるため、仕様は、システム必要な機能や性能に焦点を当てる必要があります。

このとき、ステークホルダーの要望や必要性だけではなく、ユーザー視点に立って本当に必要な要件のみ精査するようにしましょう。
一方で、システムが将来的に変更される可能性があることを考慮して、柔軟性を確保しておいた方がいい状況もあります。その点は、将来の拡張や変更を容易にするように、可能な限り汎用的な仕様とするほうがよいでしょう。

仕様は、不正確な情報を提供すると、システム開発に混乱が生じ、品質に悪影響を与える可能性があるため、システム性能や機能に関する正確な情報を提供する必要があります。

また、あいまいな表現や誤った情報を避け、関連する人々とのコミュニケーションを密に行いながら正確性を確保することも重要です。

下記のウェブサイトは要求仕様書やRFPといったシステム開発やセキュリティに関する資料や情報が集約されています。一度ご覧になってみてください。
IPA（情報処理推進機構）公式ウェブサイト

システム開発において、要求仕様書はシステム運用の要望を明確にし、それを実現するための計画を立てるための基礎となるものです。
したがって要求仕様書の完成度が低い場合、受託側のシステム開発会社が想定する開発プロセスと実際のニーズとのかい離が生じ、開発プロジェクトが失敗するリスクが高まります。開発の前にこの工程をきちんと対応し、やりたいことを明確にすることが求められます。
一方で、要求仕様書の作成のノウハウがない場合もあります。

そのようなときは、システム開発が必要と感じた最初の場面から併走して、システム開発の成功をサポートをいたしますので、一度テクバンにご相談されてはいかがでしょうか。

また、システム開発におけるブログ記事は他にもご用意しております。
システム開発が必要になり、不安やご不明点などございましたら、下記の記事もご参考になさってはいかがでしょうか。
▼SREとDevOpsの違いとは？ インフラエンジニアとの違いも含めて解説
▼「監視設計」がシステム運用において重要な理由を解説！
▼仕様書のサンプル、書き方は？ わかりやすい仕様書の特長や種類を紹介
▼安定稼働に欠かせない運用設計とは？ 運用設計の重要性や注意点を解説