要求仕様書とは？要件定義書やRFPとの違いから書き方、構成まで解説
- DX
Introduction
企業が業務システムや社内システムなどの開発を外注先に依頼する際は、
ただ開発を丸投げするだけでは、よいシステムを構築できないでしょう。
なぜならシステムを開発する目的や要望、求める機能などを細かく外注先に伝えられないからです。
要求を伝えるために必要なのが、要求仕様書です。要求仕様書を作成することで、依頼側と開発側がシステムの仕様や目的を適切にすりあわせられます。
この記事では、要求仕様書とは何か、要求仕様書の作成ステップや書き方、作成時の注意点などについて解説します。
目次
要求仕様書とは
ここでは、要求仕様書とは何か、要求仕様書が必要になる理由や、要件定義書などとの違いについて解説します。
依頼者からの要求を受け開発側が実装する機能などを記述した文書
要求仕様書とは、依頼者が外注先にシステム開発を依頼する際に、依頼者からの要求や目的などを記述した文書です。依頼者からの要求を文書化することで、開発するシステムの仕様や機能を検討するための材料が明確になります。要求仕様書で、依頼側と開発側の認識を明確にすりあわせることが可能です。
要求仕様書では、プロジェクトの目的と背景、依頼側の要求や課題、制約条件などを明確に定めて文書化します。
簡単にいうと、要求仕様書は依頼側の「こういったことがしたい」「こういったことについて困っている」といった要求や制約条件をドキュメント化したものです。これらの情報を明確にすることで、そのあとにつづく要件定義、設計などの工程を進めやすくなります。
なお、要求仕様書は依頼側が作成するドキュメントですが、開発側が作成する場合もあります。
要求仕様書が必要になる理由
要求仕様書を作成することで関係者間のコミュニケーションツールになり、とくに、依頼側と開発側の間の意思疎通に役立ちます。
システム開発を依頼する際には、依頼側から「こうしたい」「こういったことに困っている」という要求や条件を開発側に伝えることが重要です。しかし、依頼を羅列したExcelの資料やメールのやりとりだけでは要求をまとめて体系的に伝えるのが困難です。
そこで要求仕様書を作成すれば、その場が議論を交わすたたき台となり、依頼側と開発側との明確なコミュニケーションツールになります。
このように、開発をはじめるにあたり要求仕様書として依頼側からの要求をまとめて文書化することは、非常に重要です。
システム開発についてはこちらもご覧ください。
＞＞システム開発とは？工程や手法、依頼時のポイントまでわかりやすく解説のページへ
要件定義書との違い
要件定義書とは、要求仕様書作成後に開発側が作成するドキュメントです。要件定義書では、依頼者からの要求を実現するための機能や性能などを明確に記載します。たとえば画面遷移、機能、性能要件、セキュリティ要件などが明確に記述されます。
要求仕様書は、依頼者側からの「こうなってほしい」「こういったことに困っているから解決してほしい」という要求や条件を記載したものです。一方の要件定義書は、要求仕様書を受けて「機能の内容」「問題の解決方法」を記載したドキュメントといえます。
なお、一般的に要求仕様書は依頼側が作成しますが、要件定義書は開発側が作成することが多いです。
要求仕様書で依頼側の要求がしっかりと定義されていれば、要件定義書で機能要件や非機能要件を的確に漏れなく定義することが可能です。
▽あわせて読みたい▽
＞＞要件定義とは？作成手順や前後の流れをわかりやすく解説！のページへ
提案依頼書（RFP）・情報提供依頼書（RFI）との違い
要求仕様書とよく似たドキュメントに、提案依頼書（RFP）と情報提供依頼書（RFI）があります。
提案依頼書とは、企業が新しいサービスなどをはじめる際に外注先候補に向けて提案を求めるために作成するドキュメントです。提案依頼書にはプロジェクトの目的、要求内容、求めるスキルや経験、スケジュールや予算などが記載されます。
要求仕様書と似ていますが、その目的が異なります。提案依頼書は、最適な外注先を選定するために複数の外注先候補に発出するものであり、複数社から提案を受けて比較選定する目的で作成するのが特徴です。一方の要求仕様書は、開発を担当することが決まった外注先に要求を伝えるためのドキュメントなので、目的が異なることがわかります。
情報提供依頼書とは、市場調査や情報収集を目的として作成するドキュメントで、外注先を選定する前の段階で使用するものです。業界内の動向や技術について理解を深めるための質問が記載され、外部企業から一般的な情報を求めるために用いられます。
依頼側が開発側にシステム開発に関する要求を伝えるための要求仕様書とは、位置づけや目的がまったく異なることがわかります。
RFPについてはこちらもご覧ください。
＞＞RFPとは？意味やRFQ・RFIとの違い、構成要素、書き方について解説のページへ
要求仕様書の作成ステップ
要求仕様書を作成するステップについて、解説します。
①要求の収集
まずは要求を収集します。「ビジネスが変わって担当者の手間が増えた部分をシステムでサポートしたい」「ボトルネックになっている処理を自動化したい」などの要求を洗い出します。機能面だけでなく、増え続ける取引量やユーザー数に対応したいなどの非機能面に関する要求も大事です。
ユーザーや業務を行う現場の担当者などからヒアリングして情報を集めるとともに、性能要件、法的要件、技術的要件、セキュリティ要件などの観点からの情報も幅広く収集します。
②要求の分析・定義
収集した要求の情報を分析し、機能要件、非機能要件に分類します。機能要件とは、システムが提供する具体的な機能や、計算結果などの処理内容を明確に定義したものを指します。非機能要件とはレスポンスタイムなどの性能要件や、セキュリティ、ユーザビリティなどの要件のことです。
要件を機能ごとなどに分類していき、漏れや抜けがないかをチェックします。また、要求が多すぎる場合は、優先順位をつけておきます。
③要求の文書化・レビュー
要求が集まり、分類が完了したら文書化します。そして、現場の担当者などの関係者によるレビューを行い、問題がないかを確認します。
要求仕様書の構成要素と書き方
要求仕様書に記載する内容と書き方について、解説します。
①プロジェクト概要・背景
まずは、今回システム開発を依頼することになった背景、プロジェクトの概要を記載します。「こういう問題が起きたので解決したい」「こういった目標を達成したい」「顧客からこのようなクレームをいただいた」などです。これにより、プロジェクトの目的や目標を明確にすることが可能です。
②プロジェクトの目的
システムを導入する理由、目指す目的、目標を明確にします。たとえば業務プロセスの改善、コストの削減、品質の向上など、具体的に何を目的にするのかを明記します。そうすることで、この目的を達成するための要求を明確に洗い出すことが可能です。
③機能要件と非機能要件に関する要求をまとめる
上記の目的を満たすための要求にはどのようなものがあるのか、機能要件と非機能要件にわけた要求をまとめ、記載します。
▽あわせて読みたい▽
＞＞機能要件とは？非機能要件との違いや決定ステップ、注意点を解説のページへ
＞＞非機能要件とは？機能要件との違いや設計方法、設計のポイントについて解説のページへ
要求仕様書作成時の注意点
要求仕様書を作成する際に気をつけるべき注意点について、解説します。
目的とゴールを明確にする
要求仕様書を書く際は、まず目的とゴールを明確にする必要があります。目的とゴールがはっきりしていないと、関係のない要求ばかりが膨らんでしまうでしょう。あらかじめ方向性が定まっていれば、それに向けた要求に絞って情報を整理できます。
要求の漏れや過不足がないか確認する
要求を洗い出したら、機能ごとに分類し、漏れや過不足がないかを確認しましょう。ここで、要求が漏れると、要件が丸ごと漏れてしまうため、必ずレビューを行って念入りに確認してください。
関係者とのすりあわせを丁寧に行う
現場の担当者や外部連携先の担当者など、システムに関わる関係者と入念にすりあわせを行うことが重要です。要求仕様書ですべての要件が決まるといってもよいくらい、重要な段階なので、関係者の承認を必ず受けておきましょう。
技術用語や曖昧な表現は可能な限り排除する
要求仕様書でむずかしく専門的な技術用語を多用したり、曖昧な表現を使ったりすると、要求がぼやけてしまいます。また、関係者にレビューを依頼しても内容を正しく理解されず、誤りや漏れが見つからないこともあります。そのため、技術用語や曖昧な表現はできる限り排除しましょう。
変更管理のルールを定義する
要求仕様書を最初に作成した段階から、レビューや工程を重ねることで変更が入る場合もあります。そのため要求仕様書のバージョン管理と、変更履歴の管理のルールを定めて、適切に行いましょう。変更が重なることで、結局いまの要求は何かがわからなくなることを防げます。
まとめ
要求仕様書とは、依頼者が外注先にシステム開発を依頼する際に依頼者からの要求や目的などを記述した文書です。依頼者からの要求を文書化することで、開発するシステムの仕様や機能を検討するための材料が明確になります。
要求仕様書で、依頼側と開発側の認識を明確にすりあわせることが可能です。要求仕様書を依頼側が作成する、または開発側が作成した要求仕様書を依頼側がレビューすることで、システムに対して何を求めるのかが明確になります。
なお、要求仕様書により要求や要件を明確に定義しても、設計を行いプログラミングからテスト、納品までを一回で行うウォーターフォール開発という開発手法では、後戻りができません。一度仕様を決めてしまうと、顧客からの仕様変更の要望を受けることは困難です。
要求仕様書を通じて開発要件を明確にしても、実際の開発が進む中で新たなニーズや仕様変更が生じることは少なくありません。そのような変化に柔軟に対応するためには、ウォーターフォール型ではなく、反復的かつ柔軟な開発が可能なアジャイル開発が有効です。
しかし、自社だけでアジャイル開発を導入し、継続的に運用していくのは容易ではありません。そうした課題を抱える企業を支援するのが、SHIFTのアジャイル開発支援（SHIFT 1LINE）です。
お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。
継続的なプロダクト開発に伴走する、SHIFTのアジャイル開発支援
「アジャイル開発手法を導入して、顧客満足度の高い製品を開発したい」「アジャイル開発を導入したいが、社内にノウハウがない」などの悩みを抱えている企業様は多いかもしれません。
アジャイル開発は短いスパンの開発を繰り返すため、機能変更や機能追加に柔軟に対応できるというメリットがあります。しかし、アジャイル開発をスムーズに進めるためには、設計、開発、テストという短いスパンを繰り返して、つねにフィードバックを行う必要があり、豊富な専門知識や経験、ノウハウが必要です。
アジャイル開発に関する知識やノウハウ、優れた開発メンバーなどがそろわない状態で、アジャイル開発にシフトするのはむずかしいでしょう。
そこで、SHIFTのアジャイル開発支援（SHIFT 1LINE）をご活用いただければ、お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。
短期的な人材確保や長期的な人材育成など、お客様のニーズにあわせて対応し、お客様のシステム開発に柔軟性とスピードをもたらします。
監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
