Blog

目指せ、自己管理型チーム! 役割分担の垣根を取っ払い、心理的安全性を高めるチームマネジメント手法の紹介

ニフティ株式会社でシニアエンジニアしています芦川です。

前回の「基幹システムグループ サービスインフラチームの紹介です」に引き続き、今回は、私がチームマネジメントをこれまでどうしてきたか、これからどうしていくか、についてお話したいと思います。

まずは数年前に話は遡ります。

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

かつてチーム内に、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に興味があるこの頃です。

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

We are hiring!

ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です!
ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! Tech TalkやMeetUpも開催しております!
こちらもお気軽にご応募ください!