DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

私が理事を務めるIasa日本支部のイベント「第8回BITAS Executive Series 2019」が、去る10/30-11/1に開催されました。国内外の有識者をお迎えし、最新のデジタル活用の事例を伺うことで多くを学ぶことができました。また、先進企業のEA（エンタープライズアーキテクチャ）への関心の高さも改めて確認できました。一方で世の中に目を向けると、国内外ともにDXをキーワードにビジネス変革への関心が高まっていますが、イノベーションや組織論、テクノロジーの議論が多く、これらをつなぐアーキテクチャへの関心はまだ低いように感じます。アーキテクチャおよびそのデザインへの関心がもっと高まっていくべきでしょう。ということで、今回はアーキテクチャデザインをテーマにしてみます。

＊＊＊

そもそもアーキテクチャという言葉の意味が、多くの方にとってわかりにくいかもしれません。インターネットや関連文献をみると、様々なアーキテクチャの定義を目にすることができます。唯一のものがあるわけではありませんが、国際規格ISO/IEC/IEEE42010では以下のように定義されています。
“コンポーネント（構成要素）、コンポーネント間および環境との「関係」、また
その設計と進化の指針となる原理に体現された「システム」の基本「構造」である“
この定義をもとに考えてみます。世の中はシステムと呼ばれるものに満ち溢れています。これらシステムの中には、セキュリティや信頼性のように堅牢性が最優先のものもあるでしょうし、利便性や使い勝手がシステム価値に直結するものもあります。柔軟性も重要な特性としてあげられる場合が多いです。こうしたシステムの特性はその構造によって決まるといえます。システム構造、すなわちアーキテクチャです。よって、望ましいシステムの特性を手にするにはアーキテクチャをデザインすることが不可欠です。意図しない、つまりデザインしない特性を手に入れることはできません。

アーキテクチャという言葉は、最初に建築の世界で生まれました。ITの世界においては、IBMがSystem/360の設計思想を表現するために、この言葉を使ったのが始まりだそうです。それがさらに広がって、ソフトウェアシステムの設計思想にも使われ、今や企業のビジネス活動全体に対しても使われています。近年は、ビジネスアーキテクチャへの関心も高まっているようです。その背景には、グローバル化・デジタル化に伴って、ビジネス活動が広範かつ複雑になってきたことがあるのではないでしょうか。そのアーキテクチャを知ることなく、複雑なものを理解はできません。同時に企業のアーキテクチャ課題には、ビジネス視点に関わるものが大きくなってきています。これは前回のコラムで２重のギャップとしてふれたとおりです。ITアーキテクトは、アーキテクチャデザインによって課題を解決する専門職です。ですから、IT視点にとどまらずビジネス視点でアーキテクチャ対象を捉えデザインすることが求められているのです。

＊＊＊

では、このアーキテクチャはどのような活動を通してデザインされるのでしょうか。皆さんの組織のなかには、アーキテクチャの開発プロセスを定めているところもあるでしょう。TOGAF(The Open Group Architecture Framework)等のようなEAフレームワークをベースにされているかもしれません。様々な方法論が世の中にありますが、私の経験から言うとアーキテクチャデザインに関わる活動には概ね次の７つがあげられそうに思います。特に、論理モデリングの役割は重要です。これはテクノロジーの急激な変化に対して安定しているだけでなく、ビジネス側とテクノロジー側の両方のステークホルダーが理解できる共通言語となります。それぞれの活動を簡単に見ていきます。

・アーキテクチャ戦略／構想
ビジネスニーズやそれを取り巻く環境、ビジネス戦略を理解することなく、アーキテクチャ活動はできません。これらを理解したうえで、アーキテクチャ活動範囲のスコーピングや活動推進のためのアプローチ選定を含めた全体計画をします。
・アーキテクチャモデリング(ASIS論理)
現時点でのアーキテクチャ構造を論理モデルとして表現します。ここでのポイントは、テクノロジー詳細や物理実装に非依存なモデルとすること、細部に踏み込みすぎないこと、そしてモデリング範囲を広げすぎずに必要十分に留めること、などがあります。
・アーキテクチャデザイン
あるべき姿から見て、不足していたりギャップを引き起こしている構成要素を特定して解決します。本当の意味でのデザイン活動であり、ITアーキテクトの腕の見せ所です。実績のあるリファレンスやパターン、ドメインに対するITアーキテクトの豊かな経験知の活用が肝要です。
・アーキテクチャモデリング(TOBE論理)
アーキテクチャデザインの結果を論理モデルとして表現します。TOBEモデルとASISモデルの差分が、アーキテクチャ要求を導きます。よって、モデリングの範囲や記載粒度はASISモデルとできるだけ揃えることが望ましいでしょう。
・アーキテクチャ評価
前回のコラムでとりあげたように、ITアーキテクトの役割には「要求者のビジネスの方向性に対する思いと実現性のあるITの観点をつなぐこと」があります。よって、ITアーキテクトは自身がデザインしたアーキテクチャを様々な観点で評価することが求められます。ここに至って、論理アーキテクチャがひとまず完成したといえるでしょう。
・実装への展開
論理アーキテクチャはプロジェクトに引き継がれて、具体的なテクノロジーや物理実装に結び付けられたシステムへ具現化されます。このことを通じて、論理アーキテクチャは物理アーキテクチャへ展開されます。ITアーキテクトは、論理アーキテクチャと物理アーキテクチャのギャップが生じないようプロジェクトを導くことが求められます。
・アーキテクチャ維持管理
システムは企業が存続する限り成長していかねばなりません。アーキテクチャデザインも同様で、実装したら終わりというわけにはいきません。システムの実態とアーキテクチャデザインは整合が取れており、逆にアーキテクチャデザインの進化は確実にシステム実装へ反映されるように、維持管理していくことが求められます。

＊＊＊

ここで、アーキテクチャの価値について少しふれておきます。
多くの組織では、ビジネスやITの構造がブラックボックスとなっています。そのため、組織のアジリティが大きく損なわれ、その硬直性ゆえに組織の無駄を排除することが難しくなっています。経済産業省の「DXレポート」が警鐘しているのもこのことだといえます。これは、ビジネスやITのアーキテクチャモデルを手にすることなく、目先のソリューションありきで近視眼的な投資を積み重ねてきた結果ともいえます。従来、企業はヒト・物・金の見える化に取り組み、これら経営資産の戦略的活用を推し進めてきました。今や企業変革のカギを握るアーキテクチャに対しても、同様の取り組みが必要でしょう。「組織を変革する」ことと「アーキテクチャを変革する」ことは同じと捉えるべきです。アーキテクチャモデルを組織改革の海路図とすることで、変化の激しいこの時代を乗り切ることができるのではないでしょうか。

＊＊＊

今回は、自身の経験と考えを踏まえて、アーキテクチャの価値とそのデザインに関わる活動のアウトラインにふれてみました。次回は、その活動内容にさらに踏み込んでみたいと思います。お楽しみに！