国のIT基盤を設計するITアーキテクト：ITアーキテクトを探して（8）

ITアーキテクトになったら、できるだけ大規模システムのアーキテクチャ設計にかかわりたい。例えば国のIT基盤、そして参照となるアーキテクチャモデルの策定など。そう思うITアーキテクト志望者は多いだろう。こうした仕事に携わっているITアーキテクトがいる。マイクロソフト　公共インダストリー統括本部　テクノロジーソリューション部のテクニカルアーキテクトである鈴木章太郎氏がその1人だ。

» 2006年03月29日 12時00分 公開
[岩崎史絵（トレッフェ），＠IT]

マイクロソフトでITアーキテクトは何をするか

　マイクロソフト日本法人に「テクニカルアーキテクト」、いわゆる世間一般でいわれているようなITアーキテクト職ができたのは3年前からです。米国ではすでに実績があり、人数も多いのですが、国内では私を含め数名しかおりません。が、今後は少しずつ採用を進め、人数を増やしていきたいと考えています。

ALT マイクロソフト　公共インダストリー統括本部　テクノロジーソリューション部のテクニカルアーキテクトである鈴木章太郎氏

　マイクロソフトの場合、テクニカルアーキテクトはプリセールス部隊の一員となっています。しかしテクニカルアーキテクトの仕事は、営業数値を持たされるわけではなく、主にアウトリーチ的な活動が中心。例えば私のケースでいうと、仕事内容は大きく3つに分類されます。

　第1に、まずプリセールス部隊の一員として、営業SEやパートナー企業が設計したアーキテクチャをレビューしたり、あるいは実際に自分が設計する仕事。特に当社は、パートナーを通じた営業活動が基本となっているので、パートナーに対する技術支援や協力は必須です。

　そこで第2に、パートナー企業や業界アナリスト、大学などでの講演活動があります。これは当社でかかわっている技術標準化の策定動向や、マイクロソフトの具体的なソリューションなどを啓蒙し、さらに技術的に不明な点についてお答えするという活動。関連して書籍の執筆なども行っています。

　第3に、政府系諮問機関への参画、講演、アーキテクチャ策定とレビューなども担当しております。これは公共インダストリー本部としてのアウトリーチ活動の一環でもありますが、官公庁側でも「参照すべきアーキテクチャモデル」や「技術標準」について策定する必要があり、そういった疑問に対する支援の役割も果たしています。現在私が参加しているのは、総務省の電子調達関係の委員会、経済産業省の業務システム最適化計画の参照モデル作成ワーキンググループなど。昨年12月に発表された政府統一基準の仕様についてのレビューも行いました。

　ですので、お客さまのプロジェクトに参画したり、技術検証ばかりを行っているわけではありません。

　もちろんMS技術だけを追えばいいわけでもありません。他社の技術、そして業界全体の技術トレンドを的確につかみ、パートナー企業や政府CIO補佐官の疑問に答え、あらゆるアーキテクチャを設計・レビューする。その中には、当然政府で作成している標準アーキテクチャなども含まれます。これがマイクロソフトの“ITアーキテクト”です。

MSだからこそ「幅広い中立的な知識」が必要

　ご存じのとおり、マイクロソフトは製品ベンダです。だからといって、他社の技術に無関心なわけではありません。むしろ最適なアーキテクチャモデルを作るため、特にJavaの動向や仕様は常にウオッチし続けています。

　特に官公庁市場では、Interoperability（透過性）が重視されます。官公庁のシステムが1ベンダの製品で構成されているはずはなく、そこにはIBMやHPのサーバがあったり、J2EEが動いていたり、ヘテロな環境が前提となっています。だからSOA（Service Oriented Architecture）の考え方は大きなポイントとなっていますし、さらに「Webサービスなどの標準仕様にMS製品はどう対応しているのか」という疑問に応える必要があります。例えばSOAによるデータ連携でいえば、「相互運用性を実現するために、まずXSDを最初に設定し、透過性を高める」といった技術的な特徴を踏まえ、実証実験し、他社の方とも会議を重ねてアーキテクチャの在り方を論じています。そういった意味では、社内に閉じているのではなく、いろいろなIT企業さんと会議をし、参照モデルを作るといった活動が中心ですね。社外とのかかわりがとても多い。

　また中央省庁だけでなく、自治体のIT化計画を考えるうえで、EA（Enterprise Architecture）に基づいた案件支援にもかかわっています。10年以上利用されているシステムを総称して「レガシーシステム」と呼んでいるのですが、このレガシーシステムが多い自治体に対し、EA／SOAに基づくIT化計画、アーキテクチャの設計・レビューを担当することも。当社の場合、米連邦政府の事例も抱えているので、そういった情報も提供しています。最近ではオープンソースソフトウェアが注目されていますが、機能やSLA（Service Level Agreement）でいうとまだ“参考レベル”という感は否めません。そうした検証についても、「マイクロソフトだから」ではなく、他社の方々と意見交換しながら進めていく。そのように全体の整合性を図ってアーキテクチャを設計する。それがマイクロソフトのテクニカルアーキテクトなのです。

好奇心がなければITアーキテクトは無理

　米本社ではテクニカルアーキテクトの数も多く、アーキテクチャレビューが専門だったり、技術検証が専門だったりと、アーキテクトの専門性も高くなっています。が、日本ではまだまだこれからといったところですね。なのでITアーキテクトのキャリアパスについては、これから整備していく必要があると思います。

　ちなみに私自身は、かつてあるSI企業でコンサルタントとプロジェクトマネージャの中間的な仕事をしていました。いまでもその当時に使っていたUNIXやOracleの知識は生きていますし、またそうした他社技術について、中立的に学習・評価・検証することが求められています。繰り返しますが、「マイクロソフトにいるから.NET技術しか追わなくていい」というわけではなく、逆にさまざまな技術にも精通することが必要なのです。ハードやソフトは問いません。なぜならこの業界では、他社製品や古いものも含め、co-existence（共存）を前提としているから。むしろ当社のケースでいえば、より幅広く深い技術知識が求められるといえるでしょう。当然、他社との交流も多くなります。

　こうしたことから、私が「ITアーキテクトに必要な資質」を挙げるとすれば、とにかく好奇心旺盛であることが条件です。逆にいえば、好奇心がないとITアーキテクトは務まりません。

　さらにいえば、コミュニケーション力／調整力、プロジェクトマネジメント能力、UMLやPMBOKといった技法の知識を備えていると、なおいい。特に官公庁でのアーキテクチャモデルの策定では、中立的で幅広い視点が求められます。大変ですが、やりがいのある仕事ですね。

「ITアーキテクトを探して」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ