b.l0g.jp     About     Archive     Feed

10 Rules for Fast-Moving Dev Teams in the Age of AI

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.

  1. 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.
  2. Keep teams small Ideally 2–3 people, to minimize communication overhead.
  3. 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.
  4. 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.
  5. Deliver quickly Don’t wait for a sprint to end. Ship as soon as something is ready.
  6. 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.

  1. Prioritize synchronous communication Meet in person or via Zoom as often as possible to quickly align and unblock.
  2. 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.

『詳解 Terraform 第3版』を翻訳しました

詳解 Terraform 第3版』という本が本日2023年11月21日、オライリー・ジャパンから出版されました。米O’Reillyから出版されている『Terraform: Up and Running, 3rd edition』を私が日本語訳したものです。この本は原著の初版が出版された頃からぜひ自分で翻訳したいと思っていたので、やっとここに至れて個人的にとても嬉しいです。

  • 目次(詳細はオライリーのページへ)
    • 第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ユーザを増やす一助になればと思います。

『入門 監視』を翻訳しました

サーバやネットワーク、セキュリティなどシステムの監視に関わる心構えや取り組み方を解説した「入門 監視」という本が、2019年1月17日にオライリー・ジャパンさんから出版されました。原書は「Practical Monitoring」という本で、それを私が翻訳したものです。私が訳した本としては3冊目、オライリー・ジャパンさんから出版されるものとしては「入門Kubernetes」に続いて2冊目です。

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

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

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

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

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

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

謝辞

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