記事公開日:2024.06.14
最終更新日:2024.07.16

「要件定義書」と「要求仕様書・RFP」の違いとは!?基本の流れと重要性、記載内容について解説!

システム導入を成功に導くために欠かせないのが「要件定義書」と「要求仕様書・RFP」です。
しかし、多くの中小企業ではこれらの文書が適切に管理されておらず、導入後にトラブルが発生することが少なくありません。
本記事では、これらのドキュメントの役割や違い、記載すべき内容を解説します。

1.システム導入で必要な「要件定義書」「要求仕様書・RFP」

中小企業様に訪問やヒアリングをさせて頂く機会が多くある中で、既存システムの現状把握の際に伺うのは【既存システムにおける「要件定義書」「要求仕様書・RFP」】の話です。
システムをどういうコンセプトで導入したのか、どういう機能が実装されているのかを把握するために伺います。システム導入時には当然のようにあるべきドキュメントですが、残念ながら現実として、この資料がすぐに出てこないケースが多く、「要求仕様書がないパターン」は大変よくありますが(良いことではありませんが)、偶に「要件定義書もないパターン」ということもお聞きします。どうやってシステム導入したのか!?と思いますが、
様々なベンダーさんがいる中でこれが実情とも感じます。
皆様もこれまでシステム導入を行ってきたと思います。改めてですが、今、手元に過去システム導入で作成した「要件定義書」「要求仕様書・RFP」はありますか?
両方ない場合は、ほぼ間違いなく納品後にベンダーとトラブルになってきていると察しますが、いかがでしょうか。パッケージのカスタマイズする場合でもシステム導入する際には、このドキュメントがないとほぼ間違いなくベンダーとのトラブルになる。と感じています。

今回はなぜシステム導入で「要件定義書」「要求仕様書・RFP」が必要になるのかを解説してきたいと思います。

2.「要件定義書」「要求仕様書・RFP」の違いとは??

要件定義書・・・要件定義とは、開発者がプロダクト開発をするための仕様を定義したものです。要件定義を明文化した「要件定義書」は、ユーザー側の合意・了承を得るためのもので開発者側が作成します。

要求仕様書・RFP・・・要求定義はユーザーがプロダクト開発・システムに求める仕様を定義したものです。要求定義を明文化した「要求定義書」は、プロダクト開発に対するオーダーを記したものになるため、ユーザー側が作成します。

要求定義は、プロダクト開発の上流工程として最も重要なプロセスです。
「要求定義→要件定義→基本設計→詳細設計→開発→テスト→リリース/運用」となります。

ユーザーが作成する要求仕様書とRFPも実は異なるドキュメントになるので、説明していきます。
RFPとは提案依頼書「Request for Proposal」の頭文字を取って「RFP」と呼ばれることもあります。外部業者へ発注しようとしている企業の担当者が、外部業者から提案をもらうために必要な要件をまとめた書類のことです。
要求仕様書の違いは、提案の求め方です。要求仕様書は、企業が自社で開発するソフトウェアやシステムの要件や仕様を明確にするために使用されます。一方、RFPは、外部業者からの提案を求めるために使用される文書であり、提案内容や提出期限、提案方法、評価方法などを明確に記載する必要があります。きちんとしたRFPは、外部業者側はどのような要件に基づいて提案すれば良いのかが明確になるので、自社の課題に沿った内容の提案を組み立てしやすくなるとともに、正確性の高い見積もりを導き出すことにもつながります。

3.「要件定義書」「要求仕様書・RFP」がないトラブル事例

このようにシステム導入において、「要件定義書」「要求仕様書・RFP」はとても重要なドキュメントとなります。

「要求仕様書・RFPがない」=開発者に伝えられるべきユーザーの要望が文書化されていない(ユーザー側で纏まっていない)。開発者にも明確に伝わっていない可能性が高い。
「要件定義書」=開発者が開発すべき機能が明確になっていない。ユーザー側もどんなものを開発者が作ろうとしているかをわかっていない。ということです。

要求仕様も要件定義書がない場合、ほぼ間違いなくシステムの納品後に以下のようなトラブルになります。

  • (口頭で)要望した機能が実装されていない(使い始めて気づいた)
  • 機能は実装されているが気がするが、物凄く使い勝手が悪い。
  • システムが運用に即していない。
  • 当初イメージしたシステムでない。(もっとスタイリッシュなものを想像していた等)

たとえ納品後に、ユーザー側にこういった不満があっても、要求仕様・要件定義書を作成してなれば、お互いに立ち返る根拠がありません。ドキュメントにしていれば、○○に明記されていると伝えることが出来ますが、ドキュメント化されていなければ「言った言わない」という話に終始して、お互いに歩み寄ることが出来なくなります。
この場合、泥沼化しながらユーザー側があきらめるか、開発側が作り直すか。二者択一になります。恐ろしい話ですが、各地で実際によく起きているのが実情です。

システム導入が上手くいかなかった企業は多くあります。振り返ってみて、要求仕様書・要件定義書があったかどうか確認してみてください。もし、トラブルが起こった場合、自社は悪くない。ベンダーに問題があったと思いがちですが、

  • ユーザー側の要望は齟齬ないように明確に伝えられていたでしょうか?
  • ベンダーが作成した要件定義書はきちんと読み込んでいたでしょうか?
  • システム開発をベンダーに丸投げしていなかったでしょうか?

ベンダーに要望を明確に伝えることも、ベンダーが開発しようとしているシステムについてしっかり理解しておくことも、開発中もきちんと要望したシステムが出来ているかを確認することも、全部ユーザー側の仕事となります。それを放棄することを、「ベンダーへの丸投げ」といいます。ベンダーへの丸投げのシステム開発はほぼうまくいきません。

いかがでしょうか。「要件定義書」「要求仕様書・RFP」に重要性について理解頂けたかと思います。システム導入においては、ユーザー側にも要望を明確にする義務があります。まずは何をしたいのか?はきちんと整理することから始めていきましょう。

4.要求仕様書/要件定義書に盛り込むべき内容

要求仕様書には、最低限下記の内容を盛り込みましょう。

①事業の目的と背景
なぜこのシステム導入/ロボット導入が必要なのか、導入の目標は何かを示す明確な定義。

②期待される成果
システム導入/ロボット導入を通じて達成したい具体的な成果や効果の列挙。
要件定義書では、技術的な側面に焦点を当て、具体的な実現方法や進捗管理のポイントを明示しましょう。

①技術的要件
システム導入/ロボット導入に必要な技術やプラットフォーム、開発言語などを具体的に指定。

②機能仕様
システムやロボットが持つべき具体的な機能やモジュールを明確に定義。

③進捗管理と品質管理
プロジェクト進捗を管理する方法や品質を確保する手段を具体的に記載。

これらの情報は、スムーズなプロジェクト進行に不可欠です。各文書の作成に充分な時間をかけ、関係者間での意見の一致を確認することがプロジェクト成功の鍵です。

無料経営相談の際はフォームよりお気軽にお問い合わせください。お電話でのお問い合わせは 0120-958-270へ(平日9時45分~17時30分)