チームのコミュニケーションの問題はモブで解決するよ

on

プロジェクトが終わって完了報告会やふりかえりの場を持つと、プロジェクトの目的を達成しているかQCDのいずれかでプロジェクトの目的を達成できないかったに関わらず、もっと上手にやればよかった、やりたかったと出てくるコメントが

「コミュニケーションをもっととればよかった」

というものです。

聞いている方としては、そんなことは必要かどうかその場でないと判断できないのだから、

「その場で判断して自らコニュニケーション＝意思伝達をすればいいじゃない」

、と思うわけです。こういったコメントは裏を返せば、意思決定の能力が低いですといっているのと同じなんだよ、と思っているんですよ。（ニッコリ

コミュニケーションをもっと取りたいはどうして？

ふりかえりでエンジニアはどうしてもっとコミュニケーションをとればよかったと思っているのでしょうか。

コミュニケーションは意思伝達の手段を丸っと表している表現ですから、コミュニケーションを取ること＝意思伝達することで実現したことがあった、と捉えることができます。

では何を実現したかったか。

自らコミュニケーションをとっていれば、自分の作業をもっと間違いなく、効率的に終わらせることができた、ということでしょう。

・質問をするのを躊躇った
・疑問に感じた技術的な質問を先送りした
・自分しか持っていない情報を共有しなかった

 こうした自分に指を向けたふりかえりでの気持ちは、その逆も間接的に求めているものです。

こうしたふりかえりの気持ちは、その場で解決してほしいものです。欲しいという表現にしているのは、当事者でなければ解決できないから。しなさい、といってできるものでもないのです。これ、大事です。

どうしたら気軽にコミュニケーション取れる？

聞くこと、教えることのハードルを下げることが一番効果的です。それもチーム全員の。

チームの中で一人だけハードルを下げてもそれはチームの中でのコミュニケーション＝意思伝達が一人だけ下がるのであって、全員が同じレベルにならなければハードルが高いままのメンバに同じ気持ちが回るだけです。

モブろう

プロジェクトの一番最初のWBSをチーム、ープロジェクトの人数が多ければサブチームと数人程度がおすすめですー、全員で作業をしてしまいましょう。

用意するもの

・プロジェクタ１台
・PC１台

・人数分の小さな作業

ルール

・作業を担当する人がPCを操作する
・作業時間を決める
・周りのメンバは必ず助言する

 人数分の作業を順繰りに終わらせる。

たったこれだけ。

ルールに揚げ足取りのような指摘にならないように、と追加してもいいです。まあ、どうせ自分の順番に同じことをされるので自分が気持ちよく助けて欲しければ気持ちよく助けてあげましょう。

これの良いところはコミュニケーションが問題だったという点を解決できるのです。ほら。

・質問をするのを躊躇った　→　その場で尋ねられる
・疑問に感じた技術的な質問を先送りした　→　その場で解決できる
・自分しか持っていない情報を共有しなかった　→　その場で共有できる

これやるととっても疲れますが、得るものが多いです。