「アジャイルコーチング」を読みました
原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。
- 作者: Rachel Davies,Liz Sedley,永瀬美穂,角征典
- 出版社/メーカー: オーム社
- 発売日: 2017/01/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
第1章 旅を始める
「エクササイズ：コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。
- 動機：自分はどのような変化をもたらしたいのか？
- 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
- スキル：自分は何を提供すべきか
- （他チーム・他社のベストプラクティスを含め）メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
- 責任：仕事の進捗をどうやってレビューすればいいか
- 以前よりチームとして成果を出せていること
- （のためには、成果って何？とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・）
- 支援：周りからどのような支援が受けられるか
- 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる
第2章 みんなと一緒に働く
「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。
ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。
権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。
第3章 学習を促す
質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。（略）たとえば「このバグをもっと早く見つけるにはどうしたらいい？」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。
あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。
とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。
ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。
第5章 デイリースタンドアップ
「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。
ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。
朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。
第6章 何を作るかを理解する
ユーザストーリーの作り方や、ストーリーテスト（受け入れ基準）の話。ストーリーテストのテンプレートとして、 Given-When-Then（前提 - もし - ならば ） という形が紹介されていました。ってこれ、BDDで見たパターンだ。
以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given（前提）とWhen（もし）の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。
いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。
第7章 前もって計画する
午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。
このやり方、よさげ。機会あれば提案してみようかしら。
あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。
書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。
(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)
@ikikko 書記のところは、コーチやスクラムマスターみたいな人がホワイトボードのペンを持ってしまう、みたいなことです。その人が場をしきる感じになってしまい、チームのための会議という感覚が薄まってしまうので、できれば避けたいところです。
— 角征典／新刊『アジャイルコーチング』 (@kdmsnr) 2017年5月8日
第8章 見える化する
この章、目下の課題。
うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。
まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。
第13章 ふりかえりで変化を推進する
ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。
スーパー雑に、ふりかえり・カイゼンとやる必要があること（タスク）や、大きな目標について、自分の今の理解を書いてた pic.twitter.com/4cPETpKns7
— ikikko (@ikikko) 2017年5月4日
第14章 あなたの成長
この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。
例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。
コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。
あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。
自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの？」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの？」
「それは・・・」
それに続く理由は山のように浮かんだわ。
（うまくやらなくてはいけないから。）
（明らかなミスをするのは恥ずかしいことだから。）
（もっとうまくやりたいから。）
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら？
途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。
ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・
