エンタープライズにアジャイル開発を導入しようとしているすべての人に。 企業にアジャイル開発を導入するときに、何が障壁となり、何が課題となり、どのように取り組んでいけばその中で成功がつかめるのか？ アジャイル開発を成功させるためのチーム作り、プロジェクトの進め方、プランニングからリリースまでの流れ、開発時に必要な技術、評価と改善まで、徹底的に解説。 エンタープライズでのアジャイル開発の実現に向けて様々な経験をし、度重なる試行をしてきた執筆陣が、その実践の中で得た知見とノウハウをこの一冊に凝縮しました。 前半は「導入編」として、「チームを作る」「開発の準備」「開発」「評価と改善」など、それぞれの場面でのアジャイルの理想と現実、そしてどうしたら上手くいくか、を説明しています。これらを参考に、是非、読者自身の組織やチームに適用してみてください。 後半は「実践編」として、「要件管理」「アジャイルで求められる開発技術」「品質管理」「構成管理」「DevOps」「プロジェクト管理」などのトピックを解説しています。 「アジャイルに必要な考え方やプロセスだけでなく、エンジニアリングの解説もしています。これまでの私たちの経験のなかで、アジャイルの実践においてはプロセスだけに力を入れても上手く実践できないことを学んだためです。プロセスとエンジニアリングを両輪として実践していく必要があります。プロセスとエンジニアリングの両方が書かれていることも本書の特徴です。 本書を読んだあと、アジャイル導入に関するあなたの悩みや課題が解消でき、よいプロダクトができ、顧客へさらなる価値が提供できることを期待しています。」（著者「はじめに」） Introduction 1　アジャイル開発の守破離 2　ソフトウェアのビジネス価値 3　アジャイルを始める前に理解しておくべきこと 4　我々の知っているアジャイル開発 5　アジャイル開発のフレームワーク 6　アジャイル開発についてよく聞かれる2つのこと 導入編 Chapter1　チームを作る 1-1　メンバーを集める 　　　1-1-1　プロダクトオーナーを決める 　　　1-1-2　プロダクトオーナーの権限 　　　1-1-3　開発チームのメンバーを集める 1-2　チームビルディング 　　　1-2-1　メンバーの適切な関係を作る 　　　1-2-2　目標に対して一丸となる 1-3　環境を整える 　　　1-3-1　ステークホルダーのサポートを受ける 　　　1-3-2　快適な作業環境を準備する Chapter2　開発の準備 2-1　プロジェクトの方針を決める 　　　2-1-1　方針の決め方 　　　2-1-2　プロジェクトを管理する方法 　　　2-1-3　関係者の認識を合わせる 2-2　プロダクトバックログの作成 　　　2-2-1　プロダクトバックログアイテムを作成する 　　　2-2-2　アイテムの優先順位を決める 　　　2-2-3　リリースのタイミングを決める 2-3　開発のスタートができる状態にする 　　　2-3-1　開発環境を構築する 　　　2-3-2　開発のリハーサルをする 2-4　ステークホルダーへの説明 　　　2-4-1　ステークホルダーへの説明 Chapter3　開発 3-1　イテレーション（スプリント）のプランニング 　　　3-1-1　プランニングの準備 　　　3-1-2　プランニングで目標とスコープを決める 　　　3-1-3　プランニングで開発作業の計画を立てる 3-2　バックログアイテムの実装 　　　3-2-1　リリースまでの開発の進め方 　　　3-2-2　開発中のコミュニケーション 　　　3-2-3　設計 　　　3-2-4　コーディング 　　　3-2-5　他のシステムとの連携 　　　3-2-6　テスト 　　　3-2-7　デイリースクラムの開催 　　　3-2-8　ドキュメントの作成 　　　3-2-9　開発したソフトウェアのレビュー/ 受け入れ 3-3　ソフトウェアのリリース 　　　3-3-1　計画した通りにリリースする 3-4　プロジェクトの管理 　　　3-4-1　品質の管理 　　　3-4-2　プロジェクトの進捗管理 　　　3-4-3　スプリントの進捗管理 　　　3-4-4　バージョン管理 　　　3-4-5　ステークホルダーへの報告 3-5　運用 　　　3-5-1　運用フェーズへの移行 Chapter4　評価と改善 4-1　ソフトウェアの評価と改善 　　　4-1-1　ソフトウェアの評価 　　　4-1-2　ソフトウェアの改善 4-2　組織の評価と改善 　　　4-2-1　組織の評価 　　　4-2-2　組織の改善 4-3　開発チームの評価と改善 　　　4-3-1　開発チームの評価 　　　4-3-2　開発チームの改善 実践編 Chapter5　要件管理 5-1　プロダクトオーナーの役割 　　　5-1-1　プロダクトオーナーの役割・責任 5-2　インセプションデッキ 　　　5-2-1　インセプションデッキを作成する理由 　　　5-2-2　エンタープライズならではのナレッジ 　　　5-2-3　インセプションデッキの活用 5-3　プロダクトバックログの概要 　　　5-3-1　プロダクトバックログとは 　　　5-3-2　プロダクトバックログを見える化する方法 5-4　プロダクトバックログの作り方 　　　5-4-1　ユーザーに届けたい価値を整理する 　　　5-4-2　ユーザー像の深堀り 　　　5-4-3　ユーザーストーリーマッピング 　　　5-4-4　プロダクトバックログアイテムを作る 　　　5-4-5　プロダクトバックログアイテムの見積り 5-5　フィードバックを集める 　　　5-5-1　背景にある考え方 　　　5-5-2　ユーザーのフィードバック 　　　5-5-3　フィードバックを集める Chapter6　アジャイルで求められる開発技術 6-1　オブジェクト指向 　　　6-1-1　オブジェクト指向の基本 　　　6-1-2　アジャイルで必要なオブジェクト指向の考え方 6-2　デザインパターン 　　　6-2-1　デザインパターンの基本 　　　6-2-2　アジャイル開発で効果を発揮するデザインパターン 6-3　テスト駆動開発 　　　6-3-1　テスト駆動開発の必要性 　　　6-3-2　テスト駆動開発のしくみ 　　　6-3-3　テスト駆動開発で利用するツール 　　　6-3-4　テスト駆動開発の本質 6-4　リファクタリング 　　　6-4-1　リファクタリングとは 　　　6-4-2　コードの臭い 　　　6-4-3　リファクタリングカタログ 　　　6-4-4　リファクタリングツール 6-5　ペアプログラミング 　　　6-5-1　ペアプログラミングとは 　　　6-5-2　モブプログラミング 　　　6-5-3　リモートでのプログラミング 6-6　アーキテクチャ設計（マイクロサービス） 　　　6-6-1　サービス化の検討 　　　6-6-2　マイクロサービスの効果と支えるしくみ 　　　6-6-3　サービスメッシュについて 6-7　マイクロサービスの採用と組織 　　　6-7-1　マイクロサービスの概要 　　　6-7-2　アジャイルの組織とマイクロサービス Chapter7　品質管理 7-1　アジャイルの品質管理 　　　7-1-1　アジャイル開発の品質課題 　　　7-1-2　アジャイル開発の品質管理の基本 　　　7-1-3　エンタープライズで押さえるポイント 7-2　テスト技法 　　　7-2-1　アジャイルテストの分類 　　　7-2-2　Q1 エリア: テクノロジー観点の開発支援テスト 　　　7-2-3　Q2 エリア: ビジネス観点の開発支援テスト 　　　7-2-4　Q3 エリア: ビジネス観点のプロダクト評価テスト 　　　7-2-5　Q4 エリア: テクノロジー観点のプロダクト評価テスト 　　　7-2-6　アジャイルテストの重要ポイント 7-3　ソフトウェアメトリクスの収集と改善 　　　7-3-1　ソフトウェアメトリクスによる品質チェック 　　　7-3-2　ソフトウェアメトリクス収集の仕方 7-4　アジャイルの品質報告 　　　7-4-1　ウォーターフォール開発との成果物比較 　　　7-4-2　アジャイルの品質報告 Chapter8　構成管理 8-1　分散型バージョン管理 　　　8-1-1　分散型バージョン管理とは 8-2　Git 　　　8-2-1　Git 誕生の背景 　　　8-2-2　ノンリニア開発のための分岐システム 　　　8-2-3　Git の仕組み 　　　8-2-4　基本操作 　　　8-2-5　ブランチモデル決定の3 つのポイント 　　　8-2-6　主要なブランチモデルの概要 8-3　まとめ Chapter9　DevOps 9-1　DevOpsとは 　　　9-1-1　背景 　　　9-1-2　DevOpsの考え方 9-2　DevOpsのためのインフラ構築の自動化 　　　9-2-1　クラウドのリソースの構築/管理を自動化する 　　　9-2-2　ミドルウェアの構築/ 管理を自動化する 9-3　DevOpsのためのアプリケーション開発の自動化 　　　9-3-1　基本となる技術 　　　9-3-2　自動化の種類 　　　9-3-3　チームや組織に合致した自動化の選択 　　　9-3-4　自動化を実現する構成 9-4　DevOpsを導入する 　　　9-4-1　エンタープライズのDevOpsの問題点 　　　9-4-2　DevOps の準備 　　　9-4-3　DevOps の環境を試運転する 　　　9-4-4　DevOpsを実践する 9-5　組織のパフォーマンスを高めるための体制 　　　9-5-1　エンタープライズに多い組織体制 　　　9-5-2　従来の組織体制が引き起こす問題 　　　9-5-3　パフォーマンスを向上させる組織体制への変更 Chapter10　プロジェクト管理 10-1　プロジェクトプランニング 　　　10-1-1　ウォーターフォール開発 　　　10-1-2　アジャイル開発 10-2　体制作り（チームビルディング） 　　　10-2-1　ウォーターフォール開発での体制作り 　　　10-2-2　アジャイル開発での体制作り 10-3　開発の進め方（リリース計画） 　　　10-3-1　Quality（品質） 　　　10-3-2　Delivery（スケジュール） 　　　10-3-3　Cost（お金） 10-4　まとめ Conclusion　本書のまとめ 　　　1　魔法の杖ではない 　　　2　アジャイルの導入をはじめる 　　　3　アジャイルのチームづくり 　　　4　改善サイクル 　　　5　BizDevOps 　　　6　最後に

複雑で変化の激しい問題に強いチームで立ち向かう。要求、見積り、進捗、問題を可視化する。ふりかえりとレビューにより、改善を繰り返す。属人化を解消し、チーム全体を成長させる。導入時に起こりがちな失敗を回避する。DeNA、GMOペパボ、mixiのノウハウを凝縮。 ソフトウェア開発の困難にスクラムで立ち向かう スクラムチーム スクラムイベント スクラムの作成物 スクラムを支えるプラクティス GMOペパボの事例-どのように導入したか mixiの事例-導入失敗からの立てなおし DeNAの事例-大規模開発、業務委託への適用 スクラム導入時によくある問題と解決策 スクラムチームでよくある問題と解決策〔ほか〕

チームづくりをストーリーで学ぼう！ スクラム・アジャイルを導入した現場で直面するチーム・マネジメントの問題解決を詳説。 「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で 直面する開発チーム・マネジメントの問題に立ち向かうすべ、 チームづくりの要点をストーリーで学ぼう！ 【本書の特徴】 ・現場のストーリーから、考え方とプラクティスを一緒に学べる ・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う ・日本の現場を前提にしているので、実践しやすい ・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適 【本書に登場するプラクティス】 出発のための3つの問い ／ 段階の設計 ／ ドラッカー風エクササイズB面 ／ 割れ窓理論 ／ フォーメーション・パターン ／ コンウェイの法則 ／ 越境のデザイン ／ 重奏型仮説検証　ほか 【あらすじ】 チームによるプロダクトづくりができる環境を求めて “太秦（うずまさ）”が転職した先は、デベロッパー向けのツールを開発、提供する、 小さなベンチャーだった。しかし会社期待のタスク管理ツールを開発するチームに 配属され、いきなりチームリーダーをつとめることに。 ……とうていチームとは呼べない“グループ”（個人活動の集合）の状態から、 本当のチームになれたと思ったのもつかの間、経営陣はタスク管理を含めた 3つのツール統合を発表。太秦はそれらプロダクトの統合を行う開発リーダーを 任されたのであった。 チームとは何か？、チームのファーストとは？、分散チームへの適応など様々な 「単一チームの問題」、複数のプロダクト統合に伴うチーム間の断絶や衝突、 チームが上手く連携できないなど様々な「複数チームの問題」……これらを乗り越え、 太秦たちがたどり着いた「ともに考え、ともにつくる」とは？ 推薦のことば ・私たちは他者を必要としている｜宇田川元一 ・その先へ！Beyond the Agile｜新井剛 第1部　僕らが開発チームになるまで─1チームのジャーニー □単一チーム 基本編 ・第01話｜グループでしかないチーム ・第02話｜一人ひとりに向き合う ・第03話｜少しずつチームになる ・第04話｜チームのファーストを変える □単一チーム 応用編 ・第05話｜チームをアップデートする ・第06話｜分散チームへの適応 ・第07話｜チームの共通理解を深める ・第08話｜一人の人間のようなチーム 第2部　僕らがプロダクトチームになるまで─複数チームによるジャーニー □複数チーム 基本編 ・第09話｜塹壕の中のプロダクトチーム ・第10話｜チーム同士で向き合う ・第11話｜チームの間の境界を正す ・第12話｜チームの境界を越えてチームをつくる □複数チーム 応用編 ・第13話｜チームとチームをつなげる ・第14話｜クモからヒトデに移行するチーム ・第15話｜ミッションを越境するチーム ・第16話｜ともに考え、ともにつくるチーム 付録　リーン・ジャーニー・スタイルのプロダクト開発

第1部 XP概要(XPとは ソフトウェア開発とは 従来の開発手法とXP XPの考え方) 第2部 開発プロセス(XP開発の流れ) 第3部 プラクティス(プラクティスの変遷 全員同席 計画ゲーム ユーザテスト 短期リリース シンプル設計 ペアプログラミング テスト駆動開発 設計改善:リファクタリング 常時結合 コード共同所有 コーディング規約 メタファ 最適ペース プラクティス以外の項目) 第4部 まとめ(XPの開発事例 XPが困難な開発 今後のXP)

アジャイル開発の概要から，エクストリーム，スクラムを使った開発プロセス，リスクマネジメント，開発事例まで網羅した指南書 アジャイル開発の指南書 アジャイル開発は従来のウォーターフォール型とは対照的に顧客にとって価値の高い機能を優先し，迅速・適応的な開発が行えるが，我国ではまだ開発手法の主流であるとはいいがたい．本書は今後導入が期待されているこのアジャイル開発の概要から，エクストリーム，スクラムを使った開発プロセス，リスクマネジメント，開発事例まで網羅した指南書とである．ソフトウェア開発者必携の書である． 1.アジャイル開発の現状と課題 2.アジャイル開発の概要 3.アジャイル開発の特徴 4.アジャイル開発プロセス 5.アジャイル開発の効果とリスク 6.上流工程を組み込んだ拡張アジャイル開発 7.アジャイル開発の事例 補遺：P2Mプログラムマネジメントとアジャイル開発 参考文献 付録1.アジャイル開発に用いられる自動化ツール 付録2.コードの不吉な匂い

小さなことをする、小さなソフトウェアチームがうまくやっていくために！ アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。 大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。 このことを、我々はあらためて認識する必要がある。 'アジャイル開発とは何か？　どうやって生まれたのか？　どのように進化したのか？　本書では、これらの質問にアンクル・ボブが答えてくれる。また、アジャイル開発に対する誤解や不正利用についても指摘している。 第1章 アジャイル入門 第2章 アジャイルにする理由 第3章 ビジネスプラクティス 第4章 チームプラクティス 第5章 テクニカルプラクティス 第6章 アジャイルになる 第7章 クラフトマンシップ

より開発を楽しく、より価値の高いソフトウェアをつくる方法を学習。 第1章 なぜアジャイルなのか?(ソフトウェア開発を「よりよくする」には? プロジェクトを「ノウハウ」からとらえる ほか) 第2章 ソフトウェアの価値とはなにか?(ソフトウェアの「価値」を考える ソフトウェア開発とは、価値を創出すること ほか) 第3章 アジャイルを現場に導入しよう(根底で求められるもの-変化を受け入れる アジャイルソフトウェア開発の全体像 ほか) 第4章 アジャイルを現場に定着させよう(アジャイルな「場」の作り方 ワークショップを活発にする「アクティビティ」 ほか) 第5章 アジャイルの本質-その原則と理論(アジャイルの本質とはなにか? アジャイルの本質と日本人) 付録

アジャイル開発はスピードの速いビジネスに迅速に対応する新しい開発手法です。今までは中小規模のプロジェクトでの採用に留まっていたアジャイル開発手法ですが、いよいよ大手ベンダーもアジャイル開発手法の導入に本腰を入れてきました。本書はこれからアジャイル開発のマネジメントをしていく方のために、導入のポイントをコンパクトにまとめたハンディな解説書です。アジャイル開発のメリットを最大限に生かし、一歩先行く開発スタイルをいち早く確立したい方のための必読書です。 1章 日本におけるソフトウェア開発の課題(日本のソフトウェア開発の実態 開発工程別の職種とプログラマ ほか) 2章 アジャイル開発手法とは(反復でビジネスリスクを制御する ビジネス視点で小さな開発を積み重ねる ほか) 3章 アジャイル開発手法導入のポイント(アジャイル開発手法導入のポイント クラウドでアジャイル開発をしよう ほか) 4章 アジャイル開発の実際(アジャイル開発の始め方 要件調整と進捗管理 ほか)

世界のエンジニアが支持するプロジェクト運営法「スクラム」。その生みの親が、あなたのチームで今すぐ実践する方法を解説。住宅リフォームから宇宙船の開発まで、あらゆる現場に革命が起きる！　

第1章 プロダクトオーナーの役割を理解する 第2章 製品を想像する 第3章 プロダクトバックログの使い方 第4章 リリース計画 第5章 スプリントミーティングの協働 第6章 プロダクトオーナーになる 付録 Salesforce.comのChris Fryへのインタビュー

治したと思っても再び蘇る「ゾンビスクラム」との戦いに辟易していませんか？本書は、あなたのスクラムの「困った」を解決します！ 　スクラムを上手く扱えていますか？世間で言われていような、あるいは想像していたようなメリットを享受することはできていますか？　実際には何ら恩恵をもたらさず、治したと思っても再び蘇る「ゾンビ」のようなスクラムとの戦いに辟易していませんか？ 　本書は、スクラムを上手く扱えていないと感じるすべての人のために書かれた、「上手くいっていない」状態から脱却することを主眼にまとめた実用書です。本の冒頭には「応急処置キット」がついているため、すべてを読んでいる暇はない人でも素早く行動を起こすことができます。応急処置を終えたら、ゾンビスクラムがなぜ起こっているかを根本的なレベルで理解し、改善に取りかかるための実践的なツールを身につけます。ユーモラスかつ非常にビジュアルな内容で、すべてのスクラムマスター、プロダクトオーナー、開発チームのメンバー、アジャイルコーチ、管理職にとって必携の書となるでしょう。 デイヴ・ウェストによる序文 ヘンリ・リプマノヴィッチによる序文 日本語版に寄せて 謝辞 著者紹介 第1章　はじめに 　この本の目的 　この本は必要？ 　この本の構成 　一刻の猶予もない！　さあ行こう！ 第2章　応急処置キット 第1部　（ゾンビ）スクラム 第3章　ゾンビスクラム入門 　スクラムの現状 　ゾンビスクラム 　　症状1：ゾンビスクラムチームはステークホルダーのニーズを知らない 　　症状2：ゾンビスクラムチームは速く出荷しない 　　症状3：ゾンビスクラムチームは（継続的に）改善しない 　　症状4：ゾンビスクラムチームは障害を克服するための自己組織化をしない 　　すべては繋がっている 　　これってカーゴカルトスクラムやダークスクラムの話？ 　ゾンビスクラムに希望はあるか？ 　実験：一緒にチームを診断する 　　手順 　　私たちの発見 　次はどうしたらいいんだ？ 第4章　スクラムの目的 　理解するカギは複雑で適応的な問題 　問題 　複雑、適応的な問題 　複雑性、不確実性、リスク 　経験主義とプロセス制御理論 　経験主義とスクラムフレームワーク 　スクラムフレームワークが可能にすること 　スクラム：常に進化している、経験的に働くための最小限のルール 　ゾンビスクラムと効率主義 　単純な問題についてはどうだろう？ 　次はどうしたらいいんだ？ 第2部　ステークホルダーが求めるものを作る 第5章　症状と原因 　なぜ、わざわざステークホルダーを巻き込む必要があるのか？ 　実際のところ、ステークホルダーは誰？ 　　価値に関する仮説の検証 　なぜ、私たちはステークホルダーを巻き込んでいないのか？ 　　プロダクトの目的をあまり理解していない 　　ステークホルダーが必要とするものを決めてかかっている 　　開発者とステークホルダーとの間に距離をとっている 　　ビジネスとITは別物と考えている 　　プロダクトオーナーが実際にプロダクトのオーナーになることを許されていない 　　価値よりもアウトプットを測る 　　開発者はコードだけ書いていればよい 　　関与しなくてもよいと思っているステークホルダーがいる 　健全なスクラム 　　誰がステークホルダーのことを理解するべきか 　　ステークホルダーをいつ巻き込むか 　次はどうしたらいいんだ？ 第6章　実験 　実験：ステークホルダーを知る 　　ステークホルダートレジャーハントを始める 　　ステークホルダーとの距離を測って透明性を作り出す 　　ステークホルダーの席をスクラムチームの近くに用意する 　　プロダクトの目的に合わせてチームの部屋を飾りつける 　実験：プロダクト開発にステークホルダーを巻き込む 　　“フィードバックパーティー”にステークホルダーを招待する 　　ユーザーサファリに行く 　　ゲリラテスト 　実験：価値あるものに集中し続ける 　　プロダクトバックログの長さを制限する 　　プロダクトバックログをエコサイクルにマップする 　　やるべき作業ではなく、望ましい成果を表現する 　次はどうしたらいいんだ？ 第3部　速く出荷する 第7章　症状と原因 　速く出荷することの恩恵 　　あなたの環境の複雑さ 　　プロダクトの複雑さ 　要するに、速く出荷しないのはゾンビスクラムのサイン 　　なぜ、私たちは十分な速さで出荷しないのか？ 　　速い出荷がリスクを減らすことを理解していない 　　計画駆動型の管理が妨げになっている 　　速く出荷することの競争優位性を理解していない 　　速い出荷の阻害要因を取り除かない 　　スプリントで扱うアイテムが非常に大きい 　健全なスクラム 　　リリースするかしないかを決断する 　　リリースはもはやゼロイチではない 　　スプリント中に出荷する 　　「ビッグバン」リリースはもうしない 　次はどうしたらいいんだ？ 第8章　実験 　透明性と危機感を生み出す実験 　　継続的デリバリーに投資するための説得材料を集める 　　リードタイムとサイクルタイムを測る 　　ステークホルダーの満足度を測る 　もっと頻繁に出荷するための実験 　　インテグレーションとデプロイ自動化への第一歩を踏み出す 　　完成の定義を強化する 　　スプリントごとに出荷する 　　ゴールを達成するためにパワフルクエスチョンを使う 　フローを最適化するための実験 　　スキルマトリックスでクロスファンクショナルを強化する 　　仕掛中の作業を制限する 　　プロダクトバックログアイテムをスライスする 　次はどうしたらいいんだ？ 第4部　継続的に改善する 第9章　症状と原因 　なぜ、わざわざ継続的に改善する必要があるのか？ 　　継続的改善とは何か？ 　　継続的改善かアジャイルトランスフォーメーションか？ 　なぜ、継続的に改善しないのか？ 　　ゾンビスクラムでは、失敗に価値を置かない 　　ゾンビスクラムでは、具体的な改善をしていない 　　ゾンビスクラムでは、失敗するための安全性を作らない 　　ゾンビスクラムでは、成功を祝わない 　　ゾンビスクラムでは、仕事における人間的要素を理解していない 　　ゾンビスクラムでは、仕事のやり方を批評しない 　　ゾンビスクラムでは、仕事と学習は別と考える 　健全なスクラム 　　自己批判的なチーム 　　木を見て、森も見る 　次はどうしたらいいんだ？ 第10章　実験 　深い学習を促すための実験 　　阻害要因ニュースレターを組織内で共有する 　　スプリントレトロスペクティブでパワフルクエスチョンを使う 　　問題点と解決策を一緒に深く掘り下げる 　改善を具体化するための実験 　　15% ソリューションを生み出す 　　何をやめるかに焦点を当てる 　　改善レシピを作成する 　新しい情報を集めるための実験 　　公式・非公式のネットワークを利用して変革を促す 　　ローテクな指標ダッシュボードを作成し成果を追跡する 　学習環境を整える実験 　　成功体験を共有し、それを基に事を進める 　　お祝いケーキを焼く 　次はどうしたらいいんだ？ 第5部　自己組織化する 第11章　症状と原因 　なぜ、わざわざ自己組織化する必要があるのか？ 　　自己組織化とは何か？ 　　シンプルなルールによる自己組織化 　　自己管理による自己組織化 　　自己組織化は複雑な世界におけるサバイバルスキル 　　要するに 　なぜ、私たちは自己組織化しないのか？ 　　ゾンビスクラムでは、自己管理が十分にできていない 　　ゾンビスクラムでは、市販の解決策を使う 　　ゾンビスクラムでは、スクラムマスターがすべての阻害要因を解決していく 　　ゾンビスクラムでは、スクラムマスターはスクラムチームだけに集中する 　　ゾンビスクラムでは、ゴールがないか、押し付けられている 　　ゾンビスクラムでは、作業環境を外部記憶として使わない 　　ゾンビスクラムでは、標準化が妨げになっている 　健全なスクラム：自己組織化とはどのようなものか 　　スクラムチームはプロダクトに対する自律性を持つ 　　管理職がスクラムチームを支援する 　次はどうしたらいいんだ？ 第12章　実験 　自律性を高める実験 　　パーミッショントークンで自律性の低さによるコストを可視化する 　　統合も自律も高める行動を見つけ出す 　　ルールを壊す！ 　自己組織化を促進する実験 　　自己組織化のための最小限のルールを見つける 　　助けてほしい気持ちをはっきりと言葉にする 　　何が起きているか観察する 　自己アラインメントを促す実験 　　パワフルクエスチョンでもっとよいスプリントゴールを作る 　　物理的なスクラムボードを使う 　現場での解決策を見つける 　　阻害要因を話し合うスクラムマスターの集いを開催する 　　オープンスペーステクノロジーで現場での解決策を作る 　次はどうしたらいいんだ？ 第13章　回復への道 　グローバルな活動 　どうにもならない場合は？ 　さらなる参考情報 　さいごに 訳者あとがき 参考文献 索引

* Teaches how to write good tests * Uses state-of-the-art open source software * Offers real-world insights from an expert author Code is written by humans who make mistakes UPSILONV hence bugs and the need for testing. Savvy Java developers know that not all testing is created equal. In addition to traditional functional testing, many shops are adopting developer testing techniques such as unit testing. Specific, automated tests are created to verify the accuracy and function of code while or even before itUPSILON s written UPSILONV to catch bugs early. Unit Testing in Java teaches how to write good tests that are concise and to the point, useful, and maintainable. This book focuses on tools and practices specific to Java. It introduces emerging techniques like specification by example and behavior-driven development, and shows how to add robust practices into developers toolkits.

デジタル化で人間性が軽視されつつある中、心理的に安全なチームを築くカギとは。『恐れのない組織』のエドモンドソン氏のお墨つき。 心理的安全性がない組織には、未来もない。 職場の恐怖を取り除き、幸福と成果を約束する！ 【序文】 エイミー・C・エドモンドソン （心理的安全性の権威、『恐れのない組織』著者） 【内容紹介】 デジタル時代にチームワークを生み出す最重要な要素は、 「心理的安全性」と「アジャイル」である。 様々な業務がデジタル化・自動化・遠隔化され、 現代の職場から人間性が失われてきた。 そんな中で組織が競争力を保つには、 健全に働けるチームづくりが不可欠だ。 実際のところ、社会のデジタル化を推し進めてきた 巨大IT企業からは、社員＝人がのびのびと働く様子が聞こえてくる。 彼らは一体何が違うのか。それは真似できないのか。 予測不可能なVUCA世界でも有効な考え方がここにある。 コロナパンデミック後の働き方の理想像も追う。 【心理的安全性とデジタル化を共存させるキーワード】 ・信頼、学習、実験 ・リモートとフレックス ・柔軟性と回復力 ・EQ（感情指数） ・印象操作の回避 ・人的負債の削減 【巻末インタビュー】 ジーン・キム （『The DevOps 逆転だ！』著者） 【目次】 エイミー・エドモンドソン教授による序文 第1章　今日の仕事、明日の仕事 第2章　プロセス vs. 人 第3章　チームと好業績の探求 第4章　心理的安全性――高いパフォーマンスのための唯一のスイッチ 第5章　心理的安全性と感情指数を数字に置き換える 第6章　ソフトスキルは難しい（ハード） 第7章　次になにが起こるのか、そしてパンデミック以降の世界での働き方 特別付録　ジーン・キムへのインタビュー エイミー・エドモンドソン教授による序文 第1章　今日の仕事、明日の仕事 ・VUCA、デジタル・ディスラプションとテクノロジーのスピード ・「人的負債」 ・組織 ―― 人、チーム ・明瞭さを手に入れる ・「発言できる」文化 ―― 連携のために真の対話を生み出す ・本当の「ToDo」リストを作る ・人事を再び偉大にする ・許可を与える ・チームに重点を置く ・真にアジャイルになる ―― WoWのためのWoT 第2章　プロセス vs. 人 ・新しい働き方と考え方 ・新しい働き方は新しくない ・アジャイルではないもの ・デザインによる、または「トランスフォーメーション」によるアジャイル ・WoT（考え方）なくしてWoW（働き方）なし ・アジャイルと人 ・なぜアジャイルが難しいのか ・アジャイルのスーパーヒーローたち ・アジャイル、DevOps、WoW、そして「人的負債」の削減 第3章　チームと好業績の探求 ・チームとはなにか？ ・現代のチームと新しい働き方 ・リーダーシップ2.0 ・形成期――チームの立ち上げ、カルチャーキャンバス、契約作成、共同作業 ・混乱期――健全な対立、真の対話と機能不全 ・規範期、成就期、ハイパフォーミング：チーミングおよびリチーミング――チーム構成vs.チームダイナミクス ・プロジェクト・アリストテレス 第4章　心理的安全性――高いパフォーマンスのための唯一のスイッチ ・心理的安全性 ―― 高いパフォーマンスのための唯一のスイッチ ・経営陣における心理的安全性 ・心理的安全性ではないもの ・信頼 ・「柔軟性」と「回復力」 ・意見を言う、すなわち「勇気」と「オープンさ」 ・「学習」―― 学び、実験し、失敗する ・士気と「やる気」 ・印象操作を回避する ・バブルでの対話 ・チームの幸福と人的負債 第5章　心理的安全性と感情指数を数字に置き換える ・人的負債を削減する ・行動的基礎 ・チームへの介入と改善 ――「人間中心の行動」 ・さまざまな業界からの教訓 ・ビジネスではなぜ数字を見る前に人とチームのことを気にかけないのか ・実験しようとする実験 ・大きく勝利するために小さく、しつこく、頻繁に測定する 第6章　ソフトスキルは難しい（ハード） ・ハードスキルと未来 ・職場における感情 ・IQ vs. EQ ・勇気と脆弱さ ・情熱と目的 ・「数字で共感力」は実現できるか？ ・人間らしくある許可 ・「人間中心の行動」 ・チームの枠を超えて 第7章　次になにが起こるのか、そしてパンデミック以降の世界での働き方 ・2020年のパンデミック ・リモートvs.柔軟（どこでvs.どうやって） ・新しい現実を共にデザインする ・突然のリモートへの移行の影響 ・リモートとワークライフバランス ・世界的不況の中でのVUCAなデジタル世界における生産性とパフォーマンス ・パンデミック以降の世界での働き方 ・次に仕事とチームに待ち受けているものは？ 特別付録　ジーン・キムへのインタビュー 用語集

開発者必読のロングセラー『コードコンプリート』の著者マコネルが推奨するアジャイル実践法を公開。 開発者必読のロングセラー『Code Complete（コードコンプリート）』の著者として著名なスティーブ・マコネルの新刊が15年ぶりに登場！　本書は“More Effective Agile: A Roadmap for Software Leaders”（Construx Press、2019年）の日本語版です。企業活動やビジネスが今後ますます「ソフトウェアファースト（ソフトウェア主導）」になっていく中で、リーダーシップを発揮できる人材である「ソフトウェアリーダー」を目指すために、アジャイルから「価値を引き出す」ための実践的なプラクティスを解説します。監訳者にはアジャイル分野で著名であり、『Adaptive Code（旧名『C#実践開発手法』）』で実績のある長沢智治氏を起用しました。 本書に寄せて 謝辞 Part 1　より効果的なアジャイル 第1章　はじめに 1.1 効果的なアジャイルはなぜ重要か 1.2 本書の対象読者 1.3 他のアジャイル本との違い 1.4 本書の構成 1.5 あなたの意見をお聞かせください 第2章　アジャイルの本当の違いは何か 2.1 アジャイルの恩恵の源は何か 2.2 アジャイルの境界 2.3 推奨リーダーシップアクション 2.4 参考文献 第3章　複雑さと不確実さという課題に対処する 3.1 Cynefin 3.2 複雑系のプロジェクトを成功させる：OODA 3.3 基本原則：検査と適応 3.4 推奨リーダーシップアクション 3.5 参考文献 Part 2　より効果的なチーム 第4章　より効果的なアジャイルの始まり：スクラム 4.1 基本原則：スクラムから始める 4.2 スクラムとは何か 4.3 スクラムの基本 4.4 スクラムロール 4.5 スクラムの一般的な失敗モード 4.6 スクラムの失敗モードの共通点 4.7 スクラムの成功要因 4.8 成功するスプリント 4.9 一般的なスプリントの時間配分 4.10 スクラムへの移行の問題 4.11 スクラムのスコアカード 4.12 スクラムでの検査と適応：デイリースクラム 4.13 その他の検討課題 4.14 推奨リーダーシップアクション 4.15 参考文献 第5章　より効果的なアジャイル：チーム構造 5.1 基本原則：機能横断的チームの結成 5.2 テスト技術者の組織化 5.3 基本原則：テスト技術者を開発チームに統合する 5.4 プロダクションサポートの組織化 5.5 ブラックボックスとしてのアジャイルチーム 5.6 組織はアジャイルのチームづくりに前向きか 5.7 その他の検討課題 5.8 推奨リーダーシップアクション 5.9 参考文献 第6章　より効果的なアジャイル：チーム文化 6.1 基本原則：自律、熟達、目的によるチームの動機付け 6.2 基本原則：成長マインドセットを培う 6.3 基本原則：ビジネスフォーカスを培う 6.4 その他の検討課題 6.5 推奨リーダーシップアクション 6.6 参考文献 第7章　より効果的なアジャイル：分散チーム 7.1 基本原則：よりタイトなフィードバックループ 7.2 分散アジャイルチームの成功を目指して 7.3 基本原則：人ではなく仕組みを修正する 7.4 その他の検討課題 7.5 推奨リーダーシップアクション 7.6 参考文献 第8章　より効果的なアジャイル：個人および対話 8.1 個人重視のポテンシャル 8.2 基本原則：個人のキャパシティを向上させることでチームのキャパシティを向上させる 8.3 より効果的な対話（チーム） 8.4 推奨リーダーシップアクション 8.5 参考文献 Part 3　より効果的な作業 第9章　より効果的なアジャイル：プロジェクト 9.1 基本原則：プロジェクトを小さく保つ 9.2 基本原則：スプリントを短く保つ 9.3 ベロシティベースのプランニング 9.4 基本原則：バーティカルスライスでのデリバリー 9.5 基本原則：技術的負債を管理する 9.6 バーンアウトを回避する作業構造 9.7 その他の検討課題 9.8 推奨リーダーシップアクション 9.9 参考文献 第10章　より効果的なアジャイル：大規模なプロジェクト 10.1 大規模なプロジェクトにおけるアジャイルの本当の違いとは 10.2 大規模なプロジェクトにおけるアジャイルの重点 10.3 ブルックスの法則 10.4 コンウェイの法則 10.5 基本原則：アーキテクチャを通じて大規模なアジャイルプロジェクトをサポートする 10.6 大規模なプロジェクトではコラボレーションの種類が変化する 10.7 大規模なプロジェクトでの協調性の課題 10.8 大規模なアジャイルプロジェクトのスコアカード 10.9 スクラムから始める 10.10 その他の検討課題 10.11 推奨リーダーシップアクション 10.12 参考文献 第11章　より効果的なアジャイル：品質 11.1 基本原則：欠陥検出のギャップを最小化する 11.2 基本原則：完成の定義を作成し、使用する 11.3 基本原則：リリース可能な品質水準を維持する 11.4 手戻りを減らす 11.5 その他の検討課題 11.6 推奨リーダーシップアクション 11.7 参考文献 第12章　より効果的なアジャイル：テスト 12.1 基本原則：開発チームが作成した自動テストを使用する 12.2 効果的なアジャイルテストに対するその他の秘訣 12.3 その他の検討課題 12.4 推奨リーダーシップアクション 12.5 参考文献 第13章　より効果的なアジャイル：要求の作成 13.1 アジャイル要求のライフサイクル 13.2 アジャイル要求では何が異なるのか 13.3 Cynefinと要求作業 13.4 アジャイル要求：ストーリー 13.5 アジャイル要求のコンテナ：プロダクトバックログ 13.6 プロダクトバックログに要求を追加する方法 13.7 基本原則：プロダクトバックログのリファインメント 13.8 基本原則：準備完了の定義を作成し、使用する 13.9 その他の検討課題 13.10 推奨リーダーシップアクション 13.11 参考文献 第14章　より効果的なアジャイル：要求の優先順位付け 14.1 プロダクトオーナー 14.2 Tシャツのサイズ分け 14.3 ストーリーマッピング 14.4 その他の検討課題 14.5 推奨リーダーシップアクション 14.6 参考文献 第15章　より効果的なアジャイル：デリバリー 15.1 基本原則：繰り返し行う作業を自動化する 15.2 継続的インテグレーションと継続的デリバリーを支援するプラクティス 15.3 継続的インテグレーションと継続的デリバリーの利点 15.4 その他の検討課題 15.5 推奨リーダーシップアクション 15.6 参考文献 Part 4　より効果的な組織 第16章　より効果的なアジャイル：リーダーシップ 16.1 基本原則：細部ではなく成果を管理する 16.2 基本原則：「司令官の意図」を使って目的を明確に表現する 16.3 基本原則：活動ではなくスループットに焦点を合わせる 16.4 基本原則：鍵となるアジャイルな振る舞いをモデル化する 16.5 推奨リーダーシップアクション 16.6 参考文献 第17章　より効果的なアジャイル：組織文化 17.1 基本原則：間違いを許す 17.2 心理的安全性 17.3 基本原則：チームキャパシティの計測に基づいたプランニング 17.4 プラクティスコミュニティを確立する 17.5 より効果的なアジャイルを支援する上での組織の役割 17.6 推奨リーダーシップアクション 17.7 参考文献 第18章　より効果的なアジャイル：計測 18.1 作業の量を計測する 18.2 作業の品質を計測する 18.3 計測全般に関する検討課題 18.4 その他の検討課題 18.5 推奨リーダーシップアクション 18.6 参考文献 第19章　より効果的なアジャイル：プロセス改善 19.1 スクラム：プロセス改善のベースライン 19.2 生産性を向上させる 19.3 原理原則に従って仕掛かり作業をマッピングし、監視する 19.4 アジャイルのレトロスペクティブ 19.5 計測ごっこに注意 19.6 検査と適応 19.7 その他の検討課題 19.8 推奨リーダーシップアクション 19.9 参考文献 第20章　より効果的なアジャイル：予測可能性 20.1 リリースサイクルの違いによる予測可能性 20.2 予測可能性の種類 20.3 コストとスケジュールの厳密な予測可能性 20.4 フィーチャーセットの厳密な予測可能性 20.5 予測可能性に対するより大まかなアプローチ 20.6 予測可能性と柔軟性 20.7 その他の検討課題 20.8 推奨リーダーシップアクション 20.9 参考文献 第21章　より効果的なアジャイル：規制産業 21.1 アジャイルは規制産業での作業をどのように支援するか 21.2 スクラムは規制産業での作業をどのように支援するか 21.3 規制環境のアジャイルの境界 21.4 その他の検討課題 21.5 推奨リーダーシップアクション 21.6 参考文献 第22章　より効果的なアジャイル：ポートフォリオマネジメント 22.1 WSJF 22.2 その他の検討課題 22.3 推奨リーダーシップアクション 22.4 参考文献 第23章　より効果的なアジャイル：導入 23.1 変革の大まかなアプローチ 23.2 ドミノ変革モデル 23.3 組織全体に改革を行き渡らせる 23.4 続：上空40,000フィートから見たロールアウト 23.5 検査と適応 23.6 推奨リーダーシップアクション 23.7 参考文献 Part 5　おわりに 細工は流々、仕上げを御覧じろ 28の基本原則のまとめ 監訳者あとがき 参考文献

企業の経営層に向けてソフトウェア開発手法の「アジャイル」とその手法の一つである「スクラム」を体系的に解説。スクラムはソフトウェア開発のみならず、組織や企業活動、企業経営全体にまで適用できることを提示する。さらに、この手法を取り入れ、ビジネスと一体になってソフトウェアを開発する組織や、その組織に息を吹き込む、新しいタイプのリーダーシップ像についても考える。日本におけるアジャイル開発の第一人者と世界的な経営学者・スクラム産みの親による提言。業界をリードするリクルート・富士通・楽天の最新開発事例を収録。 第1部 アジャイル開発とは何か、スクラムとは何か(アジャイル開発とは何か? なぜ、アジャイル開発なのか スクラムとは何か? アジャイル開発の活動(プラクティス)) 第2部 アジャイル開発とスクラムを実践する(スピード時代に独自のアジャイル手法ワンチームマインドで挑むリクルート 小さく始めて浸透させる-楽天のアジャイルによる組織改革 「IT新市場」におけるアジャイル開発に取り組む富士通の挑戦) 第3部 アジャイル開発とスクラムを考える(竹内・野中のスクラム論文再考 スクラムと知識創造 スクラムと実践知リーダー)

スクラムの実践において、様々な課題に対処してきた実践者が経験や考え方を語るエッセイ集。体験談、仕事への適用、調整方法を学ぶ。 スクラムを実践してきた著名人が寄せたエッセイ集！ スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じて様々です。本書はスクラムの実践において、様々な課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。フレームワークのルールや役割、戦略、またスクラムで使うべきパターン、現場での体験談など紹介し、またスクラムを仕事に適用したり、調整する方法について学べます。

アジャイル開発における各プロセスを可視化し、問題点の抽出と解決方法を定量化する手法 開発に関わる全工程の詳細を定量化し より強く、より高パフォーマンスなチームへ 【本書の内容】 本書は Christopher W.H.Davis, "Agile Metrics in Action", Manning Publications 2015 の邦訳版です。 アジャイル開発は、その特性である「反復」によって、経験に基づく継続的な改善に最適な開発手法です。 この手法に、追跡システム、テストおよびビルドツール、ソース管理、継続的統合、およびプロジェクト ライフサイクルといったさまざまなコンセプトとツールを援用することで、製品やプロセス、 さらにはチームそのもののパフォーマンス改善できる豊富なデータを入手できます。 本書は、そういった実際に生成されるデータを計測し、結果を的確に分析し、効果的な対処法を指南してくれます。 パフォーマンスや進捗度合いなどを定量化することで、経験値による知見だけではなく、 より合意しやすいチームへと組織や方法論を改善してくれることでしょう。 【読者が得られること】 ・プロセスやタスクを定量化できるようになる ・定量化したデータから現状を正確に把握できるようになる ・コミュニケーション、生産性、透明性、士気を向上させる ・客観的にパフォーマンスを測定する 【著者について】 Christopher W. H. Davis（クリストファー・M・H・デイビス） ソフトウェアエンジニア。20年以上にわたり、旅行、金融、ヘルスケア、通信、製造業などの分野で開発チームのリーダーを務め、 世界中のさまざまな環境で多様なチームを率いてきました。 熱心なランナーでもあるクリスは、妻と2人の子供とともに、オレゴン州ポートランドの美しく雄大な太平洋岸北西部を満喫しています。 目次 第1部　アジャイルチームを測定する 　　第1章　アジャイルパフォーマンスを測定する 　　第2章　生きたプロジェクトを観察する 第2部　チームのデータの収集と分析 　　第3章　プロジェクト管理システムからのデータと傾向 　　第4章　ソースコード管理 　　第5章　継続的インテグレーションおよびデプロイからのデータと傾向 　　第6章　本番環境から届くデータ 第3部　メトリクスをチーム・プロセス・ソフトウェアに適用する 　　第7章　収集したデータの扱い：データの集約 　　第8章　ソフトウェア品質を測定する 　　第9章　メトリクスの公開 　　第10章　アジャイルの原則に照らし合わせてチームを測定する

10年以上のロングセラーとなっているシステム設計レビューの解説書、待望の増補三訂版。AIシステム、アジャイル開発に対応 10年以上のロングセラーとなっているシステム設計レビューの解説書、待望の増補三訂版。AIシステム、アジャイル開発に対応 　失敗レビューを防ぐワザ、この1冊ですべて学べます！　「要件定義書や設計書などのドキュメントレビューに時間をかけているのに、重大な問題を見逃してしまう」「どうでもいい問題の指摘ばかり」「なかなか問題を出し切れず、夜遅くまで会議が続く」「人格を攻撃するレビューアーが出てくる」――。　検出した問題を指摘し、よりよいシステムを作り上げるためのレビュー会議が、どうも適切に運営できない。そんな経験はありませんか。原因は、間違ったレビューのやり方にあります。ITエンジニア出身で、現在は研究者として企業とレビューの共同研究に長年取り組む著者が、失敗レビューを防ぐワザの数々を紹介します。　例えば、重大な見逃しを防ぐ「問題種別の設定」、1時間で問題を出し切る「ゴール確認」、的確な意見を引き出す「指針となるシナリオ」、意識合わせを促す「ウオークスルー」といったワザを詳しく解説しています。これらのワザを取り入れることで、適切な時間で重大な問題を漏らさず見つけ出すレビュー会議に変わるはずです。　本書は10年以上のロングセラーとなっている設計レビューの手順書の第3版です。第3版では、システム開発の現場で近年重要性が増している「人工知能（AI）システム」や「アジャイル開発」におけるレビューの手順などを新たに盛り込みました。 第1章 レビューの間違い 1-1 レビューの目的の間違い 1-2 問題検出の間違い 1-3 問題指摘の間違い（方法編） 1-4 問題指摘の間違い（マインド編） 第2章 準備と問題検出 2-1 レビューの準備（リーダー、作成者） 2-2 レビューの準備（レビューアー） 2-3 問題検出の手順 第3章 レビュー会議の進め方 3-1 問題指摘の手順（前半） 3-2 問題指摘の手順（後半） 3-3 問題の修正・フォロー 3-4 レビュー技法 第4章 さらなる効果向上 4-1 レビューの改善・効率化 4-2 問題種別の設定対象を広げる 4-3 保守開発、クラウド開発への応用 4-4 AIシステムへの応用 4-5 アジャイル開発への応用 付録 レビュー観点絞り込みの効果 参考文献 索引