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

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

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

1. クライアントの要求、希望などを記述した仕様書
2. クライアントの要求や希望の中でも、システム開発で必要なものを示した仕様書

要求仕様書は、開発チームが開発をする前に作成するべき文書として、システムやソフトウェアの要件を明確化するために使用されます。この文書には、システムの目的や機能、性能、インターフェース、セキュリティ、品質保証など、開発に必要な要件や仕様が詳細に記載され、プロジェクトの進行や品質を確保する上で重要な役割を果たします。そのため要求仕様書は、システムやソフトウェアの開発において必要不可欠な文書のひとつといえます。

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

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

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

要件定義書と要求仕様書の違いは、作成する段階が異なることです。要件定義書は、システムを開発する前段階で、システムの要件を明確にするための文書です。
一方、要求仕様書は、要件定義書で定義されたシステムの要件を基に、システムの仕様を詳細に記述する文書です。要求仕様書は、システムの開発中に作成され、開発者やテスターが参照する文書として利用されます。

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

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

仕様書を作成する目的はシステムが必要とする要件や機能を明確にすることにより、システム開発の効率性と品質を向上させることです。特に工程を細かく分けて、上流工程から下流工程へと順番に進めていくウォーターフォール型の開発手法の場合、開発の進捗を管理するための重要な指標となるため、要求仕様書の作成は重要であるといえるでしょう。
一方、作るシステムの概要が決まったらすぐに開発工程に入り、機能ごとに「計画→設計→実装→テスト」のサイクルを繰り返しながら進めるアジャイル型の開発手法では、要件の変更に柔軟に対応することが求められます。そのため要求仕様書は開発チームと顧客とのコミュニケーションの手段として機能するよう、より柔軟性のある形で作成します。

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

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

上記を順番で行うことにより、質の高い要求仕様書を作成できるでしょう。いずれの項目も重要度が高いため、発注側とすり合わせをした上で慎重に行うことが求められます。
それぞれ手順について詳しく解説していきます。

まず、その開発対象のソフトウェアに何を実行させたいか、どのような役割を担わせたいかを、利害関係者からヒアリングし要件を集めます。ユーザー、開発者、マネージャー、エンドユーザー、ビジネス担当者、法的要件、技術的要件などの多数の観点の情報を収集することが望まれます。ここでは、顧客のニーズや問題点、必要な機能、予算、スケジュールだけではなく、法的要件、技術的要件なども押さえておきましょう。
システム開発でありがちなのは具体的なシステムの動作などについては要求されるものの、セキュリティ面や品質について決めてないというパターンです。システムにおいてセキュリティ面や品質は非常に重要な要素であり、これらを正確に決めることでより良いシステムを開発することができます。過去のノウハウを活かすこともおすすめです。

要求分析では、収集された要件を分析し、独自の要件を決めていきます。それぞれの要件が重要かどうか、また抜けている部分がないか、完全性の検証を行いながら優先順位をつける必要があります。
特に矛盾する要件、抜けている要件がある場合には、ユーザーに再度確認を行い、より重要な要件を優先するようにします。チェックリストなどを用いて発注側からの要求を洗い出したり、矛盾点を探るために関係者を招いてワークショップを開いたり、細かい検証が可能になります。
また、開発前に受注側に対してアプリケーションを視覚化して見せるためのプロトタイプを開発するのもひとつの手段です。本格的に開発に入る前にプロトタイプで確認することで、両者の齟齬をなくしながら工程を進められます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システム開発において、要求仕様書は顧客の要望を正確に把握し、それを実現するための計画を立てるための基礎となるものです。したがって要求仕様書の完成度が低い場合、開発チームが想定する開発プロセスと実際のニーズとのかい離が生じ、開発プロジェクトが失敗するリスクが高まります。開発の前にこの工程をきちんと対応し、やりたいことを明確にすることが求められます。
一方で、要求仕様書の作成のノウハウがない場合もあります。そのような際は、システム構築の最初の場面から併走してサポートをいたしますので、一度テクバンにご相談いただければと思います。

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