概要

チームでアジャイル開発を実践するための原則と手法を体系的に習得する

想定読者

アジャイル開発の導入を任されたエンジニアやプロジェクトリーダー。「スクラムという言葉は知っているが、実際の進め方に自信がない」という開発者1〜5年目が主な対象

こんな人には向いていない

• スクラムマスター認定取得済みで複数プロジェクトにわたるアジャイル実践経験を持つ上級者には、大部分が既知の内容となる
• 一人で完結する個人開発が主な作業スタイルの開発者には、チーム協調・合意形成に関する章の適用機会が限られる
• アジャイルの理論的・学術的な深掘り(ソフトウェアプロセス研究など)を求める読者には、実践寄りの構成では物足りないことがある

この本で身につくこと

• インセプションデッキを使ってプロジェクト開始時に「なぜ作るか」「スコープ外は何か」をチームで明文化できる
• ユーザーストーリーの書き方・見積もり・優先付けを通じてイテレーション計画を自力で回せる
• デイリースタンドアップ・ショーケース・振り返りの目的を理解し、ファシリテーションできる
• ベロシティを指標にした継続的なスケジュール管理と進捗の可視化ができる
• 「形だけのアジャイル」に陥る典型パターンを見分け、チームの改善指針として対策できる

章立て

(公式情報未確認 — 出版社公式ページの目次が公開され次第、本セクションを更新予定)

関連記事 / 参考情報

• 【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた — 入門から中級まで段階別に整理した推薦書リスト。開発プロセス理解の一冊として本書が掲載されている
• Webエンジニア1年目の自分に捧げたい本・記事を超まとめ — 1年目エンジニアが振り返り「これを読めばよかった」と挙げた書籍群。チームで動く感覚を養う枠に収録
• IT系の会社に入った新入社員の皆さんへのアドバイスを、ひとつだけ — IT職の新入社員に向けた実践的アドバイス記事。開発チームの動き方を学ぶ一冊として本書が挙げられている
• SREやクラウドエンジニアが読むと良さげな本まとめ — SRE・インフラ職視点から選んだ技術書まとめ。プロセス改善・チーム文化の理解枠として本書が選出されている
• アジャイル初心者だけど、どうしてもインセプションデッキの素晴らしさを伝えたい話 — 本書のインセプションデッキ章に触発された実践報告。プロジェクト合意形成ツールとしての有効性を現場目線で解説
• 「アジャイルサムライ」を読んだので、その要点 — 本書を通読した著者による章ごとの要点まとめ。事前確認や読後の復習に活用できる
• まだ読んだことない人が読んだ気になれる「アジャイルサムライ」まとめ — 本書の内容を未読者向けに圧縮整理した記事。購入前に全体像を把握するのに有用
• 「なんちゃってアジャイル」から抜け出すにはどうしたらいいのか？を考える — 形式的なアジャイル導入に陥る原因を分析し、本書の原則を軸に「真のアジャイル」への移行を論じた記事
• 【スクラム導入】経験者1人(自分)のみのチームにスクラムを導入した話 — 少人数チームへのスクラム導入実践記。本書の枠組みを参照しながら手探りで進めた経緯を記録

学習のヒント

• インセプションデッキの章(「なぜここにいるのか」から始まる10の問い)を最初に読むと、その後の計画・実行・チーム運営の各章が「なぜそのプラクティスが必要か」という文脈で腑に落ちやすい
• イテレーション計画・ショーケース・振り返りの章は、実際のスプリント運営と並行して読むと定着が早い。まず1スプリント回してから該当章を参照するサイクルが効果的
• チームへの導入時には、インセプションデッキのワークショップを実施する前に担当者だけでも本書の該当章を先読みしておくと、ファシリテーションの質が上がる
• スクラム経験者がチームに1人しかいない状況でも導入できる構成になっているため、「経験者がいなければ始められない」という思い込みを外す読み方ができる

前提知識

• チームでのソフトウェア開発の実務経験(個人開発のみの場合、チーム協調に関する記述の実感が薄くなる)
• バックログ・スプリント・ベロシティなど、スクラム基本用語の意味をおおよそ知っている

次に読む本

SCRUM BOOT CAMP THE BOOK

アジャイルサムライで概念を掴んだ後、スクラムの具体的なロール・イベント・アーティファクトを実務レベルで整理する定番書

エクストリームプログラミング

XPの技術的プラクティス(TDD・リファクタリング・ペアプログラミング等)を理解することで、本書が提示する「技術的な卓越さ」の背景をより深く掴める

カンバン仕事術

スクラムと異なるフロー型アプローチを学ぶことで、チームの状況に応じた開発プロセス選択の判断軸が広がる