「いざ、IT投資」となった時に、情報システム部門として困るのは、事業側の要請（スピード感／コスト感）に応えられない事態である。「やりたいことの明確化と現行システムの調査に時間がかかります」「当社のシステムのアーキテクチャが古くて、対応には時間と高い費用がかかります」「当社のシステムのアーキテクチャで、今できること（＝今年度の予算・期間の範囲でできること）はこれだけです」といった会話を耳にすることも多い。
情報システム部門において、時に業務部門からの要求の盾にもなるが、多くの場合、変化の足かせとなってしまう「アーキテクチャ」というと何を思い浮かべられるだろうか。 「情報システムを構成する技術要素の組み合わせや設計方針」と思い浮かべられる方もおられれば、「データ構造と処理構造」「情報システムの設計思想」を思い浮かべる方、あるいは具体的に「モデル駆動型アーキテクチャ（MDA）のようなソフトウエア開発手法」「サービス指向アーキテクチャ（SOA）のような企業情報システムの包括的な構造や設計仕様」「汎用機やx86のようなコンピュータの設計仕様」等と考える方もおられるだろう。
ここでは、「企業情報システムの包括的な構造や設計思想」という意味での「企業情報システムアーキテクチャ」の寿命に着目して、どうやったら事業部門の要請に迅速に応えられる素地を整えられるのか、について考えてみたい。
※この定義では、設計仕様等を指す各種アーキテクチャは、大きな企業情報システムアーキテクチャの中に採用/不採用するものとして位置づけられる。
1.企業情報システムのアーキテクチャとソリューション決定の実態
「企業情報システムの包括的な構造や設計思想」は、よく都市計画のようなものだといわれる。もっとも有名なエンタープライズ・アーキテクチャ（EA）の言い方では、企業情報システムのアーキテクチャは、以下の4つの階層で表現される。
- ビジネスアーキテクチャ（BA）
- データ・アーキテクチャ（DA）
- アプリケーション・アーキテクチャ（AA）
- テクノロジ・アーキテクチャ（TA）
実際には各々の情報システム（都市計画に対して個別建築物に相当）は様々なレベルのソリューションを適用して実現しており、個別のソリューションと上記1～4のアーキテクチャの対応付けをして表現し、企業情報システムとしてのアーキテクチャを維持しながら、個別システムを構築するというのが、EAの教えである。
事業の方向性や技術動向を見ながら、都市計画であるところのEAを作成・維持しておくことの重要性は、古くから言われていることであるが、現実的にこれだけの情報を整合的に維持管理するには、困難が伴う。そのため、実態としては、技術標準、個別システムの要件・設計の決定プロセス、テクノロジ・アーキテクチャ（TA）をシステム部門内部のルールとして定めておいて、それより上位は個別建築物である各システムへの投資の際に検討することが非常に多い。
この方策を採るメリットは、情報システム部門で標準を維持する工数を最小限に抑えながら、システムとして「動く」状態を確実に維持することにある。一方で、アプリケーション・アーキテクチャ（AA）より上位の階層については文書化と維持を緩やかにすることで、本稿の冒頭に記載したように、本来、整斉と進めたい検討が進められず、事業側の要請（スピード感／コスト感）に応えられないという犠牲も払っている（もちろん個々の情報システムの保守文書のまずさに起因する場合もある）。
2. 維持すべき対象として改めて注目したい「データ・アーキテクチャ」
事業側の戦術変更や、基本的に同じ設計思想を維持したインフラ刷新は、数年サイクルで起きるものの、これらの変化を除けばBAやTAの根幹は、長期（10～20年以上）に維持される（注1）。
※注1：本格的なシステム全体刷新は、非常に大きな投資を伴うため、めったに起こらない。事業構造改革等の大きな経営面・事業面での変化を契機としたり、大きなTAの変化に対応して劇的なITコスト削減を旗印に一気に変革（例としては、ダウンサイジング）を起こすなどしないと、その費用を捻出できない。上記以外に、比較的中長期（10年前後）に維持されるものとして、挙げたいのが「データ・アーキテクチャ」である。具体的には何を指しているかといえば「顧客情報・取引先情報」「業務情報」「生産情報」「製品情報」等の情報の構造と具体的なデータ項目である。概念レベルの幹となるデータ構造は対象とする事業の仕組み（儲けの構造）が変わらない限り、ほとんど変化しない。そのため、多くの企業で、暗黙知的に管理部門の一部の従業員の頭の中に維持されていて、情報システム部門に必要なデータを要求し、必要な分析を行うことが可能であった。
しかしながら、昨今のデータ活用の流れ（いわゆるビッグデータ活用）の中で、事業の成果としてのデータだけでなく、顧客1人1人の取引内容や活動も含めて分析対象とするなど、これまでにない粒度・質のデータを対象とする必要が出てきている。この分析に必要なデータは量的・質的にまったく異なる上、対象となるデータエンティティ自体も多く、変化しやすい（例：販促の際の属性である○○項目を対象にするなど）。そのため、特定のシステムだけでなく、関係のあるシステム全体でデータ構造をしっかり維持管理しない限り、必要なデータ取れなかったり、取れたとしても中途半端なデータしか取れなかったり、という事態が起きてしまう（注2）。
※注2：さらに状況を複雑にしているのが「クラウド」の存在である（拙稿「クラウド時代・ビッグデータ時代のデータマネジメント」）こういった事態を避けるためにも、「データ・アーキテクチャ」は中長期に維持管理する価値が高いものである。即時に直接的な便益を生むものではないが、上記のようなデータ活用の組織的な準備として必要なものではないだろうか。
ただし、これを事業・業務と情報システムの両面に目配りができる人材を必要とするため、育成にも大変な時間がかかる。目先の案件だけでなく、戦略的に人材を配置して対応する必要があることを申し添えたい。
本文中のリンク・関連リンク：
- クラウド時代・ビッグデータ時代のデータマネジメント
- 南波幸雄『企業情報システムアーキテクチャ』翔泳社（2009）
- Nick Rozanski, Eoin Woods『Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives』Addison-Wesley Professional(2011)
- 松島桂樹『IT投資マネジメントの変革』白桃書房（2013）
- 松島桂樹『IT投資マネジメントの発展』白桃書房（2007）