要件定義とは？押さえるべき3つのポイントも解説【要件定義の終了判定サンプル有】

皆さん、こんにちは。リンプレスの塚本です。

ITシステム構築に携わる多くの方を悩ませているのが、要件定義といわれるプロセスではないでしょうか？

要件定義はシステム開発の成功を左右する重要なプロセスです。正確に要件定義を実施するには、「なぜ要件定義を行うのか」「要求定義との違いは何か」といったポイントを理解しておく必要があります。

今回は、自社の要件定義プロセスに課題を抱える企業に向けて、役立つ情報をご紹介させて頂きたいと思います。要件定義書の作成に役立つサンプルデータも配布していますので、ぜひダウンロードしてご利用ください。

「要件定義の終了判定サンプル」をダウンロードする

＼ リンプレスの支援実績をまとめた導入事例集を公開中 ／

要件定義とは、システム開発において「何を実現するべきか」を明確にする工程です。

業務課題を踏まえ、必要な機能・性能・制約条件・運用ルールなどを整理し、関係者間で共通認識をつくる役割を担います。要件が曖昧なまま開発を進めると手戻りやコスト増につながるため、上流工程の中でも特に重要なプロセスといえます。

DX推進やシステム内製化が進む現在、企業が確実に成果を出すためには、要件定義の質がプロジェクト全体の品質を左右するといっても過言ではありません。

要求定義は、利用者や業務部門が「こうしたい」「こういう課題を解決したい」と示すニーズを整理する工程であり、ビジネス上の目的や期待を言語化するフェーズです。

一方、要件定義はその要求をもとに、実際のシステムとしてどのように実現するかを詳細化する工程を指します。

つまり、要求定義は「顧客の期待の把握」、要件定義は「期待を実装可能な形へ落とし込む作業」という位置づけです。この2つを正しく切り分けることで、開発チームと利用部門の認識のズレを防ぎ、プロジェクトを安定して進められます。

要求定義と要件定義の違いについては、以下の記事で詳しく紹介しています。
要求定義と要件定義の違いとは？IT化の上流工程で重要なポイントを解説

要件定義の目的は、要求定義の枠組みを劣化させることなく、要求を実現するために「〜が必要」を具体化し、明文化することです。

具体的には、以下のように明文化を行います。

要求の実現に必要なシステムの機能　→　システム要件
要求の実現に必要な業務の移行　　　→　業務移行要件
要求の実現に必要な運用の移行　　　→　運用移行要件

このように要求定義と要件定義は目的そのものが違うため、開発工程上、同じ工程で扱うとしても、
要求定義（要求の枠組みを決める）→要件定義（枠組み内で必要なものを定義する）の順番で実施する必要があります。

要件が明確であれば、設計・開発・テストといった後工程の判断基準が揃うため、意思決定が迅速になり、開発コストの最適化にもつながります。DX時代に求められるスピードと確実性を両立するためにも、要件定義は欠かせない基盤となります。

ITシステムの構築において、なぜ要件定義が必要なのでしょうか。
その理由は、「一言で要件定義といっても、その中に含まれる『要件』は複数存在するため」です。

例えば現在運用されている販売管理システムを再構築し、新販売管理システムを構築するといった場合、当然システム要件が存在しますが、再構築であれば、それに加え、移行要件が存在します。

移行要件と聞くとデータ移行を想像しがちですが、実際には新システムに合わせた業務の移行、運用の移行などもあり、それぞれ業務移行要件、運用移行要件として定義される必要があります。

また、『現行システムと同じに作ってくれれば良い』という話も良く聞きますが、これでは要件を定義したことにはなりません。

現行同様を望むのであれば、現行機能を棚卸しし、ひとつひとつ定義付けしていく必要があるのです。
なぜならば、定義されていないことが実現されることはありえないからです。

実際のシステム開発現場において、納期遅れや予算オーバーといったトラブルが起きた原因からも、要件定義の重要性がわかります。

以下のデータをご覧ください。

　　　　　　◆納期遅れの原因（複数回答）
　　　　　　　　　・要件定義が計画より長引いた　 … 37.7％
　　　　　　　　　・企画作業が長引いた　　　　　 … 22.7％

　　　　　　◆予算オーバの原因（複数回答）
　　　　　　　　　・追加の開発作業が発生した　　 … 65.0％
　　　　　　　　　・追加の企画作業が発生した　　 …   8.0％

　　　　　　◆品質不備の原因（複数回答）
　　　　　　　　　・要件定義が十分でなかった　　　… 35.9％
　　　　　　　　　・システムの企画が十分でなかった… 16.7％

（出典：日経コンピュータ　2003年11/17号）

これは、ITシステム構築が計画どおりにいかなかった理由に対してのアンケート結果です。
20年ほど前のデータですが、当時から要件定義の重要性は広く認識されていました。
それにも関わらず、このような失敗がおきるということは、要件定義の難しさを如実に表しているといえるでしょう。

現在でも、要件定義の失敗に起因するITシステム構築プロジェクトの失敗は後を絶ちません。
だからこそ、抜け漏れ、取違えのない正しい要件定義が求められているといえるでしょう。

要件定義の意義のひとつは、前述したとおり、正しい要件を定義しプロジェクトを失敗させないことですが、この要件を明文化し、「要件定義書として正しく落とし込む」ことも重要です。

ITシステム構築の現場では、要件定義〜テストまでの一連の工程をたった一人で行うことはまれであり、多くの場合、役割に応じて担当が変わり推進されます。このような進め方であるが故に、伝言ゲームのように情報劣化が発生する可能性は避けえません。

このような事態に陥らないためにも、要件定義書の記載内容が読み手の誤解を生むことなく、一意に解釈できる定義になっていることが大切です。

これに加えて、もう一つ重要な意義は、ITシステム構築を他社発注の際の合意形成文書であり、契約の枠組みであるということです。

要件定義書は、

• 契約の物差し
• システムを具体化していく上での物差し

として、極めて重要な意味合いを持っています。

こちらから、要件定義書の作成に役立つ「要件定義工程の終了判定のサンプル」をダウンロードできます。

「要件定義の終了判定サンプル」をダウンロードする

要件定義の作業自体は、システムエンジニアやコンサルタントなどの開発側が中心となって進めることが一般的です。業務ヒアリングや現状分析、必要な機能の整理といった専門的な工程は、技術知識を持つ担当者がリードする方がスムーズです。

しかし、要件定義の「最終的な責任」は発注者であるユーザー側にあります。ユーザー自身が業務課題や目的を明確にし、提示された要件を自社視点で確認・承認しなければ、開発の方向性がずれてしまうためです。

適切な要件定義を実現するには、開発者とユーザーが協働し、双方が責任を持って内容を固める姿勢が欠かせません。

要件定義は、関係者の認識を揃えながら具体的な仕様へ落とし込むプロセスです。

はじめに現場の理解を深めるためのヒアリングを行い、その情報を整理して業務課題やニーズを明確化します。そのうえで、開発で実現すべき内容を客観的に示す「要件定義書」にまとめ、関係者全員で合意を形成します。

これらの流れを、3ステップで以下から詳しく解説します。

要件定義の第一歩は、利用部門・現場担当者・管理者などから業務の流れや課題を正確に聞き取るヒアリングです。

現状の業務手順や抱えている問題、理想とする状態を深掘りし、開発の前提となる情報を集めます。この段階で見落としがあると後に仕様のズレが生じるため、質問の設計や関係者の選定も重要です。

ヒアリングは単なる情報収集ではなく、ユーザーが本当に求めている価値を引き出すプロセスとして丁寧に進める必要があります。

ヒアリングで得られた情報をもとに、開発すべき内容を整理し、要求を具体的な形へ落とし込みます。

業務課題・優先度・制約条件を明確にし、必要な機能や非機能要件に分類することで、後工程で判断しやすい構造へ整備します。

ここでは、曖昧な表現を避け「誰が」「いつ」「どのように使うのか」を定義することが重要です。要求を言語化し整理することで、ユーザーと開発者の認識差を埋め、要件定義全体の精度を高められます。

整理した内容を正式なドキュメントとしてまとめるのが要件定義書です。

システムが提供する機能、運用ルール、性能要件、前提条件などを体系的に記述し、プロジェクトの共通基準として活用します。

明確な要件定義書があることで、設計・開発・テストといった後工程が迷わず進められ、品質管理もしやすくなります。また、ユーザーと開発者が合意する公式資料としての役割も担うため、内容の正確性と網羅性が欠かせません。

要件定義を実際に行う際に押さえておくべき重要ポイントとして、以下の3つが挙げられます。

1. 見過ごされがちな要件定義の「定義」をする
2. レビュープロセスを軽視しない
3. 5W2Hを活用する

それぞれ、以下にて詳しく紹介します。

ITシステム構築における外部委託契約には、以下のようにいくつかのバリエーションが存在します。

• 要件定義までを自社で行い、設計以降を外部へ
• 要件定義から外部へ

要件定義起因のトラブルの中には、受発注間における要件定義に対する認識齟齬が少なからず存在します。具体的には以下のようなケースです。

• 発注側、受注側の要件定義でやるべきことに対する認識に齟齬があった
• やるべきことの認識はあってはいたが、やるべき人（発注側、受注側）の認識に齟齬があった

要件定義には前述したように業務要件、運用要件なども含まれます。

他社と協業し要件定義を実施する場合は、契約締結前に要件定義でやるべきこと、やるべき人を明確に定義し、認識を合わせることが重要です。

要件が正しく定義されていると判断できるのは誰でしょうか？
ITシステム構築のプロフェッショナルであるITベンダや情報システム部門の方達でしょうか？

確かにシステム要件であれば、ITシステム実現に向けて、どういったハードウェアやソフトウェアが必要か、そのプラットフォーム上にどういったシステムを実装していくのかを定義し、それが正しいかを判断するのは、ITベンダの役割範疇かもしれません。

では、業務要件や運用要件はどうでしょうか？
委託業務の契約範囲内で、業務要件や運用要件をITベンダが定義することはありますが、定義された内容が要求定義した自分達の業務や運用にとって正しいかを判断できるのは、業務担当者であり運用担当者です。

ITシステム構築で厄介なのは、業務や運用にとって正しくないものが定義されたとしても次工程に進めてしまうという点です。

もしも取り違いや漏れが発生したまま、次工程に進んでしまうと、それに気づくタイミングは、運用テスト、受入テスト、最悪の場合、サービスイン後ということになり、典型的な要件定義に起因した失敗プロジェクトになってしまいます。

このような状況に陥らないためにも、要件定義開始前に誰がどの部分のレビューを担当し承認するのかを決めた上で、レビュープロセスを確実に履行することが重要です。

要件定義の「定義」で述べた要件定義でやるべきこと、やるべき人の明確な定義にはレビュープロセスも含まれるのです。

要件定義では、Tシステム構築における5W2Hをしっかりとおさえ、明文化（定義）するプロセス定義が必要です。

ITシステム構築における5W2Hとは、

■要求

　　Why・・・なぜITによるシステム化を行いたいのか

　　What・・・ITシステムを使って何を実現したいのか

■システム要件

　　Where・・・要求を満たすためには、どの部分をITでシステム化するのか

　　Who・・・そのITシステムの利用者は誰なのか、運用者は誰なのか

　　How・・・ITシステムを使ってどのように実現するのか

■プロジェクト要件：制約、前提事項

　　When・・・そのITシステムによるサービスをいつから享受したいのか

　　How much・・・そのITシステムの実現に対し、いくらの予算を組むのか

であり、

設計工程は、要件定義で定義されたHow（どのような機能が必要か）を更に深堀り、詳細化して実装レベルまで落とし込む工程であり、

・IT化するその機能はどのような振る舞いをするのか

・IT化するその機能にはどのような項目が必要なのか

・IT化するその機能にはどのようなチェックが必要なのか　etc..

へと落とし込んでいく工程です。

つまり、設計工程で扱うものは、5W＋2Hのうち、Howだけが対象であり、以外の定義は全て要件定義の段階で明文化（定義）されている必要があります。

5W＋2Hのうち、Howを除いた5W+1Hの定義を要件定義工程までに終了しておくことは必須事項であり、仮にこれらの定義が終了しないまま、次工程に進む場合は、プロジェクトリスク（失敗プロジェクトに陥る可能性）が高いと認識すべきでしょう。

このような状況でのプロジェクト運営は、そのリスクを顕在化させないためのリスク管理、既発課題に対する期日管理といった課題管理が重要になってきます。

一方で、Howに関しては前述したとおり、要件定義工程、設計工程でそれぞれ取り扱うため、要件定義開始前に要件定義工程で扱うHow、設計工程で扱うHowを定義しておく必要があります。

要件定義〜設計工程を1社で実施する場合は、細かいプロセス定義は不要かもしれませんが、要件定義工程と設計工程を別々の会社で行う場合は、厳密な線引きが必要です。

ここまで解説してきた要件定義の流れやポイントを踏まえて、実際の要件定義プロセスの具体例を見てみましょう。

下図は、要求分析と要件定義を別工程とした時のプロセス定義の一例です。

※要求分析プロセス ：システム構想策定（CANVAS-SAⓇ）の資料はこちらからダウンロードできます。

前の工程で何をどこまで作っているかで、要件定義工程の実施内容も変わってきます。
この場合、要求分析の結果を受けて、要件定義プロセス内の項番1~8を実施プロセスとして定義しています。

前述した要件定義プロセスの定義はあくまで一例ですが、後工程には設計工程があります。
要求分析工程のアウトプットを要件定義工程のインプットとしているように、要件定義工程のアウトプットが設計工程のインプットとなります。

要件定義工程と設計工程におけるHowの線引きでも述べたとおり、後続の工程との整合性をとることを考えなければいけません。

特に後工程が要求するインプットの不足は避けなければいけません。

要件定義をはじめとする上流工程を担うには、業務理解・論理的思考・企画構想力など、IT企画人材としての総合的なスキルが求められます。こうした能力を実務レベルで身につけるには、体系立ったカリキュラムと実践的なトレーニングが不可欠です。

リンプレスでは、企業のDX推進を担う人材を育成するために、現場で即戦力として活躍できるIT企画スキルを体系的に習得できる研修プログラムを提供しています。自社内に企画力を持つ人材を育てたい企業にとって、リンプレスは有力な選択肢といえるでしょう。

ご相談・お問い合わせ

リンプレスが提供する「STUD-SA®」は、システム企画・要件定義・業務分析を実践的に学べる独自プログラムです。

実務で使われるフレームワークやドキュメントを用いながら、現場でのヒアリング方法から要件整理、企画書作成までを一連の流れで習得できます。多くの企業が抱える「上流工程を担える人材がいない」という課題に対し、STUD-SA®は短期間で実務力を高められるよう設計されているのが特徴です。DX推進やシステム内製化を進めたい企業にとって、確かな企画力を育成できる研修として高い評価を得ています。

リンプレスの「STUD-SA®」について詳しくはこちらから

今回のブログでは、私の経験上からも重要と考えられる要件定義プロセスの具体例を上げさせて頂きましたが、要求分析ありきの要件定義プロセスであり、必ずしもこれが正解といったものではありません。

大切なことは、自社の要件定義プロセスを定義する際、要件定義に必要なもの（インプット）の抽出、後工程で必要なもの（アウトプット）の抽出をしっかりと行い、過不足のない要件定義成果物を作成する為のプロセスを“定義”し、それを実施していくことだと考えます。

今回のブログの内容がみなさんの今後のお仕事に少しでもお役立て頂ければ幸いです。