ソフトウェア開発の現場で、「要件（Requirements）」と「制約（Constraints）」の違いに悩んだことはないだろうか。

私は設計を考える際に、この２つの概念を混同してしまうことがあった。

適切な設計を行うために、これらの違いを明確に理解することが大事であると感じたので、これらの違いについてシステム工学の国際標準である ISO/IEC/IEEE 29148 の定義をベースに整理してみた。

定義

国際標準では、この二つは以下のように区別されている。

• 要件 (Requirements)

  • 定義: ステークホルダーがシステムに求める「機能」や「能力」の記述。
  • 本質: 「何を達成したいか (What)」 というゴールへのベクトル。
  • 特徴: 交渉可能である。例えば「検索機能が欲しい」という要件は、予算やスケジュールの都合で「次期フェーズに回す」という調整ができる。

• 制約 (Constraints)

  • 定義: 設計や実装の自由度を制限する「条件」や「要因」。
  • 本質: 「守らなければならない枠 (Limits/Bounds)」 という解決空間の切断線。
  • 特徴: 原則として交渉不可、または変更コストが極めて高いものである。「レガシーシステムと連携必須」「GDPR準拠」といった、外部から与えられる強制力である。

補足：なぜ「要件」なのか

現場の標準語彙であるため

日本の開発現場では、ステークホルダーの「生の願い」を**「要求（Needs/Requests）」、それをエンジニアリングの言葉に翻訳・確定したものを「要件（Requirements）」**と使い分ける慣習がある（例：要求定義ではなく要件定義）。設計の話をする場合、扱うのは確定した「要件」であるため、こちらが適切である。

「制約」との対比が鮮明になるため

• 要求（Request）: 「～してほしい」（願望）
• 要件（Requisite）: 「～である必要がある」（条件）
• 制約（Constraint）: 「～でなければならない」（強制）

上記のように、要求・要件・制約は強制力のグラデーションで並んでいる。設計を議論する際、「～してほしい」という曖昧な要求レベルではなく、「～である必要がある」という確定した要件として扱うことで、制約との対比が明確になり、トレードオフの判断がしやすくなる。

ISOの構造的意図

ISO 29148でも、"Stakeholder Needs"（利害関係者ニーズ＝要求）と "System Requirements"（システム要件）は明確に区別されている。本記事の文脈は「設計」であるため、ニーズの段階ではなく、要件の段階の話となる。

要件と制約の見分け方

要件と制約を見分けるための簡単なフレームワークとして、以下の4つの質問を使うことができる。

非機能要件 (NFR) は「制約」として振る舞う

少しややこしいのが、パフォーマンスやセキュリティなどの「非機能要件（Non-Functional Requirements: NFRs）」である。これらは形式上は要件だが、アーキテクトにとっては強力な 「制約」 として機能する。

例えば、「ページを1秒以内に表示する」というNFRがあるとする。

• これはユーザーにとっては「高速な体験が欲しい」という要件である。
• しかしエンジニアにとっては、「重厚なフレームワークの使用禁止」や「キャッシュ層の強制導入」を意味する、設計を狭める制約となる。

まとめ

ソフトウェア設計とは、**「制約（Constraints）の枠の中で、最大限に要件（Requirements）を満たす解を見つけるパズル」**と例えることができる。

• 要件は、創造性を発揮して解決すべき課題である。
• 制約は、創造性を発揮する際のルール（土俵）である。

ただし、制約は「絶対に動かせない壁」とは限らない。 設計を進める中で、制約が要件の実現を著しく阻害したり、コストを爆発させたりする場合は、制約そのものを「交渉して変える」こともアーキテクトの重要な仕事である。

プロジェクト開始時にこの二つを明確に区別しておくことで、「変えられないもの」と「変えるべきもの（あるいは交渉すべきもの）」を正しく見極め、チームのエネルギーを最適なトレードオフの判断に集中させることができる。

参考

• tracery.jp - 要件とは何か
• drkasbokar.com - ISO/IEC/IEEE 29148