ITアーキテクトとスーパーSEの違いITアーキテクトを探して(2)

 ITアーキテクトという職種は、その職種をつくり上げてきた先人がいたからこそ、今日存在するものだといえる。ITアーキテクトをつくり上げ、現在第一線のITアーキテクトとして活躍しているエンジニアは、どのような道筋をたどってきたのか。また、今日のITアーキテクトの流行をどのように見ているのか。情報処理推進機構(IPA)ITアーキテクト委員会の主事を務める日本IBM サービス事業 ストラテジー&コンピテンシー IBMディスティングイッシュド・エンジニア ITアーキテクト 榊原彰氏のインタビューをお送りする

» 2005年09月07日 12時00分 公開
[岩崎史絵(トレッフェ),@IT]

ITアーキテクトを目指すきっかけはCASEツールの開発だった

ALT 日本IBM サービス事業 ストラテジー&コンピテンシー IBMディスティングイッシュド・エンジニア ITアーキテクト 榊原彰氏

 私が入社したときには、実はITアーキテクトという職種は存在していませんでした。現在でいうプロジェクトマネージャもITアーキテクトもすべて「システムエンジニア」(SE)という1つの職種でくくられていたのです。システムエンジニアのほか、メインフレームマシンの保守を担当する「カスタマーエンジニア」、それに製品ソフトの開発・保守を担当する「プログラムスペシャリスト」という3つの職種だけでした。

 SEになると、主任SE、課長、マネージャというコースに乗るのが一般的でした。IBMの職種にITアーキテクトが誕生したのは、クライアント/サーバ型システム全盛の1990年代初頭です。そのころはITアーキテクトではなく、「システムズアーキテクト」と呼んでいました。具体的な役割としては、まさに現在のITアーキテクトと同じく、システム全体の設計を担当する職種です。

 もちろん、それまでにも“アーキテクト”に相当する職種はありましたし、プロジェクトの中では普通にシステム全体の設計も行っていました。ただ、メインフレーム時代は1つのベンダの技術で統一されていたため、「異なるベンダのさまざまな技術を組み合わせ、最適化する」というやり方ではありませんでした。この状況が大きく変わったのは、オープン技術が台頭し、クライアント/サーバが登場してからです。IBMは世界的にこの動きが顕著になると考え、いち早くITアーキテクトという職種を規定したわけです。同時期に誕生した職種にはほかに「プロジェクトマネージャ」などがあります。

 ITアーキテクトやプロジェクトマネージャなどが職種として成立したとき、私は入社6〜7年目でした。ちょうど会社の中や仕事の進め方を理解して、「さてこれからどうしよう」と思う時期に当たっていたため、新しい職種ができて非常にうれしかったことを覚えています。ただ、そのころはまだプロジェクトマネージャになるか、ITアーキテクトになるかはっきり定まっていませんでした。

  ITアーキテクトを目指そうと思ったのは、入社して10年目のあるプロジェクトがきっかけです。そこで私はCASEツールを補完するリポジトリシステムの開発に携わりました。リポジトリなので、あらゆる情報を格納するための「情報のメタモデル」を作る必要がありました。いまの言葉でいえば、まさにこの作業に“ハマった”のです。情報のメタモデルとは、つまりその情報全体のアーキテクチャを考えることです。これが非常に面白かった(笑)。そこから徐々に、「ITアーキテクトになりたい」という意思が固まっていったのです。

 とはいえ、誕生したばかりの職種だったため、具体的にどんな役割を担うのか、きちんと理解している人は誰もいませんでした。それこそ、ぼんやりと「システム設計をする人」ということは分かっているものの、どんな専門性を持ってどうすればいいのかは、まだこれから形成していくという段階だったのです。ですから、当時は「ITアーキテクトになるぞ」と周囲に宣言して、自分でそれらしい仕事を見つけてやってみる、といった具合でした。

 現在はIBMのキャリアパスプログラムはずいぶんと整備されてきて、ITSSのキャリアパスプランのベースとしても採用されています。実際、私もIBMのITアーキテクト育成カリキュラムの策定にもかかわっていますし、講師として教育することもあります。ただ、私がITアーキテクトを目指していた当時は、まだそこまで洗練されてはいませんでした。

システム構築の“複雑性”がITアーキテクトの存在を必然としている

 IBMの場合、入社するとまず技術者としての普遍的な専門性を確立するために、研修とOJTによるトレーニングを2〜3年実施します。その後、どの技術分野を極めていくかを決め、そこに向けて各種認定試験が実施されるのですが、プロジェクトマネージャだろうと個々の技術スペシャリストだろうと、ITアーキテクトだろうと、職種に上下はありません。あくまで個々の専門分野を職種として表現しているだけです。

 ITアーキテクトの中には、それこそ“スーパーSE”と呼ばれるような天才肌の方がいらっしゃるかもしれませんが、ITアーキテクトはあくまでシステム全体を設計する人です。SEの上位職種ではありません。これはIBMの認識もそうですし、またITSSのITアーキテクト委員会でも同じ考えです。

 なのになぜ現在、ITアーキテクトがここまで注目されているのか。それは「異なる技術を組み合わせてシステムを開発する」という命題が、厳しく問われているためだと考えています。例えば冒頭に申し上げたように、かつてのシステム設計は単一技術を見ていればよかった。しかし現在はそういうわけにはいきませんし、複雑度が年々増しています。同時に、システムの品質も考えないといけないし、また最適な開発手法を見極めて、適用しなくてはなりません。既存のシステムとどう連携させるかも考慮する必要があります。納期もどんどん短くなっています。つまり技術だけでなく、システム構築にまつわるさまざまな要素が複雑になっており、その複雑性を整理して、統一しなければならないのです。

技術・ビジネスの両面から“設計の優劣”が問われる

 こうした要件を見ていくと、ITアーキテクトは自身の中に核となる分野を確立することが求められます。もちろん複数の技術に精通していることも大切ですが、実際の案件ではさまざまな視点による適切な判断が必要になります。例えば、お客さまのシステムを品質面から検証し、どこにどんな技術を適用すれば最適なのかを判断、決定しなくてはならない。やみくもに技術知識だけがあってもダメなのです。だからこそ、核となる分野が必要なのです。

 ちなみにIBMの場合、ITアーキテクト認定試験では、いままで手掛けた案件の実績や研究活動などすべてを提出し、面接を行います。具体的には、「なぜこういう設計をしたのか」「その設計は、技術的、ビジネス的にどのようなインパクトをもたらすのか」といったことを細かく問われます。つまりどういうプロジェクトをどのように成功に導いたか、その技術的・ビジネス的な貢献度合いが問われるわけです。その中で、「優れた設計とはどういうものか」という知識が社内に蓄積されていく。そのため、ITアーキテクトに認定されるボーダーも年々上がっていきます。これはIBM社内だけの話ではありません。業界的にITアーキテクト像やアーキテクチャのリファレンスモデルが整備されていけば、同じように「ITアーキテクチャに必要なスキルと実績」のボーダーが上がっていくでしょう。

 あと1点、IBM社内の状況をお話ししておきます。現在日本IBMには、私のほかにも(ディスティングイッシュド・エンジニアのレベルにある)ITアーキテクトが6〜7人おり、それぞれが個々の専門分野を生かして、さまざまな活動を行っています。現在、私の仕事は多岐にわたっており、「これがITアーキテクトの仕事だ」と断定するのは非常に難しい状態です。大きくいえば、IBMが抱えている案件の後方支援部隊として、新しい技術を開発したり、プロジェクトマネジメントオフィス(PMO)の中でユーザー企業のシステムを設計したり、ツールを含めた開発方法論を作成したり、フレームワークを推進するなど、仕事内容を1つにまとめられません。本当に「何でも屋」ですね(笑)。

ITアーキテクトが担う役割をきちんとかみしめてほしい

 確かに現在、ITアーキテクトという職種が注目されていることは私自身も実感しています。ただ、この状況に対していくつかの懸念も感じています。

 1つは、数年前に流行したプロジェクトマネージャのように、「何となく格好がいい」とか「上位職種だ」とか「報酬がたくさんもらえる」といった即物的な目標が、「ITアーキテクトになりたい」という目標とすり替わってしまうこと。繰り返しますが、ITアーキテクトはスーパーSEでもなければ、上位職種でもありません。品質、納期、技術、開発手法、ビジネス要件などさまざまな要素を加味し、ユーザー企業のニーズに合ったシステムを設計する人です。一過性の流行でITアーキテクトを目指すようになってもらいたくない。実は自分の適性は、1つの技術を追求することかもしれないし、あるいはプロジェクトマネージャとしてスタッフやスケジュール、コストを管理することに向いているかもしれないのです。ですからメディアの方にも「ITアーキテクトは素晴らしい職種だ」とあおるだけあおって、後から落とすようなことはしてほしくありません。

 そもそもITアーキテクトが増えることで、どんなメリットがあるかを考える方が重要です。私はITアーキテクトが増えると、「全体最適にのっとった統合システムが増える、整合性の取れたシステムが増える」というのが最大のメリットだと考えています。

 もちろんシステムは日々拡張、改善されていくものですから、どのスコープで最適化を図るか判断するのは困難です。でもその1つの指標として、整合性が取れたシステムが構築されることで、将来的な投資コストが下げられるといった効果が期待できます。

 これは「プロジェクトマネージャが増える」ことのメリットを考えても同じだと思います。プロジェクトマネージャという職能が確立され、その人たちが増えることで、健全なプロジェクトサイクルが回るようになる。これは短期効果は望めませんが、やはり長期的な視点で大きなメリットをもたらすことになります。

 これらのメリットは、IT業界だけではなく、ユーザー企業にも還元されます。いままでITプロジェクトは、IT業界の側からだけで論議されていましたが、「全体最適なアーキテクチャ」という観点からすると、ユーザー企業にもITアーキテクトが必要だと思っています。まだまだ数は少ないのが実情ですが、ITアーキテクトが増えることで、IT企業とユーザー企業の結び付きが強まる可能性がある。この未来が実現できるかどうかは、ITアーキテクトの存在にかかっているといえるでしょう。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ