スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

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

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

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

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

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

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

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

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

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

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

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

f:id:scrummasudar:20171103224545j:plain

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

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

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

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

情と理のバランス

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

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

という内容でした。

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

f:id:scrummasudar:20171103231609j:plain

IT業界における理

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

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

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

プログラミング

設計

テスト

その他

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

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

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

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

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

おわりに

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

RSGT2018のプロポーザル提出しました〜

タイトルどおりですが、RSGT2018のプロポーザル提出しました。

Regional Scrum Gathering Tokyo 2018 - 大規模で技術的に多様な開発に真正面から取り組む | ConfEngine - Conference Management Platform

タイトルは『大規模で技術的に多様な開発に真正面から取り組む』です。

アジャイルに関わらずですが、新しく何かを始める時には、小さく始めることが基本だと思います。
僕も、その通りだと思っていますし、出来る限り、小さく始めれるように頑張っているつもりです。

しかし、世の中、そういう状況だけではないと思います。
最初から大人数での開発プロジェクトが動き出すこともあるのです。
少なからず、私は経験しました。

数は多くはないと思いますが、大規模開発で困っていらっしゃる方も、いらっしゃると考えています。

大規模開発は、大規模開発ならではの問題が発生すると思います。
例えば、開発チームが複数あるからこそ、チーム間のやりとりが重要になることです。
開発チームが1つしかない状況では発生しない状況です。

また、どのようにチーム分けをするべきかも、重要です。チーム編成は容易に変更することが出来ず、最初のチーム分けが、特に重要です。ただ、最初に決めたとおりに進めるだけでは改善が生まれません。

などなどと、多少なりとも、私の経験からお伝えできることもあると思います。

今回は、エモい内容より、テクニカル面重視で、お話できればと思っています。
エモい話を否定しているわけではありません。むしろ、エモい話好きです。11月にお話させて頂く『DevLOVE関西2017 commitment 〜"何"にコミットするのか?〜』では、ガッツリエモい話をしようと思っています。

devlove-kansai.doorkeeper.jp

今まで、ぼくが、アジャイルについて話すときには、どうしてもエモい話が多かったように感じています。だからこそ、テクニカル的な面重視で、話したいと思っています。

色々書きましたが、プロポーザル提出されていらっしゃるみなさんの話、聞きたいモノ多すぎです!
ぼくのプロポーザル、OKいただける感じが、まったくしません!!
現時点では、大規模開発のプロポーザルが少ないので、多少は、芽がありそう?

もし、「話聞いてみたいなぁ」と共感いただいた方は、投票いただけると、嬉しいです!

第3回「エラスティックリーダーシップ」読書会を開催します!

昨年2016年に登壇させていただいたScala関西Summitですが、今年の開催は、いよいよ3日後の2017/9/9ですね。

summit.scala-kansai.org

今年は、普通に参加者として、楽しみます。
あと、どこかのブースでモブプロやっていると思います!

第3回「エラスティックリーダーシップ」読書会

第3回「エラスティックリーダーシップ」読書会を開催します。
タイトル通り、エラスティックリーダーシップをみんなで、読み進める会です。

shin-osaka-agile.connpass.com

第1回は、訳者の島田さんにもご参加いただき、大盛況でした。 3回目も、それに負けじと、頑張りたいと思います。

書籍の範囲

第3回の予定範囲は、以下のとおりです。

  • 8章 自己組織化を促進させるためにクリアリングミーティングを行う
  • 9章 影響パターン
  • 10章 管理職のためのマニフェスト
  • 11章 フィードバック
  • 12章 衝突を学習へと導く
  • 13章 おそらく技術的な問題ではない

読書会の進め方

読書会は、ジグソー法という手法を採用しています。

読書会中に、黙読時間を設けて、読んだ範囲についてセッションをします。
セッションが終わった後は、読んでいない方に読んだ範囲をお伝えして、セッションします。 これらを繰り返しています。

今回は、3チームは、作りたいので、参加者として、9名の方には来ていただきたいと思っています。 ※2017/09/06時点で、参加者が7名なので、あと2名!

おわりに

事前に本を読まなくてもOKな読書会ですので、迷われていらっしゃる方は、ご参加いただけるとうれしいです。

2017/8/24発売のWEB+DB PRESS Vol.100で、まつもとゆきひろさんがエラスティックリーダーシップを紹介されていたので、新しく興味を持っていただいた方も、是非ご参加ください。