aretan.jp

• イントロダクション
• 第1部 コーチングの基本
  • 第1章 旅を始める
  • 第2章 みんなと一緒に働く
  • 第3章 変化を導く
  • 第4章 アジャイルチームを作る
• 第2部 チームで計画づくり
  • 第5章 デイリースタンドアップ
  • 第6章 何を作るかを理解する
  • 第7章 前もって計画する
  • 第8章 見える化する
• 第3部 品質に気を配る
  • 第9章 「完成」させる
  • 第10章 テストで開発を駆動する
  • 第11章 クリーンコード
• 第4部 フィードバックに耳を傾ける
  • 第12章 結果をデモする
  • 第13章 ふりかえりで変化を推進する
  • 第14章 あなたの成長

イントロダクション¶

アジャイルコーチングの技能は、「状況の理解」と「アジャイル開発の価値」、そしてその２つをどのように組み合わせるかで決まります。

私たちが一緒に仕事しているチームは、エクストリームプログラミング、リーン、スクラムを組み合わせて使っています。本書では、それらをまとめてアジャイルと呼ぶことにします。

開発チームの外にいて開発チームと協力するビジネス側の代表者のことを顧客と呼びます（スクラムの「プロダクトオーナー」に相当します）

第1部 コーチングの基本¶

第1章 旅を始める¶

あなたの使命は、チームがアジャイルを導入して、素晴らしいソフトウェアを作る手助けをすることです。それを成功させるには、あなたのアジャイルに対する情熱と熱意が必要になります。

あなたのゴールは、他人から押しつけられるアジャイルの行動規範に依存するのではなく、自分たちで考えることのできる、生産的なアジャイルチームを育てることです。アジャイルになる方法を示すだけでは不十分です。

• 教育する
  • やってみせる
  • 教える [学習、道場、ゲーム、物語]
  • 実例を示す
• ファシリテートする
  • 会議
  • 対話
  • 環境
• フィードバックする
  • 口頭で [チームに、1対1で]
  • 見える化 [図表、フロー、リマインダー、メトリクス]
• 気づく
  • 観察する [見る、聴く]
  • 熟考する
  • 質問する
• 支援する
  • 育てる [守る、与える、勇気づける]
  • 動機づける [挑戦実験]

アジャイルコーチの大切な習慣には、以下のようなものがあります。

• 模範を示す - 原則に本気で従っているところを見せてください。あなたが模範を示したい原則のリストを作るといいでしょう。
• バランスを取る - 変化に対する反発は予期しておくべきことであり、チームの反応によってあなたがバランスを失ってはいけません。
• 地に足をつける - もっとも重要な資質は辛抱強さです。自分自身に原因がないかと考えてみましょう。急ぎすぎていませんか？
• 言葉に気をつける - あなたもチームの一員であることを示しましょう。十把一からげに総括することは避けましょう。
• 実践から学ぶ - 最も強烈な教訓は、誤りから生まれます。チームに失敗する余地を与え、経験から学べるように支援しましょう。

エクササイズ：コーチングを始める前の質問

動機：

• 自分はなぜこのチームをコーチするのか？
• 自分はどのような変化をもたらしたいのか？
• 自分は何を学びたいのか？

スキル：

• 自分は何を提供すべきか？
• みんなは自分の何を知りたがっているのか？
• この情報をどうやってチームに知らせるべきか？

責任：

• コーチングを始めるために誰かの同意が必要か？
• 自分の正式な役割における責任は何か？
• アジャイルコーチの立場と競合することはあるか？
• 仕事の進捗をどうやってレビューすればいいか？
• 仕事が終わったことをどうやって把握すればいいか？

支援：

• 周りからどのような支援が受けられるか？
• どのようにチームに紹介してもらうか？
• 一緒に働きたいアジャイルコーチは他にいるか？
• 発注者にコーチングの進捗を報告する必要はあるか？

他のアジャイルコーチと一緒に働く機会を探しましょう。そうすれば、コーチングスタイルの違いにも気づくでしょう。他の人が問題にどう対処するかを観察し、自分のコーチングのレパートリーを増やすのです。

テックリードやプロジェクトマネージャーからアジャイルコーチになった人は、仕事上の古い自分を捨てて、新しい自分になるまでに時間がかかるでしょう。人生の多くは、仕事や自分のあり方を中心に回っているので、肩書きを変えることはすべてに影響してきます。

プロジェクト作業に深く関わりすぎてしまうと、チームをコーチする時間を作るのが難しくなります。現場でプレーヤーを兼ねるのではなく、第三者的な立場でコーチの役割をしたほうが、プロセスやチームワークの改善に集中できます。

キュウリを漬けたまま瓶詰めにしておいたらどうなりますか？ピクルスになりますよね？あなたの意思とは関係なく、キュウリは漬かってしまいます。

• アジャイルについて説明する練習をしましょう。説明を聞きたい人が相手なら誰でも構いません。あなたのアジャイルのウリ文句を洗練させるには、アジャイルユーザーグループはもってこいの場所です。
• 下準備をしながら、チームにどのように紹介してもらうのが一番いいかを考えましょう。
• アジャイルの原則を自分自身に当てはめる方法を見つけましょう。たとえば、反復的に仕事を進めたり、メールで質問を投げる代わりに、面と向かって話をしたりしましょう。
• あなたのコーチングにPrOpERサイクルを適用しましょう。課題から始め、少なくとも３つの選択肢を考えておいて、選んだ一つを実験してみて、その成果をレビューするのです。
• 立ち止まってゆっくりと考え、失敗から学びましょう。また、チームにもその余地を与えましょう。
• 社内外の他のアジャイルコーチから学ぶ機会を探しましょう。
• 同じ組織で長く働いているなら、あなたはすでに漬かっています。チームが効果的なアジャイルプロセスを回していれば、立ち去るべきときだと考えましょう。

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

• チームが直面している課題を理解して、信頼関係を築けるように、傾聴を練習しましょう。すべての注意を話し手に向けて、話を明確にする質問を投げかけ、内容を理解できているかを確認しましょう。
• フィードバックを伝えるときは、見たことや聞いたことと、状況から感じたことを区別しましょう。一般的なコメントよりも、具体的な気づきを伝えましょう。あなたの見たことや聞いたことを伝えてから、相手に説明を求めましょう。次回また同じ状況になったときの対応策について、みんなで協力してアイデアを出しましょう。
• 対立が起きたら、すべての立場の言い分を共有してもらいましょう。チームの代わりに対立を解消しようとしてはいけません。チームは自分たちで対処しようとせずに、常に仲裁役に頼るようになってしまいます。
• 「合意の段階」を使って、変化に対する賛成のレベルを明らかにしましょう。そうすれば、意見の不一致の度合いを把握できます。

第3章 変化を導く¶

• アジャイル信者にならないようにしながら、アジャイルに対する情熱を共有しましょう。アジャイルの話をして、アジャイルをやってみせて、アジャイルで他の人を手伝いましょう。チームを勇気づけ、元気づけて、アジャイルをうまく使ってもらいましょう。
• チームに問題を売り込みましょう。なぜ変わる必要があるのかを理解してもらいましょう。現状のままでいると、長期的にはどうなるでしょうか？チームメンバーの一人ひとりとも話をしましょう。何かが変わることで、メンバーが個人的に得をすることは何でしょうか？
• 抵抗されたときは、相手が抵抗する理由を考えましょう。それはアイデアの問題？説明の仕方が悪かった？提案したアイデアに懸念点でもあった？相手が心配している点について、ちゃんと話を聞いていますか？
• チームに質問を投げかけて、一緒にアジャイルプロセスを改善してもらいましょう。支援してほしいと協力を求めましょう。考えさせる質問をして深く考えてもらいましょう。5回のなぜを使い、根本原因分析をしましょう。
• アジャイルを学習するために、さまざまな方法を試してもらいましょう。たとえば、職場に本を置いたり、自分が読んだブログを共有したり、ポッドキャストを教えたりするといいでしょう。講演会や勉強会を開催し、組織の他のチームにも参加してもらいましょう。これから行われるアジャイルイベントの開催を知らせ、地元のアジャイルユーザーグループにみんなを連れて行きましょう。
• 新しいミーティングを開催するときは、初回はファシリテーターを担当し、チームがやりやすいようにしましょう。実況解説をしながら、ミーティングの進め方の考えを聞いてもらいましょう。次回からチームに準備してもらい、あとでフィードバックを伝えましょう。

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

• チームの絆を深めるために、お互いを知る機会を作りましょう。定期的に非公式なランチや飲み会を開催しましょう。
• 共有ワークスペースを作り、チームが一緒に働けるようにしましょう。チーム全体が同じ部屋にいられるようにしましょう。
• 役割の責任を明確にしましょう。顧客がチームと一緒に働けるように支援しましょう。
• チームに実現可能かつ挑戦的なゴールを用意しましょう。仕事は簡単すぎてもいけませんし、難しすぎてもいけません。
• 食事や飲み物を用意して、リリースのお祝いをしましょう。顧客やマネジメントからチームに感謝の言葉を伝えてもらいましょう。

第2部 チームで計画づくり¶

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

• チームボードの前でデイリースタンドアップができるような場所を探しましょう。職場に部屋がないなら、持ち運び可能なチームボードを使いましょう。
• デイリースタンドアップの時間はチームに決めてもらいましょう。全員の勤務時間が合わない場合は、１日２回以上やっても構いません。
• 答えは手短に済ませるようにチームに伝えましょう。マニュアルどおりの３つの質問は、チームを始動させるときは役に立ちますが、デイリースタンドアップの会話がそれに縛られるようではいけません。
• デイリースタンドアップがスムーズに進むようにしましょう。会話のトークンがあると、チームをうまくコントロールできます。
• 顧客にもデイリースタンドアップに参加してもらい、進捗や最新状況を聞いてもらいましょう。
• 出てきた課題をホワイトボードなどの見えるところにまとめましょう。チームと一緒に優先順位をつけ、きちんと追跡しましょう。
• ふりかえりでは、デイリースタンドアップの有効性をレビューしましょう。デイリースタンドアップの形式をいくつか試してみましょう。

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

• 「カード、会話、確認」の３Cをチームに紹介して、ユーザーストーリーに欠かせない３つの要素を覚えてもらいましょう。顧客と会話しながら、ユーザーストーリーを洗練してもらいましょう。
• ユーザーストーリーの書き方のお手本を見せたら、あとはチームが自分たちで書けるように、あなたが書くのはやめましょう。
• カードやメモはチームのスペースやミーティングの場所から見えるようにして、いつでもストーリーについて議論できるようにしましょう。
• 「○○というユーザーとして、○○という機能がほしい。そうすれば、○○という利益が得られる。」は便利なテンプレートです。ただし、これは穴埋め問題ではありません。チームに質問を促すためのものでなければいけません。正しい質問ができるようになれば、テンプレートの使用を中止しても構いません。
• 計画セッションが始まるまでに、顧客がストーリーの詳細に取り組めるように支援しましょう。チームメンバーの数人に参加してもらえれば、質問やストーリーテストの提案をしてくれるので、ユーザーストーリーがうまく形になるはずです。

第7章 前もって計画する¶

• 計画ミーティングのアジェンダを作りましょう。できればひとまとめにやるのではなく、何パートかに分けてください。話がずれてきたら、時間の使い方を教え、会話に集中してもらいましょう。
• 計画ミーティングの前に、顧客と一緒にユーザーストーリーを着手できる状態にしてください。
• 計画ミーティングでは、誰もがユーザーストーリーについて質問しても構いません。そのことを周知しておいてください。
• 作業を見積もる前に、設計の議論をしてもらいましょう。顧客が席を外したほうがうまくいくことが多いようです。
• 大きなストーリーがあれば、小さなタスクに分割してもらいましょう。ストーリーと一緒にタスクをチームボードに貼り出しておけば、チームが協力して動くようになります。ただし、重要なのは完成したストーリーを追跡することであり、完了したタスクを追跡することではありません。そのことをチームに伝えましょう。
• 見積りの数字が同じストーリーをグループにする「ストーリーカードマトリックス」を作り、一貫性のある見積りができるように支援しましょう。
• チームが持続可能なペースで働いているか、ベロシティと大幅にずれた約束をしていないかに注意しましょう。計画に含めるストーリーを決定する前に、キャパシティを確認してもらいましょう。
• ミーティングが終わる前に、カードを集めてチームボードに貼ってもらいましょう。チームはどのストーリーが計画に含まれているのか、初期見積りがどうなっているかをメモする必要があります。初期見積りは、ベロシティを計算するときのベースラインになります。

第8章 見える化する¶

• チームボードの設計や構築をするときは、チームと一緒にやりましょう。そして、チームにイテレーション計画を見える化してもらいましょう。そうすれば、何をやればいいのか、仕事をどのように調整すればいいかが、全員にわかりやすくなります。
• チームボードはチームの所有物なので、仕事の改善に役立つのであれば、個人的なモノやチャートを貼っても構いません。
• チームの役に立つようにボードを調整しましょう。遠くからでも見えやすい文房具を選択しましょう。色を分ける場合は、その色の意味がわかるようにしましょう。
• 誰が何を担当しているかがわかるように、カードに名前やアバターをつけてもらいましょう。誰かがブロックされていたときに、そのことがわかりやすくなります。
• 情報をため込んで「電子的な情報冷蔵庫」にしてしまわないようにしましょう。ただし、チームメンバーが離れている場合や、チームが大きなプログラムの一部として動いている場合は、イテレーション計画の概要を電子的に作成する必要があるかもしれません。
• イテレーションバーンダウンチャートは、チームが順調に進んでいるかどうかを示す大まかな指標として使いましょう。また、デイリースタンドアップで自分たちで更新するか、トラッカーを任命するようにしてもらいましょう。進捗を示すためには、リリースバーンアップチャートのほうが優れています。今後のイテレーションにおいて、スコープを削減する必要があるのか、予算を追加する必要があるのかなどが顧客にとってわかりやすくなります。
• イテレーション終了時にボードを綺麗にしましょう。イテレーションの途中で見える化チャートを評価して、役に立たないようなら、使うのをやめましょう。

第3部 品質に気を配る¶

第9章 「完成」させる¶

• 「完成」の意味をチームと一緒に決めましょう。それをチームのワークスペースにチェックリストとして貼っておきましょう。顧客、開発者、テスターによるテストは含めても構いませんが、チーム外によるテストは除外しましょう。
• テストはイテレーション計画で検討しましょう。テストのタスクは、チーム全体で理解すべきです。
• 開発者には、テスターや顧客と密接にやり取りしながら、ストーリーに関するフィードバックを早く手に入れてもらいましょう。顧客には、チームからの質問に答える時間を確保してもらいましょう。
• イテレーションの期間中から、顧客にソフトウェアを使ってもらうことを推奨しましょう。イテレーションが終了するまで待たなくても済むように、ユーザーストーリーのスライスを作ってもらいましょう。
• チームボードを用意して、イテレーションの終了前に修正すべきバグを貼り出しましょう。テスターには、「隠れたバックログ」を作るのではなく、今後のイテレーションで計画できるように、顧客と一緒に新しいユーザーストーリーとしてバグを記述してもらいましょう。
• チームがすべてのストーリーを完成できなければ、その理由についてデモやふりかえりで話し合いましょう。イテレーション終了時にボードをすべて綺麗にして、未完成のストーリーを次のイテレーション計画に引き継ぎましょう。ベロシティのデータを収集できるようにチームを支援して、次のイテレーションでは無理せずにコミットしてもらいましょう。

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

• テスト駆動開発に移行する時間を与えましょう。チームが一気に理解できる大きなチャンスです。反復的アプローチでTDDを導入しましょう。妨害するものをチームが理解するまでは時間をかけましょう。それから、PrOpERサイクルを適用しましょう。
• 新規プロジェクトであれば、すぐにテストファーストを始めることができます。既存コードのテストを改良する必要があれば、どこから着手すべきかを把握するために時間をかける必要があるでしょう。レガシーコードのテストの書き方が身につくまでは、１日に書ける自動テストはそれほど多くはありません。また、テストファーストではなく、テストアフターから始めることになるでしょう。
• チーム全体で、TDDでテストを書き、テストを実行する必要があることに合意しなければいけません。TDDで解決される問題について、チームで理解するようにしましょう。
• チームが自動テストの書き方を学ぶ時間を計画に含めましょう。トレーニングを実施したり、コーディング道場を開催したりするなどして、チームの学習を支援しましょう。
• チームを集めて、テスト戦略に合意してもらいましょう。中間にあるユニットテストから着手すると安全です。テストの保存場所や実行方法など、自動テストの基本的なことに合意することも忘れないようにしましょう。次にどこに取り組むかについて、チームと一緒にテスト戦略をレビューしましょう。
• 継続的インテグレーションは、ツールではなく態度です。ビルドサーバーに頼る前に、同期型CIプロセスから始めることをチームに提案しましょう。
• CIサーバーを使えば、壊れたテストを修正することにチームが責任を持てるようになります。ビルドステータスをメールに埋もれさせるのではなく、チーム全体に見える化しましょう。
• 実行の遅いテストに注意しましょう。ビルドスクリプトとインフラの改善の時間を計画に含めてもらいましょう。テストカバレッジは自分たちがどれだけうまくやっているかを理解する助けになります。

第11章 クリーンコード¶

• ソフトウェアの設計に費やす時間とコードを実装する時間のバランスが取れるように、チームをうまく支援しましょう。チームは、顧客のことを推測するよりも、自分たちがよく知っているユーザーストーリーの設計にフォーカスする必要があります。
• 計画のときに、インクリメンタルな設計の時間を作ることを思い出してもらいましょう。設計の話し合いをするときに、チームのワークスペースにあるホワイトボードを使う習慣をつけてもらいましょう。
• 技術的負債を積み上げるのではなく、チェックインする前にリファクタリングすることによって、ソフトウェアの設計を少しずつ改善してもらいましょう。リファクタリングツールを使えば、設計を改善する障壁が低くなります。チームにはツールの使い方を覚えてもらいましょう。
• チーム全体で共通のコーディングスタイルに合意してもらいましょう。チームがペアプログラミングを導入しないのであれば、ピアコードレビューを「完成」の定義に含めることを勧めましょう。
• 設計が古くなったコードの再建計画が立てられるように、チームを支援しましょう。割れ窓を修復すれば、チームの設計水準が向上します。
• ペアプログラミングによって、難しい問題を２人で協力して解決し、チーム内に知識を広めましょう。ペアプログラミングが快適にできるワークスペースを整えましょう。たとえば、同じデスクトップを表示できる２台のモニターを用意しましょう。
• ピンポンプログラミングを導入して、ドライバーとナビゲーターの役割を交代してもらいましょう。ペアがかたまらないように、適宜休憩を取りながらパートナーを交換してもらいましょう。

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

第12章 結果をデモする¶

• ユーザーストーリーのデモができるように、チームと一緒に計画に参加しましょう。
• チームと顧客にデモに参加してもらいましょう。デモに関係のあるステークホルダーを顧客に招待してもらいましょう。アジャイルがはじめてのステークホルダーのために、これからデモするものは最終的なプロダクトではないことを簡単に説明しましょう。
• イテレーションの最終日に、デモできるものとできないものを評価してもらいましょう。デモの準備に必要なことを網羅したタイムテーブルを貼り出すことをチームに提案しましょう。チームそれぞれのストーリーをデモする担当者を決めましょう。通常、これはデイリースタンドアップで合意します。
• 技術的な問題でデモが台無しにならないようにチームを支援しましょう。事前に部屋の準備をして、ネットワーク接続をチェックすることをチームに勧めましょう。デモがうまくいくように、リハーサルをしておくといいでしょう。
• ミーティングでは、ステークホルダーの反応とフィードバックを記録しましょう。ミーティングが終わる前に、フィードバックのポイントを全員でレビューしましょう。フィードバックから新しいユーザーストーリーを作り、次のイテレーション計画に持っていきましょう。
• イテレーションデモでは、動くソフトウェアのデモをするだけでなく、最終的なベロシティを計算するために、「完成」の定義を満たしているストーリーをチームと顧客が同意しましょう。
• デプロイとデプロイテストを自動化してもらいましょう。そうすれば、ソフトウェアのリリースがエラーなしでうまくいきます。
• デモのあとに成功のお祝いをしましょう。デモがうまくいかなければ、ふりかえりで話し合いましょう。次はうまくいくように、チームと改善に取り組みましょう。

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

• ふりかえりは、何がなぜ起きたのかを理解するために、過去をふりかえるところから始めます。詳しい話を語ってもらうために、チームには十分な時間を与えましょう。
• ふりかえりの後半は、今後の展望とアクションプランの策定に使いましょう。
• ふりかえりの効果を下げる「臭い」に注意しましょう。ふりかえりがプロセスの改善につながらなければ、どうすればよくなるかを考えましょう。
• チームが最も解決したい問題を見つけましょう。ドット投票を使って、チームが積極的に取り組めることに集中しましょう。
• 次のふりかえりまでに達成できないようなアクションにコミットしてはいけません。イテレーションごとに２〜３個のアクションを達成していけば、それだけでも数ヶ月にわたって大きな影響を及ぼすことができます。
• 前回のふりかえりのアクションが達成できていなければ、新しいアクションを追加する前に、その理由を見つけましょう。

第14章 あなたの成長¶

• 学習する時間を作りましょう。今月学びたいことの計画と、それを成し遂げるための計画を作りましょう。
• ふりかえりの時間を作りましょう。教訓は書籍からではなく、自分自身のさまざまな失敗から得られるものです。
• ストレスを解消する時間を作りましょう。仕事だけが重要だと思っていると、すぐに消耗してしまいます。毎日きちんと自分の時間を作り、物事を冷静に判断しましょう。
• 関心事を共有できる人たちに会いましょう。地域のグループやカンファレンスに参加すれば、これからもアジャイルに対する情熱を維持できるような人たちに出会えます。
• 自分に優しくなりましょう。ミスは忘れましょう。そこから学び、償いをして、先へ進みましょう。
• 他人に優しくなりましょう。悪意のせいにしてはいけません。そのような行動をする理由を明らかにしましょう。チームで意見や様式に違いがあっても、それは問題ではありません。
• 仕事が色あせないようにしましょう。自分を仕事に駆り立てましょう。それができないようなら、仕事は楽しくありません。