ITシステムやソフトウエアの開発は、設計やプログラミング、テストなどさまざまな工程を経てリリースされます。その中でもプロジェクトの初期段階で行う「要件定義」は、システムで実装する範囲や内容を決定する重要な工程です。

プロジェクト全体の道しるべとなるため、要件定義がシステム開発の成功を左右するとも言われます。重要な工程であるがゆえに、どう進めるべきか頭を悩ませている人も多いかもしれません。

今回は要件定義の概要や進め方、成功させるためのポイント、失敗事例まで詳しく解説します。

要件定義とは

要件定義とは、システム開発における「目的」を明確にする作業のことを指します。クライアントがそのシステムで何をしたいのか、なぜそのシステムが必要なのかを明確にし、開発者側が要件へ落とし込みます。

そしてそれを実現するために必要な機能や性能を洗い出してプロジェクトの具体的な進め方を決定する、システム開発の土台となるものです。

要件定義を誰が担当するかは、企業の体制やプロジェクトによって異なります。しかし一般的にはシステムエンジニア（SE）やプロジェクトマネージャー（PM）といった職種の人が担当することが多いです。

これらの職種は実際に手を動かしてプログラミングなどの開発業務を行うことは少ないかもしれませんが、精度の高い要件定義を行うには深い技術的知見が欠かせません。

IPA（独立行政法人 情報処理推進機構）でも要件定義の不備に起因した手戻りによるトラブルを防ぐため、要件定義を含む上流工程の強化が推奨されています。

参考：システム構築の上流工程強化（要件定義・システム再構築）／IPA 独立行政法人 情報処理推進機構

上流工程と下流工程の定義

システム開発においては「上流工程」と「下流工程」という言葉がよく使われますが、中でも要件定義は「最上流工程」といわれます。では、上流工程と下流工程の明確な定義とは何でしょうか。

上流工程や下流工程という言葉は、ウォーターフォールモデルという開発手法から取られたものです。

ウォーターフォールモデルは「工程を一つずつ順番に終わらせていく開発方法」を指します。水が高いところから低いところへ流れ落ちるように、最初の工程から最後の工程に向かって一つずつ順番に進めます。

このことから、工程前半のシステムの作り始めの部分を上流、工程後半のシステム構築完了までを下流というようになりました。具体的には要件定義から詳細設計までが上流工程、プログラミングによるシステム実装からテストまでが下流工程とされることが一般的です。

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

要件定義と似た言葉で「要求定義」というものがあります。これらは混同しがちですが、明確な違いがありますので確認しておきましょう。

まず要求定義とは要件定義の前段階で実施する、クライアントの希望を確認する作業です。クライアントが目標を実現するために必要なニーズの中から、システムで実現したい要求事項を整理します。

要件定義は要求定義の内容を受けて、開発者の視点からシステム要件に落とし込む作業です。クライアントの要求を実現するために予算やスケジュール内で実装可能な機能や性能を定め、具体的な進め方を決定します。

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

では、要件定義の具体的な進め方について解説します。プロジェクトや所属企業によって細かいプロセスは異なりますが、必須とされる基本的な内容は同じですので把握しておきましょう。

【1】ユーザーの要求をヒアリングする

まずはシステム開発の目的やゴールを明確にするため、ユーザーとなるクライアントの要求をヒアリングします。先に紹介した、要求定義の段階です。どのような課題を解決したいのか、システムを使用して何がしたいのかといった目的や背景を確認します。

ユーザーの要望をただ聞くだけでは、顕在化していない潜在的なニーズを発見できないこともあります。

ユーザーの業務内容や課題を深く理解した上で適切なヒアリングを行い、真の意図を汲み取れるよう意識することが大切です。またすべての要求を実現できるとは限らないため、優先順位を確認しすり合わせておきましょう。

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

ヒアリングした要求を細分化して整理し、システム化すべき要件・内容を決定します。要求を実現するために必要な機能を洗い出す作業です。一つ一つの機能の要件を細部までまとめていきます。

いきなり要件定義書といった成果物に着手するのではなく、内容の整理や必要な機能の検討にじっくりと時間をかけることで、完成したシステムを使うユーザーの満足度向上につながります。

【3】実行計画を立てる

システム要件が決定したら、具体的な実行計画を立てます。要求を満たす機能を決定したとしても、プロジェクトの予算やスケジュールをオーバーするようなら実現は難しいでしょう。

行うべき開発内容から必要な工数や費用を具体的に割り出し、クライアントへ見積もりを提出します。対応範囲や全体のスケジュール、プロジェクトに関わるメンバーすべてを考慮する必要があり難しいですが、後工程でのトラブルを避けるためにも入念に計画を立てましょう。

【4】要件定義書を作成する

システム要件と実行計画が固まったら、要件定義書を作成します。要件定義書はここまで整理した内容を体系的にドキュメントに落とし込んだものです。

この後の工程であるシステム設計の前段階となるため、開発メンバーとも共有できるよう細分化された機能まで記載します。一般的に要件定義書に必須とされる項目には以下のようなものがあります。

要件定義に必要なスキル

最重要工程とされる要件定義を行うエンジニアには、具体的にどのようなスキルが必要なのでしょうか。

コミュニケーションスキル

ユーザーの要求を引き出して正しく要件に落とし込むには、適切なヒアリングを行うコミュニケーションスキルが必要です。ユーザーの認識と要件にズレが生じると、その後の全工程に影響が生じます。細かな部分まで相手の意図に寄り添い、すり合わせを行うコミュニケーションスキルは非常に大切です。

スケジュール・リスク管理スキル

要件定義はプロジェクト全体の進行を考慮しなければなりません。納期や予算、実現できるシステムの内容などを総合的に検討して進行させるスケジュール管理やリスク管理のスキルが必要です。

開発業務の知識・スキル

要件定義はユーザーの要求をシステム化した際にどのように動くのか、ユーザーのオペレーションがどのようになるのかを具体的にイメージして実現可能がどうか判断する必要があります。その後の工程でのトラブルを防ぐためにも、開発業務の経験や深い知識は必要不可欠です。

ドキュメンテーションスキル

要件を決定するだけでなく、ユーザーや開発メンバーに共有するために適切にドキュメント（要件定義書など）に落とし込むスキルも必要です。設計以降の工程ではもちろん、システム稼働後のメンテナンス時や仕様変更時にも参照されることがあります。ミスやトラブルを避けるためにも、誰が読んでも分かりやすい表現を意識しましょう。

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

要件定義の基本的な進め方や必要スキルについて理解できたら、実際に要件定義を行う上で特に注意すべきポイントについても押さえておきましょう。

要件定義の成功ポイント1.5W2Hを明確にする

要求定義・要件定義のためのヒアリングでは抜け漏れや曖昧な部分がないよう、ITシステムにおける5W2Hを意識するのがおすすめです。

・要求

Why：なぜシステム化が必要なのか
What：何を実現したいのか

・システム要件

Where：要求を実現するためにどの部分をシステム化するのか
Who：誰がシステムを利用するのか
How：どのように要求を実現するのか

・プロジェクト要件

When：いつまでに開発するのか
How much：どのくらいの予算が必要なのか

要件定義の成功ポイント2.ユーザーの現行システムと業務フローを把握する

要件定義には現行システムの課題を解決するという目的が含まれることが多いです。課題を理解し解決するには、現行システムの構成や業務フローを正しく把握する必要があります。可能な限り入念に調査・確認を行いましょう。

要件定義の成功ポイント3.プロジェクトの役割分担を確認する

要件定義を進める上で、クライアント側と開発側の役割を明確に定めておく必要があります。例えば現行業務の洗い出しや整理、将来的なビジョンの策定などはクライアント側が行わなければなりません。曖昧なままにしたりクライアント側の業務まで開発側が引き取ってしまったりすると、本来行うべき業務の進行に影響します。あらかじめ担当範囲は明確に設定しておきましょう。

要件定義の失敗事例

最後に、要件定義で多く見られる失敗事例を紹介します。同じ失敗をしないためにも、ぜひ参考にしてください。

失敗事例1.要件のすり合わせ不足で炎上

クライアントと開発側で要件のすり合わせが足りず認識の齟齬が発覚した場合、作業のやり直しなどが発生して結果的に炎上するというケースがあります。ここで言う炎上とは、当初の計画や予算通りに作業が進まず、納期までの達成が不可能になる事態を指します。これは打ち合わせの段階で正しい認識のもと要件定義ができているという勘違いから発生することが多いです。くれぐれも確認やコミュニケーションは入念に行いましょう。

失敗事例2.予算と規模が見合わない

クライアントの要求をなるべく実現しようと、あらゆるニーズを受け入れてしまい開発プロジェクトの規模と予算が結果的に見合わないというケースもあります。予算が設定されている以上、すべてのニーズを満たせるとは限りません。無理な計画を立てることでプロジェクト自体が頓挫したり、下流工程のメンバーに無理をさせてしまったりします。要件定義の段階で、実現できない要求については断ることも重要です。

失敗事例3.開発条件とアサインメンバーのミスマッチ

開発チームにアサインしたメンバーのスキルが開発条件に合わなかったり不足したりしていて、スケジュールが遅延するというケースもあります。予算によってアサインする人員は調整しなければなりません。それぞれのメンバーのスキルをきちんと把握した上で、プロジェクトの開発条件に見合ったスキルを持つメンバーをアサインする必要があります。

要件定義のスキルを磨いて、エンジニアとしての市場価値を高めよう

要件定義はシステム開発の成功・失敗を左右する非常に重要な工程です。要件定義の内容次第でその後の工程に良くも悪くも影響するため、難しく感じる方も多いでしょう。実際要件定義には、開発技術や知識だけでなくさまざまなスキルが求められます。

しかし重要な任務をクリアしてプロジェクトを成功に導くことができれば、大きなやりがいを感じられるはずです。難しい業務ゆえに適切な要件定義を行えるエンジニアは少なく、市場価値は非常に高い傾向にあります。

ぜひ要件定義のスキルを磨いてレベルアップできるよう、前向きにチャレンジしてみてください。

文／江副杏菜