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

現場に残って技術者としての専門性を高めるか、マネジメント職に移ってプロジェクトを引っ張るか。30代半ばになった多くのソフトエンジニアが迫られる選択であり、後者を強制されるのが実情だ。しかし、決して平坦な道ではないが、ITアーキテクトという選択肢もある。

（取材・文／総研スタッフ　高橋マサシ）　作成日:06.10.11

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

　ITアーキテクトをひと口に言えば、「顧客のビジネス的な要求を、情報システム化された要件としてまとめ、ITのアーキテクチャを設計する人」となる。システム構築の全体的な設計を行い、その成果物に対して責任をもつエンジニアだ。この職種が生まれた背景にはIT産業の変遷があると榊原氏は語る。
「1990年代初めからC/Sとオープン系技術が主流となり、システムを構築するための製品と技術の組み合わせが多様化・複雑化してきました。それまでの単一的な製品や技術で構築されたメインフレームと異なり、これらの要素を最適化しながら全体設計をする人材が求められたわけです。システムの複雑度が増し、高い品質と成果物が要求され、短納期が進む現在では、ITアーキテクトの重要性はさらに高まっています」
　ただ、榊原氏はITアーキテクトを「SEの上位職種ではない」と語る。ITアーキテクトもPMも技術のスペシャリストもそれぞれ専門職であり、上下関係はないという意味だ。

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

　ただ、ほとんどの企業で「コンピュータによる業務の省力化」は既に終わっている。昨今のITは、人手の事務処理をコンピュータ化する段階を過ぎ、より戦略的に企業のビジネスを支える仕組みとなっている。そのため、別々の思想や目的で設計されたさまざまなシステムを統合し、アーキテクチャを設計して全体的な最適化を行うことも、ITアーキテクトの主な仕事となる。
「仕事は主にアーキテクチャをモデリング、抽象化するところから始まります。そして具体的な設計に入り、最終的には実装へとつなげていきます。また、顧客企業のCIOと将来のビジョンについて話したり、設計内容に関する交渉をしたり、開発現場のエンジニアに対しては直接指揮をするという、職務範囲の広い仕事でもあります」

　システム全体を理解するには広範囲の技術知識が必要になりそうだが、ソフトエンジニアは専門特化した業務に携わることが多い。すべてを網羅したゼネラリストは実は少ない。
「ITアーキテクトも規模が大きくなればネットワーク、アプリケーション、インフラなどの専門に分かれます（下図）。データベースに関しては人に負けないがBPMには自信がないという人もいるわけです。また、いわばオーケストラの指揮者ですから、各パートの音色や音域などがわかればよく、すべての楽器を演奏できなくてかまいません。ただ、何らかの楽器が得意でなければタクトは振れませんね。それぞれの得意分野があり、経験を積んだうえで、暗黙知でプロジェクトに対応しているのです」

　ほかのソフト系職種になじみが薄いのが「モデリング」という仕事だ。目的であるビジネス的な成果を考えて、システム開発にかかわる業務の構造やプロセスを、人的・技術的要素や各種データを入れて記述すること。榊原氏も「アーキテクチャをモデリングする能力はかなり必要」と語るが、プロジェクトごとに異なるモデルを生み出すトレーニングはどうしたらよいのか。
「書籍などで勉強する方法もありますが、何より実装の経験に基づくもの。それから顧客とのコミュニケーション能力。口がうまいのではなく、資料の作成や内容の図化などを含めて、状況に応じた論理的な説明ができる力です」
　こうしたITアーキテクトという仕事の醍醐味は、設計のポリシーを自分で決められることだそうだ。
「自分の考えを、ある意味チームに対して押し通すことができる。その分の責任は重いのですが、エンジニアとしては非常に面白い仕事」

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

　ITアーキテクトはどの段階からシステム開発に加わるのか。顧客の要求がある程度の形になっていればコンサルタントから内容を聞き、評価や分析から入って設計を行う。ただし具体的でない場合、特に大きな案件では、企画段階から参加する場合も多いようだ。
「最初は大まかな要求から始まります。例えば『うちのすべてのお客さんの半年後のニーズを予測せよ』などですが、このままでは非現実的な要求ですので、この場合なら過去の受発注のデータから購買行動を分析するなど、結果としてどうしたいかをITとビジネスの双方を踏まえて具現化していきます。こうした会話から、経営課題と技術的な課題を擦り合わせていくわけです。図面も何もない段階なので、ITシステム化のフィジビリティに関しては、エンジニアでないと直感的な『当たり』を付けるのは難しいのです」
　ただ、ここまでできるのはトップクラスで、一般的にはコンサルタントと協業して、顧客の要求を確定させるケースが多い。そしてモデリングを行い、システム設計へと落としていく。

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

　顧客企業の業種や分野、システム化する業務内容、プロジェクトの規模などにより、開発内容は千差万別だ。設計する期間にも大きな開きが出てくる。
「最低で1週間、長くて1年といったところでしょうか。1年も掛かるのかと感じるでしょうが、これは設計と同時に実装の検証をしているからです（上図）。この設計で性能は出るのか、描いた設計図どおりのコンポーネントは実装できるのか、その実装に必要なスキルをもつメンバーはそろうのか、開発ツールは購入するのか自前での開発なのかなど、仮説の実現性を確認しています」
　こうして設計ができ上がると開発チームをアサインし、開発現場に指導や支援を行い、顧客やPMと打ち合わせを重ねながらプロジェクトを進めていく。
「PMが納期や進捗を考えるプロジェクト管理の責任者なら、ITアーキテクトはシステムの構造と品質を保証する技術の最終責任者です。システムの隅々まで知らないと開発部隊をサポートできませんから、マネジメント的な職種からはまずなれないと思います。ベースとなるのは技術力と構想力です」

　ただ、技術力だけでITアーキテクトにはなれない。この職種を目指す人には「いつまでもプログラミングを続けたい」といった技術好きが多いそうだが、問題点もある。
「選ぶ技術やデザイン的な美しさにこだわるあまり、顧客や消費者の立場を忘れ、結果的に不具合なシステムになることが多いのです。目的はあくまでお客さんの問題解決。そのためにITを駆使してシステムを構想するという意識が欠かせません」
　また、現場の開発者を技術的に引っ張り、進行管理面では論理的にPMと戦い、顧客にはヒアリングや提案を行う仕事。羽生田氏はコミュニケーション能力の必要性を説く。
「プログラマの時代から日々の仕事で学べばいいので、難しいことはないと思います。いわば社会人の常識ですから、最初はメンバーときちんと話して、徐々にお客さんとの接し方を覚えていく。しっかりした技術の基盤があり、コミュニケーション能力があれば、30代前半でもITアーキテクトになれると思いますよ」

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

　ITアーキテクトに必要なのはまず「現場でもまれた技術力」。だが、漫然とプロジェクトに参加するだけでは必要とするスキルを習得できない。
「要件定義から統合テストやシステムテストまでフルにかかわり、1年程度のプロジェクトに参加する。これを5、6回経験するのが理想ですが、そうした環境になければ、自分からITアーキテクト的な役割を主張して、少しでも経験を積むことです」（榊原氏）
「小さなソフトハウスのほうが、ITアーキテクト的な動きを求められるものです。入社して数年すれば数人のチームのサブリーダーとなり、顧客とも直接対応する。要求を理解して課題を見つけ、ソリューションへとつなげていく。コンポーネント開発だけを行う業務などでは難しいでしょうが、職業意識をもてば得られる経験値が違ってきます」（羽生田氏）

　プログラミングのスキルを高めること、得意分野の業務知識を深めることも、ITアーキテクトへの近道となりそうだ。
「一般的な手続き型言語をしっかり押さえつつ、HaskellやMLなどの関数型など違うタイプの言語を覚えると、視野が広がり発想が柔軟になると思います。有名なモデルや評価されているソースコードを読むのも勉強になります。何より大切なのは新しい技術への好奇心と、上流から下流までの仕事をやり遂げるという強い意志です」（羽生田氏）
「専門的な業務知識は大きな武器です。例えば、銀行の勘定系に詳しければみどりの窓口のシステム開発に、デリバティブの開発経験は保険の新商品システムにといった、経験の応用が利くからです。われわれはこれを『ソリューションエリア』と呼んでいます」（榊原氏）

　このほかにもするべきことは多い。榊原氏は「ITアーキテクトには説明責任が求められるので前後のトレーサビリティが大事」と語り、その理由についても言及する。
「ある方針や作業が変更になったとき、それは前（これからの作業）に向けてどんな影響を与えるのか、後（これまでの作業）のどんな経緯から生じたのかを探ります。ここで必要となるのがドキュメントなのですが、『なぜ必要か』を考えず『言われたからつくっている』という若い人が多い。それでは伸びませんし、逆にこうした経験の蓄積がモデリングにもつながります」
　羽生田氏は「直接的な指導を受けるチャンスは開拓できる」という。
「できるITアーキテクトになりたいのなら、本を読むだけでは無理でしょう。先輩のITアーキテクトから直接コーチングを受けるのが効果的。身近にいない場合はそうしたコミュニティやアーキテクチャについての勉強会に出る方法もあります」
　純粋に技術志向で、より大きなプロジェクトで腕を振るいたいエンジニアなら、ITアーキテクトという選択を真剣に考えてはどうだろうか。

あなたを求める企業がある！

まずはリクナビNEXTの「スカウト」でチャンスを掴もう！

高橋マサシ(総研スタッフ)からメッセージ

ITアーキテクトという職種には以前から興味がありました。私は「採用天気予報」という記事を担当していますが、話をうかがうリクルートエージェントの方が1年ほど前から、「ITアーキテクトを欲しがる企業さんが増えているんだけど、転職市場にはほとんどいない。まさにこれからの職種だね」と繰り返していたからです。ITの高度化に伴ってますます注目される職種だと思います。