技術書典20に新刊2冊出します！！「エンジニアとお金」と「AWSの薄い本8 AWS Organizationsと愉快な仲間たち」

新刊2冊のお知らせ　「AWS Organizationsと愉快な仲間たち」と「エンジニアとお金」

技術書典20に向けて、技術同人誌の新刊を2冊執筆しました。ジャンルはまったく違うのですが、どちらも長年暖めていたテーマです。本記事では、それぞれの内容と狙いを紹介させてください。

1冊目：AWSの薄い本８『AWS Organizationsと愉快な仲間たち』

おなじみ「AWSの薄い本」シリーズの第8弾です。今回のテーマは AWS Organizations。ただし、よくある「機能紹介本」ではありません。

techbookfest.org

この本の位置づけ

本書は、AWS Organizationsそのものの設定手順を解説する本ではありません。Control TowerやSecurity Hubといった周辺サービスを、個別に設定解説する本でもありません。

AWS Organizationsは、単なるアカウント管理サービスではありません。
マルチアカウント時代において、権限分離と責任分界を形にするための、組織設計そのものです。

これが本書の中心メッセージです。つまり、本書が扱うのは設定手順ではなく設計思想と組織設計です。ちなみにAWSの薄い本3として、AWS Organizationsを出すつもりだったのですが、ずいぶんと回り道したものです。また、設定手順など一切ないので、当初の構想とは全く違うものになりました。これは、自分が向き合っているものの変化が、テーマの変化につながったのかと思います

取り扱うテーマ

具体的には、次のようなテーマを整理しています。

• 権限委譲の境界
• セキュリティ統制の責任分界
• 情シス / CCoE / 事業部の役割分担
• AWSアカウントの分割方針とOUの切り方
• IAM Identity Center、SCP、Config、Security Hub、GuardDuty、CloudTrail、Control Towerの役割分担
• 自社にとって現実的な導入順序

「Security Hubも、GuardDutyも、Configも、とりあえず全部有効化したから安心」と思っていたら、全然そんなことは無かった。そんな経験ありませんか？こうした状況が何で発生するのか、そして何をすればいいのか。そのために、何のためにどのサービスを入れるのかを整理し直すことを目的としています。

想定読者

直接の想定読者は、情シス、CCoE、基盤チーム、セキュリティ担当の方々です。また、それらの人たちが設計思想を共有するために、現場へ配る本としても位置づけています。

特に、すでに複数のAWSアカウントを運用しているのに、全体設計や責任分界、サービスの役割分担が整理しきれていない組織を主な対象としています。

目次

章	タイトル
第1章	なぜAWS Organizationsが肝になるのか
第2章	組織としてAWSを管理するとは何か
第3章	アカウント分割とOU設計の原則
第4章	IAM Identity Centerで権限をどう渡すか
第5章	AWS Organizationsのポリシーで統制を設計する
第6章	セキュリティサービスを"入れる"だけでは回らない
第7章	管理アカウントに集めすぎないための設計
第8章	コストを組織として管理する
第9章	AWS Control Towerと現実的な導入順序

前著との関係

本書は、シリーズとしては以下の流れを受ける位置づけです。

• 『AWSの薄い本　IAMのマニアックな話』
• 『AWSの薄い本Ⅱ　アカウントセキュリティのベーシックセオリー』
• 『AWSの薄い本６　IAMのマニアックな話2025』

前著がIAMやアカウントセキュリティを「アカウント単位」で扱っていたのに対し、本書はそれらを一段引いた視点から再配置し、「マルチアカウントと統制編」として全体像をつなぎ直す役割を担います。前著を読んでいるとより深く理解できる構成ですが、本書単体でも読めるようにしています。

読み終えた頃には、IAM Identity Center / SCP / Config / Security Hub などの役割分担が整理でき、自社にとって現実的な導入順序とOU設計の方向性を自分で描けるようになる。そんな到達点を目指しています。

2冊目：『エンジニアとお金』

もう1冊は、まったく毛色の違う本です。実はこれ、技術書ではありません。対象読者はエンジニアですが、テーマは「お金」です。

techbookfest.org

この本でやらないこと

いわゆる一般的なお金の本で扱っている内容は、一切扱っていません。

• 儲かる投資手法の紹介
• 副業・不動産・株式などの具体的な攻略法
• 成功体験の再現を煽る話
• 「これをやれば正解」という結論づけ

How to 本ではないので、「これを買えばいい」「この副業が稼げる」といった話は一切出てきません。この辺りの話が聞きたければ、どこかで飲みながら話しましょう。

この本でやること

代わりに本書がやるのは、次のような整理です。

• 収入を「性質・仕組み・時間・再現性」で整理する
• 給料一本足の構造と、その前提条件を言語化する
• 人生と収入を「同時に設計する」という考え方を示す
• 行動につながる最小単位（年次設計）を提示する

言い換えると、お金を「儲け方」ではなく「設計対象」として捉え直す本です。答えを渡すのではなく、考え続けられる設計思想を渡すことを目的にしています。エンジニアがシステムを設計するときの思考様式を、そのまま自分の収入に向けてみる。そういうイメージです。

想定読者

• 20代〜30代のエンジニアをメイン。それ以上の年齢の人にも示唆を与えられる内容
• 給料以外の収入に興味はあるが、何から考えればいいか分からない人
• 投資や副業の情報に触れて、かえって混乱している人
• 将来に不安はあるが、危ないことはしたくない人

特に最後の「将来に不安はあるが、危ないことはしたくない」。これは私自身の生き方でした。本やネットの情報は「一歩踏み出せ」と煽るものが多くて、かえって動けなくなる。本書はその逆で、読者を責めない・煽らないことを基本方針にしています。

構成

章	テーマ
第1章	なぜエンジニアはお金を考えてこなかったのか
第2章	給料は強い──給料一本足が持つ構造的な前提
第3章	給料以外で稼いだ体験がもたらす視点の変化
第4章	同じ金額でも、たどり着き方が違う理由
第5章	収入を複利で設計する
第6章	来年の自分を設計する

最後の章では、「年次で収入を設計する」という行動レベルの話に落とし込みます。読み終えたあと、翌年の自分の収入と時間の使い方を、自分の言葉で設計し直せるようになる。それが本書のゴールです。

2冊に共通していること

ジャンルはまったく違いますが、2冊には共通するスタンスがあります。

• How toではなく、設計思想を渡す
• 全体像を俯瞰して、役割と構造で整理する
• 現実解に落とす。理想論で終わらせない

『AWS Organizationsと愉快な仲間たち』は、AWSのアカウントや権限やセキュリティサービスを組織として
設計する本です。そして、『エンジニアとお金』は、収入や時間や人生をエンジニア的に設計する本です。

扱う対象が「会社のAWS環境」か「自分の人生」かの違いだけで、全体像を俯瞰して構造で整理するという姿勢は、実はまったく同じなのです。

頒布情報

どちらも技術書典20向けに準備中です。当日はオフラインブースでも頒布予定なので、お立ち寄りいただけると嬉しいです。電子版については、技術書典のマーケットおよびBOOTHでの頒布を予定しています。

感想やツッコミは X（旧Twitter） @dkfj までいただけると、著者としては非常に喜びます。それでは当日、会場でお会いしましょう。それぞれ、タグはAWSの薄い本とエンジニアとお金でお願いします

takuros.booth.pm

takuros.booth.pm

S3 20周年、あの日の「よくわからなさ」を思い出す

S3 20周年の日に、20年前の自分を思い出す

Amazon S3が正式にローンチされたのは2006年3月14日です。今日でちょうど20周年になります。おめでとうございます。

改めて20周年と聞くと、とんでもない長さです。S3が誕生した日に生まれた人は、もう20歳です。私の中ではクラウドはいまだに「比較的新しい技術」という感覚がありますが、今の若い世代にとっては、物心ついたころから当たり前に存在していたものなのだと気づかされます。

　S3は、クラウドの歴史を語るうえで外せない存在です。ですが、少なくとも20年前の私は、そんな偉大な一歩とは全く認識していなかったです。正直に言えば、「Amazonがまた何か変なことを始めたな」くらいの感覚でした。

最初に見えていたのは、壮大な未来ではなく、ただの「わからなさ」だった

私は2006年3月30日に触っていたようで、当時のメモがブログの記事として残っています。そこにあるのは凄いものが出たという驚きではなく、何なのか理解できず試行錯誤する戸惑いでした。

blog.takuros.net

思い立ってAmazon S3に申し込んでみる。サンプルアプリを触ってみる。PEARのライブラリを入れる。ReadMeを読む。エラーが出る。BucketとKeyが何を指すのかわからない。マニュアルを読む。そういう、ごく手探りの記録です。

当時の私が最初につまずいたのは「Bucketとは何か」でした。マニュアルを読んで「表領域みたいなものか」と理解したあたりに時代を感じます。オンプレのデータベースが一番身近なインフラだった時代、新しい概念を既存の知識で理解しようとする。今思えば、当然の反応でした。

さらに言えば、サンプルアプリにはBucketを作る機能すらなく、SOAPかRESTでPUTするところから始めないといけないという状態。HTTP_Requestライブラリのバグに遭遇し（果たして本当にライブラリのバグだったのか、自分の使い方が間違っていたのか、今となってはわかりません）、日本のサーバからアクセスしたらDateヘッダの問題で認証エラー。USのサーバに移してもAccess Denied。今なら「aws s3 mb」の一行で済むことに、どれだけの時間を費やしたか。

でも、あの「わからなさ」こそが、新しい時代の入り口の風景だったのだと思います。

Bucketの名前空間が変わった日に

20年前の私を困らせたBucketの仕組みについて、ちょうど20周年の直前に大きなアップデートがありました。S3にアカウントリージョナル名前空間が導入されたのです。

これまでS3のBucket名はグローバルに一意である必要がありました。全ユーザーで名前空間を共有しているため、「test」のような単純な名前は早い者勝ちで取られてしまう。私も20年前のブログで「どうやらbucket名はAmazon S3ユーザ間で共有されているようだ」と書いていました。

新しい名前空間では、アカウントIDとリージョンをサフィックスとして付与することで、自分のアカウント内で自由にBucket名を決められるようになります。なお、サフィックスが付与されることで、Bucket名がグローバルで一意であるという性質自体は維持されています。あくまで「名前の衝突を気にせず、好きなプレフィックスでBucketを作れるようになった」というのが今回の変更の本質です。

今にして思えば、最初からグローバルに一意という制約を課したのは、S3にとってとてつもないメリットだったと思います。もし最初からアカウント単位で一意という設計にしていたら、アカウント間のデータ共有やバケットの移行、クロスアカウントアクセスなど、後々多くの問題を引き起こしていたはずです。20年後の今に至るまでS3がクラウドの基幹であり続けている背景には、こうした初期設計の強さもあったのではないかと思います。そのうえで、マルチアカウント運用が当たり前になった時代に合わせて、名前の衝突を気にせず使える選択肢を追加した。20年越しの、良いアップデートだと思います。

20年分の「当たり前」

2006年当時、S3はRESTとSOAPのAPIでのみアクセスできる、シンプルなオブジェクトストレージでした。それが今やS3は350兆を超えるオブジェクトを格納し、毎秒1億回以上のリクエストを処理する巨大なインフラになっています。

でも、S3単体の成長よりも重要なのは、S3がきっかけとなって「クラウド」という概念そのものが形づくられていったことだと思います。S3のローンチから5ヶ月後の2006年8月にEC2が登場し、「ストレージだけでなくコンピューティングもクラウドで」という世界が始まりました。S3はその基幹として、クラウドのあらゆるサービスの土台であり続けています。

2006年当時、自分のデータを、自分のサーバではなく、インターネットの向こう側にある誰かのサーバに預けるという発想自体が突飛なものでした。当時のエンジニアの多くは、これを自分の仕事で使うものとは考えていなかったと思います。

潮目が変わったのは2009年前後だったと記憶しています。VPCが登場してネットワークの分離が可能になり、エンタープライズでの利用が現実味を帯び始めました。そこから先の展開は加速度的です。2012年のDynamoDB、2014年のLambda。サーバレスという概念が生まれ、「サーバを意識しないインフラ」が現実になりました。そしてここ数年は生成AIの波が押し寄せ、Bedrockを通じてクラウドはAIの実行基盤そのものになっています。

振り返ると、この20年間でクラウドは「インフラの持ち方そのもの」を変えてしまいました。データセンターにラックを並べ、ハードウェアを調達し、OSをインストールするところから始まっていたあの時代。今の若いエンジニアには想像しづらいかもしれませんが、サーバを1台増やすのに稟議を通して発注して届くまで数週間かかるのが普通でした。それが今では、コンソールを数クリックするか、コマンドを一行叩けば、世界中のどこにでもインフラが立ち上がる。

この変化の起点にS3があった。最初の一歩は「インターネット越しにファイルを置ける」という、ただそれだけのサービスでした。でも、その「ただそれだけ」が、インフラに対する私たちの常識を根底から書き換えていったのです。

おわりに

20年という時間は、技術を「新しいもの」から「当たり前のもの」に変えるのに十分な長さでした。S3はその筆頭です。

私はこの20年間、AWSとともに歩んできたと言っても過言ではありません。BucketとKeyの概念がわからなかった初心者が、今ではAWS IAMのマニアックな話を本に書いています。そう考えると、クラウドの歴史は、私自身のエンジニアとしての歴史でもあるのです。

こうして20年を振り返ると、S3は単なるストレージサービスではなく、クラウドそのものの歴史を開いた存在だったのだと改めて感じます。そのS3の内部構造や設計思想を、もう少し深く掘り下げて書いたのがこちらの一冊です。

booth.pm

また、クラウドの歴史に思いを馳せると、いま当たり前に見えるサービスも、長い試行錯誤の積み重ねで形づくられてきたと感じます。その歩みを敬意を込めてたどった一冊もあります。

booth.pm

S3、20周年おめでとうございます。そしてこれからも、クラウドという「当たり前」の土台を支え続けてください。
なお、最後に一言付け加えるとすると、SQSは2004年にAmazon Mechanical Turkは2005年に出ております。そちらにも思いを馳せてあげてください。

AWSの薄い本シリーズのセット販売のお知らせ

BOOTHのセット販売を大幅拡充しました！AWS本まとめ買いがさらにお得に

こんにちは、佐々木（@dkfj）です。

突然ですが、みなさんは技術書をまとめ買いしたいと思ったことはありませんか？「どうせなら関連する本をセットで揃えたい」「バラで買うより少しお得になればうれしい」

そんな声にお応えして、BOOTHのセット販売のラインナップを大幅に増やしました！

今回用意したセットは全部で5種類。IAMやセキュリティ、S3まわりの本を、テーマ別にまとめてお得な価格でご提供しています。物理本＋ダウンロード版がセットになっているのもポイントで、手元に置いておける紙の本と、検索しやすいPDFの両方が手に入ります。まとめて発送できるので、送料もお得になっています。

それでは、それぞれのセットを詳しく紹介していきます。

📦 全巻セット（7冊）

booth.pm

「どうせなら全部揃えたい！」という方には、全7巻セットがいちばんお得です。定価合計9,000円のところ、6,950円と約23%OFF。2,000円以上お得になります。

IAMからセキュリティ、S3・データ分析基盤まで、私が書いてきた本をまるごと手に入れられるセットです。AWSを幅広く深く学びたい方、とりあえず全部読んでみたいという方にはこれが一番のおすすめです。

📦 セキュリティセット（3冊）・3,510円（約2割引）

収録タイトル：

• IAMのマニアックな話
• アカウントセキュリティのベーシックセオリー
• IAMのマニアックな話2025

booth.pm

AWSのセキュリティをちゃんとやろうと思ったとき、どこから手をつければいいか迷いませんか？このセットは、そのあたりの悩みをまるっと解消できるように3冊を選びました。

「アカウントセキュリティのベーシックセオリー」でまず全体像と基本的な考え方を押さえて、「IAMのマニアックな話」「IAMのマニアックな話2025」でIAMの深いところまで掘り下げていく、という読み方ができます。設計の考え方から実際の設定まで、カバー範囲がかなり広いのがこのセットの強みです。

「セキュリティは大事だとわかってるけど、何から始めればいいかわからない」という方にも、「IAMはある程度わかるけど、もっと深掘りしたい」という方にも、どちらにも刺さる内容になっていると思います。

📦 ストレージセット（3冊）・2,700円（約2割引）

収録タイトル：

• S3の深淵
• データ分析基盤を作ってみよう 設計編
• データ分析基盤を作ってみよう 性能測定編

booth.pm

「S3ってとりあえず使えてるけど、ちゃんとわかってるかというと……」という方、けっこう多いんじゃないでしょうか。このセットは、S3を本当の意味で使いこなすための3冊です。

「S3の深淵」でS3の機能や挙動を深く理解したうえで、データ分析基盤の設計・性能測定へと進んでいく流れになっています。3冊読み終えるころには、「データ分析基盤を自分で設計できる人」になれるはず、というのが目指したゴールです。実務でS3をよく使っている方、これからデータ基盤を作ろうとしている方には特におすすめです。

📦 IAMセット（2冊）・2,350円（約2割引）

収録タイトル：

• IAMのマニアックな話
• IAMのマニアックな話2025

booth.pm

自分で言うのもなんですが、日本でIAMだけに特化した技術同人誌を継続的に出しているのは、たぶん私だけだと思っています（笑）。そのIAM専門誌が2冊まとめて手に入るのがこのセットです。

IAMポリシーの書き方、権限設計のパターン、よくやりがちなミスとその回避方法など、IAMに関するマニアックな内容をギュッと詰め込んでいます。「IAMは奥が深くて好き」「ポリシー設計を突き詰めたい」という方には、間違いなく刺さる内容です。IAMマニア、ぜひどうぞ。

📦 ベーシックセキュリティセット（2冊）・2,300円（約2割引）

収録タイトル：

• IAMのマニアックな話
• アカウントセキュリティのベーシックセオリー

booth.pm

「まずAWSのセキュリティの基本をしっかり固めたい」という方向けのセットです。

「アカウントセキュリティのベーシックセオリー」でAWSアカウント全体のセキュリティ設計の考え方を学んで、「IAMのマニアックな話」でIAMの権限管理を深く理解する——この2冊を読めば、AWSアカウントセキュリティの基礎はひととおりマスターできます。セキュリティの勉強を始めたばかりの方にも、体系的に学び直したい方にもちょうどいいセットだと思います。

丁寧に梱包してお届けします

物理本の発送については、自宅から1セットずつ手作業で梱包してお送りしています。今回セットのバリエーションが増えたので、誤配が起きないよう、これまで以上に気をつけて対応していきます。

個人での発送なので大量注文への即日対応などは難しいこともありますが、丁寧にお届けすることだけは約束します。何かご不明な点があれば、BOOTHのメッセージや Twitter（@dkfj） でお気軽にどうぞ。

まとめ

セット名	冊数	セット価格	こんな人に
全巻セット	7冊	6,950円（約23%OFF）	とにかく全部揃えたい人
セキュリティセット	3冊	3,510円（約2割引）	セキュリティを幅広くカバーしたい人
ストレージセット	3冊	2,700円（約2割引）	S3・データ基盤を深く理解したい人
IAMセット	2冊	2,350円（約2割引）	IAMをとことん極めたい人
ベーシックセキュリティセット	2冊	2,300円（約2割引）	AWSセキュリティの基礎を固めたい人

いずれも定価からおよそ2割引きで、物理本とダウンロード版の両方が手に入ります。バラで揃えるよりまとめてお得に、というのがセットの一番のメリットです。気になるセットがあれば、ぜひ覗いてみてください！

それでは、引き続きよろしくお願いします 🙏

技術同人誌の著者は、なぜ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月号

　キッカケは編集者の方から、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