変化に強いシステムのためのアーキテクチャ：こんな時にはこのITアーキテクチャ （6）

[河野紀昭，日本IBM ICP-エクゼクティブI/Tアーキテクト]

アプリケーション保守は開発より大変といわれることがある。こういう場合の保守は、バグ修正などではなく、扱う商品や制度の変更などに対応するための修正作業であることが多い。世の中の変化は予知できないことが多いが、柔軟なアーキテクチャによりシステムを変化に対応しやすくすることはできる。Dependency Injection（DI）をはじめとする、さまざまな手法を取り入れて変化に強いシステム構築を目指そう。

　企業の情報システムを取り巻く環境変化として、次のようなものが考えられる。

• 取扱商品の増加、販売チャネルの変化
• 消費税率の変更や手数料自由化など法制度の変化
• 事務フローの改革や事業所の統廃合
• 企業合併

　企業合併は話が大き過ぎるとしても、取扱商品の変更などにはできるだけ柔軟に対応できるようにしておきたいところである。業務の変化に強いシステム構築のためには、次の4つの考え方が有効である。

1. 変化要素の外部パラメータ化
2. テスト・ファーストによる保守性向上
3. Dependency Injectionによるコンポーネント再利用
4. サービス指向アーキテクチャ（SOA）によるサービス再利用

　1）の外部パラメータ化とは、変化しそうなパラメータをプログラム内に直接コーディングせずに、外出ししておくということである。例えば、消費税率を用いて売り上げ処理をするプログラムであれば、消費税率をプログラム外部に持っていればよい。

　パラメータ化についての考慮点は、いつどうやって切り替えるかである。システム全体で1つのパラメータで動くのであれば、DBにパラメータの値を持って、これを書き換える方法が使える。ただし、オンラインとバッチが混在していて、例えば手数料切り替えに従って、オンラインは新しい手数料で動くが、前月の売り上げを処理するバッチは旧手数料で計算したい場合もある。

　このような場合には、業務日付によってパラメータが変わると考え、DBから業務日付に対応したパラメータを読み出すデザインが有効だ（図1）。

図1 DBから業務日付に対応したパラメータを読み出すデザインが有効だ

勘所：パラメータ化に当たっては切り替え方法を考慮しよう

　ある日を境に計算式が変わるなど、単純なパラメータ切り替えでは対応できない場合には、図2のようにDBに計算ロジックの入ったモジュール名を登録しておく方法がある。

図2 DBに計算ロジックの入ったモジュール名を登録しておく方法がある

　上記の方法は変化の内容がある程度予測でき、対応するパラメータやロジックをあらかじめ切り出しておくことができる場合に有効である。実際には変化の内容が予見できない場合が多い。

　2）のテスト・ファーストはこんな場合に有効な手段となる。テスト・ファーストはeXtreme Programming（XP）などのアジャイルな開発手法の中で提唱されている考え方で、まず、自動テストケースを作ってからコーディングを行う。このルールに従って開発すれば、すべてのプログラムに対して自動テストケースが用意されている状態になり、すべての動作を確認するリグレッション・テストをいつでも実行できる。

　このようにしておけば、ビジネス環境変化に対応してプログラムの機能追加や変更を行った場合に、副作用が生じていないかいつでも確認できる。アジャイルな開発手法では、変化を予見して機能を盛り込むより、現時点で必要な機能だけ実装して、追加機能は必要になった時点で柔軟に追加するという考えを採用している。これは変化の予見が難しい場合に、とても有効な考え方となる。

勘所：テスト・ファーストで変化した場合の機能保全を担保しよう

　ここまでは、アプリケーションの比較的小さな部分が変化する場合の対応法を述べてきた。新しい販売チャネルで商品を売るなど、ビジネスの仕方が変わった場合には、既存の仕組みを利用しつつ、新しい仕組みを構築する必要があるだろう。

　このような場合に有効なのが、DIやSOAの考え方だ。3）のDIとは、独立したコンポーネントを作っておき、必要なデータやモジュールを外部から「注入（Injection）」してから実行させるというものである。この考え方に立てば、コンポーネントは疎結合になり再利用性は向上するはずだ。

　そうはいっても、単にDIを導入しただけでは、コンポーネントの再利用はできない。あらかじめ再利用を考えてコンポーネントを設計し、再利用しやすくしておくことが大切だ。

　ここで、有効なのがデザインパターンの活用である。コンポーネントが決められたデザインパターンに従って作成されており、利用するためのルールが分かりやすければ再利用が促進される。特に有効なのがコマンドパターンで、図3のように再利用可能なコンポーネントをコマンドパターンで作っておき、再利用する際は必要なコマンドを選んでDIを用いて順次呼び出すようにすればよい。このデザインでは、アプリケーションに機能を追加したい場合もコンポーネントの追加で対応できる。

図3 再利用可能なコンポーネントをコマンドパターンで作っておく

勘所：コンポーネントをデザインパターンで標準化し、DIを用いて再利用しよう

　4）のSOAであるが、3）がプログラム・レベルでの再利用であるのに対し、SOAでは、既存システムを含めたサービス実行を再利用することになる。これは、既存のアプリケーションを、データを含めて再利用したいときに、特に有効だろう。

　さて、これまで変化に強いアーキテクチャ構築のための4つの考え方を述べてきたが、これらは相反するものではなく、組み合わせて使えばさらに有効である。例えば、DIやSOAで再利用を行う際に、再利用するコンポーネントやサービスが、パラメータで新しい使用形態に対応できたり、テスト・ファーストで保守性が担保されていたりすれば心強い。

勘所：いろいろな手法を組み合わせて、変化に強いアーキテクチャを構築しよう

---

　この連載では、いろいろなケースに対応するアーキテクチャを述べてきた。筆者としては、特定の要求に対し、解決方法をできるだけ複数示すようにしてきたつもりである。ITアーキテクトの仕事は、お客さまのこんなことを実現したいというご要望に対して、自分の引き出しからいろいろな解決策を取り出して、組み合わせてベストのITアーキテクチャを提示することだ。この連載が読者の皆さんの引き出しの中身を増やすことに少しでも貢献できればうれしく思う（図4）。

図4 さまざまなアーキテクチャ

最後の勘所：解決策の引き出しの中身を増やして、ベストのITアーキテクチャを構築しよう

「こんな時にはこのITアーキテクチャ」バックナンバー

• 変化に強いシステムのためのアーキテクチャ
• 使いやすいシステムのためのアーキテクチャ
• 24時間止められないシステムのためのアーキテクチャ
• 高可用性システムのためのアーキテクチャ
• 大量トランザクション処理に適したアーキテクチャ
• 良好なレスポンスを実現するアーキテクチャ