僕がいまもらっている給与もかなり低く抑えられており、ここシンガポールの日本より高い（東京都心と同じレベルぐらい？）家賃と組み合わせて、毎月の貯金がほとんどできないような感じだ。

　そんな風にコストを少しでも多く抑えることが、そのまま企業としての生存にかかわるような環境で、経営者、もしくは経営に関与するレベルでかつあまり開発のことを知らないプロマネが考えることは、そう、開発を賃金の安い周りの東南アジアの国に委託すること。つまりオフショア開発になる。

　彼らが簡単にそう考えるのは、複雑に絡みあう多数のサブシステムから構成されるシステムの開発を、例えば、積み木を積み上げていくようなイメージで達成できると思っているからだろう。もちろん、SOAなどという複数のサブシステムを組み合わせて、システムを創り上げていくソフトウェアの開発のフレームワークが世の中にある。それをうまく利用すれば彼らが思うイメージに近いことが実現できるかもしれない。しかし、それにはSOAを使いこなせる高度な技術を持った技術者が必要なことを忘れてはならない。僕自身それを習得すれば、もっと高い給与を払ってくれる、例えば欧米系の会社に移れるかもしれないと努力している途上で、とてもSOAのプロと呼べるレベルには達していない。今のところはSOAを実践として経験できる場所として、今の現場を利用しようと思っているが……。　

　さて、僕に課せられた仕事はどんどん増える開発案件。それに当たれるオンサイト開発者は僕以外増やせない。しかし、必要ならバングラデッシュやスリランカ、ベトナムのフリーランスの開発者に開発を依頼できると言われ、渋々、外部の開発者を増やすことになり、気付いたら、知らぬ間に僕を中心にしたASEAN software 開発デリバリーのネットワークができてしまった。

　日本で、オフショア開発はかなり行われる時代になっていると思うが、多分まだウォーターフォールで、ドキュメントでがんじがらめにした形で海外のリソースに開発を依頼する形が主流だと思う。しかも依頼先はちゃんとしたシステム開発会社。また、日本のいわゆるweb企業で、オフショア開発を使っているところは、多分まだそれほどないと思う。そういうところは、開発のスピードが半端でないので、ドキュメントなどを作る隙がなくて、開発者は、要件をプロダクトマネージャから直接口頭で聞いて開発することが、基本になっているだろうから。

　そういうことで、僕みたいな開発をしている日本の現場はそれほどないと思うが、世の中にはそんな開発もあるということを分かってもらうため、これから何回かに分けて、僕の開発について投稿することにする。初回は、オンサイト側のエンジニアに必須の能力について書く。

利用技術のすべてに精通したオンサイト技術者は必須

　（1）まずは、少なくとも1人は、オンサイトに技術者が必要。技術者とここで書いたが、開発に利用する技術のすべてに精通していることが必須。必要とあれば、バグ対策や小さな変更をオンサイトの技術者ができる状態にあることは必須。しかし、既存のシステムに対して変更を入れることは、ある程度の経験を持った技術者なら、それがまったく知らない技術で作られたものであろうと、少し時間はかかるが可能だ。ここで言っているのは、利用する技術を使ったレファレンス実装、それと同時にフレームワークを作れるレベルの技術者ということ。

　普通日本でオフショア開発をするとして、オンサイト側技術者に要求される技術は要件定義、そして基本設計程度まで。詳細設計までが要求されることはない。ところが、アジャイルではどうしても、実装を理解できるオンサイト技術者が必要。その技術は、バグ対策や細かい変更を即断即決で行うためというよりは、プログラムの基本構造つまり、アーキテクチャを決定する必要があるから。そして、その構造を作るときに重視することは、プログラム構造の可視化を強制できる仕組み。

　例えば、オフショアに実装させて、できたものをチェックするとき、実際に動作させてテストするのではなく、出来上がったソースコードを一瞬見た程度で、意図したものと一致しているかを確認できるレベルの可視化が必要。アジャイルの現場で、少なくともコード納品直後のチェックで、実際に動作させて、いちいち細かい条件を作ってテストする隙はない。

　一番簡単な例を挙げると、ユーザー入力のバリデーションチェック。そのチェックを実際にアプリを動作させてテストするのではなく、コードを見て判定する。それを一瞬で行うためには、バリデーションチェックの実装アーキテクチャをあらかじめ指示して置く必要がある。

　ウォーターフォールのオフショアでは、バリデーションチェックのすべてのチェック内容を事細かにドキュメントに記述することになるが、アジャイルではそんなことをやっている隙はないので、開発者の自主性に任せて、バリデーションチェックを入れさせることになる。そのためにも、コードの可視化は重要。

　開発者が10人以上いるような大きなプロジェクトなら、見積もりはプロジェクトマネージャがやるのが普通なので、チームのメンバーの一人としてプロジェクトに参加していたとして、見積もりを要求されることはあまりない。大きなプロジェクトの場合、個々のディベロッパーの能力の差はかなり大きいだろう。それにもかかわらず、プロジェクトマネージャが「独断と偏見」で見積もりを立てて、それが結構正確にできてしまうのは、なぜか？

　これを読んでいる人なら、直感的に理解していると思うが、統計学で「中心極限定理」といわれる法則があるからだ。個々のディベロッパーごとにかける時間のばらつきがあっても、全体でかける時間のばらつきの平均はディベロッパーの平方根に逆比例するという法則だ。つまり、10人のディベロッパーがいるプロジェクトで、見積もりを出したとして、プロジェクト全体としてかかる時間のばらつきは、10の平方根、つまり大体一人一人のディベロッパーがかける時間のばらつきの3分の1ぐらいになる。

　プロジェクトマネージャがマネージャとしてやっていくための能力として重要なものは、何かの開発案件を与えられて、それを実装するための作業量をかなり正確に推定できることだと思う。そして、その能力を使って、プロジェクトマネージャはチーム内の平均的レベルのディベロッパーなら、これくらいの時間で作業を完了できると見積もれる。そして、多様なレベルのディベロッパーで構成されるチームで作業を行うとしても、このように、平均的レベルのディベロッパーを前提として見積もりをたてる方法でも、中心極限定理のおかげで、かなり正確に見積もれるのだ。

　さらに、世の中には、いろいろと見積もりの取り方の方法論がある。プログラムステップ法、ユースケース法、ファンクションポイント法、画面数カウント。僕の考えでは、どれもこれも考え方は同じで、開発する対象をできるだけ小さなサブユニットに分けて、それぞれを別々に「独断と偏見」で見積もり、後はそれを足し合わせるだけ。違うのは、サブユニットに分ける方法だけ。それぞれのサブユニットの個々の見積もりを単独で見ると、かなりの誤差があるだろう。しかし、ここでも、すべてを足し合わせてやると、中心極限定理が効いてくる。結果、かなり正確な見積もりが可能になる。

　ところで、僕が今までに従事した開発プロジェクトで、メンバーが5人以上いるようなものは実はそれほどないし、大体はリーダーとしてのプロジェクトへの参加だった。結果、僕自身が見積もりを立てなくてはならない。小心者の私は大体、過小見積もりしてしまう。小心者なら、マージンを付けて多めに見積もりしそうだと思う人もいるかもしれない。だが、とにかくその場をしのぎたい一心で、僕に見積もりを聞いているボスをハッピーにさせようという感情が働き、過小見積もりしてしまうのだ。

　「その場」と書いていることから分かるように、僕が見積もりを聞かれる現場は、現場での口頭ベースであることが多い。例えば議事録なども取らないようなインフォーマルな現場。そういう現場が僕にそういう反応をさせてしまう。取りあえず、この場でボスをハッピーにさせておけば、後に、多少「その場」でいった期間より、多くの期間がかかると分かったとしても、忘れているだろうと。

　最近気付いたが、このような、その場しのぎのいい加減な僕のやり方で、今まであまり問題になったことがない。これについて、よく考えてみた。今までに僕が開発に関与した現場は、ほとんどがスタートアップの『いけいけどんどん』だったから問題がなかったのだと思う。スタートアップをやろうと思うような人は、超楽天的でなければできない。過去の失敗にくよくよするような性格の人には無理だと思う。

　何かのサービスなり製品を作ろうと考えるとき、そんなもの売れるわけがないとか、作れるわけがないとか、できる前に競合他社にマーケットをもっていかれてしまうとか、そんな悲観的なことは考えない。とにかく、そのサービスや製品は絶対に市場に受け入れられると信じ込める人でなければいけない。そういうボスなので、多少の見積りのずれも気にせず、許してくれるのかなと思う。まー、僕の今までのシステム開発で、時間的には多少後ろにずれることはあったかもしれないが、すべて高品質で、かつフレームワークがしっかりしていてエンハンスしやすく、変更に強いシステムを作ることに最終的には成功してきたので、問題なかったのだろう。

　そのため、採用に関わる法的な側面、特にシンガポールならではの外国人を採用する場合のビザの話や、スタッフを人として見たときの判定の話はできない。しかし、過去に何度か、エンジニアの選考の仕事を経験した結果、僕なりに「確立」している使えるエンジニアを判定する方法を今回もとっているので、今回はそれについて書いてみる。ただし、自分自身が求職していて、同じ方法で自分自身が選考されていると感じたことはあまりないので、世間一般の方法とは違うのかもしれない。

　さて、まずはレジュメに目を通すことから始まる。僕自身が仕事を探したときの経験から分かってはいたが、実際に聞いて驚いた。私が今勤めている誰も名を知らない中小企業が、安っぽい募集広告をだして、それにレジュメを送って来る応募者が100人近くもいるということだ。レジュメは東南アジア全域から送られてくる。とても応募者全員と面接をするようなことはできず、書類選考を行う。

　レジュメを見るポイントだが、まず学歴。シンガポールの大学は別にして、それ以外の東南アジアの国の大学の場合、マスター卒であろうと、成績がどうであろうとそれは無視する。また、レジュメの職歴に書かれている、Javaの経験や.NETなどの技術の経験、金融関係とか医療関係などのドメインの経験は一応見るが、あまりそれに引きずられないように努力する。見るのは、1つ1つのプロジェクトの期間と、そのプロジェクトで応募者が果たした役割だ。

　ただし、役割として書かれている内容は自己申告なので、基本的に信じることができない。そのため、それを基に面接することを決めた場合は、面接で嘘を見破る努力をしなければならない。また、僕は、エンジニアが1人前に育つには長期のプロジェクトを一度は経験する必要があると思っているので、2年以上の長期のプロジェクトの経験がない候補者は落とす。つまり経験年数が長くとも、短いプロジェクトばかりの候補者は落とすことになる。

　さて、面接だが、レジュメの選考の基準でも書いたように、Javaの何かのフレームワークを知っているとか、デザインパターンを知っているとか、そういう知識の有無も少しは聞くが、これも、あまりその結果に引きずられないように努力する。基本的に、確認することは以下の3つだ。

(1) 未知の分野のエキスパートの説明を短期間で理解できるか？

　私の開発現場は基本的にアジャイルなので、開発要件は開発対象の分野での、その道のプロに直接聞いて把握していくことが必要になる。僕の経験だが、この能力はやはり、普通にいう「頭の良さ」、とかなり相関が高い気がする。学生時代の成績が良かった人。しかも、それほど努力せずに良い成績をとれた人。学生時代に先生の説明を1回聞くだけですんなりと理解できた人。そういう人が、文句なしだといえる。

　しかし、それに加えて、自分が理解できていないことが分かる人。そして、その理解できていないことを、要領よく言葉にして質問できる人。この辺りの能力は、多分、経験で身に付けられるものだと思う。

　話を聞きながら、自分の頭の中に論理のネットワークを作り、そのネットワークの中の矛盾に気付き、その矛盾の原因となる勘違いを突き止められる能力だ。多分、僕自身は後者のタイプのエンジニアだと思う。僕自身は、人の話を一度聞いただけで、なかなかすんなりと理解できない。質問を数多くして、理解するタイプだ。

　さて、短い面接でこの能力を測るのだが、方法は簡単だ。難しい要件を面接の会議室の白板を使って、僕自身が複雑な内容を実際に説明し、その後、それをどこまで理解しているかをチェックするためのテストを課す。

　今回、具体的に行っているのは、僕自身が昔日本の給与計算システムのアプリを開発したことがあるエキスパートなので、僕が日本の給与計算、一番分かりにくいのが社会保険料の算出の部分だが、その仕組みを説明している。理解していることを確認した後は、ERダイアグラムを書いてもらい、同時に設計能力の有無も確認している。シンガポールのエンジニアで日本の給与計算についての知識を持っている人は、まず皆無なので、公平に能力を確認できる。

　この方法だが、実際のアジャイルの現場で要件を聞く相手は、通常はITエンジニアではない。つまり、システム化するしないにかかわらず、自分が現在やっている業務を、システム化など一切考えずに説明してくるのが普通だ。しかし、私が説明するときはどうしてもシステム化を頭に思い浮かべながらの説明になるため、上のやり方は、厳密な意味のアジャイルでの要件把握のプロセスとは少しずれる。しかし、本当の能力との相関がかなり高い能力確認法だと思う。

(2) 未知のプラットフォームを使った開発を命じられて、短期間にそのプラットフォームの技術を習得して、開発できるか否か？

　レジュメを見て、応募者が経験したことのないプラットフォームを見付け、「そのプラットフォームを使った開発をやることになった。さてどうする？」を問う。僕にとって納得の行く回答が出てくれば合格だ。大抵の候補者は「Googleを使って検索して調べながら開発を行う」と回答してくる。スタッフレベルの開発者なら、そうやって技術を習得したとししても、及第点だ。

　しかし、「本を図書館で借りて週末や通勤時に読んで、未知のプラットフォームの知識を効率よく得ながら開発する」と回答する候補者なら、100点満点だ。120点の回答は、「レジュメには書いてないが、趣味でその技術を使った開発をやったことがあるので、問題ない」だが、そういう応募者には、まだ会ったことはない。また、「過去のプロジェクトで、同じ目にあったことがあり、このときはこう対処した」と、具体的な話ができても、最高だ。

（3） レジュメにうそがないか？

　プロジェクトの中の1つ2つをピックアップして、プロジェクトの役割に応じた苦労話などの具体的なエピソードを聞く。技術面や、開発対象のドメインについて聞くのもよいが、この場合付け焼き刃の理論武装をしていることもあるので難しい。また、プロジェクトが終わった後、2年も3年もたてば、細かい技術などは、忘れてしまっていることが普通だが、具体的なエピソードは簡単には忘れないので、このやり方が良い。

　実は、今回私がついたプロジェクトがまさにその種のプロジェクトで、今回の体験を忘れないうちに何かを書こうと思ったことが今回のコラムを書くモチベーションだ。ブラウンフィールドという言葉だが、Wikiのここを見ていただくと分かるが、英語のBrown Fieldのカタカナで、 本来は使われなくなった工業地帯や商業地を再開発するときに使い言葉らしい。実は、Manninigの書籍に、Brownfield Application Development  in .NETというものがあり、ソフトウェアの開発でも、Brownfieldという言葉を使うことを知り、タイトルに使った。

　Manningのこの本は実は、私は読んでいない。しかし、ブラウンフィールドのソフト開発。その開発を行う方法に決まった方法などはないだろう。担当したプロジェクトごとに、現場に合わせた方法を工夫して行うことがプロのソフト開発者の取るべき道だと思う。そういう考えもあり、この本はあまり読む意味がないかと思う。

　しかし、読んでいない一番大きな理由は、あまり売れている本ではないらしく、世界一IT系の書籍が充実している、ここシンガポールの図書館にもなく、こちらのIT系の書店に行っても見つからず、手に入れるにはアマゾンを使うしか方法がないことが分かったこともある。内容を予想できない本は、立ち読みをして、ある程度中身を見た後でないと買う気がしない。

　さて、現在立ち向かっているブラウンフィールドのアプリ開発だが、どんな状態か差し支えのない範囲で書く。（0）今のアプリを作った開発者はすでに会社を去っている。（1）ドキュメントは、ほぼゼロ。（2）実装はJava。（3）コメントはかなり少なく、かつ英語でも日本語でもない。（4）実装の骨格はかなり立派。数多くのクラスがあるが、Single Responsibility Principleを真面目に実現している。クラス間の関係も継承やコンポジションを的確に使い、かなりすっきりしている。

　また、外部インターフェイス層、ビジネス層、データベース層と、きれいな階層構造も実現している。（5）後になって見つけたのだが、このアプリはマルチスレッドのアプリだが、その実装はとあるO’Raillyの『Java Threads』にあるサンプルコードをベースに作ったもので、かなり立派。 （6）問題は、そのように基本的骨格は立派だが、細かい実装がかなりひどい。

　例えば、階層間のデータのやりとりは、Value objectではなく、プロパティ名をキーにしたHashを使っている。Global変数を多用し、変数の変更の捕捉がかなり難しい。コードのDuplicateもひどい。（7）Javaには数多くのオープンソースのコンポーネントがあるが、それらをほとんど使わず、すべてを自分で実装している。（8）現在のスタッフにアプリの仕様を細かく理解している人は誰もいない。

　推定するに、こういう構造のアプリは多分、リーダーは優秀だったが、スタッフレベルのプログラマはそれほど優秀でなく、リーダーがスタッフをうまく指導できなかった場合生まれるのだろう。さて、私に課せられたタスクは、大規模なエンハンスとともに、将来の発展に備えてプログラム構造を改善すること。上で書いた（0）から（8）について私なりの対処法を書いていく。

　（0）（1）（4）ドキュメントはソースコードを見て最低限のものを自分で書くしかない。まず書いたのは（4）の話と絡むが、静的クラス関連図。クラス間の継承やコンポジションを一枚の図面にした。このとき、一番重要なことはクラス間の関係と、interfaceやabstractなメソッド、そしてコンポジションなど、なので、その辺りだけを記述することにして、それぞれのクラスに数あるメソッド類の記述は省略した。

　必要なときには、ソースを見ればすぐに分かる。必要なものはアプリケーションの全体像を見渡せる図面だ。アプリの動きはクラス間の複雑なシーケンス処理で達成されるものなので、シーケンスダイアグラムを書く誘惑にかられたが、それは工数の関係で断念した。もう1つ必要なドキュメントはデータベースのエンティティ関連図。これも、一番重要なことはテーブル間の関連なので、primary key（pk）やforeign key（fk）をヒントに、テーブル間の関連を記述する図面を作った。そこに記述するコラムはpkやfkと、その他は重要なものだけにした。

　（2）Javaはカプセル化という強力な仕組みを持つobject指向言語で、この種の改造がやりやすい。

　（3）僕自身コメント不要論者、つまりコメントでコードを解説するよりは、変数名、関数名、そしてプログラムの構造でプログラムを分かりやすくするべきだと思っているので、コメントが少ないことは問題ではない。特に、今回のアプリはプログラムの構造自体はしっかりしているので、それぞれの場所でのコードの意図はかなり正確に推定できるので、コメントはあまり必要ではなかった。英語でも日本語でもない、少しだけあるコメントだが、それは必要するところはGoogleのtranslateを使って英語に翻訳していった。

　（5）後から、コードをメンテナンスする側にとって、有名な書籍のサンプルコードをベースにプログラム開発を行うやり方は、実にありがたい。願わくは、例えば、書籍名とチャプター名をソースのコメントのどこかに入れておいてもらえれば、今回のようにたまたま見つけるという『運』に頼る必要もなくなる。

　（6）階層間のやりとりに、Value objectでなくHashを使う方法はJavaのプロパティの実装があまりに長くなり過ぎるので、採用されたものと推定する。私はこれを、プロパティの実装が楽になるLombokを使って、HashをValue objectに変えていった。Global変数多用の問題は、今のところ対策がない。現在稼働しているシステムだけに、デグラのリスクの高い変更は仲々できない。自動テストコードをある程度準備してから、おもむろに手をつけるという作業になるのかと思う。

　（7）自分で実装している部分はオープンソースのコンポーネント利用にどんどん変えていった。例えば、Logはslf4j経由のLog4jに変えた。また、ConfigurationはSpring利用に。 DB層は、JDBCを使った実装だが、これもHibernateに変えたいが、これはあまりにリスクが高過ぎて無理かもししれない。

　（8）最大の問題は、アプリの細かい仕様を理解している人がいないこと。実は、このアプリとインターフェイスする、あるハードウェアの開発を外部の業者に依頼しなければならないが、そのために渡す必要があるインターフェイス仕様を書くには、コードを見てリバースエンジニアしていくしか方法がなかった。

　ソフト開発のだいご味はもちろんスクラッチ＆ビルドだが、例えば自分にとって未知のプラットフォーム使って始めて作るような場合、仲々それは難しい。そういうとき、このように、基本構造は立派なアプリを改造するような仕事は、未知のプラットフォームの実装を学びながら、仕事をできるわけで、自分の仕事の範囲を広げられるいいチャンスだ。ただし、一部のITエンジニア、大手のシステムインテグレータに長年努めているような人はドキュメントベースの仕事に慣れているだけに、多少つらいかもしれない。

　Javaを使い始めた直後は、新しい開発環境に入るときにつきもののイライラ感があった。何かをやろうとするが、その具体的な実装方法がすぐに思いつかず、Googleを使って調べると確かに実装例が見つかるが、そうやって見付けた方法が本当に最適なのか、今いち自信の持てない状態にあった。しかし、本を数冊を読み終えて、本の中の何処に何が書いてあるのかが把握した状態になり、読んだ本から具体的な方法を素早く見付けられるようになり、さらに、Googleの検索で見付けた方法でも、それを自分なりに評価できるようになってきて、ようやく新しい言語になれつつある自分を感じる。

　さらに、前回書いた私の『不平不満』に対して、いろいろとアドバイスしていただける方がいて、そのアドバイスを取り込んで、私のコーディングの能率も徐々に挙がってきている状況だ。ということで、素人Javaプログラマが約1.5月を経た後、自分なりに得た意見を書いてみる。まず、前回書いた、不平不満それぞれについて。

1．クラスのプロパティーのコードが、Javaでは長くなってしまう。

　Lombokを使えば、ほぼC#でのプロパティの実装と同じレベルの簡潔さなるようだ。Lombokについては、これを読んで一発で概要を理解できた。

2. Javaにはプリミティブ型を表すクラスが、プリミティブ型そのものと、そのプリミティブ型をラップするクラスの2種類あって、それを使い分けなくてはならない。

　auto boxingがJava5以降サポートされたようで、そういう歴史を知らない私はauto boxingは当たり前と思っていた。しかし、それにもかかわらず、両者を使い分けしなくてはならないのは苦痛だと思った。私が苦痛だと思ったのはGenerics collectionで、例えばintそのもの、つまりPrimitiveTypeを格納できないことを知ったときだ。

　なぜそんな制限があるのかよく分からない。C#では、primitiveタイプを堂々とGenericsに格納できる。boxingやunboxingなど不要。というか、genericsを使うメリットの1つがcollection内にprimitiveタイプを格納して、読みだすときもキャストする必要もなく使えることだと思っている。genericsでないcollectionはobjectタイプしか格納できず、そこにprimitive タイプを格納すると、書き込みや読み出しのときにcastが必要で、(auto)boxingやunboxingが発生してしまうからだ。primitiveタイプをgenericsに格納できないJavaでは、genericsのメリットを半分しか生かしていないことになるのではないだろうか。

3.  Javaでchecked exceptionを投げる可能性のあるメソッドを使う場合、そのExceptionをメソッドの定義の「throws」節で、宣言しなければならない。そして、throws節が宣言されているメソッドをコールする側は必ずそのExceptionをcatchしなければならない。

　いただいたコメントで、checked exceptionとunchecked exceptionの使い分け方がよく分かった。つまり、自分で投げるexceptionはよほどのことでない限りunchecked exceptionにする。それもruntime exceptionにするのが良い。checked exceptionを投げるメソッド、例えばもともとのJavaのクラス体系が持つメソッドを使うなどのときはexceptionをそのメソッドを呼び出したメソッド内でcatchし、それに説明を付けてunchecked exceptionでラップして再投入する。Exceptionが発生した原因を一番把握できるのはそのメソッドを使った直近なので、明確な説明を記述しやすい。結果的に、自分で定義するメソッドでは『throws』節はほとんど使わなくなる。コールスタックの一番上で、すべてのExceptionをまとめて処理するプログラム構造を容易に作れる。

4. Javaには.NETのdelegateやラムダ式など、関数を変数として扱える仕組みがない。

　条件によって使うメソッドを切り替えるためには、工数がかかるが、state patternを使うなどして、同等のことを実現できる。また、もちろんReflectionを使えば可能だが、これは多分性能的に問題があるのかと思う。非同期処理を容易に実装するために使うdelegateだが、これにはclosureのサポートが必要だが、そのサポートはかなり前から議論されているようだが、最新のJava7でもまだサポートされていない。

　JavaがSUNからOracleに移るようなごたごたがあったおかげで、言語の進化が止まってしまったかと勘繰りたくなる。AndoroidはJavaを使っているので、GoogleがJavaの進化を進めてくれればよいのにと思ったりもする。とにかく、この辺りの話の解決策は、同じJVM上で使えるScalaを使うしか今は解決策はないらしい。

　問題は、ScalaがかなりJavaと異なる言語になってしまっていること。これはかなり敷居が高い。今回、本を購入してScalaを読み始めたが、最初の1、2章を読んだだけで、他にもっと勉強しなければならないことが持ちあがり、止まってしまった。Scalaを使うプロジェクトにでも当たらない限り、これを勉強するモティベーションが挙がってこないかもしれない。

　ところが、ClosureとJavaをキーワードにして検索して分かってきたが、どうやら来年末ぐらいにGAになる予定のJava8でClosureやramda expressionがサポートされるらしい。後一年も先かと思うと、遅すぎ感があるが、少なくともサポート予定があるということで、Javaを勉強する意味はあるようだ。

5. Javaに.NETのLINQに相当するものがない。

　これも多分、Scalaしか解決法がないのかと思う。

　いろいろ勉強した結果分かってきたことを、結論からいえば、Javaでも.NETと同程度の能率の実装を達成することはできそうだが、それには、優秀で経験豊富な上級Javaプログラマが、持っている知識、能力を駆使して、初心者プログラマでも、楽に高能率で実装できる環境を準備してあげる必要にあるのかと思う。具体的には、開発環境であり、各種Frame workであり、Reference実装だ。もちろん、.NETの環境でも、そのような準備は必要だがJavaで準備しなかればならない環境と比較すると.NETではずっと楽にそれを準備できる。

　ということで、大きな受託開発業者、つまり、多くのJavaを使ったプロジェクトが同時に走っていて、少数の高い給与の上級プログラマを複数のプロジェクトの作業にあたらせやすい会社では、Javaでの実装は有利に働くのかと思う。.優秀なプログラマの側も、その能力の違いを差別化しやすくて、高い給与を要求しやすくなる。

　.NETには、上級プログラマはいるが、必要とされるフレームワークなどは比較的小さくて済むので、能力の差別化をしにくい面がある。上級プログラマのの需要も小さい傾向があるのかもしれない。

　そんなところで、Javaがいろいろと欠点はあるが、今もシステム開発の主流である原因かと思った。僕のパーソナルなページに書いたが、シンガポールでのプログラマの報酬はそれほど高くない。インドやフィリピンなどから優秀なプログラマが簡単に参入できるため、報酬が低く抑えられがちなためだ。そんな中で、高い報酬を得るためには、自分の希少価値を高める必要がある。

　私の場合、もちろん日本語を使え、かつ日本の会社文化を知っているということは、日系企業内では大きな希少価値だが、最近はその価値は高くなくなってきている。最近の傾向として、海外に進出する日系企業も現地に出る限り徹底して現地化する傾向が広まっているからだろう。私に残された方法は技術だけだ。ところが、.NETでは、その高い技術を生かす場所は多くない。しかし、Javaなら、結構多くあるようだ。今回の機会ををうまく使って、高いレベルのJavaプログラマになれるように努力していこうと思う。

　BASICを使って、私も、学生のころ、当時日本で売られていたSharpの『マイコン』で、色々とゲームを作った。ASICだと言ってもバカにしてはいけない、学生時代はゲームだったが、それなりに物理や数学を駆使したアプリだった。社会人になってからは、事務所で使っていたIBM PCに乗っていたBASICを駆使して、本業の合間に仕事で使うシステムを色々と、EUC（End User Computing）の一環で作った。

　その後は、DBaseIIIなるものを使って、Relational Databaseの構造が必要な結構複雑なアプリを作ったり、性能を要求されアプリをCで作ったり。かなり大きなデスクトップのWindowsのアプリをC++で作ったりした。そこら辺りまでが、僕のアマチュアプログラマとしての実績だ。

　私の定義でのプロのプログラマとは、しっかりと給料をもらえる仕事のなかでフルタイムでプログラムの作業をする人のことだ。プロになった直後、Javaを使った開発を約1年行うことになった。それは、デスクトップのアプリでSwingを使ったものだった。

　約1年Javaを経験した後は、Microsoft陣営に入り、最初は、いわゆるclassic ASP。Microsoftが.NETをリリースした後は、.NET一本で約10年、ここまで来た。その間のプロのソフト開発の仕事で、Javaを使ったことは最初の1年を以外はない（*1）。ところが、今回Javaを使って開発することになり、今いろいろと勉強している。

　ところで、私が『.NET』や『Java』とここで書くときは、言語のことを言っていない。そこら辺りは、.NETを、C#とかVB.NETとかいう言語で代表していないことからも、悟ってほしいが、両者を開発のプラットフォームなどを代表する単語として使っている。つまり、.NETと書けば、それがVisual Studioを使って開発し、VSSでソース管理する。

　WebアプリはIISの上にASP.NETやASP.NET MVC。リッチなクライアントアプリはSilverlightやjQuery。デスクトップアプリはWPF。そして、エンタープライズアプリは、WCFやWFなど。ORMにはLINQ to SQLやNHibernate、そしてADO.NET entity framework。そして、非同期通信にはMSMQなど使う開発環境のことを指す。

　Javaの陣営は、実はまだあまり把握していないが、開発環境はEclipseやNetBeans。ソース管理はSVN。そしてWeb アプリはApacheのTomcatの上にJSPやサーブレットそしてStruts, Java Server Faces。そしてエンタープライズアプリは、Java EE（旧J2EE）。最近は、このJava　EEはPOJOの思想のものに置き換わっているらしく、今はSpringや、iBATIS、 そしてHibernateを使うらしい。

　異論のある人も多いかもしれないが、現代のWebシステムの2大プラットフォームは、この.NETとJavaだと思う。他に、Ruby on RailsやPython、そしてPHPなどもあるが、言語の周りを囲むフレームワークの充実度を考えると、やはり.NETかJavaが2大プラットフォームだろう。そして、それは、技術を習得するためには充実したフレームワークの習得に時間がかかるということをも意味する。

　誤解しないでもらいたいが、チームの中の1メンバーとしてソフト開発を行う場合、開発環境の違いなど、あまり大きな障壁ではなり、優秀なチームリーダーが、新しく入ったメンバーを多分1日で戦力にしてくれる。そして、それが出来ないチームリーダーはリーダー失格だ。

　新しいプラットフォームに移行するときに苦労するのは、自分がチームリーダーのときだけだと思って良いと思う。そこら辺り、日本、そして世界の開発現場で開発者を選考するとき、どこまで理解しているのか、ちょっと疑問だったりする。面接で聞かれるのは、「Javaの経験は何年？」とか、どうでもいいことを聞かれることが多い。確かに一番聞きやすいことなので、面接で聞きたくなることは分かるが。

　ここからは、.NETのプロの私が、今回Javaを再習得して、記憶が新しい間にJavaについて思ったことを少し書いてみる。書いてみて思ったが、書けることは、Javaに対する不平、不満でしかない。

1. クラスのプロパティーのコードが、Javaでは長くなってしまう。例えば、C#では、

public int Count {get; set;}

と書けるところが、Javaでは、

private int _Count; 

public setCount(int c) 

{   

_Count = c ;

}

public int getCount()

{

return _Count;

}

と、なってしまう。IDEが持つコード自動生成の機能を使うと、上記のJavaのコードなど、1発で書けるが、私はコード自体の長さを問題にしている。

2. Javaにはプリミティブ型を表すクラスが、プリミティブ型そのものと、そのプリミティブ型をラップするクラスの2種類あって、それを使い分けなくてはならない。

3.  Javaにはchecked exceptionとunchecked exceptionの2種類のExceptionがあるが、checked exceptionを投げる可能性のあるメソッドを使う場合、そのExceptionをメソッドの定義の「throws」節で、宣言しなければならない。そして、throws節が宣言されているメソッドをコールする側が、かならずそのExceptionをcatchしなければならない。

　.NETでは、Exceptionをcatchする場所は、それを投げたメソッドの外側のコールスタックでありさえすれば、どの層のコールスタックでもよい。例えばWebアプリ、ページの処理が1回1回、別のThreadで処理されるような単純出来るWebアプリでは、メソッド呼び出しスタックの1番外側で全てのExceptionをcatchするのが普通だ。ほとんどのケースでExceptionは、それを投げたメソッドを呼び出した直近で処理できることはないので、.NETのやり方が、もっとも理にかなっていると思う。

　しかし、Javaではunchecked exceptionでしかその方法が使えない。 結果、前任者のコードを見ると、catch blockの中が空っぽになっている、つまり、エラーを無視する最悪のコードが散見される結果になっている。Javaを最初に作った人は、自分たちの生真面目さが、全世界のプログラマも同じく通用すると思っていたのだろう。開発言語は、生真面目でない開発者でもしっかりと、ちゃんとしたコードが書けるようなものでないと行けないと思う。

4. Javaには.NETのdelegateやラムダ式など、関数を変数として扱える仕組みがない。Javaのコードを見ていると、とにかくswitch文が多いような気がする。与えられた変数によって、行う処理を切り替えるような処理はswitch文で書くしかないためだ。

　.NETではdelegate、そして、それをより簡易に書けるラムダ式などを使えるので、コードがよりすっきりしたものになる。delagateのもっとも強力な使い方は、関数そのものを、別の関数への引数として渡すというものだが、これは例えば、非同期の処理を扱うときなどのコードが、非常に簡単なものになる。Javaで同じことができない。

5. Javaに.NETのLINQに相当するものがない。これもJavaにないので、フラストレーションを溜める原因になる。例えば、C#でLINQを徹底的に使うと、例えばLoopを全くゼロにできるが、同じことをするコードをJavaで書くと、プログラムがLoopばかりになっていることになり、嘆くことが多い。

　今のところ、僕にとって、Javaの悪い点しか気付かない。もしかしたら、そのうち良い点も見つけるのかもしれない。しかし、それを考えても、私は日本、そしてシンガポールのシステム開発の主流がいまだにJavaにある理由がよく分からない。.NETを使うと、はるかに楽にコードは書けると思う。

*1 :  実装担当としてJavaを使ったことがないという意味で、PMやビジネスアナリストとして参加したプロジェクトで使ったアプリがJavaだったことはある。

　最初、面接を受けたのは小さな受託開発のシンガポールの現地企業。.NETの案件があって、そのプロジェクトのリーダーをできる人を探していた。最も得意な.NETで開発ができる。

　こういう小さな受託開発の場合、社内の開発で使う基盤、つまり、フレームワーク的なものは、あったしてもドキュメントが不備だったり、使いものにならないなどが多い。多分、僕が作ることになるだろうと思い、実はそういうことを私はやりたかったので、願ってもない話だった。ということで、オファーを受けようとしていた。

　そんなとき、もう1つの面接への案内の電話が入った。よく聞くと、そこは医療関係のコンサルテーションをする多国籍企業。米国、シンガポール、ヨーロッパ、そしての日本に拠点はあるが、それぞれの拠点はかなり小さかった。しかし、何より、期待を持てたたのは、面接を受けるとされる人の名前がシンガポール人の名前でなく、アメリカ人。しかも、タイトルは『DR.』。ドクターというタイトルを使える人は医者か研究者のPHD. 。もしかしたら、医療関係の研究のためのシステム開発かもしれないと思い、喜び勇んで、面接に向かった。

　面接の場所は、シンガポールのオーチャード・ストリートにあった。しかも、シンガポール唯一の超大型書店として確立している紀伊国屋書店があるビルの中だった。実際、訪れて分かったが、場所は確かに良いが、オフィスはかなり狭い。顧客受けする住所を得るために、高い家賃、つまり住所代を払い、そのしわ寄せで狭いオフィスにするしかなかったという事情を推定した。しかし、研究のための開発の仕事の可能性の魅力はは捨てがたい。

　面接官は、アメリカ人のドクターで医者ではなくPHDとのこと。面接で説明されたが、私の上司になる人は、中国人のPHDで、仕事は医療関係の委託研究のためのプログラマ職。その中国人のPHDのもと、彼女の指示に従ってプログラムするらしい。そして、私に白羽の矢がたった理由も明かされた。

　ある米国の企業が日本市場でeコマースをするに際して、日本でのシステム開発を含めたコンサルテーションを請け負っており、その際のコーディネート的な業務を、仕事の一部としてやってほしいとのこと。シンガポールにて、日本で行われるシステム開発のコーディネート。なんだ？ といぶかしんだが、『多分、語学的なサポートだろう。それなら、実は私はソフト開発の仕事にキャリアチェンジする前に散々やっていた種類の仕事なので、なんとかなるだろう』と、あまり深く問題視しなかった。

　ということで、面接の場で、『オファーをもらえるなら、そのオファーを受ける』と宣言。しかし、すでに1つもらっているオファーを受けるか否かを回答する期限が迫っているので、3日以内でオファーを出すかどうかを決めてほしいと依頼。日本ではちょっと考えられないが、シンガポールではそれほど無理な話ではない。1つオファーを受けていると、強気になれる。

　次の面接は、同じ日午後に日本からの電話だった。日本人のマーケッティグ部長と称する人から、先のイーコマースの案件の内容を少し説明を受けた。これは面接というよりは、事情を説明された程度だ。

　次の日、大学への通学途中。私の上司になると言う人から電話があった。NUS（National Univ. of Singapore）の図書館で面接をできないかという。NUSはシンガポールの名門大学で、世界の大学ランキングでは、東大と争っているところだ。先に書いた委託研究とは、NUSの教授からの委託研究で、そのために、私の上司になる女性は普段はNUSにいるらしい。しかし、私はNTUの学生で、NUSに行ったこともないので、地理が分からず、結局大学近くの駅の近くの喫茶店での面接となった。

　向かった喫茶店で待っていたのは、若い女性だった。多分20代ぐらいだろう。しかし、若くても何でも、PHDのすごさは、この1年NTUでPHD候補の学生と机を並べて勉強して、よく分かっている。彼らの努力、そして能力は私なんかとは比べものにならない。若くても何でも、僕の上司になるかもしれない人との面接を真摯に受けた。

　面接は、ITの素人がITを付け焼刃で勉強し面接していることが、よく分かる内容だった。ITの基本的な言葉、例えばデザインパターンについて聞いてみたり、アジャイルについて聞いてみたりだった。こういう面接なら、多分、大学を出たばかりの人の方が高得点を得るだろうなと思いながらも、面接はいい雰囲気で終了した。これですべての面接は終了で、後は結果を待つばかりとなった。

　さて、この時、3社目の企業の面接も同時進行で進んでいた。そこは、受託開発ではなく、シンガポールの地元企業で、金融関係のサービスを顧客に提供している小さなスタートアップ。僕が、6年前にシンガポールに来て最初に勤めた場所の近くにオフィスがあった。シンガポールのの東海岸に位置するところで、6年前から、地下鉄、つまりMRTの工事が行われていたが、2年ぐらい前に工事が完了、開通しており一段と便利になった地域である。

　今回、6年ぶりに来て驚いた。当時なかったオフィスビルが新しく林立して、欧米人を含むオフィスワーカーで賑わっていた。この6年で、シンガポールの1人あたりのGDPは日本の3分の2（約2万ドル）から、今では日本をとっくに追い越して5万ドルぐらい。そこらあたりの発展の具体的な現れが、こういう場所にあるのかと思いながら、面接のためにオフィスに向かった。

　オフィスはスタートアップらしく、小さなところで、通された会議室も小さかった。普通に面接。面接は、気さくなシンガポール人の社長とITマネージャの面接で、1回で終了。ここでも強気に出て、3日以内に結果を欲しいと依頼した。

　最初にオファーをもらったのは、金融関係のサービスを提供するところだった。オファーを受けた後、オファーを受けるか否かは、翌日を期限にしている医療関係のコンサル企業からの結果を待ってからとするため、返事は翌日まで待って欲しいと依頼した。

　そして、翌日の夜遅くになって、その医療関係のコンサルからのオファーを受けて、それを受けることに決定した。同時に、他の2社のオファーをすべて同時に断り、僕の転職、シンガポール編も、これで終わるはずだった。

　勤務開始は、8月1日からと決めていたので、勤務開始まで1週間程度時間があった。その間に、フィリピンのバギオに行っていた。バギオのホテルでメールをチェックしていて驚いたのが、オファーを取り消したい旨の医療コンサルの会社からのメールだった。予算を取れないことが判明したとのこと。実は、この会社、少し疑惑がなかったといえば嘘になる。オーチャードでの最初の面接は朝の8時半 からだったが、アメリカ人のPHD、オフィスに入る鍵を持っていないことが判明。結局、面接の最初はオフィスでできず、他のスタッフがくる9時になるまでが、近くの喫茶店でやることになった。面接で、開発する場所を聞くと、その狭いオフィスでもう1つ机とPCを準備するのは難しそうなのにもかかわらず、そこで開発するという回答だった。

　とにかく、フィリピンにいた僕は、スカイプを使って電話をかけて、さんざん文句を言った後、帰国後すぐにシンガポール政府の労務働関係の役所、MOM(Ministry Of Man power)に駆け込むと宣言した。以前、書いたが日本の社会保険事務所に新卒の内定取消についてクレームを入れると、やってくれることぐらいのことをMOMでもやってくれると期待して、そう宣言した。

　帰国してすぐ、同時に内定をもらっていたが断っていた2社に事情を説明して、オファーを受けたいが、今でも可能かと打診した。受託開発の.NETは残念ながら他の候補者にすでにオファーを出しておりNGだった。ところが、金融関係のスタートアップは、他の候補者にオファーを出してはいたが、少し条件を落とし、さらに3カ月の短期間の契約社員なら私にもオファーを出せるとのこと。3カ月後、正社員にするかどうかを検討するという条件だ。条件的に厳しいので、それは断ろうかと思ったが、再び仕事を探すモードに入るにも、気が進まず、結局その条件を飲むことにした。

　8月からそこで働いているが、結構面白い。9月2日の現時点で思うが、僕のこの時の判断は結局、悪くなかったと思っている。金融の新しい分野に触れることができたり、あまり慣れていない技術、JavaでSpringを使ったり、Strutsを使ったり、マルチスレッドでソケットを駆使する開発だ。さらに、日本とはまったく関係のないすべて英語の環境で、アジャイルで開発を行っている。良い経験になっていると思う。

　さて、上に書いた、MOMに駆け込む話だが、その顛末を少しだけ書く。MOMには、労使関係のトラブルに対するコンサルテーションを無料で提供する窓口が存在する。Web上に有る、E-appointentで、そのコンサルの予約をネットから入れることができる。僕はこれを利用して、予約を入れた。

　予約システムの作りの問題で、実は、何度いれても予約をいれることができず閉口したが、とにかく翌日のコンサルの予約を入れることができて、翌日、予約した時間にMOMに向かった。そこにあったのは、少々の人が待つベンチと、その前の約5つぐらいの個室だった。コンサルテーションはその個室で行われた。

　私の順番が来て、担当者に事情を説明した。しかし、結局、担当者の話は、MOMでは『なにもできない』とのこと。私のような話は、純粋な商取引の契約不履行に当たる話で、MOMでは取り扱えないらしい。民間の法律事務所の法律家に相談するしかないとのこと。結局、弁護士費用を払ってまでも、こだわる話でもないので、私の抵抗はここで終えることにした。

　結局、落ちも何もない話になってしまったが、『僕の転職　シンガポール編』はこれでいったん終わりにする。

　「送る」という行為だが、最初は前回紹介したようなWebサイトが持っている機能を使って送っていた。つまり、Webサイトで自分のレジメ、就労可能時期、希望給与、生年月日などをいったん登録した後は、見つけた募集広告にある『応募』ボタンをワンクリックするだけで応募できる機能。そう、応募はワンクリックでできてしまう。

　さらに、その種の募集サイトの求職者用のページでは、応募状況のリストなどを表示してくれる。多分、企業用のページには、応募者のリストを表示するページなどが準備されているのだろう。

　もう少し細かいことを書く。この種の求職サイトに広告を出す企業は大きく分けて、2種類に分けられる。転職エージェントか、実際に採用する企業。僕は、最初はその2種類を分け隔てなく応募していた。

　しかし、分かってきたのは、転職エージェントに応募すると、そのエージェントから、ほぼ確実に電話がかかってきて、根掘り葉ほり聞かれた後、実際に募集している企業の具体的な名前を説明され、『その企業のレジメを送るので、もし面接に呼ばれることになったら、連絡する』と行って電話を切られるパターン。このやりとりがすべて電話で行われる。実は、これが私には、かなり負担が大きい。

　電話で企業の詳細を、きついシンガポールなまりのエージェントに説明されても、記憶に残るのは半分ぐらい。最初はこの種の転職エージェントが出す広告にも大量に応募したので、エージェントから大量の電話を受けることになったこともそれに拍車をかける。次から次へと電話を受けるので、最初は、『僕ってこんなに、需要が高いエンジニアなんだ』と誤解してしまった。しかし、その1回目の電話の後は、すべてなしのツブテで、そんなわけがないと気付くわけだ。

　僕も、だんだん、不意うちの電話でのやりとりの結果、『応募』したことになっている企業の名前など、分からなくなってくる。日本の転職エージェントや、こちらの日系のエージェントは、希望を説明して、『それならば、こういう応募があります』と、オフィスでゆっくりと時間をかけて説明してくれるが、こちらのエージェントは明らかに『数打ちゃあたる』式。募集サイトに広告を出して、応募してきた人全員に電話をかけて、多分、ここで、英語が通じるかどうかか、その辺りをチェックしているのだろう。

　少なくとも受け答えができると判断すれば、そのままレジュメを募集企業にフォーワードしているのだろう。その時の電話の話の内容から分かることは、エージェントは私が一生懸命書いたレジュメの中身など一切読んでいないこと。レジュメの書いてある、明々白々なことを、平気で聞いてくることも多い。

　さらに閉口するのは、ネット上の求職サイトの中には、自分がサイトに登録したレジュメを、企業の側もしくは転職エージェントが検索できる機能を持つものがある。日本の転職サイトにもよくある機能、つまり『スカウト』の機能だ。こちらのサイトの問題は、上で書いたような『数打ちゃ当たる』の仕事をする転職エージェントも、それを見られること。結果、その種のサイトに自分のレジメを登録して、『スカウト』許可モードにしてしまうと、次から次へと、転職エージェントからの電話を受けることになる。

　結果につながる確率の低い転職エージェントの電話を受けるのは、シンガポールで仕事を探す初心者には、電話でいろいろと英語で受け答えをする練習になるのでいいかもしれない。私も、実は、最初は卒業研究モードから転職モードに自分の気分を切り替える為に使った。しかし、その後はすべてシャットアウト。つまり、活動の後半では、応募する募集広告は、企業が直接広告を出しているもののみとした。

　そんな風にいろいろとシンガポールでの転職の方法を学習しながら、レジュメを20～30通送った後だろうか、ある募集サイトの求職者用のページの1つに、募集した企業ごとの、その広告にレジメを送っている応募者の数、そして自分の希望給与額が、その応募者の中で、どの位置にいるかが分かるものがあることに気付いた。

　それを見て驚いたのが、自分の位置が、ほとんどの応募先で、ダントツで1番上か、上から2番目ぐらいだということ。実は、最初の希望給与は前の仕事でいただいていた給与より少し落とした程度の6000シンガポールドルで応募していた。この額が、シンガポールのソフト開発のエンジニアの平均よりは、かなり高い給与だということは知っていた。しかし、僕ぐらいの実力のエンジニアなら、そのくらいの希望を出してもいいだろうと思っていたし、他にも同じぐらいの希望を出している人も大勢いるだろうと思っていた。実際見ると、僕の希望額を提示している求職者はほぼ皆無ということ。これはかなりショックだった。

　仕方なく、それより少し落とした額の5000シンガポールドルで、しばらく応募。様子を見るが、それでも、面接をしたいという電話が来ない。

　そこで、考えたのだが、企業で採用業務をしている人事担当者は、募集サイトが準備している企業側用のサイトの応募者検索の機能を使って、客観的データを基に、応募者を絞っているだろう。その絞りこみに使うデータは多分、希望給与、年齢、学歴、経験年数、資格、そのあたりだろう。

　それを考えると、僕のレジュメが、実際に僕のレジュメをじっくり読む立場にある人、つまり実際に採用する部署のボスのところに至る確率はかなり低いのではないか。僕の希望給与5000シンガポールドル、応募者の上から10％程度だろう。50歳と言う年齢 は、ソフト開発エンジニアとしては、シンガポールでは高すぎる。学歴の大学卒は、シンガポールでは最低レベル。

　そんなことを考えて、データの絞り込みをスキップできる道を考えるべきだと思った。よくある方法は、昔の同僚のつてを使うなど。実際そのつてを使った応募も2～3行ったが、数を打てない。何か良い方法はないか？ それは何か？

　なんのことはない、募集サイトには大抵、メールアドレスが書いてあるので、そこに直接レジュメをメールへの添付として送ることだ。多分、そのメールを最初に見るのは人事担当者。

　ざっとレジュメを見て、そこで普通の応募者のルートでないので、捨ててしまう人もいるだろう。しかし、普通の小心な担当者はそうしない。小さな企業なら、自分の見える範囲のところで仕事をしている、開発部署のマネージャに声をかけて、そのメールを転送するだろう。そんな形で届く応募はそんなに数はないのだから、問題ないと考えるのが普通だ。レジメの内容を理解できるレベルの人が、僕のレジュメをみて、『ぜひ採用したい、一緒に働きたい』と思うことには、小生、実はかなり自信がある。かなりの確率でそうなるだろう。

　後は、高い給与、高い年齢、そして日本人と一緒に働いたことないけど、大丈夫だろうかという不安。その辺りをクリアする努力を社内でしてくれれば、面接に至ることになる。

　ということで、私が最終的に始めた応募法は、直接募集記事を出している企業に、直接メール添付でレジメを送ること。案の上、方法を変えてすぐに、3件の面接に来てほしいという旨の電話を受けた。そして、3件の面接すべてで、オファーをいただくことになった。客観的な条件では、少々無理のある僕を、押して、面接に至っているのだから、面接通過率100％。当たり前だ。

　長くなったので、今回はここで終えて、次回の終編に続くことにする。

　しかし、今回、私も一応大学を終えて、仕事を見付けて再びITエンジニアとして働き始められたので、自分のことを書かないのは、申し訳ないので、ここで自分のことを書くことにする。このコラムでは、企業名その他はすべて隠すが、金額は一部公開する。雑誌に書いた記事は、『日本人ITエンジニアよ、こっちの水は甘いぞ』という内容だったので、私の記事を読んで、真剣にシンガポールで仕事を探すことを考えている人もいるかもしれないが、ここに書く内容は、それに水を差すことになるかもしれない。

　シンガポールで仕事を探し始めたのは、大学の後期の試験、つまり最後の試験が終わり、後は論文提出のみとなった時点からで、5月の中旬ぐらいだった。シンガポール人の日本人のためのWeb雑誌として、メジャーなものが2つ、シンガポールお役立ちWeb、AsiaXあり、それらに日本人向け、およびJapanese speaker向けの仕事の募集広告のサイトがある。5月中旬に、そのうちの1つにITエンジニア募集の広告があり、それに応募したのが最初だった。

　このサイトの求人広告のリストを見ると分かるが、広告を出しているのは、ほぼ日系の転職エージェントだけ。つまり、募集広告のどれかに応募するということは、それは自動的にその日系エージェントと仕事を見付ける契約を交わすことになる。とにかく、ある募集広告に募集して、ある日系エージェントを経由してレジメつまり職務経歴書を送った。

　書類選考は通り、Skypeを使った面接となった。その企業、広告業務を、世界に進出している日系企業に提供することを主業務とする会社で、最近シンガポールに進出することを決め、シンガポール勤務のITエンジニアを探していたのだ。しかし、まだシンガポールには人がおらず、東京本社からの面接となった。

　結局不採用になったが、説明された不採用の理由は、“over qualified”。私のような、年寄りエンジニアを断る理由として、日系企業に限らず、よく使われる理由だ。私のレベルのエンジニアに見合う仕事がないということ。確かに、シンガポールで行うと想定される仕事は、東京で開発されているシステムを東南アジアに進出している日系の顧客向けにカスタマイズするような内容で、そのカスタマイズも、それほど難しい作業と思えず、面接でも明らかにover qualified だと感じただけに、これも仕方がないことだろう。

　5、6月の時点では、私は、大学に提出するべき論文のための卒業研究にいそしんでいたので、利用するエージェントは1社に絞り、ゆっくりと仕事を探した。その次に、同じエージェントから紹介されたところが、ある日系大企業のメーカーの東南アジア地域を統括するITマネージャーの仕事だった。

　エージェントから話を聞いた瞬間に、私には難しい仕事だと感じた。多分、求められている人は、日本の大企業、それもメーカーで社内SEを経験したことのあるような人だろう。つまり、私のようなSIとは逆の立場の、開発を発注する側の仕事。ITの知識や、ソフトウェアを開発するためのプロジェクトマネジメントの経験だけでは、難しいだろう。

　しかし、職務経歴書を送ったところ、面接に至り、駄目もとで面接。結局、不採用だった。この種の仕事、普通に考えたら現地採用ではなく、日本からの駐在員が行うのが普通とも思えるだけに、その後、現地採用で人が見つかったのか、それとも、結局見付からず、駐在員で対応することになったのか、興味深い。

　7月になった時点で、私の仕事探しにも火が付き。Web上の募集サイトで見付けた目ぼしい募集に片端からレジメを送り始めた。片端というやり方だが、日本で転職をしたことのある人が聞くと、そんなことをすると、応募したところ、書類選考中のところ、ごっちゃになり、訳が分からなくなるのでは？ と心配になる人もいるだろう。私も、最初は結果が分かってから次の企業に応募する方法を取ろうと思った。

　ところが、それはこの国ではできない。なぜなら、ほとんどの企業は、書類選考の不合格を通知してこないからだ。ここら辺りが、日本の転職と違う。結果をいつまで待てばいいのか分からない応募では、シーケンシャルな応募は不可能だ。そして、いったん、前の応募の結果を待たずに、次の応募を送るようになると、それは、だんだんエスカレートして、最後には『片端』になってしまう。

　さらに、日本の転職広告Webサイトを見ると、動画を載せ、写真を載せ、社長の文章を載せ、そこで働く社員の文章を載せと、社内の様子が分かるように凝った広告が多い。ところが、こちらの広告は、基本的にスペックだけ。どういう職種の募集で、給与が『これこれ』と、味もそっけもない。何も考えずに、職種が合う募集に片端から応募することに拍車が掛かる。

　また、同じ企業が、週に1度ぐらいの頻度で何度も広告を載せてくることも多いので、どの企業が応募済みで、結果待ちなのかどうかも分からなくなってくる。とにかく、毎日、広告を見て、新しく追加されている広告に、以前応募したか否かなど考えずレジメを送り続けることになる。どうも、この国ではこのやり方が一般的なようだ。

　さて、このやり方で求職者が募集に応募して来る国で、企業の側はどういう状態になっているかは予想が付くだろう。そう、毎日、多数届くレジュメ、中には、毎日同じものを、送ってくる輩もいるだろう。その中から、面接する人を選ぶ。レジュメの中身をいちいち読んでいる暇などない。とにかく、目立つレジュメを見付けて面接する。みたいなことになっているに違いない。

　結果、レジュメはパッと見で目立たなくてはならないことになる。有名企業の名前があったり、何かの難しい資格があったり。さて、ものすごく長くなってしまったので、この続きは、次回に続くことにする。終わる前に、その片っ端から、レジュメを送るために使った求人サイトをリストする。

 
• JOB STREET
• Job DB
• ST Job
• Monster.com

　さて、内定取り消しといえば、日本で、去年の東日本大震災の影響で、新卒就職の内定取り消しの数がかなり多かったと報道された。これによると、全国で600人程度。そのうち震災の影響によるものが450人、つまり震災の影響でない取り消しが150人程度とある。この数をどう考えるかだが、新卒学生の就職活動の場合、3年生に始まり、4年生中に内定をもらうらしい。つまり企業は内定を、実際に勤め始めてもらう1年も前に、出す必要があることになる。新卒の内定を、これほどまでの事前に出さなければならない慣行。学生にとって学業の妨げになるだけでなく、企業の側にとっても、恐ろしく厳しい条件だと思う。実際、震災の影響でない内定取り消しが全国でたったの150人という数字。これは、私は、各企業そして学生がものすごい無理をした結果だと思う。

　この、企業と学生双方にとって明らかにLOSE-LOSEな慣行が毎年続けられているのは、異常だと思う。付け焼刃のゲーム理論の知識だが、この慣行は一種の『囚人のジレンマ』の状況だろう。つまり、学生と企業の両方で最も理性的な行動を取ったにもかかわらず、その結果が、両者にとって決して好都合な結果になっていないということ。こういう時の解決は、政府の介入しかないと思うが、なぜかない。それが不思議で仕方がない。

　そこで、少し考えてみた。1年も前の内定は仕事量の変動が会社全体として少ない企業にとっては負担が少ない。それがどういう企業かというと、やはりそれは大企業だ。どういうことか。

　大雑把な計算をする。例えば、毎年4月に1000人の新卒を取る従業員が3万人の大企業があるとする。その企業には、平均10人程度の社員で構成される部署が3000あるとする。すると、これはつまり平均して3部署に1つで、1年後に新卒を雇用できる状態になると予想したから1000人採用を決めたということだ。ところが、1年も先のことの予測は、それぞれの部署の単位ではかなりの確率で外れる。

　実際にその企業全体として何人の新卒を使える状況になるかだが、その数は、ポアッソン分布に従うと考えられる。ちなみに、ポアッソン分布では平均と分散は同じになる。

　つまり、必要な新卒の平均が1000人だとしたら、その分散が1000になる。分散が1000なので、標準偏差が1000の平方根で、32人程度。つまり、分布が正規分布に従うとすると70%ぐらいの確率で、1年後に実際に必要な人数が1032人から968人の範囲に入ることになる。悪い方に傾いたとして、例えば、1000人に内定を出した後、1年後に実際968人しか雇用できなくなったとして、余分に採用してしまった32人だが、この程度なら、3000有る部署の中で、なんとかやりくりできる範囲だろう。つまり、大企業では、今の慣行を維持する負担はそれほど大きくないことになる。

　ところが、50人程度の企業で、新卒を1人取ることを決めた場合。1年後の平均雇用人数は1人、そして分散は1。よって標準偏差は1人。70%ぐらいの確率で、実際に雇用できる人数は0人から2人になる。悪い方に傾いて、仮に0人、つまり雇用できないことになってしまったとしたら、当然その企業は、内定取消にせざるを得なくなる。

　というようなことを考えると、分かってくることは、日本の中小企業にとって、日本の新卒採用慣行に則り、1年後の採用を出せる企業は、かなり限られることになる。多分、

1. 成長分野に乗っており、毎年、確実に大きくなっていくことが分かっている企業
2. 事業は毎年それほど変動がないが、スタッフに近いうちに定年退職になる人がいるなどで、1年後に確実に人を雇える状況を見込めるところ
3. そして、『万が一、1年後に雇うことができなければ、内定取り消しにしちゃえば良いや』と考える、学生の人生のことを何も考えない企業

だろう。

　（1）の場合は、学生にとっては取り消しになる可能性は低いと考えていいので、問題はないが、企業の側、特に実際に採用を出した部署は、1年間どんどん仕事が増えてくるのにもかかわらず、1年後に新卒が来ることを想定しているので、人を増やせない状況になる。それが結構きつい。

　実は、東京でとあるスタートアップで開発部署のマネージャを努めていたころ、新卒を1人採用することを決めて、実際に内定を出したことがある。当時の日本の慣行とおり、来てもらう1年前に内定を出した。ところが、その1年間にいろいろあって、申し訳なかったが、内定取り消しを通知せざるをえなくなった。その学生、もちろん大憤慨。社会保険事務所に駆け込まれ、保険事務所の所員からの調査のための訪問を受けたりした。私は経営者でなかったので、結局どういう形で、ことを収めたのか詳しくは知らないが、非常に残念な結果になった。

　他の職種がどうか分からないが、ソフトウェアの開発者は、適性があれば、優れたリーダのいるチームなら、新卒であろうとかなり短期間に戦力になるものだと思う。私が面接で、適性もやる気もあると判断し、もちろん、最終決定するのは経営者だが、私の意見を取り入れた形で内定を出した人で、入社後の活躍を思いっきり期待していただけに残念だった……。

　さて、学生の側が、この内定取り消しを避ける方法だが、1番確実な方法は大企業を目指すこと。しかし、大企業の採用人員だけで、すべて日本の大学の卒業生を採用できない。中小企業からしか内定をもらえない学生も多いだろう。また、そういう消極的理由でなく、大企業特有の細かく職務分類された形で仕事をするのが嫌で、中小企業を積極的に目指す学生も多いだろう。そういう学生は、内定取消のリスクを常に考える必要がある。特に、上述した（3）のケースは絶対に避ける必要がある。しかし、そんなこと、社会経験のない学生に判断できるわけがない。運を天に任せるしかないと、僕は思う。

　最後に、最初に書いたが、企業にとっても学生にとってもLOSE-LOSEなこの慣行、なぜ維持され続けているのだろうか？ これは、まったくの私の推測だが。大企業が優秀な人材を1人占めできる状況に政府、官僚にとって、少なくとも短期的な一定のインセンティブがあるからでないだろうか。さらに、大企業の側も、もしかしたらある程度、政府や官僚に圧力をかけているのかもしれない。

　私自身の経験を少し書く。

　私が日本で新卒で就職した1985年当時は、就職活動解禁は4年生の10月だった。実際、私が内定をもらったのは4年生の10月の最初の週ぐらいだったと思う。そのころの学生の就職活動は4年生の夏休みに同じ大学の卒業生で、目指す企業に勤めている先輩の話を聞くために会社訪問した。その過程で、めぼしいところを決めて、夏休みがあけて10月になって入社試験、面接をして内定をもらうものだった。つまり、6カ月前の内定がそのころの慣行だったわけだ。私は、それでも長過ぎると思うが、今の12カ月前よりは、はるかにましだった。

　また、ここシンガポールで約1年大学院生をやっていて、7月末でそれを終えたわけだが、今回、同級生の就職状況を見た。卒業してまだ仕事を見つけていないもの、6月の時点から働き始めたものなど、さまざまだ。大学側も、企業の側に大学に来て説明会を儲けることを促したり、学生を採用予定の複数の企業を集めて、最終学年の学生を対象に大がかりなリクルートフェアを学内で開催したりで、かなり大がかりな就職支援をやってくれる感じで、総じて、日本の学生の就職活動より、はるかに学生にとっての負担は小さいと感じた。

　新卒向けの特別な就職慣行があるのは、世界でも日本と韓国だけらしいが、そんなもの早く辞めて、世界標準の、卒業した学生が働き始める時期がみんなてんでバラバラに異なることを良しとする慣行に、早くしてしまった方がいいと思う。

　（*1）  私の今回の内定取り消しだが、取り消しを受けた後、運よく同じぐらいの条件の別の仕事に8月から就けた。しかし、それは結局、金融関係の開発の仕事。もちろん、金融関係と言っても範囲は広く、今回仕事をついたものは未経験な分野で、それなりにチャレンジングではあることは確かだが、結局、研究の分野の仕事に就けなかったショックは大きい。しかし、もともと、大学院で勉強すると決めた時、年齢を考えて、卒業後に研究関係の職場で働ける可能性は低いと考えていたので、その予想どおりになっただけではあるが。

　しかも、生物関連の研究のためのプログラマ。つまりバイオ・インフォマティックスの仕事。バイオ・インフォマティックスは諦めていただけに、結構うれしい。しかし、この仕事、確かにバイオ・インフォマティクスではあるが、実は、仕事の一部に日本で行われる開発のコーディネート作業が含まれている。

　資格的に問題がある僕、年寄りで、成績も良くない僕、それにもかかわらず、僕の職務履歴書が選考者の目に止まったのは、僕が日本人だからであることは明らかで、日本人で良かったと思うことしきりである。

　今回、こちらの日系のエージェント、オンライの求人広告などで多くの求人を見た。最近のシンガポール、そして他のアジアの日系企業の求人募集の傾向を見ていると、採用はこちらに住む日本人より、日本語を話せるローカルスタッフにより重きをおく傾向が強まっているようだ。

　日系の求人欄を見て、『Japanese speaker』と書いてあれば、それは日本人ではなく、日本語を話せる外国人の求人だが、最近そういう求人がどんどん増えている。しかし、そうは言っても、今のところは、やはり日本は大国。お金持ちの国である。求人上に現れる、多少条件が良い仕事は日本が絡んだものであることが多い。

　今回思ったが、僕の人生、結構ついていると思う。私が就職したころの1985年は、日本はバブル景気全盛。私の出た大学の、私より数年前の卒業生の就職先を見ると、あまり名前を聞かないところが多かった。しかし、私が卒業した前後の数年の就職先は、誰でも名前を知っている企業の名前が並んでいた。

　そんな時代だったため、僕のように成績が良くない人でも、名の通ったところに就職できたのだと思う。さらに、それだけでなく、就職して3年目にロンドンに赴任してしまった。『ロンドンに赴任』その言葉だけで『エリート』と連想してしまう人が今でも多いのではないだろうか。実際自分も、もしかしたら『俺ってエリート？』と誤解したものである。しかし、実際、当時の僕がどれだけのものだったのか？ 全然仕事はできず、先輩の足を引っ張るしかできなかった。

　しかし、若い時期に外国に赴任できたおかげで、英語の環境で仕事ができるようになったことは、まぎれもない事実だ。そのおかげで、私は現在、外国人の中で仕事をしている。私をロンドンに送ってくれた、大学卒業後、私が最初に就職した会社に感謝感激である。しかし、私を送ることに決めた人は、さぞかし、不安で不安でしかたがなかっただろう。

　時を経て、2000年ごろ。僕はそのころ、横浜にいた。そしてソフトウェア開発がやりたくて仕方がなかったが、当時の私はテクサポ要員で開発ではなかった。そこで、転職先を探してみるが、開発未経験で、かなり年を食っていた私を採用するところなどなかった。このまま、やはりこの会社でテクニカル・サポートをやるしかないのかと思っていた矢先に、職務経歴書を送った東京のとあるスタートアップが面接に僕を呼んでくれた。面接官はイギリス人で、英語で面接。結果、あれよあれよという間に内定。あっけなく、転職に成功してしまった。

　実際に働き始めて分かったことは、私が採用された理由は僕が英語ができたこと。それだけだった。開発の経験のあるなしは、二の次だったようだ。イギリス人ボスの下で、数人の日本人のデベロッパ。コミュニケーションに難儀を極めていたのだ。

　そこでの開発、実はアーキテクチャ的にかなり問題があったが、その点を、後に僕が何とかするとは、多分私を採用するときに期待していなかっただろう。とにかく、私は、これでソフト開発者になれる。このチャンスを逃すわけにはいかないと、必死でソフト開発を勉強。なんとか、開発技術を身に付けて今の私に至るわけだ。

　そして、今回、私は新たな分野、つまりバイオロジー関連の研究のための開発の仕事を得た。そして、それを、私が日本人であるという『とっかかり』から得た。もちろん、大学で勉強したと言えど、最先端の内容のバイオが簡単なわけがない、これから相当苦労することになるだろうが、なんとかなるの精神でやっていこうと思う。

　人生は、ロック・クライミングの要領だと思う。手を伸ばして、自分の体の上の岩をまさぐってみて、なんでも良いので、『とっかかり』になる岩の出っ張りを見つけて、そこを使って一気に体を引き上げる。『とっかかり』は何でも良い。『日本のバブル』『英語ができること』『日本人であること』。とにかくチャンスをつかんだら、後はその『とっかかり』を絶対に離さず体を引き上げるべし。そういうことだと思う。片手で全身を引き上げるのだ、相当苦労することになるが、それは、それでやるしかない。

　今、ITエンジニアをやっている皆さん。今の仕事に満足しているなら、それはそれで良いが、もしそうでないなら。とにかくどこかに『とっかかり』を見つけて、それを頼りに、別の道を模索してみるべきだと思う。

　例えば、日本では今、スマートフォン系のエンジニアが不足している。もしそれをやってみたいなら、経験があるなしをあまり考えず、とにかく、職務経歴書をそういう開発をやっている会社に送ってみるべきだと思う。運良く面接にこぎつけられれば、『僕はいままでこんなに、自分で勉強して技術を身に着けてきました、未経験のスマートフォン開発など、へのかっぱです』と必死にアピールすると良い。ここで使う『とっかかり』は、1つのことを自分の力で習得したと言う実績だ。

　僕がもし、スマートフォンアプリ開発マネージャで採用の権限を持っていれば、それで採用すると思う。多少不安だが、なにしろ、猫の手も借りたいのだから。

　僕は、イギリスやアメリカで働いたことがある。欧米でも、年が高いプログラマは仕事を見つけにくい傾向が少しはあるだろうが、やはり能力重視が普通で、アジアほど年が高いエンジニアが仕事を見つけにくくなる傾向はないと思う。

　私がイギリスやアメリカで働いていたときはプログラマ職でなかったが、テクサポのバリバリの現役のエンジニア、つまりマネージャでない人で、50歳以上の人がかなりいた。またイギリス人のITエンジニアが多く受講しているインドのITトレーニングに行ったときに気付いたが、そこでも、受講者の多くは私より年上ぐらいの人だった（当時私は45歳）。極めつけは、60歳のイタリア人もいた。

　これ以上書くとボヤキになるので、ここまでにして、今回書こうと思ったのは、そういうことではなく、私の英語の勉強暦。前にもそのような内容を書いているので、今回はもっと詳しく書く。

　今の時代、英語を勉強しようと思ったら、特にリスニングの材料は、YouTubeの動画やiTunesなどのPodcastまで、山のようにある。さらに、トーキングの場所も、フィリピン人を講師にした安価なオンライン英会話がどうやらブレークしたようで、選り取りみどり。

　英語を勉強したい人にとっては、夢のような環境になっているわけだが、そうなったのは多分、すべてインターネットの普及のおかげ。僕自身がインターネットを使い始めたのは1995年ごろで、当時イギリスに駐在していたが、近くのパソコンショップで4～5万円もしたモデムを買って『ピーヒャララ』(*1)から入ったが、日本でインターネットを常時接続で使うことが普通になったのは、多分Yahoo! BBからだから、おそらく2002年ぐらいから。つまり、まだ10年ぐらいの歴史しかない。

　この10年、日本の英語学習の環境の様変わりを見ると、隔世の感がある。今まで、日本人は先進国のなかで一番英語が下手ということで有名だったが、10年前に中学生になった人、つまり当時、英語を習い始めた日本人が、現在、大学を卒業する時期に来ているわけで、そろそろ汚名の返上の時期がやってきているのかもしれない。楽天など、ついに、社内での日本語が厳禁になったらしい。

　僕が真剣に英語を勉強しようと思った時期は、大学生のころの1983年ぐらい。当然インターネットはない。トーキングの場所は皆無。リスニングも、少なからずのお金を出して、テープやCDが買うしかなかった。実は今でもあることに驚いたのだが、 ヒアリングマラソンと称して、毎月テープが送られている教材を、高いお金を出して受講してみたり、イングリッシュアドベンチャーなるものがあって、シドニーシェルダンの英語のミステリー小説をオーソンウエルズが読んだテープ集を買ってみたりした。

　それより少し後のころだろうか、テレビで音声多重放送が始まって、これでニュースを英語で聞けると喜んだのも覚えている。そんな中でも多分、一番効果があったかと思うのは、ソニーの短波ラジオを購入して、BBC国際放送と、VOA（Voice of America）などの短波放送を聞いていたこと。大学までは関西だったので、関東にしかないFENは聞けなかった。関東に就職した後、FENを時々聞いたが、FENはやはり駐留米軍向けの放送で、スラングだらけの早口アメリカ英語で、結局ついていけなかった。

　英語の実践的勉強法としてよく読んだのが、松本道弘さんという、海外留学せずに英語の同時通訳者になった人が書いた本。調べると、松本道弘さんは、今では70歳を超えているのに今でも現役らしく、ブログなどを書いている様子。

　彼の推奨するやり方はいろいろあったが、基本はまず、インプットを増やすこと。英語を話すにも、話す内容がなければ意味がないと主張。とにかく多読を薦めた。欧米の高級誌が、よくNewsweekやNew York Timesを読むように薦めていた。ただし、学生だった僕は、薄っぺらい雑誌なのにもかかわらず、500円以上した雑誌をあまり買えなかった。しかし、就職して少し自由になるお金が増えたころは、Japan Timesなどの英文の新聞を読んだ。

　学生のころ、ペーパーバックを買って読もうとしたこともあったが、ついに最後まで読めるものはなかった。そのころの英語力では、知らない単語が多すぎて読みきれなかった。しかし、25歳になってイギリスに駐在したころ、会議や電話で聞く英語が分からず、克服はやはりより多くの英語に接するしかないと、英語のペーパーバックの多読に走った。初めて最後まで読みきれたペーパーバックは、確かシドニー・シェルダンだったと思う。最後まで読めたときは、結構感動したのを覚えている。

　しかし、松本道弘さんのアドバイスで一番大きかったのはシャドースピーキングだった。何をやるかというと、日常、車に運転していたり、電車に乗ってたりして、なにもやることがないが頭を使える時間を利用して、とにかくなんでもいいので、思い浮かぶことをすべて頭の中で英語にしてみるのだ。この時しっかりとした文章の英語にする努力をすることが大切。実際に口ずさんでもいいかもしれないが、車を1人で運転しているときならいいが、電車の中では変人と思われるので、頭のなかで閉じておくほうがいいだろう。

　実は最近、脳について少し興味があり、いろいろと本を読んでいる。ヒトの頭には1000兆のニューロンがあり、そのそれぞれのニューロンは平均1万個の他のニューロンとつながっている。脳の働き、記憶や論理の能力などすべては、この接続それぞれに付加されているウエイトで実現されている。そして、このウエイトを調整していく過程が学習になる。学習は1回で最適のウエイトに達することはなく、複数回の学習で少しずつ最適になっていくものらしい。

　つまり、何かを学習するに際して、繰り返しの効果は非常に高いということだ。繰り返し同じことを頭にさせることで、ニューロン間の接続のウエイトを最適化していくのだ。

　何を言いたいかというと、語学の学習成果は、その外国語にふれている時間、つまり練習する時間に相関するということだ。忙しい人が英語に触れる時間を増やす一番簡単な方法は、頭が空いている時間を、英語の練習にあてることで、このシャドースピーキングはそれに最適。何しろ、車を運転していても、電車に乗っていてもできるのだから。

　ということで、今英語を勉強している方は、今の恵まれた環境におぼれることなく、空いた時間をうまく利用して、24時間を最適に利用して勉強されることを薦めます。多分、1日30分のオンライン英会話で英語を勉強するだけでは、あまり能力の向上は見られないのではないでしょうか。とにかく1日のうちのできるだけ長い時間を、自分の頭を英語漬けにさせる努力が必要だと思う。そしてそのための工夫をいろいろとやってみることが大切だと思う。

(*1) 『ピーヒャララ』　この意味が分からない人がまさかいないと思うが、もしいたら、周りの先輩に聞いてください。

　たぶん、ヤフーが倒産でもしない限り、一生使い続けるだろう。そして、そのメールアドレスを、私のホームページ他で大公開している。

　誰でも簡単に、私がどういう人であるか知ることができて、その私にメールを送れることになる。そのおかげで、Webを通じて、いろいろと知り合いもできた。

　ところが、問題は、今回のタイトルにあるようにスパムメールが毎日、大量に届くことだ。私に届くメールのうち、多分1日50通ぐらいのメールが、『バイアグラが安いぞ』とか、『良い娘いるよ』とか、『今が投資のチャンスだよ！』といったスパムだ。

　もし、Yahoo! Mailのスパムフィルタがなければ、私のメール受信リストははぼこの種のスパムで埋ってしまう状況で、メールは使いものにならなかっただろう。ヤフーのスパムフィルタに感謝感激である。時々、忘れたころに届く重要な仕事関連のメールが、スパムとして判定されてしまうなんてこともあるが、それは仕方がないことだろう。重要なら、普通は相手も電話をかけてくれるので、あまり大きな問題にならない。

　さて、このスパムフィルタだが、高度なAI（人工知能）の技術を使い、私などには絶対理解できないものなのだろうと思い、今までその仕組みについて考えたことがなかった。今回、バイオ・インフォマティクスの受講の中で、機械学習を教わり、それが実は簡単な仕組みであることを知った。そこで、今回はその機械学習のアルゴリズムを使って、簡単なスパムフィルタを作ってみた。

　naive baysean（ナイーブベイジアン）というアルゴリズムを使のだが、それなりの数学がある。実はそれほど難しいものではないが、コラムなのですっ飛ばして、結果だけ書くと、

                          N
Vmap = argmax (logP(vi) + Σlog(P(fj|vi))
       vi∈V              j　

　ここで、argmaxはどちらかのうちの最大になるものを返すという意味で、比較するのはv_i、つまりi=1のときをスパムとして、v₁のスパムメールと、i=2の時を通常メールとして、v₂の通常メールで比較する。P(v_i)は、中身を考えず受け取るメールがスパムか通常かの確率。これは、単に同じ期間に受け取ったメールをスパムと通常で振り分けるだけで求まる。P(f_j|v_i)は、数学の条件付き確率を高校生のときに習っていない人には、難しいかもしれないが、条件付き確率で、v_iの条件でf_jになる確率。f_jはjという単語の出現確率と考える。その確率は天下りだが、以下の式で求める。

            fjが使われているメイル数 + 1 
P(fj|vi) = --------------------------------------     
           すべてのメール数 + data中に使われていたすべての単語

　ここまでの直感的な理解はこういいうことだ。メールで使われる単語それぞれが、メールの中に入る確率を、スパムメールの時と通常メールのそれぞれごとにあらかじめ求めておく。例えば、スパムのメールに『バイアグラ』がある確率は、通常のメールにそれが入る確率より高いだろう。そして、判定しようとしているメールの中で使われている単語ごとのその確率を、スパムと仮定してのものと、通常メールしたもので、別々に掛け算をして、その結果を比較。大きな確率になるほうが、判定結果と考えてよいだろう。上の式では、計算機で処理するときの常套手段として、掛け算をLogを使うことにより、足し算にしている。

　ところで、このアルゴリズムを実装するに際して、必要なことに単語の抽出がある。単語がスペースで区切られている英語の場合は簡単だ。ところが、単語と単語と間の物理的な区切りがない日本語は難しい。厳密に単語を抽出するためには、日本語の文法や意味解釈をする必要がある。

　ヤフーのスパムフィルタがどういうアルゴリズムで単語の抽出を行っているのか、私は知らない。もしかしたら、厳密に意味解釈をやっているのかもしれない。

　ここでは、次のようにした。つまり、日本語の中で、重要な語句のほとんどは漢字とカタカナで、ひらがなはその重要な語句をつなげるために使われることが多いだろう。そこで、アルゴリズムの中で使う単語は、漢字の熟語とカタカナだけとして、ひらがなやその他の記号などは、それらの重要な単語を区切るのために使うだけにした。ひらがなだけで構成される語句はアルゴリズムで使えないことになる。少数だが、ひらがなだけで構成される重要な語句は当然ある、例えば『ひらがな』などは良い例だろう。しかし、ここではそういう単語は無視することにする。

　ということで、実装。実装をここに示したいが、一部でもかなり長いので、見たい人は私のページに来てほしい。POP3のメールを受信するクラスだが、Microsoftの.NETのフレームワーク中にないことを発見。そこで、ネット上のOpen sourceを探したところ、ろくなものがなかったが、たどりついたのが、higuchi氏なる日本人の、THE CODE PROJECTのUnderstanding the insides of the POP3 mail protocol: Part2なる記事。 このコードが私の欲しいコードにぴったりだった。この種のサイトに日本人の投稿を見つけたのは初めてで、かつここまでのレベルのものを見たのも初めて。higuchi氏と書いたが、実は東京に住む樋口昭太郎さんのコードで、.NETのOpen source codeが多く登録されているCode Plexにも同じコードが登録されている。HigLabo。

　これは機械学習の中でも教師あり学習、つまり答えの分かっているデータをコンピュータに与えて、コンピュータに『学習』させる方法を取る種類のアルゴリズムなので、まず正解の分かっているデータを機械に与える必要がある。つまり、あらかじめ分類済みのメールの準備が必要だ。この場合の学習の結果、得るパラメータは、単語ごとのそれがメールの中で使用される確率、つまり、P(f_j|v_i)ととなる。それを、スパムと通常メールのそれぞれで求めることになる。トレーニングデータは、私のYahoo! Mailに到着するメールをスパムフィルタにより分類させ、少数ある間違いを私が自分自身で修正したものを利用した。

　ヤフー側でスパムと判定されたメールは一月分しか残らないのでスパムメールは1月分しかなくて、データは十分ではなかったが、以下の結果になった。

　トレーニング・データとして、スパム342通、通常が380通、を学習させ、テストを別のデータを使ってやると、

• True Positve(正しくスパムを検出):68
• False Positve(誤ってスパムと検出):1
• True Negative(正しくスパムでないと検出):89
• False negative(誤ってスパムでないと検出):5

　スパムメールとして、一番困るのはFalse positive。つまり、通常のメールが誤ってスパムと判定され、スパムのビンに入れられてしまうことだが、それがたったの1件だった。簡単な実装で、近似だらけのアルゴリズムだが、ここまでの精度を得られるところを見ると、業界内で、『スパムフィルタはnaive bayseanで決まり』といわれている理由が良く分かった。もう少しの努力で、実用レベルのものを作れそうだ。

　実は、僕は現在、大学にパソコンと机を与えられて卒業研究をしている。普通マスターの学生には、そういう環境は与えられないのだが、たまたま当たった指導教授の学内での政治力の関係か、ここで『研究』をしている。実は、周りはphD、つまり博士号の学生ばかり。

　僕が在籍する学部は生物学科ではなく、情報処理の学科なので、みんな情報処理のphDを目指して、連日連夜休みなく、日夜パソコンの前で格闘している学生だ。ほとんどは中国からの留学生。

　彼らは、どんなことを研究しているのか？ 実はほとんどは、この機械学習に絡むことをやっている。もちろん学生ごとに微妙に違う。グラフ理論を絡めて体内のたんぱく質の挙動を予想してみたり、時系列のデータを学習させて将来に証券市場で何がおこるかを予想してみたり、自律ロボットが自分で判断して動くため、周りの状況をパタン認識させたり。

　つまり、みんな基本はいわゆる『ビッグデータ』を機械学習で分析するような内容。ビッグデータが体内のたんぱく質間の連携だったり、証券データだったり、マーケッティングデータだったり、周りの視覚情報だったりするが。

　現在、現役のITエンジニアの中で機械学習を使って何かの開発をやっているような人はあまりいないかもしれないが、これからどんどんそういう分野の案件が増えてくるのは確実だと思う。何しろ、世界何十億人の人の日々のネット上のやりとりがすべてデータとして蓄積されていく昨今、宝の山がそこにあるのは確かなのだから。もちろん、機械学習の応用はネット上に蓄積されているデータの分析だけではなく、僕が今回大学で機械学習を学んだように生物学。さらに、自律ロボットや、自動車の自動運転、経済の予測、もしかしたら天気予報?など、応用分野は現代の産業のいたるところに現れる。

　機械学習は、基本的にアルゴリズムの集まりで、何かの現象のデータを機械つまりコンピュータに入力して、そのデータを基にコンピュータに必要なパラメータを推論させ、その後そのパラメータを使って、ものごとの判断をコンピュータにやらせようとするものだ。機械にデータを入力して『学習』させるわけなので、『機械学習』だ。しかし、今では、本当にAIと言ってもいいぐらいの応用ができる分野ゆえに、名前の野暮ったさをぬぐいきれない。

　機械学習を勉強していて最初に紹介されるのは、回帰分析。日本では、中学もしくは高校で習うのではないだろうか。縦軸に予測したい何かの数値を当てはめて、横軸に予想に使う数値を当てはめて、グラフ上に観測データをプロットして、そのプロットに最も近い直線を求める。直線は普通は、最小二乗法で求める。

　世の中で、行われる科学的分析、その他の説明でたいてい使われるグラフだ。誰でも直感的に理解できるゆえ、特に一般向けに科学を説明する時には不可欠のグラフだ。例えば、福島第一の事故以来、日本のマスコミで取り上げられない日がないぐらいのグラフが下のグラフ。

　被爆量とそれによる人体への影響を表すグラフ。このグラフでは、実データはプロットされず、その実データから回帰分析の結果得られる直線もしくは、曲線を表示しているだけだが、上のグラフにもそのグラフを予想するために必要だった実データが必ずあることを注意すべきだ。その点で少し問題があるのが、上の図中の下側のグラフ、つまり『確率的影響のグラフ』の点線の部分。『仮定』と書いてある部分。実は、この部分のデータは存在しないのだ。というか自然の放射線によるノイズの影響があまりに大きく、信頼性を置けるデータを採取出できないのだ。サイエンスの世界で、データから何かを回帰分析するとき、やってはいけないことの1つとして紹介されるのが、このExtraporate(外挿)というやつで、上のグラフはまさにそれをやっている。測定できない範囲まで、測定できた範囲で予想した直線を引き伸ばしているのだ。

　多分、低線量のデータはないが、何かの結論を引き出さなければ原子力の応用が前に進まないということで、本来はやってはいけないことを仕方なくやっているわけだ。上のグラフは、しっかりと『仮定』と注意書をしているので良心的だが、そうでないものも多い。

　ちなみにこの点線の部分、つまり低線量の被爆による体への影響の、本当のところはどうなのか？ データがないため定説はまだない。しかし、3つの説がある。

　1つは、上の図の下側のグラフのように体への影響は直線的に減っていくという説(LNT仮説)。現在の日本政府はこの説を採った形で法律を制定している。一番安全性を重視する説なので、それはそれで政府としては正しい判断なのかもしれない。

　もう1つは、実は低線量での影響は、上図の上側のグラフ、つまり『確定的影響のグラフ』と同じで、ある一定以下の線量からは影響は限りなくゼロになるという説。

　そして、最後に、実は『低線量は体に良い』つまり、ホルメシス効果の説。ちなみに僕はホルメシス効果を信じる。生物をいろいろと学んだが、知れば知るほど、生物は体を外部の影響から守る仕組みを高度に発達させていることが分かる。太古の昔、地球は高濃度の放射線にまみれていた。現存する地球上の生物はすべてその時期を乗り越えて進化して来たわけで、多少の放射線の影響から体を守る仕組みがあるはずだ。

　だいたい、酸素と言う非常に危険な元素を使ってエネルギーを得ている生物である。放射線により発生するフリーラジカルと、酸素により発生するフリーラジカルも同じもの。結局のところは両者は同じぐらい危険なのであって、酸素のよるフリーラジカルの影響もなんのそので生きている我々は、放射線起源ののフリーラジカルも同じく、うまく対処しているに違いないのである。多少の『ばい菌』にまみれながら生きているのが我々であるのと同じように。

　機械学習と関係ない話を長々と書いてしまった。機械学習の最も初歩について紹介した後、一気に最も最先端の応用を紹介する。

　ということで、Googleが開発中の車の自動運転の機能。下の映像を見てほしい。車の屋根につけられたレーザ光の反射、そしてフロントグラスにつけられたカメラの映像情報などの情報の処理法を機械学習のアルゴリズムで学習させ、見事にサンフランシスコの公道を自動運転している。

　実は小生、シンガポールの大学に入学し1年。そろそろ卒業で、現在は卒業研究に勤しんでいる。そのため、教科書や論文などをとにかく大量にに読まなければならない状況だ。小生、コンピュータのソフト開発の技術習得では、英文の本をとにかく大量に読むことを常としていた。本は通勤途中に読むと決めていた。コンピュータソフト関係の本、特に原書は確かに重いが、列車の中で立って手すりにつかまりながら読めないほど重いわけではない。しかし、同じことをやろうとして、生物学の教科書の多くは日本人の感覚では常識はずれに大きく、かつ重い。日本の雑誌の大きさの本でページ数が1000ページを超える。1ページは横2段だ。これを列車の中で手すりにつかまりながら読むのは不可能だ。そこで、まず考えたのは前から持っていたAsusのEeePCにPDFリーダをインストールして、それでPDFで手に入れた専門書や論文を通学途中に読むことだった。PDFリーダは本の画像をPC画面に横表示にできるので、その機能を使って、PCを縦にして読むのだ。

　しかし、この方法は実は僕には無理だった。雑誌大の本の1ページすべてを一画面に表示させると文字が小さすぎて私には読めなくなてしまうのだ。50歳の小生、実は10年ぐらい前から、小さな字が読めなくなっている。そこで横表示はあきらめて縦表示にすると、確かにこれで読めるが1ページすべてが一画面に入らなくなり、スクロールが必要になる。これも気に入らない。ということで、最近はEeePCで本を読むのはあきらめている。

　そこで、私もiPadもしくはGalaxyを購入しようかと考えるのだが、これもよく考えてみると、画面の大きさが生物の巨大教科書の大きさより小さいことに気付き、これで巨大本を読むとかなり字が小さくなりそうなので、結局辞めた。

　今は、結局読もうと思う本や論文を家で印刷して、それを通学途中で読むようにしている。

　そしてこのやり方が結局一番良いと今ではかなり満足している。何が良いかと言うと、まず気軽なこと。丸めて持てるし、とにかく軽い。さらに、読み終わった本のチャプターや論文をまとめて積み重ねて保管していくと、それがどんどんたまっていくところを毎日見ることになり、達成感を得ることができる。英文の専門用語いっぱいの専門書を読むのだ。かなり無理して読む。

　モティベーションを維持するための、この達成感は非常に重要だ。デメリットはいちいち印刷が必要なこと。あらかじめ読む部分を決めて事前に印刷しておかなければならない。印刷のカートリッジの費用がかさむのでないかと思う人もいるかもしれないが、実はそれは問題ない。安いインクジェットプリンターを利用しているが、普通に文房具屋で購入できるようなインクのカートリッジは買わない。プリンター本体の価格と比較してあまりに高価なカートリッジを買わせるプリンターメーカーのビジネスモデルの罠にははまらない。つまり、インクの詰め替えが可能なカートリッジを使い、インクの入れ替え時に手は汚れるが、ボトルに入った安いインクをカートリッジに注入しているのだ。

　そんな経験から、僕が使ってみたい読書用端末を考えてみた。多分、海外の大学生に受けると思う。日本の大学生と違って、大量の文章を読むことを要求され、さらに読む本は普通巨大。日本なら分冊にしたり、小さな新書版程度の大きさにするところだが、海外では平気で巨大な本が多くある。

　イメージはこんなもの。Paint brushで下手に書いて見ました。目玉は大きな本をこれで読めるが、持ち運び時は折り畳めるので小さくなる。

　システム手帳の少し大きめみたいなイメージで、上の茶色の部分が革の装丁。黒いところが電子回路。そして青色が、液晶。ある程度まで丸めることができる。これを広げて本を読む。

 
1. 最低でも、広げてA4サイズの大きさがほしい。
 
2. 安価　1万円を超えないこと。
 
3. できればカラーだが、高くなるなら不要。
 
4. 動画はPCを使ってみるので不要。
 
5. 容量は一度に1000ページぐらい入ればそれで良い。その替り、PCと接続して簡単に中身を入れ替えることができるようにする。
 
6. Web接続などは不要。USBでPCからファイルを取り込むことができればそれで良い。
 
7. 書籍はWeb上で購入できるようにするべき。

　クリアするのはかなり難しいだろう。特に値段や折り曲げられたり、丸められたりする機能はかなり難しいと思う。しかし、実現できれば世界中の大学生がこぞって購入すると思う。日本の本は文庫本が主流なので、iPhoneなどのスマートフォンでも本を読めるぐらいだ。そのため、日本にはそれほど需要は無いかもしれない。しかし、海外では受けると思う。KindleやiPadで先行されてしまったタブレットのマーケット。このような機能の端末を出すことができれば、日本の家電メーカーにもまだまだ巻き返しができると思う。多分シンガポールの学生の間でのiPadの普及率はかなり高いと思う。今のところ10人に1人ぐらい。米国や欧米も同じようなものだろう。残る10人に9人のマーケットがある巨大マーケット。そのマーケットをみすみすGoogleやMicrosoftに渡す手はないだろう。日本のお家芸の技術力で、残る10人に9人のマーケットを取れると思う。

　大学もそろそろ卒業で、再びエンジニアライフへの投稿を再開することにしました。最初はこんなのを書きました。大学在学中も実は、コラムは書き続けており、それは自分のホームページに載せていました。良かったら、読んでみてください。