#技術書典 20オフラインに出展してきました。売上報告と新刊「AWSの薄い本8 AWS Organizationsと愉快な仲間たち」と「エンジニアとお金」

　2026年4月12日、池袋サンシャインシティで開催された技術書典20のオフライン会場にブース出展してきました。今回は、新刊の『エンジニアとお金』と『AWSの薄い本8 AWS Organizationsと愉快な仲間たち』の2冊に加えて、これまでの「AWSの薄い本」シリーズ＋会社の同僚が書いた本の委託販売含めて、合計10冊を並べての参加です。

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

新刊『エンジニアとお金』について

　今回の新刊の1冊目は、『エンジニアとお金』です。
この本に関して言うと、SNSを見て来ましたという声が非常に多かったです。そのうえで、内容をじっくり見て買って頂いた方が多かったです。今まで技術書典ではAWSの人と認知されてきたので、新境地を開くキッカケになれればと幸いです。

『エンジニアとお金』の内容

　本書の内容は、次のようなものです。
「転職したら、いくら上がりますか？」エンジニア同士でお金の話になると、会話はたいていこの問いに収束します。でも、「給料が止まったら何カ月もつ？」「収入が一本しかないことを、どう考えている？」になると、急に会話が止まりませんか？

　エンジニアはシステムの単一障害点を嫌います。冗長化も監視も当たり前。なのに、自分の収入が一つしかないことには、なぜか無頓着でいられてしまう。本書は、その違和感から始まった一冊です。

　NISAの始め方でも副業ノウハウでもなく、エンジニアがお金を扱うときに持っておきたい「構造」の話を書きました。収入をどう分解して見るか、給料という仕組みの強さと上限、給料以外の収入を小さく持つと何が変わるのか。20年以上のエンジニア経験の中で得た成功談も失敗談も、FXで100万円近くを失った話やブログの流入が検索エンジンのアップデートで吹き飛んだ話なども正直に書いています。

本書では、

• 第1章　数十円が、収入観を変えた
• 第2章　給料は強い。だから、外への一歩が踏み出せる
• 第3章　給料以外で稼ぐと、世界の解像度が上がる
• 第4章　差は、どこで広がるのか
• 第5章　エンジニアの複利設計（技術・英語・発信・資産形成）
• 第6章　次の1年を設計する（3つのモデルケース付き）

という構成で、入社3〜10年目くらいの会社員エンジニアを中心に、30代・40代で「そろそろ働き方やお金のことをちゃんと考えたい」という方に向けて書いています。第6章には「28歳バックエンドエンジニア」「35歳・育児中のSRE」「42歳テックリード」の3つのモデルケースを用意していて、読後すぐに自分の1年を設計できる構成になっています。

techbookfest.org

ハッシュタグは、#エンジニアとお金 です

新刊『AWSの薄い本8 AWS Organizationsと愉快な仲間たち』について

　新刊の2冊目は、『AWSの薄い本8 AWS Organizationsと愉快な仲間たち』です。こっちはシリーズものなので、ノールックで買って頂いている方も多かったです。ありがたい限りです。

『AWSの薄い本8 AWS Organizationsと愉快な仲間たち』の内容について

　AWSの薄い本シリーズ第8弾で、AWS Organizationsを中心に「マルチアカウント時代のAWSを、組織としてどう運用するか」を整理した設計思想の本です。設定手順書ではなく、設定の前に持っておくべき判断軸を渡すことを目的にしています。

　多くの現場で起きているのは、Identity Center、SCP、Config、GuardDuty、Security Hub、Control Towerといった個々のサービスは知っているのに、全体像がつながっていないという状態です。本書ではOrganizationsを「組織の責任分界を技術で実装する設計の骨組み」として捉え直し、各サービスがその骨組みの上でどう役割分担するかを整理しました。

本書では、

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

という全9章の構成で、技術だけでなく、CCoE・情シス・事業部の役割分担や権限委譲の設計など、組織設計としてのAWS運用も正面から扱っています。2024年末にGAしたRCP（リソースコントロールポリシー）や宣言型ポリシーなど、新しいポリシータイプもカバーしています。

　情シス、CCoE、基盤チーム、セキュリティ担当の方はもちろん、「アカウント数が増えてきたけど全体設計が追いついていない」という現場の方に読んでいただきたい一冊です。シリーズとしては、『IAMのマニアックな話』『アカウントセキュリティのベーシックセオリー』の流れを受ける「マルチアカウントと統制編」という位置づけになります。
　一点反省点としては、今回画像をHTMLベースで作るようにしたのですが、印刷すると思った以上に色合いが薄く見づらかったです。少なくとも電子版の方は改善しようと思いますので、少々お待ちください

techbookfest.org

ハッシュタグは、#AWSの薄い本 です

技術書典20 初動の売上速報

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

2日間+13日午前の技術書典での状況

• 合計：469冊
• オンライン販売：193冊
• オフライン会場（技術書典20当日）：276冊

　オフライン会場だけで276冊と、前回の技術書典19（212冊）を大きく上回る結果となりました。新刊を2冊出せたことが大きかったと思います。オンラインも193冊と、会場に来られなかった方にもしっかり届いている感覚があります。

新刊『エンジニアとお金』の動き

• オンライン：106冊
• 会場：101冊
• 合計：207冊

　初動で207冊と、今回の最大のヒットになりました。オンライン初日だけで40冊、会場当日は会場101冊＋オンライン54冊と、オフライン・オンラインの両方で万遍なく動いてくれています。テーマがAWSに限らず多くのエンジニアに刺さる内容だったことが、この数字に表れているのかなと思います。

新刊『AWSの薄い本8 AWS Organizationsと愉快な仲間たち』の動き

• オンライン：58冊
• 会場：80冊
• 合計：138冊

　もう一つの新刊も初動で138冊と、しっかりとしたスタートを切れました。オンライン初日に27冊、会場当日は会場80冊＋オンライン24冊という内訳です。Organizations周りは実務で悩んでいる方が多いようで、会場でも「まさにこれが欲しかった」という声をいただきました。

既刊の動き

　既刊についても、ざっくり数字を出しておきます。

• ① IAM初代本：6冊（全て会場）
• ② アカウントセキュリティ本：5冊（オンライン1／会場4）
• ③ データ分析基盤設計本：5冊（会場5）
• ④ 昔話本：4冊（全て会場）
• ⑤ データ分析基盤性能本：3冊（全て会場）
• ⑥ IAMのマニアックな話 2025：26冊（オンライン6／会場20）
• ⑦ S3本：19冊（オンライン1／会場18）
• ⑩よもやま話：54冊（オンライン19／会場35）

　新刊をきっかけに「せっかくだからIAM本も」「Organizationsと合わせてIAM2025も」という形で、既刊も合計68冊（よもやま話・合本除く）動いてくれました。特にIAM2025とS3本が前回に続いて堅調で、シリーズとして定着してきた感があります。

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

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

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

　会場での販売冊数276冊は、コロナ以降の技術書典では過去最高となりました。11時台・14時台に特に集中しており、14時台に52冊というのは午後の時間帯としてはかなり多い数字です。新刊2冊体制の効果が大きかったと感じています。
　ちなみに会場で10時代で売れているのは、他のサークル主さんが一般のお客様が来場される前に買いに来ていただいているからです。沢山の人に来ていただいて、ありがたい限りです。

次回以降に向けてのメモ

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

• 既刊が増えてきたので、展示の仕方を見直す。今回は11冊体制で、机の上のスペースがかなり厳しくなってきた。全冊を平置きで並べるのは物理的に限界があるので、立体的に見せる工夫や、シリーズごとにまとめて配置するなど、見せ方を考える必要がある
• 今回ポスタースタンドを購入した（4/13到着。。。）ので、次回はこれをもっとうまく活用したい。遠くからでもブースの存在に気づいてもらえるように、新刊の表紙やシリーズ一覧を大きく掲示するなど、机上の展示と組み合わせた使い方を検討する

まとめ — 新刊2冊、引き続きよろしくお願いします

　ということで、技術書典20の初動の売上速報と、新刊2冊の紹介でした。
Organizations周りで悩んでいる方、エンジニアとしてお金の話を整理しておきたい方、あるいは「AWSの薄い本シリーズをコンプリートしたい」という方に、ぜひ手にとってもらえれば嬉しいです。
　技術書典オンラインの会期中は、物理本＋PDF版のセットをオンラインでそのまま購入できますし、BOOTHの頒布も開始しています。

booth.pm

booth.pm

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

技術書典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もまた、才能ではなく運用の話だという実感を得た取り組みでした。
　ただ、こんな事をしなくても、感覚で簡単にやっちゃう凄い人も多いと思います。自分はそういう風にはできないので、仕組みで淡々とやっていく方を選びました。

オチ

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