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

今回のテーマも再びITアーキテクチャに原点回帰し、未だに、ふんわりとした“ITアーキテクト”なるものの定義について、私なりに探求してみたい。実際、ITアーキテクチャを必要とする領域は人工的なシステム全般に渡って存在するし、このアーキテクチャを設計する“ITアーキテクト”の役割は広範囲に及ぶ。

巷では広い世界のどこのアーキテクチャのことを言っているのか？という文脈が曖昧であるために、ITアーキクトに関する議論が嚙み合わないことがしばしば見受けられる。最初に、ITアーキテクチャの専門性分類として代表的な２つをご紹介したい。まずは図1を参照していただきたい。

上段は本ブログシリーズでもお馴染みのEAにおける分類である。業務部品→データ部品→プロセス部品→インフラへとビジネスドリブンにIT要件へ落とし込んで行く過程に沿って層別に専門性が分割されている。

下段はIPA（情報処理推進機構）によるITSS-v2における専門性の分類である。こちらは情報システム内の各アプリケーションが中心にあり、それに横串を通す形で、共通フレームワークが走り、その下をインフラ基盤が支えるといった建て付けである。さらに、他の情報システムとの間の相互接続性という大きな横串が加味されている。

さて、両者はアプリケーションアーキテクチャ、インフラ（EAではテクニカル・・・）アーキテクチャが存在する点では似通っているが、目線がどこにあるかという点で異なる。EAは文字通りエンタープライズ（ビジネス）にあり、各コンピュータシステムを超えた”企業システム”のあり方に主眼を置いたトップダウンモデルである。

一方のIPAのモデルはどうであろうか。中心となるアプリケーションアーキテクチャにおいて、ビジネスドリブンに業務課題をITで解決するという点では同様である。しかし、フレームワークやインフラが横串を通しているものの、複数アプリケーションが独立して描かれている点や、他システムとの相互接続性の後付け感から見て、主眼をコンピュータシステムの作り手に置いたボトムアツプモデルである（そもそもITSSがIT人材のスキル標準であるので当然と言えば当然であるが）。

このように両者は、共通点は多いものの出発点が異なる。EAが最上段の自社の企業モデルが起点であるのに対して、IPAは“顧客のビジネス戦略”が起点にある。よって、それぞれのITアーキテクトの専門性分類に基づいて、これを設計するITアーキテクトなる人材のスキルマップも、個々の要素技術は要求分析やモデリングスキル等かなりの部分でオーバーラップしているが、その重心が若干異なっている。

図2に、EA、IPAそれぞれのアーキテクトの専門性が向かう方向を⇒で表し、ビジネスとITのどちら側の要素が濃いかについて色の濃淡で表した。

繰り返しになるが、ITアーキテクトのカバー範囲はたいへん広い。とても一人の人間が全てをカバーする事は、現代のレオナルドダビンチと言えるような万能人でなければ、不可能に近いだろう。そこで私は、ビジネスからITソリューションを考える事を生業とする人間と、IT-Seedsをビジネスの局面に活用する事を得意とする人間がコラボレーションすることでお互いを補完し、ベストなITアーキテクチャが描けるのではないかと考える。

具体的な人物像をイメージしてみよう。EAの方はビジネスを熟知しているユーザ企業情報システム部門のアーキテクトで、IPAの方はITベンダー側のアーキテクトとなる。そしてこの似通っているが生い立ちの違う2種類のアーキテクトを敢えて命名すれば、前者は”エンタープライズITアーキテクト”、後者は”エンジニアリングITアーキテクト”という具合になる。ちなみに、30年以上ユーザ企業に在籍した私は前者であるが、友人は後者が圧倒的に多い。

ここまで書き進み、ふと、昨年秋ザックマンが来日した際、「EAはオントロジー（存在論）でありメソドロジー（方法論）ではない」としきりに言っていた事を思い出した。両者の起点が違うという違和感の源泉がどこにあるかはこれでさらに明白になった。

さらに、当時のメモを引っ張り出してみる（正確にはFBに呟いた昨年の履歴を検索）～～～とそこには、こうも書かれていた。「Ontology or Methodology ⇒ ✕。Ontology and Methodology ⇒ 〇」つまり両者は二者択一ではなく共存するものということ。どちらか一方だけでもダメということ。まさに温故知新である。

話を現実に戻そう。企業情報システムのアーキテクチャ設計の現場においては、EA的観点での普遍性を重視するとともに、IPA的な具体的物作りの方法論も同時に必要である。システム構築プロジェクトにおける最強のアーキテクト軍団は、間違いなく両者の混成チームという事になろう。日本におけるユーザ企業のシステム開発の現状（構築をSIerへアウトソーシングせざるを得ないという）を前提にすれば、両者のコラボレーションが必須である。

そして、アーキテクトの養成においては、それぞれの本丸を磨くことは当然として、ユーザ企業アーキテクトはよりIT寄りの知識を、ベンダー側アーキテクトはよりビジネス寄りの知識を増やすことが良い。なぜなら、分業を常とする開発プロジェクトにおいて、個々の知識のオーバーラップはプラスに働くので。