第5回　保守運用・移行工程のITアーキテクト

　ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は保守運用・移行工程を対象にします。保守運用・移行工程では、主に次の5つの成果物を作成します。

（1）アプリケーション改修基準書
（2）モジュールの依存関係図
（3）システム稼働統計レポート
（4）改善アーキテクチャードキュメント
（5）実装に基づき最新化した文書
　　（コンポーネント図、状態遷移図、データモデル図）

　この工程で重要なポイントは、システムは常に変化し続けるという認識を持ち、変化に伴うリスクが顕在化する前に手を打つことです。長年にわたって改修してきたシステムでは、仕様と実装の乖離が激しくなり、移行する段階で“正”の仕様がコードからしか分からない状態になっていることが少なくありません。デグレードを恐れて付け焼刃的な対応を繰り返しているとシステム内部の複雑さが増し、移行時点で大きなリスクを伴います。

　一度リリースしたシステムは継続性を求められるので、そう簡単には作り直すことはできません。24時間365日の運用を求められるシステムであれば、歪な改修を強いられるかもしれません。性能問題の対応だけで莫大なコストが発生することもあるでしょう。これらすべては、アプリケーションの本質的な複雑さではなく、制約から生じる偶発的な複雑さです。アクシデントを最小限に抑えるために、ITアーキテクトは事後的（Re-active）に動くのではなく、能動的（Pro-active）に活動を続けます。

（1）アプリケーション改修基準書
　初回リリース後に発生する改修案件。その際の対応として、新たなコンポーネントを追加するのか、あるいは既存コンポーネントを改修するのか、その判断基準を示した文書が「アプリケーション改修基準書」です。その基準は、アプリケーションの新陳代謝を維持することです。新陳代謝を維持するとは、変化への対応力が低下しない、また、過去に築いた資産を活用してより迅速に改修案件に対応できることを指します。

　初期リリースの段階では「開発体制」と「開発対象」が1対1の関係になっていますが、リリース後は初期の「開発対象」をまたがるような要件が生じます。この際、「誰が対応するべきか？」という観点でタスクをアサインすると、よく知っているコンポーネントの改修/拡張を行うといった対応に陥りやすく、既存コンポーネントの責務が曖昧になっていきます。このようにしてコンポーネント分割のメリットが薄れて依存関係が複雑化し、その結果、品質の担保に苦慮することになります。こうした事態を避けるために、事前に改修基準を決めます。

（2）モジュールの依存関係図
　ソフトウエアモジュールの依存関係が一方向に保たれていることを明らかにした文書が「モジュールの依存関係図」です。ここでいう「モジュール」とは、コンポーネント間を行き交うデータ構造なども含め、ある責務を持ったソースコードのまとまりを指しています。

　ITアーキテクトは“無重力”のソフトウエアの世界に、あたかも重力が働いているような普遍的な規律を生み出し、システム全体を統制します。モジュール間の一方向の依存関係を保つことが、その普遍的な規律を維持することです。その規律が働いていることを可視化し、システム改修時の潜在的影響範囲を特定しやすくし、改修後も規律に従うように導きます。モジュールの相互依存が発生すると著しく保守性が低下します。これを避けるために、依存関係を明らかにし、関係者全員で常に共有します。

（3）システム稼働統計レポート
　ハードウエアの使用状況や処理ピーク時のボトルネックを表した文書が「システム稼働統計レポート」です。適切なアーキテクチャーの改善には日ごろからの「計測」が不可欠です。特に性能のボトルネックになるハードウエアリソースが逼迫する前に、変化の兆候を読み取り、改善策の検討に入ります。性能問題が発生してからでは付け焼刃的な対応になりがちです。性能問題が日々深刻化する環境でそのような対応を繰り返すと、システム内部の偶発的な複雑さは増加し、システムが重厚長大化していきます。その結果、変化への対応力は低下し、システムのTCO（総所有コスト）は上昇していきます。

（4）改善アーキテクチャードキュメント
　システム運用する中で得た事実に基づく、アーキテクチャー改善策を示した文書が「改善アーキテクチャードキュメント」です。アーキテクチャー改善の意思決定を行うために使います。ファクト（事実）に基づく、コスト（費用）・ベネフィット（効果）分析が付記されたものである必要があります。モジュールの依存関係図とシステム稼働統計レポートがファクトです。このファクトが十分な情報でなければ、時系列でトレンドを追えず、適切なアーキテクチャーに改善できません。要件定義工程で作成したVision Documentに照らし、改善アーキテクチャー策が妥当であるか確認し、リスクが顕在化する前に改善策を施します。

（5）実装に基づき最新化した文書
　　（コンポーネント図、状態遷移図、データモデル図）
　設計工程で作成したドキュメントを実装に基づき最新化した文書（欠落していれば補完した文書）が「実装に基づき最新化した文書（コンポーネント図、状態遷移図、データモデル図）」です。移行プランを立てるためにこれらの文書を使います。最新化しておくことで、何を移行するのか、何を作り替えるのか、何を捨てるのかなどを仕分けし、ファクトに基づく移行プランを立てることができます。また移行時に、「現行保証（既存の機能の継続利用を可能とする）」の要件がある場合、移行時のテストケースの妥当性検証にも使います。