スクラムマスダーの日記

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

しがないラジオを聞き始めたきっかけと感想

この記事は しがないラジオAdventCalendar 18日目の記事です。

adventar.org

しがないラジオを聞き始めたきっかけ

学生時代から、ラジオを聞く習慣がありました。エンジニアになってから、同僚に、「Podcastで、Rebuild.fmっていう面白い番組があるよ~」と教えてもらい、Rebuild.fmを聞き始めました。

それから、いくつかテック系のPodcastを聞いたり、やめたりしつつ、Podcastをあさっていました。その中の1つが、しがないラジオです。

当初は、Podcastに溜まっているだけでしたが、Twitter湊川あいさんが出演されることを知り、「お、これは聞いてみるか!」というのが、きっかけでした。

しがないラジオのよさ

Rebuild.fmリスペクト

パーソナリティの@jumpei_ikegamiさん、@zuckey_17さんが、Rebuild.fmをリスペクトされており、Rebuild.fmをきっかけにテック系のPodcastを聞き始めた僕と同じ仲間という感覚が強いです。 お二人は、Rebuild.fmをきっかけに、しがないラジオを始めたというところも「仲間だ!」という感じです。
僕自身も、アジャイルラジオというテック系Podcastをやっているからですね。

agileradio.github.io

言語系の話が多い

テック系ラジオといっても、開発言語系、ガジェット系、プロセス系、組織系などなど内容は様々です。
しがないラジオは、そのなかでも、開発言語の話が多いことが素敵な感じです。
僕のような普段プロセスだったり、チームビルディングだったりと、コーディングをあまりしないエンジニアとしては、開発言語に関する知識を自発的に学ぶ必要があります。
PHPなどは、個人的には全く触っていませんが、それでも学びは多いですし、他の言語に置き換えることが出来る内容もあります。

一緒に成長するライバル感がある

パーソナリティのお二人は、おそらく、僕と同じか、少し下の年齢だと思います。僕が普段活動しているアジャイル系の領域では、僕が圧倒的に年下で、同年代の仲間が、なかなかいません。
Rebuild.fmに出演される方々は、日本どころか世界的にもトップクラスですので、崇める感じです。
しがないラジオだと、「今年初めてコミュニティで登壇しました!」といった話が出て来るなど、「この新鮮な感じ求めていた!」という感じになっています。
同年代で、これから頑張ろう!という感じなので、一緒に成長できるライバル感があります。

おわりに

僕は関西なので、パーソナリティのお二人とは、なかなかお会い出来そうにないですが、機会があれば、お話してみたいですね〜。

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の自動テストが行われていれば、多くの場合結合テストは完了しているはずです。
チームの仲を良くするためには、感情的な解決を考える前に、技術的なスキルをあげれば解決できることを忘れてはならないと思います。

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

おわりに

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