要件定義はシステム開発プロジェクトを成功させるために不可欠なものです。すべての要件をきちんと文書化すれば、プロジェクトはお金、労力、時間の膨大な浪費を防ぐことができます。見積もりやタスクの割り当てを効率的に行い、開発チームは納期を確保することで、顧客の満足につながります。

本記事では、要件定義の概要と具体的な進め方と、優れた要件定義書の特徴をわかりやすく丁寧に解説します。

要件定義とは

要件定義はシステム開発を本格的に開始する前に、開発者の視点からユーザー側の要求を整理しながら、必要な業務内容を文書化する段階です。要件定義の工程のアウトプットは要件定義書となりますが、ユーザー側が求めているシステムの機能だけでなく、その目的、スケジュール、予算、実施体制などの想定も要件定義書に反映されます。そのため、要件定義をしっかりすれば、正確なプロジェクトの全体計画ができます。逆に、要件定義で、ユーザー側の要望を十分に掴めないと開発段階で手戻りが多数発生することで、システムの品質と納期に悪影響を及ぼす可能性があります。

そのため、要件定義はシステム開発業界で長年の経験を持つ方が担当することが多いです。

「要件仕様書」と「要件定義書」の違い

要件仕様書と要件定義書は類似した内容が多いためよく間違えられますが、簡単に説明すると、「要求仕様書」というのは発注するお客様側が「このようなシステムを開発したい」「こういう機能が欲しい」という要望をまとめて、開発側に渡すものです。つまり「提案依頼書」ともいえます。

一方で、開発側はお客様が提出する要件仕様書の内容に基づいて、エンジニアの観点でその要望を「システム開発業界の言葉」に変換します。その変換作業を「要件定義」と呼びます。

しかし、「担当者が忙しい」「IT知識がない」といった理由で、要件仕様書の作成ができない企業が多く存在します。その場合に開発側は、お客様にヒアリングを重ねた上で、要件仕様書がないまま、直接要件定義を進めるケースもあります。

弊社でもお客様のアイディアをまとめて、事業化までサポートするサービスを提供しており、詳細についてはNTQコンサルティングサービスでご参考ください。

要件定義の進め方

要件定義という作業のアウトプットは「要件定義書」となりますが、適切なものを作成するためには、以下のステップで行うことが必要です。

①お客様の要求の明確化

上記にも述べた通り、プロジェクトのゴールはお客様の要望を実現することであるため、これは最も重要なステップです。

また「何を作りたい」「こうしてほしい」という細かい要望より、「その開発でどんな課題を解決したいか」「その解決でどんな目標を達成したいか」という本来の目的に注意を向ける必要があります。全体像を共有してもらうことで、開発したものがお客様の目的から乖離することを未然に防ぐことができます。

②システム全体の構成の明確化

お客様の要望をヒアリングした後、それを満たす機能を考えることが多いですが、要件漏れを防ぐためには、システム全体の構成要素を十分に検討することが必要です。

例えば、どんな簡単なシステムでもウェブサーバー等のバックエンドとユーザー側のクライアントエンドがありますので、それぞれの役割と要件を詰めておく必要があります。また、ハードウェアが必要かどうか、どのようにハードウェアが動作するか等はこれらを進めるうえでのステップになります。

③機能要件の定義

お客様が求めているシステムには「機能要件」と「非機能要件」を含みますが、システム開発では機能要件がお客様の業務効率に直結するものとして注目されています。

機能要件を定義するためにいくつか注意点があります。

まず、現行の業務フォローを明確にしながら、システム導入後の姿を描く必要があります。現行のものを細かく分析すればするほど、問題点と新しいモデルの改善点が見えるようになるので、フロー図等を使うことが多くあります。

次に、データの構成と流れを想定しながら整理を行います。システムに対応する言語、フレームワークやデータベースの構造等を洗い出し、設計に入ります。

最後に、ユーザーと新しいシステムとの設定であるユーザーインタフェース（UI）を定義することになります。この段階では、ユーザーの利用状況を検討しつつ、画面のレイアウト、状態の遷移と使用するデバイスを定義します。

④非機能要件の定義

非機能要件とは機能以外の要件であり、例えば可用性、性能、拡張性、運用・保守性、セキュリティ等の要件は非機能要件に当たります。業務効率にそんなに影響を与えていないようですが、問題が発生すると多大な損失になる可能性があります。しかし、この要件事項の重要性は、業界によって異なりますので、業界の特徴に合わせて定義することになります。

⑤業務実施の関連内容の定義

機能要件と非機能要件を固めてから、それを実現する見積、体制（メンバー構成）とスケジュールやコミュニケーション等を定義する段階に移ります。

システム要件に基づいて、実装の工数と必要なハードウェアの調達金額を算出しますが、技術の難度によって、より単価の高い人員を配置することもあります。また、コミュニケーションの体制とそこにかかる工数も見積に入れ忘れることのないように注意していきましょう。

最後に、算出した工数をお客様のご要望と合わせて考慮し、最も妥当なスケジュールを提案することになります。

⑥要件定義書の作成

要件定義に必要な内容を納めた後に、要件定義書をつくることになります。これはダイレクトにプロジェクト全体の成否に関わりますので、可能な限り正確に詳細情報を記載していきます。

参考として要件定義書の一般的な項目を以下の通り示します。

1．はじめに

1.1 目的

1.2 利用者一覧

1.3 意図的またはイレギュラーな使用

1.4 作業範囲

1.5 用語の定義

2. 全体説明

2.1 ユーザーニーズ

2.2 前提条件と依存関係

3. システムの機能と要件

3.1 機能要件

3.2 外部インタフェース要件

3.3 システムの特徴

3.4 非機能要件

4.スケジュール

5.見積

こうした要件定義書のテンプレートをご用意しております。

入手を希望される方は、ご遠慮なくお問い合わせまでご連絡ください。

お問い合わせページ

優れた要件定義書の特徴

要件定義書の重要性が高いため、作成した文書は関連者に役立つことを保証するために、再度確認しなければなりません。ここで優れた要件定義書の特徴を説明します。

・誤解を招かないこと

要件定義書の注意点としては、理解しやすい表現を使用し、誤解が生じないように、曖昧な表現はできる限り避けなければなりません。

・測定可能

完成した製品が仕様に対して妥当であることを検証できるように、要件定義書の要件は測定できるようにしましょう。

・実行可能性

技術、予算、スケジュールなどは現実的に定義すべきです。今後の技術など何かブレークスルーの期待などを含まないようにします。

・柔軟性

作業環境が変化する可能性があるため、ある程度要件の変更に対応できるように、要件定義を工夫すべきです。

・一貫性

要件定義における全てのセクションは矛盾がなくお互いに整合していることが必要です。フォーマットから用語にいたるまで一貫した方針を持って用いる必要があります。

まとめ:的確な要件定義でご要望通りのシステムを開発しましょう

以上、要件定義の概要および要件仕様書と要件定義書の違い、要件定義の進め方における6つのステップ、レビューに役立つ優れた要件定義書の特徴をまとめました。

具体的な注意点を含めて解説しましたが、それでも要件定義に関する不明点、不安がある方がいるかもしれません。

NTQでは、要件定義をはじめ、システム開発全体に関するコンサルティング・受託サービスを提供しておりますので、是非一度お気軽にお問い合わせください。

お問い合わせページ