そのシステムの将来の姿、見えますか？：ITアーキテクト的発想のススメ（3）（1/2 ページ）

本連載ではこれまで、ITアーキテクトは複数の視点で対象をとらえ、評価する必要があると述べてきた。評価はその時点で確定するものではなく、時間経過に伴う状況の変化によって変わっていく。従って、ITアーキテクトには将来の変化という時間的な要素も加味した「物の見方」が必要になってくるのだ。

[東山 靖弘（NTTデータ），＠IT]

時間経過に伴う変化を考える

　これまで2回の連載では、ある時点におけるアーキテクチャを「形態」として扱い、その全体像を把握するために必要な見方を紹介してきた。具体的には、対象のとらえ方として空間的な広さや深さが大事であること、検証の仕方として複数の立場の視点から見ることが必要であることを説明した。

　特に明記はしなかったが、これまでの解説ではいろいろな尺度や立場の見方をとった場合でも、アーキテクチャを評価する観点は、ある時点においてステークホルダー間で合意された1つの基準があるということを前提としていた。

　今回は少し異なり、アーキテクトがビジネスやシステムのライフサイクルを通じて直面する「評価の変化」という、時間的なテーマを扱いたい。

「共時的」と「通時的」

　今回のテーマを理解していただくために、まずはこんな話から始めてみたい。

　自分の生活の中で、何か大事な物を買うときのことを思い出してもらいたい。おそらく、いろいろなお店に行って実際に自分の目で見て確かめたり、知人の口コミやインターネットでの評判を調べたりして、多くの情報を集めることから始めるだろう。そういった情報収集活動の中で、徐々に自分自身の中でその物に対する評価軸や実際の評価が出来てくる。

　例えば車であれば、乗り心地、スタイル、燃費、サイズ……、といった評価軸に対して、購入候補の車ごとに自分なりの評価を下していく。販売する側もそういった顧客の購入プロセスに対応して、自社製品の特徴や他社製品との比較などの情報を提供している。

　ただ、ここで1つ注意してもらいたいのが、そういった製品比較の多くが、自分が物を買おうとしている時点における評価に過ぎないということだ。

　そのとき、一番自分に合っていると思った物を選んだにもかかわらず、その後数年して「やはり、あちらにしておけばよかった……」と感じた経験は誰しもあるだろう。また、「これまでこういう物を使っていたから、今回もこうしておこう」といった形で買う物を決めていることもあるのではないか。実はこのどちらの場合も、「時間的なつながり」が物を決める際に大きな問題となってくることを示している。単純にある時点での見方、すなわち「共時的な見方」だけでは評価は決まらないのである。

　アーキテクチャの検討・決定というプロセスも、時間的なつながりに対する考慮というものが大きなウェイトを占めている。アーキテクトは、過去から現在、未来にわたる「通時的な見方」でアーキテクチャを考えていかなければならない。

　それでは、以下でもう少し具体的に説明しよう。

アーキテクチャの通時的評価

［問い］

　「こんなとき、あなたならどうするだろうか」

　ある情報システムでは、新規ビジネス向けの基幹業務の機能を提供していた。ビジネスの立ち上げ当初は、必要最低限の情報投資を行うという方針のもとに、初期コストを最小化するアーキテクチャを採用してきた。その結果、下図のようにサブシステムごとの連携は、個別設計のインターフェイスを通じて行われていた（図1）。

図1　サブシステム同士を個別インターフェイスで連携

　ビジネスはその後順調に拡大していったが、それに伴うシステムへの機能追加でさまざまなインターフェイスに変更が発生したり、管理対象となるアプリケーションが肥大化してきたことが、アーキテクトにとって重要な課題となってきた。

　さて、あなたならどうするだろうか？ もちろん、判断を下すためにはさらに多くの情報が必要だ。いくつかの前提や仮説を設定した解答例を挙げてみよう。

［答え1］

　「機能間連携の共通基盤を導入する」

　1つの答えとしては、下図のような共通基盤を採用した新しいアーキテクチャに変更していくというものが考えられる（図2）。

図2　サブシステム同士を共通基盤で連携

　このような共通基盤を導入したアーキテクチャが効果を発揮するには、以下のような前提条件や仮説が必要だ。

1. 個別に設計されているインターフェイスは、共通化が十分に可能である
2. 共通基盤により開発期間の短縮や開発コストの削減が可能になる
3. 共通基盤が活用される機能間連携のインターフェイスは、今後も増加する

　ここで、上記1と2は現行アーキテクチャと新しいアーキテクチャの「形態の違い」をもとにした比較の結果であるのに対し、3は「時間的な変化」に着目したものである点が重要である。

［答え2］

　「いままでどおり、個別に機能を追加していく」

　もう1つの答えとして、当然ながら現行のアーキテクチャをそのまま維持するという考え方もある。そのような考え方の理由には、以下のようなものが考えられる。

1. 個別に設計した方が、要件に柔軟に対応できる
2. 共通基盤が開発や運用におけるボトルネックとなりかねない
3. すでに開発した機能を移行するコストが無駄である

　この場合も、1と2は形態における比較だ。一方3には、移行コストを回収できるほど共通基盤の導入効果が得られない、つまりそれほど将来にわたって活用されないだろう、という暗黙の仮説が含まれている。

　答え1と答え2のそれぞれの前提条件を比べてみると、3番目の「時間的な変化に対する予測」が相反していることに気付くだろう。答え1では、今後もこのシステムは大いに活用され、機能追加やそれに伴うシステム間連携も増えていくだろうと予測している。一方、答え2の方では機能追加はあまり行われず、今後もいまある機能が主に使われることになるだろうと予測している。この違いが理由で、それぞれ異なる結論に至っていることが分かっていただけるだろう。