その施策に意味はあるのか？

チームビルディングにはさまざまな打ち手がある。エンジニア組織であれば、モブプログラミングや輪読会などの施策をよく見る。

施策とは

施策とは「何かを解決する」ために行われるものだ。施策だけが先行すると、いわゆる「手段の目的化」が発生する。

手段が目的化しても、ある程度の効果が得られるようになっている。過去の英雄たちに感謝というわけだ。インターネットで拾ってきた何らかの施策をコピー&ペーストして自身が干渉するチームで実行しても一定の効果は得られる。 一方、チームビルディングは地続きで、施策という点と点が繋がらなければチームのスケーラビリティは高まらない。 点と点を繋ぐために、あるいは描かれた線上に点を置くために、現在・未来の状態と潜んでいる課題を意識して施策を考えるとよい。

効果ではなく課題に目を向ける

よくあるチームビルディングの失敗として、課題の発見や特定が終わってないまま、他のチームで成功してる施策を取り入れることがある。 あの会社が、隣のチームが、知り合いのマネージャーが紹介していたこの施策がスゴい！というものを導入する、みたいな。エンジニアで言えば、インターネットに落ちてるコードを理解せずにコピペするような行為だ。 ※私はコードの意図を理解しないままコピペすることがよくあります

このような事態に陥らないよう、施策を実行する前に「この施策はどのような効果があるか」ではなく「この施策は何を解決するのか」を考えるとよい。 モブプログラミングを例に挙げると、共同で作業することによって「チームにおけるベストプラクティスを学び、コード品質が高まる」という効果に目を向けるのではなく「チームでベストプラクティスが共有されておらず、コードの品質が低下している」という課題に目を向けるのだ。 ※モブプログラミングのアンチではありません

課題は 2 種類ある

運動不足のような「持続的にネガティブな影響を与えるから解決しないといけないもの」と筋トレのような「何らかのゴールがあって、その実現のために解決すべきもの」がある 前者は単純明快で分かりやすい。お腹にお肉が付いてきたから散歩しようくらい単純明快。チーム内のコミュニケーションが減ったから、チームランチを実施しよう、といった施策が当てはまる。このような施策もとても大切だ。

一方、後者はきちんと具体化されたゴールがないと、何を行えばよいのかわからない。 ボディビルやフィジークといったカテゴリを意識せず、ただただ胸のトレーニングだけに勤しんでも、バランスの悪いマッチョにしかならない。 本来は、フィジークの大会に出たいから脚のトレーニングはほどほどにして、胸と肩と背中と腕を満遍なく鍛えよう、といったように取り組むべきだ。

未来とのギャップから考える

チームビルディングも同様だ。チームの未来の状態を定義し、いまの状態と照らし合わせて、その両者のギャップが解決すべき課題となる。 打とうとしている施策がそのギャップを埋める(=課題を解決する)ためのものか、を意識することが大切という話だ。

3年後、5年後にはプロダクトがスケールしてるから、機能開発チーム、運用保守チーム、インフラチームに分けたい。チームを分けるために、各チームのリーダーやマネージャーを担える人材が必要だ。今のチームで働くメンバーが将来的にリーダーやマネージャーへステップアップできるように、リーダーシップを養うワークショップを行おう。社内メンバーのステップアップだけでなく社外からも迎え入れられるように、他社のリーダーやマネージャーとリレーション構築しよう。本来、施策を考えるときは、こうあるべきだと思ってる。

これはチームビルディングに限った話ではない。何かアクションを起こすとき、全てに当てはまる。今回はチームビルディングに焦点を当てたが、すべての業務に当てはまる。

マネジメントを触り始めた数年前の自分に向けたメッセージになってしまった