「要件定義」は, システム開発 における重要な工程の1つです。
適切な要件定義をおこなわないと、開発の方向性が当初の目標と大きくズレたり、開発途中で大きなトラブルを起こす可能性があります。

このように重要な工程である要件定義ですが, システム開発 の依頼を希望されている方や開発初心者の方の中には、具体的な内容があまりわからないという方もいらっしゃるのではないでしょうか。

そこでこの記事では要件定義の概要から実際の作業内容まで、全体像を把握できるよう網羅的に解説します。

システム開発をスムーズに進め、良いサービスや商品を作るコツが詰まった内容となっていますので、ぜひ参考にしてください。

目次

• システム開発における要件定義の概要
• 要件定義がシステム開発の工程の中で重要視される理由
• システム開発における要件定義で決める内容
• システム要件
• 機能要件
• 非機能要件
• 技術要件
• 要件定義の進め方とコツ｜システム開発のスタート！
• システム要件で目標とゴールを設定する
• 機能要件で業務フローと用いるデータについて整理する
• 非機能要件でトラブルが起こらない仕様を作る
• 要件定義書を作成する
• まとめ

システム開発における要件定義の概要

要件定義とは、ユーザーの欲している内容を明確にし、それを実現するために必要な開発項目を具体化・見える化するプロセスです。

そのためには、まず開発予定のシステムを使う方が欲しいと感じている機能や役割を明確にします。
次に、その要求を満たすためにどのようなプログラムや性能が必要かを明文化します。

場合によっては、システム開発を依頼する側（発注側）の要求をまとめる作業のことを「要求定義」と呼び、要求を開発項目にまで落とし込む作業と区別する場合もあるようです。

発注側の要求はシステムを通して実現したい内容だけでなく、納期や予算など多岐に渡ります。
これらが実現可能かどうかも含めて整理し、実際の作業や準備内容をまとめるのが要件定義です。

要件定義がシステム開発の工程の中で重要視される理由

要件定義はシステム開発の第一段階であり、下流の開発すべてに共通する内容を決める重要な段階です。
つまり、開発の方向性がここで決まるといっても過言ではありません。

システム開発が成功するか失敗するかは、要件定義をどれだけしっかりおこなえるかにかかっています。

要件を具体的に定義しておくとその後の開発がトラブルなく進み、プロジェクト全体を計画通りに進められます。
そして最終的には事業全体を成功に導くことができるのです。

また、テスト時に要件通りの機能が本当に実装されているかチェックするために、要件定義書が必須です。
誰が見ても目標やタスクがわかりやすい書類作りを心がけ、開発もテストもスムーズに進行させましょう。

システム開発における要件定義で決める内容

要件定義では、以下の内容などを詳細に決めていきます。
・開発目的
・ターゲット
・ゴール
・予算
・必要な機能
・必要なシステム構造やデータ
・スケジュール（納期）
・必要な人員・工数
・実装手順
これらの「要件」は複数の種類に分けることができるため、分類ごとに詳しく見ていきましょう。

システム要件

「システム要件」は、要件定義の中でも最初におこなうプロセスです。
システム開発の方向性を決める、重要な作業になります。

具体的な作業としては、発注側が欲している内容の中からシステム化するもの・しないものを取捨選択していきます。

なぜこの作業が必要かというと、発注側が望んでいる内容と、開発側で実現できる内容が異なるからです。
技術的な点はもちろん、予算や納期、開発に関わる人員数を考えて優先順位をつけていくことが大切です。

機能要件

開発の方向性をシステム要件で決めたら、次は「機能要件」でより具体的な実装方法を決めます。

実際の内容としては以下のような項目が挙げられます。
・システムの機能
・システムの階層構造
・画面表示や遷移方法
・データの種類
・処理できる情報

非機能要件

「非機能要件」とは、システム要件や機能要件以外のすべての要件のことです。

システム開発はシステムの中身だけ作ると思われがちですが、システムの安定性や拡張性、セキュリティなど考慮に入れるべき内容は意外と数多く存在します。

非機能要件は発注側で想定していない、または具体的なイメージがついていないことが多いです。
そのため、非機能要件について発注側と開発側でしっかり合意を得るためには、開発側がその要件が必要だと考えている理由もしっかり述べるようにしましょう。

技術要件

「技術要件」では、プラットフォームや開発に使用する技術・言語、データベースなどを決定します。
ただし、技術要件は必ず決めなければならない項目ではありません。

なぜかというと、プラットフォームの形や開発技術などは他の要件で触れる内容でもあるからです。
複数の要件に点在している技術的な内容を技術要件としてまとめると、いつ何をおこなうかが見えやすくなるため、決めておいたほうが無難ではあります。

要件定義の進め方とコツ｜システム開発のスタート！

定義する要件はカテゴリ分けできることをご説明しましたが、考える順番もある程度決まっています。
開発に時間もお金もかかったのに目的と違うものができあがってしまったという事態を防ぐためにも、正しい手順とポイントを押さえて要件定義をおこないましょう。

また、要件定義全体を通して重要なことは、発注側と開発側が密にコミュニケーションを取ることです。
互いが持っている情報や考えている性能に齟齬がない状態を常に作ることが重要です。

要件定義の進め方は以下の章から詳しく解説します。

システム要件で目標とゴールを設定する

発注側は、なんらかの課題を抱えているからこそシステム開発に踏み切っています。

そのため、システム要件を定義する際はまず課題をはっきり捉え、次に開発の目標とゴールをできるだけ具体的に文章化することをおすすめします。
目標が定まっていると、仮に途中で開発内容を変更する場合でも、当初の目的から逸れずに変更を加えていくことができるからです。

発注側の状況分析や、提示できる課題解決方法を見える化するツールとして、「機能情報関連図（DFD）」を使う場合があります。

この図を活用することで一連の業務の関係性や、業務全体の流れが可視化されます。
可視化するとどこに課題があるのかをはっきり把握できるようになり、何を変えるシステムを作るべきなのか明確になるのでおすすめです。

機能要件で業務フローと用いるデータについて整理する

システム要件で目標とゴールを確定したら、次に機能要件を定義します。
機能要件では決める項目が数多く存在します。

機能要件は、システムに搭載する機能や業務の改善内容を具体化する工程です。
そのため、機能情報関連図であぶりだした業務の関連性よりさらに細かい、業務フローまで分解する必要があります。

業務フローを書き出すことで発注側がおこないたいこと、開発側が提供できることがより明確になります。

また、機能要件では扱うデータの種類も規定するのですが、その際には「ER図」を用いると便利です。

ER図とは扱うデータを図で示したもので、システム上でおこなわれる動作とその時々で使われるデータの関係を明確にすることができます。

データの流れが複雑で混乱を招く恐れがある場合は、「データフロー図（DFD）」を用いてデータ処理の流れを明文化しておくとよいでしょう。

また、画面表示などのUI（ユーザーインターフェース）を整えることも大切です。
機能面では優秀なのになんとなく見づらい、わかりづらいといった理由でなかなか使ってもらえないシステムにならないよう、レイアウトやデバイスの種類も考慮に入れるとユーザーに喜ばれます。

想定している使用時の画面を列挙するのも効果的ですが、各画面がどのようなシーンで使われるかを「ユースケース図」を使って定義していくことでわかりやすくまとめることもできます。

非機能要件でトラブルが起こらない仕様を作る

非機能要件は、様々な機能を問題なく使用するために定義するといっても過言ではありません。

例えば、システム障害が起きやすい構造になっていないか、不正アクセスがされにくい状態になっているかなどが挙げられます。
特定の機能を使う場合の挙動や動作結果を数パターン想定し、トラブルを未然に防げるような内容を定義しましょう。

想像力を働かせることが大切であり、発注側と開発側のコミュニケーションがひときわ重要になる場面でもあります。

要件定義書を作成する

要件定義書には、要件定義で固まった内容から予算などシステム開発を進めるうえで必要な情報をすべて記載します。

開発スケジュールとの兼ね合いもありますが、要件定義書を作りこむことで担当者の思い込みや各自の齟齬を減らせるため、できるだけ細かく記載するのが理想です。

作成のコツとしては、先に盛り込みたい内容を目次立てにしておき、その後肉付けするイメージで詳細を書き加えていくと作成しやすいです。

まとめ

システム開発における要件定義でおこなう内容を網羅的にご紹介しました。
要件定義と一口に言っても実は決めなければならない内容が多く、少し面倒だと感じた方もいらっしゃるかもしれません。
しかし、システム開発の要である要件定義をしっかりと定めれば定めるほど、後のトラブルを減らすことができます。
この記事を参考にしつつ周囲の方とコミュニケーションを取り、よいシステム開発の滑り出しとしていただければ幸いです。

お見積もり・ご相談はこちら