Ruby/Rails の勉強に何読んだらいいかと聞かれたとき

「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。

「読める」になるために

言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。

Ginza Rails27 igaiga - Speaker Deck

著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。

たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。

できることを知る

は読んでいて面白いのでオススメです。まずはサラッと目を通す感じ。

なんか書く

Rails で何かアプリを作る。まず 1 個ぐらいは手を動かしておきたいね。

作るものが思いつかなかったら、Rails Girls のガイドを見ながら画像アップロード機能のある Web アプリを作ったり、Rails チュートリアル をやったりすると良いんじゃないか。

チュートリアルは長いので、サクッと rails new してナルホドと言えるぐらいのサイズで良い。

ライブラリを知っていく

「何か gem があるんじゃないかと疑う」を基本行動としながらしばらく暮らす。

The Ruby Toolbox は昔からあるサイトなので、かなり古いメンテされていない (2010 ぐらいが最終更新の) ライブラリも載っている。古いのは見なかったことにしつつ、一番有名なのを触ると良いです。基本的に困るまでは有名どころしか使わなくても生きていける。

awesome-ruby はいつもの awesome- シリーズです。ちゃんとメンテされている（感謝）

アプリを作ったら dependabot や renovate でバージョンアップの指示があるたびに中を読みながら上げていくのも良いですね。現在進行形で開発されている現場の空気が分かっていくので。

Real World Rails にある各アプリの Gemfile を読むのも効いてきます。これも世界の現場感が身に付いていく。

こういう「gem を読む」を自然にやるためには、gem-src と ghq を入れておくのがオススメです。自分のアプリと gem との距離感がどんどん減っていって「読むのがふつう」になっていきます。

実践的な開発に参加する

Enumerable や ActiveSupport の core/ext でできることを知って、代表的な gem が分かっていたら、ほぼコードの読み書きする分には困らなくなっていると思う。

  • テスト
  • API サーバ
  • パフォーマンスチューニング
  • CI/CD

辺りが次の話題かな。

まさに Kaigi on Rails はこういった話題を取り扱っているのでぜひ見て欲しい。

他は

とかになるんじゃないか。

手当たり次第に読む

あとは技術的な興味をどこまで持ち続けられるかみたいな勝負になる。新しい話題が次々飛び込んでくるように自分のアンテナをしっかり張っておきましょう。

という感じ。ではでは ruby-jp や各地域 Ruby コミュニティ、カンファレンス等でお会いしましょうﾉｼ

作業者じゃなく開発者でありたい

自分がこうありたいというメモ。

作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。

これは今 GPT-4 に聞いた。

Q: 作業者と開発者の違いを100文字ぐらいで教えて。

A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。

単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている

  • コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい
  • 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい

そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つけるのが、仕事をしていて一番面白いところだと僕は思っている。

仕事の定義を

理想の状態になることを阻害している問題を見つけて，
問題を解決する手段を考え，解決すること

と 以前書いたことがある。

機能やサービスを開発する過程で出てくる課題を、よりクリエイティブに解決するのは、全能感が出て気持ちいい。

新しいアイディアやアプローチを考えて実際のプロジェクトに取り入れていくのも、テクノロジーやテクニックの進歩によってより良い状態に辿り着いていると思う。

常に新しい方法を模索する姿勢は、成長や、自己実現の欲求に効く。自分のアイディアを形にする体験、形にしたものに対してユーザーからフィードバックを受ける体験が、僕らがプログラマになった原体験だろう。

組織の目標達成への強い関与

  • より広い視野で物事を考え、計画をする体験を得たい
  • 複雑な状況を解きほぐして解決する経験をもっと積みたい

中腹じゃなく頂上に立てってヤツかなぁ。

広い視野があると、各タスクや機能がどう全体と連動しているのかを理解できる。理解から、より価値に対して効率的な進め方を模索できる。自分のタスクだけでなく他のメンバーの作業状況も見えるので、全体の流れをスムーズにすることを考えられる。戦略ゲームのプレイヤーの位置で日々暮らしたいという欲求と思う。

複雑な状況というのは、クネビンフレームワークで言うところの複雑《Complex》。問題が何なのかが明らかになっていない状態。現代のソフトウェア開発は概ねこの状態からスタートすると考えている。(Chaotic な状態だとタスクフォース的に急いで何かを手を打つだろう、Complicated な状態はもうやるだけになっている (やるだけ距離 がまだ遠いことはある) ので、マネージではなくコントロールして着地に向かうプロジェクトだろう)

何をやるのかを明らかにして、やるだけな状態に持って行くには、分かったことを積み重ねて、仮説を立て、対策していくというアプローチが効く。つまり OODA ループ。観測して (observe)、方向付けて (orient) 、意思決定し (decide)、実行する (act)。実験や試行錯誤を通じて何が効果的であるかを見つける楽しさがここにある。

やるだけになっているものを進めるのでも十分難しいとは思うが、誰も明らかにできていなかった問題に対して自分が輪郭を削り出すことに成功するのは最高に気持ちいい。モデル化に成功すると人類の叡智が一歩前に進んだ気持ちになる。同じ問題には同じ対策が効く。

組織目標はだいたい複雑な状況であるので、複雑な状況を任せられるようになると関与度が上がっていく。

全体設計の楽しさ

  • アーキテクトとして、システム、「系」を構築する
  • プロジェクトマネージャーとして、実行計画を立てる

抽象的な要件を具体的なシステム設計や実行計画に変換するのは、とてもクリエイティブな楽しさがある。また、この過程で新しい技術やツール、プロセスを取り入れる機会をねじ込み、自分やチームの経験領域を広げることができる。

目標や成果物を明らかにし、それを達成するための戦略やアプローチを定義するプロセスは、戦略的な思考を活かすことができ、自己効力感がある。

まとめ

単なるメモなのでまとめも何もないが。

仕事をする上で、何らかのクリエイティブな取り組みがなかったらつまらないと思う。僕はこういう仕事をやりたいし、みんながこういう仕事をやれる (ように経験資源を配れる) 状態だといいなと思っています。

このエントリは HatenaBlog Workflows Boilerplate を用いて GitHub から publish しました。push したら公開されるのは個人でも便利。

手を動かさないマネージャーを試している

2 月から、Mackerel チームの所属になった。

これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。

今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。

この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。

もう半年以上業務ではコードを触っていないが、ISUCON に負けたとき用の言い訳を用意しているわけではない。今年の ISUCON 13 はチーム No.117 で参加します。勝ちに行くぞ！

「掌握する」をやる

さて、異動にあたって、観察と干渉のバランス を意識しようと考えた。

僕の言葉ではこれは「掌握する」となる。

dictionary.goo.ne.jp

［名］(スル)《手ににぎる意》自分の思いどおりにすること。全面的に自分の支配下に置くこと。「政権を―する」「部下を―する」

※一応書いておくけど、以下は個人の感性に基づく感想です

「把握」は「独力で説明できる」状態を指している。観察の結果として割と早期に獲得できる状態だが、あくまで説明できるだけで、有事に判断を下すことは「把握」だけだと難しい。

一方「掌握」は「変えようと思ったら変えられる」状態を指している。（こういう状態を (control と対比した) 《manage》と言うんじゃないか、というのは 以前書いた）

掌握するとは、どこを変えたらどこにどんな影響が出るかの検討が概ね終わっている状態を指している。この「意のままにできる」感を表現したくて、「掌握」という言葉を使っている。

というわけで

  • どこに変更を入れると、どんな風に波紋が広がるかを、自分の言葉で言えるようになっている
  • 変更を入れようとしたときに大きな反発が起きない

というのが目指す姿だった。

なお「この音とまれ！ ＃118」の「掌握する」のシーンは最高に痺れるからぜひ読んで欲しい。単行本では 28 巻に収録されています。

初動の失敗

異動後に、以前のチームにも引き続き同じように顔を出す、というのをやっていた。どうせ当面のアクションは「観察」なので、言うて社内異動だしある程度知っていることもあるだろうから、片手間っぽくても成立すると油断していたのだ。

実際には片手間ではまったく無理で、1ヶ月経った時点で何も判断できるようになっていない自分に気がついて、ようやく焦って動きを変えた。

具体的には

  • Slack のチャンネルの並び順を変えて、自チームのチャンネルのみを一等地に置き、他のチャンネルは視界に入りづらいように押し込める
  • デイリースクラムの司会を貰う
  • 既存の Issue をとにかく読む

をやった。あと意識的に旧チームから離れた。

この結果、何も進捗しなかった1ヶ月とは打って変わって急速に「掌握」に辿り着けたんじゃないかと思う。

各リーダーからのヒアリングや 1on1 さえやっていたら片手間で辿り着けると思っていたが、思っていた以上に無理で、これは自分でもビックリした。

僕は自分の意識の大半を向けないと、想像を膨らませる遊びができなくて無能になるっぽい。想像を膨らませるというのは、どうやら、仮にこの仕事を〜〜がやったとしたら上手くいくか、チームをこう分割すると認知負荷が減るか、リーダーを誰に任せると覚醒し得るか、という思考実験を脳内で無限に繰り広げている、らしい。最近気づいた。

オチはない

コードを読まないマネジメントスタイルを試してみているが、果たしてできているのか、このスタイルが良いのか悪いのかはまったく判断できていない。

自分の感覚としては、コードを読んでいたときとそんなに全能感は変わっていない。各サブシステムの関係性のみの把握でなんとなく運用を理解することはできているし、判断する際にもどちらが正しそうかを選べているんじゃないかと思う。が、根拠の幾つかが伝聞に変わっているので、危うさはありそうな気がする。

コードを読んでいたときは、コードベース上に表現されるアーキテクチャに対して想像を膨らませて遊んでいた。現在はチーム上に表現されるアーキテクチャに対して想像を膨らませて遊んでいそう。変化させる対象がコードベースからチームに変わっているかもしれない。

似たような話が Hatena Engineer Seminar #26 「エンジニアリングマネージャー編」 でもありましたね。

手を動かさないスタイルを試し過ぎた結果、戻れなくなることがあるのかどうかもまだ判断できない。なんとなく、丸 3 年ぐらいなら戻って来られそうな感覚はある。

特にオチはない。

株式会社はてなでは、マネージャーをとてもとても募集しています。

サブカル業界Developers 勉強会 Vol.5 で Cache Stampede の話をした #subcul_dev

登壇

サブカル業界Developers 勉強会 Vol.5 (オンライン/オフライン同時開催!!) - connpass

前日に急に寝台特急の存在を思い出したので、サンライズ出雲で上京した。寝台車は寝てたら勝手に着くので便利だなぁ。強制的に 7 時から活動させられるので朝活しやすいのもポジ。

登壇枠

Cache Stampede (検索用ワード: Thundering Herd) という話をした。

Cache Stampede 対策のうち 3 案は以下のスライドから貰ってきた。

www.slideshare.net

ZOZO さんも同じ分類で話をしていましたね。

techblog.zozo.com

4 案目とした SWR も 6-7 年前から定番かなー。

＼キャッシュと上手に付き合おう!!／

パネルディスカッション

主に「サブカル企業のスタッフはオタクなのか」というお題で 5 社でパネルディスカッションしました。

パネルは「toB v.s. toC」という枠に当てはめようというモデレータの力が働いていた気がする。これはプロダクトにはかなり影響するが、社内文化は違いを感じないなというのが自分の感想だった。

実際、熱量を持っている開発者と意思決定者との距離は、施策選びにとても影響がある。そこで距離の近い共同開発を行える関係性、任せて貰える信頼関係を作るのに腐心している。

一方で、社内文化については、オープニングでも触れられたが、雀魂 夏の企業対抗戦 2023 が特徴的で面白かったなと思う。パネル登壇 5 社中 3 社が出場している。

こういうイベントにどんどん参加できる環境とか、およそどんな話題でも食いついてくる人がいる社内 Slack とかは福利厚生だろう。

懇親会

前回に引き続き、オフライン懇親会も開催した。オフライン懇親会は新しい人との繋がりを作りやすいのが本当に便利で、知り合いと知らない人とが親しそうに話をしているところに「どんな繋がりなんですか」を携えて入っていくと、どんどん繋がっていく。これを繰り返して顔なじみを増やしてきたんだよなぁ、と再認識した。

一方で、はてなからも 2 人参加していたけどあまり引率できなかったのは失敗だった。懲りずにまた来てください。次は紹介して回ります。

サブカル業界 Developers は引き続き開催していくつもりなので、connpass で Join Group して新着イベントを拾える状態にしておいてください。

git revert 時は理由を入れよう

コミットを何らかの理由で取り消したいときに git revert を使う。

git revert -m1 MERGE_COMMIT したときは

Revert "Merge pull request #1 from onk/repo"

This reverts commit 35b7e7c517c438b805d442ff45242334bb91eda5, reversing
changes made to 07989ab9643e204a0d26a19152c5ace2657cf421.

という commit になる。

GitHub だと UI 上からも revert できて、そのときは以下のようになる。

Pull Request を revert する画面。本文は「Reverts onk/repo#1」
「revert」ボタンを押すと revert PR を作成する

どちらも、このまま進めることはできてしまうが、「revert した」という事実だけしか残っていない。なぜ revert する羽目になっているのかという Why がどこにもない。これは後世でとても困るのです。

revert commit のコミットメッセージもしくは revert PR の description に、理由を入れて欲しい。

「... の考慮が漏れていて動作確認時に ... というエラーが出たため」とか。Slack のリンクだけでもいいです。

理由が全員の記憶から揮発してしまったら「前回 revert した記憶があるが、当時ダメだった理由って潰せてるんだっけ？」という質問に答えられず、不安の中で次のリリースをすることになるからです。

オンボーディングは3ヶ月で3連勝を目指す

先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。

オンボーディングとは

採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。

僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。

これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセスとして見ると、教科書を読んだり講義を受けたりワークショップに参加したりするだけではまだ足りず、もっと実践的な具体的なタスクが欲しい。そして、その具体的なタスクに関して、3ヶ月で3連勝を達成したい。

3ヶ月で3連勝

元ネタは fukabori.fm でエムスリーの山崎さんが語っていた内容です。

自分がチームでやっていけそうという感覚を手に入れるために、できるだけ短期間で成功体験を積んで貰いたい。更に単発じゃなくて3連発で成功すると「このチームで良かった！」と思えるんじゃないか。そのためにチームがちゃんと応援する。オンボーディングタスクに対して、チームメイトが積極的に関与していく状態でありたい。

対義語（？）は「お手並みを拝見する」かもしれない。

「活躍してもらうためのサポートがあなた (受け入れる側) の仕事です」というのを明確にするために標語が欲しくて、また見守りコーナーで「活躍できていますか？」と問いかけるための指標も欲しくて、「3ヶ月で3連勝」は失敗を検知しやすいしアクションも取りやすいなと思って取り入れているのでした。

まずはデプロイ成功を初日に持ってくるとか、ちょっと難しめの 1 スプリントかかるタスクや、2-3 スプリントかかるタスク、ちょっとした気になりを解消するタスクを用意していくとかをするだろう。タスクサイズがバランス良いかとか、大玉や改善タスクも含めて3ヶ月のスケジュールができている？みたいな確認も自然に取れるのが良いところだと思っている。

3連勝するためのアクション

3連勝を達成するためには、本人の力だけではなく周囲のサポートも必要で、両方がうまく組み合わさっていることが望ましい。どちらか一方だけでは不十分であろう。サポートするをより明確にするための標語でもあるが、本人が連勝を目指してアクションを取るための標語でもある。

本人の力をより引き出すためには、大声で作業をするというのをいつも伝えている。

blog.studysapuri.jp

社内 Scrapbox や Slack に書き残しながら作業をしていると、悩みを素早く拾えるし、リモート下でも非同期にサポートできるようになり、より短期間で成功する確度が上がっていると思う。

また、日々大声で作業をし続けていたり、スプリントレトロスペクティブがあったり、隣のチームメンバーとの 1on1 で最近やったことをまとめて説明する時間を取ったりで、他人に伝わるように説明する力を養えているんじゃないかなー。上手くサポートしたいので、障害物があるかを確認したいし、障害物があれば高速に排除したい。

サポートする側としては、目の前のタスクを成功させるためのサポートの他には、良いタスクを選ぶというのが大事になる。より多くの領域に触れるようなタスクを選ぶことを心がけるし、本人がモチベーションのあるタスクを見つけて、目標にする、というのも考えて活動している。

書かなければいけない採用リンク

みたいなことを考えながらオンボーディングに取り組んでいるのでした。

株式会社はてなでは、あなたの応募をお待ちしています。 https://hatena.co.jp/recruit

*1: id:tokizuoh が 中途入社エンジニアが体験した、はてなにおけるオンボーディングの実例 - Hatena Developer Blog で書き残している

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

6 年目で所属は引き続き弊社です。触っていく範囲がまたちょっと広がりました。