YAZエンジニアが運営するメディア

開発プロジェクトが本格的に始まる前には、必ずといっていいほど要件定義という作業が行われます。いわば、開発の第一歩となる重要な作業です。要件定義の内容によっては、システム開発がとん挫・失敗してしまうことも十分に考えられます。開発側だけではなく、発注者にも要件定義への正確な理解が必要です。

こちらでは、要件定義の意味や一般的な流れ、上手に進めるために意識していただきたいポイントについてご紹介します。

要件定義の基礎知識

要件定義はシステム開発において必ず行われる作業です。どういった意味があるのでしょうか。また、どうして重要なのでしょうか。以下では、要件定義の意味や、同じような意味を持つ要求定義についてお話しします。

要件定義とは？

要件定義とは、ユーザー（発注側）の要求を実現する方法・進め方をまとめたものです。開発プロジェクトは、ゴールを定めなければ無駄な工数が増え仕様変更などの手戻りが多くなってしまうだけではなく、最終的にユーザーにとって使えないシステムが成果物としてできあがってしまうこともあります。そのため、明確なゴールを定めておくことは重要です。

要件定義は、ユーザー側が要求する仕様をヒアリングしプロジェクトのゴールを定めるため、システム開発で最初に行います。プロジェクトの進捗だけでなく、最終的に納品されるシステムのクオリティを左右する最重要作業です。

システム開発のステップは、上流工程と下流工程に大別されます。上流工程に不備があるとプロジェクト全体が失敗に終わってしまうことも少なくありません。要件定義は上流工程でも特に重要な作業として認識されています。

要求定義との違い

要件定義と混同されやすい要求定義という用語があります。要求定義とは、ユーザーの求める結果や希望を明確化することです。システムを利用することになる人が何を求めているのか、ビジネスにおいて何が必要なのかをもとにして作成されます。開発側が顧客の要求を正しくつかむために実施される作業です。

対して、要件定義はユーザーの要求をシステムで実現可能にするために必要な仕様を定義づけることを意味します。要求定義の内容をもとに、要件定義を行います。また、要求定義に変更が生じた場合は、要件定義にも変更が必要です。

要件定義の主な流れ

要件定義はシステム開発をスムーズに進めるための重要な行程です。適切な方法を知っておかなければ、時間がかかってしまう可能性があります。また、ヒアリングしておくべきユーザーの要求が抜け落ちしてしまうケースも少なくありません。

以下では、要件定義の主な流れをご紹介します。

STEP1：要求のヒアリング

まずは、ユーザー側からの要求のポイントを聞き出すことから始まります。ユーザーがビジネスで何を必要としているのか、システムによって課題をどのように解決したいのか、漏れなく具体的に聞き出すことが大切です。ここでヒアリングした情報は、上述した要求定義を行うためのベースになります。システムの構造に関わる機能要件だけでなく、セキュリティなど非機能要件についても聞く必要があります。

STEP2：要求の細分化

続いて、ユーザーの要求を明確化し、実現可能か整理します。要求によっては理論的に実現できない場合があるため、その場合は必要に応じてユーザーと相談を行い、代替案を考えなければなりません。また、理論上は実現可能であっても、コストやスケジュールなどの都合で困難な場合があります。そのため、必須要件と希望要件に分けるなど、優先順位を付けておくのも大切です。

STEP3：要件定義書の作成

最後に、ここまでヒアリングした要求を要件の形まで落とし込んだ要件定義書を作成します。

具体的には、以下のような項目を記載します。

• システムの概要
• システムを導入する目的
• システム導入後の業務フロー
• ユーザーの要求と必須要件

こうした内容をシステム要件として記載し、基本設計や詳細設計などシステム化の具体的な作業に移っていきます。

要件定義を上手に進めるポイント

要件定義には意識すべきポイントがあります。何も考えずに要件定義を行うと時間がかかるだけではなく、開発に着手してから問題が発覚する場合もあるため注意が必要です。以下では、要件定義を上手に進めるためのポイントをご紹介します。

役割分担を明確化する

要件定義では、ユーザー側と開発側の双方にタスクがあります。例として、現行業務の洗い出しなどはユーザー側で担うべきタスクであり、本来開発側が担うものではありません。こうした業務の担当を開発側が請け負ってしまうことにより、時間がかかるだけではなく、システムに求められる仕様が正しく浮き彫りにならないことがあります。

そのため、まずユーザー側と開発側で役割分担を明確化することが大切です。具体的には、プロジェクトごとに担当者を確定させる必要があります。可能限りタスクを細分化することで、業務間の影響を防ぎ、全体の進行に支障が出ないようにするためです。

ユーザーの現行のシステムを把握する

多くのユーザーは現行のシステムに問題点を感じ、刷新を希望しています。現状の問題点や解決方法を導き出すため、現場で使われている現行システムについて把握しておくことが重要です。業務フローやシステムがどのように使われているのか把握し、ユーザーとどんなシステムが必要なのか導き出す必要があります。

現行システムを理解するためには、資料だけではなく保守担当者との打ち合わせも求められ、時間がかかることも少なくありません。しかし、システム設計を効率的に行うためには、この段階で時間をかけ、現行システムの問題を顧客との間で共有しておくことが大切です。

ユーザーの要求と要件定義書をすり合わせる

ユーザーの要求と要求定義所のすり合わせを入念に行うことも大切です。具体的には、開発側で定義した要件定義書の仕様で、要求が実現可能かユーザー側としっかり協議する必要があります。

認識の違いにこの段階で気づかず開発に移行した場合、手戻りが発生する可能性があります。スケジュールがずれ込んだ場合は納期に間に合わないケースもあるため、慎重なすり合わせが必要です。

要件定義書をわかりやすく作成する

要件定義書はさまざまな人が読むことになります。それぞれリテラシーや専門分野が異なるため、関係者間で認識の齟齬を生じさせないようにするため、わかりやすく作成することを意識する必要があります。開発についての専門知識がないユーザーでもわかるように記載すると良いでしょう。

要件定義に必要なスキル

要件定義の担当者には、いくつかのスキルが求められます。代表的な適性である「コミュニケーション力」「開発業務に関する知識・経験」「スケジュール管理能力」「文書化スキル」についてご紹介します。

コミュニケーション力

要件定義にはユーザーからの要求をユーザーから要求を適切にヒアリングするためのコミュニケーション力が求められます。さらに、ユーザーの意図を汲み取って要件定義書に落とし込まなければなりません。

実現不可能な欲求を飲むとクレームや手戻りなどトラブルの原因につながる可能性があります。そのため、ユーザーの要求が実現可能か吟味した上で不可能な場合は、妥協するように促すか、代替案をユーザーと共同で探す必要があります。

開発業務に関する知識・経験

要件定義には、開発業務に関する知識や経験もある程度必要です。ユーザーの要求をヒアリングした上で、実現するためにどのような解決策があるかイメージしやすくなります。特に、担当者が実現可能な要求の範囲を把握していない場合は問題です。要件定義の担当者が「実現可能」と判断した要求に対し、開発のメンバーが苦労する案件の例は多く見られます。

スケジュール管理能力

要件定義では、必要な工程から逆算してスケジュールを設定する必要があります。そのため、スケジュール管理能力も求められます。

どの作業にどれくらいかかるか、おおよその作業時間を把握できていることが重要です。開発の経験があると、各作業にかかる時間をイメージしやすいでしょう。

文書化スキル

ユーザーや開発メンバーなどさまざまな人が読むことを想定し、誰にとってもわかりやすく、認識の齟齬が生まれにくい文書を作成するためのスキルが求められます。

システムの詳細を数値や言葉で正確にわかりやすく表現できる能力が必要です。テキストのみで仕様書を構成しなければならないルールはありません。適宜、図やイメージを用いると良いでしょう。

要件定義はシステム開発の最重要タスク

要件定義の内容や重要性について解説しました。ゴールが明確化されていないまま開発に移行すると、クライアントとの間に問題が生じます。そのため、開発作業に入る前のフェーズで要件定義を行い、クライアントとの間で開発のゴールを設定しておくことは重要です。

一方で、要件定義には今回ご紹介したようなスキルが求められ、一般的には難しい作業として認識されています。担当する人材は慎重に選ばなければなりません。YAZでは経験豊富なエンジニアが要件定義をしっかり行いますので、初めてのシステム・アプリ開発の際にぜひご検討ください。