システム開発の本質的な目的は、物理的なITインフラを構築することそのものではなく、発注者が抱えるビジネス上の課題を解決することにあります。そこで重要となるのが、発注者の要望を明確化する「要件定義」です。本記事では、要件定義の具体的な進め方や押さえるべきポイントなどについてご紹介します。
要件定義とは？
「要件定義」とは、発注者の要求を踏まえながらシステムの仕様を定義するプロセスを指します。システム開発では、「要件定義」→「外部設計」→「内部設計」→「プログラミング」→「テスト（単体・結合・総合）」→「運用」の各工程を時系列順に進めていくのが一般的です。そして、要件定義・外部設計・内部設計を「上流工程」、プログラミング・各種テスト・運用を「下流工程」と呼びます。
こちらの記事も合わせてご確認ください。
「要件定義」と「基本設計」の違いとは？基本の流れとポイントを解説
上流工程の役割は、発注側の要求や課題をシステム設計へと落とし込むことです。なかでも要件定義は、システムに実装する機能や性能などの「機能要件」と、可用性やセキュリティといった「非機能要件」を具体化するプロセスであり、発注者の成否を担う最も重要な工程といっても過言ではありません。
システム開発における重要課題のひとつは、発注側と受注側が発注者の全貌を共有することです。そのためには機能要件と非機能要件を言語化・数値化し、要件定義書として落とし込むプロセスが不可欠となります。
要件定義と要求定義の違い
「要件定義」と「要求定義」は混同されがちな用語ですが、その定義は明確に異なります。まず「要件」は「必要な条件」や「肝要な事柄」を意味する概念であり、システム開発の領域では「実装する仕様」を意味する用語です。
一方で「要求」は「強く求めること」といった意味合いをもち、「システムに求める仕様」を指します。要求定義は「何を実現したいのか」という発注者の要望を扱う工程であり、そこから「何を実現するのか」という仕様を明確にする工程が要件定義です。つまり、要求定義とは要件定義における最初のステップと位置付けられます。
要件定義書を作成する理由
要件定義書を作る主な目的は、発注者の全体像を明文化し、発注側と受注側で認識を共有することにあります。それぞれの認識に齟齬がある場合、システム開発の進行を妨げる要因となり、最悪の場合は発注者が契約を解除してしまうことにもなりかねません。要件定義書の作成は契約の大枠となるため、発注者と開発側の認識のくい違いが生まれにくくなります。
また、システム開発の各工程は役割を分担して行うため、その過程でメンバー間の認識に差が生じる可能性も否定できません。要件定義書をまとめることでメンバー間の意思疎通を図る一助となり、開発の円滑な進展に寄与します。
要件定義の進め方
要件定義の工程に絶対的な正解はないものの、一般的には以下のプロセスに沿って展開されます。
・要求の本質を理解する
・要求を分類し必要な機能を明確にする
・要件定義書を作成する
要求の本質を理解する
発注者の要望をしっかりと落とし込むためには、要求を正確に理解し、要件へと変換する必要があります。そのためには、発注者が求める要望を入念にヒアリングし、その実現の可能性を客観的な視点から評価した上で、要件と開発スケジュールを設計しなくてはなりません。ヒアリングを通して発注者の要求と要件をすり合わせ、発注者の意図する内容を正確に掴んでいきます。
要求を分類し必要な機能を明確にする
ヒアリングによって発注者の要望が明確化されたなら、次はその要求を整理し、要件を具体化する必要があります。発注者の要望をすべて満たせるとは限らないため、業務プロセスを分析し、本当に必要な機能を選別しなくてはなりません。このシステム化の対象となる業務プロセスを明確化したものを「業務要件」といいます。
そして、業務要件を満たすために、どのようなものを機能として実装すべきか定義したものを「システム要件」と呼びます。この工程では発注者の要求を細かく分類し、見落としがないか確認するとともに、本当に必要となる機能を洗い出すことが重要です。
要件定義書を作成する
細分化した発注者の要求を分析・整理し、全体像から詳細まで矛盾がないように定義された要件をドキュメント化します。要件定義書にはシステムの機能や性能といった機能要件はもちろん、可用性や拡張性、保守性、移行性、セキュリティ、システム環境などの非機能要件も含めた設計の全容を記述します。
また、実装後の業務フローの変化やアクセス権限の設定、用語定義、利用者一覧、開発スケジュールなどの要素も網羅しなくてはなりません。要件定義書は、システム開発において羅針盤となる要素のため、発注側と受注側の双方が納得いくまで意見をすり合わせる必要があります。
要件定義をする上で押さえるべきポイント
発注者が求めることを明確な要件として定義するためには、以下に挙げる3つのポイントを押さえることが大切です。
・誰でもわかるようにドキュメント化する
・役割の分担を明確にする
・知見のある技術者が判断する
誰でもわかるようにドキュメント化する
先述したように、要件定義書の役割は発注側と受注側が開発の全貌を共有することです。システム開発に関わるのはプログラミングに精通したエンジニアだけではなく、発注側と受注側のさまざまな人物が関与します。したがって、システム開発における全工程を共有するためには、誰が読んでも把握できるドキュメントを作成しなくてはなりません。構築するシステムの詳細を具体的に落とし込むのはもちろん、開発イメージを図などによってビジュアライズしたり、ドキュメントのフォーマットをそろえたりといった工夫が求められます。
役割の分担を明確にする
要件定義の工程では、発注側と受注側の双方に取り組むべきプロセスが存在します。たとえば、システムを実装・構築するのは受注側ですが、既存の業務フローを洗い出し、システムへの要求を定義するのは発注側の役割です。ここを曖昧にすると認識に齟齬が生じ、後々の作業工程において手戻りが発生しかねません。また、こうした発注側が行うべきタスクを受注側が担当した結果、システムが業務要件を満たせず、大きなトラブルに発展する可能性もあります。そのため、発注者を含め各工程において役割分担を明確化することが大切です。
知見のある技術者が判断する
要件定義書の役割は認識の共有であり、すべての関係者が理解できるように作成しなくてはなりません。しかし、要件の実現可能性を判断できるのは、ITやプログラミングに関して高度な知見を備えた技術者です。プログラマやエンジニアの知見がなくては、要件に抜け漏れが発生する可能性もあります。要件に抜け漏れが生じた状態で実装に進んだ場合、テスト段階や運用後に問題が発覚することになり、多大な損失を被りかねません。そのため、要件定義書は誰でも理解できるよう作成する必要があるものの、担当者だけで判断するのではなく、システムの実装に関して高度な知見をもつ技術者が必ず詳細をチェックし、実現可能性を判断する必要があります。
まとめ
「要件定義」とは、システムに求められる機能要件や非機能要件を定義し文書化する工程を指します。システム開発の土台であり、その後の進展を左右する非常に重要な工程です。
ソフトウェアの品質向上にはOBPM Neoのようなプロジェクト管理ツールの導入もおすすめです。
