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

お題「エンジニア立ち居振舞い」 オンラインのコミュニケーションで即レスを心がけている、という話を何度か書いたが、オフラインでもそうしているよ、という話。 blog.kyanny.me blog.kyanny.me やってることはオンラインより単純で、 話しかけられたら即座に応対する。そして、その場の会話で、できるだけ多くの疑問に答え、できるだけ多くの課題を解決する。自分一人では解決しきれなかったら、より適切な人に繋ぐ。 手が放せないときは「今は手が離せないから、○分待ってくれ」と言う。短時間なら待ってもらうし、長くなりそうなら手が空き次第こちらから連絡すると告げて、後回しにさせてもらう。 これだけ。当たり前のことだけど、疎かにしがちなので、たまに意識するようにしている。 短期的にみれば自分の時間をより多く費やすことになるが、チーム全体でみると、こういう風に都度発生する非公式な「打ち合わせ」

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

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

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

「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが

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

ginzarb.doorkeeper.jp Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワーク という勉強会で、 Quipper で JavaScript (CoffeeScript) と Rails によるシングルページアプリケーション開発をどうやっているかについて発表しました。お声がけいただいた @willnet さん、 Ginza.rb のみなさま、ありがとうございました。 発表で使った資料はこちらです。 Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 もともと YAPC::Asia の CFP に応募して落選したネタだったのだが、ある意味で自分がこの 2 年間やってきた仕事の集大成ともいえる内容だっ

Bundler.with_clean_env と bundle install --gemfile について追記しました bundle exec した環境下でさらに bundle exec したいことがある。 bundle exec rake resque:work で起動した Resque ワーカーのなかで system("bundle exec rake spec") のような外部コマンドを呼び出すとか。ありますよね。ぼくは最近ありました。そしてハマった (そしてググりづらかった) のでこれ以上犠牲者を増やさないためにブログに書く。 bundler は実行時にいくつかの環境変数を定義するが、この場合問題になるのは BUNDLE_GEMFILE と GEM_HOME だ。 BUNDLE_GEMFILE は bundler が参照する Gemfile のパスで、 GEM_HOME は ge

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

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

shibuyarb.doorkeeper.jp LT やらせてもらいました。資料は remark.js で作りました。スライドの画面クリックで進みます。GitHub Pages でも公開しています。 What I have learnt about React so far... - Shibuya.rb 20150520 雑感 説得力を増す目的でサンプルコードを書いたが、しっくりくるようにはなかなか書けなかった Flux については全然踏み込んだ話はできなかったけど少しフィードバックをもらえてよかった remark.js 使ったらスライド作るのめっちゃ楽だった。画像のサイジングとかだけちょっと工夫が必要だけどマークダウンやっぱり楽 あと GitHub Pages で気軽に公開できて更新も簡単なので発表前にスライドの URL シェアとかも気楽にできる ただしブログに貼り付けるのは ifra

rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。

自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面

笹塚に創価学会の施設がある。Ingress をやっていて何気なく Hack したポータルがそうだったのだが、ポータル名に悪意を感じた。 特定の新興宗教を邪教と呼ぶのは個人の自由だが、不特定多数の目に触れるある種パブリックな場所にあるものに対して偏った主観に基づくラベルをつけるのは感心しない。自分はさほど熱心なエージェントではないのでゲームにもコミュニティにも強い思い入れはないが、こういうつまらないイタズラで Ingress の評判に傷がついたら残念に思う人も少なくないと思う。 ポータル名の編集をリクエストすることができたので、看板に書いてあった「創価学会 渋谷平和会館」という正式名称に変更要請しておいた。気がついてよかったと思う反面、日本中にこんなのがあるのかと思うと気が滅入る。 2015年4月9日更新 Accepted. https://www.ingress.com/intel?ll=

Manage Jenkins -> Configure System から Global properties -> Environment variables のチェックを入れること（デフォルトではチェックされていない==無効）有効になってないといくつかの環境変数がジョブから参照できないらしい。参考 [#JENKINS-16225] Add note to env-vars.html so user knows that Environment variables configuration is requried to export JENKINS_URL, JOB_URL, BUILD_URL - Jenkins JIRA Jenkins URL は同じ Configure System ページの下のほうにある Jenkins Location -> Jenkins URL に入力す

↓こういう風にハイライトしたい部分だけくり抜いた画像を作る方法（それ以外の部分にマスクをかけて目立たせなくする方法）。こういう画像をなんと呼ぶのか知らないので言葉でうまく説明できない。呼び方をご存知の方は教えてください。 Mac OSX 10.9.5 の プレビュー.app バージョン 7.0 (826.4) です。 元画像 この画像の左上のプロフィール部分だけ目立たせたい。そこ以外の部分を暗くすることでハイライトさせたい。 作り方 1. 楕円選択してCmd+xでハイライトしたい箇所を切り抜く 2. 不透明度50%の黒塗りつぶし長方形を全体にかぶせる 3. 切り取った部分をCmd+vで貼り付ける 貼り付けると切り取られた部分が半透明の黒い長方形より上のレイヤーに来るので、ちょうどくりぬいた部分の真上に来るようにがんばって位置を合わせる。残念ながらぴったり位置を合わせてくれるガイドアシスト機

Pull Request ベースの開発手法（いわゆる "GitHub Flow" というやつ）では、未完成のブランチに "WIP" という件名をつけて作業中である旨を示しつつ途中経過もレビューしてもらう、というのをよくやります。 Quipper ではそれに加えて "DONT MERGE" とか "DO NOT MERGE" というのもよく使っています。 WIP と同じ意味で使うこともあれば、レビューの過程で発生した議論にまだ決着がついていないのでマージしないでね、という意思表明として使うこともあります。 僕は一日にだいたい十個弱の Pull Request をレビュー・マージしています（個人差はありますが Quipper のデベロッパーの多くは似たようなものです）レビュー・マージのタイミングははやいほうが良いので、一日に少なくとも二回か三回は Organization の Pull Req

Quipper, 採用は基本的に 24/7 いつでもウェルカム！なんだけど、とはいえ対外的にちゃんと求人を掲載して「募集中ですよ！」とアピールする必要もあるよね、ということで、 Wantedly でソフトウェアエンジニアと DevOps エンジニアの採用を開始した。 Quipperで新しい学びの形を創造したいエンジニアをウォンテッド！ - Quipper Ltdの求人 - Wantedly https://www.wantedly.com/projects/6602 @ffu_ とチャットで「こんなことやります」欄の内容を相談していて、「改めて考えると、自分たち普段いろんなことをどうやってるんだっけ？」と考えた末にひねり出した一文がこれ。 Quipperのエンジニアリングは「生産性」にフォーカスしています。運用に人手のかかるインフラ部分はHerokuやCircleCI等の外部サービスを積極

http://b.hatena.ne.jp/entry/staff.hatenablog.com/entry/2012/02/13/172342 はてなブログProに対して「高い」とか「競合に比べて機能が少なすぎる」とか「腕に覚えがあるエンジニアならさくらのVPSで全部自力で作れてしまう」とか、肯定的ではないコメントが散見されるので、初日にProにした俺ががなぜ1年分8200円を払う気になったのか書いてみる。 高い？ 本当に？他が不当に安すぎるのでは？これは正直いって職業柄ふつうの人に比べて金銭感覚が狂ってる自覚はある。けどあえて書くと、ウェブサービスの価格は安すぎる。BtoCなウェブサービス運営の仕事に就いたことがある人ならば同意してもらえると思う。フリーミアムとか無理だから。はてなブログはリリース当初から記事下にアドセンスをでかでかと貼っていて評判が悪かったけど、広告モデルは規模が全て