チームビルディングについてのふりかえりLTをしたので、ふりかえりをしてみます
はじめに
外販グループの中嶋（@jnuank）です。
この記事は、チームビルディングのふりかえりLTを終えたあとに、自分自身でふりかえりをしてみた、というお話です。
タイトルからお察しのとおり、テクニカルなお話ではありません。
この記事を書くきっかけ
3ヶ月前に今のチームでリーダーを務めることになり、今に至るまでのふりかえりを社内でLTしてみました。
その時のフィードバックの中で、「この内容だったらブログも書けそう」というお言葉を頂き、じゃあ書いてみようと考えたのがきっかけです。
どうせならスライドの内容をそのまま書くのではなく、
LT後の皆さんのフィードバックを元に、自身で更にふりかえりをした内容を書いてみようと思います。
ふりかえりLTのふりかえりという、なかなかこんがらがりそうな感じですが、どうぞよろしくお願いいたします。
当日発表したLT資料
詳細はスライドを見て頂けたらと思います。
LT後に出た意見・質問
リーダーの職務記述書がリーダーズインテグレーションっぽい
これは最近リーダーズインテグレーションをやったチームからの意見でした。
確かにリーダーズインテグレーションの「③リーダーに知ってほしいこと」「④メンバーがリーダーのためにできること」は、私がやったことと近いものを感じます。
メンバーと「リーダーの職務」のすり合わせを行った一番の理由としては、 「リーダー忙しそうだけど、何やっているのかわからない」「メンバー側からは、これやって欲しいのに、リーダー何もやってくれない（ように見える）」など、不幸なすれ違いを早めに解消したかったという想いがありました。
リーダーの期待マネジメントという意味では、リーダーズインテグレーションも同じような効果が望めるのかな、と思います
逆にリーダーズインテグレーションをやってみてどうだったのか聞いてみると、やはり準備等に時間が掛かったそうです。
ただチームメンバー同じ場になって話し合うことに意味はありますし、
このワーク自体、リーダーの期待マネジメントとは別に、リーダーを務める人自身を知って、メンバーたちに親しみやすさを生み出す効果があります。
実践したチームの議事録を見せて頂きましたが、「（メンバー）リーダーに恋愛相談してもよいか→（リーダー）私で良ければ」という質問もあって楽しそうなチームだな、というのが傍目から見ていても感じ取れました。
プラクティス名をあえて出さずに、自分で資料を作って個別に説明したのは何故か？
「デイリーでファイブフィンガーをやる時、説明資料を作ってメンバーに説明した」という話を受け、他チームから出た質問です。
理由としては、プラクティスを導入することに対して、なるべく拒否反応を起こして欲しくなかったからです。
仮に自分が「ファイブフィンガーやりましょう」と言ってやり方を伝えただけだと、「5本指で表すことになんの意味があるのか？」という疑問を生み出し、「そんな余計なことしなくても、いつもどおりデイリーをやればいいじゃん」と言われる可能性が、もしかしたらあったかもしれません（ハンズラボの中で、そういう人は少ない傾向にはありますが）
なので、
- 5本指でタスク進捗を表明しましょう
- なぜそれをやるのか
- これを始めたらどういう効果が期待できそうか
という資料を簡単に作成し、説明をすることから始めました。
※カイゼン・ジャーニーの第1部にも「プラクティスは強力だけど、そのままやるな」といった記述があります。
あれはプラクティスの手順をそのまま現場に適用しようとするな、という意味でしたが、チームの状況に合わせないで適用とするから、メンバーの拒否反応が出てしまうんじゃないかと思ってます
このスライドでは載せてないけど、やってみて失敗した取り組みはあるか？
取り組みを止めたかどうかで言うなら、と前置きした上で、今の所ノーです。
取り組みを始めて2〜3ヶ月のため、まだ 「失敗もしていないし、成功もしていない」というのが正直な感想です。
そもそも私の中では「上手くいっているチーム」という定義が、まだ曖昧です。
（この辺り、一家言ある方がいらっしゃいましたら、ぜひ教えて頂きたいと思っております）
とりあえずの目標としては、以下の2つを考えています。
- お互いの成功・失敗を恐れなく共有できるくらいに、コミュニケーションのハードルを低くする
- お互いチームの問題点を見つけ出し、前向きにカイゼンしやすくする空気を作り出す
上記の目標を達成する為に、デイリーとKPTをやり始めたのは、私の中では「大切な一歩」だと考えています。
もちろん一回やって終わりではなく、やり方自体もカイゼンをしながら、チームに根付かせる努力をしていきたいです。
※目標を書いてて思いましたが、これも定性的ですよね。
強いて言えば会話の量が増えるかどうかでしょうか。
とはいえ、会話が多すぎるということは、コミュニケーションルールがうまくできていないということに繋がるので、一概には良いとは言いにくそうです。
チームで立てた行動目標、成果目標が上手く達成できているのかを見るのが良いのか、うーん…。
デイリーを今やっていないけど、やった方がいいのか？
これは2人チームのリーダーから出た質問でした。
賛否が分かれそうですが、個人的にはやったほうがいいと思っています。
スライドの中でも書いていますが、デイリーをすることで「チームのリズムを作ること、メンバーが均等に喋る機会を1日に数分でも良いから作る」ことが重要だと思うからです。
デイリーに関しては、既に導入済みの他チームからも以下の肯定的な意見を貰えました。
- デイリーをやることによって、楽しくおしゃべりする機会が増えた
- 必ず毎日顔を合わせて喋るので、メンバー同士のコミュニケーションを取ることへの心理的障壁が下がった
心理的障壁が下がるっていう意見はとても良いなって思います。
これはいわゆる、心理的安全性が構築された状態だと言えそうです。
どうして心理的障壁が下がるかと考えると、毎日少しでもコミュニケーションを取ることにより、相手の考え方や人となりが理解できる。
そうすれば、相手に合わせた会話がしやすく、コミュニケーションのハードルが下がっていくのではないかと。
KPTをこれからやろうと思うけど気をつけた方が良いところは？
この質問に関しては、導入時と実施後の経験から、以下の内容をお話しました。
- KPT経験者（チーム外の人、外部CTO）にオブザーバーとして入ってもらう
- アジェンダを先に作っておく
- グランドルールの共有
経験者を入れるのは、円滑なKPTを運営する為です。
アジェンダに関しては、時間内に終わらせるためにタイムテーブルを共有する為。
グランドルールは、この場で守って欲しいことを伝える為です（意見に対する批判はしない、など）
特にグランドルールを共有することは、心理的安全性を作るのにとても重要だと感じています。
また、LTを終えたあとに、こうした方がいいのかな、と思った事は以下の3つです。
- KPTのファシリテーターは順繰り制にしてみる
- KPTボードに目標・テーマを入れる（オプション）
- 最低でも4回はやってみましょう、と導入前に伝えて合意を得る
常にファシリテーターを固定してしまうと、その人が不在の際にはスキップする、という心理が働いてしまうので、順繰り制を導入した方がいいのかなと考えました。
目標・テーマについては、永和システムマネジメントさんのKPTふりかえり会体験で学んだことですが、ただ漠然とKeep、Problem、Tryを考えるよりテーマを渡した方が考えやすいそうです。
最低4回やろう、というのは実際に私がチームに導入するとき、「KPTはふりかえりのフレームワークなので、ある程度の期間やって効果を見ましょう」と話し、最低4回、毎週やるとしたら1ヶ月やって、それでも意味が無いと思えばやめましょう、とメンバーに伝えました。
ふりかえりが重要だと私個人が思っていても、メンバーがその効果を感じれず、「やらされている」感が抜けないのであれば、それは潔くやめてしまうのがチームの為だと思ったからです。
LTを終えたあとのふりかえり
ふりかえりLTしてみて、
いろんなことにTryしてみたな、という実感と、
これだけやっても、まだまだチームの問題は尽きないっていう気づきが得られました。
ソニックガーデンの倉貫さんの記事でも、KPTでProblemが出ないことは良いサインではなく、出ないのであれば日々挑戦していないかもしれない、といった事を書かれているので、そういう意味ではちゃんと挑戦が出来ているのかもしれません。
あと、「やると良さそう」というのはわかっているけど、
どんな風に始めたら良いのか、どうやって他のメンバーを巻き込んだら良いのか、というニュアンスの意見がチラホラあり、みんな最初の一歩が踏み出しにくいんだなって印象でした。
私の場合も最初の一歩が踏み出しにくかったですが、いま外から来ているCTOとの1on1で「とりあえず、やってみましょう」と背中を押されたのが大きかったと思います。
人間、相談できて背中を押して貰える、ということは大切だなと感じました。
自分がやったLTも他のチームの方々の背中を押せるようなLTになってればいいな、なんて今は思っていたりします。
今後の妄想
デイリーでは日々のタスク、KPTではチームのカイゼンが主となっているので、今後はメンバー個人にフォーカスした1on1を実践していきたいです。
KPTなどで定期的なチームのふりかえり、1on1で個人のキャリアや志向のキャッチアップしてチーム状況の変化に気づきやすくできれば良いかな、と考えています。
最近のチーム状況的に、KPTが合わないような気もしてきたので、折を見てYWTも試してみてもいいのかなーと考えています。
あとは、開発〜運用フローを可視化するバリューストリームマッピングを試してみたいという気持ちがあります。
ちょうど最近メンバーの入れ替わりがあった為、これを機にプロセスの可視化をして、できるところからカイゼンしていきたいです。
また、Joinしたてのメンバーが早くコードベースに馴染めるように、ペアプロ・モブプロを業務の中で取り入れたいなと密かに思っていたりします。（せめて週イチくらい
おわりに
今回のLTで思いのほか、社内外問わずにフィードバックが貰えたのが嬉しかったです。
隣の芝は青い理論で周りを見渡していると、「他のチームみんな上手くいってるな……こういう内容興味ないかな……」と萎縮していましたが、
いざ共有をすると、意外とそれぞれチームの悩みがあったりして、
「なんだ、みんな悩んでるじゃん。もっと早く言って一緒に悩めばよかった」なんて思えたのが一番の収穫かもしれません。
人がそれぞれ違うように、チームもそれぞれ違います。
となると、チームビルディングのやり方もそれぞれ変わってくるはずです。
これをやれば絶対うまくいく、といった銀の弾丸はありませんが、
いろんな体験を共有しあって、より良いチーム活動が出来るようにしていきたいなと思っています。
