第6章 適時、適切なコーチングの体制(p189~)
コーチングとは何か
p.191 コーチングとはチームの仕事に携わることではなく、チームワークを醸成するための行動である。
パフォーマンス・プロセス
1.努力の量
2.パフォーマンス戦略の適切さ
パフォーマンス戦略ってどんなの?
業務の進め方??
業務の目標に応じて適切に業務の進め方を変えていく、ということをいいたいのでは?!
個別の要素も入ってきて、ふわっとしたまま展開されていく?
3.知識とスキルのレベル
魔法の杖ほしい。。。
USJで買えますよ、一応!!
p.193 ほかの3条件を整えていなければ、いくらコーチングを施しても無意味である
無意味である、強い
3条件としてここで言われていること
まずは、真のチームを作るぜ!!
次にこれら3つの条件を整えるぜ
チームの力を引き出す構造
魅力ある方向性
チームを支援する環境
最後にコーチングをやるぜ!!←いまここ
すると、真のチームがハイパフォーマンスのチームになるよ!!
6コンディションの中でも、他の5条件が整ってないとコーチングは効果ないよって言っているので、ここでも言いたいことはそういうことかな??
リーディングチームの共著者がチーム診断というサービスを行っていて、それが6コンディションという名前
この図の真ん中がパフォーマンス・プロセスの3項目だった!
https://scrapbox.io/files/624456692a39fe001f4ff969.png
プロセスロスとプロセスゲイン
https://scrapbox.io/files/62444d85851f990021af6c2f.png
自炊したPDFで読んでるんで、貼るの楽っす(あまの)
努力のプロセスロス
ゴールが曖昧だと発生しやすい気がする。 曖昧なスプリントゴールとかダラダラしがち
目的を果たして居るかどうかはさておき、ゴールが明確ですべき事が明確な頃のほうが、デイリーに緊張感が合った!!じゃあそれが楽しいか、と言われると、そうでもないが、、、
スプリントゴールの運用が上手くいかないチームがありましたが、上手く活用できていますか?
ゴールを明確にして投入するPBIを明確にして、検査と適用がてきていたが、もう一方は形骸化していた。。。箇条書きにした文書をどうすればいいのか??をレトロで挙がった、という例も合った。何が違うのか??
スプリントゴールを決めていないチームでもPOも満足していた!!
スプリントゴールの箇条書きがなんか嫌な匂い
箇条書きではなく、シンプルで明確な記載!!ネガティブな感じではない
PBI先なのか、ゴールが先なのか、どっちかという話もある。
本当はゴールを先に決めたいが、PBIが先になることが多い → 悪いことなのか?
ロードマップからゴールを決めて、PBIを決めることはある
PBI←スプリントゴール←プロダクトゴール←ビジョン、の流れがいいかも
スプリントの途中でPBIが捨てられるか、はスプリントゴールが合意できているかどうかの判断基準の一つになりそう
業務の進め方のプロセスロス(異常に気づかずルーティンを進めてしまう)
スプリントバックログを消化してバーンダウンチャートが落ちているから大丈夫(出来たものがゴールに近づいているかは知らんけど)、ってチームもこの一例なのかもしれない
異常は裏で起きているし、気づいているけど、消化しているアイテムは終わっているから大丈夫!!という、怖いケース
P.197「同じ受け答えを何度も何度も繰り返してきたために、状況が変わればいつもと違う答えが必要かもしれないということすら頭に浮かばなかったのかもしれない」
あるある。チェックリスト化しても、「このチェック項目、いつも〇だから今回も〇にしておけばいいか」みたいな惰性や思考停止。
https://blogimg.goo.ne.jp/user_image/65/54/6635360f4e89be81df86c0d650a245e8.jpg?1572665052
チェックリストすること自体が思考停止につながる、、、、仕組みで解決したい!!チェック項目の背景が分からないのでチェックの効果が薄くなってしまうことが
完成の定義の追記して確認することもチェックリスト、チェックリストを作ってどんな状態にしたいのか、を検討するようなプロセスがないのであれば、あまり意味が無いような気がする
チェックリストから漏れるような状況を常に見つけるためにはチームが何を意識していないといけないか、を考えていたい。
チェックリストに助けられた体験。。。。。。。
みんな「・・・・・・・」
オンボーディングした際にやること、リリースする際の細々としたことを忘れない
1回しかやらないようなことは有効かもしれない(備忘録に近い)
知識とスキルのプロセスロス
偏見みたいな感じになっているのが面白い
プロセスゲインのためにクロスファンクショナルチームにする・多様性を入れる、なるほど
このあたりを読んで、プロセスロス/プロセスゲインという観点でチームが効果的な振る舞いをできているか考えられるようになった気がする
コーチングはプロセスロスを減らして、プロセスゲインを高めるための行動
この点に気づくと、チーム主体で注力して変えていけるのでは、という面白い視点もあるかも!!
コーチはいつ、何をすべきか
「努力」→「動機づけ」によるコーチング
メンタリング?
「パフォーマンス」→助言的コーチング
「知識とスキル」→知識と教育を図る教育的コーチング
ティーチングとはちゃうんか
スプリントによる区切りは、スタート、折り返し地点、ゴールのコーチングしやすいタイミングを生み出す仕組みと捉えられる
デイリースクラムではどれが中心的に現れるだろうか
タックマンが引き合いに出されてることを考えると、ここで言ってるタイミングはけっこう時間軸長そう
「コーチングに適したタイミング」プロジェクトに適したコーチングの話は助かるーーーーー!!まさにこれーーーこれーーーって思ったー
チームが仕事を始めて間もない頃→チームと仕事への取り組みのレベルに関するコーチング
新メンバーが増えてくるタイミングなどもここに該当しそう。
チームを立ち上げたときのふりかえりは、細かいルールよりもビジョンの意識づけや外的な規範を整えて「動機づけのコーチング」をやって、仕事が慣れてきた頃に混乱期を迎えるので内的な規範を整えるパフォーマンス戦略のコーチングをするってことかしら
あ、そういえばリリースに向けて数ヶ月活動してるとスプリントのレトロがパフォーマンスの助言的コーチングになったりする感覚
P204
開始時の決定は何となくの合意というような話があるけど、「適切な決定権を持った人が決定する」みたいな最初の方の話と関連させるのかな?それは初期にやるには組織としてのリーダーが決められている方がいいということ?自己紹介なりの経験を通して何となく決まっていくの?
例文では、ある程度リーダーが決まっている(機長)パターン
「チームが開始する」はどれくらいの割合の顔ぶれが一新したら「新たなチームの開始」と定義されるのかな?
何かいいやり方がないかとメンバー全員で探るチームは、そういう手間を省いてすぐ仕事に取り掛かるチームよりもパフォーマンスが高い
P206
インセプションデッキ入念にやりたい派閥の工数のかけすぎ問題がスッとした気がする
作り込まない程度に、必要最低限のチームビルディングを見定めろって感じがした
とは言え、初期段階でペルソナを想像しながらユーザ価値について議論するのは必要かなぁと。それは戦略じゃないのか。。
スプリントが短いことで学習のためのコーチングとしてふりかえりを頻度高くできることでチームが育っていくのは、スクラムのうまいところな気がする
P208:ゴール
スプリントの最後にレトロをする効率の良さが書かれている!!ちゃんと緊張を解きほぐしてあげないと学べない!!!
だからスプリントの最後にやるんやろなー
教訓化する話は経験学習のサイクルの話と繋がる
プロダクト思考な場合のゴールの設定のなんかモニョっとする感じ
P212
境界線上を自分の居場所にするリーダーの話がスクラムマスターの話な気がした
p.213 コーチングは、チームがそのとき直面している生々しい課題に切り込むものでなければならない。
そこに痺れる!憧れるゥ!
P214
勝手に時間で区切るなんてウソだ・・・信じないぞ・・・
p.217 ただ、「間違ったやり方」は確実に存在する。それは、自分のものになっていないコーチング・スタイルを実行しようとすることだ。
あるあるな気がした
優れたコーチが絶対にやらないこと
人間関係のコーチング(仲裁)はいくらやってもパフォーマンス上がらないという話
システムコーチングとはなんだったのか的な話?
システムコーチングはむしろ逆で個人よりもパフォーマンスの方に焦点を当ててる気がします
人間関係=友好関係では無い感じがシステムコーチングです!
友達に早くなりたいみたいなのを推してるチームがあって、それと仕事上の信頼関係は違うだろって感じたから、それが文章にされている気がする
衝突があるチームがパフォーマンスが高いってのは、心理的安全性が高い的な話なのかしら
共同で行うコーチング
デモの例が通常通りピンと来ねえんだよなあ
「民主主義っていうのはね、嫌いな人の意見も聞かないといけないんだよ。その人が社会主義者でもね。」って言うことで見事に模範になった例、みたいな感じで認識