ITアーキテクトに必要な3つの視点ITアーキテクトを探して(7)

ITアーキテクチャが問われるようになった最大の理由は、オープン技術の進展によるところが大きい。そこでITアーキテクトには、整合性をもって種々の技術を組み合わせ、価値ある“ソリューション”を形作る役目が求められる。日本ユニシス ビジネス開発部 テクノロジー&サービス推進室長荢津(おおつ)昌三氏は「“ソリューション”を構成する視点により、ITアーキテクトを3種類に分けることができる」と語る。

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

「ソリューション」を設計するITアーキテクト

 私が最初にこの業界での「アーキテクト」という言葉に接したのは、1990年代前半に米国ユニシス本社に行ったときでした。そこで初めて「チーフ・アーキテクト」という肩書の人間と会ったのです。その人の仕事は、ユニシスの提供する情報システムパッケージ全体のグランドデザインを決めることでした。

ALT 日本ユニシス ビジネス開発部 テクノロジー&サービス推進室長荢津(おおつ)昌三氏

 メインフレームの時代だと、アーキテクチャの重要な部分はハードやOSなどのプラットフォームにビルトインされており、その上にアプリケーションを実装すればソリューションということができました。しかしオープン時代になってプラットフォームも選択肢が増え、C/Sでどのような機能分割をするべきかとか、そのときどきのハードやソフトの特性に合わせてソリューション設計の最適化を考える人間が必要になりました。

 私自身も、こうした米国ユニシスで策定されたアーキテクチャを日本に導入し、日本独自のソリューションを設計する立場に立つことでITアーキテクトの重要性を実感するようになりました。情報システムは、そのライフサイクルにおいて機能追加・変更をしていくにつれ、当初の設計思想はどんどんと崩れ、結果として信頼性や保守性は損なわれたものになってしまいがちです。情報システムを効率的に維持するには、ライフサイクルを意識した構造設計と、それを維持するための開発・保守プロセスが組織に組み込まれていなければなりません。私自身がITアーキテクトとして日本独自のソリューションを設計する立場に立って、特に注意したのは “論理的に、分かりやすく”ということでした。

 具体的にどういうことか。ITアーキテクチャが、お客さまや要求者に分かりやすいと同時に、後続の設計者や開発者にとっても分かりやすいものでなければならないということです。こういう意味でいうと、アーキテクチャのグランドデザインに必要となるのは「システム基盤として分かりやすいこと」「アプリケーション的に分かりやすいこと」「その情報システムを利用するビジネスプロセスとして分かりやすいこと」という3つの視点が必要になります。そこで当社では、ITSSで定義されているITアーキテクトほど専門分野を細かく分けずに、「システム基盤アーキテクト」「アプリケーションアーキテクト」、そして2005年3月からは「ビジネスアーキテクト」という専門分野を設定しました。これは他社にはないと思います。

 先述したとおり、メインフレーム時代はアプリケーションプログラム、そして所与のOSとハードが一体化してソリューションとなっていました。一方オープン環境では、所与だったOSとハードも設計の対象となり、システム基盤という考え方が必要になってきました。そのシステム基盤とアプリケーションが組み合わさることで、ソリューションとなります。

しかし今日では、顧客企業から「ITでこういう新しいビジネスモデルを実践したい」という要望が後を絶ちません。こうしたニーズに応えるとなると、システム基盤とアプリケーションだけではソリューションとはならないのです。そこで当社ではシステム基盤とアプリケーション、それにビジネスプロセスの3つを合わせて“ソリューション”と位置付け、提供する体制を取っていきます。

ビジネスアーキテクトとは

 お客さまの組織や仕組みを理解したうえでビジネスプロセスを実装できて初めてソリューションということができるわけですが、ビジネスプロセスは最終的にお客さまの中に実装されるわけですからお客さまが設計するのが本来の形だと思います。しかし、残念ながらそういうことができる方はお客さまの中にも非常に数が少ないのが現状です。そこでビジネスアーキテクトの出番になります。つまり一言でいうならビジネスアーキテクトとは、「ビジネスプロセスを設計する人」なのです。

 ビジネスアーキテクトがコンサルタントと異なる点は1点。「ビジネスアーキテクトは、ビジネスとITを理解して実プロセスに落とし込む人であること」です。具体的には、コンサルタントは経営課題を明らかにしてソリューションの枠組みを決める人ですが、実際に実プロセスに落とし込むときには、情報システムのデータやプロセスの流れを理解しなければなりません。それらを理解しビジネスプロセスを可視化しなければ、ERPやCRMなどが典型的だと思うのですが、情報システムを導入しただけでは何の価値も生み出さない。何度もいいますが価値を生み出すプロセスを実装できて初めてソリューションと呼べるのです。

オープン化の進展がITアーキテクトを求めている

 ちなみにITSSのITアーキテクト委員会では「ITアーキテクトそのものの定義が分かりにくいのではないか」という話も出ています。具体的に、どういう局面でどのように活躍するのか、どういう改善が必要かを考えなくてはなりません。私はそのワークグループに入っており、達成の目標だけでなく、スキルについても専門職種ごとに分かりやすく体系化し、「具体的に目指すもの」を作る必要があります。これが業界を挙げた形におけるITアーキテクトの振興につながると考えています。

 いま技術者はたくさんおりますが、下流工程の実装が海外へと流れていることを考えると、ITアーキテクトを増やすことは日本のIT産業の将来にとって重要な使命ではないでしょうか。

 ちょっと話が飛びますが、現在メインフレームの出荷金額は日本ではまだ売り上げの3割くらいありますが、欧米では1割程度といわれています。もちろん単純にメインフレームが悪いというわけではありませんが、メインフレームへの依存が高いと、スピードが必要とされるグローバル競争でどこまで柔軟に変化に対応できるかという問題があります。いまやITを最大限に有効活用することは企業の競争戦略上、大変重要であり、経営環境の変化に合わせて柔軟に対応できる“変化対応力”が情報システムには求められています。

 近い将来、メインフレーム上で情報システムを作っていた技術者の多くがリタイアし、その設計思想やノウハウが引き継がれなくなるとともに、柔軟に対応できる技術者が激減するとしたら、変化対応力がさらに低下することを意味します。

 そのため、今後は国内企業の情報システムのオープン化はさらに加速すると思います。実装工程は海外に移るかもしれませんが、オープン環境でソリューションを提供するとなると、どうしてもITアーキテクトの存在が重要になります。今後はオフショア開発とグランドデザインの国際分業が進むのではないでしょうか。

ITアーキテクト志望者はアセンブラを学べ

 ひところはITバブルでにぎわったこの業界も、いまや典型的な“3K”業界のようにいわれていますから学生からの人気は減っている可能性がありますね。もちろんそうはいっても、ITの可能性を信じているとかプログラミングが好きなどの理由から入ってくる学生は多いと思います。そういう若手エンジニアに、将来的に「これだけの可能性があるよ」と道筋を示してあげなくてはならない。そこでITアーキテクトへのキャリアパスを考える必要があります。

 これはわれわれ自身の反省でもあるのですが、ITアーキテクトへのキャリアパスを用意している企業はほんの少数にすぎません。例えば当社の場合、メインフレームの出荷率低下はダイレクトに事業に響きますので、徐々にサービス事業に移行するようになり、その過程でプロジェクトマネージャの育成に注力してきました。プロジェクトマネージャの仕事は、いうなれば“現場監督”ですから、現場監督が棟梁や作業員を仕切ることで、一応システムは出来上がります。しかしそのシステムの「顧客満足度」ということで見たらどうでしょうか? 本当に顧客企業に価値をもたらすシステムになっているのでしょうか? 顧客企業の価値をもたらす「ソリューション」を設計するのは棟梁たるITアーキテクトなのです。ITアーキテクトはもっと早い段階から業界を挙げて育成するべきだったのではないでしょうか。

 私は日本ユニシスにおいて、3〜4年前からITアーキテクトの育成プログラムの必要性を訴え、積極的に推進してきました。プロジェクトマネージャは、すでにお客さまからその重要さも認識され、ある意味では、この業界に入ってくるエンジニアのキャリアの「ゴール」のような存在ですが、われわれはITアーキテクトを「途中経過でもあり、それ自身がゴールでもある」と位置付けています。ITアーキテクトを経てプロジェクトマネージャやコンサルタントに移る可能性もありますが、優秀なITアーキテクトは優秀なプロジェクトマネージャと同じように価値があるのです。

 ではITアーキテクトを目指すエンジニアが身に付けるべきスキルとして何が必要か。これは本当にいろいろありますが、プログラミング経験は大変重要だと考えています。なおかつ個人的には、若いうちにアセンブラを覚えてもらいたいなと思っています(笑)。

 その理由は、論理的に機能を分割し、モジュールを作るということをハードに近い低い水準で体得できる技術だから。私も昔やっていたのですが、「こう書いたらこう動く」というのが非常に分かりやすい。どのようにしたらコンピュータがどのように動くのか、そのプロトコルがイメージできるかが重要なのです。そういう経験をさせてくれるのに、アセンブラは最適だったと思っています。

 私自身、アセンブラの技術が直接的に役に立っているのかどうかはっきりいえませんが、設計から動作をイメージできるようになったことはいまでも非常に役立っていると信じています。先ほどいったように、ビジネスプロセスとアプリケーションとシステム基盤の中で、どんなアルゴリズムを用いてどのようなデータを処理するのか考えるとき、「構造化する」技術はとても重要。アーキテクチャは誰でも簡単に作れるわけではないので、こうした地道な努力を重ねなくてはなりません。

自社と顧客の損得のバランスを取る

 ちなみに当社の育成プログラムでは、ITアーキテクトにはコミュニケーション能力も重要であると位置付けています。なぜかといえば、お客さまに対する説明責任を果たす必要があるからです。

 基本的にエンジニアとして入社したら、技術知識としてプログラミングなどのソフトウェアエンジニアリングを覚えてもらい、それぞれのスペシャリティを高めていきます。ある分野のスペシャリストになったら、その上位職種としてITアーキテクトを目指していく、こういうプロセスを考えています。年代的にいうと、早ければ30歳くらいから、平均的に35歳くらいに転換点がやって来ます。

 スペシャリストというのは、基本的に「誰かの指示で働く」立場です。ところがITアーキテクトはそういう職種ではありません。いい方は悪いかもしれませんが、スペシャリストの場合、平たくいえば「自分の損得やチームの損得」をバランスして働くレベルです。プロジェクトに対する自分やチームの貢献度がいかに自分へと跳ね返ってくるかを考える。プロジェクトマネージャは「プロジェクト全体とお客さまの損得」をバランスして働く立場ということができるでしょう。

 一方ITアーキテクトは、プロジェクトを超えて「自社とお客さまの将来にわたる損得」のバランスをイメージする能力が必要です。なぜなら自分が提供するソリューションは、お客さまに導入され、運用されて初めて価値を発揮するのであってプロジェクトの終了後にも責任を持つ立場だから。そしてそのお客さまとの成功体験の共有が継続的なビジネス貢献につながります。このバランスを取っていく能力は経験の積み重ねが重要で、少なくとも35歳前後から身に付くのではないかと考えています。

 もちろん、それに見合う処遇も考慮しなくてはなりません。よく比較される建設業の場合、一級建築士や棟梁の立場は確立されていますが、IT業界ではまだそのレベルに達していません。まずはそこのところをITSSやITアーキテクト委員会で定義し、その職種自体の意義を広く知らしめることで、ITアーキテクトの地位向上を目指すことができればと考えています。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ