さまざまな困難をどう乗り切ればいいのか
ITエンジニアとしての道を究めるには

第5回　ITアーキテクトの道

萩本順三（豆蔵取締役）
2004/3/19

　今回は、多くの企業が求め、多くの技術者があこがれるITアーキテクトについてお話ししたい。

　ITアーキテクトという職種は、業界でその職種に対する意味が広く認知されているものではない。また、どのような技能やロールに対して名付けられているのかもあいまいな状況なので、本来「職種」と呼ぶのに少々ためらいがある。では、「技能」なのか。まあ、そのようなことは後回しにして、もっと重要なことから解説しよう。

　筆者はITアーキテクトを現在のソフトウェア開発において必要不可欠なものだと考えている。

　そこで、ここではITアーキテクトになり得る人材の特徴を分析し、なぜそのような人材が現代のソフトウェア開発環境で必要とされているのか、その技能とはいったいどのようなものなのかを明らかにしたい。それにより、その技能を持つ職種の定義を少しでも明らかにしたい。最後に、技能はどのようにすれば身に付けられるのかについて話すことで、読者が目指す「ITアーキテクトの道」への案内ができれば幸いである。

■アーキテクチャとは

　まずは、アーキテクトが設計の対象とする仕事が何かを考えよう。アーキテクトという名前からして、対象は「アーキテクチャ」なのは想像がつく。では、本業界におけるアーキテクチャとは何か。さまざまな定義があると思うが、筆者の定義は次のようなものだ。

・アーキテクチャとは対象となるソフトウェアシステムにおいて、ハードウェアを含めたシステム構成、モジュール構成を表したもの。

　そしてITアーキテクトのメインターゲットとなる「ソフトウェア・アーキテクチャ」の定義は次のとおりである。

・ソフトウェア・アーキテクチャとは対象となるソフトウェアシステムの設計課題を反映したソフトウェアの構造を表現したもの。

　アーキテクチャの対象となるものには、そのほかにもさまざまな領域があるだろう。例えば、ハードウェア・アーキテクチャがある。が、これらを説明の対象とすると狙いが定まらないため、ここではソフトウェア・アーキテクチャに限定し、これを明らかにする人材をITアーキテクトと呼ぶことにする。

■ソフトウェア・アーキテクチャとは

　対象となるソフトウェアシステムの全体的な設計課題を反映したソフトウェア構造を表現したものが、ソフトウェア・アーキテクチャであるならば、それはいったいどのように表現できるものであろうか。

　「全体的な設計課題を反映したソフトウェアの構造を表現」するのであれば、全体的な設計そのものになる。しかし、それでは話にならない。そこで、ソフトウェア・アーキテクチャという用語を、図1のようなレイヤ構造として表現してはどうだろうか。図1は、さまざまな視点からソフトウェア・アーキテクチャという構造を見たものである。上位方向は概念的、下位方向には具体的なソフトウェアの構造を表現するという意味を示している。

図1　ソフトウェア・アーキテクチャのレイヤ

　このすべてを守備範囲とする人材が、ITアーキテクトと呼ばれているのである。

■ITアーキテクトに求められるもの

　もう少し図1を詳しく説明すると、概念的なレイヤでは、技術者以外の人にも、対象とされるシステムのコンセプトを、とても分かりやすい比ゆを使って表せる能力を持つことである。例えば、スポンサー、ユーザーにも分かりやすくて、開発者にも開発するシステムの方向性を指し示す重要なコンセプトを比ゆ表現する。これができれば、アーキテクチャの価値を高めつつ、重要なコンセプトを関係者に見せることができる。これは、XPのシステム・メタファに近いものである。残念ながら、このレベルを表現できる人があまりにも日本には少なすぎる。

　中間レイヤでは、開発対象の設計の最も重要な部分を構造として表す力が必要とされる。これがアーキテクチャを表現する力である（RUPのアーキテクチャル・ベースラインの確立など）。最下位レイヤでは、個々の問題を解決できる設計能力である。このように、レイヤを分割するとアーキテクトに求められる能力が明確になるのだ。

　しかし、業界のさまざまな方と話をすると、ITアーキテクトに求められる素養は、もっとレベルが高いようである。図2にITアーキテクトに求められる素養について示す。この図では、図1に加えて、マネジメント能力もITアーキテクトの素養に含まれている。何よりも重要な点として、それらの能力をしっかりと統制・統治できるセンスが必要である。

図2　ITアーキテクトに求められる素養

　ところで、図2のマネジメント能力とは、人をマネジメントすることではなく、技術をマネジメントする能力のことである。その能力だけにフォーカスした別の視点を図3に示す。

図3　ITアーキテクトに必要とされる技術マネジメント能力

　さらに、もっと上位のITアーキテクト（チーフアーキテクト、トップアーキテクト）に求められるものは、ビジネスとITを融合できる力となる（図4）。ここまでくると一流のアーキテクトということになる。

図4　上位アーキテクトに求められる能力

■ITアーキテクトはスーパーマンか

　ここまでITアーキテクトに求められる素養と技術について話をしてきたが、いかがだろうか。おぼろげにITアーキテクト像というものが見えてきただろうか。

　が、こんな人はこの世に何人いるのだろうか、という疑問が浮かぶ。筆者自身も書きながら、そんな人は「スーパーマン」だよな、といいたくなる。このような人材は、企業の中に数人もいないだろう。

　しかし、さまざまな技術が融合するオープンな開発環境は、いまだ未成熟である。そこには、多様な技術的リスクが待ち受けている。しかも、ユーザーからの要求は非常に複雑になっている。そのような要求を受け止め、開発を見事に切り抜けて完成させるには、これまで書いたようなITアーキテクト像が求められるのは必然的にも思える。

　現在のITアーキテクト像をこのようにひも解くと、ひょっとすると業界の求める（つまり実存しない）スーパエンジニアを、ITアーキテクトとし、それを待ち続けているだけなのでは、という気もする。しかし、私の周囲には、そのITアーキテクト足り得る技術者も存在する。では、彼らはスーパーマンであるかというとそうでもない。

■ITアーキテクトへの道

　では、どうやってITアーキテクトを目指せばよいのだろうか。筆者から見て、優秀なITアーキテクトだと思える人の特徴は、ここまで説明した能力のどれかを非常に高度なレベルで持ち、それ以外の能力もバランスよく持つ人なのである。

　であるならば、皆さんに私がアドバイスできることは、ここまで紹介してきたアーキテクトの技術領域や素養を参考に、自分の得意とする能力がどこにあるのかを知ることである。そして最大限伸ばすべき能力と、そのほか身に付けておく能力を見定めて、そこに向かって地道な努力をすることが重要である。

　最初はターゲットとする能力・技術と、そのほかの能力・技術の関係を知ることから始めるとよい。つまり、これまで示した図を参考に、技術や能力をまずは棚卸しして、その関係構造を知り、そこに自分の得意領域をうまく生かせる可能性のある部分を見付けることが重要だと思う。

　参考として、ITアーキテクトの持つべきスキル項目（表1）を示す。

マネジメント	プロジェクト計画・プロジェクト管理・要求／変更管理 ・コミュニケーション
開発手法	要求分析・システム分析・システム設計等、フェイズの目的とアクティビティ把握
開発プロセス	開発プロセスの基礎知識からプロセステーラリング・要員アサイン計画
J2EE/EJBテクニカル	分散システムにおけるデザイン・EJB設計・業務モデルから設計へ落とす
デザインパターン	デザインパターンの基礎知識から、設計課題に最適なパターンを選択
コンポーネントモデリング	拡張可能・再利用可能なコンポーネントの設計・開発
アーキテクチャモデリング	実装環境の幅広い知識を持ち、拡張性・スケーラビリテイなどを加味したデザイン
要求モデリング	ITの課題を見据えた要求定義からユースケースモデルに落とす
業務（分析）モデリング	オブジェクトモデルを中心に、ビジネスモデリング、分析モデリングが可
設計モデリング	分析モデルを非機能要求を加味した設計モデルに落とす
OOP	基礎的な言語能力に加えクラスライブラリを使いこなしOO言語の特性を生かせる
分散システム	分散DBの知識から負荷分散設計・セキュリティ設計・信頼性設計・レイヤ設計
業務知識	業務の基礎から幅広い知識を持ち、業務をIT化する際の課題について定義
J2EE／EJB基礎	J2EE／EJBアーキテクチャを十分理解しており、簡単なシステムなら利用可
ツール環境	IDEを始めとする開発ツールの基礎的な理解からプロセスの中での利用方法
テスト手法	単体テスト・結合テスト・過負荷テストなどテスト手法を理解しており、実践可
UML	UMLの基礎的な表記法と利用方法から、利用目的に応じてモデルを定義可
モデリング	オブジェクトベースによるモデルの意義・目的を理解しており、自分で作成可
DB、ネットワーク	DB論理・物理設計、DB正規化手法、ネットワーク・トランザクション
XML知識	XML基礎、XMLデータの設計、XMLデータの利用（XSLT、DOM）
オブジェクト指向言語	Java言語と標準APIの基礎
プログラミング言語基礎	関数型プログラミング言語の基礎、関数、ローカル変数、引数、制御命令など
OSの基礎	マルチプロセス・マルチスレッドのメカニズム・ファイルシステムなどのOSリソース
表1　ITアーキテクトの持つべきスキル項目

　さらに、スキル項目の相関マップ（図5）を示そう。この2つの図で勘違いしないでほしいのは、これらはあくまで個々のスキルであり、それらを身に付けたからといって優秀なITアーキテクトになれるわけではないということだ。これらのスキルを持ちながら図1〜図4のような能力と素養を身につけていくことが必要なのである。

図5　スキル項目の相関マップ。画像をクリックすると拡大して表示されます

　ここまで書くと、「やっぱりITアーキテクトという道はあまりにも遠く、自分はクリアできない」とか、「会社の中で育たない」といった感想を抱く人も多いだろう。それでは私のITアーキテクトの定義は失敗に終わってしまう（定義しても夢を語っているだけになってしまう）。

■ITアーキテクトになるための現実的なヒント

　そこで、もう少しヒントになるテクニックについて話してみよう。

・ITアーキテクトの能力は、すべて自分で身に付ける必要はない
　ITアーキテクト能力は、チームで実現する。ITアーキテクトと呼ばれる人は、自分の得意な能力以外は、その能力を持つ技術者を自分のチームに入れておき、チームでアーキテクトとしての役割を発揮するようにする。この場合、ITアーキテクト能力として必須になるのは、チームに点在するアーキテクトスキルを一貫性のある形で統制・統治する能力となる。つまり、人に点在する技術をマネジメントする能力があれば、自分がアーキテクトスキルをすべて持たなくても、アーキテクトとして立派に活躍することができる。実際、このような腕を持つ技術者ならば、皆さんの周囲にもいるのではないだろうか。

・技術を抽象化する力と、具象化する力を身に付ける
　図6を見てほしい。この図は、本連載の「第2回　エンジニアとして生き残るには」で取り上げた図1に、今回の図1（ソフトウェア・アーキテクチャのレイヤ）をマッピングさせた図である。具体的な物事から抽象化すると概念レイヤになり、それをもっと抽象化すると目的レイヤになるという私が考案した「思考の秩序棚」に、アーキテクチャをマッピングすると、ソフトウェアの概念を表した表現（設計の中で重要な部分を抽象モデルで表現）や、ソフトウェアの目的を表現したもの（システム課題の重要部分のコンセプトを抽象表現）を発見できるという例である。

図6　第2回で取り上げた図1に今回の図1をマッピングしたもの。画像をクリックすると拡大して表示されます

　アーキテクチャとは、そもそも設計をある程度抽象表現しなければ説明できない。図6の意味は、その抽象化する方向に「設計概念（コンセプト）」があり、「設計目的」があることを理解していただくと、アーキテクトの普遍的なテクニックにつながるのではないか、という提案である。

　この方法を利用すると、抽象化の狙いを「設計の目的」に照らし合わせて、細かな個々の設計課題の中から抽象化を行うことで、設計概念が抽出できるようになる。こうすることで、設計目的に見合った設計概念が抽象化できるようになる。また、その設計概念を設計目的という視点で抽象化し、一般にも理解できるようにデフォルメしたものが、システムの比ゆ表現なのである。

　ここで重要かつ普遍的なテクニックとしていえることは、この図のように「設計」「概念」、それに「目的」という視点を抽象化できる能力である。そして、抽象化したものをもう1度具象化する能力だ。つまり、抽象化と具象化を幾度となく行き来できる能力を磨くことが重要だと思うのである。

　今回は、ITアーキテクトという職種・技能について説明をしたが、ここで書いたものは業界で認知されているものではない。まだ筆者の個人的な定義でしかないが、筆者の周りにいる非常に優秀なアーキテクトと呼ばれている人々の能力や、筆者自身の経験の共通点について分析し、その普遍的な部分を整理しているものである。皆さんがITアーキテクトを目指す際の道案内に少しでも貢献できれば幸いである。

■筆者が目指すもの

　最後に、筆者自身は何を目指しているのかについてお話したい。

　筆者は以前、ITアーキテクトを名乗っていた。しかしいまはITアーキテクト志向ではない。どちらかというと、アーキテクトという職種を作り出し定義することで、ITアーキテクトを創出したい、という願望が強い。また、開発に必要な方法論を作り出したい。現在もビジネス主導の開発方法論を作成している。

　結局、筆者の目指すものは、現在定義されていないモヤモヤしているものを棚卸しして、目に見える形にデザインしたいのである。これを何かに例えるとなるとコンポーザー（作曲家）を目指しているといえる。ただ、残念ながら売れない未熟なコンポーザーである。

　本稿を読んだ皆さんは、おそらくITアーキテクトを目指す方、目指したい方が多いと想像する。私がコンポーザーになるのが早いか、皆さんがITアーキテクトになるのが早いか、ここで競争をしてみようではないか。筆者としては、その競争ができるようになるためにも、ITアーキテクトという職種を形にしていく努力を続けていきたい。皆さんもITアーキテクトを目指して1つ1つ確実に技能を身に付け、得意能力を磨き、ITアーキテクトを目指してほしい。

筆者プロフィール 萩本順三●豆蔵 取締役。20代後半でエンジニアに転身。その後、泥くさい開発の中からソフトウェアの構造をとらえることに関心を持つ。それをきっかけとしてオブジェクト指向技術に出合う。最初は同技術を疑い続けていたが、いつの間にかオブジェクト指向の虜（とりこ）となってしまい現在に至る。