ついに「技術記事を書く技術」が物理的な「本」として完成しました！
#技術記事を書く技術 、見本誌が届きました。ついに完成！嬉しい！！ pic.twitter.com/JNFEHGVahh
— Junichi Ito (伊藤淳一) (@jnchito) 2026年4月16日
これまであまり公にしていなかったこともあり、この本をいつから書き始めたのかを知っている人はほとんどいないと思いますが、編集の大嶋さんから執筆の誘いを受けたのは2021年11月のことでした。
そして今は2026年4月です。ざっと数えて4年半！
そう、「技術記事を書く技術」ができあがるまで4年以上かかったんです！！
赤ちゃんを出産したときに、お母さんが「やっと会えたね」と声をかけるシーンがありますが、完成した本を受け取ったときの僕の気持ちはまさにそんな感じでした……!!
おお、この4年間、ずっとデジタルデータだった僕の原稿が、ついに本として物理化された……!! #技術記事を書く技術 https://t.co/grtsKExV2Z
— Junichi Ito (伊藤淳一) (@jnchito) 2026年4月16日
発売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年越しで完成した、伊藤さん入魂の一冊」をぜひ手に取っていただきたいです。
みなさん、「技術記事を書く技術」をよろしくお願いします！！
