give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

「技術記事を書く技術」の著者直筆ポップを書く技術

はじめに

先日、大阪〜神戸の書店を回って「技術記事を書く技術」の直筆ポップを置かせてもらいました。

東京の書店にも直筆ポップを置かせてもらっています。

直筆ポップを置いている書店は以下の通りです。

<東京>

  • ジュンク堂書店 池袋本店
  • 三省堂書店 有楽町店
  • ブックファースト新宿店
  • 丸善 丸の内本店
  • 書泉ブックタワー
  • 紀伊國屋書店 新宿本店

<大阪・神戸>

  • MARUZEN&ジュンク堂書店 梅田店
  • 紀伊國屋書店 梅田本店
  • ジュンク堂書店 大阪本店
  • ジュンク堂書店 難波店
  • ジュンク堂書店 三宮店

上記の書店にお立ち寄りの際は、ぜひ僕の直筆ポップをチェックしてみてください!

「技術記事を書く技術」を見つける技術?

ちなみに、実際に書店を回って思ったのですが、「技術記事を書く技術」は、

  • これまでにないジャンルの本なので、どの棚にあるか予想しづらい
  • 表紙がシンプル(悪くいえば地味)なので、他の書籍と並んだときに埋もれやすい

という問題(?)があり、自力で見つけるのにちょっと苦労しました。

この直筆ポップが置いてあるお店は、多少「技術記事を書く技術」を見つけやすくなるかもしれません。

直筆ポップがあるとき〜(左)ないとき〜(右)

もし自力で見つけられなかった場合は、書店員さんをつかまえて「すいません、『技術記事を書く技術』はどこにありますか?」と大きな声で聞いてください!!

直筆ポップの作り方

ところで、本を書いた人なら一度は作ってみたい(?)著者直筆の書店用ポップですが、いざ作ろうとすると「どうやって作ればいいの!?」と困ってしまうかもしれません。

そこで今回のエントリでは、僕がどんな流れで直筆ポップの作ったのかを説明しておきます。

1. 準備

まず、編集者の人に「直筆ポップを作ってみたいんですけど」と相談しましょう。
ほとんどの場合、「いいですね、やりましょう!」と乗ってきてくれるはずです。
直筆ポップを書く厚手の台紙は、編集者の人が自宅まで送ってきてくれると思います。

台紙が届いたら、多めにカラーコピーしておきましょう。
これは何度もデザイン案を下書きできるようにするためです。

次に、ポップを書くための色ペンを用意しましょう。
今回は100均で太めと細め、2種類の色ペンを買ってきました。


2. 情報収集する

「書籍 直筆ポップ」「技術書 著者直筆POP」のようなキーワードでネットを画像検索してみましょう。
また、「ジュンク堂書店池袋本店 PC書担当」さんは、直筆ポップの写真をXにたくさん載せてくれているので、過去事例を探すのに大変役立ちます。

"from:junkudo_ike_pc 直筆POP"のXの検索結果

これらの事例を見ながら、なんとなく自分の中のイメージを膨らませます。

3. 生成AIに叩き台を考えてもらう(?)

上のような情報収集だけで、すぐに「よし、こんなポップを作ろう!」とアイデアが出てきた場合はいいですが、僕のようなデザイン素人にはそんな芸当はできません。
というわけで、とりあえず生成AIに叩き台を作ってもらうことにします。

今回はこんなプロンプトをGeminiに打ち込んでみました。

以下の本を執筆した。書店に置いてもらう著者直筆POPの叩き台画像を考えてほしい。

https://www.shoeisha.co.jp/book/detail/9784798177045

Geminiが提案してきた直筆ポップのデザイン案はこんな感じでした。

……うーん、なんかイマイチですね😅
やっぱり自分でじっくり考えることにします。

4. 下書きを(山ほど)書いてみる

直筆ポップを作るためのインプットはこれぐらいにして、ここからは実際にデザインを考えましょう。
まずはポップを見た人に何を伝えたいかを考えて、ポップに載せるキーワードを検討します。

そして、事前に用意しておいた台紙のコピーに、あれこれ文字を書いていきましょう。
文字を書くのは台紙のコピーなので、いくら失敗しても大丈夫です。
コピーがなくなったら、さらに追加で台紙のコピーを取ってください。

こんなふうにあれやこれやと下書きをいくつも作り、最終的に以下の2案に絞りました。

案1:メッセージを大きく打ち出すパターン

案2:「あるある」なお悩みに訴えかけるパターン

5. 編集者の人と相談してデザインを選ぶ

どっちがいいのかは編集者の人の意見も参考にした方がいいと思ったので、編集の大嶋さんにどっちがいいですか?と尋ねてみました。

大嶋さんからは次のような返事が返ってきました。

下書きありがとうございます。
2つのパターン、どちらも内容がしっかり伝わってきて、とてもよいと思いました。

個人的には、メッセージを大きく打ち出している1つ目のパターンが、今回のPOPにはより合っているように感じました。
POPは、書店の店頭でひと目でメッセージが伝わることや、今の時流に合った言葉を載せやすいことが強みだと思うので、今回であれば 「AI時代だからこそ、人が書く技術記事に価値がある」 という点を前面に出せるとよさそうです。

なるほどなるほど。
僕もそれでいいかな、と思ったので、今回は「案1:メッセージを大きく打ち出すパターン」を採用することにしました!

6. パソコン上で文字の大きさや配置を検討する

次は文字の大きさや配置を検討します。
これもコピーした台紙の上で考えてもいいのですが、より細かい試行錯誤がしやすいように、パソコンの画面上で検討することにしました。

具体的には台紙をスキャンして画像化し、それをスライド作成ツールのKeynoteに取り込んで、その上に文字を書き込んでいきました。


7. 配色を検討する

このままだと白黒の味気ないポップになってしまうので、これまたGeminiに配色の叩き台を考えてもらうことにしました。

添付画像のような書店用直筆POPを作成した。色ペンで魅力的な彩色を入れたい。

Geminiが提案してきた配色案はこんな感じでした。

うーん、いいような、そうでもないような……。
いや、やっぱり微妙ですね。

というわけで、配色に関しても実際に色ペンを使い、コピーした台紙上に何度も下書きを繰り返しました。

8. 直筆ポップのデザインが完成!

あーでもない、こーでもない、と言いながら下書きを繰り返した結果、直筆ポップのデザインは以下のようになりました。

個人的なこだわりポイントを以下にまとめます。


  1. 「あなたの言葉で 技術記事を書こう!」これが一番伝えたいメッセージなので、黒ペンで目立つように書いています。さらに目立つよう、アクセントカラーの赤で下線も入れています。ちなみに「あなたの言葉で」は細ペンで、「技術記事を書こう!」は太ペンで書いているのですが、ここはそこまで違いがわからないですね。
  2. 「15年分の知見とノウハウをすべて詰め込みました。」はサブメッセージです。「(私が)詰め込みました」は著者にしか書けないメッセージなので、これがあることで著者の直筆ポップだと伝わりやすくなるはずです。黒ペンで書くとごちゃごちゃしたので、黒ほど前に出てこない青文字で書いています。また、「15年分」の下には強調と彩りの目的で黄色で下線を入れました。
  3. 文字で書籍名を入れるとそれもごちゃごちゃしたので、代わりに表紙の縮小コピーを貼り付けました。また最悪、何かの事故で直筆ポップと書籍が離ればなれになったとしても、表紙画像があれば、これは「技術記事を書く技術」の直筆ポップであることがすぐにわかるはずです。
  4. メインメッセージ=黒、サブメッセージ=青、なので、区別しやすくするように著者名はまた黒に戻しました。「伊藤淳一」だけでも良かったのですが、それだと空白ができてしまうので、あたかもその日に著者がやってきたかのように見える日付を入れることにしました。(関西の書店には実際に行ってますけどね)
  5. 「AI時代だからこそ」は、実はオマケワードです。「右上に空白ができるので何か埋めたいな」と思い、編集の大嶋さんのフィードバックにあった 「AI時代だからこそ、人が書く技術記事に価値がある」というコメントから「AI時代だからこそ」を拝借しました。表紙のアクセントカラーに合わせて文字色は緑にし、吹き出しは台紙の縁(ふち)の色に合わせて水色にしました。
  6. 一枚一枚手書きで書いてますよ、ということを証明するために、各ポップには書店名を入れています。ただし、書店名が目立つとやはり全体がごちゃごちゃするので、あえて(一番目立ちにくい)ボールペンで書店名を書きました。

9. がんばって量産する

デザインが完成したら、あとは同じポップを量産していきます。
といってもこれは「著者の手書き」であることがポップの価値になるので、機械を使ったコピーではなく、がんばって自分の手で書き書きします。

東京の書店用に6枚、大阪・神戸の書店用に5枚作ったので、結構大変でした!!💦

東京用のポップ 6枚
大阪・神戸用のポップ 5枚

ちなみに台紙に貼り付けている表紙画像は、東京用は翔泳社さんに用意してもらい、大阪・神戸用は僕が自分で作りました。
表紙画像を印刷する→カッターで切り取る→糊で貼り付ける、という作業も地味に大変でしたね😅

10. 書店に配布する

最後に、直筆ポップを各書店に配布したら、ミッションコンプリートです。
東京方面は、兵庫県民である僕はぱっと行けないので、翔泳社さんに郵送して書店に配布してもらいました。
大阪・神戸の書店は、事前に翔泳社さんから各書店に連絡を入れてもらった上で、僕が書店に足を運んでポップを置いてもらう、という手順で配布しました。

紀伊國屋書店 梅田本店にて

ちなみにポップを置いてもらう際に、書店員さんから「これ、たくさん売れてるので、追加発注かけてるんですよ〜」みたいな話を聞いたときは、とても嬉しかったです!

まとめ

というわけで、このエントリでは拙著「技術記事を書く技術」の書店用直筆ポップの作り方を解説してみました。
我流なのでもっとスマートなやり方もあるかもしれませんが、こういう泥臭いやり方のほうが、より「著者のぬくもり」を感じやすいんじゃないでしょうか?(と、勝手に思っています)
もし「著者の直筆ポップ」を作ろうとしている人がいたら、今回のエントリをぜひ参考にしてみてください。

そして、直筆ポップを作る予定はなくとも、「技術記事を書いてみたいな」「もっと上手に書きたいな」と思っている人は、ぜひぜひ、「技術記事を書く技術」を手に取ってみてください。
きっとみなさんの悩みを解決するヒントがたくさん詰まっているはずです!よろしくお願いします!!

唯一の正解なんてない。「技術記事を書く技術」が「私見強め」になった理由(アウトプットに関するリンク集もあるよ)

はじめに

このブログでも何度か紹介してきたとおり、本日2026年4月27日に、僕が執筆した新刊「技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて」が発売されました!🎉


この書籍はタイトルの通り、アウトプットに興味があるITエンジニアに向けて、技術記事を書く方法を指南する本です。
また、「書き方」のみならず、ネタの見つけ方や、記事を公開したあとの反応との向き合い方なども説明しています。
さらに、最後の第3部には、他のエンジニアが書いた実際の技術記事を僕が添削するパートもあります。

「技術記事を書く技術」の概要を知る

本書の目次は以下の通りです。

【第1部 最初の一歩を踏み出す】

  • 第1章 技術記事を書く目的とメリット ⭐️試し読み可
  • 第2章 まず1本記事を書いてみる

【第2部 質を高める】

  • 第3章 ネタを見つける技術
  • 第4章 事前準備の技術
  • 第5章 見出し・タイトルの技術 ⭐️試し読み可
  • 第6章 構成・見せ方の技術
  • 第7章 正しい情報を正しく伝える技術 ⭐️試し読み可
  • 第8章 文章を読みやすくする技術
  • 第9章 よいサンプルコードを書く技術
  • 第10章 公開・シェアする技術
  • 第11章 反応と向き合う技術
  • 第12章 アウトプットを継続する技術
  • 第13章 アウトプットの幅を広げる技術

【第3部 実例添削で学ぶテクニック~達人による 38 のフィードバック~】

  • Case 1:「技術を自分なりの言葉で説明する」記事
  • Case 2:「エラーの解決方法を解説する」記事
  • Case 3:「新しい技術を触ってみた」記事

このうち、第1章、第5章、第7章は翔泳社の書籍紹介ページにある特別抜粋版PDFで試し読みができます。

技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて(伊藤 淳一)|翔泳社の本

また、書籍冒頭の「はじめに」は、僕のXのポストにアクセスすれば読むことができます。

購入を迷っている方は、「試し読み」をうまく活用して、自分のニーズに合う本かどうかを判断してみてください。

ここからが本題:アウトプットに唯一の正解なんてないんだよ

さて、ITエンジニアのアウトプットに関する本を書いておきながら、こんなことを言うのもなんですが、アウトプットに唯一の正解はありません。

僕が本の中で書いていることも「数ある正解のひとつ」です。

「そんなの当たり前じゃないか」と言われそうですが、この本の執筆に取りかかる前は「自分ならアウトプットのバイブルになるような本が書けるんじゃないか」と考えていました。

僕自身「技術記事を書くならこうした方がいい」という考えがいくつかありましたし、ネットを見ていてもいろんなエンジニアが「アウトプット論」を語っています。
そこで「僕自身のアウトプット論」と「世間でよく言われるアウトプット論」をくまなくカバーするような本を書けば、「完全無欠のアウトプット論」ができあがるはずだ、と考えました。

が、言ってることはみんなバラバラだった

ですが、このアプローチは秒で頓挫しました。
というのも、みんな言っていることがバラバラだからです。

ある人は「読み手のことを考えて記事を書け」と言い、またある人は「技術記事なんて自分のために書くものだ」と言う。

ある人は「同じような記事がすでにあるなら、自分が記事を書く意味はない」と言い、またある人は「同じ記事であっても、気にせず書けばいい」と言う。

と、こんな調子でみんな正反対のことを言うので、とても「これが正解」なんて言えるようなものは導き出せなさそうでした。

僕「唯一の正解なんてない!僕は僕の考えていることだけを書く!!」

というわけで、方針変更です。
誰もが納得する「完全無欠のアウトプット論」なんてものは書けそうにないので、「僕の本なんだから、僕の好きなように書かせてもらいます」というポリシーに変更しました。

原稿を書きながら「これ、正反対のことを考える人も絶対いるだろうな〜」と思うような場面もたびたびありました。
ですが、そういうときは毎回「いや、唯一の正解はないんだ。だから、ここは僕の考えを書く!」と強い気持ちで、僕自身のアウトプット論を書いていきました。

なので、「技術記事を書く技術」はとっても「私見強め」です。
本書を読みながら「ちょっと私見が強すぎるんじゃない?」と思うような箇所があったら、それは意図的にそうしていると考えてください。

私見強めですが、そのぶん、この本には僕自身の個性やオリジナリティが詰め込まれています。
それがかえって本書の面白さを引き立てているはず、と僕自身は信じています。

とはいえ、他の人のアウトプット論もチェックしていた

上で述べたように、「技術記事を書く技術」は、僕「伊藤淳一」が考えるアウトプット論を書く、というポリシーで執筆していました。
ですが、その一方で参考情報として他の人のアウトプット論もたまにチェックしていました。
具体的には、はてなブックマークやQiitaの週間ランキングでアウトプット論っぽい話題が出ていたら、ざっと目を通してネタ帳にURLを保存していました。

本の執筆には4年かかったので、その間にいろんな記事のリンクが集まりました。

他の人のアウトプット論もぜひ参考にしてほしい

繰り返し述べている通り、アウトプットに唯一の正解はありません。
よって僕以外の人が語るアウトプット論もまた「数ある正解のひとつ」です。

世の中には僕と同じ意見、ちょっと違う意見、まったく違う意見など、さまざまな意見があります。
ここから下ではカテゴリ別に、他の人が書いたアウトプット論のリンクを集めました。
タイトルを見て興味を持った記事があれば、ぜひチェックしてみてください。

アウトプットに関するリンク集

まとめ:AI時代だからこそ、あなたの言葉で技術記事を書こう

というわけで、このエントリでは本日発売の新刊「技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて」の紹介と、僕以外の人が書いたアウトプット論のリンク集を作ってみました。

リンク先の記事を読むと、僕と同じことを言っている人もいれば、僕と違うことを言う人もいます。
でも、それは唯一の正解がないのだから当然です。
また、「技術記事を書く技術」の中には、他の人が書いていない、僕だけのアウトプット論や、アウトプットに関する知見も載っています。

繰り返しになりますが、「技術記事を書く技術」は「私見強め」です。
言い方を変えれば「個性が強め」です。

しかし、本の執筆も、技術記事の執筆も「個性強め」でいいんじゃないでしょうか。
みんな同じことばかり書いてもつまらないですし、AIに聞けば同じようなことを答えてくれるような記事も「それじゃあAIに聞きますわ」ってなりません?

先日開催されたRubyKaigiでは、先行販売用にこんなポップを作りました。

AI時代だからこそ、あなたの言葉で技術記事を書こう。

AIにお願いすればそれっぽい記事を書いてくれますが、「あなた」という人間の個性が一番発揮できるのは、あなた自身が書いた記事です。
「技術記事を書く技術」を読んで、あなた自身の言葉で書かれた技術記事を書いてみましょう!

「ありがとう」で埋め尽くされた、初めての #RubyKaigi

はじめに

今回のRubyKaigiは2026年4月22日〜24日に開催され、僕は初参加でした!

って言うと、

「えっ、伊藤さんってRubyKaigi初めてなんですか?意外!!」

と思った方も多いと思います😅
そうなんです。Ruby歴10年以上で初めてなんです。

コロナ前は仕事が忙しくて行けず、コロナ中はコロナなので行けず、コロナ後も家の中がバタバタして行けず。
今年になってようやくいろいろ落ち着いたので、「よし行くぞ!」と初めてRubyKaigiに行く決意をしたのでした。

ただし、家の用事があるため、3日間フルで参加することはできず、Day 0(イベント前日)からDay 2の昼過ぎまでしか滞在できませんでした。。
それでもとても充実した時間を過ごすことができたので、今回は僕のRubyKaigi参加レポートを書いていきます。

rubykaigi.org

【もくじ】

Day 0:えっ、飛行機が飛ばないの?

前日入りするために、僕は午前11時 伊丹空港発、函館空港行きの便を予約していました。
なるべく十分な余裕を持って行けるように、朝9時に伊丹空港に着きました。

が、空港に着くとターミナル前に長蛇の列が。
これは何事?と思ったら、なんと!

えー、まさかの管制システムトラブル発生。
その前日には東北で大きな地震があったし、なんとも不運続きな・・・。

長蛇の列を眺めながら「どうするべ」と立ち尽くしていたら、前方から知ってる人が歩いてきました。
「あ、ydahさんだ」
というわけで、ydahさんに声をかけて、「いやあ、本当に困りましたねえ」と2人で話していました。
その後、同じく飛行機に乗れなくて困っていたluccafortさんも合流して、3人で「函館に行けないなら、ここで伊丹.rbを開催しますかあ」と冗談を言ったりしていました。

なんとか1時間遅れで出発できることに

飛ぶのか飛ばないのかはっきりした情報がなく、

「飛ばなかったらどうする?新幹線で行く?」
「えっ、新幹線で行くと8時間かかるの?それはキツいなあ……」

みたいな話をしていましたが、最終的にはなんとか1時間遅れで飛ぶことになりました。

ただ、僕たちはJALの便でしたが、同じ時間帯に飛ぶ予定だったANAは欠航になっており、ANAで予約していた人は他の手段で函館に向かわないと行けなかったみたいです(大変だ……)。

函館着。美味しいお寿司を食べる

函館には14時過ぎに着きました。
RubyKaigi前日に1時間遅れで到着するなら全然許容範囲です。

函館空港にはRubyKaigiの看板が立っていました。

Day 0はANDPADさんの前夜祭に参加する以外、特に予定を決めていなかったのですが、伊丹空港で落ち合ったydahさんとluccafortさん、それと現地で一緒になったすぎうりさんと一緒に、函館駅周辺でちょっと遅いお昼ご飯を食べました。

tabelog.com

入ったお店はうに専門店だったのですが、僕はそこまでうにが好きではなかったので(せっかくつれていってもらったのにすいません💦)、お寿司を食べました。

お寿司はどれもめっちゃ美味しかったです。さすが函館!
そして、普段はそこまでたくさん食べる人ではないので、お腹がいっぱいになりました。
ごちそうさまでした!!

晩はANDPADさん主催の前夜祭へ

お寿司を食べた後はみんなでRubyKaigiの会場に向かい、プリチェックイン(前日の入場受付)を済ませました。
当日の混雑を緩和するために、前日にネームバッジ?イベントパス?がもらえるようになってるんですね。
初参加なので初めて知りました。

そして晩はANDPADさん主催の前夜祭へ向かいました。

https://andpad.connpass.com/event/385957/

ここでも美味しそうな料理がたくさん出てきたのですが、少し前にお寿司をたらふく食べたあとだったので、一口ずつぐらいしか食べられませんでした。悔しい&申し訳ない。。。

僕のテーブルでは、たまたま隣に以前からよく知っているhsbtさんとwillnetさんが座っていたので、ぼっちにならずに済みました(RubyKaigiには初参加だったので、この時点では結構緊張してたんですよ……)。

Photo by TONYさん

前述のとおり、この日は飛行機が飛ばなかったりした影響で、この前夜祭は当日キャンセルが大量に発生したみたいです。
そのため、キャンセル待ちだった人の大半が繰り上げ参加できたそうです。

それにしても、これだけの人数に対して無料で前夜祭を開催してくれるANDPADさんってすごい。
楽しい前夜祭を開催してくれて、どうもありがとうございました!!

Day 1:初めてのRubyKaigiがスタート!

さて、いよいよRubyKaigi当日です。
Day 0ではいろんなRubyistたちに会って話したので、緊張感はだいぶんなくなっていました。

ここから下では当日聞いた発表を簡単にまとめていきます。

キーノート:The Journey of Box Building

Ruby 4.0から実験的に導入されたRuby Boxについて、大変だった部分や具体的な実装方法が語られていました。技術的な部分は難しいところも多く「完全に理解した」とは言えませんが、Ruby Kaigi 2023で起きたあるきっかけがRuby Box開発の動機になり、この函館(ハコ=Box、館=Builidng)で奇跡的に伏線回収された、というエピソードがお見事でした!

When Can You Skip a Test? Tracking Test Impact

「巨大なプロジェクトではテスト全体を毎回実行すると遅い。でも、コードの変更点に関係するテストだけを実行すれば速く終わるよね」というコンセプトで開発された、テスト影響度解析(Test impact analysis) gemの解説です。

github.com

僕も実務では「毎回全テストを回すのは無駄が多い」と思っていたので、これはとても興味深い発表でした。
ただし、登壇内容としては、「どういうふうに影響度を解析するか」という技術的な解説がメインで、具体的な導入手順については語られませんでした。
このgemはかなり気になるので、折を見て詳しく調べてみようと思います。

Liberating Ruby's Parser from Lexer Hacks

speakerdeck.com

伊丹空港でご一緒させてもらったydahさんの発表です。
が、これは前提知識がない状態だとかなり難しかったかも。。

発表を聞いた時点ではほとんどわからず、このブログを書いている今の時点で、スライドの内容をGeminiに要約してもらったり、ydahさんが書いていた告知ブログを読んだりすることで、「なんとなくわかった(気がする)」という状態になりました😅

雑にまとめると、こんな感じでしょうか?(間違ってたらツッコんでください、ydahさん!🙏)

  • Rubyの文法は柔軟だが、悪くいえば曖昧でパーサーにとっては嬉しくない
  • 従来のRubyではlex_stateというフラグをparse.yに埋め込んで、強引に曖昧さを解決していた
  • だがこれはハック的な手法なので保守性が非常に悪いという問題があった
  • そこでPSLRという手法(理論)を用いて、構文の曖昧さを6種類(6つのレイヤー)に分類した
  • この分類の結果、6つ目のレイヤー(Layer 6)以外は、必ずしもlex_stateに頼る必要がないことがわかった
  • Rubyの文法の複雑さを整理・可視化したことで、未来のRubyを安全に設計・進化させるための土台が完成した
Guide to getting started walking source codes of CRuby

https://youchan.info/slides/RubyKaigi2026/

CRubyのコードを読むときのコツを解説する、youchanさんの発表でした。
「RubyKaigiに参加してるけど、CRubyのコードは全然わかりません!」っていう人は結構多いんじゃないでしょうか?
かく言う僕もその一人です(苦笑)。

さすがに「この登壇を聞けばCRubyを全部理解できる」というわけにはいきませんが、それでもCRubyのコードを読むときのハードルがぐっと下がったんじゃないかと思います。

また、会場ではyouchanさんの執筆した「CRuby Quest 〜Rubyのぼうけんのしょ〜」という同人誌も売っていたので、これとあわせて読めば、さらにコードリーディングが捗ります。

ちなみにAIにコードの読み方を答えてもらう際は「ギャル語」に設定するのがオススメだそうですw

Digits, Digits, and Digits

https://drive.google.com/file/d/1HCxghNmKMx8WIMdPp3hgNmAlEOxtMbId/view?usp=sharing

巨大な数を高速に計算するためのBigDecimalのアルゴリズムを見つけるまでの、tompngさんの試行錯誤の過程を解説する発表でした。
見つけたアルゴリズムは、実は"Bit-burst"と呼ばれる既存のアルゴリズムで「車輪の再発明をしていただけ」というオチだったのですが、それでもそこに至るまでの数学的&計算機科学的なアプローチは非常に興味深いものでした(どちらも僕はあまり明るくない分野ですが……)。

難しい話をわかりやすく説明するだけでなく、ときどきユーモアのある小ネタを交えて説明してくれたので、「緩急の付け方が絶妙だなあ」と感じました。

Lightning Talks

Day 1の最後の枠は、11人のLTでした。
どの話も興味深く、面白かったのですが、フィヨルドブートキャンプ(FBC)の卒業生であるima1zumiさんとharuna_tsujitaさんのLTがFBCのメンターとして、個人的にとても印象深かったです。2人ともすごく立派になったなあ!!😭



Day2:僕だけもう最終日……

冒頭にも書いたとおり、家の用事で昼過ぎに帰らないといけなかったので、僕だけ早々とDays 2が最終日になります(涙)。

キーノート:Twenty Years of JRuby

Day 2のキーノートは、JRubyの開発を20年以上続けているheadiusさんの発表でした。
JRubyのこれまでの歴史やheadiusさんのRubyに対する思い、これからのJRubyについてなどなど、Ruby愛とJRuby愛に満ちあふれたトークを繰り広げてくれました。
JRubyは名前はよく聞くものの、そこまで詳しくなかったので、「へ〜、そうなんだ、JRuby!」と思うようなポイントがたくさんありました。

ちなみに、あまりテクニカルな話題が出てこなかったせいもあると思いますが、「英語がすごく聞き取りやすくてわかりやすいな〜」というのが、トーク内容以外の面でも印象深かったです。

No Types Needed, Just Callable Method Check

「生成AIが十分なコードを書いてくれる現代に必要な仕組みは、型ではなくNoMethodErrorを防止するガードレールだけでいいのではないか」
「NoMethodErrorを防止するだけなら、わざわざ型を書かなくてもコードの静的解析によって判定できるのではないか」

という思想のもとに作られた、Method-Rayという「メソッドが呼び出し可能か判定するgem」を説明する発表でした。

正直なところ、上記の思想に僕が共感できるか?というと、ちょっと頷きにくいところがあるのですが、Rubyの型(というか、実行時エラーを防止する仕組み)はどうあるべきか?という考え方のひとつとしては、興味深いものがありました。
このあたりは現場で書かれているコードの規模や開発・運用プロセスなどによって「Rubyのあるべき姿」に対する考えが変わってくるような気もしますね。

Implementing Core Set

SetクラスはRuby 4.0から組み込みクラス(コアクラス)になりました。
組み込みクラスに昇格させるにあたって、jeremyevans0さんはHashを利用していた実装をCで再実装し、さらにメモリの使用量を減らすこともできました。

・・・というのが発表の概要なのですが、「スライドに出てくるコードはバリバリのC言語&かなり早口な英語」だったので、途中で付いていけなくなりました。(うひー)
なんとなく雰囲気だけ理解した、っていう感じですね。

僕が見た発表は以上です!

全体的な感想=やっぱり技術者個人が評価される世界っていいな

はてなブックマークなどを見ていると、最近上がってくるテック系の記事は「あれもAI、これもAI」で、正直食傷気味になっています。
「自分で手を動かさなくても、AIがここまでやってくれるようになりました!」みたいな話も、もちろん技術的な価値はあると思います。
ただ、それは「その人がすごい」のか、それとも「AIがすごい」のか、どっちかよくわかりません。

その点、RubyKaigiは基本的にどれも「私の成果」や「私の偉業」を発表するので、シンプルに「この人、すげー」と思えます。
個人的には「ヒーロー」や「ヒロイン」として技術者個人が評価される世界がいいなと思っているので、たとえ「難しすぎる、ついていけねー」と思ったとしても、僕にとっては心地のいい空間でした。

あれ、発表の感想が少ないのでは?→企業ブースを回ってました

ところで、RubyKaigiに参加された方は気付いたかもしれませんが、Day 1もDay 2もタイムテーブルにはもっとたくさん発表があったのに、僕が上で紹介した発表はそれよりも少ないです。

実は発表を見に行くだけでなく、企業ブースもたくさん回っていたので、一部の発表は見ることができませんでした。
もうちょっと詳しく言うと、

休憩時間に企業ブースを回る
 ↓
気付いたらもう登壇が始まっていた
 ↓
遅れて入るのも失礼なので、このまま企業ブースを回ることに

みたいな感じで行動していました。

RubyKaigiって企業ブースもめっちゃたくさんあるんですね。
あんなにたくさんあるとは思わなかったです。

企業ブースに行って、どんなビジネスをやっているのかを聞いたり、ミニゲームをしてノベルティをもらったりするのも楽しくて、ついいろんな企業ブースを転々としてしまいました。
発表は3トラック同時並行で進むし、企業ブースは大量にあるし、身体が1つではまったく足りませんでした!!


ノベルティ第1位は「ツボ押し棒」!?

いろんな企業でいろんなノベルティをいただいたのですが、RubyKaigi 2026の「このノベルティが良かった」第1位は、Linc'wellさんの「ツボ押し棒」でした!


Image: https://x.com/lincwell_dev/status/2046792552226177308

1位の理由は、妻が「これいいわ〜。最高!!」と喜んでいるからです。
(そして、ツボ押し棒で妻の足裏をマッサージしているのは僕です😅)

「技術記事を書く技術」の先行販売&サイン会もやっていました

RubyKaigiでは技術書が購入できる本屋さんコーナーがあります。
今回はここで新刊「技術記事を書く技術」の先行販売も行いました。

また、Day 1とDay 2の昼休みには著者サイン会も開催されました。

恐れ多くもRubyのパパMatzさんと、キーノートスピーカーのtagomorisさんと並んでサイン会を開催させてもらいました↓

Day 2ではイベントコーナーの壇上で「技術記事を書く技術」の紹介もさせてもらいました。
(まったく何も準備せずに突然呼ばれたので、グダグダな話になったかもしれませんが……)


Day 3専用の購入者特典としてメッセージカードを作った

Day 3は僕はサイン会に参加できなかったので、代わりにメッセージカードを作って本の購入者に渡してもらいました。

ちなみにこのメッセージカードはもともと用意していたわけではありません。
「Day 3だけ、本の購入者にサインできないのは申し訳ない」ということで、急きょDay 1に近くの文房具店で厚紙とペンを買ってきて、夜にホテルで書き書きして作ったものです。

なんと、100冊全部完売しました!

編集の大嶋さんからは事前に「RubyKaigiには『技術記事を書く技術』を100冊持ち込みます!」と言われていました。
それを聞いたとき、僕は「ひゃっ、100冊!?いや、Rubyの本でもないのに、RubyKaigiで100冊はちょっと無謀なのでは!?」と思いました。

大量に売れ残る新刊、閑散としたサイン会コーナー……そんな地獄のような光景を目にすることになるのではないか、と僕は本気で心配していました。いや、本当に!!

が、予想に反して、たくさんの人が「技術記事を書く技術」を購入してくれました!
サイン会もおかげさまで大盛況でした。

Day 2が終わった時点で、すでに80冊以上が売れ、残り約20冊、という状況でした。

Day 3は僕は現地にいないので、販売員を兼務している大嶋さんから状況を聞くしかなかったのですが、昼休み中に無事に全100冊が完売したらしいです。すごい!!

メッセージカードが少し余っていたので、それはチェリー本を買ってくれた人と、「技術記事を書く技術」を買ったけどサインはもらっていない人にプレゼントすることにしました。
最終的にはメッセージカードも全部配布済みになったらしいです。

よかった、どちらも余らなくて本当によかった!! 😭

そして、現地で「技術記事を書く技術」と「プロを目指す人のためのRuby入門」を購入してくださったみなさん、ほんと〜〜にどうもありがとうございました!!

「はじめまして」の人から「お久しぶりです」の人まで、いろんな人に会えた

Day 0の前夜祭、Day 1のオフィシャルパーティー、企業ブース、著者サイン会など、RubyKaigiではいろんな場所でいろんな人に会うことができました。

初めてお会いする人からは、

「チェリー本を読んでRubyを勉強していました!」
「伊藤さんに初めて会えて嬉しいです!」
「QiitaのRSpecの記事は何度も読みました!」
「伊藤さんのブログは昔からチェックしてます!」

といった、とても嬉しいお声がけをたくさんいただきました。
本当にありがたいことです!

Qiita記事やブログは普段からよく書いていますが、ネット上の活動なので、読者のみなさんの顔を拝見する機会はないんでよね。
(1人1人の人間というより、PVとか「いいね」の件数とか、そういった数値になってしまいがち)
また、読者のみなさんからしても、「伊藤さんはネット上でしか見かけない人」だと思います。
RubyKaigiは「記事を書いている人」と「記事を読んでいる人」がリアルに対面できる貴重な機会になりました。

いやあ、これだけでも行った甲斐があったと思います!
そして、現地でお会いしたみなさん、今後ともよろしくお願いしますね😘 


まとめ:「ありがとう」で埋め尽くされた、初めてのRubyKaigi

というわけで、今回のエントリでは、初めて参加したRubyKaigiの参加レポートを書いてみました。

RubyKaigiでは何度も「ありがとう」と思いましたし、実際に何度も「ありがとう」という言葉を口にしました。

  • Rubyを作ってくれたMatzさん、どうもありがとう!
  • テクニカルで興味深い話をたくさん聞かせてくれた登壇者のみなさん、どうもありがとう!
  • すばらしいカンファレンスを開いてくれた、運営やスタッフのみなさんありがとう!
  • イベントの運営費や美味しい食事を提供してくれたスポンサーのみなさん、どうもありがとう!
  • 本屋さんを開いてくれたささださん、本の販売員を兼務してくれた編集の大嶋さん、どうもありがとう!
  • 「技術記事を書く技術」やチェリー本を買ってくれたみなさん、どうもありがとう!
  • 「伊藤さんに会えて嬉しいです」と声をかけてくれたみなさん、どうもありがとう!
  • 久しぶりに会っておしゃべりしてくれた旧知のRubyistのみなさん、どうもありがとう!
  • 決して安くない参加費用を負担してくれた弊社ソニックガーデン、どうもありがとう!

これで全部かな?もし感謝を伝え損ねている人がいたらごめんなさい。

そう、こんな感じで会場をあとにするときに「この3日間で、数え切れないぐらい、『ありがとう』って言ったなあ」と思いました。
僕の初めてのRubyKaigiをひとことでまとめるなら「ありがとう」なのかもしれません。

2027年は宮崎のようですね。
今のところ来年も行こうと思っているので、来年もみなさんよろしくお願いします!

おまけ

このブログのどこかに「技術記事を書く技術」の小ネタが紛れ込んでいます。
ヒントはこの手書きポップに書いてあります。
「技術記事を書く技術」を持ってる人は探してみてね!