要件定義とは？流れや要件定義書の内容・必要スキルも解説
COLUMN

要件定義とは、システム開発を進める初期段階で必要な機能や要求を明確にして、その内容を文書としてまとめる作業のことです。要件定義は開発初期に行う工程であるため、その後のシステム設計・実装・テストという開発の流れに大きく関わる項目と言えます。要件定義が曖昧であれば開発終盤で大幅な修正が入り、納期に影響を与える恐れもあるでしょう。

当記事では、要件定義の基本的な意味やプロジェクト内での位置づけ、具体的な流れなどを解説します。システム開発でプロジェクトを成功に導きたいという方や、要件定義について詳しく知りたいという方は必見です。

1.要件定義とは？

システム開発を円滑に進めるために、事前準備として要件定義を行います。要件定義とは、開発するソフトウェアに盛り込む、機能要件と非機能要件を明確化する作業のことです。

機能要件とは、クライアントから受けた機能面に関する要望をさします。どのようなシステムを開発するか計画するとき、機能要件は最低限満たすべき必須要件とも言えます。一方の非機能要件とは、保守やセキュリティなどユーザビリティに関係する機能面以外の品質要件のことです。

機能要件のみを満たしても、クライアントにとっては最低限の依頼を遂行したのみであり、顧客満足度にはつながりません。非機能要件のみに注力しても、最低限求められる機能要件を満たしていなければ、システム開発プロジェクト自体は失敗と言えます。

クライアントに満足してもらうためには、機能要件と非機能要件どちらもバランス良く実現することが大切です。要件定義で事前に複数の要望をカテゴリ分けして整理することで、開発者側もクライアント側もシステムの完成イメージを描きやすくなります。

1-1.要件定義のプロジェクト内での位置づけ

システム開発は、要件定義・基本設計（外部設計）・詳細設計（内部設計）・開発・テスト・リリース・運用・保守と複数の工程があります。開発における工程は上流・下流に分けて考えられることが多く、要件定義に近いものが上流工程と呼ばれます。

要件定義は、上流工程の中でももっとも初期の段階です。要件定義に誤りや大々的な変更があれば、川の上流・下流の関係と同じように後の工程へ影響を及ぼします。トラブルを防ぐためにも、クライアントと開発側の認識をすり合わせ、慎重に要件定義を行う必要があります。

システム開発における上流工程の特徴や主な流れについては、下記のページもご覧ください。

システム開発の上流工程とは？流れとポイントを解説

テスト自動化ツールならATgo
1か月トライアル無料：詳細はこちら

2.要件定義の流れ

要件定義では、いくつかの段階を踏んだ上で文書として残す作業を行います。クライアントの要望を確認するのみならず、開発作業が円滑に進められるように、文書作成もカテゴリ別に分けるなどの事前準備が必要です。

ここでは大きく3つのステップに分けて、要件定義を進めるときの手順を紹介します。

2-1.要求のヒアリングを行う

最初に行う作業が、クライアントとの要件確認です。ヒアリング時はベンダーの担当者が主に対応することもあれば、大規模なプロジェクト時のように開発部の担当者が数名参加することもあります。

要件定義工程におけるヒアリングは、主に下記のポイントを確認します。

機能の明確な要望がないときは、ヒアリングでどのようなシステムを求めているのか開発目的を確認して提案します。

ヒアリングをしているうちに、クライアントの要望と求められている機能との間に矛盾や無理が生じることもあります。適宜修正や提案を行いつつ、希望納期までに本稼働できるかスケジュールの交渉も行いましょう。

2-2.要件整理を行う

ヒアリングした内容を反映するのみでは、複雑な文書となるおそれがあります。要件定義の最終的な目的は、開発の指標となる分かりやすい要件定義書を作成することです。開発メンバー全員が理解できるように、ヒアリングした内容を整理して、可能な限りシンプルな内容に仕上げるように意識しましょう。

要件整理を行うときのポイントは、クライアントからの要求内容に優先順位をつけることです。クライアントがどのようなゴールを想定して要求を出しているのかを確認した上で、課題の洗い出しや解決に適した要件、スケジュール的な実現性を検討します。

要件の抜け漏れを防止するためには、打ち合わせを繰り返して何度も要件整理することが大切です。

2-3.要件定義書を作成する

必要な情報を整理した後は、要件定義書を作成します。プロジェクトの目的や課題、解決につながる要件や機能をまとめるときは、分かりやすく記載することが大切です。

分かりやすさの基準として、IT知識のない人でもプロセスや必要性が理解できる書き方を心がけましょう。クライアントは、必ずしもシステム開発に詳しい人が担当するとは限りません。リリース後に「要求と違う」とトラブルが生じないように、理解しやすい要件定義書を作成する必要があります。

3.要件定義書に記載する内容

要件定義書は、クライアント側も理解できる内容にまとめることが大切です。同時に、開発者側の基準となるように、必要な情報を抜け漏れなく記載する必要もあります。

要件定義書に最低限盛り込むべき項目として、以下の5つが挙げられます。

完成した要件定義書は開発者側の意思決定のみならず、クライアント側からの合意も得る必要があります。トラブル防止のためにも、各項目に分かりにくい部分はないか、入念に確認しましょう。

4.要件定義に必要なスキル

要件定義を円滑に進めるには、さまざまなスキルが必要です。IT知識の少ないクライアントと接する可能性もあるため、聞き取った要望を適切にまとめられる専門知識に加えて、ヒアリングに役立つスキルが求められます。

ここでは、要件定義の場面で生かせる3つのスキルを解説します。

4-1.コミュニケーションスキル

クライアントの要求を聞き出し、的確に盛り込むべき機能の提案を行うために必要な力が、コミュニケーションスキルです。

また、プロジェクトには開発者側も多くの人が関わります。さまざまな立場の関係者の事情を考慮しつつ、予算や納期の希望に応じた要件定義書を作成しなくてはなりません。

プロジェクトの関係者それぞれが躊躇なく意見や疑問を共有できるような環境づくりや会話の運び方ができる、優れたコミュニケーションスキルが求められます。

4-2.スケジュールを管理するスキル

クライアントが満足する品質でシステムを開発するためには、適切なスケジュール管理スキルが必要です。スケジュール作成を円滑にするコツとして、WBSに沿ったガントチャートの作成が挙げられます。

WBSとはWork Breakdown Structureの略語で、開発に必要な作業を工程ごとに書き出した表のことです。WBSとガントチャートで誰がいつまでに何をすべきなのか書き出し、予算や納期も考慮してスケジュールを組みましょう。

4-3.ドキュメント作成スキル

要件定義書を作成するときは、最終的にクライアントと開発担当者、双方の合意を得ることを念頭に置かなくてはなりません。分かりやすい要件定義書を作成するために求められる力が、ドキュメント作成スキルです。

IT知識のない相手にもソフトウェアの仕様が伝わるドキュメントを作成するコツは、目次をつけることです。目次をつけて、1つのスライドに1つのテーマを記載するように心がければ、シンプルで分かりやすいドキュメントに仕上がります。

まとめ