give IT a try

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

「ありがとう」で埋め尽くされた、初めての #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年は宮崎のようですね。
今のところ来年も行こうと思っているので、来年もみなさんよろしくお願いします!

おまけ

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

【制作裏話】「技術記事を書く技術」を書くのに、4年もかかった理由を説明したい

ついに「技術記事を書く技術」が物理的な「本」として完成しました!

これまであまり公にしていなかったこともあり、この本をいつから書き始めたのかを知っている人はほとんどいないと思いますが、編集の大嶋さんから執筆の誘いを受けたのは2021年11月のことでした。

そして今は2026年4月です。ざっと数えて4年半!
そう、「技術記事を書く技術」ができあがるまで4年以上かかったんです!!

赤ちゃんを出産したときに、お母さんが「やっと会えたね」と声をかけるシーンがありますが、完成した本を受け取ったときの僕の気持ちはまさにそんな感じでした……!!

発売10日前ということもあり、本来なら書籍の魅力を伝えるエントリを書くのがマーケティング的には望ましいんでしょうが、今は「あ〜〜〜、やっとできたーーー!!」という喜びの方が大きいので、今回は「なぜ完成まで4年もかかったのか」について語らせてください。

最初は「すぐに書けるだろう」と高をくくっていた

「エンジニアのアウトプットをテーマにした書籍を作りたい」というお話をもらったときは、1年ぐらいで書けるんじゃないかと高をくくっていました。

それはなぜかというと、

  • 「プロを目指す人のためのRuby入門」を書いたときは、最初からかなりハイペースで書けたので、今回も同じようにいくはずだと考えていた
  • アウトプットのノウハウについては、このブログでも過去に何本か書いているので、ある程度元ネタもあった
  • 「エンジニアのアウトプットを語らせたら、日本で5本の指に入るだろう」という自負もあるので、その気になればいくらでも原稿は書けると思っていた

からです。

が、現実はまったく違いました!

「技術記事を書く技術」を書くのに4年もかかった理由

4年もかかった理由はいくつかあります。
以下でその理由を述べていきます。

仕事が忙しかった

「プロを目指す人のためのRuby入門」を書いていた頃に比べると、会社の仕事量がちょっと増えていて、原稿を書く空き時間が少なくなっていました。
また、並行してフィヨルドブートキャンプでメンターをやっていたのも、空き時間が減る理由のひとつになっていました。

プライベートも忙しかった

「プロを目指す人のためのRuby入門」を書いていた頃は、子どもたちはどちらも小学生でした。
一方、今回の執筆では子どもたちが中高生になっていました。
なんとなく、子どもが大きくなればなるほど手がかからなくなるイメージがありますが、現実は逆でした。

僕は田舎に住んでいるので、どこかに移動するのには車が必須です。
子どもたちが大きくなると、大人と同じぐらい行動範囲が広がります。
しかし、中高生はまだ車を運転できません。
となると、代わりに親が車で送迎しないといけなくなります。
これが意外と時間を食うんですよねえ。

送迎以外でも「やれることは大人とほとんど違わないが、子どもにはまだできないこと」を親がサポートしないといけない場面がよくあって、思った以上に中高生の子育て(というか、子どもたちのサポート)は忙しかったです。

体力が落ちた

あまり年齢の話はしたくないですが、45歳を過ぎたあたりから「むむ、体力が落ちてきたような?」と感じる場面が増えてきました。

「プロを目指す人のためのRuby入門」を書いていた頃は30代後半で、早朝から原稿を書いたり、土日をまるまる使って原稿を書いたりするのはそれほど苦にになりませんでした。
しかし、ここ数年は同じようなノリで仕事をしようとしても、平日の仕事の疲れが土日に残っていたり、無理をすると頭が痛くなったりして、なかなか原稿の執筆に集中できなくなりました。

情けない話ですが、加齢による体力の低下が執筆がなかなか進まなかった理由のひとつであるのは間違いありません。

Rubyの解説書と違って、アウトプットには正解がない

「プロを目指す人のためのRuby入門」はRubyの解説書です。
当然ですが、プログラミング言語は仕様が決まっています。
ですので、プログラミング言語の解説書を書くときは極端な話、

  • どの仕様を説明の対象にするのかを決める
  • その仕様をわかりやすく説明する

という作業を繰り返せば、本が完成します。
つまり、本を書くときの正解やゴールがある程度決まっています。

一方、エンジニアのアウトプットにはプログラミング言語のような仕様や正解がありません。

「自分はアウトプットに関する知見や経験が豊富だからスラスラ書けるはず」と思っていましたが、どんな話をどんなふうに着地させるのかを自分自身で定義しなければならない、という状況が思った以上にハードで、執筆に手間取る原因になりました。

「よっしゃ書くぞ!」という熱量が上がりづらい

個人ブログであれ、Qiitaであれ、僕がアウトプットするときは、「今、これを書きたい!!」というきっかけが必ずあります。
たとえば、このブログを書いている今がまさにそうです。
このブログを書こうと思ったきっかけは、「本ができた!とても感慨深いので、大変だったここまでの道のりをまとめておきたい!!」と考えたからです。

しかし、本の原稿を書くとき(原稿を書こうとするその瞬間)は「今、この話を書きたい!!」という動機がありません。
「自分はアウトプットに関する知見や経験が豊富だからスラスラ書けるはず」と思っていましたが、書こうとするテーマやネタがなんとなくあったとしても、「今、書きたい!」という着火剤がないと、なかなか筆が乗らないことに気付きました。

雑誌やWebメディアへの寄稿なら、ページ数や文字数が事前に決まっているので、熱量が低くてもまだ乗り切れます。
しかし、本は「ここまでやれば終わり」というゴールが遠すぎて、なかなか視界に入ってこない。
短距離走なら「あそこまで走ればゴールだから頑張ろう」と思えますが、ゴールが全く見えない長距離走は「あそこまで頑張ろう」という気持ちもわかないので、走ること自体に嫌気が差してくる。

そんな感じで、「今書きたいわけではないのに、終わりの見えないゴールに向かって何か書かなければいけない状態」にとても苦しめられました。

間が長期間空くと、なかなかエンジンがかからない

上に挙げたような複数の理由から、原稿の執筆は遅々として進みませんでした。
すると、何が起きるかというと、原稿を書く間隔が数週間おきになったりします。

こうなると、パソコンに向かったときに「あれ、前回は何を書こうとしてたんだっけ??」と、数週間前の記憶を呼び戻すところから始めないといけません。

さらに、前回の原稿執筆ではエンジンが暖まっていい感じに筆が乗ってきていたとしても、間が空くことで、そのエンジンが完全に冷めてしまう、という問題も起きます。
「今日は昨日の続きから」と「今日は2週間前の続きから」では、再始動のしやすさが全く変わってきます。

というわけで、執筆を開始して以来「なかなか書けない→間が空く→さらに書けなくなる」という悪循環を繰り返しておりました……。

本気で「もうやめよう」と何度も思った

原稿の進捗が悪いのは十分自覚していたので、編集の大嶋さんに進捗報告するのが苦痛で仕方ありませんでした。

「えっと・・・今月は○○と○○みたいなことがありまして・・・なかなか原稿を書く時間が取れず・・・前回の打ち合わせ以降で書いたのはこれとこれだけです」

みたいな話を何度したことか!

1年ぐらいならともかく、2年、3年も経つとさすがに僕も焦ってきます。
こんな状況だと出版社の人もあきれてるだろうし、向こうから「この話はなかったことにしましょう」と言われてもまったくおかしくないだろうな、という気持ちになりました。

ぶっちゃけ、「もうダメだ。完成しそうにないからギブアップしよう」と何度も思いました。

頻発する「すいません、進捗なしです」メッセージ💧

編集の大嶋さん「大丈夫です。待ちます!」

実際、大嶋さんには「さすがに時間かかりすぎてますよね?出版の話がキャンセルになっても、僕は当然だと思ってますが……」という話を何度かしました。

ですが、そのたびに大嶋さんは、弱気になった僕を優しく励ました上で

「大丈夫です。待ちます!」

と力強く言ってくれました。(毎回ちょっと苦笑いしてたような気もしますが😅)

大嶋さんの寛大なサポートがなければ、きっと「技術記事を書く技術」は日の目を見ることはなかったんじゃないかと思います・・・!!

最後の最後は気合い?去年の秋から締切駆動で作りきった!!

そんなこんなで、何年もかけて亀のようなスピードで原稿を書いていたのですが、去年の夏ぐらいにようやく全ての章について、ざっくり原稿を書くことができました(ソフトウェアでいうところのアルファ版が完成、ぐらいのイメージです)。

アルファ版ができたのを機に再度スケジュールを検討し、発売日を「来年の4月(2026年4月)」に設定することにしました。
そして、そこから逆算で大嶋さんに刊行までのスケジュール表を作ってもらいました。

僕も「これ以上スケジュールは遅らせない、なんとしても2026年4月に本を出す!」と腹をくくり、去年の秋以降は基本的に空いている時間はすべて原稿執筆に費やしました。
スケジュール表の締切を守ることを最優先し、年末年始も大阪の実家には帰らず、自宅で缶詰になって原稿を仕上げていきました。

というわけで、去年の秋から今年の3月ぐらいまでは超々ハードモードでした。
ですが、そのおかげでなんとか予定通りに「技術記事を書く技術」を刊行することができました!!

大変だったけど、いい本ができた!

ここまでずっと苦労話ばっかり書いたので、できあがった本にも僕の産みの苦しみが染みこんでるんじゃないかと思われるかもしれませんが、その心配は無用です!
自分で言うのも何ですが、とても興味深くて面白い本ができたと思います。

先ほどは「Rubyの解説と違って、アウトプットには正解がない」という話を書きましたが、これは裏を返すと、「伊藤淳一という著者の個性がふんだんに詰め込まれた本である」とも言えます。
特に、第11章から第13章にかけては、僕のこれまでの経験をベースにした内容になっているので、きっと他の誰も書けない内容になっているはずです。(当然、ChatGPTに質問しても同じ内容は出てきません!)


ページ数を削ってさらに濃厚になった

また、あれだけ「原稿が書けない、書けない!」と悩んでいたくせに、昨年秋以降の仕上げ作業では書き足したい内容がたくさん出てきて、当初予定していたページ数を大幅にオーバーしてしまいました。

「さすがにこれを全部書籍に収めるのは難しい」という話になり、いくつかのセクションは泣く泣くカットすることになりました。
また、もともと巻末付録として掲載する予定だった「付録B 記事パターン別の構成テンプレート」と「付録C Markdownを使いこなす技術」は、書籍内の付録ではなく、翔泳社の公式サイトからPDFをダウンロードするタイプの付録になりました。

最終的には400ページを超える内容だったものを50ページ以上カットして、352ページまで圧縮しました。
ページ数は減りましたが、そのぶん内容が濃縮されて、どのページを開いても面白い「濃厚な味わいの一冊」に仕上がったんじゃないかと思います。


まとめ

というわけで、今回のエントリでは新刊「技術記事を書く技術」を書くのに、なぜ4年以上の月日がかかったのか、というお話を書いてみました。

いや、本を読む人にとっては、その本に書かれている内容がすべてであって、半年でさくっと書き上げようが、10年かかろうが、執筆にかかった時間は大した問題ではないことはわかっています。

ですが、「めっちゃ大変だった!何度もモームリって思ったけど、完成して良かった!!」という喜びが大きすぎて、どうしても書かずにはいられませんでした。

アウトプットに興味を持っているITエンジニアのみなさんはもちろん、単純に読み物として楽しめる側面もあると思うので、「4年越しで完成した、伊藤さん入魂の一冊」をぜひ手に取っていただきたいです。

みなさん、「技術記事を書く技術」をよろしくお願いします!!

【締め切りました】書評を書いてくれる方に、新刊「技術記事を書く技術」をプレゼントします!

2026.4.11追記

抽選結果を応募されたみなさんにメールで送信しました。
たくさんのご応募、どうもありがとうございました!

はじめに

先日もお伝えしたとおり、僕の新刊「技術記事を書く技術」が2026年4月27日に発売されます。

blog.jnito.com

出版社の翔泳社さんのご厚意により、見本誌を3冊用意してもらったので、このブログを読んでくれているみなさんにプレゼントします。

「気になる!ぜひ読んでみたい!」という方は、以下の要件と応募方法をご確認の上、ふるってご応募ください!

応募要件

  • 本書の書評を必ず書いてくれる方
    • 書評はブログやnote、Qiita、Zennなどに投稿してください
  • 本の到着後、1~2ヶ月以内に書評を書いてもらえると嬉しいです
  • アウトプット経験の有無やエンジニア歴に関係なく、どなたでも応募可能です

応募方法

本企画に応募される方は下記の入力フォームを使って必要事項を送信してください。

docs.google.com

  • 申込み締切 = 2026/4/9(木) 23:59まで
  • いただいた個人情報は商品発送の目的以外に使用しません。

当選発表について

  • 応募いただいた方の中から3名を選び、当選者とさせてもらいます。
  • 当選された方には4/13(月)までに、僕からメールにてご連絡させてもらいます。
  • 落選された方の個人情報はこちらで責任をもって削除します。

まとめ

普段はRuby関連のアウトプットが多い僕ですが、「技術記事を書く技術」はプログラミング言語を問わず、ITエンジニア全員に役立つ内容になっています。

アウトプットに興味はあるけど、なかなか記事が書けない、どうすればいい記事が書けるのかわからない、といった悩みがあるエンジニアのみなさんはぜひ本書を読んで、ご自身のアウトプットに役立ててほしいです。

書評を書くのもアウトプットのひとつなので、このプレゼント企画を利用して「絶対、書評を書くぞ!💪」という目標を立てるのもいいと思います。

それでは、たくさんのご応募をお待ちしています〜!

「技術記事を書く技術」について

僕、伊藤淳一のアウトプットに関する15年間の知見と経験と私見をぎゅうぎゅうに詰め込んだ一冊です。
技術記事について知りたいこと、気になっていることは全部本書に載っているはず!

現在Amazon等で予約受付中ですので、気になる方はぜひチェックしてみてください👇