VP of Engineering やめた - @kyanny's blog
2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
「はてなブログ大賞2016」の選者になりました - @kyanny's blog
ご縁があって、「はてなブログ大賞2016」という企画で“推しエントリー”を選ばせていただきました。 blog.hatenablog.com はてなブログの企画にお声がけいただくのは、「はてな エンジニアブロガー祭り」以来です。もう三年も経ったとは...。 私がイチオシに選んだエントリーは...「はてなブログ大賞2016」をご覧ください！ ちなみに、イチオシが他の選者の方とかぶったときに備えて次点に選んだエントリーは「結婚披露宴の写真を頼まれても、お断りする理由がある - 紺色のひと」で、コメントは、 いわゆる「カメラ女子」と対決、もとい、さりげなくフォローにまわったエピソードが印象に残りました。かくいう私も友人の結婚式の写真撮影を引き受けたことがあるのですが、デジタル一眼レフカメラを買ったばかりで写真撮影の基本的な知識も無い素人には荷が重すぎました。幸い、友人はプロの写真撮影も手配していた
簡素な RequestBin みたいなのを rackup するワンライナー - @kyanny's blog
$ rackup -b "run ->(env) { lf=%Q,\n,; [ 200, {'Content-Type' => 'text/plain'}, [env.sort_by{|k,v|k}.map{|k,v| %Q,#{k}=#{v},}.join(lf)+lf*2+env['rack.input'].read+lf] ] }" ワンライナーでやる必要は無いけど、なんとなく RequestBin （というか外部）にログを残したくないが HTTP リクエストを調査したいというときに。 Transfer-Encoding: chunked を避けたい場合はこっち。 $ rackup -p 9393 -b "run ->(env) { lf=%Q,\n,; body=env.sort_by{|k,v|k}.map{|k,v| %Q,#{k}=#{v},}.join(lf)+lf*2+e
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
RubyConf Taiwan 2012 - @kyanny's blog
RubyConf Taiwan 2012 was held at December 7, 8. I attended this conference and had great experience. Thank you for the people who I met at Taiwan. Conference This is my first time attendance of oversea conference. It was very exciting for me. I thought some of the talks are focusing a common awareness of the issues with Japanese developer community. DevOps talks are also familiar topic in Japan. I
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
クローン病患者が MYCODE の遺伝子検査を受けてクローン病の発症リスクを調べてみた - @kyanny's blog
自分は十数年前からクローン病を患っており、現在も治療中の身なのだけど、以前から「遺伝子検査を受けたらクローン病の発症リスクはどのくらいと出るんだろう」とずっと気になっていた。先日 MYCODE が 40% オフキャンペーンをやっていたので、申し込んで検査を受けてみた。 なお、 MYCODE の説明事項において、 本検査結果に示される病気の発症リスクや体質の情報は、個人のリスクを示すものではなく、特定の塩基配列に関する統計的な確率を相対的な数字として表したものであり、特定の塩基配列を持つ集団の平均的な傾向及びリスクです。さらに、環境要因や生活習慣等、他の要因によっても大きく左右され得ます。お客様ご自身の健康状態・体質そのものを示すものではありません。 と説明されており、自分はこれを読んで内容について理解・同意しているので、自分の遺伝子に対するクローン病の発症リスクが高いとでようが低いとでよう
最近思ったこと - @kyanny's blog
Medium のはくフィード (RSS2.0) は 2015 年にもなって全文配信していなくてマジかよって気持ちにさせられた。また Medium を使いたくない理由が一つ増えた。「ブログと似て非なるもの」はその姿形の変え方が巧妙になってきているので注意深く避けなければならない。インターネットにおける自分の魂を売り渡すことにもなりかねないのだから。 物分りの悪い役人というのはたちが悪い。迂回できないし他の道も無いので、ニュータイプ同士なら見つめ合うだけで分かり合えるような話を延々としなければならない。当方ただの人なのでどのみち無理なんだけど。 プログラミング・プログラムすること、ないしコーディング・コードを書くこと、を「開発する」「実装する」と呼ぶのは内心気持ち悪いと思っていて、でもまだ妥協できる。しかし「製造」という表現は無理だ受け入れがたい。それは量産品に対して使う言葉だ。おれの仕事は、
掛け算の定義 - @kyanny's blog
Why 5 x 3 = 5 + 5 + 5 Was Marked Wrong — Math Memoirs — Medium 日本でもよくインターネットで「こどもの算数のテストの結果が納得いかない」みたいな話題が盛り上がる。同じような話が海外でもあるというのが新鮮だったので読んでみた。 5 × 3 を 5 + 5 + 5 と書くと不正解で 3 + 3 + 3 + 3 + 3 と書くと正解なのは、掛け算の定義に基づくらしい。a × b は b を a 回足したものだ、と定義されているので、5 × 3 は 3 を 5 回足したものと考えるのが正しく、5 を 3 回足したものと考えるのは間違っている、従ってどちらの計算も結果は 15 になるが、計算過程の考え方において間違った解答なのだ、ということらしい。 理屈はわかったが、どうもすっきりしない。 俺は学校で掛け算の定義をここまで厳密に習った覚え
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
最近思ったこと - @kyanny's blog
コードレビューするときに考えること 開発チームもコードベースもプロジェクト規模も大きくなってきたので、もはや実装上の設計の細かい点まで指摘することが難しくなった。個人的な趣味で、自分が直接関わっていないプロジェクトの issues も全部眺めているが、それでも内容を把握しきるのは無理。なので、コードそのものに対する指摘は少なくなり、その代わりに「第三者があとでこのコードを見たとき、意味がわかるだろうか」と考えて、わからなそうだなと思ったらたとえ自分には意図が理解できたとしても「意図がわからないのでコメント書いてくれ」とか指摘するようになった。コードレビューをしているのに、コードレビューをしていない人の気持ちになる、みたいな感じ。ちょっと幽体離脱っぽい。違うかもしれない。 仕事のやり方について考えること 一般に、能力が高い人ほど仕事が増えがちだし、責任感の強い人ほど仕事を抱えてしまいがちだ。
Ginza.rb で Quipper のシングルページアプリケーション開発について発表しました - @kyanny's blog
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 年間やってきた仕事の集大成ともいえる内容だっ
ConoHa を vagrant up - @kyanny's blog
ConoHa の API は OpenStack らしいので vagrant-openstack-provider が使えた。 gist6ce12317582b130fe4ff VM 作れるし消せるし vagrant ssh もできるが、エラーが出る（完全互換ではないのだろうか？） メモ: 事前に ConoHa のユーザー登録が必要。クレジットカードの登録も必要。このページから登録したら1000円の無料枠がついてきた。アフィリエイトリンクもどうぞご利用ください。 https://manage.conoha.jp/API/ から API ユーザーを作る必要がある。 API ユーザー名は自動発行され、自分で決められないし、変更もできない。パスワードはあとで変更可能。 API ユーザーは一つしか作れず、一度作ると削除できない。 API ユーザー名とパスワードは Vagrantfile で利用する
Qiita::Team やめた - @kyanny's blog
Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
YAPC のトークに応募した - @kyanny's blog
ぎりぎり滑り込みで YAPC::Asia Tokyo 2015 のトークに応募した。 Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 - YAPC::Asia Tokyo 2015 もうすっかり Perl を使わなくなってしまったし、個人的に「プログラミング言語のカンファレンスなのにそれとは無関係の話をするのはどうなんだろう」という葛藤も感じるのだが、 Perl コミュニティからオープンソース的な「シェア・与えるカルチャー」を学び、 YAPC に参加することでカンファレンスの楽しさを知り、そのうえスピーカーとして登壇する経験も YAPC で積ませてもらった身として、お世話になってきた YAPC が一旦区切りを迎える節目の年に自分はいったい何ができるだろう？と考えた結果、
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
渋谷.rb[:20150520] で「入門 React」を読んで思ったことを発表しました #shibuyarb - @kyanny's blog
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
![渋谷.rb[:20150520] で「入門 React」を読んで思ったことを発表しました #shibuyarb - @kyanny's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/ff7144548d4bf866e33abc382a3dc55c619fb123/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729888747%2F8454420450095117952%2F1432208426)
ES6 Generator と Ruby の Fiber と Python 2 の generator - @kyanny's blog
CodeGrid で ES6 Generator の記事を読んだ。 ECMAScript 6の新機能 - Generator | CodeGrid Ruby の Fiber のようなものなのかな、と思って書き比べてみたら少し違うところがあった。 function* generatorFunc(a) { console.log(a); var b = yield 1; console.log(b); var c = yield 2; console.log(c); } var generator = generatorFunc('a'); console.log(generator.next('b')); console.log(generator.next('c')); console.log(generator.next('d')); この結果は $ node -v v0.12.0 $
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
