すがブロ

sugamasaoのhatenablogだよ

EMとして開発チームのマネジメントするときに気をつけていること

この記事はSmartHR - Qiita Advent Calendar 2025 - Qiita シリーズ2の3日目です。

ここに書かれている文章は100%オーガニック、人間の手でタイピングされたものです。

まえおき

この文章の前提として、私はエンジニア組織のセカンドラインマネージャーとしての立場からエントリを書いています。 プレイングマネージャーなど、別の立場から見ると違う意見や感じ方があるかもしれませんので、その点を留意してください。

正確を期すため所属会社であるSmartHRのレポートラインの資料で示すと、このDirectorというポジションでの観点となります。 https://www.figma.com/board/HFNrUtz5Bf1c52YABCxxrY/SmartHR-%E9%96%8B%E7%99%BA%E7%B5%84%E7%B9%94%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6?node-id=0-1&p=f

開発チームのマネジメントをする

いきなり主題から外れますが、自分自身においても、チームにしても、より良くしていくには理想との差分を考えることが大切です。例えばアーキテクチャやコードの書き方一つとってもそうですね。

「いま困ってないからオッケー」も間違いではないのですが、変化が大きい環境ではより良くしていくためには同じ場所で考え続けるのではなく、何らかのチェックポイントからバックキャストしてどう近づけるか（あるいはこのままで良いか）を考えないと先に進むのが難しいです。

スクラムでいうところの透明性・検査・適応が大切なのはそういったことを実現するために必要なのかなと考えています。

閑話休題

「開発チームをマネジメントする」とはなんでしょう？チームメンバーの採用？プロジェクト進捗？チームの雰囲気？色々な観点があると思います。私がEMを始めた頃はチームのスクラムイベントを通じてチームの雰囲気を見ていることが多かったです。

今振り返って見ると、この頃のチームの接しかたは「問題が起こったら（起こりそうなら）対処する」という側面が強く、チームがより良くなっていくという観点はチーム任せだったように思います。

もちろん、それも大きな間違いではないと思うのですが、マネージャーとしてチームをより良い状態にしていくためには理想との差分を追求していく必要がありました。

そこに気がついてから開発チームの状況や長期的な計画を考える際に重要としているのは、以下のドキュメントに書かれている「ピープルマネジメント」「テクノロジーマネジメント」「プロダクトマネジメント」「プロジェクトマネジメント」のバランスです*1

これは広木さんがEMとして求められるスキルを体系化したものですので、ご存じの方も多いでしょう。このエントリでは、このドキュメントで整理された4つのカテゴリをベースに進めていきます。 エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド #マネジメント - Qiita

こちらのドキュメントはEMとしてこうしたスキルの獲得や強みを把握して意思決定などのマネジメントに活かしていきましょう、という話ではありますが、私はEMとしてのケイパビリティだけではなく、組織・チームなど各単位のケイパビリティとして各カテゴリのバランスを考えることが多いです。

EMにはEMとして求められる時間軸、影響範囲がありますが、チームという単位においても、求められる時間軸、影響範囲があります。もちろん、個人に対しても。 それらの枠の中で適切なケイパビリティが確保されているのか？あるいは支援が必要かを考えながらマネジメントをしているよ、という話です。

チームと4つのケイパビリティのバランス

個人の能力として4つのケイパビリティを全て十分な水準で備えるのは難しいですが、チームとしてケイパビリティをどの程度備えているか？あるいは苦手とする部分はあるか？ということを考えると、チームメンバーのバランスやマネジメント上注視する部分などを整理しやすくなります。

チーム内で長所や短所を理解して補っていけることが理想ではありますが、そうはいっても目の前のタスクがあるのでなかなか難しい面もあるでしょう。そんな時は、EMとしてプレイングマネージャーを通じて（あるいはチーム全体に対して）、仕組みや成長を促すことでバランスを取れるようにしていきます。

例えば、SmartHRのプレイングマネージャーというポジションにおいてピープルマネジメントを除外することはできませんが、プロジェクトマネジメントは別のメンバーに任せる、といった委譲は可能です。あるいは、得意なメンバーに背中を預けながら経験の浅いメンバーに挑戦を促すといったこともやりやすくなると思います。または、チームに人を配属する際には不足している能力を補える人を配属するなどが考えやすくなりますよね。

ケイパビリティと規模

自分自身がプレイングマネージャーだった頃、4つのケイパビリティの話を見ても「ほえ〜〜〜EMって大変なんだな」くらいにしか考えてなかったのですが、自身がEMとなってわかったことは、自分たちで決められる規模に応じて、それぞれの立場に応じたケイパビリティが備えられるようにチーム作りや委譲、支援などをしていくことが重要なんだな、ということです。

EMであれば事業成長に対してプロダクト開発がボトルネックにならないようなアーキテクチャや技術戦略、組織設計などが当たるでしょうし、チームであればロードマップなどのスケジュールに対して価値提供できる機能開発やその機能開発を阻害する課題の発見、解決などが当たるでしょう。 個人であればそのコードが妥当性のあるコードなのか？決定した仕様の懸念点をどこまで考えられか、といったことが当たると思います*2。

これは当時の自分に言いたいことなんですが、どのポジションにおいても、自身の責任範囲におけるテクノロジーマネジメントやプロジェクトマネジメント、プロダクトマネジメント、ピープルマネジメントは必要になるので、「EM大変そう〜〜〜」じゃなくてもっと体系立てた情報を咀嚼しておくべきだったな、と反省しております😓

そうしたことを踏まえて、今は管掌チームと話す際もこれらの4つのケイパビリティをチームとして十分満たせているか？誰かががんばりすぎていないかといったことを気にかけながらコミュニケーションを取っています。

こうした様々な要素をケイパビリティとして整理し、強み・弱みを把握した上でチームや組織の運営をしていけると透明性・検査・適応がやりやすくなり、より良い状態を目指しやすくなると考えていますので、皆様の参考になれば幸いです

なんか久しぶりにブログ書いたら文章のテイストがわかんなくなっちゃったんですが、これもオーガニック文章ならではの迷走ということで許してください。

*1:最近はテクノロジーマネジメントをプラットフォームマネジメント、として4つのPとも言いますね

*2:SmartHRではマネジメントラインなどの階層構造があるため上記のような分け方をしていますが、小さい組織であれば規模の大小はあれど1つのチーム自体にそれらが求められることもあると思います

Kaigi on Rails 2025へ参加した

Kaigi on Rails 2025

今年も会社で参加させてもらってありがたい話ですね

とても印象に残ったトーク

2日間で聞いたトークはどれも面白かったり興味深かったのですが、とくに以下はRailsに限らずイチWebアプリケーションエンジニアとして大切な示唆が含まれていたな〜〜と感じました（今回テーマに多かった非同期処理なんかもそうですが）

スライドはこちら

speakerdeck.com

speakerdeck.com

speakerdeck.com

それはそれとして、ぼくはこの紹介文を全身に刻んで山に篭ります。さいなら……

https://speakerdeck.com/takahashim/a-guide-to-japanese-books-for-rails-application-developers?slide=48

Railsアプリケーション開発者のためのブックガイド 48P

閑話休題

↑にあげたテーマなんかも顕著ですが、「使っている道具」「取り組んでいる仕組み」を高いレベルで引き出すのはとても大切な話だと思う。

およそこの業界は新規作成よりはメンテナンスのほうが時間が長いはずで、その時にどれだけ王道のポテンシャルを発揮させるかは腕に見せどころだし、トータルの運用コストを減らすといったことにもつながる。

30%しかポテンシャルを引き出していない中でXXに大移行しました、というよりは*1*2、80%くらいは引き出した上で不足している点を別の何かに接木する、くらいが良い塩梅なんじゃないかと思うわけですよ。

こうした内容は最近読んだ「エンジニアリング統括責任者の手引き」の「付録 E」に書かれている「標準化」のトピックにも通じるものがあるように感じるのですが、当たり前のことを当たり前にやって高い水準に到達する、というのは自分がプレイヤーの時に考えていた以上に重要なのでは？ということを近年マネジメントを生業とするようになって強く思うようになってきたんですよね。

というようなことを考えながらトークを聞いていたのですが、物事に深く向き合うための地に足がついた話が多くてとても実りのあるカンファレンスでした。登壇した方、運営スタッフの皆さん、ブース出展の皆さん、大変良い時間を過ごせました、ありがとうございます！

www.oreilly.co.jp

さいごに

こちらも何卒（ダイマ）

Kaigi on Rails 2025事後勉強会 - connpass

*1:これは特定のどこかを揶揄しているわけではない単なる例です。信じてください

*2:もちろん、そうせざるを得ない状況もあると思いますし、そこはそこで苦渋の決断があると思います

RubyKaigi 2025 荷物ストラテジー

基本方針

まず、大前提としてPCを捨てる いや、持っていっても良いんだけど、明確な用途がない限り滞在時間の3%も使わないことが（悲しいことに）わかってしまったから持って行かない方向で検討してる*1。あとPC持って歩き回ると腰が……

もちろん、メモを取るのにPCがあると便利なんだけど机がない場合も多いから結局スマホで実況メモを残すのが楽って結論を出しています

持ち物リスト

  • iPad
    • 主に時間潰し用なのでスマホで代替できる可能性は高いです。今回のRubyKaigiでは出番がなかった……
  • 着替え
  • 充電ケーブル
  • モバイルバッテリー
  • リュックとは別に現地で動きやすいようにサコッシュ的な小さめのバッグ
    • 10年？くらい前にbuildersconでもらったサコッシュを使い続けていたのだが、ついにぶっ壊れたので新調しなければ……
  • 細々したものとしてはティッシュや常備薬、何かと使うことがあるビニール袋的なものを1〜2つ

着替えについて

着替えは初日に身につけてる分 + 二日分の着替えを持ってきてる 多くの宿泊施設にはコインランドリーがあるから、滞在3日目に初日〜2日目の衣類を洗えばなんとかなる コインランドリーに失敗して、本当に本当のどうにもならなければ下着類だけ現地で調達しても良い（上着はガチの夏場以外は着回してもなんとかなるじゃろ）

あとは季節にもよるけどイベントのノベルティでもらえるTシャツなどをあてにすることで1着減らす、というテクを使うこともあります

ここ1〜2年くらいはこんな感じで旅行やカンファレンスへ参加しています。良いと思ったらいいジャン！お願いします

*1:カンファレンス中はともかく観光中は取り扱いにも気を使うので

DRY原則とDRYさせない方法

SmartHR Advent Calendar 2024 シリーズ1 の3日目です。

前日はalpaca-tcさんのRailsで任意のキャッシュストアを移行する - alpaca-tcでした。

さて、12月ですね。皆さん乾燥していますか？私は冬場の寒さに耐えられずエアコンを使いまくってしまうので当然のように乾燥しまくっています。

少し前まで空気清浄機兼加湿器を使っていたのですが、タンクの形状が複雑で汚れがちだったり加湿が十分なのかわからん、という状態でした。

そんなわけで2023年に象印のいわゆる魔法瓶的な加湿器を買って利用するようになったのですが、かなり潤ってる感じがしていて、なんなら加湿器に近い部分の布団は若干湿ってるような勢いなので乾燥対策はできていると考えて良さそう。

ちなみに、買った機種はこれです。 www.zojirushi.co.jp

給水のためには本体ごと持って行かないといけないので少々重かったり、デカいので風呂場でシャワーヘッドを使って給水することになっていますが、部品を外す手間などもないので楽と言えば楽です。シンプルな分取り扱いしやすいしオススメです。

これがDRYさせない方法ってｺﾄ!? ーーそうだよ！

というわけで閑話休題

DRY原則

良くも悪くもDRY原則、よく聞きますよね。「DRYにする」といって同じ仕様ではなく同じコードをまとめちゃってPRでやり取りをする、なんていうのは一生に一度は経験しているものかもしれません。

でも待ってください。そもそも、ぼくらはDRY原則について何を知っているのでしょうか？よく言及される原則ではありますし、大筋はわかると思うのですが原典ではどのように書かれていたのでしょう？

我々は原典を探すため、Amazonの奥地へと向かった

DRY原則の原典

Wikipediaによると、達人プログラマーが出典と書いてあります。

www.ohmsha.co.jp

おお、俺たちの達人プログラマーが原典だったのか。大昔に読んだ気がするけど全く覚えていない。

改めて読んでみても良いかもしれない……と考えたところで思い当たったのですが、達人プログラマーは初版と第二版が出版されています。

初版と、およそ20年の歳月を経て出版された第二版で内容を見比べてみると、当時と現代で気をつけているポイントが異なるかもしれないし、この二つを見比べてみると面白いかもしれない。

というわけで見比べてみました、というのが本エントリーの趣旨です*1。

DRY原則に関する初版と第二版の違い

まず、目次のタイトルからして違います。なんと初版ではDRY原則という名前がついてない（本文中に出てくる）。

初版 第二版
1章 7 二重化の過ち 1章 9 DRY原則 - 二重化の過ち

この時点で、20年の時を経てDRY原則が概念として確立した気配を感じますね。

ではもう少し見てみましょう。

流石に本文を丸々載せるわけにはいかないので、ざっと見出しを抜き出してみます。

初版

  • どのように二重化が発生するのか？
  • やむを得ない二重化
  • 不慮の二重化
  • 手抜きによる二重化
  • 開発者間の二重化

第二版

  • DRY原則はコード以外にも適用される
  • コードの二重化
  • コードの二重化すべてが知識の二重化というわけではない
  • ドキュメントに二重化
  • データにおけるDRY原則の違反
  • 表面上の二重化
  • 内部APIの間での二重化
  • 外部APIの間での二重化
  • データソースの二重化
  • 開発者間の二重化

比べてみて

シンプルな話ですが、第二版になって分量が増えています。それはなぜかというと、第二版にこのような記述があるのです。

「まず最初に述べておきたいことがあります。本書の初版では、「 DRY原則」が意味することについて書き足りない部分がありました。多くの人々はこれがコードの話だと受け取ってしまったのです。つまり、 DRYを「ソースコードのコピー＆ペーストをしてはいけない」と解釈してしまったのです。これも DRY原則の一部ですが、ほんの些細な一部でしかありません。 DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異なった場所（おそらくはまったく異なった場所）に同じことを表現するという問題を避けるための原則です。」

—『達人プログラマー ―熟達に向けたあなたの旅― 第2版』David Thomas, Andrew Hunt著 https://a.co/bGDC7rE

こうして見ると、当時の後悔だったのかそれ以降の時勢を読み取ったのかは分かりませんが、第二版で丁寧な解説になっているように見えます。 ソースコードの例も増えていて、わりとイメージつきやすくなっている印象もあります。

ただ、「データソースの二重化」に関しては趣旨はわかるけれども、あまり自分の好みじゃないかもしれねえ……。

それはさておき、第二版では「DRY原則」が指していることが詳細化され、言いたいことが誤解なく伝わるような構成になっていることと合わせて、内部APIや外部APIなどに言及されている点は現代っぽいなと感じました（とはいえ、API関連の話はそこまで記述が厚くなくて無念）。他にも、コミュニケーション面での話ではデイリースクラムやslackが例として挙げられるなど、本当にモダナイズされています。

詳しくは本書を買って君の目で確かめてくれ！という話なんですが、改めて読んでみた感想としては初版・第二版それぞれ良さがあるものの、DRY原則については「プログラマが知るべき97のこと」のDRY原則のエッセイを見るでも十分かもしれませんね……。

xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

それはそれとして、改めて達人プログラマーに目を通してみて再確認したのですが、ぼくは達人プログラマーの「まえがき」と「第一章」が好きすぎるかもしれない。自分のプログラマーとしての考え方の原型はここにあるなと再確認しました*2。 特に「まえがき」で書かれている "「単なる石を切り出すのが我々の仕事であったとしても、常に心に聖堂を思い描かなければならない」" が本当に好きすぎるんですよね

あなたの石切工はどこから？と聞かれたら「達人プログラマー！」と答えるくらい好きなので……

最終的にDRY原則というよりは達人プログラマー好きすぎるという話なんですが、読んでない人はみんな読んで！！！！１

www.ohmsha.co.jp

*1:偶然にも、初版と第二版を所持していた

*2:正確には、この本と「My Job Went To India」で作られたと言っても過言ではない

Kaigi on Rails 2024への参加とプロポーザルを出した結果得られたもの

1ヶ月経ってしまいましたが、ようやっとこの文章を書いています

Kaigi on Rails 2024、大変楽しめましたし普段会わないRubyistな皆さんとも交流できてとても楽しめました

Kaigi on Rails 2024

ちなみに、これは会場へのルート選択を誤ってビッグサイトに着いてしまった事例です

Kaigi on Rails で得たソフトウェアとの向き合い方

自分がそういうトークを見にいったから、ということもありますが……

以下のトークを見て、改めて感じたのはソフトウェア開発をどこまで深いレベルに潜って設計・開発できるかだな〜〜〜と思いました。表層的に解決しようとすると痛い目を見るのは経験しているものの、それを高いレベルで解決するためには練度が必要

Railsの思想やRailsが提供しているものを理解して上手に使おうというものがベースにありつつも、モデリングやRailsの拡張を通じて、どう破綻しないように事業成長を止めることなくソフトウェア開発を続けられるか。質とスピードの両方を維持していけるか、というのはやはりWebアプリケーションエンジニアとしての腕の見せ所だし、そこを深く考えられる人は尊敬してしまいますね……

speakerdeck.com speakerdeck.com speakerdeck.com

今回はプロポーザルを出した

それはそれとして、今回はKaigi on Railsにプロポーザルを出しました。事の成り行きは↓の同僚氏が書いたブログを見ていただくとして

はじめてのKaigi on Rails 2024 ── 初プロポーザルから登壇までの道のり - SmartHR Tech Blog

自身でプロポーザルを出したのは（たぶん）人生で2回目。今のところプロポーザル→登壇という流れは経験したことがないのでいつかは達成したいものですね

今回は「良いコードの書き方」的なかなり抽象度の高いテーマで応募したため、「それRailsと関係あるんか」という問いに対して芯を食った打ち返しができなくて落選したのかなと思っています

テーマ的にそれはそう、という話ではあるものの見せ方、伝え方次第であろうとも思っていて、もっとRailsでこういうコードあるよね！という文脈をセットで書ければもうちょっと良い線行けたんじゃないかとも想像しており、「この場（Kaigi on Rails）で、あなたが話すべき理由は何ですか？」という観点をもっと強くプロポーザルに乗せられるようにすべきだったなと反省しています

とはいえ、プロポーザルを出すということで自身がボンヤリ考えていたことを体系的に伝えるにはどうしたら良いか？など考えるきっかけにもなったし、プロポーザルを出す際の観点も（結果から考えれば当たり前の話ではあるけれど）しっかり受け止められたので良かったなと思います。

ちなみに、登壇できた暁にはJoel Spolsky氏の「間違ったコードは間違って見えるようにする」をフックにして話す予定でした。コード自体というよりはコメントなども含めた少し幅広いテーマではありますが 😆 （プロポーザル提出前の仮タイトルは「令和最新 間違ったコードは間違って見えるようにする」でした）

間違ったコードは間違って見えるようにする - The Joel on Software Translation Project

Kaigi on Railsの企画・運営していただいたスタッフの皆さんや登壇者、スポンサーなど関わった全ての皆さんのおかげで楽しく過ごせました。ありがと〜〜〜〜！

知識の探求と喜び #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:もちろん、十分スキルフルで少人数なチームであれば労せず達成できる可能性はあります