システム開発の要件定義とは？目的や進め方、コツ紹介｜サンプル付

要件定義は、プロジェクトの成否を左右するもっとも重要な作業工程です。なぜなら、要件定義とは依頼主のニーズを見える化する作業だからです。

しかし、ITの専門家でもなければ、要件定義がどのようなものなのか？なぜ重要なのか？分かりにくいでしょう。

・システム開発における要件定義とはなにか？
・なぜシステム開発で要件定義が重要なのか？
・発注する側としてシステム開発の要件定義にどう関わるべきか？

本記事では、システム開発における要件定義の重要性と進め方を解説。最後まで読めば、開発会社のやり取りが格段にスムーズになります。

※システム開発を依頼する会社を探している方はシステム幹事にご相談ください。予算や目的から最適な開発会社を選定させていただきます。相談料などは一切かかりません。

【無料】プロのアドバイザーに最適な開発会社を探してもらう

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

そもそも日常で使わない”要件”とは「求められる条件」という意味。「こんなシステムを作りたい」とフワッと考えている”要望”や、求める予算や納期などの”要求”​​を「本当に必要なもの」「現実的に可能な機能や日程」などに絞り込んだものです。

つまり、システム開発における要件定義とは「どんなシステムを開発するのかを見える化すること」。発注者の希望を叶えるために必要な機能などを明確にする作業です。下記動画は要件定義について説明している動画。タイトルが「アプリ開発」とありますが、システム開発と同じ内容です。

具体的には下のような項目を決めます。

・開発目的
・ターゲット
・予算
・必要な機能
・用いられる技術
・スケジュール（納期）
・必要な人員（工数）
・実装手順

要件定義では、「なぜ（Why）システムを開発するのか？」システム開発の目的・ゴールを実現するため、「なにで（What）解決するのか？」システムに実装すべき機能、要求される技術・ソフトウェア・ハードウェアなどを明確にします。

要件定義が重要な理由

要件定義は発注者と開発者の綿密な打ち合わせ・協議が必要であり、その過程で要件が変更されることも珍しくありません。要件定義をしっかり固めないと、以下のような問題につながります。

・開発工程で想定以上に時間がかかる
・作ったものの役に立たなかった
・無駄に高機能になって予算オーバーになる

上記のような発注後のトラブルにもつながりかねません。また、開発会社としっかり話し合う中で「想定していなかったけど、実はこんな機能が必要だった」など、隠れた要求が明らかになることもあります。

「Why」と「What」を明確にするための要件定義は、システム開発でもっとも重要な作業工程であり、プロジェクトの成否を左右するもっとも重要な要素なのです。

システム開発における要件定義の位置付け

システム開発の「Why」「What」を明確にする要件定義は、プロジェクト全体の指標でもあります。要件定義がシステム開発工程のもっとも上流に位置付けられているのはこのため。

以下は、システム開発で一般的な、ウォーターフォール型開発モデルにおける開発工程例です。

「企画」>「業務設計」>「要求定義」>「要件定義」>「仕様確定」>「基本・詳細設計」>「実装（プログラミング）」>「テスト」>「納品・リリース」>「運用・保守」

「企画」「業務設計」「要求定義」は依頼する側である発注者のタスク。要求定義は「こんなことを実現したい！」という希望を明確にするものです。

関連記事：ウォーターフォール型システム開発とは？開発工程・メリット・アジャイル型との違いを解説！

システム開発の開発工程の詳細は下記記事をご参照ください。
関連記事：システム開発の工程・流れをプロが解説！発注者が知っておくべきポイントを紹介

「要求定義」との違い

「要求定義」はシステム開発の目的・ゴールをもとに、課題を解決するために必要なシステムの概要、具体的に実装したい機能を定義していきます。これが「要求定義」です。発注側が行う作業ですが、ヒアリングという形で開発会社がヘルプ、あるいは代行する場合もあります。

「要件定義」は開発会社のタスク。開発会社とのコミュニケーションが非常に重要で、仕様確定後、要件定義の最終的な成果物ドキュメントとして「要件定義書」が作成されます。

関連記事：システム開発における要求定義の重要性｜要件定義との違いや要求定義の実態・改善ポイントを解説！

システム開発での成果物の詳細は下記記事をご参照ください。
関連記事：システム開発の成果物・ドキュメント｜知っておきたい開発工程ごとの成果物を一覧で紹介！

要件定義書は受託側の開発会社が作成することが基本ですが、プロジェクトの予算・納期とのバランスで発注側のニーズ・要求すべてを盛り込めない場合もあります。そのため、最終的な要件を定義するまでには、発注側・受託側で綿密なコミュニケーションを重ね、妥結点を探っていく必要があります。

要件定義書の重要性

発注者と開発会社の互いが合意した要件を確認するためにも、システム開発の「Why」「What」が明文化された要件定義書の作成が必須です。

また、開発チームの指標としても、要件定義書は必須のドキュメント。要件定義書をもとに基本設計・詳細設計が行われるのはもちろん、実装された機能が要件を満たしているのか？テスト時の指標としても要件定義書が必要だからです。

関連記事：システム開発の基本設計とは？その位置付け・重要性・発注者としての関わり方を解説！
関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！

要件定義で使われるツール

要件定義では、発注者の目的・ゴール・現状の課題・理想とする状態を踏まえ、開発会社が解決策の検討と分析を重ねていきます。この過程で、クライアントの現状分析や解決策の検討に「機能情報関連図」をはじめとした各種ツールが活用されます。

仕様を確定するまでのミーティングでも活用されるため、各種ツールがどのようなものなのか？概要だけでも把握しておくことが重要。以下から、代表的なツールを簡単に紹介していきます。

機能情報関連図

画像引用：総務省

機能情報関連図とは、業務の流れ・業務と業務の関連を見える化したものです。

業務を把握して現状の問題点をあぶり出し、業務の仕組み改善や課題解決などに活用される白地図・基盤図のこと。DFD（Data Flow Diagram）とも呼ばれます。

システム開発では、プロジェクトで解決すべき業務機能の特定、あるいはプロジェクトの対象範囲を把握するためにDFDを活用することがほとんど。現在の業務にどのような課題があるのか？ボトルネックになっている要素はどこか？把握するためにも有効です。

業務フロー図

業務フロー図は、業務を処理する組織・手段・手順を見える化したもの。人がやる作業とコンピューターがやる作業も明確化します。

DFDで特定された課題を、業務手順（ミクロレベル）まで落とし込んで図式化したものが業務フロー図です。要件定義では、「As-Is」とも呼ばれる既存業務フロー図を作成したうえで、「To-Be」とよばれる新規業務フロー図（解決策）が作成されます。

業務フロー図をもとに「こうしたい」という発注者の希望に対し、「こうしたらどうか」と開発会社の提案を繰り返していく形になるため、要件定義で最も重要なツールになります。

ER図

ER図（Entity Relationship Diagram）とは、システムで扱うデータを図で明確化したもの。システムが処理するデータとデータの関連性を図式化したデータベース設計図です。

たとえば「顧客」「商品」の間には「購入する」という関係が成り立ちますが、これを図式化するER図を活用すれば、大規模なシステムでもデータ間の処理構造をシンプルに表現できます。

※ここまで読んで、システム開発を外注しようと思われた方はシステム幹事にご相談ください。予算や目的などをヒアリングし、最適な会社を選定いたします。

【無料】プロのアドバイザーに最適な開発会社を探してもらう

システム開発の要件定義で決めること

要件定義から仕様確定までは、上述したツール・ドキュメントを活用しながら発注者・開発会社間で協議を重ね、特に「実現したい機能」を確定していきます。
それぞれ具体的に見ていきましょう。

システム要件

現状の業務フロー、新規の業務フローとそのギャップを踏まえ、それらをどのようにシステムに落とし込んでいくのか？システム開発の方向性を決める作業が「システム要件」です。具体的には、洗い出した新規業務フローから、システム化するもの、しないものを選別していきます。

これは、発注者の望む業務要件と、システム開発会社側で実現できるシステム要件が異なるため。すべてのニーズをシステム化すると予算オーバーになってしまう場合があるほか、技術的な観点から実現が難しいという場合もあります。システム開発の目的・ゴールに立ち返り、譲れるもの、譲れないものの優先順位を付けていくことが重要です。

機能要件

システム要件で決定した方向性をもとに、クライアントの望む機能をどのように実装していくか？システム開発の「How」にあたる要件を決めていく作業が「機能要件」です。具体的には、システムの機能・構造やデータの種類、処理可能な内容などを定義していくことが一般的。

以下の表のように、要件定義書に記載される各種要件を定義していく作業だと考えれば間違いないでしょう。

非機能要件

言葉からはシステム開発に必要のない要件だと思いがちですが、「非機能要件」とは、システム要件・機能要件など、機能面以外で検討すべき、すべての要件のことを意味します。どうしても機能要件に目を向けがちですが、システムのパフォーマンスや拡張性などの重要な要件も「非機能要件」。システムが不安定、セキュリティが甘くて情報漏えいしたといったことにならないよう、しっかりと要件定義しなければなりません。

ただし、機能以外のすべてが含まれる非機能要件は、対象範囲が幅広いのも事実。非機能要件の項目をどのように設定すればいいのか？迷ってしまう方に向け、情報処理推進機構（IPA）が策定した「非機能要求グレード」の6項目を紹介しておきましょう。

関連記事：システム運用とは？開発との関係・保守との違い・重要性・作業内容を解説！

注意 非機能要件をすり合わせる場合は、イメージ画像で伝えることは難しいです。なので、非機能要件になぜそうするのかを明記してもらうようにしましょう。例を上げると「サーバ構成は○○にしておきます。ピーク時は同じ時間帯に1000人程度のユーザが利用することが想定されるため、そのアクセスに耐える場合はその程度考えておく必要がある」と言った形です。

技術要件

IPAの非機能要求グレードとは別に、近年では「技術要件」を設定するケースも増えているようです。具体的な内容は、システムのベースとなる「プラットフォーム」、特定のフレームワークなどの「採用する技術」、システムを構築するために活用される「開発言語」、採用する「データベース」など。

パブリッククラウドを活用することの多い近年では、これらの要素は可用性、性能・拡張性などの要件で触れられる場合もありますが、技術要件としてひとつにまとめておいた方がチェックしやすくなるかもしれません。

その他の要件

開発するシステムによっては、適用される法律の規制をクリアする必要があるかもしれません。たとえば、知的財産権に抵触しないか？といった基本的なところから、個人情報保護法、特定電子メール法、輸出禁止技術の活用など。こうした法律に関連する要件を「規制要件」としてまとめるケースもあります。

要件定義書の例（サンプル）

上記はWebサイト制作の要件定義書になりますが、システム開発でも基本的には同じです。

【無料】プロのアドバイザーに最適な開発会社を探してもらう

要件定義の進め方

ここまで、要件定義の基本や重要性とともに、開発会社と協議を重ねて仕様を確定していくまでの流れを解説してきました。しかし、システム開発の工程を見てもおわかりのように、発注側にとっての要件定義は、開発会社が携わる前からはじまっているともいえます。それが「企画」「業務設計」「要求定義」です。

それでは、発注側としてこれらの「要件定義」をどのように進めていけばいいのか？簡単に解説していきましょう。

システム開発の企画・業務設計

手作業で行っている業務をシステム化したい、生産性の上がらない既存システムを刷新したい、新規サービスを立ち上げたいなど、システム開発を検討するからには、なんらかの課題・ゴールがあるはず。これを明確にしていくのが「企画」「業務設計」です。

・現在の状態（現状）
・本来あるべき状態（理想の状態・ゴール）
・現状とゴールのギャップ（解決すべき課題）

システム開発の目的（現状とゴールのギャップを埋める）とゴール（理想の状態）を決めることが「企画」とするならば、それをより明確にするため、現状を分析して課題を特定し、本来あるべき理想の状態を設定することが「業務設計」だといえるでしょう。

これはシステム開発の「Why」に該当する重要な要素。
「企画」「業務設計」が明確かつ具体的であればあるほど、その後の要件定義フェーズ、ひいては開発プロジェクト全体の精度を高められます。

要求定義

明確化したシステム開発の目的・ゴールをもとに、課題を解決するために必要な システムの概要、具体的に実装したい機能を定義していきます。これが「要求定義」。
社内SEがいなければ難しいのでは？そう考える方が多いかもしれませんが、必ずしも専門知識・スキルが必要なわけではありません。

「○名が同時にアクセスして××を1秒以内に並列処理できるシステム」「○○ボタンをクリックすると、××と△△を処理できる機能」といった具体的な表現であれば問題ありません。ここまでの分析結果を「RFP（提案依頼書）」としてまとめておけば、複数の開発会社に提案・見積もりを依頼する場合にも役立ちます。

一方、言語化が難しい、時間がないなどの理由で、ドキュメントの作成が困難だというクライアントが多いのも事実。こうしたケースでは、開発会社からの「ヒアリング」という形で、企画から要求定義までミーティングを重ねながら進めていくことになります。

ただし、ニーズをヒアリングしてくれるからと、開発会社に任せきりにしていてはいけません。システム開発における「Why」は、あくまでも委託側であるクライアントのタスク。最低でも「企画」「業務設計」を入念に行い、積極的にニーズを伝えていく努力が必要です。

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

注意 要件定義で失敗するケースでよく見るのが、すり合わせたつもりになっていること。開発会社は「わざわざすり合わせなくても大丈夫だろう」や「話をしている感じで認識が揃っているだろう」と思っている場合があります。エンジニアと非エンジニアで見えていることが全然違うので、丁寧すぎるくらい説明してもらいましょう。要件定義時に時間を掛けることであとの修正が減るのでトータルで考えるとコスパは良くなるはずです。

要件定義のコツ・注意点

システム開発のトラブルを最小限に抑えるためには要件定義でしっかり固めることが必須。システム開発におけるリスクを減らすために、事前にできる対策方法を紹介します。

開発目的は分かりやすく言語化できるほど明確に！

システム開発の目的（要件定義）を明確に定めなければ、希望の内容をシステムに反映してもらえません。開発会社と依頼者間の認識不足がシステム開発の失敗を招きます。日経コンピュータのアンケート調査によると、システム開発の失敗原因で最も多いのが「要件定義の不備」という結果も出ています。

要件定義を明確に定められない原因の一つに、発注者と開発会社との認識のズレが挙げられます。認識のズレは、双方によるコミュニケーションが不足していることによって起こることがほとんどです。開発会社は「わざわざすり合わせなくても大丈夫だろう」「話をしている感じで認識が揃っているだろう」と思っている場合もあります。必要のない機能を入れてしまったことで予算が膨らむなど、後悔の原因になります。

目的を設定する場合は「何のためにやるか」を決めるだけでは理想の効果が出ません。「具体的に何を実現したいか」で決めることが大切です。緻密な計画を立てなかったため、システム開発が失敗に終わるケースは非常に多いです。

目的を明確にする方法の一つとして、開発したいシステムに近い事例を探しておきましょう。システム事例を探ることで、開発したいシステムのイメージを具体的に伝えられます。

技術的リスクはシステムの検証を！発注側の協力も大切

システム開発の工程は「要件定義、基本設計、詳細設計、開発・実装、テスト・レビュー、リリース」に分かれています。開発側の技術的リスク対策になりますが、要件定義の前に1つ1つの要件について実現可能かシステム検証を行うことが大切です。早い段階で開発の実現性・不実現性を確認することで、開発が進んでから実現困難な状態に陥るのを防ぎます。つまり無駄に工数、コストを費やしてしまうリスクを回避できるのです。

発注側も技術的リスクに備えて気をつけなければなりません。発注側が希望を盛り込みすぎると要件やプログラミングの構成が複雑になってしまい、技術的リスクにつながります。

例えば旧システムから新システムへ移行する場合に、発注側のシステムを使う現場から反発が起きることがあります。新システムにも旧システムと同じような操作性を求めたり、「現状と異なる業務は行いたくない」と現場が現行業務をかたくなに変えたがらなかったりする場合です。

また、何でもシステムに任せようとしたり、例外処理が多い場合も技術的リスクを招く恐れがあります。現場の声に振り回されて要件がどんどん膨らんだ結果、スケジュールの遅延を招く恐れがあります。

発注側がデータを整理してからシステムに渡す、新システムの操作に発注側も対応する努力をする、不要な機能を搭載しないなど、発注側の協力も必要です。

システム開発における要件定義まとめ

本記事では、システム開発における要件定義の基本・重要性とともに、委託側の関わり方、事前準備を含めた要件定義の進め方を解説してきました。要点を簡単におさらいしておきましょう。

・要件定義はシステム開発の「Why」「What」を明確にする工程
・要件定義の精度がその後の工程、プロジェクト全体の成否を左右する
・仕様確定に向けて要件定義で決めるのは「システム要件」「機能要件」「非機能要件」「技術要件」など
・「企画」「業務設計」「要求定義」は委託側のタスク

システム開発では「完成したはいいけど、使えない・使われないシステムが出来上がってしまった」といった失敗例は少なくありません。しかし、そのほとんどは綿密に要件定義を詰めていなかったことが要因です。

経験の少ない方であれば、システム開発、特に要件定義に身構えてしまうかもしれませんが、委託側のニーズをシステム要件に落とし込むのが要件定義です。ニーズを明確にしたうえで開発会社と積極的にコミュニケーションを取り、疑問点・懸念点を徹底的につぶしていくことが重要です。

システム開発の工程では、希望が反映されて具体化される「要件定義」が特に重要です。
スムーズに開発を進めるためには、システム開発会社選びも重要なポイント。コミュニケーションを円滑にとることができ、信頼できる開発会社に依頼することが大切です。

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

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

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