2024-02-09 で GitHub に入社して丸 3 年経った。入社日は 2021-02-09 だった。 （これは 2024-03-06 に書いている） 3 年目はあまり良い一年ではなかった。年末年始は US テック業界にレイオフの嵐が吹き荒れ、GitHub でも 2 月にレイオフが行われた。比較的仲がよかったエンジニアも対象になり、数少ない「つて」がなくなった。春以降は同僚が育児休暇に入り（これはとても良いことだ）、仕事量が増えてオーバーワーク気味になった。勤怠の記録を振り返ると実稼働時間（残業）が顕著に増えたわけではないが、週末も翌週の仕事のことが頭から離れなかったり（まあそれは昔から割とそうだが）、仕事中も息つく暇なく次から次へと問い合わせをこなす感じで余裕がなかった。秋には状況が改善したが、知らずのうちにストレスを溜め込んでいたようで、職場に関連して思慮の浅さからくる失敗をして

ある Vercel ユーザーが「空っぽの状態」の画面に適切な導線が表示されているのを褒めたら、 Check out this delightful empty state by @Vercel! pic.twitter.com/qFkhFcUlwq— usrnk1 (@usrnk1) 2023年6月14日 Vercel の CEO が GitHub の new repo screen を参考にして意図的にやっているのだといい、 My love language is thoughtfully designed empty states See: @github's timeless new repo screen with `git` copypasta. https://t.co/ADFg52G7Ba— Guillermo Rauch (@rauchg) 2023年6月14日 それを受け

YAPC::Kyoto 2023 に参加した。久しぶりの京都、久しぶりのオフラインカンファレンス、久しぶりの発表で大いに充実した 2+1 日間だった。花粉症がひどくて体調がとても悪く、日中も夜もせっかくの交流の機会を満喫しきれなかったのは残念だった。 今回は特に Perl ハッカーたちのキャリアの話が印象深かった。 一つ目は @ar_tama さんの、あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで。「ハッカー」を再定義したうえで、技術・事業・組織の三軸を「ありたい自分 = will / いまある自分 = can / 自分への期待 = must」に応じてバランスよく伸ばしていくことの重要さを説いたスピーチで、狭い意味での、あるいは古典的な定義の「ハッカー」になれなかった多くの人々を救う、ベストトーク賞にふさわしい内容だった。 が、おれ自身はというと、まさに救われる一人で

toya.hatenablog.com id:toya といえば「年ごとにブックマークしたページでよかったもの集めた」の人という認識で、とにかくたくさんブログを読んで・ブクマしている人だなあと思っていた。おれのブログも読んでもらえていることは把握していて、「年ごとに〜」に自分のエントリが選ばれていると嬉しかったりスターがつくと嬉しかったりして、これがまた、ブクマ・スター数的には冴えないけど自分的には気持ちを入れて書いたものがよく選ばれていて、なんとなく親近感を持っていた。けど直接の関わりはないし、そもそもなぜ読まれているのかもわからない、謎の存在だった。 ので、YAPC::Kyoto 2023 のクロージング後の会場で Twitter の #yapcjapan ハッシュタグを見ていてこのツイートを発見したときはびっくりした。 スタッフの皆さまお疲れ様でした！！ありがとうございました！ #y

ソフトウェア開発者がよく使う言い訳の一つに「（レガシーシステムに）詳しい人がいないのでバグを直せない」というのがある。端的に言ってこれは単なる泣き言であり、最悪の言い訳だと思う。プロダクション環境で動いてるバイナリしかない、とかであればまだしも、ソースコードが手元にあるのに「詳しくないから直せない」は話にならない。ソフトウェアのソースコードを読み、理解し、修正方法を発見して、修正する。それはソフトウェア開発者の責務だ。「詳しくなれよ、それがお前の仕事だろ」という話だ。「詳しくないから直せない」は、自分にはソフトウェアを理解する能力がないと、自分は無能だと言っているに等しい。せめてもっとまともな、たとえば「詳しい人がいないので修正にどの程度の時間を要するかわからない（一ヶ月？一年？一生？）。完了時間が不明なタスクに割ける時間はないので着手できない」のような言い訳をすべきだ。

↓を読んで、タイトルで脊髄反射したくなっただけ。 トラックバックがあった時代のブログ作法ってこういう感じだったな、と懐かしくなった。タイトル含めて他人のブログ記事にお返事するというか、アンサーソングというか。もちろん元記事はお前に向けて書かれたものではないので返事もクソもないだろ、という話なのだが。 おれはインターネットにテキストを書かずにはいられない人間で、これを禁じられたら精神に失調をきたすこと間違いなしと思う。なので逆に書かずにいられる人たちのことが正直いうと信じられない。しかし世の中の大半の人はウェブ日記を書き続けたりしない、ということに十年くらい前から徐々に気づき始めて、いまでは確信に至った。これはおれの才能だ。インターネットにテキストを書き続けられる才能。なんの役に立つんだと言われれば特になんの役にも立たないとしかいいようがない、しょぼい才能だけど、それでも稀有な才能には違いな

I am thrilled to announce that I joined GitHub as an Enterprise Support Engineer. GitHub was one of my dream companies for years. I am so happy to be a member of people who make a platform where the world builds software. I am looking forward to helping our customers build software to make the world a better place.

cron ジョブを監視したい。監視したい項目は以下。 cron ジョブの実行が開始されたかどうか cron ジョブが正常終了したかどうか cron ジョブの所要時間 このような課題を解決するソリューションとして Dead Man’s Snitch を使ったことがあるが、他にも複数の類似サービスが存在する。 Cron Job Monitoring というジャンルのようだ*1。 Dead Man’s Snitch は 1 の監視に主眼をおいたサービス（だと思う）。 Cronitor は 3 の監視もカバーしているっぽい（が試してはいない）。他のサービスもおそらく似たようなものだろう。 cron ジョブ監視専門のサービスを導入するのも良いが、 mackerel で実現できないか、と思ったので考えてみた。 1 と 3 は、 cron ジョブの所要時間を計測してサービスメトリックとして投稿する その

Is it time to change the name? · Issue #8091 · rubocop-hq/rubocop · GitHub Rubyists, we must do better | timriley-info The RuboCop Name Drama Redux | Meta Redux 件の騒動を知る前に「Black Lives Matter の流れに乗って名前変えたらいいんじゃねーの」とは思った 難癖をつけられて揉める前に済ませておくほうが楽そう、とか FactoryBot のことを当然思い出しながら 個人的に RuboCop は好きではなく愛着もないので、というのもある リネームしたら？という提案自体は、まぁ妥当な範囲内だと思う master ブランチやめます話もあることだし https://twitter.com/mislav/status/1270

会社がスタートアップだった頃に「この人いざってときに頼りになるなぁ…」と思った人たちには、共通する特徴があると思う。 プロフェッショナルだけど、サラリーマンではないのだ。 仕事に対する責任感が人一倍強く、締め切りを守る。そのためならオーバーワークを厭わない。基本的に物事を他責にせず、周りがどうだろうが自分の責任として仕事を完遂する。無茶な要求にはきっぱりノーと言うが、現実的な代案を提示して着地させるし、そもそも「無茶」と判断する基準が高すぎるので、並の人ならとっくにサジを投げるような仕事も涼しい顔で片付ける。 それほど自分の仕事を終わらせることにこだわるのに、「仕事だから」を逃げる理由にしない。自分の仕事はここまで、とか、この仕事は他の人・チーム・部署の仕事だろう、とか、残業することになってしまうので、とか、基本的にそういう言い訳をしない。また休出しちゃったよ、などと軽口を叩くこともあるが

「マネジメントって本当に必要かなぁ。。」と日々疑問を感じているので（する側としてもされる側としても）、何か得るものがあればいいなと思って参加した。 ワークショップもプレゼンテーションもなかなか良かった。三点にはまとめきれないので、箇条書き。 チェックイン（アイスブレイク）のために行ったムービングモチベーターズ・ゲームはシンプルで良かった Management 3.0 については、「自己組織化されてて裁量の大きいところで働くほうがいい、ってのはみんなわかってるよなぁ。でも現実にそうしていく難しさがあるんだよなぁ。『フレームワークではなく概念』らしいから、みんなが共通理解を確認しながら継続して改善していく取り組みが大切、ということなのかなぁ」と思った フィードフォースの鈴木さんによる事例紹介のなかで挙げられていた ADKAR （変革管理）の話が素晴らしく、目から鱗だった。要は丁寧に段階を踏まな

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

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

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

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

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

知人が「新しいソフトウェア技術を習得するためにコードを書いたりしているが、まだ手に馴染まなくて」と言っていて、いい表現だなと思った。 プログラミングやソフトウェア技術の学習方法としてよく紹介される「写経」はまさに、その言語やソフトウェアの使い方を手に馴染ませるための訓練だ。だから、文字通り一字一句書き写すのでも、アレンジを加えながらでも、どちらでも良いのだ。 とにかく手を動かすことだ。考えながらでも、何も考えなくても、手を動かした時間は無駄にならない。

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

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