今年度、部内で取り組もうとしている大きなテーマとして
・営業系システム開発の標準化
があります。ざっくり言えば、よくある「開発効率を向上しよう！」というものです。
私の属する部隊では、主に製造業のお客様向けの営業系基幹システム開発を担当しています。
開発は基本的に毎回スクラッチで行っているのですが、マネージャ層では頻繁に「今回の案件は、XX案件と似てるので、あれをベースにすることで短納期・高品質で作れるだろ？」という話がでてるようです。
けれど、現実的には結局スクラッチ開発になっていて、納期厳守や品質確保に残業続きというのが実態です。
理由は色々あるけれど、結局の所「改造するくらいなら新規に作ったほうが楽だ」という結論に至ることが多いのです。
問題は明らかで、開発の初期段階で他のプロジェクトでも使いまわせるような設計や作りをしていないこと、開発を外部に委託するケースが多いこと、等なのですが、納期の絡みが根本にあり、中々この習慣が変えられず、最後はそのシステムを動かすので精いっぱいとなってしまいます。
で、今年度こそ！と奮起した私のチームのマネージャさんにより、部内の一部システム開発の標準化を試みる流れが本格化し、私もその一端を担う形となりました。
私自身としては、この取り組みは大賛成ですが、現実的にはBrooksさんの「銀の弾などない」を思い出すような難しさがあって、どの辺りを落としどころとするか、が大事だと考えています。
……
…
で、この標準化はWeb案件が対象となりました(最近多くあるため)。
じゃあ当然ASP.NETか。と構えていたのですが(今までずっと部内は.NET C#だったため)、なんと、Javaでやってみないか、とのこと。
元々マネージャの方自身がJava好きだったことと（笑）、色々な案件でIISに苦しんだことがあったためのようです。これは私自身も苦しんだ経験があり、新しいものをやってみる価値はあるなと思いました。
一方で部長は「なぜ今までの経験値・資産を捨てるんだ」と、ある意味もっともな批判をされていて、未だに微妙なのですが、まずはJavaの情報収集とプロト開発をやってみることになりました。
で、8月頃から私のほうでOracleさんのセミナー行ったり、金魚本やその他海外のJavaEE本を読んだりしつつ、9月に入って、実際に後輩とプロト作りを初め、今に至ります。
長々と書いてしまいましたが、その状況報告を今月末の部会で行うことになり、プロトのお披露目と共にJavaEE6を（開発者に受け入れてもらうために）紹介することになり、どういう流れで紹介するかあれこれと考えている次第です。
標準化の取り組みに関してはおそらく皆が共通認識しているので、あまり問題なく
・今までの開発の問題（毎回フルスクラッチで大変ですよね）
・各プロジェクトで使いまわせるようなものを作りましょう（そして残業減らしましょう）
という流れで受け入れてもらえるものと思います。
が、多分「標準化はJavaEEでやります」と言ったら、一部の人は「は？」となるのではないかと。
実際に、室内の若手は「マルチプラットフォームという観点以外、Javaの利点を感じません」などとエンジニアとしては仰天するような発言がありました。
この若手は(何でか知らないけど)非常にMicrosoft好きで、C#一本の人。
それだけに、触った経験もないプログラミング言語を知識だけで批判するなよ、という想いがありました。
彼は情報系出身ではない（というかうちの部はほとんどがそうなのだけど…）ためか、会社に入ってから初めてプログラミングをして、オブジェクト指向を覚えて、という流れなので、まあ仕方がない気もします。
自分は大学が工業系の情報学部だったためか、PC環境がSolarisとMacしかない、という不思議な環境で育ちました。
さすがに大学4年生くらいになった頃、WindowsXPが大学環境にも導入されていましたが、それまではUnixメインでした。
プログラミングもC言語から入り、Z80アセンブリ言語を学び、そこからLisp、Prologを触りました。
当時は構造化プログラミングでもいっぱいいっぱいだったのに、Lisp、Prologと不思議な言語(関数型,論理型)を経験したため、「うへっ、こんな世界があるんか」と驚いた覚えがあります。で、大学院に入ったときに初めてオブジェクト指向言語Javaを知りました；
なので、会社に入ってC#メインになって、それはそれでよくできた言語なので好きなのですが、たまには違う言語もやりたいよなぁ、とか思うことがしばしばあったので、今回のマネージャのJava提案は個人的に「よっしゃ」というものでした。
……
…
で、本題の「標準化はJavaEEでやります」をどうしたら賛同集まるのか。興味を持ってもらえるのか。ここが本当に大事になりそうです。
私としてはASP.NETを使うことに対して全く問題はないと思っている(部として経験も豊富だし)ので、単に部内で扱える技術としての選択肢が増えるのはいいですよね〜、くらいに言いたい所です。実際にそう思ってるし；
ただ標準化をJavaEEメインで行うとなると「なんだ、じゃあこれから俺たちはJavaEEメインになるのか？なんでASPでやらないんだ。新しく学習するの大変じゃないか」という声が予想されます。
うーむ。これも一理あります。
実際、JavaEEを使うのは初めてなので、開発がASPと比べて効率よくなるか、運用がIISより安定するか、やってみないとわからない部分があるため、難しいです。「真面目にやって、楽をしましょう！」という取り組みが全員を苦しめる結果になってはあまりにも悲惨で、そう考えると責任は重いなと…。
多分ネックになるのは
・学習コスト(主にフレームワークとしての ASP.NET vs JavaEE)
・C#言語仕様 vs Java言語仕様
・VisualStudio vs NetBeans(or Eclipse)
・IIS vs GlassFish
・O/Rマッパーの賛否
の辺りかと。
プロト開発で初めてJavaEEを触りましたが、JSF、JPA、EJB…と色々概念が出てきて最初はちょっと面喰いました。
周囲に有識者がゼロ、というのが一番辛かったですが、海外には情報が豊富にあったので良かったです（国内に少ないのが微妙ですが…）
先日マネージャにプロト報告した際には、新しいフレームワーク、言語を使って2ヶ月程度でこのレベルを作れるようになったのは良いことじゃないか、と言って頂き、確かにそうなのかなと。
開発を通じてある程度知識もついたので、あとは共有すれば、最初の壁は払える気がします。
そういった意味でも間違った知識を展開しないように気を付けねば…と気が重いのですが。。。
また、一緒に開発した後輩をみていると、言語仕様に関してC#からJavaへは特に抵抗がなさそうでした。自分もですが。
最初はDIが不思議で、@Injectを書くだけでnewしない、という感覚が不思議でしたが、今は慣れました。そして、設定ファイルだけでインジェクトする中身を変えることができるなど、やっとnewしない嬉しさがわかるようになりました；
DI、AOP辺りは.NET系にはまだない（はず）ので、開発上の優位点かなと。
ただ痛いのは、C#にあるDataSetやDataTableクラスがJavaにないことですね。
JPAを初めて使ったとき、Entitiyまるごと取得の際は問題ないのですが、JPQLで複数テーブルのJoinクエリ等を書いたときに、戻り値がListとなるのが「えっ…」と思いました。DataTableだったら最高なのに…ここはC#派から色々言われそうです。
IDEに関してはやはりVisualStudioはよくできてるので、中々難しい所ですが、私自身NetBeansを触れた感想としては、非常によくできていて、「これが本当に無償なのか…すごい」と思いました。VSと比べても大きな違和感はない気がします。
先読みに関しては細かい点では微妙な所（例えば、Beansでbooleanを返す関数名をisXXXとしたときに、JSFのEL式で参照しようとすると、作っていないはずのprivate変数がXXXでみえてたり…）がありつつも満足いくものだし、デバッグのブレイクポイントもほぼ文句ないです（EJBの@StartUpモノでブレイクポイントが止まらないのだけは辛い；）。
あとウォッチに関しては、入れたはずのprivate変数値がnullになってて、あれ？と思ってgetterでみると値が入っているケースがあって、たまに辛いときがあったり。
こういう細かい所で微妙なものはありますが（でも意外と大事だったり）、それでもVSに勝る点も多々あるかと。
例えば、NetBeansのプロファイリング機能は素晴らしく、これは絶対VS派にもおすすめです。
なんといっても、VisualStudioはEditionによってプロファイリングできなかったりするので。お高いEditionならできるという何ともビジネスライクな開発環境です。
IDEに関しては、ベテラン陣からすれば「お前らはIDEが当たり前だと思ってる。俺らはエディタだったぞ」という方もいますので（笑）、まあIDE育ちの若手と真面目に議論するのがいいのかなと。
あと全然本質的ではないですが、ねこびーんが非常に女性受けがよく（笑）「かわいー」といって興味持ってくれます。
IISとGlassFishは比較するのも何かヘンテコなんですが(というのも、IISと比べるならWebコンテナのApache Tomcatであってアプリケーションサーバとはちょっと違うのかなと)、GlassFishの管理コンソールは便利だし、あとは細かい設定方法や内容を1つ1つ把握すればいいのかなと。ミッションクリティカルなシステムを想定して是非WebLogic等も触ってみたい所。
最後のO/Rマッパー。これが結構難しい。
もはやこれはASPどうこうより、SQL派との議論かと。
業務システムは最終的に性能問題に行き着くことが多く、今までも非常に苦労してきました。
WANによる遅延なども問題ですが、やはりSQLが問題になることも多いです（インデックスつけてるのに、効かないクエリになってるとか…）。
まあ、この辺りは、O/Rマッパーが実際に発行するクエリをしっかりチェックして、explainで分析するなどすれば問題ない気がするし、最後の最後はNative Queryもあるので今の段階ではあまりネガティブではありません。
クエリ職人的な人はJPQLを受け付けない可能性もありますが、今までの開発で他プロジェクトに使いまわせない原因の１つとしてSQLがあるのも事実です。
SQL規格がありつつも、最終的には各DBベンダによってクエリに差異があるので。
これに関してJPQLは1つの解を与えてくれている感じがします。実際にプロト開発では、初期にApache Derbyを使っていて、途中からMySQLを使いましたが、設定ファイル変えるのみで、コードに手は入りませんでした。
まあ実際にプロジェクトが異なってスキーマが一緒というケースはほとんどないのですが、それでもクエリを参考にする場合、JPQLで統一されるのはありかなと。
こういった辺りを上手く説明したい所です。
なんかダラダラ書いてしまった。こういうことを考えながら、やわらかいプレゼン資料作らないと。
