形成期からのチームビルディング
この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー4日目（シリーズ2）の記事です。
はじめに
はじめまして、コインチェックのタバタと申します。
コインチェックには3年半ほど在籍しており、2024年9月から事業開発室の室長となりました。本記事では、sotaさんの声かけにのっかって、所属する事業開発室の組織立ち上げに伴ってやってみたことをご紹介します。
こんな方の参考になれば嬉しいです。
・マネージャーとしてチーム創りをどこから始めればいいか悩んでいる
・メンバーとして所属するチームに課題感を感じている
なぜチーム創りに取り組んだのか
いきなりですが、今みなさんが所属するチームは以下の図のどのフェーズだと思いますか？（タックマンモデルより）
タックマンモデルとは
1965年に心理学者のブルース・タックマン（Bruce Tuckman）によって提唱された、チームやグループの発展段階を示す理論的モデル。プロジェクトチームや作業グループが時間とともにどのように機能し、進化するかを理解するために使用される。
もし、現在のチームが統一期（Norming）または機能期（Performing）の方は、この時点でそっ閉じいただいていいかもしれません。
私の場合、チームが未だ「形成期」ではないかという考えが起点にあり、メンバー/チームのポテンシャルを爆発させたいという想いからになります。
当時のチーム状況
実際に当時のチーム状況は、「形成期」に該当するような特徴がいくつか見られました。
お互いが十分に理解できていない
相互に警戒心を持ち、慎重に行動している
チームの目標や業務に関する理解が浅い
チーム内のコミュニケーションがまだ表面的
リーダーの指示に強く依存している
その背景にはチームの立ち上がりに至るまでの経緯も大きく関わっています。
事業開発室は2024年9月から新たに立ち上がった7名で構成された組織で、それまでは異なる二つの部門でした。それまでは、この2つの部門で構成されており、私は副本部長という役割を担っていました。当時の部門長が組織から離れることになった経緯もあり、2つの部門が統合され、新たに私が統合後の組織長を担うことになったのです。
こうして、わずか半年足らずの内に2度の大きな組織変更を経て（この期間に3名新たなメンバーも加わってくれてました）、チームは新たな船出を迎えました。
計画したこと
チームビルディングの目的は、メンバーがパフォマンスを発揮でき、その結果チームとして成果を上げることでした。 そのためにいくつか切り口を考えて行動計画を立ててみました。
実際の取り組み
本記事では詳細は割愛しますが、それぞれの背景にあった考えや工夫したことを残したいと思います。
準備 篇
チームビルディングを一人でやりすぎようとせず、同調してくれそうな二人に声かけしてスタートさせました。私自身の課題感や考えについて説明し、協力してほしいと働きかけたのです。自分自身以外に前向き且つ能動的に行動してくれる人を沿えることで、マネージャーとメンバー間の壁をなくす作用が働けばいいなと考えました。
① お互いを知る 篇
一緒に働く以上、当たり前すぎることではありますが、お互いを知るきっかけづくりでした。チームというのは、必ずしもお互いに仲良しである必要はないけれど、相互理解は必要だと考えています。さらには、機会がないと聞かない・話さないようなことを共有することで、相手の内なる情報をこっそり教えてもらったような感覚になり、親近感を憶えるきかっけになる側面があると考えての取り組みでした。
ストレングス・ファインダーは時間がかかりそうだったったので、この時点では実施を見送りにしました。
② 協働する 篇
①が一方通行型だったのに対して、②は双方向型の取り組みでした。
毎日の朝会（金曜日のみ夕方）は顕著で、一緒にコミュニケーションする頻度を高める意図がありました。当社の勤務形態は出社とリモートのハイブリットなこともあり、毎日顔をあわせて会話・相談できる場を持つことで、心理的距離感を縮められればと考えたのです。
また、振り返り会や新メンバーに対する全員からのフィードバックは、やったことをやりっぱなし状態にするのではなく、個人としてもチームとしても改善して成長するための仕組み化でした。
③ 知を共有する 篇
社歴や経験による情報差分をなくすことで、仕事のアウトプットの質にも好影響を与えると考えての取り組みでした。
仕事をする上で、「わからないことあったら聞いてね」というスタイルもあると思いますが、情報を知ってる側が知らない側に対して積極的に伝えていく努力も必要だと考えています。
④ 環境を整える 篇
ツール関連では、Slack、Confluence、Google Drive 等利用しているSaaS類の利用状況を全て棚卸し、チャンネルや格納場所など新規作成・削除・統合していきました。
「あったらいいはなくていい」の思想で、「なくてはならないもの」以外は基本的になくしていきました。結果、会議体は11→5つになり、Slackの利用チャンネルなどツール類もおおよそ1/2に断捨離しました。
⑤ 指針を定める 篇
これは結果的に、取り組み自体をやめました。
①〜④の取り組みがそれなりに機能したことと、あまりチームビルディングによって割かれる時間が増えすぎることによって、目の前の取り組むべきことに必要な時間を阻害したくなかったためです。
また、ちょうど会社のVALUEが変更になったタイミングと重なったこともあり、全社の行動指針がアップデートされたタイミングで、チーム内に新たなルールや行動指針を持つのはメンバーの混乱を招くことと、会社のVALUE浸透を優先すべきだとも考えました。
やってみてどうなったか
結果的に、メンバーからポジティブな反応が得られました。
1ヶ月目から、プロジェクトにおいてもチーム内でシナジーが生まれ始め、日を経る毎に仕事の質やスピード感に変化が表れました。
タックマン・モデルの段階でいうと、3ヶ月経過後の現在は混乱期と統一期のような状態が見られ、チーム内外から「チームっぽくなってきたね」という声も聞けるようになってきました。混乱期も一つの過程だと認識すると、意見のぶつかり合いや個人の主張が必ずしも悪いものではなく、チームの強くしていくために必要なプロセスだと捉えることができました。
2ヶ月目の振り返り時には、メンバー間の空気感が良く、なんだか一体感が生まれたなと感じたものです。
また、当初の計画を全て実行するのではなく、状況や周りの声に耳を傾けて、やりすぎなかったこともよかったような気がしてます。
もちろんチームメンバーの人間的な素養やポテンシャルが備わっていたことも大きかったです。
これからの課題
引き続きチームを強くしていくことはもちろんですが、最近はチームの外との関係性を強めていくことが大切だと考えています。
私たちは事業開発室という名の通り、自室だけで完結する仕事はほとんどなく、あらゆる部門の協力が必要です。チーム内だけの仲良しグループになるのではなく、チームとしての成果を出すために、他部門との連携を強化していきたいと考えています。
あまり堅苦しく考えすぎるのではなく、コミュニケーションがテキスト中心になりすぎることなく対面との使い分けを工夫したり、チーム内×他部門でランチの機会を設けるなど、ちょっとした働きかけを意識的にしていきたいです。
番外 篇
本記事で紹介した「タックマンモデル」との出会いは8年ほど前でした。当時、初めてマネジメントの役割になり、そんな時に本屋に並んでいたこの本が目に止まりました。
これは自分のための本ではないかと思って即購入。そこで一番印象的だったの「タックマンモデル」というチーム成長のモデルでした。
実は数年前の断捨離で一度破棄してしまっていたのですが、あれはなんだっけ？とどうしても気になり、2年ほど前に再購入。今は本棚にスチャっと佇んでます。
最後までご拝読いただき、ありがとうございました。
本記事がマネージャー又はメンバーとして、チームビルディングを検討・実践されている方に少しでも参考になれば嬉しい限りです。