プログラマでありたい

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

技術者であることを諦めない

 だいぶ前にAWSのAmbassadorが集まっての懇親会がありました。年齢の話になって聞いていると、どうやら私が最年長グループでした。最年長!!おっさんです。私は42歳で、役割的な部分を考えれば、そうなるのも無理はないのかなという気がします。せっかくなので、ポエムっぽいブログエントリーを残しておきます。

SIerの中での技術者の生き方

 技術者と書くのがよいのか、ITエンジニアと書くのがよいのかイマイチ解りませんが、ここでの技術者は、下記のように定義しておきます
※あくまでこの文脈の中だけの定義です。

  • 主たる業務に対して、自身のもつITの技能・知識を持って業務を遂行している
  • 業務で必要とされる技術の変化に追随しつづけている

 ここで重要なのが2つ目の技術の変化に対して追随し続けるという点です。一口にSIerといっても対象とする業種や業態によって必要とする技術は大きく違います。業務知識がとにかく重要でそれを実装する技術については十年一昔はなんのその、COBOLで作られた数十年もののシステムが今日も元気に動き続けるところもあれば、クラウド業界のように日々新しいサービスがでてくるといった業界もあります。大切なのは、まずは仕事を遂行する上での技術力を得ることだと思います。一方で、今の仕事がどれくらい続くのか、今働いている会社がなくなったとして、同様の給料を維持できるのかも考える必要があるのが辛いところです。

 また経験を重ねて昇進していくと、通常であれば給与がアップしていきます。会社視点で考えると、その分に見合ったアウトプットを期待されることなります。1日の時間は限られているので、アウトプットを増やすには単位時間あたりの生産性を高めるしかありません。例えば若手の時のアウトプットが設計やコーディングなど直接的なコードがアウトプットが中心だとして、給料が2倍・3倍となった時に生産性も2倍・3倍に出来るかという問題に直面します。一部では2倍・3倍の生産性を実現する人もいますが、大半の人は標準レベルの人に対して数倍の生産性は発揮できません。そのため、他の付加価値をあげる方法にシフトしていく事になります。
 その一つが技術者が嫌がるマネジメントですね。個人としては数倍の生産性を出せなくても、チームとして活動し個人の数倍のアウトプットを出すことは可能です。そのチームを率いるリーダーは、それだけ分の付加価値を出しているのと等しくなります。ということで、一定の年次にいくとマネジメントが主要業務になることが多くなります。
 一方で、マネジメントスキルだけを伸ばしていけば、それで大丈夫かというとそうでもないのが難しいところです。10年に一度ほど、或いはもっと短い期間で断続的にゲームチェンジを強いられる革新が発生しつづけています。そういった局面で、従来のやり方で良いのかという問題が発生します。大きな会社であれば、その辺りの手法を標準化してマネジメントレベルまで落とし込むのかもしれないですが、多くの会社はマネジメント層自体が自身で対応を考えていく必要があります。そうなると、やっぱりIT業界にいる限り、マネジメント層にも技術には無縁ではいられなくなります。

時間が無い中での技術との関わり方

 じゃぁ、常に技術力をアップデートし続けないといけないとして、どうやってそれを身につけるのか。日々の業務や研修などを通じる方法と、自己研鑽の2種類があると思います。前者は所属する組織によって状況は大きく異ると思うので、後者の自己研鑽にフォーカスしようと思います。自己研鑽するにしても、時間が限られています。自由に使える時間は個人差がありますが、30〜50代くらいでは結婚や子育てなどの時期とかぶることが多いでしょう。そうなると、その貴重な時間をどこに振るかが重要になります。
 個人的なおすすめとしては、今持っている自分の専門の隣接領域が良いと思っています。単一の専門性だと100メートル走の世界と同じで、その先にもっともっと凄い人がいます。なので、勝手に複数の領域を組み合わせて、ベクトルとして合成できるようにするのです。このあたり、だいぶ昔のスライドですが、説明しているので見てみてください。

www.slideshare.net

 大切なのは、積み重ねになる領域を選ぶことです。自分より数倍頭の回転が早い新人は現れる可能性はありますが、インフラ経験10年とかアプリ開発歴20年の新人は(たぶん)現れません。経験の積み重ねを活かせる方向に技術をアップデートしていきましょう。

まとめ

 長くなったので、もう1回くらいに分割して書きます。とにかくおっさんになっても、マネージャーになっても技術者であることは諦めないでねという思いです。たとえ、スーパーカーみたいな若者が一杯台頭してきても、経験を活かして生き残る戦略を考えながら頑張りましょう。続きは、また次回。

2020年4月3日追記:
続き書きました
blog.takuros.net

技術本の著者からみた商業誌と同人誌の違い

 先日リリースした『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』は同人誌として2冊目になります。また今回は、サークル主として他のメンバー3冊の企画作りを少し手伝わせて貰いました。なので、何となく同人誌の世界も解ってきたと言っても良いような気がするので、すこしエラそうかもしれませんが、技術本の著者から見た商業誌と同人誌の違いを述べさせて貰います。

f:id:dkfj:20200323084651j:plain

執筆時間

 まず商業誌である『Amazon Web Services 業務システム設計・移行ガイド』は、384ページです。これに対して『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』は104ページです。ページ数にすると。3.7倍の違いがあります。が、実は文字数ベースでいうと、もう少し大きな開きがあります。27万字と6万字で、4.5倍と差が開きます。
 これは、同人誌フォーマットが紙のサイズもA5と小さく、文字が大きめというのが一般的だからです。もちろん商業誌でもジャンルによっては、同じような傾向のものもありますが、一般的には1ページあたりのボリュームは商業誌の方が多いです。
 そしてここからは執筆の累計時間から1ページの生産性を求めてみましょう。厳密に測っていないし、商業誌の方は分担して書いたという違いはありますが、自分ひとりで書いたと仮定するとだいたいこんな感じだったと思います。

業務システム設計・移行ガイド: 500時間
アカウントセキュリティ本:   60時間

 執筆時間は個人差が多く、私は割と執筆が早いほうです。人によっては、2倍3倍の時間が掛かることもあると思います。また、純粋に原稿に向かい合ってる時間なので、それ以外の構想とか検討、執筆後の校正の時間とかも入れていません。

印税率

 そして、ここからが下世話ながらみんな気になる印税の話です。商業誌の印税率は、会社や本のジャンルごとによって違います。パターンとして多いのが8%なので、そこで計算することにします。著者に入ってくる印税は、刷り数×書籍価格×印税率になります。初版の刷り数は、これもケースバイケースですが、3,000部とします。(最近は、これより少ないケースの方が多いようですが。)そうすると、書籍代を3,500円とした場合に著者に入ってくる印税は次のようになります。

 3,000(冊)× 3,500(円) × 0.08 = 84万円

 対する同人誌です。ここはBOOTHという破壊的なプラットフォームがあるので、このBOOTHで印刷原価が掛からない電子書籍を前提とします。BOOTHの何が破壊的かというと、印税率ではなく単に販売手数料を取るというモデルなのです。そして、その手数料がたったの3%程度。つまり97%と殆どが著者の取り分となります。売上の計算に、書籍代を1,000円で100部売れたと仮定します。この100部は、技術書典7の平均頒布数が133冊から導出しました。技術書典というお祭りという特殊要因を抜いても、テーマ選定とマーケティングをしっかりすると、100部という数字は非現実な数字ではないです。

 100(冊) × 1,000(円) × 0.97 = 9万7千円

この数字に執筆時間で割って、時間給を出してみましょう。

商業誌:840,000 ÷ 500 = 1,680円
同人誌: 97,000 ÷ 60 = 1,616円

 ほとんど同じになりますね。そして、あまり割が良いものでもありません。では、それぞれヒットしたらどうなるでしょう?技術書の商業誌だと1万部売れたらまずまず大人気といえます。また同人誌だと500冊かなと思います。それぞれ売上を出した上で、時給を出してみましょう。

商業誌:280万円 ÷ 500 = 5,600円
同人誌:48万5千円 ÷ 60 = 8,083円

 ここまでくると、時間辺りの単価としてはそれなりになります。が、エンジニアとして普通に働いているのと、それほど変わらないような気もします。で、私の場合はどうだったかというと、商業誌だと1万冊とか2万冊売れているのが幾つかありますし、同人誌の場合は前作が1,500円で1,500冊以上売れています。商業誌で1万部売るのと同人誌で500部売るのだったら、同人誌の方がハードル低いかなと思います。簡単単純な利益を追求するのであれば、私の場合は同人誌の方が今は実入りが良いというのが現状です。

企画

 刷り数を踏まえた上で、じゃあ同人誌と商業誌は企画段階で何が違うのかという点です。これははっきりしていて、商業誌は出版社も利益を出さないといけないので、最低3,000部売れる、そして1万冊くらいは狙えるテーマを選ぶ必要があります。そうすると、世の中のニーズ的には10万人以上の潜在的な市場がある世界です。10万人となると、それなりにビックなテーマで、必然的に競合が多くなります。これに対して、同人誌は100冊売れれば充分なので、ニッチなテーマを選べます。この違いは大きいです。
 大きな市場という意味だと、必然的には初級・入門的な内容になります。何故ならば、初級者より中級者・上級者が多い市場というのは、一般的には存在しないからです。逆に、同人誌は100部で良いので市場の大きさより競合の少なさの方が重要になります。そうすると、テーマの多様性が増え、中級・上級向けの本も多数でてきています。

この辺り、5年前くらいに考えていたようで、物理本の制約がなくなればと思っておりました。現実は、そっちに向かっているのかもしれませんね。
blog.takuros.net

編集者

 じゃぁ単純に同人誌(個人出版)が今後増えてくるのかというと、そうでもないでしょう。商業出版では基本的に編集者が付きます。この編集者の役割というのは、やはり大きいと思います。著者という存在は、そのテーマにおいてはそれなりの知識を有しているものです。その著者が、そのまま文章を書くと同程度の知識を持つ人間ではないと、50%も伝わらないことが多いです。そこを助けてくれるのが編集者です。
 私は10冊以上の商業誌の執筆経験がありますが、編集が入った自分の文章を読むと、やはり伝わりやすさが違います。また色々指摘された経験があるので、ある程度は編集者の視点で文章を校正することもできるようになってきました。でも、やっぱり編集者はいて欲しい。同人誌向けにエージェント的な編集者がいても良いのではと思っています。ちなみに、米国だとエージェントとしての編集者が主流で、書籍の企画から出版社への交渉まで著者側についてするスタイルが多いようです。日本も、こういったモデルが出てくるかなと予想しています。

まとめ

 いろいろツラツラと書き連ねましたが、同人誌と商業誌のどちらが良いかという話ではありません。単に違いがこうだよと整理してみただけです。執筆に興味がある人は、同人誌というのも選択肢に入れても良いのじゃないかなと思います。私は、どちらの良さも知っているので、お声がかかる限りは商業誌でも書き続けますし、同人誌もしばらくは続けます。同じ執筆でも、プラットフォームを変えることで、見えてくるものが違うなということに気がついた次第です。今年はもっと色々なプラットフォームに挑戦するつもりです。

booth.pm

See Also
AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい
AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策
AWSのアカウントセキュリティ本を書きました #技術書典

AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい

 昨日のブログエントリーで、AWS Organizations × CloudFormation StackSetsが素晴らしいという話をして、少しだけ紹介しました。今日も、もう少しだけ詳しく説明します。まずは、CloudFormation StackSetsから
※本エントリーの内容は、『AWSの薄い本 アカウントセキュリティのベーシック』で手順を含めて解説しています。興味がある方はBOOTHからダウンロードできる無料サンプルをみてください

f:id:dkfj:20200323084651j:plain

CloudFormation StackSetsとは?

 CloudFormation StackSets(CFn StackSets)は、CloudFormationのテンプレートを元に、任意のAWSアカウント・リージョンに対してスタックの作成・実行ができる機能です。ベーシックなCloudFormationは、アカウントにログインしてリージョンを選んで一つずつ実行する必要があります。同じ設定を複数のアカウントに流し込もうとすると、CLI等を駆使してもそれなりに面倒くさいのも事実です。CFn StackSetsを使うと、その辺りをサクッと管理できるようになります。もちろん、対象アカウントに対して、IAM Role等の準備が必要にはなります。

f:id:dkfj:20200325091547p:plain

図では、Organizationsのマスターアカウント(親アカウント)から実行していますが、権限設定をすればどのアカウントからでも実行可能です。

AWS Organizations × CloudFormation StackSetsの素晴らしさ

 単体でも魅力的なCFn StackSetsですが、Organizationsとの連携機能を使うと、その真価を発揮します。
なんとOrganizationsからアカウントの作成・削除時や、OUの移動時にStackSetsを自動で実行させることができるようになりました。
 つまりアカウント作成時に共通の初期設定をしたり、本番環境用のOUに参加した時により厳しいセキュリティの制約をつけたりするといったような事が、自動でできるようになったのです。アカウントセキュリティ本で繰り返し説明していますが、セキュリティ設定というのはどこか1箇所抜け漏れがあると、そこから侵入される可能性がでてきます。そして人間は(特に私は)、繰り返しの作業を正確にするには向いていません。そういった部分を補完する素晴らしい機能だと思います。

f:id:dkfj:20200324063218p:plain

CloudFormation StackSetsの初期テンプレート

 CFn StackSetsには、サンプルテンプレートが用意されています。そのリストをみてみましょう。

- CloudTrailの有効化
- Configの有効化
- GuardDutyの有効化
- 設定ルール root-account-mfa-enabledの追加
- 設定ルール cloudtrail-enabledの追加
- 設定ルール eip-attachedの追加
- 設定ルール encrypted-volumesの追加

 サンプルといえども結構実用的なものですよね。そして、CFn StackSetsの方向性が見えるものになっています。テンプレートの実体はCloudFormationなので、もちろん自作することが可能です。
 個人的な考えとしては、CloudTrailやConfigなど設定をするテンプレートを作って、それをアカウントID等を引数にわたして一括で設定するチェーンのテンプレートなど、そういった単位でまとめて使えばよいかなと考えています。それを初期設定・ルール設定など幾つかのまとまりで管理すると便利でしょう。

まとめ

AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしいというタイトルそのままのブログエントリーでした。私の興奮が伝わりましたでしょうか?AWSのアカウントセキュリティ本では、100ページに渡って、なぜセキュリティはサービスを使って守らないといけないのか、そしてどのサービスを使えばよいのかを解説しています。興味をもったら是非BOOTHで見てみてください。サンプル版の無料ダウンロードができます。

takuros.booth.pm

AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策
AWSのアカウントセキュリティ本を書きました #技術書典

AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策

 昨日の完成したぞエントリーに続き、『AWSの薄い本 アカウントセキュリティのベーシック』関連のエントリーです。
f:id:dkfj:20200323084651j:plain

 私は今まで、あまりセキュリティって好きな分野では無かったです。もちろん必要性は解っていて、その対策等をいろいろ考えてはいたのですが、どこか自分の仕事じゃないなぁと思っていた部分があります。今回、AWSのアカウントセキュリティ本を書いて、ようやく腑に落ちました。それをまとめたのが、次のツィートです。

24時間365日での自動攻撃。では、防御は?

 攻撃者が24時間365日、自動で攻撃してくる中で、それに対して防御する方が手動で対応するのはナンセンスということに気が付きました。もちろん、セキュリティの設計を考えたり、どういった判断をするかという部分で人間が果たすべき役割は大きいです。一方で、そのためのセキュリティの設定や、日々の攻撃に対する防御は人間に向いている仕事なのか?
 多分あまり向いていないのだと思います。セキュリティはどこか一箇所に不備があれば、そこを狙って侵入口をあけて、そこから内部に侵入される類のものです。人間が手動で設定していると、どこかでミスする可能性は高いです。EC2が登場したことにより、同じ設定をコピーして使うことが簡単に出来るようになりました。それ以来、一つ一つのインスタンスを設定して使う人は殆どいなくなり、職人が手を込めて作られて一台一台微妙に設定が異なる人間の温かみがあるサーバーはだいぶ減ったと思います。でもAWSのアカウントの設定という面ではどうか?一つ一つのアカウントごとに、まだまだ手動で設定されているのではないでしょうか?
 今回AWSのアカウントセキュリティ本を書きながら、AWSのサービスの最新の情報を学びました。もともとAWSでは、設定の大部分がCloudFormationなりCLIなりでコードから設定できます。そのうえで、そのコードをアカウントレベルでまとめて適用させる方法が整っています。つまりAWSではアカウント設定というレベルで、インスタンスと同じように同一の設定を簡単にできるようになっています。その手法について、ちょっと紹介してみます。

AWS Organizations × CloudFormation StackSetsの破壊力

 CloudFormationは、テンプレートを元にスタックを作成し、AWSを設定する機能です。その機能の拡張であるCloudFormation StackSetsは、複数のAWSアカウントやリージョンに対しスタックを作成し、一括で設定します。これだけでも充分便利な機能ですが、2020年2月にAWS Organizationsとの連携機能が発表され、ものすごい進化を遂げました。
 Organizations傘下で、アカウント作成・削除時、あるいは特定のOUに参加したタイミングで、自動でCloudFormation StackSetsを実行する機能です。

f:id:dkfj:20200324063218p:plain

 これがあれば、AWSのアカウント設定の自動化がものすごいレベルで進みます。具体的な使い方については、次回紹介しようと思います。
※本にも書いているので、気になる人はBOOTHへGo!!

まとめ

 セキュリティの施策で、設定レベルの作業は人類には向いていないので、テンプレート等を利用して自動化するべきです。AWSでは、そのためのサービスが凄い勢いで整備されてきています。特にAWS Organizations × CloudFormation StackSetsの組み合わせは破壊的です。この存在の有効性を確認できただけで、AWSのアカウントセキュリティ本を書いた意味があったなと実感するほどです。今、思っている事は以上です。

booth.pm

See Also:
AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい
AWSのアカウントセキュリティ本を書きました #技術書典

AWSのアカウントセキュリティ本を書きました #技術書典

2020年2月29日の技術書典8に発表予定だったAWSのアカウントセキュリティ本こと、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』の執筆が完了し、BOOTHで販売開始しました。

f:id:dkfj:20200323084651j:plain

内容

 書名のとおり、セキュリティがテーマです。そしてただのセキュリティを題材にすると、いろいろな方面からまさかりが飛んできそうなので、AWSのアカウントセキュリティと限定しています。で、アカウントセキュリティとはなんぞやという話ですが、前作ではAWSを扱う上での認証認可のサービスであるIAMをテーマにしていました。ここをしっかりしていると、ことAWSのアカウントまわりという点では6〜7割くらいはカバーできているのではと思っています。一方で、長く使っていると気が付かぬ穴や、複数人で使って誰かがやらかす人も出てくる可能性があります。この辺りを仕組みとしてカバーできるようにしようというのが、今回のアカウントセキュリティ本です。

構成

 構成としては、8章構成です。1章でアカウントセキュリティの説明と、AWSでセキュリティを考える際はどういった領域があるのかの分類をしています。2章はガードレール設計としてAWSのControl Towerの説明をしています。ここで、AWSが目指している方向性を見てもらった上で、以降で自分のアカウントにどのように設定していけばよいのかの解説が続きます。
 3章は主要なAWSサービスの説明をし、4章でチュートリアルとしてAWS Organizationsを使って、2アカウント構成での設定をしています。はい。マルチアカウント構成にしています。当初は予定なかったのですが、アカウントセキュリティを語る上で、Organizationsのサービスコントロールポリシー(SCP)は外せないという判断に至りました。個人ユースでマルチアカウントとドン引きされる可能性を恐れましたが、ここは敢えてマルチアカウント構成です。書いてみた感想としては、もう個人でもマルチアカウント構成でやった方がよいのじゃないかなと思うようになりました。その理由が、OrganizationsとCloudFormation StackSetsの組み合わせです。
 5章のテーマががCloudFormationです。ここはサラッと終わらせるつもりだったのですが、執筆途中に前述のOrganizationsとCloudFormation StackSetsが出てきたので、再びチュートリアルを含めて書いています。この組み合わせの何が素晴らしいかというと、OU傘下に入れば自動的にCloudFormation StackSetsを走らせるということが出来るようになったことです。セキュリティ設定は、どこかに穴があればそこからつけこまれます。人間は必ずミスをするので、繰り返しの作業には向きません。じゃあどうすればよいのという解答に、OrganizationsとCloudFormation StackSetsの組み合わせです。これ本当に素晴らしいです。
 6章・7章が書名のタイトルからいくとメインのコンテンツになる、セキュリティと運用の設計の考え方です。ここについても、どういった切り口で解説するのがよいか悩みました。マニアックな話の路線を踏襲するのであれば、具体的な設計・設定集になるのですが、今回はもう少し考え方の方に重きをおきました。そうした時に、じゃあ何を拠り所にすべきかという点で、NIST サイバーセキュリティフレームワークのコアとAWS Well-Architected Frameworkを中心に解説するというスタイルに落ち着きました。賛否あるとは思いますが、まず読んでいただければと思います。
 最後の章はまとめです。それぞれの章のポイントと次回作ですべきことを書いています。マルチアカウント管理です。

次回作

 次回作としては、前々からの宣言通りAWSのマルチアカウント管理を書く予定です。ただSecurity HubやOrganizationsのSCP周りは既に書いているので、次はOrganizationsのOUの構造とかSSO周りを中心に薄くまとめる予定です。
 それ以外に、今回はあまり設定まわりのところを書けなかったので、マニアックな話としてConfig RulesとCloudFormationをそれぞれ独立して書いてもよいかなと思っています。いつ書くかが問題ですが。。。

技術書典8のサークル

 「チームになった佐々木です」というふざけたチーム名で出していましたが、他のメンバーはしっかりと書いて、好評を博しています。技術書典8で発表された中で、ベスト8に全員入っているという快挙です。どれも良い本なので、ぜひ見てみてください。

f:id:dkfj:20200323065655p:plain

booth.pm

booth.pm

booth.pm

まとめ

 今回は特に難産で疲れました。その分、執筆を通じて私自身も随分レベルアップできたかと思います。査読として周りの人に読んでもらうと、AWSでこんな事ができるなんて知らなかったという声が沢山ありました。
 AWSはどんどんと新しく便利な機能が出てきています。それを自分ひとりで追い続けるのは大変です。そういった人の手助けになれるような1冊になれればよいなと思っています。

AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい
AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策

目次

はじめに
 本書の目的
 対象読者
 本書で得られること
 本書で得られないこと
 お問い合わせ先
 免責事項

第1章 AWSアカウントセキュリティ
1.1 AWSのセキュリティとサービスの概念図
 AWS上に構築するシステムのセキュリティ
 AWSアカウント自体の管理(IAMの設計・運用)
 セキュリティを維持管理するための施策
1.2 責任共有モデル
1.3 AWS上に構築するシステムのセキュリティ
1.4 AWSアカウントの管理
1.5 セキュリティを維持管理するための施策
1.6 マルチアカウント管理

第2章 ガードレールという設計と思想
 2.1 Control Towerの全体像
 2.2 ガードレールの設計と思想
 2.3 予防と検知の実体

第3章 AWSのセキュリティサービス
 3.1 NISTサイバーセキュリティフレームワーク
  CSF コア
 3.2 AWSのセキュリティサービスの全体像と対象領域
 3.3 CloudTrail
  CloudTrailの注意点
  CloudTrailのログ集約
 3.4 Config
  Config
  Config Rules
 3.5 GuardDuty
  GuardDutyの分析対象
  脅威の重要度と通知・対処
 3.6 Security Hub
  Security Hubの集約対象
 3.7 AWS Organizations
  AWS Organizationsの構成要素
  組織単位(OU)と階層構造
  サービスコントロールポリシー(SCP)
  SCPとIAMのアクセス許可の境界
 3.8 Trusted Advisor

第4章 サンドボックスアカウントの作成のチュートリアル
 4.1 サンドボックス環境の要件
 4.2 サンドボックス環境の全体像
 4.3 設定の流れ
 4.4 Organizationsの設定
  Organizationの作成
  サンドボックスアカウントの作成
  組織単位(OU)の作成
  OU配下にアカウントを移動
 4.5 マスターアカウントでの設定
  設定用のIAMユーザー作成
  IAMのアクセスアナライザーの設定
  組織に対するCloudTrailの設定
  Configの有効化
  Configのアグリゲータの設定
  Security Hubの有効化
 4.6 サンドボックスアカウントの設定
  Organizationsで作成したAWSアカウントへのログイン
  設定用のIAMユーザー作成
  監視・監査ログの収集と集約
 4.7 問題の検知と通知
  セキュリティグループの全開放を検知するConfig Rule
 4.8 問題検知時の復旧
  SSMで利用するIAMロールの作成
  自動修復の設定
  修復の確認
 4.9 アカウントのサンドボックス化
  サービスコントロールポリシー(SCP)の有効化と設定
  禁止行為を抑制するポリシーを作成する
  サンドボックスアカウントにポリシーを適用する

第5章 CloudFormationを利用した構成管理
 5.1 CloudFormationで管理する理由
 5.2 CloudFormationで管理する範囲
 5.3 複数アカウントに適用するCFn StackSets
  CFn StackSetsとOrganizationsの連携
 5.4 StackSetsのチュートリアル
  StackSetsの作成
  テンプレートの選択
  StackSetsの権限設定
  デプロイターゲットの設定
  動作確認
 5.5 テンプレートの設計
  サービスのセットアップとルール設定の分離
  アカウント共通設定と個別設定の境界
  CloudFormationの具体的な構造
 5.6 CloudFormationのまとめ

第6章 アカウントセキュリティの設計の考え方の原則
 6.1 CSFコアとAWSの設計原則にみるセキュリティ
 6.2 AWSのセキュリティ ベストプラクティス
  アイデンティティ管理とアクセス管理
  発見的統制
  インフラストラクチャ保護
  データ保護
  インシデント対応
 6.3 セキュリティ設計のまとめ

第7章 障害の検知と復旧の考え方
 7.1 AWSの運用の原則を知る
 7.2 AWSのサービスを使った検知と復旧
 7.3 統合サービス Security Hubの位置づけ
 7.4 Security Hubと個別検知の使い分け
 7.5 監視と検知
 7.6 通知
 7.7 対応と復旧
  AWSの自動復旧のパターン
 7.8 Security Hubの活用

第8章 まとめとマルチアカウント管理への道
 8.1 セキュリティ設計と運用
 8.2 Organizationsのサービスコントロールポリシー
 8.3 Security Hubの導入
 8.4 マルチアカウント管理への道
 8.5 まとめ

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

Kindle本の販売という実績解除しました

 2016年から目標として掲げ続けてきた、Kindle本の販売という目標を2020年3月15日にようやく達成しました。

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

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

IAMのマニアックな話とEPUB

 Kindleで販売を開始した本は、昨年執筆しBOOTHで販売していた『AWSの薄い本 IAMのマニアックな話』です。この本は、Re:VIEWという紙書籍・電子書籍作成支援ツールを利用していて、PDFだけでなくEPUB形式でも出力可能でした。なので、執筆している当時は、BOOTHと同時にKindleでも販売開始しようとしていました。が、出来上がったEPUB版をみて、販売を見合わせていました。

 書籍を作成する場合、図の位置であったり内容に合わせて改ページを考えます。しかし、一般的なEPUBは、リフロー型といって画面や文字サイズに合わせて、テキストやレイアウトが変わります。電子書籍のメリットの一つですが、その反面、意図を込めて配置した図や改ページが無視されます。実際、EPUBでデフォルトで表示してみたら、読めたものではなかったです。

 出版社から出した自分の本が、画像による固定レイアウトにしていることについて、常々文句を言っていました。が、いざ自分で出すとなると、リフロー型の問題点を認識できるようになりました。

リフロー型と固定レイアウトのジレンマ

 読者にすると執筆者の意図を込めたレイアウトより、自分に自由に設定できるリフロー型の方がメリットある場合が多いです。画像による固定レイアウトの場合、検索もできなければハイライト等もできません。検索できない技術書なんてと思いますよね。私も、そう思っています。でも、Amazonに出す場合は、リフローで出すのが怖いのですよ。
 Amazonで出す場合、レビューが非常に重要になります。レビューでは内容そのものだけでなく、レイアウトであったり値段や本の対象とするする読者層に関係なくレベルまで含まれます。ex)私には簡単すぎた or 難しすぎた 果ては物理本の場合は、紙質まで言及されることがあります。そんな中でリフロー型で出すのは、恐怖があります。
 今回、Kindleで販売するにあたっては、画像化による固定レイアウトで販売しました。その代わり、BOOTHではKindleより200円安くした上で、PDF版と固定レイアウトのEPUBとリフロー型のEPUBの3つをダウンロード可能として優遇しています。本当は、Amazonでもこのような形で販売したいのですが、現状はできません。

Kindleで売る意味

 それではBOOTHをメインにしているのに、Kindleで売る意味は何があるのでしょうか?実は、そこを模索中です。BOOTHに比べてAmazonの方が圧倒的にリーチする層は多いです。一方で、当初想定していた以上にBOOTHでも売れつづけているのです。そこでしか買えないのであれば、ちゃんと買ってくれるというのが解りました。ただ、その上でKindleで発売したらどうなるのか試してみたいというのが今回の販売開始の意図です。まだ始めたばかりなので、試行錯誤中ですが、ある程度解ったらまたブログで報告します。

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

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

 BOOTHでは、2冊セットや5冊・10冊セットとバリエーション揃えています。社内で利用すると言った場合は、こちらもご検討ください。

booth.pm

IAM本こと『AWSの薄い本 IAMのマニアックな話』の物理本、販売中です #技術書典

Twitterで告知はしているのですが、ブログの方でも改めて告知です。
技術書典8向けに用意していた『AWSの薄い本 IAMのマニアックな話』の物理本、ただいまBOOTHで販売中です。

f:id:dkfj:20200314171352j:plain

入庫作業に時間が掛かっているので、自宅から注文のたびに1冊1冊私が梱包してファミリーマートから発送しています。また、自宅から発送なので商品バリエーションの自由度があるということに気がついて、2冊セットや5冊セット、10冊セットなども用意しています。

takuros.booth.pm


そういったバリエーションを用意しておいて何ですが、ポツポツと2冊セットや5冊セットが本当に売れているのですね。どういった人が買っているのか、気になります。商品に対してリクエストがあれば検討しますので、お気軽にお問い合わせください。