要件定義書に書くこと｜ビジネス要件とシステム要件（機能要件・非機能要件）の違いと、要件定義の4ステップARTICLE

要求仕様書ができたら、いよいよ要件定義です。要件定義は、第1回で整理した工程の中で、発注側と開発側のどちらか一方に任せられない唯一の工程です。発注側が「何を求めているか」を持ち込み、開発側が「システムとして何を満たせばよいか」に翻訳し、すり合わせながら決めていきます。

本記事はシリーズ「発注側のための要件定義」の第4回として、要件定義書に何を書くのか、そのために何をするのかを、発注側の視点で解説します。要件定義の進め方そのものは全体像の記事で扱っているので、この回では「文書に何が入っていれば要件定義と言えるのか」に焦点を当てます。

要件定義とは ――「何を作るか」を決めること

要件定義は、システムやソフトウェアの開発・導入にあたって、どのような機能や性能が必要かを明確にする作業です。システムが満たすべき条件を定義し、その基準を明確にすることで、開発の進め方と、導入後に「できた」と判断する基準を確立します。

要は、何を作るかを決めるということです。

システム開発の中で「何を作るか」を決めることは、最も重要な工程です。ウォーターフォール型でもアジャイル型でも、要件定義はシステム開発の出発点であり、ここがうやむやなまま進むと、後の工程がすべてぐだぐだになります。

システム開発は、要件定義→設計→開発→テスト→リリース→運用・保守と進み、運用の中で見えてきた課題が次の要件定義につながる、というサイクルで回り続けます。要件定義はこのサイクルの出発点です。ここで決めたことは設計・開発・テストにそのまま引き継がれるので、最初のずれは後の工程で直すほど高くつきます。

企画で「なぜやるのか」を決め、要求定義で「何を求めているのか」を言葉にし、要件定義で「システムが何を満たせばよいか」を決める。同じ「やりたいこと」が、工程を経るごとに具体的になっていきます。

要件定義の目的を整理すると、次の4つになります。

• プロジェクトの土台を築く：ここで要件を正確に定義することで、方向性が定まり、後の開発作業がスムーズに進みます
• 範囲と目標を決める：プロジェクトで達成すべき目標と、必要な機能・非機能要件が明確になります
• 関係者の期待を一致させる：関係者の期待を集めて分析し、全員が同じ目標に向かえるようにします
• 後の工程での誤解を防ぐ：要件が明確なほど、開発の各段階での誤解が減り、変更要求の数が減って、遅延とコスト増加を防げます

要件定義書は二層でできている

要件定義書に何を書くかを考えるとき、ビジネス要件とシステム要件の二層で捉えると整理しやすくなります。

ビジネス要件 ―― 発注側が主に決める

企画の要望と要求仕様書の内容を土台に、業務の現状（As-Is）と、あるべき姿（To-Be）を書きます。「今はこう回っていて、ここに問題がある。システムが入ったあとはこう回る」という、業務の変化を描く層です。

ここは発注側にしか書けません。開発側は業務の現状を知りませんし、あるべき姿を決める権限もありません。要求仕様書がしっかりしていれば、この層の多くは要求仕様書から引き継げます。

システム要件 ―― 開発側が主に決める

ビジネス要件を受けて、システムとして何を満たすかを書きます。

• 機能要件：システムが提供する具体的な機能そのものです。確実に実装する必要があります
• 非機能要件：機能以外で求められる要件です。性能やセキュリティなど、後述します
• 外部連携：既存のシステムや外部サービスと、何をどう受け渡すか
• データ構造：どんなデータを、どんな形で持つか
• 運用設計：稼働後に、誰が、何を、どう運用するか

この層は開発側が主に書きますが、発注側は「それで業務が回るか」を確認する役割を持ちます。特に運用設計は、発注側の業務に直結するので、開発側に任せきりにせず、内容を理解しておく必要があります。

二層は、要件定義書という一つの文書で結ばれます。ビジネス要件のどの項目が、システム要件のどの項目で実現されるのかが追えるようになっていれば、要件定義書として機能します。

要件定義の4ステップ

要件定義は、次の4ステップで進みます。要求定義の4ステップと似ていますが、扱うものが「要求」から「要件」に変わり、開発側の関わりが深くなります。

1. 要件の収集：要求仕様書をもとに、発注側の期待と「最終的に得たい結果」を開発側が確認します。発注側は、要求の背景にある目的を伝えます。
2. 要件の分析：要求同士の整合性を確認し、技術的に実現できるか、費用と期間はどのくらいか、どこまでを範囲にするかを検討します。
3. 仕様の検討：優先順位をつけ、競合する要求の矛盾を解決し、機能要件と非機能要件に分類します。
4. 仕様化：要件定義書を作成し、関係者の合意を取ります。あわせて、要件が変わったときの変更管理の方法を取り決めます。

このステップを通じて大切なのは、発注側と開発側が多くのコミュニケーションを取り、協力しながら進めることです。「最終的に何が得たいのか」を常に意識して、お互いの理解を深めていくことが成功の要です。

発注側の立場で言えば、開発側から「この要件はどちらにしますか」「この機能はなくても目的は達成できますか」と聞かれたときに、目的に照らして即答できる状態を作っておくことが、この工程での役割です。

抜けやすい非機能要件

システム要件の中で、発注側が最も見落としやすく、しかも後から直しにくいのが非機能要件です。

機能要件が「何ができるか」だとすれば、非機能要件は「どのくらいちゃんと動くか」です。主な観点は次のとおりです。

• 性能：画面の応答速度、同時に使う人数、処理できるデータ量
• 可用性：止まってよい時間、障害からの復旧の速さ
• セキュリティ：認証の方法、誰が何を見られるかの権限、操作の記録
• 運用・保守：監視、バックアップ、更新の手順と頻度
• 使いやすさ：操作性、アクセシビリティ、教育なしで使えるか
• 拡張性：利用者が増えたとき、機能を足すときに耐えられるか

非機能要件は、案外エンジニアも意識が抜けがちです。機能の話は具体的で盛り上がるのに対し、「何秒以内」「何人まで」といった話は地味だからです。しかし、リリース後に「遅い」「落ちる」「セキュリティ監査で指摘された」となったとき、直すのは機能の追加より大変です。

発注側が意識すべきことは、非機能要件を数字で書くことです。「速く」ではなく「一覧画面は3秒以内に表示」、「止まらない」ではなく「計画停止は月に計2時間まで」のように書きます。数字が分からなければ、「今の業務ではどのくらいで困るか」から逆算し、開発側と相談して決めます。

効果的な要件定義のための3つの戦略

要件定義の質を高めるために、K.S.Rogers が重視している戦略を3つ挙げます。

1. コミュニケーション ―― 誤解を早く見つける

関係者との定期的なコミュニケーションは、誤解を避け、要件を正確に理解し合うために欠かせません。定期的なミーティングと進捗の報告、フィードバックの場を設け、開かれた連絡経路を確保します。要件定義の誤解は、見つかるのが遅いほど高くつきます。

2. 明確性と一貫性 ―― 全員が同じ理解を持つ

要件を明確かつ一貫した形で文書化することで、全員が同じ理解を共有し、将来の混乱を防ぎます。文書化する際は、明瞭で理解しやすい言葉を使い、必要に応じて図表やモデルで説明します。発注側が読んで分からない要件定義書は、発注側が確認できないという意味で、要件定義書として不十分です。

3. 柔軟性 ―― 変化に振り回されない

プロジェクトは動く環境の中で進むので、新しい情報や変更要求に対応できる力が求められます。ただし、柔軟に対応することと、なし崩しに変わることは違います。変更管理の仕組みを確立し、新たな要求や情報が出たときには迅速に評価して、適切に要件に反映させる、という手続きを最初に決めておきます。

変更管理の基本は、変更が出たら「影響（費用・期間・他の要件）を評価する → 採否を決める → 記録して関係者に通知する」の3つです。誰が採否を決めるのかは、第1回で決めたプロジェクトオーナーとPMの役割に従います。

要件定義の後、開発はどう進むか

発注側と開発側が力を合わせて要件定義をした後は、開発側が要件に基づいて設計と実装を行い、それぞれのテストを実施します。実装が終わるとシステムテストが始まり、それが進むと受入テストが始まります。

要件定義書は、この後の工程すべての基準になります。設計は要件定義書に基づいて行われ、テストは「要件定義書に書かれた条件を満たしているか」で合否が決まります。だからこそ、要件定義書に書かれていないことは、作られませんし、テストもされません。発注側が「当然入っていると思っていた」ことは、書かれていなければ入りません。

受入テストは、発注側が再び主役になる工程です。要件定義書に書いた条件が、業務で使える形で満たされているかを、発注側が確認します。

要件定義でよくあるつまずき

1. 要件定義書が開発側の言葉だけで書かれている

システム要件が専門用語で書かれ、発注側が内容を確認できないケースです。確認できないものに合意しても、あとで「そういう意味だとは思わなかった」が起きます。発注側が読んで分かる言葉と図で書いてもらうか、開発側に説明を求めて理解してから合意します。

2. 非機能要件が「一般的な水準で」になっている

「性能は一般的な水準で」「セキュリティは適切に」のように、数字のない非機能要件です。何をもって満たしたと言えるのかが決まっていないので、テストのしようがなく、リリース後に揉めます。前述のとおり、数字で書きます。

3. 変更が口頭で積み重なる

打ち合わせのたびに「ついでにこれも」と要件が増え、記録も影響の評価もないまま進むケースです。開発側は善意で受けますが、費用と期間が膨らみ、最後に「聞いていない」と衝突します。変更は手続きを通す、と最初に決めておきます。

支援の現場で見た、要件定義書があることの意味

オンライン診療プロダクトの開発体制を立て直した事例では、要件定義書がなく、プロダクトを実際に触らないと要件が分からない状態から支援を始めました。要件が文書になっていないと、開発側は判断の基準を持てず、発注側は確認のしようがありません。

要件定義書は、作ること自体が目的ではなく、発注側と開発側が同じものを見て判断するための共通の基準です。それがあるかないかで、その後の開発の進み方は大きく変わります。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版」：要件定義で起きやすい問題と解決策が、発注側の視点で整理されています。非機能要件の考え方についても触れられています
• IPA「非機能要求グレード」：可用性・性能・セキュリティなど非機能要件の項目と水準を、体系的に整理した資料です。「何を、どのくらいで決めればよいか」の網羅性を確認するのに使えます
• IPA「情報システム・モデル取引・契約書（第二版）」：要件定義の成果物と、その後の工程の契約上の位置づけを確認できます

要件定義書の作成からご一緒します ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。開発側との間に入り、発注側の言葉と開発側の言葉を翻訳しながら、要件定義書にまとめます。

まとめ

• 要件定義は「何を作るかを決める」工程で、発注側と開発側の両方が関わります。ここが曖昧だと、後の工程がすべて曖昧になります
• 要件定義書は、発注側が主に決めるビジネス要件（要望・要求仕様・現状・あるべき姿）と、開発側が主に決めるシステム要件（機能・非機能・外部連携・データ・運用）の二層で捉えます
• 進め方は要件の収集 → 分析 → 仕様の検討 → 仕様化の4ステップです。「最終的に何が得たいのか」を常に意識します
• 非機能要件は抜けやすく、あとから直しにくいので、数字で書きます。変更は手続きを通す、と最初に決めておきます

次回は、要件定義書を基準に発注側が主役として行う受入テストの進め方を扱います。シリーズの全体像は要件定義の進め方を、要件定義書について相談したい方はお問い合わせからお気軽にご連絡ください。