A-Listers

スタートアップのビジネスが成功（または失敗）するにつれて問題となってくる、創業メンバーの利益の取り分や意思決定の方法などを記載したAgreement（合意書）を、5つの質問に回答するだけで作成できるBack of a Napkinというサイトが公開されました。

以下の5つの質問に回答すると必要事項が記載されたPDFファイルがダウンロードでき、あとはメンバーがそれぞれ署名をすればAgreementができあがる、というものです。

1. チームメンバーの名前
2. チームが開発しようとするもの（aかanで始まる1文）
3. プロジェクトが利益を生んだ場合の各メンバーの取り分
4. 意思決定の方法（誰かが決定権を持つか、完全に合議制とするか、など）
5. プロジェクトが失敗した時にどうするか（ブランドや成果物の扱い）

このサイトがあれば弁護士へ相談する必要がなくなるといった性格のものではありませんが、こういった取り決めなしに複数人でスタートしたプロジェクトは、成功しても失敗しても厄介な問題を抱えることになりかねませんから、「最初の段階でどんなことを取り決めておくべきか」を意識させるという点では有用かもしれません。

via http://thenextweb.com/entrepreneur/2013/12/14/back-napkin-aims-get-basics-building-startup-way/

David Heinemeier Hansson氏（Railsの開発者。以下DHH）が37signalsのブログに公開したRunning beta in productionというエントリによると、同社ではBasecampの開発に使われる6つのベータサーバーがすべて単一の本番環境のデータベースを参照して動いているそうです。

DHH氏曰く、「自分がいいアイデアだと思ったものが本当にそうなのかを知るには、実際のデータを対象に自分たちが日々使ってみることが必要」とのこと。

Basecampでは新機能や改良の開発、技術的なアップグレードなどを継続的に行なっており、そのために同一の本番環境のデータベースを参照する6個の異なるベータサーバーが運用されています。通常、開発中の機能は開発用のデータベースと共に運用するのがセオリーだと思いますが、DHH氏は「実際の重要なデータとともに不満を感じながら使わないかぎりは、そういった機能をきちんと評価することは不可能だと気づいた」とのことで、このような構成になっているそうです。

最初は、実際にサービスの運用に使っているものとは物理的に異なるサーバーに本番のデータを複製しているのではないか、とも思ったのですが、コメント欄にて「All beta envs and production share the same prod database.」という37signalsスタッフのコメントがあるので、やはり実際にサービスで利用しているデータベースにベータサーバーを接続しているということで間違いないようです。

また、6つのベータサーバーをどのように使い分けるのかの手順はシンプルで、どのサーバーでどのブランチのコードを走らせているかは、開発者が適宜、開発用のチャットルームのタイトルに反映させているそうです。ブログエントリに掲載されたスクリーンショットでは、以下のようなルームタイトルになっていました。

• staging: riakcs
• beta: project_templates
• b1: redis-resque-upgrade
• b2: tags-mini
• b3: bcx-ios-compose [reserved for bcx-ios]
• b4: email-in-phone
• b5: rails4

エントリではstagingの位置づけには触れられていませんが、それ以外のbetaからb5までのサーバーはすべて本番のデータベースに接続していると考えてよさそうです。

開発者は、ベータサーバーが必要なときはルームタイトルの「b1」の部分を「b1: redis-resque-upgrade」のようにサーバー名とブランチ名に書き換え、ベータサーバーでの作業が終わったら「b1: available」のように変えることで、シンプルに運用しているようです。

このようなスタイルの運用で気になるのが、データベースマイグレーション（スキーマの変更など）をどのように適用するか、というところだと思います。

それについてはコメント欄でいくつかやりとりがされていて、基本的には、

• 本番データベースに接続されたステージング環境でマイグレーションのテストを行う
• その後、それを本番環境にもロールアウトする

という運用のようですが、この際、ステージング環境が接続する本番データベースというのが、本番データベースの複製なのか実際に運用しているデータベースそのものなのかについては残念ながら言及がありませんでした。

個人的にはかなりアグレッシブな運用だと感じたのですが、データベースマイグレーションを注意深く行うようにすればアリなのかもしれませんね。

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

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

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

などなど。

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

ボルチモアにて、現地時間の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氏のツイートによるとどうやら日曜日には仕上がっていたようです。

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