心理的安全性をもたらすために必要なもの

アジャイル界隈をはじめ、心理的安全性という言葉を、あちらこちらで聞くようになりました。
バズワード的な感じにではありますが、「心理的安全性をチームにもたらすために、どうすればよいか？」を考える機会が多くなってきたので、個人的な考えをまとめてみます。

心理的安全性が話題になったきっかけ

心理的安全性は、Googleが生産性を高めるために必要だと発表したことをきっかけに、一気に広まりました。
「グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ」が、2016年に公開され、話題になりました。この記事をご覧になった方も多いと思います。

アジャイルの世界では、2017年のAgile Japan 2017の基調講演であるモダンアジャイルをきっかけに、色々な方が考え始めたと思います。
※基調講演の資料は、こちら

http://www.agilejapan.org/2017/img/session/document/modernAgileJapan2017.pdf

そもそも心理的安全性とは

心理的安全性とは、どういうものかというと、答えるのは非常に難しいです。
心理的安全性とは、非常にエモいもので、言葉に表すことができないと考えているからです。
感情は、色々な言葉で表現することは可能ですが、自分が考えていることを、他の方に伝えるのは非常に困難だと思います。心理的安全性という言葉は、「喜んでいる」、「怒っている」、「寂しい」、「楽しい」といった言葉と同じようなものだと、私は考えています。

このようなことだけブログに書いてしまうと、「おいおい…」となって しまいそうですので、心理的安全性がもたらされたチームがどのようなチームであるかを考えてみます。

心理的安全性のあるチームの状態

心理的安全性のあるチームはGoogleのレポートの通り「他者への心遣いや同情、あるいは配慮や共感」ができている状態です。ここで重要なのは、単なる馴れ合いだけではなく、相手の間違っていることは間違っていると言うことができ、相手がよいことをした場合には褒めるといったことが、チームメンバー同士で伝えることができている状態です。

チームメンバー同士が「言える化」できている状態が、心理的安全性のあるチームだと言えます。

心理的安全性だけで解決するのか？

Googleが発表した良いチームには心理的安全性があることに注目ばかりしてしまいますが、もともとは生産性を高めるにはどうすればよいかがきっかけです。心理的安全性は、そのための方法にすぎないと思います。
もちろん心理的安全性は非常によい方法ですので、利用するべきです。生産性を高めるための方法として心理的安全性が重要であることは間違いありません。

しかし、心理的安全性はすべてを解決してくれわけではないと思います。既に記した通り、心理的安全性とは感情です。感情は非常に重要ですが、感情だけでは生産性は向上しません。
感情の対極にある、理論的な内容、ITの世界でいうと技術的な充実度合いが非常に大切だと考えています。

情と理のバランス

個人的な体験にはなりますが、現在勤務している会社の研修で心に残っている言葉があります。研修の中で社長が述べた「情と理のバランスが取れてこそ、物事をうまくいく」ということです。(※書いている通りかは自信がないですが、内容はあっていると思います。)

仕事を進める上で、理論的な内容だけを伝えてもうまくいかない。いくら理論的に正しくても、相手の心を揺さぶり、よいものだと伝わらなければ、製品を買ってくれない。
仕事を進める上で、感情的に進めるだけでは、うまくいかない。飲み会などでいくら仲良くなっても、製品自体のよさを理論的に正しくつたえなければ、製品を買ってくれない。

という内容でした。

物事をうまく進めるために必要なのは、感情だけでもなく、理論だけでもない。２つのバランスがあってこそ、うまくいくということです。
心理的安全性は、感情に該当するもので、いくら感情の面を強化しても、理論的な面もバランス良く強化しなければ、よいチーム、つまり生産性の高いチームにならないと思います。

IT業界における理

心理的安全性は、どのようなチームにも必要なものだと思いますが、ここでは私が働いているIT業界について考えてみます。

心理的安全性を感情的な側面をもったものとすると、IT業界において理論的なものといえば、プログラミング、設計、テストなど、いわゆる技術的なスキルだと思います。

真に心理的安全性のあるチームを作るには、技術的なスキルの向上が必須だと思います。あくまで一例にはなりますが、私が考える技術的な要素は以下の通りです。

プログラミング

• オブジェクト指向に基づいたコーディング(※JavaやC#といったオブジェクト指向言語を用いている場合)
• テストコードの実装

設計

• MVC
• MVVM
• DDD
• クリーンアーキテクチャ
• レイヤー化アーキテクチャ
• オニオンアーキテクチャ
• マイクロサービスアーキテクチャ
• ヘキサゴナルアーキテクチャ
• サーバーレスアーキテクチャ

テスト

• ブラックボックステスト
• ホワイトボックステスト
• APIのテスト自動化
• UIのテスト自動化

その他

• DB(RDB、NoSQLなど)
• クラウド
• Restful API
• Jenkinsなどの自動化ツール
• サーバーの運用

ここに書いたのはあくまで一例で、プロダクトやプロジェクトによっては、必要なもの、必要でないものがあると思います。
使っている技術要素に対して、チームがスキルを向上させているかが重要です。

理の向上で解決できる場合があることを心に留める

技術的なスキルで解決できることは数多くあります。品質が悪く納期に間に合わずチームの仲が悪くなることは、よく見かけます。開発チームとテストチームの関係性が良くないは、典型でしょう。
しかし、開発チームがテストコードを書き、GitでPUSHした後にJenkinsが自動でテストコードを実行していれば、おそらく品質が極端に悪くなることはないでしょう。そのまま、Infrastructure as Codeで、環境の構築、WebAPIの自動テストが行われていれば、多くの場合結合テストは完了しているはずです。
チームの仲を良くするためには、感情的な解決を考える前に、技術的なスキルをあげれば解決できることを忘れてはならないと思います。

もちろん一朝一夕に技術的なスキルは、あがりません。非常に時間がかかります。ただ、心理的安全性をもたらすための感情的な施策も非常に時間がかかると思います。

おわりに

心理的安全性を真にもたらすためには、情と理のバランスが大事で、技術的なスキルを高めることも視野に入れておく必要があるということでした。