5.2要件定義と非機能要件

要件定義では、「業務として何を達成したいか」「そのためにシステムが何をするか」「どの程度の品質・制約で実現するか」を、利害関係者と合意しながら明確にします。これらはそれぞれ業務要件・機能要件・非機能要件として区別され、混同すると後工程で「何のための機能か」「どこまでの品質が必要か」が曖昧になります。とりわけ非機能要件は、可用性を上げればコストが増えるといったトレードオフを含むため、IPA の非機能要求グレードのような枠組みで水準を段階的に示し、利用者と合意することが重要です。この節では、ストラテジストが要件の種類を切り分け、非機能のトレードオフを判断し、利害関係者要件をトレーサビリティを保って束ねる視点を学びます。

5.2.1業務要件・機能要件・非機能要件の区別

• 業務要件＝システム化の目的として業務上達成すべきこと（例「受注から出荷までのリードタイムを短縮する」）。機能要件＝それを実現するためにシステムが備える機能（例「受注データを登録・照会・更新できる」）。非機能要件＝性能・可用性・セキュリティ・拡張性・運用性など、機能をどの品質・制約で満たすか（例「オンライン応答時間3秒以内」「稼働率99.9%」）。
• 三者を切り分ける意義は、後工程での追跡と合意にある。業務要件が機能要件・非機能要件の根拠となり、機能だけを列挙すると「なぜその機能が要るか」「どの品質で満たすか」が抜け落ちる。非機能要件を機能要件に含めてしまうと、品質水準の合意やコストの見積りが曖昧になる。

5.2.2非機能要求グレードとトレードオフの合意

• 非機能要求グレード（IPA）＝可用性／性能・拡張性／運用・保守性／移行性／セキュリティ／システム環境・エコロジーの6大項目で非機能要件を段階的（グレード）に評価・提示する枠組み。抽象的になりがちな非機能要件を具体的な水準で示し、利用者とベンダーの認識の齟齬を防ぐ。
• 非機能要件はトレードオフを伴う。可用性の目標稼働率を上げるほど冗長化などのコストが増えるため、業務が本当に必要とする水準とそれを実現するコストを天秤にかけ、過剰でも過少でもない水準を利用者と合意する。「高いほど良い」と最高水準を一律採用するのは過剰投資、逆に軽視すれば運用段階で品質不足が露呈する。

あるECサービスのITストラテジストが、基幹となる受注システムの刷新にあたり非機能要件を利用者部門と詰めています。事業部門からは「機会損失は絶対に避けたいので、24時間365日一切停止しない無停止のシステムにしてほしい」という強い要望が上がりました。ここでストラテジストは、要望をそのまま最高水準の非機能要件として確定するのではなく、非機能要求グレードの可用性項目を用いて、目標稼働率や許容される計画停止・障害復旧時間を段階的に提示し、それぞれの水準を実現するのに必要なコスト（サーバの多重冗長化、待機系の常時稼働、拠点分散など）を並べて示します。無停止（例：稼働率99.999%）を実現するには構成が大幅に複雑化しコストが跳ね上がる一方、実際の業務では深夜帯の受注はごくわずかで、短時間の計画停止であれば機会損失はほとんど生じないことが分かりました。ここで重要なのは、「可用性は高いほど良い」と最高水準を一律に採用するのは過剰投資であり、逆に軽視して低い水準にすれば繁忙時間帯の停止で機会損失が出るという、両側のリスクを踏まえて水準を選ぶことです。ストラテジストは、業務が本当に必要とする水準——たとえば「日中の主要時間帯は実質無停止に近い高可用とし、深夜の短時間の計画メンテナンスは許容する（目標稼働率99.9%）」——を非機能要求グレードの具体的な段階として利用者と合意し、その水準に見合った冗長構成を選びます。あわせて、この可用性要件がどの業務要件（機会損失の回避）に由来し、どの機能・構成で実現されるかのトレーサビリティを確保しておくことで、後工程で「なぜこの構成か」を追跡でき、要件の変更や監査にも耐えられます。このように、非機能要件は「高いほど良い」で決めるのではなく、非機能要求グレードで水準を可視化し、必要性とコストのトレードオフを利用者と合意して過不足なく定めることが、ストラテジストの判断の核心です。

5.2.3この節のまとめ

• 業務要件（業務上の目的）／機能要件（システムの機能）／非機能要件（品質・制約）を切り分け、根拠と追跡を明確にする
• 非機能要求グレードの6項目（可用性／性能・拡張性／運用・保守性／移行性／セキュリティ／システム環境・エコロジー）で水準を段階的に可視化する
• 非機能要件は水準とコストのトレードオフを利用者と合意し、利害関係者要件をトレーサビリティを保って束ねる