リモートモブプロ勉強会をrepl.it+Zoomでやれそう

モブプロ勉強会のリモート開催の可能性を考えて、簡単な素振りをしてみました。

  • repl.it(オンラインIDE)は言語やフレームワークの幅が広く、使える
  • replt.itのMultiplayer機能で、ブラウザ上で複数人(無料では4人まで)で共有できる。VSCode LiveShareとほぼ同じ感覚。参加者もアカウントが必要 https://repl.it/site/blog/multi
  • ファイル追加したときに同期されないことがあった(リロードしたら見えるようになった)
  • 誰がどのファイルを開いているかわからないので、ぼんやり見てると見失う可能性がある。ドライバーは編集箇所を頻繁に口に出すとか、ドライバーの画面を共有するといいかも。(なお、ファイル内では誰がどこにカーソル置いてるかはわかる)
  • テスト駆動開発や自動テスト実行は、repl.itの機能としてはないけど、実現可能(テストケース実行を外部コマンド叩くとか、言語内から呼び出すとか。言語にもよる。今回はruby+rspecで、main.rbからexecでコマンドを実行した)
  • コミュニケーションはZoom
  • Zoomの文字チャットを使うのが一番ハードル低い(replt.itのチャット機能は貧弱なので厳しい。Slack使えるといいけれど、そのためだけにワークスペース追加してもらうのはちょっと心理的ハードルが高い)
  • タイマーは、誰かが手元で動かしておく
  • ドライバーは参加順などで強制的にまわすのがよさそう(リモートで空気読んで手を挙げるのは難しい

なお来週のテスト駆動飲み会自体は、予定変更せず普通のモブでやる方向で考えています。その後、リモート開催に切り替えることになりました

 

 

自分がどんなふうにインセプションデッキ作りをファシリテートしているか

インセプションデッキ Advent Calendar 2019 - Adventarの参加エントリです。

アジャイルコーチとして活動する中で、インセプションデッキ作りを手伝うことがよくあります。私がファシリテートする場で、どんなことを考え、どんなことをしているのか、思いついたところを書き出してみました。一例として参考になる部分があればいいなと思っています。書き出してみると、我ながらちゃんと考えられていないところがあるなあと気づいたりしますね。

 

目次

 

インセプションデッキ作りが重要だ、作ったインセプションデッキはどうでもいい (いくないけどそれほどでもない)

私がインセプションデッキを作るねらいは、参加者がプロジェクトの背景や目的、ねらいとこれからの進め方について議論し、理解し、合意する活動そのものです。その意味で、デッキ作りの成果は、参加者の中にある認識であったり、作ったデッキに対して合意したという仲間意識であったり、これから一緒にやっていこうという意気込みであったりします。

 

デッキの完成は、そうした成果に比べると優先順位は下がります。個々のスライドの完成度はあまりこだわりませんし、すべて完成しようともしません。組織、プロジェクト、参加者によって重要な要素は毎回異なるので、時間をかけたいスライドも変わってきます。

 

もちろん完成に意味がないというわけではありません。完成したデッキは有用で、目に付くところに貼っておいたり、将来のタイミングで見直したり手直しをしたりできます。ですが、完成のためにやっているわけではないのだと認識しておくほうが健全です。またデッキの完成を目標にしてしまうと、議論が足らなくなったり、空気を読んで“合意”してしまったり、しやすいようです。

 

タフクエスチョンカードを手作りする

タフクエスチョンカードを、最初に作ります。これは物理的な紙のカードで、「(タフクエスチョンするぞ…!)」という気持ちを表明するのに使います。質問、ツッコミ、反論をするときにこのカードを出してから言うという使い方をします。説明としてはそういうふうに言いますが、実態としては質問することを忘れないための手元のトークンになるものです。


インデックスカードを1人1枚配り、各自カードを作ってもらいます。デザインは人それぞれで、びっくりマークやクエスチョンマークを描く人や、人間の顔を描く人、爆発やツッコミのイラストなどもあります。インパクトあるデザインでもいいし、逆に雰囲気を和らげるように描くのもよいでしょう。


タフクエスチョンカードを手元に置いておくと、質問から議論が起こりやすくなります。話を聞いたときそのまま納得するのではなく、なにかツッコミを入れるように意識が向きやすくなるのではないかと考えています。

 

全体の進め方も合意で決める

インセプションデッキ作りの進め方そのものも、議論と合意で決めていきます。最初に導入として、インセプションデッキの全体像や個々のスライドの内容を簡単に紹介し、スライドのタイトルを付箋に書いて並べます。ここからは、参加者全員でのプロセスになります。どのスライドを選ぶか、どの順番で作るか、どのくらい時間をかけたいか、その場で検討しながら決めていきます。結果として作るスライドを順番に並べたものができます。これはスクラムのプロダクトバックログと同じで、進みながら見直し、随時変更、入れ替えていきます。


スライドを自由に選ぶ流れではありますが、実際には「なぜここ」が外れることはありません。他にも「エレベーターピッチ」「ご近所さん」「夜も眠れないこと」「トレードオフスライダー」あたりは採用されることが多かったです(私がファシリテーターをやるときの話なので、私自身のバイアスが影響してそうな気もします)。順序は「なぜここ」が最初、あとは気になっている箇所を優先していくと、けっこうバラバラになります。Why→Howの順序が崩れることもあります。


少なくとも最初の数枚を決めてから、スライド作りに入ります。1枚終わったら、本当に完成にしていいかを確認したうえで、付箋に大きなチェックマークを付けていきます(確認にはサムズアップ・ダウンを使います)。また、そこで残り時間を確認し、次以降のスライドを見直します。予定時間を調整したり、順序を入れ替えたり、ときには準備が不足だと気づいてスケジュールを立て直すこともあります。

 

オーナーは目的意識を持って事前準備する

インセプションデッキ作りには、通常オーナーがいます。すでにバスに乗っていて、今回の参加者もバスに乗せたいという意図をもった人々です。この人たちには、作りたいスライドを事前に考えておいてもらい、いくつかは叩き台を準備してもらうこともあります。しかし当日、スライドを決めるに当たっては、そうした意見もあくまでいち参加者の意見として発言し、そうしたい理由を説明してもらい、全員の合意で決めるようにしています。


オーナーは場合によっては、事前に他の参加者に状況説明や参加してほしい理由などを説明していることもあります。インセプションデッキ作りは合意を一とする場で、アイデア出しや各論の検討、議論をするには時間が足りないようです。


(こう書いてみると、まるで根回ししまくりの、当日は意見もアイデアも出ない静寂とした、オーナーの都合に合わせた予定調和の、粛々と進行してシャンシャンとまとまる、つまらない会議みたいに聞こえますね。実際はそんなことなく、それぞれの人がそれぞれの立場から色々な案や反論や感想が出てきますし、はじめに思っていたのとは違う合意があらわれることも多いです。上に書いたような気を使うのは、参加者の数が多く多様で、仕事上の立場もミッションも違い、利害対立する可能性があるような場合で、オーナーの判断によります。一例として、いわゆる顧客や発注側の内部で合意を作りたいときです。)

 

タイムボックスはあんまり使わない

完成を意識しすぎないよう、インセプションデッキではタイムボックスをあまり設けないようにしています。「なぜここ」を話し始めて、そのまま丸1日まとまりきらないこともありました。


議論をファシリテートするうえでのテクニックとして、時間を意識してもらうことはありますし、割と大事にしてもいます。ですが「このスライドはあと30分で打ち切りましょう」というような進め方は避けています。参加者が話し尽くしたと感じられる、挙げられた論点がひととおりカバーされている、熱意を持って「これでいこう!」という雰囲気ができているかで、終了にしてよさそうか判断します。ファシリテーターや、参加者から「これで完成にしましょう」のような意見が出て、みんなが喜んで合意すれば、完成です。合意できないときや、不承不承な感じがする、疲れてきてどうでもよくなっているようなときは、長めの休憩(15分~30分)をとってから再確認します。


スライドにより、時間あたりの収穫が急に下がるものや、時間で切らないと終わりにしにくいものもあります。最初にタイムボックスを決めることが多いのは「パッケージ」や「夜も眠れないこと」などです。
もっとも参加者が全員集まれる時間は限られているので、いくらでも時間をかけていいというわけにはいきません。時間がかかりそうな部分は、事前に叩き台を準備してもらったり、一部の関係者で議論を進めておいてもらったりするようアドバイスしています。

 

休憩は戦略的に

休憩は重要です。4時間、あるいは丸1日かけてインセプションデッキ作りをするのであれば、休憩もしっかり確保します。休憩には戦略性があって、お手洗いに行くていどの5~10分くらいの休憩は前の議論を続けやすくなります。議論が詰まったような場面では、15分~30分くらいの長めの休憩を取って、頭を切り替えます。場のあったまり方にもよりますが、休憩時間にリラックスしてコーヒーやお菓子をとりながら話しているときが、実は突っ込んだ話ができていたりもします。当然、ちゃんと休むのも大事なので、話が続いているのを遮ってしまうこともあります。


休憩を取るタイミングも工夫ができます。話が盛り上がったとき、特にテンションや感情が高まったときは、すこし落ち着くために休憩を挟むのも有効です。結論や合意になんとなく不満がありそうなときも、いちど休憩を入れて個別に話すタイミングを取るとよいです。デッキ完成など区切りがついたときに取るのもよいのですが、完成したときはテンションが上がっていて、そのまま休まず次に進んだ方がスムーズに移行できるようなときもあります。

 

それぞれのスライドについて個人的なメモ

なぜここでは、以下のような質問を使って、状況を深掘りすることが多いです。

  • なぜ今、このタイミングなのか?
  • なぜこのメンバーなのか?
  • 他のことではなくこのプロジェクトをやる理由は?
  • うまくいったとき、本当に喜ぶのは誰か?

会社組織の中で立ち上がるプロジェクトでは、プロダクトとして実現したい目標だけではなく、組織の事情、人の都合、予算や年度区切りなど、本質っぽくないドロドロしがちだけど必要な話というのがよくあります(面倒くさい……)。きれいごとだけではない背景まで明るみに出して、コアメンバーで共有するようにします。こうした話はデッキには書き残せないこともありました。

 

エレベーターピッチには苦手意識を感じています。おそらく、企業の社内システムに関わる仕事が多いためもあって、エレベーターピッチ作りで紛糾したり、議論がダレる場面を多く見ます。エンドユーザーにはっきりしたペインがない、他の選択肢がなく優位性を考えられない、上からやれと言われてやっている感がにじみ出てしまう、などです(そうした認識が表面化するのは、それ自体は有益だと思います)。ステークホルダーが顔の見える特定の個人で、その人を説得する言葉が政治じみていて、プロダクトからフォーカスが外れてしまう場合もあります。

 

パッケージデザインは、私は心の中で「プロダクトビジュアル」と呼んでいます。プロダクトのポスターを描く形式にすることが多いです。プロダクト名や特徴などの文字も使いますが、なにかしらの絵、イラスト、アイコン、ロゴを入れてもらいます。アイデアを出しながら、全員がペンを握って描くように、絵が上手い人に押しつけるようなことがないようにガイドします。上手だったり綺麗だったりするよりも、参加者全員が「自分が描いた」と感じられる方が大事です。できたポスターはそのまま、チームの仕事場に貼り出しておきます。

 

ご近所さんでは、顔が見える(個人名が分かる)ようにしています。部署だったり会社だったりではなく、その中の誰が担当なのか、内部にはどんな人がいるのか、何かあったときに誰に連絡することになるのか、わかる範囲で出してもらいます。

 

トレードオフスライダーの基本4項目(スコープ、予算、時間、品質)だけ議論するときは、必要ではあるもののあまり面白い話にならないことが多いようです。面白いかどうかは、大いに主観ですけれど。それ以外の項目の話が出てくると、このプロジェクトならではの話に発展します。

 

以上です。アドベントカレンダー次回は、12/21稲野さんの予定です。

スクラムで問題(バグ)対応するときのアプローチ

先日、現場の人から質問を受けました。

スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」

バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。

  • 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。
  • POが優先順位が1番だと判断したからといって、READYであるとは限らない。スプリントに入れて開発チームで取り組む準備ができていなかったら、スプリントに入れられない。
  • 問題が大きそうで、プロダクトやプロジェクト(リリース)へのインパクトも大きいのであれば、スプリントに入れるのとは別の理由で、できるだけ早く見積もりができるほうがよいはず。リリース日の変更や、リリースに含める機能の大幅な変更、関係者への連絡や調整などのためにも、できるだけ早く見積もりがほしい。
  • 粗く当たりをつけた当初の見積もりは、関係者に早く伝えるのが重要かつ、状況が変わったら随時伝え続ける、現状を更新し続けるのも重要。問題はとりわけ、どんどん対応工数がふくらみやすいので、最新の現状を共有しないといけない。相手にもよるが、あまり楽観的に伝えない方が先々お互いに安心。
  • 問題の調査を開発チームがする必要があるのであれば、その作業を解釈としてはリファインメントの時間と考えることもできる。ガイドではリファインメントはスプリントの10%までだが、一時的に越えるのは大きな影響はないと思う。
  • 問題の調査、切り分けはスプリント期間中、一定の時間枠(タイムボックス)を取って進める。逆に言うと、スプリントの他の開発も並行して進める(「4.1.20 常に誰かが進捗させる」組織パターン)。すべてが止まってしまうと後から立て直すのがしんどい。調査に12時間使う、1ペアはずっと問題調査に充てる、あるいは3~4人はモブでずっと問題調査をするなどということにして、残りの人数は他のPBIを進められる。12時間ならベロシティは通常の28/40になる。5人チームで1ペアが問題調査をするなら、ベロシティは通常の3/5になる。
  • ペアプロやモブプロのスタイルで調査をする。問題調査は心が折れやすい仕事で、ペアやモブだと心が折れにくい。どこにあるかわからない、なにかもわからないものを探すのには、目玉と脳味噌が多いほうが良い。スタイルはゆるくてよく、自分のPCでちょっと確認するとか、相談した上で手分けをするタイミングが、あったりしてもよい。またペアやモブのメンバーもゆるく、時々入れ替わったり、誰かを呼んで教えてもらったり手伝ったりしてもらう。
  • 問題調査もできるだけブレークダウンして、個別のタスクに切り出す。思いついたところから手当たり次第に進めたり、各自が勝手に調べたり、あるいは誰かが脳内で整理しつつ指示をするようなやり方は、効率が悪い。おそらくスプリント単位(1週間)でタスクを切り出すのは困難なので、タスク出しは随時おこなわれることになる。(Mikado Methodも便利。テストとリファクタリングに関する深い方法論 #wewlc_jp の36枚目など)
  • 調査の状況や進捗は、できるだけ記録に残す。ラフで良く、またアナログ、できれば目の前のホワイトボードを占有するようなやり方がよい。作戦司令室とか、あるいは捜査本部みたいな感じで、その場に来れば状況が分かる、いま何を調べていて、どこまで進んでいて、次に何をすべきか全員がつかめるようにする。問題調査はカオスになりがちなので、そのカオスをそのまま表現する。
  • 調べた結果は、できるだけ自動テストや自動化スクリプトなどで残す。調査自体も自動化しながら進める。勘違いや見落としを後から確認できるし、パターンを追加するのも容易。他の人が確認した内容を正確に共有できる。問題を特定したら、その問題を再現するテストを自動化しておく。
  • 問題調査にキリがついて、対応方針が確定して、あとは直すだけというところまできたら、直すという作業をPBI(ストーリー)にする。あとは他のPBIと変わらない(見積もりをして、大きければ分割し、受入条件を作り、プロダクトバックログに並べる)。
  • そもそも問題に緊急性が高く、スプリントで扱いきれないようであれば、スプリント緊急中止を検討する。本来のスプリント中止では、そこから新しいスプリントを計画する。また別の案として、スクラムそのものを停止して、全員で問題の調査や対応に全力で対応する。どうしても必要なときに検討すべき手段だが、あとでスクラムを再始動するのにかなりエネルギーがいることを覚悟する。
  • そもそも問題調査を開発チームでやるのがいいかはわからず、外部の人に頼む、別にチームを作るなどのアプローチもできるはず。

RSGT2020勝手にプロポーザル紹介(2日目)

Regional Scrum Gathering Tokyo 2020 (2020年1月予定)のセッション公募が始まっています。プロポーザルがどれも面白そうだけどたくさんあるので、気になったものを紹介してみたいと思います。経緯はRSGT2020勝手にプロポーザル紹介(1日目) - The HIRO Saysも参照してください。

わたし自身はこちらを応募しています。興味あれば投票お願いします。

confengine.com紹介する方向性としては、入門や事例よりは新たな理論や突っ込んだ分析、あとは生の現場の様子なんかに興味があって、RSGTはけっこう参加してるぜ(だけど実はセッションはあんま真面目に聞いてないな)という立場です。

というわけでひとつめ。

confengine.com
野中郁次郎が『知的機動力の本質』で米国海兵隊を研究しているように、軍事組織から学べることってたくさんあると思います。良い点も、悪い点も含めて(悪い点は『失敗の本質』が有名ですね)。米陸軍のAARなんかも学ぶところがあります。

このセッションの内容については知らないのですが、そんなわけで新たな学びに期待しています。

 

 次は、いきなり前言ひるがえして入門的なやつ。

confengine.comJeff Sutherland, James Coplienらがスクラムというフレームワークをパターン言語としてまとめなおしたという、壮絶な手間暇がかかっている知の結晶がやっと書籍として出版されます(2019年秋。電子版はすでに入手可)。パターングループにも所属していてパターンライティングに参加している原田騎郎さんが紹介してくれると思います。

これは自分が興味があるというよりは、ぜひ採用されて多くの人に参加してほしいというプッシュの意味で紹介しました。

 

それから、理論を謳っているもの。

インテグラル理論を用いた、今までにない文化に根ざしたやり方を導入するためのトップダウン・アプローチ

confengine.comいまさらながらケン・ウィルバー読んでいるので、気になっています。林栄一さん、最近お忙しかったみたいであまり表に出てこられない印象だったんですが、久々の登場なのでお話を聞きたいなとも思っています。

 

最後に、ガチな内容が期待大なトークセッション。

confengine.comホロラボの中村薫さんのセッション。広い意味でのバーチャルリアリティを以前から研究されていて、いまは最先端で活躍されています。中村さん、以前アジャイルコミュニティやイベントでお見かけしてたんですが、それが本業でやっとわかってきた、というお話のようです。どんなことがわかったのか、すごく気になります。

 

というところで。次回はこちら、書かれたのは森一樹さんです!

 

qiita.com

 

「心理的安全性ゲーム in 福岡」をやってきました

福岡で心理的安全性ゲームの体験イベントをやってきました。

engineers-day.connpass.com

募集40名枠のところに、最大46名くらいの申し込みがあり、前日~当日のキャンセルも出たものの追加申し込みもあって、ふたを開ければほぼ満席となりました(主催者入れてたぶんちょうど40人)。

f:id:yach:20190523195526j:plain

福岡のみなさんはとても活発で、ゲームにもすぐに入り込んで盛り上がっていました。演技にも熱が入り、このノリの良さは、RSGT2019のとき以来かも。また同じ会社からグループで参加してくれた人や、この場で知り合いと出会っている様子も見られて、コミュニティのつながりの濃さを感じます。

今回はボードを新しく作りました。いままで要望で「マイナスの感情、これダメだって感じも表現したい」「程度(レベル)を表したい」という声をいくつか聞いていたので、そういうボードを作っています。

f:id:yach:20190524112723p:plain

このボードだと、左より・右より・バラバラという石の配置で様子が分かるので、以前のものより見やすい感じがします。

f:id:yach:20190523201111j:plain

ゲームを2回遊んで(途中ではいつもの心理的安全についての簡単な解説を入れています)、全体でのふりかえりにも取り組みました。この人数で全体共有は難しいので、ワールドカフェ形式でグループをシャッフルしながらそれぞれの人の経験、発見を語り合いながら、最後は「心理的安全のために明日からできること」を付箋にまとめて、全体で共有をしました。「人にフォーカスせず 出来事にフォーカス」や「一見、否定的な発言でも、チームのためを考えてのこともある」などの心構えや、「ネガティブ発言をした人はすでに追い込まれているので、丁寧にフォロー」「サポーターが1人でもいるといい」などのすぐに使えるアイデアも出ています。

f:id:yach:20190523211035j:plain

福岡は美味しい

今回は鬼木さんに福岡を案内していただき、うどんやぜんざいなどを食べ歩きました。懇親会でも美味しいものがたくさんで、あらためて「福岡は美味しい」と思い知りました。福岡に定期的に来られるといいなあ。

f:id:yach:20190523154815j:plain

f:id:yach:20190523164921j:plain

f:id:yach:20190523215524j:plain

f:id:yach:20190524103410j:plain

 心理的安全性ゲームについて

 心理的安全性ゲームは、グループで遊べるカードゲームで、心理的安全のある状況・ない状況を体験しながら、心理的安全について考えたり、議論したり、具体的な行動を取ったりするきっかけ作りになるゲームです。

games.yattom.jpゲームを体験するイベントの主催者を募集中です。会社のメンバーとやってみたい、コミュニティやなんらかの活動グループで体験したい、セミナーをやってほしいなどのご要望があれば、道具類をもってやりに行きます。詳しくはこちらから。

 

 

心理的安全性ゲーム レポート集

心理的安全性ゲームを遊んでみた方、体験した方のブログなどのレポートを、いま見つかる範囲で集めてみました。心理的安全性ゲームの紹介はこちら。

後半の、自分で社内でやってみた編は、同じく自分でやってみたい方の参考になるかなと思います。

やっとむ(制作者)の体験イベント編 


独自でやった編

心理的安全性ゲームをDevelopers.IOカフェでやってきました

3月20日に、クラスメソッド株式会社の運営するDevelopers.IO CAFEで場所をお借りして、心理的安全性ゲームの体験イベントをやってきました。

cafe.classmethod.jpDevelopers.IOカフェ、完全キャッシュレス&カウンターもレジもないということで有名ですね。以前に営業時間内に行きましたが、お店に着く前からアプリで注文、店内のお菓子も持ち去るだけで課金されるという新体験が面白かったです。

分析力の高い心理的安全性ゲーム

今回は4テーブルと比較的少人数だったのと、参加者層がなんとなくこれまでと違ったのか、新しい工夫と、ゲームや心理的安全に対する冷静な分析が見られました。

f:id:yach:20190320202637j:plain

2回目が終わった様子。ボードの黄色、「新たな挑戦」にだけ石がない

私の体験イベントでは、1回目のあと心理的安全についての解説をはさみ、グループ内ふりかえりをしたうえで2回目をやってもらいます。2回目はカードをフルオープンにして、自由に発言カードを選べたらどうなるかを試すグループが多いようです。

写真のグループもフルオープンにしたところ、ボード上の石が大幅に増えたのですが、黄色枠の「新たな挑戦が今より増える」のところだけ石が1つもありません。ボード全体を見ると、チームは失敗への耐性や協力の強化が期待できるものの、成長や挑戦に懸念があります。言ってみれば、レジリエンスがあるのに伸び代が期待できない。

心理的安全がいわゆる「なかよしグループ」と異なるのがこの点です。スライドの36枚目、37枚目でも解説しています。

  1. 限られたリソースで、不確実性のある仕事をしているグループが、
  2. 心理的安全と同時に強い責任を負っているときに

はじめて、チームの学習が起こります。チームが学習するには衝突や、失敗の共有、弱みをさらけ出す必要があり、そのためにこそ心理的安全が大事なのです。今回のグループではこの問題について議論をして、「寄り添うだけではダメ」「前向きな、使いやすい発言だけ選ぶと成長がない」などの意見が出ていました。

f:id:yach:20190326203734p:plain
f:id:yach:20190326203818p:plain



遊び方として、フルオープンの逆に、発言を1枚ずつめくって使うというやり方を編み出したグループもありました。引いた発言カードを使わないといけないので、かえって使い方や言葉の補い方、言い方の工夫が強まっていたようです。

f:id:yach:20190320201909j:plain

全体ふりかえり

今回はグループごとのふりかえりに加えて、「今日学んだことを、自分の現場で使うにはどうしたらいいか?」というテーマで全体ふりかえりをしました。以下に、参加者のみなさんが書いてくれた付箋を共有します。文字起こししたものも置いておきます。

f:id:yach:20190320210312j:plain
f:id:yach:20190320210224j:plain
f:id:yach:20190320210215j:plain
f:id:yach:20190320210209j:plain
全体ふりかえり

 

  • 個人への責任追及 → 解決の方が大事
  • 個人にフォーカスせず、チームの課題にするとよさそう
  • 組織内対立は打つ手なかった
  • 自分の心の余裕がわかる気がする
  • 心理的安全性が上がるとある程度余裕ができる
  • (平和を)乱した人がモヤモヤを解消できないと心理的安全下がりそう
  • 否定と肯定が入り交じってる方が丁度良い
  • 組織自体の課題は安全性とりやすい
  • 言う人の実力で受け手の反応は異なる
  • 善人だけのぬるま湯チーム 逆にNoと言いづらい
  • タスクの分担が明瞭すぎると無関心が生じる(すき間は誰がやる?)

 

  • 4.aの"チームで使いたいもの"ばかりのチームだとぬるま湯的な…
  • 使いたくないカード=安全が悪くなるカード
  • フォローする反応ばかりだと学習が弱くなる
  • 気持ちに寄り添うだけでは進まない
  • 4.aだけでは学習がない?
  • 余裕が自分にないと助けられない
  • 無視して見ないふりする あんまり良くない
  • 同じフレーズでもコンテキストによって違う

 

  • 多様性大事 でもスキルセットがまったく違うと学びがない
  • 学びあいできるチームになりたいと思った
  • 1人温かいことを言うとぜんぜん雰囲気が変わる
  • メタな視点で見直せたので客観的になれた
  • それまでにコミュニケーションがとても大事
  • なかよしクラブではない安全を考えたい
  • 安全が確保できていなければチャレンジできない
  • 無視されるとツライ
  • みんながネガティブに言っていても、フォローが入ると大分ちがう
  • 同じことを言っても言い方と状態で違う捉え方をされてしまう
  • 「自由に発言する」が意外にむずかしい
  • ゲームだけど安心感を感じたり変な気持ちになった
  • 実際の現場ならなおさら強くこの気持ちが出そうだ
  • 雑に振る舞ってることあるな…
  • 同じ発言でも語調によって安心が出来ない
  • ネガティブなOptionは意識していかないと
  • 使いたいカードがフォロー系のカードが大半で、挑戦、学びが少なかった

 

  • ゴールへの縛りがあるほうが建設的意見が出やすい
  • チームに浸透させるためにはどうしたらいいか
  • RPGとしてはひよった
  • なんとかしろって言う人が自分でやるべきみたいな発想がすでに安全とは遠い
  • ネガティブパワーはすさまじい
  • 寄り添うだけではダメ
  • 無関心をなくすための雰囲気作りが大事
  • 「大変・つらい」と不安は別である。やれる幅がないと不安
  • まず関心をもつこと → いや、"もたせる"?
  • チャレンジできるチームとわ
  • 安全と建設的な衝突との違いとわ
  • 安全に倒しすぎてもダメかもしんまい
  • ロール設定
  • ゲームの成否に責任をどう扱うかが重要だと思った
  • 心理的安全が低い現場、高い現場を想定して発言をしてみるとより見えるものが
  • 増えるかも
  • 助け合いとわ

体験イベントの主催者を募集しています

今回のような心理的安全性ゲームの体験イベントを主催していただける企業やコミュニティなどを募集しています。オープンな形でも、従業員限定などのクローズな形でも構いません。人数分の道具を持ってやりに行きます。詳しくはこちらをどうぞ。

f:id:yach:20190320201903j:plain


なお今回の心理的安全性ゲームは夜、営業終了後の開催でした。20名枠に倍近くの申し込みをいただき、当日も17名に参加いただきました。またクラスメソッドのみなさんに準備や片付け、お手伝いを頂きました。終了後の飲み会もやたら面白かった!ありがとうございます。

classmethod.connpass.com