1. はじめに：ある思考実験――Observability時代の「リリース判定」とは？

「もし、システムのエラーがリアルタイムに検知され、コードが即座に修正・自動回復できるとしたら、結合テストの『バグ検出数』でリリース判定を行う仕組みは、そもそも成立するのだろうか？」

私がこの根源的な問い（思考実験）に行き着いたのは、インフラ運用監視とオブザーバビリティの最前線で、システムの異常と常に向き合ってきたからです。
先日、私は独立研究者として『Observability-Native型開発モデル of 提唱：システム品質の再定義と社会技術システムにおける最終平衡状態』（ SSRNリンク）という論文を公開しました。

ツールやアーキテクチャがクラウドネイティブへと進化し続ける一方で、私たちの「品質管理」や「契約」の考え方は、いまだにシステムを無菌室で作ろうとしていた時代のまま止まっています。本稿では、現代の必須要素であるObservability（可観測性）を前提としたとき、ソフトウェアの品質管理がどのように再定義されるべきか、そしてそれが私たちエンジニアのビジネスモデルをどのように変革するのかについて、論文のエッセンスを解説します。

2. 熱力学が暴く「バグ収束曲線」のフィクション

従来のソフトウェア管理工学では、テスト工程で累積バグ発見数をプロットする「バグ収束曲線」が品質の絶対的な指標とされてきました。しかし、熱力学の観点から見ると、この数理モデルはシステムが外部環境からの摂動を一切受けない 閉鎖系 であることを前提としています。

閉鎖系であれば、時間の経過とともに新規バグ発見レートは極限においてゼロに漸近します。

$$\lim_{t\rightarrow t_{accept}}\frac{dN(t)}{dt}=\epsilon\approx0$$

しかし、現代のクラウドネイティブ環境は、サードパーティAPIの遅延やユーザートラフィックの変動という「熱流入（エントロピー生成）」が常時存在する 開放系 の生態系です。システム全体のエントロピー変化は次式で表されます。

$$\frac{dS}{dt}=\frac{dS_{int}}{dt}+\frac{dS_{ext}}{dt}>0$$

外部からの摂動（ $dS_{ext}/dt>0$ ）がテストによるバグ枯渇の速度を上回る高周波領域において、「バグを事前にゼロにする（静的無謬性）」という目標は成立困難なモデルとなります。これからの品質は、バグの不在ではなく、未知の障害に晒されても自律的に生き残る 動的恒常性 （ホメオスタシス）の維持能力へと再定義されなければなりません。

3. 新たな品質基準の提示：Observability-Native Development (OND)

この動的恒常性をシステムに実装するため、私は次世代パラダイムとして Observability-Native Development （OND：可観測性ネイティブ開発モデル）を提唱しました。

従来のウォーターフォール開発では、下流のテスト工程で初めてマクロな検査が行われていました。一方ONDでは、コーディングの最上流段階からAPMプラットフォームなどの可観測性をシステム内部に初期計装します。これは生物に例えるなら、自然免疫であるマクロファージが細胞レベルで抗原を即座に貪食・排除するような、システムの 自律神経系 を設計段階から組み込むプロセスです。

具体的には、特定のベンダー製品に依存しない、以下のようなオープンスタンダードな実装を指します。

設計・実装フェーズ: 開発の初期段階で、CNCF（Cloud Native Computing Foundation）が管理するオープンな業界標準であるOpenTelemetryなどに準拠した計装を行い、マイクロサービス間でトレースIDの伝播設計を行います。コーディング段階では適切なスパンの境界を定義し、システム内部の状態を常時出力可能な状態にします。
運用・評価フェーズ: 例えば、月間稼働率99.9%のSLO（サービスレベル目標）を設定した場合、許容されるダウンタイム（エラーバジェット）は約43分となります。CI/CDパイプラインにSLOダッシュボードへの自動反映を組み込み、「Burn Rate（予算消費速度）が1時間で10倍を超えた時点でアラートを発火させる」といった自動制御を実装します。

ONDにおいて、従来の「検収」という離散的なチェックポイントは消失します。代わりに、エラーバジェット消費速度の評価関数 $G(t)$ を用い、「システムが健康状態を保っているか」を連続的に証明し続けること自体がリリース基準となります。

4. 社会技術システムの衝突：ONDが「一括請負」を破壊する

思考実験を現実のビジネス環境に適用したとき、最大の障壁となるのが「一括請負契約」や「受託開発」、「RFPによる仕様凍結」という社会的な上部構造です。

環境に適応し続ける動的なシステムに対し、RFPによるガチガチの仕様を当てはめようとすると何が起きるでしょうか。この矛盾は、「DevOps」のようにベンダーと顧客で歩み寄り文化を変えよう、といった精神論では決して解決できません。
例えば、外部APIの仕様変更によって本番システムがエラーを吐き出しているのに、一括請負契約の壁があるために「追加費用の再見積もり」と「契約変更の稟議」に数週間を要し、その間システムが放置されてしまう――現場のエンジニアであれば、誰もが一度は経験するリアルな痛みです。

仕様変更の要求はランダムに発生し（ポアソン過程）、その対応にはばらつきのある時間がかかるため、このプロセスは待ち行列理論の「M/M/1モデル」で記述できます。ここで、環境変化の周波数を $\omega_c$ 、組織の合意形成能力の限界（処理率）を $\mu$ とおきます。$\omega_c$ が $\mu$ に近づくにつれ、取引コスト（ $C_{trans}$ ）は無限大へと発散することが証明できます。

$$\lim_{\omega_{c}\rightarrow\mu}C_{trans}=\infty$$

さらに致命的なのは、開発（設計）と運用（管理）を別会社に分断する「分離発注」です。組織を分断する行為は、第3章でエンジニアがせっかく組み込んだシステムの 自律神経系 を物理的に切断するに等しく、情報の伝達遅延（むだ時間）が最大化し、高確率で運用破綻を誘発します。

5. 結論：エンジニア主導で「MSP 3.0」へ相転移せよ

取引コストの爆発と運用破綻を防ぐため、業界構造は不可逆的な相転移を起こさざるを得ません。

SIerは「納品して手離れ」ができなくなり、月間のエラーバジェット内で恒常性を維持し続ける継続的運用（MSP的機能）へと移行します。同時に、MSPは単なる「インフラの外形監視」から、コードの内部構造を理解し開発側とエコシステムを共有するSIer機能へと踏み込む必要があります。

この両者が融合し、エラーバジェットを共有する共生型の準委任契約こそが、本論文が導き出した最終平衡状態、すなわち MSP 3.0 です。

そして、この変革を牽引するのは他でもない、私たちエンジニア自身です。コードを書いて終わりにするのではなく、設計段階から可観測性を計装し、エラーバジェットをコントロールする。平時にSLOという制約条件を設計しておく 判断の位置エネルギー化 に徹し、システムの自律的なエコシステムを構築するのです。

品質管理の基準が変われば、契約も組織も変わらざるを得ません。仕様書で凍結された「固体」のビジネスモデル（ウォーターフォール）から、変化に追随する「液体」のモデル（アジャイル）を経て、エコシステム全体でエラーバジェットを共有・拡張していく「気体」のビジネスモデル（OND/MSP 3.0）へ。

本稿が、明日からの計装設計を見直し、ポスト・アジャイル時代における新たなパラダイムシフトへ踏み出す一助となれば幸いです。

原著論文へのリンク：
伊藤覚宏, "Observability-Native型開発モデルの提唱：システム品質の再定義と社会技術システムにおける最終平衡状態" (SSRN)
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6824418