もう一方の、今回お話をした話はもう少し大局的で、概念的なお話です。実際のところ、ここ数年でこういった話を聞く機会は少しずつ増えたものの、現場を見て回ればあまりそれらの知識が生かしきれていないようにも感じていました。今回の発表の趣旨はおおざっぱに言えば「便利なものをもっと使おう、そのために使える環境を準備しよう。あるいは使えるように交渉しよう」という内容でした。

前提として、よくあるトラブルシューティング／パフォーマンスチューニングの現場を説明しておきましょう。プロジェクトメンバーは多くの場合すでに多方面から時間的／政治的プレッシャーを与えられており時間的／精神的な余裕はあまりありません。新たなツールを導入するような時間もコストも許されず、対処方法は似たような事例をGoogleで検索する程度です。Googleで検索した情報がぴったりその状況を引き起こしている原因に当てはまれば良いのですが、それは一攫千金を夢見て宝くじを買いに走るのと同様、確率に身を委ねているにすぎません。Googleで検索した情報は既に現在のバージョンのプラットホームには意味の無い情報だったり、現在扱おうとしているトランザクションの性質と、検索で見つかったブログエントリーが問題としているトランザクションの性質が多くの場合違うからです。

では本質的に、問題を解決するためにはどうしたらいいでしょうか。問題を解決したり、あるいは本当に解決されたことを確認するためには問題の原因を探る必要があります。原因が分からなければ再現手順もわからず、解決したことを示してみせるにも説得力がありません。経験上、トラブルシューティングを行うときのほとんどの時間は問題の原因を探すこと、とくに問題を再現することに充てられていると言っても過言ではありません。問題の再現は、比較的簡単な場合もありますが、プロジェクトメンバーが時間的／精神的に追いつめられるほど深刻な問題の場合、問題の再現すら難しいというケースがほとんどです。

本番環境で発生している問題は、なかなかテスト環境では再現しません。データに起因する問題、ハードウエアやプラットホームの違いによる再現性の違いによって、問題の再現は困難を極めます。また、仮に似たような問題を再現できたとしても、それが本当に本番環境でおこっているトラブルやパフォーマンス劣化と同一なのか、確認することはきわめて難しいことです。こうした問題は、本番環境と切り離された環境、少ない情報で作業せざるを得ない環境特有の問題です。本番環境で直接プロファイリングをしたり、ログやダンプの設定を動的に変更したり、プローブを加えて仮説を検証することができれば問題の原因特定は飛躍的に効率的になります。

ツールを使うことを勧めると「はい、それはわかっています。しかし、xxxx」というような返答は常にあります。SOX、J-SOXなどをきっかけとした職務分掌／権限分掌の確立もより問題を複雑にします。?本番環境にデバッガやプロファイラが接続できればどんなにいいことでしょうか。そのシステムの設計や開発に携わったエンジニアであれば、いくつかの仮説を持って問題に取り組むことが出来ます。しかしながら、仮説を検証するためには情報を試行錯誤しながら集めなければならず、1ヶ月に1度しか変更の加えられないシステムに対しては仮説の検証も困難を極めます。

さて、だからといってこのまま闇雲に問題解決に取り組んだり、じれったい思いをしながら雲をつかむような思いでログをなめ回すことを続けるべきでしょうか？日本のエンジニアは勤勉で、優秀です。しかしながら、ツールが自由に使えないがために諸外国の経験の浅いエンジニアと同等の生産性しかだせないとしたらどうでしょうか。ツールが自由に使えるならば3日で問題が解決するにもかかわらず、ツールが自由に使えないがために最低2週間は問題の解決に時間を要するとしたらどうでしょうか。より安く、より速く問題を解決してくれる海外に頼りたくなるのが自然な思考です。多くの場合、スポンサーが有用性を理解していないがために非科学的に禁止されたツールの利用禁止は、そろそろ日本のエンジニアが主体となって、利用を認めるよう主張を始めるべきだと思っています。とてもおとなしい、主張しないエンジニアの言い分はいままでも、これからも認められていかないでしょう。経営や運営の立場をもつ人々の視点からみれば、そもそもなぜ問題の解決に時間がかかるのか理由もわからないまま、（多くの場合精神的なセキュリティーを根拠として）ツールなんて無くてもよいと思われているにすぎず、エンジニア側の主張がそもそも足りないのだと思っています。

もの言うエンジニアを増やそうという、主張ではありませんが、科学的に有益なものはもっと主張して、自由に使えるような環境を獲得する。これが、この先10年〜20年先に日本のエンジニアが職を失わず、また国際競争力をもちつづけられるための必須条件ではないかと考えています。以上が、発表でのおおまかな主張でした。小手先のテクニックと比べれば、こうしたもっと土台となる問題が、少なくとも前職Sunにおいて見えてきた、エンジニアにとって一番の問題解決の障壁になっていることだと思っています。

ライトニングトークです。去年に引き続きJavaOneに行かないままJavaOne報告をすることになったのですが、今年はAIR JavaOneと題してネット越しにJavaOneを楽しむ方法をご紹介しました。下記に参考URLをリストしておきます。

• 2009 JavaOne Conference Homepage – JavaOne公式サイト
• General Session Details and Video Plays – Generalセッションの録画
• JavaOne Online Technical Sessions – PDF化されたセッション資料。Hands On Labsの資料もあります。LTでも話しましたが、まとめてZIPでダウンロードするリンクがありますのでそちらをご活用ください。
• JavaPosse – 有名なPodcast

マイコミジャーナルに執筆されている杉山さん。プレスの立場での参加についてと、メディアのあり方について話されました。

技術評論社の馮(ふおん)さん。杉山さんと同様、プレスとしての参加について、メディアのあり方について。

続いて櫻庭さんより。今回のLTは固い内容が多かった、との話でした。櫻庭さんからはサンフランシスコ(というか海外に行くときの)での食事情改善方法について。ミシュランガイド、ぜんぜん使ったことありません。櫻庭さんが今回べた褒めされていたOpenTable。その日の予約を、Web上のみで完結できるというのがいいですね。ちなみに、OpenTableは日本版(東京)もあります。東京カレンダーとのコラボもしてるようです。

最後は太田さんよりCommunityOneスピーカーとして話された時のお話。

左からキムティさん、はっし〜〜さん、川口さん、きしださん、nekopさん。

金曜日はグラジェーの飲み会。

誰にTシャツを渡しているかすべて把握している寺田さんによってまだTシャツをゲットしていない方々にTシャツの授与が行われました。

二次会は会場探しに困りました。さすが金曜日・・。なかなか空いてません。

何とかは入れましたがぎゅうぎゅう・・。特に長身なnekopさんは窮屈そう。

土曜日はcero-tさんの川口さんを囲む会。飲み会5日目ということもあって、ほとんど記憶ありません・・。

二次会は中華料理店らしきところ。ドリンクの注文がうまく通りません。一つ確認に着たと思ったら、ひとつ忘れて帰るような感じです。でもあまりうるさくなくていいお店でした。
川口さんおつかれさまでした！

• エンジニアのための、キャッチコピーの作り方(PDF)

キャッチコピーの作り方、まだまだ勉強中ですが少しでもご参考になれば幸いです。

プレゼンのタイトルや、ブログのタイトルを考えるときいつも流行り言葉をちりばめるだけで満足していませんか？ バズワードに頼らない自分だけのキャッチコピーを考えてみましょう。

としてあります。きしださんのページにタイムテーブルの告知も出ていますが、18時35分頃から20分程度時間をいただけるようです。当初は15分ということでしたが、5分増えたことですこしBOF(Birds of a feather)らしく、双方向的なやりとりができたらいいなと思っています。BOF枠では、よういちろうさんのOpenSocialや、ヌーラボ縣さんのCubby、太田さんのHadoop+Lucene、水島さんのScalaなど、JJUGらしいテクニカルな話題が中心ですが、一つだけ息抜き程度にみていっていただければ幸いです。もっと息抜きしたい方はjava-jaによるライトニングトークがおすすめ。

さて、なんだかんだでイベントも来週に迫ってしまいましたが、その0で告知したとおりどういったことをしゃべるか、このブログでねたばれさせていきたいと思います。なお、プレゼンソフトを自作しようと思っていましたが時間の都合上、そこまではできないかもしれません・・。見栄えよりもコンテンツのほうが大事ですからね・・。背に腹は代えられません。
さて、今回のテーマはあえて技術ネタを外して、キャッチコピーの作り方としました。個人的にはいままでコピーライターとして働いた経験もなければ、マーケティングの仕事をしていたわけでもありません。ただ、全く知識ゼロということでもありません。

今年の4月から東京コピーライター養成講座という夜間のコースに通い始めました。別にこれもコピーライターに転職してやろうと考えて通い始めたわけではなく、たまたま手に取った宣伝会議のコピーライター、書く語りき。という雑誌に載っていたコピーライター向け教室の広告がきっかけです。この雑誌に載っていたのは、とうぜん宣伝会議の雑誌と言うこともあって宣伝会議の教育講座だったんですが、ぐぐって調べてみたところこの宣伝会議以外にも、いま行っている東京コピーライター養成講座(TCS)、というのがあるのがわかりました。場所が宣伝会議は青山、TCSは銀座ということで、土地勘のない銀座で開催されている方を選ぶことにしました(通えば覚えると思って)。

おおよそ半年通ってキャッチコピーについてわかったのは:

• キャッチコピーは作り込むことよりも、発見することを大事にする。

ということです。キャッチコピーのようないわゆる宣伝文句は、ウケをねらっていろんな要素を詰め込みたくなりがちです。たとえば、「Web 2.0時代のクラウドコンピューティングによるSOA基盤のデザインパターン」とか。場合によってはさらに「かんたん〜」とか、「最新〜」と形容するかもしれません。それはそれで一つの方法ですので強く否定はしません。でも、より効果的なのは多くの場合、広告ターゲットとなる人々にとってより共感でき、具体的なイメージのわく言葉です。そういった言葉は、設定したターゲットの人々が何に共感しそうか、また、それは具体的に何か？といった疑問の答えを探し求め、発見する作業です。(最終的調整はするにせよ) 単に流行言葉をちりばめて表現をかっこよくしたり、ウケそうな言葉を付け加えるような作り込み作業とはアプローチがかなり違います。

共感を得る言葉というのは、意外といろんなところに落ちているんですが、それらをピックアップしてキャッチコピーにするのはやってみるとなかなか難しいことです。たとえば、クラウドコンピューティングを説明したいときに、「クラウドコンピューティングとは」というようなキャッチコピーよりも「クラウドコンピューティングって何に使うの？」のようなある素朴な疑問の方が、クラウドコンピューティングの内容をよく知らない人にとっては共感が得られやすいと思います。共感が得られて、具体的で、かつ、訴求したいポイントともよく合致するような表現はなかなか難しいことです。そりゃ、コピーライターというプロの職業が成り立ってるんだから、素人の私たちがやるのは難しくて当然。ただ、プロのコピーライターと比べて我々のアドバンテージは、これならエンジニアに共感が得られそうだ、という感覚がプロのコピーライターよりも敏感に感じられることです。今回のBOFではたった20分しか時間もありませんが、このあたりのディスカッションが少しでもできればいいなと思っています。

GlassFish で、作ってみた。

岡崎 隆之 (Glassfish ユーザ・グループ・ジャパン)

最新 GlassFish は単なる Java EE 実行環境ではなく、多彩な機能が盛り込まれた遊べるアプリケーションサーバです。
今回は開発の実演を交えながら、Java はもちろん、JRuby での開発に便利な機能をご紹介します。
この秋は、思いっきり GlassFish で遊んでみましょう!

(写真は先月のJRubyとJythonのJJUGクロスコミュニティーセミナーの様子)