ソニー生命保険が考えるITアーキテクト像

有限会社トレッフェ
岩崎 史絵

2006/4/19

ITアーキテクトの役割は多様

　ユーザー企業から見ると、ITアーキテクトというのは非常に広い範囲の職種にまたがっており、一口に「こういう仕事をしている人がITアーキテクトだ」と言い切るのは難しいのです。例えばプロジェクトマネージャのように、システム開発全体を指揮するのもITアーキテクトですし、またアプリケーションエンジニアのように1つの分野で経験を積んだ者の最終形としてITアーキテクトがあると思います。また、企業のセキュリティ施策を考えたり、また予算を含めてIT化計画を策定するのもITアーキテクトといえます。

ソニー生命保険 経営企画部・業務プロセス改革本部担当 取締役執行役員 常務の嶋岡正充氏

　そういう意味で、ベンダ側とユーザー企業側で「ITアーキテクト」の役割に明確に線引きできるとは思えません。むしろプロジェクトごとに役割が違うのではないでしょうか。いずれにしても計画策定やプロジェクトマネジメントのスキルは必要だと思います。

　ここでいうプロジェクトマネジメントとは、「調整能力」のこと。大体、1つの組織の中でも新しいことを始めてそれを根付かせるというのは大変なことです。そういう役回りを引き受けるのがIT部門であり、中心的な役割を担うのがITアーキテクト。業務のやり方を変え、システムを変え、協力ベンダを含めて関係者を調整し、計画を遂行するなど、いってみれば損な役回りです。そこに対して抵抗なく、しかも全体を調整しながら仕事を進めていけるのがITアーキテクトの資質として重要なのではないでしょうか。

顧客を含めてプロセスを最適化する

　私はもともとプログラマから始まり、ずっと技術畑を歩んできた人間です。ですからITアーキテクトの仕事の基本はやはり技術だと思っています。「この技術を何に役立てられるのか」ということを常に考えてきました。2000年代に入り、要素技術そのものの活用を考えるのではなく、「実装されたサービスをいかに利用するか」という思考が求められるようになりましたが、基本路線としては「技術を使って、いかに企業のサービスや業務を変革できるか」ということが中心となります。

　例えば当社の場合、基本的にシステムアーキテクチャはメインフレームの勘定系が中心となっており、ほとんどの基幹業務プロセスが実装されています。でもこれは通常の金融業務としては極めて普通の形で、例えばある金融機関の窓口応対業務を見ても、その業務だけが独立して切り離されているわけではなく、後ろのバックエンドにまで続いているものです。そういう意味で、業務もシステムもフロント部、バックエンド部、と切り離して考えるのではなく、常に全体最適を考えないといけません。私たちの仕事はまさに、「ある技術やサービスを使い、業務全体がどう変わるか」を考え、最適な形を実装するために動く部隊です。

　こうした意味では、もはやIT部門は、組織内のことだけを考えるのではなく、お客さままで巻き込んだプロセス策定が必要になっていると考えています。例えばインターネットは、もはや顧客チャネルの1つとして定着していますが、そのユーザーインターフェイスを変えるとなると、バックエンドのシステムに影響が出てくる場合もあります。かといって、使いにくいインターフェイスだとお客さまが離れてしまう可能性もある。その両者の間を取って、最適なシステムを設計しなくてはなりません。そうした意味で、今日の技術革新がわれわれの仕事の範囲を広げているのは確かですね。

すべてをベンダ任せにできない

　新しい技術を導入する場合、一般的には「専門のITベンダに任せた方がいい」といわれていますが、個人的な考えではこの意見に疑問があるのです。「果たして、そうかな？」と。

　確かにITベンダには優れた技術ノウハウがありますし、環境も整っているでしょう。しかしそのことと、一企業のビジネスの中でその技術が生かせるかは別物です。

　新しい技術を導入するとはいっても、システムを全部取り替えるわけではありません。周辺には必ず別のシステムがあり、それぞれが相互連携して1つのプロセスを構成しています。その中で、例えばある部分を新規技術に置き換えた場合、どのような影響が出るかを事前に考える必要があります。技術的な負荷分散だけではなく、利用者側にとって便利なものかどうか、ビジネス上どのようなメリット・デメリットがもたらされるのか、あらゆる角度から検討すべきなのです。

　ただ、これは技術知識だけで太刀打ちできるものではないし、業務知識があるからといってできるものでもありません。業務知識があれば、トラブルの際の後始末はうまくなりますが、大切なのは事前にリスクを予知して、それを防ぐこと。つまりITアーキテクトには、調整能力のほか「危機察知能力」が最も大切なのではないかと思います。

　危機察知とはちょっと大げさな言葉かもしれません。が、概して日本人は危機意識が薄い傾向にあります。特にシステム現場では「何とかなるだろう」という楽観主義が多く見られます。また「日本企業には、しっかりしたIT担当者がいない」といわれていますが、これも危機管理の低さが関係あるのではないでしょうか。企業全体のプロセスを監視するのに最適なのはIT部門ですし、現実としてそうした役割を担っています。だとすれば、IT部門を有効活用すべく、企業の中枢に位置付ける必要があると思います。またそうした役割を担うように、ユーザー企業のIT担当者やIT部門も自覚しなくてはなりません。

ITアーキテクトの存在で仕事は変化したか？

　ITアーキテクトの存在で、プロジェクトの進め方や仕事そのものがどのように変わったか。これは判断が難しいですね。「開発工程の実務を握るのはITベンダだ」という意見もありますが、最終的にはその統制をこちら側で担うことが多いのが現状です。というのも、要求を出すのは基本的にユーザーサイドであり、その要求はどんどん膨らんで、変化していくものだからです。

　 われわれがITベンダに求めることは1つ。こちらが出す要求をそぎ落としてもらいたい。しかし実際には、そういうわけにはいかないので、統制はわれわれが行うしかありません。つまり調整力と危機察知能力ですね。これらを駆使して、必要な要求を抽出し、最適なシステム化計画を立てていきます。最終的に「いいシステムを作る」という目的は一致しているはずですが、「どういう技術をどのように適用するのが最もリスクが少なく、最適なのか」ということは、やはりユーザー企業のIT担当者、しかもアーキテクチャ設計を担う人物でないと分かりません。いくら「生保システムの構築経験がある」といっても、やはり当社には当社特有のアプリケーションや業務プロセスがあるからです。そうした意味で、ITプロジェクトの実務はユーザー企業にあるといえるでしょう。

　ちなみに当社のIT担当のほとんどは中途採用で、前職も金融系SEだったり、メーカーのIT担当者だったりとさまざまです。それぞれ背負う文化が違う中で、ソニー生命保険という1つの会社のアーキテクチャを共同で設計し、統制を取っていく。それが当社のITアーキテクトの姿です。

　もしわれわれの仕事に「経験」と「知識」の両方が必要とすれば、いまのエンジニアは概して経験不足の感が否めません。しかしその一方で、PMBOK（Project Management Body of Knowledge）のように、方法論が科学的に整備されてきました。これらの知識を有効活用すれば、経験を補うことができます。

　加えて、私たちはアセンブラ、COBOL、PL/1という限られた世界の中でいろいろな経験をしてきたのですが、いまは水平線状態に技術が広がっています。個々の知識は上がるけど、スキルがなかなか上がらない。2007年問題の原因も、ここにあるのでしょう。だからこそ、いまはITの仕事領域を標準化してルールを決めて、その方法論を普及させていくことが求められているのだと思います。IPAのITSS（ITスキルスタンダード）もその1つではないでしょうか。

　またITSSには、キャリアと役割が明確にされることによって、IT技術者そのものにもっとスポットライトを当てるという効果も期待できます。こうした活動によって、IT技術者やひいてはユーザー企業のITアーキテクトが活性化されることを期待しています。

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）