はじめに
15年前の定番書『アジャイルサムライ』の教えは、AIがコードを書く時代でも通用するのか。読み終えたあと、本の教えを「古びたもの」と「まだ効くもの」に仕分けてみたところ、結果はタイトルの通りきれいに割れました。
『アジャイルサムライ』（Jonathan Rasmusson 著、原著2010年・日本語版2011年）はアジャイル開発の入門書として定番中の定番です。ただ出版から15年以上経った今、開発の現場にはAIエージェントが入り込み、コードもテストもドキュメントもAIが書く時代になっています。
この記事はその仕分けの中身です。本の要約ではなく、AIエージェントと一緒に開発している現場の実感を通した再解釈として読んでもらえればと思います。
- 想定読者: AIエージェント（Claude Code / Codex など）を開発に使っていて、開発プロセスをどう組み立てるか考えている人。『アジャイルサムライ』既読でなくても読めるように書いています
前提: 『アジャイルサムライ』とは
3行で説明すると:
- 「価値のある成果を毎週、ちゃんと動く形で届ける」ためのアジャイル開発の実践書
- インセプションデッキ（プロジェクト開始時の認識合わせ）を世に広めた本として有名
- 前半がプロジェクトの立ち上げと計画づくり、後半がXP由来のエンジニアリングプラクティス（ユニットテスト・リファクタリング・TDD・CI）
古びた教え——「作るコスト」を前提にしたもの
「テストをとにかくたくさん書く」→ 書くのはタダになった。問われるのは質
本書は「危なっかしいところは全てテストする」「テストは自動化する」と繰り返します。2010年当時、これは高くつく投資でした。テストを書く時間を確保する戦いが本書の裏テーマだったはずです。
2026年、この戦いは終わりました。AIに頼めばユニットテストは大量に、ほぼタダで生成されます。実際、私のプロジェクトはCIにカバレッジ率を設定しているので、AI製のユニットテストが大量にあります。
ただし新しい問題が生まれました。そのテスト、本当にバグを検出できるのか？ カバレッジという数字は満たしていても、実装をなぞるだけのテストが並んでいる可能性があります。体感では、ユーザー操作を通しで確認するE2Eテストのほうがよほど品質担保に効いています。
「たくさん書く」は達成された。次の課題は「書かれた大量のテストの検出力をどう測るか」です。
「ペーパープロトタイプ」→ AIに動くプロトタイプを作らせる
本書はユーザーとの認識合わせのために、紙でUIのモックを描いていろんなデザインを試すことを勧めています。「安く速く作って会話の材料にする」のが狙いです。
今なら紙より速く、動くプロトタイプがAIで作れます。狙い（会話の材料を安く量産する）はそのままに、道具だけ差し替えられる典型例です。むしろ動くものを触ってもらえるぶん、当時より強力になっています。
「見積もりは当てずっぽう」→ 当てずっぽうの一次見積もりはAIにやらせる
本書の見積もり論は率直です。「見積もりとは当てずっぽうである」。だからこそ絶対値ではなく相対サイズ（ストーリーポイント）で、手早く気軽にやれと説きます。
「どうせ当てずっぽう」なら、一次見積もりをAIにやらせるのは理にかなっています。直近に完了したタスクを基準ストーリーとしてAIに与え、残りを相対見積もりさせる——本書の三角測量そのものです。人間はAIの見積もりに違和感がある箇所だけ直せばいい。
私のチームでもストーリーポイント導入の話はありながら手が付いていないのですが、「AIでざっくり出す」なら導入の敷居は当時よりずっと低いはずです。
「イテレーションゼロ」→ AIの段取りを整える日になった
本書には、開発を始める前に段取りを済ませる期間として「イテレーションゼロ」が出てきます。当時の中身はリポジトリ・ビルド・テスト環境の整備でした。
2026年版のイテレーションゼロには、明らかに新しい項目が入ります。AIに与えるナレッジ（CLAUDE.md）、作業手順やルールを固めるための skills・hooks、linter / formatter、コード規約の明文化。これらは人間のためでもありますが、AIの出力品質を決めるガードレールとしての意味が大きい。初日にここを整備しておくと、後続のタスクすべてがきれいになります。
「継続的インテグレーション」→ 時代が追いついて標準装備になった
「ビルドを大事にする」「常にデプロイできるようにしておく」という15章は、正直に言うと今読むと当たり前に感じます。GitHub Actions と IaC が普及した今、CIは「頑張って導入するもの」ではなく前提です。
これは本が古びたのではなく、本の主張が完全に勝利したということなのだと思います。
むしろ効くようになった教え——「認識合わせ」と「確認」
「動くソフトウェアこそが進歩の最も重要な尺度」
もともとはアジャイルマニフェストの原則の一節で、本書も冒頭で引用しています。
AIは大量のコードを瞬時に出力します。コードの行数、コミット数、生成されたファイル数——進捗に見えるものが爆発的に増えました。だからこそ「動くものだけが進歩」という尺度の価値が上がっています。
本書の「完了とは完了のこと」も同じです。AIが「実装しました」と言っても、動作確認が済むまでは完了ではない。AIの申告と実際の乖離を日常的に見ている人ほど、この一文の重みがわかるはずです。
「やらないことリスト」
インセプションデッキの中で一番実用的だと感じたのがこれです。やること・やらないこと・後で決めることに仕分けるだけの単純なフレームワークですが、AI時代には新しい意味が生まれています。
作るコストが下がったせいで、余計なものを作りがちになったからです。AIに頼めば機能が一晩で生えてくる時代、スコープを絞る力は実装力より希少になりつつあります。「何を作らないか」を最初に決めて明文化しておくのは、人間のためでもAIのためでもあります。Issue やタスクの説明に「やらないこと」を書いておけば、AIに実装を任せたときにスコープが勝手に膨らむのを防げます。
ユーザーストーリーは「会話の約束」
要件を思いついたとき、詳細を書き込まず「あとで話し合う約束」として大きな枠組みだけ書く——本書のユーザーストーリー観です。
AIで仕様書っぽい文書を量産できる今、これは逆張りに見えて本質だと思います。詳細に書かれた文書は「合意した感」を出しますが、実際の認識合わせは会話でしか起きません。私は副業で、実際に使う人と直接話しながら要件を決めて作った経験がありますが、ざっくり話して作って直すサイクルで十分いいものができました。AIが文書を書ける時代でも、フェイス・トゥ・フェイスの価値は下がっていません。
「バグを直す前に、失敗するテストを書く」
本書のバグ修正の作法です。①バグの本質を理解したことを示せる ②自信を持って修正したと言える ③再発しないことを保証できる。
これはそのままAIへの指示として使えます。AIにバグ修正を頼むと、原因を理解しないまま「動くようになった」パッチを当てがちです。私はこの手順を skills（AIが特定の作業のときに読み込む手順書）にしていて、AIがバグ修正のチケットを消化するときは、修正案を出す前に根本原因を調査し、失敗するテストを先に作るところから始まるようになっています。手順を縛ると、AIの修正の質は目に見えて変わります。
2010年の人間向けの規律が、2026年にはAIのガードレールとして再利用できる。この本を読んで一番面白かった発見です。
ユビキタス言語
プロジェクトで使う用語を定義して、会話・ドキュメント・コード・DBのカラム名まで揃えるという話（11章）。地味な教えですが、AI時代には効果が倍増しています。
AIに与えるナレッジに用語集を入れておくと、AIの出力が一気にプロジェクトに馴染むからです。用語が曖昧なままだと、AIは一般語で命名し、コードベースに表記ゆれが蓄積していきます。人間のチームだけの頃より、用語定義のリターンは大きくなっています。
まとめ: 仕分け結果の一覧
| 教え | 2010年の意味 | 2026年の意味 |
|---|---|---|
| テストをたくさん書く | 高くつく投資。時間確保の戦い | 書くのはタダ。問われるのは検出力 |
| ペーパープロトタイプ | 紙で安く速く作って会話する | AIで「動くもの」を量産して会話する |
| 見積もり（ストーリーポイント） | 人間がやる当てずっぽう | 一次見積もりはAIの仕事 |
| イテレーションゼロ | リポジトリ・ビルド・環境整備 | CLAUDE.md・skills・hooks の整備 |
| 継続的インテグレーション | 頑張って導入するもの | 標準装備（主張の完全勝利） |
| 動くソフトウェアが進歩の尺度 | 進捗管理の規律 | AIの「実装しました」への防衛線 |
| やらないことリスト | スコープ管理の道具 | AIのスコープ暴走の防止線 |
| ユーザーストーリー＝会話の約束 | 文書より会話 | AIが文書を量産する時代の、なお本質 |
| バグ修正は失敗するテストから | 人間の規律 | skills にしてAIの手順を縛る |
| ユビキタス言語 | チームの共通語 | AIナレッジに入れて効果倍増 |
仕分けてみると、境界線はきれいでした。
- 古びたのは「作るコスト」を前提にした教えだけ。テストを書く、プロトタイプを作る、見積もる——作業のコストはAIが溶かした。しかもCIのように「主張が勝利しすぎて当たり前になった」ものも含めて、負けた教えはひとつもない
- 「認識合わせ」と「何が本当かの確認」の教えは全部現役。動くものが尺度、完了とは完了のこと、会話の約束、やらないことを決める——ここはAIが逆に重要度を上げた
そして一番の発見は、本書の「人間チーム向けの規律」の多くが、そのままAIエージェント向けのガードレールとして書き写せることでした。失敗するテストを先に書け、用語を揃えろ、やらないことを決めろ。15年前の本が、CLAUDE.md や skills、Issue に書く内容の元ネタとして普通に役立っています。
古典と呼ばれる本の教えを「AIならどうなる？」と問い直しながら読むのは、思った以上に収穫がありました。あなたの本棚で眠っている15年前の名著も、同じ問いで読み直してみてください。CLAUDE.md や skills に書き足す次の一行が、たぶん見つかります。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通して見えてきた「実務未経験の方にぜひ身につけてほしい技術力」を、ここでは紹介していきます。