システムの要件定義とは？ 重要性や注意点を解説

発注者の要求をまとめ、受注者がシステム要件にまとめる作業を要件定義といいます。

システム開発における要件定義はシステム設計や実装作業の前に行われる工程です。要件定義では、システムを作る目的と必要性を明確にして、発注者がどんなシステムを使いたいかを分析します。さらに、システム実装に必要な機能などの要件を明文化します。

発注者はシステムのイメージ像を受注者に具体的に伝える必要があります。受注者は発注者の要望を正しく理解し、要求を具現化しなければいけません。そのためには、発注者と開発者で頻繁にコミュニケーションを取ります。また、受注者はスケジュール管理を十分に徹底し、予定通りにシステム開発を完成させなければなりません。

システム開発における要件定義の流れ、要件項目、用いられるツールについてはこちらの記事で詳しく解説していきます。

システムの要件定義とは

要件定義は英語でRequirements Definitionといい、略してRDと呼ばれることがあります。システム開発で盛り込む機能を要件として定義し、それらのシステム要件を要件定義書にまとめていきます。要件定義を行う工程をRD工程ともいいます。

　システムの要件定義では、発注者の現状の悩みや戦略を把握し、問題やニーズを掘り起こします。その問題やニーズを元に対策を検討し、機能として実装する業務を取り上げます。機能要件と非機能要件をまとめ、データ構造やインターフェースを概略設計していきます。最終目的地である運用までのスケジュールを立て、システムプロジェクト構築をします。

要求定義との違い

要件定義以外に類似の言葉として要求定義という言葉があります。この要件定義と要求定義には明確な違いがあり、正しく意味を理解する必要があります。

要件定義は受注者が実施するもので、発注者の問題やニーズへの対策を具体的にシステムに盛り込むために要件を明確化します。

一方で、要求定義は発注者が抱える問題やニーズを受注者に伝え、システム化の目的や運用イメージを明確にすることです。発注者はシステム開発に慣れてないことが多く、受注者がヒアリングを実施して要求定義をまとめていくことが多いです。

発注者と受注者で密にコミュニケーションを取り、要求定義と要件定義をそれぞれ明確にしていきます。

ソフトウェアの要件定義との違い

ソフトウェアの要件定義は、システム開発における重要な土台を定義することを意味します。開発をする前に「どのようなプログラムをシステムに盛り込むのか」「プログラミング工程がどれくらい要するか」「どのくらい人件費が発生するのか」などを明確にするためにソフトウェアの要件定義が必要です。

また、受注者はシステム開発をベンダーに丸投げせずに、「自社がシステム開発に必要なツールを持っているか」「適切な担当者はいるか」などの自社リソースの確認作業もしなければなりません。

システム要件と違い、ソフトウェア要件では、具体的なシステム構築に向けて必要なリソース要件を定義することが肝要になります。この違いを正しく理解しましょう。

要件定義の重要性

要件定義は発注者の問題やニーズからシステムを具体化させる重要な開発フェーズになりますので、この要件定義に具体性・実現性がどれだけ入るかによってシステムの完成度が変わってきます。

この要件定義を手抜きしてしまうと、後工程の内容がすべて曖昧になってしまいます。そうすると、システム設計や試験において不明確な箇所が多くなってしまい、想定以上にシステム開発に時間がかかってしまいます。

要件定義の重要性を認識し、焦らず他の工程よりも十分に時間をかけて定義を決定していきましょう。

要件定義の流れ

続いて、要件定義をまとめるのに必要な流れについてご紹介していきます。どんなシステム開発プロジェクトにおいても最初の工程が要件定義となるので、今回ご紹介する流れを第一にマスターすることをオススメします。

流れ①ヒアリング

開発するシステムを運用する発注者へのヒアリングは、要件定義書を作成するうえでベースとなります。発注者からシステムに盛り込みたい機能や悩んでいる内容などを聞き出し、文書化していきます。

ヒアリングが十分に行われないと、システムの機能が十分に盛り込めなかったり、納品後に発注者のイメージと違うという理由で検収されなかったりするため、十分に内容を確認することが求められます。

ヒアリングのフェーズでは、機能以外にも保守サービスやセキュリティ対策についても打合せすると良いです。発注者は後から仕様を追加することも多く、運用イメージができるよう具体的なシステム構成を説明し、発注者の思いや心配を引き出しておきましょう。言葉にできない要求もあるため、きちんと発注者の声に耳を傾けて意図を汲み取るようにしてみましょう。

流れ②機能要件の定義

次にシステムに必要な機能要件を定義していきます。機能は、発注者の要望をシステム化したもので、必ず搭載すべきサービスや挙動になるものです。主に発注者の要求分析や要件定義の工程で具体化されて決定されます。

機能要件は発注者が必須と考える項目であるため、システムが機能要件を満たしていなければ、プロジェクトは必ず失敗します。発注者にとって機能要件は「必ず実装されるもの」であって最低限必要な要求であるため、機能要件通りにシステム化されても発注者は満足することはありません。

流れ③非機能要件の定義

機能要件が確定したら、非機能要件を定義していきます。非機能要件とは、システム構成における機能要件以外のもの全般を指します。これには可用性、移行性、セキュリティ、システム環境などに関する要件が挙げられます

非機能要件は、システムの機能に直接影響しませんが、システムのパフォーマンスに大きく影響します。そのため、非機能要件を詳しく高いレベルで定義できれば、システムは発注者にとって使いやすいものになり、発注者の満足度増加につながります。

流れ④プロジェクト内容の決定

機能要件と非機能要件が決まったら、プロジェクト内容について決定していきます。プロジェクト内容は以下の5つに分けられます。

• プロジェクトスコープの定義
• 人的リソースの見積もり
• スケジュールの決定
• コストの見積もり
• リスクアセスメントの実施

システム化範囲を決め、人やコストの見積を実施してプロジェクト全体像の概算をします。プロジェクトリスクを抽出して実行可能な工程であることをプロジェクトマネージャーと相談して全体の計画を決定します。「ヒト、モノ、カネ、ジカン」が限られる中、いかに効果的に発注者が要求するシステムを構築することができるかによって、プロジェクトの成果が大きく変わってきます。

プロジェクト内容が決定したら、発注者に一度プロジェクト全体像を説明して合意を取るようにしましょう。あまりにも開発期間が長いプロジェクトや、コストが高いプロジェクトは発注者が嫌います。発注者にとってもリーズナブルなプロジェクトを提案することが、プロジェクト内容確定の近道となります。

流れ⑤要件定義書の作成

発注者が求める内容をヒアリングし、要求内容の整理を行ったら、これまでに決まった内容を要件定義書に落とし込んでいきます。落とし込む際の内容として次の8つのものが挙げられます。

• システムの概要
• 導入目的
• 発注者の要求
• 機能要件
• 非機能要件
• サイト要件
• インフラ要件
• セキュリティ要件

以上の内容がシステムの開発における設計図となります。肝要なシステム要素となるため、手を抜かずに正しく定義しましょう。

要件定義書で定義する内容

ここからは要件定義書で定義しなければいけない内容を具体的に解説していきます。要件定義と言っても様々な要件がありますので、一つ一つの要件範囲を丁寧に決めて定義していきます。

機能要件

機能要件ではヒアリングをして発注者から引き出した問題やニーズを解決する方向性に基づいて、発注者が要望する機能をどのようにシステムに実装していくかを決定していきます。

機能に必要なシステム構造、処理方法、データ種類などを定義していきます。例えば、システム化する業務範囲の確定、インプットからアウトプットまでの処理方法、数字・アルファベット・桁数などのデータ型の選定などです。普段の業務イメージを具体的な形や数字に落とし込んで複数の機能を作り上げていきます。

非機能要件

非機能要件では機能面以外で必要となる要件を定義していきます。非機能要件にはシステムの可用性や保守性などが含まれます。

非機能要件はシステム構成に必要な細かな設計が含まれており、ユーザーが普段気にしないバックグランドの設計が特徴です。そのために非機能要件の項目の設定に悩むエンジニアが多いのも事実です。ここでは6つの非機能要件についてご紹介します。

• 可用性：システムを継続的に利用するための要件
• 拡張性：将来的拡張に関連する要件
• 保守性：保守サービスに関係する要件
• 移行性：既存システムのデータ資産などの移行に関係する要件
• セキュリティ：システムの安全性に関連する要件
• システム環境：システムの設置環境

上記の非機能要件を発注者の環境に合わせて構築していきます。

サイト要件

サイト要件はターゲットユーザー、ターゲットOS/ブラウザ、サイトマップの3つについて定義していきます。

ターゲットユーザーは、発注者の従業員、客、システム管理部門などの開発するシステムのユーザーを定義します。システムを不特定多数の人が利用できないよう、ログイン方法を検討し、利用人数に応じたライセンス数の確認をしておきましょう。

ターゲットOS/ブラウザについては、システム開発で使用するOSとブラウザを定義します。一般的に馴染みが深いwindowsがOSに選ばれ、必然的にブラウザはedgeになることが多いです。ただし、発注者によってはgoogle chromeなどのブラウザを要望することがあるため、発注者に合わせて設計を見直しましょう。

サイトマップは、システムサイト全体のページ構成をマップのように一覧で記載しているページのことを指し、ホーム画面を中心にサイトマップ構成を定義していきます。サイトマップ作成に際して、発注者のシステム構成のイメージをヒアリングし、システム全体像からサイトマップを作成していきましょう。

インフラ要件

どのようなインフラが必要なのか発注者にヒアリングをして要件定義を行っていきます。

システムに必要なインフラ情報は、実際にシステム管理をしている担当者か、これから開発するシステムを管理する担当者に確認します。システムが動作する環境について聞き取りを行います。

障害対応のために最低限は知識が要することもあり、PC、アプリ、配置、配線などのインフラ要件について説明し、維持管理できるか確認しておく必要があります。

また、トラブルシューティングを想定してデバックや開発環境などのインフラ条件を整えておくことは大切です。発注者には現状のシステムインフラを確認し、流用できるシステムはインフラ要件に盛り込むようにしましょう。

セキュリティ要件

セキュリティ要件は、システムの安全性に関連する要件を定義することです。

ログイン手順、パスワード定義、システムへのアクセス制限などを定義します。近年ではサイバー攻撃が多様化していることから、最新のウイルス対策情報を取得しなければなりません。

セキュリティ事故が起こった際は、システム開発におけるセキュリティ責任を問われることがあるため、事故時の保証範囲についてもセキュリティ要件に定義することが肝要となります。

要件定義で用いられるツール

要件定義するうえで便利なツールをご紹介します。これらのツールを効果的に使用することで、システム構成における課題や全体像がより鮮明になります。

今回紹介するツールは要件定義で使用される基本的なツールとなるため、様々なシチュエーションにおいても利用することができます。

機能情報関連図（DFD）

機能情報関連図は、システムする業務のフローや業務同士の関係性を明確化したもので、DFD（Data Flow Diagram）と呼ばれます。

DFDを使用することで業務全体を把握し、問題点や改善できる点を抽出することができます。システム開発ではDFDを使用し、業務システム化の対象範囲の把握をしたり、プロジェクトにおいて問題となっている機能を特定したりすることができます。

ER図

ER図はEntity Relationship Diagramを略した言葉であり、開発するシステムで取り扱うデータを項目でまとめ、図で明文化したものです。システムが処理するデータ同士の関連性を表したもので、データベースの元となるものとして活用されます。

例えば、注文テーブル、顧客テーブル、商品テーブルなどの項目ごとにテーブルを作り、それらの項目に属するデータの紐づけ関係をER図として表現していきます。

業務フロー図

DFDから実際の業務に落とし込み、業務をフロー図で表現したものを業務フロー図と呼ばれます。

業務フロー図は業務の手段を明文化したものです。業務フロー図には、人による業務とシステムによる業務を分けて記載します。

要件定義では、現在の状態がどうであるかを表す「As-Is」の業務フローを作成し、あるべき姿の状態を表す「To-Be」の業務フローを作成します。現在とあるべき姿のギャップが課題であるため、その課題を解決するための方法を考えます。

要件定義の注意点

要件定義でつまずくとプロジェクトが失敗してしまうため、要件定義は厳格に定義していかなければなりません。次に注意すべきポイントを挙げていますので、取り上げた注意点を抑えていきましょう。

注意点①目的を明確にする

第一の注意点は目的を明確にすることです。目的が不明確だと、開発したシステムが発注者の要望するシステムになりません。

システムの開発目的を最初の要件定義の段階できちんと明確にし、一気通貫で目的達成のためにシステム開発をすることが重要です。

要件定義において、発注者からのヒアリングを通じて様々な悩みや問題が共有され、受注者もすべての要望を叶えようと努力します。しかし、すべての要望を盛り込もうとして、目的が不明確になってしまってはシステム開発プロジェクトが失敗してしまいます。

プロジェクトマネージャーと相談して、システム機能の取捨選択を確実に行ってください。

注意点②現行システムを確認する

業務フロー図であるべき姿を文書化したとしても、それが確実に実装できなければ意味がありません。新しい端末やアプリを入れてあるべき姿を実現することができれば問題ないですが、すべて新調するとコストがかかるため、コスト削減のために現行システムを流用することが多々あります。

ただし、現行システムを利用する場合は、新システムと互換性があるか、データ容量が十分かなどを詳細に調査する必要があります。現行システムを管理している担当者と複数回打合せを実施して受注者は内容を細かに把握しなければなりません。

注意点③要件定義書の読み合わせを実施する

一番肝心な注意点は要件定義書の読み合わせです。

いくら要件定義書を完璧な状態に仕上げたとしても、その内容を発注者が理解していなければ、開発したシステムのクレームにつながります。

要件定義書の読み合わせは最低でも３回は実施し、発注者と受注者の認識のすり合わせを行います。読み合わせが足りないと、担当者間の意思疎通が十分に行われず、設計の段階で勘違いミスを発生させてしまいます。

要件定義に必要なスキル

要件定義は0から1を作る作業で、普段はなかなか馴染みがないため、初心者は有意な要件定義を提案できないことが多いです。ここでは、要件定義に必要なスキルを列挙していきます。

コミュニケーションスキル

要件定義は、発注者からヒアリングにより要望を聞き出すため、人と密にコミュニケーションできるスキルが重要となります。

発注者はシステムに疎いことが多く、要望をすべて明確に表現することはできません。そこで、受注者がコミュニケーションを通じて事細かに情報を引き出してあげることが肝要です。

要件定義書を作成することで、聞き出した内容を文書化し、発注者と要求内容と突き合わせを行っていきます。その過程において、不明確で曖昧な部分を潰していきます。後工程のシステム設計でつまずかないように、要件を的確に定義するコミュニケーションスキルが求められます。

具体的なイメージをもつスキル

要件定義は発注者の漠然としたイメージを具体化する作業です。

システムを構築するときに漠然としたプログラムでは動作はしないため、具体的なプログラムを作らなければなりません。そこで必要となるスキルが、具体的なイメージをもつスキルとなります。

要件定義において、単純に発注者の要望を文書化するのではなく、発注者の発言の意図を汲み取り、具体的なシステムの入力やデータの連携方法をイメージしていきます。このイメージがより具体的であればあるほど、プログラムのコーディングがより正確なものになっていきます。

具体的なイメージは、様々なシステム構築経験を積むことで培われるため、ある程度の場数を踏むことが要求されます。

スケジュールを管理するスキル

システム開発は決められた期間内に完了することが求められるため、スケジュール管理が重要になります。

システム開発には、要件定義、システム設計、プログラミング、テストなどの様々な工程があります。期間内にシステムを完成させるために各工程の必要日数から逆算して、プロジェクト全体の日数を算出していきます。

システム製作する上で、想定外トラブルが発生することもあるため、ある程度余裕を持ったプロジェクト工程を組むことがポイントです。

また、納期を意識して適宜工程進捗を確認します。プロジェクトスケジュールが予定通りに進捗しているか管理するスキルが必要であって、開発工程が遅延している場合は、その工程をフォローアップしなければなりません。

ドキュメント化のスキル

発注者の要求を正確に要件定義する上で、一番重要なスキルはドキュメント化のスキルです。

システムに関する文書は発注者や受注者だけでなく、システムを運用・保守する担当者も読むことになります。専門用語ばかりを並べていても、システムに疎い発注者は文書を読むことができないため、一般的な言葉に置き換えて分かりやすく文書化することが求められます。

また、システム開発において、要件定義書だけでなく、データベース仕様書、帳票仕様書、試験要領書など様々な文書が作成されます。これらの文書でバラバラの言葉を使ってしまうと、読み手が混乱してしまうために言葉の統一化することも意識しなければいけません。

システム要件定義に悩んでいる方におすすめ

システム開発をする上で、要件定義を明確にして発注者が要望するシステムを実現するために、担当者間のコミュニケーションが必須となります。
受注者側のシステムに関するスキルは当然要求されますが、発注者もシステム開発について基本的な知識を身につけてください。
本記事でご紹介したシステム開発における要件定義の流れ、要件項目、用いられるツール、ポイントとなる注意点、必須となるスキルをフル活用して、システムを導入していきましょう。正しく理解して知識を付けていけば、プロジェクトの失敗を回避することができます。

システム開発の要件定義に悩んだ際にはEMEAO!へのご相談を一度ご検討ください。