ITアーキテクトはプロジェクトも設計する：ITアーキテクトを探して（5）

　ITアーキテクトが普及する前から「ITアーキテクト」と名乗り、その普及に尽力している人物がいる。それがドリームメカニズム　代表取締役　平林憲林氏だ。「プロジェクトで信頼される人、それがITアーキテクト」と明確に定義する平林氏が、プロジェクトにおけるITアーキテクトの役割と任務について語った。

技術観点でプロジェクトを統制する

ドリームメカニズム　代表取締役　平林憲林氏

　ITアーキテクトとは、そもそも「開発プロジェクトの技術分野における中心的な存在」と私は考えています。今日のオープン系システムは、さまざまなベンダの製品や技術を組み合わせており、プロジェクトマネージャ1人がすべての技術に精通するのは不可能です。ですからITアーキテクトは技術について広く浅く知っており、さらに特定の技術分野について深い知識を持っていることが求められます。例えば、当社にはJavaアーキテクトがおりますが、Javaだけを知っているのではなく、.NETやほかの開発技術・ツールを検証し、その中で特にJavaの技術知識に秀でているというように教育しています。そしてその知識を生かし、開発標準や手法、ツール、フレームワークを定め、プロジェクト内に定着させていく。それがITアーキテクトです。

　なぜITアーキテクトという職種が注目されるようになったのか。ちょうど2000〜2002年くらいにプロジェクトマネージャのブームがありましたが、その当時は本当に“失敗プロジェクト”が多かったのです。もちろん何をもって失敗と定義するのかといえば、さまざまな解釈があり一概にはいえませんが、プロジェクトそのものを統制するのがとても困難でした。もともとプロジェクトマネージャの基本的な仕事はQCD（Quality・Cost・Delivery：品質・コスト・納期）の管理であり、それに付随してスタッフのモチベーション管理やアフターフォロー、クライアントとの折衝などさまざまな役割を負っています。

　そこでITアーキテクトが何をやるのかといえば、技術的な分野においてシステム全体の構造を設計し、それに基づいた適切な開発技術を決め、開発手法を定義し、その手法で円滑に開発が進められるようにチームを統制する。もちろん、技術的なヘルプデスクも兼ねる。こうすることで、プロジェクトマネージャは1人ですべてを抱え込む必要はなく、QCDの管理に徹底できます。

　今日ではITアーキテクトの範囲も少し拡大し、いわゆるコンサルティング的な役割も担うようになってきました。ちょうど建築の世界で、建築士がその技術知識を生かして建築設計をするような形です。これまでコンサルタントといえば、業務知識や経営知識は持っているけれど技術知識に弱いといわれてきましたが、昨今では技術知識を持ったITアーキテクトがコンサルタントとして活躍する場面も増えています。

頼られる人、それがITアーキテクト

　とはいえ、いまのIT業界では名刺に「ITアーキテクト」という肩書を持つ人はほとんどいません。ではどういう人がITアーキテクトなのかといえば、技術分野で「頼りにされる人」です。プロジェクトの中を見渡してみると、中には必ず「ここをどうすればいいの？」とか「どうしたら効率的に開発できるのか？」と聞かれている人がいます。その人こそがITアーキテクトです。

　こういうと、ITアーキテクトとは「人望がある人」と定義できますが、それこそがまさにITアーキテクトの条件です。そもそも人から技術的な事柄で質問されるということは、その人が組織の中でトップランナーである証拠。加えて人望があるから、いろんな人が寄ってきます。その人を中心に、開発工程が回っていく。だからITアーキテクトなんです。

　エンジニアというのは、スキルシートなど明確な基準を定めたがるので、「ITアーキテクトになるにはどういうスキルセットが必要か」という話題もしばしば登場するのですが、私は「人望」というヒューマン要素が欠かせないと考えています。もちろんヒューマン要素には資質がありますし、技術知識も人間性も問われるとなると「ITアーキテクトになるにはハードルが高過ぎる」と思う人もいるでしょう。特に、昨今ITアーキテクトとしてメディアに登場するエンジニアは、もともと技術についての造詣が深く、とても立派な仕事をしている方々ばかりなのでそう思われることが多いと思います。

　が、いま登場しているITアーキテクトの方は、松・竹・梅でいうとすべて松クラス。これからさまざまなタイプのITアーキテクトが出てきてもいいし、またそうなることがITアーキテクトの振興につながると考えています。

ライン制の職種に疑問を抱き、“ITアーキテクト”に

　私がどういう経緯でITアーキテクトを標ぼうするようになったかをお話ししましょう。私はもともとあるSI会社のエンジニアでネットワーク設計やデータベース開発、Java開発を経験し、その後フリーとして独立しました。

　1999年ごろ、Javaの基幹開発が盛んになり、私の実績からある大手SI会社の基幹システム開発プロジェクトのメンバーに抜てきされたのです。その役割は、ちょうどいまでいうITアーキテクトでした。プロジェクトマネージャやサブマネージャは別におり、私はJavaによる開発責任者ということで、スタッフの面接からチーム編成まですべてを任されました。というのも、当時はまだJava開発の経験を持つエンジニアが少なく、プロジェクトマネージャもサブマネージャもC言語については詳しかったのですが、Javaの経験はあまりなかったのです。

　このような経緯で、私が何人かスタッフを面接したのですが、Javaで基幹システムを開発するにはやはりスキル的に懸念がありました。そこで成果物の品質を一定に保つように、開発手順を定め、要件分析の仕方から実装に落とし込むまでの流れをドキュメントに落としました。同時にチーム分けをし、各チームを管理していきました。

　プロジェクト自体は1年間、ピーク時には30人が稼働しましたが、最初の2〜3カ月は見積もりばかりやっていましたよ（笑）。で、作業を割り出して、開発標準を定め、チームを編成して開発手法を定着させていく。一見プロジェクトマネージャの仕事のようですが、これを技術的な分野で担当するわけです。

　そのころ、米国の文献などを見ていたらマーチン・ファウラーなどが「Javaアーキテクト」として登場し、こういう職業もあるんだなと思いました。日本だと、プログラマー・システムエンジニア・プロジェクトマネージャという職制が一般的で、これは工場でいう作業員・主任・工場長というラインに近い。でも米国では、特定の分野のプロフェッショナルがいて、その知識やノウハウをプロジェクトに還元する仕組みも職制も整っていたんです。

　そこで私も、2000年ごろから外部の人に対して「自分はITアーキテクトだ」と標ぼうするようになりました。誰かが言い出さないと、認知されませんから。そのうち賛同する方が現れ、業界でITアーキテクトを育てる「ITアーキテクト塾」というものを開設しようか、という話になったんです。それが2002年ごろでした。そのうち、アットマーク・アイティで「ITアーキテクトフォーラム」が立ち上が り、この状況を追い風として、“ITアーキテクト”という職種の普及活動に努めて今日に至っているというわけです（笑）。

まずは何でも経験してみよう

　「ITアーキテクトになるにはどうすればいいか」と聞かれることも多々あります。月並みですが、私はいつも「いろいろな経験をしよう」といっているんですよ。例えば私の場合、エンジニアになる前は人形劇団で働いていたこともありますし、建築業界で橋梁の設計をやっていたこともあります。よく「どうしてシステム全体を設計できるのか」といわれるのですが、橋梁の設計もシステムの設計もほとんど同じなんです。要件があって、制約条件があって、図面を引いていく。そういう素地があったからシステム設計にもすんなり入っていけました。人をまとめるということも、いろいろな経験があってこそです。

　もう1つは「お客さまの情報価値を最大化しよう」ということです。私たちの仕事は、お客さまの情報価値をシステムによって向上させることですよね。それが達成されたらお客さまは喜ぶし、すると「必要とされる人間」になれます。先ほど申し上げたとおり、ITアーキテクトには人望が必要ですので、お客さまからの信頼を勝ち取るということは非常に重要です。そう考えると、ITアーキテクトという職種は本当に奥が深く、面白い仕事だといえますね。

ITアーキテクトには向上心と好奇心、そしてコスト感覚が必要だ――ドリームメカニズム気鋭のITアーキテクトが語る

◎ 技術部 部長 吉田文雄氏

　私は卒業後、証券会社に勤務していたのでもともとエンジニアではないんです。その後この業界に入ってCOBOL系のプログラマーとしてスタートし、2年目以降はオープン系のプログラマーとして従事しました。Javaを始めたのは4年前からですが、いまはプロジェクト内で技術サポート的な役割やシステム設計、開発標準の定義・定着などを行っています。

　仕事では絶えずシステムの全体像を見て、性能的な矛盾がないか、全体最適にのっとって効率的な設計になっているかを考えています。なぜ全体像の把握ができるかといえば、プログラマーとしてスタートしたので、性能単位で物事を考えるのに慣れているからです。全体像の把握には、プログラマーとしての経験が左右すると痛感しますね。逆にそれができなければ、非常に苦労にすると思います。また証券会社で働いていたおかげで、金融系のシステムなどは、要件を聞いて大まかな像を描くこともできます。技術や業務に向上心を持ち、何でも学んでいこうという好奇心があれば、ITアーキテクトは本当に面白いと思いますよ。

◎ 開発生産部　SDSチーム　上田誠治氏

　私の場合、大学・大学院と宇宙物理学を専攻し、シミュレーションシステムをJavaで開発していました。エンタープライズ系のシステム開発に携わるようになったのは、卒業後ドリームメカニズムに就職してからです。

　仕事内容は、ハードやソフトのリソース配分などが中心です。いまのシステムは独立しているものはほとんどなく、必ず別のシステムとつながっているので、どれか1つをバージョンアップするとほかのシステムにも影響があります。そういう周辺環境のバージョンアップの技術調査も行っています。

　私自身、まだまだITアーキテクトとして勉強していかなくてはならないことがたくさんありますが、1ついえるのは「全体最適」と「コスト意識」をもって仕事ができるかが重要だということです。例えば一見コストが掛かる作業でも、全体の中で見たら後工程でその分を圧縮できるかもしれないし、逆にその時点でコストや工数を削減できても、後になって負荷が増大することもあります。開発するときに、ちょっと視点を変えて「全体の中で、この工数やコストはどうだろう？」と分析してみることで、ITアーキテクトの資質も培われると思います。