【ご紹介】書籍「スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-」
スタッフの山本です。
頂いた書籍をご紹介します。
なお、いただいた書籍は、4/23(土)に開催する「名古屋アジャイルまつり DevOps編」（告知・参加申し込みページ：http://nagoyaagile.connpass.com/event/29154/ ）の参加者に抽選でプレゼントします。
以下、山本の感想を含む、本書の各章の概要です。
ジム・ハイスミス（アジャイル関連著書を多く持つソフトウェア開発方法論者）による序文
スクラムに初めて取り組むチームの多くが、スクラムのシンプルさにつまづく。本書は、華麗なシンプルさから効果ある実践的な姿への移行を導く。
スクラムに初めて取り組むチームの多くが、スクラムのシンプルさにつまづく。本書は、華麗なシンプルさから効果ある実践的な姿への移行を導く。
ジェフ・サザーランド（スクラムの提唱者）による序文
アジャイルマニフェストから10年、起草者と主要なアジャイル推進者が集まり、10年間のふりかえりを行なった。そこで、以下の要素がこれからの10年の成功に必要であると合意した。
1. 技術的卓越の追求
2. 個人の変化の支援と、組織の変化の推進
3. 知識の整理と教育の改善
4. プロセス全体における価値創造の最大化
スクラム導入は改善を引き起こすが、上記を重視して取り組むことでより大きな成果を生むだろう。本書はそれをサポートする。
アジャイルマニフェストから10年、起草者と主要なアジャイル推進者が集まり、10年間のふりかえりを行なった。そこで、以下の要素がこれからの10年の成功に必要であると合意した。
1. 技術的卓越の追求
2. 個人の変化の支援と、組織の変化の推進
3. 知識の整理と教育の改善
4. プロセス全体における価値創造の最大化
スクラム導入は改善を引き起こすが、上記を重視して取り組むことでより大きな成果を生むだろう。本書はそれをサポートする。
補足資料
著者が実際に利用したツールやテンプレートをWebで提供している。
著者が実際に利用したツールやテンプレートをWebで提供している。
著者紹介
ゲーム会社でテスト技術者としてキャリアをスタートし、テストマネージャ、開発者等を経験した後、プロジェクトマネージメントとプログラムマネジメントに就いた。Microsoft社でWindows Liveのサービス開発を管理する経歴を経て、コンサルタントとして独立。
Agile2012およびAgile2014のチェアパースン、Scrum AllianceとAgile Allianceの取締役を勤めた。
ゲーム会社でテスト技術者としてキャリアをスタートし、テストマネージャ、開発者等を経験した後、プロジェクトマネージメントとプログラムマネジメントに就いた。Microsoft社でWindows Liveのサービス開発を管理する経歴を経て、コンサルタントとして独立。
Agile2012およびAgile2014のチェアパースン、Scrum AllianceとAgile Allianceの取締役を勤めた。
1章 スクラム:シンプルだが簡単ではない
「スクラムを導入したがあまりうまくいっていない」チームの物語。表面的なところ、例えば短いリリース間隔、だけを真似ているが、なぜそのような活動を行なうかを理解せず、導入以前の慣れ親しんだやり方をベースにしている。結果として、スクラムが狙っていることが実現しておらず、効果もでていない。
スクラムはウォーターフォールとは大きく異なるため、それを始めるときには不安になるものだ。十分な理解と支援、準備期間が必要。
「スクラムを導入したがあまりうまくいっていない」チームの物語。表面的なところ、例えば短いリリース間隔、だけを真似ているが、なぜそのような活動を行なうかを理解せず、導入以前の慣れ親しんだやり方をベースにしている。結果として、スクラムが狙っていることが実現しておらず、効果もでていない。
スクラムはウォーターフォールとは大きく異なるため、それを始めるときには不安になるものだ。十分な理解と支援、準備期間が必要。
第1部 準備
2章 仲間と共に旅立つには
新しいやり方を組織に導入するにはコツがある。必ず抵抗はあり闇雲に進めればそれは強まる。
2章 仲間と共に旅立つには
新しいやり方を組織に導入するにはコツがある。必ず抵抗はあり闇雲に進めればそれは強まる。
3章 チームコンサルタントでチームの生産性を最適化する
コアチームとコンサルタント（コンサルタントプールからスポット参加する）でプロジェクトを進めるモデルの紹介と、それを通じて柔軟な人材活用を意識することの勧め。
コアチームとコンサルタント（コンサルタントプールからスポット参加する）でプロジェクトを進めるモデルの紹介と、それを通じて柔軟な人材活用を意識することの勧め。
4章 ベロシティの測定
初期見積りとベロシティの求め方の解説と例。
初期見積りとベロシティの求め方の解説と例。
6章 スプリントの長さを決める
スプリントの長さを決める方法、考慮すべき点。フィードバック駆動。
スプリントの長さを決める方法、考慮すべき点。フィードバック駆動。
7章 完成を知る
完成の定義の具体例、定義の作り方。
定義の運用とグルーミングについても触れて欲しかった。
完成の定義の具体例、定義の作り方。
定義の運用とグルーミングについても触れて欲しかった。
第2部 現場の基本
9章 エンジニアリングプラクティスのスクラムにおける重要性
TDD、ペアプロ、CI等の技術系プラクティスの有用性とその理由。ここは技術者側からの抵抗と管理上の抵抗のあるところなので、個別の事例をよく分析して考察すべきところ。
9章 エンジニアリングプラクティスのスクラムにおける重要性
TDD、ペアプロ、CI等の技術系プラクティスの有用性とその理由。ここは技術者側からの抵抗と管理上の抵抗のあるところなので、個別の事例をよく分析して考察すべきところ。
10章 チームのコアタイム
勤務時間の裁量が各自に任されているチームには、コアタイムを導入するといい。
これはコアタイムだけの話ではないと思う。仕事に関する習慣や常識観が対立したときにどうするか、という話。アジャイル開発ではアソビが少ないので、対立が起きやすい。それは意図したものなので、よいことと捉えて対処すればいい。
勤務時間の裁量が各自に任されているチームには、コアタイムを導入するといい。
これはコアタイムだけの話ではないと思う。仕事に関する習慣や常識観が対立したときにどうするか、という話。アジャイル開発ではアソビが少ないので、対立が起きやすい。それは意図したものなので、よいことと捉えて対処すればいい。
11章 リリースプランニング
見積りと計画作りの話。利害関係者の理解を得ることができるか、に尽きると再確認。
見積りと計画作りの話。利害関係者の理解を得ることができるか、に尽きると再確認。
12章 ストーリーやタスクを分割する
しばしば話題に上る分割の話。具体的な例がありがたい。
しばしば話題に上る分割の話。具体的な例がありがたい。
13章 欠陥を抑制する
欠陥マネジメント、品質の作りこみ。ここでもトヨタ生産方式でいうところの「ダンゴ生産」ベースの考え方から離れることの難しさが描かれている。この古い考え方は様々な立場の人の様々な知識・経験・価値観の中に入り込んでいるので、これを取り除くことはとても難しい。挑戦の意欲と安心が必要。
欠陥マネジメント、品質の作りこみ。ここでもトヨタ生産方式でいうところの「ダンゴ生産」ベースの考え方から離れることの難しさが描かれている。この古い考え方は様々な立場の人の様々な知識・経験・価値観の中に入り込んでいるので、これを取り除くことはとても難しい。挑戦の意欲と安心が必要。
14章 サステインドエンジニアリングとスクラム
保守と開発を両立するための方法。保守対応の時間をあらかじめ確保しておく方法と、保守専任チームと開発チームに分ける方法の二つを紹介。それぞれメリットデメリットがある。
保守と開発を両立するための方法。保守対応の時間をあらかじめ確保しておく方法と、保守専任チームと開発チームに分ける方法の二つを紹介。それぞれメリットデメリットがある。
16章 ふりかえり
プロジェクトの状態が厳しくなるとまずふりかえりを止めたくなるが、けしてそうすべきではない理由と、そうしないためのよりよいふりかえりのヒント。検査と適応とはどういうことか具体的に理解させてくれる。
プロジェクトの状態が厳しくなるとまずふりかえりを止めたくなるが、けしてそうすべきではない理由と、そうしないためのよりよいふりかえりのヒント。検査と適応とはどういうことか具体的に理解させてくれる。
第3部 救急処置
17章 生産的なデイリースタンドアップ
デイリースクラム（朝会）のアンチパターンとその対処方法。朝会は比較的よく知られたアクティビティで、始めることは難しくない。しかし、その狙いを理解共有して、価値あるものとして行ない続けることは難しい。
17章 生産的なデイリースタンドアップ
デイリースクラム（朝会）のアンチパターンとその対処方法。朝会は比較的よく知られたアクティビティで、始めることは難しくない。しかし、その狙いを理解共有して、価値あるものとして行ない続けることは難しい。
19章 ペアプログラミング
ペアプログラミングの効果については疑う余地がないが、実際にはこのプラクティスを好かない人や、うまく取り入れられないチームも多い。心理学的なアプローチでより効果を上げるいくつかの工夫を紹介する。
ペアプログラミングの効果については疑う余地がないが、実際にはこのプラクティスを好かない人や、うまく取り入れられないチームも多い。心理学的なアプローチでより効果を上げるいくつかの工夫を紹介する。
20章 新しいチームメンバー
新しいメンバーを追加する際に、最短でチームのやり方とプロダクトについて正しく理解し会得してもらう方法の紹介。新しいメンバーにも、チームにも負担はある。自然に慣れるのを待つのは時間がかかるうえ正しい理解を得られないリスクがある。ここにおいても経験主義、検査と適応というスクラムの基本原則が見て取れる。
新しいメンバーを追加する際に、最短でチームのやり方とプロダクトについて正しく理解し会得してもらう方法の紹介。新しいメンバーにも、チームにも負担はある。自然に慣れるのを待つのは時間がかかるうえ正しい理解を得られないリスクがある。ここにおいても経験主義、検査と適応というスクラムの基本原則が見て取れる。
21章 文化の衝突
前章の別物語。人の問題は特に、単純な正解はない。関係者が経験を元に話し合い、よりよい方法を模索していくことが重要だろう。
前章の別物語。人の問題は特に、単純な正解はない。関係者が経験を元に話し合い、よりよい方法を模索していくことが重要だろう。
22章 スプリント緊急手順
あまり語られることのない、スプリントの中断という方法についての説明。すべての基盤にコミュニケーションがあると強調されている点にも着目したい。
あまり語られることのない、スプリントの中断という方法についての説明。すべての基盤にコミュニケーションがあると強調されている点にも着目したい。
第4部 上級サバイバルテクニック
23章 持続可能なペース
妥当な生産性とはどういうことか、という問いに応えることは難しい。しかし今はまず、（効率的ではなく）効果的になること。顧客価値に結びつかない作業を減らすこと。それにはプロセスの見直しが必要であり、マネジメントに対する教育が必要になる。大変な仕事だ。
23章 持続可能なペース
妥当な生産性とはどういうことか、という問いに応えることは難しい。しかし今はまず、（効率的ではなく）効果的になること。顧客価値に結びつかない作業を減らすこと。それにはプロセスの見直しが必要であり、マネジメントに対する教育が必要になる。大変な仕事だ。
24章 動作するソフトウェアを届ける
この章はとても基本的なことを述べている。ステークホルダーにイテレーション毎のフィードバックを約束させるにはどうしたらいいか、といった現実的な問題に対する示唆が欲しいと感じた。
この章はとても基本的なことを述べている。ステークホルダーにイテレーション毎のフィードバックを約束させるにはどうしたらいいか、といった現実的な問題に対する示唆が欲しいと感じた。
25章 価値の測定と最適化
チームがなにに時間を使っているか測定し、それをステークホルダーに公開し、理解と改善のヒントを得ること。これは難しいテーマだる。妥当な生産性とはどのように定められるべきものなのか。この章のストーリーのように、客観的論理的に皆が関わりあえるか。
チームがなにに時間を使っているか測定し、それをステークホルダーに公開し、理解と改善のヒントを得ること。これは難しいテーマだる。妥当な生産性とはどのように定められるべきものなのか。この章のストーリーのように、客観的論理的に皆が関わりあえるか。
26章 プロジェクトのコストを事前に考える
相対見積り、幅のある予想、実績に基づいて更新されること。しもべとしてのコミットメントではなく、パートナーとしての予測であるということ。そのことを関係者と共有するとりくみのために、本章はまず理想の形を示した。
相対見積り、幅のある予想、実績に基づいて更新されること。しもべとしてのコミットメントではなく、パートナーとしての予測であるということ。そのことを関係者と共有するとりくみのために、本章はまず理想の形を示した。
27章 スクラムにおけるドキュメント
ドキュメント作成のフローを見直そう。ウォーターフォールに最適化されたやり方が常に最善ではない。本章では触れられていないが、事前設計を文書でレビューするという方法を手放す不安を関係者が持つ場合がある。関係者の不安を払拭するベターなやり方を模索しよう。
ドキュメント作成のフローを見直そう。ウォーターフォールに最適化されたやり方が常に最善ではない。本章では触れられていないが、事前設計を文書でレビューするという方法を手放す不安を関係者が持つ場合がある。関係者の不安を払拭するベターなやり方を模索しよう。
28章 アウトソースとオフショア
この章には著者の苦しみが感じられる。控えめにいって、アウトソースとアジャイルは相性が悪い。それでもオフショアにアウトソースしなければならないときに気をつけるべきこと。それはつまり、アジャイルであり続けろということ。
この章には著者の苦しみが感じられる。控えめにいって、アウトソースとアジャイルは相性が悪い。それでもオフショアにアウトソースしなければならないときに気をつけるべきこと。それはつまり、アジャイルであり続けろということ。
29章 巨大なバックログの見積もりと優先順位付け
大量のバックログの見積りと優先順位付けを一気に行なう方法。スクラムにおいて見積りはコミットメントではないが、だからこそ必要十分な見通しを与えてくれる。
大量のバックログの見積りと優先順位付けを一気に行なう方法。スクラムにおいて見積りはコミットメントではないが、だからこそ必要十分な見通しを与えてくれる。
30章 契約の記述
顧客と開発業者が信頼できるパートナーになるための方策として、段階的契約、準委任契約を用いることを勧めている。
顧客と開発業者が信頼できるパートナーになるための方策として、段階的契約、準委任契約を用いることを勧めている。
付録 スクラムフレームワーク
ミニマムなスクラムの説明。本当に最小限なのでこれだけでスクラムを理解することは難しい。本書の著者によるポイントを押さえた解説なので、本書の読者には復習として参考になるだろう。
ミニマムなスクラムの説明。本当に最小限なのでこれだけでスクラムを理解することは難しい。本書の著者によるポイントを押さえた解説なので、本書の読者には復習として参考になるだろう。
