要件定義の進め方は？効率的に進めるポイントを解説

2023.10.17

記事の監修

代表取締役村越聖人

2006年からエンジニアよりデジタル業界でのキャリアをスタート。
大小様々なWebシステム開発およびシステム運用保守を経験。

フルスタックエンジニアとして上流から下流工程まで一連の業務を担当するとともに、サーバー設計、構築、運用設計などのサーバー管理者業務も兼任。

近年は、顧客折衝を含む提案型営業からDMP絡みのデータ分析業務をはじめ、プロジェクトの全体統括・SEなど業務要件に合わせたポジショニングで顧客ニーズの最大化を図るサービス提案を実施。

新規事業で立ち上げた自社サービスにて、発明者として特許取得。

2019年5月株式会社glorious future 設立。

2006年からエンジニアよりデジタル業界でのキャリアをスタート。
大小様々なWebシステム開発およびシステム運用保守を経験。

新規事業で立ち上げた自社サービスにて、発明者として特許取得。

2019年5月株式会社glorious future 設立。

この記事では、システム開発をはじめとしたプロジェクト活動における最初期のプロセスである要件定義について紹介します。プロジェクトリーダーに任命され、要件定義を主導することになったが、詳しいことはわからない、という方に役立つ知識をお届けします。

この記事はこんな人におすすめ

システム開発を検討している人
要件定義のまとめ方や進め方を詳しく知りたい人
システム開発や要件定義をスムーズに進めたい人

要件定義とは

要件定義とは、「要件」を定義するプロセスを指します。要件とは、ITシステムなどに求められる「必要なこと」です。これがないと目的が達成できない、便利に使えない、といった顧客の要望・ニーズを取りまとめたものと言えます。要件は、具体的には機能要件と非機能要件に分かれます。

例えば、販売管理システムを想定すると、担当者がログインする機能、商品を登録する機能、現在の在庫を検索する機能などは、システムを開発する目的であり、必要不可欠です。このようになくてはならないものが、機能要件に該当します。
そして、システムが安定して動き続ける度合いである可用性や信頼性、エンジニアではない販売担当者でも簡単に操作できるユーザビリティなどは、そのものが目的ではないですが、あると望ましいものです。これらは必須ではないが、あると嬉しいものが非機能要件となります。

要件定義とは、開発者 (ベンダー) と発注者 (ベンダー) がコミュニケーションを取り、機能要件と非機能要件、互いの役割やスケジュールを合意の上決定する作業と言えます。

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

要件定義がしっかりと行われないまま進むプロジェクトは、進めていく中で破綻していきます。まず、作るべきものが明確でないため、機能や性能の過不足が生じやすくなります。また、発注者と開発者の間でシステムのあるべき姿について認識の齟齬が発生し、さまざまなトラブルのリスクが高まります。結果として、成果物であるシステムのリリース (完成) が遅れてしまいます。

このように、要件定義はプロジェクト成功の鍵を握る、重要なプロセスです。

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

要件定義と似た言葉として、要求定義があります。要求定義は、「そもそも何がしたいのか、何を解決したいのか」を明確にするプロセスです。その内容を「ITでどうやって解決するか」検討するのが要件定義と言えます。

下の図は、システム開発のプロセスを表現するものとして広く知られる「V字モデル」です。このモデルにおいて、要求定義は最初に行うもので、そこで合意したことを元に開発プロセスが進みます。また、最終的に顧客が成果物を受け入れる (検収する) かは、要求定義に基づいて判断されます。

要件定義の進め方

ここからは、要件定義を具体的にどうやって進めていけばよいのか紹介します。要件定義プロセスでは、機能要件、非機能要件以外にも、下記のようにプロジェクトを円滑に進めるためにさまざまな事柄を決定する必要があります。

目標や課題の整理
システム構成の決定
機能要件の定義
非機能要件の定義
スケジュールや予算の決定
要件定義書の作成

目標や課題の整理

はじめに、プロジェクトの目的や課題を整理します。大まかな目的は、「〇〇システムを開発する」ということになりますが、要求定義プロセスで得られた課題意識を踏まえ、「いつまでに、どのような課題を、どのようなアプローチで解決するか」を明確にし、メンバー間で共有しましょう。また、プロジェクトには必ずステークホルダー (利害関係者) がいます。ステークホルダーの要求を整理し、調整していくことも必要です。

システム構成の決定

次に、開発するシステムの全体像 (仕様) をデザインします。この段階では、具体的にどのような機器を導入するか、画面は、といった詳細を決めるのではなく、業務プロセス全体を、システムを導入することでどのように変えていくかを考えます。この作業の成果物として、例えばIPA (情報処理推進機構) が公開している「ユーザのための要件定義ガイド」では、ビジネスプロセス関連図やシステム化業務フロー図などが紹介されています。

機能要件の定義

システム化する業務が明確化されたら、それを実現するうえで必要な機能要件を定義します。ユーザーにヒアリングし、機能のヌケモレがないようにリストアップします。合わせて、機能に紐づくデータの定義、機能間のデータ受け渡しのフローなどを、ER図を作成し具体化します。

この段階で、優先順位をつけておくと、スケジュールやコストとのバランスが取りやすくなります。

非機能要件の定義

非機能要件についても同様に、ユーザーにヒアリングしてリストアップします。非機能要件は、実際に現場でシステムを使うことになる利用者の声を拾うことが重要です。作成するシステムの画面 (UI) も基本仕様を定義します。

スケジュールや予算の決定

取りまとめた要件をもとに、開発するシステムの規模を見積もり、スケジュールと予算を検討します。無理なスケジュールや不十分な予算は、プロジェクトの失敗と直結していますので、ベンダーの経験や体系化された見積手法をもとに、適切に策定する必要があります。例えば、IPAはCoBRA法という見積モデルを公開しています。

要件定義書の作成

ここまで紹介したさまざまな決定事項と作成したドキュメントを取りまとめたものが要件定義書です。要件定義書は正式な契約文書のひとつですので、ユーザーとベンダーが互いに確認し、合意したことを証跡として残すことが重要です。以降の設計、開発プロセスは要件定義書をもとに進めていきます。

要件定義を効率的に進めるポイント

ここからは、要件定義作業を効率的に進めるうえで重要な「コミュニケーション」と「取捨選択」について紹介します。

発注側と開発側のコミュニケーション

要件定義は、ユーザー (発注者) とベンダー (開発者) のコミュニケーションと合意形成のプロセスです。あいまいな態度や隠し事は避け、率直な意見を交わしましょう。コミュニケーションロスが生じると、後の工程で作業のやり直しなどのトラブルが発生します。また、打ち合わせにおける議論の内容は、必ず議事録として残しましょう。後で言った言わなかったということにならないよう、文書で証跡を残しておくことが重要です。

既存のシステムの把握を行う

システムを開発する際に、機能の重複や現在の業務との衝突を避けるため、既存のシステムや業務について把握しましょう。既存システムや業務の調査を怠ると、かえって生産性が低下したり、既存システムを改修するコストが発生したりする場合もあります。現状を踏まえて、要件や設計をアジャストする必要があります。

打ち合わせの回数を把握しておく

打ち合わせにもコストがかかります。各回の打ち合わせのゴールを明確に定め、要件を固めるために必要な回数を決めましょう。打ち合わせ中も、ゴールを意識した密度の濃い内容になるよう進行しましょう。

機能を盛り込みすぎない

ユーザーとしては、あれも欲しい、これも欲しいと要望を多くあげがちですが、限られた予算とスケジュールでできることに絞り込むことが重要です。システムを開発する目的に立ち返り、どんな課題を解決したいのか、そのために必要な機能はなにか、という観点で取捨選択しましょう。

まとめ　開発を成功に導くために要件定義をしっかり固めよう

ここまで、システム開発における重要なプロセスである要件定義について紹介しました。要件が具体的にならないまま進むプロジェクトは失敗する可能性が高まります。プロジェクトを成功させるために、要件定義をしっかりと行いことが重要です。

この記事のまとめ

要件定義は、ソフトウェアを開発するうえで顧客の要望やニーズを要件（機能）にまとめたもの。
要件定義は、なくてはならない「機能要件」と、必須ではないがあると便利な「非機能要件」に分かれます。
要件定義の進め方は「目標や課題の整理→システム構成の決定→機能要件・非機能要件の定義→スケジュールや予算の決定→要件定義書の作成」の流れで行う。
要件定義は、発注側と開発側がコミュニケーションをしっかりとり、既存のシステムを把握しておくことで効率的に進めることができる。