自分の中で少し整理できたので改めて。ドキュメントは man journalctl で読める。それなりに長くて盛りだくさんだけど、必要なオプション一つずつ読んでいけばそこまで負担ではない。 ログをフィルタする書式の基本 -N, --fields -F, --field= -u, --unit= -t, --identifier= -S, --since=, -U, --until= --utc -g, --grep= -f, --follow -r, --reverse -n --lines= -o, --output= --output-fields= ログをフィルタする書式の基本 FIELD=VALUE という書式でフィルタする。 journalctl UNIT=ssh.service FIELD については man systemd.journal-fields で解説されている。よく知

2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数

というか、（かなり偏見を含む）空想。 blog.kyanny.me 「技術力が衰えつつあるおじさんエンジニアのキャリアパスをどうするか」という命題に対して業界は「経営がわかるCTO」「技術顧問」などの回答を示してきた しかしCTOも技術顧問も椅子に限りがあるため、業界は新たな受け皿を必要としていた 業界の平均年齢が上がり、他の業種と同様におじさんエンジニアたちは「管理職」になることを受け入れなければならなくなったが、この業界は「マネージャー（管理職） = 悪」という価値観が根強いため、業界人たちの意識変革が必要だった そういうもろもろの問題意識やら個々人の思惑やらが交錯した結果、どこかの誰かが「エンジニアのマネージャーは無能な管理職なんかじゃない！『髪の尖った上司』なんかじゃないんだよ！」といいだし、キャリアに不安を抱えていたおじさんエンジニアたち（と、そんなおじさんの背中をみてぼんやりと

Slack のリマインダー機能はもっぱら「メッセージにリマインダーを設定」する方法で使っている。書式が難しい /remind コマンドよりずっと使いやすい。自分自身への DM にリマインドしたい内容を走り書きして、そのメッセージにリマインダーを設定したりする。パブリックチャンネルに誰かが書いたメッセージにリマインダーを設定したりもする。 たくさんのメッセージにリマインダーを設定していると /remind list コマンドで一覧表示したときどれがどれだかわからくなって不便。 そこでメッセージ本文を展開して一覧表示する Slack アプリを作った。 /expanded-reminders というコマンドで呼び出せるようにした。やってみたらこれがなかなか便利。 Complete ボタンもつけてみた。 やりたいことがはっきりしていたので、Slack API のドキュメントをあちこち読みながらとに

社内でも話題に挙がっているし、登壇者の方々と以前お話する機会があり、改めて話を聞きたいと思ったので参加した。 懇親会で個別に質問した内容も含め、メモ 自分たちがサバイバルフェーズにいるということを認めたくない人もいると思うが、徹底させるにはやはりある種軍隊式のトップダウンのマネジメントをするしかないのか？ サバイバルフェーズの場合、とにかくこれと決めてやりきる、引っ張るのが大事。1on1とか、いわゆるふつうのマネジメントはその後のフェーズで活きてくる。 「メンバーが自走してくれなくて…」というのは、情報共有ができていないということ。知っている情報以上に目線は上がらない。経営情報など。 いまの自社に最も足りないのはこれなのでは？と思った。実際、何かにつけ「情報共有されてない、不透明だ」という声が挙がることが増えている。実はサインはとっくに出ていて、適切なアクションをとれていなかっただけなのか

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

半年以上経って、またいろいろ環境が変わった。 7月に会社で大きな組織変更があった。直属の上司が変わった（上司の肩書も変わった）。それと並行して組織の体制もガラリと変わった。詳しいことは Quipper組織変更と41歳CTOの今後 - Masatomo Nakano Blog に書いてある。 新しい上司は開発体制だけではなくマネジメントの体制もいろいろ整備してくれて、自分に関わる部分でいうと、自分が Engineering Manager としてマネジメントする人数が 19 人から 7 人に減った（新しく Engineering Managers が増えて、減った分はそちらにスライドした）。その上 Engineering Manager に求められる役割もより限定されたものになった。要するにマネジメント業務はずいぶん楽になった。 毎日ミーティングするために会社へ行き仕事のプログラムを一行も読

流量の多いリポジトリを Not watching にするだけではさすがに絞りが甘すぎたので、もう一段絞った。 ポリシーを変えたポイントは Pull Request は mention の有無にかかわらず全て通知を受け取っていたが、流量も内容も流し読みするのは無理になったので、見るのを諦めた 浮いた時間を Pull Request を能動的に見にいく時間にあてたい mention されていないイシューコメント等も同様なので、見るのを諦めた その代わり mention されているものを見落とさないようにしたい カスタマイズしたのは GitHub の Notification settings で以下を変更 Watching の Email 通知をオフにした Participating のみ通知を受け取る Email notification preferences の Pull Request

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

ものすごく良かった。とても面白かった。もっと早く読むべきだった。 「答えを出すだけの価値がある問題を見極める」「取り組むべき問題を絞り込んでから解き始める」これが大事なんだ、という論点をいきなり冒頭で述べている。言われてみれば（言われてからなら）その通りだと思えるが、初めて読んだときはけっこうな衝撃を覚えた。自分がこれまでいかに無駄なことをしてきたか気付かされた。 本書では「イシューの見極め」「大胆な仮説」「仮説に基づくストーリー」「仮説を検証する分析」「明快な結論」という順序で物事を進めていくのだ、と説明されている。その各項目の説明の仕方それ自体が、著者の提唱する「イシュードリブン」の考え方に基いて構成されている。つまりこの本は、本を読み進めるにつれて「考え方」そのものが例を変えながら繰り返しでてくるので、読めば読むほど考え方への理解が深まる、というつくりになっている。これに気づいたとき

Visualization Type: Chart Chart Type: Pie X Column: Type（円グラフを分割したい条件にあたるカラム） Y Columns: cnt（それぞれの条件で何件あるかを表すカラム） SELECT COUNT(*) cnt, Type FROM visualizations GROUP BY Type 考え方 円グラフを分割したい条件で GROUP BY する それぞれの条件が何件あるかを COUNT(*) で計算する 単純に一項目で分割した円グラフにする場合、結果データセットのテーブルのカラムは COUNT と 条件 の二つだけでよい https://demo.redash.io/queries/930 会社の re:dash と demo のやつはバージョンが違うので見た目がちょっと異なるが、考え方は同じ。

学習サービスのソフトウェア開発に二年半ほど携わってきて、「主役は教材コンテンツである」ということが、ペンキを重ね塗りするように最初はうっすらと、徐々にくっきりと、心の底から納得するというレベルで「理解」できてきた。自分が作っているソフトウェアはコンテンツを利用するためのツールに過ぎない、ということだ。 ツールがヘボいせいで教材が利用しづらくなり、結果的に教材そしてサービスの価値を毀損してしまうことは十分ありうる。しかし、ツールがどれほど素晴らしくても、教材コンテンツがヘボかったら価値はゼロだ。ダメな教材で勉強したいとは思うひとは誰もいない。ツールたるソフトウェアは価値を殺さず・より引き出すための引き立て役なのだ。 その前提に立ってようやく、あの「UI・UX」というやつが、限定的ながら理解できた。主題が明らかになって初めて、引き立て役が「何を」引き立てるのか、という議論が成り立つ。価値あるコ

こんにちは、Quipper です。話聞きにきてくれ!!! jp.techcrunch.com www.wantedly.com

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

実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=

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

社内勉強会でいろいろ教えてもらったのでメモ。トレンドと呼ぶには一、二年遅い。なお自分の考えを整理するために書いているものなので正確さは保証しませんしツッコミも不要です。 前提: 仮想マシンと仮想マシンイメージ VirtualBox とか、 AWS なら AMI とか。ホストマシン上で動作しているものが仮想マシンで、仮想マシンイメージは仮想マシンのスナップショットだったり、それをもとに新しい仮想マシンを作れる雛形だったり、くらいに理解しておけばよい。 Vagrant と Packer 仮想マシンと仮想マシンイメージの技術があるおかげで、作業環境（Mac とか Windows とか）上でプロダクション環境により近い環境を手軽に用意できるようになた。しかし仮想マシンの管理（起動したり、設定を変えたり）は手作業でやる必要があった（VirtualBox なら GUI でぽちぽちやったりとか） Vag

より正確に言うと、知見はプライベートな領域ではなくパブリックな領域に書いた方がよい。プライベート領域は Evernote に限らないし、パブリック領域もブログに限らない。 パブリックな領域に書く場合、プライベートな領域に書くのに比べて第三者の目を意識するぶん文章を推敲する機会が増える。 単に読み直すだけでも頭の整理に効果的だが、さらに正確を期すため調査や検証をすることもあるだろう。プログラミングのことであれば検証コードを書くとか、ツールのことであればドキュメントやソースコードを読むとか。そうすることにより、周辺領域も含めて理解が深まる。 また、公開に耐える内容にするために一般化する必要もあり、その過程で問題の本質をより正確に把握できる。 つまり、パブリックな領域に書く方が自分自身の勉強になる。 もう一つ、パブリックな領域で公開することで、他人が書いたより良い情報と競わせられる、というのがあ