ソフトウェアアーキテクチャを決定するのは品質特性 [memo]

最近，会社の部内でデザインパターン研修が行われている．研修といっても「自習スタイル」で，若手エンジニア (受講生) が各自アサインされたパターンを自分で勉強し，各週ごとにプレゼンを行うというもの (いわゆる輪講)．それで中堅エンジニアが「技術アドバイザー」として持ち回りで参加し，内容を補足していく．

私も技術アドバイザーとして参加しているのだが，どうも聞いていると「このパターンはこういう構造で，リファクタリングの手順はこうなります」といった内容に陥りがちだ．もちろんデザインパターンを習得するには各々の内容を把握する必要があるが，それよりももっと大事なことがあると思う．

基本的にどんなパターンを適用するにしろ，メリットと同時にデメリットがある．つまり，何かを実現したい時にある特定のパターンを適用することよりも，「互いのデメリットを補い合い，いかにシステム全体として品質特性を高めるか」という，パターンの「組み合わせ」こそが，デザインパターンの本質だと思う．


一般的に「機能要件 (Functional Requirement)」「品質特性 (Quality Attribute)」「技術制約 (Technical Constraint)」「ビジネス制約 (Business Constraint)」の4つが，アーキテクチャ決定要因 (Architectural Drivers) と言われている．ソフトウェアを設計する時には，機能要件 (いわゆる要求仕様) をどう実現するかという点だけを頭に置きがちだが，実はこんなものはアーキテクチャを決定しない．極端なことを言えば，まったくモジュール分割を行わないスパゲッティコードの塊だって，機能要件を実現することはできる．

本当にアーキテクチャを決定するのは品質特性だ．品質特性とは，そのソフトウェアが実現するべき品質の特徴で，具体的には「Performance (性能・速度)」「Modifiability (変更容易性)」「Availability (可用性)」「Security (堅牢性)」「Usability (使いやすさ)」「Testability (テスト容易性)」を指すが，厳密にはこれだけある．
Ilities - Wikipedia, the free encyclopedia

例えば今後変わる可能性が低い業界標準規格を実装するなら「再利用性を高めたい」だろうし，今後プロトタイプを重ねて動きを見ていく中で仕様変更が予想されるところは「変更容易性を高めたい」だろうし，起動に関する個所は「パフォーマンスを圧倒的に優先したい」だろうし，アプリケーションや GUI を担当するなら「ユーザビリティ」を高めたいだろうし，もちろんそのソフトの特徴や使われ方，動作するハードウェア環境などによっても重要な品質特性は変わってくるだろう．

そしてどんなパターンを選び，どんな設計をしたとしても，それはある特定の品質特性を持ち上げ，また別の品質特性を押し下げるはずだ．それらを組み合わせてトレードオフをうまく調整することこそ，ソフトウェア設計というものだと思う．その為には要求仕様だけではなく，システムが実現したい品質特性とその優先順位を確実に把握しておく必要がある．

デザインパターンはそれを実現する手段の1つに過ぎない．「いくつかの似たような条件ロジックがあるから Strategy パターンが使えるかもなー」ではなく，自分の設計に持ち込みたい品質特性は何か，それを実現するパターンは何か，そしてそのパターンが抑制する特性が何で，その特性はどれぐらい重要か，重要なら代替案は無いか，もしくは他のパターンを組み合わせることで解決できないか…といった思考を持たなければいけない．そこの概念が欠落していると，デザインパターンを勉強するにしても単純に知識として理解することに満足してしまい，実際の開発現場で手段と目的が逆転しかねない．

「コードがきれいになる」とか「可読性が上がる」というのも重要だが，ソフトウェアを市場で使うユーザーは，そんなことにまったく興味はないのだ．


というわけで，デザインパターンを習得する際は，パターンの実現方法と一緒に，「そのパターンが促進する・抑制する品質特性」を意識すると良いと思う．