外資系企業に勤めた知人によると、日本と米国のITエンジニアに能力差はないという。能力差はないが、違いはある。

　米国のITエンジニアは、新しい技術や製品を見極める際、何よりも「アーキテクチャー」に注目する。アーキテクチャーをつかめば、その技術や製品の本質的な長所や短所が分かるからだ。情報システムでやりたいことが実現できるかどうかは、採用する製品のアーキテクチャーにかかっていると考える。もちろん、機能・コスト・利用実績などを参考にするが、それらはアーキテクチャーを評価した後のことだ。

　一方で日本のITエンジニア、特に企業システムに携わるエンジニアは、利用実績を重視するケースが多く、アーキテクチャーを軽視している印象である。

　例えば、エンタープライズ向けパッケージソフトを導入する際、日本のITエンジニアはフィット＆ギャップ分析をするものの、パッケージソフトの基幹部分にまで手を入れて変えてしまうことがある。米国のITエンジニアに言わせれば、「そんなことをすればアーキテクチャーが崩れてしまう。アーキテクチャーが崩れれば、そのソフトを採用する理由がない」。

　なぜ、こうした違いが生じたのだろうか。いろいろな理由が考えられる。筆者が注目したいのは、日本人の品質へのこだわりである。ある外国人のエンジニアは、「日本以上に品質にこだわる国を知らない」と断言していた。

　顧客に届ける際のシステム品質には妥協を許さない。日本人なら誰もがそう考えるだろう。たとえそのシステムで採用している技術のアーキテクチャーが合わなくても、すでにアーキテクチャーが崩れていても、テストを重ねて品質を磨くので、問題が表に出ることがない。

　その結果、アーキテクチャーはさほど重要ではない、と思われてしまった。結果論にしかすぎないが、品質に妥協を許さない姿勢がアーキテクチャー軽視の風土を育ててしまった側面があるように思う。

　品質を重視する姿勢はすばらしい。その点を変えたほうがいいとは思わない。しかし、それによってアーキテクチャーが軽視されているとしたら、それは問題だ。なぜなら、これからのシステムはアーキテクチャーがますます重要だと思うからだ。

　スマートフォンやタブレットを生かしたシステムを依頼されたとする。おそらく、見本になるシステムはないだろう。自分たちでシステム構成をゼロから組み立てることが必要だ。つまり、アーキテクチャーを考えるということだ。

　同様に、コンシューマー向けにクラウドを活用してスモールスタートのシステムを作るとする。スタート時点の利用者は少なくても将来的に1000万人に使ってほしいと思うなら、どんなシステム構成でもいいというわけにはいかない。クラウドサービスのアーキテクチャーに目を向け、自分たちのやりたいことができるかどうかを見極めなければならない。それはアーキテクチャーをつかむということだ。

　米国のソフトウエア開発の現場では、優れたITエンジニアは優れたITアーキテクトであると考えられている。日本の現場も、ぜひそうなってほしい。