28歳から挑戦するITアーキテクト（1）
ITアーキテクトへの“脱皮”の覚悟

株式会社 豆蔵
BS事業部 エンタープライズシステムグループ
岩崎浩文

2005/8/19

　日々追われる作業、上司からの圧力、顧客との苦い折衝、理解できない既存システム、遅延するプロジェクト、追いつくのが精いっぱいの次々と登場する新技術、複雑な外注関係、理不尽な納期、完成直前まで変更が続く仕様、永遠に続くかのようなバグの発生と切り分け、長期にわたる徹夜作業、擦り切れた人間関係、明日の見えないキャリアパス……。

　筆者の20代のころの経験は、主にこうした「混沌とした」ものから構成されていたといっても過言ではない。こうした経験は、まじめに仕事をすればするほど、どんどん狭く深みにはまっていくものだ。

　そうした悩み深きプログラマの1つの解として近年脚光を浴びている「ITアーキテクト」という役割。この連載では、いまも現場でもがき続ける現役ITアーキテクトの1人として、悩ましい20代への「次のステップ」の手引となるものを残していきたいと考えている。

◆ ITアーキテクトとは

　 「ITアーキテクト」とは、近年「プログラマよりも一段上の立場」という意味合いで用いられることが多い単語だ。特に現職でプログラマの役割を持つ方々にとって、非常に人気の役割となっている。書籍などでも多く「アーキテクト」と名の付くものが出版され、転職セミナーなどでは、希望職種にITアーキテクトと記載する方々が非常に多いと聞く。

　ただし、IT業界にてITアーキテクトという言葉がここまで頻繁に用いられるようになったのがごく近年であるため、用語の統一という意味ではまだ混乱が深い。例えば本フォーラムの「ITアーキテクト宣言」では、筆者もよく存じ上げる名だたる方々がITアーキテクトについて語っていらっしゃるが、やはり現場の意見の統一という意味ではまだまだ、といった感が強い。このため、ITアーキテクトを目指して転職したのに、想像していた仕事とはまるで違う、という悲劇が起こらないとも限らない。

　こうした状況下、近年アーキテクトの指標としてよく用いられるのが、経済産業省「ITスキルスタンダード」（ITSS）のITスキル標準フレームワークに記載されている「ITアーキテクト」だ（図1）。

図1 「ITスキルスタンダード」（ITSS）のITスキル標準フレームワーク（クリックすると拡大）

　これは職種とレベルを格子状に並べたもので、すでにご存じの方も多いだろう。この中でITアーキテクトの専門分野は以下の5つが定義されている。

• アプリケーション （レベル4〜レベル7）
  
  
• データベース （レベル5〜レベル7）
  
  
• ネットワーク （レベル5〜レベル6）
  
  
• セキュリティ （レベル5〜レベル6）
  
  
• システムマネジメント （レベル5〜レベル7）

　こうした分類に対しては、すでに現場から多くの異論等が出ていると聞くが、企業向けアプリケーション構築側の立場である筆者の率直な意見としては、さほど異論はない。また、良い悪いは別にして、こうした標準指標となるものが出ている限り、標準として根付く可能性が高い（すでに根付きつつあるのかもしれない）。

　もともとアーキテクト（architect）とは建築家・建築技師という意味で、建設業界の用語をIT業界が転用したものと見ることができる。このため、ITシステム構築を依頼する他業種の方から見た場合、建設業界の「建築のスペシャリスト」としての意味合いをベースに、「ITシステム全体のスペシャリスト」として見られることが多いのではないだろうか。

◆ プログラマとしての限界

　さて、転職市場等でITアーキテクトがもてはやされ、プログラマ（ITSSでは「ソフトウェアデベロップメント」）がITアーキテクトを目指す1つの理由として、プログラマとしての限界がよく引き合いに出される。他業種にもよくある都市伝説である「35歳限界説」として、プログラマは35歳が限界、つまり解雇の憂き目に遭ったり、プロジェクト管理者など別の職種に強制的に配置換えを食らったり、再就職時に不利になったりという、まことしやかにささやかれる話である。

　確かに深夜・休日を問わない過酷な労働条件や、日進月歩の技術革新についていけないため、不本意にも脱落していくプログラマが多くなるのが30代を超えた辺りからだ。筆者と同年代のプログラマの多くも、すでに「行方不明」となっている割合の方が多い。また、筆者が客先でITアーキテクトとして開発現場を指導する場合、現場を率いる30代のプログラマの層がすっぽり抜け落ちている場面に出合うことが多くなってきている。

　また、近年現場にて見過ごすことのできなくなってきた問題として、オフショアリング（海外への開発の委託）の活性化がある。古くはインドや中国、近年ではベトナムなど、人月単価が日本の数分の一という驚異的な低価格の下、国内の単純作業系IT開発が根こそぎ奪われつつあるという現実だ。これまでプログラマは国内の敵対会社や同僚などをライバルとしていれば良かったのが、一気に世界のプログラマたちと戦わねばならなくなってしまった。

　顧客から人月単価について「キミは3分の1の値段の海外要員より、3倍働けるというのかい？」と真正面から問いただされた場合、論理的な反論に窮してしまうだろう。最小の投資で最大の効果を上げる必要のある、顧客側の立場を考慮すればなおさらだ。

◆ 「逃避」ではなく「向上」として

　こうしたプログラマを取り巻く状況の悪化から、やはり単なる「いわれたことを淡々とこなす」プログラマであり続けるのは非常に困難となりつつある。IT投資が縮小していく可能性が高く長期で考えた場合、この惨状がより悪化することは目に見えている。

　このため、プログラマ自身ができる自衛の策として、製造業などの他業種と同じく、より高度な知識や経験を基に、高品位のサービスを提供し、自らの立場を常に確保し続けることが考えられる。特にプログラミングを日々の糧としている腕に自信のある方ならば、それを基に高度な技術提供とそれに基づくビジネスを考えるのは何ら不思議な話ではない。

　ITアーキテクトとは、こうした高い技術を保持し、顧客に対して最小の投資にて最大の効果を上げるための処方せんを提供できる「プロフェッショナル」としての活動が源泉であると筆者は考えている。これは特に「仕事で何となく（嫌々）プログラミングをやっている」プロフェッショナリズムに欠ける作業者の立場と根本的に対立する指向であるという点に注意する必要があるだろう。つまり、プロである限り、自らの仕事に対する重責と誇りから常に逃げず、真正面から取り組む必要があるということだ。

図2 プログラマをベースに進化する

　このプログラマから「ITスペシャリスト」としてのITアーキテクトへの脱皮については、他業種の同じような高い職責と同様、ある程度の覚悟を決めないと、そうそうできるものではない。つまり、やる気のない者は市場から退場を促され、できる者は常に顧客から直接に成果を求められる厳しい弱肉強食の世界にあるということだ。

　このため、「プログラマとしての立場が危うくなったからITアーキテクトと看板を掛け替えました」ではなく、「プログラマでは自らの能力を生かせないため、より高度なアーキテクトとして技術を提供する必要がある」という、逃避ではなく向上としてのレベルアップが求められている。IT開発現場としても、顧客側としても、そうしたやる気と豊富な経験と自信に満ちた参入者であれば、もちろん大歓迎だろう。

◆ より深いコミットメントを

　さて次回以降ITアーキテクトの具体的な仕事についてもご紹介していくが、現場での重責を考えた場合、ITアーキテクトになるということは、仕事に対してより深いコミットメントが求められているということになる。

　これは長い労働時間が必要、という話ではなく、自らの経験と知恵を絞り出して顧客からの信頼を得、多くの開発人員からなる現場を正しい方向に導き、長期にわたる運用の悩みをともに解決してゆく「現場と目線を合わせる」柔軟さと責任感が求められるということだ。

　ITシステムは機械が動作するものであるにもかかわらず、非常に多くの人間がその構築・運用にかかわる。そうした人員は多少なりとも技術的に「こだわり」を持つ方々が多い。こうした中、ITアーキテクチャを武器として作業員を納得させながら開発し、正常運用に持ち込むためには、そうした現場とがっぷり四つに組み、ともに意見をぶつけながら解決策を模索する、粘り強い日々の取り組みが不可欠となる。

　ITアーキテクトは、決して楽な仕事でも、おいしい立場でもない。かえって多くの情熱と労力を注ぐ必要のある、後ろ向きの考えであれば「厄介な」職業であるはずだ。それはプログラマが最も苦手とする「人間系」の技術と、それに似つかない「IT系」の技術の両輪が求められる、高い難易度を必要とする職種といえるだろう。

図3 ITアーキテクトにとって、IT系と人間系スキルは両輪

　こうしたスキルは一朝一夕で得られるものではない。可能であれば早いうちから日々の自律的な訓練が望ましい。今回のサブタイトルに含まれる「28歳」というのは、すでに数年間現場で酸いも甘いも経験し、世の中が見えてきたちょうど良い年齢だろうと筆者は考えている。まずはそうしたITアーキテクトが置かれる立場と求められることを理解したうえで、ITアーキテクトへの挑戦を開始したい。

IT Architect 連載記事一覧

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