開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ

blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき

お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか

お題「エンジニア立ち居振舞い」 同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる） で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓ 作業の進捗をチャットに逐一報告する production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用

note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

著者の id:tomoya さんから本をいただきました。ありがとうございます。 d.hatena.ne.jp 宣伝に偽りなし。 Atom の操作方法から内部構造まで丁寧かつ徹底的に解説した一冊だ。 Chrome DevTools しかり、 Web Components しかり、 2016 年に書籍で読む価値のある Web 技術の話であり、それぞれ単体で一冊の本になってもおかしくないトピックだ。それをテキストエディタの解説書でカバーしてしまう発想には脱帽する。 本題のテキストエディタの解説部分も抜かりない。まず目次からしてひと味違う。操作の名前（日本語）と対応するコマンド名（英語）が併記されているので、目当ての操作を見つけたらコマンドパレットにコマンド名を入力してすぐに使うことができる。さらに各項目の解説ページにはそのコマンドを呼び出すデフォルトのキーバインドも掲載されているので、メニューか

ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を

Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ

ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不

Quipper では日本オフィスの開発者を中心に、 Qiita::Team を導入して社内のドキュメント共有を行なっている。書かれる内容は日報が多いが、技術 Tips の共有やチャットでは適切でない込み入った技術的問題を解決する議論の場としても活用している。 なぜわざわざドキュメント共有？ていうか日報書くなんてダサすぎじゃね？そう思ったあなた、日報を見くびっちゃいけません。上手に運用すればナレッジシェアやコラボレーションのみならず、チームビルディングにも役立つんです。 上手に運用された日報には前例がある。ペパボの社内 SNS であるタンパクがそれだ。毎日スタッフ全員が日報を書くきまりなのだが、本来の目的である業務内容の記録以外に一言コメントを書く欄がある。定型文で済ます人もいればブログ並の長文を書く人もおり（それはわたしです！）、これがそこらの SNS なんかよりよっぽど面白いコンテンツな

コードレビューするときに考えること 開発チームもコードベースもプロジェクト規模も大きくなってきたので、もはや実装上の設計の細かい点まで指摘することが難しくなった。個人的な趣味で、自分が直接関わっていないプロジェクトの issues も全部眺めているが、それでも内容を把握しきるのは無理。なので、コードそのものに対する指摘は少なくなり、その代わりに「第三者があとでこのコードを見たとき、意味がわかるだろうか」と考えて、わからなそうだなと思ったらたとえ自分には意図が理解できたとしても「意図がわからないのでコメント書いてくれ」とか指摘するようになった。コードレビューをしているのに、コードレビューをしていない人の気持ちになる、みたいな感じ。ちょっと幽体離脱っぽい。違うかもしれない。 仕事のやり方について考えること 一般に、能力が高い人ほど仕事が増えがちだし、責任感の強い人ほど仕事を抱えてしまいがちだ。

二年前に autodoc を導入したが、現在はもはや誰も見てないし使ってないね、という話を社内でしたら、「使い始めた話だけじゃなくて、やめちゃった話もブログに書くべき」と指摘され、確かに誠実な姿勢とはいえないなと反省したのでこの記事を書いています。 恥を忍んで現状を明かすと、 master ブランチに push されたタイミングで実行される Jenkins のジョブが半年ずっと fail していた、ということに昨日気づいた体たらく。そもそも生成された markdown ドキュメントを push していたリポジトリがとっくの昔に削除されていたと思っていた。 うまくいかなかった原因の分析: Quipper の Internal API は非常に込み入ったデータ構造を返すものがほとんどで、お世辞にも「きれいな RESTful API」とは言えない。なので request spec を書く際に、完

チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身

Quipper ではエンジニアを採用するにあたり、候補者に複数回の面接と、コードテストのための課題提出をお願いしている。 今年の春から夏にかけて、前任者から日本オフィスのエンジニア採用に関わる仕事を引き継いだとき、採用プロセスを変更した。それまでは一部の採用担当者だけが面談と合否判断をしていたが、エンジニア採用の場合は原則としてエンジニア全員が面談に参加可能とし、課題のレビューも全員が行うようにした（カレンダーに面談の予定を作るとき全員招待する。辞退しても構わない）そして合否判断の議論も原則としてエンジニア全員で行うようにした。 これによってブラックボックスだった採用プロセスを透明化できたが、課題のフィードバックを共有するとき、先に発言した人の意見に影響されてしまってフェアな判断が下せなくなる懸念があった。そこで、以下のようなやり方でフィードバックを共有することにした。 フィードバック記入

Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して

Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな

毎年恒例の振り返り。今年は面倒くさいので日本語で。 Look back 2012 - @kyanny's blog Look Back 2013 - @kyanny's blog 1-3月 TOEICを受けてスコアは720点だった。仕事は昨年から引き続きのプロジェクトに関わっていたが、政治色が濃くて自分は蚊帳の外だったので傍観してる感じだった。 4-6月 仕事で JavaScript/CoffeeScript を書く機会が増えてきたので JavaScript 関連の技術書を多く読んだ。 Chrome 拡張を作ったり Chromecast SDK で遊んだりしていた。仕事は別プロジェクトで技術チームのリードっぽい役をちょっとやって毎週のチャットミーティングを主催したりした。 7-9月 この時期が一番充実していた。仕事でフィリピンに出張した。 RubyKaigi 2014 で英語スピーチをした