give IT a try

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

「世界で闘う エンジニア・アウトプット力を鍛える本」を監訳しました(2026年9月17日発売)

はじめに

タイトルにあるとおり、「世界で闘う エンジニア・アウトプット力を鍛える本」という本を監訳しました。
本書は2026年9月17日に発売されます。

原著は2025年に刊行された「Writing for Developers」です。

このエントリでは「世界で闘う エンジニア・アウトプット力を鍛える本」はどんな本なのか、そして僕が監訳者としてどう関わったのかについて書いていきます。

【もくじ】

「世界で闘う エンジニア・アウトプット力を鍛える本」はどんな本か?

ひとことで言うなら、本書はITエンジニア向けに、技術ブログの書き方を指南する本です。

ここで、本書の目次を見てみましょう。

Part 1 基礎

  • 第1章 なぜ書くのか
  • 第2章 何を書くか
  • 第3章 読者を魅了する

Part 2 書くプロセスを極める

  • 第4章 作業用ドラフトの作成
  • 第5章 原稿を最適化する
  • 第6章 フィードバックをもらう
  • 第7章 公開しよう

Part 3 ブログ記事パターンの適用

  • 第8章 「バグハント」パターン
  • 第9章 「〇〇で書き直してみた」パターン
  • 第10章 「どのように作ったか」パターン
  • 第11章 「得られた教訓」パターン
  • 第12章 「トレンドに関する考察」パターン
  • 第13章 「マーケティング色のないプロダクトの視点」パターン
  • 第14章 「ベンチマークとテスト結果」パターン

Part 4 プロモーション、応用、展開

  • 第15章 注目を集める
  • 第16章 ブログ記事からカンファレンス講演へ
  • 第17章 本を書きたいあなたへ

付録

  • 付録A 公開と執筆のためのリソース
  • 付録B AIの使い方と濫用の実際
各Partの概要

「Part 1 基礎」では、なぜ書くのか、どんなことを書くのか、といった、アウトプットの基礎知識を解説します。

「Part 2 書くプロセスを極める」では、企画から執筆、公開に至るまで、技術ブログを書くためのプロセスや考え方を解説します。

「Part 3 ブログ記事パターンの適用」では、実際のブログ記事を分析し、パターンごとに共通する特徴や注意点などを解説します。

「Part 4 プロモーション、応用、展開」では、自分の書いた記事をたくさんの人に読んでもらうためにはどうすればいいか、そして、カンファレンス講演や本の執筆につなげるためにはどうすればいいかを解説します。

このように、「世界で闘う エンジニア・アウトプット力を鍛える本」(以下、世界で闘う本)は、どのように技術ブログを書き、それをどのように発展・応用させていくのかを、それぞれのPartでかなり深く掘り下げて解説しています。

「技術記事を書く技術」とは何が違うのか?

ところで、もしかするとみなさんの中には「なんか同じようなテーマの本が最近出てた気がするぞ?」と思われた方もいるかもしれません。

そうです。「技術記事を書く技術」という本がこの4月に発売されましたね。
そして、その本を書いたのは何を隠そう、この僕=伊藤淳一です!

「世界で闘う本」と「技術記事を書く技術」は、テーマ的にかなり被っているのは事実です。
ですが、想定している読者が若干異なります。

拙著「技術記事を書く技術」は、エンジニアとしての経験年数が浅く、「技術ブログをまったく(or ほとんど)書いたことがない、まずは初めの一歩を踏み出したい」という方に向いています。

一方、「世界で闘う本」は、技術者としてある程度の経験があり、「私の(もしくは弊社の)高い技術力を世界に向けてアピールしたい」と考えている方におすすめです。

また、ブログ記事のみならず、技術系のカンファレンスで発表をしたいという人にも「世界で闘う本」は打ってつけです。
実際、本書の第16章には「ブログ記事からカンファレンス講演へ」という章も用意されています。

ブログであれ、登壇であれ、「私の成し遂げた技術的な偉業を、自分の言葉で人に伝えたい」と考えている人は、ぜひ本書を読んでみてください。

「世界で闘う本」は560ページの大ボリューム!

「世界で闘う本」のページ数は560ページです。
「技術記事を書く技術」のページ数は352ページなので、約1.6倍のページ数があります。

「技術記事を書く技術」もそこそこのボリュームがありますが、「世界で闘う本」はさらにその上をいきます。
そのぶん、「世界で闘う本」は中身の濃い一冊になっています。

両方読めば完璧!?

なお、ここまであえて「技術記事を書く技術」と「世界で闘う本」の違いを強調しましたが、熟練者が「技術記事を書く技術」を読んでもアウトプット力の向上に役立ちますし、「世界で闘う本」にも「初めの一歩」を踏み出すための執筆ガイドは載っています。

ですので、実務経験やアウトプット経験の多少にかかわらず、どちらの本もそれぞれ違った形でアウトプット力の向上に役立つはずです。
目次を眺めたりして、興味を持った方から手に取ってみてください。

また、2冊の本で同じことを説明している内容もあれば、片方の本では説明していない内容もあります。
なので、アウトプットに関する知見をくまなく得たいなら、2冊とも買って読んでみるのが理想的です!

ところで、なんで監訳者になったの?

さて、ここからは「監訳」のお仕事について、ちょっと語らせてください。

監訳については、7月の上旬に「監訳をしてもらえませんか?」と、編集者の西田さんからDMが届きました。

実は原著の「Writing for Developers」は、個人的な興味からすでに読んでいて、過去に書評ブログも書いていました。
blog.jnito.com

西田さんいわく、「伊藤さんはテーマ的に近い「技術記事を書く技術」の著者だし、Writing for Developersの書評も書いているし」ということで、僕に監訳を依頼しようと思ったとのことです。

ただ、入稿までのスケジュールを聞いてみると、(制作上のさまざまな事情が重なってしまい)かなりタイトでした。

加えて、8月はデブサミ2026関西の登壇も控えており、スライドの準備作業なども含めると、「これはかなり厳しいのでは……」と思ったのですが、「俺がやらなきゃ誰がやるんだ?」と思った依頼だったので、今年のお盆休みは全部返上するつもりで、監訳を引き受けることにしました!
(この決断のせいで、7月〜8月はハンパないくらい忙しくなったのですが……詳しくは後述しますw)

監訳って何をするの?

僕はこれまで「プロを目指す人のためのRuby入門」「技術記事を書く技術」という2冊の本を書いたり、「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍を翻訳したりと、本の執筆や翻訳の経験はあります。
ですが、監訳を担当するのはこれが初めてでした。

監訳者の役割は必ずひとつに定まるわけではないと思いますが、今回の監訳では、

「翻訳やニュアンスが違うのでは?」「この部分は、わかりづらい」「ここは補足説明や追加の訳注が必要ではないか」といった点を指摘してください

と依頼されました。

なんとなく「原著の英語と訳文を1文1文見比べて、訳の正しさをチェックしたりするのが監訳者なのかな?」と思っていたのですが、そうではなく、まずは翻訳された日本語の文章を読者目線でチェックするのがメインのお仕事でした。

実際にやってみると、監訳者の役割は「表紙に名前が載る、ちょっと責任の重いレビュアー」がイメージ的に近かったです。

監訳者としてがんばったこと

「世界で闘う本」の翻訳者は水野貴明さんです。
水野さんはこれまで技術書の翻訳を数多く手がけており、「プログラマー脳」や「JavaScript: The Good Parts」など、そのうちのいくつかの書籍は僕も過去に読んでいました。

というわけで、技術書の翻訳に関しては、僕からすると大先輩・大ベテランなわけですが、いただいた原稿を読んでいると、ときどき「これは日本語としてちょっとわかりにくいかも」と感じる部分がありました。

「原著の言い回しをなるべく崩さずに翻訳する」という考え方もひとつのアプローチなのかもしれませんが、僕は「原著者の意図を変えないなら、日本語としての読みやすさを重視してある程度意訳しても構わない(むしろその方が望ましい)」と考えています。

なので、「日本語として自然か」「日本語としてぱっと理解しやすいか」を重視して、いくつかの箇所を意訳してもらうようにお願いしました。

「訳書は読みづらいので苦手」という人も、もしかすると「この本はちょっと読みやすい気がする」と思ってもらえるかもしれません。
もしそう思ってもらえたら、僕の監訳者としての仕事は大成功!ということになります。

訳注をたくさん入れてもらった

また、本書は海外の本なので、日本人には馴染みのない固有名詞もよく登場します。
加えて、具体的な事例として技術的にやや高度なブログを挙げている関係で、"io_uring"や"eBPF"など、ITエンジニアであっても分野外の人は聞いたことがないであろう技術用語もときどき登場します。

最初の原稿の時点でも訳注はたくさん付いていましたが、僕目線で「これは注釈を入れた方がわかりやすいだろうな」と思った用語には、さらに追加で訳注を入れてもらうようにしました。

章によっては18個も訳注が載ってます
個人的なつぶやきを監訳注として入れてもらった

本書は訳注のほかに、「監訳注」もあります。
これは監訳者である僕が、個人的に「ひとこと説明しておきたい」もしくは「ツッコんでおきたい」と思った内容です。

あまりたくさん入れるとノイズになるので、なるべく少なくしたつもりですが、本書を読みながら「監訳注=僕のつぶやき」を探してみるのも面白いかもしれません😄

監訳注は僕個人のつぶやきです
いくつかの誤訳を修正してもらった

数としては少なかったものの、「あれ、その訳し方だとまったく意味が異なるぞ?」と思うような誤訳もたまにありました。

受け取った原稿は最初から最後まで、人間である僕がしっかり目を通しています。

読者視点で原稿を読み進めていって、「ここは文脈的になんか意味が通じないなあ」と思った部分は、原著の英文と見比べながら翻訳におかしな点がないか確認し、誤訳があったときは修正してもらうように依頼しました。

こういった地道な確認作業も、本書の品質向上に少なからず貢献しているはずです。

まえがきを書いた

監訳者として、本書のまえがきも書かせてもらいました。

見開き2ページで、そこそこボリュームのあるまえがきです。
本編とあわせて、こちらも楽しんでもらえると嬉しいです。

そうそう、上のまえがきの最後の段落にも書いてありますが、本書は「ネイティブスピーカーでなくても、ブログは英語で書こう」というスタンスで書かれている点も興味深いポイントです!

大変だったけど、がんばった!!

監訳の依頼を引き受ける際、「原著のWriting for Developersは1回読んでるから、まあ何とかなるだろう」と高をくくっていました。
が、レビュー用の紙原稿が届いてびっくりしました。

え、こんなにたくさんあるの・・・???

しかもこれ、片面印刷ではありません。両面です。

さらに、サンプルコードやスクリーンショットの少ない、テキスト中心の書籍だったのも誤算でした。
テキスト中心ということは、それだけチェックしなければならない文量も多い、ということです。

誇張ではなく、監訳作業のボリュームは、当初予想していた5倍以上ありました(完全に甘く見すぎていた……)。

とはいえ、「やります」と引き受けてしまった以上、手を抜くわけにはいきません。
前述のとおり、デブサミ関西の登壇準備もあったため、7月から8月にかけて、監訳と登壇の準備で超ハードな日々を過ごしておりました💦

でもなんとか乗り切った!
監訳も登壇もがんばった!!

どちらも無事に終わって、今はほっと胸をなで下ろしています。

本書の根底にあるのは、「書くこと」ではなく「共有すること」by 西田さん

(2026.9.18追記)
本書の編集を担当していた西田さんは、ご自身のFacebookタイムラインに企画から刊行に至るまでの紆余曲折や、編集裏話を書いておられます(去年話題になった「秀和システムの破綻」との関係についても……)。

僕の監訳についても言及してもらってます。

伊藤さんの監訳のおかげで、この本のクオリティは、一段も二段も向上しました。「ギャラに合わない作業量かも……」と言いつつも、伊藤さんからは読者目線での修正の提案や訳注追加の指摘をキメ細やかにいただきました。

褒めていただいて、とっても嬉しい😆

また、西田さんは本書の根底にある重要なメッセージを、次のように表現されています。

しかし、スコット・ハンセルマンの「あとがき」を(何度目かに)読んでいたときに、はたと気づきました。本書の根底にあるのは、「書くこと」ではなく「共有すること」なのだと。知を共有するための最短距離が「ブログを書くこと」であり、本書には「読まれるためのメソッド」が詰まっているのだと。

そう考えると、本書の構成や内容にも納得がいきます。より広く共有されるためには、「書くこと」以上に「読まれるための技術」が必要なのです。書くからには、読まれなければ意味がないのです。本書で解説している、トピックの選び方も、文法も、プロモーションや講演につなげることも、そのための(原著者が試行錯誤した)最適解なのです。

僕とは違った視点で本書の魅力を伝えておられるので、西田さんのポストもぜひチェックしてみてください👇


まとめ

というわけで、今回は2026年9月17日に発売される「世界で闘う エンジニア・アウトプット力を鍛える本」という本を監訳しましたよ、というお話を書いてみました。

原著の「Writing for Developers」は個人的に読んでいたものの、「ちょっとニッチなので日本語訳はされないんじゃないかな〜」と勝手に思っていました。
ですが、予想に反して日本語に翻訳され、さらに僕が監訳者として関わらせてもらえるとは、原著を読んでいたときには想像もしていませんでした。

もっと技術的に高度なブログを書きたい、そしてその内容でカンファレンスに登壇してみたい、と考えている人には、「世界で闘う エンジニア・アウトプット力を鍛える本」は、とても「刺さる」一冊だと思います。

自分の技術力をもっと世界に向けて発信したい人は、ぜひ本書をチェックしてみてください!

あなたは見分けられる?同じテーマで「AIバージョン」と「人間バージョン」のQiita記事を公開してみた

はじめに:今月のQiita記事のネタはCarrierWave!

「今月はQiitaにどんな技術記事を書こうかな〜?」と考えた結果、業務でいろいろ対応したCarrierWave 3.1のパフォーマンス問題をテーマに記事を書こうと思いました。
CarrierWave(以下CW)のmasterブランチにこの問題を解消するコミットが入ったのもちょうどいいタイミングだったので。

github.com

パフォーマンス問題は予期せぬタイミングでAmazon S3にアクセスが発生するのが原因なのですが、基本的にライブラリの裏側の処理なので、Railsアプリのコードだけ見ても、アクセスが発生しているのかどうかはわかりません。

また、S3は外部のリソースなので、ローカルで試行錯誤するためにわざわざS3のバケットを作って、クレデンシャルを書き込んで・・・というのも、ちょっとオーバーです。

そこでClaude Codeと相談しながら、ローカル環境だけでS3へのアクセスの有無を検証できるサンプルアプリを作りました。
ちなみにローカルのS3はMinIOというツールを使ってシミュレートしています。

github.com

試しにAIに書かせてみる?

さて、あとはこの検証結果をQiita記事にして公開すれば完了・・・なのですが、昨日はあまり時間がなく、「一度試しにAIに記事を書かせてみるか」と思いました。
というのも、サンプルアプリを作る過程でAIには記事執筆に必要な様々なコンテキストが溜まっているだろう、と考えたからです。

使ったプロンプトはこんな感じ。

ブランチをmainブランチに切り替え、このリポジトリをgithubにアップした。
CarrierWave 3.0→3.1→最新のmasterで何が変わったのか、どういう点に気を付ければいいのかをこのサンプルアプリを活用しながら解説するQiita向けの記事を書きたい。
叩き台となる記事をリポジトリ内にmarkdownファイルとして書き出してほしい。

ただ、できあがった記事はイメージと異なる部分があったので、何度かやりとりして、僕のイメージに近づけていってもらいました。

やっぱり自分の手で書くか〜!

が、やっぱりしっくりこない。
わかってたけど。

なので、やっぱり自分の手で書くことにしました。
叩き台になる記事はClaudeに書いてもらったので、それもある程度は参考にしますが、説明の流れや「この話も追加で書きたい」「これは無理に載せなくて良い」といったトピックの取捨選択は、僕が考えました。

その結果、CarrierWave 3.1のパフォーマンス問題という同じテーマで、Claudeが書いたAIバージョンと、僕が書いた人間バージョンの2つができあがりました。

どっちがAIバージョンで、どっちが人間バージョンでしょうか?

同じテーマであるにもかかわらず、記事のテイストはかなり異なるものになったので、どちらもQiitaで公開してみることにしました。
それが以下の2つの記事です。

qiita.com

qiita.com

ここではあえてどちらがAIバージョンで、どちらが人間バージョンなのかは書きません。
みなさんが読んでみて、どっちがどっちなのかを当ててみてください!
(たぶん、すぐわかると思うけど……)

そして、なぜそう感じたのか、どこを見てそう判断したのか、そのポイントについても考えてみてください。
SNSのリプライ欄や、このブログのコメント欄で、「自分はこっちがAIで、こっちが人間だと思う。その理由は……」みたいに、みなさん自身の見解を書いてもらったりすると嬉しいです。

また、自分はどっちの記事が好きか、どっちの記事がわかりやすいか、といった好みもぜひ聞いてみたいです。
(好きな記事に「いいね!」を付けてもらうと、定量化できていいかも?)

ちょっとしたクイズだと思ってぜひトライしてみてください!

参考:ChatGPTは大正解!

ちなみにChatGPTに聞いてみたらちゃんと正解しました(笑)。


AIなら10秒、人間なら3時間。この差をどう捉えるか?

ただ、執筆時間は全然違うんですよね〜。

  • AIバージョン = 初稿は10秒前後。その後のブラッシュアップを含めても、トータルで数分
  • 人間バージョン = 約3時間。「これは書こう」「この内容はカットしよう」とか、いろいろ考えていたら、あっという間に時間が溶けた🫠

この大きな執筆時間の違いをどう捉えるのかも、技術記事はAIに書かせるのがいいのか、それとも自分で書くほうがいいのか、大きな分かれ道になってきそうです。

このあたりの話は先日のデブサミ2026関西でもお話したので、よかったら以下のスライドもチェックしてみてください。

まとめ

というわけで、今回のエントリではQiitaに同じテーマで「AIバージョン」と「人間バージョン」の2種類の記事を公開してみたよ、という話を書いてみました。

まあ、僕が書いたプロンプトはざっくりしすぎているので、「こんな雑なプロンプトなら、この程度のアウトプットになって当然やろ」と思われそうですが、とりあえず記事の書き手として、もしくは読み手として、どっちが良いか考えるひとつのきっかけになればいいな〜と思って、こういう企画を考えてみました。

どっちがAIで、どっちが人間か、ぜひ当ててみてください!

qiita.com

qiita.com

12年ぶりの登壇!デブサミ関西2026で「AI時代のアウトプット」についてお話しします #devsumi

お知らせ

2026年8月21日(金)に開催される「Developers Summit 2026 KANSAI」(デブサミ関西)に登壇します。

event.shoeisha.jp

今回の僕の登壇タイトルは「AI時代のアウトプット――変わったこと、変わらないこと」です。

当日はこんなテーマでお話しする予定です ↓

生成AIの登場によって、エンジニアのアウトプットを取り巻く環境は大きく変わりました。技術的な疑問はAIに聞けば解決できるようになり、記事の執筆もAIが支援してくれます。

一方で、自分の経験や考え、試行錯誤の過程を言語化する価値は今もこれからも価値があると考えています。

本セッションでは、AI時代になって変わったこと・変わらないことを整理しながら、長年アウトプットを続けてきた私自身の考え方やAIの利用方法を紹介します。

AIと共に生きる時代に、エンジニアが学び、書き続ける意味を参加者のみなさんと考えます。

AI時代のアウトプット――変わったこと、変わらないこと | Developers Summit 2026 KANSAI(2026.08.21)

12年ぶりのデブサミ登壇!

デブサミ関西の登壇はこれが初めて・・・ではなく、実は2014年に一度登壇しています。

blog.jnito.com

およそ12年ぶりということで、久々のデブサミ関西を楽しみたいと思います!

ちなみに当日は、あの「とほほ」さんや、あの「みのるん」さんの基調講演もあります(お二人とも同じ時間帯なのが悩ましい💧)

他にも興味深い講演がたくさんあるので、関西近辺のエンジニアのみなさんはぜひ、ご参加を!

早めの事前登録をお忘れなく

申込みの期限は8月19日(水)13時までです。

参加費は無料ですが、A会場、B会場、それぞれで席数が決まっているので、聞きたい講演がある場合は、早めに参加登録しておくことをおすすめします!

なお、会場は大阪梅田ツインタワーズ・サウス11Fにある、梅田サウスホールです。

hankyuhanshin-hall.com

まとめ

というわけで、今回のエントリは2026年8月21日(金)に開催される「Developers Summit 2026 KANSAI」に登壇しますよ、というお知らせでした。

そういえば、オフラインで登壇するのも久々ですね。
調べてみたら、前回オフラインで登壇したのは、2023年9月の大阪Ruby会議03でした。

blog.jnito.com

個人的には、会場のみなさんの顔を見ながら発表できるオフライン登壇の方が僕は好きですね。
当日は会場でみなさんとお会いできるのを楽しみにしています。

参加登録はこちらからできます。みなさん、お早めに!!
👇 👇 👇
event.shoeisha.jp