A-Listers

Workspace

今や、いいエンジニアを雇うのに環境や待遇が重要なのは言うまでもないことで、「希望するマシンが支給される」とか「椅子はすべてアーロンチェア」といったフレーズは魅力的です。しかし、そんな華やかなフレーズの裏側に見え隠れする「社内のカルチャー」という本質を理解しないと、本当に素晴らしいエンジニアを惹き寄せることは難しいもの。

NingやVMware、Akamaiといった企業で働いた経験のあるJohn Josef “Sef” Kloningerさんは、Why Quit? Because They Have Bigger Monitorsというブログ記事で、自身の経験を以下のように紹介しています。

退職理由は「転職先のモニターのほうが大きい」から？

以前の職場での話。

私はエンジニアリングマネージャーで、人材確保に関して問題を抱えていた。チームのエンジニアが会社を辞めて、もっと小さい今風の会社に移ろうとしていたのだ。

以下は退職者面接での一幕。

私：なぜ辞めてしまうんだい？
彼：あっちにはもっと大きいモニターがあるんだ。
私：（疑わしそうに）冗談だろう？うちでも君にもっと大きいモニターを支給できるよ。
彼：僕だけじゃない。あっちでは全員が大きなモニターを使っているんだ。
私：それがそんなに重要なのかい？
彼：僕の作業時間というものを彼らがどれくらい重視しているかわかる。彼らにとっては、僕の網膜により多くのピクセルを詰め込むことは、余分な資金を費やすだけの価値があるってことさ。

今となっては、これがまったく真実であると理解できる。このように従業員を評価する職場では、設備投資を節約することと従業員の生産性（そして喜び）を比較して考える。最高のエンジニアは、職務のために最高のツールを与えられる。

大きなモニターはそれをあらわすわかりやすいサインだ。

Kloningerさんは、優秀なエンジニアが惹かれる強いエンジニアリングカルチャーというものを「エンジニアが高く評価され、また重要とされている」ことと定義して、意味合いとしては以下のように説明しています。

• 決定までのプロセス − どんなものをいつ誰が作るのかということについて、技術畑の人たちが提案することで決定がなされる
• ソフトウェアを作り上げる技術に対するリスペクト − プロジェクトによっては期間の予測が難しいものもあるが、そういったものも受け入れられる必要がある
• インフラストラクチャーへの理解 − メッセージキューのスケーリングやビルドシステム、バージョンコントロールなどの機能面とは関係のない作業が必要な場合に、その正当性を上司が理解している

こういったカルチャーを面接の場で引き出す・聞き出すことは双方にとって難しく、それは前述のエピソードでもうかがえます。

記事にはもう1つエピソードがあって、こちらは人によってはそれほど気にしないかもしれませんが、社内文化をうかがい知るという部分ではとても興味深い観点だと思います。

自分のメールアドレスを選べる？

エンジニアでない人々は、メールアドレスがどれくらい重要なのかということを正しく理解していないことがある。メールアドレスはオンラインでのアイデンティティなのだ。

厳格な命名規則（ファーストネームとラストネームの1文字目とか、もっとひどいのはラストネームとファーストネームの1文字目）は、エンジニアのハッピーさよりも画一性に価値を置いた職場であることを暗に示している。

それどころか、従業員に自身のことを「クールな個人」ではない「歯車」や「人的資源」のように感じさせてしまう素晴らしい方法ですらある。

（余談：Human Resources（人的資源）という言葉はやめよう。とても不快だ）

私のファーストネームは風変わりなので、この問題は個人的にも重要だ。もしあなたが sef@company.com を使わせてくれないのならば、それは私にとって大きなマイナス点となる。

エイリアスや、メンバーが1人しかないメーリングリストといったダサいもので誤魔化したりもしてはいけない。シェルプロンプトでどのように見えるか、whoami コマンドが何を返すのかが重要なのだ。

ということで、悪いカルチャーから生まれる悪いポリシーによって、あなたの組織が優秀なエンジニアにとって魅力的ではないポジションに位置することになってしまう、というお話でした。

日本でも、エンジニアだからこそ転職時に気になる社内文化の問題っていろいろあるような気がします。オフィス設備だけでなく、そういった部分にもっとフォーカスをあてた採用活動も増えていくといいですね。

via Why Quit? Because They Have Bigger Monitors | sef.kloninger.com

Citrix SystemsによるCloud.comの買収が発表されました。

• Citrix Buys Cloud.com for More Than $200 Million; Redpoint Is on a Roll | TechCrunch
• Citrix Systemsによるプレスリリース

Cloud.comはオープンソースのクラウドコンピューティングプラットフォーム CloudStackを開発・提供している企業です。もともとはVMOpsという社名でしたが、2010年5月にステルスモードを抜けるとともに社名をCloud.com, Inc.に変えて現在に至っています。

気になる買収額ですが、TechCrunchの推測によるとおよそ$200M〜$250M（2億ドル〜2億5000万ドル）あたりではないかとのこと。そのTechCrunchのエントリーでは「彼らが手に入れた一番の資産はcloud.comというドメインだ！」というジョークが真っ先にコメントされていて笑ってしまいましたが、実際のところ、cloud.comというのはかなり資産価値の高いドメインのような気がします。

「果たしてVMOpsはいくらでこのドメインを手に入れていたのか？」

少し気になったので調べてみたところ、ドメイン名業界向けの情報サイト Domain Name Wireに当時の記事がありました。

• VMOps Buys Cloud.com from Meetup Co-Founder – Domain Name Wire

記事によると、もともとcloud.comというドメインはMeetupの共同創業者であるScott Heiferman氏が保有していたもので、それが2009年にオークションに出され、2010年2月17日にVMOpsへと所有者が書き換えられたそうです。なお、ドメインが登録されたのは2000年ですが、当時からHeiferman氏が保有していたのかは確認できませんでした。

気になる譲渡価格については「Heiferman氏との契約内容により、開示することはできない」と言われたそうです。ただ、ちょうどその時期にVMOpsが$17M（1700万ドル）の投資を受けていたことから、これがドメインの購入に向けたものだったのではないか？と推測されています。

当然、Citrix Systemsはドメイン名だけを目当てに買収したというわけではないでしょうが、資産にcloud.comというドメインが含まれていなければ評価額はもっと下がっていたであろうことを考えると、Cloud.comの思い切ったブランディング戦略はなかなか上手かったと思わざるをえません。

とはいえ、一番関心すべきなのはHeiferman氏の先見の明ですね。2007年のHeiferman氏のブログには以下のような一文もありました。

(I happen to believe in a Web OS [& I own cloud.com]. Funny how the social OS is now web OS.)

Hacker Newsで、ベルギーの女性2人組によるDon’t be rich, Live rich（金持ちになるのではなく、豊かに暮らす）というプレゼンテーションが話題になっていました。

この2人は、WebデザイナーのIne Dehandschutterさんと、オンラインコミュニケーションのコンサルティングをしているCatherine Van Holderさん。サイトはnomadz.nu。2人はとくにお金持ちというわけではないけれど、様々なデザインのアパートメントに滞在しビンテージカーに乗りながら、2010年の間に南アフリカやタイ、アルゼンチンなど10カ国を旅してまわるというとても充実した生活を送ってきました。

2人はこの生活を一般的な毎月の収入だけでまかなっているそうですが、そのポイントは「働きながら」というところ。2人ともリモートで作業のできる仕事を持っているために、このようなスタイルで暮らすことができているというわけです。

これだけでは単に羨ましいだけの話で終わってしまいますが、このプレゼンテーションで2人は、普通の「テンプレート」な生活ではなく自分がどんなことをやりたいかを元に自分のライフスタイルをデザインしよう、と呼びかけていて、そのための心構えとアドバイスを紹介してくれています。

プレゼンテーションでは、2人のような暮らし方を始めるための4つのステップと気をつける点が解説されていますが、詳細はプレゼンテーションを見ていただくとして（とてもグラフィカルで端的なので英語が苦手な方でも読みやすいと思います）、ここでは気をつける点と役立つツールをいくつか抜粋しておきます。

• 気をつける点
  • 言葉が通じないことによる不便さ（南アフリカでは簡単に友達ができたけど、タイとブラジルは言葉の壁があった）
  • いくつかの国はあなたが思っているものとは違う（アルゼンチンは物価が高騰している、週末に旅して回るには広すぎる）
  • ヘッドフォンは必須
  • 規律正しく働く必要がある（ブエノスアイレスにオフィスを持ったのでとても生産的に仕事ができた）
• 役立つツール
  • iPhoneと現地の携帯電話番号、SIPソリューション（ベルギーの電話番号から旅先の電話番号への転送をする）
  • Skype（顧客との通話と画面共有）
  • Dropbox、Sugarsync、Nomadeskなどのファイル共有サービス
  • Backblazeなどのオンラインバックアップサービス
  • AirBNB.com
  • FacebookとTwitter

というわけで、羨ましい反面、いざ実践するには勇気がいるなあ…というお話でした。

でもやっぱり羨ましい。

via: Hacker News | Don’t be rich, Live rich

スタートアップのビジネスモデルについて「グーグルメソッドで考えるのはやめよう」と呼びかける記事がスタートアップ向けブログメディア The Startup Foundryに掲載されていました。グーグルメソッドとはつまり、「今はまだ利益があがっていないけど、ユーザーが10万人に達しさえすれば広告で採算がとれるようになるはずだ！」という考え方。

Googleのビジネスモデルについては既にご存知の方も多いと思いますが、同ブログによれば、

• Googleは実質的には、マーケットに入り込むために検索を利用している広告の会社である
• 無料のサービスで注目を集め、実際の製品である広告をより効果的なものにしている

といった点で、Googleは多くのスタートアップとは異なるゲームをプレイしている、としています。

一方で、スタートアップ（特に自己資金によるブートストラップ・スタートアップ）は生き延びるためにキャッシュを必要としており、主力製品を無料で配りその分を規模で補うようなやり方はとても危険なので、盲目的にグーグルメソッドをなぞってはならない、と。

では、スタートアップはどうすればいいのか？という話なのですが、同ブログでは自社のサービスに「初日から課金する大胆さ」を持つように勧めています。このアプローチは一部のアントレプレナーたちからは敬遠されているようですが、

• 自分のスタートアップが現実の価値を提供できると信じているのならば、ユーザーにお金を払ってもらおう
• 無料で提供するという考えに怖気付いてはならない

だそうです。

Googleのモデルもスタートアップのモデルも理屈としては理解している人が多いと思いますが、いざ自分のサービスをローンチさせるという段階になってみると、なかなか冷静に判断できなくなるものなのでしょうか…。

via: It sucks to build a startup with the “Google Method” | The Startup Foundry

The Startup Dailyというサイトでは、起業家やスタートアップ向けの書籍から、1日1つ印象的なフレーズを紹介しています。これまでに取り上げられている書籍は、

• REWORK（邦訳：小さなチーム、大きな仕事―37シグナルズ成功の法則）
• Behind the Cloud（邦訳：クラウド誕生 セールスフォース・ドットコム物語）
• The Presentation Secrets of Steve Jobs（邦訳：スティーブ・ジョブズ 驚異のプレゼン）

などなど。

簡潔だけど力強い言葉が多いので、仕事に煮詰まった時にアクセスしてみてはいかがでしょうか。

RubyアプリケーションのPaaSとして知られるHerokuが、Node.jsで書かれたアプリケーションへの対応を開始しました。現時点ではパブリックベータという位置付けですが、これまでと同様の使い勝手で簡単にNode.jsアプリケーションをデプロイすることが可能となっています。

Herokuでは、アプリケーションが稼働するOSとRubyインタプリタの組み合わせをスタックと呼び、これまでは2種類のスタックが用意されていました。そこに、今回新たにRuby 1.9.2とNode.jsをインタプリタとして含んだCeladon Cedarというスタックが追加され、これを使うとRails3アプリケーション、Sinatraアプリケーションなどのほかに、Node.jsを使ったアプリケーションにも対応するという形です。

HerokuでNode.jsアプリケーションを動かす手順については、Getting started with Node.js on Heroku/Cedarが詳しいので、興味のある方はぜひ試してみてください。各種パッケージもインストール可能なので、expressフレームワークやPostgreSQL（Herokuが標準提供するデータベース）を利用した本格的なアプリケーションも運用できそうです。

これまでもHerokuはNode.jsの試験的なサポートを行なっており、クローズドなベータテストが続けられていましたが、今回突然パブリックベータとして公開された背景には、このところ新しいPaaSプレイヤーが続々と登場していることも大きく影響しているのでしょうね。

via: Heroku Gets Node.js and More in New Beta Version – ReadWriteCloud

ボルチモアにて、現地時間の16日よりRuby on Rails開発者のイベント RailsConf 2011がスタートしました。Rails開発者のDHHことDavid Heinemeier Hansson氏によるキーノートスピーチのレポートがDHH’s RailsConf 2011 Keynote Live-Blogged Hereにて公開されています。

今回のDHH氏のスピーチは「The Asset Pipeline and our Post-Modern, Hybrid, Javascript Future」と題したもので、来るべきRails 3.1の新機能紹介が中心となっています。が、今回はその内容ではなく、スピーチに使われたスライドのイラストにまつわるエピソードを紹介します。

スピーチのタイトルどおりに未来風（だけどちょっとレトロ）なパイプラインと宇宙船が描かれたこのイラストは、このスピーチのためにMike Rohdeさんという方が描かれたそうで、DHH氏に依頼されてからイラストを仕上げるまでの流れがブログで公開されていました。

この方、DHH氏が所属する37signalsの書籍 REWORKのイラストも担当された方だそうです（邦訳は「小さなチーム、大きな仕事」ですが残念ながらイラストは収録されていません)。

さて、今回DHH氏からはスピーチのタイトルとThe Jetsons風の宇宙船というイメージが伝えられ、Mike氏はまず、

• PenultimateというiPad用のスケッチソフト
• 自分の指
• Stylus Socks Pro

を使ってデジタルなスケッチを仕上げました。それをiPadからダイレクトにDHH氏に送り、コンセプトとデザインの大枠が決まったら、次はモレスキンとペンを使ってアナログなスケッチを作成、それをスキャンしたものをPhotoshopで仕上げる、という流れで完成させたとのこと。

ちなみにキーノートの本番は月曜日、依頼があったのが金曜日でしたが、DHH氏のツイートによるとどうやら日曜日には仕上がっていたようです。

最近は、クリエイティブ・コモンズな画像や有料の写真素材をスライドに取り入れる方が増えてきましたけれど、あえてオリジナルな手書きスケッチを取り入れてみるというのも目を惹いて面白いかもしれませんね。

Node.jsのカンファレンス NodeConf 2011にて、YammerのリードエンジニアであるMatthew Eernisse氏がNode.jsの運用を通じて学んだことについての発表を行いました。発表のサマリーは5 Lessons Learned Running Node.js in Productionで読むことができます（スライドはまだ公開されていないようです）。

「コールバックを使ったスタイルのコードは、イテレーティブに開発をしやすいが、結果としてスパゲッティコードになりがち」という意見は他所でも見かけることがありますね。また、

• 物事は失敗すると仮定せよ
  • コールバックは失敗すると仮定してデフォルトではエラーメッセージを出力するようにし、処理が上手くいった場合にエラーを取り消すようにする
  • あとで原因を調査できるよう、すべてのエラーはログに記録しておくこと
• 可視性とメトリクス
  • 初期段階から、あらゆるものを測定して記録するようにすべき
  • Yammerではメトリクスライブラリとしてmikejihbe/metricsを利用している

といったところは、実際にサービスを運用しているところらしい意見です。

私も普段からYammerを利用しており、ここ数カ月でリアルタイム性がかなり向上してきている印象があったのですが、その裏にはNode.jsのパワーがあったのですね。

ポートランドで開催されたJSConfにて、ブラウザ上で動く教育用ビジュアルプログラミング環境 Waterbearが発表されました。

Waterbearは、MITメディアラボで開発されているScratchに似たアプローチの言語で、制御構造やユーザーの操作をあらわすブロックを繋ぎ合わせることでプログラミングを行います。ベースがJavaScriptなので、ビジュアルに作成したプログラムから生成されたJavaScriptコードを見ることができるのが特徴です。

開発者のDethe Elza氏が目指しているのは、Alan Kay氏がSqueakで目指したものと同様に、

• プログラミングの書籍で使われるようになること
• プログラミングの初学者がよりプログラミングに没入できる環境となること
• 普通の人がカジュアルなプログラマーとなれること

だということです。

実装としては、jQueryやModernizr、Processing.js、Raphael.jsといったライブラリを使ったクライアントサイド（ブラウザ上）で稼働するアプリケーションとなっています。Waterbearのサイトでは実際にブラウザ上からプログラミングを試すことができますし、ソースコードもGitHubで公開されていますので、興味のある方はちょっと覗いてみてはどうでしょうか。

ちなみに、Waterbearという名前はタフさに定評のあるクマムシから命名されたもので、RubyやPythonといった他の言語からも使えるようなとにかくしっかりした言語を目指している、ということです。

via:http://www.readwriteweb.com/hack/2011/05/waterbear-is-like-scratch-but.php

@junyaです。海外のテクノロジースタートアップが出している求人情報を探ることで、次のトレンドやマイナーだけどパワフルな技術、効率的に優秀な人材を見つける方法をうまく知ることができるのではないか、と思ったので、そんな記事をしばらく書いていこうと思います。

今回は、最近TechCrunch JAPANでもGreplin: エンジニア6名, 3か月で15億のドキュメントをインデクシングという記事で取り上げられたGreplinを探ってみました。

彼らが採用しているテクノロジーについては、GitHubで公開されているコードおよびQuoraのWhat languages/frameworks is Greplin using in their recently launched and much faster rewrite?という質問をざっと見ることで、おおまかに知ることができます。

それによると、インフラはAmazon Web ServicesのEC2/S3/SES、プログラミング言語はPythonとJavaがメインのようです（最近はScalaも使い始めたとか）。ライブラリやミドルウェアとしてはTwistedやApache Lucene、memcachedなど。どうしても遅くなりがちな、Amazon SESやSendGrid、KISSmetrics、Mixpanelといった外部サービスAPIへのアクセスを、Tornado Web Serverに含まれる非同期HTTPクライアントを利用した独自ライブラリで行うようにしている点は、なるほどなという感じです。

• greplin-tornado-ses
• greplin-tornado-sendgrid
• greplin-tornado-kissmetrics
• greplin-tornado-mixpanel

そんなGreplinは技術者の応募をThe Greplin Programming Challengeというページを通じて受け付けており、同社ブログによれば、エンジニアのShaneal Manekさんも450件ほどあったプログラミングチャレンジ経由の応募からの採用だそうです（この方はさっきのQuoraページでも回答を寄せてくれている）。このプログラミングチャレンジでは20分〜2時間ほどで解ける3つの問題が出題されるので、プログラミングに自信のある方は挑戦してみても面白いのではないでしょうか。

採用ページでは同社のエンジニアリングスタイルとして、

• 難しい問題をコードによって解決することが好き
• 何をするにも最速の方法を選ぶ（最速とは少ないCPUサイクルの場合もあるし、少ないプログラマーの稼働である場合もある）
• データ構造とアルゴリズムについての確かな知識（大学でも書籍でも実務で学んだものでも構わない）
• 勤務初日からコードをコミットする

といった点が挙げられています。

というわけで、「勤務初日からコードをコミットする」という表現からもわかるように、とにかくプラグマティックに「コードを書く」というスタンスが感じられるGreplinなのでした。