Subscribed unsubscribe Subscribe Subscribe

@kyanny's blog

Write down what I learnt. Opinions are my own.

最近読んだもの

Reading

Solving the OPTIONS performance issue with single page apps | SOASTA

リバースプロキシを挟めばあっさり解決するけど、そうできない場合もあるし、仕組みと仕様を押さえておくに越したことはない。

Workspaces - Persistent authoring in the DevTools - Google Chrome

使い方がわかりづらいし、.jsはローカルで書き換えるとエラーがでるし(だったらこの機能意味あんのか?)Chrome Dev Tools - Workspace mapping mismatch - Stack Overflow というのを見つけたが Paul Irish の回答も意味わからんしで downvote しておいた。未だにうまくできてない。

What kind of company are you? – Signal v. Noise

company を person に置き換えても全く同じことがいえる。悪い知らせほど隠さずできるだけはやく報告する勇気を持ちたいものだ。

GitHub: Scaling on Ruby, with a nomadic tech team — > S C A L E — Medium

いい話だった。

  • 誰もが解いてる問題(フレームワーク作るとか)ではなく自分たちしか取り組んでいない問題(巨大な Git ホスティング)を解決するためのものだけ自ら作る。価値のあることに集中する、の線引きとしてわかりやすい。
  • Hubot であらゆるコマンドを実行できるのは単に chatops 便利とかいうレベルの話ではなく、オープンチャットで全員に操作ログが見えることで、いま誰が何をしてるか共有できる、作業の重複もない。この文化、考え方は素晴らしい。

AWA

AWA の無料期間が終わったので迷わず Standard プラン(月額 960 円の高いほう)を契約した。それと前後して Apple Music は無料期間中だが次回以降の購読停止をしたので、音楽ストリーミングサービスは AWA のみ使うことになる(ストリーミング以外の音楽ライブラリも別段充実していなかったので、要するに音楽はほぼ AWA のみで聴くことになる)

 
アニソンやポップスなどのラインナップが自分にとっては豊富で、適当にプレイリストを再生するだけで飽きずに聴いていられるのが決め手になった。アプリの UI も見た目とは裏腹に片手でも使いやすくてよい。仕事中も聴いてるのでランドスケープモードとデスクトップ版が欲しい。

Quipper のエンジニア採用プロセス コードテスト編

Quipper ではエンジニアを採用するにあたり、候補者に複数回の面接と、コードテストのための課題提出をお願いしている。

今年の春から夏にかけて、前任者から日本オフィスのエンジニア採用に関わる仕事を引き継いだとき、採用プロセスを変更した。それまでは一部の採用担当者だけが面談と合否判断をしていたが、エンジニア採用の場合は原則としてエンジニア全員が面談に参加可能とし、課題のレビューも全員が行うようにした(カレンダーに面談の予定を作るとき全員招待する。辞退しても構わない)そして合否判断の議論も原則としてエンジニア全員で行うようにした。

これによってブラックボックスだった採用プロセスを透明化できたが、課題のフィードバックを共有するとき、先に発言した人の意見に影響されてしまってフェアな判断が下せなくなる懸念があった。そこで、以下のようなやり方でフィードバックを共有することにした。

  • フィードバック記入用のテンプレートとなる Google ドキュメントを用意する。記入すべき項目は、
    • 合否の判断(yes or no; 必須)
    • 良いポイント(任意; 複数可)
    • 悪いポイント(任意; 複数可)
    • 総評コメント(任意)
  • 課題のコードレビューをしたエンジニアはテンプレートの Google ドキュメントをコピーして自分専用のフィードバックシートに記入する
  • 記入が終わったら採用プロセスのコーディネーターに Google ドキュメントを共有する
  • コーディネーターは全員分のフィードバックが集まったら(または提出期限がきたら)内容をとりまとめる
  • 合否判断が明らかな場合は結果に従い採用プロセスが進んだり終わったりする。明らかでない場合はエンジニア間で議論し、それでも決まらなければ CTO に判断を委ねる

こうすることで、他人の意見に影響を与えてしまう・影響を受けてしまう懸念をなくすことができた。また、合否判断を yes or no の二択としたことで曖昧さがなくなり、ジョエル・スポルスキーの本に書いてある「いいと思うけど僕のチームに入れるのはちょっと」みたいなアンチパターンを避けることができる。日本オフィスのエンジニア採用だけでなくグローバルでエンジニア採用する際も同様のやり方をはじめたので、各人が合否の意思表示をはっきりさせるのがより大事になってくると思う。


このやり方は、採用という非常にセンシティブな情報を扱うプロセスに関与する人数が増えてしまうし、一票の重みに差がないので、合否判断を下すエンジニア間の実力差が大きい場合は適用するのが難しいかもしれない。 Quipper 日本オフィスの場合は、在籍しているエンジニアが全員十分なキャリアと見識を兼ね備えており、センシティブな情報を共有しても差し支えなく、また実力差による一票の不平等も発生しないと判断した。組織がかわるにつれて、このやり方もかわっていくことになるだろう。

採用プロセスのコーディネーターはあくまで事務手続きや諸連絡などの雑用を行う調整役に過ぎず、マネージャーのようなものではない点は強調しておきたい(少なくとも自分は単なる調整役であるという意識でその仕事をこなしている)フラットなエンジニアリングチームは「どのコードをマージするか」だけでなく「どの候補者を仲間に迎えるか」の議論においても対等な関係であるべきで、そこに肩書きはいらない。