チームの症状と処方の考察
はじめに
自己紹介を少しさせてください。
私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。
その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。
チームの健康状態とは
チームの状態を表す指標として心理的安全性はよく聞きますよね。
広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。
「問題点の指摘」や「自分の弱みの開示」「失敗の報告」といった行為には、通常「対人リスク」が伴います。「心理的安全性」が高い状態とは、突き詰めると、このような「対人リスク」を伴う行動が増えている状態のことだといえます。
...
正しく機能している心理的安全性は、「問題に対して向き合う状況」を生み出します。この「問題に対して向き合う状況」のことを責任という指標だとすると、心理的安全性と責任は次のようなマトリックスを形作ります。
引用: エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング
コンフォートゾーンは、責任がなく心理的安全性が高い友達同士のサークルのような状態、不安ゾーンは心理的安全性がなく責任感に押しつぶされそうになっていく状態でしょうか。
つまり、心理的安全性が高いだけではなく、問題に向き合っている状態のラーニングゾーンになってはじめて生産的なコミュニケーションや問題解決のアクションが取れるようになるということです。
もしラーニングゾーンが「健康」であるとするならば、その他は何かしらの「症状」が出ているということになります。
またチームの状態も健康と同じように、少しのきっかけで変化します。大切なのは今の状態を見極め、正しい「処方」をすることです。
私自身、組織づくりが下手くそで、実はずっとチームは不健康でした。また、自身も症状を発症していました。
症状の経験値は溜まっているので、経験の中からそれぞれありがちな症状（と可能な限り処方）をご紹介し、迅速な問題解決のお役に立てれば幸いです。
症状の具体例と処方
下記は実際に経験した症状です。それぞれ紹介していきます。
■不安ゾーン
1. ＜軽症＞ぼかした発言が増える
2. ＜重症＞不確実性が減らない作業 / 報告が増える（問題を隠す）
■コンフォートゾーン
1. ＜軽症＞原因を外に求める / 主語が大きくなる
2. ＜重症＞議論ができない
■無関心ゾーン
1. ＜軽症＞議論中の発言がなくなる
2. ＜重症＞対話（雑談）ができなくなる
■不安ゾーン
心理的安全性がなく責任感に押しつぶされそうになって心が病んでいく状態です。
特徴として「〇〇だから〜すべき」という思い込みから、各人が１人で抱え込んでいることが多いです。
重症になると問題を隠そうと働いてしまうため発見が難しいです。
＜軽症＞ぼかした発言が増える
「今日中にはできる思う」「何とか午前中に終わらせたいと思う。多分何とかなる」など進捗を確認する朝会などでよくある会話だと思います。
ただこういった発言には結構気をつけた方がいいです。
なぜならイメージがついているタスクであれば、「あと3時間くらいでできるので今日中にこれを終わらせます。」と言えるし、イメージついていないタスクなら「1時間作業してみたが、正直タスクのイメージがついていない。この後相談して改めて報告させて欲しい。」など具体的にぼかすことなく言えるからです。
こういったぼかした発言が出た場合は 「自分は一番経験が長いから分からないことがあっても１人で解決するべき」などの思い込みから「責任感」「失望されたくない」という感情で思考停止しており、本当はどう進めたらいいか分からない作業を１人で抱えこんでしまい、それを言えずに自分を追い込んでいるかもしれません。
実際に私も下記を経験し、ストレス性胃腸炎になりました。
1. 「自分が一番経験があるから私がちゃんと１人で進めるべきだ。クライアントもそれを望んで依頼しているはずだ」と思う
2. 何が分からないかも分からない問題をずっと考える
3. チームの朝会では「なんとかする」「MTGが多くて作業できていない」と誤魔化す
4. 「進捗がないのは自分の努力が足りないからだ」と思う
5. 朝から晩まで考えても進捗がない
6. 「自分のスキルが足りないからだ」と思う
7. 寝る間を惜しんで勉強しても進捗がない
8. 🤯
今思うと「プロだからちゃんとクライアントをリードしてプロジェクトを円滑に進めなきゃいけない」「クライアントに失望されたら嫌だ」などクソの役にも立てないプライドや責任感が邪魔して思考停止していただけだなと思います。思考停止した1ヶ月は今でも本当に悔やまれます。
ちなみに組織改善でアドバイスに来てくれていた方に相談したときに 「プロだからこそ相談するんです。何のためにチームがあるんですか？」 と言われ目が覚めました。
＜重症＞不確実性が減らない作業 / 報告が増える（問題を隠す）
重症になると、積み重なった時間と反比例して、心理的安全性が下がるので、余計本当のことが言いづらくなります。そうなると問題を隠す方向に動いてしまいます。
「本当は何をしたらいいかわからないけど何かをしなきゃ…」という考えのもと、自分で自分の仕事を増やすというループに陥ります。
その結果、「似たようなアウトプット」「ネクストアクションが伴わない報告（ただ共有するだけ）」など不確実性が減らない作業や報告が増えます。
一見すると何かやっている感じが出るので、パット見では見抜けないこともあります。
マネージャーやリーダーはアウトプットとコミュニケーションの質まで注視する必要があります。
＜処方①＞コミュニケーションルールの設定
心理的安全性を上げる施策として、コミュニケーションルールの設定があります。
心理的安全性を上げるために私がいた開発チームに新たに追加されたコミュニケーションルールが「True」と呼ばれるものでした。
その名の通り「腹を割って本音（True）でコミュニケーションしよう。」というルールです。こういったルールは設定するのは簡単なんですが、浸透するのが一番むずかしいです。そのためにクライアントである事業の開発責任者の方がやっていたことは下記です。
1. 毎回全体会議でTrueの目的を共有する
2. Trueしてくれたことに感謝をする
例）発覚した障害やバグをエンジニアが報告する際に「言いにくいことをTrueしてくれてありがとう。一緒に改善していこう」と言う
3.普段の会話から「〇〇さん、それ本当にTrueしてる？」と冗談まじりで言う
こうして上層の人たちがTrueしやすい空気を作り出すことで、開発チームにも徐々にTrueが根付いていきました。
1ヵ月後くらいには「Mr.True」という肩書の人も生まれました。会話の中でも「それTrueしてる？」が聞こえるようになりました。
浸透には、上層の人たちが自ら率先してルールを実行することが何より重要だと学びました。
＜処方②＞相互進捗レビュー
心理的安全性を上げる施策とは文脈が違うのですが、 不安ゾーンに陥る時間を少なくするために日々検査する仕組みを作りたいと思い、普段の朝会のアジェンダに、自分の進捗を他の人が検査する項目を加えることにしました。
↓朝会のアジェンダはこんな感じです
理由としては、下記です
1. 自分のタスクの進捗が良ければいいという考えになってしまっていたため、チームとして全てのタスクを終わらせるという仕組みにしたかった
2. 責任感やプライドで正しい判断ができない場合のストッパーが欲しかった
3. スクラムマスターの負担を減らしたかった（スクラムマスター以外の業務も抱えていたので）
チームはUIデザイナーとPMが混合で、UIデザイナーがPMのタスクを、PMがUIデザイナーのタスクを検査することもありましたが、特に問題なく検査 / 対応策の検討ができました。
検査対象は「仕事の進め方」なので、職能や個人のスキルは関係ありません。 私もUIデザイナーに検査、対応策の検討を一緒にやってもらいましたが、「ここの作業は手戻りが大きそうなので、早めにやってクライアントに見せた方がいい。なのでこの後予定をすぐおさえましょう」など「PMじゃん」って思うくらいの対応策を出してくれてめちゃくちゃ助かりました。
人間、冷静であれば色んなことが見えるし実行できるものです。 何かができないんだとすれば、それは個人のスキルが低いというわけではなく、感情に囚われて思考停止しているだけなのです。
実績としては、2スプリント連続でタスクを全てDONEに持っていくことができました。
■コンフォートゾーン
コンフォートゾーンは心理的安全性が高く、責任が低い、一見するとチームとして「仲が良い」状態です。特徴として「共感」をベースとしており、同調圧力を働かせて問題解決から逃げることが多いです。
＜軽症＞原因を外に求める / 主語が大きくなる
最初の症状は、自分たちのチームの外に原因を求めるなどの他責的な言動から始まります。
おそらく自分たちの外に共通の敵を作った方が共感を得やすいのと、自分たちの現実に向き合わない方が楽だからです。「プロダクトオーナーの完了条件が良くない」「エンジニアは楽しようとしている」のような発言は良くチームで聞いていたし、私も実際に発言してしまうこともありました。
今の発言にあるように「プロダクトオーナー」「エンジニア」全員が本当にそうなのでしょうか？きっと発言者は誰か特定の人を指して発言しているはずです。（なぜならその人はプロダクトオーナーとエンジニア全員に会って統計的に調べているわけではないからです。）
「金子っていうプロダクトオーナー」を思い浮かべているのに「プロダクトオーナー」全般は皆そうだとして、自分で解決できない問題にしてしまっているのです。
本当は「金子っていうプロダクトオーナー」に「完了条件をもう少し細かく書いてくれませんか？」と一言言うだけで問題は解決するのに。
また主語が大きい方が共感を得られる可能性が高い理由から、コンフォートゾーンでは主語が大きい発言が目立つようになります。
＜重症＞議論ができない
重症になると「共感」が正義となり、意見を闘わせる議論ができなくなります。
違う意見が出ると「何でそんなことを言うんだ？私達は仲間のはずなのに」という感情が攻撃的 or 悲観的に働き、その人自体を理解できないものとして位置づけて問題解決を放棄してしまいます。
こういったチームは飲み会やイベントなど意見を必要としない活動は活発だと思います。一見すると「仲の良いチーム」「アットホームな現場」として見られがちです。ただ実体は同調圧力を働かせて問題解決から逃げているだけかもしれません。
マネージャーやリーダーは単純なコミュニケーション量ではなく、チームの議論量を注視する必要があります。
私も同じチームのエンジニアと週3日くらいで飲みに行ってた時期がありました。仲は良かったと思います。ただ仕事上で意見を言うことがあり、その後から何となく飲みに行かなくなりました。今思えば彼らの同調の和からはずれたのと、自分自身飲み込まれないように意識して飲み会に行かないようにしてたのかもしれません。
＜処方＞？？？
これは正直よく分かりません。私自身解決できませんでした。
知見がある人教えてほしいです。
■無関心ゾーン
無関心ゾーン自体すでに重症だと思います。心理的安全性も低く、責任も低い状態です。
自分の経験からすると「諦めた状態」というのが一番近いかなと思います。
＜軽症＞議論中の発言がなくなる
人間は何もしないのが一番楽です。発言しない人は今までの経験から「どうせ言っても変わらない」と思って発言するのすら諦めているのかもしれません。
＜重症＞対話（雑談）ができなくなる
少し話がはずれますが、組織におけるコミュニケーションの形式を分類すると議論・対話・雑談に分けることができるそうです。
個人的にはその中でもステップがあり、必要な信頼ポイントによって、雑談・対話・議論の順になると考えています。
その中で変化が起きお互いの信頼が生まれるのが対話です。
参考: デザイン組織における「対話」のススメ
https://note.mu/stam_mat2/n/nf40dc2bd60c3
対話ができなくなる状態...例えば1on1でも何も発言が出ない、本心を言わないなどは、もはや信頼関係を築くのを放棄しているのも同じだと思います。
私も無関心ゾーンに陥ったときは、対話はおろか雑談もできないような状態でした。
＜処方＞第三者の介入
こうなると当事者のマネージャーがどうにかするよりも、第三者に介入してもらい、お互いの胸の内を打ち明けて、第三者が問題解決に動いた方がいいです。
実際のプロジェクトでも、開発責任者との関係性がうまくいってなかったときに、下記メンバーで2時間「本音を言う」会をクライアント主導で開いてもらいました。
1. 自社 - チームメンバー7名
2. 自社 - マネージャー2名
3. クライアント- 事業責任者1名
4. クライアント- 開発責任者2名
事業責任者の方にファシリテーションをしてもらい、チームメンバーと開発責任者がそれぞれ今まで思っていたことを言いました。
その後の問題解決はもうひとりの開発責任者の方が主導で動いてくれました。
あの会で本音を言い、聞かなければ、未だにお互い憎しみ合って仕事していたかもしれないです。
※私の場合、この「本音を言う会」の後、開発責任者と3時間対話をする機会があり、関係が正常に戻りました
さいごに
チームの健康管理は、ユーザーインタビューよりも、要件詰めよりも、実装よりも何よりも優先すべきだと学びました。
プロダクトがクローズしないためには、継続的に改善していく必要があり、そのためには、不確実性に強く生産性が高いチームが必要だからです。終りがあるプロジェクトについても3ヵ月以上続く場合は健康管理に気を遣った方がいいと思います。
健康と同じで少しのきっかけでチームの状態は変化します。重要なのは継続的にチームを観察することです。
また今挙げたのはあくまで定性的なものなので、定量的なサーベイと合わせてチームの健康状態をチェックすることをおすすめします。
この内容は私の浅い経験からの考察なので間違った部分もあるかもしれません。優しく色んな意見をもらえるとありがたいです。
＜番外編＞セルフメディケーション
自分の健康状態って自分だと気づかなかったり、目をそむけたりしてしまうものです。
私の傾向として不安ゾーンに陥ることが多かったので、自分の状態をいち早く把握するためにやっている工夫を少し紹介できればと思います。
超高速PDCA - ポモドーロ・テクニック
ポモドーロ・テクニックは時間を区切ることで集中力を高め、生産性を上げるテクニックです。知っている人も多いと思うので、概要は割愛します。
基本的なルールは一緒です。個人的にアレンジしている点は1ポモドーロにつき、1PDCAを行うということです。
↓こんな感じです。
作業の基本的な流れです。
1. Planに自分が25分間で行える見積もりの作業をできるだけ具体的に書く
2. タイマーをスタートさせる（25分）
1.＜作業中＞タスクとは別に確認したい点や気になった点をその都度Action欄に書く
3. 25分間終了後、5分間の休憩
1. ＜休憩中＞終わらなかったタスクがあった場合、なぜ終わらなかったのか？をCheckに、それに対する改善策をActionに書きます。
2. ＜休憩中＞Action欄にあるものの中から休憩中に解決できそうなものを対応
3. ＜休憩中＞1.に戻る
ここで重要なのはCheckに自分がどんな分析をしたか？です。
私の場合、Checkに「途中で別のタスクをやってしまった」「途中でネットサーフィンしてしまった」など別のことに時間使ってしまったと分析したとき、「実際はどう進めたらいいか分からず現実逃避している」という可能性が高いです。
その場合、ポモドーロを中断し、一旦何が分からないのか分かるまで、他の人に相談したり、紙に書き出してみたりすることにしています。（その後何となくイメージがついたらポモドーロを再開して作業を進めています。）
今までの経験から自分の傾向を見つけ、その傾向が出たときのフローチャートを決めておくことで、悩む時間を少なくし、不安ゾーンに長く陥らないようにしています。
もともとポモドーロ・テクニックは時間を区切ることで集中力を高め、生産性を上げるテクニックですが、私は25分ごとに自分の健康状態を把握することに使用しています。（なので結構グダグダだったりしますが）
もし良かったらお試しください。
以上です。最後まで読んでいただき、ありがとうございました！