28歳から挑戦するITアーキテクト（6）
ITアーキテクトになった後の試練

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

　難解なプログラムをマスターし、複雑な仕事や人間関係にも何とか慣れ、複数人からなるプロジェクトの枠組みを土台から支えるITアーキテクトとなる。その第一歩を目指す若手の方、またはすでにその役割を与えられ途方に暮れている方をターゲットに本連載は続いてきた。

　 しかし、仮にITアーキテクトという肩書を持つことが、名刺上の自称肩書ではなく実際をも反映した、本物のITアーキテクトとなったとしても、そのスキルを危ぶむもの、または自らの責任で脱落する要因が次から次に登場してくるはずだ。

　例えば、前回「誰のためにシステムをつくっているのか？」も取り上げた職業倫理の問題だ。前回の原稿を書き上げた直後、マンション建設の耐震構造に関する問題が明るみに出た。これはITアーキテクトに相当する建築士（逆にIT側が一方的に参考としているというのが正解だろうが）、つまり本家本元のアーキテクトによる問題といえるだろう（この問題の場合、自らの立場がどうこう、という次元の話ではないことはいうまでもない）。

　仮にITアーキテクトとなったとしても、やはり10年、20年と長期にわたり第一線で実績を積んで初めて「活躍する」という言葉を当てはめることができるのだろう。読者の方はそれをどこまで認識しているだろうか。

◆ 続けるということがいかに難しいか

　筆者も以前そうだったのだが、意外にも20代のころというのは、目の前の仕事が忙し過ぎて、30代、40代の自分の姿をまったく想像していない。考える土台となる経験がないこともさながら、いや、考えたくもないというのが正直なところだろう。

　しかし残念なことに、人間誰しも生きている限り年齢は重ねるもので、30代を目前とした年にもなれば、いや応なく「次」の自分の姿を正視せざるを得なくなってくる。「若手のホープ」ともてはやされるのも一時期で、どんどん飲み込みの早い新人が自分を追い上げてくる。プログラム技術での技術力の差別化についても、ある1つの技術について深く理解したとしても、あっという間に陳腐化する。そして新しい技術が出るたびに新人がそれを引っさげて追い上げてくる。

　年齢が30前後になれば、プロジェクトのリーダーまたはサブリーダーに相当するところを任されてくる。責任は重くなる一方だ。日々の忙しさにかまけているうちに、本来やりたかったはずの技術をしばらく触らなかったばかりに、新しい技術と新人がわがもの顔で活躍し始める。

　こうして、数年間のみの「時流」に乗ってのし上がったとしても、30代を境にある人は体力的な限界を感じ、ある人は技術的な追従に嫌気が差し、ある人は業種に絶望して他業種へ転職していく。

◆ 技術の移り変わりの激しさ

　仮に1つの技術について「売れる」ものを取得できたとしよう。しかし、それ一本を武器に仮に他人よりものし上がれたとしても、現在の技術革新（という名の新製品登場）の速さからすれば、せいぜい1年から2年程度でそれは陳腐化してしまうだろう。

　執筆時点（2005年末）での現在エンタープライズ系開発の主流となっているJava EE（旧J2EE）にしても、その主な要素であるJSPやEJBなどが本格的に用いられ出してからまだ5〜6年しか経過していないが、その間に初版の1.2から1.4に2回の改訂が行われている。Microsoft .NET Frameworkに至ってはさらに新しいが、2002年の1.0登場から最新の2.0まで、3年で2回の改訂を行っている。

　どれもベースも考え方も同じ、とはいえ、具体的な運用スキルまで含めた製品レベルでの細かな技術は猛スピードで変化しているうえ、昔の内容はそのまま通用せず、ある機能は大幅に、またある機能は微妙に変わり続けている（ビジネスで使いこなすうえでは、製品という水準で技術を考える必要があることはこれまでの指摘のとおりだ）。

◆ その技術はいずれ廃れる運命にある

　いまとなっては信じ難いのだが、本稿執筆時から10年前はWindows 95が登場したばかりで、まだ多くの人はPC-9801上でMS-DOSやWindows 3.1またはMacintosh漢字Talk 7を利用しており、インターネットに接続できるのは超高額なUNIX系システムとネットワークを保有する大学や（いまと比較して）一部の愛好家に限られていた。その5年前は2400bpsのモデムを経由したNIFTY-Serveを代表とするBBSブームとMS-DOS上の一太郎・Lotus 1-2-3ブーム、さらにその5年前は8ビット国産機ブームでMicrosoft BASICが大流行していたころになる。何とも目眩（めまい）がするほどの進化ぶりであるが、そのほとんどの技術は、語弊があるかもしれないが、20年経た現在、まったく役に立たない。

　片や企業向けシステムとなると、ベンダによる囲い込み（ベンダ・ロック・オン）全盛時代となり、オープンシステム・オープン言語が主流の現在では、C言語など恐ろしく基礎的な技術やウォーターフォール、DOAなどの一部の方法論を除き、やはり製品レベルで見た場合、役に立たない。

　ここから類推できるのは、10年後から20年後、現在のIT技術は多分廃れているかまたはごく部分的にしか役に立たないだろう、ということだ。

◆ 追従する覚悟はあるか

　こうした激変するコンピューター事情に巻き込まれながら、常に第一線でITアーキテクトとして活躍し続けるのは、どう考えても困難な部類に入る。残念ながら、ITアーキテクトは、ハードウェアやソフトウェアベンダがおぜん立てした人工的な「プラットフォーム」上で活躍することが宿命付けられている。「プラットフォーム」が変われば販売される機器・ソフトウェアも更新または淘汰が進む。一歩身を引いて批判したところで、その流れに追従しない限り、あっという間にそれは「ITアーキテクトとしての死」を意味することになってしまう。

　こうした変革は、あらかじめ予測し覚悟していればある程度は対応できる可能性があるが、まったく予期していない場合や、1つの技術でITアーキテクトとなることを「終着点」と考えている場合、致命的な弱点となる可能性をはらんでいる（ちまたのうわさで「新しい言語に乗り換えられる人は旧ユーザー全体の数割」とささやかれるのと同じだろう）。

　もし「活躍する」ITアーキテクトであれば、こうした変革は逆に絶好の好機となる。なぜなら、まだ誰も知らないうえに、新しいものを常に求めるアーリー・アダプター層に対しての接触の好機となるからだ。加えて、仮にその新しい技術が浸透した場合、非常に良いポジションに就くことができる「おまけ」も付いてくるわけだ（外れた場合はもちろんその限りではないリスクも負うことになる）。

　このように、鋭い嗅覚としたたかな行動力を持ち、新しい技術に追従していく覚悟があるだろうか。

◆ 「限界」を乗り越えるために

　このような続々と新しい製品が登場する状況は何もIT特有のものではない。しかし、今後業界から足を洗うつもりならいざ知らず、少なくともITアーキテクトとして将来も活躍するつもりであれば、10年、20年先の自らの在り方を多少なりとも想起しておく必要があることはいうまでもない（残念ながら筆者を含めほとんどの一般人は、年金をもらう時期まで多少なりとも食いぶち分は働き続ける必要があるわけだ）。

　「継続こそ力なり」とよくいわれるが、プロフェッショナルとして誇りある仕事をするためには、継続して第一線で活躍し続ける必要がある、というのがかねてからの筆者の持論だ。新しい技術が登場した時流に乗ってのし上がることができたとしても、勝負はそれからだ。「次」の一手で煮詰まってしまえば、ただの一発屋としてあっという間に市場から淘汰されてしまうだけだ。

　「限界」はすぐそこまで迫っているかもしれない。しかし、それは誰かが事前に気付くたぐいのものではなく、後から「実はあれがそうだったんだ！」と振り返り評価が定まるものだろう。同じように、この「限界」を乗り越えるための方策は、重責を担う他業種の職種と同じく、「こうすれば大丈夫」との明確な答えがあるわけではない。

　ただし、さまざまなところにその回答のヒントとおぼしきものは隠されていて、思いがけないところでその回答となるのでは、と筆者は考えている。そのためにも、ITとは全く無関係の分野まで自らのアンテナを広げ、視野を狭くしないよう心掛けている次第だ。また、ITアーキテクトとしての実務をこなしてゆくと、いままでまったくかかわったことのなかった分野のシステムデザインおよび構築に携わることが多い（筆者の偶然かもしれないが）。

　このような経験からの刺激は知的好奇心を大いに奮い立たせる。こうした場への貢献として、筆者は常日頃から長期的な製品ライフサイクルを持つ新しい技術をもってして行いたいと考え、それをモチベーションの1つとしている。

　この筆者の例は、多分多くの方にはピンと来ないだろう。それは、各人の仕事へのモチベーションがそもそも違うため、その解決法も当然異なるためだろう。このように、悩みは業種を超えて共通だとしても解決法は千差万別、という非常に厄介な課題であるが、こればかりは致し方ない。だが、悩みが業種を超えているとすれば、多くの第一線の方の解決法が参考になるはずだ。

　このような発想の転換と課題を自ら克服していく能力も、重責をこなしてゆくITアーキテクトに求められるスキルの1つなのだろう。

IT Architect 連載記事一覧