ベトナムにおける、優秀なプログラマーの見つけ方

いやぁ、ベトナム在住という特徴を活用するのを忘れていました……。私には、それくらいしか特別なところはないのにね。

というわけで、今回は、素敵なベトナム・ライフ……なんか知りません。私はプログラマーでヒキコモリなので、外を出歩きませんから。というか、そもそもベトナムのハノイに素敵な場所なんかないですし。

ですから、やっぱりコンピューターの話を。将来ベトナムで働くかもしれないプログラマーの皆様向けに、2012年7月現在での、仲間となる優秀なプログラマーを採用する方法について考えてみます。

高給待遇で、大量の応募者を集めましょう

まずは、高給の待遇を用意して、とにかく大量の応募者を集めるべきだと考えます。以下に、この結論に至った経緯を述べます。

ベトナムの学校での教育内容は、暗記が中心です。実は、ベトナムは科挙を世界で一番最後まで実施していた国です。科挙には「家柄ではなく学識に基づく官僚制度を創り上げたというメリット」だけではなく、「非実用的な知識の詰め込みだったというデメリット」があったわけで、残念なことに、ベトナムにはこのデメリットが色濃く残っているようです。昔、ベトナム人に試験問題を作らせたら、テキストの文中の重要ではない単語（inとか）を穴埋めさせる問題を作りやがりました。そんな問題、ページ丸ごと暗記していないと解けないっつーの。

また、教育の内容も古いようです。以前、大学に企業説明会で伺ったら、黒板に、プリエンプティブ・マルチ・タスクのOSがどーのこーのと書いてありました。この内容は、そろそろ就職しようという学生に教える内容じゃないよなぁ……。また、授業で使うプログラミング言語も、古き良きC言語が多いようでした。古くても内容が高度ならばそれでよい*1のですけれど、応募者にC言語のポインターについて聞くと、まともに答えられない場合が多かったです。

というわけで、情報工学系の大学を出ていても、そのプログラミング・スキルには期待できません。でも、

そんなことは問題にはならない！ウォーター・フォールならば、スキルの問題は発生しない。ウォーター・フォールでプログラマーに要求されるのは、設計書をコードに変換する作業なのだから！

と考えて、スキルの問題を無視している方が多いように思えます。

とーんでもなーい。

ビジネス・アプリケーションでウォーター・フォールを「完全に」運用するなんて絶対に無理！非現実的に過ぎます。ウォーター・フォールってのは工程単位で間違いがない完全な成果物を作り上げる（間違いが発見されたら後戻りしてやり直す）というやり方で、それには金と時間が必須なのです。金も時間も足りない普通のビジネス・アプリケーション開発における設計書には、間違いがいっぱいあります。SI（System Integration）プロジェクトのコストと期間の削減圧力なめんなって感じです。

だから、ウォーター・フォールを採用しているプロジェクトでは、多かれ少なかれ、問題にならない程度にズルをしていると思います。詳細設計とプログラミングを同じ技術者が担当して、ちょこちょことプログラミングしてから詳細設計書を書いたり。基本設計書の間違いを、基本設計書を修正せずに詳細設計書でだけ修正したり。よくあるのが、詳細を書かずに行間を読みながら後工程の作業をするというルールで運用しちゃうとか。ウォーター・フォールの下っ端のプロジェクトへの貢献を舐めんなって感じです。

ただ、このようなズルをまがりなりにも実施できているのは、いつでも前工程の担当者にヒアリングできる（ので曖昧なところや間違いがあってもすぐに解決できる）からなんですよね……。ベトナムでオフショアの場合は、残念なことに、いつでもヒアリングできるという前提が当てはまりません。

だから、日本側が頑張って完璧なウォーター・フォールを実施する……なんてのはオフショアを使うコスト削減の圧力が高いプロジェクトでは期待できないので、ベトナム側でどうにかしなければなりません。ヒアリングせずに、ヒアリングした場合と同じ結果を出すわけですな。設計書の矛盾を付きあわせ、システムの全体像を思い浮かべて正解を導き、ソース・コードの詳細を想像して最適な実装を提案し続ける。これを、直接コミュニケーションなしでやるわけ。うぅ、とてもキツイです。

だからそう、優秀ではないプログラマーには、完璧ではないウォーター・フォール、かつ、オフショア開発での下っ端はこなせません。優れたプログラミング能力と、仕様の全体像を理解できる頭の良さと、設計書の矛盾に気がつく細かさが必要になるのですから。で、ベトナムの教育内容では、こんな高度な作業ができる人は作られません……。

もちろん、ウォーター・フォールをやめるという選択肢もあります（プログラマーの私としては大歓迎！国内でやる場合であっても、下っ端に支えられたウォーター・フォールってのはやっぱり無理があると思いますもん）。しかし、アジャイルを採用したとしても、やはり高いスキルを持ったプログラマーが必要になってしまいますから、ベトナムの教育が問題になっちゃう。教育問題のソリューションにはならないわけですな……。

うぅ、どうしましょう？

幸いなことに、プログラミングの学習には、特別な設備が不要だという特徴があります。この特徴を利用しましょう。プログラミングの勉強は、コンピューターとインターネット、あとは少しの本があれば可能。だから、学校教育では不足する分を独学で補うことが可能。そしてモノ作りであるプログラミングは面白い。ということは？そう、独学で不足分を補った優秀な人が、一定の割合で存在するはずです。

ベトナムでは、その独学で不足分を補っている人を探すことにしましょう。そしてそのために、応募者の数を揃えることにしましょう。100人に1人の人材を10人集めたいのであれば、1,000人の応募者を集めればよいわけです。

そのためにはどうすればよいか？同業他社よりも高い給与です。会社を選ぶ際の第一の要因は、ここベトナムでは金なのですから。身も蓋もない話で恐縮なのですけど、「金でカタが付くのだから簡単」と前向きに考えちゃいましょう。発展途上国なので、金額もタカが知れていますしね。

プログラミングのテストをして、ダメな応募者をふるい落としましょう

大量の応募者の全員に対して、大きなコストがかかる面接を実施する必要はありません。ベトナムでは、簡単なプログラミングのテストをするだけで、ダメな応募者をふるい落とすことができます。

以下、順を追って考えます。

前節での考察で、採用のターゲットは、独学で学校教育の不足分を補った優秀なプログラマーだと結論しました*2。ただ、気をつけて欲しいんですけど、暗記中心のベトナムの教育の影響で、独学の際にも暗記中心にやってしまう場合があるんですよ。知識はあるけど理解をしていない場合は実際に手を動かしてプログラミングすることはできないわけで、それでは現場では役に立たないので困っちゃう。

というわけで、応募者が独学で勉強していて、しかも内容を暗記ではなくて理解しているかどうかを、チェックすることにしましょう。「教わっていない」ことを「実際にやらせる」わけです。

さて、ここで思い出して頂きたいのは、前節で述べたベトナムのプログラミング教育のレベルの低さです。教育レベルが高い場合には教わっていないことを探すのは大変ですけど、教育レベルが低いベトナムなら簡単です。あと、高度な内容を理解しているか確認するのは難しいですけど、レベルが低い内容を理解しているか確認するのは簡単です。というわけで、ベトナムでは簡単なプログラミングのテストで、ダメな応募者をふるい落とすことができます。

具体例をあげましょう。2012年7月現在だと、「再帰」とか「コレクション・ライブラリの適切な利用*3」とかを使えば、独学をやっていて、しかも、内容を理解しているかを判断できます。レベルが低すぎて嘘だと思うかもしれませんけど、ベトナムだと、本当にこの程度のテストでほとんどが落ちちゃうんですよ。

私がやった中で効率が良かったのは、再帰を使っていてバグがあるプログラムを修正させる方式でした。応募者に、以下のようなプログラムを見せます。

public class Factorial {
  public int calculate(int number) {  // number must be more than 0.
    if (number == 1) {
      return 1;
    }

    return calculate(--number) * number;
  }

  public static void main(String[] args) {
    System.out.println(new Factorial().calculate(5));  // It will show answer of 1 * 2 * 3 * 4 * 5.
  }
}

上のコードを見て、「return calculate(--number) * number;」の「--number」の部分がおかしい*4ことが分かれば、面接に進む。分からなければ、適当に時間を潰してお帰りいただく。レベルを少し下げてもよくて、採用にかけられるコストに余裕がある場合は、机上ではなく、コンピューターを貸して、実際にデバッグさせてもよいでしょう*5。

こんな感じのプログラミングのテストで、ダメな応募者のふるい落としができます。たぶん、応募者の数を1/10から1/100くらいに減らせるでしょう。問題の流出に対応するために、定期的に問題を変更すればパーフェクト。レベルが低い問題でよいのですから、問題の変更は容易でしょう。

面接で、何らかの技術の説明をさせましょう

ダメな応募者をふるい落とした後の面接では、自分が好きな技術の説明をさせるのがよいと考えます。うまく説明できるかどうかではなく、「その技術をよいと考えている理由」の内容で採用/不採用を決めます。

以下、その詳細です……が、まずはごめんなさい。以下は、ベトナムという特殊事情はあまり入っていません。だって、面接から先は、日本の場合とあまり変わらないですからね。あと、かなり個人的意見が入っています。こいつが一緒に仕事をしたいと思うタイプのプログラマーはこんな感じで、このように集めているんだな、とでもお考えください。

さて、マンホールの蓋が丸い理由について聞いても、バスに人が何人入れるかを聞いても、富士山を移動させる方法について聞いても構わないのですけど、私は、技術者同士なのだから、技術について語り合うのが一番良いと考えています。

その際に気を付けるべきは、知識量を争わないことです。私のようなヲタクは知識量を誇ってしまいがちで、そして知識量勝負はとても楽しいのですけれど、それだと技術を聞きかじっただけの実際には手が動かない人を採用してしまう危険性があります。だからやはり、応用が可能なレベルまで理解しているかを確認すべきだと考えます。

私は、応募者に好きな技術を選択させ、その技術が優れていると思う理由を説明させることで、技術を理解しているかどうかを判断できると考えています。昔、これは日本での話なのですけれど、Visual Basic 6.0からVisual Basic.NETに書き換えるプロジェクトで、「VB6のプログラムをVB.NETで書き換えるべき理由」を「AndAlsoとOrElseがあるため」から語り出した応募者がいました。彼は実に良かった。これらの言語要素がある場合はパフォーマンスはもちろん、コードが綺麗になるということを説明しだして、話が飛んでVB6の良いところと悪いところ、C#が人気だがVB.NETでも変わらないと思うということ、C#はたしかに文法が優れているけれどIDispatchはVBの方が楽*6なこと。これらを、コードを書きながら主張してきました。説明は下手でしたし、彼が出した結論には同意できない部分もありましたけど、もちろん、即採用です。

逆の不採用になる場合は、以下のようなケースです。「Javaが好きです」「その理由は？」「Write once, run everywhereなところが」「えっと、続きは？」「はい？Write once, run everywhereなところですけど……」「もう少し詳しく話すか、2番目に好きな他の点をあげてくれませんか？」「Write once, run everywhereというのは、一度書けばどこでも動くということです」「そうですか……」

初級の教科書に書いてあるだけの話を、繰り返して聞いている暇なんかねーんだよ！Wreite once, run everywhereな他の言語と比べて優れている点、たとえば、JVM（Java Virtual Machine）のパフォーマンスがいかに優れているか*7とかを説明して欲しい。Write once, run everywhereを安価に実現できている理由、たとえば、JVMをコンパクトに作れる理由*8等を説明して欲しい。

上であげた例は意味がない議論だと感じるかもしれませんけど、自分が好きな技術についてなのですから、意味がないような部分まで理解していて当たり前ですよね。

で？

以上でめでたく採用した後は、ひたすら仕事をさせましょう。給料の分を超えて働け！そうしてくれないと、日本人というだけで偉そうにしていて実際には働いていない駐在員の私の給料が出ないんだから……。

と、思ったのですけど、優秀な人を集めて、さて、いったいどんな仕事をさせましょうか？

ビジネス・アプリケーション開発のウォーター・フォールの下っ端……は、優秀なプログラマーにやらせるべき仕事ではないでしょう。工夫する余地が少ないので、繰り返してやっていると、せっかく選別した優秀なプログラマーがだんだん馬鹿になってしまいます。なにより、楽しくないし。

というわけで、せっかく優秀なプログラマーを集めたのですから、ビジネス・アプリケーション開発をアジャイルで……やるのは、日本でも流行っていないのにねぇいったいどうやって？この前読んだIPAの報告書では、アメリカやイギリスではすでに主流、デンマークやブラジルでは普及が進んでいると書いてあったのですけど、日本ではまだまだ（IPAの報告書では、日本と中国で普及が進んでいないと書いてあった）ですよね。プログラマーの一人としてとても悲しいけど、それが現実ならばしょうがない。

そうだ、プロダクトの開発ならば、アジャイルが適用できそう。ソーシャル・ゲームの会社がベトナムに子会社を作っていましたけれど、あれはうまく行くかもしれない（実情は全く分からないけど）。SIerではない企業が情報子会社をベトナムに作る場合も、アジャイルできそう。システム開発をSIerに発注せざるを得ないのは技術力不足という問題が理由だと思うのですけど、ベトナムに優秀なプログラマー*9を確保できるのであれば、この問題を解決できます。基幹システムは企業の競争優位性に直結しているわけで、その基幹システムを内製化できるのですから、あれ、かなり良いかもしれません（勢いで書いただけであまり考えていないので、大きな落とし穴があるかもしれないけど）。

あれ、SIerに務めている現在の自分自身を否定しちゃった……。

ともあれ、選別さえきちんとやれば、ベトナムのプログラマーは素晴らしいですよ、本当に。

*1:C言語とLispとSmalltalkを完璧にマスターした人は、他のどんな言語でもすぐに使いこなせると思う。

*2:これは、日進月歩のコンピューター業界での必須能力でもあるでしょう。

*3:.NET FrameworkのLINQの、クエリ式ではない方の活用とか。

*4:これだと、先に--されるので「1 * 2 * 3 * 4」になっちゃう。だからreturn calculate(number - 1) * number;が正解。return number * calculate(--number)でも動作はするけど、再帰の際に呼び出し側の状態が変わるというのは危険なので避けるべき。

*5:模範解答を暗記しただけの場合があるので、実際にデバッグできるかどうかを確認するのはとても有効です。

*6:当時の話。今はC#でも楽。

*7:「仮想マシンを使えばどこでも動くのは当たり前で、SmalltalkなんかOS全体と呼べるようなレベルまで仮想マシンが対応している。JVMの特筆すべきは、そのパフォーマンスである。JITコンパイラは……」とか話して欲しい。

*8:「JVMはレジスタ型ではなくて、スタック型だ。その結果として、コマンドが少なくて済んでいて……」とか話して欲しい。

*9:私は、開発作業の全てに対応できる人という意味で、プログラマーという言葉を使用しています。SEという、日本にしか存在しない職種は絶対に認めません。