ITアーキテクトを目指す多くの人々は、現在、プログラミングを主な作業として仕事に従事しているのではないだろうか。プログラミングを行う場合、Javaなど特定の言語のみを主軸としている人と、振られる仕事によって言語を切り替えるような、複数の言語を同時に操っている人とに分かれるだろう。今回はプログラミング言語を中心とした開発系の話が中心である。
ソフトウェアはそもそも、特定の基盤技術の上(特定のハードウェアやOSの上ということ)で、特定のコンパイラを用いて、特定の言語を操作して構築するものだ。このうち、どれか1つでも“特定”という条件から外れた場合、そのソフトウェアは動作しない。それは、ハードウェアやOSから独立した特定のバーチャルマシン上で動作するJavaクラスファイルでも同じ話だ(例えば、PC-AT互換機であろうとも、Java SE 5.0仕様VMの存在しないMS-DOS 6.2の上ではJava言語仕様第3版のクラスファイルは動作しない)。
従って、構築したソフトウェアの正常な動作がその使命として求められるITアーキテクトにとって、ターゲットとなるソフトウェアが支障なく動作する環境を正確に把握することは、業務のスムーズな遂行を行う上で必須の要素となる。
かつて、企業向けソフトウェア構築で使用される言語の主流はCOBOLだった。その後、Windows 95登場を境にVisual Basic 4〜6やBorland Delphiが用いられるようになった。2000年頃にはJava 2 Platform,Enterprise Edition (J2EE、後にJava EEと改名)が登場している。さらに現在では、.NET Frameworkが、COBOLの主戦場だったミッションクリティカル分野に浸透しつつある状況でもある。
20代の人に、システム構築環境の歴史的背景を完全に把握してもらうのはさすがに難しい。そこで、以下に簡単にまとめておく。ITアーキテクトの仕事を行うのであれば、「既存システム」として必ず出会うことは容易に予想できるからだ。
特定のプラットフォームを対象とした仕事や学習を続けながら、より深い技術へと理解を深めていくにつれて、それ以外の言語やプラットフォームを意識することはどんどん希薄になっていく。限られた時間で結果が求められる実際の開発現場を考えれば至極真っ当な話だし、このことでプロダクトの提供側を責めているわけでもない。
しかし、このような視野の狭くなりがちな状況が、IT技術者の短命化を招いているのも事実だろう。多くの場合、1つの開発環境を深く理解した技術者が新たに登場した技術や言語に乗り換えられる確率は低いといわれている。1つの技術が高く売れる「おいしい時期」を仮に6〜10年と考えれば、いわゆる「プログラマ35歳限界説」もあながち根拠のない風説とは切り捨てられない。
特定の技術に従事する技術者が、新技術とともに葬られる傾向というのは他業種でも普通に発生する悲劇だが、ITの場合、全体的にそのスパンが異様に短いのが特徴だ。
となれば、「35歳の限界」を超えて普通に活躍しているITアーキテクトともなれば、その基盤技術を乗り越える準備を、日々怠ることはできないと考えるのが自然だろう。
さて、企業向けシステムで現在主流の基盤技術といえば、ずばりJava EE、およびマイクロソフト .NET Frameworkだろう(ほかにもPHPなどの軽量言語やCOBOLなど古いがまだ第一線で使われている言語なども多くあるが、本連載の対象読者である28歳の方が普通に実務で使い、いま現在多くのお金が動いているプラットフォームとなればこれらが妥当だろう)。
なお、よく勘違いされるのだが、.NET Frameworkに相当するJavaの技術は、Java SE(旧J2SE)ではなくJava EE(旧J2EE)である。それは、基盤実装がカバーする範囲やAPIが提供する機能を比較すると一目瞭然だ。これらの比較は次回詳しくみていきたい。
まずひとくちに「Java EE」「.NET」といっても、それらには細かい異バージョンがあり、その提供時期によってサポートされる環境が異なっている。例えば現在主流のJava SE 5では、基本的にJava EEの前身であるJ2EEの初版である1.2はサポートされない。「Javaはいつでもどこでも動く」と無邪気に信じている人にとっては驚くべき事実だろうが、それは似通った.NETでも同じだ。
以下の文章はJava EEおよび.NETの歴史を年代順に並べたものだ。.NETに関してはその前身となるCOM関連技術も併せて記載した。
年 | 会社名 | 名称 | バージョン | 対象プラットフォーム |
---|---|---|---|---|
1995/05 | マイクロソフト | Visual BasicVisual C++ | 4.0 | Windows 3.1/95/NT 3.5 |
1996/01 | JavaSoft | JavaDevelopment Kit(JDK) | 1.0 | Windows Solaris SPARC/Intel Macintosh System 7 |
1996/08 | マイクロソフト | ActiveX | - | Windows 95/NT 4.0 |
1996 | マイクロソフト | Distributed COM(DCOM) | 1.0 | Windows NT 4.0 |
1997/02 | JavaSoft | JDK | 1.1 | Windows Solaris |
1997/02 | マイクロソフト | Visual Basic Visual C++ | 5.0 | Windows 95/NT 4.0 |
1997/12 | サン・マイクロシステムズ | Enterprise JavaBeans(EJB) | 1.0 | Windows Solaris |
1998/09 | マイクロソフト | Visual Basic Visual C++ | 6.0 | Windows 95/98/NT 4.0 |
1998/12 | サン・マイクロシステムズ | Java 2 Platform、Standard Edition(J2SE) | 1.2 | Windows Solaris SPARC/Intel |
1999/12 | サン・マイクロシステムズ | Java 2 Platform、Enterprise Edition(J2EE) | 1.2 | J2SE 1.2 準拠 |
2000/02 | マイクロソフト | COM+ | 1.0 | Windows 2000 |
2000/05 | サン・マイクロシステムズ | J2SE | 1.3 | Window/Solaris/Linux |
2001/09 | サン・マイクロシステムズ | J2EE | 1.3 | J2SE 1.3 準拠 |
2002/01 | マイクロソフト | .NET Framework (C# 1.0、Visual Basic.NET、 Visual C++.NET) | 1.0 | Windows 98/98SE/Me /NT 4.0/2000/XP |
2002/04 | サン・マイクロシステムズ | J2SE | 1.4 | Windows/Solaris/Linux |
2003/06 | マイクロソフト | .NET Framework(C# 2.0、 Visual Basic.NET 2003、 Visual C++ .NET 2003) | 1.1 | Windows 98/98SE /Me/NT 4.0/2000 /XP/2003 |
2004/04 | サン・マイクロシステムズ | J2EE | 1.4 | J2SE 1.4 準拠 |
2004/09 | サン・マイクロシステムズ | J2SE | 5.0 | Windows/Solaris/Linux |
2005/11 | マイクロソフト | .NET Framework(C# 2.0、 Visual Basic 2005、 Visual C++ 2005) | 2.0 | Windows 2000/XP/2003 |
表1 Javaおよび.NETの主な仕様発表 |
一見して、度重なるリリース数に驚くだろうが、この一覧をあらためて見たときに、意外にも自分がかかわっている言語以外は知らないという事実にも驚くのではないだろうか。
ITアーキテクトの立場ではシステムを新規に開発する場合を超えて、すでに構築されたシステムのメンテナンスや結合などの検討が頻繁に発生する。そうした場合、過去のシステムを全く知らなければ、お手上げとなってしまうことが多い。このような技術の流れは、同じ時代を同時に体験し、その時々の流行と設計思想などをある程度把握しておくべきだ。そうしないと、仮にそのシステムに手を入れる場合が来た時、予期しないトラブルに巻き込まれる可能性が高くなる。
筆者の失敗談を紹介しよう。
1990年代前半、MS-DOSを中心にQuick BasicやQuick C辺りをやっていた。その頃、Windows 95が登場した。その辺りからマイクロソフトを中心とした技術を追いかけるのをやめ、当時ベータ版であったJavaに「すべてを賭ける」形で没頭することにした。その結果、Javaに関しては相当程度深く知ることができたが、その代わり、ActiveXからDCOM〜.NET Frameworkの流れに関しては、ポッカリと欠落していた。
その後.NET Framework 1.0を初めて業務で触ったのだが、(.NET Frameworkの)周辺技術にまったく手が出ず、キャッチアップに相当の時間を費やすことになった。最初から少しずつ追いかけていればこのようなことはなかったはずだが、結果的に大きなツケを払わされた形になってしまったのだ。
過去の技術をサポートすることも重要だが、これから登場する技術についても追う必要があるのはいうまでもない。
年(予定) | 会社名 | 名称 | バージョン | 対象プラットフォーム |
---|---|---|---|---|
2006/Q1 | サン・マイクロシステムズ | Java EE | 5.0 | J2SE 5.0 |
2006/秋 | サン・マイクロシステムズ | Java SE | 6.0 | Windows/Solaris/Linux |
2006末 | マイクロソフト | WinFX | 3.0? | Windows XP/2003/Vista |
表2 これから登場する技術 |
これらの各技術についての詳細解説は本題からそれるため別途各自調査してほしいところだが、とりあえずポイントだけを指摘していく。EJBが強化されたJava EE 5の登場と、Windows Vista登場に伴う.NET FrameworkのAPI実質メジャーアップデートが最重要事項と考えていい。まずはこれらの技術動向をキャッチアップするのが急務だ。ベータ版などを入手し、事前にある程度把握しておくと、その後の研究が楽になる。これより先の技術となるとさすがに雲をつかむような話になるが、最低でも今年登場する予定の技術については、現在行っている各自のプロジェクトの状況と照らし合わせ、移行プランを考慮しておくべきだろう。
ITアーキテクトとして長期にわたって仕事をこなすためには、まずは基盤技術を把握し、それらを使いこなしていかなければならない。意図せず(特定の技術に)囲い込まれてしまうのは避けたいところだ(これはベンダを非難する意味ではない)。もちろんあえて囲い込まれるという戦略もあり得るが、その場合、あくまで意図的でなければならない。
“ロックオン”を避けるために、何か難しいことをする必要はない。日々の心掛けとして、新しい技術やこれから普及しそうな技術について、変な色眼鏡を外して興味を持つことだ。得てしてプログラマの立場では、自分が現在使っている言語を持ち上げたり、派閥を作ったりして排斥したりするものだが、そのような振る舞いは、ITアーキテクトにとって百害あって一利なしと、この際なので断言してしまおう。すべては、技術に対しての誠実な取り組みと顧客利益への貢献のためだ。そうした心掛けが、いつか必ずあなたを救うはずである。
Copyright © ITmedia, Inc. All Rights Reserved.