システム開発における要求定義の重要性｜要件定義との違いや要求定義の実態・改善ポイントを解説【2024年最新版】

要件定義は知っているけど、要求定義という言葉ははじめて聞いた。そんな企業担当者の方であれば、以下のような疑問を感じているはず。

・要求定義とは？システム開発における位置付けは？
・要件定義とはなにが違う？要求定義が重要な理由は？
・要求定義フェーズでは具体的になにをする？

システム開発のもっとも上流に位置する要求定義は、要件定義とは異なるシステム開発の要ともいえる工程。企業IT担当者の方なら、プロジェクトを成功に導くためにも要求定義の意味・重要性を理解しておく必要があります。

そこで本記事では、システム開発における位置付け・重要性、要件定義との違いから、要求定義フェーズの実態・課題・改善ポイントまで、知っておきたい要求定義の基本を徹底解説！漠然としたイメージの要求定義が明確になります。

※開発パートナーとしてタッグの組める優秀なシステム開発会社を探している方は、システム幹事にご相談ください。専任のアドバイザーが最適な開発会社をご紹介します。相談料などは一切かかりませんので、お気軽にお問い合わせください。

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発における要求定義とは

要求定義とは発注者の目的やニーズを具現化すること

要求定義とは、発注者の目的やニーズをヒアリングしたうえで「開発するシステムに何を求めるのか」を具体化する工程のこと。

どんな課題を抱えて、どうすれば解決できるのかを言語化していきます。

・現状の課題（何に困っているのか）
・理想の状態（どうなれば解決するのか）
・システム機能（どんな機能があれば良いのか）

例えば「○名が同時にアクセスして××を1秒以内に並列処理できるシステム」「○○ボタンをクリックすると、××と△△を処理できる機能」といった概要を決定します。

要求定義と要件定義の違い

繰り返しますが、要求定義は「ビジネスや業務の課題を解決するため、システムになにを求めるのか？発注者の目的・ニーズ・要求を具現化する工程」です。

それに対し要件定義は、「発注者の目的・ニーズ・要求をどう実現していくのか？システムに求められる要件を具現化する工程」だという違いがあります。

要件定義については後ほど詳しく説明します。

要求定義の位置付け

システム開発における要求定義の位置付けを理解するには、ウォーターフォール型と呼ばれる開発手法で採用されることが多い「V字モデル」を参考にすることが早道です。

V字モデルとは、開発工程の粒度（詳細度）と同じテスト工程を対比させ、各工程で定義された仕様通りにプログラムが動作するか、プロジェクト全体をマネジメントしていく仕組みのこと。

図をご覧いただければ「要求定義」が「ユーザーテスト・受け入れテスト」に対応するのに対し、「要件定義」が「総合テスト」に対応しているのがおわかりでしょう。

ユーザーテストとは、完成したシステムが発注者（ユーザー）の要求を満たしているかをチェックするテスト。
総合テストとは、要件を満たすシステムに仕上がっているかをチェックするテストです。

※ウォーターフォール型システム開発・V字モデルについてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：システム開発の手法4つの特徴・メリット・デメリットを解説！【比較表付き】
関連記事：システム開発のV字モデルとは？発注者が知っておきたい基本を解説！

要件定義のインプットは要求定義書

このことからもわかるように、要求定義は要件定義の上流に位置する開発工程です。要求定義のアウトプット（成果物）である「要求定義書」をインプットに活用し、要件定義を進めていくことが理想です。

ただし小規模なプロジェクト、あるいは発注側がシステム開発に不慣れな場合などでは、要件定義フェーズで要求定義も同時に明らかにしていく、という作業パターンになることも珍しくありません。これは、システム開発の目的・ニーズ・要求を言語化するためには、企業担当者に一定以上のIT知識が求められるからです。

このパターンでは、システム開発会社側がヒアリングという形で発注者の目的・ニーズ・要求を引き出すことがほとんど。要求定義という言葉を聞いたことがない、という企業担当者の方が少なくないのはこのためです。

【無料】システム開発の要求定義について相談する

要求定義の成果物

しかし、発注者の目的・ニーズ・要求を定義する要求定義は、本来、発注者自身が主導して進めなければならない工程です。具体的には、現状の課題（As-Is）とあるべき姿（To-Be）からギャップを埋める方法を設計（業務設計）し、成果物であるRFP（提案依頼書）に落とし込んでいきます。

RFP（提案依頼書）

RFPは、発注者がシステム開発会社に対して提案を依頼するドキュメントであり、複数の候補から依頼先を絞り込む際にも活用される文書です。一方、日本情報システム・ユーザー協会（JUAS）では、RFPを要求定義書・要求仕様書として捉えており、要件定義のインプットとして活用されることもポイント。RFPに記載される主な内容は以下の通りです。

※RFP（提案依頼書）についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：RFPとは？システム開発の質を高める提案依頼書の作り方を解説！【サンプルあり】 | システム幹事

提案書・見積書

発注側からの要求定義書・仕様書ともいえるRFPに対する、受注側のシステム開発会社からの回答となるドキュメントが提案書・見積書です。

提案書には、RFPの内容を取りまとめたうえで、発注側の要求を実現するため、下記のようなことが記載されることが一般的。

・システム提案
・プロジェクトの進め方
・開発側の体制・役割

予算・納期を踏まえたうえでの見積書作成を含め、受注側のシステム開発会社にとっての提案書は、要件定義フェーズの事前準備に近い性格を持つ作業だといえるでしょう。

【無料】システム開発の要求定義について相談する

システム開発で生じる要求定義フェーズの課題

それでは、RFP作成を含めた要求定義を発注者主導で進めれば、システム開発プロジェクトで生じがちな課題を解決できるのか？そうとばかりはいえません。要求定義書であるRFPの品質が高ければ、その後の開発工程の品質にもいい影響を与えます。しかし、そもそも要求フェーズではさまざまな課題が生じがち。以下から、簡単に解説していきましょう。

プロジェクトの複雑化

システム開発における要求定義は、発注者の目的・ニーズ・要求を具現化する工程です。つまり、要求定義および成果物であるRFPの品質を高めるには、どのようなシステムで目的・ニーズ・要求を満たすべきなのか、開発するシステムの全体像を具体化しておくことが理想。

しかし、競争の激化する経済市場やITの進化を背景に、システム開発プロジェクトは年々多様化・複雑化が進んでいます。要求定義フェーズで「正確な要求を定義」することが難しくなりつつあるのが現実です。

これは、ITシステムが単なる業務効率化ツールではなく、ビジネスの成長に欠かせない経営基盤として活用されているから。また、将来的なユーザーの動向、自社業務の拡張に備えたフレキシビリティを求められているからだといえるでしょう。定型業務をITシステムで置き換えるため要求を定義する、というわけにはいかなくなっているのです。

業務目線と開発目線の違い

システム開発プロジェクトが多様化・複雑化すれば、ただでさえ難しい目的・ニーズ・要求の言語化が、さらに困難なものとなります。自社内にITチームを持たない企業であれば、外部のシステム開発会社に協力を仰ぐ流れになるのは自然なことでしょう。しかし、ここにも要求定義フェーズの課題となる要因が潜んでいます。

それは、発注者が業務目線でシステムを考えるのに対し、受注者が開発目線でシステムを考えるという違いです。協力を仰ぐシステム開発会社に多くを依存すると、要求定義フェーズが「システム開発のしやすさ」を中心に進んでしまうことも。結果的に、現場で使いにくい利用されないシステムになってしまう場合も珍しくありません。

【無料】システム開発の要求定義について相談する

システム開発を成功させる要求定義フェーズの改善ポイント

こうした要求定義フェーズで生じがちな課題を解決するにはどうしたらいいのか。そんな疑問を感じる企業IT担当者の方に向け、以下から、要求定義を改善するためのヒントとなるポイントをいくつか紹介していきます。

要求仕様書の図式化・レビュー

成果物としてアウトプットされた要求仕様書（RFP）の品質が確保されているか、要件定義フェーズに移る前に確認しておくことがおすすめ。具体的には、RFPで策定した仕様を図式化し、システム開発プロジェクトの目的・ニーズ・要求に応えられているのか？関係者間でRFPのレビューを実施するといいでしょう。

ポイントとなるのは、プロジェクトの中心を担うIT担当者だけでなく、実際の利用者となるエンドユーザー、現場担当者を含む、さまざまなステークホルダーにレビューしてもらうこと。さまざまな立場からのフィードバックを集めることで、全体を見るだけでは気が付かなかった改善点が見えてきます。

ビジネスプロセス関連図

ビジネスプロセス関連図とは、システム開発の対象となる業務とそれ以外の業務を含め、ビジネス全体を俯瞰する目的で作成される図のこと。外部組織・システムとの関係性とともに、ビジネスのなかでヒト・モノ・資金がどう流れているのか、システム化によってなにが変わるのかを1枚の紙で把握できるようになります。

画像引用：情報処理推進機構（IPA）「ユーザのための要件定義ガイド第2版」

業務フロー図

業務フロー図とは、要求定義で明らかにした「あるべき姿（To-Be）としての業務手順」を図式化したもののこと。場合によっては、現状（As-Is）の手順も業務フロー図として起こし、課題に対する解決法の妥当性を評価することもあります。

出典：情報処理推進機構（IPA）「ユーザのための要件定義ガイド第2版」

システム化業務フロー図

システム化業務フロー図とは、あるべき姿（To-Be）として図式化した業務手順を、システム側から見た情報のやり取りの手順・順序を図式化したもののこと。システムリプレイス案件などの場合は、従来（As-Is）のシステム化業務フロー図を起こし、比較検討することもあります。

出典：情報処理推進機構（IPA）「ユーザのための要件定義ガイド第2版」

信頼・協力できる開発パートナー

上述したビジネスプロセス関連図、業務フロー図、システム化業務フロー図は、要件定義フェーズの成果物として作成されるドキュメントでもあります。自社でRFPの図式化が難しい場合は、要求定義書の品質を高めていくためにも、要件定義以降の開発パートナーとなる信頼・協力できるシステム開発会社の存在が欠かせません。

実際、要求定義以外のプロジェクト課題発生要因は、ほとんどがベンダー（システム開発会社）側に起因するもの。システム開発でなによりも重要なことは、開発するシステムの品質を高めるための「要求定義」ですが、開発パートナーとなるシステム開発会社の選定も重要であることを忘れないようにしましょう。

※自社の目的に合ったシステム開発会社を探している方は、システム幹事にご相談ください。相談料などは一切かかりませんのでお気軽にお問い合わせください。

【無料】おすすめのシステム開発会社を紹介してもらう

要求定義書をインプットにした要件定義の成果物

RFP・提案書が揃ったところで、システム開発プロジェクトは要件定義のフェーズに進みます。ただし、RFPに記載されたシステム開発の目的・ニーズ・要求を、いきなり要件定義書に落とし込むわけではありません。

発注側・受注側間で、要求定義に対する認識のズレがないか？不足している要素はないか？ディスカッションを重ねたうえで、予算・納期を念頭に要素を取捨選択しつつシステム要件へと落とし込んでいく作業が要件定義だからです。要件定義の結果としてアウトプットされる成果物（要件定義書）には、主に以下のような内容が記載されます。

※システム開発の要件定義についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：システム開発の要件定義とは？受託開発における重要性や進め方を解説！

【無料】システム開発の要求定義について相談する

システム開発における要求定義フェーズの実態

ここまでの解説でおわかりのように、要件定義は要求定義書をインプットにして進めることが理想。目的・ニーズ・要求を具現化する要求定義フェーズは発注者が主導して行われるべきものです。

これは、要求定義がシステム開発プロジェクトの「目的そのもの」であり、最上流の開発工程に位置付けられているからにほかなりません。しかし、要求定義という言葉を聞いたことがない企業担当者の方が少なくないように、実態はそうとばかりはいえないようです。

半数の発注者がRFP制作をベンダーに依存

以下の図は、日本情報システム・ユーザー協会（JUAS）が2018年に実施した「ユーザー企業IT動向調査2017」で公表されている、RFP（要求定義書）制作における役割分担をグラフ化したものです。

画像引用：日本情報システム・ユーザー協会（JUAS）「ユーザー企業IT動向調査2017」

驚くことに、RFPを自社で作成していると回答したユーザー企業は、全体の16%に過ぎず、半数の発注者がRFP作成をベンダーに大きく依存していることがわかりました。なんらかの形でベンダーがRFP作成に関与している企業も含めれば、その割合は80%を超えることになり、企業規模が小さくなるほどその傾向が強まることも見て取れます。

プロジェクトの課題発生要因は要求定義の品質

RFP作成を含む要求定義をベンダー（システム開発会社）に依存することが、必ずしも悪いということではありません。プロジェクトが滞りなく進行し、満足のいくシステムが開発されれば問題ないはずです。

では実態はどうなのか？同じJUASが実施した「企業IT動向調査報告書2019」で公表されている課題の主な発生原因をグラフ化したものを紹介しておきます。

画像引用：日本情報システム・ユーザー協会（JUAS）「企業IT動向調査報告書2019」

工期遅延・予算超過・品質不良というプロジェクト課題・トラブル要因の多くが「企画・要件定義不良」および、それにともなう「仕様変更多発」に起因していることがわかります。

要求定義品質の低さがさまざまなトラブルを招いているのです。
「開発体制・要員不足」「見積もり不良」も含めれば、プロジェクト課題の半数以上が要求定義不良からくるものだともいえるでしょう。

このことからは、RFPの作成をベンダーに依存していても要求定義フェーズの品質改善につながらないこと、むしろ事態は悪化していることがわかります。実際、JUASのIT動向調査2017では、RFP作成をベンダーに依存する企業ほど、ベンダーに対する不満が大きくなるという結果も公表されています。

画像引用：日本情報システム・ユーザー協会（JUAS）「ユーザー企業IT動向調査2017」

【無料】システム開発の要求定義について相談する

システム開発の要求定義まとめ

要件定義は知っているけど、要求定義という言葉ははじめて聞いた。そんな企業担当者の方に向け、本記事では、システム開発における位置付け・重要性、要件定義との違いから、要求定義フェーズの実態・課題・改善ポイントまで、知っておきたい要求定義の基本を解説してきました。

システム開発プロジェクトは、その7割が失敗に終わるともいわれており、その原因のほとんどは上流工程の失敗によるものです。目的・ニーズ・要求を具現化して業務設計する要求定義、そしてそれをシステム要件に落とし込む要件定義がいかに重要かがわかります。

つまり、システム開発プロジェクトを成功させるためには、要求定義の品質を高めていく努力とともに、どのようなシステム開発会社を選定するかが重要です。

※もし開発パートナーとしてタッグの組める、優秀なシステム開発会社を探している方はシステム幹事にご相談ください。予算や目的から最適な開発会社を選定させていただきます。相談料などは一切かかりません。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

必ず開発会社に発注する必要はありません。システム開発の相場情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】おすすめのシステム開発会社を紹介してもらう