目次

第1章　アジャイルの基本と原則：強いチームの作り方

• 1.1　アジャイルソフトウェア開発宣言
  • 1.1.1　4つの価値
  • 1.1.2　12の原則
  • 1.1.3　アジャイル宣言が示す学習する組織への転換
• 1.2　スクラムとは
  • 1.2.1　アジャイルとスクラムの関係
  • 1.2.2　スクラムの価値観
  • 1.2.3　スクラムの責任（Accountability）
  • 1.2.4　スクラムのイベント
  • 1.2.5　スクラムの作成物（アーティファクト）
  • 1.2.6　スクラムの特長と効果
• 1.3　アジャイルはチームスポーツ
  • 1.3.1　優れた個人の寄せ集めだけでは勝てない
  • 1.3.2　「阿吽の呼吸」はいかにして生まれるか
  • 1.3.3　自己組織化という戦術
• 1.4　反復：不確実性を飼いならす最も有効な方法
  • 1.4.1　反復とは「経験主義」という科学的アプローチである
  • 1.4.2　短い反復が「リスク」を燃料に変える
  • 1.4.3　信頼の再定義：「計画への準拠」から「価値提供能力」へ
• 1.5　本章のまとめ
  • column　雁の群れに学ぶ自己組織化

第2章　共通理解が自律性とチームワークを育む

• 2.1　リファインメント：価値の種を見つけるための共同作業
  • 2.1.1　ユーザーストーリー：対話を生む「共通言語」
  • 2.1.2　リファインメントにおける具体的な活動
  • 2.1.3　ユーザーストーリーマッピングという共同作業
  • 2.1.4　チームワークを高める見積もりとは
  • 2.1.5　プロダクトオーナーの「説明責任」と役割
• 2.2　スプリントプランニング：「共通理解」を行動計画に変える共同作業
  • 2.2.1　スクラムの「計画」とウォーターフォールの「計画」
  • 2.2.2　共同作業による「共通理解」が計画を支える
  • 2.2.3　リファインメントをおろそかにした場合に起きる問題
  • 2.2.4　チームワークを支える2つのイベント
• 2.3　デイリースクラム：計画を生き生きと動かす共同作業
  • 2.3.1　デイリースクラムの目的と本質
  • 2.3.2　共通理解を更新し、チームワークを強化する
  • 2.3.3　報告会に陥ったデイリースクラムの問題
• 2.4　スプリントレビュー：共通理解を顧客に広げ、チームの未来を拓く
  • 2.4.1　スプリントレビューは「承認会議」ではない
  • 2.4.2　チームの共通理解がスプリントレビューの質を高める
  • 2.4.3　顧客からのフィードバックがチームの未来を拓く
• 2.5　スプリントレトロスペクティブ：チーム自身を「強化」する共同作業
  • 2.5.1　スプリントレトロスペクティブの目的と本質
  • 2.5.2　共通理解と心理的安全性が深い議論を生む
  • 2.5.3　継続的改善がチームを「最強の学習マシン」にする
• 2.6　スプリント：共同作業が織りなす「価値創造のサイクル」
  • 2.6.1　スプリントはアジャイル開発の心臓である
  • 2.6.2　共同作業が織りなす「共通理解のサイクル」
  • 2.6.3　イベントの連鎖がチームの自律性を育む
• 2.7　本章のまとめ
  • column　「　問題」と「課題」を混ぜていませんか？

第3章　チームワークで「アジリティ」を高める

• 3.1　フローとは何か
  • 3.1.1　「フロー」の見える化：バリューストリームマップ
  • 3.1.2　リードタイムとサイクルタイム
• 3.2　WIP制限でフローを高める
  • 3.2.1　WIP制限とは
  • 3.2.2　高速道路の例で見るフロー効率
• 3.3　スウォーミングでフローを加速させる
  • 3.3.1　WIP制限の問題点とスウォーミング
  • 3.3.2　スキルマッピングによる多能工化の促進
• 3.4　仕事の細分化によるフローの改善
  • 3.4.1　バッチサイズ
  • 3.4.2　「ロット生産」と「一個流し」
  • 3.4.3　ウォーターフォールとアジャイル
  • 3.4.4　プロダクトバックログの分割
  • column　ユーザーストーリーの分割方法
• 3.5　ボトルネックを見つけて改善する
  • 3.5.1　システム全体の能力はボトルネックに制約される
  • 3.5.2　「局所最適」に陥る罠
  • 3.5.3　インプットをアウトプットに合わせて調整する
  • 3.5.4　ボトルネックを補強し、フローを改善する
  • 3.5.5　ボトルネックの探し方
• 3.6　サイクルタイムはどこまで短縮できたか
• 3.7　本章のまとめ

第4章　チームを支援する組織作り

• 4.1　アジャイル開発の成否は準備で決まる
• 4.2　まずは構造を疑おう
• 4.3　品質ゲートを取り払い、フローを加速しよう
  • 4.3.1　品質ゲートがフローを阻害する理由
  • 4.3.2　アジャイルにおける品質と安心の実現
• 4.4　チームメンバーは専任にしよう
  • 4.4.1　兼務問題に見るチームワークとエンゲージメント
  • 4.4.2　ワインバーグの表に見るコンテキストスイッチのムダ
  • 4.4.3　共同作業の機会損失とアジリティの低下
• 4.5　階層型組織から脱却しよう
  • 4.5.1　組織の「当たり前」を疑う
  • 4.5.2　階層型組織の源流：テイラー主義という思想
  • 4.5.3　現代に潜むテイラー主義の亡霊
  • 4.5.4　階層がアジリティを蝕む3つの病
  • 4.5.5　新たな組織OSへのアップデート
• 4.6　機能別組織から脱却しよう
  • 4.6.1　なぜ今、組織の形を変える必要があるのか
  • 4.6.2　機能別組織（サイロ型組織）の功罪
  • 4.6.3　コミュニケーションの壁と部分最適の罠
  • 4.6.4　意思決定の遅延とハンドオーバーの連鎖
  • 4.6.5　コンウェイの法則と組織構造の弊害
• 4.7　機能横断型組織へ移行しよう
  • 4.7.1　機能横断型組織とは何か
  • 4.7.2　機能横断型組織への移行戦略
  • 4.7.3　移行を阻む壁とそれを乗り越えるために
  • 4.7.4　価値提供の流れを作るために
  • column　最初の壁：パイロットチームが作れないとき、どうするか
• 4.8　フロー効率を阻害するチーム外への依存をなくそう
  • 4.8.1　WIP増加と停滞のメカニズム
  • 4.8.2　多能工化でフローを取り戻す
• 4.9　パッションを持ったプロダクトオーナーに権限を委譲しよう
  • 4.9.1　なぜ管理職をPOにしてはいけないのか
  • 4.9.2　「パッション」を基準に選び、「権限」を委譲する
  • column　受託開発の光と影
• 4.10　アジャイルにおける管理職の役割の変化を知ろう
  • 4.10.1　指示する人から、信頼で導くサーバントリーダーへ
  • 4.10.2　チームを守り、障害物を取り除く交渉人へ
  • 4.10.3　本質的な成果を定義し、ビジョンを示す戦略家へ
  • 4.10.4　人の成長を支援し、キャリアを育むコーチへ
  • 4.10.5　自ら学び、組織変革を推進するチェンジエージェントへ
• 4.11　スケールの幻想を超え、自己組織化しよう
  • 4.11.1　スケールの罠と「デスケール」
  • 4.11.2　逆コンウェイ戦略：デスケールを実現する道しるべ
  • 4.11.3　理想の姿：「自己組織化された雁の群れ」
• 4.12　本章のまとめ
  • column　なぜ組織は変われないのか？：ラーマンの法則

第5章　チームを支援する組織運営

• 5.1　成果を求めるなら、まず関係の質から始めよう
  • 5.1.1　成功循環モデルとは
  • 5.1.2　【バッドサイクルの実例】「成功」の仮面を被った失敗：Zynga
  • 5.1.3　【グッドサイクルの実例】人と人とのつながりが生む成功　―　スターバックス
  • 5.1.4　アジャイルは「チームスポーツ」
• 5.2　「やらないこと」を最大化しよう
  • 5.2.1　価値の8割は、2割の機能から生まれる（パレートの法則）
  • 5.2.2　無限に増える仕事との向き合い方（パーキンソンの法則）
  • 5.2.3　スクラムにおける実践：「価値」と「時間」の制約
  • column　アジャイルに効く認知バイアス集
• 5.3　スケジュールではなく、ゴールで計画しよう
  • 5.3.1　「計画＝スケジュール」という呪縛
  • 5.3.2　アジャイルにおける「計画」：地図ではなく、コンパスを持つ
  • 5.3.3　タスクの事前割り当てがチームワークを阻害する
  • 5.4　成熟したチームを維持しよう
    • 5.4.1　チームの成熟プロセス「タックマンモデル」
    • 5.4.2　プロジェクト型開発とプロダクト型開発
    • 5.4.3　視点の転換：「チームに仕事をアサインする」へ
    • column　顧客価値の流れに沿うチーム：Stream-Aligned　Team
  • 5.5　全体最適の優先順位を考えよう
    • 5.5.1　「全体最適」の欠如がリソースの無駄を生む
    • 5.5.2　経営層の責務：価値の低い仕事をさせないこと
  • 5.6　予算は経験主義で決めよう
    • 5.6.1　「プロジェクト」ではなく「プロダクト」に予算を付ける
    • 5.6.2　経験主義のアプローチを適用する
  • 5.7　本章のまとめ
    • column　アジャイルの難しいところ

  第6章　組織はチームをどう評価するか

  • 6.1　ベロシティはチームのパフォーマンスを表さない
    • 6.1.1　ベロシティとは何か
    • 6.1.2　なぜベロシティをパフォーマンス指標にしてはいけないのか
  • 6.2　KPIは少数を定点観測しよう
    • 6.2.1　KPIは「指標」であって「目標」ではない
    • 6.2.2　グッドハートの法則と、その罠に陥った企業事例
    • 6.2.3　KPIの正しい使い方：定点観測による学習
  • 6.3　アジャイルチームの予測可能性を知ろう
    • 6.3.1　予測は「過去の実績」からのみ得られる
    • 6.3.2　予測は「対話」と「調整」のためにある
  • 6.4　「結果」をコントロールできるという幻想
    • 6.4.1　「結果」はコントロールできない
    • 6.4.2　フィードバックループによる脱却
    • 6.4.3　アジャイル開発への応用
  • 6.5　フローで測るチームと組織のパフォーマンス
    • 6.5.1　サイクルタイムが映し出すチームの実力
    • 6.5.2　リードタイムが示す価値創造能力と組織の問題
    • 6.5.3　指標は「対話」の出発点
  • 6.6　チームの現在地を知る自己評価
    • 6.6.1　なぜ他人からの評価ではいけないのか
    • 6.6.2　「わかったつもり」という成長の壁
    • 6.6.3　ダニング・クルーガー効果からの脱却
    • 6.6.4　メタ認知能力を鍛える2つのアプローチ
    • column　メタ認知獲得のための自己評価法
  • 6.7　階層的な評価制度から脱却しよう
    • 6.7.1　伝統的な評価制度がもたらす弊害
    • 6.7.2　事例1：Spotify　―　報酬の「構造」を自己決定する
    • 6.7.3　事例2：Whole　Foods　Market　―　アジャイルな文化と徹底した透明性
    • 6.7.4　事例3：チームによる給与決定（TSS）
    • 6.7.5　アジャイルな制度改革のススメ：小さく始めて育てる
    • 6.7.6　評価制度は組織文化を映す鏡
  • 6.8　本章のまとめ

  第7章　変化を乗りこなし、価値を創造し続けるために

  • 7.1　なぜ今、「チームを支える組織」が必要なのか？
  • 7.2　「強いチーム」の本質：共同作業が織りなす学習サイクル
  • 7.3　流れを制するものがアジリティを制す：フロー効率という革命
  • 7.4　チームを解き放つ組織デザイン：構造が文化を創る
  • 7.5　リーダーシップの変革：管理から支援へ
  • 7.6　測るべきは価値であり、成長である：評価という対話
  • 7.7　終わりなき旅へ：学習する組織への第一歩