DMMにおけるユーザーレビュー基盤の変革(心理的安全性を高めるワークショップを行いました)

サムネイル

はじめに

はじめまして。プラットフォーム事業本部の室木(@masa-m)です。
私はDMM.comのユーザーレビュー基盤の開発・運用・保守を行うチームでスクラムマスターをしています。
2018年7月ごろにチームが結成され、私はすでに稼働していたユーザーレビュー基盤や通知配信基盤を引き継ぎました。
現在、ユーザーレビュー基盤をさらに発展させるためにリプレイスを進めています。

今回、我々のチームが行う心理的安全性の担保に役立つ取り組みをご紹介したいと思います。

過去のユーザーレビュー基盤の変革シリーズは以下のリンクよりご覧いただけます!
ユーザーレビュー記事一覧

心理的安全性とは

簡単に言えば、「ありのままの自分を受け入れてもらえる環境や雰囲気」です。

  • 自分が間違いをしたとき、それを素直に認められる雰囲気
  • 分からないことや困っていることがあるとき、チームに助けを求められる雰囲気
  • 失言や失敗をしても、拒絶や非難されることのない雰囲気

このように思えることができれば、「心理的安全性の高いチーム」と言えるはずです。
Google re:Work が公開する記事では、チームの効果性の向上に関する5つの柱を下記のように定義しています。

  • 心理的安全性 - 「チームの中でミスをしても、それを理由に非難されることはない」と思えるか。
  • 相互信頼 - 「チームメンバーは、一度引き受けた仕事は最後までやりきってくれる」と思えるか。
  • 構造と明確さ - 「チームには、有効な意思決定プロセスがある」と思えるか。
  • 仕事の意味 - 「チームのためにしている仕事は、自分自身にとっても意義がある」と思えるか。
  • インパクト - 「チームの成果が組織の目標達成にどう貢献するかを理解している」か。

また、高パフォーマンスを発揮するチームに固有の5つの力学のうち「圧倒的に重要なのが心理的安全性である」とも記載されています。
私はこの記事を読んだことがきっかけで「チームの心理的安全性を高めたい!」と思うようになりました。

引用:Google re:Work「効果的なチームとは何か」を知る / チームに必要なものを見極める

測定方法

エイミー・エドモンソン氏いわく、以下の7項目に対してポジティブな回答が多ければ、チームは心理的安全性を高く感じていると判断できるとのことです。

  1. チームの中でミスをすると、たいてい非難される。
  2. チームのメンバーは、課題や難しい問題を指摘し合える。
  3. チームのメンバーは、自分と異なるということを理由に他者を拒絶することがある。
  4. チームに対してリスクのある行動をしても安全である。
  5. チームの他のメンバーに助けを求めることは難しい。
  6. チームメンバーは誰も、自分の仕事を意図的におとしめるような行動をしない。
  7. チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、活かされていると感じる。

引用:Google re:Work「効果的なチームとは何か」を知る / 心理的安全性を高める

私のチームの心理的安全性

エイミー・エドモンソン氏の測定方法を元に、下記の回答項目でアンケートを取りました。

  1. そう思う
  2. ややそう思う
  3. どちらとも言えない
  4. ややそう思わない
  5. そう思わない

最もポジティブな回答を4点、最もネガティブな回答を0点として、チームメンバー7人に回答してもらいました。

最高点は4点×7問×7人の196点で、アンケート結果では合計176点となり、約9割の点数でした!
この結果から心理的安全性はすでに高いと言えそうです。
しかし「なぜ高いのか」を理解する目的以外においても、さらに上を目指していくために心理的安全性への理解を深めるワークショップを行いました。

心理的安全性の理解を深めるワークショップ

まず、チームで心理的安全性について議論するためにシステム開発の現場でありがちな問題集を作成しました。
チームメンバーには作成した問題に対して、下記の観点で付箋に書き出して共有してもらい、メンバーが「求める心理的安全性とは何か」を議論しました。

  1. 仮に問題を指摘される側の場合、どのようなリアクションをするか?
  2. 指摘された場合、どう思うか?
  3. 仮に問題点を指摘する側の場合、どのように伝えるか?
  4. 指摘する場合、何を心がけるか?

ワークショップの狙い

このワークショップで心理的安全性についての理解を深め、チームメンバーの「情報の受信と発信の仕方」を自己開示することで心理的安全性を高めます。
有名なジョハリの窓でいうと、「開放の窓」が広くなるとチーム内の認識のズレが軽減され、コミュニケーションが円滑になり、ストレスも軽減されることを狙ったものです。

実際に議論した具体例

具体例:「レトロスペクティブで完了したタスクが少なかったことを改善したい」と話が上がり、原因について各自思うことを発言してもらった。

意見:Aさんのレビューが遅いせいでプログラムのマージができず、タスクが完了できなかった。(Bさん)

  1. 仮にAさんだったら、どうリアクション取りますか?
  2. 言われた時どう思いますか?
  3. 仮にBさんだったら、どのように伝えますか?
  4. 何を心がけて伝えますか?

4枚付箋を記載してください。

上記のような具体例をいくつか用意し、チームで議論しました。

チームで議論した感想

過去にチーム内で問題となったテーマを元に議論すると、問題の背景や置かれている状況をイメージしやすく、チームメンバーの情報の受発信にどのような傾向があるのかについてまとめやすく感じました。
逆に、過去の事例を元にしない問題 は背景や状況に対する捉え方が過去のメンバーの経験によって異なるため、同じ問題であっても情報を受信したときの印象が大きく異なりました。
その場合、議論する際には下記のような「どのような状況を想定していたか」について聞くと「なぜ印象が異なったのか」が明確になり議論が進みます。

  • 自分を助けてくれるメンバーがいる想定か?
  • 問題を指摘した人は誰を想定したか?

私のチームでは役職が高い人や自分と関わりが少ない人から言われるほど「嫌悪・恐怖・従順」になりやすく、関わりが多ければ「改善意識」が向上することをチームで認識できました。
情報の発信の仕方についての議論では、「個人を限定して伝えない」という意見が多く出ましたが、情報を受信する側で考えた場合、バイネームで指摘されることは悪くない というチーム内の共通認識も得られました。
バイネームで指摘をする場合、個人を否定しないように言い方に気をつけて「どうしてほしいか」を伝えれば、感情的になりにくいこともチームで確認できました。
また現状、進捗具合がうまくいっている状態であってもそれが崩れ始めると、上記の対応や心がけは変わる可能性がある ことも認識できました。

まとめ

議論するために用意する具体例は下記の2パターンがあります。

  • 過去の事例を元にするパターン
  • 過去の事例を元にしないパターン

過去の事例を元にするパターンの場合、背景や状況がイメージしやすくチームの価値観の傾向を知ることができる。
過去の事例を元にしないパターンの場合、メンバーの過去の経験によって認識に差異が生まれるので「安全だと思う状況」についての議論がしやすい。

今回のワークショップを通して、チームの価値観の傾向やメンバーが安全だと思う状況の確認ができました。
どこまで踏み込んで伝えて良いのかについては、時間をかけて探らなければ人間関係がギクシャクすると思います。
今回のワークショップで、どこまで踏み込んで伝えても良いのか分かったことや事前に「状況によっては気遣いをできないこと」をチームで認識できたことも心理的安全性を高めるのに役立つと思います。
今回は主に人間関係(チームメンバーの行動・発言)に対して、またどのように考えるかを議論しましたが、次回はチーム内の心理的安全性が向上している取り組みや仕組みについて議論しようと思います。

最後に

私の所属するプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。
それぞれの得意分野を活かしながら、みんなでフロントエンドからインフラまでフルスタックを目指しているチームです。
少しでもご興味のある方はぜひご応募ください!

dmm-corp.com