Contents
Javaができたのはいつごろ？
Javaがいつごろ登場したのかをご存知でしょうか？実は1990年台には早くもJava Beansが登場しています。Java Beansと聞いて、聞き慣れないもしくは「古すぎる」と思われたかもしれません。Javaは歴史ある言語なのです。
1998年頃は、まだインターネットと言えばダイアルアップでした。NTTの夜間かけ放題プランである「テレホーダイ」を使って、自宅から夜間のインターネットにアクセスし、常時接続は月10万円したため、自宅に専用線を持っている人はほぼおらず、会社からの常時接続が当たり前だった時代です。
そんな時代、ソフトウェア開発はどのようなものだったのでしょうか？実はクライアント・サーバー型だったのです。さらにその前も、メインフレームで大型コンピュータが処理し、端末はスペックが脆弱だったため、クライアント・サーバー型のシステム開発が一般的でした。
Javaはいち早くオブジェクト指向を取り入れ、Java Beansでデータを守り、サーバサイドにアルゴリズムをラップして、クライアントからアクセスするというプログラムが生まれました。JavaにはJavaの誕生の由来があったのです。
Web時代とJava
そして、時代は一気にインターネットの社会になります。クライアント・サーバー型も使われていましたが、WebのMVCモデルに移行しました。これにもJavaはいち早く適応し、MVCモデルを主軸としたJava ServletとJSPが生まれます。
このServletとJSPは、HTMLを吐き出すことのできるJavaプログラムです。
Webサイトを作る際において、HTMLを動的にコントロールする必要が生じます。HTMLを静的に記述するだけでは、どうしても表現に限界が生まれるからです。
しかしこのServletにもJSPにも、まだまだ欠点があります。その一つが、例えば、JavaエンジニアがHTMLまで身につけなければならないことでした。そして、細かなデザインの変更はWebデザイナーがCSSをいじる必要があったため、共同作業が難しい状態でした。
ブラウザ読み込みのJava Applet
そして、今のエンジニアには信じがたいかもしれませんが、インターネットエクスプローラやFireFoxに埋め込みつまりブラウザ上にダウンロードされてクライアントサイドで実行される、Java Appletというアプリケーションも開発されました。
セキュリティ面でやや怖いという一面はあるものの、Java Appletは、クライアントのブラウザを自由に操作したいという要望を持つ組織で採用されました。たとえば、総務省の電子申請プログラムなどは、当初はこのアプレットで実装されていました。
Javaを武器にし続けることのメリット
Javaを武器にしていく上で大きいのが、大規模案件に関われるということです。上流工程へのキャリアパスが見えているのであれば、Javaは極めて有効です。なぜなら、安定しており、比較的歴史が長く、そして大規模開発の実績が多数あるJavaは大組織や大規模なプロジェクトで人気でよく採用されるためです。大勢のJavaエンジニアが世の中にいることも人気の理由の一つです。。
よって、上流工程にのぼっていこうと考えるのであれば、初期の段階でJavaが書けるのは大きなメリットとなります。上流工程とは、顧客との要件定義を詰めたり、仕様を書いたり、そして工程管理を行ったりといういわゆる「システムエンジニア」の職業です。
ただ、現在、Javaをどのポジションで書いているかにもよります。大企業のSIerやその子会社のシステム開発部で働き、より上流に上がっていきたいと考えたときに、Javaは大きなパワーとなってくれるのは前述の通りです。一方で、二次受けや三次受けといったシステム開発会社としてプロジェクトに入っている場合は、現状のウォーターフォール型開発だと、階層をのぼっていくのは難しいことも多々あります。
また、システムエンジニアから、さらに人を取りまとめるプロジェクトマネージャーやチームリーダーとなって、社会的にインパクトある仕事をしていくことができ、それで給料も上がることも多くあります。個人事業主ではなく、正社員であればプロジェクトは安定的にあるので、仕事がなくなるという不安も当面はないでしょう。他にも、Javaはスマホアプリを作ることが簡単にできたり、別のJava系言語にスムーズに移行できたりすることもJavaを基礎としてやっておくことのメリットです。
Javaを武器に仕事をするリスク
では、反対にデメリットといいますか、リスクもあることを肝に銘じなければなりません。Javaを使って仕事をするのであれば、大規模開発案件が多くなるので、メンバーとして加わると、あまりにタスクが分割されすぎて、そもそも何の機能をつくっているのかすら、自分では知らされない、そして理解できないということも多くなります。
さらには、Javaではインターネットが使えない現場まであります。仕事に集中して遊ばないようにするのと、プロジェクト機密を管理するためのものですが、これがある現場は、インターネット接続できないので、公式リファレンスすら読めなくなります。
ではどうやって実装するのかというと、自分のスマホで調べたり、本を読んだりして調査してください、というわけで、極めて非効率な仕事となってしまうのです。これは何も、Javaに限ったものではありませんが、Javaは大規模開発で多く採用されているため、一部にこういった現場もあるということです。
インターネットに接続しなければ、情報漏えいも起こらないし、エンジニアも働くだろうという考え方はとても怖いですが、中には、国家機密を扱うケースがありますので、そういったところはとてもセキュリティが堅牢になります。
加えて、Javaで開発を行う環境は、アナログなテスト環境であることも多くなっています。つまり、テストツールがあるにしても、Junitのみであり、デバッガにalert()をいれてデバッグするというプロジェクト現場異場も実際にあるのです。
では、どうやってテストするのかというと、画面のスクリーンショットをとって、手でエクセルに貼り付けし、画面を手で操作するというもの。こうした現場も、Javaでは自然にあります。
こうした現場の色に染まってしまうことこそ、Javaエンジニア最大のリスクとなります。時代が進化し、Webが発展し続けている中、いつまでもメインフレームやクライアント・サーバー時代のテスト方式や開発方式を引きずっているのが、このJavaにまつわる最大のリスクです。
なぜJavaにだけこうしたリスクが潜む？
こうしたリスクは、Javaの開発周りに多く潜んでいます。ではなぜ、Javaにだけリスクがあるのでしょうか？基本的に、いまはIT業界も人手不足で、いくら募集をかけても人が集まらないのが現状です。
よって、エンジニアは引きも切らないのに、なぜこうした劣悪な開発環境に人手が取られ、全体の生産性を押し下げているのでしょうか。
それは、やはりSIerを中心とした日本のIT業界全体が、ピラミッド型の構成になっており、システム開発がまるで建築業界と同じように、流れ流れて多重請負の構造になっているからだと考えられます。
つまり、SIerを頂点としたエコシステムに、Javaが組み込まれているケースが多いということです。これは、さまざまなデメリットを生みます。その結果が、Junitしかテスト環境がなく、自分でスクリーンショットを撮影してエクセルに貼り付けるテスターの存在といった、非効率に結びつきます。
従来は、こうしたエコシステムはCOBOL業界で行われていました。現在でもフリーランスエンジニが参画可能COBOL案件というのはあります。
なぜなら、SIer独自の雇用の問題で、COBOLエンジニアがあまっており、技術力を無駄にしないためにも、COBOLでの開発が続いているのです。
同じ現象が、Javaでもおきつつあります。メモリ管理が不要で、リファレンスがしっかりしていて、比較的“枯れた“技術であるJavaにおいて、時代に合致しないという現象がおきているのです。
ちょっと今回は、悲観的な観測になってしまいましたが、Javaはそれでも、スマホアプリを作れたり、Web時代に取り残されたりしないよう、アップデートが続けられています。よって、Javaを使った案件は当分はなくなりませんが、それでも、他の言語にも手を広げ、できることを増やして次の時代へのリスクヘッジをしておいた方がいいのは事実となります。
Javaだけでやっていくことには、一定のリスクがあるという話でした。繰り返しになりますが、言語が悪いのではなく、時代と合わなくなりつつあるのです。