【書評】「技術記事を書く技術」は一貫して読者ファーストな技術だった

はじめに

2026年のゴールデンウィークは、「技術記事を書く技術」を読了しました。
この本を読もうと思ったのは、著者の伊藤 淳一さん（以下、伊藤さん）が、技術記事やブログを量産されているコツみたいなものを知りたかったからです。

他にも、Xで読了を宣言していて時間的な期限を設けていたこともあります😅

読了後はアウトプットもできればいいなと考えていましたので、まずは今回の書評でアウトプットすることにしました。
（仮に誰にも読まれなくても、伊藤さんは読んでくださるだろうという安心感もありました😁）。

ちなみに、本題からは外れますが、伊藤さんはプログラミングスクール「フィヨルドブートキャンプ」のメンターをされており、私がそのスクール出身でお世話になったご縁からも、感謝の意を込めて今回の記事を書かせていただきました。

書籍の概要

著者の伊藤さんは、QiitaのContribution数ランキング総合1位（2026年3月時点）、Qiita表彰プログラムDIAMOND受賞者であり、プログラミング言語「Ruby」入門書の決定版的な存在である 通称：チェリー本 の作者としても有名な方です。

その伊藤さんが、4年かけて2026年4月27日に出版された待望の一冊がこちらです。
技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて
Amazon「ブロギング・ブログ」カテゴリ で ベストセラー1位 を記録されています（2026年5月6日時点）。

書籍の概要は、伊藤さんのブログにまとまっていましたので、引用させていただきます🙏
blog.jnito.com

4年もかかった理由は、別のブログで説明されています。
あの伊藤さんが執筆の進捗報告で苦しまれているとは意外でした😭
blog.jnito.com

書籍の感想

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

2章構成になっており、記事を1本書くまでの動機付けや書き方について、伊藤さんと伴走しながら手取り足取りといった感じで読み進めることができました。記事を書いたことがない方には特におすすめです。

一番印象に残ったのは動機付けの部分で、以下の引用部分が個人的には刺さりました。

ネット上に転がっている無数の技術記事は、自然発生的に湧き出てきたわけではありません。生成AIが文章を生み出せるようになった現在でも、その土台には誰かが残してきた知識や経験のアウトプットがあります。そうした積み重ねがあるからこそ、現在の私たちは助けられているのです。

あらためて、自分もアウトプットを通して、ギブする側に回るべきだと感じました。

第2部 質を高める

第2部は11章構成で各章に書く前、書くとき、書いたあと、その他というサブカテゴリが振ってあります。個人的にはこれらサブカテゴリを親に持って来てもいいのかなとも思いました。

読み手に負担を掛けないようにするためのテクニックが満載です。
中でも特筆して参考になったのは、以下の章です。

  • 第3章 ネタを見つける技術
    • 技術記事のネタにも17パターンあることに驚き
    • パターンごとのテンプレート（これはめちゃくちゃ助かります‼︎）
    • 自分が記事を書く上での指針が決められそう
  • 第4章 事前準備の技術
    • 正しい情報を技術的根拠をもって捉える習慣を
    • 結果的に自分に確かなスキルとして返ってくるという納得感
    • 正確な情報を相手に伝えるコミュニケーションスキルの観点でも大事
  • 第5章 見出し・タイトルの技術
    • 見出しの有無で脳の認知負荷が下がることを実感
    • 豊富な例示による納得感
  • 第6章 構成・見せ方の技術
    • タイトル・はじめに・まとめの三人四脚だと記事の構成に迷うことがなさそう
    • 第3章の17パターンごとのテンプレートについてもこの構成となっていました
    • 本文から書いて最後に記事全体の構成をまとめるという方法も普通にアリ
    • TL;DR の意味が分かりました
  • 第7章 正しい情報を正しく伝える技術
    • やはり一次情報を参照することは大事
    • 時間が経った時のことも考えて、前提条件を入れることの大切さを再認
  • 第12章 アウトプットを習慣化する技術
    • 一番気になっていた章、当然ながら銀の弾丸はない😇
    • 記事を書いていれば将来の自分も助かるという納得感
    • アウトプットのノルマ化、日常での優先順位、楽しみながらが印象的

第2部を通して随所で感じたのは、未来の自分も含めた読者に対する思いやりでした。

第3部 実例添削で学ぶテクニック

これまでのおさらいといった感じで実例での添削が行われています。
そういえばこんなツッコミどころがあったなとかを思い出しながら読むことができました。自分が技術記事を書くときに読み返して参考にしたいと思います。

[付録A] 生成AI時代に、人間が記事を書く理由を考えてみた

生成AIが書いた文章は、たしかに出来過ぎというか人間の感情があまり感じられない点で読んでいてつまらなく感じるのは同感です（とはいえ、私もあまり感情を表に出すタイプではないのですが・・・）。

自身が経験したこと、感じたことをアウトプットすることで、読み手との共感やご縁が生まれていくことを考えると、やはり、自分の頭で考えて手を動かすのがいいのかなぁと感じたところでした。

あくまで人間が主体で、生成AIは補助的な活用にとどめたいと思いました。

まとめ

この記事では「技術記事を書く技術」の書評を書かせていただきました。

タイトルにもありますように、読んでみて感じたのは一貫して読者ファーストな技術（読者を思いやる方法）を紹介するものでした。また、楽しみながら書くためのコツも分かってきた気がします。

記事冒頭で触れた記事を量産するコツというのは、とにかく数を経験して自分の頭で考えて手を動かすことに尽きるのだなと感じました。

伊藤さんの伝えたかったことのほんの少しかもしれませんが、未来の自分も含めて読者を思いやる気持ちも伝わりました。技術記事やブログがいまいち楽しく書けていないなと思っている方にも、この本をおすすめしたいです。

伊藤さん、関係者の皆様、このたびは大変参考になる情報をありがとうございました。

Ruby × Rails × Wasm で動く正規表現エディタ Rubree をリリースしました

はじめまして、シモカワと申します。
この度、長く Rubyist に親しまれてきた Rubular の使い心地を受け継ぎつつ、現代的にアップデートした正規表現エディタ Rubree をリリースしました。

Rubree画面

Ruby の正規表現エディタのカリスマ的存在である Rubular には、現代の Ruby 環境での利便性や拡張性の面でいくつか課題がありました。

  • 古い Ruby バージョン上で動作している（執筆時点で Ruby 2.5.9）ため、処理速度や安全性の面で最新 Ruby の恩恵を受けられない
  • OSS としてソースが公開されておらず、拡張や検証が難しい
  • サーバー依存のため、文字列を入力するたびにバックエンドで評価が必要
  • Regexper のような鉄道図による正規表現の視覚化ができない
  • 正規表現による文字列置換の確認ができない

こうした課題を受け、Rubree は Ruby × Rails × Wasm を用いて、機能も UI も現代的に再構築しました。結果として、フルスタックな Rails アプリの利便性をブラウザ上で体験できる正規表現エディタが誕生しました。

🔍 Rubree でできること

Rubular の基本操作に加え、Rubree では次の機能拡張を行いました。

  • リアルタイムでのマッチ結果表示
    Rubular 同様にマッチ位置やキャプチャ / 名前付きキャプチャを確認できますが、Rubree では即座に更新され、反応がより軽快です。

  • 構造可視化
    鉄道図形式の SVG により、正規表現の構造を直感的に理解できます。

  • 置換結果の確認
    置換結果もブラウザ上で即座に確認可能です。

  • Ruby コードスニペット生成
    入力した正規表現からそのまま Ruby コードを生成できます。

  • ブラウザ内完結・サーバー不要
    評価処理がすべてブラウザ内で行われるため、サーバーに依存せず軽快に操作できます。ページ遷移なしの SPA 操作でストレスなく利用可能です。

  • 利用者にやさしい機能
    英語 / 日本語切替や多数の例文を収録。従来の Rubular の日時 example に加え、おみくじ的に例文を切り替えて表示することも可能。

  • 開発者視点の利便性
    GitHub 上で OSS として公開、CI/CD によるテスト・デプロイ自動化も整備されており、フォークやカスタマイズも容易。

Rubree は、Ruby の正規表現を学習・テスト・可視化・置換・コード生成まで、ブラウザだけで一度に扱えるワンストップ型ツールです。

🔧 使い方

初回起動

  1. Rubree にアクセス
  2. 「Get started」をクリック
  3. アプリが起動するまで 10秒ほど お待ちください
    （Wasm モジュールをブラウザにロードするため）

2回目以降の利用

  • ブラウザ側のキャッシュ状況により、まれに数秒ほど読み込みが入る場合があります。Wasm の特性というよりブラウザの挙動によるものですので、ご理解いただければ幸いです。

基本の流れ

  1. 正規表現を入力
  2. テキストを入力
  3. マッチ結果・構造図を確認

例文を試す

  • ロゴ直下の 「Try this example」 をクリックすると、サンプルの正規表現とテキストが自動入力されます。
  • その横にある サイコロアイコン をクリックすると、おみくじのように例文がランダムで表示されます。
  • 画面右上の 「Regex Examples」 からは、多数の例文一覧を開き、任意の例を選んで表示できます。

正規表現の構造図を拡大・共有する

  • Railroad diagram エリアの 虫眼鏡アイコン をクリックすると、構造図が拡大表示されます。
  • その横の クリップアイコン をクリックすると、構造図を画像としてクリップボードにコピーし、そのまま共有できます。

正規表現の確認結果をURLで共有する

  • 画面右上の 共有アイコン をクリックすると、Rubular と同様にパーマリンクが生成されます。Rubree の場合は、Base64 形式のデータが URL のクエリとして生成され、クリップボードに自動でコピーされます。
  • 生成された URL をチャットやブログなどで共有すれば、相手側でも同じ状態が再現されます。

今後、さらに詳しいチュートリアルや使い方の記事も順次公開していく予定です。

🧱 技術スタック

Rubree は Ruby 3.3 + Rails 8.0 を Wasm 上で安定動作させる構成からスタートしました。 その後、Wasm ビルド特有のいくつかの技術的課題を乗り越え、2026年4月5日より Ruby 4.0 + Rails 8.1 に対応しました。

⚙️ Backend

  • Ruby 4.0
  • Rails 8.1
  • Regexp::Parser

🎨 Frontend

  • Hotwire
  • TailwindCSS
  • RailroadDiagrams

🛠️ Development

  • Foreman
  • Lefthook

🧹 Lint / Testing

  • Rubocop / ERB Lint / Biome
  • RSpec
  • Playwright
  • Octocov

🚀 Build / Deployment

  • Wasmify Rails
  • GitHub Pages

🤖 Shift-left Security

  • Dependabot
  • Gitleaks
  • Brakeman

▶️ CI/CD

  • GitHub Actions

🧩 開発のきっかけと裏話

開発は、プログラミングスクール「フィヨルドブートキャンプ」の 卒業課題 として 2022 年 1 月にスタートしました。
きっかけは、スクール内のDiscordチャンネル「欲しいサービス・npm・gem」の中で、メンター の 伊藤さん が作って欲しいサービスとして挙げられたことでした。

（案）オープンソースのRubularクローンを誰か作ってほしい
（理由）Rubularはオープンソースじゃないので、作者がメンテナンスをやめたらサイトが止まりそう。チェリー本の正規表現の章がRubularに依存しているので、サイトが止まるとちょっと困るんですよね。

チェリー本で Ruby を学習するうちに正規表現が好きになり、ちょうど卒業課題を考えていた時期でもあったため、少しでもRubyの正規表現の分野で貢献できるものになればという想いで開発することを決めました。
単なるクローンだとあまり存在価値を感じられませんので、現代の Ruby で動作させつつ、利便性を向上させることを目標としました。

いざ開発に着手する段階で、Rubular をクローンしつつ便利機能を並行開発するには相応の時間が必要でした。また、前職を退職して学習に注力していて経済的にも再就職を考える時期に差し掛かっていたため、一旦生活を立て直すべく、開発よりも就職活動に力を入れることにしました。幸いにも、希望通り Web エンジニアとして就職することができました。

3 年後の RubyKaigi が開発再開のきっかけに

その後、会社から RubyKaigi 2025 に参加する機会をいただき、フィヨルドブートキャンプの仲間や Ruby コミュニティの方々と直接交流する中で、開発再開のきっかけを得ました。

Rubree に搭載予定だった正規表現を鉄道図で可視化する機能は、JS の世界では Regexper が有名ですが、Ruby には対応するライブラリが見当たりませんでした。

そんな中、Ruby コミッターであり、パーサージェネレーター Lrama のコミッターでもある ydah さん が RubyKaigi の LT 登壇で「parse.y を読むのが難しいという課題に鉄道図で全体の見通しをよくすることで解決を図った、しかしながら既存ライブラリは Ruby に対応していない」ということを語られ、大いに共感しました。

さらに、ydah さんが「なければ作ればいいや」という発想で開発された railroad_diagrams gem の存在を知り、これなら正規表現の可視化にも使えると直感しました。会場からの帰路では直接お話しする機会にも恵まれ、アドバイスをいただけたことが開発再開の大きな後押しとなりました。

その後、regexp_parser gem で正規表現の構造を解析し、railroad_diagrams gem で SVG 化する試行錯誤を重ね、フィヨルドブートキャンプでのレビューやブラッシュアップを経て、今回のリリースに至りました。

❤️ 感謝

  • フィヨルドブートキャンプの皆さま
  • 開発のきっかけをくださったメンターの伊藤さん
  • 開発再開・前進のきっかけをくださったRubyコミッターの ydah さん
  • 家族や会社の仲間
  • Rubular という素晴らしいツールを開発してくださった Michael Lovitt さん
  • Ruby や Rails をはじめ、ライブラリ等の OSS 開発者の皆さま
  • GitHub リポジトリや Actions、Pages 等を無償で提供してくださる GitHub 様

皆さんのおかげで、Rubree は形になりました。本当にありがとうございます。

🚀 最後に

Rubree は
Rubyist だけでなく、従来から Rubular を使ってきた方や、これから正規表現を学ぶ方にも便利に使っていただけるワンストップ型ツール
です。

コードの確認、ちょっとしたテスト、学習など、様々な場面で活用していただければ嬉しいです。
ご質問や機能追加のリクエストなどは、GitHub Issues にお気軽にお寄せください。

また、同じスクール生の sugiwe さんも最近、自作サービス『CAMPUS』をリリースされています。
組織やコミュニティでクローズドに使えるイベント管理アプリを探している方は、こちらのリリースブログもぜひチェックしてみてください。