「ふりかえりの問題分析をみんなでやってみよう」に参加してきた

retrospective.connpass.com

今日は「ふりかえりの問題分析をみんなでやってみよう」に参加してきたので、会の様子を感想を書いていこうと思います。

会の概要

『ふりかえりカンファレンス』で講演いただいた 安達賢二さんと一緒に、ふりかえりでよく起こりがちな問題を一緒に分析して、モデル化するワークを行っていきました。

ふりかえりカンファレンスで「ふりかえりをふりかえった結果」として出た、「うまくいったこと」「うまくいっていないこと」をモデリングし、問題分析をしていきました。

会の内容

以下、時系列で会の様子を書いていきました。

今日やることを共有

安達さんから、今日の会の流れを共有してもらいました。説明時に使用したスライドは以下に添付します。

ライフサイクルのSTART～ENDでやんわり配置

前さばきとして、ふりかえりで出た要素*1を整理していきました。
ワークしている皆さんが、ふりかえりの時系列順に要素を並び替えて、要素に対してあれこれ並び替えている様子が伺えました。

出てきた要素で解像度が低めなものについて、チームメンバーで深い理解をするのがポイントだということです。
ワークで、自分がこうかなあと解釈したものについて皆さんが要素の意味を慎重に確認しているのを見ていて、ふりかえりで出てきた要素を整理する行為は、自分が十分やっているつもりでも、結構足りていないことも多いのかなと思いました。

要因と結果の関係があれば➡で結ぶ

整理した要素について、要因と結果を矢印で結んでいきました。
ワークでは、適度に時間を区切りながら、安達さんが少しずつコツを説明してくれました。
この作業は中々難しそうで、実際にワークをしていた方からも「要因と結果の矢印の距離が離れたり近くなったりしていて難しい」といった感想が挙がっていました。
今回は要素数を20個にしてやっていたのですが、要素数が過剰になると分析が難しくなってしまう(矢印が多くなってしまい構造化するのが難しい)ということで、要素をカテゴライズ(スライドで言うと、STEP3のゾーンなどを利用の部分)したりしても良いとのことです。
また、結果を説明するのに抜けている要因があったり、*2要因を見ていて思いついた結果があれば、*3要因や結果を適宜追加しても良いという話がありました。

構造化した後は、全ての要因を潰していくのではなく、ROIが高い個所にリソースを集中させて問題解決すると良いということでした。

最もインパクトがあった事項を1件出してふりかえり

ワークをした皆さんで、ワークのふりかえりをしていきました。

• 新しい前提を作り出すのが凄い経験の差として現れた
• チームメイトの観点が勉強になった
• 確度が曖昧でもとりあえず引いてみることが大事だと感じた
• グルーピングすると情報整理されて分かりやすい
• 同じ文言を見ても、想像する過程が違う
• 関連を一度引いてしまえば、考え直すのが楽だった
• 話ながら因果関係を整理するのが面白かった

などがふりかえりとして挙がっていました。

問題分析の本当の価値

ワークをやってみたりスライドを見ると、どうしても図に目が生きがちですが、本当の価値は、チームで問題分析する際に生まれる相互対話や試行錯誤だという話がありました。
これには100%共感で、チームで相互対話や試行錯誤ができるような、楽しいふりかえり手法でふりかえりできると、素敵なチームに近づいていくんだろうな、と思いました。

全体を通した感想

良く作り込まれた手法だなあというのが素直な感想でした。
手法やルールはシンプルであるものの、問題が少しずつ構造化されていって、最終的にはチーム(ワーク参加者)が納得のいくパスが出来上がっていく様子を見るのは、圧巻でした。
安達さんの説明は分かりやすく、落ち着いたトーンで常に話してくれていたこともあり、聴いていて心地よかったです。

*1:今回はふりかえりのふりかえりがテーマだったので、例えば「ふりかえり中にリモート中のメンバーが内職しているように見える」「ネクストアクションが多すぎて飽和」...が挙がっていきました

*2:例えば、「強風が吹く」という要因と「砂や埃が舞う」という結果がある時、「舗装もなく土や砂利の道が多い」という要因が抜けている...

*3:例えば「ネズミが増える」という要因と「ネズミが桶をかじる」という結果がある時、「ネズミが増える」という要因から「疫病が流行する」という結果が仮説として出せる

アジャイル開発とスクラム～第二版～を読んだ

最近は「ユニコーン企業のひみつ」の盛り上がりが凄いですが、「アジャイル開発とスクラム～第二版～」を読み終えたので、今日はこちらの感想を書いていこうと思います。

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

本の概要

アジャイル、スクラムの第一人者が企業のリーダー層に送る必読書、8年ぶりに大改訂!

ソフトウェア開発手法「アジャイル」と、その手法の1つである「スクラム」の体系的な解説書が初版刊行から8年の時を経て、装い新たに新登場です。

第2版となる本書では、ビジネスで広く存在感を示すようになったアジャイルの新しい知見を盛り込み、内容をアップデート。

アジャイルとスクラムの全体像や、野中郁次郎の知識創造プロセスとの関係など、初版での核心部分はそのままに、アジャイルを組織内で大規模化するためのスケールフレームワークなど、新たな観点から、解説を追加しています。

また、国内有名企業による実践をまとめた、事例記事&インタビューも一新。KDDI、ANA、IMAGICA.Lab、NTTの最新事例を収録し、国内企業ならではの取り組みを紹介しています。

日本におけるアジャイル開発の第一人者、平鍋健児氏、アジャイル開発実践者の筆頭である、及部敬雄氏、そして世界的な経営学者でありスクラムの提唱者、野中郁次郎氏
これら国内を代表する著者陣による提言は、ITエンジニアはもちろん、あらゆる業界・企業のリーダー層に受け取ってほしい内容です。

印象的だった箇所

アジャイル開発とスクラムを実践した企業の実例

NTTコムウェアやANA、永和システムマネジメント、IMAGICA Lab、KDDIと、多種多様な企業がアジャイル開発やスクラムを実践した実例を紹介してくれていました。
どの企業も、様々な苦労を抱えたり障害にぶつかりながら、顧客が喜ぶプロダクトを作ったり組織を改善していったりしていて、刺激をもらうことができました。
また、各々の企業のコンテキストに合わせて、スクラムやアジャイルの理念を踏襲しながら具体的のどのような施策を打っていったのかが分かったのも印象的でした。

スケールフレームワーク

大規模スクラムは賛否両論で色々と言われていますが、「既にスクラムを導入してうまくいったチームが2つ以上ある」「大規模化する必要がある」という前提付きで、アジャイルのスケールフレームワークが解説されていました。
自分は今すぐにスケールフレームワークが必要な状況ではないのですが、各フレームワークの特徴と生まれるまでの簡単な過程が記載されていて、他の文献と比較してこれだけ分かりやすい解説で端的に各種フレームワークが書かれている本はないのかな、と個人的には思いました。

本から感じる熱量

特に本の終盤にかけて、アジャイル開発の知見を参考にしながら、組織あるいは社会にイノベーションを起こしていけるんだという熱を個人的には感じることができました。
野中先生が力強い言葉で日本企業の可能性について言及している部分などは、読んでいてぐっときましたし、おわりにの章に記載されているやり取りについては、やり取りをしている場面が脳裏にイメージできました。

全体を通した感想

本書の著者である野中先生、平鍋さん、及部さん全員のお話をリアルタイムで聴いたことがあったということもあり、本を読んでいく中で頭の中にお三方の顔や声が浮かんできて、楽しく読むことができました。
また、周りの評判等で本を選定するのもいいですが、多少の接点がある方の本を読むことで、内容も他の本より頭に残りやすい気がしました。(内容が頭の中に残りやすかったのは、もちろん本の内容が分かりやすかったということもあります)

アジャイルやスクラムを勉強していたり実践している人や野中先生の本を読んでいる人だと、新しい知識という意味ではそこまでないかもしれませんが、知識が整理された&企業で実際にアジャイルが導入されて起きた変化の事例が知れたのは良かったです。
内容は全体を通して本当に綺麗にまとまっていて読みやすく、基礎知識の整理&各企業で実際にアジャイルが起こした変化&スクラムの原点である野中先生の知見と、盛りだくさんの内容が凝縮されている最高の一冊でした。

Scrum Developers Night! Online 〜4th〜に参加してきた

smn.connpass.com

今日はScrum Developers Night! Online～4th～に参加してきたので、会で話した内容を書いていこうと思います。

会の概要

以下、Connpassのイベントページから引用です。

Scrum Developers Night!（スクラムデベロッパーズナイト） は、オープンスペーステクノロジー（※）で運営される、Scrumに取り組んでいる（取り組もうとしてる）Developer向けのイベントです！

参加者同士のディスカッションを通じて、スクラムを実践する上で「技術的プラクティス」や「変化に強い設計」をどのように考えるか等、現場でぶつかった課題や疑問に対して解決のヒントを得ることを目的としています。

会で議論したテーマ

皆でTDDしてみよう

cyber-dojoを使って参加者でTDDをしていきました！

最初にそれぞれが黙々とTDDをして、書いたコードについて解説をしていくというスタイルで進めたのですが、シンプルな課題でも、皆さんそれぞれの作り方が違っていて面白かったです。
会社外の人とTDDするのは初めてだったので、新鮮味があって是非次回もやってみたいと思いました！(今度はモブプロとかだと面白いかも、と思いました)
エディタが使えないときつかったのと、普段使っている言語と違うのが若干ハードルになっていた感はありましたが、自分も含めて皆さん楽しめたということで、良かったです。

TDDでRed/Green/Refactoringのサイクルを回す時に、Redに時間制限をおいていますか？

皆でTDDをした流れで、TDDに関連する話題で盛り上がりました。

Redに留まる時間が長くなり過ぎないように、何かしらの工夫*1をしているかという話をしていったのですが、モブプロでドライバー交代する時、Redに留まりすぎである旨をフィードバックしているという話があり、やっぱりモブプロとTDDの相性は良さそうだなあ、と感じていました。
また、エンジニアの美徳である短気を持ち合わせている人だと、時間を測らなくてもRedに留まる時間が長いことに自分で気が付きやすいと話してくれた人もいて、Redに留まりがちなエンジニアに対してのアドバイスの一観点として持っておきたいなーと感じました。

モブプロで熱くなりすぎないための工夫

自分も問題意識を感じていましたし、今日はちょうどTwitterでモブプロで傷ついたという話を聴いたので、テーマに挙げてみました。
様々な工夫が出ましたが、モブにいるメンバーの中で必要最低限のアグリーメントを取るというのが現実的な工夫だなあと思っていました。(指摘が出やすい、変数名やコーディング規約について必要最低限のガイドラインを定めたりする等...)
また、モブプロをする前にモブプロのトーンを決めるという話も聴けて、その場にいる人が気持ちよくコーディングするための仕組みづくりをもっと考えてみたいと思いました。

全体を通した感想

TDDやモブプロ、テスト自動化の話など、普段参加しているアジャイル関係のイベントよりも技術に寄った話をOSTできるイベントなので楽しみにしていましたし、実際参加していて楽しかったです。

2次会も含めて、学びもあり笑いもあり、とっても楽しいイベントでした！

*1:例えば、Red/Greenに留まっていい時間を3分とおいてTDDをするなど

大人のソフトウェアテスト雑談会 #52【論理的思考とは】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に参加してきたので、会の様子を書いていこうと思います。

オープニング

オンライン区長の釣りの話を聴いていました。
区長の独特の釣りの方法(テクの釣り、忍耐の釣り！？)は独特でしたが、めちゃくちゃ大きな鯛やオニカサゴを釣りあげていたということで、凄かったです。
また、先日Emiさんから、「テストの街葛飾のロゴがバグではなくてワームだよね」というご指摘を受けた話も出て、全員納得していました笑

Ryoさんのふりかえりカンファレンス再演の前段

今日はメインイベントとして、Ryoさんがふりかえりカンファレンスで話した内容をロングバージョンで再演してくれました。
講演の前段として、Ryoさんが最近買った車の話や、教習所のシュミレーターの話をしたり、その前段としてKENさんの子供とかわいいお子さんと戯れたりしていました。(ふりかえりカンファレンスの内容とは関係ないですw)

Ryoさんのふりかえりカンファレンス再演

Ryoさんが、ふりかえりカンファレンスで発表した内容(↑のスライド)の再演をしてくれました。
印象的だった箇所を改めて書いていきます。

NEEDSとREQUESTは違う

例えばふりかえりで、「給与を上げてほしい」という話が挙がった時、チームは給与を実際に上げてもらうことを求めているのではなく、給与を上げることで何かしらを満たすことを求めているはずだ、という話がありました。
例えば給与の例であれば、「給与を上げて欲しい」という要望は、自身の頑張りを認めて欲しいという気持ちが要望のもとである可能性があるので、日頃から常に感謝の気持ちを丁寧に述べることが大事だったりするかもしれないよね、という話でした。
ふりかえりや1on1をしている時、出てきた話をそのまま捉えると、実現も不可能で突拍子もない話に見えたりして問題に向き合いきれないことが多いのですが、めちゃくちゃな話に思えても、出てきた話に向き合うことが大事だよなあ、としみじみ思っていました。

問題は解決することよりも向き合うことが大事

ふりかえりで出た問題は、必ずしも解決しなくて良くて問題に対してチームが向き合い続けることが大事だという話があり、問題は見つかっただけで解決する(=オートクライン)こともあるし、ふりかえりなどを通して継続的に向き合い続けることが大切だという話を聴きました。

また、問題に向き合い続けられるための仕組みや問題に対してチームで向き合い続ける姿勢を作っていくために、Ryoさんの発表はすごく役に立ちそうだし、現場で活かせる考え方も多そうだと、発表を聴いて感じていました。

承認は気持ちが入っていないとばれる

講演の内容とは直接関係ないのですが、Ryoさんが、「ファシリテーターはチームから出てきたアクションアイテムに対して心から承認をするのが大切だ。心からしていない承認は相手に響かないことが多い」という話をしていたのが印象的でした。
あまり賛成できない意見や価値観の相違で共感できない意見に対して、心から承認をすることができていないなあと、自身の行動を顧みて反省していました。

講演のあとがたり

講演の内容から文化を変える難しさを語る流れになり、気持ちが入っていない技術だけのコーチングが辛い話...をしていきました。

テストの街葛飾らしく、ぎゅっと濃縮された話が綺麗なタイミングで次々と移り変わっていったのですが、「何が良い方向かなんかは分からないのだから、今のベストを尽くしていけばいい」という話があり、キャリアに悩んでいる自分にとって、はっとする内容でした。

1on1

1on1ってなんだろうね、という話をしていきました。
皆さんの1on1事情が聴けて面白かったのと、オンライン区長が1on1について色々と思っていることを話して、それに対して皆さんが1on1について思うことを話す、という時間だったのですが、1on1の定義やなぜやるのか、という所から話ができて、非常に興味深い話を聴くことができました。
結構カルチャーショックを受けるような話も多かったので、改めて1on1について考えるきっかけになりました。

全体を通した感想

まずは、Ryoさんの再演が聴けて楽しかったです！
げらげら笑うみたいな会ではなく、しんみりと良い話を多数聞くことができて、今日も楽しい会でした。
仕事しながら聴いていて、今日はあんまり声を出して喋らずに皆さんの話を聴く or Discordで会話だけ参加、という状態でしたが、そのような参加スタイルでも楽しめるのが、テストの街葛飾のいい所だなあと感じました！

【モク読会】に参加してみて

先日金曜日、なべさんが主催している【モク読会】に参加してきました。

yasashii-agile.connpass.com

参加してみて、楽しかったのは勿論ですが、思ったよりも多くの気づきが個人的にはあって、有意義な時間を過ごすことができたので、会の簡単な様子を紹介するとともに、感想を書いてみようと思います。

会の進め方と様子

進め方はシンプルで、以下の流れを2時間繰り返していくという形式です。

1. 読書する(25分)
2. 参加者が一人ずつ感想をシェアする(5分)
3. 上記1と2を繰り返す

読書中は皆さん音声をミュートにして静かに読む形で、特にコメントや会話があるわけではありません。(皆さん別々の本を読んでいるので当たり前ですが笑)

気づき・参加してよかったこと

「上記のシンプルな進め方の読書会でどれ位効果があるのかな？まあ一人で読むより楽しそうだし参加してみるかー」くらいのノリで参加していましたが、楽しいのみならず予想外に学びや気づきがあり、イベント終了後には「参加してよかったー！」となっていました。
以下、気付きと参加して良かったことを書いていきます。

一人で読むよりはるかに楽しい

たくさんの知識を持ち併せている方々と一緒に読書できるという体験だけでもわくわくしますが、その上で皆さんの読んでいる本やコメントが聴いていて面白いので、参加していて純粋に楽しいです。

皆さんの本の読み方や本を読みながらどういうことを考えているのかが分かる

皆さんが本をどんな感じで読んでいるのかやどんなことを考えているのか(どういう表現に引っかかるのか、どういう内容に対して考察を深めているのか...)が分かり、本の読み方の幅が広がったような気がしました。
また、考察や思考の深め方が皆さんの感想から読み取れました。読書術の本や記事の内容よりも抽象度が低い情報が得られるので、理解が一段深まったような感覚がありました。
効率的な読書法はまだまだ訓練中な自分にとっては大きな学びがありました。

25分+5分のサイクルの優秀さ

所謂ポモドーロテクニックと呼ばれる方法で読書+感想シェアを繰り返していくのですが、このサイクルがめちゃくちゃ優秀でした。
これまで、テクニックとしては知っていて試したことはあったものの、読書をする時は時間を厳密には区切らず*1、流れで一気に読む方が効率が良いと思っていましたが、思い込みだったことを痛感しました。
あくまでも個人の感想ですが、

• 読書をしていて疲れない気がする
• 25分で読んだ(インプットした)内容を5分でアウトプットするというサイクルを回すことで記憶の定着率が高いような気がする
• 読んでいて詰まったポイントや本の言い回しなどで感じたことを、短いスパンでふりかえりし、次に活かすことができる

という効果を実感しました。
あまりにも強力で驚いたので、個人の読書でも導入を試みだしています。

適度な緊張感

普段は読書をしよう！と思いたっても、眠くなってきて数十分読んで途中でやめたり、仕事のことが気になってきたり自分はしてしまいますが、皆と読んでいるという適度な緊張感があるので、途中で離脱したりせずに、持続して本を読むことが可能です。

ただ、気分が乗らないなら途中退出しても良いくらいの緩さがあるのが、このイベントの良い所だとも個人的には思っています。(絶対抜けれない空気があると、それはそれで継続して参加しにくくなってしまうので...)

おわりに

以上、色々と気が付いたこと・参加してよかったことを書いていきましたが、参加のハードルはめちゃくちゃ低くて、

• 途中参加, 途中退出OK
• 聞き専でもOK
• もはや本を読まなくてもOK
• 感想を発表しなくてもOK

という感じなので、興味がある人は是非参加してみて下さい！
自分も今後、定期的に参加してみようと思います！

*1:目次を読む時間だけしっかり区切っていました

「チームビルディング勉強会 コラボレーション・パターンを使って語る会」に参加してきた

team-building-study-group.connpass.com

kuroさん主催のチームビルディング勉強会～コラボレーション・パターンを使って語る会～に参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、connpassのイベントページから引用です。

今回のイベントではパターン・ランゲージの1つである「コラボレーション・パターン」を題材にしてチームビルディングに関する対話を参加者同士でします。各参加者にて「コラボレーション・パターン」の各パターンの中から気になるパターンを選び、パターンそのものについての話や関係する過去の事例、現在の悩み等を議論したいと思います。
事前に読んだ上で選んで来てくれてもよいですし、当日直感でパターンを選んでもらっても構いません。

コラボレーション・パターンとは

慶應義塾大学の井庭崇研究室にて作成されたパターン・ランゲージです。

創造的コラボレーションを実現するための共通言語を。 コラボレーション・パターンは、「創造的コラボレーション」の秘訣を言語化したものです。創造的コラボレーションでは、メンバーが高め合い成長しながら、個人には還元できないチームレベルの「創発的な勢い」に乗り、世界を変えるような成果を生み出します。そのようなコラボレーションのデザインにおける視点や方法をまとめたものが、コラボレーション・パターンなのです。

collabpatterns.sfc.keio.ac.jp

会の様子

用事が長引いてしまい10分ほど遅れての参加になってしまいましたが、以下のような流れで進んでいきました。

オープニング

会の趣旨説明&自己紹介をいつも通りしていきました。

「コラボレーション・パターン」について語る時間

参加者の皆さん各々が、それぞれが気になるコラボレーション・パターンを選び、パターンそれぞれについて議論をしていきました。
以下、会で議論したパターンと議論内容を書いていきます。

クオリティ・ライン

クオリティ・ラインを定めるという部分で、クオリティ・ラインとは何かを話していました。クオリティという言葉が個人の解釈によって誤解を招くかもしれないね、という話があり、製造業やソフトウェア開発でいう品質ではなく、チームの目標とか目指す姿みたいな言葉の方が解釈しやすいかもしれないね、という話がありました。
また、コンフォートゾーンにいるチーム(現状に満足しているチーム)には刺さる内容なのかな、という話をしていきました。

臨機応変な動き

プロジェクトだと、トップダウンである程度できる人が指令をしていくしかない場面が多いと自分は感じていて、どうすればコラボレーション・パターンに書いてあるような臨機応変な動きができるのか気になり、自分が挙げさせてもらいました。
皆さんからも、「何でもかんでも手を挙げたり動きすぎると器用貧乏的な動きになる印象がある」という課題感があるというお話や、越境(=臨機応変な動き)ができるために余白を作ることが大事なのでは、という話を伺いました。

創造の場づくり

どういう場を設計をすると創造の場づくりができるのかという話で盛り上がり、トップダウンでかんばんやホワイトボードを与えられて、「さあ創造的な場づくりをしましょう！」というのではなく、チームが漸進的に創造しやすい場を、自律的に作っていくのが望ましいのではないかという話が挙がりました。
また、参加者の方から、「現実を変えていくための第一ステップが言葉である」という話や「敢えていけていない状態(名前)でチームに渡して、チームが改良しやすくしていく工夫を普段している」という話が聴けて、大変参考になりました。

全体を通した感想

前回のOSTもそうですが、会が盛り上がった結果時間が足りなくなって、挙げられた半分のパターンしか話をすることができませんでした笑
普段一緒に仕事をしていない皆さんの経験があれこれと聞けたり、抽象度が高くて理解が難しい話が、皆さんの話を通して理解できたりして、非常に有意義な時間を過ごすことができました。
コラボレーション・パターンがどういう風に活用できるのか？これがパターンなのか？というのは良く分かりませんでしたが、勉強になる内容が多くて今回も参加していて楽しい会でした！

「スクラムマスターとしてのメンバーとの関わり方は？」に参加してきた

agile-hiyoko-club.connpass.com

今日はこちらのイベントにイベントレポート枠として参加してきたので、レポートを書いていこうと思います。

以下、時系列順にイベントの様子を書いていきます。

LT～SIerでの初めてのアジャイル～

hiraokaさんのLTとして、SIerに初めてアジャイルを導入した話を聴いていきました。
中村洋さんをアジャイルコーチとして招聘して、2つの課題に対して取り組んだ話を伺っていきました。
課題は、①チームメンバーが話さない・意見ができない ②リーダーの指示を待ってしまう、の2つが今回は説明されていました。
①に対しては関係性構築のためにチームビルディングのエクササイズ(ドラッカー風エクササイズ...)で、②に対しては意見を引き出すために問いかけを活用することで対応されたということでした。
アジャイルを上手く進めるために複数冊の本を読んだり、チーム全体で問題に対して実直に向かっている様子が伺えたのが印象的で素敵な発表でした！

メインスピーチ～スクラムマスターとしてのメンバーとの関わり方～

ShoheiKunさん*1が、スクラムマスターとして参画したチームにおける失敗談と成功談から見えてきた、スクラムマスターとしてのチームメンバーとの関わり方についてお話してくれました。

失敗談

教科書的な理想をスタートに、「ユーザーストーリーを価値ある単位に分割しよう」と開発メンバーに提案したら強烈な反発を受けてしまい失敗した、という話がありました。
スクラムの構造を守ることを意識し過ぎると、スクラムをやることが目的になってしまったりしがちな話と似ているのかもなあと、聴いていて感じていました。

成功談

チームで仕事の属人化が進んでしまっているといたり、スイッチングコストが多くかかってしまいたり、という問題ベースでペアプロの導入を勧めたら、チームに定着したという話を聴くことができました。

失敗談と成功談から見えてきた話

チームの想いにまずは共感して、共感した想いをベースに外から観察できた視点を混ぜて働きかけできるといい関係が築けるのではないか？という話をしてくれました。
素敵な気づきだなあと素直に思いましたし、理想を押し付けずにメンバーの想いに共感する姿勢を持てているShoheiKunさんのスクラムマスター力の高さが尊敬でした！

お悩み相談会

3つのテーブルに分かれて、それぞれでお悩み相談会をしていきました。
自分は、「意思決定や進捗管理をついしてしまうが、進捗遅延している時はSMとしてどうしているか？」という話に参加しました。
前半は話に入るタイミングを上手く掴めておらず、ほぼ聞き専の形での参加になってしまったのですが、後半は少しだけ会話に参加することができました。
折角なので色々とお話をしたいなあと思っていたので、話ができて良かったです。

意思決定や進捗管理をついしてしまう

メンバーが指示や仕様の意思決定や進捗管理を求めてきがちな環境ということで、どうしたら意思決定や進捗管理をせずにメンバーが自律的に動けるようになるか？という話をしていきました。
さりげなくメンバーに聞き返すテクニックであったり、スクラムが理想としている状態を言語化して教えたりすると良いのでは？というお話がありました。

進捗遅延している時はSMとしてどうしているか？

レトロスペクティブやスプリントレビューなどの機会で、チームに対して、進捗が遅延していること(プロダクトバックログアイテムが予定通りに終わっていないこと)を相談してみると良いのでは？という話がありました。
また、そもそも、プロダクトバックログアイテムが予定通りに終わっていないことをチームに対して問題だと思っているか聴いてみると良いのでは？という話がありました。

ふりかえり～Fun/Done/Learn～

お悩み相談会の内容共有後に、イベントのふりかえりをしていきました。
Fun, Done, Learnそれぞれについて、参加者の皆さんから多数の意見が出ていて、参加者の皆さんがそれぞれ楽しんで参加できていた様子が伺えました！

全体を通した感想

終始優しい空気で進行されていくイベントで、初参加の自分でも非常に参加しやすかったです。
oViceがやや不安定だったのは少しだけ残念でしたが、盛りだくさんのコンテンツを楽しむことができたので、参加することができてよかったなあと思うイベントでした。
お悩み相談会では、お悩み相談のテーマが多数出ていたり、Muralの盛り上がりがあったりと、意欲的な参加者の皆さんの姿が印象的な、元気がもらえるイベントでした！

*1:Twitterでちょこちょこお話していたので、今回メインスピーカーとしてお話を聴く機会を楽しみにしていました！