隣の芝は青く見える。なら全員でやる。

かつてチーム内に、3人ずつの2つの開発グループがあり、それぞれの開発グループで開発・運用するシステムをきっちりわけていました。これはよくあることで体制としては問題ないと思います。しかし、ある場合においては問題となりました。

Aグループの人の意見

• Bグループは新規開発が多くて楽しそうだなあ。こっちは運用ばかりだ。羨ましいなあ。
• こっちは残業時間多いなあ。嫌だ。

Bグループの人の意見

• Aグループの運用大変そうだなあ。助けたいなあ。でもグループ違うしな。
• 案外、運用も心の安らぎがあり、好きなんだけどな。開発以外にももっと運用してもいいけど。

開発・運用作業の割合、さらには残業時間の割合がそれぞれのグループで大きく差がでる状況がでてくると、メンバーからこういう意見が出ます。

このような状況がでたとき、トップダウンでメンバー配置をする、という選択肢もあるでしょう。しかし、いずれ開発・運用するシステムの状況が変わり、同じことがきっと起こると思いましたので、私の解決方法としては、「じゃあ、いっそのこと1つのグループにしちゃおう」でした。

• 人数として計6名になりますが、1つのチームの人数としては問題ない。スクラムの開発メンバー数としても適正。（スクラムで開発してました。）
• 困っている人を垣根なく助けることができる。
• 作業時間がメンバー間で平準化され、残業時間が均一化されていく。
• 1つのシステムを知る人数が増え、属人化から遠ざかる。
• コミュニケーションする人が増え、単純に楽しい。

デメリットとしては、業務知識やシステム知識のメンバーへの共有・教育コストが増大します。しかし、共有・教育時間に使うドキュメントを一旦整備してしまうと、そのシステムの開発に加わる次のニューカマーのオンボーディング資料とすることができます。また、そういったドキュメントを整備することは、ニューカマーに限らず、人が離れるときの引き継ぎ資料も不要になり、将来的には人数の増減に強いチームになることができると思っています。

（余談ですが、リモートワークでの業務が始まって以降、オンラインMTGが増えました。その際、共有・教育するオンラインMTGは画面を録画することで、後によいオンボーディング教材とすることができます。）

私の理想のチーム状態は、チームメンバーが各自、自律的に考え行動ができるようになれることです。スクラムで言う、自己管理型組織です。その観点からすると、今回行ったのは、まずは垣根を取っ払い行動をしやすくし、行動するための業務共有・知識共有をできるようにした、ということになります。

しかし、上の理想には、まだまだ足らず、実際は、いざ行動するときはそのときの個人の気持ち・モチベーションが大事になります。行動する際の気持ちのハードルを低くしてあげないといけません。そのためのヒントとして、心理的安全性が高いか、という観点が大事になると思います。

毒をかんたんに吐けるようにする

私のチームのスクラムでは、1スプリントを2週間でおこなっています。つまり、2週間毎に必ず振り返りを1度することになります。ある日まで、通常のKPTを用いて振り返りをおこなっていました。

• KEEP：良かった点を続ける
• PROBLEM：問題点・課題点を見つける
• TRY：問題点・改善点に挑戦する

数年間はこれでやってきましたが、徐々に違和感がでてきました。

KEEPは良かったことなので、メンバーがあげやすいものになります。しかし、PROBLEMも同様にあげやすいものであるべきなのですが、どのようにそれを改善するか（TRY）が先に頭をよぎってしまい、だんだんPROBLEMの出る量が減ってきてしまいました。PROBLEMを出すと、必ずTRYを考えなければいけないなあ、時間もかかるしなあ、、という心理的なプレッシャーがあったのかと思います。

TRYを考えることは改善につながる、と想像はできているものの言い出すことができない、というのは、ある意味、心理的安全性が阻害された不健全な状況と言えるのでしょう。

そこでですが、いつからか、メンバーの提案によりこうなりました。（このあたりは自己管理型組織ができてきたのかなあと思います。私の役割としては「いいねぇ」と言うだけです。）

• KEEP：良かった点を続ける
• BOYAKI：ぼやきたいことを言う
• PROBLEM：問題点・課題点を見つける
• TRY：問題点・改善点に挑戦する

略してKBPT（ケブプト）になりました。するとどうでしょうか？BOYAKIが異常に出てきます。なにかモヤモヤしている些細な事であっても、何も阻害されない状況で、ボヤくことができるようになりました。この方法によって意見の出る量が格段にあがり、メンバーの気持ちがどんどん出るようになってきたと思います。

一方で、デメリットはあります。このボヤキは本来改善しないといけない、PROBLEMにあるべきだろうな、と思うこともBOYAKIに上がってしまうことがありました。これは、その場で「このボヤキ落ちしているのは、TRYを考えたほうがいいんじゃない？」とPROBLEMに昇格させることがたまにあります。これからも振り返り手法は、KBPT以外も含めて、より気持ちが出せ、自由に意見が言えるようなものを模索していきたいと思います。

長くなってきてしまいました。これらの他にも、「チーム内で心理的安全性を高める」「自己管理型組織」へつながると信じて、以下のことやってみたりしています。

• 上長（私）が偉そうに喋る時間は極小にする。（特にチーム会。基幹システムグループ サービスインフラチームの紹介です の最後の方の話です。）
• 身構えるような固い言葉を使わない。（システムリソース監視報告会 → システム健康診断）
• ニューカマーとは積極的に仲良くなる。（偏愛マップ、実家自慢、俺の音楽史、PCの中のツール自慢）
• 個人の問題はチームの問題とする。（個人 VS 問題、ではなく、チーム VS 問題）
• 学習のための時間を必ず確保する。（輪読、プログラミングチャレンジ、自己学習）

これからどうするか？

さて、今思うことは、少々、「チーム内で心理的安全性を高める」アクティビティをやりすぎた感じがあります。やり過ぎると、チームメンバーがコンフォートゾーンに陥っていきます。

コンフォートゾーンは、慣れ親しんだ環境で安全が確保されている良い面はありますが、個人・チームの成長を考えときに、本来は、もっとラーニングゾーンに行く機会を増やさないといけません。チーム内の活動としては、意見が言いやすいよい土壌は醸成されてきましたが、例えば、チームの外の人とのコミュニケーションや、チームでは今使っていない技術スキルに触れる機会を増やし、未知の領域に突入する時間を増やさないといけません。

これが現在のチームの課題だと思っています。ので、徐々にチームの外への発信ということを最近はじめました。これまで個人学習をしたアウトプットはチーム内で発表していましたが、これをチームの外の人もだれでも参加どうぞ、としてみたり。また、全社で取組中ですが、ブログ記事をエンジニア全員書いて公開していこう、Tech Talkに参加しよう、など。何か便利なツールを作ったらチーム内に閉じず、全社に公開していこう、など。そしてフィードバックや良いストレスを受け、人は成長していくものだと思います。

やれることはまだまだありそうですが、このあたりに現在力をいれている最中です。

このあたりの自身の経験については、「トラブル対応で私はいっぱい成長してきた」に書きました。

以上が、サービスインフラチームのチームマネジメントになります。ご参考になりましたでしょうか？

偉そうに書いてしまいましたが、私がチームリーダーになる以前からすでにあったチーム文化・活動も中にはあり、しっかりと恩恵をいただきつつ、継承し、さらにエンハンスしていきたいと思っております。

最後に感想ですが、私の場合、最初にチームリーダーという役職が与えられ、チームマネジメントを行き当たりばったりやってきましたが、その都度、マネジメントスキルやMTGファシリテートスキルなど、いろいろなスキルアップができたな、と振り返って思います。まあ、やったらやったで楽しいもんだな、と。HR Techに興味があるこの頃です。

以上です、ありがとうございました！