システム開発を進行するにあたっては、まずは要件定義を行い、プロジェクトの概要や目的を明確化する過程が欠かせません。

開発者の視点からプロジェクトの具体的な進行方法を定める要件定義は、クライアントやユーザーの要求を適切にプロダクトに落とし込むために、重要な役割を担う工程です。本記事では、要件定義とはどのようなものなのか。誰が、何のために実施するのか？　その重要性や要件定義書の書き方なども含めて解説します。

要件定義とは

要件定義とはシステム開発の最上流に位置する工程であり、本格的な開発工程の前段階にて、クライアントやユーザーの要望の実現に向け「どのようにシステムを構築するのか」を開発者視点から決定し、まとめる作業です。

要件定義は、一般的にはシステム開発の経験が豊富なエンジニアや、プロジェクトマネージャーが担当します。担当者はヒアリングを経て、クライアントが直面する課題や本質的な開発目的を明確化したうえで、システム構成や機能要件、予算、スケジュールのすり合わせドキュメント化します。

 

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

要求定義とは、要件定義の前段階で実施されるシステム開発への要求を確認する工程です。クライアントやユーザーが解決したい課題やシステム導入の目的、ならびに必要な機能などの要求事項を整理します。

つまり要件定義は、要求定義の内容をシステム開発要件に落とし込む作業とも言い換えられます。

また、要求定義はシステムを発注・使用するクライアント側が主体となりますが、要件定義はシステム開発側が主体となって実施する点も両者の違いです。

 

要件定義と基本設計の違い

基本設計とは、要件定義の内容からシステムの仕様を決定していく工程です。要件定義で定められた機能や性能はどのようなもので、どういった役割を果たすのか、具体化していきます。

たとえば、UIや画面遷移図、機能一覧などを基本設計として定めることで、基本設計を確認すればシステム全体の機能や各機能の関連性などを把握できるようになります。

要件定義がシステムの構成や機能を「言葉」で表現するのに対し、基本設計は「図」を用いて完成したシステムのイメージを共有する工程ともいえます。

 

要件定義の重要性

要件定義は、システム開発の目的やシステム構成、予算、スケジュールなど、プロジェクト進行の要点をドキュメント化するものです。この段階にて抜け漏れや誤りが生じれば、以後の開発工程やシステムの仕様にまで影響がおよぶため、納期遅れや品質低下など、深刻なトラブルの発生を招きかねません。

また、要件定義が曖昧なままにプロジェクトを進行してしまうと、ユーザー・クライアント側と開発側にて認識の齟齬が生じ、予期せぬ機能追加や機能不足なども発生してしまいます。

適切な要件定義を経て関係者の認識を統一することは、高い品質のシステムの提供やトラブルの未然防止に欠かせません。

 

要件定義の進め方

要件定義は、次の3つのステップで進めていきます。

1. ヒアリングを実施する
2. 要件を固める
3. 要件定義書を作成する

要件定義書は、前提としてユーザーの課題やクライアント側の要求をベースに作成します。

まずはヒアリングを実施し、現状の課題や具体的な要求事項を把握します（要求定義）。続いて、ヒアリングの内容からシステム要件を検討し、要件定義書としてまとめ共有する流れです。

 

１.ヒアリングを実施する

はじめに、ユーザーやクライアントはどのような課題に直面し、それを解決するシステムをなぜ必要としているのか、具体的にどのような機能を求めているのか、詳細をヒアリングします。

• 現状の業務はどのようなプロセスに沿って進められているのか
• どこのプロセスに問題があり、どのような課題がボトルネックとなっているのか
• その課題をどのようなシステムで解決できるのか
• 課題を解決し、実現したいことはなにか
• 言語化できていない潜在的なニーズはないか

これらの要求内容を特定するために、ヒアリングには開発側の営業担当者、あるいは要件定義を担当するエンジニアやプロジェクトマネージャーが出席します。クライアント側からは、実際にシステムを扱う現場の社員や、発注の権限を有する担当者に参加してもらいます。

なお、ヒアリングの際にはクライアントの要求をそのまま受け入れるのではなく、実現可能性を判断しなくてはいけません。予算の超過はないか、スケジュールは遅延しないかといった観点も含め、受け取った要求を精査します。

事前にヒアリングシートを共有して、要求事項をある程度リストアップしてもらい、ヒアリングの場で内容の詳細を詰めていくアプローチも有効です。

 

２.要件を固める

ヒアリングした内容を、具体的なシステム要件に落とし込む工程です。ここでは要求内容に優先順位をつけ、必須要件と希望要件に分類します。

予算とスケジュールに沿ったシステム開発に向けて、クライアントの合意を得ながら必須要件と希望要件を固めていきましょう。

また、この際には、要求内容からリストアップした機能要件に加え、拡張性や互換性といった非機能要件も検討します。

 

３.要件定義書を作成する

要求内容を反映したシステム要件が定まったあとは、開発までのロードマップや想定する仕様をドキュメントに落とし込み、要件定義書を作成します。

要件定義書は、基本設計などシステム開発の基盤となる情報をまとめた書類です。各項目に関して、詳細に記載しましょう。具体的には、システムの概要や導入目的、システムの全体像や具体的な機能などを記載します。

なお、要件定義書はシステム開発に関する専門知識がなくても理解できる内容にすることが重要です。関係者の認識を統一できるよう、明確なドキュメントとしてまとめます。

要件定義書の書き方

要件定義書には決まったフォーマットはありません。要件定義書に必要な項目をリストアップし、各項目について抜け漏れや誤りがないよう、詳細に記載していきます。

項目の漏れなどが生じないよう、事前にテンプレートを準備・作成しておくとよいでしょう。一定のフォーマットがあれば、要件定義書の作成効率も向上します。

【要件定義書に必要な項目の例】

• システム導入の背景と目的
• システムの概要
• 業務要件
• 機能要件
• 非機能要件
• 技術要件
• 予算・スケジュールなど

 

要件定義書に必要な項目

要件定義書に必要な項目について、さらに詳しく見ていきます。

このように、要件定義書には現状の課題やニーズ、それらに対応するシステムの仕様を記載します。機能に関する要件だけでなく、予算や納期も定めましょう。

 

要件定義を行う際に必要なスキル

要件定義の担当者には、次のようなスキルが求められます。

• ユーザーから要求を引き出すスキル
• システム設計の可否を判断できるスキル
• 要件を言語化するスキル

必要な機能を備えたシステムの開発には、ユーザー側の要求を正しく、詳細に引き出すスキルが大前提となります。また、ヒアリングの際には、求められている機能は問題なく実装できるのか、実現可能性も判断できなくてはいけません。内容を認識齟齬なく共有するために、要件を言語化するスキルも重要になります。

 

ユーザーから要求を引き出すスキル

要件定義の最初のステップとなるヒアリングの精度は、開発するシステムの全体像をも左右します。

現状の課題や要求の詳細を引き出せなければ、求められているシステム開発のゴールは見えてきません。要求とは異なる機能を付加してしまう、あるいは必要な機能を備えていないシステムを開発してしまうといったことがないよう、徹底したヒアリングを実施し、ユーザーからより具体的な要求を引き出しましょう。

不明な点は質問する、相手の話を要約して認識にズレがないかを確認するなど、曖昧な認識をクリアにしていきます。

 

システム設計の可否を判断できるスキル

予算や納期、あるいは技術的な問題などから、要求のすべてに対応するシステムの開発は困難であるケースもあります。要求のどこまでを実現できるのか、あるいは実現できないのか、ヒアリングの場で判断し、仕分けするスキルも重要です。

そのため、要件定義の担当者にはシステム開発に関する深い知見を有する人材を配置すべきです。担当者がヒアリングの場で「実現可能」と判断したものの、実際の開発体制では実現が困難である場合、納期や予算などに多大な影響が及んでしまいます。

 

要件を言語化するスキル

要件定義の担当者には、要件を言語化するスキルも欠かせません。繰り返しになりますが、要件定義書はシステム開発の知見がないユーザーでも理解できるよう、わかりやすい記載が重要になるためです。

ただし、平易な言葉で表現するドキュメントの作成は簡単ではありません。しかし、この言語化の不備から認識の齟齬が生じると、開発過程での手戻りや余剰なコストが発生しかねないほか、プロジェクトの炎上にまで発展することもあります。

時間や工数はかかりますが、要件定義書における具体的なアウトプットは、慎重かつ綿密に実施しましょう。