Javaの生産性が思ったよりあがらない理由

　未だに Java は生産性が低いと思っている人を見かけます（人によっては「この人、まだ Java の生産性は悪くないって言ってるよ」って言うでしょうけど）。私の周りのそういう人に見受けられるパターンを書いてみたいと思います。

Java をちゃんと身に着けていない

　「簡単に身に着かないなら、学習コストの分、生産性が悪いじゃないか」と言われるかもしれません。確かにそうです。ですが、Java がエンタープライズ用途に使われるようになってからいったい何年経ったでしょうか？　それは、COBOL に比べたら赤ちゃんみたいなものですが、学習コスト云々というほど新進気鋭の言語ではすでにないはずです。

　以前、「C++ が難しいのはなぜか？」という話があって、「それは、Microsoft Visual C++ で学習するからだよ。そういう人は、C++ の文法と MFC と Windows API を同時に覚えようとする。そんなにいっきに勉強しても身に着くもんじゃない」といった人がいます。Java もそれに近いことが言える現場が少なくないようです。たとえば、「Java の文法と Struts と HTML と HTTP」を同時に学ぼうという人がいます。そんなのかなりの天才肌でなければ無理です。どれもいい加減な習熟度で終わり、考えるスピードでコーディングを行うようなことはまず不可能です。

最適なフレームワークを選定していない

　Java はエンタープライズ用途によく用いられます。そうなると開発規模も大きくなり、大手 SIer が幅を利かせてきます（笑）。そうすると、その大手 SIer の製品（しかもマイナー）であるトンデモフレームワークを使用するはめになったりします。これがかなり危険。万能なツールなんて世の中に存在しません。

最適な開発ツール（IDE）を選定していない

　前項のトンデモフレームワークが提供するしょぼい IDE を使ったり、Eclipse を効果的に使ってないという場合が多いです。未だにテキストエディタで開発している人すらいます（それはそれでいいのですが、それで生産性が悪いと言わないで）。

技術責任者がいない

　これは Java に限ったことではないのですが、私がさまざまなプロジェクトでいかがなものかと思うことは「技術責任者」の不在です。これは、プログラマの次のキャリアパスが SE という日本の IT 界の習慣の弊害だと思います。ここでいう SE とは、お客さんと折衝してシステムの大枠の仕様を作ったりする立場の人です。
　問題は、技術力のピークがこの SE にないということです。SE にあるのは過去の経験からくるものであって、現在の技術をプログラマ以上に知っている SE は皆無と言えるでしょう。しかしながら日本のプロジェクトでは、プロジェクトの舵取りをするのは SE です。業務要件をまとめてどのような仕様にするのかは彼らが行ってもいいでしょうが、実装方法まで彼らにやらせるとどうしても少し時代遅れな物となります。しかし、プログラマが SE の下であるという今の日本の構造では、プログラマが意見し、それが大きくプロジェクトに反映されるのは難しいと言えるでしょう。
　そこで私が提案したいのは、「技術責任者」のポストを置くことです。技術責任者は、発言力では SE 並みであり、もっぱら技術面からプロジェクトを牽引する立場の者です。最近では、CTO（最高技術責任者）というポストを設けている会社も増えてきましたが、このように技術的な責任者は必須だと私は考えています。
　データベースやプログラムの構造が悪くてパフォーマンスがあがらない、セキュリティホールを大量に作りこんでいるのを後から気づいたなど、技術的な問題の解消のために余計な工数がかかりデスマーチになるパターンは少なくありません（むしろそれが一番多いような……）。これを解消するリーダーの設置こそが生産性の向上（というか本来の生産性の発揮）に不可欠でしょう。