はじめに
Forming 段階における簡単で効率的なチーム・ビルディングを以下の観点で説明する。（長文御免）
- チーム・ビルディングの目的を考える
- 「生産性を上げる」は手段であり、目標ではない
- 問題が何かを知る
- 認知バイアス
- 集団思考
- 心理的安全
- エンパシー
- 10x30 フォーマットの紹介
- ルール
- 運用方法
10x30 は、ソリューションの1つでしかないので、こだわらなくてもよい。
意味ある？それ
これまで、数名のチームから100人を超える部署、職種は営業部門を除く様々な組織のマネジメントをしてきた。東京で働いていた頃は、Face to Face のマネジメントだったが、現在はハノイで、主なプロジェクトは、リモートで多国籍なグローバル・チームをマネジメントしている。
過去に、人事部の用意したチーム・ビルディング研修として、1日会議室に缶詰にされて共同作業をしたり、何なら山奥に連れて行かれたり、メンバー同士で激詰めしあうようなとんでもないものまで、様々な研修を受けたが、果たしてあれは効果があったのか？甚だ疑問である。
意味がない。とは言わないが、どの段階でどんなアクティビティをやるべきかを熟慮しなければ、かけた時間やコストにたいして効果がペイしない。チームビルディングは内発的・自発的に行うものであり、自分たちをよく知らない外部から押し付けられるものではない。
というわけで、自分たちでできる、簡単で効果的なチーム・ビルディング手法を紹介したい。コストや時間は人件費を無視すればかからない。Face to Face だろうが Remote だろうが、何人だろうが関係ない。
なお、チームにはタックマン・モデルとして知られる "Forming", "Storming", "Norming", "Performing" の4つの段階があり（あると捉えることもでき）、今回紹介するのは、"Forming" または、"Storming" に失敗して空中分解しかけの段階のチーム向けだ。
タックマン・モデルがピンとこない人は、ジャイキリ でも読むと良い。
目的が間違ってる
ドラゴン倒せます。だから何？
まず、そもそもの話になるが、チーム・ビルディングして何がしたいの？をしっかり把握しておく必要がある。チーム・ビルディングは手段であり目的ではありえない。
- チームの生産性を上げたい
- 開発効率を上げたい
- アウトプットの品質を上げたい
こういったものはどうだろうか？残念ながらこれはまだ手段だ。しかも目的の2段階くらい前。魔王を倒すことが目的になっており、その先の世界平和が頭から抜け落ちてる例えで言うならば、これはレベル上げだ。
生産性が高く、アプトプットの品質の良いチームは、それはそれで素晴らしい。満足度は高くなるだろうし、重宝されるだろう。それを目指すのも否定はしない。しかし、それがプロダクトを良くしているか、ビジネスに貢献しているかは別の問題だ。
利己的なアジャイル・チーム
アジャイル開発の研修を行っていると「どうやったらクライアントをアジャイル・マインドにできますか？」と言ったような質問をよくされる。クライアントのプロダクトのためのアジャイル開発ではなく、アジャイル開発のためのアジャイル開発。オ◯ニー・アジャイル。そういうことだ。
マネージャーは、自分たちは何を志して集まっており、自分たちの活動がそのビジョン達成に対して、どうつながっているのか言語化できなければならない。マネージャーの果たすべき重要な役割は、勤怠管理や評価査定ではない。ビジョンを伝えることだ。クライアント・ワークでも一緒だ。
レトロスペクティブは、ベロシティを上げるためだけに行われてはならない。（マネージャー = PO は参加しないかも知れないけど）
エンパシー
PDCA の前に S (Sympathy) と言った人がいる。概ね共感であるが、私は E (Empathy) だと思う。Sympathy と Empathy、何が違うの？という人は、ブレイディみかこさんの
などを熟読すると良い。書籍帯の言葉を借りるなら「エンパシー = 意見の異なる相手を理解する知的能力」ということになる。
ビジョンへのパスを明快に示し、エンパシー（Cognitive Empathy）という能力を効果的に開発する。
これがチーム・ビルディングだ。（異論は認める）
チームがまとまらないたった1つのシンプルな理由
それは「よく知らない人とは一緒に働きたくない」だ。
人見知りって！子どもかよ！と思うかも知れないが、どうしようもなく根深い問題なのだ。
頭良さそうに言い換えるならば、
- 認知バイアスによって非合理な判断に陥っている状態
- 集団思考によって全体として非合理な判断に陥っている状態
- 心理的安全が担保されていない状態
と言えるかも知れない。差別は無知・偏見から生まれる。
以前ホーチミンで働いていた時にこんなことがあった。
半数以上がホーチミンおよびその周辺エリア出身者で構成されていたチームに、チームに不足したタレントを補うべく、ハノイ出身者を入れた。スキルも人物も、チームにフィットすると確信して採用したのだが、すぐに辞めたいと相談されることになった。チームが彼女を受け入れなかった。その理由は「ハノイの人だから」だ。典型的な認知バイアス・集団思考による非合理な判断。
「東京もんは」とか「◯◯人は」とか、ラベルを貼って個人をよく見ない・まとめて毛嫌いするのと一緒だ。
くだらなすぎるとブチ切れる代わりに、私はチーム・ビルディングに取り組んだ。
チームがまとまるたった1つのシンプルな方法
それは「自己紹介」だ。
知らないことが原因なら、教えてあげれば良い。
「みなさん、はじめまして。◯◯と申します。前職ではXXしていました。その経験をいかし、△△したいと思います。よろしくお願いします。」
これで、認知バイアスによる非合理や心理的安全が解消されるのか？
されるわけがない。
何が問題かと言えば、圧倒的な紹介ボリュームの不足だ。上記は挨拶であって、自己紹介ではない。自己紹介とは、自分のことを知らない相手に対して、自分を知ってもらうための行為である。挨拶だけじゃ、どんな人なのか全然分からない。
では、適切なボリュームはというと、聞き手に負担にならないことを考慮すると、時間にして5分程度が良い。
しかし、自己紹介を、5分以内で喋ってではなく、5分間みっちり喋って（でも5分超えないで）は、やってみれば分かるが、割と難しい。人は自由すぎると持て余す。制約がないとクリエイティブにはなれないのだ。
そこで、フォーマットを用意する。
10x30 フォーマット
10x30 は、10枚の写真について30秒ずつ喋るという、Pecha Kucha フォーマット（20スライド20秒ずつ）をパクった を参考に、私の経験から最も効果的と感じられるフォーマットだ。要は私の匙加減だ。
10x30 のルール
スピーカーは、
- 10 枚の写真を用意する
- テキストは禁止
- それぞれの写真について30秒ずつ喋る
オーディエンスは、
- 遮らないこと
- 批判しないこと
これだけだ。ファシリテーターは、強い意志を持って写真を30秒ごとに進める。
マネージャーには別の制約もあるのだが、それは後述する。
10枚の写真
10枚の写真、つまり10トピックについて自己紹介をする。10トピックもあれば、何等かフックするトピックがあるものだ。さて、
- 名前等の基本情報
- 職歴や出身地・出身大学などのバックグラウンド
- 好きなこと・趣味
- やりたいこと
- 家族？
- …
え？まだ半分？？10トピックは割と多い。しかも各トピック30秒。自分についてかなり絞り出す必要がある。20トピックとなると途方もない。
30秒で喋れるボリュームは、一般的に英語などでは70〜80単語程度、日本語なら150〜175文字程度だ。さらっと喋るには多すぎるが、しっかり話すには短い。アドリブが難しいボリュームだ。
挫折しない程度に難しいのが10トピック・30秒ずつだ。
テキスト禁止
メラビアンの法則（Verbal 7%, Vocal 38%, Visual 55%）で言われているように、コミュニケーションにおいて言語情報が与える影響は 7% しかない。言葉を軽視してはいけないが、表情や喋り方、ボディランゲージなどの非言語コミュニケーションはとても大事だ。
スライド上のテキストは、スライドを補足するが、スピーカーはそれを読むためにオーディエンスに背を向けてしまったり、オーディエンスはスピーカーを見ずにテキストを読んでしまったりと、デメリットの方が多いので、禁止する。
なお、例えばベトナムのオフショア開発チームなどで行う場合、言語はベトナム語でOKにしてあげよう。自己紹介は、マネージャーに対してではなく、メンバー同士で行われるべきであるからである。そうしたら分かんないじゃんと思うかも知れないが、大丈夫だ。言語は7％。しっかり見てればだいたい分かる。
要練習
10x30 のフォーマットは、高いプレゼン能力が必要とされる。しっかり考えて、みっちり練習しないとうまくできない。プレゼンで重要なのは準備である。そのことが身にしみて分かるし、同じフォーマットでプレゼンする他のメンバーの苦労も、手抜きも、分かりやすい。
高いプレゼン能力が必要とされるが、喋る内容は、誰よりも詳しい自分のことだ。大丈夫。なんとかなる。
10x30 の運用
自己紹介は何度もするものではないので、1回やったら終わりだ。10x30 というフォーマットによって、よほどのことがない限り、認知バイアスは上書きされ、メンバー同士の受け入れる姿勢が整い、心理的安全が生まれ、健全なコミュニケーションが活発化する。
だが、ここで終わるのはもったいない。定例化しよう。
- 新しいメンバーは自己紹介
- 既存メンバーはあらかじめ決めたトピックについて
既存メンバーは、10枚も喋らず、5x30 程度でも良いかも知れない。トピックはボトム・アップにしよう。
月1回、メンバーが入るたび、メンバーの流動性が低いチームならQに1回。頻度は好きにしたら良い。準備期間は最低でも1週間は与えよう。私は、1〜2ヶ月に1回くらいの頻度でやっていた。
続けることで、エンパシーもプレゼン能力も鍛えられる。日常業務において、説明がうまくなっていくのが実感できる。こちらが求めているものをきちんと理解し、どう説明したら伝わるか考えてくるようになる。自然に。
ブレイク・スルーの瞬間
継続していると、ある時、プレゼン・ファンタジスタが現れる。
ある時、何故かバナナをポインター代わりに持ってきたメンバーがいた。結局バナナには何の意味もなかったが、笑いは取れた。その後、例えば好きな食べ物のようなトピックで喋る時には、実際にその食べ物を持ってきてみんなに配った。クリエイティブである。
10枚・30秒・テキストなしのルールは、それ以外に守るべきルールも、禁止されていることもない。思い込みによる枠組みを取り除く、素晴らしいムーブだ。こういうことは、実業務でも現れてくる。バンザイ。
ファンタジスタが現れなければ、自分がなれば良い。
マネージャーのルール
これで、うまく行っているように見えるかも知れないが、チーム・ビルディングの目的を考えると、これはレベル上げが順調というだけだ。チーム・ビルディングに成功しているとは言えない。
マネージャーの仕事はビジョンを示すことだ。マネージャーはメンバーに対して喋る時は、全てビジョン・シェアの時間であると認識すべきである。なので、マネージャーは、どんなトピックでも、10枚、30秒、テキストなしに加え、ビジョンにつながるストーリーを語る というルールが追加される。マネージャーは、毎回スピーカーとして参加すべきだ。
これは努力目標であるが、チーム・ビルディングに必要不可欠だ。好きな食べ物とビジョンを結びつけられないよと思うなら、普段の業務においてシェアすれば良い。
何故必要かは繰り返す必要はないと思うが、別の言葉で言うならば「心理的安全の罠」に陥らないためだ。
心理的安全が確保されているからと言って、何言っても良いわけではない。ディスカッションの 見当違いな 発散は、むしろ悪影響だ。そうならないためにも、チーム全体が何に向かっているのかをしっかり共有している必要がある。
崇高で美しく壮大なビジョンを、個々のメンバーが実感できるくらいに噛み砕いて伝えることが重要だ。ちょっと宗教的とキモがられるくらいが丁度よい。またか…と思われた時からビルドが始まる。
なお、あなただけがあまりにも魅力的で圧倒的あると、Yes Man だらけになってチームが死にかねないので、注意が必要だ。
権限委譲
チームが成長するために、もう1つ大切なことがある。それは権限委譲だ。権限委譲の重要性は今更解く必要はないと思うが、注意点が1つある。
責任を移譲してはいけない。移譲するのは権限だけだ。その代わり、説明責任を課す。
Responsibility is on "me", Accountability is on "you".
これができないのであれば、権限委譲をしてはいけない。いきなり全権限を移譲するのではなく、タイミングを見ながらちょっとずつ移譲して行けば良い。
読んでないが、Netflix の NO RULES という本が良いらしい。
Ten*Thirty
10x30 フォーマットによるプレゼン・ミーティングを支援するサービスを作った。パソコンとディスプレイだけあればできそうなアクティビティに支援が必要なのか？と思うかも知れないが、あると便利だ。
実際に開催してみると、ルールを説明しているのに
- 文字を入れてくる
- 練習不足で 30 秒を守れず、進めて/戻ってとか言ってくる
- 聞いてると 30 秒で進めるの遅れたりするし、なにかと忙しい
となる。
文字が入れられない、スタートしたらノンストップ自動再生。Powerless Point と言っても良いかも知れないが、運用のハードル・コストを極力下げたつもりだ。
（おまけ）技術的なこと
サービスは、Next.js 15 (React 19), Drizzle-orm, NextAuth 5 と、canary, rc, beta なちょっと攻めた構成にした。これらをいじってみたかったが先にあって、その題材として、チーム・ビルディングを乗せた。
Chat GPT, GitHub Copilot, DALL-E, uizard などなどと、全ての工程に AI を用いて制作した。特にフロントのギミック実装などは、素晴らしいパフォーマンスだった。一方、新しすぎる技術に関しては、AI の学習不足が否めないのと、メモリ管理などはまだまだ任せきれないと感じられた。
が、今後も日常的に使っていくことで、勘所を養っていけば良いかなと思う。
日々 AI に指示出しをしていて思うのは、AI は仕事を奪わないが、AI をうまく使える人が使えない人を駆逐していく（いる）ということだ。では、AI をうまく使える人とはどんな人か？と考えると、説明のうまい人、つまりはコミュ力の高い人というところに落ち着く。
今後のキャリアを実り豊かなものにするには、ソフトスキルの開発が重要だ。
あら！10x30、やったら良いじゃないの？
私は AI に please / thank you と言える人でありたい。
（おしまい）