すがブロ

sugamasaoのhatenablogだよ

知識の探求と喜び #RubyKaigi 2024

（タイトルはAIに考えてもらいました。確かにそうだな！？と思ったので採用しました）

rubykaigi.org

沖縄開催

元来出不精でとにかく家に居たいパーソンなのですが、なんとか一念発起して沖縄に行くことにしました

そして、せっかく行くのであればある程度観光も、ということで妻と一緒に前乗りして5/11-5/13は家族旅行、5/14-5/18(day0からday3の翌日まで)はRubyKaigiというスケジュールにしました

RubyKaigi - はじまりはじまり

ここ数年は会社のお金で参加させていただいており、今年はドリンクアップスポンサー

SmartHR Drink Up at RubyKaigi 2024 Day2 (5/16) - connpass

をやったり貢献できる幅が増えてきているのは嬉しいです

これは単なる社内事情ですが、DevRelの立ち上げを起点として社内でのスポンサー時の体制がしっかりしたものになってきて、社内でのモチベーションや熱量がうまく企画に昇華させられたことにより事前勉強会・事後勉強会・ドリンクアップの実施などいい感じに企画・運営ができていて組織力の高まりを感じます

day0 - すでに疲労

前乗りの旅行ですでに疲弊していたので、day2に行われるドリンクアップの下見で少し飲んで終了

沖縄の台所ぱいかじ｜国際通り店

ちなみに、「ぱいかじ」とは「南風」を沖縄の方言で読む言葉だそうです。勉強になりますね

day1 - 初手からわからん

Writing Weird Code

PEN sanのキーノートは本当に「わけわからない（褒め言葉です）」を無限に浴びせてくるのですがその中で他のセッションを紹介していく流れが美しすぎて本当に練度の高いトークでした。TRICKとか全くできる気はしないものの、だんだん興味が湧いてきました……

The grand strategy of Ruby Parser

実質parserのキーノートだなと思いました。parser.yについては過去のRubyKaigiなどを通じてなんとなく知っているものの、取り巻く環境などはまったくわかっていなかったので、関連技術要素がマッピングされて説明されてFF3の飛空艇を手に入れてからのような感覚*1*2を得ました

それはそれとして話しているkaneko sanがとても楽しそうだったのが印象的です

Namespace, What and Why

Namespace、ぜんぜん実現できるイメージが湧いてなかったのですが本当に動いてる……!!という感動がありました

Namespaceで解決する話ではないような気もするけどRubyでは require したタイミングでrequire先の定数などがグローバルに展開されてしまうのは制御できるオプションがあると嬉しいなあというのはずっと思っています

Ruby 3.1から load の第二引数にモジュールを渡せるようになったやつがrequire でもできたり事前にモジュールを定義するのではなく何らかのシンタックスシュガーでシュッとかけると嬉しいと言いますか……

update: ↑で書いた内容はMatzの話していたpackageに相当するとのことです

夜の部

夜はRubyKaigi 2024 Official Partyへ行き、BBQを楽しみながら本当にさまざまなお久しぶりの人と話せてよかった。お互いの近況であるとか、若者にドリームキャストってなんですか？と聞かれるなど時間を感じる一日でしたね😌

day2 - 話を聞くと興奮してくる

Leveraging Falcon and Rails for Real-Time Interactivity

リアルタイム通信（というのか？）の歴史とFalconでFlappy Birdを作るデモ

サーバーサイドで計算して、その結果を描画しているんだと思うけどあんなに滑らかに動かせるものなんだなあ、というのとああいうインタラクティブな操作とかは昔にFlashでやっていたのを思い起こされる

Embedding it into Ruby code

soutaro sanのRBSをコメントに埋め込めるようにする話。現在のIDEやGitHubなどの状況だとやはりrbsファイルが別にある状態でのメンテナンスが難しいのはそうなので、コメントに埋め込むというのは良さそう〜〜〜〜と思いました

Reducing Implicit Allocations During Method Calling

メソッド呼び出し時に余計なオブジェクトを生成しないようにしていく話。メモリのアロケート状況を見ながらチューニングしていく流れは参考（何のだろう）になりました

このセッションを見ていなかった同僚に話たところ、研鑽Rubyに書いてある内容が近いっぽいですね。研鑽Rubyを積読しているのがバレてしまった……

Good first issues of TypeProf

毎年、TypeProfのトークは楽しみにしているのですが、今年はコントリビュートしやすくするためのチュートリアル的な話でした

TypeProfは毎年「期待しています！」という気持ちを持っているのですが、今回のトークで「1人で開発してるの大変ス」という話を聞いて自分も何らかのお手伝いができれば、、という気持ちになっています（なっているだけじゃダメなの手を動かしましょう）

夜の部

day 2は会社のドリンクアップ準備のためLTの途中で抜けて事前準備へ

ドリンクアップでは入口の案内パーソンとして階段を上がったところでお出迎えする役をやりました。来場していただいたみなさん本当にありがとうございます

ドリンクアップ後は適当なお店で会社の人と飲みつつ、@kwappa san / @tagomoris san / @tompng san / @gachacomplete san へ近況やトークの感想などお伝えできてよかったです。ガチャピン先生はmalloc動画のころからのファンだったのでちゃんとお話できたのがめちゃくちゃ嬉しかったです😌

沖縄の締めはステーキ、と聞いていたので一日の最後にステーキを食べに行ったのも良い経験でした。さすがに40歳過ぎ & 24時過ぎにステーキを食べるのはためらいがあったのですが、赤身のステーキだと意外とシュッと行けて新しい概念を獲得してしまいました……

day3 - 来年のRubyKaigiも楽しみすぎる

前日、IVRy社さんからもらった酒豪伝説を飲んでいたおかげか、わりと元気に起床。酒豪伝説しゅごい……

Ruby Committers and the World

例年、英語でのフリートークになると20%くらいしか理解できなくて「楽しいけどわからね〜〜」という感じになりがちだったのですが、今年はトークテーマなどをいい感じに整理してもらえたおかげかだいぶ理解できた気がします。コミッター陣の中でも意見が分かれたりしていたのは側から聞いていて面白かったです

soutaro sanがコメントに記載するRBSの記法について来場者に聞いていて、自分が手を挙げたほうがめちゃ少数派だったりして「うおお」となったりしました

これはコメントに記載する云々という話ではないと思うんですが、型によるサポートが強くなればなるほど、class（あるいはDataなど）でのオブジェクトの定義が重要になってくるかなあと思ったりしています。例えば Integer であるだけではなく、「1〜10までのIntegerである」などが表現できて型情報で事前条件（と表現するのが正しいかわからないけど）が明示できるようになると嬉しい……。というかこれは単にunionで型を定義したいという話な気がしてきました。忘れてください……（？）

Speeding up Instance Variables with Red-Black Trees

ちょっと事情があってトークに遅れてしまったのですが、赤黒木の説明をしつつそれをRubyで活用している実例に展開する流れはめちゃくちゃ面白かったです。Object Shapes、毎年話を聞いていてちょっとずつわかり具合が高くなっている気がします

ERB, ancient and future

関さんファンなので今年も聴きました。ERBの話を聞いていて「これはCGI!!」と興奮していたら「CGIだよ」という展開になって楽しかったです

自分が本当に文字通り駆け出しエンジニアだった頃は print であらゆるものを出力していたものですが、その時代にERBのアーキテクチャを検討できたのって本当にすごいなあ。今見ると「それはそう」となるかもしれないですが……

Matz Keynote

Ruby2（2.0ではない）の構想と現在実現されている機能の話や、Namespaceが入ってRuby2時代の構想が一通り実装できたらRuby 4にしようかなという内容

Namespaceの仕様などはこれからより詰めていく段階だと思いますが、めちゃくちゃ夢のある話でよかった。毎年、RubyKaigiでMatzの話を聞くと未来に対してワクワクさせられてすごいなあと思います（小並感）

夜の部

RubyKaigiの最後はmov社さんのAfter Partyへ

@kamipo sanと人生について話したり、@masaya_dev san と久しぶりにお話したり、LeSS について話したりといろいろな話をできて満足です。会場の導線などオペレーションがしっかりしていてとても過ごしやすい空間でした

day4 - また来年

飛行機の搭乗時間まで時間があったので、うわさの千日でぜんざいを食べたり、波の上ビーチで海を感じたりして解散

もはや方々で言われているので言語化されつつある話ではありますが、RubyKaigiって「明日使える便利テクニックを得ました！」とかではなく「なるほどわからん」を積み重ねて各トークの関連やRubyという言語のアレコレ*3を知っていくことで繋がりが生まれてくる快感や高揚がすごいんですよね（(自分の性格として"物事を知る"ということが好きっぽい)）。そしてまたわからないことが増えていく。無限か？

さらにさらに、それを作っている・トークしていた人が目の前にいる、なんなら隣で酒を飲んでる的なことが普通に発生する。

この"良さ"を未経験の人に伝えるのは難しいのですが、私は今年もRubyKaigiを十二分に楽しめました！RubyKaigiのSpeakerのみなさん、RubyKaigiスタッフのみなさん、スポンサーブースの皆さん、お久しぶりに/はじめましてでお話できたみなさん、あらゆる人のお陰で今年も素晴らしい体験をすることができました！

また来年、松山で会いましょう〜〜〜☺️

*1:例えが古い

*2:今なら暗黒大陸と言ったほうが良いですか？？？

*3:パーサーの概念とかメモリの考え方を押さえておいて他の言語を触るとより特色が理解しやすくなってとてもお得なんですよね。それを日本語で聞けちゃうの便利すぎるね

認知負荷の種類と対策と組織文化について

このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。

これは何

当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。

ツールの関係性については↓のエントリをご覧ください

Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ

閑話休題

認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、「認知負荷」という言葉をふわふわな認識のまま「なんか大変」という言葉の言い換えにしておくのはせっかくの気づきをフワッとさせたままになってしまうので、正しく概念を理解して、立ち向かえる単位に分割できるとより成果に繋げられると思いませんか？思いますよね。思ってください。

さて、そんな話題については 【増枠！】Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 - connpass というイベントで登壇してお話しさせていただきました。

一方で、タイトルがへちょすぎて内容が想像できないという意見も想像に難くないためこちらで少し補足プラスアルファを書いていこうと思います。

認知負荷 is なに

認知負荷とは記憶に関するモデルのうち「ワーキングメモリ」と呼ばれる、何らかの作業おこなっているときに使用する記憶に関する負荷です。 認知負荷という言葉が位置するもの

そして、その「負荷」にはいくつかの種類があり、それを包括したものが認知負荷と呼ばれるものです。

認知負荷の種類

認知負荷理論として教育心理学者、ジョン・スウェラー氏によって確立された理論で、3つあります

  • 課題内在性負荷
  • 課題外在性負荷
  • 学習関連負荷

それぞれは以下のスライドを見てください

課題内在性負荷の説明 取り組むタスクの難しさによって発生する負荷 課題外在性負荷の説明 取り組むタスクの外側にあり、本質的ではない難しさによる負荷 学習関連負荷 学習するための負荷なので、これが十分に高い状態が望ましいとされる

世の中には私が調べたことより丁寧な資料もあるので、ぜひ併せてご覧くださいませ

www.ipii.co.jp

で、これがわかるとどうなるんだってばよ

ここに書いてあることは認知負荷に私の独自解釈であるため、諸説ある可能性があります。有識者のご意見があればぜひ教えてください🙏

課題内在性負荷 であれば本質的な難しさを減らすことはできないけれど、取り扱うサイズを小さくすることで理解しやすくすることができます。 複雑なロジックを小さなメソッド名に切り出し命名していく、変数名を適切なものに変える、（DDD的な文脈で）ユビキタス言語を利用する、などが挙げられるでしょう。

課題外在性負荷 であれば継ぎ足しで複雑になってしまったif文やループ処理をリファクタリングする、Why Notが正しくコメント化されている、ADRなどによりコードの設計方針を記録として残すなどして、コードを読んでいて「アレ？」となる部分を解消できるようにしていくと良いでしょう。

認知負荷とコードの話は、「プログラマー脳」という書籍がめちゃくちゃ参考になるので、ぜひ読んでみてください

www.shuwasystem.co.jp

これらを推進するには組織文化が重要

ここまで書いてあることは、一般的なエンジニアであれば「まあ個別には気になったら対応するよな」というものも多いでしょう。しかし、これらを「気になった個人」駆動でプロダクト全体に一定の規律をもたらすのはとても難しい*1ため、チームや組織の望ましい振る舞いとして浸透・後押ししている必要があるんですよね。

さらに、組織文化だけではなくプロダクトに対してオーナーシップを持てているか？ということも重要な観点になります。 今この瞬間はちょっと妥協できても、半年後、一年後にこのコードが耐えうるかは考慮できる状態になっていてほしいし、既に難しくなってしまったコードにもきちんと立ち向かえる環境である必要があります。

そういった観点で、こういった文化をより強固にしていくための取り組みは社のテックブログに書きました チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog

さて、ここまで書いた負荷を減らすという話と似た概念として技術的負債（の解消）というワードがあるかと思いますが、これに関してはさいきん目にした↓の資料が良すぎて血の涙が流れました。

このエントリではどちらかと言えば個人がどのように認知負荷を捉えるか？という話題を書いたのですが、例えば「チームトポロジー」のような組織構造と認知負荷の話もありますし、個人としても組織としても両方で立ち向かっていかないといけないんですよね。つまり、ハサミ討ちの形になるな…

認知負荷の詳細を把握してから問題を見ると、フワフワな課題の輪郭を捉えやすくなる

ここまで書いてきたことは、身も蓋もないことを言うと何らかの課題を分割するためにどのような尺度を使って捉えるかという話でした。 もちろん、「認知負荷」で全ての課題を分類できるわけではないと思いますが、成長していくソフトウェアや組織に携わっていると有用なシーンも多いと感じます。

引き続き頑張っていきましょう。

*1:もちろん、十分スキルフルで少人数なチームであれば労せず達成できる可能性はあります

rustでgemパッケージ内のコードを書く方法のメモ

Ruby 3.2に同梱されるBundlerでは、 bundle gem に --ext=rust とすることでrustでgemのコードを書けるようになります。

新しいものはとりあえず触ってみたいので、試してみましょう（完全にn番煎じなのですが、自分用の備忘録です）

事前準備

  • rustのビルド環境
  • Ruby 3.2.0（正確にはBubdler 2.4.0以上）

やってみる

rust_gem_sample という名前のライブラリを作ってみるとしましょう。

$ bundle gem rust_gem_sample --ext=rust
 : # 場合によってはさまざまな質問があるので適当に答える

これで雛形ができる。 作成された rust_gem_sample ディレクトリへ移動し、コードをさらっと眺めてみましょう。

rustのコードはC言語の場合と同じように ext ディレクトリ内に生成される。

$ tree ext
ext
└── rust_gem_sample
    ├── Cargo.toml
    ├── extconf.rb
    └── src
        └── lib.rs

ちなみに、生成されるサンプルコードはこんな感じ

# ext/rust_gem_sample/src/lib.rs
use magnus::{define_module, function, prelude::*, Error};

fn hello(subject: String) -> String {
    format!("Hello from Rust, {}!", subject)
}

#[magnus::init]
fn init() -> Result<(), Error> {
    let module = define_module("RustGemSample")?;
    module.define_singleton_method("hello", function!(hello, 1))?;
    Ok(())
}

define_singleton_method でメソッドが定義されているということは、RustGemSample.hello で呼び出せて、1つの引数を受け取るコードってことですね。

さて、ビルドするためには事前準備が必要なので、以下を修正します（これはrust関係なく、bundle gemした時に必要な一般的なもの）。

  • rust_gem_sample.gemspec
    • TODOをURLっぽい値に書き換えておく（これをしないとビルド時にエラーになる）
  • testを生成している場合、自動生成された test コード
    • デフォルトのコードは失敗するようなコードになっているので、修正するなり消すなりする必要がある

これは余談ですが、久しぶりにgemspecの中身を見て source_code_uri や changelog_uri というのが設定できるということを知りました。RubyGemsのドキュメントを見るに、設定しておくとrubygems.orgのサイドバーにいい感じに表示してくれるっぽいですね……？

$ ./bin/setup
$ bundle exec rake

これで無事にビルドできるはずです。

ではお試しで実行してみましょう。

$ ./bin/console
Ignoring rust_gem_sample-0.1.0 because its extensions are not built. Try: gem pristine rust_gem_sample --version 0.1.0
irb(main):001:0> RustGemSample.hello("hoge")
=> "Hello from Rust, hoge!"
irb(main):002:0>

おー、うごいた！

せっかくなのでブログにしてみよーと思って書き始めたのですが、なんか、思ったより何もせず動いてしまった……（いい話）。

2021年に読んだ本

2021年は比較的本を読んだ気がします。

よく考えると、ゲームチェンジが起こったことが影響しているかもしれませんね。

読み切った本

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか

アーサー王とかエクスカリバーとか、小さい頃から慣れ親しんでいたけれど、それが日本でどのように受容されてきたかの話。どのように編纂されてきたかも含めて読み物としてめちゃ面白い。それと、「いかにして〇〇は〇〇したか」構文はアーサー王伝説を編纂した「アーサー王の死」の章タイトルに由来しているということを知れたのは結構なアハ体験。

あと、コラムとして本文の途中に差し込まれている侘助さんという方のコラムが完全にオタク特有の早口文体なんだけど読みやすくて、なんというか筆力を感じてすごい。

残念ながらkindle版はないのですが、amazonでも物理本は購入できます。kindle版があればな〜〜と思いつつも、この本は装丁もめちゃくちゃ凝っているので本で購入する方が良い体験を得られると思います。

07-9いかアサ〈ガウェイン〉 | みずき書林

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

  • みずき書林
Amazon

眼の誕生

進化の過程でどのように生物が眼という器官を発生させたかという話。推理小説のような書きっぷりで、表題に到達するまではそれなりに読み進めなくてはいけないけれど、光と生物の関係についてじっくり説明していくので、それはそれで読み物として面白い。

眼が発生するのは光を検知して外敵を発見するなどする光受容体をより発達させていったものという内容が段階を経て理解できる構成になっていて良かったのと、三葉虫が目を獲得していった話とかは読み応えありました。

これも物理本しかなかった。

眼の誕生――カンブリア紀大進化の謎を解く

眼の誕生――カンブリア紀大進化の謎を解く

Amazon

ユニコーン企業のひみつ

いわゆるスクラムのような1チームで成果を出す規模を超えてしまったときに、Spotifyはどういうアプローチでスケールさせていったか？ということが書いてある。LeSSのようなスクラムチームをスケールさせる手法をとっている場合、おそらくアプローチは異なるけど目指す方向は似てるはずなので、Spotifyがどういう取り組みをしていたかは解像度を高めるための参考になりそうな気がしています。

詳しくはこっちに書いた。

🦄ユニコーン企業のひみつを読んだ🦄 - すがブロ

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

Amazon

OKR

OKR、雰囲気でしかわかってなかったので参考になった。とはいえ、エンジニアの評価軸に合わせるの難しいな〜〜とか、今週の目標確認やウィンセッションなどのイベントごともスクラムを取り入れた組織だとコンフリクトしそうだよな〜〜などの感想を得た。杓子定規なOKRとスクラムの併用は難しいだろうなあ（導入するならそれなりに強い意志でアレンジしていかなといけなさそう）というのはググるとチラホラ見かけました。

OKR（オーケーアール）

OKR（オーケーアール）

Amazon

エラスティックリーダーシップ

以前読んでいたのを再読した。

エラスティックリーダーシップを読んだ - すがブロ

感想としてはあまり大きく変わらないけれど、当時よりは解像度が高い状態で読めて良かった。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Amazon

つまみ食いで読んでるシリーズ

手を動かしながら学ぶTypeScript

同僚が執筆したTypeScriptの本。 #手TypeScriptというハッシュタグ流行らせたいんですが、全く流行っていません😭

まだ読み進めている途中ですが、個人的には数年前、当時在籍していた会社でJS -> TSへのコンバートをやったときにこの本があれば……!! という気持ちがあります。

手を動かしながら学ぶ TypeScript

手を動かしながら学ぶ TypeScript

Amazon

達人プログラマー 第2版

いまさら語ることは無い良本ですが、最近になって読み直したけどやっぱり良いこと書いてありますね。

最初は数々の引っ越しイベントを経て手元に残していた初版を読んでいたのですが、圧があったので2版を買いました（のちに気が付いたんですが、kindle版ではなくどこかのPDF版を購入済みだった）。

達人プログラマー ―熟達に向けたあなたの旅― 第2版

達人プログラマー ―熟達に向けたあなたの旅― 第2版

Amazon

アジャイルな見積もりと計画作り

自社ではスクラムをベースとした開発をしており、「これ、どう考えたら良いんだっけ？」というときに見直しています。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Amazon

Clean Agile

こっちの本はほぼ読んだと思うけど、アジャイルな見積もりと計画作りと同じく、考え方を参考にしたいときに読み直しています。

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Amazon

エンジニアリング組織論への招待

これはまだ読んでいる途中なのですが、2021年の後半はチーム内のチーフというロールをやることになったので1on1をやる機会もあり、メンタリングについて興味があって読んでいます。 これは1on1をやり始めてすぐ読むべきだったな〜〜〜というくらい良い本でした。まだ読みきれてないけど……。

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

Amazon

エンジニアのためのマネジメントキャリアパス

どういう内容かはそのっつさんの感想を読むとわかりやすいですが、ひとまず自分の目の前にあるチームのマネジメント文脈ほしさで5章まで読んだ。

自社のチーフというロールはプレイングマネージャーなので、参考や目標に。

これはkindle版が無いのが惜しい

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

Amazon

おわりに

読んだマンガとかも書こうと思ったけど分量がめちゃ多くなりそうなのでここで終わります。

といいつつ、いま一番良いなと思っているのを書いておくと、ハイパーインフレーションです（最初はイロモノ的なマンガかなと思ったけど、完全にシリアスな笑いを狙ってきていて引き込まれる良さがある）。 shonenjumpplus.com

RubyMineでよく使ってる機能

この記事は SmartHR AdventCalendar の2日目です。

20代の頃はVimを使っていたのですが、膝に矢を受けてしまいIDEを使うようになってしまいました。

さて、そんなこんなで普段使いしているRubyMineですが、この中でよく使う機能について少し書いてみようかなと思います。

というわけで書いていきますが、ファイルを開くとか検索するとかはメジャーだと思うのでそれ以外について書いていきます。

コードを見ているときに便利なやつ

キャプチャを取得する際のサンプルとしてrubygems.orgのコードをRubyMineで開いています。

cmd + clickで関数ジャンプをした後、cmd + [で戻る

メソッドを探索していて、「今見ているメソッドを呼び出していた部分を読みたい」というときに戻れて便利。

さらに、cmd + ]で戻った状態から進むことができるらしいのですが、何らかのアプリにショートカットが吸われていて使えた試し無し😇

開いているファイルを「Project」タブ内で選択状態にする

読み進めているファイルと同じ階層の別ファイルを開く場合などに、シュッと周辺ファイルを探すことができて便利。

f:id:seiunsky:20211202002036p:plain

「Structure」で概要を見る

単純にメソッド一覧が表示されるだけでも便利なのですが、RSpecなど、テストを書いているときにどのようなテストケースが書かれているか把握するのに便利（RSpecだと階層構造も把握しないとテストの全体像が把握できなかったりするので）。

RSpecに関しては--dry-runを実行するという手もありますが、編集しながら横に表示できるのが便利なんですよね〜〜〜。

f:id:seiunsky:20211202002943p:plain

With Coverageでコードカバレッジを見る

テストを実行するときに、「'With Coverage'」を選択するとテスト実行後にカバレッジを表示できます。 網羅率がどうこうというより、テスト対象としたいコードに対して正しくテストが通っているかを確認するのに便利。

f:id:seiunsky:20211202003130p:plain

便利Plugin

ゴテゴテ入れるのは好きでないので、あまり入れてませんが……。

GitLink

Open in GitHubのショートカットを追加するやつ。カーソルがある行に対応するGitHubのパーマリンクが取得できるので便利。

https://plugins.jetbrains.com/plugin/8183-gitlink

Find Pull Request

該当行を変更したであろうPRを探してくれるくん。システム考古学してるとき便利。

https://plugins.jetbrains.com/plugin/8262-find-pull-request

Railways

rails routeをシュッと見る用です。絞り込みもできるので便利。

https://plugins.jetbrains.com/plugin/7110-railways/

SmartHRに入社して1年が経った

めでたいのでハッピーターンをたくさん食べました

これまでのあらすじ

sugamasao.hatenablog.com sugamasao.hatenablog.com

近況

5/1で入社して1年ということになりました。

10年ちょっとぶりの転職なので世の中のエンジニアリングについていけなかったらどうしようかと思っていたのですが、幸いにもWebアプリケーションエンジニアとしてなんとかやれてます（たぶん……）。

今までロクに経験のなかったチームでの開発ってやつを楽しんでます。

SmartHRとぼく

忘れそうなので書いておきます。

認知のきっかけ

2018年

この頃、転職はまだ少し先の話という認識でいました。

少なくとも半年後に転職するとかそういう気持ちではなく、IT業界にありがちな、そのうち転職するとしたら合いそうな会社の目星をつけておこうくらいの温度感ですね。

  • おそらく最初に認知したのはこのconnpassだったと思う
  • もしかしたらRubyKaigiでの宮田さんの話だったかもしれないけど、このRubyKaigiは不参加だったのでTwitterのTLごしにうっすら認知していた可能性がありそう（いまとなってはこの時点で認知していた気がするけど、存在しない記憶の可能性がある）
  • エンジニア向けの体験入社制度ができましたの時に名前だけじゃなくて事業も把握したはず
    • というのも、当時は私自身も半蔵門に勤務していたので、ふつうの出社気分で体験入社できそうだな〜とか考えたりしていたのだった
    • 良さそうな会社という認識はあったので転職する気持ちが高まってたらすぐに飛びついていた可能性はあった

2019年

アラフォーで同じ会社に10年いるのやばくね？　みたいな気持ちが高まっており、ワンチャン転職しても良いかもっていう気持ちになってきた年です。

正確に書くと、40歳過ぎてから転職するのヤバそう（転職した時の期待値を越えられなさそう）という気持ちが強く、40歳になる前に−−そして転職に失敗した場合の再転職バッファも考えると今のうちに一度転職しておいた方が良さそうだなみたいな事情です（2019年当時、私は37歳）。

  • Rails DMのランチセッションでSmartHRが会社紹介をしていて、その話を聞いた時かなり魅力的に感じた記憶がある
    • この手のランチセッションって、ご飯食べながらだし、言うても話半分で聞く感じになりがちだと思うのですが、なんかめちゃくちゃ響いたんですよね
      • この時点ではすぐに転職活動するつもりはなかったのですが、時が来たら話を聞きにいこうと思った
  • そのほかにはたらいの話がすごく良さそうに思えて、人が増えていってもちゃんと対処できてそうという雰囲気を感じたのだった

ちなみに、これが響いた様子です（これはさまざまな感情を圧縮した結果のコメントです）

それから

以前の転職活動メモにも少し書きましたが、転職活動は2019/10ころから始めていました。

初手は転職ドラフトで本当に自分自身に市場価値あるんですか……？みたいなところを見つつ、転職ドラフト経由以外に自分からいくつかの企業にコンタクトをとったのが11月末〜12月くらいって感じですね。

SmartHRに関しては、たまたま参加したイベントに人事の方がいらっしゃったのでダイレクトアタックして選考フローに乗せてもらいました（ふつうにHPから応募しようと思っていたので、これは本当に偶然）。

その後、なんやかんやあって、ありがたいことに内定はいくつかいただけたのですが、どの会社も魅力的で本当に迷っており、パーフェクトRuby on Railsの改訂作業を行う精神力が保てなくなったりしました（それはまた別のお話）。

ここまでを振り返ってみると

SmartHR社は転職に対するマインドシェアが高まっている時にちょうどよく認知を高めるイベントがあったのかな〜〜という感じはありますね。

最終的に決断した一手はこれらとは別にありましたが、そこに至るまではやはり「タイミングが合っていた」というのは結構重要なファクターだったかもしれません。

露骨な宣伝

それはそれとして、CTOからのお知らせにあるとおりSmartHRではWebアプリケーションエンジニア（に限らず）積極採用中なので、もし話を聞いてみても良いかなって人がいらっしゃればぜひ以下の資料やエントリーページをみていただければと思います。

会社説明資料はこちら。

speakerdeck.com

以下の採用ページにある各職種の募集ページからエントリーしていただけますが、カジュアル面談のエントリーも可能なので、まずはどんなもんか話を聞いてみようかって場合はそちらを選択していただければと思います。

smarthr.co.jp

露骨な宣伝2

パーフェクトRuby on Railsも何卒よろしくお願いします。

パーフェクト Ruby on Rails　【増補改訂版】

パーフェクト Ruby on Rails　【増補改訂版】

🦄ユニコーン企業のひみつを読んだ🦄

私は訳者お二人のファンなので書いました。まあもちろん、それ以外にも単純にスクラムをもうやっていないという宣伝はシンプルに気になりますよねということでシュッと買って読みました。

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

  • 作者:Jonathan Rasmusson
  • 発売日: 2021/04/26
  • メディア: 単行本（ソフトカバー）

ちなみに、オライリーのサイトだと電子書籍版を購入できます。

www.oreilly.co.jp

かんたんな感想

スクラムとかアジャイルとかあまり詳しくないので小学生並みの感想です。

今北産業

  • 「スクラムをやっていない」isいわゆるSpotifyモデルの話
    • ただ、これはあくまで著者がSpotifyに所属していた時期（2014〜2017）のモデルであって、いまどうなっているかを書いているわけではない
  • 「Spotifyモデル」is少数チームで迅速に開発をする速度を維持しながらスケールさせるには？という話
  • このモデルを実現させるためには"開発チーム"みたいな閉じた座組みではなく、経営陣を含めた考え方、つまり企業の文化を変えなきゃダメだよねということを述べている

ちなみに、本文の補足を書いてある「訳者あとがき」はインターネット上に公開されているので、購入前に一読してみると良いかもしれません。

https://scrapbox.io/iki-iki/%E3%83%A6%E3%83%8B%E3%82%B3%E3%83%BC%E3%83%B3%E4%BC%81%E6%A5%AD%E3%81%AE%E3%81%B2%E3%81%BF%E3%81%A4%2F%E8%A8%B3%E8%80%85%E3%81%82%E3%81%A8%E3%81%8C%E3%81%8D

感想

Spotifyモデルのことを名前しか知らなかったのだけど、どういう思想のもと作られたものかわかってよかった。 また、これは読めばわかることだけど、「スクラムをやっていない」、それはそうだけど事業規模や会社に合わせて変化させていった結果であって、取り組みはスクラムの知見や経験をベースにしていてスクラムは役に立たなかったとかとかそういう話ではなさそう。

Spofityモデルの話をベースにしているけど、どちらかというと"テック企業になるためには文化を作っていかなくてはいけないんだよ"というメッセージが書いてあるように思えたので、形をまねるのではなく自社がより良い一歩を踏み出すための参考にする感じが良いのかなあ。

👇のような話もあるし、世の中銀の弾丸なんてないのじゃ……（真偽のほどはわかりません）。

https://agile.quora.com/Spotify%E3%81%AF-Spotify%E3%83%A2%E3%83%87%E3%83%AB-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84

ちなみに、Spotifyモデルを見ていてLeSS(大規模スクラム)と似ている*1ようで異なるなーと思ったのですが、お互いに影響を与えたりがあったりしていたんですかねえ。

読書メモ

*1:どっちも企業文化から変えないと価値をデリバリーできないですよねって話は共通してるかな〜とか