As AI continues to accelerate what’s possible in product development, the biggest bottleneck isn’t the technology—it’s us. Human coordination, communication, and decision-making often slow things down more than any technical limitation. To truly harness the power of AI, we must focus on minimizing friction for people just as much as we optimize for machines. This article outlines practical strategies to align teams, reduce cognitive load, and create a work environment where both humans and AI can operate at their full potential.

Ensure Everyone Understands the Goal

(Responsibility of the board, Product Managers, and Engineering Managers)

In today’s rapidly changing world, teams need to act more autonomously. They shouldn’t have to constantly ask what to do next. Clear alignment is more critical than ever.

1. Clarify the north star at the company, department, and team levels. If members don’t fully understand it, progress stalls.
2. Keep strategies up to date across all levels. While not mandatory, shared understanding of strategy helps everyone move faster and make better decisions.

Minimize Cognitive Load for Both AI and Humans

(Organizational structure: VPs. Execution: PdMs, EMs, and ICs)

To enable close collaboration between AI and people, everything—products, code, and processes—must be designed to reduce complexity.

3. Keep product requirements as small as possible Write compact PRDs that can be used directly with AI coding tools. If it’s too large, break it into smaller parts.
4. Keep teams small Ideally 2–3 people, to minimize communication overhead.
5. Keep codebases small and focused Large codebases are harder for AI tools (and people) to navigate. When AI starts struggling to understand the architecture, it’s time to break things down. Always consider creating a new component before modifying an existing one.
6. Minimize dependencies between systems Dependencies increase complexity. Don’t be afraid to reinvent the wheel when it reduces entanglement. If you must depend on another system, keep interfaces as simple as possible.
7. Deliver quickly Don’t wait for a sprint to end. Ship as soon as something is ready.
8. Start collecting feedback immediately It’s likely your first version won’t hit the mark. Gather user feedback or metrics right away, learn, and iterate fast.

Minimize and Optimize Human Communication

(Everyone, especially EMs and ICs)

Humans—not AI—are usually the bottleneck. The most time-consuming task is communication between people, so make it count.

9. Prioritize synchronous communication Meet in person or via Zoom as often as possible to quickly align and unblock.
10. Revisit architecture after PMF Once your product has found market fit, take time to reassess and optimize the system architecture holistically.

Summary

By aligning teams around a clear vision, minimizing complexity for both humans and AI, and streamlining communication, organizations can unlock faster delivery and better outcomes. These principles aren’t just about working more efficiently—they’re about creating a culture where high-performance teams can thrive. The companies that adopt these habits now will be the ones that lead tomorrow.

• 目次（詳細はオライリーのページへ）
  • 第1章 なぜTerraformを使うのか
  • 第2章 Terraformをはじめよう
  • 第3章 Terraformステートを管理する
  • 第4章 モジュールで再利用可能なインフラを作る
  • 第5章 Terraformを使うためのヒントとコツ: ループ、条件分岐、デプロイ、その他のつまずきポイント
  • 第6章 シークレットを管理する
  • 第7章 複数のプロバイダを使う
  • 第8章 本番レベルのTerraformコード
  • 第9章 Terraformのコードをテストする
  • 第10章 チームでTerraformを使う
• Amazonの書籍詳細

帯などにはTerraform 1.0対応とありますが、より詳しく言うと原著はTerraform 1.2までの変更が含まれており、かつ日本語版ではTerraform 1.5までの変更（原稿を仕上げたのが1.6発表の直前でした）に関しても訳注としてできるだけ情報を追加しています。ちなみに第3版とありますが、翻訳の元になった原著が第3版なためで、日本語ではこれが最初の版です。

基本的にはAWSにリソースを作るチュートリアル形式で、インスタンスを1台デプロイする非常に短いコードから始まり、徐々にそこにリソースを追加していくような流れで進んでいきます。

とは言え、目次を見ていただくと分かるように単に文法を学んでいくだけではなく、Terraformをチームで使ったり複雑な使い方をしていくと必ず突き当たるであろう問題に対するベストプラクティスを提示する流れにもなっています。この本で取り上げられているこういったテクニックやベストプラクティスの主な点をいくつか抜粋すると次のようなところでしょうか。

• 開発、ステージング、本番と環境が増えていくときのステートファイルの管理
• Terraformコードを保存するリポジトリのディレクトリ構造をどうするか
• モジュールはどういう時に使い、どう分けるべきか、どの程度の粒度にすべきか
• リファクタリングの注意点
• パスワードなどのシークレット管理
• AWSとAzure、あるいはAWSの複数のリージョンといった複数のプロバイダの扱い方
• テスト
  • 1.6で導入されたterraform testは含まれませんが、プランテスト、terratest、インフラ(E2E)テストなどが含まれます。
• 開発プロセスあるいはCI/CDへの組み込み

これに加え第10章の冒頭ではTerraformを使っていないチームにTerraformを導入する場合の根回しの流れが書いてあるのですが、この記述がTerraformに限らず新しいツールや技術をチーム内で導入しようとした時の一般的あるある例になっており、個人的には面白かったです。

著者のYevgeniy Brikman氏は、Terraformを活用したインフラの構築運用などを手掛けるGruntwork社の創業者でありCTOです。この本はそのビジネスを通じた経験を元にして書かれており、Terraform導入にかかるコミュニケーション的な側面も、Terraformを使って顧客に対しサービスを提供してきた経験からくる知識でもあるのでしょう。また、長年Terraformコミュニティに貢献してきた人でもあります。

一方で、最近のTerraformのライセンス変更から始まった論争の中では、いち早くライセンス変更に異議を唱えており、その論争に端を発しTerraformからフォークされたOpenTofuプロジェクトの発起人の1人でもあります。

そのあたりからもうかがえるように、Terraformとそれを取り巻くエコシステムはやや先が見えない時代を迎えているとも言えますが、以前と比べると多くの人に使われるようになっており、その意味ではこれまでにない安定した時期を迎えているとも言えます。この本は、現時点のTerraformを使いこなそうと考える人に対しては、幅広い分野をカバーしており決定版と言っていいでしょう。今まで、日本のTerraformコミュニティの広がりに比べると広い範囲をカバーした日本語書籍は少ない印象でしたが、この本がさらに日本のTerraformユーザを増やす一助になればと思います。

• 目次
• Amazonの書籍詳細

私がこの記事を書くのにモタモタしているうちに、書評を書いてくださった方が早くもいらっしゃるのですが、いちおう翻訳者としてこの本について少し紹介しておこうと思います。

「入門 監視」のユニークなのは、監視と言うとどうしても特定の監視ツール（Nagios、Zabbix、Mackerelなどなど）の話になってしまいがちなのですが、そこをあえて特定ツールの名前をなるべく出さないようにしているところです。むしろ著者が冒頭の第1章から戒めているのは、ツール依存です。ツールから監視を考えると非効率な仕組みを作ってしまいがちであり、さらに監視とは単一の問題ではなく色々な問題が複雑に絡み合ったものなので、監視したいもの、監視すべきものを元にしてツールを選ぶという順番を取るべきであるという主張が書かれています。それ以降も、著者の経験を元にした監視のアンチパターン、デザインパターン、そしてサーバやネットワークからビジネスKPIの監視、セキュリティ監視などといった対象ごとの監視のポイントが書かれるという流れです。どの記述も著者の強い主張がにじみ出ているのですが、それでいて監視についての本質を突いたことが簡潔にまとめられています。

数年前私がとあるシステムの運用を引き継いだ時、監視は一通り設定されており、障害があれば気づける状態にはなってはいました。しかし、毎日大量のアラートメールが飛んできており、しかも大部分は無視してよいものでした。そのため、私の最初の仕事はそれらが自動的に既読になるようメールの設定をすることでした。その時点ではそんなものかなと思いつつ、あれこれ試行錯誤をしてそういった「慣れている人が見ないと本当に対応が必要かどうかわからないアラート」ばかりを生成する監視システムを改善していきました。初めてこの「入門 監視」の原書「Practical Monitoring」を読んだ時は、その時の試行錯誤の結果分かったことがほとんど書いてある！という驚きを感じたものです。この本を翻訳しようと思ったきっかけがこの驚きでした。とりあえず監視をしないといけないから監視ツールを導入したけれど本当に十分なのか分からない、意味不明なアラートメールがたくさん飛んできていて困っている、これからシステムの監視をしないといけないが何をしたらいいか分からない、といった監視の初心者の方が、監視に対する考え方を身につけるのにはとてもよい本です。

原文ではあえてツールに関する記述が少なくなっていますが、それだと監視に初めて触れる人にとっては抽象的な話ばかりになってしまうので、もう少し具体的な話を付録として付け加えればいいのになと、原書を読んだ時から考えていました。そこで、SaaS型サーバー監視サービスであるMackerelのプロダクトマネージャーである株式会社はてなの松木雅幸さん（@songmu）に付録を書いていただきました。注意点などを含め分かりやすい解説を書いていただいたことで、本全体のバランスがずっとよくなったと確信しています。

ちなみに、「入門 監視」というどストレートなタイトル、短すぎるとは思ったものの特に違和感は感じませんでした。どうやら驚きを感じた人が多かったようですが。。

正直「入門 監視」というタイトルに違和感を抱かない程度には監視脳になっています。

— songmu (@songmu) 2019年1月14日

私もまさにこの感覚でいました。

謝辞

今回も、レビュアーの方々には丁寧に本文をチェックしていただき、技術的な指摘から日本語としての読みやすさまで、様々なアドバイスをいただきました。レビュアーのみなさま、そして付録の執筆をしていただいたsongmuさんにはここで感謝を表したいと思います。

• 目次
• Amazonの書籍詳細ページ

Kubernetesの開発者たちが直接Kubernetesを解説した本で、Kubernetesでアプリケーションを動かすために必要な色々な概念を、実際にKubernetesクラスタ上で動かしてみながら学んでいくという構成になっています。

また、チュートリアルだけでなく「なぜコンテナを使うべきなのか」「どういう経緯でKubernetesが生まれたのか」「マイクロサービスの何がいいのか」といった、コンテナやマイクロサービスが広まって来た背景についても書かれています。そのため、コンテナはほとんど触ったことがないという人でも読み始められるようになっています。

入門書なのでKubernetesの機能のすべてが網羅されているわけではありませんが、Kubernetesを理解するための基本的な事項については一通り書かれています。Kubernetesの公式ドキュメントはとても丁寧に書かれているので(ただし英語)、まずこの『入門Kubernetes』を読んでKubernetesの仕組みと基本的なリソースを学び、さらにその先を知りたい場合には公式ドキュメントを読み込んでいくというのにぴったりだと思います。

日本語版独自の改善点

原著はKubernetes 1.5あるいは1.6をベースに書かれています。日本語版には、翻訳完了時の最新版であるKubernetes 1.9までに加えられた変更などを、注釈などの形でできるだけ反映しました。チュートリアルを簡単に進められるように、原著の内容に合わせてサンプルデータのリポジトリが用意されているのですが、これも日本語版に合わせてKubernetes 1.9対応データを含むリポジトリを用意しました。

また、原著への「内容はいいのに誤植が多すぎる」といった指摘に対しては、翻訳の際にできる限り修正を反映させるようにしています。

翻訳の経緯と謝辞

英語を日本語に翻訳することで日本語の情報量を増やしたいという思いで、人力翻訳コミュニティYakstというサイトを作って翻訳したり、『SQLパフォーマンス詳解』というデータベースに関する本の翻訳などをしてきました。その先に、いつかは書店で売られる本の翻訳がしたいと思っていたところ、機会をいただいて実現することになりました。

私自身Kubernetesに関してはまだまだ経験が浅いこともあり、Kubernetesの運用経験豊富なレビュアのみなさまからの指摘無しにこの本は完成しなかったといっても過言ではありません。レビューしていただいた@mahataさん、@Ladicleさん、@superbrothersさん、@strskさん、@deeeetさん(順不同)には本当に感謝するばかりです。

「私は『入門Kubernetes』でKubernetesを始めました」という人がたくさん現れて、日本のKubernetesコミュニティがさらに盛り上がっていくことにつながれば、翻訳者としてこの上ない喜びです。みなさんぜひ読んでみてください！

2月10(金)に開催されたTokyo Rubyist Meetupというイベントで、自分が翻訳したSQLパフォーマンス詳解という本をベースにして「How indexes work in relational databases」という題で発表した。題名からわかるように、英語での発表。

Tokyo Rubyist Meetupは、Doorkeeperの社長Paul McMahonさんが主催している、Rubyのことを中心にしつつも色々なトピックを取り上げている英語話者向けの勉強会。Paulさんからお声がけがあって、DBエンジニアからの知見はRubyistにもうけると思うよということで、英語の勉強と本の宣伝とデータベース知識の整理の意味で発表することにした。Paulさん貴重な機会をくれて本当にありがとうございました！

内容的には、SQLパフォーマンス詳解(の英語版)の第1章の要約みたいな感じで、インデックスがなぜ必要なのか、Bツリーインデックスはどうやってデータを探すのに役立つのかといった基本的なところを書いた。Active Recordばっかり使ってて、SQLがどう動いているのかあまり意識していなかったり、高速に応答するクエリをどう書いたらいいのかわからない人に向けて、インデックスコワクナイヨ、ということを言ったつもり。しかし特定のDB(MySQLとかPostgreSQLとか)についてあえて触れなかったので、内容的に抽象的すぎたかもしれない。こういう発表って、どの程度の人をターゲットにするかブレないようにすること、そして抽象的すぎず突っ込みすぎずな内容にもっていくのが難しい。

今年は意識的に英語でアウトプットしていこうと思っているので、できる限り機会を見つけてこういう場で発表するつもり。

I gave a talk “How indexes work in relational databases” based on the book SQL Performance Explained at Tokyo Rubyist Meetup held on Feb. 10.

(See the material above.)

Tokyo Rubyist Meetup is a tech meetup for English speaking Ruby engineers organized by the CEO of Doorkeeper Inc. Paul McMahon. One day, he gave me an email and suggested me to talk about a topic related to databases. I decided to talk something to practice my English, to promote the book, and to reorganize my thought on databases. Thank you very much Paul, this was my precious experience!

The talk was basically the summary of the chapter one of SQL Performance Explained, including basic topics like why indexes are needed and how B-tree indexes search a record. The talk was for developers who use Active Record and don’t have enough knowledge about indexes and what I wanted to say for them is that don’t be afraid of indexes. I intentionally avoid to write about a specific database management system (MySQL, PostgreSQL, etc.) to focus on how indexes work in general but because of that, the talk might be too abstract. Hopefully, the talk was a good introduction to the internal of databases for attendees.

I’m going to talk at some more events in this year to improve my English skill.

ちなみに、これらのサービスを既に使っている人は、単純にこれらのボットをフォローするか、Slack(英語の公式ドキュメント、日本語記事)やHipchat(Zapierを使った方法の日本語記事)などにボットのツイートを通知するようにしておくと、障害検知の一環としても使えますのでぜひどうぞ。どのボットも障害発生時間などを日本時間に置き換えてツイートする仕組みです。

AWS

Twitterボット

• 全リージョン対象 @awsstatusjp_all
  • 下のボットのツイートも包含されるので片方フォローすればOK
• 東京リージョン関連のみ @awsstatusjp
  • 東京リージョンのサービスと、S3やManagement consoleなどリージョンなしのサービスの障害が対象

障害情報サイト

• http://status.aws.amazon.com/
• 大まかな地域ごとにタブが並んでおり、その中に地域内の全リージョン、全サービスが一列に並ぶ
• 障害があると左端の緑の丸がオレンジになり、障害の詳細がDetails列に簡潔に書かれる
• 他のサービスと比べると障害内容の記述はシンプルであまり詳細は書かれない
• 過去の障害履歴は下半分に1週間分(それ以前にもさかのぼれる)表示されるが、サービス数が多すぎてやや見にくい
• 比較的定型的な表現が多い
• タイムゾーンはPST/PDT

機械的に障害情報を取る方法

• 全リージョンの全サービスの情報がそれぞれ1つずつRSSフィードで提供される
• その他に全障害情報が含まれるRSSフィードもある
• 基本的には上記サイトに表示される内容がフィードにも書かれる

所感

• いいところ
  • リージョン及びサービスごとにフィードがあるので特定サービスごとに監視したい時は楽
  • 定型的な表現が多いので訳したり表現を拾って処理を分岐したりしやすい
• 悪いところ
  • 過去の障害情報が見にくいので他サービスのように時系列の一覧などが欲しい
  • フィードの数が多すぎる(all.rssをうまく使えばいいが)
  • 他サービスと比べて障害情報の詳細さが足りない

GCP

Twitterボット

• 全リージョン対象 @gcpstatusjp
  • 日本リージョンはまだない(開設予定)
  • 現状、障害がリージョンごとにうまく分けて通知されないので日本リージョンができても別ボットにしづらそう

障害情報サイト

• https://status.cloud.google.com/
• 地域ごとやリージョンごとの区分けはなく、横軸が日時、縦軸がサービスのグリッドのみ
• 障害があるとグリッド状に赤(致命的障害)やオレンジ(一部障害)の丸が表示され、障害の詳細へのリンクが貼られる
• 障害内容の記述は詳細で、次の報告をいつまでにするかが必ず併記される
  • ただし次の報告時刻は守られない時もある様子
• 過去の障害は時系列に並んで表示される
• タイムゾーンはPST/PDT

機械的に障害情報を取る方法

• サイトに掲載されている詳細情報や障害のレベル(Severity)、開始・収束時刻なども載ったJSONと、少し情報が少ないRSSの2つ

所感

• いいところ
  • フィードの他に詳しい情報を含むJSONフィードが提供されている。しかもちゃんとスキーマ情報も別にある
  • Severityと障害の開始・収束時間があるのが非常にいい
• 悪いところ
  • リージョンが障害情報の詳細にしか書かれないので、特定リージョンの障害のみを検出したりするのが困難

Azure

Twitterボット

• 全リージョン対象 @azurestatusjp_a
  • アカウント名の文字数制限の影響で末尾がallじゃなくて悲しかった
  • 下のボットのツイートも包含されるので片方フォローすればOK
• 日本リージョン関連のみ @azurestatusjp
  • 日本のリージョンとグローバルサービスのみ

障害情報サイト

• https://azure.microsoft.com/ja-jp/status/ (https://status.azure.com/でもアクセス可)
• 大まかな地域ごとにタブが並んでおり、その中に横軸リージョン、縦軸サービスのグリッドがある
• 障害があるとグリッドに赤丸や黄色三角が表示され、障害の詳細がページ上部に書かれる
• 障害内容の記述はGCPに近い詳細さで、今後の対応予定なども書かれる
• 過去の障害は時系列に並んで表示される
• URLからすると障害内容は日本語で表示されそうに見えるが、リージョン名などのみ日本語であとは英語のまま
• タイムゾーンはUTC

機械的に障害情報を取る方法

• 全リージョンの全サービスの情報が含まれるRSSフィードが1つのみ
• 障害内容の記述はサイトに表示されるものと同じだが、Severityなどの情報は含まれない

所感

• いいところ
  • かなり詳しい障害状況が報告される
• 悪いところ
  • RSSフィードのスキーマが微妙(リージョンとサービスが同じCategoryに列挙されている)
  • 障害がない時はRSSフィードの内容が空になる
    • どんな情報がどのように配信されるか分からない
    • 障害が終わった時の情報がフィードから得られない
    • 他サービスだと、障害収束後に「こんなのありました」という報告パターンがあるがそういうのをどう出すのか謎
  • サイト上には表示されるがRSSフィードに載らない情報が多い

全体的に

• 利用者から見てもっとも丁寧な感じなのはAzureだが、フィードがいけてないので情報の加工は一番やりにくい
• AWSは情報の詳細さが他サービスと比べて全然足りない
• 障害情報を加工して通知などに使いたい時には圧倒的にGCP。Severityや障害開始・収束時間など詳しい情報をパースしやすい形式で提供しているのはGCPのみ

1000 speakers conference in English

金曜は1000 speakers conference in Englishという、参加者全員が英語で3分のLTをするというイベントに参加、マイペースで続けている個人的な翻訳プロジェクトYakstについて英語で話してきた。3分というのは非常に短いので、英語どころか日本語でもプレゼンしたことないという人でも、意外と話せてしまう時間。思ったよりゆるい雰囲気かつ参加者はエンジニアばかりではないというところが面白く、ネタがあるときには今後も積極的に参加してみたい。参加費無料。

Vital Japan / Vital English

土曜はVital Japanという老舗かつ大規模な英語勉強会のイベントで、シリコンバレー企業のワークスタイルについての英語セッションを聞いた。たった1000円で第一線で活躍するコンサルタントの英語のトークが聞け、さらに参加者同士で英語ディスカッションする機会もあるなんて、なんてお得な！

現職がシリコンバレー企業みたいなもの(本社はサンフランシスコ。SFもシリコンバレーに入る？)だし、How Google Worksとか読んだ身としては特に目新しいトピックはなかったけれど、逆にディスカッションの時に他の参加者の話から日本企業の闇みたいなのを感じられて、その意味では興味深かった。

最後の質問時間に参加者から出た「シリコンバレー企業のやり方が非常にいいのはわかるが、既にルールでがんじがらめの日本企業を一般社員の力で変えていくにはどうしたらいいか？」という鋭い質問に対して、「日本企業でも、経営者と現場の社員は何が問題か既に気づいていて、中間管理職の存在がシステムを変えにくい原因になっているケースが多いように感じる。経営者が言っていることをよく聞いて、彼らと協力する方法を探せば道は開けるんじゃないか」とスピーカーのロッシェルさんが回答していたのが印象的だった。

また、Netflixに勤めているという日本人が、発音は日本人的だけれど的確な言葉を選んで非常に流暢に発言していて、まさに自分が目指すのはああいうレベルだよなと再確認。勉強会みたいなイベントは、何かの知識を得るために行くのだけでなく、自分よりできる人を目の前にしてその人に感化されてもっと頑張るモチベーションをもらいに行くところでもあるなと改めて思った。

ちなみに、いきなり全部英語は無理という人は、Vital English 英語勉強会というのもあり、こちらは説明が英語に加えて日本語でもされて、資料に従って会話の練習をするというような流れになっている。こちらも参加費1000円とは思えない非常に濃い内容。

他にもオススメの英語勉強会あったら @dblmkt まで教えてください！

EBSボリュームのスナップショット

インスタンスストレージ(インスタンスに無料で付いてくるローカルストレージ)と比べてEBSを使うことの利点の一つに、スナップショットを取れるというのがある。これはもちろんAWSのコンソールからの操作でも、awscliのようなツールを使ってもできるんだけど、いちいちこれらの操作をやるのは面倒になってくる。そうすると、

• 自動で定期的にスナップショットを取りたい
• 古いスナップショットは自動的に消したい
• 複数のEBSボリュームのスナップショットをまとめて取りたい
• 全ボリュームのスナップショットを取る必要はなく、一部だけ取っておきたい

みたいな話が出てくる。

そういう時にはもちろんawscliや各言語のSDKを使って自分でこれを実装してもいいのだが、AWS Missing Toolsと言う、AWSに関するちょっと痒いところに手が届くツール集があって、これに含まれるEBSスナップショット取得用のスクリプト ec2-automate-backup.sh を使うと便利。

ec2-automate-backup.shの使い方

拡張子でわかる通り単なるシェルスクリプトで、中ではawscliを駆使して処理を行っている。なので、前提としてawscliがインストールされていて、credentialの設定が終わっている必要がある。awscliのインストール方法については割愛。

awscliの用意が済んだら、リポジトリをクローンしてきてコマンドを叩けばよい。

  
git clone https://github.com/colinbjohnson/aws-missing-tools.git
  
cd aws-missing-tools/ec2-automate-backup
  

コマンドのオプションはREADMEに書いてあるが、イマイチわかりにくい。最低限以下がわかればとりあえずのバックアップは取れる。

• -s [volumeid|tag] : バックアップ対象のボリュームをボリュームID指定するか、特定のタグが付いているもので指定するかを選択する。tagを選んでおくと、例えば「Backup=true」と付いているボリュームを一括でバックアップする、ということが可能。
• -v ボリュームID : -s volumeidを指定した場合にボリュームIDを指定する。
• -t 'タグ名,Values=値' : -s tagを指定した場合にタグ名を指定する。上の例のように「Backup=true」のタグが付いているボリュームをバックアップする場合、-t 'Backup,Values=true'と指定する。ここちょっとわかりにくい。なお、タグはEC2インスタンスではなくEBSボリュームに付ける。
• -r リージョン : リージョン指定。ap-northeast-1とか。
• -n : タグ指定でスナップショットを取った時、スナップショットのNameタグに、元のボリュームIDを入れる
• -k 日数 : 指定した日数以上経過したスナップショットは削除可能タグが付けられる
• -p : -kで指定した日数以上経過したスナップショットを実際に削除する

具体的には、以下のようにコマンドを実行する。これは「Backup=trueタグが付いたボリュームのスナップショットを作成し、7日以上経過したスナップショットを削除する」例。

  
bash ec2-automate-backup.sh -s tag -t 'Backup,Values=true' -r ap-northeast-1 -n -k 7 -p
  

実際の挙動的には、-k 7オプションがあるので7日経つとスナップショットにPurgeAllow=trueタグが付けられ、次の実行で-pオプションが効いてPurgeAllow=trueがついているスナップショットが消される、という流れになる。

これをcrontabに書いておくなりJenkinsで定期実行するなりしておけば、うっかりファイルを消してしまったとか、データベースがぶっ壊れたみたいな時にもサクッと戻せて幸せになれる。

プログラミングの勉強にと思ってTwitterボットを作ってみたら、ことあるごとに「あっ、これもボットになってたら便利そう」と思うようになってしまって、さらにいくつか作るという流れ。それなりに便利なのができると、ほっといてもフォロワーが増えていくのが楽しくなってしまう。今まで作ったボットのまとめ。

深田久弥bot  @fukadakyuya_bot

TLでフォロワーのみなさまと盛り上がったのがきっかけで、初めて作ったTwitterボット。ボットをフォローしているユーザが深田久弥の著書「日本百名山 (新潮文庫)」に含まれる山名を含んだつぶやきをすると、同書の中からその山の特徴などを表した部分をリプライする。また、1日1回7：00にはランダムに抜粋をつぶやく。

@doublemarket 夕方、日本海に沈む太陽の余映を受けて、白山が薔薇色に染まるひと時は、美しいものの究極であった。みるみるうちに薄鼠に暮れて行くまでの、暫くの間の微妙な色彩の推移は、この世のものとは思われなかった。

— 深田久弥bot (@fukadakyuya_bot) 2014, 7月 27

最初はPHPで書いたのだがいつの間にかうまく動かなくなったりして、Rubyで書き換えた。ソースコードはGithubに上げてある。作った頃はRubyのエコシステムが良く分かってなくて、bundler使わずにやってたりして、自分でもどうやって動いてるのか理解してなかったなあｗ リプライする山名にどういう傾向があるのか気になったので、山名ごとにリプライ数を集計する仕組みも作ってみた。基本的に富士山がダントツに多いのだが、例えば最近だと吾妻山や蔵王山(火山活動活発化)、立山(アルペンルート開通)といったように、急にリプライ数が増えた山があると、大体そこでは何かあったということが分かって面白い。

山の天気 @yamatenki

毎朝7：30前後に、その週末に天気がいい(登山日和になりそうな)山を地域ごとにツイートする。 土曜と日曜それぞれ分けて判断するようになっている。祝日などの連休にも対応させたいが、めんどくさそうなので先送りしてしまっている。

【南アルプス】今週末、山に行くなら「甲斐駒ヶ岳」「仙丈岳」「鳳凰山」「北岳」「間ノ岳」、日曜日なら「塩見岳」「悪沢岳」「赤石岳」「聖岳」「光岳」の天気が良いようです。 http://t.co/YU8l9oRZUo — 山の天気 (@yamatenki) 2015, 5月 15

山名を含んだメンションを送ると、少し詳しい天気予報をリプライしてくれる。

@doublemarket【今週末の丹沢山】03/29土曜日は、くもり時々晴れ、降水確率は12時まで30%、18時まで30%。03/30日曜日は、くもり一時雨、降水確率は12時まで50%、18時まで50%。 (神奈川県西部) http://t.co/0Kh75x9Egg

— 山の天気 (@yamatenki) 2014, 3月 25

こちらも最初はPHPで作ったが今はRuby製。天気が一覧で見れるページも定期的に生成している。 深田久弥botと違ってうざくない作りなのもあってか、フォロワーが4600以上(2015年5月)もいて、自分の作ったボットの中では一番多い。

hatebu english @hatebu_e

はてなブックマークが一定数以上付いた日本語以外の(正確には、タイトルと本文に全角文字を含まない)記事をツイートする。Yakstという主に英語のブログ記事などを翻訳して公開するサイトを解説しているのだが、そのネタ探しの足しになるかと思って作った。

GitHub Engineering (3 users) http://t.co/xWxAkjVCZI http://t.co/aDzjTh7OfY — hatebu english (@hatebu_e) 2015, 5月 19

誰得なのかよく分からないボットなので、フォロワーは少ないw

AWS障害情報(全リージョン) @awsstatusjp_all

AWS障害情報(東京リージョン) @awsstatusjp

仕事でAWSを本格的に使い始めたので、手軽にAWSのステータス情報を知れる手段がないかと思ったのだが、いい感じのボットがなかったので作った。時刻を日本時間に直し、定型的な文言はなるべく日本語に翻訳するようにしている。GCPとかのボットもなければ作ってみようかな。

日本時間2015年05月19日(火) 07:46:53 EC2 (サンパウロ) お知らせ Network Connectivity http://t.co/LMkNfK2ZYm

— AWS障害情報(全リージョン) (@awsstatusjp_all) 2015, 5月 18

日本時間2015年05月16日(土) 00:36:27 EC2 (東京) 正常稼働中 [復旧済み] Network connectivity http://t.co/aq5bOVSJ4H

— AWS障害情報(東京リージョン) (@awsstatusjp) 2015, 5月 15

ちなみに、プロジェクトでHipchatやSlackなどのチャットツールを使っている場合、それぞれのTwitter連携機能を使ってこのボットのツイートを拾うようにすれば、AWSの障害情報が流れてくるようになって便利。

ボットを作ると、プログラミングの基礎もだが、Twitter APIやスクレイピングのテクニックなど、作るボットに応じて色々な技術が必要とされるので、新しい言語を覚える人とか、そもそもプログラミング初心者にはもってこいの課題になる。オススメです。

題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDF版と印刷版が上記サイトから購入できます。

(追記 2017年9月から、渋谷のBOOK LAB TOKYOさんでも印刷版を販売していただいています。輸送コストの関係で、サイトから購入するより若干安くなっています)

リレーショナルデータベースにおいて、SQLとインデックスがどのように関連し、どのようにすればSQLのパフォーマンスを良くできるのかを解説した本です。特定のデータベース製品に焦点を当てた本は多数ありますが、この本ではOracle Database、PostgreSQL、MySQL、SQL Serverの4つのメジャーなリレーショナルデータベース製品を同時に扱っていて、それぞれのクセや特徴も分かるように書かれている点が非常にユニークになっています。また、ORMが生成するSQL文の違いなどにも言及されています。

前書きにもあるように、データへのアクセスパスを知っているのは他ならぬ開発者なので、開発者自身がSQLとインデックスについての知識を深めなければ本当の高速化はできない、というのが著者の考えのようですが、もちろんアプリ開発者だけでなくインフラエンジニア、データベースエンジニアの方々にもおすすめできる内容だと思います。

目次とそれぞれの内容は以下の通りです。

• 第1章 インデックスの内部構造
  • インデックスとはそもそも何か、インデックスはどのような仕組みか
• 第2章 where句
  • where句とインデックスの関連、例えば=を使った場合、likeを使った場合など演算子の違いによるインデックスの活用方法など
• 第3章 パフォーマンスとスケーラビリティ
  • インデックスの作り方の違いによるパフォーマンスとスケーラビリティの違い
• 第4章 結合処理
  • 結合(join)とインデックスの関連
• 第5章 データのクラスタリング
  • データのクラスタリング(HAクラスタなどではなく、いわゆるクラスタリングインデックスのこと)
• 第6章 ソートとグルーピング
  • ソート(order by)やグルーピング(group by)とインデックスの関連
• 第7章 部分結果
  • MySQLで言うlimitやPostgreSQLのfetch firstのような、結果の一部分を取得するSQL文とインデックスの関連
• 第8章 データの変更
  • update, insert, deleteといった更新処理とインデックスの関連
• 付録A 実行計画
  • 各データベース製品での実行計画の表示方法とその読み方

既にご存知の方もいるかもしれませんが、Use The Index, Lukeという名でほぼ全文がWeb上で公開されています。とはいえWeb上で通しで読むのはかなり辛いですし、PDFあるいは印刷版を購入いただければ、作者・訳者とも嬉しい限りです。

私は、Yakstというサイトで海外のブログ記事などを翻訳して公開するというのをやっているのですが、原著者(Markus Winandさん)が書かれたブログ記事を翻訳させてもらったのがきっかけで、この本の翻訳をやることになりました。オンライン販売だけの予定なので書店に本が並ぶわけではないとは言え、自分が訳した本が人に読まれることになるというのは、不思議な感覚です。Markusさんはオーストリア人で英語のネイティブスピーカーではないこともあり、原文は非常に分かりやすい英語で書かれているのですが、それでも翻訳の難しさ、自分の未熟さをひしひしと感じました。素晴らしい本を書いてくださった原著者のMarkusさん、私のつたない訳を丁寧にレビューしてくださった@matsuuさん、ありがとうございました！

訳の問題など、ご意見ご感想ありましたら@dblmktまでいつでもご連絡ください。

ちなみに、海外の有益な技術系ブログを翻訳して公開しているYakstで、翻訳を一緒にやっていただける仲間も募集しておりますので、良かったらそちらも是非よろしくお願いします。