要件定義とは？　今さら聞けないDX関連用語をわかりやすく解説

DX推進には欠かせないITシステム開発。そんなITシステム開発には、さまざまな工程があります。
その中でも、業務やシステムの要件を決める「要件定義」は、システムの利用者となるユーザー企業と、システムの開発者となるベンダー企業の認識を合わせるために大切な工程です。

「要件定義」がシステム開発の成否を分ける、ともいわれます。

この記事では、これからDXを進める企業のみなさんが知っておくべき「要件定義」の言葉の意味や進め方、意識すべきポイントを解説します。

なお、この記事は、IPAの「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」をもとにDX SQUARE編集部にて執筆したものです。

要件定義とは？

要件定義はシステム開発の上流工程のうちの1つ

要件定義とは、システム開発の工程の1つであり、プロジェクトの初期に実施される工程のことです。

要件定義の前には「企画」、うしろには「基本設計」という工程があります。企画から要件定義、基本設計までを、まとめて「上流工程」と呼びます。
上流工程の取り組みが、完成するシステムの品質に大きく影響するといわれます。

「企画」の工程では、業務の全体像やシステムの構想を立案します。これは、経営のニーズや課題を実現・解決するための、ビジネスモデルを想定しておこないます。
システムを具現化するための計画やプロジェクト計画を立て、「システム化計画書」としてまとめます。

この記事で解説する「要件定義」の工程では、企画の工程で立てたシステム化計画をもとに、システム利用者のニーズや要望、課題を分析。そして、利用者が必要とする機能やサービスに対する「要求」を抽出します。それから、システムに関係する顧客、従業員、株主、取引先、地域社会などの利害関係者（ステークホルダー）と合意して、要求を「要件」としてまとめます。

そのあとの「基本設計」では、要件定義でまとめた要件を具体化し、業務フローを明確にします。また、必要な機能やソフトウェア構成を決めたり、外部インタフェースの整理などをおこない、「基本設計書」としてまとめていきます。

要件定義はプロジェクトの成否を分ける

一般社団法人日本情報システム・ユーザー協会の調査「ユーザー企業ソフトウェアメトリックス調査（2016年版）」によると、システム開発プロジェクトの工期遅延理由の1位と2位は、要件定義フェーズに原因があるという回答でした。調査対象のプロジェクトのうち4割のプロジェクトが、要件定義に問題があって工期が遅延した、としています。

要件定義はシステム開発の初期の工程です。
要件定義で抜け・漏れ・あいまいな表現があると、のちのちの設計や開発工程での手戻りのコストが大きくなってしまいます。要件定義を適切におこなうことで、システム開発を効率化し、システムの品質を向上させることができるのです。

要件定義の進め方

では、要件定義はどのように進めればよいのでしょうか。
実は、要件定義の進め方に明確なルールはありません。また、プロジェクトによっても進め方は異なります。

ここでは要件定義のプロセスを大まかに説明します。

1.ビジネス要求を定義する

「ビジネス要求」とは、利用者や他のステークホルダーにとって必要なサービスを提供するシステムに求める業務上の要求事項のこと。

ここでは、企画の工程で整理された経営のニーズや課題にもとづいて、業務の観点から要求を集めます。また、それらの要求の関連の整理や優先度付け、具体化をおこない、文書としてまとめていきます。

具体例を用いて「ビジネス要求」を定義してみましょう。
たとえば、とある部品メーカーにおいて、経営レベルの要求を以下のように整理したとします。

• グローバルな視点で製品在庫を最適化し
  • 過剰在庫の管理コストを削減
  • 在庫切れをなくし、受注機会損失を削減
• 競合他社の在庫切れに互換製品を提案し
  • 売上を伸ばす

これに対して、ビジネス要求は、業務の観点での要求です。たとえば以下のようなものになるでしょう。

• グローバルに在庫の状態がリアルタイムに把握できる
• 製造中の製品の予定入庫日、予定入庫数が把握できる
• 需要予測が実用的な精度でできる
• 在庫切れが予測された場合、余裕のある倉庫の在庫を移動できる（前提：在庫切れが発生する製品は全体の１割以下で、事前に想定できる）

このようなビジネス要求を導き出すには、現行の問題や解決すべき課題を抽出して、目指すべきゴールとその手段を設定します。

さまざまな要求や目指すべきゴールがたくさんの関係者から出てくるでしょう。それらを経営の要求に貢献するかどうか見極め、優先順位を明確にしていきます。これを「ビジネス要求」として、以下のような文書にまとめ、関係者で合意します。

2.システム化要求を定義する

システム化要求とは、システムやその運用環境、画面や帳票、外部インタフェースに対する要求事項を構造化した集合のこと。

先にまとめた「ビジネス要求」をもとに、システムに対する要求をまとめていきます。

たとえば先述の部品メーカーの例でいうと、システムに対する要求は以下のようなものになるでしょう。

• 世界地図の上に倉庫を表示し、指定された品種の在庫をビジュアルに表示する
• 各倉庫の入庫・出庫情報をリアルタイムに新システムに伝送する
• 在庫切れを監視する製品を事前に登録する
• 上記製品の3か月後先までの需要予測を実施し、自動設定された安全在庫量を下回った場合、メールで通知する
• 安全在庫量を下回る製品の一覧を表示し、製造指示を出す

このようなシステム化要求を導き出すには、「ビジネス要求定義」で文書化した要求を、機能面と非機能面の両方で分析する必要があります。

機能面とは、業務と直接関係のある事項のこと。たとえば、システム上の業務フローや、管理するデータ、画面や帳票のレイアウトなどがあります。

非機能面とは、業務とは直接関係ないものの業務機能を実現するために必要となる事項のこと。たとえばシステムの稼働率や、レスポンスタイム、セキュリティなどです。非機能面はビジネス要求には表れにくい部分のため、システム部門が主体になって業務部門から要求を聞き出すのが効率的です。

「システム化要求」として、たとえば以下のような文書を作成してシステムの仕様をまとめていきます。

3.関係者と合意して「要件」とする

ここまでにまとめた「ビジネス要求」と「システム化要求」を要件定義書として文書化して、ステークホルダーと合意したものが「要件」になります。

ここまでの、「要件定義」で作成する文書の例は以下です。

なお、作成する要件定義書はプロジェクトによっても異なります。
IPAでは、実際の開発現場で使用している要件定義書を「事例集」として公開しています。参考にしてみてください。
超上流から攻めるIT化の事例集

要件定義を成功させるためのポイント

プロジェクトの成否を分ける要件定義。そんな要件定義を成功させるために意識するべきポイントを、IPAのガイドからいくつか紹介します。

参考：
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ
超上流から攻める IT 化の原理原則 17ヶ条

要件定義の責任はITベンダーではなく自分たち（ユーザー）にあることを認識する

要件定義とは、どのようなシステムをつくりたいのかを定義すること。これは、発注者であり利用者であるユーザー企業の仕事です。

要件定義があいまいなままITベンダーに開発を依頼してしまうと、作成されるシステムはユーザーの求めるものと違ったものになるかもしれません。そうすると、修正のために追加のコストがかかったり、納期が遅れたりするおそれがあります。その責任をITベンダーに負わせることはできません。

もちろん、人的資源、経験、スキルなどの問題で、自分たちだけでできない場合は、ITベンダーをうまく活用し、不足しているシステム知識を補うことが有効です。そのために、ITベンダーに一部を委託して、支援を受けることもあります。

ただし、ITベンダーに支援してもらう場合でも、要件定義でつくった成果物に対する責任は、ユーザー企業にあるのです。

「要件定義はシステム部門の仕事」という固定観念を捨てる

要件定義は、システム部門だけの仕事ではありません。
経営や業務に貢献するシステムを構築するためには、経営層や業務部門の主体的な参画が欠かせません。

ITシステムは、業務の一部を機械化したものです。つまり、システムは業務の一部。
どのようなシステムをつくるか、そしてそのシステムからどのような効果を引き出すかは、業務部門の責任です。

そのため、システム開発をシステム部門だけの仕事にせず、業務部門が自分のこととしてとらえる「態勢」を整えることが大切なのです。

また、DXを目的としたシステムの構築には、今の業務の大きな変化を伴うものもあるでしょう。この場合、業務部門の理解がなかなか得られないかもしれません。
そのようなときは、経営として、システム化による目標を明確にすることが重要です。数値レベルの具体的な目標や、社内の各部門が達成状況を確認できるレベルの目標設定が必要です。

このように、要件定義はシステム部門の仕事ではなく、全社で取り組むべきものなのです。

要件の確定を先送りしないために、じゅうぶんな時間と体制を確保する

「まだ要件定義で決めなければならないことがあるものの、設計で決めれば何とかなるのではないか。開発担当のプログラマーも手配済みなので、先を急いでほしい」
そんなITベンダーの要望もあって、要件定義が打ち切りとなってしまうことが多くあります。

要件定義の工程で修正に気がつけば、その作業負荷は少なくて済みます。しかし、その後の設計、開発、テストと工程が進めば進むほど、修正作業の負荷は大きくなります。要件の確定を先送りしないためには、要件定義に多くの時間を確保することが必要です。

システム部門だけでなく経営層や業務部門も参画する要件定義。普段の業務をしながらの参画になるでしょう。本当に必要な人をアサインし、その人にじゅうぶんな時間を与えることが、成功のポイントです。

「今と同じ」という要件定義はありえない

DXを進めるなかで、現行のシステムを再構築することもあるでしょう。そのとき、「現行踏襲」とか「今と同じでいい」という要求が出ることがあります。しかし、これはトラブルの元。

「同じ」という表現が正しく伝わるのは、具体的なプログラムやコードなど、形のあるものだけです。

業務やシステムの機能が不明瞭なまま、「今と同じ」という要求を受け入れてプロジェクトを進めると、あとで問題になる可能性があります。

「今と同じ」でも、要件定義は必要です。そもそも今の要件はどうなっているのか、現行業務や現行システムを可視化し、把握することから始めなければならないのです。そしてその内容について「要件定義書」として改めて文書化する必要があります。

要件定義を自分ごととしてとらえよう

要件定義はシステム開発の工程の1つ。DX推進のためのシステム開発において、DX推進部門や業務部門の方が要件定義に参画することが重要です。
「システム開発だから」とITベンダーやシステム部門に任せきりにするのではなく、システムの利用者である自分たちの仕事としてとらえましょう。

また、要件定義の工程でまとめた要求は、プロジェクトの進行につれて追加や変更が起こることもあるでしょう。要件定義とあわせて、適切な「要求管理」をおこなっていくことも重要なのです。

こうして要件定義を抜け・漏れなくできれば、プロジェクトやシステム開発の成功確率はぐんとアップするはずです。

なお、ここまでは主にウォーターフォール型のシステム開発における要件定義についての考え方でした。
ビジネスを取り巻く環境の変化が激しい世の中では、長期間を要するシステム開発がそぐわず、要求の変更に柔軟なアジャイル開発をおこなうことも増えてきています。しかし、アジャイル開発であっても、「お客様が本当にほしい価値」や「ビジネスにどのような価値をつくるのか」を考えることは、ウォーターフォール型の要件定義の考え方そのものといえるでしょう。

コラム：要件と要求は違う？

国際標準である「ISO/IEC/IEEE 29148 Systems and software engineering – Life cycle processes –Requirements engineering」の中で、要件定義を含めた上流工程における用語や概念、プロセスの定義が記載されています。

また、この ISO/IEC/IEEE 29148 をもとに、「JIS X 0166 システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング」が日本工業規格化されています。このJIS X 0166において、「requirementは、通常要求又は要件と訳される」と記載されています。つまり、「要求」と「要件」の違いに関する標準的な基準定義は存在しません。

ただし、IPAの「ユーザのための要件定義ガイド 第2版」では、「要求」をJIS X 0166の定義をもとに、「ビジネス要求」と「システム化要求」に分類しています。また、「要件」は、それらの要求を文書化・仕様化して、ステークホルダーと合意したもの、と定義しています。