2026年7月31日から8月1日にかけて大阪で開催される Scrum Fest Osaka 2026 に『マネージャーこそコードを書こう』というタイトルで登壇します。詳しくは以下のプロポーザルをご参照ください。
年に1回はアジャイルコミュニティでの登壇をするということを心がけていて、今年は昨年に続きスクフェス大阪にご縁をいただきました。ありがとうございます。
タイトル的には Scrum Fest Kanazawa 2024 で発表した『ベテランこそ日報を書こう』を意識した、独立したシリーズものとなっています。以下はその際のスライドで、今年の発表スライドはスクラッチで真心込めて準備中です。お楽しみに。
私の発表は 2026年8月1日(土) 16:15-16:35 の Room2 です (最後のコマ) 。よければご参加ください。
大阪でお会いしましょう。
MCP (Model Context Protocol) が Linux Foundation の AAIF (Agentic AI Foundation) に寄贈された流れで、Linux Foundation メンテナーの org となる linuxfoundation-maintainers org に招待された。
これで何がどうなるの？というのはまだ作られたばかりなので自分もよく分かっていない。ちょっとした AI 利用ができるようには追加招待がされている。具体的に何がどうというのは、地域コミュニティなんかでお声掛けください。
ひとまず日記としての記録まで。
Findy メディアさんの「エンジニアたちのやらないことリスト」に寄稿しました。以下の寄稿記事の執筆後の、あとがき的な位置付けとして書き残しておきます。
今回は次の3つのやらないことを軸にしたお話になっています。
@naofumi さんから「プログラマーだけでなく、仕事をする全ての人にとっての金言が詰まっている内容だった。」とありがたい感想をいただきましたが、実はこれは著者の自分も半無意識化で行っていた裏テーマでした (というのを感想を読んで気がついた) 。
プログラマーだけでなく、仕事をする全ての人にとっての金言が詰まっている内容だった。
— Naofumi Kagami - 🇵🇸 lives matter (@naofumi) 2026年6月11日
素晴らしい！ https://t.co/Z5VbyH2pri
OSS プログラマーとしての記事という位置付けを取りつつも、日中のサラリーマン時間の考え方など含めて「やらないこと」をピックアップしてまとめた形になります。結果としては、ひとりのビジネスパーソンとしての自分自身の時間の使い方に対する考え方となるものから、3つの要素をピックアップして文章として表現しています。文中に出てくる Getting Things Done (GTD) は、いま読んでも何か参考になるものがあるかもしれません (自分が読んだ版は同じことが3回くらい書いてあった感じだけど、新装版だとどんな感じだろう) 。
GTD に影響を受けた「すぐ終わるタスクを溜め込まない」という考え方、姿勢は一般的なビジネススキルの話で、勤務先で共有した後に開発者以外からの感想としても「さっそく、すぐできるタスクを終わらせた」との声をもらってしめしめといったところ。
余談ですが、今回の執筆時における原稿 (Markdown) の文字数のチェック、ですます調のリンティング、リリース後の記事イメージの HTML への変換については、いわゆる生成したコードを見ないバイブコーディングで、プロジェクト自動化タスクを作ってチェックしながら原稿を書いていました。この話もどこかでできると面白いかもしれませんが、それはまたの機会に。
最後に、今回の執筆について、中薗さんにはお声掛けから記事レビューまで、過去の Findy Engineer Labさんのインタビュー、OSS開発記事に続きお世話になりました。特に今回のタイトルは、校正の際に中薗さんにいい感じに付けて頂きました。
「大切なのは「時間」以上に「心」の余裕」というのは、今回の機会がないと自分自身の中から引き出せなかったもので、リリース時のタイトル付けは編集者としての中薗さんの妙技を見た気持ちでした (ちなみに自分の提出時のタイトルは『OSS活動を続ける「やらないこと」3選』で、自分でももう少しいいタイトルが付けられそうなんだけど、、、と思っていたところ) 。素敵なタイトルありがとうございました！
よければご一読ください。
松江Ruby会議12 に参加した際、yhara さんの LT で自分の Pull Request に言及してもらっていたのがきっかけ。
スライド中に出てくる、chroma-dbのv2対応は @koic さんのPRです。感謝🙇♂️
— yhara (@yhara) 2026年6月6日
chroma-rb は、Chroma というベクトルデータベースの Ruby クライアントで、上記 Pull Request は Chroma v2 API 対応していた PR となります。
Pull Request を開いてから1年くらい停滞しているので、そろそろ作者に連絡をしても良いかな？と思い、最終的にメールをしてコミット権とリリース権をもらいました。
yhara さんの LT で言及されていた Chroma v2 API 対応は v0.9.0 としてリリース済みです。
この日記を書いていて、そもそも chroma-rb に Pull Request を送っていたのは、昨年の RubyWorld Conference 2025 の登壇準備の一環で Langchain.rb を試していたときに見つかっていたものだったかもしれないことに気がつきました (やや時系列があわない気もするけれど、結果的にだいたいそんな感じだったと思う) 。このあたりですね。
Ruby and LLM Ecosystem - Speaker Deck
ある意味で、松江イベント発祥によるパッチを、松江イベントによってリリースできたというストーリーでした。
カンファレンスによる Kaigi Effect の繋がりはおもしろいですね。
松江Ruby会議12に LT 登壇した。
島根県指定有形文化財の興雲閣での開催ということで、同僚の S.H. さんとテンションが上がっていたのがプロポーザル提出のきっかけだったと思います。参加できて楽しかったです。
何を話すかといったところ、度々見かける NotImplementedError の本来の用途ではない使い方の問題のエレベータピッチにしてみようと提出していたもの。松江Ruby会議のキーノートと対談コーナーのアイコンが元になっているのと、パラレルのタイムテーブルではないので、おそらく提案を直接聞いてもらえるだろうという前提を置いていた。
スライドは以下。
色々と聞けたのが収穫。自分の解釈として以下箇条書きで。
NotImplementedError を使うのは本来の意図ではないNotImplementedError の代わりのクラスを入れるではなく、サブクラスで実装すべきものをスーパークラスで実装していないままなら、ダックタイピングとして NoMethodError を起こすなどの設計が考えられるNotImplementedError はひとまずそのままSubclassResponsibility あるいは AbstractMethodError という名前の例外クラスを新設するScriptError を継承するものとする。StandardError ではない。余談ながら、自分は NoMethodError と同じような位置付けとして、StandardError を継承するものだろうと思っていたところ、そもそも NoMethodError も本来的には StandardError 継承をしたくなかったけれど、途中で変更するには影響が多すぎたというエピソードはなるほどとなった。
簡単にですが、公開スライドは発表時に加えて、上記を踏まえた「編集注」という但し書きを付与しています。
余談ですが、登壇について「間違っていたら怖いから発表できない」という声を聞くことがありますが、私の今回の登壇は間違っていた方を選んだもので、間違っていたらいたで直す機会になるし機会がなければ直らないので、むしろ登壇すべきだと思っています。間違えるつもりで間違う人はいないわけなので。
そんな感じで、自分の LT が、まつもとさん、卜部さんへの質疑応答というスタイルだったため、「卜部 昌平 氏 & まつもと ゆきひろ 氏の対談」コーナーで優先して質問を拾ってもらえていたというか、たくさん時間をもらってすみませんといったところ (ありがとうございます) 。
ここでの話は、開発者会議の議題として提出しておきました。後述。
2026年6月11日追記
開発者会議の結果、class AbstractMethodError < ScriptError という方針になったようです。ご検討ありがとうございました！
色々と印象に残ったトークはあるものの、shyouhei さんのトークは大江戸Ruby会議の生活発表会的な感じの OSS プログラマーの自然体な話で興味深く聞けたり、joker1007 さんと tagomoris さんの高度なギャング抗争はさすがだったり、pocke さんは本当に Ruby をイチから作っていてビックリするしかなかった。
多少音楽を嗜んだ身としては、純正律に関するトークをした nagachika さんのあとに、平均律で音楽を奏でる 5hun さんという、これもある意味で抗争的なトークになっていて良かった。mruby と PicoRuby のお膝元だけあって、ydah さん、makicamel さんはじめ、何らかのデバイスが用意されたトークの数も結構あったように思う。
高尾さんの司会がプロすぎて、RWC の司会の石原さんを彷彿しました。松江イベントの司会力すごい。
個人的には西田雄也さんと、KOF 2005 (厳密には KOF 宴会) 以来、20年ぶりにお会いして、しかも LT で並んでいたのがなかなかエモい会でした。実は生 shugo にお会いしたのはこの時が初めてなのですが、shugo さん覚えてらっしゃるかな？ (覚えていないと言われたことがあった気がする)
余談ながら、高橋会長の高橋メソッドの書籍のゲラハック会があったのも、この KOF 2005 の懇親会の後の夜のこと。
今回のカンファレンスでも、layout: takahashi といった構成を用意しているといったプレゼンを見たので、高橋メソッドは時を超えてきているのを感じていた。
自分の LT へのフィードバックをまとめたものを、bugs.ruby-lang.org へのイシューコメント並びに、2026年6月11日の開発者会議向けに提出しておきました。
2026年6月11日の開発者会議向けのイシューはこちら。6月8日までにコメントの旨と書かれていたのに気がついたのが、6月8日だったので急いで認めていました。
yhara さんの LT で言及していただいた chroma-rb の Chroma v2 API 対応の PR について、後日作者にメールしてメンテナンス権をもらって v0.9.0 としてリリースしておきました。
スライド中に出てくる、chroma-dbのv2対応は @koic さんのPRです。感謝🙇♂️
— yhara (@yhara) 2026年6月6日
今回の松江滞在中も、佐香やさんには遅い時間までお世話になりました。2日目は懇親会幹事の hasumikin さんに「お先に失礼します」せずに先に帰る失態。また遊んでやってください。
@koic お前黙って帰ったな？おれは不満 pic.twitter.com/uzQhOhrP1P
— 橘羽角前下総守情操指南匠均之助 (@hasumikin) 2026年6月6日
実行委員長の佐田さんはじめスタッフのみなさん、とても楽しい地域Ruby会議をありがとうございました。
『Ginza.rb 第97回 - RubyKaigi 2026を振り返る』に参加した。会場は東銀座のメドピアさん。いつもありがとうございます。
今回は表題のとおり RubyKaigi 2026 のふりかえり回として開催された。
参加者のほとんど (全員だった?) が RubyKaigi 2026 参加者ということで、概ねコンテキスト共有されている状態でスタート。
まず登壇者だった dak2 さんと自分がざっくり話をした際に、dak2 さんと自分のふたりともが、Rubydex は今後の Ruby エコシステムのキーワードになりそうという話として取り上げていたのは印象に残ったポイント。
そのあとは、基本的にタイムテーブルを初日から見ていって、参加したセッションで興味深かったものや、参加できなかったセッションで参加した他の人がいれば聞いてみるスタイルで流れていった。自分は Vlad の『Require Hooks: Filling the Gap in Ruby's Extensibility』の話が色々と発見のあるトークだったので、今年のイチオシトークとして話していた。ちなみに、この日に勤務先の永和システムマネジメント社内でも junk0612 主導で進めてもらっている RubyKaigi 2026 社内ふりかえり会が開催されていたのと、他の Ginza.rb 参加者も勤務先でふりかえり会を行ったなど、RubyKaigi は各所でふりかえりされる愛されたカンファレンスだと思う。
限られた時間ということもあり、タイムテーブルベースの感想戦は Day 2 まで。Day 3 は Matz のクロージングキーノートがテーマとなった。Spinel はとても興味深いプロダクトということで、Ginza.rb のお題イシューにも登録された。
懇親会では、Ginza.rb から Ruby Kaja 2026 に推薦していた内藤さんを、Sch"matz" でお祝い乾杯したりしていた (おめでとうございます！) 。
Ruby Kaja の流れで書き残しておくと、コミュニティかわらばんの寄せ書きが募集されています。Ginza.rb メンバーからの寄せ書きを絶賛募集中です。1回でも参加すれば Ginza.rb メンバーだと思いますし、お祝い事みたいなものなので遠慮なく書いていきましょう。
詳しくは以下リンクをご参照ください。
次回の Ginza.rb は 2026年7月頃の開催予定のようです。
ko1 さんから、RubyKaigi 2026に書店を出すので、AI 関連書籍をピックアップして紹介するゲストをしないかという打診があり、Day 2 の Afternoon Break の時間にゲスト参加させてもらいました。
入荷してもらった書籍、入荷できなかった書籍、その他の書籍について、改めて私の主観でまとめておきます。
入荷してもらった書籍は以下。
現代 AI のバックエンドとなる LLM をブラックボックスのまま使っているエンジニアには特におすすめしたい一冊だったので、特に仕入れをしてもらいたいというものだった。予想外に1冊売れ残っていたかもですが、社内読書会の次の一冊にしますという声や、電子書籍で購入しますといった声を聞けたので、書籍としての認知度は多少上げられたかなといったところ。私からの推薦文は「未読の方はみんな読もう」にしていたと思います。未読の方はみんな読もう。
いわゆる生成したコードを見ない狭義のバイブコーディングと、従来の開発手法のポイントポイントに AI を活用する両端の間のどこかに我々はいるという、中庸といった立ち位置の書籍。二元論ではなく現実はその狭間にあることと、AI は原則としてできることを補助するブースターに過ぎないことを説いている。RubyKaigi のコードを書いている人向けかというと、もう少しマネージャー側の視点が強い書籍かもなものの、中庸的な考え方を得る意味でも選書しておいて良いかなと思い含めた。
いまの時代、コーディングエージェントツールの書籍が並んでいてよかろうと、Claude Code を我流で使っている人におすすめできるかと思って選んだ一冊。自分の書いた最初の帯が良くなかったかなというので一冊売れ残ったかも。Claude Code は営業日毎日リリースされているスピード感なので、書籍の細かな部分は古くなっている部分があるものの、考え方の大枠などはいまでも通じるし、gihyo.jp などで著者フォローアップされているので、いまからでもこの一冊はおすすめできると思う。早いうちに読んだ方が、Claude Code 最新版との差分も少なくて済むのでおすすめ。
入荷分売り切りできていたと思う。正直、このレベルの書籍を翻訳ではなく、日本人著者の書いたものそのままで日本語で読めるのはとても貴重だと思う。そして、現代 AI の辿り着く先は原論文になるものの、そこにスポットをあてた希少な書籍にもなっている。翻訳本でないのに、異常なまでに注釈が記されていて、著者の熱量が半端ないのは手に取った人に伝わったのかもしれない。RubyKaigi 参加者は選ぶ購入書籍もハードコアだった。ちなみに私からの推薦文としては「日本語で読めるAI関連書籍の最高傑作」といったようなテキストを書いていました。arXiv の論文群を正面から取り扱った書籍というのは他に類を見ないと思います。
コーディングエージェントとして LLM を使うのではなく、例えば Rails アプリに LLM を組み込むといった、開発対象への AI 活用向けに選んだ一冊。店頭に立っていても、アプリに AI を組み込む勘所を得られる書籍がないか尋ねられたときに紹介できたのでちょうどよかった。Python で書かれているのはいつも通りだけれど、こういった内容のものが Ruby で書かれて出版されるようになると、Ruby x AI にとってひとつの転換期になりそう。
以下は入荷できなかったと伺っている書籍。
RubyKaigi という場所に、完全に Python な書籍を入れるべきか悩んだものの、LLM そのものを知るのにとても良いと思ったので選んだ一冊。特に最初の方は AI という分野における LLM の位置付けから、Transformer アーキテクチャの概略が説明されていたり、付録には PyTorch が記されていたりと、現代 LLM を支える技術のコアな部分から説明が割かれているということで選んでいたもの。残念ながら仕入れができなかったようだけど、RubyKaigi 参加者は選ぶ購入書籍はハードコアとわかったので、仕入れができていたら売り切れていたのかもしれない。
一転して、こちらは読みもの形式で手軽に読める一冊。帰りの飛行機のお供にも良いかなと思い選んでみた。仕入れには至らなかったものの、LLM を復習するのに良いと思う。
これを読めば、Transformer アーキテクチャにある Scaled Dot-Product Attention が何をやっているものかを理解できると思う。ちょうどこの書籍の制作に関わった翔泳社の方と話す機会があったけれど、実際に売れ行きよく品切れ中で入荷できなかったとのこと。書籍としても数式のフォントを柔らかくしたり「怖くないよ」の工夫を凝らされていたというお話を聞けたりと、その場には見本誌しか置いていなかったものの、実物があったら売れ行きを見届けたかった一冊。
以下は悩んで仕入れリストに記さなかったもの。
自分が MCP の話をするのに入れ忘れていた一冊。登壇で「基本的な話は他所に任せる」といったことを言ったのに、何のポインタも示していなかったという。私の登壇で割愛している MCP の基本はこの書籍がコンパクトにまとまっていると思います (他の MCP 書籍は手に取っていないので純粋に知らないだけ他意はないです) 。リストアップしていなかったのは、自分のトークに対して本当に片手落ちだった。そんなこともある。
LLM は突然に登場したものではなく、長い歴史の重なりの上に登場したということがわかる一冊。うーん、これ RubyKaigi どころかプログラミングもあまり関係ないけれど、どうしようかなと思って割愛したものの『原論文から解き明かす生成AI』を入れた時点で、候補に上げてもよかったのかと思う。
『大規模言語モデルは新たな知能か――ChatGPTが変えた世界』の姉妹本で、こちらは Diffusion Model について記された書籍。LLM を前提とした AI 話が多いものの、こういった画像、動画系のモデルについての書籍もあると面白いかも？と思いつつ選び損ねていた書籍。版元の取り寄せ都合で入手できなかったかもしれないけれど、LLM 以外のモデルの仕組みを知る機会の書籍としてリストに入れておいてよかったかもしれない。
以上が自分が読んできた AI 関連書籍ですが、通読したものしていないものも合わせて、この1年で手にしたきたものを中心に選びました。
おもしろい機会を設けていただいた ko1 さんに感謝します。
