6か月後、あなたのコードベースは仕様どおりの状態を保っているでしょうか？

ソフトウェア設計書とコードベースは別物です。それらを同期させ続ける方法とは？

コードベースは先へ進みました。しかし、ドキュメントはその場に取り残されたままでした。

これは、多くのプロジェクトで起こることです。

数か月にわたる作業の末、ソフトウェア要求仕様書が完成し、ソフトウェア設計書も承認されました。
関係者がレビューし、アーキテクトが設計を具体化し、開発チームは実装を開始するために必要な情報
を手にしています。

しかし6か月後には、状況は変わっています。機能が追加され、緊急修正が一晩で取り込まれ、新しく加
わったメンバーがその時点では妥当に思えた近道をし、単体では問題なく動作していた提供コンポーネ
ントが、誰も確認しようと思わなかったレイヤリングルールをひそかに破っていたことが分かります。

誰かが詳しく確認する頃には、仕様として定められていたものと実際に構築されたものとのギャップ
は、監査で実際の、しかも非常に高額な問題を引き起こすほど大きくなっています。

これは、プロセスの問題やチームの規律の問題として語られがちです。しかし、実際にはそのどちらで
もありません。

では、何が問題なのでしょうか。

問題は構造にあります。ソフトウェア設計書とコードベースは、同じものではないからです。

ソフトウェア要求仕様書（SRS: Software Requirements Specification）は、システムが何をすべきかを
示します。しかし、6か月後のコードがそれらの決定をなお反映しているかどうかまでは教えてくれませ
ん。

仕様と実装を同期させ続けるには、よく書かれたドキュメントや善意だけでは不十分です。

ソフトウェア要求仕様書とソフトウェア設計書には何が記載されるのか？  

ソフトウェア要求仕様書 (SRS)は、システムが何を実現しなければならないかを定義する文書です。

IEEE 830 の考え方に従い、ソフトウェア要求仕様書にはシステムが満たすべき振る舞いを定義する機能要件 (Functional Requirements）だけでなく、性能、安全性、セキュリティ、信頼性といった制約条件を定義する 非機能要件（Non-Functional Requirements）、さらに開発対象の範囲や境界も記載されます。

これにより、開発チームおよびその成果に関わるすべての関係者が、「何を実現しようとしているのか」について共通の認識を持つことができます。

一方、ソフトウェア設計書（Software Design Document）は、ソフトウェア設計仕様書（SDS: Software Design Specification） と呼ばれることもあり、次の問いに答えるための文書です。それは、「システムは何をするべきか」ではなく、「システムをどのように構築するのか」 という問いです。

設計書には次のような内容が記載されます。

• システムをどのようなコンポーネントに分割するか

• 各モジュールが担う責任

• インターフェースをどのように定義するか

• どの依存関係を許可するか

• 開発期間を通じて維持すべきアーキテクチャ上の制約

優れたソフトウェア設計書は、意図したシステム構造を具体的な形で示します。例えば、次のような内容を明確にします。

• どのようなレイヤーが存在するのか

• 各レイヤーがアクセスできる対象は何か

• どのモジュール同士の通信を許可するのか

• アクセスや依存が禁止される領域はどこか

これら2つの文書を合わせて読むことで、システムがどのように設計されたのかを記録したアーキテクチャ記述（Architecture Description）が形成されます。ISO/IEC/IEEE 42010 では、完全なアーキテクチャ記述に含めるべき内容が体系的に定義されています。

ただし、これらの文書には共通の限界があります。それは、文書が作成された時点のシステム状態しか表現できないということです。文書は作成・承認された時点では正確です。しかし、コードベースが変化した際に、それに合わせて自動的に更新されるわけではありません。

アーキテクチャドリフトはどのように発生し、なぜ発見が難しいのか

アーキテクチャの劣化（Architecture Erosion）は、実装されたシステムが時間の経過とともに、気づかないうちに本来のアーキテクチャ記述から逸脱していくことで発生します。

それは、一つひとつはその場では合理的に見える小さな判断の積み重ねによって進行します。そして最終的には、ソフトウェア設計仕様と実際に稼働しているコードとの間に、実害をもたらすほど大きなギャップが生まれてしまいます。

例えば、ISO 26262 に基づいて開発される安全クリティカルな組込みシステムを考えてみましょう。ソフトウェアアーキテクチャ記述では、厳格なレイヤ構造が定義されています。アプリケーション層はハードウェア抽象化ルーチンへ直接アクセスできず、すべてのハードウェアアクセスは専用のハードウェア抽象化レイヤ（HAL）を経由しなければなりません。

このルールには、もちろん正当な理由があります。

プラットフォーム固有の処理を局所化できるため移植性が向上し、さらに認証機関に対して機能安全性を説明・証明する際の重要な根拠にもなるからです。

ところが開発開始から18か月後、納期に追われた開発者が、アプリケーションモジュールからハードウェア制御ルーチンを直接呼び出すコードを追加したとします。

その変更は目の前の問題を解決しました。コードレビューも通過しました。レビュー担当者はコードが正しく動作するかどうかに注目しており、アーキテクチャのルールに従っているかまでは確認していなかったためです。そしてそのまま製品に取り込まれました。

さらに6か月後、別の違反が発生します。その後さらにもう一つ。しかも別のサブシステムで発生します。その開発者は、以前に発生した違反について何も知りません。

やがてアーキテクチャチームが機能安全監査の準備を始める頃には、ソフトウェア設計仕様のアーキテクチャ記述とコードベースは、まったく異なる内容を語るようになっています。

それらを再び一致させるには、大規模なコードベース全体を調査しなければなりません。しかしその時点では、変更は高コストで、困難であり、場合によっては実施不可能ですらあります。

研究結果も、このような状況が決して珍しくないことを示しています。

同じ現象は、IEC 62304 に準拠した医療機器ソフトウェアや、IEC 62443 に基づく産業制御システム、さらには DO-178C に準拠した航空宇宙ソフトウェアでも発生します。

安全・規制要件が厳しい分野においては、アーキテクチャ記述と実装が一致していない状態は、単なる品質上の問題ではありません。コンプライアンス違反でもあります。

このギャップを表す技術用語が Architecture Divergence（アーキテクチャ乖離） です。

これは、アーキテクチャ上は許可されていない依存関係がコード内に導入された状態を指します。アーキテクトは、このような差異を分析することで、実装が依然として仕様どおりであるかを判断します。しかし問題は、多くの開発チームがその判断を自動的に行う仕組みを持っていないことです。

ソフトウェア要求仕様書はルールを文書化する。アーキテクチャ検証は、そのルールがコードで守られているかを確認する。

アーキテクチャ検証とは、実装されたシステムが依然としてアーキテクチャ記述に準拠しているかどうかを継続的に確認することです。これは、ドキュメントだけではカバーできない部分を担うプロセスです。

Axivion アーキテクチャ検証は、ソフトウェア設計書に記載されたルール、許可された依存関係、禁止されたレイヤ間呼び出し、モジュール境界といった定義を取り込み、それらをアーキテクチャモデルとして表現します。

このモデルは、システムが本来どのような構造であるべきかを表します。そして Axivion は実際のコード
ベースを解析し、モデルと実装との違いを自動的に算出します。

CI/CD パイプラインに統合されるため、これは一度きりのチェックではありません。Axivion はすべてのビルドに対して実行されます。

開発者がアーキテクチャ記述に違反する依存関係を追加してしまった場合、その問題は監査の準備段階になって数か月後に発見されるのではなく、追加されたその時点で検出されます。

禁止された import、レイヤをまたぐ呼び出し、モジュール境界の違反、あるいは本来存在すべき依存関係の欠落など、どのような問題であっても、追加された瞬間に検出されます。

コンプライアンス要件の下で開発を行うチームにとって、このようなトレーサビリティは「あれば便利」というものではありません。

例えば、

「アプリケーション層はハードウェアレジスタへ直接アクセスしてはならない」

といったアーキテクチャ上の制約を定義した要求事項は、単に文書に記載されているだけでは不十分です。実際の成果物（ソフトウェア）がその要求を満たしていることを検証可能でなければなりません。Axivion はその検証を提供するとともに、それを裏付ける監査証跡（Audit Trail）も維持します。

ソフトウェア要求仕様書の作成方法を解説するガイドは、要求仕様書を適切に作成する上で役立ちます。しかし、そのようなガイドでは、

「6か月後のコードベースが、依然として仕様書に記載された内容を満たしているのか」

という問いに答えることはできません。

アーキテクチャ検証が担うのは、まさにその部分です。

ソフトウェア設計書を「生きた資産」にする

Axivion でアーキテクチャモデルを構築する際の出発点となるのは、すでに手元にある次のような成果物です。

• ソフトウェア設計仕様書

• ソフトウェアアーキテクチャ記述

• それらに記載された依存関係やレイヤ構造に関するルール

アーキテクトは、ソフトウェア設計書に定義された構造上のルール、許可されたモジュール間依存関係、レイヤ階層、禁止された関係などを整理し、それらを Axivion のアーキテクチャ定義における制約として表現します。

その後 Axivion は、ファイル、パッケージ、クラス、関数といった実際の実装要素を、アーキテクチャモデル内の概念的な要素に対応付けます。そして リフレクション分析（Reflexion Analysis） によって、コードベースがアーキテクチャに準拠しているかどうかを判定します。

アーキテクチャモデルは、ソフトウェア設計仕様書を置き換えるものではありません。むしろ、設計仕様書を「生きたもの」にするための仕組みです。文書化する価値があるほど重要なルールは、単に文書に記載されるだけでなく、継続的に検証・適用されるルールへと変わります。

フレゼニウス メディカル ケアFresenius Medical Care 社が、数十年にわたる開発ライフサイクルの中で、 multiFiltratePRO のソフトウェアアーキテクチャをどのように維持しているのかをご覧ください。また、ソフトウェア品質が患者の安全に直結する医療機器において、それがどのような意味を持つのかもご確認いただけます。

成功事例を読む >

アーキテクチャ検証の恩恵を最も受けるのはどのようなチームか

アーキテクチャ検証は、規制や各種規格への準拠が求められるソフトウェアのためにソフトウェア要求仕様書を作成するあらゆるチームにとって有効です。しかし、その重要性が特に高いのは、設計されたアーキテクチャと実装されたアーキテクチャとの間に乖離が生じた場合、それが安全性やコンプライアンスに直接影響を及ぼす業界です。

ISO 26262 に準拠した車載ソフトウェア

ISO 26262 に基づく車載ソフトウェア開発では、機能安全性の妥当性を示す根拠は、ソフトウェアアーキテクチャ記述が実際に構築されたシステムを正確に反映していることを前提としています。レイヤ構造の違反や想定外の依存関係は、何か月もかけて実施した安全分析の前提を崩してしまう可能性があります。そして、そのような問題がプロジェクト後半で発覚すると、修正には大きなコストがかかります。

継続的なアーキテクチャ準拠チェックにより、開発が進行する中でも、実装が安全性ケース（Safety Case）の基盤となるアーキテクチャと整合していることをチームは確信できます。

IEC 62304 に準拠した医療機器ソフトウェア

IEC 62304 に基づく医療機器ソフトウェアでは、要求仕様からアーキテクチャ、そして実装に至るまでのトレーサビリティが求められます。

アーキテクチャ検証は、実装されたシステム構造がソフトウェア設計仕様に一致していることを自動的に証明します。さらにその証跡は、「理論上すべてが完成した時点」でのみ有効なものではありません。実際のプロジェクトで行われる反復的な開発サイクル全体を通じて維持されます。

IEC 62443 に準拠した産業システム・IoTシステム

IEC 62443 に基づいて開発される産業制御システムや IoT システムでは、サイバーセキュリティ要件の中に明確なアーキテクチャ制約が含まれています。

このような制約こそ、アーキテクチャ検証が特に効果を発揮する対象です。実装が設計仕様から逸脱した場合、それは単なる品質上の問題ではありません。セキュリティ境界が破られたことを意味する可能性があります。

DO-178C に準拠した航空宇宙ソフトウェア

DO-178C に準拠する航空宇宙ソフトウェアでは、開発ライフサイクル全体を通じてアーキテクチャの整
合性が維持されていることを示す証拠が求められます。

アーキテクチャ検証は、その証拠を監査直前の一時的な活動としてではなく、継続的に提供します。これらすべての分野に共通しているのは、要求仕様書やソフトウェア設計書の作成に多大な労力を費やしている一方で、開発が進むにつれてコードベースが依然としてそれらを正しく反映しているかどうかを、自動的かつ確実に確認する手段を持っていないことです。アーキテクチャ検証は、そのギャップを埋めるための仕組みです。

要点まとめ： アーキテクチャ検証のないソフトウェア要求仕様書は、検証できない約束に過ぎない

ソフトウェア要求仕様書（SRS）は、システムが何を実現すべきか、そしてどのような構造であるべきかを定義します。しかし、実際に出荷されるコードが、それらの設計上の決定を今も反映しているかどうかまでは教えてくれません。それを継続的に確認する仕組みがなければ、仕様書は保証ではなく、単なる意思表明に過ぎません。

アーキテクチャ違反を追加された瞬間に検出することと、監査の場で初めて発見することとの間には、大きな違いがあります。

前者はプルリクエスト内の1行の修正で済むかもしれません。一方、後者はプロジェクトの最も避けたいタイミングで、大規模なコードベース全体を対象とした高コストな原因調査を伴います。そしてそれは、やり直し作業や再分析、さらにゼロから作り直さなければならないコンプライアンス証跡の準備が始まる前の段階にすぎません。

最も厄介なのは、

「この状態はいつから続いていたのか？」

という問いに答えなければならなくなったとき、誰も答えられないことです。

仕様と実装の乖離は、工学的な問題です。そして、その解決策も工学的です。つまり、アーキテクチャとコードが依然として仕様どおりであることを継続的に確認することです。

Axivion アーキテクチャ検証は、まさにそれを実現します。開発ライフサイクル全体を通じて、すべてのビルドで自動的に検証を実施し、認証・規格準拠が求められる分野で必要となるトレーサビリティも提供します。

プロジェクトについてぜひご相談ください。私たちがお手伝いします。