自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |

第34回　技術の総合責任者“ITアーキテクト”という選択

Tech総研
2006/10/26

近年耳にするようになった肩書き、「ITアーキテクト」。どのような職業でどのような役割を担っているのか、現役ITアーキテクトに聞く。（Tech総研／リクルートの記事を再編集して掲載）

Part1 情報システムをグランドデザインする技術者の仕事

　IPA（情報処理推進機構）は、ITアーキテクトの育成を目的とした「ITアーキテクト委員会」を2003年11月に設置した。メンバー13人の多くは現役のITアーキテクトであり、主査を務める榊原彰氏は1990年代からその職務を行ってきたエンジニアだ。榊原氏にITアーキテクトの実像を聞いた。

■複雑になった製品・技術の最適化設計を行う人

日本IBM 東京基礎研究所 IBMディスティングイッシュド・ エンジニア 榊原彰氏

　ITアーキテクトをひと口にいえば、「顧客のビジネス的な要求を、情報システム化された要件としてまとめ、ITのアーキテクチャを設計する人」となる。システム構築の全体的な設計を行い、その成果物に対して責任を持つエンジニアだ。この職種が生まれた背景にはIT産業の変遷があると榊原氏は語る。

　「1990年代初めからC/S（クライアント／サーバ）とオープン系技術が主流となり、システムを構築するための製品と技術の組み合わせが多様化・複雑化してきました。それまでの単一的な製品や技術で構築されたメインフレームと異なり、これらの要素を最適化しながら全体設計をする人材が求められたわけです。システムの複雑度が増し、高い品質と成果物が要求され、短納期が進む現在では、ITアーキテクトの重要性はさらに高まっています」

　ただ、榊原氏はITアーキテクトを「SEの上位職種ではない」と語る。ITアーキテクトもプロジェクトマネージャも技術のスペシャリストもそれぞれ専門職であり、上下関係はないという意味だ。

■1つの楽器に精通すればオーケストラは指揮できる

　ただ、ほとんどの企業で「コンピュータによる業務の省力化」はすでに終わっている。昨今のITは、人手の事務処理をコンピュータ化する段階を過ぎ、より戦略的に企業のビジネスを支える仕組みとなっている。そのため、別々の思想や目的で設計されたさまざまなシステムを統合し、アーキテクチャを設計して全体的な最適化を行うことも、ITアーキテクトの主な仕事となる。

　「仕事は主にアーキテクチャをモデリング、抽象化するところから始まります。そして具体的な設計に入り、最終的には実装へとつなげていきます。また、顧客企業のCIOと将来のビジョンについて話したり、設計内容に関する交渉をしたり、開発現場のエンジニアに対しては直接指揮をしたりという、職務範囲の広い仕事でもあります」

　システム全体を理解するには広範囲の技術知識が必要になりそうだが、ソフトウェアエンジニアは専門特化した業務に携わることが多い。すべてを網羅したゼネラリストは実は少ない。

　「ITアーキテクトも規模が大きくなればネットワーク、アプリケーション、インフラなどの専門に分かれます（図1）。データベースに関しては人に負けないが、BPMには自信がないという人もいるわけです。また、いわばオーケストラの指揮者ですから、各パートの音色や音域などが分かればよく、すべての楽器を演奏できなくてかまいません。ただ、何らかの楽器が得意でなければタクトは振れませんね。それぞれの得意分野があり、経験を積んだうえで、暗黙知でプロジェクトに対応しているのです」

図1　システム開発の一般的なフローとITアーキテクトの役割（特に大規模案件の場合）*クリックで拡大します

■ITアーキテクトに必須な「モデリング」を行う能力

　ほかのソフトウェア系職種になじみが薄いのが「モデリング」という仕事だ。目的であるビジネス的な成果を考えて、システム開発にかかわる業務の構造やプロセスを、人的・技術的要素や各種データを入れて記述すること。榊原氏も「アーキテクチャをモデリングする能力はかなり必要」と語るが、プロジェクトごとに異なるモデルを生み出すトレーニングはどうしたらよいのか。

　「書籍などで勉強する方法もありますが、何より実装の経験に基づくもの。それから顧客とのコミュニケーション能力を付けること。口がうまいのではなく、資料の作成や内容の図化などを含めて、状況に応じた論理的な説明ができる力です」

　こうしたITアーキテクトという仕事のだいご味は、設計のポリシーを自分で決められることだそうだ。「自分の考えを、ある意味チームに対して押し通すことができる。その分の責任は重いのですが、エンジニアとしては非常に面白い仕事」

Part2 上流から下流まで携わるITアーキテクトの実務

　ITアーキテクトの実際の仕事はどういうものか。Part1の榊原氏と同じくIPAのITアーキテクト委員会の委員である羽生田栄一氏に話を聞いた。経済産業省が2002年に策定したITSS（ITスキル標準）の11職種の中にITアーキテクトは含まれており、これが一般化のきっかけになったと羽生田氏は語る。

■顧客の要求をビジネスとバランスさせてIT化する

豆蔵 取締役会長 羽生田栄一氏

　ITアーキテクトはどの段階からシステム開発に加わるのか。顧客の要求がある程度の形になっていればコンサルタントから内容を聞き、評価や分析から入って設計を行う。ただし具体的でない場合、特に大きな案件では、企画段階から参加する場合も多いようだ。

　「最初は大まかな要求から始まります。例えば『うちのすべてのお客さんの半年後のニーズを予測せよ』などですが、このままでは非現実的な要求ですので、この場合なら過去の受発注のデータから購買行動を分析するなど、結果としてどうしたいかをITとビジネスの双方を踏まえて具現化していきます。こうした会話から、経営課題と技術的な課題を擦り合わせていくわけです。図面も何もない段階なので、ITシステム化のフィジビリティに関しては、エンジニアでないと直感的な『当たり』を付けるのは難しいのです」

　ただ、ここまでできるのはトップクラスで、一般的にはコンサルタントと協業して、顧客の要求を確定させるケースが多い。そしてモデリングを行い、システム設計へと落としていく。

図2　ITアーキテクトの一般的な職務内容

■ITアーキテクトの必要最低条件は高い技術力

　顧客企業の業種や分野、システム化する業務内容、プロジェクトの規模などにより、開発内容は千差万別だ。設計する期間にも大きな開きが出てくる。

　「最低で1週間、長くて1年といったところでしょうか。1年もかかるのかと感じるでしょうが、これは設計と同時に実装の検証をしているからです（図2）。この設計で性能は出るのか、描いた設計図どおりのコンポーネントは実装できるのか、その実装に必要なスキルを持つメンバーはそろうのか、開発ツールは購入するのか自前での開発なのかなど、仮説の実現性を確認しています」

　こうして設計が出来上がると開発チームをアサインし、開発現場に指導や支援を行い、顧客やプロジェクトマネージャと打ち合わせを重ねながらプロジェクトを進めていく。

　「プロジェクトマネージャが納期や進ちょくを考えるプロジェクト管理の責任者なら、ITアーキテクトはシステムの構造と品質を保証する技術の最終責任者です。システムの隅々まで知らないと開発部隊をサポートできませんから、マネジメント的な職種からはまずなれないと思います。ベースとなるのは技術力と構想力です」

■顧客の視点を忘れがちな「技術オタク」はダメ

　ただ、技術力だけでITアーキテクトにはなれない。この職種を目指す人には「いつまでもプログラミングを続けたい」といった技術好きが多いそうだが、問題点もある。

　「選ぶ技術やデザイン的な美しさにこだわるあまり、顧客や消費者の立場を忘れ、結果的に不具合なシステムになることが多いのです。目的はあくまでお客さんの問題解決。そのためにITを駆使してシステムを構想するという意識が欠かせません」

　現場の開発者を技術的に引っ張り、進行管理面では論理的にプロジェクトマネージャと戦い、顧客にはヒアリングや提案を行う仕事である。羽生田氏はコミュニケーション能力の必要性を説く。

　「プログラマの時代から日々の仕事で学べばいいので、難しいことはないと思います。いわば社会人の常識ですから、最初はメンバーときちんと話して、徐々にお客さんとの接し方を覚えていく。しっかりした技術の基盤があり、コミュニケーション能力があれば、30代前半でもITアーキテクトになれると思いますよ」

Part3 SEからITアーキテクトへと進むキャリアプラン

　プログラマやSEからITアーキテクトを目指すには何をしたらよいのか。大学卒業後にソフトハウスか中堅システム開発企業に就職した若手SEを想定し、これから何をすべきかをPart1の榊原氏とPart2の羽生田氏に聞いた。一例として参考にしてほしい。

■プロジェクトの場数を踏んで技術を身に付ける

　ITアーキテクトに必要なのはまず「現場でもまれた技術力」。だが、漫然とプロジェクトに参加するだけでは必要とするスキルを習得できない。

　「要件定義から統合テストやシステムテストまでフルにかかわり、1年程度のプロジェクトに参加する。これを5、6回経験するのが理想ですが、そうした環境になければ、自分からITアーキテクト的な役割を主張して、少しでも経験を積むことです」（榊原氏）

　「小さなソフトハウスの方が、ITアーキテクト的な動きを求められるものです。入社して数年すれば数人のチームのサブリーダーとなり、顧客とも直接対応する。要求を理解して課題を見つけ、ソリューションへとつなげていく。コンポーネント開発だけを行う業務などでは難しいでしょうが、職業意識を持てば得られる経験値が違ってきます」（羽生田氏）

■人にないスキルと専門的な業務知識で幅を広げる

　プログラミングのスキルを高めること、得意分野の業務知識を深めることも、ITアーキテクトへの近道となりそうだ。「一般的な手続き型言語をしっかり押さえつつ、HaskellやMLのような関数型など違うタイプの言語を覚えると、視野が広がり発想が柔軟になると思います。有名なモデルや評価されているソースコードを読むのも勉強になります。何より大切なのは新しい技術への好奇心と、上流から下流までの仕事をやり遂げるという強い意志です」（羽生田氏）

　「専門的な業務知識は大きな武器です。例えば、銀行の勘定系に詳しければみどりの窓口のシステム開発に、デリバティブの開発経験は保険の新商品システムにといった、経験の応用が利くからです。われわれはこれを『ソリューションエリア』と呼んでいます」（榊原氏）

図3　ITアーキテクトを目指すSEのキャリアアップ例（クリックで拡大します）

■業務の内外で自主的に動いてITアーキテクトを目指す

　このほかにもするべきことは多い。榊原氏は「ITアーキテクトには説明責任が求められるので前後のトレーサビリティが大事」と語り、その理由についても言及する。

　「ある方針や作業が変更になったとき、それは前（これからの作業）に向けてどんな影響を与えるのか、後（これまでの作業）のどんな経緯から生じたのかを探ります。ここで必要となるのがドキュメントなのですが、『なぜ必要か』を考えず『いわれたから作っている』という若い人が多い。それでは伸びませんし、逆にこうした経験の蓄積がモデリングにもつながります」

　羽生田氏は「直接的な指導を受けるチャンスは開拓できる」という。「できるITアーキテクトになりたいのなら、本を読むだけでは無理でしょう。先輩のITアーキテクトから直接コーチングを受けるのが効果的。身近にいない場合はそうしたコミュニティやアーキテクチャについての勉強会に出る方法もあります」

　純粋に技術志向で、より大きなプロジェクトで腕を振るいたいエンジニアなら、ITアーキテクトという選択を真剣に考えてはどうだろうか。

☆SEの上位職種ではないが、目標の1つ

記事にあるようにITアーキテクトとは「技術の総合責任者」だ。「責任者」ではあるが、責任を持つのはプロジェクトマネージャのようにプロジェクトの進ちょくではなく、システムの構造や品質に対してだ。高く総合的な技術力を要するが、SEとは異なる。 　重要なのはシステムの構造や品質を考えていくうえで、実ビジネスに適合するかどうかを総合的に判断することだろう。こういう意味ではコンサルタントに近いようにも思えるが、コンサルタントは一般的に理論や説明までが責任範囲であり、ITアーキテクトには成果物となるシステムについての責任が課せられる。 　もしITアーキテクトがいなければこの役割は誰が担うか考えてみると、企業や状況により差異はあると思うが多くはSEではないだろうか。それもスーパーSEと呼ばれるような、優秀で特殊な存在だ。だがITアーキテクトが担うべき役割は特殊なSEに頼るのではなく、企業はきちんと定義して育成し、業務で任命していく必要があるのではないだろうか。 　ITアーキテクトはSEの上位職種ではないというが、SEの経験や感覚は重要だ。SEの技術力に加え、業務のモデリングやシステムを総合的に把握する能力などが必要になる。SEの目指す先の1つと考えてもいいのではないだろうか。 （加山恵美）

この記事は、Tech総研／リクルートの記事を再編集して掲載しています