プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

でも、もしプロダクト開発がゲームだったら・・・

コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

「どういう人がスクラムマスターをやればいいんだろうか？」

この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

では、どのような人がスクラムマスターに向いているのでしょうか？
またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか？

このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか？」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

English follows:

「[email protected]（[email protected]）を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター（QAエンジニア・テストエンジニア ・などなど）もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA（Visionary QA）」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト（Agile Testing）』（翔泳社）は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ（テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える）。

このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

"In a 100-strong software development organization which runs [email protected], an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

ちんもです。

ちんもが所属する企業グループには、社会に誇れる理念と（野中さん流に言うと）腹にズシンとくる価値観や行動原則があり、併せて組織文化を醸成するための様々な施策が実施されています。

組織文化醸成のための部署（！）があり、毎週の様に動画が配信され、経営陣から新人に至るまで、組織文化に関する理解度把握アンケートやe-larningを繰り返し、価値観や行動原則の実践が評価制度、表彰制度に組み込まれるなど、まあやれることは全部やってるんじゃないかと思います。

じゃあもうグループ社員全員「価値観の体現者！」とか、「創業者の意志を継ぐもの」、みたくなってるかというとそういうわけでもないんですよね。それだけ文化をつくるということは難しいのだと思います。ところで弊企業の掲げる価値観、最近すごくアジャイルぽいやつに変わりました。え、変わっていいもんなんだっけ？あ、そうですか。あなたも変えたいんですね。いいけども。

一方でちんもにはちんもなりに生きているなかで、アジャイルと出会い、現状をそうではない方向へ変えていこうとするなかで、その手段としてちんも風アジャイル組織の文化を産み出そう、広めよう、としてきたのかもしれません。

そんなこんなで入社して4半世紀、曲がりなりにもチームをリードするようになってからは15年、そういうことをしてきたわけです。

しかし僕は文化をつくろうとしたのだろうか。軽々しくそんなことは言えるのだろうか。

ただ、己がやりたいことをやるために、周囲を巻き込み、だまくらかし続けてきただけのことではないのか。僕がいなくなったらそれまでなのか。では今お前がやり続けていることはなんなのか。

個人が自分の周囲に存在する文化を変えようとする試みと、企業が掲げる文化はどう交わるのか。

自律的に発生する既存組織文化への抵抗組織文化たるカルチャーバブルは、企業の文化をどうしちゃうの？

15年をふりかえり、チームの文化と企業の文化に結果的に影響があった可能性が高いと思われる行動を洗い出し、そこから何かしら見えてくるものを探してみたいと思います。

（長々と書きましたが、本発表は「田舎で十年スクラム」シリーズであり、ちんもとその仲間たちの定点観測コンテンツとなっております）

みなさん、ふりかえりは楽しんでいますか？
うんうん、いいですね！私はすっっごく楽しんでいます！！

この2-3年、ふりかえりのことを発信する人たちが増えてきました。
日本で初開催された  ふりかえりカンファレンス では、22名もの人がふりかえりの想いや新しい手法を語っています。
また、ふりかえりamでも、Podcastの中でゲストが様々な手法を紹介してくれ、新しい手法も生み出されています。

日々、新しい手法が生み出されているふりかえり。

このセッションでは、近年生み出された手法を紹介していきます。
どれも楽しくわくわくする手法ばかりですので、気になる手法を真似してみてくださいね！

スプリントプランニングってどうやってやったらいいか、モヤモヤしていませんか？

スクラムガイドを読んで、又は認定トレーニングを受けていざスクラムやっていこう！となったとき、実際にやってみると具体的にはどうやって進めたらいいかわからない、ということがスクラムには多いのではないかと思います。

「プロダクトバックログってどうやって作るの？」とか「自己組織化って何から始めたら？」とか「Doneの定義って具体的に何？」とかいろいろありますが、中でもワカラナイ代表の一つとしてあげられるのが「スプリントプランニングってどうやるの？」じゃないかなと思っています。

私自身もトレーニングを受けてから見様見真似でスプリントプランニングをやっていましたが、
「今までやってたWBSと何が違うんだ」
「タスクってどの単位で切るの？細かくするにも限界が・・・」
「なんかしっくり来ないな」
という感じでモヤモヤしていました。

それでもなんとか試行錯誤を繰り返していたら、チームの学びとして一つのやり方が確立できてきて、スプリントプランニングの役割もなんとなくしっくりきたな、と思えるようになったので、そのあたりを共有していきます。

これが全てではないけれど、きっと誰かの参考になるだろうと思います！

システム開発において、テストは切っても切り離せない存在です。
しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか？
実は、テストコードを書き始める前に既に勝負は決まっています。

本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

皆様は、組織でスクラムマスターをお願いするときに困ったりしていませんか？
また、スクラムマスターが、成長していると感じますか？

多くのチームの見てきましたが、スクラムマスターの任命時から育成において
うまく仕組みが作れている組織はあまりありません。

スクラムマスターの任命にうまくいかなかったり、育てられないと、
スクラムチームのアウトプット・アウトカムの向上がすごく遠回りになってしまいます。

そこで、これまで私が実施してきた方法を学習科学の観点から解説しながら、
スクラムマスターとしての任命から育成の方法について紹介します。

スクラムの活動にはチーム内で話す場面がたくさん設計されていると思います。
話すという行為は言われてみると当たり前なのかもしれないのですが
・ちゃんとチームのメンバーと話せているのか
・聴く耳を持てているのか
・チームメンバーの気持ちを尊重できているのか
・個々のキャリアに向き合えているのか
といった観点を振り返ってみるとどうでしょうか。
話すということはちゃんと考えると結構難しいことだと思います。

私は1on1ミーティングを外部の立場から行うなど、職場のコミュニケーションに特化して組織を支援しています。
一見、1対1のコミュニケーションだから、チームの話とは違う印象をもつかもしれません。
でも仕事を行う以上、人と関わるのは必然。複数人行ううちに共通の課題も見えてきます。
いろんな現場にいくと、対話をしているようでできていない現場をよく見ます。
もちろんこんな風に書いている私もうまく話せなかったなぁという体験はあります。

このセッションでは、「外部メンターとして現場に関わる私がメンバーとの会話で大切にしていること」として職場のコミュニケーションを行う上でどんな考え、理論をもとに普段行なっているのか、そこを考えるに至った背景や時に失敗したことなどをお話ししたいと思います。話すこととはどういうことかをセッション参加者と一緒に考えられたら嬉しいなと思っています。

※参考スライドとして先日発表した資料を添付します。
この内容をそのまま話すわけではないですが、雰囲気や大枠の流れが似たものになるかと思います。
可能な限り新作を加えた形でお話ししたいと考えています。

RSGT2021をきっかけに2冊の本を読みました。

『知識創造企業』と『ワイズカンパニー』。

この中で語られている、
組織がよりいきいきするを、みんなで実現することに
とても魅せられてしまい、野中郁次郎先生のファンとなりました。

20年前に語られていた野中先生のお話を、
スクラムを学んだ目線で読み解いてみると、
非常に面白い要素がたっぷり詰まっていました。

野中先生は、1986年に『The New New Product Development Game』という、
スクラムの原点となった論文を書かれたことでも有名です。

そんな切っても切れないスクラムと野中郁次郎先生について、
にわかファンのJ.Kが熱狂したポイントを語り尽くします。

チームを「アジャイルなチーム」にどう変容させるかという点に苦慮されている方は多いと思います。

「チームの動きがなかなかうまくいかない」「あの人が変えられない」「自分のやり方が間違っている」などと悩んでいる方もいるのではないでしょうか。

そんな時は、一呼吸おいて「チーム」や「他者」ではなく「自分の内面」に目を向けてみましょう。

本セッションでは、チームではなく個人、他者ではなく自分に着目して「自分が変わることで、チームが変わる」という可能性を探ります。

登壇者は、2000年から、XP、スクラムをはじめとする様々なソフトウェア開発、アジャイルの手法・思想・価値体系、パタン・ランゲージやネイチャーオブオーダーなどの周辺の思想も含めて探求してきました。そして現在着目しているのが「個人の変容」です。

Kent Beckは以前、来日した時に「Social change starts with you.」と言う言葉を残しています。本セッションでは「自分が変わる」ということはどういうことなのかをワークを通じて探求していきます。

まず最初に、IKIGAIマップによって自分の今を客観視してみます。IKIGAIマップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

その後、「マルチポ・テンシャライト」という「器用貧乏」を肯定的に捉える考え方をご紹介した後に、自分の内面に目を向けるワークをおこないます。

最後に、「ザ・メンタルモデル」をヒントにして、自身の無意識の振る舞いがどのような現実を作っているのかを見つめます。

自分を内観することで、どのように認知が変わるでしょうか？「そこにあるものを、ある」と認めることで何が変わるでしょうか？

そして、結果として自分の周囲がどう変化するのでしょうか？

様々な手法や考え方を紹介しながら、他者ではなく自分を見つめ、チームが変わるのではなく、自分が変わることで世界が変わるという意味とはどういうことかを一緒に探求しましょう。

Intro

　現代社会学の本を読むと、ある言葉をよく目にします。それは「機能主義」という言葉です。これは、各役割を担当する人の集合体として社会を理解するというもので、生き残るために細胞が進化を重ねるように、社会も僕たち人間が状況に合わせて絶え間なく仕組みを変えていくという概念です。

スクラムも同じ観点で理解することができます。人の集まりであるスクラムチームがどれだけアジャイルに時代のニーズに対応できるかで集団の運命が左右されます。僕はここでスクラムの成功の鍵として、スプリントの期間に注目したいと思います。

スプリントの期間は絶対的なものではありません。よくプロダクトを子どもに例えることがありますが、まさに年齢によって子どものしつけを変えるのと同様に、状況によって常に見直しされるべきものがスプリントの期間です。

このセッションでは、最適なスプリントの期間を探すために考慮すべき要素は何か、どういう時に期間の見直しをしないといけないかなどの考察を行います。

時間の経過により変化し続ける条件のコントロールに対し、スプリントの期間がどれだけ重要なものか。

この２０分間の考察で成功の鍵を見つけられるように、みんなで一緒に頑張りましょう。

このセッションでは，大学のPBL（Project Based Learning）でリーダーのいない組織を形成し，その活動の中でどのようにチームが成長してきたかをお伝えします．

いま，日本の大学ではPBLという学習方法が広く実施されています．PBLとは，実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって，チーム開発やチームマネジメントの手法について学ぶことができる学習手法です．私が所属する大学でもPBLのカリキュラムがあり，スクラムを用いてプロダクトを作るという経験を得ました．しかし，私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました．そして，その結果として，とても良いチームを形成できたと感じています．

リーダーもいなく，開発初心者が集まるプロジェクトで，どのようなことに苦労したか紹介・分析し，そのうえでチームをより良くするためにはどうすればいいかお話ししていきます．

達人たちが見ている世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界を覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び！

旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます！

★旅するAgile本箱LT2021：発表順(予定)

1. 前説:旅するAgile本箱って?
2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
4. 鳥井 雪さん 　「ダイバシティな絵本」のご紹介(順不同)
   『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる　とびきりおいしいデザート』
5. 吉羽 龍太郎さん「エンジニア的翻訳術」
6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
7. 佐藤 竜也さん『達人プログラマー 第2版』
8. 島田 浩二さん『ユニコーン企業のひみつ』
9. 結び

●ハッカーライフラボスタッフ
・司会：コサカ ジュンキ
・配信：アジャイル札幌のみなさん

私がスクラムマスターになって１年半が経ち、

この間にチームはランダムペアプロを導入し、実践してきました。

個人によるタスク実施では様々な問題が生じます。

個人依存による待ち時間の発生、引き継ぎのコストの増加など。

そこから「ランダムにペアを作り、タスクを割り当てる」というランダムペアプロを、

どの様に導入したのか、

どの様な効果があったのか、

その時スクラムマスターとして私は何をしたのか、

ということを発表いたします。

ペアプロを検討されている方だけでなく、チームの改善にあたって困られている方のヒントになれば幸いです。

クラスメソッド株式会社では、ベトナムの事業会社と共にクライアントワーク（受託）を行うことも多く、その中でもスクラムで開発することも多いです。

弊社ではオフショア×スクラムを『モダンオフショア』と称して推進しており、そんなモダンオフショアのリアルな現場を、それぞれ別の案件に携わる3名のスクラムマスターとパートナーであるベトナムのオフショア事業会社から2名（予定）でお話していきます。

本セッションではパネルディスカッション形式でお題に沿ってお送りします。
現場の明るい部分だけではなく、暗い部分、成功から失敗まで忖度なく語っていきますのでご期待ください。

時間の都合上、セッション中に質問回答時間を用意することが出来ませんでしたので、ぜひ質問・感想等あればDiscord上でお願い致します！

モダンオフショア/ クライアントワーク（受託）/ オフショア/ 海外/ スクラム開発 etc...
何かひとつでも気になるワードがありましたら、ぜひご観覧くださいませ。

私は大学教員として工学部の学生さんにシステム設計やプロジェクトマネジメントを指導しています。また、共同創業者としてジョインしている会社でもシステム設計の人材育成サービスを扱っており、新入社員やビギナーエンジニアを対象にすることもあります。

学生さんやビギナーエンジニアさんを対象にしてシステム設計を教える場面でよく困るのは「設計やマネジメントの重要性が分からず、様々な方法論やフレームワークを伝えてもピンとこない」ということです。これはよく考えればあたり前のことです。学生さんやビギナーエンジニアさんたちはシステム開発の経験がない（もしくは少ない）ので、開発の全体像や重要なところ・失敗しやすいところ・よくある課題などを知らないのです。そのような状態で方法論やフレームワークを伝えようとしても「なぜそのような方法が良いのか？」や「なぜそんな考え方をするのか？」ということが腑に落ちないため、教える方も教えない方も苦労します。

そのような問題を解決する最も直接的な方法は、経験を積ませるということです。特に失敗経験を経ることで、設計やマネジメントの重要さに目が向いて、学ぶ準備が整います。しかし、大学の授業などの限られた機会の中では失敗経験を経るだけの時間的な余裕がありません。企業における人材育成においても、一昔前のようにたっぷりと時間をかけてOJTで学んでいくという余裕がある場合は少なくなっており、激しい競争環境の中で素早い人材育成が求められています。

そこで私達は、システム開発を疑似体験することのできるボードゲーム「ペジテの自転車」を開発しました。このゲームで上記の「経験しないと分からない。失敗しないと分からない。」という問題を全て解決できるわけではありませんが、導入教材としてうまく活用することで、効果的な教育プログラムを構築＆実践することができたと思っています。

「ペジテの自転車」のプレイヤーは、架空の自転車メーカーの新製品開発を担当するチームメンバーになりきって、顧客満足度の高い自転車製品を設計することを目指します。ゲームが進行する中でプレイヤーたちは、顕在化しない隠れた要求があったり、途中で要求が変更されたり、リソースが足りなくなって困ったり、ビジネス環境が変化したり、異なる立場の意見が対立したり・・・と様々な「システム開発あるある」を体験します。そしてゲーム後のディブリーフィング（振り返り）を通して「システム開発において重要なことは何か？難しいことは何か？」を体感的に学ぶことができます。

ボードゲーム「ペジテの自転車」の外観

学生たちがプレイする様子

今回の発表では「ペジテの自転車」のコンセプトやルール、実践結果などをお伝えします。

スクラムマスターの役割で動いていると、さまざまなところで言葉を利用したアクションが必要となります。

スクラムマスターのみなさんは、とてもたくさん勉強をして、色々と新しい発見をして、それをチームに伝えたい！そんな思いやりのある方ばかりですよね。

しかしながら、「伝え方が悪くて伝わらない」「うまく伝えられない」という気持ちになったことも一度や二度ではないはずです。

このセッションでは、言葉は伝える（アウトプット）だけではなく、伝わった（アウトカム）を大切にしていくことが大切だという気づきを得た経験から、言葉のアウトカムを最大化するための方法を紹介して、皆さんの言葉の力を引き出せることを目指しています。

チームのスクラムマスターとしての経験だけではなく、Podcastのパーソナリティとしての経験やカンファレンス運営の経験など、様々な角度から言葉のアウトカムについて考えてきた経験を基にお話をさせていただきます。

言葉のアウトカムを高めるために必要なのは、ふりかえりです。

自分の発言した言葉をふりかえることはできていますか？

仮説を立てて、発言をして、ふりかえって、カイゼンするといったサイクルを日々考えることができていますか？

実際に私が行っているふりかえりの方法や、簡単にできる言葉のふりかえり方法の紹介を通して、皆さんがこれから話す言葉の一つ一つを大切にできるようになります。

さらに、言葉のアウトカムを高める意識が高くなっていくと、問いのスキルも向上します。スクラムマスターにとって大切な問いのスキル

効果的な問いをチームに投げかけることで様々なことを引き出すことができると皆さんは感じていると思います。しかり、それを実践することはとても難しいことです。

効果的な問いをするためにはどうすれば良いのか？どのように訓練をすれば効果的な問いを生み出すことができるのかをお話しします。