@kyanny's blog

My thoughts, my life. Views/opinions are my own.

なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか

ohbarye.hatenablog.jp

Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており

2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。

いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。

なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば:

  • 試用期間を終えた正社員の開発者は全員「採用担当者」として、採用関係の話をする非公開チャットルームに参加してもらった。センシティブな情報を扱うのでさすがに招待制にしている。
  • 以前も採用担当の開発者が面接をしていたので、候補者の同僚となる人が面接に参加してはいたが、それ以外の人は参加できなかったので、逆に必ず複数の開発者が面接に参加するルールに変更した。
  • 採用活動の各段階ごとに「誰が・いつまでに・何を」するべきか?というフローを文書化して README.md に書き、それに従えば誰でも採用の流れを把握でき、採用フローを進めることができるようにした。特定の人のステップでスタックしてしまうのを防ぎ、また「今どういう状況だっけ?」というのを減らすため。
  • 応募いただいた候補者のいわゆる書類選考の結果や面接の結果など、全て GitHub の専用リポジトリに個別にイシューを作り、そこに記録していくようにした。ここも閲覧できるメンバーを Team で限定している。以前は Google Docs とチャットのみでやっていたが、議論の過程を追いづらかった。
  • 面接後の所感の共有なども関係者が少なかったときは口頭で済ませてログが残らない傾向があったが、所感 + 面接した人たちで話した内容もイシューへのコメントとして書き残すようにした。記憶し続けられないから記録する、というのもあるが、面接に全ての開発者が参加するわけではないので、参加しなかった人たちに対してもフェアな形で議論を進めていきたいから、という理由もある。

Quipper では「言い出しっぺの法則」が強く働くので、当然のことながら、言い出した自分自身が誰よりもこれらの地道な活動をし続けて、こういうオープンなやり方にはやや懐疑的だった人たちに対しては「ほら、ちゃんとうまく回るんですよ」と示し、新たに参加してくれた人たちに対しては「こういう風にやるんだよ」と示してきた(つもり)。

そのおかげ、なのかどうかはわからないが、一年前に採用面接を受けてその後入社した人に入社後半年くらいで採用活動に参加してもらうことができている。結果的に、採用というタフな仕事の負荷分散ができ、なおかつ難しい判断を迫られたときにもより多くの頭脳を動員して精度を高められた。それは「良い人をとる・失敗しない」ことにつながり、ここ一年ほどで Quipper 東京オフィスで採用したエンジニアの人たちが皆さんチームにフィットして活躍しているのは、採用活動がうまくいっている証左といっていいと思う。


要するに「やり方が気に食わなかったので自分の好きなやり方に変えた」わけで、こう書くとひどい話のようにも見えるけど、当事者意識どころか自分が当事者そのものになるのだから、多少エゴイスティックな感じがしたとしても、言いたいことはどんどん言ったほうがよい。当事者がお互いに言いたいことを言ったうえで、妥当な落とし所をみつけていけばよいのだ。議論すべき場で何も言わず、居酒屋で愚痴ってばかりなんてのはまっぴらだ。

Atom実践入門

著者の id:tomoya さんから本をいただきました。ありがとうございます。

d.hatena.ne.jp

宣伝に偽りなし。 Atom の操作方法から内部構造まで丁寧かつ徹底的に解説した一冊だ。

Chrome DevTools しかり、 Web Components しかり、 2016 年に書籍で読む価値のある Web 技術の話であり、それぞれ単体で一冊の本になってもおかしくないトピックだ。それをテキストエディタの解説書でカバーしてしまう発想には脱帽する。

本題のテキストエディタの解説部分も抜かりない。まず目次からしてひと味違う。操作の名前(日本語)と対応するコマンド名(英語)が併記されているので、目当ての操作を見つけたらコマンドパレットにコマンド名を入力してすぐに使うことができる。さらに各項目の解説ページにはそのコマンドを呼び出すデフォルトのキーバインドも掲載されているので、メニューから機能を選ぶ初心者・コマンドパレットを駆使する中級者・キーバインドを指で暗記する上級者の誰にとっても役に立つ。

カスタマイズ方法の解説部分はさすがに Emacs の本を書いた著者だけあってマニアックで、おすすめパッケージ紹介の一発目に Emacs 相当のキーバインドを提供するパッケージが出てきたり、キーバインドのカスタマイズ方法にがっつり数ページを割いている(しかもまず最初に定義済みキーバインドの確認方法を持ってくる)あたり、10 年来の Emacs ユーザーとしては「わかってるなぁ」と頷くばかりだ。

これだけ濃い内容なのに実質 250 ページ以内におさまっているのだから大したものだ。分厚くないし、版の小ささもあって重くもなく、かさばらない。図表が豊富で文章も読みやすいので、本の薄さに輪をかけてさくさく読める。そして紙の本と同時に電子書籍も発売されているので、カバンや本棚を持っていない人でも安心だ(私も買いました)

惜しいのは、 Atom 自体もさることながらその土台となるものも進化がとてもはやいので、例えば Chrome DevTools の解説の図表などは発売日時点ですでに古くなってしまっていること(2016/07/14 時点の最新バージョンは Atom 1.8.0)印刷した時点で内容が永遠に決定されてしまう紙の宿命とはいえ、最新の状況にかなりキャッチアップしている本なだけに惜しい。内容の更新と再配布がしやすい電子書籍版での対応が望まれる。

Atom実践入門──進化し続けるハッカブルなエディタ (WEB+DB PRESS plus)

Atom実践入門──進化し続けるハッカブルなエディタ (WEB+DB PRESS plus)

gihyo.jp

二年前に Emacs から Atom への乗り換えを試み挫折したが、この本をお供にもう一度トライしてみてもいいかな、と思った。

いなくなれ、群青

明け方になっても読み終わるまで読んでしまうくらいにはよかった。けど、内容よりも表紙がよかった。「にたりと笑う」という表現が不気味だった。

いなくなれ、群青 (新潮文庫nex)

いなくなれ、群青 (新潮文庫nex)

How Quipper tests software

Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ

という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。

実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。

f:id:a666666:20160708011955p:plain

サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある(インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ)これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがところどころインドネシア語が混じっている(「学習スケジュール」というボタンをクリックしろ、というシナリオだとすると、「学習スケジュール」という文言がインドネシア語で書かれており大半のスタッフには読めないのでテストシナリオ内に英訳が必要)

一番左のシートがテスト仕様書のマスターで、プロダクション環境へのリリースに備えてテストを実施するタイミングでシートをコピーする。テストケースは上から順番に実施していくとスムーズにこなせるようなストーリー仕立てになっているので、テスト担当者は指定されたOS・ブラウザ・デバイスを使って上から順にテストをしていき、うまくいったら 1 を、うまくいかなかったら 0 をセルに入れていく。全部終わって致命的なバグが無ければリリース(しばしば hotfix をあてて該当箇所を再テスト→リリース、としたりする)これをいまは週に一回やっている。当然テストケースは常時アップデートしていく。

Google Spreadsheets を使うと、冒頭の記事にある「Excel によるテスト仕様書の悪いところ」がほとんど解決できると思う。

  • Microsoft Office 不要。ブラウザがあればよい(さすがに Google Apps for Work は会社で利用してるよね、という前提)
  • 変更履歴が残るので Git 等でバージョン管理不要(あんまり強力ではないけど!)マスターシートから毎回コピーして過去のテスト実施分のシートはそのまま残すので、そっちでも履歴を担保できる
  • リアルタイムに複数人で共同編集可能
  • テストケースのレビューはスプレッドシート上では確かにやりづらい!(ここは Quipper でまだちゃんと取り組めてない部分)
  • ↑変更履歴のところに書いたとおり、マスターシートのテストケースが変更されても過去にテストを実施したときのシートは当時のまま残るので履歴は残る。経緯はマスターシートのセルへのコメントなどで残せる

おそらく Markdown で書くことよりも Git によるバージョン管理下におけること(つまり GitHub に置けること)を重視したのだと思うが、頻繁に変更したくなるドキュメントを Git で管理するのはあまりおすすめしない。実は Quipper では過去に技術的なメモを同じように Markdown で書き GitHub リポジトリで管理していたのだが(まさに Pull Request でレビューしたいという理由で)、当時は GitHub の Web サイト上でファイルを直接編集できなかったこともあり、ちょっとした変更を気軽にできず、結局すたれてしまった。その後それらのドキュメントを GitHub Wiki に移動したところ、以前よりはメンテナンスされるようになった。

テストケースのレビューについては、現状 Quipper には QA を専門に行う部隊がおらず、テストケースのメンテナンスはプロダクトの仕様に明るい数名の開発者とプロダクトマネージャが仕事の合間に行っている(あとは、テストの実施は開発者・プロダクトマネージャ・一部のセールス担当らが交代で行っているが、最新のアプリケーション仕様に追随できていないテストケースを見つけたらその都度テストケースの方を更新している)このように、正式なチームによる公式なレビューを行えるような体制がまだできていない、いわば「ボランティアベース」なやり方なので、メンテナにとってやりやすい形に最適化されすぎている面は否めない。いままさに QA チームを発足させて体制を整えたりする仕事に取り組もうとしているところだ。

個人的にはオフィスツール、特にスプレッドシートは大嫌いで、 Markdown はもちろん大好きだけど、テストケースの管理においてはスプレッドシートの柔軟さや一覧性の高さがプレインテキストの移植性に勝ると思う。

最近読んだもの

Udacity Turns 5, by Sebastian Thrun | Udacity

Coursera に比べると地味な Udacity が5周年。 Udemy と名前が似てて紛らわしいのも不運だった。

if we give every human being on this planet a fair chance, we will make a huge difference. Today, high-quality education is a privilege of the few. Our vision at Udacity is to make high-quality education a basic human right.

ここはよかった。Quipper に転職する決め手になったのも CEO の口からこういうビジョンを語られて感銘を受けたからだった。教育に関わろうとする誰もがこういうことを言うのだろうけど、でもいいものは何度聞いてもいいのだ。

しかしこの後に続くのが

If we do this, I truly believe we can double the world’s GDP.

だったのには「おいおい」とズッコケた。そりゃ GDP 2倍になったらすごいと思うけど、せっかく崇高な話をしてたと思ったら急に経済の話になるのはいい話が台無しな感じがしないか?

まぁでも他にもところどころいい話をうかがわせるフレーズがあって、全体的にはもちろんいい話だった。


メールできたレターはほぼ全文同じだったけど追加で割引のプロモーションコードつき URL がついてきた。これもちょっと興ざめな感じではあった。