「アジャイルコーチング」を読みました

原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。

アジャイルコーチング

アジャイルコーチング

第1章 旅を始める

「エクササイズ:コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。

  • 動機:自分はどのような変化をもたらしたいのか?
    • 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
  • スキル:自分は何を提供すべきか
    • (他チーム・他社のベストプラクティスを含め)メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
  • 責任:仕事の進捗をどうやってレビューすればいいか
    • 以前よりチームとして成果を出せていること
    • (のためには、成果って何?とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・)
  • 支援:周りからどのような支援が受けられるか
    • 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる

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

「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。

slide.meguro.ryuzee.com

ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。

権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。

第3章 学習を促す

質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。(略)たとえば「このバグをもっと早く見つけるにはどうしたらいい?」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。

あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。

とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。

ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。

ikikko.hatenablog.com

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

「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。

ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。

朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。

  • 朝からの流れでその日の状況をある程度推測しつつ、問題起こりそうなのを検知・対応できるように
    • 対応悩んで時間かかりそうなものを、デイリースタンドアップ後に相談したり
    • 立て込んでキャパオーバーになりそうな場合、適切に他チームなどにエスカレーションしたり
  • 昼に一度作業の流れを切ることによって、立ち止まって状況を整理する機会を提供
    • 合わせて、デイリースタンドアップ前に 2,3 分程で状況を俯瞰できる問い合わせボードを更新
    • 定期的に整理する場があると、日々の作業にズルズル流されることなくボードを最新に追随できる

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

ユーザストーリーの作り方や、ストーリーテスト(受け入れ基準)の話。ストーリーテストのテンプレートとして、 Given-When-Then(前提 - もし - ならば ) という形が紹介されていました。ってこれ、BDDで見たパターンだ。

以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given(前提)とWhen(もし)の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。

いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。

第7章 前もって計画する

午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。

このやり方、よさげ。機会あれば提案してみようかしら。

あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。

書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。

(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)

第8章 見える化する

この章、目下の課題。

うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。

まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。

ikikko.hatenablog.com

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

ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。


第14章 あなたの成長

この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。

例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。

コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。

あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。

自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの?」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの?」
「それは・・・」
それに続く理由は山のように浮かんだわ。
(うまくやらなくてはいけないから。)
(明らかなミスをするのは恥ずかしいことだから。)
(もっとうまくやりたいから。)
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら?


途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。

ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・

docs.google.com

*1:スクラムマスター、だとスクラムに限定されそうな感じがして、ちょっと狭い