アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。
このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。
- 利害関係者にインタビューをして重視しているポイントを聞き出す
- そのポイントからシステムに求められる品質特性を整理する
- 整理された品質特性を元に、実際のアーキテクチャの設計を行う
- 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う
品質特性というのは色々なところで定義がありますが、経産省が公開している「情報システム/ソフトウェアの品質メトリクスセット」というのがよくまとまっているので紹介します。この資料は様々なソフトウェア品質についての資料を統合し、いまの状況に合うように整理したものです。
情報システム／ソフトウェアの品質メトリクスセット（PDF）
情報システム/ソフトウェアの品質メトリクスセット 利用ガイド（PDF）
この資料で定義されている品質特性は以下の通りです。8つの品質特性と、それぞれに副特性が定義されています（細かい説明などは資料を参照ください）。
- 機能適合性
- 完全性
- 正確性
- 適切性
- 性能効率性
- 時間効率性
- 資源利用性
- キャパシティ
- 互換性
- 共存性
- 相互運用性
- 使用性
- 適切度認識性
- 習得性
- 運用性
- ユーザエラー防止性
- ユーザインタフェースの快美性
- アクセシビリティ
- 信頼性
- 成熟性
- 可用性
- 障害許容性
- 回復性
- セキュリティ
- 機密保持性
- インテグリティ
- 否認防止性
- 責任追跡性
- 真正性
- 保守性
- モジュール性
- 再利用性
- 解析性
- 変更性
- 試験性
- 移植性
- 順応性
- 設置性
- 置換性
これを参照しながら評価する軸を決めていくと抜け漏れなくできると思います。使用性とか保守性とかは抜けがちですよね。
重要なことは上記全てについて検討をすることです。利用ガイドには「全てのメトリクスを利用する必要はありません。情報システム／ソフトウェアの特性に合ったメトリクスを選び、」とはありますが、全ての視点で考えてみるというのも非常に大事です。思いつかないから抜くのではなく、ひねり出すぐらいの心づもりで考えた方が抜け漏れがなくなる気がします。
品質特性を使ったアーキテクチャ評価としてはATAM (Architecture Tradeoff Analysis Method: アーキテクチャトレードオフ分析方法)が有名だと思います。日本語の本としては「実践ソフトウェアアーキテクチャ」ですので、読んでみるのもよいかと。
とはいえ、これは形式的にまとめられているだけなので、本当の実践には様々なアプローチが必要です。こういう具体的なところを書きたいのですが、なかなか文章になりにくく断念しました。勉強会もしにくいし、どうしたらいいんですかね。伝えたいとは思っているのですが...。
