1.2要件定義プロセス

要件定義は「ステークホルダに聞いたことをそのまま書き出す」作業ではありません。ステークホルダ間で要求が対立していたり、要求そのものが曖昧なまま合意されてしまったりすると、後工程（設計・開発・テスト）で手戻りが発生し、コストと納期に大きな影響を及ぼします。システムアーキテクトには、要求の矛盾や曖昧さの兆候を早期に見抜き、合意形成のプロセスをどう設計するかを判断する力が求められます。

1.2.1要求獲得と要求分析

• 要求獲得＝インタビュー・ワークショップ・現場観察・既存文書調査などの手法で、ステークホルダが持つ要求（明示的な要求だけでなく、業務の中に暗黙に存在する要求も含む）を引き出す活動。ステークホルダごとに立場や関心が異なるため、同じ機能に対しても相反する要求が出てくることが前提となる。
• 要求分析＝獲得した要求を整理・構造化し、重複や矛盾を洗い出し、優先順位を付ける活動。矛盾する要求が見つかった場合、その場で多数決や声の大きさで決めるのではなく、経営戦略や業務目標に照らしてどちらが本質的に必要かを判断し、必要なら関係者間の合意形成の場を設けるのがシステムアーキテクトの役割。

1.2.2機能要件・非機能要件とトレーサビリティ・変更管理

• 機能要件＝システムが「何をするか」を定めた要件（業務機能・画面・帳票など）。非機能要件＝性能・信頼性・可用性・セキュリティ・保守性など「どの品質水準で実現するか」を定めた要件。非機能要件は利用者から自発的に語られにくく、曖昧なまま合意されがちなため、システムアーキテクトが主体的に引き出し明文化する必要がある。
• 要求トレーサビリティ＝個々の要求が、どの設計・実装・テストケースに対応しているかを追跡できるようにする仕組み。要求の変更が生じたときに影響範囲を漏れなく特定するために不可欠。変更管理＝開発途中で生じる要求変更を、無秩序に取り込むのではなく、影響範囲・コスト・納期への影響を評価した上で承認/却下を判断するプロセス。

あなたはある会員制サービスの刷新プロジェクトのシステムアーキテクトで、要件定義の中盤に差し掛かったところ、営業部門は「検索機能を今すぐ使えるようにしてほしい、応答時間の要件は特に無い」と述べ、一方で運用部門は「ピーク時でも3秒以内に応答してほしい」と要望していることに気づいたとします。この場面で「営業部門は非機能要件を口にしなかったから、応答時間の要件は無いものとして進める」と判断するのは危険です。非機能要件は利用者から自発的に語られにくい傾向があるため、営業部門が「要件は無い」と言った背景には、単に性能面を意識していなかっただけという可能性が高いからです。適切な進め方は、営業部門に対しても要求獲得の一環として「ピーク時にどの程度の検索件数・利用者数を想定しているか」「応答が遅い場合に業務にどう影響するか」を具体的に問いかけ、暗黙の期待値を明文化することです。その上で運用部門の「3秒以内」という要求と突き合わせ、要求分析として矛盾がないかを確認し、もし営業部門の想定するピーク負荷では3秒以内の達成にコストが見合わない場合は、経営目標（会員満足度・離脱率）に照らして応答時間の目標値を関係者間で合意形成する必要があります。合意した非機能要件は、後工程で要求トレーサビリティにより性能テストのテストケースと対応付け、要件が満たされているかを検証可能にしておきます。「要求が語られなかったから無いものとして扱う」のではなく、語られなかった要求（特に非機能要件）を能動的に引き出し、対立する要求は業務目標に照らして合意形成することが、要件定義プロセスの核心です。

1.2.3この節のまとめ

• 要求獲得では矛盾する要求が出ることを前提とし、要求分析で業務目標に照らして優先順位を判断する
• 非機能要件は自発的に語られにくいため能動的に引き出し、測定可能な水準として合意する
• 要求トレーサビリティと変更管理で、変更時の影響範囲を漏れなく特定し無秩序な取り込みを防ぐ