
チームビルディング|チームの境界線
こんにちは。みなさんいかがお過ごしでしょうか?
オリンピックも終わり、パラリンピック開催までハーフタイムといったところでしょうか。外出もままならず、読書が捗ります♪
さて、今回はチームビルディングのカテゴリで、プロダクト開発現場で起こりがちな問題と問題の背景、対応について「チーム・ジャーニー」(市谷 聡啓 著)を参考としてお伝えしたいと思います。
チーム間の問題
ものづくりやサービス開発に限らず、あるプロジェクトの現場では複数のチームが役割分担し、協働することが通常です。そしてそれを統合推進するためのリーダー会が行われたりします。
例えばソフトウェア開発において複数のモジュールごとにチーム分けをしたり、イベント準備プロジェクトでは、映像コンテンツ企画制作、会場企画設営、広報、来客管理等々、機能別に分けるなど。
チームで役割分担することで発生する問題とは、特定チームに問題が発生して進捗に偏りが生じるが、隣のチームのことだからわからない、チーム以外の全体像が見えない状況でよくわからない指示が一方的にくる、などメンバーにとってやりづらい状況が発生します。
役割間の隙間タスクをどっちがやるべきか、お見合い状態、Bチームに問題発生だが、普段どう活動しているかわからないので手の差し伸べようがありません。
では、情報共有をオープンにして、垣根を一切無くしてしまったらどうでしょうか。
メンバー間で草の根的に業務依頼が行われ、本来果たすべき主機能の開発よりもチーム間対応のタスクが多くなり、依頼を積極的に行った機能チームと依頼を受けたチームでバランスを欠く、といったことも起こります。
一時的ならまだしも、いつしか応援状態が常態化してしまう、その状態をマネジャーも知らない、という混沌になってしまうなど、どちらも弊害が起きてしまいます。
越境のデザイン
これら課題を起こさない、もしくは大事にならないようにするためのグラウンドデザインをしましょう。(「越境のデザイン」という言葉と、後述する2つの越境パターンは「チーム・ジャーニー」を参考にしています。)
1)役割からの越境
そもそも、チームには役割があります。だからこそ境界があります。細胞には細胞膜があります。生物は皮や甲殻で周辺環境と境界を作っています。心理的側面でも自と他を区別して、「自分は何者なのか?」を定義します。この境界は当然あるべきものです。
その前提で、越境することを曖昧にせず、明確に定義しておくこと、仕組み化しておくことを提唱しています。
より具体的には、ある状況において前進を先導する「リード」という役割を導入します。これは機能チームのリーダーとは異なり、ある軸でチーム横断的に協働が必要になる活動の推進を行う「役割」です。チームメンバーからアサインします。
ソフト開発の例)テクニカルリード、仮説検証リード、テストリード、開発エクスペリエンスリード等々。
固定メンバーが常時担当するのではなく、期間限定的に、必要に応じて適任者をリード役にする、動的な運営です。
また、チーム内でリード役を複数人が担える状態にすることで柔軟な動きができるようになるでしょう。普段からそういう役割を意識したスキルアップを行っておくことも必要です。
チームが縦割りだとしたら、縦割り組織のリーダーと、横串のリードという役割分担をし、リードはチーム間の繋ぎ目の役割を果たし、情報をチームにインプットすることができます。
2)チームからの越境
こちらは、コミュニケーションの構造化と、それを支えるための情報の見える化を行います。
情報の滞留が起こらないようにコミュニケーションプランを持っておくこと、チーム内のコミュニケーションに加えて、リード間で情報を同期する、リーダー間で全体の状況共有する、それぞれの場を設定し、情報が滞らないようにします。
リーダー間の同期ミーティングにリードを参加させる、といった工夫で有機的に直接コミュニケーションがとられる(伝言ゲームをなるべく減らせる)でしょう。
注意点は、リーダーの同期ミーティングが一方的な意思決定の場にならないようにしましょう。チーム現場での気づき、改善が全体に伝播するように留意してください。
最後に メンバーは自ら「意識の境界線」を作っていないか?
これは完全に私の見解ですが、これまでチームメンバー、チームリーダー、チーム統括マネジャーを担当してきた経験から申し上げると、境界って、そこに属するメンバー一人一人が、自らの定義で設定することがよくあります。
全員の意思を、満遍なく統一ができるかというと、動的な環境でそれは困難でありますが、大枠の柵を、わかりやすく設計して、提示すること、そして、柵ははみ出ちゃいけない訳ではなくて、はみ出し方も明快にしておくことで、安心して柵を乗り越えられながらも、チームに属しているアイデンティティも保てると思います。