スクラムマスダーの日記

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

「「心理的安全性」のことに思いを馳せてみる」に参加した!

DevLOVE関西さん主催の「「心理的安全性」のことに思いを馳せてみる」に参加させていただきました!

devlove-kansai.doorkeeper.jp

心理的安全性は、Agile Japan 2017でも話題になっていたので、気になっていたワードであったことは、もちろんですが、及部さんのお話を聞いてみたいという思いが強く、「参加しないと!」って感じでした。

個人的な感想を、つらつらと書いていきます。

心理的安全性について本気出して考えてみたら普段やってるチーミングの話だった

及部さんのセッション

speakerdeck.com

資料のタイトルが、DevLOVE関西さんのWebページ掲載タイトルとは異なるという、いきなり中村さんの心理的安全性を崩していくスタイル!
このような、発表におけるつかみが、大事なのかもしれません!

心理的安全性について、及部さんが色々と考えられたらチーミングにたどり着いたのは、なるほどな~って感じです。
もちろん、言われれば、そのとおりなのですが、心理的安全性という概念を、いかに現場感に落とし込めるかが、真のプロフェッショナルなんかなーと。

「チームのゴール」と「個人のゴール」

チームのゴールは、各現場で色々とあると思います!で、それがチームの中で共有できている状態ですよね~と。
※この段階で、あやしいチームいっぱいある気がしますが…

個人のゴールも、色々とありますよね!働く目的は色々なのは、間違いないです。
独身ならば、単純にスキルを磨くだけで、いいかもしれませんが、家庭を持つと養っていかなければならないですよねーと。
ゴール自体に、良い悪いは、ないと思います。

及部さんの問いかけとしては、「チームのゴール」と「個人のゴール」って、同じになってますか?、ということだったと思います。
チームも個人も、同じ問題を見つめて取り組む形にするために、

  • 1on1
  • ふりかえり

などなど実施すると、良い感じになるんじゃないかなーって。

「言える化」と「失敗の定義」

言える化! 難しいですね…。日々悩んでます。新入社員を含めプロジェクトに新しい方が参画されるたびに、悩んでいる気がします。
ほんと、スクラムはじめて、悩んでばっかりです。

チームで仕事をしている中で、困ったこと、改善したいこと、より良くしたいことなどなどは、日々共有していく必要がありますよね。
ただ、自分のスキルのなさを露呈したり、現状について否定的なことを言うことは、良くない、つまり失敗につながっていると、直感的に思います。

ただ、チームにおける真の失敗とは、なんだ?ということを共通認識することで、今発生している課題は、失敗ではないことをチームメンバーそれぞれが持つことができるようになると思います。
おそらく、真に回避すべき失敗があるのだから、今起きていることは失敗ではないので、チームでどんどん解決すればよいという考えに至るのが、心理的安全性につながるのかなーと。
事象が失敗ではなく、学びのきっかけになるのが理想なのだと感じています。

本質が先

真にワークするチームは、集められたチームではなく、集まったチームになる。そのためには、チーミングが必要で、さらに心理的安全性が自然と必要になる。
まさに、そのとおりですね。本質とは、なんぞやということです。

一つのチーミングの方法として、モブプログラミングがあるのかと思います。

良いチームにするために、

  • 場を作る
  • 不安を取り除く

人が必要で、スクラムのコンテキストであれば、スクラムマスターになりますね。

良いチームは、戦友であるというのもそのとおりで、互いに刺激し合える関係でなければならないと思います。
アジャイルでは、技術的卓越性が求められているので、単なる仲良しこよしでは、ダメなのです。

○○さんだからできる!

及部さんが、「そう言っても○○さんだからできるんでしょ」は、「そうだよ!だって、そのために取り組んでるから!」とおっしゃってたのが印象的でした。
誰にでもできるものではなく、努力しているからできるのです。

もっと、自信持って、取り組む必要あるな!って思いました。ぼくは、まだまだ未熟ですが!

心理的安全性があるとき〜ないとき〜 チームマネジメント・ファシリテートの経験談

金 陽信さんのセッション

資料が公開されていないので、ざっくり覚えている限りの内容です。

発表内容は、本当に、泥臭くて、コレが現場だな!って感じです。
良い感じの成功事例も、もちろん目指すべき状態として必要なのですが、もちろん現場は山あり谷ありなので、失敗事例も大切です。
こういうことをやったらまずいよな~ということを知っておくだけでも、少し変わると思います。

担当者を飛び越える、「私バカだから…」と発言される方がいらしゃるなど、「そんなことあるかーい!」って感じですけど、実際、様々な現場で起きているのが事実かなーと。

心理的安全性って、構築するのには色々なことが必要ですが、壊すのは一瞬というのは、真実だと思います。
心理的安全性は、人間同士のつながりの話しですからね。基本は、人間関係をベースに考えればよいのかなーと。

おわりに

今回は、参加してホントよかったなーって感じです。お二人の発表は、参考になることばかりでした。
ぼくのチームも「負けてないぞ!」って思いつつ、「そう、負けてないって感じだよなー」っという…。
スクラムマスターの仕事は、チームを世界最高のチームにすることなんで、まだまだ、やることいっぱいあるなーって感じでした!

おまけ

エムオーテックスは西の聖地らしい!

「エラスティックリーダーシップ」読書会はじまります!

タイトル通りですが、新・大阪アジャイル勉強会で、「エラスティックリーダーシップ」読書会をはじめます! shin-osaka-agile.connpass.com connpassで、参加者募集中です!

「エラスティックリーダーシップ」読書会とは

文字通り、読書会参加者で、『エラスティックリーダーシップ ―自己組織化チームの育て方』を読み進める会です。
書籍の内容について理解を深めることはもちろんですが、書籍をきっかけに、参加いただいた方々が、自身の仕事現場をふりかえり、改善につながればと考えています。
各回の読書会の範囲で、現場で困っていること、気になっていること、改善したいことについて、参加いただいた方同士で、話し合い、現場に持ち帰っていだき、最終的に改善につながることを理想としています。

読書会の進め方

読書会は、「アジャイルな見積りと計画づくり」読書会と同じくジグソー法を用いて進めます。

  1. グループにごとに読む範囲を決める。
  2. 決めた範囲を黙読する。
  3. グループごとに読んだ範囲についてディスカッションする。
  4. グループを変更する。
  5. 読んだ範囲を読んでない参加者に伝える。
  6. その範囲についてディスカッションする。
  7. 5と6を繰り返す。

という流れです。
読んだ内容を読んでいない相手に伝える必要があるため、より深く書籍を読み、自分の言葉に言い換えることで理解が深まる手法になっています。

第1回目について

  • はじめに
  • 1章 チームリーダーマニフェストに向かって努力する
  • 2章 リーダーシップスタイルをチームのフェーズに合わせる
  • 3章 バス因子に対処する
  • 4章 サバイバルモードに対処する

が対象範囲となっています。

おわりに

黙読時間を設けていますので、書籍を読む時間がない、1人で書籍を読むことが苦手なので事前に読むことが苦手な方も、ご参加いただけます。『エラスティックリーダーシップ』を買って、そのまま読書会に、ご参加いただけます。
もちろん、事前に読んでから読書会に参加した方が、理解は深まると思います。

それでは、みなさまのご参加をお待ちしております!!

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

「アジャイルな見積りと計画づくり」読書会が最終回を迎えました!~ゆとりって何だろう?~

2017/06/27に、第7回「アジャイルな見積りと計画づくり」読書会(最終回)を開催しました。

shin-osaka-agile.connpass.com

アジャイルラジオをきっかけに始めた読書会でしたが、無事、分厚い一冊を読み終わることができました。

f:id:scrummasudar:20170629104354j:plain ※いつもお手伝いしてくれる後輩のお手製ボード!!

第7回の内容

読書会の範囲は、

でした。

ぼくは、22章を読むチームでしたので、メモはこんな感じ。

f:id:scrummasudar:20170629104941j:plain

以下、読書会で個人的に思ったことをつらつらと書きます。

ゆとりって何だろう?

ゆとり大事ですね。
今回の読書会の範囲にも、「ゆとりを残す。」(P.264 22章)が、12のガイドラインに書かれていました。

最近、スクラムマスターの師匠と色々と話しをしていることで、「ゆとり」というのは、「なんの目的もなく過ごすことが出来る時間」のことかな?と思うようになってきました。
読書会の中でも、「チームに、ゆとりの時間を確保していますか?」と質問したところ、「改善の時間として、○○%確保してますよ」という返事がありました。
たしかに、改善の時間も重要なんですが、個人的には「ゆとり」ではな気がしています。「改善する」という目的に使う必要があるので、実際何かしらの作業をする必要があるという風に考えています。

なので、チームのとっての真のゆとりは、改善の結果生み出された隙間時間だと思うように、最近はなっています。
真のゆとりの時間は、開発チームが勝ち取る感じなのかなーと。

もちろん、自動化などの改善の方法を知らないチームもあるでしょうし、POから「改善??プロダクトバックログを消化してよ!」と命じられているチームもあるので、よりよいプロダクトを開発していく上で、スクラムマスターなどが改善の時間を確保する必要があることも事実かとは思います。

ただ、それは、ゆとりとは、違うんじゃないかな〜と思ってます。

ほかの話を聞くと、「何も目的がない時間とか過ごせない…。だから改善の時間に当てた。」ということもあったので、ゆとりの時間への心理的安全性も大事ですね。
チームメンバーが何を持って心理的安全性としているかは、様々なので、「目的がない時間を過ごす」ということに対して心理的安全性をそもそも感じてもらえないと、そのチームにとってのゆとりは、ゆとりではないのかもしれません。

さてー、何を言ってるのか、自分でもわからなくなってきたので、ゆとりの話はやめようと思います。
アジリティー高いので、次は、また違うこと言ってるかもしれません。 なんたって、ぼくは、アジャイルゆとり世代ですからね!

おわりに

いままで、「アジャイルな見積りと計画づくり」読書会にご参加いただいたみなさま、ありがとうございました。
読書会やるよーって言って、会社の先輩・後輩がお手伝いいただいたのも、感謝です。そもそも、社外勉強会に会社を使っても良いとしている会社自体にも感謝ですね。

せっかく続けてきた勉強会なので、違う書籍で読書会を実施しようと思います。
これからもご参加いただけると嬉しく思います。