プログラマでありたい

おっさんになっても、プログラマでありつづけたい

技術同人誌の著者は、なぜKindle版を出すのか or 出さないのか

　技術同人誌の著者として、技術書典・BOOTH・Kindleダイレクト出版（以下KDP）と３つの販売チャネルを使ってきました。その中で Kindle をどう見ているのか、どんな距離感で付き合っているのかを整理してみます。本記事では、売上金額や販売冊数には触れず、構成比や役割の違いという観点から、Kindle と BOOTH を比較します。なお、技術書典はオフライン販売会があるなど位置づけが大きく違うので、今回は直接の比較の対象として除外します。
　Kindleはやるべきか／やめるべきかという二択ではなく、どう位置づけるのが現実的かを考えるためのヒントになれば幸いです

なぜ技術同人誌と Kindle の話を書くのか

　技術同人誌界隈では、Kindle に対する評価が両極端になりがちです。ある人はAmazonが持つ巨大なユーザー基盤の恩恵をうけ、ある人はKindleのロイヤリティプログラムに対して不満を持ちます。

　自分自身、技術書典や BOOTH、そして Kindle を並行して使ってきました。今回はその経験をもとに、どういうKDPをどう位置づければよいのか、幾つかの観点で整理してみます。

Kindleの印税率とロイヤリティプラン

　まずKindleを評価するには、KDPのロイヤリティプログラムを理解する必要があります。KDPには、35%と70%という印税率が異なる 2つのロイヤリティプランが存在します。またその上で更に、Kindle Unlimitedについての理解も必要です。

35%の印税率

　1つ目のロイヤリティプランは、印税率35%です。例えば、商品の単価を1,000円に設定しておくと単純計算で350円が著者に入ります。後述の70%に比べて制約が少なく、このプランを選んでいる人が多いのではないでしょうか。書籍の一般的な印税率8〜10%に比べては随分高いものの、販売手数料だけで残りが全部取り分となる技術同人誌販売に比べると低く見えます。

70%の印税率

　2つ目のロイヤリティプランは、印税率70%です。かなり率がいいので、このプランに飛びつきたくなります。しかし、日本の場合は大きく2つの制約があります。1つ目の制約は、Kindle Unlimitdの対象であることです。2つ目の制約は、これはKindle Unlimitedの制約に起因するのですが、独占販売であることです。技術同人誌の著者としては、どちらも由々しき問題です。

Kindle Unlimited

　みんな大好きKindle Unlimitedですが、技術同人誌にとっては中々厳しい仕組みです。ロイヤリティ発生の仕組みが、本の定価などまったく関係なく、読まれたページ数に応じて分配される仕組みです。この分配というところがポイントで、KDP セレクト グローバル基金（つまりKindle Unlimitedの会員の利用料）が原資になっているようです。
　読まれたページ数に応じての分配なので、じっくり読む、あるいは必要なところだけ読む技術書は不利になりがちです。そして、Kindle Unlimitedに登録していると、通常の購入は殆どされません。

KDPのロイヤリティプログラムに興味がある方は、こちらで詳細をご確認ください
kdp.amazon.co.jp

　なお、私はAWSの薄い本シリーズの中で、第4巻昔話で振り返るAWSの歩みのみを登録しています。また、Kindle Unlimited用に（独占販売という形にするために）ビルドを変えての提供にしています。Unlimitedで提供すると、本当に売れません。エンジニアとUnlimitedの相性が良すぎるためかもしれません。また、ページ数の分配金は、販売に比べてあまりに低い金額になります。例えば、これを1話単位で提供すると、話は違うかもしれませんが、Kindle Unlimitedへの最適化はまだ試せていません。

KDPとBOOTHの比較

具体的な数字は避けますが、構成比で見ると、直接的な収益という観点では BOOTH が明確に大きいという結果になっています。一方で KDP は、ほとんど宣伝を行っていないにもかかわらず、一定の割合で売れ続けています。この「何もしなくてもゼロにならない」という性質こそが、KDP 最大の特徴だと感じています。

Kindle の特徴：放置可能で、自動販売に強いチャネル

Kindle の最大の特徴は、圧倒的なユーザー数を背景に、「自動的に売る仕組み」が整っている点です。著者が特別な販促を行わなくても、検索やレコメンド、関連書籍表示を通じて、一定の流入が継続的に発生します。

新刊告知や SNS での発信をしなくても、「関連分野に興味を持つ人」の目に本が触れ続けるため、時間が経っても売上がゼロになりにくいという安定感があります。

Kindle は、売る行為の多くをプラットフォーム側が担ってくれる、手をかけなくても回り続ける流通チャネルだと言えます。

BOOTH の特徴：物理本を手軽に扱える主戦場

Kindle が「自動的に売る仕組み」に強いチャネルだとすると、BOOTH は 著者が物理本を手軽に売るためのチャネル です。

技術同人誌において、紙の本は今も重要な存在であり、手に取られ、所有される体験には電子書籍にはない価値があります。BOOTH は、その物理本を個人でも無理なく扱える点が大きな強みです。また、印税ではなく販売手数料という考え方なので、販売価格の大部分が著者に入ります。ある意味、革命的なプラットフォームと感じています。

在庫管理や決済、発送といった作業をプラットフォーム側が支えてくれるため、著者は本作りに集中できます。BOOTH は、「自分の手で本を届ける」ための、現実的な販売基盤だと感じています。

考察

BOOTH と Kindle は「売っている相手」が違う

BOOTH と Kindle の最大の違いは、売っている本ではなく、売っている相手が違うことだと感じています。

BOOTH は、基本的に著者を知っている人に向けた販売チャネルです。技術書典で知った人、過去作を読んだことがある人、SNS やブログを通じて存在を認識している人が、次の1冊として手に取ります。

一方で Kindle は、その著者を知らない人に本を届ける仕組みです。著者名ではなく、タイトルやテーマ、関連書籍とのつながりによって表示され、本そのものが入口になります。

この違いが、同じ1冊であっても、チャネルごとの体感を大きく変えています。

BOOTH は『信頼の回収』、Kindle は『認知の拡散』

BOOTH での販売は、これまで積み上げてきた信頼を回収する行為に近いものです。著者の考え方や文体、内容の方向性を理解している読者が、今回も読もうと判断します。そのため、1冊あたりの存在感が強く、売れた実感も、読者との距離も、非常に近く感じられます。

対して Kindle は、信頼の回収ではなく、認知の拡散に近い動きをします。読者は必ずしも著者を知っているわけではなく、『このテーマの本を探していた』『似た本を読んだことがある』という理由で辿り着きます。

Kindle では、1冊1冊の手応えは小さく感じられますが、その分、著者名やシリーズ名が静かに広がっていく感覚があります。

Kindle は収益装置ではなく、知名度を積み上げる装置

この構造を理解すると、Kindle を今すぐ儲けるための場所として捉えるのは、少し無理があります。価格や販促の多くは Amazon 側の仕組みに委ねられ、著者が直接コントロールできる余地は限られています。正直、利益面での貢献は小さいです。

しかしその代わりに、Kindle には、

  • 膨大な利用者数を背景にした露出
  • 検索やレコメンドによる継続的な発見
  • 過去作が自動的に掘り起こされる仕組み

が備わっています。

Kindle は、売上を一気に伸ばす装置というより、本と著者の知名度を少しずつ積み上げていく装置だと捉えた方が、実態に近いと感じています。

技術同人誌著者にとっての現実的な役割分担

以上を踏まえると、役割分担はかなり明確になります。

BOOTH は、著者を知っている人に、確実に本を届ける場所です。Kindle は、本の存在を知らない人に、静かに届け続ける場所です。どちらか一方が優れているわけではなく、向いている役割が違うだけです。ちなみに言うと、技術書典オフラインは、最初の認知を創るところと捉えています。

技術同人誌著者にとって Kindle は、主戦場にはなりにくいものの、知名度を底上げし続ける補助輪として、外しづらいチャネルだと感じています。

まとめ

BOOTH と KDP は、同じ販売チャネルでありながら、役割はまったく異なります。BOOTH は、著者をすでに知っている人に本を直接届ける場所です。信頼関係を前提にした販売であり、1冊あたりの手応えも大きく、収益の主戦場になりやすいチャネルです。

一方で Kindle は、著者を知らない人に本を見つけてもらうための場所です。膨大なユーザー数と検索・レコメンドの仕組みによって、本そのものが入口になります。

Kindle は短期的な成果を求めると物足りなく感じるかもしれませんが、売る行為を自動化してくれる点は大きな強みです。技術同人誌著者にとっては、BOOTH で信頼を回収し、Kindle で知名度を積み上げる。この役割分担で付き合うのが、もっとも現実的だと感じています。


AWSの薄い本６　IAMのマニアックな話 2025

booth.pm

2026年の抱負

　遅くなりましたが、あけましておめでとうございます。本年もよろしくおねがいします。
年末年始に2025年を振り返っていて、前に進めた部分と上手くいかなかった部分がありました。上手くいかなかった部分は、商業誌の新刊を出せなかったことです。10年続けた記録が途切れました。40代も後半になり、今までの体力と気力に任せた進め方では駄目だなと痛感しました。ということで、新年を機会に悔い改めることとします。
　外に見えるアウトプット面について、宣言しておきます。これ以外に仕事やプライベートで取り組んでいることは幾つかありますが、それは表に出すことではないので除外とします。

※2024年も実質的には、殆ど活動できていない

どうありたいのか？

2026年は、家族を大事にする生活者でありながら、挑戦し続けている個人でありたい。
そのためには、自分の得意とする領域で有識者として振る舞うより、未経験の分野にも積極的に取り組んでいきたい。

行動の軸

判断基準をシンプルにして、継続する。
1日30分、内容を問わず「原稿（含むブログ）を書く」が「実際に行動する」
考えるだけとか、Twitterで呟くだけはNG。何か残るという部分を重視する。

何をするのか？

  • 技術同人誌　2冊 + 1冊　⇒春・秋の技術書典とPEAKSを想定
  • 商業誌　2冊（1冊は、AWS以外をテーマとする）
  • ブログ　毎月1本以上
  • 地方（東京・埼玉・大阪以外）の勉強会に3回現地参加する

身につける習慣

  • 年間・月間の計画の策定
  • 手帳を毎日つけて、予実管理と振り返りの習慣化
  • 毎週の実績を定量的に測定
  • 通勤時間でブログを書く
  • 平日、7時間寝る

やらないこと

  • スマホに費やす時間を短くする。アプリタイマーで利用上限を設定の上で、寝室にスマホを持ち込まない
  • SNS等に時間を費やさない。

Twitter（X）の『3ヶ月500万インプレッション』チャレンジに成功し得たもの

　2025年に取り組んだことの一つに、Twitter（X）で「3ヶ月500万インプレッション」に挑戦し、見事に達成しました。その顛末についてまとめて、再現性について考えてみます。

なぜこのチャレンジをやろうと思ったのか

　まず始めに、なぜこの3ヶ月500万インプレッションのチャレンジをしようと思ったのかです。長らく執筆・出版を繰り返してきた人間として、SNSはセルフマーケティングのために非常に重要なツールです。自分が著者として毎年のように本を出せているのは、出した本が毎回沢山の人に購入して頂けているお陰です。
　売れている理由としては、テーマ選びや長年の実績の積み重ねもありますが、SNSによるセルフマーケティングの効果も少なからずあります。そのセルフマーケティングの中で、重要な位置を占めるのがTwitter（X）です。今回、これにもっとドップリと向かい合おうと思って、チャレンジしました。
　また3ヶ月500万インプレッションという数字は、Twitterの収益分配プログラムの参加条件にオーガニックインプレッション（広告なしの表示数）で3ヶ月500万という条件があるので、金銭的なモチベーションに結びつけることにより、より強い動機となるようにしました。

チャレンジ前の状況

　さて、チャレンジ前の状況としては、どういう状況だったのでしょうか？簡単に整理してみます。

チャレンジ前のインプレッションと活動量

チャレンジは、2025年8月から10月までだったので、まずは2025年2月から7月までの状況をお伝えします。（1年以上前のデータが引っ張れないので、1月1日の情報が欠落しているため）


  • 月30〜40万インプレッション程度
  • 投稿頻度・時間帯・内容が安定していなかった
  • たまに大きく伸びる投稿があるものの、再現性が低かった

趣味のツイートとしては、これで十分な数字です。一方で、もう一歩踏み込んでセルフマーケティングとして使おうとすると、少し物足りない数字というのが正直なところです。

目標設定

　この前提の元に、どう活動に落とし込んできたのか。目標設定とそれを日々に落とし込む考え方です。

『3ヶ月で500万インプレッション』

　冒頭に書いた通り、収益化プログラムへの参加という目標もあるので、3ヶ月500万というのが必須条件です。495万までいったので、目標には少し足りないけど頑張れて良かったでは済まないようにしています。やるからには、必ず達成すると計画をたてました。そのために考えたのが、次の3つです

  • 数字を置かないと改善できない
  • 月170万インプレッションが必要
  • 日次に分解するとどうなるか

　ざっくり月170万という目標で動いていると、後になっても挽回ができません。日時に落とし込むことが第一歩です。

日々の目標値

　日時の目標をたてるにあたって、平日と休日を分けて考えています。これはブログ時代から共通するのですが、私の投稿内容は技術よりの内容が多く、平日に見られる傾向にあります。そのため、平日に目標インプレッション数を多く傾斜することにしました。

  • 平日：8万インプレッション／日
  • 休日：1.5万インプレッション／日

　これまでの半年の実績が、1日1万インプレッションなので、平日に大きな開きがあります。月あたり4倍以上のインプレッション。日の平均にならすと8倍近く必要なときもあります。かなり大変です。

計画と設計

　過去の経験から、自分のツイートあたりのインプレッション数は平均1,000くらいというのは解っていました。単純計算すると、平日に80回・休日に15回呟くと達成できます。が、これは無理な数字です。イベント等で特別な事がないかぎり、ちょっと多めに呟いたとしても1日10本くらいがこれまでの実績でした。またそこから増やしたとしても、20本くらいが限度と見るべきです。その上で、どうやったら達成できるのかを考えて計画と設計を考えました。

無理せず続けられる計画

　まず考えたのが、1日の投稿数の上限はアベレージで20本として、それ前提でどう組み立てるかです。具体的には、毎日1〜2本くらい1ツイートで1万インプレッション超えの中ヒットを出して、あとは1千インプレッションを複数出す。プラスして、数日に一度くらい5万インプレッション超えのホームランが出ればくらい万々歳と考えました。
　一方で毎日コンスタントに20本投稿するのは、不可能と考えました。そのため、過去のコンテンツを再利用して、ツールを併用して自動投稿を活用することにしました。

  • 過去のコンテンツを再利用する
  • 投稿枠を先に決める、自然投稿と自動投稿の使い分け
  • 無理して自然投稿を増やさない

　過去のコンテンツは、Speaker DeckのスライドやYoutubeの過去の登壇動画、BOOTHやKindle・技術書典で販売している技術同人誌などを活用しました。本当は過去ブログも活用した方が良かったのですが、そちらは掘り起こしが少し面倒くさかったので、おざなりになってしまいました。そして、自動投稿のツールとしては、SocialDogのPersonalプランを利用していました。1日４〜５本の枠を作って、

　また、自然投稿。つまり普通の呟きをどうするか問題です。インプレッションの動向をよく見ていると、実は平日日中の閲覧数が多いわけではないということが解りました。昼休みや平日の20時以降に伸びています。なので、だいたいその辺りにのんびり呟くようにしていました。

投稿設計の考え方

　では、何を呟くのか。ここは最初にChatGPTでプロジェクトを作って、分析を行いました。過去のインプレッションの動向や、エンゲージメントが高い呟きが何か。分析すると、だいたい下記のような傾向が見られました。

  1. キャリア論・マネージメント論が一番伸びる
  2. AWS等の技術情報は、大きく伸びないが一定の需要がある
  3. 執筆関係は、インプレッション数は伸びないがエンゲージメントが高い
  4. 告知系のインプレッション数は低位安定だが、技術同人誌の売上には多大な貢献
  5. ネタ系は当たり外れが激しい

　告知系やキャリア論・マネジメント論のツイートを休日に１週間分セットして、AWSの技術情報をAWSのWhat's Newで毎朝チェックして投稿。そして、あとは適当に呟くというルーチンにすることにしました。

計測の仕組み

　あとは実践あるのみですが、上手く言っているかは計測が大事です。
Googleのスプレッドシートで、毎日予実を管理します。

　ここまでやったら仕事じゃんと突っ込まれますが、自分はこういう系統のPDCAを回すことは苦にはなりません。

結果

　さて、結果です。
10日ほど前倒しで、達成できました。

　そして、達成後にネタ投稿がバズって、さらに大きく伸びました。
これが最初に出ていれば楽でしたが、そうなったらちゃんとPDCA回せなかったので、良かったのかもしれません。

まとめ

　計画・設計・計測を徹底し、感覚やバズに頼らずに「3ヶ月500万インプレッション」を達成しました。天才的なひらめきではなく、数字を分解して構造を作り、淡々と回すことで結果は再現できます。SNSもまた、才能ではなく運用の話だという実感を得た取り組みでした。
　ただ、こんな事をしなくても、感覚で簡単にやっちゃう凄い人も多いと思います。自分はそういう風にはできないので、仕組みで淡々とやっていく方を選びました。

オチ

　ちなみに、見事イーロン・マスクからお小遣いが貰えるようになりました。しかし、手数料が。。。

技術書典19の『第11回 刺され！技術書アワード』でAWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行ったが大賞を受賞しました。と売上報告

　昨年11月に出展した技術書典19で上梓した『AWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行った』が、『第11回 刺され！技術書アワード』で大賞を受賞しました。合同誌含めて過去8冊出していますが、今回が初めてです。

booth.pm

『刺され！技術書アワード』とは

　 刺され！技術書アワードは、技術書典19の出展作品の中から自薦・他薦でお勧めの技術書を紹介する企画です。応募された作品は、主催者である日高さん・高橋さんによって、コメントとともに紹介されます。
　プロの視点から自分の本の特徴を言語化してもらえるため、マーケティング面でも、著者としても嬉しい企画だと感じています。

　応募作品は100冊を超え、その中から以下の3部門でファイナリストが選出されます。その上で、各部門を横断して大賞が選ばれる仕組みです。

  • 刺さる部門
  • エポックメイキング部門
  • ニュースタンダード部門

　詳細については、こちらをご参照ください。

blog.techbookfest.org

受賞発表の様子

　当日の受賞発表の様子です。私のS3本は、ニュースタンダード部門でエントリーされていました。ニュースタンダード部門は、こういった基準で選ばれているようです。

技術書典とその読者の「枠」や「間口」を押し広げてくれるような、新たな視点・可能性を示した技術書に送られます。

www.youtube.com

　実は発表当日は体調不良で早々に寝てしまっており、ライブ配信を見ていませんでした。後からTwitterのタイムラインを追っていると、なんと自分の作品が受賞していることを知りました。
　一世一代の機会をライブで見られなかったのは残念ですが、それ以上にありがたい出来事でした。

受賞作品『AWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行った』について

書籍についての紹介は、過去のエントリーで書いているので、こちらをご参照ください

blog.takuros.net

S3の深淵を書いた理由

　7冊目の「AWSの薄い本」シリーズとして、S3を選んだ理由についてです。以前から公言しているのですが、AWSの中で特に好きなサービスはS3とSQSです。どちらもクラウドらしさや、AWSの設計思想を強く体現しているサービスだと感じています。

　S3はクラウドを前提としたオブジェクトストレージであり、AWSのサービス群の源流の一つです。また、SQSはEC2やS3よりも前から提供されているサービスで、こちらもAWSの源流の一つと言えるでしょう。特にSQSは、うまく使うことでサービス同士を疎結合にできます。

　S3は、AWSを使っている人であれば、ほぼ誰もが利用しているサービスです。明示的に使っていなくても、裏側でS3を利用しているサービスは多く存在します。一方で、S3は非常に懐が深いサービスであるため、多少雑に使っていても大きな問題が起きにくく、「なんとなく使えてしまう」側面があります。
　そうした背景もあり、深く理解しないまま使っている人も多いのではないでしょうか。そんな人たちに、「もう少しS3を知ってみよう」と思ってもらうきっかけになればと考えて、本書を書きました。

評価されたと感じているポイント

　この本が評価された理由は何だったのでしょうか？幾つかコメント頂いていますが、この本にはAWSの管理画面やコンソール操作などは一切言及していません。ひたすらS3がどういうサービスなのか、またどのように使えばよいのかという考え方のみを書いています。そういった方針が、今の技術書典の潮流とは少しズレていて良かったのかもしれません。

PEAKSクラウドファンディングに向けて

　この技術書アワードの大賞は、副賞としてPEAKSクラウドファンディングで出版ができるそうです。具体的な部分については、これから調整していくことになるかと思いますが、せっかくの機会なので挑戦してみようかと思います。無事に出すことができそうであれば、大幅に増補して150〜300ページのマスター of S3みたいな感じで出したいですね。
　それくらいの分量であれば、S3 TablesやS3 Vectorsについても、たっぷりとページを割くことができます。相変わらずS3に対してどれくらいの需要があるか謎ですが。

Software Design誌に、S3の特集記事を寄稿しました

　S3関係の今月の予定として、1月17日発売の 『ソフトウェアデザイン2026年2月号』にS3の記事を寄稿しました。第二特集24ページ分、まるまる私の方で書かせて頂きました。話の内容としては、S3の深淵本と被ることも多いのですが、re:InventのS3関係のセッションの内容を聞いた上で、最新の情報やベストプラクティスについても盛り込んでいます。

ソフトウェアデザイン 2026年2月号

ソフトウェアデザイン 2026年2月号

  • 技術評論社
Amazon

　キッカケは編集者の方から、AWS の薄い本の合本 Vol.01で私が書いたS3の章をベースに書いてみないかと依頼がありました。ちょうどどの時に、S3の深淵本を執筆中で内容が被っても問題ない旨が確認とれました。あとはre:Inventの情報盛り込めば楽勝で書けるなと、甘く見積もった産物です。内容自体はしっかりと書けていると思いますが、楽に書けたかどうかはご想像にお任せいたします。

技術書典19の売上報告

　ここから話題が変わりますが、技術書典19の売上報告です。前回はオフライン会場を中心に、最初の2日間の売上をまとめましたが、今回は次回以降の参考として、会期全体の売上状況を記録しておきます。

全体の売上概要

　みんな大好き、売上報告です。メールからの集計で若干実数とあわないところがありますが、期間中の合計で520冊売れました。そのうち新刊のS3の深淵本は、369冊です。また、オフライン（会場）とオンラインでの比率は、212冊と308冊で約6割がオンラインでの販売となりました。


売上から見えた傾向

新刊のS3の深淵本の動向

　新刊については、前回のIAM2025本に比べて勢いが若干弱いです。要因としては、次の３つくらいがあるかなと思います。

  • 宣伝不足
  • IAM本に比べて、S3というテーマは新機軸だった
  • S3を学ぶ必要性を訴求できなかった

　1つ目の宣伝不足については、完全に自分の落ち度です。今回は多忙だったこともあり、新刊を見送るつもりでいましたが、直前になって「やはり新刊がないのは寂しい」と思い、突貫で執筆しました。結果として、執筆後は力尽き、十分な宣伝ができませんでした。これが最大の要因だと思っています。

　2つ目については、「IAMの人」というイメージが自分に定着している影響もあったのかもしれません。その人間がS3について何を書くのか、と感じた方もいたのではないでしょうか。
　3つ目は、冒頭でも触れた通り、S3が非常によくできたサービスであるがゆえに、「今すぐ学ばなくても困らない」と思われがちな点です。

　一方で、技術書典19の会期が終わっても、じわじわと売上は伸びていっています。これからの宣伝・マーケティング次第で、十分訴求できるという手応えも感じています。

オフライン（会場）とオンラインの傾向

　技術書典の目指している方向でもあるのでしょうが、ここ数年の傾向としてはオンラインの売上の力強さが顕著になってきています。従来は、会場販売の一発勝負だったのですが、今では総数としてはオンラインの売上比率の方が高くなっています。爆発的な売上というより、評判が良いものがしっかりと売れるという傾向になっています。会場で購入して頂けるアーリーアダプターに誰に向けての本なのかをしっかりと訴求し、それが広がればオンラインで広がるという設計になっています。
　逆に言うと、自分は購入者がSNSで呟きたくなる仕組みが不足していると反省しています。このあたりは次回に向けて、しっかりと仕組みを考えていこうと思っています。

まとめ

　少し長くなりましたが、技術書典19の総括です。記事中では触れていませんが、今後の執筆スタイルや方向性、セルフブランディング、マーケティングについても、多くの示唆を得ることができました。
　出展としては9回目になりますが、本気で向き合えば、まだまだ学ぶことは多いと実感しています。2026年も年2回開催されるようなので、引き続き新刊を出していきます。今後ともよろしくお願いいたします。
booth.pm

技術書典19オフラインに出展してきました。売上報告と新刊「AWSの薄い本7　S3の深淵を知るためにAmazonの奥地に行った」

　少し報告が遅くなりましたが、2025年11月16日、池袋サンシャインシティで開催された技術書典19のオフライン会場にブース出展してきました。今回は、新刊のS3本に加えて、これまでの「AWSの薄い本」シリーズやIAM本2025など、7冊を並べての参加です。

技術書典19



　次回の自分と技術書典に参加される方に参考になるように、最初の2日分の売上速報と、新刊の紹介をまとめておきます。イベント全体の集計は、11月末までのオンライン開催が終わった後に、あらためて別エントリで整理する予定です。

新刊『AWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行った』について

　今回の新刊は、 『AWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行った』 です。
S3は2006年から続くAWS最古参のサービスの一つであり、今もAWS全体の設計思想が一番よく表れているサービスだと感じています。

本書では、

  • オブジェクトストレージとは何か？そして、S3とは？
  • EC2からS3に至るまでの接続経路とネットワーク構造
  • IAM・バケットポリシー・KMSを組み合わせたアクセス制御とセキュリティ設計
  • ストレージクラスやリクエスト課金まで含めたコストの考え方
  • プレフィックス設計やS3 Express One Zoneなどを踏まえたパフォーマンスと最適化
  • 99.999999999%の堅牢性を誇るS3に何故バックアップが必要なのか。またランサムウェアについての私見

といった観点を中心に、「S3を理解すると、AWS全体が立体的に見えてくる」というコンセプトで書きました。設定手順そのものを追うというよりは、「なぜそう設計するのか？」という背景や考え方にフォーカスしています。

techbookfest.org

　S3をちゃんと理解しておきたいインフラエンジニアの方はもちろん、アプリケーションエンジニアやアーキテクトとして「S3の制約を前提にシステムを設計したい」という方にも読んでいただきたい内容になっています。

技術書典19 初動2日分の売上速報

　それでは、みなさんお待ちかね（？）の売上速報です。今回は、技術書典オンライン開始から最初の２日分だけ、ざっくり数字を共有しておきます。全期間を通した最終的な集計は、冒頭に書いたとおり後日まとめます。また、集計も受信メールを元にChatGPTに簡単なスクリプトを書いてもらって計算しているので、例外ケースなど多少の誤差はあります。そのあたりはご容赦ください。

２日間の技術書典での状況

  • 合計：337冊
  • オンライン販売：125冊
  • オフライン会場（技術書典19当日）：212冊

　オフライン会場だけで200冊を超えていて、体感としても「常に誰かが立ち止まっている」くらいのにぎわいでした。オンラインも初日からコンスタントに動いていて、会場に来られなかった方がしっかり拾えている感覚があります。また新刊に関しては、会場と同じくらいの売れ行きでした。


新刊S3本の動き『AWSの薄い本7 S3の深淵を知るためにAmazonの奥地に行った』

  • オンライン：112冊
  • 会場：120冊
  • 合計：232冊

　初動2日で232冊と、シリーズの中でもかなり良いスタートダッシュになりました。内訳を見ると、オンライン初日にS3本だけで40冊。オフライン会当日、 会場120冊＋オンライン72冊という感じで、オフラインとオンラインがうまく噛み合ってくれています。会場で「とりあえず新刊を1冊」という方が多かったのに加えて、SNSでの告知を見てオンラインで買ってくださった方もかなりいた印象です。

既刊の動き

　既刊についても、ざっくり数字を出しておきます（いずれも初動2日分の合計です）。

  • â‘  IAM初代本：19冊（全て会場）
  • â‘¡ アカウントセキュリティ本：8冊（全て会場）
  • â‘¢ データ分析基盤設計本：9冊（オンライン2／会場7）
  • â‘£ 昔話本：11冊（オンライン2／会場9）
  • ⑤ データ分析基盤性能本：7冊（オンライン1／会場6）
  • â‘¥ IAMのマニアックな話 2025：51冊（オンライン8／会場43）

　新刊S3本をきっかけに「せっかくだからIAM本も」「分析基盤の本もまとめて」という形で、既刊だけで合計100冊強動いてくれました。シリーズ全体として見ても、かなりありがたい数字です。

初動を眺めてみての感想

　今回の初動を眺めていて感じたのは、初代IAM本とIAM2025の売り方を工夫することによって、初代IAM本の動きがよくなったことです。具体的な工夫としては、下記をポップおよび口頭での説明をしました。

  • IAM本を2冊並べて展示する
  • 2冊の役割の違いを伝える。初代IAM本は、個々のIAM設計の話。IAM2025は、組織としてIAMをどう扱うかの話

というあたりです。これにより、2冊同時に購入される方や、自分に必要なのはIAM本だと購入される方が多かったのが印象的でした。

これまでの技術書典オフライン会との比較

時間 技術書典7 技術書典14 技術書典15 技術書典17 技術書典18 技術書典19
11:00
151冊
43冊
24冊
42冊
62冊
42冊
12:00
94冊
37冊
23冊
43冊
55冊
44冊
13:00
82冊
48冊
30冊
37冊
48冊
51冊
14:00
43冊
25冊
49冊
28冊
47冊
40冊
15:00
45冊
22冊
26冊
28冊
24冊
19冊
16:00
36冊
11冊
4冊
17冊
19冊
16冊
合計
451冊
186冊
156冊
195冊
264冊
212冊
来場者数
9,700人
2,100人
2,200人
2,600人
2,800人
2,400人

※集計漏れ等もあり、数字が一致しないところがあります（合計値が正しい）

次回以降に向けてのメモ

　備忘録も兼ねて、次回以降に改善したいポイントを簡単に残しておきます。

  • S3本とデータ分析基盤本の3つを一つのストーリーで説明する
  • 机上の価格表に、本の説明を記載する
  • ワンオペはしんどい

　物理出展も6回目を超えて、だいぶ慣れてきた一方で、毎回なにかしら反省点が出てきます。こうやって少しずつブースの完成度を上げていくのも、技術同人活動の楽しさのひとつだなと感じています。

まとめ — S3本、引き続きよろしくお願いします

　ということで、技術書典19の初動2日分の売上速報と、新刊S3本の紹介でした。
S3まわりで悩んでいる方、S3の設計をちゃんと整理しておきたい方、あるいは「AWSのことをもう一段ちゃんと理解しておきたい」という方に、ぜひ手にとってもらえれば嬉しいです。
　技術書典オンラインの会期中は、物理本＋PDF版のセットをオンラインでそのまま購入できますし、会期終了後もBOOTHで頒布を継続する予定です。

techbookfest.org

booth.pm

　残り会期と11月末の最終集計に向けて、引き続き見守っていただければ幸いです。

S3を理解するとAWSが分かる！！構造からスッと理解できる一冊を書きました

AWSの薄い本シリーズの第7弾を執筆しました！！
AWSの薄い本7　S3の深淵を知るためにAmazonの奥地に行った

タイトルの通りS3についての本で、 S3を使いこなすための知識を構造的に整理した1冊 です。
本日より BOOTH・技術書典オンライン で販売を開始し、明日（2025/11/16）の技術書典19（池袋）では紙版を直接頒布します。

S3の「奥深さ」に改めて向き合った理由

S3はAWSの歴史の中でも特別な存在です。2006年3月に登場し、AWSという名前を冠した最初のサービスでもあります。「AWSを使いこなす」ためには、このS3を深く理解することが避けて通れません。

一方で、S3はその“簡単そうに見える顔”とは裏腹に、ネットワーク経路・コスト・暗号化・アクセス制御・バックアップ設計など、多層的な知識が求められるサービス でもあります。

今回の本は、私自身がこれまで多くのプロジェクトでS3に向き合ってきた経験を踏まえつつ、「なぜそうなっているのか？」という構造的な理解を軸にまとめたものです。AWSを扱うすべての人にとって、実務で役立つ“手元に置く本”を目指して執筆しました。

どんな視点でこの本を書いたのか

今回の執筆では、次のポイントを重視しています。

  • S3の構造を軸に理解すること
  • 図と例を多く用意すること
  • 実務で使う上で、知っておく必要を中心に整理
  • 初心者〜中級者にも伝わる言葉で書くこと

シンプルなようで奥行きを持つS3を、無理なく体系として理解できるような流れにしています。

この本で扱った主なテーマを紹介します

  1. S3の内部構造と誕生の背景
  2. アクセス制御（IAM・バケットポリシー・KMS）
  3. ネットワークと接続経路
  4. コストと最適化の考え方
  5. バックアップとデータ保護の考え方
  6. パフォーマンス最適化
  7. 安全な運用と実践的ガイド

実務で迷わないために必要なものを、網羅しつつも読みやすい粒度でまとめています。

なぜ今、S3の“構造理解”が必要なのか

S3はシンプルに見えますが、実務での事故やトラブルの多くは以下の原因で発生しています。

  • コストモデルの誤解
  • ネットワーク経路の理解不足
  • KMSの扱いを誤る
  • アクセス制御の“二層構造”を意識していない
  • バックアップ不要という誤解
  • S3は「なんでも置けば良い場所」と思われがち

本書ではそれらを避けるため、
“構造の理解” → “設計原則” → “実践” の三段階
で理解しやすい流れにしています。

S3を理解すると、AWS全体がもっと見えてくる

　好きなAWSサービスは何と聞かれると、S3とSQSと答えます。SQSはシステム間を疎結合にするためのキーファクターで、上手くつかいこなすとシステムの安定性はグッとあがります。そして、S3は数あるサービスの中で、もっともクラウドとして完成度が高いサービスだと思っています。S3があったからこそ、AWSはクラウドという新しい世界を作れたのだと考えています。
　そして、S3はAWS設計の肝です。ここを理解するとアーキテクチャ全体が一段クリアになる。そんな実感を得られる一冊になるはずです。

販売情報

BOOTH（電子・紙）

booth.pm

技術書典

オンライン

techbookfest.org

オフライン

技術書典19（池袋）：明日、直接頒布します！

Kindle版

2026年1月を目安に販売開始予定です。既刊販売中！！
AWSの薄い本

目次情報

はじめに
　　本書の目的
　　対象読者
　　本書で得られること
　　本書のスタイル
　　お問い合わせ先
　　免責事項
第1章　S3を構造から理解する
　1.1 S3とは何か？
　　1.1.1 オブジェクトストレージとは
　　1.1.2 「Simple」の意味
　1.2 S3の内部構造とオブジェクトの仕組み
　　1.2.1 バケットとオブジェクト
　　1.2.2 キーとオブジェクトの関係
　1.3 フラット構造とプレフィックス設計の影響
　1.4 S3の信頼性と整合性
　　1.4.1 アベイラビリティーゾーンと冗長性
　　1.4.2 リージョンと可用性
　　1.4.3 データ整合性モデル
　1.5 ストレージクラスと用途別の使い分け
　1.6 S3誕生秘話：Werner Vogelsのブログ
第2章　S3のアクセス制御
　2.1 IAMポリシーとバケットポリシーの関係
　　2.1.1 IAMポリシーと最小権限設計
　　2.1.2 バケットポリシーによるアクセス制限
　　2.1.3 IAMポリシーとバケットポリシーの関係
　　2.1.4 特定のVPCからのアクセス制限
　　2.1.5 S3 Access Grantsという選択肢
　2.2 重要なデータを扱うバケットは二重の防御を
　　2.2.1 二重の防御が必要な理由
　　2.2.2 バケットポリシーを設定すべきもの／不要なもの
　　2.2.3 ReadOnlyAccessとViewOnlyAccessの違い
　　2.2.4 ReadOnlyAccess付与時の注意点
　2.3 Block Public Accessと公開バケット
　　2.3.1 公開経路を根本から遮断する仕組み
　　2.3.2 4つの設定項目
　　2.3.3 S3は直公開せずCloudFront経由で公開
　　2.3.4 公開バケットは別アカウントで運用
　　2.3.5 安全な運用ルール
　　2.3.6 まとめ：誤公開を防ぐ構造的設計
　2.4 Admin権限でも操作できないバケットの対処法
　　2.4.1 アクセス拒否の原因特定
　　2.4.2 Admin権限でも操作できない場合の対処
第3章　ネットワークと接続経路
　3.1 AWSのネットワーク構造を理解する
　　3.1.1 パブリックIP通信
　　3.1.2 AWSグローバルネットワーク
　3.2 EC2からS3への4つの接続ルート
　　3.2.1 Internet Gateway経由
　　3.2.2 NAT Gateway経由
　　3.2.3 VPC Endpoint（Gatewayタイプ）
　　3.2.4 PrivateLink（Interfaceタイプ）
　3.3 通信経路別の比較と設計（コスト観点）
　3.4 Direct Connect経由のS3アクセス
　　3.4.1 Private VIF
　　3.4.2 Public VIF
　　3.4.3 実際のユースケースと設計判断
　　3.4.4 Private VIFの注意点
　3.5 まとめ：接続経路の正しい選択
第4章　S3のコストを理解する
　4.1 ストレージクラスと料金体系
　　4.1.1 標準ストレージ
　4.2 APIリクエスト料金の仕組み
　　4.2.1 ファイル数の影響
　　4.2.2 コスト差の実例
　　4.2.3 設計指針
　4.3 ライフサイクル最適化
　　4.3.1 設定指針
　　4.3.2 コスト注意点
　4.4 自動圧縮と最適サイズ設計
　　4.4.1 圧縮の仕組み
　　4.4.2 圧縮方式の使い分け
　　4.4.3 ファイルサイズ設計
　　4.4.4 ログデータのコスト削減
　4.5 まとめ
第5章　バックアップとデータ保護戦略
　5.1 バックアップが必要な理由
　5.2 データ保護設計（IPA非機能要件）
　　5.2.1 Grade1
　　5.2.2 Grade2
　 5.2.3 Grade3
　 5.2.4 Grade4
　5.3 バージョニングとオブジェクトロック
　5.4 レプリケーション
　　　5.4.1 CRR（クロスリージョンレプリケーション）
　　　5.4.2 クロスアカウント構成
　5.5 ランサムウェアとバックアップ
　　5.5.1 IAM権限を狙う攻撃
　　5.5.2 防御実装例
　5.6 マルチクラウドでのデータ保護
第6章　パフォーマンスと最適化
　6.1 性能と分散構造の理解
　6.2 プレフィックス設計とスループット
　6.3 S3 Express One Zone
　　6.3.1 性能比較
　　6.3.2 ユースケース
　6.4 パフォーマンス測定
　6.5 キャッシュ戦略
　　　6.5.1 CloudFront
　　　6.5.2 アプリケーションレイヤ
　6.6 まとめ
第7章　安全に運用するための設計指針
　7.1 KMSによる機密データ保護
　7.2 公開アクセスブロック（BPA）
　　7.2.1 Block Public Access
　　7.2.2 公開データの分離
　　7.2.3 CloudFront利用時の注意点
　7.3 監査・運用体制
　7.4 まとめ：正しいS3運用のために

あとがき
　著者紹介
　既刊一覧

技術書典18 オフラインに新刊『AWS の薄い本6　IAMのマニアックな話2025』とともに出展してきました（売上報告）

　2025年6月1日に池袋サンシャインシティで開催された技術書典18 オフライン開催にブース出展してきました。今回は、自身の新刊と会社の同僚3人が書いた委託本を引っ提げての参加です

技術書典18のブースの様子
技術書典18のブースの様子

新刊について

　今回の新刊については、JAWS Daysのセッション等で書くと宣言していたIAMのマニアックな話2025です。他の勉強会含めて数百人の前で書くと宣言していたので、なんとか期限が間に合って出版できてホッとしております。

AWSの薄い本６　IAMのマニアックな話
AWSの薄い本６　IAMのマニアックな話

techbookfest.org

各章のテーマ

目次

第1章　IAMの基礎と進化
　1.1 AWSアカウントと IAMの関係
　　1.1.1 AWSアカウントと IAM
　　1.1.2 AWS Organizationsと AWSアカウント
　　1.1.3 AWS Organizationsと IAM
　1.2 IAMの基本的な４つの機能
　　1.2.1 IAMユーザー
　　1.2.2 IAMグループ
　　1.2.3 IAMロール
　　1.2.4 IAMポリシー
　1.3 2019年～2025年の IAM関連のアップデート
　　1.3.1 主なアップデートの一覧
　　1.3.2 IAM関連のアップデートの潮流
　1.4 まとめ

第2章　AWS Organizationsと IAM
　2.1 AWS Organizations
　　2.1.1 AWS Organizationsの概要
　　2.1.2 AWS Organizationsの構成要素
　　2.1.3 組織単位（OU）と階層構造
　2.2 組織ポリシー—承認ポリシーと管理ポリシー
　　2.2.1 サービスコントロールポリシー（SCP）
　　2.2.2 リソースコントロールポリシー（RCP）
　　2.2.3 SCPと RCPのユースケースの違い
　　2.2.4 タグポリシー
　2.3 AWS Organizationsと IAMの関係
　　2.3.1 IAMの権限に対する SCPの位置づけ
　　2.3.2 IAMの権限に対する RCPの位置づけ
　　2.3.3 ポリシーの評価ロジック
　　2.3.4 IAM Identity Centerとの連携
　　2.3.5 アカウントをまたいだ IAMロールの利用（クロスアカウントアクセス）
　　2.3.6 IAM Access Analyzerと Organizations
　2.4 まとめ

第3章　AWS IAM Identity Centerと IAM
　3.1 IAM Identity Centerの概要
　　3.1.1 AWS IAM Identity Centerとは何か
　　3.1.2 IAM Identity Centerと IAMの役割の違い
　3.2 構成要素と動作の仕組み
　　3.2.1 インスタンス
　　3.2.2 アイデンティティソースの選択肢
　　3.2.3 許可セット（Permission Set）と IAMロールの関係
　3.3 マルチアカウント時代における IAM Identity Centerの必然性と課題
　　3.3.1 許可セット設計の難しさとスケーラビリティの限界
　　3.3.2 SCIM連携・外部 IdP統合時の権限割り当て運用の複雑さ
　　3.3.3 IdPが1組織に1つしか設定できないという制約
　　3.3.4 管理主体の分散による運用の複雑化
　3.4 課題を解決するための設計パターン例
　3.5 まとめ

第4章　IAM Access Analyzerと CCoE
　4.1 IAM Access Analyzerの基本
　　4.1.1 IAM Access Analyzerとは
　　4.1.2 外部アクセスアナライザー
　　4.1.3 未使用アクセスアナライザー
　　4.1.4 ポリシー生成
　　4.1.5 ポリシーチェック
　　4.1.6 カスタムポリシーチェック
　4.2 IAM監査体制と CCoEの役割
　　4.2.1 組織全体で実現する IAM監査体制と CCoEの役割
　　4.2.2 IAM監査における代表的なチェックポイントと Access Analyzerの役割
　　4.2.3 リアルタイム監査の実装と組織
　4.3 AIを活用したポリシー提案への夢
　　4.3.1 なぜ AIが必要なのか ～現状の課題と AI導入の意義～
　4.4 まとめ

第5章　AWS Verified Accessと IAM
　5.1 AWS Verified Accessの概要
　5.2 AWS Verified Accessの構成要素
　　5.2.1 Verified Accessインスタンス
　　5.2.2 信頼プロバイダー（Trust Provider）
　　5.2.3 Verified Accessグループ
　　5.2.4 Verified Accessエンドポイント
　　5.2.5 Verified Accessポリシー
　　5.2.6 Verified Accessのアーキテクチャ構成例
　5.3 Verified Accessと IAMの関係
　　5.3.1 Verified Accessのユースケース
　　5.3.2 IAMロールと Verified Accessの関係
　5.4 ゼロトラスト時代の認証認可のあり方
　　5.4.1 Verified Accessの役割
　　5.4.2 デバイス認証
　5.5 まとめ

第6章　IAMベストプラクティス集
　6.1 IAMベストプラクティスの変遷
　　6.1.1 削除されたベストプラクティス
　　6.1.2 追加されたベストプラクティス
　6.2 ベストプラクティスに向けての対応事項
　　6.2.1 長期認証情報から一時的な認証情報への移行
　　6.2.2 Access Analyzerの活用
　　6.2.3 多要素認証の位置づけと管理
　　6.2.4 ガードレール設計
　　6.2.5 最小権限の実現方法の高度化
　　6.2.6 マルチアカウント環境のガバナンス強化
　　6.2.7 権限委任の体系化
　　6.2.8 自動化とツールの活用
　6.3 AWS Well-Architected Frameworkと IAM
　　6.3.1 ID管理のベストプラクティス
　　6.3.2 アクセス許可の管理
　6.4 まとめ

第7章　長期認証情報から一時的な情報へ、そして動的認可
　7.1 IAMユーザーによる長期認証の時代
　　7.1.1 長期認証情報の特徴と課題
　7.2 IDフェデレーションと IAMロールによる一時的な認証への移行
　　7.2.1 IDフェデレーションと一時的な認証情報の仕組み
　　7.2.2 一時的な認証情報がもたらす利点
　7.3 コンテキストベースの動的認証・認可へ
　　7.3.1 属性ベースのアクセス制御（ABAC）の導入
　　7.3.2 コンテキストベースのアクセス制御（CBAC）に向けて
　　7.3.3 AWS Verified Accessの可能性
　　7.3.4 AWS IAM Roles Anywhereによる柔軟な認証
　7.4 AWS TEAMによる承認ベースの認可設定
　　7.4.1 従来のスイッチロールの課題
　　7.4.2 TEAMのアーキテクチャと動作
　　7.4.3 TEAMの今後

第8章　IAMユーザーゼロへの移行ステップ
　8.1 Step 1: 現状分析と移行計画の策定
　　8.1.1 現状の IAMユーザーの棚卸し
　　8.1.2 利用パターンの分類と分析
　　8.1.3 代替手段の選定
　　8.1.4 移行優先順位の決定
　　8.1.5 タイムラインの設定
　8.2 Step 2: AWS Identity Centerへの移行準備
　　8.2.1 AWS Identity Centerの初期設定
　　8.2.2 IDプロバイダーの選定と連携設定
　　8.2.3 権限セットの設計
　　8.2.4 グループとロールのマッピング設計
　　8.2.5 先行ユーザーによる検証
　8.3 Step 3: プログラムアクセスの移行
　　8.3.1 プログラムアクセスの移行戦略
　8.4 Step 4: 段階的な移行実施
　　8.4.1 開発環境での先行実施
　　8.4.2 パイロットユーザーでの検証
　　8.4.3 グループ単位での順次移行
　　8.4.4 並行運用期間の設定
　　8.4.5 移行完了の確認
　8.5 Step 5: IAMユーザーの無効化と削除
　　8.5.1 アクセスキーの無効化
　　8.5.2 IAMユーザーのログイン無効化
　　8.5.3 一定期間の監視
　　8.5.4 問題がないことの確認
　　8.5.5 IAMユーザーの完全削除
　8.6 緊急時の代替手段の確保
　　8.6.1 緊急時専用アカウントの設定
　　8.6.2 クロスアカウントロールの設定
　　8.6.3 緊急アクセス手段の管理と監査
　8.7 まとめ

第9章　まとめと今後のトレンド
　9.1 IAMの今後の進化予測
　　9.1.1 IAM Identity Centerの今後の展開
　　9.1.2 IAMと AWS Verified Permissionsの連携
　　9.1.3 AWS Verified Accessとコンテキストベースのアクセス制御
　　9.1.4 AIによる IAMポリシーの自動最適化
　9.2 それでも単一アカウントの世界は残る
　　9.2.1 進化の裏で残り続ける「昔ながらの IAM」
　　9.2.2 なぜ「昔ながらの IAM」が残るのか
　　9.2.3 未来と現実のバランス
　9.3 IAM管理者の今後
　　9.3.1 IAM管理者の役割の変化
　　9.3.2 今後の IAM管理者に求められるスキル
　　9.3.3 IAM管理者のキャリアパスと学び
　9.4 まとめ

あとがき
　著者紹介
　既刊一覧

委託本について

当日は、同僚３人が書いた新刊を委託本としても販売しました。前回は、私含めての合同誌として出していたのですが、今回は私抜きの合同誌です。企画から製本まで同僚たちだけで実現していました。なんか成長が見て取れるようで、嬉しい限りです。そのうちに、それぞれが１冊出してみるということにも挑戦してくれることでしょう
「AWS、それぞれの戦い方」 ー認証基盤・ファイアウォール・データ移行との実践記ー

「AWS、それぞれの戦い方」 ー認証基盤・ファイアウォール・データ移行との実践記ー
「AWS、それぞれの戦い方」 ー認証基盤・ファイアウォール・データ移行との実践記ー

techbookfest.org

当日のオフライン会場での売れ行きと考察

　さて、皆さんお待ちかねの売上報告です。今回は事前告知が不十分だったものの、比較的順調な売れ行きでした。全部で264冊売れて、そのうち208冊は新刊です。ほぼ8割が新刊ですね。委託販売も45冊としっかりと売れていたので、安心しました。既刊の動きをみると、もう流石に大きな動きはないものの全部まとめてなどの購入のされ方もあって、並べることの効果はまだまだありそうです。

　今回、新刊1冊＋既刊6冊＋委託本1冊と合計８冊も並べたこともあって、どれを買ったらいいのか悩んでいる人が結構いました。悩んでいる人には、簡単にそれぞれの本の特徴を案内をしていました。これはこれで、ブース出展の醍醐味ではあります。が、もう少し説明書きを増やした方がいいような気がしました。特にIAM本が２冊になったことで混乱に拍車をかけていました。初代IAM本はポリシーと運用設計の話であり、今回のIAM本2025はIAMの組織運用の話です。それぞれ別の目的の本ですよというのが、展示でしっかり解る必要があったかなと思います。


※簡易集計のために、微妙に数字が間違っています

過去開催回との比較と今後の展開の検討

　過去に出展した回の売れ行きと、技術書典全体の来場者数の推移をまとめてみました。新型コロナ前の最後の物理開催回である技術書典7は、1万人近くに人が来場しています。その後に物理開催を再開した14以降は、入場数の制限もあり2千人超の来場者で安定しています。今の自分の技術同人誌のテーマ設定としては、ニッチな部分を深ぼるという方針です。その方針の場合、だいたい会場の5〜8%くらいが興味をもってくれているようです。もちろんテーマによってこの数字は変わると思います。オフライン単体だと、今の冊数くらいが限界だと思うので、次回以降の執筆戦略についても考えていきます。

　一方で、オンライン開催が終わった後に別途ブログを書こうと思いますが、オンライン化のトレンドが花開こうとしているように思えます。オフラインの販売数の伸びに対して、オンラインの伸び率がすごく高いです。これは技術書典の会員数が増えて、会場にこれない人がオンラインで購入する。またSNS等の評判を聞いて、当日買わなかった本をオンラインで買う人が増えているのだと思います。これは、主催者の狙い通りだと思います。凄いなぁと思いつつ、それに向けてサークル主としてはどうすべきかも今後考えていく必要があります。

時間 技術書典7 技術書典14 技術書典15 技術書典17 技術書典18
11:00
151冊
43冊
24冊
42冊
62冊
12:00
94冊
37冊
23冊
43冊
55冊
13:00
82冊
48冊
30冊
37冊
48冊
14:00
43冊
25冊
49冊
28冊
47冊
15:00
45冊
22冊
26冊
28冊
24冊
16:00
36冊
11冊
4冊
17冊
19冊
合計
451冊
186冊
156冊
195冊
264冊
来場者数
9,700人
2,100人
2,200人
2,600人
2,800人

※集計漏れ等もあり、数字が一致しないところがあります（合計値が正しい）

次回に向けての準備

　技術書典への物理出展は、今回で6回目です。わりと手慣れて来ましたが、まだまだ抜け漏れが多いです。今回準備を忘れていた事項を、次回に備えて箇条書きで残しておきます。

  • テーブル背後に設置するポスタースタンド（200cm以内）
  • 新刊があることを強調して告知する方法
  • 商品の選択ガイド

まとめ

　今回は、会社の同僚たちだけで新刊を出した＆自分も新刊を出せたということで、かなり大成功だったと思います。自分の新刊については、もっと早く書いて早割を活用したかったのですが、そこは無理でした。また、Cursor（AIを活用したエディタ）を始めて導入し、だいぶサポートのされ方もわかってきました。47歳になっても少しづつ成長できているということを信じて、今後とも頑張っていきたいものです。

　ということで、新刊『AWSの薄い本６　IAMのマニアックな話　2025』をよろしくお願いします。2025年6月15日まで、技術書典オンラインで物理本+電子版を送料無料で購入できます！！また、BOOTHでも販売中です。

techbookfest.org

takuros.booth.pm