☆クラファンはじまりました☆

☆https://greenfunding.jp/thousandsofbooks/projects/6857☆

皆さんは、よく研修を受けられていますよね？

退屈な研修とそうじゃない研修の違いは何ですか？？

皆さんは、これまで学校に通っていた方がほとんどだと思います。

授業って面白かったですか？退屈でしたか？

退屈な授業とそうじゃない授業の違いは何ですか？？

このワークショップでは、これからクラウドファンディングで出版予定である、Training from the back of the Room!　のエッセンスを凝縮させて、参加者の皆様に「真の学びとは何か」「そのために講師・教師はどうあるべきか」を体験して頂きます。

実はこれ「教えない教え方」なんです。とっても興味が湧きますよね〜。もし興味が湧いた方は是非ご参加ください！

スクラムマスターの重要なスキルとして、『ティーチング』がありますよね。このティーチングを高めるためにも必要な考え方になります。

今回、Reginal Scrum Gathering Tokyoなので、「スクラム」を参加者の皆様で学びましょう！

スクラム初心者の方でも安心してご参加いただけます。スクラム熟達者の方も「教えない教え方」を学ぶことができます。

また、スクラムマスターの方に向けては、スクラムイベント・アクティビティでの応用の仕方も少し触れようと思います（ワークショップ後ご希望の方へ）。

もう『スクラムイベントが退屈だ』なんて言う人はいなくなりそうです！

In September 2021, I was certified as a Certified Team Coach by the Scrum Alliance.

I've heard that there are still very few Certified Team Coaches in Japan, so I'm sure many of you may be interested.

I will introduce the path I took to become a Certified Team Coach in this session.

If you just listen to a talk, your brain will forget most of it.

This session will be in the form of a workshop to create a relationship among the participants and to help them learn and take action.

The application for the CTC is structured in a way that strongly encourages self-reflection. My path to the CTC is the result of exploring the skills needed to be a ScrumMaster, seeking out opportunities, practicing, reflecting, and exploring again. This is just my path. I am sure that each participant has his or her own path. I would like to conduct a workshop where participants can think about the skills needed to be a Scrum Master and how to develop them to the guide level, and lay out their own path.

2021年9月に Scrum Allianceの Certified Team Coachに認定されました。

日本ではまだ少ないと聞いていますので、ご興味がある方も多いのではないでしょうか。

本講演では、私がCertified Team Coachに認定されるまでに、どのような道のりを歩んできたのかをご紹介します。

ただ話を聞くだけだと、人の脳はほとんどのことを忘れてしまいます。

本講演はワークショップ形式にし、参加者同士の関係性を創り、参加者ご自身の学びと行動に繋げられればと考えております。

CTC取得のアプリケーションは、自身の内省を強く促す構成になっています。私がCTCを取得した道のりは、スクラムマスターに必要なスキルを探求し、場を求め、実践し、ふりかえり、また探求し、を繰り返した結果になります。これはあくまで私の道です。参加者の皆様にはそれぞれの道があると思います。スクラムマスターに必要なスキルと、それをガイドレベルまでどのように伸ばすのかを、参加者の皆様で考え、ご自身でご自身の道を敷いていくようなワークショップを実施できればと考えております。

スクラムのセレモニー（イベント）が長い、退屈だ、誰か一人だけ話している、お通夜・・・
なんてことありませんか？

学習熱心なスクラムマスターに相談しましょう！
・・・でもスクラムマスターも困っています。

スクラムのセレモニーを効率的に効果的に楽しく、みんなの学習効果を最大化できる方法なんてどこにも載ってないんです！

そこで、Six trumpsをご紹介します。

この原則を元にスクラムのセレモニーのみならず、ワークショップ、カンファレンス、エグゼクティブミーティング、全社会議、株主総会、国会審議をアレンジしてみてください！！
ものすごい良いミーティングになると思います！
人が集まるところにおいて、人と人との関係性、学習効果を高めるために、すべてに応用できます！

このワークショップは、
Six trumpsの概要をお伝えし、スクラムのセレモニーにどのように応用するかを参加者同士深くディスカッションする形式
となります。

加えて、清水自身がScrumにSix Trumpsをどのように適応しているかお伝えします！

みなさん、スプリント期間ってどうやって決めてるんですか？なんとなく決めてませんか？

なんとなくでも、きっと開発チームの頭のなかにある”これまでの経験”によってひねり出された期間がスプリント期間になっているんじゃないですか？

スプリントが終わったら”潜在的に出荷可能なもの”ができるんですよね？すぐリリースしてください！

え？リリースできない？あくまで”潜在的に”って言ったじゃない。あとこれとそれとこれとそれをやらなくちゃいけない、あと１ヶ月かかるんだって。

うちの会社はしがらみが多いから・・・とか。

プロダクトオーナーと開発チームがDefinition of Doneを共有していないとこんなことになります。

Definition of Doneは、単なる、「タスクを終わらせるときのチーム内の合意事項」ではありません。

プロダクトを「リリースして、顧客に届く」までのバリューストリームを示し、そこまでに必要な作業と基準をすべてを洗い出します。

作業と基準をすべて洗い出して、はじめて、

• 「潜在的に出荷可能なインクリメント」がどのくらいの期間で作れるのか
• このプロダクトにスクラムは適用可能なのか
• スプリント期間が終わってから顧客に届くまでに何をやらなくてはいけないのか、どれくらいの期間がかかるのか

が明確になりますし、スクラムをはじめる前に明確にしておく必要があります。もちろんその後も継続的にリファインメントされる必要があります。

これがDefinition of Doneです。

このセッションでは、忘れられがち（と勝手に私が思い込んでるだけかも知れませんが）なDefinition of Doneの重要性と作り方、維持管理の方法を

みなさんと考えていきたいと思います。

とくに規制（FDA、ISO*****等）があるプロダクトや昔ながらのルールのある企業において、スクラムを適用する際には、Definition of Doneを決めることが非常に効果的だと確信しています。

私たちGROOVE Xは家庭用ロボットの開発を進めています。

この開発は非常に領域が広く、関わる人数も多く、100名を超えています。

• ハードウェア（メカ/エレキ/ファーム)
• ソフトウェア(OS/機械学習/クラウド)
• アプリケーション(振る舞い/アプリ/サイト)
• マーケティング
• コーポレート

などのチームがありますが、私たちは全社的にスクラムを推進しています。

チーム数は15を超えており、大規模スクラムの手法の一つである、LeSS(Large Scale Scrum)を活用しています。

また、組織構造はフラットを維持しており、CEO以外は役職はありません。フラット組織特有のメリット・デメリットも交えてご紹介できたらと思います。

本セッションでは、LeSSを活用する上での注意点や工夫点、難しい点、LeSS Hugeへ向かい、さらにスケールするにはどうすればよいかという今後の展望を皆様とシェアさせていただきます。

※LeSS HugeはLeSSをさらに大規模にする手法。

今後スクラムで大規模開発・スクラムのスケーリング・組織のスケーリングをする上での一助になればと思っています。

私はスクラムマスター（兼アーキテクト）として、4+1チーム同時に見ています。

私自身の効率が良くないことにも依存していると思いますが、やはり限界があることを思い知りました。

※4チームは通常のスクラムチームで、1チームは横断的なチームなので、4+1と表現しました。

本セッションでは、そんな私の辛い？体験記を皆様と共有でき、今後スクラムを始める方や、LeSS(Large Scale Scrum)、Nexus等の中～大規模スクラムを実践される方の参考になれば幸いと思います。

スクラムを行いながら、その上で品質をさらに高めるにはどうすればいいかを考え、実践しています。

システムを取り巻く環境

• 非医療系ではあるものの、医療現場であるお客様先へ導入する、クローズドなシステム（インターネットにつながっていない）
• こまめなリリースができない環境なので、品質は極めて重要な位置づけ
• ユーザはとても忙しいので、ユーザニーズが非常に掴みづらい
• ユーザのシステム運用は施設ごとにまちまち
• 他社システムや、機器との連携がある複雑なシステムである
• 医療機器開発を前提としたプロセス・ウォーターフォール文化

 上記のような環境において、スクラムを導入し、チーム力を向上し、品質をさらに高めるための工夫をしています。

• 医療機器開発を前提としたプロセス・ウォーターフォール文化にスクラムを導入
• スクラムを実践して、品質は上がったか
• ウォーターフォールとアジャイルではどちらが品質を高めることができるのか
• 人間性（Humanity）！より楽しく仕事をするために！
• 複数チームで保守と新規機能開発！～LチームとFチームにヒントを得て～
• 大規模KANBANで、組織をよりアジャイルに

Scrum + XPや、堅牢化スプリント等、アジャイルな品質指標（メトリクス）考案等、試行錯誤のケーススタディです。