ITアーキテクトを探して（6）
わたしはビジネス寄りの技術者です

有限会社 トレッフェ
岩崎史絵
2006/1/25

「いまはまだ、ITアーキテクトの厳密な定義はできない」――こう語るのはITSS・ITアーキテクト委員会メンバーである日立製作所 ビジネスソリューション事業部 プラチナコンサルタント 湯浦克彦氏だ。湯浦氏は「ITアーキテクトとはどういう存在であるべきか」を模索しながら、ITアーキテクトが登場した背景を基に、氏個人の考えとして「ITアーキテクトに期待されている役割と能力」を語った。

◆ ITアーキテクトとは何者なのか？

日立製作所 ビジネスソリューション事業部 プラチナコンサルタント 湯浦克彦氏

　「ITアーキテクトとはどういう職種か」と正面切って聞かれたら、正直なところはっきり答えられない、いくつかの人物像と育成法を模索しているところというのが本音です。「わたしは本当にITアーキテクトなのか」と自問自答するときもあるくらい。こうした疑問は、IT業界全般にもあるのではないでしょうか。

　ITアーキテクトを厳密に定義することは難しいのですが、ITアーキテクトが登場した背景には2つの理由があると考えています。

　1つは、マルチベンダ、マルチプロダクトという中で技術が多様化し、プロジェクトマネージャだけでは技術面のフォローがどうしても追いつかないこと。プロジェクトの成果として外形を決めていく役割のほかに、システムの中身の構造を押さえていくという2つの役割が必要になっています。そこで、プロジェクトを技術面から支援する役割としてITアーキテクトの必要性が出てきたのではないかと考えています。

　そしてもう1つは、経営課題の解決という側面があります。そもそもシステム開発は、ある目的を達成するためのもの。目的とは「顧客企業の課題を解決すること」です。かつては人手の省力化や事務効率の向上など、解決したい課題はある程度決まっていましたが、いまは技術の多様化と同じように、課題も多様化しています。例えばEA（Enterprise Architecture）や内部統制、CSR（企業の社会的責任）などのように、経営上の課題にITが深くかかわっています。

　では、こうした経営課題を解決するためにITのデザインはどうあるべきなのか？ どのように統制を取っていくべきなのか？ ITの専門家ではない経営者は、こうした意思決定ができません。そこで、意思決定に必要な技術知識を持ち、基本構想や投資戦略を描き、背中を押す――ITアーキテクトには、こうした役割も求められていると考えています。

◆ 技術力だけがITアーキテクトの要件ではない？

　「ITアーキテクトが何者なのか」という定義についてはいろいろ議論されていますが、個人的にはやや技術指向に寄り過ぎているような気がします。システム開発では「上流・下流」といういい方をしますが、そこでいうと「下流」の部分ですね。「モノ作りの責任者として、開発標準やフレームワークを定めたり定着を図ったり、システムのグランドデザインを請け負う人」というイメージが一般的になっていますが、「ITの本質が分かり、経営課題と関連付けて考えられる」という要件も大切だと考えています。

　もしITアーキテクトが下流の部分の責任者だとすると、人数的には多数いると思います。しかし「ITの本質から経営課題をひも解く」となると、それほど多くはありません。“ITと経営の融合”といわれて久しいですが、結局ここに難しさがあると思います。だからこそ、ITアーキテクトという役割に期待が寄せられるのだと思います。

　例えば、先に挙げたEAや内部統制などは、ITそのものの技術的な課題ではありません。でもそこには、「ITを使って社内の仕組みを統制する」「ITそのものを統制する」という形で、因果関係があります。その因果関係を理解し、基本的な構造を設計したり、適切な投資計画を立てられる人材がどれくらいいるでしょうか。

　もちろん、こうした役割は本来ならばCIO（Chief Information Officer）が担うべきです。しかし日本企業の場合、欧米と比べてITの専門知識や設計構想力はIT業界に偏（かたよ）っています。IT業界に従事する人間の半分くらいを一般企業に移管したら、状況はもっと変わると思いますが（笑）。ただ現実がそうでない以上、ベンダが果たすべき役割は大変重要であることを認識しないといけません。

　また「ITアーキテクトはもっと上流に踏み込むべき」というと、経営コンサルタントのような役割と混同しがちですが、経営コンサルタントとは少し違います。例えばわたしが所属しているビジネスソリューション事業部の場合、最上流といわれる経営課題のコンサルティングをすることも多いのですが、中にはIT化まで至らないケースもあります。ITアーキテクトの場合、経営課題がITに落ちてきたときに、その基本構造や投資計画、戦略立案をつかさどるという形ですね。

◆ ITアーキテクトが持つべきEAの思想

　いま、ITアーキテクトが持つべき知識の1つにEAがあると考えています。EAとは経営戦略から企業の構造、ビジネスの構造、そしてIT構造へと落とし込み、最適なIT戦略を描くという考え方です。

　先に述べたとおり、システムはより良い企業活動のために開発するので、その企業の経営戦略やビジネス構造を理解していないと最適なアーキテクチャは描けません。例えばSOA（Service Oriented Architecture）という用語だけを駆使してアーキテクチャを提案しても、顧客企業は底の浅さをすぐ見抜いてしまうでしょう。「何を達成するか」という“何（What）”の思想がないとダメなのです。ITアーキテクトの認定基準の1つとして「いかに最新技術を適用したか」を見よう、という意見も聞かれますが、果たしてそれが妥当なのか、非常に疑問に思います。顧客企業が達成したい課題に対し、最新技術でないと実現できないのならば話は別ですが、枯れた技術でも同じパフォーマンスと効果が得られるなら、後者を適用した方がよっぽどいい。

　いままで、達成すべきWhatは顧客先任せでしたが、それこそコンサルティングファームなどと連携し、EAをうまく実現できるように顧客企業と足並みをそろえる必要があります。そうでないと、IT戦略に優れたグローバル企業と競争できませんから。ITアーキテクトには、EAをIT側から実現するために基本構想を練る役割が求められます。

　ただしそうはいっても、EAの標準手法や手順にのっとって設計すれば成功するわけではありません。企業の構造、ビジネスの構造、ITの構造を可視化するには、相応の技術力が必要ですし、そこからどのような戦略を描いていけばいいかは、技術力のほかに経験も必要になるでしょう。ただ「いわれた要件を設計する」だけでなく、経営戦略や中・長期的な展望、技術トレンドと併せて戦略を立案していく姿勢が重要です。

◆ ITアーキテクトのキャリアパスは

　そこでITアーキテクトのキャリアパスはどういうものが適切か。実はこれについては、やはりいろいろあって、個人的に「こうだ」という意見はまだ見えていないのです。もちろん、ITSSのITアーキテクト委員会や日立製作所では模索している最中ですので、これはわたし個人の意見として受け取ってください。

　プロジェクトマネージャーなどは、管理職としてのキャリアパスとだぶった形である程度の道筋が描かれています。しかし日立の中にも、技術のトップで尊敬される人が伝統的におりますが、その活躍範囲は現場に閉じている傾向があります。これでは若い技術者が目標を持ちにくい。技術を突き詰めるモチベーションが生まれてきません。腕前や成果を一般化して、日立グループ内や社外に広く流通させるようにしたい。そのためには、ITアーキテクトという資格を設けることも有効かもしれません。“ITアーキテクト”という名称を持つようになって自覚が育つかもしれませんし、モチベーション向上に役立つ可能性もあります。

　ITアーキテクト委員会でも似たようなことが話されていますが、個人的には認定試験に合格すればITアーキテクトを名乗れる、という事象にちょっと違和感がありますね。というのは、ITアーキテクトとは顧客企業からの信用を得て、自分が努力した結果、おのずとなっていくもの、という意識があるからです。試験対策とか、問題集が売られるようになるのが果たしていいのか。まだ分からないので、何ともいえませんが。

　また、文系・理系の区分けで考えると、もっと社会系とか経営系など文系出身者の活躍があってもいいと考えています。いまのところ、社内でアーキテクト的な仕事に従事しているのは理系出身者が多いのですが、経営と技術を両方やっている文系人間も増えてきたので、今後の活躍に期待できそうです。

◆ 「わたしはビジネス寄りの技術者」

　 ちなみに現在のわたしの立ち位置を説明すると、営業コンサルティングな仕事もあるし、プロジェクト内ではプロジェクトマネージャの横に位置して技術支援をするという立場に分かれます。当社の場合、製品を販売する部隊が技術サポートに入るのですが、わたしはそれらを顧客ビジネスの価値に結びつけるガイド的な役割を担っています。個々のプロジェクトを引っ張るのではなく、複数を並行して走らせるケースがほとんどです。それと同時に、技術書の執筆に当たることもあります。

　技術書の著作が多いためか、わたしを純粋な技術畑の人間と思われている方が多いのですが、もともと「ビジネス観点から見た技術」への指向が強いのです。例えばEJBブームのときも、どのように開発するかより、「ビジネス要件をどうモデリングしてEJBに落としていくか」に興味がありました。

　同じように、2000年から興味を持って参加したのがXBRL（eXtensible Business Reporting Language）です。XBRLとはXMLに準拠した財務報告記述の標準化言語で、この策定には日本が大変大きな貢献をしています。将来的には有価証券報告書の記述がXBRLで統一されるようになりますし、そうすると技術者だけでなく会計士も備えておくべき知識になります。標準化団体には会計士の人も参加しており、今後の会計業務の中にどのように生かしていくか、さまざまな論点から検討を進めています。

　ITアーキテクトに必要なのは、こうした最新技術を用いて“何”を実現するか策定する能力。もちろんこれはITアーキテクトに限ったことではなく、ベンダの役割として期待されている事柄でもあります。そうした心構えをベンダ側の人間は持つべきではないでしょうか。

IT Architect 連載記事一覧