書籍情報

アジャイルコーチング

概要

チーム（対人）にアジャイルを浸透させる術、アジャイルを導入させる側としての本。
ところどころにチームリーダーとしての意識を考えさせられるような記述あり。
具体的な見積もり手法とかの話はアジャイルな見積もりと計画づくりの方が濃い。

前提知識

必須

なし

推奨

スクラムの実経験

アジャイルを導入させるための本なので、導入させるつもりがあって読むべき。

再読するなら

アジャイルを実践して、壁に当たったとき。
各章末尾に「苦難」の項目があり、こんなときは…の参考になる。
割と方法論なので、そんなに再読する系ではない。

人を導く立場として

第Ⅰ部

アジャイルの運用の仕方（人の説得の仕方）

第Ⅱ部

アジャイルの計画の立て方を明確な指標とともに考える

×
アジャイルな見積もりと計画づくりを読むべき

品質を考える上で必要な作業（バグ・テスト・リファクタリング）

第Ⅲ部

1イテレーションの終わりと次への始まり

第Ⅳ部

内容メモ

第Ⅰ部　コーチングの基本

アジャイルが云々というよりも、コーチとして、人の上に立つリーダーとして、認識しておきたい事項の確認。

第1章　旅を始める

アジャイルコーチのはじめ方～また次へ、を簡潔に説明した章。

• コーチを始める前に、動機・スキル・責任・支援を再認識する
• チームへは適切に紹介を受けて加入する。曖昧に入ると、コーチとしての信頼を失う
• PrOpERサイクルを意識する。
  　問題を探し（Problem）、改善の選択肢を検討し（Option）、実験（Experiment）、成果をレビューする（Review）
• 時間の概念を持ち、問題の原因・結果を考える
• ペースを維持する。進みが遅くとも、挫折せずに進み続けること

第2章　みんなと一緒に働く

チームとして他人と働く上でのコミュニケーションで大切にするべき部分の話。
相手の話はきちんと聞くとか、行間を読むとか。
議題によって対立した場合には即座に仲裁役に回る必要はなく、話を聞いたり、出ている意見に投票して視覚的に理解できるようにして感情論にならないようにする。

第3章 変化を導く

アジャイルの導入としてだけではなく、なにかの導入のときの心がけとも読める。

• チームに急速な変化を求めない
• 提案は宗教ではない。盲信しない。
• 説明だけでなく、実演して見せる
• 導入しないことによる問題を提示する
• 「提案された内容」ではなく、当事者意識を持たせることで自主性が高まる
  　・相手にオープンクエスチョン（「なぜ～だと思う？」のように、YesNoで回答できない質問）をする
  　・5回のなぜ（原因を5回探すとその間に根本的な問題が現れる）
  　・質問は誘導尋問ではない。明確な助言を持っているときの答えを促すための質問は信用をなくすので控える
• 学習の機会を作る

第4章 アジャイルチームを作る

アジャイルチームを作る前に、チームとしてのあるべき姿を考える話。心理的安全性の話とかまさにこれ。
まずはチームとしてお互いを信頼し、働くための場所を整える（物理的な席の場所を近づける）
チームのやる気を維持する。

• 簡単すぎず、難しすぎない程よい目標を常に立てる
• 説得力のあるゴールを決める
• イノベーションの時間を設ける（ゴールドカードを出した日は自分のやりたいことをやる＆結果を発表するとか）
• インセンティブ報酬には気をつける。他人を出し抜くような報酬はチームの協力を失う

第Ⅱ章　チームで計画づくり

いよいよスクラムし始める。

第5章 デイリースタンドアップ

いわゆる朝会。チーム全員がボード前に立って昨日の作業・今日の作業予定・困ってることを１０分程度で報告しあうのがテンプレ。
（これに限らず）ルールに縛られる必要性はない。「ルールに従っていればいい」と思うと自主性がなくなる。
あくまでチーム間での作業情報共有が目的なので、特定人物だけが話す場にはしない。
2部構成にして、対開発チーム・対営業チームとか分ける手法もあり（スクラムオブスクラム）
開始時間は絶対に朝ではなく、チームの都合で決める。
コーチとしては話が脱線したら補正する、当事者が慣れてしまった問題がないかを第３者の目線で考えながら参加する。

第6章 何を作るか理解する

ユーザーストーリーの作り方の話。
「＊＊というユーザーとして＊＊という機能がほしい。そうすれば＊＊という利益が得られる」をテンプレとして作成する。
３C（カード・会話・確認）が重要。
ストーリーを作成したあとにストーリーテストの詳細を確認する。
ユーザーの要求に応じて、詳細を詰めていく。
ユーザーが触れない機能（インフラ整備とか)もユーザー→プロダクトマネージャなどに置き換えて同じようにストーリー化できる。

第7章 前もって計画する

ユーザーストーリーを出したあとの見積もり・優先度会議の話。
顧客から次イテレーションに向けた目標を説明してもらう→チームで見積もり（※顧客は一旦退室しても可）→イテレーション計画（優先度・作業依存順に決定する・顧客にも説明する）

• イテレーションは数回の平均＝チームの作業可能実績であって、徐々に上がり続ける値ではない。そのような期待を持たない。
• イテレーション内で計画が変わり続ける場合、見積もりなどがうまく行っていない。調査が必要であればスパイクを設ける
• バグ修正の見積もりは難しい。かんばん方式への移行も視野に入れる

第8章　見える化する

チームボードの運用例。
・物理的
・見やすい
…なら、割となんでも良さそう。
ストーリーを優先度順に縦に貼って、横にToDOなどを並べるのが一般的な様子。（他の本もだいたいそう

なんでも見えるようにする必要はない。必要なくなれば運用を終える。
保守の仕方はチームで集まって検討するのが吉。

第Ⅲ部　品質に気を配る

テストどうするべきか？とかリファクタリングとか。
おそらく、この本自体が非エンジニア向けだから、こういう手段もあるよという紹介なんだと思う。
あまり深い部分までは突っ込まれてない。

第9章　完成させる

ストーリーテストの完成の定義を明確にする。
「テストする」だけでなく、自動テストとか、データ用意とか、実は作業はたくさんある。

バグを埋もれさせない。
変に気を遣って連絡しない（先にマネージャーを通してしまい、話が大きくなってる）とか、
頻繁に連絡して士気を下げるとか、やり取りは対人であることを意識する。

ストーリー未達を真摯に受け止め原因を振り返る。

強制されたツールの運用もきちんと考える

第10章　テストで開発を駆動する

ストーリーの完成条件でもあるテスト、それをTDDにしてみませんか、という提案。

TDDが早すぎるケースもある。
チームがテストのあり方について理解・同意できていない。
そのときは書き方を学ぶことから。

どこからテストを書くべきか？
まずは分離しやすい中間コードから。

CIも大切だがCIの規律はより大切。CI結果を無視しない

テストに時間がかかるようになると生産性が落ちてTDD持続も難しくなる。実行時間にも気を配る。

第11章　クリーンコード

作り続けるだけではなく、コードの綺麗さも考え続ける必要がある。

分析麻痺に陥ってないか？
ソースコードを書かずに設計ばかり考えてる。
逆に設計0も問題。
ユーザーストーリーに対して設計も意識する。

リファクタリングとか、チームでコードを共通所有する意識とか、ペアプロの話。

ペアプロは勉強のためではない。
少なくとも同じ言語で行う。
初心者対ベテランの組み合わせは問題ないし、お互いにお互いの意見をリスペクトし合う。

第Ⅳ部　フィードバックに耳を傾ける

イテレーションが終了して、次のイテレーションへ…行く前の、イテレーションデモ・その回のイテレーションの振り返りの話＋α。

第12章　結果をデモする

イテレーションの終了時のデモのやり方の話。

プレゼンの構成を決めて、全員が役割を果たす。
リリース事項として確認すべき事項も掲載。

技術的問題でデモが実行できない等は避けるべし。
事前準備・確認や、安定版を用意する。

第13章　ふりかえりで変化を推進する

ふりかえりのあるべきでない姿が載っている。
たまに見返して、自分たちの行っているふりかえりがどうかを考えてみると良さそう。

その期間にあった出来事と感情を導き出す。その時の気づきから改善のアイデアを探し、次に実行する
リリースレトロスペクティブでチーム全員で振り返る。これは大規模なので、事前に準備もする。

全員から、建設的な話を得るための場である。
話さない人がいる、不満ばかりの場になるべきではない。

第14章　あなたの成長

あなた自身が成長するために…のきっかけを渡そうとする章。
読み返すべきとすればこの章だけど、自己啓発話なので、それに特化した本を読んだほうが良さげ。