スクラムチームの「心理的安全性」を高める7つの方法

　先日、社内でアジャイル関連のイベントがありました。私は参加できなかったのですが、大変な盛り上がりをみせていたようです。私の所属する有志団体のSlackでも同様に盛り上がっていたのですが、その中で「心理的安全性って何だ？」という話題になっていました。スクラム開発をしたことがないメンバーにとっては聞き慣れない言葉だったようだったので、心理的安全性がいかに大事かを紹介しました。（後述しますが、スクラムだろうがなんだろうが、心理的安全性はどんな組織においても非常に重要だと思います。）

　その後、過去のスクラム案件で、心理的安全性を高める上で良かったことを整理するのは有意義かもなー、と思い記事にまとめることにしました。どれも私が主体的に施策として考えたもものではなく、自然発生的に始まったもの、お客さんのそもそも風土などが中心ですが、どんな組織でもすぐに取り組めるものばかりだと思います。

「心理的安全性」とは？

心理的安全性とは、自分の言動が他者に与える影響を強く意識することなく感じたままの想いを素直に伝えることのできる環境や雰囲気のこと （引用元：https://bizhint.jp/keyword/101187）

　ざっくり言うと、チーム内に「何でも言いやすい雰囲気があるか」といったところでしょうか。「居心地の良さ」にも繋がってくると思います。心理的安全性が高いチームは、生産性が高まる、チャレンジしやすい風土が生まれる、離職率の低下に繋がる、などと言われています。

　スクラム開発文脈でよくこの単語が出てきますが、よくあるウォーターフォール型の開発でも心理的安全性を高めることは重要だと思います。また、ITやプロダクト開発が関係のない組織でも、心理的安全性を高めるメリットは非常に大きいと感じています。

私について

　ざっくりこんな感じです。

• 新卒から数案件は、いわゆるウォーターフォール型の案件を担当
• その後、3年目にお客さんと一緒に２週間毎に小さいプロダクトをアジャイル的に開発するプロジェクトを経験
• 現在のお客さん先で初めてスクラム案件に参画。ここ数年で4つのスクラム案件に携わりました
• その過程で認定スクラムマスター資格を取得させていただき、社内の勉強会でスクラムの話をするなどしています

　では、心理的安全性を上げる上で、私が良いと思った７つの方法を紹介していこうと思います。

１）立場が上の人がデイリースクラムで笑いに繋がる話題を提供する

　デイリースクラム（いわゆる朝会）では、昨日やったこと・今日やること・困っていることを簡単に紹介します。私のいたチームでは、社員エンジニアの方（チーム内で立場が上の人）が、「困っていること」として「華金なのに飲み会がない」「花見をしたいけど誰も誘ってくれない」などといった、プロダクト開発に関係のない自虐ネタを定期的に投入していました。

　ご本人が狙っていたのかは分かりませんが、開発が佳境なときなど、チームの雰囲気が重くなりがちなタイミングでこのようなネタを投下してくれていたと思います。朝からひと笑いあると、自ずとチームの空気が良くなり、その後１日中相談しやすい雰囲気につながっていたと思います。このネタに救われたことが何度もあったので、おすすめできる方法だと思います。下の立場の人がいきなりこれをやるのは難しいので、上の立場の人に恥をしのんで頑張ってもらいたいです。チームの心理的安全性を上げるためなら安いもんです！

　（ちなみに、「スクラムチームはフラットなチームなので、上下関係なんてないんだ」というのが教科書的だと思います。しかし、先輩・後輩、上司と部下などが入り混じったチームになることはよくあり、完全にフラットなことの方が珍しいと思います。前述の通り、立場が上の方がチームの雰囲気を盛り上げやすいと私は思います。「暴飲暴食で体重が増えた」という自虐お困りごとから「子供が喋るようになってきて可愛くて家をでるのが辛い」という自慢話までなんでも良いです。明るい雰囲気を作ってみてください！まずはここからです。）

２）POがエンジニアチームに雑談しに行く

　スクラムチームの中で、PO vs. エンジニアというような構図になるシーンがどうしても出てきます。立場が違うので致し方ない面もあります。しかし、POとエンジニアの距離が近ければ近いほど、チームとしての心理的安全性は高まると思います。プロダクトの戦略にコミットするPOと、ITのスペシャリストであるエンジニアの間でうまくシナジーを出せるかどうかが、スクラム開発の成否に繋がります。

　過去のプロジェクトを振り返ってみると、良いPOは雑談をよくする人だったなーと思います。「完全に集中力が切れたので、コンビニ付き合ってくださいよー。コーヒー飲みに行きましょうよー。」みたいなお誘いもしばしばありました。雑談すると自ずとPOが今何を考えていて、何に困っているかが分かるようになりますし、その結果、エンジニアサイドが困っていることも伝えやすくなります。「お互いに悩み・弱みを共有する」雰囲気が生まれやすくなると思います。

　このような雰囲気によって、PO、エンジニアそれぞれの情報格差が埋まるとONE TEAM感が出てくると感じています。チーム全員が同じ方向を向いて走ることは、間違いなくプロジェクトの生産性向上、アウトプットの質の向上に繋がります。

３）定期的に表彰する制度を作る

　これはお客さんの文化なのですが、まさに「褒めるときは全員の前で」を体現した施策だと思います。人間誰しもが承認欲求があると思います。「自分はこの組織に必要とされている」と感じられると、自ずと心理的安全性は高まっていきます。

　自分が偉くなったら、自分の組織で最初にやりたいことは半年に１回の表彰制度を作ることです。MVP賞と成長賞の２つを作りたいなと思います。ポケットマネーからちょっとした賞金やら商品やらを出したいです。まぁ、自分が偉くなることはないと思うので、実現することはないと思いますが。というわけで、見込みのある人よろしくお願いします。マネージャーさん、部長さん、半期に１回飲み会に行かずに、そのお金を表彰に回すだけでいいんです:) 一種の「働き方改革」だと思います。ぜひお願いします！

４）Slackで分報（#times_ チャンネル）を導入

　分報については、こちらをごらんください。　

Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう | | Craftsman Software Inc.

お客さんSlackや会社チャットで分報スレを作ってます。分報のメリットはとてもたくさんあると思っていて、代表的なものを挙げると、

• 自分の作業メモになる
• 他のメンバーへの情報共有になる
• 自分から質問しなくても困っていることを書くと有識者が助けてくれる

といったところでしょうか。

　特に、最後のメリットが心理的安全性を高める上で重要だと考えています。誰かに質問する形式だと「質問する相手の邪魔をしてしまったらどうしよう」「そもそもこれって誰に聞くべきなんだっけ？」という悩みが出てきてしまいます。しかし、分報形式であれば「その瞬間手の空いている」「回答を持っているメンバーが」ヒントをくれるので、無駄に悩む時間が削減されます。

　また、分報を教育に使うこともできるのではないかと思います。例えば、シニアエンジニアの方が何かしらの設計をする際に、自分の中で答えがあったとしても「方式Aと方式Bどちらにするか、、」的なことを分報であえてつぶやきます。そこに、トレーニー（インストラクティー）メンバーや他のチームメンバーが意見を言ってくれた時に、分報上で侃々諤々な議論をすることで、チームメンバーの知識の底上げに繋げます。ここでも大事なのは、「良い議論ができたおかげで、考えがまとまった」「良い設計に繋がった」というような前向きなスタンス・コメントです。立場が下の（と思っているであろう）メンバーが、議論に参加しやすい雰囲気を出すのが非常に重要です。

５）Slackで絵文字リアクションしまくる

　これは完全に持論なのですが、絵文字リアクションが多いチームは心理的安全性が高い気がしています。ちょっとした気遣いに対する「ありがとう」、ちょっとした情報共有に対する「グッジョブ！」、小さいリアクションの積み重ねが「どんどん発信していこう！」という前向きな雰囲気を作り上げると感じています。

　私の場合は、昨年子供が生まれた時に早く帰らせていただくことが多かったのですが、私の「お先に失礼します」ポストに対して、「イイね」マークやら「赤ちゃん」マークやらをチームメンバーが大量に付けてくれたのが、本当にありがたかったです。その恩を返したいなーという想いが、私の生産性を上げたことは間違いありません。きっと。おそらく。 　

６）コードレビューで「良いコード」についても言及する

　コードレビューは、どうしても指摘が中心になってしまい、否定的なコメントが増えてしまいます。もちろんそれがコードレビューの基本なので仕方ない面もあります。

　私が以前いたチームでは、他のメンバーの方が「こういう書き方できるんですねー」「このコード参考にさせていただきます！」といった、コード（や設計）を褒めるコメントを積極的に書かれていました。心理的安全性を高めるためにそうされていたのかは分かりませんが、こういうコメントがあるとレビューの雰囲気が非常に良くなっていたと思います。このような雰囲気が、「ちょっとでも迷ったら積極的にレビューしてもらおう」という空気に繋がり、生産性やプロダクトの質の高まりに寄与すると考えています。

７）ひとつで良いのでチーム内で一番詳しい知識・スキルを作る

　最後は自分の努力が必要な方法になりますが、チームの中で「これだけは自分が一番詳しい！得意だ！」という領域を作ることで、自分の存在価値を高める方法です。その領域について、周りのメンバーをフォローしたり、チームメンバーから頼りにされることで、それ以外の（自分が得意ではない）領域について質問しやすくなると思います。やはり、聞いてばかり、フォローされてばかりだと、申し訳なさから（個人の）心理的安全性が低くなってしまいがちです。そうではなく、ギブアンドテイクな関係を築くためにも、ギブできる領域を増やすことが大事だと思います。

　私も、優秀なアプリエンジニアの方が多い案件に入る時に、そのフレームワークに精通してなかったり、既存のシステムのキャッチアップが追いついていないときは申し訳ないなーと思うのですが、インフラ周りのテーマを積極的に巻き取ることで、承認欲求を満たしつつ（笑）、アプリのテーマに必死に食らいつくという作戦をよく取ります。

　現時点で詳しい領域がない場合は、チームメンバー得意不得意や直近1, 2ヶ月に発生しそうな案件を見渡し、新しい武器を作りにいくのもいいと思います。ただし、雑用系タスクをひたすらやります！だと、そのチームでしか役に立たない知識しかつかない（ことが多い）ので、エンジニアとして血肉になりそうな領域を攻めるようにしましょう。

まとめとスクラム関連の参考書籍

　いかがでしたでしょうか。これらの7つの方法が、全てのチームに必ずしも合うとは思っていません。ですが、すぐにできる＆ほぼコストゼロで始められる施策ばかりですので、まずは始めてみていただきたいです。また、やめるのも簡単なものばかりです。やってみて合わなければやめればいいんです。チームに合えば儲けものです。心理的安全性を高めて良いチームを作っていきましょう！リーダーがやる、スクラムマスターがやる、ではなく全員でやるものです！

　最後に、私が過去に読んだスクラム関連の中から、おすすめの本を紹介して終わりたいと思います。（全て手元にあるので、私の知人の方で読みたい方いらっしゃいましたらお声がけくださいませ。お貸しいたします。）

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

まずはこれです。「明日からスクラム案件に参画する人」から「スクラム開発の基本を抑えたい人」まで、まず最初に手に取るべき本だと思います。マンガ形式になっているので、サクサク読めると思います。おそらく2時間もあれば、スクラム開発の抑えるべきポイントを学ぶことができると思います。

スクラム実践入門

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

BOOT CAMP の次に読んだ本です。スクラム開発で起こる問題点とそれに対する打ち手がボリューミーに紹介されている良書です。まずは、BOOT CAMPを読んでスクラム開発に挑戦し、壁にぶつかるたびにこの本でヒントを探すのがいいのではないでしょうか。

アジャイルサムライ

アジャイルサムライ――達人開発者への道

有名な本です。スクラムの本ではありませんが、役に立つ内容になっています。新人の頃に紹介していただいた本だったと思います。内容薄れてきているので、もう一度読み直したいと思います。

つづき

　その後、「心理的安全性」について社内発表したときの記事です。

www.ketancho.net