要件定義とは？具体例をあげながらシステム開発の手戻りを防ぐ進め方のコツを解説！

この記事では要件定義の基本的な進め方をおさらいするとともに、進め方のコツを詳しく解説します。

知識・情報

2023/02/27 UP

システム開発プロジェクトにおける「要件定義」はプロジェクト成功の鍵を握る特に重要な開発工程です。

要件定義でシステム要件が明確にならなければ、設計工程以降で仕様変更が頻発したり、手戻りによるコスト超過やスケジュール遅延が発生したりとプロジェクト失敗につながりかねません。一方で、要件定義の重要性は理解していてもスムーズに進められず、苦手に感じるエンジニアも多いのではないでしょうか。

この記事では要件定義の基本的な進め方をおさらいするとともに、進め方のコツを詳しく解説します。

要件定義とは？

要件定義とはシステムで実装する範囲や内容（システム要件）を決定する開発工程です。システム開発工程の初期に実施する工程で、前後で実施する「要求定義・企画」や「基本設計」を合わせて上流工程とよびます。

そもそも要件とは「求められる条件」、定義は「物事の内容や意味を他と区別できるよう明らかにすること」という意味です。つまり、要件定義では経営層やユーザー企業・部門の達成したい目標・理想像を実現するために、システムへ求めるものを定め、開発範囲を明確に限定することをゴールとしています。

システム開発全体の流れや、要件定義と基本設計の違いについては「ソフトウェア開発はどのような流れで進めるのか？その工程を詳しく解説」や「要件定義と基本設計は何が違う？実施すべき内容と進め方のポイントを解説」で解説しています。ぜひ併せてご覧ください。

要件定義の成果物

要件定義で作成すべき成果物は大きく「業務要件に関わるもの」と「システム機能要件に関わるもの」に分類できます。プロジェクトや所属する企業によって、作成すべき成果物は異なりますが、代表的な成果物は以下の通りです。

・業務要件に関わるもの
業務フロー図、ビジネスプロセス関連図など

・システム機能要件に関わるもの
画面一覧、画面遷移図、帳票一覧、テーブル関連図、外部インターフェース定義書など

要件定義の成果物は後続工程となる設計・開発工程のインプットとなる重要な成果物なので、必要な成果物は漏れなく作成するようにしましょう。

要求定義と要件定義の違いと関係性

要件定義と似た意味で使われるのが「要求定義」は、要件定義と混同して使われることも多いですが、厳密には異なる目的・作業内容の工程です。システム開発工程のうち、要求定義は要件定義の前工程として実施し、システム部門ではなくユーザー企業・部門での作業範囲となります。

要求とは「これが必要、欲しい、したいと相手に強く求めること」を指す言葉です。つまり、要求定義ではユーザー企業・部門がビジネス戦略や目標を実現するために必要だとあげたものの中からシステムで実現したい要求事項を検討・整理します。

対して要件定義は限られた要求定義の内容を受けて、システム要件として落とし込む工程が要件定義です。決められた予算・スケジュールの中で全ての要求を叶えることはできないので、本当に必要なものに厳選して絞り込んでいきます。

また、ユーザー企業・部門には顕在化していない潜在的なニーズを抱えていることもあります。ヒアリングを通してユーザー企業・部門の意図をくみ取ることも要件定義における目的の一つです。

要件定義が難しいといわれる理由

要件定義が上手く進まない理由の一つに「目的意識・ゴールの違い」があります。

システム開発の関係者である経営層、ユーザー企業・部門、システム開発エンジニアは、それぞれ異なる目的意識を持っています。

・経営層：IT投資を行い、コスト削減や業務効率化を実現したい

・ユーザー企業・部門：自分達の業務を良くしたい、楽にしたい

・システム開発エンジニア：低コスト開発できて、運用保守が楽なシステムにしたい

目的意識・ボールの差から要件定義を実施しても認識齟齬が生まれやすく、最終的にリリースされたシステムが使えない、という結果になりがちです。

他にも、業務知識が豊富なユーザー部門とIT技術に長けたシステム部門との間には知識の差があり、お互いの話を十分に理解できないというのも一つの理由となります。要件定義では経営層やユーザー企業・部門の意図を正確にくみ取り、設計以降の工程につなげることが重要です。

要件定義の基本的な進め方

要件定義の進め方は、所属する企業やプロジェクトによって細かいプロセスが異なるものの、大枠としては同じです。ここからは要件定義の基本的な進め方を解説します。

1. 業務要件をヒアリングする

まずは、システム開発の目的・ゴールを明確にしましょう。ユーザー企業・部門にヒアリングをし、何のためにシステムを作ろうとしているのか、どのような課題を解決したいのかを明確にしていきます。

ここでは具体的な要件だけをヒアリングするのではなく、目的や背景をヒアリングしておくのがポイントです。目的・背景が明確であれば後続工程で迷ったときにも立ち返りやすく、最終的に目指すべきゴールから大きく外れることは少なくなります。

2. システム要件を検討する

次はヒアリングした結果を整理し、システム化すべき要件を検討しましょう。いきなり成果物作成に着手するのではなく、システム化しないといけないものは何か、要件をどう実現するのかの整理に多くの時間を割くことが重要です。

システム要件の検討時は要求内容にもとづく機能要件だけでなく、性能やセキュリティ、ユーザビリティ（使用感・操作感）などの非機能要件の検討も忘れずに実施しましょう。ユーザー企業・部門の関心は機能要件に向かいがちですが、システムの満足度を決める非機能要件にも目を向けて意識的に検討することがポイントです。

3. 実行計画を立てる

整理したシステム要件をベースにどれくらいの工期・工数が必要になるのかを見積もりましょう。システム機能として求めるものを網羅的に洗い出せたとしても、プロジェクト発足時に想定していたスケジュールや予算をオーバーしてしまうこともあります。

そのため、リストアップした要件に対して重要度や緊急度などで優先順位をつけながら対応範囲、スケジュール、予算などを定め、実行計画として確定させるのがポイントです。ここが曖昧なままだと、後続工程で手戻りが発生したり、予算追加やスケジュール遅延が発生したりと重大なトラブルにつながる恐れがあります。

システム開発を手戻りなく進めるための要件定義のコツ

要件定義の進め方の基本が理解できたら、実際に要件定義を業務として経験しながら要件定義の「勘どころ」を身につけていくことが大切です。ここからは実践編として、要件定義をスムーズに進め、後続工程でのトラブルを最小限にするために気をつけたいポイントを3つ紹介します。

業務ヒアリングは5W2Hを意識する

要求を正しく引き出すためにはヒアリングが重要ですが、5W2Hを意識するとヒアリング精度が格段に向上します。ヒアリングの抜け漏れ、曖昧など要件定義不備にならないよう、以下に注意しながらヒアリングを行いましょう。

What：現場の課題、改善したいポイントは何か？何を実現したいのか？

Why：なぜシステム化が必要なのか？背景・目的は何か？

Where：開発範囲はどこまでか？

Who：誰がシステムを利用するのか？

When：いつまでに開発が必要なのか

How：どのように要求・要件を実現するのか

How much：どのくらいの予算が必要になるのか、投資予算はどれくらいか

また、業務ヒアリングに参加する関係者全員がIT技術に明るいわけではありません。専門用語はできるだけ用いず、サンプルを表示したり、図表を用いたりと分かりやすさ、伝わりやすさを工夫することが重要です。

現行システムの仕様確認を実施する

システム開発の目的が現在の業務を改善したいという場合は特に、現行システムの確認が欠かせません。現行で稼働中のシステムに影響が出ないよう入念な仕様調査を実施しましょう。

長年稼働しているシステムの場合はドキュメントが陳腐化していたり、業務知識を持っている人が業務部門にいなかったりと、仕様確認が思うように進まないケースもあります。このケースでは可能な限り調査・確認は進めつつ、プロジェクトリスクとして認識・対応することも重要です。

また、全く新しいシステムを作る場合であっても、現行業務・システムの確認は必須です。理想とするシステム像の検討が先行し、現行業務やシステムの確認が疎かになった場合、業務プロセス、およびシステム機能に漏れやムダが発生する危険があります。現行業務・システム機能が全て正解とは限りませんが、全体を俯瞰して本当に必要な機能をリストアップすることが重要です。