Hatena::ブログ(Diary)

Tous Les Jours 攻防記 RSSフィード

2013-05-08

弊社エンジニア職の求人に、日本から一向に応募が無い件

22:05 | 弊社エンジニア職の求人に、日本から一向に応募が無い件を含むブックマーク

先日、弊社CareerLink Vietnamにて、エンジニア職の新規求人を始めました。勤務地はベトナムホーチミン市

東南アジア各国を飛び回るウェブ系エンジニアWanted!!

[5/9 03:10 追記] WantedlyのURLが古く応募ができなかったようです。新URLに置き換えました。


日本人にターゲットを絞り、満を持してWantedlyに掲載したのだけれど、応募がない。

個人的には、南国ベトナムで開発に従事するというのは、なかなか魅力的な労働環境だと思うのだけれど、どういうわけか、日本から一向に応募がない。

なぜ応募が振るわないのか、理由を考えてみたが、労働環境に魅力が無いわけではないと思う。ただ、いきなり東南アジア勤務というのが若干ハードルが高く感じられるのかもしれない。

そこで、気を取り直して、現地ベトナムの雰囲気が伝わるよう、採用に関する補足事項等を、本エントリにまとめてみることにする。

CareerLink Vietnamについて

f:id:kazuk_i:20130508235237p:image:w240

ベトナム国内向けジョブサイト www.careerlink.vn を開発・運営している。


会社規模はどれくらいか

社員数は数十人程度、創業者CEOは日本人。また、日本人の営業担当の方が複数人働いている。他は皆、ベトナム人スタッフ。なお唯一のエンジニアであるところの僕(CTO)も日本人。創業は2006年だけれども、Webに力を入れ始めたのは今年に入ってからなので、技術人材面ではどベンチャーである。

f:id:kazuk_i:20121123170909j:image:w300

スタッフの皆さん

なぜ日本人エンジニアを採用するのか

今回、求人のターゲットを日本人に絞った理由は2つあって、

1)やっぱり日本人エンジニアは優秀だなあと感じるから。実は今回の採用活動に至る前に、ローカルでベトナム人エンジニアの募集をしていたのだけれども、弊社の要件を満たす応募が皆無だった。皆、レジュメを盛り過ぎである。。 またWeb系エンジニアであるからには、単に言われた通りの実装をコーディングするのではなく、ぜひプロダクトの使い勝手を積極的に改善していってほしいところだけれども、そういうマインド(やセンス)を持っている人は、ここでは本当に少ない。

2)CEOCTOが日本人だから

英語でのコミュニケーションは色々と苦労があるので。。

これまでは、僕の個人的なつてをたどって、日本在住のWeb系エンジニアの方々にお願いして、受託扱いで手伝いに来てもらったりしていたのだけれど、どうもそれでは開発が追いつかなくなってしまった。今、弊社でやりたいことを実現するには開発力が全く足りておらず、目下新規採用が至上命題ベトナム人ではなく是非日本人のエンジニアにJOINして頂きたいと考えている。

想定している応募者像

新しくJOINして頂く方には、まず弊社のフロントエンドサイト(www.careerlink.vn)の拡張・改良に従事していただくことになると思う。現在、弊社フロントエンドはSymfony2フレームワークを用いて構築されている。Symfony2を触った経験があればいいけれども、Symfony2の経験がなくても、他のMVCフレームワークを扱った経験があればスムーズに着手できると思う。またSymfony2は、Eric Evans氏が提唱するDDD(ドメイン駆動設計)の考え方が色濃く反映されたフレームワークであり、開発者にはDDDに関する予備知識があることが望ましい。


ワークパーミット(労働ビザ)について

会社にて準備。


ホーチミン市での暮らしぶりについて

食事について

1)日本食

市内に日本食レストランは充実している。「なんちゃって日本食」ではなく、どれも日本人経営の、れっきとした和食である。ホーチミン市ラーメン激戦区でもある。

f:id:kazuk_i:20130428202046j:image:w360

Lê Thánh Tông通りの日本人街にあるラーメン屋「大ちゃん

2)ローカル料理

日本食のリーズナブル感と比べると、コスパが低いように感じる。衛生面に関して言えば、僕は胃腸が弱いほうだけれども、ローカル料理を食べたことで特に問題が起きたことはない。

3)その他外食

旧仏植民地のせいか、パンはとても美味しい。自分は朝ごはんに最寄りの「Tous Les Jours」という韓国系パン屋さんでクロワッサンを食べることが多い。この店のクロワッサンとデニッシュチョコパイはとても美味い。ただ店内にヤモリが多く生息していて(ベトナムでは一般的)、天井にへばりついたヤモリが希にウンチを落とす

4)自炊について

自分は自炊をしないので、スーパーマーケットや市場等の事情はよくわからない。スーパーマーケットはあちこちにできているけれど、日本ほど多くはない印象。バイクがないと買いだしは難しいかもしれない。

家賃について

日本と比べると安いが、物価水準を考えるとかなり高い。市内は人口密度が高く、不動産は大変貴重なリソース。外国人向けワンルームのアパートであれば200USD-250USDくらいで借りることができる。奮発して500USDくらい出すと広くておしゃれな部屋になると思う。なお外国人が借りるようなアパートは、基本的にルームクリーニング・ランドリーサービス付きである。

治安について

治安は基本的に良い。軽犯罪(ひったくりなど)は多いが、注意することで被害を防げる。スマホのひったくりには特に気をつけたほうがいいと思う。凶悪犯罪は殆ど無く、真夜中に女の子が一人でATMからお金を下ろしていたりする。

気候について

11月〜4月頃までが乾季、5月〜10月ごろまでが雨季。雨季といってもずっと雨が降っているわけではなく、一日に10分ほど激しくスコールが降る。

f:id:kazuk_i:20130508234254j:image:w240

突然のスコールで道路が川になる


現地での交通手段について

運転免許を取得して、バイクに乗ると行動範囲が広がり、ベトナムを満喫できる。自分も免許を取ってバイクを購入した。免許を取得するのはさほど難しくないが、バイクに乗っている日本人の半数はなんと無免許である(免許を取得するのが面倒くさいみたい)。

ベトナムでバイクに乗っていると言うと、多くの外国人から「クレイジーだ」といわれる。事実、バイクの接触事故は非常に多い。ただ、市内では速度域が低いため、命に関わるような重大事故は少ない。ちゃんとしたヘルメットをかぶろう。真っ当な会社の駐在員は、大抵社則でバイクの運転が禁止されている。タクシーなどの交通手段も安く使えるので、バイクがなくても困ることはない。

f:id:kazuk_i:20130508232802j:image:w360

朝の通勤ラッシュ


医療等について

日本語が通じる医療機関が複数あり、大抵のことは市内で事足りる。万が一、ホーチミンで手の施しようがない事態になった場合、バンコクもしくはシンガポールにヘリ移送される。なお、会社支給の邦人向け海外医療保険があり、ヘリ移送と相成っても移送費は保険でカバーされる。

f:id:kazuk_i:20130508233305j:image:w240

市中心部サイゴン大聖堂近くの公園地帯。日本人御用達の病院が公園の隣に二件ある


日本人コミュニティについて

自分はそういう場に顔を出さないのでよく分からないが、日系フリーペーパーなどを見ていると、日本人同好会(フットサルとかソフトボールとか)のメンバー募集広告は多く掲載されている。日本人経営のバーやカフェなどもあるので、そういったお店が交流の場になっているのかもしれない...



その他

求人情報や環境の補足は以上なのだけれども、ついでなのでベトナム、というか新興国Webサービス開発をするということについて、常日頃見聞きしていること・感じていることなど書いてみたい。

現地で一般的な開発言語について

ベトナムIT開発系オフショアの一大拠点であり、当然ながら.Net, Java あとはとにかくPHP。去年Matzホーチミン自然科学大学でRuby講演をした辺りから、RubyRailsの経験を問う求人が増えてきたイメージがある。他、Drupal等のCMSカスタマイズを問う求人案件がよく目に付く。

現地Web系企業で一般的な開発スタイル

CDD - コピペ駆動開発(あっこれは万国共通かな..)

技術トレンドについて

キャッチアップは先進国の1年遅れくらいかな? 今では mongodb, redis, cassandra, neo4j (←何に使っているんだろう)などの経験を問う求人も、ちらほらと見かけるようになってきた。 ストリームデータ処理とかはまだ見かけない。

マカー

極めて低い。理由は、

  • ハードウェアが非常に高価(日本で買うよりずっと高い)
  • OSがタダではない。WindowsだとPCを買えばタダで付いてくる(えっ)

あたりだと思われ。(ちなみに僕は日本で買ってきたMBA2012を使っている)

スマホタブレットソリューションの重要性について

カフェに入ってiPhoneもしくはiPadをいじっているのがこっちではステータス。うちも早くiOSアプリを出さねば。

f:id:kazuk_i:20130508233851j:image:w240

カウンターでこれみよがしにiPhoneをいじる


情報保全コストについて

ソースコードリポジトリカジュアルにコピーし、競合他社に売りさばくエンジニアが多いので、なかなか気が抜けない。

賃金水準の違いが可能にすることについて

ここベトナムでは、4年制大学を卒業した新卒ベトナム人エンジニアで、初任給は200-300USD程度。非エンジニアのオフィスワーカーだともう少し低いと思う。

弊社社内では、顧客ユーザが入力したデータを社内オペレータが人海戦術で電話連絡、修正・加工していたり、メタデータを追加していたりするが、これは先進国では成立し得ないのではないかと思う。

外国資本同士の殴りあいについて

海外サービスを無理やり締め出して、広大な国内市場をローカルサービスプロバイダに独占させる大陸中国などと異なり、ベトナムは幸か不幸か、強力な外資系プロダクトが国内市場を蹂躙している。結果、国内IT産業が脆弱なままにある。従って、この国でWebサービスを展開する場合、競合他社は必然的に外国資本であることが多く、しかも多くの場合ベトナム以外のASEAN各国にも事業展開している多国籍企業を相手にすることになる。そういった競合と互角に渡り合うには、我々もベトナムからASEAN各国に出て行き、規模を追求しなければならない。世界規模で寡占化が進む中で、今がラストチャンスかもしれない。


このエントリを読んで、もしベトナムホーチミン市での開発業務に興味を持ってくれた方がいれば、是非連絡してください。直接Wantedlyで応募するもよし、疑問、質問があればメール(: kazki.matz@gmail.com)もしくはTwitter(: @KazkiMatz)に問い合わせるもよし。もちろん「まずは話を聞きにいきたい」も大歓迎。成田から飛行機で6時間、ホーチミンでお待ちしています。


[追記] 5/8 23:10

所用で、5月8日〜16日の間、関西地方にいます。関西圏の方で「話を聞きたい」という方がいらっしゃれば、直接お会いすることもできます。@KazkiMatzにメンション投げてください。

f:id:kazuk_i:20130508233611j:image:w240

近所の旅行代理店にて。どういうわけかベトナムの猫はみんな痩せている

ssig33ssig33 2013/05/09 00:51 給与レンジどんなもんなんですか?

さあこいさあこい 2013/05/09 01:18 年収は300万円でしょうか?それとも300万ドンですか?

さあこいさあこい 2013/05/09 01:18 年収は300万円でしょうか?それとも300万ドンですか?

kazuk_ikazuk_i 2013/05/09 01:53 > ssig33 さん
こちらで想定しているスキルを持たれている方の場合で、
総支給額2000USD-3000USD のレンジを考えています。
スゴ腕の方は応相談、です。

> さあこい さん
年収、億いっちゃいますよ(※VND建て)

333333 2013/05/09 02:06 この記事ではベトナムの魅力がさっぱり見えない.
オマケに親の世代ならベトナム戦争覚えてるから反対されるだろうし.

kazuk_ikazuk_i 2013/05/09 02:10 >333さん
いやぁ、ベトナムの魅力が伝われば、と思って書いたんですけどねぇ。新興国だし、人によって得意苦手がわかれそうですね。

興味あるが興味あるが 2013/05/09 03:24 総支給額2000USD-3000USDは、月ですよね?
日本より月収が下がって、生活環境も悪くなる可能性が高いので、応募が少ないのでは?

PeyaPeya 2013/05/09 03:25 ベトナム、ひいては貴社で働くことの魅力をもっと強調されてはいかがでしょうか?
エントリを読んで、ベトナムの環境が思っていた程悪くないことはわかりましたが
だからといって、ベトナムで働いてみようとまでは思いませんでした。

kazuk_ikazuk_i 2013/05/09 03:52 > 興味あるが さん

ええ、2,000USD-3,000USDというのは月額です。

そうですねぇ。思うに、新興国で仕事をすることを「苦役」だと考えられる方にとっては、当然、価格プレミアムがないと、ベトナムで生活なんてやってられないでしょうねぇ。
僕は今、月1000USDを下回る生活費で生きてますけど(部屋の家賃は270USDです)、ベトナムでの暮らし、気に入ってますけどね。むろん独り身だから可能ではあるのですが。。
あ、でも1000USD未満というものの、日本へ帰るチケット代なんかは別換算にしてるので、ちょっとフェアな比較じゃないかな。


> Peya さん
ベトナムで働くことの魅力、ですか。
ある種の人にとって、ストレスフリーな環境だと思いますよ、ここは。
バイクでホーチミンの街を流していても、交通マナーはめちゃくちゃ悪いし、一方通行を逆走するし、歩道を我が物顔でバイクが走るし、交通警察は賄賂とって違反者を無罪放免してるわけです。
でも、陰険な嫌がらせは目にしないですね。トラックの危険な幅寄せとか、過失者に執拗にクラクションを浴びせたりとか、そういう光景が無いんです。ホーチミンは飼い犬がとても多いんですが、こっちの犬は全然吠えないんですよ。人間の赤ちゃんも泣いたりぐずったりしてるところをほとんど見ないです。犬も赤ちゃんも町内ぐるみで可愛がられてるからじゃないかなって思ってます。
仕事関係ないですね。なんの話や。

kazuk_ikazuk_i 2013/05/09 03:59 脱線ついでに。
ゴキ、ネズミ、ヤモリが苦手な人にとっても、ベトナム生活はきついかもしれない。
ホーチミン市内には大量のゴキブリ、ヤモリ、馬鹿でかいネズミがいます。
僕の場合、昔はゴキ大の苦手だったけど、今はもう慣れてしまったなー
たしか「ゴキが自分の体に触れたら幸せになる」っていうジンクスがローカルにあったはず。以前どこかで見かけたんだけれども、今ぐぐっても出て来なかった。

興味本意だが興味本意だが 2013/05/09 04:56 英語ベトナム語さっぱりなんですが大丈夫でしょうか?
日本の年金など福利厚生はどんな感じ?

1234512345 2013/05/09 06:12 バリバリ働ける時期に何で途上国でナマケモノなのか。12345

hogehoge 2013/05/09 09:00 妻と子供がいなくて住宅ローンが無くて、開発環境が応募環境に合致してたら応募したかも?

KoshianXKoshianX 2013/05/09 09:13 なかなか手厳しいコメントが多くてたいへんそうですね。ホーチミンには何度かいったことがあり、たいへん好きな街です。ブンチャとバインミーとカフェスァダーが大好物です。
ベトナムの魅力もいいですが、海外でしか経験できないキャリアについてもお書きになられたらいかがでしょうか。ベトナム人だけじゃなく日本人以外はたいていそうだとおもいますが、英語で具体的に言わないと動いてくれない人たちをマネジメントする機会なんてなかなか国内ではもてないでしょう。マネジメント力が日本では考えられないほどあがるはずです。
また英語ベトナム語の語学学校の存在や価格、会社として補助がどれほどでるのかなどの情報もあるといいのではないでしょうか。

バンコクやクアラルンプールまで飛行機で1時間ほど乗ってしまえば、日本で手に入るもので手にはいらないものはほぼ無くなるというのも東南アジアの魅力の一つですよね。

よい人から応募があることを祈ってます♪

yaseiyasei 2013/05/09 09:21 首都のせいか家賃が思ったよりもやたら高く感じます。
500アメリカドルだと日本の地方都市なら1軒屋を借りられますよ…

yaseiyasei 2013/05/09 09:24 あ、ホーチミンは首都じゃなくて最大都市でしたね

ハンサムハンサム 2013/05/09 09:34 1990年代後半(香港が中国に返還された頃)にホーチミンに遊びに行きました。当時は女性誌でもホーチミン特集ばかりしていて、ブームが過熱していましたね。凄く良い街です。ホットです。住みたいです。アジアの文化が好きで熱病のように香港に何度も足を運んでいる人が、香港の次に選ぶハードコアな土地だと思います。あえて順位を付けるなら、住みたい街ベスト3は、1位がホーチミン、2位が香港、3位がハワイ、でしょうか。

ぽにょぽにょ 2013/05/09 10:29 職場環境のことが数行程度で現地の生活が大半ってブラックにありがちですよね?
福利厚生もよくわからんし、人がこない=地雷ですって言ってるようなもの。
金だしゃエンジニアくるみたいな見方、はっきりいって胸くそ悪いです。
人を引き付けるものがまったく感じられない。御社がどんなのかは読んでわかった。
そりゃ優秀なエンジニアはスルーするわw

ぽにょぽにょ 2013/05/09 10:40 言いたいことがズレてしまったぽいのでまとめると、
・開発すんの日本でもよくね、なんで現地なの? = 人件費安くできる = それって会社の都合のいいことで、エンジニアのメリットはないよね?説明できるの?
・トラブったとき回りに頼れる人いなくて孤立するよね。そもそも日本でもよくあるのに現地にいくとか遠征かよ…。技術の習得なら日本でもできるわw
・よーわからんけど、使いやすいように改良かさねてくれって仕様書段階でぐらぐら揺らいでる案件でしょ。そんなとこ会社として信用できんわ。

みたいな見方のエンジニアが大半だと思われますけど。

菅野菅野 2013/05/09 11:56 この人の経歴見れば分かるけどなに一つまともに続いてない。
大連しかり日本に適合できない人の固まりが東南アジアにはあるのか?だとしたら危ないなわ。
しかしこの人税金使って未踏で開発してたみたいだけど、何の成果も無しでこんなことしていいの?

ロレックス レディースロレックス レディース 2013/05/09 12:15 当社の成長、ひいては事業の発展を支えるスタッフ達です。年々個性化し、また多様化する人々のライフスタイル、この様な時代で、当社は常にユーザーのウォンツを大切に新鮮で、高品質なものを提供しています。多くの情報や知識と思い入れ、そして、人と人のコミュニケーションから生まれる商品を検討し、オンラインショップで掲載します。当店でオメガ、ロレックス、エベルなど海外有名なブランドは豊富に揃えています。長年以来、お客様のおかげで最も信頼できる会社を目指しています。多くのお客様のご愛顧に応えるために、エドックス時計、オメガ時計など売れ筋商品は最安値に挑戦しています。ロレックスレディースやメンズのモデルは様々です。セレブ達の愛用しているアイテムの贅沢屋として、全ての商品は高いクオリティーがあります。魅力的なデザインは特徴です。エドックス時計やオメガ時計など大ヒット商品についてお問い合わせいただきます。よろしくお願い申し上げます。
■HP:http://www.taowatchesrk.com/
■店長:小野
■連絡先:sales@taowatchesrk.com

エンジニアってエンジニアって 2013/05/09 13:49 エンジニアが何にワクワクし魅力を感じるか、どう考えてるのかが分かってない気がします。以前ベトナムのオフショアに参加しベトナムは超楽しかったですが、御社に入りたいとは思わないですね。

ニートエンジニアニートエンジニア 2013/05/09 14:55 他の人も書いてるけど、ここで働くとこんないいコトがあるよ!という部分が伝わってこない。それでいて、給与も大したコトないでは、誰も応募しないでしょ。

kazuk_ikazuk_i 2013/05/09 15:31 > 興味本位だが さん
業務で使うのはほぼ日本語なので、英語、ベトナム語はとりあえずは必要ないです。
ですが、今後ベトナム人エンジニアも入ってくることになると思うので、ドキュメント類は英語で統一することにしてまして、
簡単な英語の読み書きができるとよろしいかと思います。

ここベトナムにも公的年金制度があって、給与から天引されるようです。ですが、この先何十年もベトナムでくらさない限り支給資格を満たさないので、我々外国人にとっては関係ない話になりそうですねぇ。
最近、ベトナムの人口動態と年金運用・財源のバランスが全くとれておらず、制度破綻は不可避、みたいな報道を見かけましたよ。何十年も払いつづけても戻ってこないかもね。

> 12345 さん
まぁ、確かにこちらでは全体的にぬる〜い空気が漂っていることは事実ですねぇ。昼からカフェでRPGやってるサボリーマンとか、ビリヤードしてるオジサンとか、たくさんいます。僕も自分のペースを作るのに苦労してます。

kazuk_ikazuk_i 2013/05/09 15:38 > KoshitanX さん
応援ありがとうございます。 バインミー美味しいですよね :) 僕も夕食をバインミー一つで済ませることもよくあります。

僕は、エンジニアは自分で実装してなんぼだと思っているのと、
ベトナム人のマネジメントで神経すり減らして欲しくはないという思いがあるのですが、
もし新しい方がそういった領域にも興味をおもちなら、積極的にお任せしていきたいですねぇ。
カジュアルに顧客データを抜いて競合他社に売ってしまうような人たちを、どう束ねて、チームとしてアウトプットを出していくのか、
というのは、相当キツく、でも貴重な経験になるのではないかと思います。

流星群流星群 2013/05/09 15:47 求人広告業界の経験者です。
僭越ながら申し上げますと、こっちのブログの方がWANTEDLYの求人広告
よりも効果が見込めると思います。


≪ブログの方が機能していると思う理由≫

・転職者へ求めている要件が分かる。
 →WANTEDLYでも書いてあるものの、こちらのブログの方が正確です。誇張表現もなさそう?な印象を
  覚えました。運営サイトの安心感もブログでの方が持てました。

  可能であれば、「すぐに任せたい仕事」「半年後に任せたい仕事」「2年後あたりに任せたい仕事」
  などのガイドポストがあれば安心するかと。

・入社後にする仕事が何かが分かる。
 →上記と理由は同じです。
 
・現地での生活への払しょくをしている。
 →現地での実生活は初めてだと思いますので、可能な限り記載していただけると助かるかと。


≪WANTEDLYで応募をためらう理由≫

・転職者へ求めているレベルがあいまい。
 →上昇志向が高過ぎて、腰が引ける
  特に「ただし、現状に満足することなく、自分のスキルも自分自身で高めていく〜」のあたり。

・現地での生活に対する不安払しょくがない。
 →転職者にとって、ベトナムで腰を据えて生活するのは初。ただし何もエクスキューズがないので、
  縁のある方からしか応募が来ないのでは。



求人広告は、「人生を変える広告だから、生活できるイメージが湧いてもらえるかが大切」と
教わりました。ブログの方がそれが出来ているかと。偉そうなこと言ってすいません。

kazuk_ikazuk_i 2013/05/09 15:55 > yasei さん
不動産はここベトナムではとても希少なリソースですね。一般的な中流ベトナム家庭だと、10畳くらいの部屋に一家4人で暮らしているようなケースも珍しくないです。個室を借りれるのは羽振りの良い人(キャバ嬢とか)か外国人くらいじゃないですかね。

> ハンサム さん
90年代だと、また今とは大分違った風景なんでしょうねぇ。最近はホーチミン市内にも高層ビルがたくさん建ってしまって、昔の面影は薄れてしまったかもしれませんねぇ。

> ぽにょ さん、菅野 さん、
東南アジアの地位、本邦では思ったより低いみたいですねぇ。。

> エンジニアって さん
弊社のプロダクトはオンラインジョブサイトですからねぇ。業界的に新規性がうすいことは否めないかもしれません。でも、やりたいこと(そしてまだ競合他社が手を付けていないこと)はたくさんあるんですよ(ヒント: Gunosy Career)。そして国内ネットユーザはますます増加しつつあり、成長余地も大きいです。日本と違って労働流動性が非常に高く、転職ネタをオープンに語り合う風土も、業界の成長余地を広げていると思ってます。

kazuk_ikazuk_i 2013/05/09 15:59 > 流星群 さん
ご意見ありがとうございます。Wantedlyは確かに、色々と機能的な制約もあって、書きたいことを書ききれないようなところがあったと思っています。ブログ記事評価いただいて嬉しいです。参考にさせていただきますね。

WISCWISC 2013/05/10 01:22 こんにちは。
海外で働らくと言うことは英語も必要になってくると言うことでしょうか?ほかの方もトラックバックされてますがそうするとやはり給料レンジがかなり低い気がします。450−600万のレンジだとある程度来るのではないでしょうか。逆に英語を話さないエンジニアとなるとかなり海外に興味ないような気がします。

ところでベトナムって結構かわいい女の子いますよね。後5年若くて上の給料レンジなら自分はいきたいです。

kazuk_ikazuk_i 2013/05/10 02:19 > WISC さん

弊社の開発業務では今のところは英語は必要ないです。ただ社内ドキュメントを英語化しているので、簡単な読み書きはできたほうがよろしいかと思います。

いやはや、皆さんの反応を見ていると、異口同音におっしゃるのは、給与水準が低いんじゃないの、という点ですねぇ。
ベトナム *なんか* に行ってやるのだから最低でも日本以上は必要に決まっているだろうが、と言われてしまうと、ベトナム生活をそこはかとなく気に入ってる僕などは、中々ショックですよ.. むろん東南アジアの気候風土が人を選ぶのはよく分かるのですが。

かわいい女の子多いですね。それで人生狂っちゃった日本人も、こっちには多いです(笑)

TKMYTKMY 2013/05/10 02:40 うーん、私は給与が低いとは思わないですねえ。日本の会社のベトナムブランチで、日本採用→駐在員ってことなら話は別ですが、要は在ベトナムの外資(と言うか、外人が現地で設立した会社)の現地採用ですよね。十分なように思えるんですけど…。他の外資の現採のレンジはどんな感じなんでしょうか? 例えばフランス資本とかヨーロッパ系が多いような印象がありますが、そこに飛び込んでくるフランス人のレンジとか。

kazuk_ikazuk_i 2013/05/10 03:10 > TKMY さん

皆さんの反応を見ていると「日本から人を引っ張りたいと考えているからには、それ相応の(日本以上の?)賃金を約束するのが筋ではないか」と考えられる方が多いようですねぇ。
ヨーロッパ系についてですが、事例を沢山見たわけではないのですが、800USD - 2000USDあたりが現地採用デベロッパーのレンジかな、と思っています。
ただ、労働ビザを持つことができない(経歴的に発給できない)人だと、もっと安い賃金でモグリで働いていたりするようですねぇ。それこそフランスで就職すれば?とアドバイスしたくなるんですが、ベトナム人の女の子に惚れ込んで結婚してしまった、など、止むに止まれぬ背景事情があるようで。。

tatatata 2013/05/10 09:39 ハノイ在住です。
応募はしたくない(っていうかさっさと日本に帰りたい・・・)ですが、色々つっこみたくなってw
日本人のバイクが無免許っていう記述がありますが50cc以下のバイクなんじゃないですか?
50cc以下は免許いりませんよ。
あと税金についても書いたほうがいいんじゃないかなーと思った。
#毎月税金高くてひーひーいってますよ・・・(現地採用の給与帯ならそうでもないだろうけど)
あと苦労するのはベトナム人に対して仕事を振ること。
・彼らは話を聞いているようで聞いていない。
・話しを聞いていても勝手な解釈でやり方を変える。
・それで間違いが起こっても非を認めない。
結果10指示して1できるのがやっとという・・・
(このあたりの話はベトナムに住んでる人のblogとか見るとだいたい意見一致していると思う)

kazuk_ikazuk_i 2013/05/10 12:23 > tata さん
110ccのHonda Wave とか、スクータ(50cc超)とかに乗ってるみたいですよ。50cc未満で探そうと思ったら、中国製コピーカブ?くらいしか無いんじゃないですかね。
所得税も高いですね。今度法人税が下がるようですが、個人所得税も下げて欲しいところですねぇ。。

dora-koudora-kou 2013/05/10 21:23 自分自身も会社を経営する立場なので、自分はお力にはなれそうにないのですが、
個人的には遊びに行ってみたいなと思ってるぐらいなのですw

はてブのコメントにも書いたのですが、いきなり労働ビザ取ってフルタイムでガリガリ働くというよりかは、2週間以内で住む・食うを会社側で負担するという条件(給与払うと観光ビザ的に問題ですし)でのカジュアルな体験であればもうちょっと興味をもつ人も増えると思ったのですよ。

結局のところ、実際に住んで軽くでも仕事をしてみない限りにはベトナムで実際に仕事をするイメージは普通に日本で仕事をする人には浮かばないでしょうし、逆に2週間体験してみたら、案外ホーチミンが快適だったという人も現れるかもしれません。

これは最終的には本人の適応力の問題ですし、案外自分自身も気がついてなかったりしますから、間口を広く設けるほうが応募にも繋がるのかなという印象を持ちました。

ある意味自分も似た悩みを抱えているので、コメントさせて頂きました。
ご参考になれば幸いです。

kazuk_ikazuk_i 2013/05/11 00:15 > dora-kou さん

ありがとうございます。間口を広げて、インターン的な立ち位置で一度ベトナムを体験してもらうというのもありですね。参考にさせていただきますね。
>案外自分自身も気がついてなかったり
これは本当にそう思います。僕自身もそうだった気がします。

nanashi3nanashi3 2013/06/10 01:22 毎日仕事以外にも刺激や発見があって面白そう!
自分がエンジニアだったら、きっと応募してました。
こんな働き方がもっともっと増えればいいのになー。応援してます。

regepanregepan 2013/10/03 11:26 こちらはもう募集してないのでしょうか?

kazuk_ikazuk_i 2013/10/03 15:32 > regepan さん
まだ定員に達していませんので、引き続き募集中です〜

2013-05-07 「fluentd」と「Storm」の比較について このエントリーを含むブックマーク

まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。

筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。

基本情報

fluentd

http://fluentd.org/

今をときめくログコレクター/イベントアグリゲーターRubyで実装されているが軽量高速。

RPC基盤ではなく、その下のレイヤーに位置するプロダクト。


Storm

http://storm-project.net/

分散RPC基盤。ストリームデータ版MapReduceフレームワークJava+Clojureで実装されている。

概要については、下記のスライドがとてもわかりやすかった。

Twitterのリアルタイム分散処理システム「Storm」入門


ストリームデータ処理で何をするのかについて

ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。

典型的なWebアプリケーションアーキテクチャ、すなわちアプリケーションサーバプロセスがステートレスであり、データの永続化はDBのみが担うタイプのソフトウェアに、上手くおさまってくれないタイプの処理がある。具体的には、

  • リアルタイムランキング
  • リアルタイムトレンド分析
  • リアルタイム不正監視

といったもの。

「ランキング?Redisでいいじゃない」Redisお手軽でいいですね。ただ「直近の60分間を対象にしたユニークアクセスランキング」みたいなことをしようとすると、Redisでは難しいかもしれない (時間窓を徐々にずらしていく必要があるし...)

(=> こんなfluentdプラグインを書いた: http://d.hatena.ne.jp/kazuk_i/20130506)

トレンド分析」これはTwitterの"Worldwide Trends"機能みたいなもので、今一番ホットなハッシュタグをリアルタイムで教えてくれたりするもの。まぁ、これもRedisで事足りる... ただしトレンドを判定するアルゴリズムが、Redisが持つデータ構造で表現できるほどに、十分単純である必要がありそう(単位時間あたりのヒット数でソートした上位アイテム、とか)。

「不正監視」たとえばパスワードのbrute force アタックを防ぎたいとか、botによるサイトクロールを一定の制限を設けて遮断したいなど。過去ののアクセスパターンと直近のアクセスを組み合わせて総合的に判断する必要あり。これはRedisとかではちょっと難しそう。

つまり、状態変化が過去の入力の複雑な重ね合わせとして導かれるようなモデルは、RDBMSや各種KVS、Redisなどに載せるのが難しい。無理に載せると、アップデートのたびに大量のREADクエリを走らせることになってしまい、現実的なパフォーマンスが出ない。

ではどうするか。必要なデータをアプリケーションプロセス内部に、インメモリで保持する。

これと親和性が高そうなのが、ストリームデータ処理であり、イベントドリブンなアーキテクチャであり、そのためのプラットフォームとして世に登場したのが、例えばApache S4であったり、Twitter Stormであったりするわけで、中でもStormが一番モテている印象がある。

ストリームデータを逐次処理するという手法は、金融系のシステム等では随分前からお馴染みのアプローチだったらしい(不正監視とか)。Web業界では、ここ3−4年でマンモスサイト(TwitterとかFacebookとか)への導入が進み、そして、ここ1−2年で、そういったプロダクト(Stormとか)がオープンソース化されて、我々も気軽に使えるようになった。


Stormのスゴイところ

ある種の(大多数の?)処理が、MapReduceでほぼ無尽蔵にスケールアウトするようになったのと同様に、StormでもSpout+Boltを組み合わせることで、ある種のストリームデータ処理をどこまでもスケールさせることができる。Twitter規模のトラフィックで、トレンドハッシュタグのランキングをリアルタイムに算出するなんて用途にうってつけ。

Stormの欠点

MapReduceはどこまでもスケールする代わりに、計算効率を犠牲にしている面がある。よくある単語数をカウントするサンプルなんかは、やってる処理内容に比べて、そのオーバヘッドが極端に大きい例だと思う(まぁ実際にはネットワークやディスクIOがボトルネックなのであまり問題ではないのかもしれないけど)。同じ事がSpout+Boltモデルにも言える。

これは欠点というより、スケーラビリティを追求した結果であり必然。

fluentdのいいところ

fluentdはあくまで土管なので、Stormのように分散処理基盤を提供してくれるわけではない。しかしfluentdには入出力プラグインAPIが用意されているので、プラグインを書くことで、データフローに対して任意の処理を行うことができる。つまりその気になれば、fluentdに複雑なストリームデータ処理を載せてしまうことができる。

一方で、トランザクションやジョブトラッキング機能が必要である場合、すべて自前で実装することになる。

fluentdストリームに対し、アドホッククエリを登録して結果を得るというアイデアが存在した :

fluentd+Esperで動的ストリー ムクエリ

@angostura11さん作のEsper。これはスゴイ!


耐障害性について

これは、「高可用性」と「整合性」の2つに分けて考える必要があると思う。

高可用性について
Storm
高可用性はStormの最大の売りの一つ。Hadoop同様、MasterノードがWorkerにタスク(SpoutやBolt)を動的に割り振る。Workerに障害が発生した場合、タスクは別のWorkerに自動的に引き継がれる。
fluentd
稼働プラグインを動的にデプロイするような仕組みは用意されていない。高可用性を実現するには、同じ設定のWorkerを複数並べて、HA構成にする必要がある?
整合性について
Storm
上で見たように、ストリームデータ処理方式の最大のメリットが、アプリケーションプロセスがデータをインメモリに持たせられることであるとすると、『Stormを採用すれば耐障害性が担保されるので、整合性も保たれる』と考えるのは妥当なのか?例えばStormに標準で付いてくるワードカウントのサンプルプログラム、これの実装を見ると、累計カウント値は Workerスレッド内の、集計担当Boltが保持しているHashMapインスタンスに保存されている。つまり、何らかの障害が発生し、このインスタンスをホストするサーバが吹き飛んでしまえば、(以降の処理は他のWorkerが受け継いでくれるものの)当然新Boltからemitされる値はゼロにリセットされる。これを何とかするには、中間データ(上記例であれば、累計カウント値など)を、Redisのような外部DBにmemoizeしなければならない、、、がそれではパフォーマンスが出ないし、そもそもストリームデータとしてStormで処理する必然性が無い。。。
fluentd
上と同じ事がfluentdでも言える。加えて、fluentdではデータがWorkerで必ず処理されることの保証が無い。

上記のような整合性リスクに関する考え方が、ストリームデータ処理を最も特徴づけるのではないかという気がしている。


自分はどうするか

弊社(CareerLink Vietnam)は業務の性質上、アクセスパターンの可視化やユーザ不正行動監視が重要。ひと月ほど前から段階的に、各種処理をストリームデータ処理として実装しなおしている。

しかし、うちのインフラは規模がかなり小さく(サーバも6台しかないし)、ストリームデータ処理のために何台もノードを割り当てることはできない。Stormの強みが活かせる環境ではない。しばらくはStormを諦めて、fluentdでささやかにストリームデータ処理しようと思っている。なにせ、fluentdならRubyで書けるし。(これが一番大きい)

"fluentd as a Poor-man's Storm"、 どうかなぁ。

2013-05-06 fluent-plugin-uniqcountを公開しました このエントリーを含むブックマーク

リポジトリ

https://github.com/KazkiMatz/fluent-plugin-uniqcount

概要

fluent-plugin-uniqcountは、指定期間範囲において、設定で指定した属性ごとにイベント発生件数をユニークにカウントし、結果の上位N件を定期出力するfluentdプラグインです。SQLでいうところの:

SELECT key1, COUNT(key2) AS key2_count, COUNT(DISTINCT(key2)) AS key2_uniq_count FROM records WHERE time BETWEEN T1 AND T2 GROUP BY key1 ORDER BY key2_count DESC LIMIT 0, N;

に相当します。

fluent-plugin-uniqcountを使うと、

などが集計可能です。

特徴

fluent-plugin-uniqcountは、単位時間あたりのトラフィック量をN、集計対象区間長(設定項目: list*_span)をTとしたときに、以下のような特徴を備えています。

  • イベント1件あたりのプラグインへの入力コストは O(logNT)。単位時間あたりだと O(N logNT)。
  • プラグインの出力コストは O(logNT)。
  • 消費メモリは O(NT)。
  • ユニークカウントである(F5リロードなどでランキングが跳ね上がらない)。
  • 直近(T秒前〜現在)の集計結果が可能である(集計対象区間が時間経過とともにスライドする)。
  • 一つの集計単位を「リスト」と呼び、独立した設定を持つ任意の数のリストを保持することができる(最大10個まで)。
  • fluentdのイベント受信時刻ではなく、レコード内のタイムスタンプを基に集計を行うことができる(未設定時はイベント受信時刻を用いる)。
  • appサーバからfluentdにイベントが到達する時間のゆらぎを吸収するため、集計対象区間の終点を現在時刻から過去へオフセットすることができる(list*_offset: 転送に関与したfluentdのflush_interval値を考慮して設定する)

設定

項目
  • list*_label : 出力レコードに付与されるラベル文字列
  • list*_time : イベント時刻フィールド名(UNIXタイムスタンプ形式 - 省略時はfluentdにおけるイベント受信時刻が使われる)
  • list*_key1 : グルーピングに用いるフィールド名
  • list*_key2 : カウント対象フィールド名
  • list*_span : 集計対象区間長(秒)
  • list*_offset : 集計対象区間終点のオフセット値(秒)
  • list*_out_tag : 出力レコードに付与されるタグ
  • list*-out_num : 出力件数(上位N件)
  • list*_out_interval : 出力間隔(秒)
設定例

入力イベントが以下のようなフォーマットを持っているとき、

site.access_log: {"at":1367820029,"uri":"http://www.careerlink.vn/","remote_ip":168364289}
...

次のような設定で、各spanにおけるURLランキングを得ることができます。

<match site.access_log>
  type uniq_count

  list1_label min
  list1_time at
  list1_key1 uri
  list1_key2 remote_ip
  list1_span 60
  list1_offset 3
  list1_out_tag trends.min
  list1_out_num 5
  list1_out_interval 1

  list2_label day
  list2_time at
  list2_key1 uri
  list2_key2 remote_ip
  list2_span 86400
  list2_out_tag trends.day
  list2_out_num 5
  list2_out_interval 10
</match>

出力例は以下のようになります。

trends.min: {"label":"min","ranks":[{"key1":"http://www.careerlink.vn/","rank":0,"key2_uniq_count":13},{"key1":"http://www.careerlink.vn/file/71ca7183087cce9f04fc559ce37738e9","rank":1,"key2_uniq_count":12}, { ... }, ...],"at":1367840734}
trends.day: {"label":"day","ranks":[{"key1":"http://www.careerlink.vn/","rank":0,"key2_uniq_count":8034},{"key1":"http://www.careerlink.vn/file/065d88676460f47d99ec59263c650f54","rank":1,"key2_uniq_count":7735},{"key1":"http://www.careerlink.vn/file/71ca7183087cce9f04fc559ce37738e9","rank":2,"key2_uniq_count":7266}, { ... }, ... ],"at":1367840734}

TODO

注意点

流しこむトラフィックや、設定によっては、かなりのリソースCPU、メモリ共に)を食うと思います。このプラグインを実際に使用する際は、fluentdプロセスを独立させ、メインのfluentdプロセスからイベントをforwardさせ、処理結果をまたメインプロセスに戻してやるのがよいと思います。

なお、手元ではfluentdプロセスが2GB超のメモリを消費した状態で、安定して稼働しています(ruby 1.9.3p194)。

2011-04-07

Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくか

08:02 | Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくかを含むブックマーク

jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性

jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。

しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう?

大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVCデザインパターンです。

MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られており、Ruby On RailsDjangoStruts等、MVCの考え方に則ってデザインされたサーバーサイドプログラミングフレームワークが多数登場しています。一方で、クライアントサイドでのJSアプリケーションにおけるMVCパターンの活用は、まさにこれから旬を迎えようとしています。ここ数カ月間で、クライアントサイドでMVCを実現するためのJSフレームワークがいくつか登場しました。

現在、クライアントMVCのためのJSフレームワークとして、KnockoutやJavaScriptMVC、そしてBackbone.jsが広く知られています。本エントリでは、その中でも特に有望(※主観です)と思われるBackbone.jsを紹介しつつ、クライアントサイドMVCサーバサイドMVCの本質的な違い、Backbone.jsを用いたアプリケーションの実装方針について考えます。

なお、Backbone.jsが最近アツいとはいえ、まだまだドキュメントやサンプルコードの整備は発展途上であり、フレームワーク自体の自由度も高いことから、Backbone.js使用時における設計の「正解パターン」は未だコンセンサスが無いように見受けられます。したがって、本エントリに記述してある考え方の大半は、あくまで僕個人が「Backbone.jsはこう使えばいいんじゃないかと思った」というレベルのものであり、オフィシャルな裏付けは特段無いばかりか、Backbone.js開発陣の思惑と乖離している可能性も十分にある旨、ご承知おきください。

参考:Knockout vs JavascriptMVC vs Backbone


ここまで前置き(;´∀`)


Backbone.jsリファレンス

公式サイト
参考記事

 Backbone.jsの端的なまとめスライド資料。本エントリに似た趣旨の内容がコンパクトにまとめられている。

 エントリ前半の概論を読むと、Backbone.jsのイメージがわきやすい。後半のサンプルは参考になるが、抜けや間違いが多く、そのままでは動かないと思われ。

 Backbone.jsに対する考察が参考になる。


Backbone.jsとは

Backbone.jsは、JSヘビーなクライアントサイドJSアプリケーションを書くために作られたJSライブラリです。Backbone.jsを導入することで、開発者は自分が実現したい処理を、Model、ViewそしてControllerの組み合わせで実装しなければなりません。

Backbone.jsはUnderscore.jsに依存しています。

Backbone.jsjQueryを置き換えるものではありません。Backbone.jsjQueryより上位の概念として存在しているライブラリです。Backbone.jsjQueryには依存していませんが、View内でのDOM操作はjQueryを用いるのが便利であるため、併せて導入したほうがよいでしょう。現在オンラインで見ることが出来るBackbone.jsサンプルコードのほとんどがDOM操作にjQueryを用いているようです。また、MustacheのようなテンプレートエンジンをView内で用いることも推奨されています。テンプレートエンジンを導入することで、View内でのHTML生成コードをスッキリ記述することができます。

以下は、Backbone.jsが提供する主だったクラスです。

(1) Backbone.Model

 いわゆるModelクラス。データの保持や操作を一身に引き受けるクラス。

(2) Backbone.Collection

 Modelクラスの一部機能を切り出したもの。Modelオブジェクトの順序付きリストとして機能する。サーバサイド等にデータを永続化する際のCRUDオペレーションも担当する。

(3) Backbone.View

 いわゆるViewクラス。HTMLレンダリングを担当する(レンダリング処理を行うメソッドはrender()という名前にすることが多い)。DOMで発生したイベントに対して、簡単にハンドラをバインドできる便利メソッド「events」等が用意されている。View内部でjQueryを併用するとDOM操作がやりやすくなる。また、Mustache等のテンプレートエンジンを用いると、HTML生成コードがスッキリ記述できる。

クライアントサイドJSアプリケーションはイベントドリブンなので、Viewはイベントハンドラの記述等で必然的にヘビーになりがち。Viewの中のrender()メソッドが、狭義での(サーバサイドMVCにおける)Vに相当する。

(4) Backbone.Controller

 いわゆるControllerクラス。URLフラグメント(URLのうち、#以降の部分)に応じたルーティング処理を行うことができる。

Backbone.js下では、Controllerを経由しない、ViewからModelへのアクセスが多発する。これはイベントドリブンな挙動を実現するため、またRESTfulに忠実なURI設計を行うため(後述)。このため、サーバサイドMVCコントローラに比べると、Backbone.jsコントローラはスカスカになりがち。

(5) Backbone.History

 Controllerクラスの一部機能を切り出したもの。ルーティング周りを担当する。



サーバサイドMVCクライアントサイドMVCの違い

デザインパターンとしてのMVCには、分野に応じて様々な定義があるようです。Web系開発者にはおなじみのサーバサイドMVCとは違って、Backbone.jsは、OSネイティブGUIアプリケーションに近いMVCを提供します。サーバサイドのMVCと、Backbone.jsを用いたクライアントサイドのMVCを、図で比較してみましょう。

f:id:kazuk_i:20110407073430p:image

左右のMVCパターンを見比べたとき、左と比べて右側が異なっている点はどこでしょうか。

(1) ViewとModelが結びついている

Backbone.jsではDOMへのイベントハンドラをView内のメソッドとして記述します。このためViewがかなりヘビーになります。さらに、View内に記述されたイベントハンドラが直接Modelを叩くため、ViewとModelが密結合になります。

OOPが重要視するクラス再利用の観点からは、ViewとModelが密結合していることは好ましくありません。このため、Backbone.jsでは、Backbone.Eventsというモジュールを内部で導入し、デザインパターンでいうところの「Observerパターン」を提供することで、この問題を軽減しています。

Backbone.Eventsの導入により、Modelは自分を利用するViewについての予備知識を持つ必要がなくなりました。しかし、Viewは自分が利用するModelについて知っている必要があります。これについてはクラス再利用の観点から許容できないと感じる人もいるかもしれません。DOMイベントに対するイベントハンドラを、Controller(もしくはそれに準じた専用クラス)に分離することで、ViewからModelへの直接のアクセスを排除することはできそうではありますが、コード量が増加する割に複雑性は対して低減せず、メリットが薄いものと個人的に考えています。シンプルさを保つためにもViewがModelを直接叩いたほうがよいのではと思います。

(2) Controllerの役割が薄い

Backbone.jsのControllerは、基本的には、与えられたURLフラグメント(http://foo.com/bar#zoo/baz のようなURLで、ハッシュ以降の"zoo/baz"部分のこと)に応じた処理のルーティングのみを担当します。このため、ページ遷移(この場合のページとは、ブラウザの再読込を伴わず、URLフラグメントのみが書き換わるような画面遷移を意味します)が無いような小規模なアプリケーションでは、Controllerがスカスカになるかもしれません。一方で、提供する機能に応じてページを切り替えるアプリケーションでは、ページに応じたルーティングをControllerが担うことになるでしょう。

たとえば、GMailの場合、受信トレイのURL

 https://mail.google.com/mail/?ui=2&shva=1#inbox

送信トレイは

 https://mail.google.com/mail/?ui=2&shva=1#sent

コンタクトリストは

 https://mail.google.com/mail/?ui=2&shva=1#contacts

といったように、機能(リソース)に応じてハッシュ以降を変更することで、ページ再読込を伴わないAjaxアプリケーションにも関わらず、各リソースに対するRESTfulURL(※本エントリの最後に注釈を追記しました)を実現しています。これのおかげで、URLによりアプリケーションの状態を復元することができ、Ajaxにも関わらずブラウザの「進む」「戻る」ボタンもごく自然に機能してくれます。Backbone.jsのControllerを活用することで、自作のアプリケーションにこういったURLを極めて簡単に導入することができるのです。

また、一般的にサーバサイドMVCでは、ControllerはViewをキックする役割を担っていることが多いでしょう。Controllerの役割は、Modelから必要なデータを取得し、それをViewに与え、ViewをキックしてHTMLレンダリングさせます。一連の処理で、常にControllerが中心で仕切っている構図です。このため当然、ControllerはViewの在処を知っている必要があります。

一方、クライアントサイドMVCでは、事情はかなり異なります。クライアントサイドMVCでは、ViewはModelのデータをリアルタイムに反映し続けなければなりません。この点、バッチ処理的に一度HTMLを生成すれば役割が終了したサーバサイドとは違います。このため、ViewはModelが持つデータの変更イベント(Backbone.jsではchangeイベント)を拾い、イベント発生のたびに自らを書き換えるようにします(Observerパターン)。このため、ControllerとViewの間に直接的な関係は生じません。むしろModelとViewが密に連動しているのです。Controllerはあくまで、アプリケーションが提供するリソースの見え方を変化させるキッカケを与えるだけの役割しか担っていないのです。


Backbone.jsがユーザ入力イベントを処理する二つのルート

Backbone.jsでは、ユーザが発生させるイベントを処理するために、二つのルートが想定されています。開発者は、処理の内容に応じてこれら二つを使い分ける必要があります。

(1) Controllerが提供するルーティング機能

URLハッシュ以降で表されるURLフラグメントを元に、Controllerがアプリケーションの状態を変更する。ページ要素の多くを書き換えるような遷移にはこの機能を使う。(例:GMailにおける受信トレイから送信トレイへの移動等)

(2) Viewが提供するdelegateEvents

Viewが提供する、イベントハンドリングの仕組み。Modelデータの更新や、ページ要素の一部が書き換わるような小機能の実装には、Viewが提供するこの機能を使う。(例:GMailにおける、下書きメールの編集更新、オートセーブ機能、フィルタ設定画面の表示)


Backbone.jsを使ったアプリケーション設計のポイント

(1) ModelはViewを意識してはいけない(ModelがViewを呼び出す際にはObserverパターンを使う)

 前述のとおり。Modelは再利用可能でなくてはならず、特定のViewや特定のControllerに依存するようなコードを、Model内に混ぜてはならない。

(2) ViewはModelを直接叩いてもよい

 前述のとおり。

(3) ControllerはRESTful

 URLフラグメントはあくまでURLの一部であるから(※本エントリの最後に注釈を追記しました)RESTfulに設計しなければならない。フラグメントに「アクション」を記述してはならない。URLが表すものは、あくまでリソースの場所情報であるべきである。

(悪い例)http://foo.com/bar#delete_comment/3URLに「アクション」情報が含まれており、RESTfulでなくなっている。このURLURLとして意味をなさない。また、このURLを再読込するとヘンなことになってしまうだろう。こういったアクションはdelegateEventの枠組みで、ViewがModelに直接依頼することで処理されるべき。

(良い例)http://foo.com/bar#latest_comments/orderby-dateasc-limit-10

 オンラインで入手可能なBackbone.jsサンプルコードは、いずれも小規模なアプリケーションであることが多い。こういったアプリケーションではページ遷移が発生しないため、ルーティング機能解説のためか、無理やりURLフラグメントにアクションを記述しているものも多く見られる。こういった部分は真似しないほうが良いだろう。

(4) ViewはModelの粒度にあわせて階層化/細分化する

ViewとModelはそれぞれ一対一に対応しているのが望ましい。ViewとModelを対応させることで、あるModelが更新されchangeイベントが生じると、対応するViewが自動的に書き換わるような設計が採用しやすい。また、DOM書き換えの範囲を最小限にすることができるため、描画高速化に寄与する。



Backbone.jsまとめ

(1) クライアントサイドMVCは、サーバサイドMVCと比べ勝手が違う

 Web系エンジニアにとって、MVCは馴染みが深い考え方です。しかし、クライアントサイドにMVCを導入するにあたっては、サーバサイドとの差異が多くあるため、サーバサイドで得た先入観を捨ててかかる必要があるでしょう。

(2) Backbone.jsでは、View→Modelという密結合が生じるが、しかたがない

 前述のとおりです。ViewはControllerを経由せずに、Modelに直接アクセスをすることになります。しかし、Modelの再利用性を高めるため、ModelからViewへのアクセスは、原則としてObserverパターンを用いて実装されることになります。

(3) URLフラグメントはRESTfulに設計する

 アクションをURLに含めてはいけません。URLアプリケーションの状態を表せることは、アプリケーションにとって非常に大きなメリットになります。URLRESTful*1に設計することにより、Ajaxアプリケーションにも関わらず、ページのブックマークが可能になり、ブラウザ再起動させても復元したタブに以前と同じ画面が表示され、ブラウザの「進む」「戻る」ボタンもユーザの直感どおりに動作するのです。



大規模なJSアプリケーションを構築する上で、MVCパターンの導入は非常に大きな助けになります。Backbone.jsのようなフレームワークの登場により、クライアントサイドでのMVC導入がこれまでになく簡単に実装出来るようになりました。

現在、この分野で参考になるドキュメントやサンプルコードは、まだまだそれ程多くはないようですが、スマートフォン全盛期の今、クライアントサイドで動くリッチなJSアプリケーションの需要は高まる一方でしょう。今後数カ月で、状況は劇的に改善していくものと思われます。

今は皆が試行錯誤を繰り返している段階であるため、Backbone.jsはユーザの自由度が非常に大きい設計になっているものの、現状のコミュニティの活況を見るにつけ、Backbone.jsを用いたアプリケーション開発の「定番デザイン」が見出されるまで、それほど時間は要さないのではないかと思います。

*1:4/8 5:03追記 はてぶコメントで指摘頂きましたが、#以降のURLフラグメントは厳密な意味でのURL構成要素ではないことを考えると、URLフラグメントでアプリケーションリソースを表現する手法を「RESTful」と呼ぶのは間違いであることに気づきました。他にどういう言葉を使うのが適切なのか分かりませんが...

yossyyossy 2012/06/20 22:47 非常にわかりやすい解説ありがとうございます。

2011-01-29

異形の廃墟ビル『メタボ岡崎』に引っ越しました

00:43 | 異形の廃墟ビル『メタボ岡崎』に引っ越しましたを含むブックマーク

[注意:京都市左京区ローカルネタです]

一目見たら一生忘れることのできない異形の廃墟建造物、"メタボ岡崎"に引っ越したので、その魅力を写真でレポートしたいと思います。

夕日に映えるメタボ岡崎。左京区聖護院はとても住みよいところ。

f:id:kazuk_i:20110130004617j:image

とにかく外見にインパクトがある。

f:id:kazuk_i:20110115162939j:image

f:id:kazuk_i:20110115162321j:image

室内。とても窓が多くて開放的ながら、レイアウトがそこはかとなく奇妙である。

写真からはアラが見えにくいかもしれないけれども、外側も内側もボロボロの建物なので、家賃が非常にリーズナブル。

f:id:kazuk_i:20110127163328j:image

f:id:kazuk_i:20110127163346j:image

最大の特徴は全室にそれぞれ2つ用意されている出窓。各部屋には3ヶ所出っ張りがあり、そのうち2つが出窓に、残る1つはベランダにアサインされる。下層の部屋と入れ違いになるように割り振られるので、外から見ると凸凹して見える。

f:id:kazuk_i:20110130005737j:image

メタボ岡崎航空写真。二棟をエレベータ-階段エリアで接続した構成。室内からは、向こう側の棟が谷の向こうにある島の様に見える。

f:id:kazuk_i:20110130010926p:image

柱の位置が変。窓からは谷向こうの島が間近に見える。開放的。

f:id:kazuk_i:20110127163433j:image


メタボ岡崎は非常に多くの間取りパターンが用意されており、これはあくまで一例。僕は3部屋見せてもらったけれども、全て大幅に違うレイアウトになっていた。(ひょっとして全室間取りがユニークだったりするのだろうか?)

中にはこんな部屋も(僕の部屋ではない)。前の住民が柱に絵を描いていった。

f:id:kazuk_i:20110108122037j:image


角が非常に多い特徴あふれるデザインは、60-70年代の黒川紀章らによるメタボリズム運動を汲んだ物。建物名の由来にもなっている。充填率を優先させておらず、全室が角部屋になるような構成が採用されている。建築当時は人気のマンションだったこと[要出典]も納得の、非常にぜいたくなスペースの使い方である。

全体として異様に対称性にこだわった印象を受ける。例えば建物の中央部、一基のエレベータを挟んで両側に階段が配置されている。合理性に欠けるが、たいへん美しい。

f:id:kazuk_i:20110129163320j:image

f:id:kazuk_i:20110129163328j:image

メタボ岡崎研究家の@nanki氏曰く『この建物には至る所に黄金比が隠されている』

氏は現在、メタボ岡崎3Dモデリングデータの構築を手がけており、完成の折には建物に隠されたさらなる秘密が明らかになるかもしれない。3Dモデルの一日も早い完成及び徹底した分析が待たれるところである。

下の画像は、@nanki氏の手により、驚くべきクオリティで再現されたメタボ岡崎3Dモデリングスクリーンショット。氏曰く「今までの人生で手がけてきたモノの中で、一番クオリティが高い制作物になってしまった」 本データを元に、FPSゲーム「MO(MetaboOkazaki)」やLEGO版「メタボおかざき」の開発等様々な企画が有志により手がけられる予定。

f:id:kazuk_i:20110125035703j:imagef:id:kazuk_i:20110125040657j:image

なお姉妹マンションとおぼしき『メタボ広沢』が右京区にあるらしい。同様に老朽化が進み、某TV番組では心霊スポットとして紹介されていたとか。実に失礼な話である。外見は類似点も多々あるものの、シルエットに大幅な差異が見られる。メタボ広沢は75年施工、メタボ岡崎は80年施工なので、メタボ広沢で得たフィードバックがメタボ岡崎に投入されたのだろうか。

f:id:kazuk_i:20110129175031j:image(メタボ広沢)

僕の部屋、契約前に下見をしたところ、室内バスルームには鳥の糞が散らばっていた。ハトが住んでいたらしい。(その後管理人さんにクリーニングしてもらった)

f:id:kazuk_i:20110108123736j:image

風雨にさらされ、朽ち果てた僕の部屋の浴室窓。

f:id:kazuk_i:20110108121611j:image

今日の午後、階下の廊下からラジオ放送のような音がするのでなんだろうと思ったら、女性アナウンサーの無機質な声でなにか(乱数表?)を読み上げているとおぼしきハングルの放送が、とある一室から漏れ出ていた。一体誰が住んでいるんだろう。一昨日は突然廊下の火災報知ベルが鳴り出し、数秒後に停止した。

室内にある謎の非常ボタン。メタボ岡崎歴が長い人に聞いてみたが、押すと何が起こるのかは知らないらしい。

f:id:kazuk_i:20110130010929j:image

付近一体には、廃墟スポット特有の独特な空気が漂う。時間が止まっている感じ。人気がない。チェルノブイリのようだ。

f:id:kazuk_i:20110108122106j:image

メタボ岡崎入り口。建物名を記した碑があるが、時の洗礼を受けツタが絡まり、文字が読めなくなっている。

f:id:kazuk_i:20110129080630j:image

地下一階にはなかなかイケてるジャズ・バー「ZAC BARAN」がある。お酒も料理もとても美味しい。

f:id:kazuk_i:20110130003022j:image

f:id:kazuk_i:20110130003116j:image

(ZAC-BARAN 店長。料理の腕が素晴らしい!!)

f:id:kazuk_i:20110130003419j:image

f:id:kazuk_i:20110130003303j:image

屋上では楽器練習もおk。

f:id:kazuk_i:20110129163816j:image

ZAC BARANでとある住民の方に借りた本。Geek芸術家肌の個性的な人が住んでいる。

f:id:kazuk_i:20110130012342j:image

メタボ岡崎の魅力はまだまだ語り尽くせないほどある。空室がまだあるようなので、左京区内で引越しを検討している方、如何ですか :)

sacchisacchi 2011/03/09 12:22 初めまして〜。

ごくフツーのOLですが、廃墟メタボの住人ございます。

kazukiさんのこの記事と更新日時を拝見して思い出したんですが、お引越し中にエレベーターでお会いして一言二言お話したような記憶が。(「近所から引っ越してきました」とおっしゃっていたような。違います?間違いだったらホントごめんなさい。)

私も、メタボに一目ぼれして、去年メタボへ引っ越してきました。
大阪北区OLで、通勤片道2時間かけてるんですけど、2時間かけても帰る価値のある我が家☆

またブログ読ませていただきますんで♪

kazuk_ikazuk_i 2011/03/09 13:12 sacchiさん、コメントありがとうございます〜
エレベータでお会いしましたね!その節はありがとうございました。sacchiさんもメタボ一目惚れ派だったのですねぇ。やはりこの建物の魅力は老朽化などでは隠しきれないようですね〜(むしろそこが良い?)。
ご通勤で片道2時間とはまた。。。でもメタボ岡崎に掛けるその思い、素敵です(*´∀`)
また今度是非、ZAC BARANあたりでメタボトークさせて下さいね!

SANTASANTA 2011/05/27 14:11 はじめましてこんにちわ。現在お部屋探し中です。メタボ素敵なビルですねー前から気にはなってんですがblOGの読ませて頂いてますます興味深々です。その後、住み心地ってどんな感じでしょうか?古いビルだから夜とか怖くないですか?女子もいっぱいすんでおられますか?
インターネットとか引き込みできるのでしょうか?
NYのアパートみたいで本当に憧れます。
お時間あれば教えてください。お願いします。

kazuk_ikazuk_i 2011/05/27 16:58 SANTAさんこんにちは。メタボ岡崎の住み心地はすこぶる快適ですよ!最近謎のネットがビル外壁に被せられてしまい、若干視界がぼやけてしまったのですが、それ以外は特に問題ないですね〜 至って静かな建物で、住民の方には小さなお子さん連れの家族世帯もいたりするようです。地下のZACBARANが午前4時まで開いているので、夜はむしろ安心かも? 女性の方は、どれぐらいいるんでしょうねぇ、そもそもあまり住民の方にあわないので、よく分かりませんが。。。インターネットは備え付けのものが7階まで伸びているようですが、僕は8階に住んでいたので、自分でADSL回線を契約しました。電話線は各部屋に来てますから、ADSLであればスムーズに契約できると思いますよ。ご参考になりましたら :-)

SANTASANTA 2011/06/01 18:41 早速ご返答ありがとうございました。
一度今空いているお部屋を不動産屋さんと一緒に拝見しにいこうかと思います。
大変ワクワクします。ありがとうございまーす。でも景色を考えるとやっぱり8Fがいいですよねーーー

kazuk_ikazuk_i 2011/06/01 20:56 おぉ、内見ですか。僕の友人もメタボ岡崎に興味があって近々見学にいくらしいので、一緒に付いていこうかなと思ってます :D 僕は自分が部屋を決めるときには3部屋みせてもらったんですが、後日分かったのですが空室はもっとずっとたくさんあったようで、一部しか見れなかったことがとても残念で。。SANTAさんも是非色々な部屋をみていただいて、よろしければ様子をレポートもしてください〜 :)

sacchisacchi 2011/08/19 15:56 二度目のコメントとなります。
sacchiです。
前の仕事が異様に残業が多く「メタボライフが楽しめない」と苦悩した結果、転職しまして(それでもなお大阪キタ勤務ですが・・・)、バタバタしておりました。

6月頃だったかな、残業した日の夜、夜食を兼ねてZAC BARANにもデビュー。いい雰囲気ですね!

ようやく落ち着いたので、ぜひ、メタボトークしたいです。よろしければ連絡くださいませ〜。

kazuk_ikazuk_i 2011/08/22 21:03 sacchiさん
ぜひメタボトークしましょう〜! メタボリズムの権威であるnanki氏にも来てもらわねば :)

sacchisacchi 2011/08/24 14:06 ありがとうございます♪
メタボリズム研究の大家の方にもぜひお越しいただき、熱く語りたいです。いつ頃がよろしいんでしょう??

ちなみに。メタボ住人のワタクシは、ついにクーラーなしでこの夏を乗り切ってしまいました(いや、乗り切る予定です)。
うちは、夜になると結構風通しがよくて涼しいんですが、泊まりにきた友人らからは「暑すぎやがな」と不評でした。
他のお宅はどうなんでしょう?
クーラーない部屋はレアケースなんでしょうか??

kazuk_ikazuk_i 2011/08/30 19:50 sacchiさん
お返事遅くなってすみません!sacchiさんはお勤めの身とのこと、やはり週末あたりがご都合がいいでしょうか? 9月3日(土)などは如何でしょう。

僕の部屋にはボロボロのクーラが備え付けでありまして、普段は窓をあけてしのいでますが、あまりに熱い日はクーラつけてますねぇ。このクーラも、前の住民の方が残していったとかで、備品扱いでは無いとのことです。
メタボ岡崎は風の通りは確かに良いですね〜 ビルの形になにか工夫があるんですかねぇ。

めいめい 2011/11/07 11:06 メタボ!!!!!!
今森美術館でやっている『メタボリズムの未来都市展』で、自分の好きな団地、万博、地図、車窓、生物学、物理学などなど全てが自分の中でつながったばかりのめいです。
おおぎさわが見つけた松本さんのHPに『メタボって書いてある』と聞いて飛んできました。
今度これとは関係のない松本さんの興味のあることを含め、いろいろお話お伺いしたいです!!!
お忙しいとは思いますが、ぜひ一度めいちゃんちにでも遊びにきてください。

kazuk_ikazuk_i 2011/11/07 12:35 昨日はどうも〜!
「メタボリズムの未来都市展」良かったですか。僕も見に行こうと思いつつまだ足を運んでおらず、、展示が終わるまでに是非行きたいです。めいちゃんち、今度ぜひ遊びに行かせてくださいね :)

元住人元住人 2011/12/04 22:13 初めまして。
3、4年前まで住人でした。最近メタボリズムという言葉を知り、メタボ岡崎の名前の由来の謎がとけました。改めてメタボ岡崎を検索したところ辿り着いた次第です。柱の絵は僕が描いたものです。まだ残っているとは笑えますね。生活していて結構ネタはできましたが、一言でいうと好きでないと住めない所ではないでしょうか。最近ネットが張られて壁の補修でもするのかなと思いきやただのネットやったんですね。
いつか文化遺産になる日でも来たらおもしろいですね。失礼しました。

kazuk_ikazuk_i 2011/12/04 22:28 元住民さん、はじめまして。コメントいただきありがとうございます。
そうですか!あの絵を描かれた方だったのですねー。絵がとても素敵だったのでかなり迷ったのですが、結局8階の空き部屋を選びました(眺めがよかったので)。
古い内装や水回り等、不満点もありますが、今のところ楽しく暮らしております。ネットは確かにうっとおしいですが。。
解放感あふれる設計の、とてもよい建物だと思うので、将来再評価されることを心待ちにしています :)

現住民現住民 2011/12/30 03:26 メタボに住み始めて1年程の新人メタボです。
森美術館のメタボリズム建築の展覧会行ってきました。中銀カプセルタワーの一室が展示されていて、とでも満足しました。
メタボる前は職場の寮に住んでいました。
不動産屋クマノハウジングの貼り紙でメタボを発見。名前に惹かれて覗いてみたら、予想以上にザ・昭和なデザイン。即刻寮を引き払い移住しました。
メタボのスゴさを知って欲しいとき、いつもこちらのブログを参照すべし!と案内させて頂いてます。
メタボ住民の会合があれば、是非ともに参加させてください。

kazuk_ikazuk_i 2012/01/04 07:00 現住民さん、
はじめまして。コメントいただき有難うございます〜
一年前と言いますと、丁度僕と同じくらいですね。同期生ということでどうぞよろしくお願いします (^_^)
メタボ展にも行かれたということで羨ましい限りです。僕は結局、会期中に上京の機会なく、断念、、
元住民さんも書かれていますが、やはりこの建物、人を選ぶのでしょうか。友人などを自室に連れてきても様々な反応が見られてそれがまたとても面白く感じています。
メタボ会合、近いうちに是非またやりたいですね。ZAC BARANあたりで是非!!

現住民現住民 2012/01/07 11:39 早速のお返事ありがとうございます。
メタボ会合、是非開催しましょう!
寒さ対策や水周りについての工夫など、あれば教えて頂きたいです。
ZACで2012年度メタボ会合を☆
꒰ෆ❛ั ु▿❛ั ु꒱