山本大＠クロノスの日記

８つの質問で、Java SI業界の現状を知る

Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。
SIの産業の人材動向が、今どうなってるかって？

大方の予想より凄惨ですよ。

それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。
SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。
対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。

その８つの質問というのはこんな問題だ。

JavaWeb技術者に技術力を問う８の質問

1. インターフェイスのメリットを一言で表して下さい。（筆記解答）
2. HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答）
3. Sessionのスコープを端的に説明してください。（筆記解答）
4. JNDIを使ってJDBCデータソースを取得するためのコードはどれですか？（選択解答）
   1. DataSource ds = (DataSource)new InitialContext().lookup("java:comp/env/jdbc/SampleDS");
   2. DataSource ds = (DataSource)new InitialContext().getDataSource("java:comp/env/jdbc/SampleDS");
   3. DataSource ds = (DataSource)new JNDIContext().lookup("java:comp/env/jdbc/SampleDS");
   4. DataSource ds = (DataSource)new JNDIContext().getDataSource("java:comp/env/jdbc/SampleDS");
5. 結合テスト中のシステムで、OutOfMemoryErrorが発生しました。UT後ソースコードの変更はしていません。ヒープメモリは足りているようです。原因として何が考えられますか？（筆記解答）
6. String オブジェクトを+で結合するのはなぜNGなのかメカニズムを説明してください。（筆記解答）
7. HTTPでクライアントブラウザの種類などの情報を知るためのヘッダは何ですか？（筆記解答）
8. JavaScriptでHTML要素をid属性の指定により取得するメソッドは何ですか？（筆記解答）

過去に実施した平均点

この８問について、僕が出会ったエンジニアに解答してもらった平均正解数は、
なんと８点満点中１点である。

内訳的な話

うろ覚えになってしまってるだろうから満点は無理でも、ちゃんとJavaをやってるエンジニアさんであれば4問は解けるだろう。
筆記解答については相当甘くつけるから尚更だ。
例えば、１問目「インターフェイスのメリット」は、「疎結合の実現」ならニジュウマルだが、「層ごとの役割分担」でも「仕様の強制」でも「ポリモフィズムの実現」でもマルで、それらに類する説明ならちょっと分かりにくくても、なんでも正解にしてる。

OutOfMemoryの問題は、経験していなかったから知らないから何も言えなくてもまぁいいだろう。
（10年やっててもOOMの込み入ったトラブルを経験しないなんて運がいい人なのだろうか、悪い人なのだろうか）
「getElementById」なんてほとんど白紙解答。
「Stringはおまじない的に＋でつなげちゃダメと思うようにしている」
「StringBufferを使うべきと教えられたから」
そんな状況である。１、２年目ではなく３−１０年生であり、PGバリバリとの触れ込みなのだ。
設計やチームリードやコミュニケーションを得意としている人ではない。プログラマー対象なんだぜ。
（ウチの会社では平均５.５点ほどあった。これは基礎教育をやってれば当たり前の点数だろう）

これぞ現在のSI業界の実態

でも僕は、ここ数年東京でSIのエンジニア提案などの営業をやっていた経験から納得がいく。
これぞ「労働集約産業である現在のSI業界の実態」なのだから。

基礎教育なしに、１年目0円でテスト要員→２年目ちょっとPHPとか→３年目Java
仕事と割り切った中で、フレームワークに乗っ取ったコードを書き続ける→その後10年経過
という流れのキャリアパスを通ってきた人に山ほど出会ってきた。

そういう人ほど、この業界で生き残っている現実ではないか。

淘汰の進まない業界

統計としては母数が少なすぎる（２桁程度）「し」、母集団を変えれば別の所感が得られるだろう。
しかしながら、ヤバいのは淘汰が進まない事だ。
特に東京は仕事量も多いから、こういうレベルの人でも危機感なく生き残ってしまう。
このところ景気がいいせいもあって、正解数1問だった人もすぐに稼働現場が決まって行ってるようだ。
こういうエンジニアたちが大勢集まってシステム開発をするのだ。

結果として、一部の出来る人には余計に負荷がかかるだろうなと思う。

いままで僕は楽観主義者だから、

SIは労働集約産業だったけど、これからは知識集約産業になっていく。
必然的に淘汰の時代になり、優秀な人が生き残るだろう。

と思っていた。

しかし現実は、もっと凄惨な世界を経て時代が進んでいくようだ。

蛇足な追記

ブクマとかで8つの質問に答えてくれる人がいたり、いろいろ言う人もいるので御答えします。

「Stringを+で連結しても、一行で書かれていればコンパイラが最適化してStringBuilderに置き換えますよ。」系の答えをしてる人は、良いとこ行ってるけど残念ながら0.5点。
こういう人は、現場で直面してないし机上で知ってるレベルだ、
デコンパイルしたり、現場で直面したりすると如何にJDKの最適化が大した事ないか思い知る。

例えばこの程度のコードをデコンパイルしてみる。

public class Main {
	public static void main(String[] args) {
		String s = "";
		for(int i=0;i<10;i++){
			s = s + i; 
			System.out.println(s);
			
		}
	}
}

JDK7でコンパイルしてデコンパイルするとこうなるんだぜ。結局+の動きなんだよね。

import java.io.PrintStream;

public class Main
{
  public static void main(String[] args)
  {
    String s = "";
    for (int i = 0; i < 10; i++)
      System.out.println(s + " Hello");
  }
}

でもこのレベルのコードの統制は、いまのSIのエンジニアレベルでは効かない事を見越して、悪と断じるなら３点あげるね。
メカニズムを質問してるのに真正面から回答してないのもマイナス点。
１行内のString＋なんてそもそも問題にならない。それはメカニズムを知ってこそわかる。


5番目の問題はやや難問。コメントで「ループ処理もしくは再帰処理内でオブジェクトの生成が原因かも」と答えて頂いたが、これは非常に惜しい。
ヒープは足りてるというのがミソであり、OOMが出てるのもミソ。
ヒープは足りてるのでヒープのリーク系は軒並みアウト。
再起が走りすぎてる系は、StackOverFlorwが先に出るのでアウト。
この問題は、JSPをやたら使うシステムで、JVMメモリ管理をうまくやってないか、
S２のホットデプロイとJenkinsなどのCIをやると直面する問題。

ヒントはPermanent領域。



次、「SIをプログラミングと思ってるわけか。」系は、単文すぎて意図は読みかねるけど僕は、プログラミングの最低レベルを切ろうと思っている訳で、ソリューション分析や設計の価値は認めてる。でもソリューション提案するにしても机上の空論が多すぎるでしょって言いたいし、ソリューション提案や設計などの価値あるビジネスを否定している訳ではない事を読み取れないレベルの人はプログラミングよりももっと高度な、ビジネス上の価値を読み取れるはずもないので、去ってほしい。


「ググれば良いじゃん」的な回答の人は、ググったことあるけど頭に残ってない系であることを宣言してるにすぎない、
同じ事案にたいしても毎回ググっちまう非効率の権化。
僕は、覚えてることを相互的に脳内でシナジーをあたえ価値を生み出すことが人間の人間たる価値だと思う。
ググるにたよるやつこそ、労働産業の申し子なので、そこで留まってて問題ない。


８問目がJavaScriptなのは、意図的。Java経験者でもJSをやってない人はめちゃくちゃ多い。
僕からするとJavaでバッチだけやってましたはJava経験者とは言わない。
だから、あえてJSの問題を入れる。だってJavaやっててJS触れてないっておかしいでしょ。
僕はこの８問でJavaWeb技術者を診断したくて、OCJ-Pをやりたいとは一言も言ってない。


「言語非依存の設計ができる方が大事そうだが。」ってブコメきたけど、、、「言語比依存の設計」の価値って、「言語を考慮した設計」の価値を超えます？僕は少なくともパフォーマンス面で超える気がしないけどな。

ツイートする

Permalink | コメント(5) | トラックバック(3) | 17:44