# 機能要件と非機能要件のトレードオフ ## 定義 機能要件と非機能要件のトレードオフとは、システムが「何をするか」を規定する機能要件(feature requirements / functional requirements、ユースケース・ユーザーストーリーの形で表現され、特定のコード・テストへ明確に対応づけられる要件)と、システム全般の属性・振る舞いに関わる非機能要件(nonfunctional requirements、セキュリティ・信頼性・SLO などが典型例)との間に生じる緊張関係、およびそれをどう解消するかという設計上の課題を指す。両者は本質的に対立するとみなされがちだが、*Building Secure and Reliable Systems* 第4章は、計画次第で機能を犠牲にせず適正なコストで両立できる場合が多いと論じる。この課題が難しいのは、信頼性とセキュリティが単一のモジュールで実装できる性質ではなく、コンポーネント分解・依存関係・通信機構・テストとレビューの慣行・モニタリングといった開発・デプロイ・運用のワークフロー全体から立ち現れる**創発的性質(emergent property)**だからである。既存システムへの後付け("bolt on")は、アーキテクチャ上の基本選択に匹敵する根本的な設計変更を要し、稼働中のシステムへの急な変更はそれ自体が新たな欠陥を持ち込むリスクを伴う。この課題への向き合い方を評価する鍵として、第4章は**初期速度(initial velocity)**と**持続的速度(sustained velocity)**を区別する——非機能要件を先送りする判断は初期の開発速度を上げることがあるが、経験上その後の速度を著しく低下させる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 4 Design Tradeoffs]] ch.4 §Design Objectives and Requirements > Features Versus Emergent Properties, §Initial Velocity Versus Sustained Velocity) ## 横断的知見 - **第1章の結論は、第4章が丸ごと1章をかけて詳細に展開する主張を、たった1文で先取りしている**: 第1章の Conclusion は「セキュリティと信頼性には多くの共通点がある——どちらもすべての情報システムに内在する性質であり、速度の名のもとに初期に犠牲にしたくなるが、後から直そうとすると高くつく」("both are inherent properties of all information systems that are tempting to initially sacrifice in the name of velocity, but costly to fix after the fact")と述べ、次章以降がこの課題への対処法を扱うと予告する。第4章はこの1文を、機能要件/非機能要件の性質の違い(創発的性質という語での再定式化)、決済処理サービスの詳細な事例、Google 社内フレームワークの事例、初期速度/持続的速度という対概念、インターネット黎明期の歴史的検証という複数の角度から、章全体をかけて肉付けする。両者を突き合わせると、第1章が"inherent property"(内在する性質)と呼ぶものを、第4章は"emergent property"(創発的性質)というより精密な語に置き換えていることが分かる——後者は「システムに単に備わっている」のではなく「開発・運用ワークフロー全体の相互作用から立ち現れる」という、後付けが困難である理由まで説明する含意を持つ。この語の精緻化が意図的な用語の使い分けなのか、単なる言い換えなのかは、両章の記述だけでは確定できない。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 1 The Intersection of Security and Reliability]] ch.1 §Conclusion, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 4 Design Tradeoffs]] ch.4 §Design Objectives and Requirements > Features Versus Emergent Properties, §Initial Velocity Versus Sustained Velocity) - **同じ「初期速度対持続的速度」の論理が、第12章ではシステム設計全体ではなくコード中の個々の TODO/FIXME 注釈という最小単位に適用される**: 第4章の初期速度/持続的速度の区別は、システム全体の設計判断(セキュリティ・信頼性・保守性を後回しにするかどうか)を対象にする。これに対し第12章「Repay Technical Debt」節は、開発者が TODO や FIXME で注釈を付けて後回しにする習慣について、「短期的にはこの習慣は最重要機能の提供速度を加速させ、初期の締め切りを守ることを可能にするが、それは技術的負債を生む」("In the short term, this habit can accelerate the delivery velocity for the most critical functionality... but it also incurs technical debt")と述べる。両者は「velocity」という同じ語を使い、「今の速度を稼ぐと後で高くつく」という同じ論理構造を持つが、適用される粒度がまったく異なる——第4章は章単位・システム単位のマクロな設計判断([[技術的負債]]の枠組みで言えば「事前予防」に近い次元)を扱うのに対し、第12章は行単位のミクロなコード注釈(同じ枠組みで言えば「事後の返済」)を扱う。この粒度の違いにもかかわらず同一の論理が繰り返し現れることは、初期速度/持続的速度のトレードオフが特定の抽象度に固有の現象ではなく、ソフトウェア工学における一般的なパターンであることを示唆する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 4 Design Tradeoffs]] ch.4 §Initial Velocity Versus Sustained Velocity, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 12 Writing Code]] ch.12 §Repay Technical Debt) ## 未解決の問い - 第1章が"inherent property"、第4章が"emergent property"と呼ぶ違いは、意図的な用語の精緻化(第4章のほうがより厳密な理論的説明を与えている)なのか、単なる言い換えなのか。両章の記述だけでは確定できない。 - 第4章のマクロな設計判断レベルの初期速度/持続的速度のトレードオフと、第12章のミクロなコード注釈レベルの同じトレードオフは、同じ根本原理(創発的性質を持つ要件ほど後付けコストが非線形に増大する)から説明できるのか、それとも粒度ごとに独立したメカニズムが働いているのか。 - 決済処理サービスの事例(第4章)が示す「信頼性リスクの緩和がセキュリティリスクを生み、それがそもそもセキュリティリスクの緩和に起因する」という入れ子状のトレードオフは、他の非機能要件の組み合わせ(例:性能とセキュリティ、可用性とプライバシー)でも同型のパターンとして観察できるか。 - Agile 開発における「テストとCI基盤への先行投資」という第4章の例は、[[技術的負債]] concept が扱う John Ousterhout の「戦略的プログラミング」(開発時間の10〜20%を継続的投資に充てる)とどの程度定量的に対応するか。両者とも「早期の投資は後で回収される」と主張するが、投資の対象(テスト・CI基盤 対 モジュール設計・文書化)が異なり、直接比較できるかは未検証。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 4 Design Tradeoffs]](§Design Objectives and Requirements, §Balancing Requirements, §Managing Tensions and Aligning Goals, §Initial Velocity Versus Sustained Velocity) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 1 The Intersection of Security and Reliability]](§Conclusion) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 12 Writing Code]](§Repay Technical Debt) - 概念: [[技術的負債]](コード単位での同型のトレードオフ) / [[ソフトウェア複雑性]] / [[セキュリティ設計原則]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 4 (By Christoph Kern). - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 1, §Conclusion. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 12 (By Michał Czapiński and Julian Bangert), §Repay Technical Debt.