図1 さまざまな階層に存在する「アーキテクチャ」はピラミッドにたとえられる
図1 さまざまな階層に存在する「アーキテクチャ」はピラミッドにたとえられる
[画像のクリックで拡大表示]

「ITアーキテクト」という仕事の存在感が増している。要件と制約の全体を理解してシステムの構造をデザインし、最適な技術・製品を組み合わせる--。このようなITアーキテクトの職能が、複雑化する一方の情報システムをコントロールするのに必須のものとなりつつあるからだ。しかし、ITアーキテクトの仕事がどんなものかは理解しづらい点があるのも事実である。なぜITアーキテクトという人材が必要なのか。ITアーキテクトに必要なスキルは。一般のITエンジニアがITアーキテクトにならってスキルを高めるにはどうすればよいのか。以下では3回にわたってこれらの疑問に答えていく。

 最近では,日本でも「アーキテクト」という肩書きを持ったITエンジニアに出会う機会が徐々に増えてきた。IT業界で最も有名なアーキテクトは,米マイクロソフトのビル・ゲイツ氏だろう。CEO(最高経営責任者)を辞めて,会長兼チーフ・ソフトウエア・アーキテクトに就任した時には,ちょっとした話題になった。

 こうしたエピソードも手伝って,IT業界におけるアーキテクト,つまり「ITアーキテクト」という存在の認知度は少しずつ高まっている。「ITスキル標準」において,ITエンジニアの職種の一つとしてITアーキテクトが規定されたことも,その背景にある。

 だが,そもそもITアーキテクトという人材がなぜ必要なのか。ITアーキテクトはどんなスキルを持ち,どんな仕事をするのか。一般のITエンジニアがそのようなスキルを身に付けるには,どうすればよいのか。日本のIT業界はもとより,ITエンジニア自身にとって重要なこれらの問題を,以下で解説していく。

広がるアーキテクチャの概念

 ITアーキテクトの必要性を語るには,まずアーキテクチャそのものの広がりや,アーキテクチャに対する認識の変化に触れなければならない。

 まず図1[拡大表示]を見て頂きたい。企業情報システムは様々な階層から構成されており,階層ごとにアーキテクチャが存在することは読者もご存知だろう。例えばこの図の最下層にある,プロセサやメモリー(キャッシュや磁気ディスクを含む)などのアーキテクチャは,上位にあるハードウエア・アーキテクチャの要素を表す。

 同様に下から2番目の層は,システム・アーキテクチャの要素だ。大半のITエンジニアにとって馴染みの深い,情報システムのプラットフォームを構成するアーキテクチャである。ネットワークの構成,OSやミドルウエアの選択,クライアントとサーバーの配置,Webコンピューティング・モデルの実現,といったことは,この層のアーキテクチャをデザインすることに相当する。

 この図の上の階層ほど抽象度が高く,新しい概念のアーキテクチャになる。

 例えば,アプリケーション・アーキテクチャとは何だろうか。これについて具体的なイメージを持ち,それを他人に説明できるITエンジニアはどれくらい存在するだろうか。

 わずか10年ほど前までは,このアーキテクチャを明確に意識し,作り込む必要はなかった。アプリケーションは個別に独立して存在しており,相互連携を考慮しなくてもよかったからである。

 しかし今は違う。人事・会計などの基幹系システムや,SCM(サプライチェーン・マネジメント)にかかわるシステムなど,複数のアプリケーションを業務の必要性に応じてスムーズに連携させなければならない。必然的に,きちんとしたアプリケーション・アーキテクチャをデザインすることが必要になる。

 最上位概念の「エンタープライズ・アーキテクチャ(EA)」も同様だろう。EAはビジネス(業務)からテクノロジまでの全体を包含したアーキテクチャだ。政府の取り組みの報道などを通じて少しずつ認知されるようになってきたが,まだ多くの人がその本質を理解していないのではないか。

技術進歩やニーズ変化が契機

 より抽象度が高いアーキテクチャが重要視されるようになった要因の1つは,何と言っても情報技術の進化,特にオープン化の進展とインターネットの普及である。メインフレーム全盛の時代と違い,今では異なるベンダーの多様な技術・製品を組み合わせてシステムを構築することが当たり前。インターネット自体,膨大な標準技術の組み合わせである。Webサービスなど,インターネットを前提とした新しい応用技術も同様だ。

 情報システムと企業経営が密接にかかわるようになったことも,大きな要因である。1990年以前の情報システムは,特定のITベンダーに依存して構築することが多く,その方法も手組み(スクラッチ開発)しかなかった。たとえ構築に時間がかかっても,きちんと動きさえすれば良かった。

 ところが現在は,ビジネスの変化に合わせて柔軟に変更でき,しかも止まらない情報システムを,早く安く構築することが求められている。アーキテクチャを階層化して定義し,各階層間のインタフェースを標準化することで,ある階層の変化を他の階層から分離でき,変化に強い情報システムを構築することが可能になる。つまりアーキテクチャがなければ変化に素早く対応できる,信頼性の高いシステムの構築は困難だ。

技術を統合する力が問われる

 言い換えれば,システムを構築して目的通りの機能や性能を実現するには,どんなソフトウエアやハードウエアを,どんなインタフェースを使って組み合わせるのか,といった見極めが非常に重要になる。しかも単一の情報システムを,うまく構築できるだけでは不十分。ほかのシステムとの連携や,近い将来に登場する有望な技術の検討,今後の拡張や機能変更をも考慮する必要があるのだ。

 さらに重要なのは,特定の階層(例えばネットワーク・アーキテクチャ)を担当する開発チーム(ITエンジニア)でも,ほかの階層をしっかりと認識しなければならない,ということだ。「階層構造をとるのは,階層同士を明確に分離するためではなかったのか?」という見方があるかも知れないが,それは正しくない。

 単純な話,バッチ処理を得意とするOSを,エンドユーザーが使うパソコンに搭載することはあり得ない。このことから推察できるように,「下位階層のアーキテクチャは,上位階層のアーキテクチャに支配される」。つまり,下位の階層になるほど上位の階層と無関係には存在できないのだ。

アーキテクト不在の日本

 ここまで述べてきたことを理解し,システム全体のアーキテクチャをデザインできる人材が,いま強く求められている。

 しかし残念なことに,日本ではITエンジニアに対し,システム・アーキテクチャに関する教育が,一部を除き行われてこなかった。1990年代初頭から海外製品への依存度を急速に高めた日本のIT業界は,リスクの高いモノ作りをできるだけ回避する一方で,新しい技術の本質を真摯に学び取るという意識に欠けていた。極論すれば,「海外発の技術・製品の使い方」の教育に重点を置いてきた。

 日本のIT業界に広がっている多重下請け構造が,この問題に拍車をかけた。ユーザー企業と契約したインテグレータは,開発案件の一部を切り出して,1次下請け,2次下請けへと丸投げする。個々のエンジニアに,システム・アーキテクチャを教育する必然性がないのは当然だろう。

 長年,ITエンジニアの教育に携わってきた筆者自身,反省すべきことは多いが,もはやそれでは済まされない。自らモノを生み出すことを忘れかけた日本のITベンダーにとって,また個々のITエンジニアにとって,高い視点から技術の本質を見極め,的確に組み合わせてユーザーに提示することは,今後ますます重要になる。ITアーキテクトに限らず,“アーキテクチュアル・シンキング(アーキテクトの思考法)”ができる人材が強く求められるのは,そのためである。

宮沢 修二/ラーニング・アーキテクチャ研究所 代表取締役

1983年に情報処理技術者教育センター(現アイテック)の設立に参加。以来,20年にわたってITエンジニアの教育に携わる。政府の「EA」プロジェクトでは,「ITアソシエイト協議会」の委員を務める。2003年8月にラーニング・アーキテクチャ研究所を設立