システム開発の要件定義とは？進め方や事例をわかりやすく解説（サンプル付）【2024年最新版】

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

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

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

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

※システム開発全体の流れや進め方についてはこちらにまとめています。あわせてご活用ください。

システム開発依頼前にチェック 中小企業向けシステム開発の進め方｜完全ガイドブックのダウンロード | システム幹事 中小企業向けシステム開発の進め方 無料でプレゼントいたします！ ・システム開発を成功させる７ステップ ・システム開発の4つ...

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

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

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

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

要件定義では具体的には下のような項目を決めます。

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

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

要件定義が重要な理由

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

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

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

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

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

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

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

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

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

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

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

要件定義はDXにおいても重要

DX（デジタル・トランスフォーメーション）を推進するにあたり、経営視点からどのような機能が必要でありシステムを構築しなければいけないのか、事前の情報整理・設計が重要となります。

DX化の推進には要件定義のプロセスと共通する部分も多く、実際、事前の仕様・要件定義によりDX化の具体的な実装プロセスを決定し計画を進めることになります。

「システム・アプリ開発」だけでなく、DXの波に乗る上でも共通で重要な工程になりますので、ぜひ心得ておきましょう。

要件定義と各種工程の違い

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

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

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

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

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

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

「要件定義」と「基本設計」との違い

「基本設計」とは、要件定義の内容をもとにシステムを動かす部分の仕様を決めることです。

要件定義で決めた実装する機能や性能を、以下のように具体化していきます。

• 機能同士はどう関連するのか
• 実装する機能はどのようなものか
• 各機能にどのような役割があるのか

つまり基本設計は、開発するシステムの完成イメージを共有しすり合わせていくプロセスです。

要件定義で実装する機能や性能を決め、基本設計によって具体化していきます。

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

要件定義から仕様確定までは、発注者・開発会社間で協議を重ね、特に「実現したい機能」を確定していきます。

どんなことを決めるのか、それぞれ具体的に見ていきましょう。

1. システム要件

現状の業務フロー、新規の業務フローとそのギャップを踏まえ、それらをどのようにシステムに落とし込んでいくのか、システム開発の方向性を決める作業が「システム要件」です。

具体的には、洗い出した新規業務フローから、システム化するもの、しないものを選別していきます。これは、発注者の望む業務要件と、システム開発会社側で実現できるシステム要件が異なるため。

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

2. 機能要件

システム要件で決定した方向性をもとに、クライアントの望む機能をどのように実装していくか、システム開発の「How」にあたる要件を決めていく作業が「機能要件」です。

具体的には、システムの機能・構造やデータの種類、処理可能な内容などを定義していくことが一般的。以下の表のように、要件定義書に記載される各種要件を定義していく作業だと考えれば間違いないでしょう。

3. 非機能要件

「非機能要件」とは、システム要件・機能要件など、機能面以外で検討すべき、すべての要件のことを意味します。

具体的には、システムのパフォーマンスや拡張性などの重要な要件も「非機能要件」となります。システムが不安定、セキュリティが甘くて情報漏えいしたといったことにならないよう、しっかりと要件定義しなければなりません。

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

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

注意 非機能要件をすり合わせる場合は、イメージ画像で伝えることは難しいです。なので、非機能要件になぜそうするのかを明記してもらうようにしましょう。

例を上げると「サーバ構成は○○にしておきます。ピーク時は同じ時間帯に1000人程度のユーザが利用することが想定されるため、そのアクセスに耐える場合はその程度考えておく必要がある」と言った形です。

4. 技術要件

IPAの非機能要求グレードとは別に、近年では開発にどのような技術を用いるかという「技術要件」を設定するケースも増えています。

具体的な内容としては以下が挙げられます。

• システムのベースとなる「プラットフォーム」
• 特定のフレームワークなどの「採用する技術」
• システムを構築するために活用される「開発言語」
• 採用する「データベース」

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

5. サイト要件

サイト要件とは、Webサイトの構成のことを言います。要件定義の際は、以下の内容を記載し、どのようなWebサイトにするのか示すことが重要です。

• カテゴリ
• ディレクトリ構造
• ページのタイトル
• サイトの概要（ディスクリプション）
• 対象のOS（iOS・Android・Mac・Windowsなど）
• 対象のブラウザ（Safari、Google Chrome、Firefoxなど）
• リダイレクトの一覧（サイトリニューアルの場合）

ボリュームによっては、要件定義とは別の資料としてまとめることもあります。

Webサイトを利用してもらうためにも、ユーザーからヒアリングを重ねどういったサイトにすべきか明確にしましょう。

6. インフラ要件

インフラ要件とは、以下のようなシステムの環境を支える技術のことです。

• サーバ
• ドメイン
• SSL証明書
• データベース
• ネットワーク

上記を想定されるシステム要件や、拡張性などのバランスを考えたうえで組み立てていきます。そのため、インフラに関する幅広い知見が必要です。

高性能なものはコストがかかるため、ユーザーニーズをもとに適した要件を定めなければいけません。

また、サーバやドメインの取得を発注者側と受注者側のどちらが行うかも重要なため、要件定義書に記載しましょう。

7. セキュリティ要件

セキュリティ要件は、システム開発の初期段階に定めるセキュリティ目標のことです。具体的には、以下のような項目です。

• セッションタイムアウト
• データベースの脆弱性対策
• 漏えい対策（SSL対応やIP制限など）

セキュリティ要件は初期段階に定めなければ、開発後のシステムにセキュリティ上の欠陥が生じる恐れがあります。

システム開発では機密情報も扱うため、情報漏洩やウイルス感染を防ぐ上でセキュリティ要件は重要です。

8. その他の要件

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

※もし自社の開発では何を検討しておけばいいのか迷った方は「システム幹事」へご相談ください。
システム開発の知見が深い担当者があなたのご状況にあわせて、要件定義、費用相場、開発会社への依頼のポイントなど必要となる情報をアドバイスさせていただきます。

【無料】要件定義について専門家に相談する

システム開発の要件定義を行うための事前準備

システム開発の要件定義をいざ実施してみると、話がなかなか進まなかったり漏れに気づかず進めたりといった問題が発生することもあります。

要件定義を円滑に実施するには、以下のような事前準備が重要です。

1. 業務内容を分析する
2. フレームワークを把握し要件定義漏れを防ぐ
3. 必要なスキルを身につける

1. 業務内容を分析する

要件定義を実施しようとしている業務内容について分析し、理解を深めましょう。業務内容を分析することで、より正確な要件定義を行えます。

仮に製造業で要件定義を行う場合、以下のような知識が必要です。

• 業務知識（工場内の設備や加工技術について）
• 生産管理の知識（行程管理や資材管理など）

業務内容をよく理解していれば、何が必要なのかが分かり要件定義がスムーズとなります。要件定義は、業務内容について十分理解した上で行うことが大切です。

2. フレームワークを把握し要件定義漏れを防ぐ

要件定義漏れを防ぐために役立つ、フレームワークの種類を把握しておくのがおすすめです。フレームワークを使うことで、要件定義漏れを未然に防ぐことができるためです。

例として、フレームワークのひとつに「5W2H」があります。

• why：システムを開発する理由
• what：開発するシステム
• where：開発範囲
• when：システムの完成予定
• who：プロジェクトの役割
• how：作成方法
• how much：必要な開発費用

上記の質問に答えていくことで、システム開発に必要な要素を漏れなく把握可能です。

要件定義漏れがあると、スケジュールの遅延や追加予算が発生することもあります。フレームワークを活用し、要件定義漏れの防止に役立てましょう。

3. 必要なスキルを身につける

要件定義を行う担当者は、必要なスキルを身につけておきましょう。スキルが不十分な状態では、要件定義をスムーズに行えません。

要件定義は、システム開発を行う上で最も重要な作業工程です。要件定義を十分にできていなければ、開発したシステムが役に立たなかったり予算オーバーしたりしかねません。

システム開発が失敗する恐れが高まるため、必要なスキルを身につけた上で要件定義を行うことが大切です。

具体的にどういったスキルが必要なのかは、次の見出しで詳しく解説します。

要件定義を行う上で必要な4つのスキル

要件定義を問題なく作成するために必要なスキルを紹介しておきましょう。

1. 要求のヒアリングスキル

先に紹介しているように、要件定義を明確につくっておき、不明点がなくなるように丁寧に質問しておくなど、相手から情報を引き出すスキルが求められます。

質問・ヒアリングのためにはある程度の「想定力」も求められますので、社内の専門家に協力してもらうなどして質問を整理し、ヒアリングの準備をしておきましょう。

2. 現実的なシステムに落とし込むスキル

「こんなシステムを実現したい」と言っても、現実的にシステムとして構築できなければ机上の空論で終わってしまいます。

現代の技術で実現する思考力も必要ですが、予算、人的リソース、実現するまでの納期などとあわせて総合的にシステムを実現するスキルが必要になります。

システムを実現可能にできるかは、開発会社の実績数（場数）によるところが大きいので、構築したいシステムの実績が多い開発会社に相談してみるとよいでしょう。

3. 開発プロジェクトのスケジュール化スキル

要件定義をもとに、開発工程を具体化させるスキルも必要です。

システム開発は多くの人を巻き込み、多くの時間を投資することになるため、いかに効率的な開発ができるかが重要となります。一方で、予期せぬトラブルに見舞われた時のためのバッファ（余裕）を取っておく必要もあり、工程作成にはバランス感覚も求められます。

品質の高いシステムを作れるように、スケジュールについて発注者・開発会社間で交渉することもありますので様々な状況を想定して工程を組めることが重要です。

4. 要件をわかりやすい文書にまとめるライティングスキル

固めた要件定義を「誰でもわかる」かつ「認識の齟齬がおきない」ように文書としてまとめるスキルも求められます。

要件定義書を作成しても、複数のとらえ方ができてしまうと、発注者と開発会社の認識のズレを生みトラブルに発展する可能性が出てくるためです。

誰にでもわかりやすく、他の解釈の余地が無いよう明確な文書としてドキュメントを作成できるライティングスキルも要件定義では重要です。

システム開発の要件定義の進め方

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

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

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

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

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

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

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

②要求定義（ヒアリング）

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

• 「○名が同時にアクセスして××を1秒以内に並列処理できるシステム」
• 「○○ボタンをクリックすると、××と△△を処理できる機能」

といった具体的な表現であれば問題ありません。ここまでの分析結果を「RFP（提案依頼書）」としてまとめておけば、複数の開発会社に提案・見積もりを依頼する場合にも役立ちます。

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

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

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

注意 要件定義で失敗するケースでよく見るのが、すり合わせたつもりになっていること。開発会社は「わざわざすり合わせなくても大丈夫だろう」や「話をしている感じで認識が揃っているだろう」と思っている場合があります。

エンジニアと非エンジニアで見えていることが全然違うので、丁寧すぎるくらい説明してもらいましょう。要件定義時に時間を掛けることであとの修正が減るのでトータルで考えるとコスパは良くなるはずです。

※もし要件定義の進め方がわからない方は「システム幹事」へご相談ください。
システム開発の知見が深い担当者があなたのご状況をヒアリングし、要件定義はもちろん、費用相場、開発会社への依頼のポイントなど必要となる情報を無料でアドバイスさせていただきます。

【無料】要件定義について専門家に相談する

「要件定義書」の作成も重要！作成手順を解説

「要件定義書」は要件定義の内容をまとめた書類であり、開発内容を分かりやすく伝えるために重要となります。

作成手順は、以下のとおりです。

1. 利害関係者の確認
2. ユーザーからのヒアリング
3. ビジネス目標を把握
4. 初期要件・非機能要件の確認
5. 要件を細分化
6. 現実案を作成
7. 要件定義書を作成

1. 利害関係者の確認

システム開発における利害関係者を確認しましょう。

要望を聞いていない関係者がいたり、一部関係者の意見ばかりを反映していたりすると、不満が高まり要件定義がやり直しになるかもしれません。

利害関係者の確認時は、特性についても調べておく必要があります。一例を以下の表にまとめました。

特性についても把握することで、双方が満足できる要件定義をまとめられます。

利害関係者とその特性を確認することで、円滑な要件定義が可能です。

2. ユーザーからヒアリング

ユーザーからヒアリングし、どのようなニーズがあるのか把握しましょう。要点定義はユーザーの要求をシステムに反映するためのものなので、ヒアリングが重要となります。

ヒアリングの注意点は、ユーザーの要求全ては受け入れないことです。要求を全て受け入れていると、開発スケジュールを圧迫しかねません。

システム開発では、発注者からの要求を実現できるか吟味した上で、適切な開発スケジュールを立てる必要があります。

円滑なシステム開発のためにも、ユーザーからのヒアリングは入念に行いましょう。

3. ビジネス目標を把握

システム開発におけるビジネス目標を把握しましょう。ビジネス目標を理解できていないと、要件の本質を見誤ったり要件絞り込みの優先順位を間違えたりする恐れがあるためです。

ほとんどのシステム開発には、作業効率化や売上向上などの目標が設定されます。しかし発注者側には当たり前すぎる内容のため、資料に専門知識を用いて記載されたり記載そのものがなかったりします。

ビジネス目標を把握していないと、満足のいくシステム開発や円滑なプロジェクト進行ができません。

システム開発は、ビジネス目標を把握した上で行いましょう。

4. 初期要件・非機能要件の確認

システム開発の初期要件と非機能要件を確認しましょう。RFPや関連ドキュメントから確かめることも可能です。

初期要件を確認した結果、利害関係者の中で要件の内容やレベル感が異なる場合もあります。その際は関係者と調整し要件をまとめ、落としどころを見つけなければいけません。

また、非機能要件には、以下表のように幅広い内容が含まれています。

情報システム部門だけでなく、業務部門のように他の利害関係者との調整が必要な場合もあります。

5. 要件を細分化

要件を細分化し、絞り込んでいきましょう。発注者の要求を全て実現できるとは限らないため、優先順位をつける必要があります。

システム開発は、必ず実現したい「必須要件」と、可能であれば実現したい「希望要件」の2つに分けられます。要件を細分化することで、要望の漏れなく開発を進められるでしょう。

要件絞り込みの判断基準は、以下のようなものです。

• コスト
• リスク
• 法令対応
• 依存性
• ビジネス価値
• 安定性

絞り込んだ要件は、ビジネス価値や経営貢献度などから優先度をつけていきます。ビジネス価値が低い要件は、思い切って削減提案することも重要です。

6. 現実案を作成

制約条件・前提条件をもとに現実案を作成します。それぞれの概要は、以下の通りです。

• 制約条件：予算や納期、契約事項など
• 前提条件：開発側が発注者から提供を受けることを前提としている内容

制約条件から要件を絞り込むこともありますが、ある程度柔軟に対応できるため、やるべきことをまとめた上で整合性を整えるのが有効です。

また、前提条件の多くは開発側に都合の良い内容です。そのため、前提が満たされるかどうか要件定義の時点で確認しましょう。

7. 要件定義書を作成

ここまでの流れをもとに要件定義書を作成します。発注者側の利害関係者に確認していただくため、理解しやすい形での文書化が不可欠です。

要件定義書にまとめるべき内容を以下の表にまとめました。

システム開発の基盤になるため、矛盾がなく分かりやすい内容にすることが重要です。開発の知識がなくとも理解できるよう、専門用語は省くようにしましょう。

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

システム開発の要件定義の事例（成果物サンプル）

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

まずは、実際の要件定義書を公開します。上記はWebサイト制作の要件定義書になりますが、システム開発でも基本的には同じです。上記は要件定義の目次であり、そこから企業の課題や強み、どんなサイトにするかの設計図などを決めていきます。

実際の要件定義（動画幹事）

※動画幹事はその後リニューアルしているため現在のサイトとは異なります。

続いては、動画制作を考えている方に最適な制作会社を紹介するマッチングサービス「動画幹事」のWebサイトを作ったときの要件定義書の一部を公開します。要件定義の内容は企業秘密が多く、あくまで要件定義の一部であることをご了承ください。どんなことを決めるのかのイメージの参考にしてもらえれば幸いです。

要件定義の概要

要件定義を行なった際の大まかな流れと、その日に決めることです。事前に競合情報などもリサーチした上で行います。

サイトマップ

サイトマップとは、そのサイトにどんなページが存在するのかのサイトの地図、設計図のことです。きちんとサイトマップが整理されていないと、訪問したユーザーが使いにくい構造になっていたり、本来必要なページがなかったり、逆に不要なページが入っていたりします。

ただし、サイトマップは要件定義では決めず、その次の工程である「基本設計」で決める場合もあります。

サイトのカラー

続いては、サイトのカラー、配色を要件定義で決めたものです。メインカラーや下層ページ、コンテンツの目次や見出しの色など、様々なパターンを決めます。これも要件定義ではなく、次の工程で決める場合もあります。

コンテンツ

最後はコンテンツです。動画幹事は制作会社の情報ページ以外にも、動画制作の費用や作り方などのノウハウを解説した記事が沢山あります。作った記事は、GoogleやYahoo!などの検索エンジンで上位表示されることを狙うため、どんなキーワードで検索されるのかの候補を挙げています。

【無料】要件定義についてプロに相談する

（参考）システム開発の要件定義で使われるツール

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

仕様を確定するまでのミーティングでも活用されるため、各種ツールがどのようなものなのか？概要だけでも把握しておくことが重要。

ここでは参考として、代表的な要件定義ツールを簡単に紹介していきます。

機能情報関連図

画像引用：総務省

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

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

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

業務フロー図

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

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

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

ER図

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

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

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

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

システム開発の要件定義のコツ・注意点

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

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

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

要件定義を明確に定められない原因の一つに、発注者と開発会社との認識のズレが挙げられます。認識のズレは、双方によるコミュニケーションが不足していることによって起こることがほとんどです。

開発会社は「わざわざすり合わせなくても大丈夫だろう」「話をしている感じで認識が揃っているだろう」と思っている場合もあります。必要のない機能を入れてしまったことで予算が膨らむなど、後悔の原因になります。

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

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

2. 設計へ移る前に要件定義書の読み合わせで認識のズレをなくす

本記事で何度もお伝えしていますが、要件定義の認識が発注者と開発会社でずれておりトラブルになるケースがあります。

開発の専門家とそうでない人で認識をすり合わせる場合も多くあり、双方の「当たり前」が異なるために引き起こされるトラブルです。

作成した要件定義書は事前に発注者と開発会社とで読み合わせを行い、不明点はかならず質問して理解をし、認識のずれを無くしておきましょう。

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

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

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

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

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

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

※もし要件定義の作成でわからないことがあれば「システム幹事」へご相談ください。
システム開発の知見が深い担当者があなたのご状況をヒアリングし、要件定義はもちろん、費用相場、開発会社への依頼のポイントなど必要となる情報を無料でアドバイスさせていただきます。

【無料】要件定義について専門家に相談する

要件定義以降の開発はどう進める？

要件定義が終わりましたら、以下の流れで開発を進めていきます。

1. 設計
2. プログラミング
3. テスト

1. 設計

システムの設計は「基本設計」と「詳細設計」の2つに分けられます。

基本設計は、要件定義で決定した要求事項を実現するため、業務フローや画面レイアウトなど全体の概要を考えていく作業です。

一方詳細設計は、基本設計をより細かくしたもので、データ処理の流れやプログラムの構造などを記載していきます。

詳細設計が作り込まれていると、記載内容に従って後述のプログラミングを行えば良くなり、作業がスムーズになります。

2. プログラミング

プログラミングは、詳細設計書に従って行います。最も優先すべきなのは、詳細設計書通りに作成することです。

プログラミングはチームで行うことが多く、個人のやり方を優先するとプログラム全体の統一感が生まれません。

設計書通りに行うため、メンバー同士でレビューし合うのも良いでしょう。

また、誰が読んでも理解できるようにコメントで補足するのも有効です。コメントが多すぎても読みづらいため、書くところは適切に判断しましょう。

3. テスト

プログラミングの後に行うテストは、以下4つの種類があります。

受け入れテストまで実施し、問題がなければシステムをリリースします。

システムの不具合はクレームにもつながるため、入念にテストを実施し問題がないことをよく確認しましょう。

※無料でダウンロードできる中小企業向けシステム開発の進め方をご用意しています。こちらもあわせてご活用ください。

システム開発依頼前にチェック！ 中小企業向けシステム開発の進め方をまとめました。
無料でダウンロードする

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

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

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

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

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

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

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

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

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