システム開発の要件定義とは?受託開発における重要性や進め方を解説!

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

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

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

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

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

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

目次
  1. 1. システム開発における要件定義とは
    1. 1-1. 要件定義が重要な理由
    2. 1-2. システム開発における要件定義の位置付け
    3. 1-3. 「要求定義」との違い
    4. 1-4. 要件定義書の重要性
  2. 2. 要件定義で使われるツール
    1. 2-1. 機能情報関連図
    2. 2-2. 業務フロー図
    3. 2-3. ER図
  3. 3. システム開発の要件定義で決めること
    1. 3-1. システム要件
    2. 3-2. 機能要件
    3. 3-3. 非機能要件
    4. 3-4. 技術要件
    5. 3-5. その他の要件
  4. 4. 要件定義の進め方
    1. 4-1. システム開発の企画・業務設計
    2. 4-2. 要求定義
  5. 5. システム開発における要件定義まとめ

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

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

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

つまり、システム開発における要件定義とは「どんなシステムを開発するのかを見える化すること」。発注者の希望を叶えるために必要な機能などを明確にする作業です。具体的には下のような項目を決めます。

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

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

要件定義が重要な理由

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

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

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

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

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

システム開発の流れ・工程

開発工程

概要

企画

どんなシステムを作って欲しいか企画する(発注者側が行う)

要件定義

発注側のニーズ・要求を実現可能なシステム要件に落とし込む

設計

要件定義をもとにシステムの見える部分を具体化・設計(外部設計)

開発

開発されたシステムが正しく動くかテストする

リリース

検収を経てシステム稼働

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

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

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

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

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

「要求定義」との違い

要求定義

要件定義

システム開発によって

実現したい希望を明確にする

発注者の希望を叶えるために

必要な機能などを明確にする

発注者側が行う

開発会社が行う

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

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

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

要件定義書の重要性

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

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

関連記事システム開発の詳細設計とは?プロジェクトの位置付け・役割をわかりやすく解説!

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

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

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

機能情報関連図

機能情報関連図

画像引用:総務省

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

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

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

業務フロー図

業務フロー図

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

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

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

ER図

ER図

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

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

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

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

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

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

システム要件

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

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

機能要件

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

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

システム機能要件

システム機能階層図

画面要件

画面一覧

 

画面遷移図

 

画面レイアウト

帳票要件

帳票一覧

 

帳票レイアウト

バッチ要件

バッチ処理一覧

データ要件

テーブル関連図(ER図)

 

エンティティ一覧

 

エンティティ定義

外部インターフェース要件

外部システム関連図

 

外部インターフェース一覧

 

外部インターフェース定義

非機能要件

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

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

非機能要求項目

概要

要求例

可用性

(アベイラビリティ)

システムを継続的に

利用可能とするための要件

運用スケジュール、

障害・災害時の稼働目標

(ダウンタイム)など


性能・拡張性

システムの性能、将来的な

拡張に関連する要件

業務特性を見越した性能目標

業務量の増加・変化への対応力


運用・保守性

システムの運用・保守

サービスに関連する要件

運用中の稼働レベル、問題発生時の対応

監視手段・バックアップの方法など


移行性

既存システムのデータ資産などの

移行に関連する要件

新システムへの移行スケジュール・方法

データ資産の種類・移行量など


セキュリティ

システムの安全性に

関連する要件

ログイン・アクセス制限などのシステム利用制限

不正アクセス防止の方法など

システム環境・エコロジー

システムの設置環境や

エコロジーに関連する要件

耐震・重量・温度・騒音

CO2排出量・消費エネルギーなど

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

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

技術要件

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

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

その他の要件

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

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

要件定義の進め方

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

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

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

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

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

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

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

要求定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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