ところで、今回のイベント中、メモがてら現地からTwitterで実況中継をしていたのですが、それを @hishidama さんが Togetter にまとめてくれました。本原稿を書く際にこのまとめは非常に役に立ちましたので、ここでお礼を述べたいと思います。

• Scala Days 2011（1日目）
• Scala Days 2011（2日目）

　今回は予告どおり、Akkaの話を中心に書こうと思います。

■Akka

○並列・分散時代の高機能ライブラリ

　今回のScala Daysではconcurrencyというキーワードがかなり強調されていて、それに関連するセッションも多くみられました。Scalaの開発側としては世間で耳目を集める「concurrency」に対する答えとしてScalaを普及させていきたいという考えが見えました。また、Scalaを使う側としてもその部分に注目して使っている人が多いように思えます。

　Akkaに関して簡単に説明しますと、AkkaはもともとScalaとJavaで使える汎用ライブラリで、以下のような機能を備えています。

• Actor (含Remote Actor)
• STM (Software Transactional Memory)
• Agent

　各機能に関してはAkkaのWebサイトを見ていただきたいのですが、分散環境で必須となる耐障害性、負荷分散が組み込まれた高機能なライブラリとなっています。

　前回も少し書いたとおり、Scala界隈では約1カ月前にScalaの開発チームが中心となってTypesafeという会社を立ち上げたというニュースが話題になりましたが、そのTypesafe社にAkkaの開発チームが参加していることから、今後はAkkaの機能がScala本体に取り込まれていくものと思われます。

　さて、今回Akka関連のセッションは3つあったのですが、そのうちの2つを見てきました。

○Above the Clouds: Introducing Cloudy Akka

　「Cloud」に対応したAkkaの紹介、という感じでしょうか。内容としては最初の10分くらいはAkkaの基本的な機能のうち「分散」に関連するものの説明でした。この辺りはAkkaのサイトにあるドキュメントを読んでいれば知っている事なので、特に目新しいことはありませんでした。

　その後Akka 2.0で導入予定の新機能についての紹介があったのですが、こちらはかなり期待できそうな内容でした。

　ところで、Actorに関してご存じない方もいらっしゃるかと思いますので、ここで簡単に説明します。Actorとは、他からメッセージを受け取ってそれに応じて処理をする、1つの独立した処理のユニットです。Actorの利用者はActorに対してメッセージを投げ、結果が返ってくるまで待ってもいいですし(同期処理)、非同期で後続の処理に進み結果が返ってきた時点でそれに対する処理を実施する、ということもできます。

　Javaで並列処理を書こうとすると、 生のスレッドを直接扱う事が多いかと思いますが（※）、Actorモデルの場合、Actorでの処理は自動的に別スレッドで動くことになり、抽象化のレベルが一段階高くなっています。スレッドを意識しないことにより、簡潔かつ安全な並列処理が書けるようになる事が期待されます。

※その他、EJBで処理を記述してアプリケーションサーバーのスレッドプールで並列化する方法などもありますが。

　また、AkkaのRemote Actorは、その名の通りActorを分散環境で実現したものですが、プログラマーはActorがローカルにあるのかリモートにあるのかを全く意識せずに扱うことが出来ます。ノードへのActorの割当て、フェイルオーバー、ロードバランスなども下のレイヤーで行われるようで、プログラマとしては分散処理を行うシステムを従来より楽に作れるようになると思われます。

　なお、本稿執筆時点ではScala Days 2011の公式サイトには発表者のスライドやビデオがアップされていないのですが、このセッションのスライドは（本人の？）Dropboxにすべにアップロードされていましたので、リンクを紹介しておきます。

　実は、先日Scala勉強会で時間をいただいてこのセッションの紹介をしたのですが、その時に

　「Message Driven Bean（MDB）とどう違うのか」

という質問がありました。先ほどの資料を見てみると、Akka 2.0で実現しようとしている機能のうち、Java EEアプリケーションサーバーやその他のミドルウェアで実現している機能と重なる部分が結構あることに気づきます。

　複数の選択肢の中からある1つの技術を選択するというのは、色々な要素が絡んできますし知識と経験が求められる所だと思いますが、Akka 2.0に関しては今後もう少し調査して、使いどころを見極めていきたいと考えています。

○The Promising Future of Akka

　こちらは前のセッションとは打って変わって、プログラミングに関するもので、"Future"というクラス（正確にはtrait）に関する説明・紹介でした。

　FutureはAkkaのActorを使用したプログラミングの際によく出てくるもので、Actorに対してメッセージを投げると（正確には !!! メソッドで投げた場合）Futureクラスのインスタンスが返されます。名前から想像できるとおり、将来Actor側での処理が終わった段階で、Futureクラスには処理結果がセットされます。

　これを使用すると、例えば2つのActorに異なるメッセージを投げて、2つの処理が完了した時点で次に進む、というような処理が簡潔に記述できます。（上述のAkkaのドキュメントから例を抜粋します）

// 以下の2行はnon-blockingな処理
val f1 = actor1 !!! msg1 // actor1 に msg1 を投げ、Futureを得る
val f2 = actor2 !!! msg2 // actor2 に msg2 を投げ、Futureを得る

// この時点では actor1, actor2 の処理は終わっていない

// f3 は actor3 にメッセージを投げた結果のFuture
val f3 = for {
  a: Int    <- f1  // actor1 からの処理結果を a に入れる
  b: Int    <- f2  // actor2 からの処理結果を b に入れる
  // actor1, actor2 の処理が終わった時点でactor3 に a+b を投げる
  c: String <- actor3 !!! (a + b)
} yield c

val result = f3.get() // actor3 の処理が終わった時点で、result に結果が入る

※ソース中のコメントは筆者が入れたもの。間違いなどがあればご指摘ください。

　ActorやFutureを使用したプログラミングは従来のプログラミングスタイルと異なる部分も多く、これも「パラダイム・シフト」の一つなのだと思います。我々プログラマとしては、そうした変化に付いていかないと仕事が無くなる確率が高くなるので、日々勉強が必要だと感じました。

■その他のセッション

　最後に、Akka以外のセッションもいくつか紹介します。

○Rogue: A Type-safe Query Language for MongoDB

　ここ1～2年でRDBMSではない新しい形のデータストアが注目されていて、それらはまとめてNoSQLと呼ばれている事はご存知だと思いますが、MongoDBはその中でもドキュメントDBと呼ばれているものの1つです。

　MongoDBの主な特徴としてはスキーマレスで、データはJSONを拡張したBSONという形式で保存されます。ただ、「スキーマレス」とは言え実際に使う場合には何らかのモデルクラスを用意して扱う事が殆どですし、データ自体は何らかの構造を持っているはずです。Rogueはそうした構造化されたデータに対して、型安全な形で問い合わせなどを行うためのライブラリ(DSL)です。

　Rogueを作ったのはFoursquareの開発チームなのですが、本発表はFoursquareの開発リーダー(細かい肩書きは忘れました)のJorge Ortizさんが行いました。

　スライドはSlideShareで既に公開されています。

　上述のスライドからの例を引用しますが、以下のようなデータの場合を考えます。

{
  "_id" :
    { "oid" : "4ddbd194686148110d5c1ccc" },
  "venuename" : "Starbucks",
  "mayorid" : 464,
  "tags" : ["coffee", "wifi", "snacks"],
  "latlng" : [39.0, -74.0]
}

mayoridには整数のみ、venuenameは文字列のみが入って欲しいところです。それに対して、Scala側で以下のようなスキーマを定義する事により、型安全な問い合わせが可能です。

class Venue extends MongoRecord[Venue] {
  object _id extends ObjectIdField(this)
  object venuename extends StringField(this)
  object mayorid extends LongField(this)
  object tags extends ListField[String](this)
  object latlng extends LatLngField(this)
}

　私自身は実際にMongoDB + Rogueは使ったことないのですが、Rogueのコードサンプルを見る限りでは非常に使いやすいライブラリのようですし、他の言語でのコードと見比べても型安全かつ分かりやすいという点で、他の選択肢に引けを取らないように見えました。MongoDBの使用を検討している場合にはScala + Rogueは選択肢に含めてもいいと思います。

　また、MongoDBは日本のコミュニティも積極的に活動しているようです。何かあったときに誰かに聞けるというのはある技術を選ぶ際の大きな要素ですので、Scala + MongoDB + Rogueという組み合わせは今後注目していきたいと思います。

○Node.scala - Implementing Scalable Async IO using Delimited Continuations

　ここ最近各所で話題になっているnode.jsですが、Scalaで似たような事をやってみました、という発表。

　非同期I/O＋イベントドリブンというのはnode.jsと一緒ですが、それにScalaの限定継続を組み合わせることにより、node.jsのような機能を見通しがよいコードで実装できるという内容でした。

　本プログラムはまだ実験段階のようですが、Scalaという言語自体の潜在能力の高さを証明していると思います。

○Porting my own programming language Onion's code from Java to Scala

　日本人唯一の発表者である水島さんの発表。彼が作ったオリジナルのプログラミング言語であるOnionをJavaからScalaに移植する際に発生した問題点や解決方法について発表しました。

　Onionは型推論を備えた静的型付け言語で、Javaのバイトコードにコンパイルされるとの事で、Scalaと似た面が多いとも言えます。ソースはこちらで公開されています。

　同時間帯に行われていた別のセッションが注目を集めるような内容だったため、残念ながら聴きに来た方は少なかったのですが、このようなプログラミング言語を作ることは、プログラミング言語、JVMの仕様についての高度な理解がないと難しいですし、研究としては面白い内容だと思いました。

　ただ、水島さん本人も仰っていたとおり、昨年に比べて今回のScala Days 2011は実用的な側面に焦点を当てたセッションが多く、参加者の多くもそうしたものを期待していましたので、研究寄りのセッションの発表者にとっては若干厳しかったようです。

○Managing Binary Compatability in Scala

　1日目のKeynoteでもScalaのバージョン間でのバイナリ非互換についての話があり、バイトコードの非互換を検知してそれを書き換える事によって互換性を持たせると言っていたのですが、2日目のこのセッションではそれを実現させるための具体的な方法に関して説明があったようです。

　私は本セッションは聞いていないので、後日公開される予定のビデオを楽しみに待とうと思います。

■2日間の感想

○Scalaを「どのように使うか」という段階に入っている

　いくつかのセッションの所でも述べた通り、海外ではScalaを単に使うだけでなく、「どのように使うか」、「他の技術に対するアドバンテージはどうか」と言った話が話題の中心であり、日本より少し先を行っているという印象を受けました。

　日本でも徐々にScalaの適用事例が出ているようですが、今後さらに事例が出て来る事を期待すると共に、そうした情報を積極的に公開していってもらえればと思います。よく例に出されるFoursqureは、Scalaを使った開発を行って事例を随時公開すると共に、前述のRogueのようなオープンソースソフトも公開してコミュニティに貢献していますが、そういった面も期待したいです。

　私自身の話をしますと、Scalaは実験的なプロジェクトでしか使っていないので、今後は実際のプロジェクトに適用していき、成果をコミュニティにフィードバックできるようになりたいと考えています。

○Scala, Akkaは要注目の技術

　昨年のScala Daysと異なり、「実用的」な点を強調したセッションが多かったと書きましたが、サーバーサイドを中心にScalaは一気にブレークしたという印象があります。初日のKeynoteでOdersky博士も触れていた通り、Scala関連の書籍がここ1年で随分増えてきており、日本語の書籍だけでも10冊近く出ています。

　Scala関連の求人はまだまだ少ないですが、ここ最近は順調に伸びているようですし、今後も注目していきたいと思います。

　そうした賑わいを見せるScala関連の中でも、とりわけAkkaは注目に値すると思います。上の方でも触れたとおり、Typesafe社のリソースの約半分をAkkaに投入しているそうですが、並列・分散に対するニーズの高まりの中、Akkaに対する期待は高まっているようです。

　実際、Scala Days 2011でのAkkaに関するセッションは部屋がほぼ満員になってました。また、上で少し触れたScala勉強会 in 秋葉原でも、Akkaに関して興味を持っている方が多いようでした。

○日本ではあまり話題になっていない技術に触れられた

　具体的にこれ、という名前は挙げませんが、日本では殆ど注目されていない技術をいくつか知ることが出来たのも良かったです。恐らく、日本にいても色々アンテナを張っていればそうした情報に触れられたのかもしれませんが、日本のトレンドと海外のトレンドが違うことが往々にしてありますので、たまに海外の状況を見に行くというのはなかなか有意義だと思います。

■まとめ

　Scala、アツいです。日本でも海外でも。

　Scalaは日本のコミュニティもそこそこ活発なので、まだ試していない方は是非体験してみて下さい。日本の各所で勉強会が実施されてますので、都合が付けば参加してみてはどうでしょうか。知ってる範囲（※1）で以下にいくつか紹介します。

• Scala勉強会in渋谷（＆秋葉原）：Scalaが絡めば何でもありの勉強会。私はほぼ毎週参加してます。
• Scala本読書会：関Javaというアイドルプログラマーの方達が始められた勉強会で、関西で月一程度で実施していくようです。@IT仲間の粕谷さんも参加しています。
• 名古屋Scala勉強会：日本の関数型言語のメッカ（※2）である名古屋で頻繁に開催されている勉強会です。
• 天領倉敷Scala勉強会：岡山で開催されている勉強会。大都市以外の勉強会は「人が集まりにくい」という共通の悩みがあると想像されますが、定期的に開催されているようです。
• Scala勉強会 横浜：月1程度で実施のようです。
• Scala勉強会＠東北 （現在お休み中）：2008年から毎週圧倒的な質で実施されているオンライン勉強会。毎週欠かさずあの質の高さを保つのはスゴいの一言。東日本大震災の影響で現在はお休み中ですが、復活が待たれます。

　それではまた。

※1 ここに載っていない勉強会の関係者の方、私が知らないだけなんですみません。

※2 どういう経緯でメッカになったのかはよく知りません。

　さて、突然ですが、この原稿は羽田空港でサンフランシスコ行きの飛行機を待っている間に書き始めたものです。6月2日～3日の2日間、アメリカのスタンフォード大学で開催されたScala Days 2011というイベントに参加するためです。

　本コラムを読んでくださっている方はご存じかもしれませんが、昨年の9月に思い立ってScalaというプログラミング言語を勉強し始めて半年以上が経ちました。Scalaを勉強し始めて1週間も経たないうちに参加したScala座というイベントでは2010年のScala Daysに参加した方の発表があって、それ以来Scala Daysには興味は持っていたのですが、今回仕事でちょうどキリが良かったということもあり、思い切って参加することになりました。

　2日間に渡って開催された本イベントのうち、個人的に興味のあるセッションを中心に紹介したいと思います。プログラムはこちら。

■Keynote by Martin Odersky

○実用段階に入ったScala

　Scala Days 2011は、Scalaの作者であるMartin Odersky博士のState of ScalaというタイトルのKeynoteで始まりました。まずScalaの歴史を簡単に紹介して、その後現在のScalaの状況と今後の展開について話しました。去年も同じような内容の話を少ししていましたが、去年に比べてScalaが使われている場面が随分増えてきて、実際、スライドで紹介されていたScalaを使っている企業のリストには、今までこの手の話では必ず取り上げられていたfoursquareなどに加えて、VMwareやAmazon.comなどが加わっていて、Scalaが今までより一般的になってきたように見えます。

　彼のScalaを作ったキッカケの1つが、関数型プログラミング(FP)とオブジェクト指向プログラミング(OOP)を1つの実用的な言語として実現させる事だったという話がありましたが、ここ数年で注目を集めている新しい言語の中でも、とりわけScalaは「実用的」という部分に大きな重点を置いているように思えます。

○並列化という大きなトレンドの中でのScala

　本Keynote、そして今回のScala Daysの他の発表を見ると「並列化」というのが1つの大きなキーワードとなっています。今世紀初頭まではHWのCPUクロックの上昇という形で処理性能力の向上が進んできたのですが、ここ数年で一気にマルチコア化という方向にシフトしてきており、マルチコアをいかに効率よく使っていくかというのが、現代のコンピュータ言語に求められている大きな要件の1つとなっています。

　OOPが今のように広く使われるようになった理由の1つとして、GUIという領域に対する問題解決の手法として、それまでの方法よりもOOPの方が優れていたというのがあったのですが、FPに対する並列コンピューティングというのがまさにOOPに対するGUIにあたり、今後、並列コンピューティングの重要性が増すにつれてFPの重要性・利用シーンが増してくると話していました。

　これからの並列化に対するアプローチとして挙げていたのが、メッセージパッシングを使用したActorモデル、エージェントモデル、Software Transactional Memory（とスレッドの併用？）の3つで、従来のスレッド+共有リソースに対するロックという方式は、今後はあまり使われなくなると話していました。

　並列化関連ではScala 2.9で取り入れられた「並列コレクション（※）」に加えて、「分散コレクション(distributed collections)」という単語も出てきました。本機能のリリーススケジュールは未定との事でしたが、実現すれば興味深い機能だと思います。

※JavaでいうListやMapに対する処理を並列で実行できるもの。例えば、Listのすべての要素に対して何かの処理をする際、Javaであればfor文で各要素に対して処理しなければいけないが、Scalaの並列コレクションでは、Javaのfor文の中で行うような処理を並列化できる。

○Scalaのさらなる普及のために

　並列化以外にもいくつかの話が出ていて、開発環境の重要性などについても触れていました。開発環境は、Scala利用者の多くから出ていた不満の１つで、ここ最近ではScala開発チームが多くのリソースをEclipseのScalaプラグインに投入していて（※）、実際、最近のベータバージョンではかなり安定して使えるようになっているので、今後が期待できると思います。

※別のセッションでの質疑応答によると、Scala開発チームなどが元となって立ち上げたTypesafe社のリソースの約半分を投入しているそうです。

　また、本Keynoteの最後で質疑応答がいくつかあったのですが、日本人の水島さんが

　「日本では関数型言語は難しいという印象を持たれているが、それに対してはどう考えているか」

という質問をしました。それに対するOdersky博士の回答の中で、

　「FPが難しいという意見は別に日本に限った話ではなく、世界中で聞かれる事だ。FPはパラダイム・シフトだから(多くの人には)難しく見える。OOPがでた時も同じような意見が出たが、それはOOPもパラダイム・シフトだったからだ。」

というようなことを言っていました。

■TT Session 4: Scala enterprise experiences

　今回のScala Days 2011で「並列」と共に大きなキーワードとなっていたのが「enterprise」で、Scalaが研究者やプログラミング言語のファンのためだけでなく、実際に企業でどう使っていくかという内容のセッションがそれなりにありました。

　2日目最後のパネルディスカッションのタイトルが「Scala in the Enterprise, What will it Take?」でしたので、「実用的な言語」としてScalaを企業でどう使っていくのか、というステージに入っているという点が昨年とは違うと感じました。

○Scala on Android: Real-world Experience at Bump Tehnologies

　まずはBumpという人気のスマートフォンアプリのAndroid版がScalaを使っているようで、実際にどう使われているのかという話をtipsや問題点などと絡めて紹介していました。

　「なぜScalaを使うのか」に関しては、開発者の生産性の向上、そして優秀な開発者を雇うため、という2つを挙げていました。シリコンバレーでは優秀な開発者を雇うのが非常に難しいそうですが（※）、新しい技術・言語を使う事が、それらの技術・言語に興味のあるレベルの高い技術者を集めることにつながると話していました。

　ただ、実際にScalaでAndroidアプリを作るにはいろいろ厄介な問題もあるようで、Scalaはしばらくはサーバサイドを中心に使われていくものと思われます。

※実際に、企業に所属しているプレゼンターの殆どは、「We're hiring.」という内容を最初か最後のスライドに含めていました。

○Pedestrian Scala: Applying Scala to Performance Challenges in the Cable TV Industry

　2番目がケーブルTV会社向けのシステムでScalaを使ったプロジェクトの話でした。ここの会社ではCATV向けの広告配信のシステムでScalaを使ったとの事です(視聴者の属性に合わせて広告を配信するような感じでした)。それまで使っていた、Java, Groovy, Hibernateを使った「レガシー」なシステムではパフォーマンスに関する問題があったそうですが、Scalaに切り替えたことによってそれは解消されたとのこと。

　また、Scalaを使ったシステムに切り替えたことによるメリットを、顧客からの立場と技術的な面の2通り説明していました。

　顧客の立場からのメリットとしては、以下が挙げられていました。

• 要求された時間内に処理が完了するシステムができた
• (処理速度向上により)ハードウェアコストを下げられた
• Javaに比べてコードの行数が減ったため、開発コストを下げられた
• メンテナンス性が増した

　技術的なメリットとしては、以下を挙げていました。

• Scalaの並列関係の機能を使うことによるパフォーマンス向上
• Javaのようにスケーラブルで、かつ、Groovyのように素早い開発速度
• ビジネス課題の数学的な部分に対する解決の為のFPの適用
• 開発者の熱意が得られる(enthusiasm)

　最後の質疑応答では、

　「Hibernateは何に置き換えたのか」

という質問に対して、

　「ORマッパーをいくつか検討したが、結局生のJDBCを使うことにした」

と回答していました。一応補足すると、ScalaからもHibernateやJPAは使うことができるのですが、どうしてもコードがJavaっぽくなってしまうと思うので、Scalaで違和感なく使えるORMが出てくるのを期待したいところです。

　また、どうやって上司を説得したのかという話が本編中でも質疑応答の時にも出ましたが、彼の場合は直接の上司が保守的でOKしなかったため、その上のマネージャーに話を通して、OKしてもらったそうです。また、プロジェクトの結果が上々だったので、その上位のマネージャーが現在では会社内でScalaのサポーターになってくれていて、他のプロジェクトにも使おうという動きになっているそうです。

　我々技術者は(組織に属している場合は特に)、新しい技術を使うことで何をもたらすことが出来るかというメリットを明確に提示しつつ、必要に応じてこうした根回しもする必要があると再認識させられました。

　また、社内の技術者で抵抗する人はいなかったのかという質問に対しては、チーム全体にScalaの使用を強要するのではなく、Scalaに興味のある人を集めてチームを作ったのでそうした抵抗はなかったとのこと。先程の上司に対する根回しもそうですが、開発リーダー・マネージャ層がうまくプランを練って導入することが成功の秘訣だと感じました。これは新しい技術の導入に限った話ではありませんが。

○Scala at Bizo

　3番目が、Bizoという会社でのScalaを使ったプロジェクトの話でした。Google Analyticsのような広告関連のプラットフォームだそうです。毎月2-3百万のリクエストを捌いていて、また毎年400％のペースで増加しているとの事ですので、データの規模としてはかなりの規模と言って良いと思います。

　プログラミング言語はScala, Ruby, Java, JavaScriptを適材適所で使っているそうですが、インフラはすべてAmazon Web Services上に載せているとの事でした。

　必ず聞かれる「Why Scala?」に対しての答えとして、生産性、そして並列化(が容易にできる事)とパフォーマンスの3つを挙げていました。

　最初はRubyでプロトタイプを作ったのですが、本番のシステムをScalaで書き換えてからは約15倍高速になったそうです。ただ、これはScalaに限った話ではなく、JVM上で動作する言語であれば、大体同じような結果になると思われます。

　使っている技術に関しては、従来通りivyなども使っていて、必ずしも一度に全てを新しい技術に置き換える必要はないと言っていました。これは他の発表や、去年のScala Daysの発表などでも聞かれた話で、各組織の状況に応じて柔軟に進めていく必要があるという事だと思います。

　JavaとScalaの相互運用性に関しての話も出ていて、ScalaからJavaのコードを呼ぶのは全く問題がないとのことで、これは自分も同感です。JavaからScalaに関しては色々面倒なようで、彼らは基本的にはthriftを間に挟んでRPC経由でScalaの機能を使っているようです。

　その他、 Scalaの標準ライブラリにバグがあった時の対処方法については

• その機能を使うのを避ける
• 同等の機能を自分で実装する
• ライブラリの問題点を修正する(そして開発チームにパッチを送る)
• Typesafe社から有償サポートを受ける

という選択肢を挙げていましたが、彼らは自分たちで修正するという選択肢を選んだそうです。その修正が必ずしも本体のソースに取り込まれてリリースされるとは限らないため、彼らは独自でScalaのライブラリをビルドして使っているそうです。このへんはearly adopterならではの悩みという感じがします。

■終わりに

　長くなりましたので、今回はここまでにします。次回は分散関連の機能が大幅に強化される予定のAkkaについてのセッションを中心にレポートします。話を聞いた限りではかなり期待できそうで、分散処理が必要なシステムを開発しているのであれば、Scala + Akkaは検討すべき選択肢だと言えます。

それではまた。

■海外生活中に災害の当事者となったら

　海外生活をしている時に災害が起きたら、どうなるでしょうか。主に2つのパターンがあると思いますので、それぞれについて少し書きます。

○自分のそばで災害が起きたら

　カナダに住んでいた時の知り合いの何人かが、日本に来て英語の先生をやっているのですが（真面目な先生です）、地震発生数日以内に2名ほどが日本を離れました。また、他の数名も離日を検討中ですし、しばらく西日本に行くと言って東京を離れた人や検討中の人も数名いて、彼らの不安な心境が窺えます。

　その中には結構仲の良かった人もいて、話を聞いた瞬間は何となく自分や自分たちが見捨てられたような、子供っぽい感覚にとらわれたのですが、ちょっと考えてみると多くの人にとって外国で暮らすというのはそれなりに不安があるものなので、自国に帰るというのは当り前の選択肢の1つなのでしょう。

　私が海外に住んでいた間は特に大きな災害、政変、戦争などもなく、大きな出来事と言えるのは身内が病気になったこととリーマンショックの2つくらいだったと記憶しています。ただ、実際のところ、その2つが私の帰国理由のそれなり部分を占めていましたので、もし私が外国にいる間に今回の大災害のようなことが起きたとしたら、恐らく帰国していたでしょう。

　海外に住んでいる方の中には、もう日本に戻る気がない方もそれなりにいますが、そうでない方は日本に戻った場合の生活についてある程度考えておいた方がいいかもしれません。

○身内・知り合いの側で災害が起きたら

　逆に、自分がもし今外国にいるとしたら、家族や友人の事で心配だと思います。私は語学の勉強も兼ねて、海外のニュースサイトをちょくちょくチェックするのですが、どこの国のサイトでも悲惨な映像をこれでもかというぐらい載せています。大半の外国人は日本の地理についての知識がほとんどありません。冗談ではなく、日本と中国の区別が付いていない人もそれなりの数がいます。そうした人たちが、日本人全員がこのような惨状に陥っているかのような錯覚を覚えたとしても不思議ではありません。

　日本人であれば、震源地は東北地方で大きな被害が出たのは東北と北関東の一部、という状況は大体理解していると思いますが、それでも情報が少なかったり海外のメディアの報道で混乱したりしている人も多いようです。

　私は地震発生から数日後に、主に外国に住んでる友人向けにFacebookで簡単なメモを書きました。たいした内容でもなく、以下のようなものです。

• 状況
  • 東北は大変。
  • 関東は揺れたけど大したことない。
  • 関西以西は問題なし。
• やめてほしいこと
  • 回線が逼迫しているので電話しないで。
  • 現地に行って救助活動ってのは邪魔なだけだからやめて。
  • 食料や衣類を送らないで（代わりにお金を送って）。
• お願い
  • 友達とかを励ましてあげて。
  • 日本に住んでる人は節電して。
  • お金に余裕があったら寄付して。

　こんな内容ですら、「こっちのメディアの情報だと状況が良く分からないから助かる」とか言われるぐらいなので、いかに混乱しているかが分かるかと思います。

■非当事者の場合

　上の話に出てくる人たちは、いずれもある種の当事者ですが、もちろん全員が全員当事者のわけではありません。

○Facebook上でのとある出来事

　私が海外に住んでいた時にはすでにFacebookはみんな使っていて、私のFacebookの友達リストには仲のいい友達からちょっとした知り合い程度の人までいろんな人がいます。Twitterであれば1人で複数アカウントを持つことが可能なので、「仕事用」「個人用」とか分ける事ができるのですが、Facebookでは複数アカウントは規約で禁止されているためそうはいきません。人数が少ない間は気にならなくても、いろんな人がFacebookの「友達」に入ってくると余計なことまで気を配らなければいけません。

　実際に（多分）一度しか会ったことがない人から、地震の数日後にFacebookのチャット機能で話しかけられました。短いのでコメント付きで全部載せます。

その人：hello

鹿島：hi （誰こいつ？）

鹿島：how are you? （誰か知らんけど一応挨拶しとくか）

その人：good

その人：too bad what is happening in Japan

その人：is your family ok?

鹿島：yeah （自分も家族も問題なしって何回も書いてるんだけどなぁ。やれやれ）

鹿島：our family is near tokyo, which is far from the epicenter. （うちは震源地から遠いって一応説明しとこう）

その人：I heard it is pretty bad... （普通、glad to hear that ぐらい言うだろ……）

その人：it is horrible what is happening （人の話を聞く気はまったくないな……）

鹿島：yes, it is in northern japan.

その人：ok friend

その人：I am out

鹿島：bye

　この人が、私や私の家族のことを気にかけていないのは文面からも明らかだと思います。「大変だった」とか「怖かった」とかそういう反応を期待していたのではないでしょうか。

※もちろんこういう人だけでなく、ちゃんとしたの友達からも暖かいメッセージをいくつももらって、そっちはありがたかったです。

○広がった世界と希薄な現実感

　この会話の直後は非常に腹立たしかったのですが、よく考えるとこうしたことが起こるのは彼だけの責任ではないようにも思えます。上の方で触れたとおり、海外メディアでは「見栄えのいい」ニュースを大きく扱っています。瓦礫で埋め尽くされた町、途方にくれる人、原発の爆発事故、メルトダウンの「可能性」、さまざまな悲劇（と一部の心温まる話題）などなど。

　もう20年も前になりますが、湾岸戦争は史上初めてTV中継された戦争ということで、当時いろいろと論議を巻き起こし、しばしば「TVゲームのような」とか「ワイドショー」という言葉で形容されていました。私もその時のテレビ映像を何となく覚えていますが、たくさんの人命が失われていたのは確かなのですが、とにかく現実感がなかったように記憶しています。

　インターネットや交通網が発達し、人間の行動範囲や情報を得られる範囲が格段に広がりましたが、人間の処理能力・認知能力というのはそれほど変わっていないはずで、人間が「現実」として認知できる世界の広さというのはそれ程広がっていないのではないかと思います。

　私自身、東京で激しい揺れは経験しましたが、特に怪我もなく自宅も特に大きな被害はありませんでしたし、あまりに現実離れしていて映画のようだったせいなのかもしれませんが、TVでの東北の映像を見ても何となく現実感を感じませんでした。

　私の場合、それでも知り合いに宮城出身の人がいたり、親戚が福島で被災したりしたので、心配したり不安な気持ちになりましたが、東北地方の方々と同じような言葉で「大変だった」とか「不安だった」とか私が語るのは不誠実に思えます。また、福島の親戚の無事を聞いてからは、なおさら東北で起きている現実と、東京で比較的平穏に暮らしている自分を結びつけることが難しく感じました。

　もちろん、個人差はありますし、私は良く言えば「図太い」、悪く言えば「無神経な」人間ですが、東京に住んでいる人間がこんな感じですので、例えば九州出身で東北には知り合いが1人もいない人、さらには外国に住んでいて日本人の親しい友人がいない人、そうした人達にとってはあまり現実味がない出来事なのではないかと思います。

○無関心→片方向→双方向

　昔であれば、新聞で「ヨーロッパの××という国で内戦があった」という記事を見ても、「大変そうだな」という感想を持つか、せいぜいその国から輸入している資源なりの供給を心配する程度だったと思います。対岸の火事、無関心と一言で言ってもよいかもしれません。

　現在でも、人間のその辺りの感覚は根本的には変わっていないと思いますが、今と昔で違うことは、地球の裏の状況が映像化され、しかも「見栄えのいい」ある種のエンターテインメントとして提供されている点です。これは地球の裏に限らず日本国内のテレビでも同様で、津波の映像を繰り返し流したり、悲しみにくれる被災者の表情を執拗に追って、悲劇をエンターテインメントとして提供しています。

　また、ここ最近では映像などの「エンターテインメント」を享受するだけでなく、Facebook、Skype、Twitterなどの双方向メディアでその「エンターテインメント」の一部となることができます。今回の東北関東大震災が、被害地から離れたところでは、双方向参加型エンターテインメントとして機能しているのです。なかなか残酷な社会になった、と感じざるを得ません。前述の彼は、悲劇映画のいちシーンになったような感覚で、日本人「被災者」の私に声をかけてきたものと思われます。

　災害発生地から遠く離れた場所にいる人が、災害をあまり現実として感じないのはどうしようもないことですし、彼らに「被災者の気持ちになってみろ」と言うのは無理な要求です。ただ、そうした「外野」が災害をネタにした「エンターテインメント」を楽しむことこそ「不謹慎」ですし、さらには無神経に「エンターテインメント」の参加者として楽しもうというのは厳に慎むべきでしょう。

■我々外野がすべきこと

○エンターテインメントの一部となる事を拒否する

　今回の事件では多くの方が被害を受けました。そうした方々に対して有形無形の援助の仕方があると思いますし、可能な限りそうしたことを行うべきでしょう。

　ただ、私を含め、多くの日本人は被災者ではありません。我々「外野」は自分が外野である事を認識し、そうした援助を行う際には自分の行動が「エンターテインメント」の一部になっていないかを常に気にしつつ行う必要があると思います（自戒の意味も込めてます）。

○同情するなら金をくれ

　伝え聞くところによると被災者の方々の状況は相当、過酷なようです。そんな被災地東北では安っぽいドラマや同情は、誰も必要としていないのではないかと思います。そうした状況下、自衛隊でもレスキュー隊でも医者でもない我々ITエンジニアができる一番効果的な援助は、間違いなく金銭的なものだと思います。

　100円でも200円でもいいですし、余裕があればもっと多額の寄付をする事が我々にできる一番の援助だと思います。

○ITでできること

　今回の大震災で、正直、ITができることの少なさを感じた人も結構いたかと思います（実際にはITに限らず、我々のほとんどが非力なのですが）。そんな中、災害情報のミラーサイトをいち早く提供したり、避難所情報とかをまとめたり、できる範囲で努力している方々も多くいたようで、そういう方々には頭が下がる思いです。

　今後IT関連で考えていかなければならないこととして、

• 災害を想定した冗長化
• 古いサーバの集約（仮想化）による節電

などがぱっと思い浮かびますが、それ以外にもいろいろな教訓が得られたかと思います。そうした教訓を今後に生かすのも我々がやらなければいけないことだと思います。これもITに限った話ではありませんが。

■終わりに

　今回の大震災はあまりに大きな出来事で、いろいろ言いたいことがあるような気もしつつも、あまりまとまりません。私個人は徐々に平静を取り戻してきたので、次回以降は通常営業で行こうと思います。

　それではまた。

　ITエンジニアである皆さんの海外（海外の方）との関わるケースとしては、主に以下のようなものが挙げられるかと思います。

• 仕事
• 日本企業勤務
• 業務の海外へのアウトソーシング（含オフショア開発）
• 自社あるいは顧客の海外進出
• （国内の）外資系企業勤務
• 本社、他国の支社との会議、出張
• 転勤
• （国外の）外資系企業勤務
• 仕事以外
• 旅行
• 移住

　アウトソーシングに関しては、専門の方がいろいろいらっしゃいますし、海外での勤務に関しては以前に本コラムでも少し取り上げたかと思いますので、今回は少し趣を変えて、ITエンジニアの人生設計における1つの選択肢として、「海外移住」というのを私個人の経験・考えなどを中心に書いていこうと思います。

　個人的な話が多く、あまり万人に役に立つ内容ではない事を、あらかじめお断りしておきます。

■理由

　海外移住を目指す理由はいろいろあると思います。

1. 「○○の本場」で働きたい
2. 日本の労働環境に馴染めない
3. 日本の（今の会社の）先行きに対する不安・悲観
4. 「海外に住む」という事自体に何となく興味がある
5. 退職後にのんびりしたい

1．「ITの本場」

　やはり、IT業界で働く人にとってはシリコンバレーというのは憧れの地と言ってもいいかと思いますので、「本場のIT企業で働きたい！」というのは、海外（この場合はシリコンバレー）移住の理由としては大きなものだと思います。

　また、先日公開された「ソーシャルネットワーク」を観て、海外で働きたいと思った方も多いのではないでしょうか。私が良く参加しているScala勉強会 in 渋谷でも、何名かの方は海外で働いてみたいと話しています。

　IT業界でもさらに分野を絞ったり、あるいは特定の働きたい企業がある場合には、シリコンバレー以外の場所を目指すことになるかもしれません。例えば、私が以前住んでいたモントリオールでは、3D CGソフトのSoftimage社や、ゲームソフトメーカーのUbisoft社の開発拠点があったりして、割とゲーム関係の仕事をしている人が多かったので、そういう分野の人にとっては、目的地となり得るかもしれません。

2．日本の労働環境に馴染めない

　最近ではエンジニアライフでもメンタルヘルス特集が組まれたりして、この問題の認知度が高まってきています。鬱病などの原因がすべて労働環境に起因するわけではありませんが、仕事というのは生活の大きな部分を占めますので、職場での問題から病を患う方も多いと思います。

　そうした方々にとっては、もしかしたら日本で働くより海外で働いた方がいいケースも考えられます。海外は海外でストレスの原因の元はたくさんあるのですが、それに関しては後ほど述べます。

3．日本の先行きに対する不安・悲観

　日本の将来に何となく不安を持っている人は多いようです。その不安感が具体的な根拠に基づくものなのか漠然としたものなのかは置いておくとして、実際にその様なことを言う人は周りにも結構います。

　希望あふれる（ように見える）他の国で生活してみたい、というのも十分自然な理由だと思います。

4．「海外に住む」という事自体に何となく興味がある

　私が海外に移った時の理由は大部分がこれです。ずっと日本に住んでいると、やはり外国での生活に興味が湧きますし、憧れみたいなものもありました。こうした理由で海外に住むというのもありかと思います。

5．退職後にのんびりしたい

　前項と少し関連しますが、退職後は好きな場所でのんびり、あるいは憧れの地で暮らしたいという人は多いかと思います。最近はどうか知りませんが、メディアで田舎暮らしがちょっとブームになった事がありましたが、それの延長で退職後に海外に住む方もそれなりにいらっしゃいます。

　東南アジアでは、そうした退職者向けの特別なビザの制度がある国がいくつかあります。私が一時期住んでいたフィリピンのセブ島では、日本食レストランとかも結構あって、退職して現地に在住している方々や現地駐在員などでそれなりに繁盛していました。

■方法

　海外移住の方法ですが、現実的には2種類に限られると思います。

1. 現地企業に就職して数年間働き、その後永住権を取得
2. 前述の退職者向け永住ビザを取得

　念のため書きますと、永住権≠国籍です。

　「○○の永住権を取得する（した、したい）」と言う方に対して「日本を捨てるのか！」みたいな反応をされる方がたまにいらっしゃいますので。

1．就労ビザ → 永住権

　現地企業、あるいは日系企業の現地支社に採用され就労ビザを取得。そこで数年間働いてその間に永住権を取得する、という方法です。実務経験、そこそこの語学力がある方は、この方法が選択肢になるかと思います。

　就労ビザの取得方法、各国の転職市場は国によって大きく異なるので、まずは行きたい国をいくつか候補に挙げて、それらの国について調べることをお勧めします。

　私自身はアメリカで働いた経験はないのですが、知り合いの話ではビザ取得が大変かつ面倒で、永住権（グリーンカード）の取得もかなりの長い道のりのようです。

　私はお隣のカナダで3年位住んでいたのですが、当時はIT業界向けの優遇措置があって就労ビザが取りやすかったのですが、現在その制度は基本的には終了したようです。ただ、どこの国でも優秀なIT技術者は不足していますので、他の国でも同様の優遇措置があるかもしれません。

　ビザに関しては私のブログの方にも書いていますので、よければそちらもご覧になってください。

　また、現時点では英語力が足りない人には、インターンも選択肢になりうると思います。アメリカの場合はインターンは就労ビザとは別のカテゴリーになっていますし、そこで業務経験・語学力を磨いて次のステップに、というのも割と自然な流れだと思います。

　なお、（最近は数は多くありませんが）私自身もインターンの紹介・サポートなどを行っていますので、ご興味のある方はお問い合わせください。

2．退職者向け永住ビザを取得

　東南アジアでは、一定の金額を預けることによりその国の永住権がもらえるという、主に退職者向けの制度を持っている国がいくつかあります。

　具体的にはフィリピン、タイ、インドネシアがそうです。国によって細かい点は異なりますが、大体以下のような条件です。

• 一定年齢以上（50歳～55歳）の人が対象
• （為替により異なりますが）200万円前後を預ける必要がある

　フィリピンの場合は、35歳以上の人も同ビザを取得可能です。その場合の預ける金額は400万強（$50,000）に増えますが。

　200万円というのは、車の購入や豪華な結婚式をあきらめれば、何とか手の届く金額ではないかと思います。もちろんそれ以外にも月々の生活費がかかりますので、実際には年金などがないと難しいかもしれませんが。

　私も何かで一発大もうけをして、東南アジアかどこかのビーチリゾートでのんびり暮らしたいなぁと思ってますが、なかなか難しそうです。

3．その他

　永住ではありませんが、大学生であれば、学校によっては交換留学プログラムがありますので、そういうのに応募してみてはどうでしょうか。

　一度就職してから海外に住もうと思うと、ほとんどの人は仕事を辞める必要があるでしょうし、結構リスクが高いと思います。大学生の交換留学、短期留学でしたら、そうしたリスクを気にせずに海外での生活を経験できるので、そうした機会があればぜひお勧めしたいです。

■環境の違い

○日本でダメなら海外でもダメ？

　前の方で、日本の労働環境に馴染めない方が多くいるという事を少し書きました。そうした人が海外に行く（行きたい）と口にすると、

　「日本でダメなやつはどこに行ってもダメ」

　とか言い出す人がいます。

　言わんとすることは分かりますし、50％ぐらいは正しいのかもしれませんが、少なくとも50％は間違いです。

　以前のコラムで、日本で勉強した事や業務経験は、海外でも生かせることが多い、という内容を書きました。裏を返すと、技術不足・経験不足のために日本であまり評価されていないエンジニアの場合、海外に行っても活躍できる可能性はそれ程高くないと思われます。

　そういった意味では上述の言葉は（ある程度）正しいのですが、仕事に求められるのは技術・経験だけでなく、コミュニケーションが占める割合も多いと思いますが、コミュニケーションの仕方、作法が日本と海外（※）では大きく異なります。技術や経験があっても、日本では対人関係でストレスを感じてしまう人が、他の国に行ってのびのびと実力を発揮できるようになるケースも実際にあります。

※海外の場合も、もちろん国によっても異なります。

○日本の方が合う人も

　ただし、逆のケースも当然ありえます。短期での滞在では気にならない様な事も、長期滞在あるいは永住の場合にはストレスになったりします。

• 母国語で会話できない
• 料理が口に合わない
• 文化に馴染めない
• 家族、古くからの友達が周りにいない

　海外就職、海外移住に関してはとかく、いい面ばかりが表に出てきがちです。海外に出て水を得た魚のように活躍している方々がいる一方、水が合わずに帰国した人、海外に住んでいるものの日々ストレスを感じながら生活をしていて、しかも諸般の事情から帰国したくても帰国できない人たちがいる事も事実です。

○お試しするのが一番だけど……

　過去の似たような話題の時と同じような結論になってしまい申し訳ないのですが、やっぱり本格的に海外移住の前に一度試してみるのが一番だと思います。

　ただ、その機会を作るのがなかなか難しいのも承知しています。大学生であれば交換留学や自費での短期留学ができますし、若い方なら会社を辞めて1年くらい日本を離れてもまだやり直しが利きやすいですが、現状ですと30を過ぎたあたりから選択肢がだんだん少なくなっていきます。

　最近ではGREEの海外進出が話題になりましたが、同じように日本の会社がどんどん海外に進出して、日本人が海外で働く機会が今より増えてくるといいですね。

■まとめ

　まとまりの無い話をつらつらと書いてきたので、まとめるのも難しいのですが、一応まとめです。

　望む望まざるに関わらず、今後は海外との関わりが増えてくると思います。そうした中、仕事をする場所の選択肢として日本以外の国を加えるとともに、生活の拠点に関しても海外を選択肢にしてみてはどうでしょうか。

　それではまた次回。

　以前、「エンジニアの方々には『海外就職』という選択肢もあるので、検討してみてはどうか」という内容を書きましたが（これやこれ）、具体的な方法についてはあまり触れていなかったと思いますので、今回は具体例をいくつか挙げようと思います。

■海外就職実例1

　自分語りはあまり好きではないのですが、一応私の就職までの経緯を書いておきます。

　一言で言うとコネです。「隣の芝は青く見える」なんて諺がありますが、こと海外生活、海外就職に関してはその傾向が強いようで、以下のような誤解をしている方もたまに見受けられます（以前のエントリとかぶる部分もありますが）。

• 海外って実力主義だから、年齢なんて関係ないでしょ？
  → 年齢に応じて自動的に昇給したり、基本的には年齢が上の人から順に昇格するといった仕組みはありません。ただ、日本ほど酷くはないですが、若い人の方が就職に有利、年を取ると転職しづらくなる、というのはあります。
• 海外って実力主義だから、人種差別なんてないでしょ？
  → 人種差別がまったく存在しなければ、黒人やその他マイノリティの方々が、人種差別に関する問題提起や抗議行動を行うなんてことはないはずです。
• 海外って実力主義だから、コネ就職なんてないでしょ？
  → コネがあると有利なのは万国共通です。
• 海外って実力主義だから（ry

　自分の場合のコネは、別に親が国会議員でとかそういうスゴイものではなく、当時の英語の先生の従兄が会社の社長だったというものです。

　「え、コネなんてないんだけど」っていう人もそれほど心配する必要はありません。なければ作ればいいだけですので。

　肝心のコネの作り方ですが、簡単にいうといろんな人と会って仲良くする、それに尽きると思います。うろ覚えですが、私の場合は大体以下のような感じだったと思います。

1. カナダ人と日本人の夫婦がルームメートを募集しているところに見にいく
2. 結局そこにはしないで、そこから歩いて1分くらいの所に住むことに決める
3. でも、近所なのでその夫婦と仲良くなる
4. その夫婦の知り合いが英語の先生
5. その人に英語を教わることにした
6. 英語の先生の従兄が会社の社長で、そこでプログラマを募集しているという話を聞く
7. 面接
8. 採用

　これだけだと「え、運が良かっただけじゃん」って言われそうですので、いろんな人に会う方法をいくつか紹介します。

○コネ作りの方法その1：パーティー

　以前にも少し書いた通り、まぁ飲み会です。日本との違いは、友達とかを連れてくるのも割と一般的というところでしょうか。お酒が飲めない人はソフトドリンクで参戦すると良いと思います。

　重要なことは、最初は頑張っていろんな人に声をかける、顔を出すことに意義があるので忙しくてもちょっとだけは顔を出す、くらいでしょうか。

○コネ作りの方法その2：ローカルコミュニティ

　これは以前紹介した「アプレンティスシップパターン」に載っていた方法ですが、ある程度の規模の都市であればコンピュータ関係のコミュニティの1つや2つはあると思います。日本で言う○○ユーザー会とか××勉強会とかその類のものです。そういうのに参加すれば、もろ同じ業界の人たちと知り合いになれますので、仲良くなってくれば仕事を募集している話とかが聞けるかもしれません。

　もしそういうコミュニティがなければ……分かりますよね。自分で作ればいいのです。

　なお、コミュニティやそういうのに興味がある人を探すには、Facebookとかcraigslistとかを使うといいと思います。

■海外就職実例2

　さて、昨年後半に知り合った別の方の例を紹介したいと思います。ニックネームHALK RICEさんは、以前から海外での就職に興味を持っていて、それがきっかけで知り合ったのですが、彼の場合も就職のきっかけはコネだったようです。

　昨年の夏に彼が勤めていた会社が黒字倒産し、最初は東京で外資系の会社での仕事を探していたようですが上手く行かなかったようです。以下、彼のメールから引用します。

2カ月間、東京で就職活動しました。どうせやるなら、英語を使った職に就きたい。ちょっと欲が出過ぎたかもしれません。無理でした。何せ、TOEICの点数が375点です。どこも、相手にはしてくれませんでした。

　彼はそこで一念発起して、友人が住んでいるフィリピンに渡って仕事を探すことを決意し、結論から言うと現地でIT関係の仕事を得ることができました。

　彼がフィリピンを選択した理由も色々聞いていますが、まとめると以下の通りです。

• ご友人が住んでいる
• 英語圏（公用語の1つ）である
• 物価が安い
• 経済が比較的安定してて、日本語の需要も多い（筆者注：日系企業が多数進出しているからでしょうか）
• 以前何度か訪れたことがあって、生活スタイルが合っている

　彼の就職までの経緯は以下の通りです。

1. 東京で就職活動しつつ、海外就職のセミナーなどにも参加（いい講師に出会っていろいろアドバイスをいただいたそうです）
2. 前述の通り、東京での就職活動に失敗。10月頭に実家に帰省
3. フィリピンの日系企業（N社）に連絡して、役員の方と会う連絡を取り付ける
4. 10月下旬フィリピンに渡航
5. 現地で、友達から人材紹介会社（J社）を紹介してもらう
6. 現地到着後2日後にJ社からコールセンターの仕事を紹介してもらう（内定）
7. N社には断りの連絡を入れる
8. 業務開始となるまで待つが、予定の日になっても連絡はなし。こちらから連絡してもなしのつぶて（※）
9. J社には見切りをつけ、一度断りを入れたN社に再度連絡を取る
10. 一度断ったにも関わらず面接してもらい、無事合格
11. 12/1より勤務開始

　ちなみに、就職が決まるまでにかかった費用は20万円弱だそうです。

　彼の場合、技術はしっかりしたものがありましたが、TOEIC 375点ということからも分かるように、英語力は全然高くありませんでした。それでも仕事を得ることをできた理由は、私は以下のように考えています。

• 友達、セミナーの講師とのつながり
• 下調べ等の事前準備
• 何より行動力

　最後に、HALK RICEさんのメールから再度引用して、2つ目の実例紹介を終えたいと思います。

私の一番の柱となったのは、セミナーでも教えてくださった、ネットワーキングです。私個人の力だけでは、フィリピンで職を見つけることは、叶わなかったでしょう。友達や知人が助けてくれた。このことがやはり、一番大きいです。

　※このように人を食い物にするような業者はフィリピンに限らずどこの国にもいますので、注意が必要です。

■成功率はどの程度

　これも何回か書いているように、「海外に行けば何でも解決する」とか「TOEIC 375点でも何とかなるんだし、何も考えずにとりあえず海外に行ってみるべき」とかを無責任に言う気はありません。今回は海外で仕事を得た例を2つほど紹介しましたが、海外就職を希望して実際に就職できる人の割合というのはどの程度なのでしょうか。

　「海外就職 割合」などで検索してみましたが、具体的な数字は見つかりませんでした。韓国での同様の調査を紹介しているブログ記事みたいなのは見つかって、それによると韓国では海外求職申請者は24429人に対して就職できた人は1446人で、成功率5.9％という数字が出ていました。情報源が「韓国産業人力公団」としか書いてないので、正確な内容は分からないですが。

　また、日本人の方が韓国人より英語力は低い→ 日本人の場合はさらに成功率が低いはずだという若干乱暴な論理展開をしているブログも見つかりました。

　私はいくつかの理由によりその意見には賛成できませんが、いずれにしても日本人の海外就職成功率が30％とか50％という数字ではないことは確かなようで、せいぜい10％程度と考えるのが自然だと思います。

　10％というとかなりの低確率のように思えますが、私はこの数字だけを見て怯む必要もないと思います。

　数字というのは（基本的には）嘘はつかないですが、トリックが隠されていることが往々にしてあります。例えば日本の失業率は4.9％です。（完全）失業率＝（完全）失業者/労働力人口 ですが、この「完全失業者」の定義を知ると、世間一般の「失業者」の感覚と若干違うというのに気付くかもしれません。

　同様に、海外就職の成功率の分母と分子はなんでしょうか。分子は海外で就労ビザやそれに類するステータスを取得して就労している人であまりブレはなさそうですが、分母にどういう人を取るかで成功率が大きく変わってきます。分母に以下のような人を含むと、成功率の数字はがくっと下がると思います。

• 海外就職にちょっと興味があって、数社にレジュメを送ってみたけど反応がなくてあきらめた
• ボストンキャリアフォーラム（※）にとりあえず日本から参加してみたけど内定をもらえなかった

　逆に、（曖昧な言い方になってしまいますが）事前にしっかり準備して就職活動をした方の就職率は、前述の数字よりは高いはずですし、実際に私の周りでも海外で就職した方はそれなりの人数がいます。

　海外に住むこと、海外で働くことのメリット（とデメリット）については以前少し書きましたが（英語編、待遇編）、若干のリスクを取ってでも多くの方（特に若い方）に挑戦して欲しいと思います。

　※ボストンで毎年開催されている、主に日本人留学生向けの就職フェアみたいなのです。

■リスク

　では、海外に行くことによるリスクとは何でしょうか。

　一番のリスクは、行ってみたはいいけど仕事が見つからず時間が過ぎてしまうことだと思います。お金もかかり職歴にも穴が開いてしまいます。

　対策として一番最初に挙げるべきこととしては、（これに限った話ではないですが）バックアッププランを考えておくことだと思います（英語だとPlan Bなんて言います）。例えば、海外就職に失敗して戻ってきたときに、知り合いの勤めている会社に潜り込めないか、今勤めている会社に復帰できる可能性はないか、などを事前に探っておくと良いと思います。

　後は以前も少し書いたとおり、インターンで経験を積む、あるいは自分経歴と比較して少しレベルの低いポジションで仕事を探す、という方法もあるかと思います。後者の場合、resumeの書き方で気をつけないとoverqualificationで落とされるケースもあるようですので、そういうことも含めて情報にしっかり収集をしておくと、成功の可能性が高まると思います。

　仮に海外就職に失敗したとしても、それほど悲観する必要はないと思います。海外就職のために各国の労働市場・環境の調査、英語や足りない技術の勉強を行ったことは別の場所でも生かされると思います。

　また、個人的な意見になってしまいますが、仮に私が採用担当として面接を行う場合には、そうしたリスクを取って何かに挑戦したという点は評価すると思いますし、同じような考えの方は少なくないと思います。

■まとめ

　海外就職の成功率は数字だけ見ると低いですが、しっかりとした事前準備＋ちょっとの行動力があれば意外と道が開けるかもしれません。その際に、人との繋がり（コネ）はいざという時に重要ですので、色んな人と会って仲良くしておくといいと思います。

　また、残念ながら就職ができなかったとしても、その過程での勉強・経験などはその後に役に立つはずですし、「挑戦した」という事実を評価してくれる人もいるかもしれません。

　次回は最近増えている企業の海外進出について書こうと思います。それではまた。

　新年最初のコラムということで、ありきたりですが昨年の総括及び今年の抱負について少し書こうと思います。何か有益な情報を期待している方は、次回以降に期待していただければと思います。

■海外ネタはどこに行った？

　昨年は他のコラムニストの方と直接お会いする機会が何度かあり、何名かの方が「コラムのタイトルと内容が合わなくなってきた」と仰っていましたが、私自身も昨年後半はコミュニティ活動の内容が多く、あまり海外とは関係ないネタばかりだったような気がします。コミュニティ活動自体は面白く、自分のためにもなっていますし、今後も引き続きやっていこうと思っていますが、今年は少し海外関連のネタも書ければ、と思っています。ただ、「○○について書く」と言ったところで、まずはネタがないと始まりません。

　昨年は一度も日本を出ませんでしたし、海外との仕事も小さなのが2回あっただけなので、今年はネタ作りのためにも何かやらなければいけません（※）。昨年、

　「海外進出する企業、技術者をサポートするような仕事をしていきたい」

というようなことを書いたことがありましたが、今年はまさにそれをテーマに取り組んでいこうと思ってます。

　さて、意気込みだけ語って行動しないのもかっこ悪いので、早速実行に移すことにしました。が、その前にもう少しだけ背景などの話をします。

※ネタ作りのためにいろいろやるのは、エンジニアライフ執筆陣の多くの方に共通する病気のようです。

■海外からのインプット、海外へのアウトプット

　本コラムを読んでくださってる方はご存じかもしれませんが、有志の方と共に昨年9月からScalaという言語の勉強会をやっています。先人の方々のいろいろな努力のかいもあって、ここ最近では注目度も上がってきているようですが、依然日本語のドキュメントは少なく、ちょっと突っ込んだ内容を調べようとすると、英語のドキュメントを読む（あるいは直接ソースコードを読む）という作業は避けて通れません。

　Scala勉強会に来ている方は、英語のドキュメントを問題なく読める方が（世間一般と比べると）多いようですが、苦労している方も結構いらっしゃるようです。こないだの勉強会の後の懇親会でもそういう話が出て、何名かの方は「今年は英語を何とかしたい」という意気込みを語ってました。

　また、以前どなたかが、

　「海外の開発者と話した時に『日本人ユーザーは結構いるみたいだけど、声があまり聞こえてこない』というようなことを言われた」

というようなことをWebだかTwitterで仰っていたのですが（内容も含め、かなりうろ覚えで済みません）、これに関してはその通りだなと思わざるを得ませんでした。

　私自身、海外のオープンソースソフトを使う機会はかなり多いのですが、バグ報告やフォーラムでの回答とかは数える程しかしたことがありません（日本語でもあまりしたことないんですが……）。

　前述のScala勉強会の話に戻りますと、英語のドキュメントが問題なく読める方は結構いらっしゃいますが、海外に向けて何かをアウトプットしている方となると、かなり数が少ないのではないかと思います。技術的に素晴らしいものを持った方が多いだけに、少し勿体ないと感じることもあります。

　これらの話からも分かる通り、海外と日本の間の情報の流れには、どちらの方向もまだ量が少ないなというのが実感です。この辺りを改善することにより、海外に進出していく日本の技術者が増えることに（直接的ではないにしろ）つながるのではないかと思っています。

■技術者向けの英語勉強会をやることにした

　で、結局何をやることにしたかと言いますと、とりあえず自分でできることということで、技術者向けに英語の勉強会を始めることになりました。といっても、単に先生役の人が何かを教えてその他の人が勉強するというのもやりたくないので、以下の形式で始めてみることにしました。

• 海外の技術系フォーラムで、投稿されてる質問をみんなで読む
• みんなで考える
• 誰かが代表で英語で回答する

　技術的な勉強もしつつ、実践的な英語が勉強できるという、なかなかいいアイディアじゃないかと思ってるのですが、いかがでしょうか。

　こうしたことをやっていくうちに、英語でのバグ報告や英語でブログを書いたりできる方がどんどん増えてくるといいなと思っています。

　勉強会の詳細ですが、例のごとくスモールスタートということで、毎週水曜日のScala勉強会の後に懇親会の席の一角でやろうかと思ってます。仮に参加希望の方が増えるようでしたら、別枠でやっても良いかとは思いますが。

　英語勉強会に関してのご質問、参加表明などは以下でお気軽にどうぞ。

• 本記事のコメント欄
• あるいは、私のTwitterアカウント（ @kaigaiengineer ）

　Scala勉強会に関してはこちらのサイトをご覧ください。 短縮URL: http://bit.ly/gryecG

　次回は英語勉強会の報告を来週くらいに書こうかと思います。それではまた。

　生まれて2回目のLT。前回はなんとか言いたいことも言えたんですが、今回のLTは結論から言うと失敗でした。時間配分がまずくて、結論を言う前に時間切れになってしまいました。関西行きの新幹線の中で資料を作ったんですが、資料ができた時点で安心してしまい、発表の練習をしなかったのが敗因だと思います。

　さて、失敗は失敗として今後改善していけばいいとして、今回のコラム（※）ではLTで話したかった内容について書いていきます。

※私自身は「コラムを書く」とか「コラムニスト」いう言い方は何となく気恥ずかしい感じがするのですが、＠IT編集部の方は「ブログじゃなくてコラムだ！」と常々仰っているので、それに従おうと思います。

■＠ITのコラムニスト

　冒頭で書いた通り、今回のリッツにはエンジニアライフでコラムを書いている人たちが集まりました。一覧ページを見ていただくと分かる通り、エンジニアの方、非エンジニアの方がいらっしゃいますし、エンジニアといってもいろいろな業種、職種の人がいます。構成は結構バラエティに富んでいるのですが、核として「エンジニア」というキーワードがあるので、何となく一体感もあるような気がします。

　そんな＠ITのコラムニストたちですが、本業を持っている人がほとんどのようです。本業の傍らコラムを書いて、コラムのネタ作りのために新しいガジェットを買ってみたり、デスマーチに自ら飛び込んでみたり、コミュニティ活動をしたり、そんな感じの方々です。

　「ネタ作り」のためというのは冗談ですが、コミュニティに参加されている方は比較的多いです。日本全国の勉強会を行脚している方、LTと言えばどこでも飛んでいく方といった極端な例は置いておくとしても、AAAユーザー会とかBBB勉強会といったものに積極的に参加している方などがいます。そもそもコラムを書くというのもある意味コミュニティ活動の一環とも言えるのではないかと思います。

■コミュニティ活動

○私が行っているコミュニティ活動

　先ほど「コミュニティ活動」というキーワードを出しましたが、私自身も今年の9月からコミュニティ活動を行っています。私の以前のコラムを読んでくださった方はご存じかと思いますが、Scalaという言語の勉強会を毎週行っています（※）。

　勉強会を始めた経緯に関しては以前のコラムで書きましたので、詳しくはそちらを参照していただくとして、ここでは簡単に説明します。

　8月末にいろいろな理由によりScalaを勉強しようと思い立って、最初は勉強会を探したのですが、東京近郊では勉強会の開催がなかったのでとりあえず自分で始めることにした、というのがそもそもの発端です。第1回勉強会は9月1日に行ったのですが、その直後の9月4日にたまたまタイミングよく開催されたScala座というイベントに参加して、そこで知り合った人を無理矢理勉強会に誘ったところ、彼らが運営にも協力してくれて今に至る、という感じです。

※以前のコラムでも書きましたが、勉強会をやり始めたのは私ですが、いろいろな方々の協力によって成り立っている勉強会ですので、私は「主催者」ではなくせいぜい「運営者の1人」だと思っています。個人的には非常に大事なことだと思っているので再度書かせていただきました。

○Scalaの流れが来ている？

　今年の9月の時点では東京近郊でのScala勉強会は1つも存在しなかったのですが、3カ月経った今では何と3つも存在します。

• Scala勉強会 in 渋谷
• WebプログラマのためのScala入門勉強会
• Scalaを遊ぶ!会

　1つ目は私が参加しているやつですので説明は省略します。2番目は、Scala座で知り合ってScala勉強会 in 渋谷の運営にも協力してくれている方が、初心者向けに新たに立ち上げたものです。最後の1つは、同じく前述のScala座に参加された方（私はまだお会いしたことがないのですが）が、Scala勉強会 in 渋谷の直後くらいに立ち上げられたようです。Scala座ではかなり高度な話題とかも出ていて、「これからScalaを勉強しようと思っている人にとっては入りにくいのではないか。もう少し取っつきやすい勉強会が必要じゃないか」という思いで始められたそうです。

　また、勉強会だけではなく、Scalaが媒体などで取り上げられる回数も以前に比べて増えてきているようですし、最近ではScala関連の本の出版が相次いでいます。

　実際にScalaを使っているシステムやWebサイトも徐々に増えてきていて、来年辺りからじわりじわりと広がっていくのではないかという、かなり確信に近い思いがありますし、そうした大きな動きを実感できる瞬間というのがかなり増えてきています。

■ソーシャルイノベーション

○大きな流れも最初は小さな動き

　そんなことを考えていてふと思い出したのが、以前読んだ『誰が世界を変えるのか　ソーシャルイノベーションはここから始まる』という本です。本の詳しい内容は各書評を見ていただきたいのですが、この本では社会を変革した出来事・ムーブメント＝ソーシャルイノベーションをいくつか紹介しています。そうした大きな動きですが、どれも最初は1人～数人の小さな活動だったのが、周りの人物をどんどん巻き込んで徐々に大きくなっていき、ある臨界点（本書ではtipping pointと呼んでいます）のようなものを超えると爆発的に広がっていく、という話です。

　Scalaに関して言うと、日本ではずいぶん前から精力的に活動している人が何名かいらっしゃって、そのうちユーザー数が増えていき、日本初（？）のScala関連イベントとなる前述のScala座が開催され、そこに参加した人が新たに勉強会を立ち上げて……という感じでどんどんコミュニティが大きくなっています。また、今回のリッツでは、関西の方が2名ほどScalaに興味を示していて、来年から大阪で勉強会を開催しようという話になっています。

　そろそろtipping pointを超えて爆発的に広がっていく可能性があるScalaですが、前述の通り最初のころから普及活動をしていた人は、それほど多くなかったはずです。

○まずは動いてみる

　大きな流れはいずれも最初は小さな動きです。世の中やある状況がこんな風になればいいな、という思いを持つことは誰でもあるかと思いますが、それと同時に「自分1人の力じゃ何も変わらない」と思ってしまう人も多いことと思われます。

　「世界は、自分が頑張れば動かしていけるものだ」という考えは心理学では「全能感」と呼ばれるようで、俗に中二病などとも呼ばれますが、私はそういうことを主張したいわけではありません。ただ、個人がまったく無力かというとそうではなく、個人の小さな活動が世界を動かす「可能性」があるという認識を持つことは、結構重要ではないかと思います。

　前述の『誰が世界を変えるのか　ソーシャルイノベーションはここから始まる』の原題は“Getting to Maybe　How the World Is Changed”で、直訳すると「『かもしれない』へ向かって　どのように世界が変わるか」という感じでしょうか。世界が動くかどうかは分かりませんが（Maybe）、まずは動いてみることが必要だと思います。

○人とつながる

　『誰が世界を変えるのか　ソーシャルイノベーションはここから始まる』では、社会の複雑性を理解してそれを受け入れるということについても書いています。社会・他者との関係性の中で自分も変化し周りも変化していく、自分という存在は社会という系の一部である、という考えも重要なポイントだと思います（この辺の話があまりしっくり来ない方は、複雑系関連の書籍を一度読んでみるといいかもしれません。と書いている私も2～3冊ぐらいしか読んだことはないですが）。

　複雑系では自己相似というのもキーワードの1つですが、人がある人と会ってその人に影響を与え、自分もその人から影響を受けるということは、社会変革のプロセスの一番小さいバージョンである、というのは言い過ぎでしょうか。人と会って影響を与え合うというのはそのぐらい重要なことだと私は思っています。

　人が集まるということは、本当に大きな力を生み出す「可能性」があります。今回のリッツは第2回でしたが、第1回は主催の森姫さんがいろいろ動いてくださり、また編集部の方なども巻き込んで、アイティメディアの会議室をお借りして開催されました。そこで生まれたいい流れを継続して、第2回は関西方面の方々がいろいろと動いてくださり、神戸にて無事に開催されました。

　他のコラムニストの方たちとは、何名かはTwitter上で絡んだりということもあったのですが、今回初めてお会いする方が半分以上です。そうした方々との新しい繋がりというのは、直接的か間接的かは分かりませんが、今後の私の人生にいい影響を及ぼすものと思います。

　また、前述の通り、今回の集まりによって関西に新しいScala勉強会が立ち上がりそうな気配です。人と繋がることによって新たな小さな動きが生まれた実例と言えるでしょう。

■まとめ

　そろそろまとめます。世界を動かすためには、まずは動き始めること、そして人とつながることが必要条件だと思います。

　もちろん世界が実際に動くかどうかは分かりません。行動したとしても動くかどうかはmaybe （or maybe not）ですが、もし動かなければ決して動きません（never）。何かを変えたいのならまずは動いてみてはどうでしょうか。

　人とつながると、すごいことが起きる可能性があります。何かを変えたいと思っている人は、機会があればそうした場・コミュニティにどんどん参加してみてください。そうしたコミュニティがなければ自分で作るのも1つの手段だと思います。

　そうしたコミュニティ活動が世界（は大きすぎとしてもIT業界）を変えるとしたら、そして自分がそれにかかわれるとしたら……面白いと思いませんか。変わるかどうかはMaybeですけど。

　最後になりましたが、今回出会いの場を作ってくださった第2回リッツの幹事の皆さまに、この場を借りてお礼を申し上げます。ここから何か新しい動きを作っていきたいですね。＞参加者、そしてコラムニストの皆さま

　それではまた次回。

■補足

　Scala勉強会 in 渋谷にご興味のある方は、ぜひお気軽にご参加ください。詳しくは勉強会のWikiで。

　さて、今年の9月に思いつきで始めたScala勉強会ですが、皆さまのご協力のおかげで開始してから約2カ月が経ち、だんだん軌道に乗ってきたように見えます。今回は「パーティー」と「勉強会」という、一見何の関連もなさそうな2つのことについて書いていこうと思います。それらの共通点はというと、

　「人が集まる」

です。さらにいうといろんな人が集まります。

■Party, Party, Party！

○飲み会（≒パーティー）のスタイルあれこれ

　もともとそういう文化なのか、人を呼べるほどの広さがないという（大都市の）住宅事情が影響しているのかは分かりませんが、日本では「知り合いを家に招いて食事をする」のはそれほど一般的ではないように思えます。（私は未経験ですが）結婚前に婚約者を家に呼んで親に紹介するとか、結構改まった場面でないと、食事会はやらない気がします。

　飲み会にしても、学生などがお金を節約するために部屋飲みをするのを除くと、普通は居酒屋で集まるのが一般的だと思います。

　それに対し、北米では（多分ヨーロッパも）家に友だちを呼んで食事会やパーティーを行うのが割と一般的です。もちろん、国や文化、年齢によってスタイルは大きく異なりますが。

　中でも、皆が食べものや飲みものを適当に持ち寄って集まる「potluck」は、ごく一般的に行われているようです。

○ホームパーティーをやってみて

　私が住んでいたモントリオールはそれほど大きな都市ではなく、徒歩圏内、あるいはせいぜい電車＋徒歩で30分以内のところに住んでいる友だちが大半だったため、よく友だちを家に呼んでホームパーティーをやっていました（極度の出不精で、外に出るのがめんどくさいので友だちを家に呼んでいたという理由もありますが）。「パーティー」というとなんだかおしゃれな感じがしますが、実態は集まって飲んで話すだけの単なる飲み会です。

　ただ、居酒屋で飲むのとの大きな違いは、以下の2点だと思います。

• 席の移動が自由なので、いろいろな人と話しやすい
• 友だちを連れて来てもOKというのが一般的なので、新しい知り合いができやすい

　向こうに引っ越して一番最初のホームパーティーは、友達4人と自分の計5人でのこぢんまりとしたものだったのですが、3年後ぐらいになると知り合いが増えてきて、毎回30～50人ぐらいが集まっていました。

　別に人数が多ければいいわけではないですが、毎回楽しみにしてくれる人もそれなりにいたので、飲み会の幹事（≒パーティーのホスト）としてはまぁまぁうまくやっていた方なのかなと思います（※）。

※念のため書いておきますと、（直接面識のある方はご存じかと思いますが）私自身は別にparty animalというタイプではなく、単にお酒が好きな普通のエンジニアです。

■勉強会、始める前と始めた後

　さて、話は変わって勉強会です。私は今年の夏まで、勉強会をはじめとするそのほかコミュニティ活動は、運営する立場はおろか、参加したことすらありませんでした。なぜ勉強会をやろうと思い立ったかについては、以前のコラムに書きましたので、そちらを参照していただくとして、ここではまず、以前の私がコミュニティ活動に関して対して思っていたネガティブな印象、参加をためらわせていたことについて少し書こうと思います。

○難しそう。初心者に厳しそう

　1番目はこれです。

　「勉強会って詳しい人がたくさん集まって難しい話をしてそうだし、自分みたいな初心者が参加してもいいのか？」

なんて思ってました。自分みたいなよく分かってない輩が参加したら、白い目で見られたり、あるいは「もっと勉強してこい！」みたいに怒られたりしないか、という不安も若干ありました。勉強会などへの参加をためらっているかなりの人が、これと似たような印象を持っているのではないかと思います。

　では、勉強会に参加した後に先ほどの先入観がどのように変わったかですが、「詳しい人がたくさん集まって」という部分はあまり変わっていません。勉強会に参加するのはスキル向上に意欲的な人が多く、当然スキルの高い人が多いように見えます。

　ただ、そうした詳しい方々の多くは初心者などにも寛容で、勉強する意欲のある人たちに対してはアドバイスをしたりしていて、その点は少し印象が変わった部分です。

　ちょっと考えてみると、世の中にこれだけ技術系のブログとかがたくさんあって、そういう人たちが自分たちの知識・技術を惜しげもなく公開していることからして、そういう人たちの多くがほかの人にいろいろ伝えたいと思っていることが分かるかと思います。

　多分、見せ方の問題なのかな、と思います。

○何か内輪で盛り上がってる

　「勉強会って、何か小さなコミュニティに閉じていて、新しく来た人が入りづらそう」

　こんな風にも思っていました。意を決して勉強会に参加しても、ほかの人たちが何か内輪ネタで盛り上がっていたらちょっと悲しいですよね。

　私はそれほど多くの勉強会・セミナーの参加経験があるわけではないので（3つ）あまり確かなことは言えませんが、それほど疎外感は感じませんでした。この辺は各勉強会の主催者が心がけているところなのではないかと個人的には推測しています。

　ただ、周りは当然知らない人ばかりなので、最初はそれなりに不安ではありました。隣に座った人に話し掛けたりして話相手ができると、一気に落ち着くのですが。

■共通点、自分なりのコツ

　最初に、パーティーと勉強会には「人が集まる」という共通点があると書きましたが、それらをうまくやるコツにも共通点があるのではないかと思います。

　「こういう勉強会だといいな」と私自身思った経験も踏まえ、以下に、私が考える「勉強会をうまくやるコツ」を書きたいと思います。

○全員が主役。全員が貢献

　勉強会は有志が集まって勉強する会なので、参加者全員の貢献によって成り立っていると思います。Scala勉強会 in 渋谷を始めたのは確かに私なのですが、「主催者」みたいにいわれるのはちょっと違うかなと思います。回を重ねてきて、最近では技術や発表の面でも運営面でも、ほかの人の貢献が非常に大きくなっているのが、そう思う理由です。そして、参加者全員が何らかの形で貢献しているのが健全な勉強会なのではないかとも思います。

　パーティーでもそうで、料理を作ってきてくれる人、ビールを作ってきてくれる人（注：日本では違法です）、デザートを持ってきてくれる人など、いろいろいますし。それ以外にも、早めに来て部屋の片付けを手伝ってくれたり、途中でお皿とかグラスを洗ってくれたりしてくれる人、面白い話で場を盛り上げる人、CDとかたくさん持ってきて音楽を流してくれる人、友だちを連れてきてくれる人、いろいろな人によって成り立っていると思います。

・いろいろな形での貢献

　一口に『貢献』と言ってもいろいろな形があると思います。「何か調べて発表する」というのはもちろんそうですが、「質問する」というのも貢献になると思います。いろいろなレベル・いろいろな視点を持つ人が集まるので、単に質問するだけで、他人にとっては気付きになったり議論のネタになったり、いろいろなよい効果を及ぼすので、「貢献」と言えるでしょう。もちろん「質問に答える」のも貢献です。

　そのほか、勉強会の告知・宣伝をしてくれるというのもありがたいです。勉強会に来た方には大体、

　「もしよければ、今度は友だちや同僚とかもご一緒にどうですか？」

と声をかけるようにしています。

　本勉強会にはWikiがあるのですが、そこに書き込むのも貢献だと思いますし、自分のブログに勉強会の感想や技術的な補足などのエントリーを書くのも、フィードバックという点で重要だと思っています。

　参加してくれた方が、上に挙げたようなこと（あるいはそれ以外でも）をどれか1つでもやってくれれば、それでOKかなと思ってます。

・いろんな人に話しかける

　私がしている貢献はこれくらいです。皆さんが発表された後の質疑応答のときにいろいろな人の意見を引き出す、あるいは勉強会の前後の時間に初めて来た人に話し掛ける、いままで発表したことのない人に「何でもいいんで発表しませんか？」とお願いしてみる、などです。

　小さな勉強会なので、参加している皆さんも、是非いろいろな人に話し掛けて交流を深めてもらいたいと思っています。

○多様性

　いろいろな勉強会のスタイルがあるので、これに関しては千差万別なのかとも思いますが、本勉強会では「Scala」というキーワードが絡めば何でもあり、ということにしています。

　主な理由として、Scalaはそれほどメジャーな言語ではないので、範囲を絞ると参加者が少なくなってしまうというのが挙げられます。また、勉強会は毎週開催しているのでネタ切れを防ぐ意味合いもあります。

　Wikiの過去の発表内容を見てもらえば分かると思いますが、周辺ツールの使い方、フレームワークの説明、言語自体に関する考察など多岐にわたりますし、レベルも比較的初心者向けから割と高度な内容まで幅広いと思います。

　参加者の方を見ても、Scalaを実際に仕事で使っている人、これから使おうとしてる人、単に興味があるだけの人がいますし、バックグラウンドもJava、C++、Ruby、Perl、Erlang、Pythonなどいろいろです（私のようにプログラムがメインの仕事でない人もいます）。いろいろな人が、独自の視点で意見を出すのが面白いと思ってます。

　また、最近は外国人の方も1名参加してくれています。今後はそういう状況がどんどん増えていくのではないでしょうか。

　パーティーにおいても、「多様性」は重要だと思ってます。やっぱりいろんな人が集まった方が面白いです。もちろん、たくさん集まればあまり話の合わない人も出てくるとは思いますが、その場合はその人との会話は適当に切り上げて別の人と話せばいいだけですし。勉強会も、毎回参加する必要はなく、興味のある会だけ参加すればいいというところはそれに似ているかなと思います。

■まとめ

　長くなってきたのでまとめます。パーティーと勉強会には意外と共通点が多いのではないかと思いますし、うまくやっていくコツみたいなものも結構共通してるのではないかと思います。

　私が考える「理想的な勉強会」は

• いろんな人が集まって
• いろんな意見が出て
• 参加者全員が何らかの貢献をする

というものです。そのために必要なことは、

• いろんな人を誘って
• いろんな人に声をかけて
• 各自の貢献を促す

ではないかと考えています。

　Scala勉強会 in 渋谷は、毎週水曜日20時から開催していますので、ご興味のある方のご参加をお待ちしております。何かご質問などがありましたら、以下までお気軽にどうぞ。

　Twitter: @kaigaiengineer

　メール: kashima あっとまーく shibuya どっと scala-users どっと org

　それではまた。

　ちょっとネタが古くなってしまいましたが、1カ月前位くらいにCNET Japanで「在宅勤務のよくない点」という記事がありました。CNET Japanは海外の記事の翻訳が多いので、英語があまり得意でない方には便利なのですが、その反面、単に英語の記事を翻訳するだけなので日本ではまったく当てはまらない内容の記事もあったりします。

　「在宅勤務のよくない点」というのがまさに「日本ではまったく当てはまらない内容の記事」なのですが、結構面白いので、この話題について少し書こうと思います。

■北米における在宅勤務

○CNETによる「アメリカでの典型的な在宅勤務風景」？

　以前のコラムで少し触れたとおり、アメリカでは日本に比べると在宅勤務が一般的です。CNET Japanの記事によると、「年次スタッフミーティング」や「大型のアップグレードのために、オフィスに呼び出され」る以外ではオフィスに行かないというケースもあり、その結果「上司の顔を忘れ」ることがよくあるようです。

　また、アメリカは国土が広いので、「普段、時差があるところに住んでいる」人同士が同じプロジェクトで働くという事も割と一般的だそうです。

　CNETの元記事は恐らく若干誇張しているとは思いますが、それでもこういった話がまったくのフィクションではなく、それなりの現実味を持ってとらえられるというところを見ても、アメリカの在宅勤務の状況が日本とは異なることが分かるかと思います。

○実例

　わたしが北米の中小企業に勤めていた時は在宅勤務ではありませんでしたが、向こうっぽい経験をすることが二度ほどありました。

　一度目は、取引先のアメリカ企業（A社）が開発しているシステムの一部を担当するようになった時のことです。A社の社員は実質2名で、彼らは普段アメリカ中部のどこかの州の違う町に別々に住んでいて、打ち合わせはSkypeやWebEx（テレビ会議システム）を使っていました。

　システムは、わたしの会社とA社、A社の外注先のポーランドの会社（P社）の3社で開発したのですが、A社とP社とのやりとりも当然インターネット経由です。また、A社、P社、わたしの会社で三者通話の会議をすることも結構頻繁にありました。

　ちなみに、わたしがA社の2人と会ったのは、彼らが一度カナダに来た時の3日間だけで、P社の人とは会うこともありませんでした。

　二度目はわたしの会社が開発拠点をフィリピンに移した時です。わたしと同僚1名がフィリピンに転勤となり、現地開発者のチームに合流しました。それに伴い、カナダに残った開発者は基本的には自宅勤務となり、コミュニケーションはメールでのやりとりとなり、重要な話がある時だけSkypeを使う形になりました。

　わたしが北米で働いていたのは2年半ほどですが、その間に在宅勤務をしている人たちに2回会ったことからしても、日本より在宅勤務が普及していると言えるかと思います。

■日本では15.3％が在宅勤務？

　翻って、日本の状況はどうでしょうか。平成21年度テレワーク人口実態調査によると全体の15.3％が「テレワーカー」だそうです。「テレワーカー」の定義は以下の通りです。

• 普段、収入を伴う仕事を行っている人の中で、仕事でITを利用している人
• かつ、自分の所属する部署のある場所以外で、ITを利用できる環境において仕事を行う時間が1週間あたり8時間以上である人

　この定義からしていくつか突っ込みどころというか疑問があります。

• 週に2日はお客さまのところで作業するエンジニアの場合は該当するのか
• 自宅に仕事を持ち帰って、1日2時間以上家で仕事している人は該当するのか

などなど。

　そもそも、15.3％が「テレワーカー」というのがまったく現実味のある数字として感じられません。世間一般の方が「在宅勤務」という言葉から想像する勤務体系で働いている人は、わたしの周りでは

• 個人でたまにWebサイトのデザインをやっている主婦
• 企業に出向いて研修を行い、自宅で研修の報告書を作成するコンサルタント

の2名だけです。株のデイトレーディングで生計を立てている1名を含めても3名です。

　もちろん「類は友を呼ぶ」ので、わたしの周りに在宅勤務の人が少ないだけという可能性もありますが、標本の偏りが少ないと思われる小学校・中学校の同級生を考えても、同じクラスのうち約3人が在宅勤務しているというのは、どうも考えにくいです。控えめに言っても「テレワーカー」≠「（世間一般で言うところの）在宅勤務者」ではないかと思います。

■IT業界でこそ普及させてほしい

○なぜ普及しないのか

　日本で在宅勤務が普及しない理由の第一は、労務管理がしにくい（と思われている）ことが挙げられます。簡単な言葉で言うと、経営側が「社員は目の届くところに置いておかないとサボる」と思っていることです。

　少し話は変わりますが、IT業界ではいわゆる偽装請負、多重派遣、多重請負などが構造上の問題として存在することは、多くの方が認識されているかと思います。その理由の1つが、在宅勤務の場合とまったく同じ「人員を目の届くところに置いておきたい」ということだと思います。もし、在宅勤務の問題が解決すると案外、多重請負の構造も解決に向かったりするかもしれません。もちろん、多重請負の原因はそれ以外にもいろいろとあるのですが、ここでは触れません。

　また、情報漏えいを理由に在宅勤務に否定的な企業が数多くあります。一見すると正当な理由に思えますが、実際には導入にメリットを感じていない、あるいは単に検討するのも面倒、というところが多いような気がします。

○まずは自分たちから使えば？

　やれ業務改善のためのソリューション提供がどうのとかVPNが何だのという話を日常的にしている割に、日本の多くのIT企業では最先端のIT技術を活用しきれていないところが多いと思います。「紺屋の白袴」なんてよく言われますが、まずは自分たちの業務を改善してほしいと思うのですが、皆さんはどう思われますか。

■終わりに

　完全在宅だとメリハリをつけづらいと思っている方も多いかと思いますが、週に2～3日出社とか昼の数時間のみ出社でOKとかであれば、受け入れられやすいのではないかと思います。

　今後、社会に在宅勤務がどんどん普及していってほしいですし、われわれITエンジニアは、在宅勤務をサポートする効率的な仕組みを提供していくことで貢献していきたいですね。

　それではまた。

This work is licensed under Creative Commons Attribution-Share Alike 3.0 Unported License.

　どうも、鹿島和郎（かしまかずお）です。秋の夜長にプログラムというのは平安時代からの日本の風景ですが、「その0」「その1」とやってきたsymfonyでのi18nの説明も今回で最後となります。

　前回は、symfonyでi18n対応アプリを作るための設定がほぼ完了しました。あとは、以下のような定常的な作業が残っているので、それについて説明します。

• ソースコード中のテキストを__()でくくる
• テキストの抽出
• テキストの翻訳

■ソースコード中のテキストを__()でくくる

　以前のコラム「i18nしてますか？（PHP+gettext）」（その1、その2）を読んで下さった方は文字列を_()でくくる作業を覚えていると思いますが、symfonyの場合には__()でくくります。アンダースコアが2つですのでご注意ください。

　例えばこんな感じです。

# 変更前
echo 'Hello World!';
# 変更後
echo __('Hello World!');

　文字列中に変数が入る場合は、以下のようにします。

# 変更前
echo "Hello, ${name}!";
# 変更後
echo __("Hello, %name%!", array('%name%' => $name));

　変数が入る部分を%name%というプレースホルダーにして、そこに変数の値を入れるという形です。

　さて、前回の最後で以下のようなファイルを作成しました。

<!-- apps/frontend/modules/default/templates/indexSuccess.php -->
<h1>Welcome to my i18n test page.</h1>
Go to <?php echo link_to('list page', 'post/index') ?>

　それを、以下のように変更します。

<!-- apps/frontend/modules/default/templates/indexSuccess.php -->
<h1><?php echo __('Welcome to my i18n test page.'); ?></h1>
<?php echo __('Go to the %list_page%',
   array('%list_page%' => link_to('list page', 'post/index'))); ?>

■テキストの抽出

　次に、__()でくくったテキストを以下のコマンドで抽出します。概念としてはgettextと大体同じです。

$ symfony i18n:extract frontend ja --auto-save

　コマンドを実行すると、以下のファイルが作成されます。

apps/frontend/i18n/ja/messages.xml

　messages.xmlの中身は以下のようになっています。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xliff PUBLIC "-//XLIFF//DTD XLIFF//EN" "http://www.oasis-open.org/committees/xliff/documents/xliff.dtd">
<xliff version="1.0">
  <file source-language="EN" target-language="ja" datatype="plaintext" original="messages" date="2010-09-18T15:07:56Z" product-name="messages">
    <header/>
    <body>
      <trans-unit id="1">
        <source>Welcome to my i18n test page.</source>
        <target/>
      </trans-unit>
      <trans-unit id="2">
        <source>Go to %list_page%</source>
        <target/>
      </trans-unit>
      <trans-unit id="3">
        <source>list page</source>
        <target/>
      </trans-unit>
    </body>
  </file>
</xliff>

■テキストの翻訳

　あとは、ひたすら翻訳するだけです。翻訳後のmessages.xmlは以下の通りです。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xliff PUBLIC "-//XLIFF//DTD XLIFF//EN" "http://www.oasis-open.org/committees/xliff/documents/xliff.dtd">
<xliff version="1.0">
  <file source-language="EN" target-language="ja" datatype="plaintext" original="messages" date="2010-09-18T15:07:56Z" product-name="messages">
    <header/>
    <body>
      <trans-unit id="1">
        <source>Welcome to my i18n test page.</source>
        <target>私のi18nのテストページにようこそ。</target>
      </trans-unit>
      <trans-unit id="2">
        <source>Go to %list_page%</source>
        <target>%list_page%に行く。</target>
      </trans-unit>
      <trans-unit id="3">
        <source>list page</source>
        <target>一覧ページ</target>
      </trans-unit>
    </body>
  </file>
</xliff>

　変更したら、以下のコマンドでキャッシュをクリアしてください。

$ symfony cc

■完成＆その後

○動作確認

　以上でi18n対応は完成です。下記URLにアクセスすると、

http://www.example.com/i18ntest/frontend.php/

このように日本語のメッセージが表示されるはずです。

　言語切り替えのプルダウンが動作するかどうかも確かめましょう。

○宣伝しよう、そうしよう

　これでsymfonyアプリのi18nが完了しました。後は、海外のMLやFacebookとかで宣伝したり、Twitterで英語でつぶやいたりして、みんなに使ってもらいましょう。

メールの例文：

Hi there,

I'm developing a small app for XX（用途、ターゲットユーザーなど）
and it's available at the following page.
http://www.example.com/super-cool-app-by-a-japanese-programmer.html

I hope some of you find it useful（ゲームとかならfunとか）.
Any feedback would be appreciated.

Thanks,
名前

○テキストの追加・修正

　PHP+gettextのときに、ソースコード中のテキストが追加・修正された場合の対応方法について説明しましたが、symfonyの場合は面倒なマージ作業などは必要ありません。以下のコマンドを実行するとmessages.xmlが更新されますので、messages.xml内の翻訳を追加・修正してください。

$ symfony i18n:extract frontend ja --auto-save

■まとめ

　symfonyはそれなりの規模のサイト作成にも耐えられる本格的なフレームワークで、本コラムで示したような比較的簡単な手順でi18n対応できます。

　これから新規でサイトやサービスを作る場合には、symfonyは有力な選択肢となり得ると思いますが、その際に、最初からi18n対応しておくと最近ブームの海外展開がスムーズに行えると思います。

　さて、3回に渡って書いてきた「i18nしてますか？（symfony）」は今回で終了です。疑問点、間違いのご指摘などはコメントいただけると助かります。

　今回のコードはLaunchpad上に置いてありますので、興味のある方は以下のブランチを取得してください。

lp:~k4200/+junk/i18ntest-symfony

　次回は、技術から離れて久しぶりに軽い話題にしようと思っているのですが、若干ネタ切れ気味です。多分海外ネタで何か書きます。

　それではまた。

This work is licensed under Creative Commons Attribution-Share Alike 3.0 Unported License.

　どうも、鹿島和郎（かしまかずお）です。日本では食欲の秋、プログラムの秋などとよくいわれますが、食欲旺盛（おうせい）なプログラマの皆さまはいかがお過ごしでしょうか。

　わたしの方はというと、エンジニアライフでコラムを書いている方々が集まるオフ会のようなものが先週末にあり参加してきました。その際に

　「みんなネタコラムばっかりで、技術的な事を書いている人ってほとんどいないですよね」「（一同うなずく）」

なんていう場面があったのですが、そんな逆風にも負けずに今回も技術ネタでいきます。内容は前回予告したとおり2回に渡ってsymfonyでのi18nについて説明していきます。具体的には以下の内容を説明します。

• 設定ファイルの変更
• URLにカルチャーを含める設定
• ソースコードの修正
• 言語切り替えメニューの追加

■設定変更（settings.yml）

　取りあえずおなじみのfrontend/backendという2つのアプリケーションがあると仮定します。

　apps/frontend/config/settings.ymlに対する変更点としては以下の3つです。

• i18nの有効化
• デフォルトのカルチャーの設定
• I18Nヘルパークラスを有効にする

　i18nの有効化は、単に1行設定を書くだけです。おまじない的なものなので、説明は省略します。

　デフォルトのカルチャーは、ハリウッドを目指すのであればen_US、まずは国内向けで展開するのであればja_JPです。

　ここまでは問題ないかと思いますが、3番目のI18Nヘルパークラスに関して少し説明します。

　I18Nヘルパークラスはその名の通り、i18n関係の処理をまとめたヘルパークラスで、具体的には、後述する__()などがI18Nヘルパークラスで提供される機能です。settings.ymlでI18Nヘルパークラスで有効にすると、すべてのページ（テンプレート）で使えます。settings.ymlで有効にしない場合は、I18Nヘルパークラスを使う際に以下のコードを書く必要があります。

<?php use_helper('I18N') ?>

　settings.ymlの最終的な変更点は以下の通りです。

# apps/frontend/config/settings.yml
all:
  .settings:
    i18n: true
    default_culture: ja_JP  # 又はen_US
    standard_helpers: [Partial, Cache, I18N]

■URLにカルチャー名を含める設定（routing.yml）

　分かりにくい見出しですみません。要するに以下のようなURLでアクセスして言語が切り替わる設定です。

• http://www.example.com/i18ntest/frontend.php/ja/
• http://www.example.com/i18ntest/frontend.php/en/

　具体的には、routing.ymlの"homepage"以外のエントリに対して、以下のように:sf_cultureという文字列を追加します。

# apps/frontend/config/routing.yml
# 変更前
default_index
  url:    /:module
  param:  { action: index }

default:
  url:    /:module/:action/*

# 変更後
default_index
  url:    /:sf_culture/:module
  param:  { action: index }

default:
  url:    /:sf_culture/:module/:action/*

　また、各国語用のホームページ（localized_homepage）も用意します。

localized_homepage:
  url:    /:sf_culture/
  param:  { module: default, action: index }
  requirements:
    sf_culture: (?:ja|en)

■ソースコードの修正

　ここまでで、事前準備は大体完了しました。後はソースコードを少し修正する必要があります。もう一息ですのでお付き合いください。

　コードの修正内容は、基本的にはsymfonyチュートリアルの以下のページに載っているのものをそのまま使えばOKですが、違いがある場合のみ説明します。

　Day 19: Internationalization and Localization （日本語、英語）

○myUser.class.php

　まずはmyUser.class.phpに初回アクセスかどうかを返すメソッド（isFirstRequest）を追加します。

　実装内容は、チュートリアルのページの apps/frontend/lib/myUser.class.php と同じで以下の通りです。

class myUser extends sfBasicSecurityUser
{
  public function isFirstRequest($boolean = null)
  {
    if (is_null($boolean))
    {
      return $this->getAttribute('first_request', true);
    }
    $this->setAttribute('first_request', $boolean);
  }
}

○action.class.php

　次に、routing.ymlの"homepage"で呼び出されるモジュールを修正します。わたしの場合、routing.ymlは以下のようになっています。

# routing.yml
homepage:
  url:   /
  param: { module: default, action: index }

　従って、修正するのは以下のファイルです。

　apps/frontend/modules/default/actions/action.class.php

　もしこのファイルが存在しない場合、symfonyのインストールされているディレクトリからコピーしてきて使いましょう。

cp -R /usr/share/pear/symfony/controller/default/ apps/frontend/modules/

　修正内容としては、初回リクエストの場合にはカルチャーをセットし、それ以外の場合はセットされているカルチャーの値に従って、localized_homepageを表示するようにします。

　実装内容は、チュートリアルのページの apps/frontend/modules/job/actions/actions.class.php と同じで以下の通りです。

public function executeIndex(sfWebRequest $request)
{
  if (!$request->getParameter('sf_culture'))
  {
    if ($this->getUser()->isFirstRequest())
    {
      $culture = $request->getPreferredCulture(array('ja', 'en'));
      $this->getUser()->setCulture($culture);
      $this->getUser()->isFirstRequest(false);
    }
    else
    {
      $culture = $this->getUser()->getCulture();
    }
    $this->redirect('localized_homepage');
  }
}

○ここまでで動作確認

　ブラウザで以下のURLにアクセスすると、

　http://www.example.com/i18ntest/frontend.php/

自動的に以下のURLにリダイレクトされればOKです。

　http://www.example.com/i18ntest/frontend.php/ja/

■言語切り替えメニューの追加

　これで大体完了なのですが、もうちょっと頑張って、言語切り替えのプルダウンメニューを追加します。行うことは、基本的には本家チュートリアルの通りです。

○sfFormExtraPlugin のインストール

　これは問題ないでしょう。以下の通りインストールします。

$ php symfony plugin:install sfFormExtraPlugin

　※実はこのプラグインにはごく最近までバグがあったのですが、最近は直ったようです。

○languageコンポーネントの作成

　言語切り替えメニューは「コンポーネント」として実装します。その為に、最初にlanguageという名前のモジュールを作成します。

$ php symfony generate:module frontend language

　次に、apps/frontend/modules/language/actions/components.class.php というファイルを作成し、コンポーネントを実装します。チュートリアルのページの内容とほぼ同様ですが、今回対応するのは英語（en）と日本語（ja）ですので、コードは以下のようになります。

<?php
class languageComponents extends sfComponents
{
  public function executeLanguage(sfWebRequest $request)
  {
    $this->form = new sfFormLanguage(
      $this->getUser(),
      array('languages' => array('ja', 'en'))
    );
  }
}
?>

　最後に、言語切り替え用のフォームを部品化します。パーシャルと同様の命名規則で、_language.php というファイルを作成します。

　実装内容は、チュートリアルのページの apps/frontend/modules/language/templates/_language.php と同じで以下の通りです。

<form action="<?php echo url_for('change_language') ?>">
  <?php echo $form ?><input type="submit" value="ok" />
</form>

○アクションの作成

　あとは、言語切替用のプルダウンの値が変更されたときに呼び出されるアクションを作成します。

　実装内容は、チュートリアルのページの apps/frontend/modules/language/actions/actions.class.php とほぼ同様ですが、ここでも対応するのは英語（en）と日本語（ja）ですので、コードは以下のようになります。

// apps/frontend/modules/language/actions/actions.class.php
class languageActions extends sfActions
{
  public function executeChangeLanguage(sfWebRequest $request)
  {
    $form = new sfFormLanguage(
      $this->getUser(),
      array('languages' => array('en', 'ja'))
    );
    $form->process($request);
    return $this->redirect('localized_homepage');
  }
}

　次に、apps/frontend/config/routing.yml に以下のエントリを追加し、change_languageにアクセスされたときに、上で作成したアクションが呼び出されるようにします。

change_language:
  url:   /change_language
  param: { module: language, action: changeLanguage }

○layout.phpの編集

　あとは apps/frontend/templates/layout.php の好きな場所に以下1行を追加し、どのページでも言語が切り替えられるようにします。

    <?php include_component('language', 'language') ?>

■動作確認

　今回のテストサイト用に、以下のようなトップページを作成しました。

<!-- apps/frontend/modules/default/templates/indexSuccess.php -->
<h1>Welcome to my i18n test page.</h1>
Go to <?php echo link_to('list page', 'post/index') ?> 

　http://www.example.com/i18ntest/frontend.php/

にアクセスすると、

　http://www.example.com/i18ntest/frontend.php/ja/

にリダイレクトされ、以下のようなページが表示されるはずです。

　Languageが「日本語」になっているのが分かるかと思います。

■まとめ

　ここまででsymfonyでのi18nの設定関連はほとんど完了しました。次回は、ソースコード中のメッセージをメッセージファイルに抜き出して、それを翻訳するところを説明します。

　それではまた。

■勉強会関連

○会場確保

　さて、前回の勉強会会場は「株式会社××」と伏字にしましたが、会員番号2番が会社の上層部の方に掛け合ってくれた結果、社名公開の許諾がおりました。株式会社××改め株式会社HDEさんの会議室を、毎週1回、勉強会会場として公式に使わせていただけることになりました。

　前回は何となくこっそりとやった感はあるのですが、次回は堂々と実施することができます。

○ATNDにイベント登録した

　上述のHDEの方からATNDで参加者を募ってはどうかと提案されましたので、早速イベント登録をしてみました。

　（わたしも含め）参加者の多くはScala初心者ですので、東京近郊でご都合の付く方はお気軽に参加していただければと思います。

　Scala勉強会第2回 in 渋谷

○Scala勉強会＠東北に参加した

　Twitter上でScala勉強会＠東北をオンライン配信しているという情報を得て、早速9月2日の回を拝聴しました。

　内容は「Scala Watch」という、Scalaコミュニティの1週間を振り返るコーナー、そして2.8で新しくなった（らしい）コレクションクラスの説明です。個人的には「Scala Watch」が非常に役に立ちました。

　あと、画面配信には独自のしくみ（？）を使っていたようで、画面が鮮明でした。次回か次々回あたりから取り入れたいと思います。

　実は、Scala Watchでは第1回読書会もちょっと触れていただいたので、挨拶がてらTwitterでちょっと反応しようかと思ったのですが、小心者なので何もしませんでした。すみません。

○発表者確保

　後述しますが、9月4日にもScala座というScalaユーザーが集まるイベントに参加してきました。灼熱（しゃくねつ）の名古屋で開催されましたが、関東からの参加者も比較的多かったです。お話しした数名に勉強会の話をしたところ、興味を示したため、半ば強引に発表をお願いして引き受けてもらいました。

　家に引きこもらないで積極的にコミュニティに参加する、という今年の目標（？）はどうやら達成されたっぽいので、この積極性を女性に対しても発揮していくことが来年の目標となりそうです。

■Scala座

　Scalaをはじめて約1週間。書いたコードの総行数は20行程度の素人にもかかわらず、日本全国からScalaの猛者が集まるイベントに参加してきました。

　発表内容は、理論的な話、事例紹介、デモ、ライトニングデバッグ、そして名古屋名物ライトニングデバッグと多岐に渡ります。レベルとしても、素人でも比較的分かりやすい話から結構専門的な話までいろいろあり、なかなか密度の濃いイベントだったと思います。

　まとめページを作った方がいらっしゃいますので、ご興味のある方はそちらをご参照ください。

○個人的に興味を持った発表

　以下、わたしが興味を持った発表をいくつか挙げたいと思います。

・Scala Daysに行ってみて（資料）

　Scala Days 2010というワークショップに行って発表をしてきたそうです。他の方の発表やScala開発チームの方達とのお話などを紹介していました。

　Scala Days 2010のプログラムはこちら。

　わたしとしては、純粋な技術的興味もありますが、実際に使えるの？ という部分が気になりますので、以下2つの発表は興味深く見られました。

• Sneaking Scala Into Your Organization
• Scala at LinkedIn: Distributed Computing with Norbert

・Lift on GAE/J（資料）

　Scalaで動くWebフレームワークをGoogle App Engine上で動かす際の問題点を説明していました。結論としては、現段階ではLiftをGAEで使うのはまったくおすすめできないとのことです。

・Scala 2.8でひるまのおしごとしてみたよ（資料）

　Scalaを使ったサービスの事例紹介です。LTなので細かい話は聞けませんでしたが、この内容＋αで勉強会で発表していただけることになったので、そのときにまたいろいろ質問しようと思ってます。

　ちなみにどういった夜のお仕事をされているのかは不明です。

・ライトニングデバッグ

　きしめん、味噌煮込み、名古屋台湾ラーメンなどの独自の食文化、そして、派手な結婚式、名古屋撃ち、名古屋嬢などの他に類を見ない数々の文化を誇る名古屋。IT関係のコミュニティ活動が非常に活発なのも特徴だそうです。独自性を重んじる名古屋の中でも一際異彩を放つのが、近年積極的に行われている「ライトニングデバッグ」だそうです。

　形式としては、5分程度の持ち時間の前半でコード（バグ持ち）の説明などを行い、後半で会場のみんなの英知を結集させてデバッグをします。持ち時間内にデバッグが完了すればOKというもの。

　わたしは一番後ろの席に座っていたためスクリーン上のコードが読めず、また、読めたところで何の貢献も行えないのでちょっと置いてけぼり感があったのですが、どうやらバグは直せたようです。

　ちなみに発表のタイトルは「ワラビモチとScalaについて」でした。資料はネットには上がっていないようです。

○懇親会

　知らない人ばっかりのイベント・勉強会の類に参加するのは今回が初めてでした。ですが、参加登録の際に勇気を出して「懇親会参加」のラジオボタンもクリックしました。

　懇親会は近くのチェーン居酒屋で開催。横長いテーブル席だったので、あまり沢山の方とはお話できませんでしたが、いろいろと興味深いお話を聞かせてもらいました。

　個人的に興味深かった話題がScalaコンパイラ（Scalaのソースコード→classファイルにコンパイル）の速度の話でした。

　　「Scalaコンパイラって少し遅いね」に対して、以下のような意見が出ました。

• それでScalaイラネっていう人も、もしかしたらいるのかも
• 頻繁にコンパイルするっていう使い方ってあまりしないと思う
• Rubyみたいな使い方をScalaに求めるのがそもそも間違い
• 型推論など、Javaのコンパイラに比べてやるべきことが多いので、遅くなるのは仕方ない

　ScalaをRubyなどのスクリプト言語の代替にするというのは、少なくとも言語の設計者や現在のScalaユーザーの大半の方にとっては想定外と思われます。ただ、適材適所の重要性はもちろん理解していますが、個人的には、あるツール・言語の使い方を最初から限定するのではなく、当初想定されていない使い方でも、ユーザーが自由にやることで何かが生まれる可能性もあると考えています。ですので、スクリプト言語的な使い方をするにはどうすればいいのか、みたいな議論もありかなと思ってます。

○2次会、そして3次会

　2次会は当然。有志6名による3次会も、某ビジネスホテルのロビーにて深夜2時まで開催されました。いろいろためになるお話を聞けて、個人的には満足しています。

　遅くまで付き合ってくださった方々、ありがとうございます。

○雑感

　さて、本イベントに参加して思ったことをいくつか書いていこうと思います。

・業種の壁？

　参加者の多くが高い技術を持った方々で、職種としては現場のエンジニアの方が中心でした。また、業種としては（わたしがお話しした範囲では）Web系の方が多かったです。

　わたしは業務系のシステムを扱うことが多いのですが、業務系とWeb系の間では技術者の交流があまりないような気がします。みなさんの周りではどうでしょうか。そうした「見えない壁」みたいなのを取り除いていくと、いろいろとみんなが幸せになれるような気が何となくしてます。

　ギラギラした起業家（準備中も含む）が集まる暑苦しい「異業種交流会」みたいなのにはあまり興味はありませんが。

・最先端の技術者≠尊敬の対象

　そのほか、印象に残っているのが、懇親会の席で数名の方が

　「（今回のようなイベントに）行くっていっても、あまり理解されない」

　「よくて『真面目なんですね』っていう反応が返ってくるくらい」

　「どうせ引かれるので会社の同僚には話はしてない」

などと言っていたことです。

　高い技術・意欲を持ったエンジニアの方々が、必ずしも尊敬の対象ではない、変わり者・マイノリティとなっているのは、なかなか興味深いと思いました。日本でのプログラマ軽視に関しては、以前のコラムでも少し触れたような気がしますが、もっと多くの人が考えていくべき問題だと思います。

■Programming Scalaはどうなったの？

　タイトルが「Programming Scala読もうぜ」のくせに、本の話にまったく触れないのも問題ですので、少しだけ。

　先週もぼちぼち読み進めてはいたのですが、本書のサンプルプログラムのコンパイルで依存関係などが出てきて、だんだん面倒になってきました。ということで、現在サンプルプログラムのビルド環境を作っています。

　当初はsbt（simple-build-tool）というコマンドラインのツールを使おうと思ったのですが、名古屋でMavenの利用を薦められたので、そちらを使って悪戦苦闘中です。ある程度めどが立ったら勉強会で発表します。

　サンプルプログラムのダウンロードはO'Reillyのページより。

■まとめ・今後

　Scala座は、参加費・新幹線代・飲み代・ホテル代・お土産代……などを合わせるとそれなりの出費を伴いました。しかし、それ以上のものを得られたと思います。

　勉強会に関しては、ぼちぼち軌道に乗ってきたのでは、といい切ってしまいます。早めに勝利宣言を出すのが未成熟な人間の特徴ですので、どうかご容赦ください。

　あとはわたし自身がもう少しレベルアップするとともに、初心者向けの内容を勉強会やブログなどで公開しようと思ってます。英語が苦手な方も多いようですので、本家MLのまとめを毎週ブログで紹介しようかとボンヤリ考えています。

　さて、思いつきで始めた「Programming Scala読もうぜ」シリーズは今回でいったん終了として、次回からまたi18n関係の話でもしようかと思います（多分）。

　それではまた。

　業界経験約10年の中堅技術者が、たまたま読んだ聖典（アプレンティスシップパターン）に影響され、関数型言語であるScalaを勉強しようと決意する。聖典の教えのままに東京近郊でのコミュニティ・勉強会がないかをチェックするものの、大都会東京は関数型言語勉強会不毛の地である事実に打ちのめされる。

　しかし、聖典中の「存在しない場合は自分で作りなさい」という教えに従い、オンラインで無料で読めるProgramming Scalaという書籍のオンライン読書会を計画する。

■前回からの進ちょく

　どうも、鹿島和郎（かしまかずお）です。まずは前回からの進ちょくを報告します。

　わたしが自分でやったことは以下の通りです。

• 資料を作成した
• Twitter上でちょびっと宣伝した
• 知り合いにちょびっと宣伝した

　他の方からもいろいろな情報、ご協力をいただきました。

• 以前の会社の後輩から、彼の同僚が興味があるとの情報をもらった
• Twitter上で、ある方からScalaの導師を紹介していただいた
• Twitter上で、別の方からScalaのメーリングリスト（Googleグループ）を教えてもらった
• Twitter上で、さらに別の方より、東北のScala勉強会がオンラインでやっていることを教えてもらった
• 同じ方より、Scala座というイベントへの参加をすすめられた

　皆さん親切に教えてくださって、大昔のバーモントカレーの……すみません。もういいません。

■まずは自分が動かねば

　人を集めるには、やっぱり自分が行動しないとダメですよね。ということで、慣れないことをいっぱいやってみました。

○資料作成

　取りあえずGoogle Docsで資料を作り始めました。簡単に公開できるので便利ですが、やっぱりPowerPointに慣れていると機能面で不満もあります。その後、SlideShareなるものの存在を知ったので、今後はこっちを試してみようと思います。

　資料の内容は、基本的には本文の要約です。それをもとに

• 技術的な解説
• 英語の解説

をやろうと思ってました。資料はこちらのページより。

○宣伝活動を少々

　人に大々的に宣伝するのって苦手なんです。Twitterでぼそっとつぶやいて、後は興味を持ってくれそうな知り合い数名にメールを出したくらいです。

　MLにメールも出したんですが、それすらかなり緊張しました（詳しくは後述）。

○元後輩の同僚が興味有り

　以前の会社の後輩（会員ナンバー2番）にメールをしたところ、彼の同僚などにメールを転送してくれて、そのうちの1名が興味を示してくれました。早速メールをして、参加メンバーとして勧誘成功。会員ナンバー3番です。

　ちなみに、以下は彼のメール。

> つまりは、Scalaの輪講をやろうということでしょうか？

　「輪講」って単語、かなり久しぶりに聞きました。ちなみに彼の大学時代の研究室では「コロキ」と呼んでいたとか。ググったところ、ラテン語由来らしいです。

■有用な情報が続々集まる

○北北東にScala導師あり

　Twitter上で、とある方からScala導師の存在を教えていただきました。英語だとguruです。聞くところによると、わたしの自宅から北北東に数十里行ったところに普段はいらっしゃるとか。直接面識はないので名前を出すのは差し控えますが、海外のカンファレンスなどでも発表を行っている求道者だそうです。

　早速その方をフォローしました。

○北方の地にてオンライン勉強会が存在するとの情報

　Twitter上で別の方よりScalaのメーリングリスト（Googleグループ）を教えていただきました。早速参加し、勇気を振りしぼり「初めまして」メールを出したところ、（恐らくそのメールを見たと思われる）数名の方がTwitterでわたしをフォローしてくれました。

　そのうちの1人の方からのTweetで、衝撃の事実が。

木20時だと、scala東北さんのオンライン勉強会と時間がかぶりますので別の曜日ではどうでしょうかー？

　その勉強会の名前自体は、ググって知ってたのですが、「東北」という2文字が入っていたためノーチェックでした。まさかオンラインでやっているとは……。

　早速、第90回を拝聴させていただく予定です。

○Scala座の新人

　先ほどのオンライン勉強会を教えてくださった方から、9/4（土）にScala座というScalaに関するイベントに参加してはどうか、とすすめられました。これも存在自体はググって知っていたものの、場所が名古屋ということでためらっていたのですが、せっかくなので参加することにしました。

　いやぁ、Scalaを勉強し始めて1週間程度なのに、こんなハイレベルそうなところに行っていいのかとも思います。しかし、せっかくなのでいろいろ最先端の話を聞いてこようと思います。ちなみにLTの話者も募集していたのですが、Scala経験1週間＆LT未経験だとさすがにツラいので、今回は見送りました。

　本イベントは、（多分）次回あたりに簡単にレポートしようと思います。

○新たな参加者が

　まずは内輪だけでやるかーと思っていた矢先、上述のメーリングリストを見た方（Tさん）から参加希望のメールをいただきました。しかもその人のTwitterとか見てみたら、どうやらかなりの技術の鉄人らしい。若干腰が引けたのですが、「初心者向けの内容でもよろしければ……」という内容の返信をしたところ、快くOKしてもらいました。

　後述しますが、約1カ月後に発表をしていただけることになりました。

■そして勉強会！

○オンラインからオフラインへ

　事前準備をしているときに、会員番号2番からこんなメールが来ました。

> ところで、当日の動きなんですが、
> 20:00ごろに鹿島さんが××（筆者注：彼の会社）に来られて、
> 会議室で一緒にScala、と認識であってますか？
> （9/1 20:00からの会議室はすでに押さえてあります）

　え？ 自分が自宅からUstreamで流して、それを見てもらって、後はオンラインで適当にやりとりしようと思ってたんだけどなー。

　でも、せっかくなんで会議室を使わせてもらって、そこでの勉強会の内容をUstreamで配信する、という形に方針転換しました。

○第1回（？）開催

　さて、記念すべき読書会第1回は9/1に実行しました。前回のはテストなのでカウントしないこととします（あるいは第0回とでも呼んでおきます）。今後、仮に参加者が増えてきたときに、

「あの第0回があったから今の隆盛があるんだよなー」

と、古参スマップファンが某オートレース選手を懐かしむかのごとく、公式には存在しないことになっている第0回を振り返れたらいいなぁなんて思ってます。

　当日は19時半にTさんと渋谷モヤイ像前で待ち合わせ。5分位前に着いてあたりを見回すとiPadをいじっている人がいたので、まぁこの人で間違いないだろうと90％の確信は持ちつつも、念のため事前に聞いていた携帯をコール。結果は正解でした。

　その後、Scalaとの出会いやTさんが参加したRubyKaigiの話とかをしつつ、会場である株式会社××（取りあえず今回は伏字）を目指します。

　道中で、晩飯終了直後の会員番号2番、3番と合流し、いざ会議室に。

　会議室でPCをセットアップしてたら、なんだか人が続々と……どうやら、会員番号2号が後輩をたくさん連れてきてくれたようです。当初の4人だけの予定が結局9名が集まり、Ustreamでも5～10人くらいが見てくれたようでした。

　みなさま、ありがとうございました。

○やったこと

　さて、肝心の勉強会の内容ですが、Programming Scalaの第1章のうち、「Why Scala」の部分を主に説明しました。英語の解説もするつもりでしたがほとんどしてません。

　あとは、各人のScalaを始めたきっかけなどを話し合ったり、クロージャーって何って話がでたり。個人的には結構楽しめました。参加された方はいかがでしたか。

　今回の読書会の内容は、わたしのブログの方にメモ書き程度に残しておきましたので、興味のある方はご覧ください。

■今後の方針

　取りあえず、何とか第1回は無事終了し、今後の発表に関してもオフライン組から2名、Ust組から1名手を挙げてもらいました。内容もProgramming Scalaに関係なく、Scalaに関することなら何でもOKということにしました。

　基本的には毎週水曜にゆるい感じでやっていければと思っています。

　さて、最後にわたし自身のScalaの勉強の進ちょくに関しても少し書きます。"Programming Scala"を、サンプルプログラムを実行しながら読み進めているのですが、現在第4章の「Traits」まできました。だんだん面白くなってきたところです。

　これからどんどんスピードアップをして、今年中には普通にプログラムが書けるレベルになりたいです。来年の前半には、実際のプロジェクトで使ってみたいというひそかな野望もあったりします。

■まとめ

　思いつきから始まった今回のProgramming Scala読書会。取りあえず上々の滑り出しをすることができました。いろいろな情報を下さった皆様、参加して下さった方々、どうもありがとうございます。

　次回は、Scala座の参加報告や、Scalaの技術的な話題にも触れたいと思います。

　最後に、読書会改め、勉強会の情報をもう1度ここに書いておきます。

• 概要はこちら（追記・修正予定です）
• 参加方法
  • Ustreamで視聴してください。当たり前ですが途中入場・途中退室OK。
  • オフライン（渋谷）で参加したい場合は、わたしあてにご連絡ください。
• Twitterをチェックしておくと何かいいことがあるかもしれません。
  • わたしのアカウント： @kaigaiengineer
  • ハッシュタグ： #rpscala

　それではまた。

p.s. 聖典↓はおすすめです。★5つ付けていいくらい。

■熟練職人になろうぜ

○本を読もうぜ

　ちょっと前にTwitter上で（少しだけ）話題になっていた「アプレンティスシップパターン」という本を先日読みました。何にでも影響を受けやすいわたしとしては、次の日から早速「熟練職人になるぞ！」という誓いを立てました。

　本の内容についてはいろんな人が書評や感想などを書いているので、ここでは詳しく説明しません。ざっくりいうと「ソフトウェア開発者見習い」（アプレンティス、apprentice）がどうやって技術を伸ばしていくかについての実践的なパターンが紹介されています。

　わたしは職歴としては、そこそこの年数があるためか、正直いって最近は技術的な勉強を怠りがちでした。でも、この本で目から鱗が落ちた部分もあります。最近はまた学ぶ意欲を取り戻すとともに、本書に紹介されているパターンをできるだけ実践するように心がけています。

　さて、そんなわたしが今回実践しようとしてるのは以下のようなパターンです。

• 学びを共有する（Share What You Learn）
• 無知をさらけ出す（Expose Your Ignorance）
• 白帯（The White Belt）
• 学びを記録する（Record What You Learn）
• 気の合った者同士（Kindred Spirits）

○新しい言語を勉強しようぜ

　いままでいろいろな言語を使ってきました。しかし、ここ最近はあまり新しい言語を勉強しておらず、何か新しいのを覚えようと思い立ちました。

　そういえば、最先端のギーク達の間では（？）関数型言語なるものがちょっと話題になっているそうです。その噂を小耳に挟み、関数型言語が何なのかもよく分からないまま、「関数型言語を1つ覚えよう」と決めました。

  Wikipediaの関数型言語のエントリを見ると簡単な説明があり、

• 「純粋」と「非純粋」という概念での区分
• 「静的」と「動的」型付けによる区分（それに加えて「型なし」というのもあるらしいです）

で、主要な関数型言語が分類されていました。

　LISPは当然、Haskell、F#などの名前は聞いたことがありました。しかしそれらの言語の特徴はまったく分かりません。それでも、取りあえず1つを選ばなければいけませんでした。

　まずは先ほどのWikipediaでの区分ですが、「純粋」と「非純粋」に関しては、素人の自分にとっては純粋性にこだわる意味がその時点ではよく分からなかったので（というかいまでも分かってません）、この区分により候補を振り分けることはしませんでした。

　「静的」と「動的」に関しても、両方のタイプの言語を使ったことがあるので、正直どちらでもいいと思ってしまいました。

　要するに、Wikipediaのエントリは、「どの関数型言語を学ぶべきか？」 というわたしの疑問にはまったく答えてくれないことが分かりました。

　ただ、自分の中では

　「せっかく勉強するなら、何かに使いたい」

という思いがありましたので、実用性を判断基準として、言語を1つ選ぶことにしました。

　その後、さらに1時間くらいネットを検索した結果、

• Twitterでも使われてる
• JVM上で動き、Javaの過去の資産が生かせる（※）
• LiftなるWebフレームワークがあるらしい

という3つの理由により、Scalaを選ぶことにしました。

※CLR上（.NET）でも動きます。

■Scalaやろうぜ

○コミュニティ探そうぜ

　さて、Scalaを勉強する事は決定しました。「アプレンティスシップパターン」（長いので、以降「アプパタ」と略します）によると、ローカルのコミュニティに参加すべしとあるのですが、極度の出不精なわたしはいままでそういったコミュニティ活動などには参加したことがありません。

　しかしそのままでは永遠に見習いのままです。意を決してIT勉強会カレンダーでScalaの勉強会がないかを探してみることにしました。その結果、Scalaの勉強会はいくつか見つかりました。が……なぜか東京近辺のみ開催予定がありません。むー。

　PCの前で涙を流し続けること1時間、仕方ないので取りあえず独学で勉強することにしました。

○Programming Scalaが無料で公開されてる！……ぜ

　さて、徐々に本題に近づいてきました。もう少しお付き合いください。

　これもしばらく前に少し話題になっていましたが、O'Reillyが古い書籍のオンライン版を無料で公開するようになったようです。話自体は聞いていて知っていたのですが、特に詳しく調べてみました。Scalaを勉強しようと思っていろいろネットを調べていたらO'Reillyの「Programming Scala」が無料で公開されていることを発見しました。感激です。大昔のバーモントカレーのCMが頭に浮かんだのはわたしだけではないはずでしょう。

　Programming Scala

　「取りあえず積ん読」派の自分としては、独学で勉強すると決めてからすぐにAmazonで「Scalaプログラミング入門」という本を買ったんですが、先に知っていれば……。

　さて、オンライン版の「Programming Scala」ですが、当然、英語版です。無料でこんな素晴らしいリソースがあるのに、英語というだけで気後れしている人も多いのではないかと思います。

○読書会やろうぜ

　ここでひらめきました。

　「『アプパタ』ではコミュニティがなければ自分で作れって書いてあったし、東京でProgramming Scalaの読書会をやろう」

　われながら、いいアイデアのように思えてきました。とはいえ、IT業界に（限りませんが）友達が少ないので、取りあえず1人で勝手に始めて興味がある人がいたら参加してもらう、という形を取ることにしました。

　だからといって、1人で貸し会議室とか借りて読書会をやっても危ない人に思われる可能性がありますし、そもそもお金がもったいないです。

　そこでまた少し考えて、Ustreamでやろうと思いつきました。以前どっかの勉強会がオンライン配信してたのですが、それが面白かったのを思い出しましたので。いいところは何でも取り入れるのが日本人のいいところだと思いますし、わたしのポリシーでもあります。

　内容は以下の通りです。

　「Programming Scala英語版を読んで、Scalaを勉強しつつ、文中の英語の解説をする」

■試行 → 本稼働……やろうぜ

　わたしはあまりコミュニケーション能力は高くないのですが、（自分1人でできることに関して）行動力だけはある方なので、Ustream配信の練習も兼ねて早速第1回を実行してみました。

　デスクトップ配信のセットアップ自体に結構戸惑ったのですが、1～2時間格闘した後に何とか配信開始。

　で、結果ですが……誰も見てくれません。まぁ、そうですよね。皆さん忙しいでしょうし、30代のおっさんが英語のテキストをボソボソ読みながらたまに日本語でブツブツいったりしてるだけですし。

　でも、「ちゃんと配信できてるよー」とチェックしてくれた人たちもいらっしゃって、大昔のバーモントカレーのCMが頭に……。しつこいですね。チェックしてくださった方、どうもありがとうございました。

　さて、第1回は完全な失敗でしたが、ここでめげていても仕方ないので、第2回を実行予定です。今度は事前準備（＆事前周知！） をしっかりやって、資料とかも用意しようと思います。

　今後の流れとしてはこんな感じにしようと思います。

• 事前にテキストを読む（いまのところ、自分1人だけ）
• 資料作成してネットで公開（いまのところ、自分1人だけ……）
• 読書会＝Ustreamで発表（いまのところ、自分1人だけ……）
• 読書会の内容をまとめてコラムにする（今のところ(ry）

　誰か時間のある・興味のある人、参加者絶賛大募集中です。Twitterで@kaigaiengineerまで声かけてください。告知とかもTwitterでつぶやきます。Ustreamはこちらです。

　あるいは、すでに東京近郊でひっそりScala勉強会とかしてる人達がいたら、参加させてください。雑用は何でもやりますので。ぞうきんがけも、打ち上げのための居酒屋の予約も得意です。

　なお、日本語でのScalaの情報として、＠ITのライバルサイト（？）であるITproに素晴らしい連載記事がありますので、なるべく内容がかぶらないようにしたいと思います。

　長くなってきましたので、今回はこの辺で終わろうと思います。次回は1人読書会の報告ができればいいなと思ってます。i18nシリーズの続きは気が向いたら書きます……

　それでは、また。