今年の4月から参画していたプロジェクトで、要件定義について改めて考える機会がありました。これまでの進め方を振り返りながら、要件定義の基本や実務での進め方について勉強し直したので、今回はその内容を記事にまとめます。
システム開発のプロジェクトにおいて、要件定義は設計や実装の土台となる重要な工程です。しかし、顧客から「セキュリティを高くしたい」「障害に強いシステムにしたい」といった要望を受けても、具体的に何を要件定義書に記載すればよいのか、悩むエンジニアも多いのではないでしょうか。
要件定義で重要なのは、顧客の要望をそのまま記載するのではなく、その背景や目的を理解し、システムとして実現すべき内容を具体的な要件に落とし込むことです。そのためには、「要求」と「要件」の違いを理解し、顧客の要望を整理していく手順を身につける必要があります。
本記事では、要件定義の基本的な考え方から、顧客の要望を要件へ変換する5つのステップ、実務で使える要件一覧表の作り方、顧客との合意形成の進め方まで解説します。システム開発やGoogle Cloudなどのインフラ設計に携わる方が、実務で要件定義を進める際の参考になれば幸いです。
ぜひ、最後までご覧いただけると嬉しいです！
要件定義の基本
要件定義とは
プロジェクトにおいて要件定義とは、そのプロジェクトで実現すべきことを明確に定めるプロセスです。顧客が実現したいことを整理し、システムとして何を実現する必要があるのかを具体化していきます。
ここで重要なのが、「要求」と「要件」という似た言葉の違いです。
- 要求： 顧客や利用者が実現したいと望むこと
- 要件： 要求を踏まえ、システムとして実現すべき内容を具体化したもの
例えば、顧客から「スマートフォンやパソコンで快適に閲覧できるWebサイトにしたい」という要求があったとします。
この要求を具体化するには、利用者が使用する端末や画面サイズ、操作性などを確認する必要があります。そのうえで、「スマートフォンとパソコンの両方で、主要なコンテンツを適切に表示できること」といった要件を定義します。
その要件を実現するための方法として、レスポンシブデザインを採用することが考えられます。
このように、顧客が実現したいことを整理し、システムとして実現すべき内容に具体化することが、要件定義の重要な役割です。
要求と要件の違い
要求と要件の違いを、具体例で整理してみましょう。
| 項目 | 内容 |
|---|---|
| 顧客の要望 | セキュリティを高くしたい |
| 背景・目的 | 個人情報の外部流出を防ぎたい |
| 要求 | 許可されていないアクセスやデータの持ち出しを防止したい |
| 要件 | アクセス主体、アクセス元、データ転送先などの制御条件を定める |
| 設計方針 | IAM、ネットワーク制御、VPC Service Controlsなどの適用を検討する |
この例では、「セキュリティを高くしたい」という抽象的な要望を、背景・目的を確認しながら具体化しています。
要件を定義する段階では、顧客の要求を満たすために何を実現すべきかを明確にします。その後、設計段階で具体的な技術やサービスを選定します。
なお、実際の要件や設計方針は、システムの構成や取り扱うデータ、業務上の制約などによって異なります。
なぜ顧客の要望をそのまま要件にしてはいけないのか
顧客は多くの場合、技術的に正確な言葉で要望を伝えてくれるわけではありません。「セキュリティを高くしたい」「障害に強い構成にしたい」「運用を楽にしたい」といった抽象的な言葉で語られることがほとんどです。
こうした言葉をそのまま要件定義書に記載してしまうと、担当する設計者によって実装内容が変わってしまうという問題が起きます。
例えば、「セキュリティを高くする」という一文だけでは、認証を厳しくするのか、通信経路を制限するのか、監査ログを整備するのか、読み手によって解釈が分かれてしまいます。
その結果、顧客が求めていた対策が設計に反映されなかったり、想定していなかった機能を追加することになったりする可能性があります。
このような問題を防ぐためには、顧客の言葉をそのまま要件にするのではなく、背景や目的を掘り下げたうえで、実現すべき内容を具体化する必要があります。
要件定義では、次の流れを意識すると整理しやすくなります。
顧客の要望を要件に変換する5つのステップ
ここからは、顧客の要望を要件に変換する具体的な手順を解説します。
例として、顧客から「セキュリティを高くしたい」という要望があった場合を考えてみましょう。
1. 顧客の要望をそのまま記録する
最初のステップでは、顧客の発言を勝手に解釈せず、そのままの言葉で記録します。
例えば、顧客から「セキュリティを高くしたい」と言われた場合、その発言を要望として記録します。
この段階で、「VPC Service Controlsを導入する」と決めてしまうのは早計です。それは要件ではなく、すでに具体的な設計案に踏み込んでしまっています。
まずは、顧客が何を求めているのかを正確に把握することが重要です。
2. 背景・目的を掘り下げる
次に、「なぜそれが必要なのか」を質問によって明らかにします。
「セキュリティを高くしたい」という要望に対しては、例えば次のような質問が考えられます。
- 何を守りたいのでしょうか。
- 外部からの不正アクセスが心配なのでしょうか。
- データの持ち出しが心配なのでしょうか。
- 誤操作による情報漏えいを防ぎたいのでしょうか。
- 監査対応や社内規定への準拠が必要なのでしょうか。
こうした質問を通じて、顧客が抱えている課題や、要望の背景にある目的を明らかにします。
例えば、ヒアリングの結果、「個人情報を扱うため、インターネット経由でのデータ流出を防止したい」という背景が分かったとします。
ここまで整理できると、顧客が本当に解決したい課題が見えてきます。
3. 顧客が実現したいことを要求として整理する
背景・目的が明確になったら、顧客が実現したいことを要求として整理します。
先ほどの例では、次のようにまとめられます。
＜要求＞
Google Cloud上の個人情報を含むデータについて、許可されていないアクセスや外部への持ち出しを防止したい。
この段階では、まだ具体的な製品名やサービス名を決める必要はありません。重要なのは、顧客の要望を技術的な解決策に置き換えることではなく、顧客が実現したいことを明確にすることです。要求が整理できれば、その実現に必要な要件を検討しやすくなります。
4. 検証可能な要件に変換する
ここが、要件定義において最も重要な工程です。
要件は、実現できたかどうかを判断できる状態まで具体化する必要があります。先ほど整理した要求を、具体的な要件に分解してみましょう。
＜要求＞
Google Cloud上の個人情報を含むデータについて、許可されていないアクセスや外部への持ち出しを防止したい。
この要求を満たすために、例えば次のような要件を検討できます。
| 要件ID | 要件 |
|---|---|
| SEC-001 | 個人情報を格納するサービスへのアクセスを、承認された利用者および許可されたアクセス経路に限定する |
| SEC-002 | 対象サービスへのインターネット経由のアクセス可否を定め、必要な制御を実施する |
| SEC-003 | 対象データの外部転送について、許可する転送先や転送条件を定め、制御する |
| SEC-004 | 対象データへのアクセスログを記録し、必要な期間保管する |
このように、1つの要求から複数の要件が生まれることもあります。
なお、表の内容は要件の具体化方法を示す例です。実際のプロジェクトでは、対象サービスや利用形態、業務上の制約などを確認し、要件を確定する必要があります。
また、「必要な期間保管する」といった記載だけでは、実際の設計やテストで判断できない場合があります。監査要件などを確認したうえで、具体的な保管期間や制御条件を定めることが重要です。
要件を定義する際は、誰が読んでも同じ解釈になり、実現できたかどうかを確認できる内容になっているかを意識しましょう。
5. 要件と設計を混同しない
技術者が陥りやすい失敗の1つが、要件の欄に「Cloud Armorを導入する」のような具体的な製品名を書いてしまうことです。
Cloud Armorを導入すること自体は、通常、要件を実現するための設計方針に該当します。
例えば、次のように整理します。
| 項目 | 記載内容 |
|---|---|
| 顧客の要望 | Webサービスのセキュリティを高くしたい |
| 背景・目的 | 不正アクセスや大量アクセスによる被害を防ぎたい |
| 要求 | 公開Webサービスへの不正アクセスや過剰なアクセスを抑制したい |
| 要件 | 必要なアクセス制御やリクエスト制限を定め、実施する |
| 設計方針 | Google Cloud Armorを使用してWAFやレート制限を実装する |
このように分けることで、「何を実現する必要があるのか」と「どの技術を使って実現するのか」を区別できます。
ただし、既存システムとの連携や指定製品の利用など、顧客側で技術的な制約が決まっている場合もあります。その場合は、制約条件や前提条件として記録したうえで、要件と設計方針を整理するとよいでしょう。
実務で使える要件一覧表の作り方
ここまでの手順で整理した要求や要件は、要件一覧表として管理することをおすすめします。
要件定義書に文章として記載するだけでなく、一覧表を作成しておくと、顧客の要望と要件、設計方針のつながりを追跡しやすくなります。
要件一覧表に記載する項目
例えば、次のような要件一覧表を作成します。
| 要件ID | 顧客要望 | 背景 | 要求 | 要件 | 優先度 | 設計方針 | ステータス |
|---|---|---|---|---|---|---|---|
| SEC-001 | セキュリティを高くしたい | 個人情報を保護したい | 不正アクセスを防止したい | アクセス主体やアクセス経路を制御する | 必須 | IAM・ネットワーク制御など | 確認中 |
| AVA-001 | 障害に強くしたい | 業務停止を防止したい | 単一障害による業務停止を防ぎたい | 要求された障害条件下で業務を継続できること | 必須 | マルチゾーン構成など | 確認中 |
この表のメリットは、「この設計は、どの顧客要望から生まれたのか」を後から誰でも追跡できることです。
また、要件IDを付与しておくと、設計書やテスト仕様書にも同じIDを記載できるため、要件と設計、テストの対応関係を管理しやすくなります。
例えば、SEC-001という要件に対して、基本設計書ではアクセス制御の方式を記載し、テスト仕様書では許可された利用者と許可されていない利用者のアクセス結果を確認する、といった管理ができます。
なお、ステータスは「確認中」「合意済み」「設計中」「テスト済み」など、プロジェクトの進め方に合わせて定義するとよいでしょう。
顧客の要望と設計方針の対応関係を管理する
要件一覧表を作成する際には、顧客の要望から設計方針までの対応関係を意識することが重要です。
例えば、設計レビューで「なぜこのネットワーク制御が必要なのか」と質問された場合、要件一覧表を確認すれば、顧客の要望や背景にさかのぼって説明できます。
反対に、顧客から新たな要望が出た場合も、既存の要件や設計への影響を確認しやすくなります。
このように、要件一覧表は単なる要件のリストではなく、プロジェクト全体の認識をそろえ、変更の影響を管理するための資料として活用できます。
ヒアリングから要件合意までの進め方
要件定義は、要件定義書を作成して終わりではありません。顧客から必要な情報を聞き出し、要求や要件を整理したうえで、顧客と合意する必要があります。
特に、Google Cloudなどの基盤設計案件では、顧客が技術的な知識を十分に持っていない場合もあります。そのため、技術的な質問だけでなく、業務上の課題や実現したいことを聞き出すことが重要です。
実務では、次の3つのフェーズに分けて進めると整理しやすくなります。
1. ヒアリングシートを作成する
最初に、顧客から必要な情報を聞き出すためのヒアリングシートを作成します。
Google Cloudの基盤設計であれば、例えば次のような観点で質問項目を整理できます。
IAM・認証
- システムを利用するのは誰か
- 社外からのアクセスは必要か
- 管理者権限を持つ利用者は誰か
- Googleアカウントや外部IdPを利用するか
ネットワーク
- オンプレミス環境との接続は必要か
- インターネットへの公開は必要か
- 接続する拠点や外部システムはどこか
- 通信を許可する接続先に制限はあるか
セキュリティ
- どのようなデータを扱うか
- 個人情報や機密情報は含まれるか
- 社内規定や監査上の要件はあるか
- 監査ログの記録や保管は必要か
- データの持ち出しを制限する必要はあるか
この段階では、顧客の回答が曖昧でも問題ありません。回答をもとに追加の質問を考え、必要な情報を段階的に集めていきます。
また、顧客が判断できない項目については、無理に回答を求めるのではなく、選択肢や具体例を提示して検討を支援することも有効です。
2. ヒアリング結果を要求・要件に整理する
ヒアリングで得られた情報を、次の流れで整理します。
例えば、顧客から「障害に強い構成にしてください」と言われた場合、そのまま要件定義書に記載するのではなく、どのような障害に対応する必要があるのかを確認します。
単一のゾーン障害に対応できればよいのか、リージョン障害でも業務を継続する必要があるのかによって、必要な構成は異なります。
さらに、停止可能時間や許容できるデータ損失量を確認することで、RTO（目標復旧時間）やRPO（目標復旧時点）などの指標に落とし込めます。
このように、ヒアリング結果を整理して要求や要件に変換することで、顧客の期待とシステムの実現内容を結びつけられます。
3. 要件確認会で顧客と合意する
要求や要件を整理したら、顧客との確認会を実施します。
ここで重要なのは、「この設計でよいですか」と確認する前に、「この要件認識で合っていますか」と確認することです。
要件の認識が一致していない状態で設計を進めると、後から顧客の期待と異なることが判明し、大きな手戻りにつながる可能性があります。
そのため、まずは要件定義書や要件一覧表を用いて、実現すべき内容について顧客と合意します。
また、未決事項や前提条件、顧客側で判断が必要な項目も明確にしておきましょう。
合意した内容は記録として残し、後から認識の違いが発生した場合にも確認できるようにしておくことが重要です。
「質問→仮説→確認」のサイクルを回す
実務では、顧客からすべての要件を一度に聞き出すことはできません。そのため、次のサイクルを繰り返しながら、要件の精度を高めていきます。
例えば、顧客が「障害に強い構成にしてください」と言った場合、次のような質問を検討します。
- ゾーン障害が発生しても業務を継続する必要がありますか。
- リージョン障害でも業務継続が必要ですか。
- システムの停止は最大で何時間まで許容できますか。
- 障害発生時に、どの時点のデータまで復旧できればよいですか。
これらの質問によって、可用性やDR（災害復旧）に関する具体的な要件を整理できます。
また、顧客が技術に詳しくない場合は、技術用語を使って質問するのではなく、業務上の困りごとを起点に質問することが効果的です。
例えば、「VPC Service Controlsは必要ですか」と聞くよりも、「Google Cloud上のデータを、許可されていない外部サービスへコピーできないようにする必要はありますか」と聞く方が、顧客は判断しやすくなります。
顧客に技術的な解決策を選んでもらうのではなく、実現したいことや許容できる条件を確認し、その実現方法をエンジニアが検討することが重要です。
要件と設計を整理するWhy・What・Howの考え方
ここまで説明した内容は、Why・What・Howの3層構造で整理することもできます。
- Why（なぜ必要か）： 背景・目的、顧客の課題
- What（何を実現するか）： 要求、要件
- How（どう実現するか）： 設計方針、具体的な技術や設定
例えば、個人情報の外部流出を防止したい場合、次のように整理できます。
| 分類 | 内容 |
|---|---|
| Why | 個人情報の外部流出を防止したい |
| What | 許可されていないアクセスやデータ転送を制御する |
| How | IAM、ネットワーク制御、VPC Service Controlsなどの適用を検討する |
この3層を混同しないことが、要件定義の質を高めるうえで重要です。
ただし、実際のプロジェクトでは、すべての要望がそのままシステム要件になるわけではありません。業務運用で対応するものや、プロジェクトの対象範囲外となるものもあります。そのため、要望の背景を確認したうえで、対象範囲や制約条件も含めて整理する必要があります。
プロジェクトマネジメントにおける要件定義の重要性
プロジェクト全体の中で見ると、要件定義は、ビジネス上の要求やシステム要件について顧客と合意を形成し、その後の設計・実装・テストなどの工程につなげる重要なフェーズです。
ここで定めた要件は、後工程におけるタスクの洗い出し、進捗管理、設計レビュー、テスト計画、リリース計画などの土台になります。
例えば、要件定義の段階で「単一ゾーンの障害が発生しても業務を継続できること」と定めていれば、その要件を満たす構成を設計し、テストで実現できていることを確認する必要があります。
一方、要件が「障害に強い構成にする」という曖昧な表現のままだと、設計者と顧客の間で期待する内容が異なり、設計のやり直しや追加作業が発生する可能性があります。
また、プロジェクトの進行中には、当初想定していなかった追加要件が発生することもあります。その場合は、既存の要件や設計への影響、スケジュール、コストなどを確認したうえで、変更内容を管理することが重要です。
このように、要件定義は単に文書を作成する作業ではありません。プロジェクトの関係者間で実現すべき内容を共有し、後工程を円滑に進めるための基盤となる活動です。
まとめ
今回は、下記３点について説明しました。
- MISP連携とIOCマッピング
- Sensitive Data Protection連携
- YARA-L 2.0パフォーマンスチューニング
要件定義とは、顧客の漠然とした要望を整理し、システムとして実現すべき内容を具体化するプロセスです。重要なのは、顧客の発言をそのまま要件として扱うのではなく、背景や目的を掘り下げたうえで、実現できたかどうかを判断できる要件に落とし込むことです。
実務では、次の流れを意識すると、要件定義を進めやすくなります。
- 要望を記録する： 顧客の発言を勝手に解釈せず、そのまま記録する。
- 背景・目的を確認する： なぜその要望が必要なのかを掘り下げる。
- 要求を整理する： 顧客が実現したいことを明確にする。
- 要件に具体化する： 実現すべき内容を、検証可能なレベルまで落とし込む。
- 設計と分けて管理する： 要件と、それを実現するための技術やサービスを混同しない。
また、要件一覧表を作成して顧客の要望と要件、設計方針のつながりを管理することで、後工程での認識のずれや手戻りを防ぎやすくなります。
特に、顧客が技術に詳しくない場合は、最初から技術的な解決策を尋ねるのではなく、業務上の課題や実現したいことを聞き出す姿勢が大切です。「質問→仮説→確認」のサイクルを繰り返し、要件の認識を顧客とすり合わせていきましょう。
要件定義書は、最初から完成形を目指す必要はありません。ヒアリングで得た情報を整理し、要件を具体化して顧客と合意しながら、段階的に完成度を高めていくことが重要です。
要件定義の質を高めることは、設計や実装の品質向上だけでなく、プロジェクト全体の円滑な進行にもつながります。まずは、顧客の要望を「なぜ必要なのか」という視点で掘り下げ、要求と要件を分けて整理することから始めてみましょう。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログ！
