こちらの記事はDIVXアドベントカレンダー2023の19日目の記事です。

はじめに

こんにちは。DIVXでプロダクトマネージャー（PdM）をしているサンディです。

今回の記事は、私がPdMとして自社開発チームに携わってきた10カ月でチームをビルディングをする上で経験した課題や実践してみて良かったことを共有しようと思います。

自社開発や受託開発に関わらず、チームで仕事をしている人であれば共感できることだと思います。

リーダーになりたての人や、チームビルディングについて悩んでいる人の参考に少しでもなればと嬉しいです！

対面してきた課題

まず、10カ月を通して直面してきた課題についてざっくりですが説明をしたいと思います。

多くのチームも直面する課題だとは思うのですが、私がいる自社開発チームも例外ではありませんでした。

大きくまとめると、以下二つです。

認識の齟齬が多い

・お葬式ミーティング

・認識の齟齬が多い

仕様やスケジュール、体制など様々なことに関して、チーム内での認識の齟齬が多くありました。

日頃の小さな「まあいっか」「後でいっか」「一旦いっか」の積み重ねが原因です。微修正で効く範囲内のズレを飛び越えた時に、認識の齟齬が多発してしまい、意思疎通が格段に難しくなります。

大事なのは、日頃からどれだけその小さなズレに目を向けられているか。そのズレを許さずその都度修正ができているかです。

日頃の微修正ができていれば、小さなコミュニケーションですみます。

私は、この微修正を怠っていました。本当は納得いっていないのに会話を終わらせてしまったり、自分の頭の中だけでを完結させてしまっていました。

時にはコミュニケーションに疲れてしまうのも人間だとは思いまが、日頃の小さなコミュニケーションを怠る方が後から大きうなつけが回ってきます。

お葬式ミーティング

まず、お葬式ミーティングって何かについてですが、特定の誰かだけが話をして他のメンバーは反応なしの”とても静かなミーティング”をお葬式ミーティングと個人的に呼んでいます。笑

デイリーのファシリテーターを基本的には、私やPM、ベテランエンジニアが行っていたのですが、ファシリテーターのみが声を出して、その他の参加者は無言でというお葬式ミーティングが行われていました。

お葬式ミーティングでは、本当に認識があっているか？問題はないのか？不安になることが多です。また、発言をする人が決まっている場合、普段発言しない側がが抱えている問題の共有がしづらく、発見も遅れてしまいます。

実践してきたこと

各課題に対して、いろんなことを実践してきました。

効果がなかったものありますが、ここでは特に効果的だったものを共有したいと思います。

日頃のコミュニケーションを増やす

デイリーの場を待たずに、問題を共有できるように日頃からコミュニケーションに機会を増やしました。

元々、週2出社でフリーアドレスだったのですが、週3出社で近くの席で固まって座るルールになりました。（出社に関しては、会社自体のルールの変更です）

すぐ話せる距離にいることや空気感が伝わるというのは、問題を素早く察知したり、認識合わせをするのにとても有効でした。

今回は、オフラインコミュニケーションにはなりましたが、オンラインでも似たことはできると思います。みんながログを残すようにしたり、チャットツールを活発に動かすことです。

また、この後の文章にも繋がりますが、デイリーを問題を共有する場にしてしまうと、その時間を待つことで問題が大きくなるまで抱え込むことになってしまいます。

問題が小さい内に微修正を日頃から行うようにしていきましょう。

ミーティングの目的を明確にすること

お葬式ミーティング脱却のために効果があったことは主に以下二つです。

・デイリーというミーティングが何のためにどういう場にしたいのかをチームメンバー全員で認識を揃えること

・ファシリテーターをチームメンバー全員からランダムの交代制で行うこと

デイリーというミーティングが何のためにどういう場にしたいのかをチームメンバー全員で認識を揃えること

まず、デイリーをどういう場にしたいかを考えました。チームメンバー全員が全体を把握できる・より良くするための提案や共有ができる場にしたいと考えました。

毎日のデイリーで使う議事録のシートには、その目的を明確な文章として載せています。ミーティングに対して、傍聴者ではなく全員が参加者であると認識してもらいました。

このミーティングの目的達成のためには自分の行動が必須であることをチームメンバーが理解し、そのために発言や提案をして良いんだ、むしろするべきだと考えてもらうようにします。

ファシリテーターをチームメンバー全員からランダムの交代制で行うこと

ファシリテーターを誰がやるかが重要というわけではありません。あくまでも大事なのは、ミーティングの参加者全員がそのミーティングの目的を理解し、その目的達成のために主体的に動けるようになっているかです。

私やPM、ベテランエンジニアがファシリテーターを行うのは、プロジェクト全体の進捗確認や状況把握、意思決定をスピーディーに行える利点がありましたが、ジュニアエンジニアにとってはデイリーの場が自分の問題を共有する・解決してもらうための場になってしまっていました。

ただ、私たちの目指しているデイリーの場は、チームメンバー全員が全体を把握できる・より良くするための提案や共有ができる場です。

ファシリテーターは、チームメンバーが各々どのタスクをやっていて何に困っているかを聞くので、自動的にプロジェクト全体の進捗を把握できます。そこで、ファシリテーターをチームメンバー全員で毎日ランダムに交代で行うことにしました。

結果的に、ジュニア・シニア関係なく、プロジェクトを前に進めるための行動や提案が活発になりました。

例として、実際に以下の効果が見られました。

・業務効率化のために、ER図の自動生成ツールを導入しないかの提案

・チーム体制を、設計チームと実装チームに分けてスピード感を上げられないかの提案

・実装方針の相談に対して、全員が各々の意見を言う

最後に

チームビルディングについて、大体のベストプラクティスなどはあると思います。チームが直面している課題も、大体はどこかのチームが既に直面している課題なことが多いです。

ただ、全く同じチームというわけでは無いので、その時をのそのメンバーとしっかり向き合ってどう解決するかをメンバーみんなで話す・みんなが合意をすることが大事です。

自分が所属するチームの色には、どういう手法が合うのかチームで模索をし、同じ方向を向いて解決に向かっていきましょう。

私の所属するチームも、まだまだ課題はありますが、メンバーで課題を共有し解決策を一つずつ実践して頑張っていきます！

最後まで、読んで頂きありがとうございました！

divxでは一緒に働ける仲間を募集しています。

興味があるかたはぜひ採用ページを御覧ください。