スクラムマスダーの日記

AWSやアジャイルの学習の記録

DevLOVE関西2017 commitment 〜"何"にコミットするのか?〜で発表しましたよ!

2017/11/25に行われた、DevLOVE関西2017 commitment 〜"何"にコミットするのか?〜で、発表してきました!
発表の機会を作ってくださったDevLOVE関西のみなさま、誠にありががとうございます!

devlove-kansai.doorkeeper.jp

ボトムアップな組織改革-会社にアジャイルな風を吹かせる-

今回は、発表者全員が、コミットする対象を掲げて発表することになっていました。私は、コミットする対象を「組織改革」として、発表させていただきました。
資料は、コレ!

speakerdeck.com

立ち見の方も含め、30名近くの方に、発表を聞いていただくことができ、本当にありがとうございます。
聞いていただいた方々に、どれだけ有効活用できる内容をお伝えできたかはわかりませんが、僕の発表が何かのきっかけになれば、嬉しいです。

雑感

今回、発表のお声がけをいただいたときには、ホント気軽に受けました。「せっかくの機会だし、発表しよか〜」くらいの感覚です。
それが、公開されたページを見ると、なんとびっくり、僕以外の方は、凄い方々ばかりで、驚きました。
1st commitmentから市谷さんと長沢さんのセッションが並行で行われ、どちらに参加するか迷うレベルの凄さです。普通に考えて、両方聞きたい。

当日は朝から緊張しまくりでしたが、みさコーチに、「大丈夫ですよ〜」と声をかけていただいたので、ちょっと安心しました。

また、50分間も、人前でお話すること自体も、初めてでしたので、何をどれだけ話するかも迷いました。発表直前まで、話す内容を色々と変えてました。発表って難しいですね…。
発表時間は、ギリギリいい感じに収まったので、発表後は一安心でした。

発表するとなると、自分を振り返る機会になるので、良い感じです。今回はエモい話だったので、次発表する機会があれば、ガッツリ技術的な話がしたいですね〜。

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

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

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

心理的安全性は、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いただける感じが、まったくしません!!
現時点では、大規模開発のプロポーザルが少ないので、多少は、芽がありそう?

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