最近よく「良いチームとは？どうあれば良いチームなのか？」という疑問をずっと抱えていたのだけども結論が出ずに堂々巡りをしておりちょっと困っていた。 ところが今朝はてブみていたら id:hase0831 さんが明確な答えを示していてくれて「そうか、これが足りなかったのか！」という気づきを得た。
技術力が決して高いと言えない開発チームで働いたときに「このチームは技術的課題はあるけども良いチームだな」と感じることと「このチームは技術的課題云々以前の問題がありすぎるチームだな」と感じることがあった。 両者にはある程度共通する(というか内容の根本自体はほぼ同じ)課題や問題があって「じゃあなにが良いチームと悪いチームを分ける分水嶺になっているのだろう？」と考えていた。
技術的レベルにおいては双方ともに同じようなレベルだったのだが明確にチームとしての明暗が分かれているように感じた。 TeamGeekなども読んだけども結局のところ、この疑問の解決や決定的な分析は図れなかったのだけどもここで挙げられている3つの点におけるアプローチが違うということに気づいた。
悪いチーム
恐らくわかりやすいだろうと思うので悪いチームからのアプローチを紹介する。 これらの状態に陥っている場合はチームが機能していない可能性が高いと思うので早急に改善すべき状態だといえるだろう。
Why？まで落とさず作業を進める
よく言われる内容だが「何故それをすべきなのか？」が説明されないまま仕事をすると多くの場合以下の問題が発生する
- 指示したものと違う提出物があがる
- 見た目は指示したもののように見えるが実体が異なる
- 指示されたものにはなっているが将来的な課題に関する対応策が検討されない
- 指示されたことしか行わない
これらの話しがでるとよく「指示の裏にある意図を作業者が汲み取って欲しい」ということを言われる。 この意見は一見正しいのだけども「指示の裏にある意図を指示者が伝える」のも同じくらい重要だと考えている。 これらはどちらかだけでは成り立たなくて悪いチームはどちらかに押し付ける形で仕事をしていることが多いように感じた。
これらはある意味でコミュニケーションにおける問題だと考える。 そのための解決策は「飲みニケーション」などではなく、「正しく伝える努力」と「正しく理解する努力」を双方が理解することだと思う。 悪いチームはだいたいこれらの努力の方向性が一方通行であることがほとんどであるように思う。
作業者からすれば「指示された通りにしたのにリジェクトされた」と不満が溜まるし「そもそもなにがしたいのか？」というWhy?が共有されていないのだから どうなっていて欲しいのか？将来的にどう発展させるのか？という将来像が見えずただ言われたことをそのまま行うという最悪の状態になる、悪循環のループが完成する。
この状態が何故最悪かというと「何故こんな状態になっているのか？」という問題が発覚したときの分析時に「指示された通りにやりました、私の責任ではありません」という責任の放棄となすりつけあいが発生してしまうからだ。 そしてその悪循環に疲弊したメンバーから辞めていくことになる。
こうなるともうチームとしては崩壊している状態といえる。 マネジメント権限を持つ人間はこれらの問題が発生する前に対処する必要がある。 正直このような状態からチームを立て直すのはかなり厳しい状態であると思う。
これらの問題をマネジメント権限を持つ人間が検知するには 「指示されている内容がわからない」「なにがどうなっていればいいんですか？」 というような意見が作業者から出たら限りなく赤に近い黄色信号になっているのでなにがどう足りていないのかを検討すべきである。
全員の持つ情報粒度にバラつきがある
全員が同じ情報を全て知っている必要というのはないと思うが「誰が知っているのか？」「どこに情報があるのか？」が共有されていないとチームメンバー間に温度差が出来てしまう。 この温度差というのはやっかいで検知するのが難しい。 ただこの温度差というのは不平不満の温床になるので出来る限り無くす、それが難しければ温度差を軽減する必要がある。
件のブログでも危ういところまでいったとのことなので情報を管理する人は特にデリケートに扱う必要があるのだと思う。
大まかにでも「ここからここまでは全員が知ることのできる情報」「ここからここまでは管理者のみが知り得る情報」というようなカテゴライズをするくらいしか解決策が思いつかない。 しかしそうすると「この情報はどっちなのか？」という例が必ず浮上してくるし、その対処に悩む内にうやむやになってしまうパターンがほとんどなのではないかと思う。
TED Talkだったと思うが今まで機密情報だったオープンにして誰でも閲覧可能にしたところ業務効率が飛躍的に向上した、情報に機密性を持たせることによるメリットよりもデメリットのほうが大きいという話しを以前なにかで読んだ(もしくは見た)がチーム単位であればそれでもいいかもしれないが会社規模となるとなかなか難しいのではないかと思う。 ただそういう方針を話しあったり常にブラッシュアップしていけば温度差というのは非常に小さい影響で収まるのではないかとは思う。
またこれらの温度差をキャッチアップする方法として1on1などの手法はあるが結局のところこれらは「どうせ言っても無駄だろう？」という諦めをメンバーが感じてしまった段階で意味がなくなってしまう。 信頼関係が構築できていないところに手法だけ持ってきても意味がないのだ、まずは崩れてしまった信頼関係を構築するところから初めなくてはいけない。
「違う」「間違ってる」しか伝えない
これは最初のWhy?にもかかる部分があると思うのだけど悪いチームというのは最初のWhyが出来ていないせいで期待したものと違うものがあがった際に「これは違います」としか伝えないことがほとんどだと言っていい。 明らかな不具合、例えばブログのエントリを投稿したのに表示されていないとかならそれでもいいと思う(というか普通に考えて大問題だしそれで伝わらないのは別の意味でやばいと思う)
ところが多くの場合は「ここのAという部分が期待した動きになっていない」「このBという表示が本来B'になっていて欲しいのになっていない」というケースが多い。 悪いチームはこの説明を後出しでいうことが多い。 当然、作業者側からすれば「最初に説明しろよ！」と不満が溜まる。 結果チームとしての空気は悪くなるし指示者に対する不信感も募るため「言われたことしか行わない作業者」が出来上がってしまう。
言われたことしかしない部下や社員がいると嘆く前にまず指示者は分析をすべきだと思う。 だいたいの場合は嘆いているだけで作業者側からすれば明確な理由に対する対策が行われていないことが殆どであるように思う。
良いチーム
Why？まで落とさず作業を進める
良いチームは多くの場合伝え方が上手いことが多い。 「Aの機能を追加してほしい、以前似たような実装をBプロジェクトのCに実装してある」などとしてどういう状態が理想なのかを具体性を持って説明する。 これを受けた作業者は当然Cの機能を元に考えるため車輪の再発明を行わなくて済むし、具体的なイメージとしてC機能があるため指示者とのズレも最小限となる。 また「C機能をそのまま使えない理由はなにであるか？」とか「今後この機能はD機能に移行していくことが予想されるので移行が簡単に行えるように実装しよう」と考えることが出来る。
これはWhy?がきちんと支持者と作業者間で共有されているからだろうと思う。
全員の持つ情報粒度にバラつきがある
良いチームの場合「これは全員が知ってる(知っていない)」が明確であることが多いように思う。 そして「このことなら社内のナレッジツールでみたことあるよ！」とか「それは○○さんに聞けばわかるよ！」とかってパターンが多い。 この例でいうなら○○さんが管理者しか知りえないことを知っているという認識がおおよそ全体に認知されていることが大事という話し。
駄目なチームは「誰に聞けばいいのかわからない」が共有されてしまっていることが多いが良いチームは全く逆で「誰に聞けばいいか」が明確なため 「こういうことを聞くのは誰かわからない」というときに「○○さんなら知ってるんじゃないか？」という質問しやすい空気につながっているのだと思う。
「違う」「間違ってる」しか伝えない
良いチームは「ここは出来ればこうしてほしかったですね。」とか「こうやれば次回からはもっと早く実装できますよ！」などOKなときでもどうしてほしいかをきちんと伝えることが多い。 ここが悪いチームとの決定的な差かなと個人的には思っている。 こういう小さな信頼の積み重ねや1つ1つの事柄に対する信頼感がチームを育てるのだと思う。
まとめ
気づけばそこそこ書いているが結局のところ悪いチームの駄目なところっていうのは共通してるけど 良いチームの良いところっていうのはそのときどきやメンバーで変わってるという印象以上のものがないんだよね。 ということで凡人たるぼくらが出来ることは潰せるデメリットは早めに潰すという対処療法しかないのだよ。
前職の同僚によく言われたことだが「一気に変えることは出来ない(難しい)ので少しずつ変えていきましょう」ということですね。 これが出来るからこそ良いチームなんだと。
