はじめに
チームビルディングというとチーム開発をしている人ならばありふれた取り組みで普段からやっているよ！という人も多いかと思います。
しかしながら、初めてチームビルディングをリードする人にとってはどうやって取り組んだらいいか悩む人もいるのではないでしょうか？
特に「いつやればいいのか？」「どうなったら成功と言えるのか？」といった疑問については言語化が難しいところでもあります。
この記事ではこれからチームビルディングにトライする人向けに、チームビルディングを始める際の考え方やHowの接続について解説します。
チームビルディングとは
チームやチームビルディングの定義についてはペパボさんの以下のスライドが非常にわかりやすいので、特にチームの定義やチームビルディングの意義についてはこちらを参照ください。
私の言葉でもチームビルディングによって作りたい状況を書いてみると、
- 個人の総和ではなし得ないアウトカムを出せるようにする
- チームで変化に適応できるようにする
の2点かなと思います。
1つ目の「個人の総和ではなし得ないアウトカムを出せるようにする」については、チーム内の議論によってよりよいHowを見出せる状況を作ることです。
よりよいHowとは、より早くリリースできる実装方法であったり、より使いやすいUIUXであったり、より品質の高いコードなどです。結果的に顧客価値の向上につながるようなHowを指します。
これを実現するためには、
- チームが何を解決すべきか（Why, What）理解している
- チームメンバーのお互いのことを知っている
- チームメンバー同士が信頼できている
といった要素が必要です。
2つ目の「チームで変化に適応できるようにする」については、チームを取り巻く状況の変化にチームで対応できるようにするということです。
わかりやすい例としては、バス係数があげられます。たとえばチームメンバーのひとりが1週間病欠になったときチームの活動を維持できるか？ということです。その人にしかできない仕事があればチームの活動はストップしてしまうため、こうした状況を取り除くこと土台を作ることもチームビルディングの一つです。
他にも、メンバーの異動や追加があったり、競合企業が自社を上回るリリースを出してきたり、大きなインシデントが発生したり、チーム内外での状況の変化というものは常に起こり得るため、その際にチーム活動が止まらないようにするという視点があるとよいでしょう。
まとめると、自己組織的に成果を最大化し、変化に強いチームをつくることがチームビルディングで達成したいことです。
チームを成熟度によってとらえる
チームの成熟度といえばタックマンモデルがよく参照されます。
これがチームが今どのフェーズにいるか？というモノサシになります。
当たり前の話ですが、チームが組成されて間もない時期としばらく経ってからのチームでやることは違います。
たとえばメンバーの理解度を深めるためのスキルマップの作成は形成期には有用ですが、関係が深まった後に繰り返しやるようなものではないと思います。
一方でメンバーそれぞれのWillは時間とともに変化していくため、ドラッカー風エクササイズはどのフェーズにおいても定期的にやることでアップデートをチーム内でシェアできるという効果があります。
以下にフェーズごとの代表的なワークショップを列挙します。（参考URLは記事の最後に記載しました）
| 内容 | 効果 | いつやるか？ | |
|---|---|---|---|
| ドラッカー風エクササイズ | 各自の得意なこと、お互いの期待値について可視化する | 初期の期待値、またそこからの変化を知ることでチーム内で動きやすくなる。 | 全フェーズ、メンバーが増えたら都度、定期開催 |
| インセプションデッキ | 我々はなぜここにいるのか？などいくつかのワークをチームで実施 | チームで集まって仕事をする根源的な目的について目線を合わせる。プロジェクトの進め方に対しての目線を合わせる。 | 形成期 |
| デリゲーションポーカー | 権限委譲レベルについて可視化する | チーム内での責任およびその権限の委譲レベルを可視化し、合意することでお互いに動きやすくする。 | 混乱期 |
| ワーキングアグリーメント | チームで一緒に仕事をするためのルールを作る | 日常業務を進める上でのルールを言語化し、すれ違いや都度指摘しあうことのコストを減らし気持ちよく働けるようにする。 | 形成期 |
| スキルマップ（星取表） | 各自の持っているスキルについて可視化する | チームのケイパビリティの可視化。強み弱みのが可視化され、弱い部分については打ち手を検討できるようになる。 | 形成期、メンバーが増えたら都度 |
| DTA(Designing Team Alliance: 意図的な協働関係の構築) | チームの雰囲気・文化の言語化、お互いの関係性についての言語化 | 個人の内面にある感情レベルまで引き出してチームの価値観を言語化することにより、チームの特色を共通の言葉にできる。 | 全フェーズ、メンバーが増えたら都度、定期開催 |
また、成熟度についてはもっと具体的な指標もあります。
スクラムで開発していれば以下のようなモデルが参考になります。
チームよりかは大きな単位ですが、デザイン組織の成熟度モデルといったものもあります。
会社独自の等級制度をブレークダウンした成熟度の指標を作るのも良いでしょう。
チームビルディングをやろうと言い出す勇気
ここまで書いてきたように、どんなシーンでどんなワークショップをすればいいかは巷に情報がたくさんあるので、なんとなくやることのイメージは湧くと思います。
しかし、そのワークショップが今のチームでも有効かはやってみるまでわかりません。またそのワークショップのファシリテーションが初めての場合は二重に不確実性を感じることと思います。
この不確実性を乗り越えることこそがチームビルディングのはじめの一歩です。
チームビルディングの経験は場数です。実践していくことで経験値が溜まっていきます。
以下にチームビルディングをやろうと提案するまでの考えを解説します。
メンバーからの視点の切り替え
メンバーとしてワークショップに参加するのと能動的にチームビルディングの場を作っていくのとでは視点がかなり異なります。
過去メンバーとしてチームビルディングに参加していた時のことを客観的に思い返してみてください。
- 何らかのワークショップをしようと言い出したのは誰でしたか？
- そのワークショップのアジェンダはどんなものでしたか？何を元にしたものでしたか？
- そのワークショップの準備にはどれくらいの時間がかかったと思いますか？
- ワークショップを実施の前後でチームは変化したでしょうか？自身や他のメンバーはどんな反応でしたか？
さて、次は自身がこれを再現しようと想像してみると、「結構考えることがあるな・・」という感想になるのではないでしょうか？
この視点の切り替えがまず重要なポイントです。
まずはチームを俯瞰的に見て会話の内容や議論のプロセスを観察する必要があります。実態を把握するところから始めましょう。
自分がイメージできる最高の状態の言語化
次に自身がイメージできる最高の状態を言語化します。これはメンバーとして参画していた際の記憶で問題ありません。
考えることは「過去最もパフォームしていた最高のチームはどんなチームだったか？」です。
以下のような観点があります。
- そのチームではどんなプロセスで仕事をしていましたか？
- メンバー誰とでもいつでも話せましたか？
- 各メンバーの得意なことや苦手なこと、バックグラウンドや将来のWillは知っていましたか？
- チームは何のためにそこに集まっていたか全員が言えますか？
- 目を背けたくなるような課題が発生した時にどんな反応をしたでしょうか？
- そのチームはどんな価値を生んでいましたか？
過去最高のチームは自身のチームビルディングのモノサシです。
今のチームと比較してできていること、できていないことを分析してみましょう。
自身が体験したことないことをやろうとするのは難しいです。まずは過去最高状態を再現することを目指してみましょう。
各メンバーの期待値の把握
これはマストではありませんが、各メンバーの期待値について事前に把握しておくと成功確度をあげることができます。
自身の中にチームのイメージがあっても、他のメンバーがどのようなギャップを感じているかはわかりません。
いきなりワークショップの提案をするのが不安な場合は1on1を通してチームがどうなるとよいと思っているか？などを聞いてみましょう。
他の質問例としては以下のようなことを聞けると参考になる回答があるかもしれません。
- 今のチームの状態を5点満点で表すと何点ですか？
- その理由は？
- あと何があれば満点になりますか？
- 今のチームの雰囲気をどう感じていますか？
- 今のチームにおけるあなたのパフォーマンスは5点満点で表すと何点ですか？
- いいチームとはどんなチームだと思いますか？
- いいチームにするためにあなたが貢献できることはありますか？私に期待したいことはありますか？
これを踏まえてワークショップのアジェンダをアップデートしたり、進行に協力してもらうことができます。
チームビルディングの準備
さて、ここまでくればあとはチームビルディングを実施するだけです！
しかしそのためには準備のアウトプットが必要です。
ワークショップによって必要なものは異なりますが、以下の観点をあらかじめドキュメント化しておくとスムーズに進めることができます。
# 開催目的・背景
<なぜやるのか、どういう議論からこの会が行われることになったのかを記載。SlackのURLなどを貼ってもOK。>
# ゴール
<ワークショップの結果としてどのような状態になっていれば目的を達成したと言えるのかを言語化。>
# アジェンダ
<ゴールを達成するためのアジェンダ。時間配分、やることを列挙し参加者がイメージ持てるようにする。>
# 事前準備
<必要な事前準備があれば記載。特に先にインプットしておくべきもの、先にアウトプットしておくべきものについて。>
特に重要なのはゴールとアジェンダを一度自身の言葉で言語化することです。
ワークショップのアジェンダを作るとそのアジェンダをこなすことに意識が寄ってしまいますが、アジェンダをこなしたあとのチームの状態としてどうなっていたらよいかをきちんと言語化しましょう。
たとえば、ワーキングアグリーメントをやろうとしたときに、「ワーキングアグリーメントが作成されていること」というゴールを置くとただ作成して終わってしまう可能性もあります。
「ワーキングアグリーメントに対してチームで合意できていること」という形で状態を具体的に表現することで、アジェンダの途中で「ファイブフィンガーで納得度を確認しながらやってみるか」などの工夫の余地が生まれます。
達成したいゴールに応じてアジェンダはカスタマイズできるとよいため、これを想像しながら準備をしてみましょう。（最初は基本のアジェンダ通りに実施でも良いのですが、あえて書いています。ここまでできたらもう上級者！）
当日のファシリテーションでは背景から丁寧に話しましょう。事前にアナウンスしていても忘れられていることもあります。ゴールに辿り着くまでためには、その場に集まった人に対して「なぜここにいるのか？」を正しく認知してもらう場作りが重要です。
チームビルディングのふりかえり
さて、ワークショップを実施できたら、成功したかはさておき、ふりかえりをしましょう。
参加者からフィードバックを得ることで場の設計、ファシリテーションなどの改善サイクルがまわり、どんどん良いチームビルディングができるようになっていきます。
もし失敗してしまったとしても気にすることはありません。手痛いフィードバックがあるかもしれませんが最終的にはフィードバックがあなたを癒します。
オープンに聞いて満足なフィードバックが得られない場合は以下のような質問を個別に聞いてみましょう。
- ワークショップを実施する前後でチームにどんな変化がありましたか？
- ワークショップに集中して参加することができましたか？
- ファシリテーションは適切でしたか？
- 場の発言や議論の偏りはなかったですか？
- アウトプットに所有感は持てていますか？
- どのような時にこのワークショップは効果的だと思いますか？
- またやりたいと思いますか？次回やるならどんな改善点がありますか？
まとめ
チームビルディングは、視点の切り替え、準備、場数です!
いいチームを作りましょう！
参考URL
- ドラッカー風エクササイズ
- インセプションデッキ
- デリゲーションポーカー
- ワーキングアグリーメント
- スキルマップ（星取表）
- DTA(Designing Team Alliance: 意図的な協働関係の構築)
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion