チームビルディングって難しいですよね。
そもそも小学校のイベント班ですら一致団結するのが難しいのに、さまざまな地域で育ち、年齢も違い、過去の業務経験が異なる人同士を一致団結させるのは容易ではないと思います。

ただ、仲良くなる必要はありませんが、最低限のコミュニケーションを取ることは大事だと思います。
これがチームビルディングにつながっていきます。

ちなみにですが、私は新卒からIT業界に入り、今年で13年目を迎えます。
過去に2〜10名のチームリーダーを担当したことがあります。
大きく分けると約3つです。

社会人5年目  ：5名のリーダー
社会人7年目  ：10名のリーダー
社会人10年目：2〜4名のリーダー

それでは本編です。

チームビルディングの目標

私個人の意見ですが、
チームビルディングはお互い思いやる気持ちを忘れないだと思います。

ただ、1ヶ月程度の案件であれば、
チームビルディングなんていらないと思います。
終わったらすぐ解散です。
というのも1ヶ月程度であれば少人数で作業することが普通だからです。
1人で半年かかる作業を6人入れたからって1ヶ月で終わらせることはしないですよね。

ただ、半年を超えるような案件である場合はチームビルディングは必須だと思います。

対応時期が長ければ長いほど、
作業者が増えることで、自分よがりになっていきます。

全員が自分主体になるとどうなるか。
簡単です。

炎上案件がはじまります

私も炎上案件に参画したことがありますが、
作業者の心がバラバラでチームというまとまりは感じられませんでした。

チームビルディングの第一段階

これは「話す時間を設ける」です。

よし、早速雑談のために会議招集しよう！
行動力は素晴らしいですが、これはNGだと考えています。

話す内容はなんでもいいのですが、
話すタイミングだけは気をつける必要があります。

想像してみてください。
突然あなたの元に「1対1で雑談しましょう」という会議招集が来たら怖いですよね。
かなり身構えてしまうと思います。

雑談するにもタイミングが大事です。

では、資料の確認会議が始まる前に「そういえば、xxさんってyyが趣味でしたよね？」と、突然自分自身の話を振られると、嬉しくなりませんか？

興味を持ってくれてると思いますよね。

雑談専用の時間は設けず、定例会議などの合間で雑談するのがオススメです。
下記図は私自身の雑談するタイミングを分析した結果なのですが、9割程度が別の目的の会議で話しています。

ただ、どんなにタイミングが良くても一回の雑談を長い時間やり過ぎると嫌な顔をされますので、ほどほどを心がけると良いです。

私は社会人10年目のチームリーダーで初めて雑談を実践しました。

すると、社会人5年目、7年目の時と違って、
チームメンバーが会議中の資料内容とは関係のない内容について懸念事項を話し始めるようになったのです。

ありがたかったですし、正直とても驚きました。
普段の会話の中でポロッと出てくる内容が重要だということはかなり多いです。

以前のチームでも、メンバーとの仲は悪くありませんでした。
お互いに決められた仕事を適切にやっているので、関係は良好でした。
ただ、目的が定められている内容以外は積極的に話すということはありませんでした。

これってお互いの距離感なんですよね。

私はレビュー中に関係のない内容を話されても、特に気にしない性格の人です。
これが普段の雑談を通じて伝わっていたということでした。

会議以外でもこの距離感は発揮されます。
例えばチャットのメッセージです。

「先ほどはありがとうございました！」

初対面の人と打ち合わせした後に文末に「！」付きのチャットを送るのは勇気が入りますよね。

なぜなら相手も「！」をつけるタイプの人か把握できていないからです。

もしかしたら礼儀正しさを重視するタイプの人で「！」を嫌うかもしれません。
でも、元気いっぱいな挨拶が好きな人だったら迷わず「！」をつけてチャットしますよね。
こんなところでも距離感が出ます。

お話は戻りますが、
タイミングよく話す時間を設けることで、徐々にお互いの距離感を確認することができます。
そして、そこから良い関係を築くチャンスに繋げることができます。

チームビルディングの第二段階

お互いの距離感が把握できたら、第二段階です。

お互いの状況を把握する

これ結構簡単そうで難しかったりします。
心の距離が離れてると遠慮して言ってくれなかったりします。

実体験になりますが、社内事情故に状況を隠している人がいました。

私「今日もおつかれさまでした。
　　定時なので上がりましょう。
　　Ｔさんは上がったら、
　　テレビとか観るんですか？」
Ｔ「あ〜いや〜実は1週間ぐらい前から、
　　深夜2時まで仕事してまして。」
私「え？！どうして？！」
Ｔ「会社でパワハラしてる人から指示あって、
　　ここの仕事終わったら自社の仕事も
　　やらされてて16時間働いてます。」

やばすぎます(汗

この方はうちの会社に協力会社として入ってくれていて、契約上は1人月契約として参画しているので、裏で別の仕事してるとは言えないんですよね。

でも、直近はＴさんの作業進捗がなんとなく落ちているのを感じてたので、疑問から確信に変わりました。
翌日は他メンバーで仕事を巻き取ることにして、Ｔさんには午前中は寝ていてもらうことにしました。

その後、状況が落ち着くまで2週間ぐらいかかりました。
しかし、ヒアリングをしていなかったら突然倒れる可能性もあったので未然に防ぐことができて良かったと思っています。

上述の紹介パターンは衝撃的すぎますが、体調不良などの場合も同じことが言えます。
まずは休んで、体調快復を優先してもらい、作業は他メンバーで巻き取るといったお互いを思いやる気持ちを持ち続けるのが大事です。
人間は機械ではありません。

半年以上の案件においては、1日や2 日の目先の利益ではなく、長期的な目線で細かな単位でのリカバリが大事になってきます。

チームビルディングの最終段階

お互いの状況が把握できたら、最終段階です。

お互いのミスのフォローです

ここまで距離感が掴めてくると、相手の性格も分かってきます。
実体験として、チームに猪突猛進な性格の人がいました。
1人で解決策を導き、推進力があるのですが、粗が目立ちました。

例えば、テスト仕様書の重要ではない箇所のコピー漏れです。
以前使ったテスト仕様書を流用しているため、表紙の言葉が前のままだったりします。
でも、最も大事なテスト内容の記載は正しいですし、とても素早く作成してくれてました。

こういった誤字については指摘をするのも大事ですが、作業者の性格を知る意識が大事です。
普段の会話や上記作業ミスにより、効率的に動いてくれるけどミスが多いという傾向を感じ取りました。
私は本番リリース時もなにかトラブルが起きそうな予感がしました。

この予感が大事なんです。

このテストについては、すべて完了し、エビデンスも問題ありませんでした。
あとはリリースを待つだけという段階でしたが、私は猪突猛進の人が担当したプログラムを確認することにしました。

あれ？
これ変なプログラムが混ざってるな。
これだとエラーにならないか？

でも、テストのエビデンスは問題ありませんでした。
どういうことなのでしょうか。
彼はエビデンスを改竄して提出するような人ではありません。

テスト仕様書を見直したところ、
正常稼働のケースが1シート目、
異常稼働のケースが2シート目に書かれてました。

異常稼働のケースは複雑な条件で再現することができないため、確実にエラーが起きる再現用のプログラムをわざと埋め込んでテストするケースでした。

ようやく分かりました。
テスト仕様書のシートを前から作業した結果、不要なプログラムが残ったのです。

正常稼働をテストした後に、確実にエラーが起きるプログラムを埋め込んで異常稼働のテストをしていたのです。
そして、テストが終わったのにこのプログラムを消し忘れていたのです。

このような類似プログラムが他にもあるか確認したところ、3つほどありましたので、本人に修正を依頼しました。

リリース直前に3つの障害を回避しました。
本番障害未遂に終わりましたが、冷や汗がすごかったです笑
完全なヒヤリハットですね。

これは彼の性格を知っているからこそ発見できたミスでした。

人間である以上、必ずミスはあります。
でも、チームビルディングをすることで、各自の特徴を把握し、円滑にチームが動けるようにできればより価値の高いものを生み出せると思います。