システム開発の要件定義。進め方や項目、失敗しないためのポイントを解説 | HRog

システム開発工程の一つである要件定義。進め方やどのような項目があるのか、気になる担当者もいるのではないでしょうか。システム開発を外注する場合においても、クライアントが要件定義を理解することは重要です。今回は、システム開発の上流工程にあたる要件定義の役割や重要性、失敗しないためのポイントをわかりやすく解説します。

システム開発における「要件定義」の役割

要件定義は、システム開発で一番最初に行われる工程です。まずはその意味と役割について解説します。

要件定義とは、開発の目的を明確にする作業のこと

要件定義とは、システム開発の「目的」を明確にする作業のこと。システム開発工数全体のおよそ20％を占める重要な工程です。

要件定義では、クライアントがそのシステムで何をしたいのか、なぜそのシステムが必要なのかを明確にし、その実現のために必要な「機能」や「性能」を洗い出していく作業が行われます。

要件定義は開発成功を左右する「最重要プロセス」

要件定義は開発の成功を左右する最重要プロセスと言っても過言ではありません。

「開発中でも要件定義を変更できるのでは？」と考えるクライアントもいるかもしれませんが、通常、後から要件定義は簡単に変えられるものではないことを理解しておきましょう。

要件定義がきちんと定まっていることで、作業途中の変更を最小限とすることができ、結果として時間とコストが抑えられ、納期に間に合うようにプロジェクトが進められるのです。

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

要件定義と混同しがちな用語に「要求定義」と「基本設計」があります。要件定義との違いは何のか、ここで確認しておきましょう。

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

要求定義とは、システム開発で「〇〇がしたい」「こういう機能がほしい」というクライアントの希望を確認する作業のことです。

要件定義がクライアントの要求を踏まえて、具体的なシステムの仕様を決定する作業であるのに対し、要求定義は、クライアントの希望、つまり「システム開発に求めるもの」をまとめる作業を指します。要件定義の前工程と覚えておきましょう。

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

基本設計とは、要件定義の内容をもとに機能ごとにどのような開発を行うかを決定する作業のことです。基本設計では、要件定義を元にシステムの外部仕様を決めていきます。要件定義の後工程と覚えておくとよいでしょう。

要件定義の進め方

システム開発を外注する場合でも、要件定義の進め方を理解しておくことは大切です。流れを知っておくことで、今どの段階にいるのかが理解でき、不安なく開発会社に任せることができるでしょう。ここでは、要件定義の進め方を開発者とクライアントの双方の視点でご紹介します。

1．要求のヒアリング

要件定義で最初に行われるのが、開発会社による「要求のヒアリング」です。開発者側は、クライアントの潜在的な要求を掘り起こすことを目的として、ヒアリングを実施します。

この段階で十分な打ち合わせを行い、内容をすり合わせていくことが重要となるでしょう。クライアント側としては、自社の「要求」を開発者に伝えられるよう、理想的なゴールをイメージしておくことが大切です。

2．要求を細分化し、要件・内容を決めていく

次に、ヒアリングによりまとめた要求を細分化し、要件・内容を決めていきます。要望通りのシステムとして動くために「必要な機能」を洗い出す工程です。

この工程では、現状の問題点について掘り下げ、解決策を検討し、一つ一つの機能の要件を細部までまとめる作業を行います。

クライアント側としては、ヒアリングの時点で要求を伝えたからと安心せずに、細分化された要件にも目を通し、見落としが無いかしっかりと確認する必要があります。ただし、要求のすべてをシステム化できるとは限らないという点も頭においておきましょう。

3．要件定義書を作成する

最後に、開発会社が要件定義書を作成します。要求定義書とは、これまでクライアントからヒアリングし、細分化した「要求」を体系的に分析・整理した書類のことです。

クライアント側としては、システムに求める「要求」とそれに必要な「要件」について、納得がいくまで確認をすることが大切です。

HRog編集長菊池

ベンダー側は単にクライアントの要求だけを整理する（クライアントに言われたものだけを作る）のではなく、ビジネスを取り巻く環境を含めてそのシステムで解決したいゴールを理解し、提案する必要があります。「他のサービスでは求職者に隙間時間にライトに使ってもらうコンセプトなので、チャット機能が搭載されていますが、今回の開発の対応範囲にしますか？」など、サービス・ビジネスに理解があるベンダーを選定すると、企画の壁打ちが進み、より理想とするサービスになります。

要件定義書の「成果物」として必要な項目

要件定義書には、どのようなことが記載されているのでしょうか。要件定義書の「成果物」として必要な項目は多岐に渡りますが、ここで主な項目を説明します。

要件定義書に必要な項目例

システムの概要や構想・目的
機能要件
非機能要件
システム導入後のフロー
セキュリティ要件

●システムの概要や構想・目的

システムを導入する目的やその背景、システムの概要や範囲についての項目です。認識の相違が生じないよう、成果物として記載されます。

●機能要件

機能要件の項目では、システムで何ができるようになるのか具体的な機能に加え、ヒアリング時に要求のあった機能が詳細に記載されます。プロジェクトの目標となる項目と言えるでしょう。

●非機能要件

非機能要件の項目では、機能面以外の要件全般について記載されます。システム性能に加え、セキュリティや保守・運用サービスなどが内容に含まれます。プロジェクトが成功したか失敗したかどうかの指標としても利用される重要な項目です。

●システム導入後のフロー

システムを導入した後に業務フローがどのように変わるのか説明する項目です。大きな体制変更がある場合は、フローチャートがあると、よりイメージしやすくなるでしょう。

●セキュリティ要件

情報漏洩やウイルス感染などの被害を避けるためには、セキュリティ要件も重要な項目です。どのような攻撃手法が想定され、それに対してどのような防御法を取るのか、さまざまなパターンに対応可能なシステムを構築するための項目が記載されます。

要件定義書は、システム開発における全ての土台であり、要件定義後の工程である「システム設計」に落とし込む前段階です。最低でも上記の項目が書かれているかどうか確認しましょう。

要件定義で失敗しないためのポイント

つづいて、要件定義の工程では、どのようなことを意識しておくとよいのでしょうか。要件定義で失敗しないためのポイントをまとめました。

＜ポイント1＞システム開発でやりたいことを明確にする

システム開発が必要な理由は何なのか、システム導入の「目的」を明確にしましょう。そうすることで、「どのような機能を搭載するべきか」などのシステム開発の優先順位が明確になります。

＜ポイント2＞クライアントと開発会社でお互いの認識を統一する

クライアントと開発会社で、お互いの認識を統一することも大切にしたいポイントです。開発途中や開発後に「思っていたのと違った」と後悔しないよう、システムに期待することや役割、目的を共有し、意見の食い違いがないように話し合いましょう。

＜ポイント3＞スケジュールやロードマップを共有する

要件定義で失敗しないためには、スケジュール管理や運用開始後の体制に関する計画も大切です。必要な要件や機能をもとに、すべての工程にスケジュールを立て、運用後の体制も整えておきたいですね。

HRog編集長菊池

システムにおいて、要件定義時にエラー対応も想定しておくのが大切です。開発に慣れていない場合、システムが想定した使われ方をすることばかりを考えていくことが多いですが、想定されない使われ方をするのもシステムです。どういった場合にどんなエラーを表示するのか考えておきましょう。「ログインパスワードを忘れた場合」などは容易に想像がつきますね。