When you think of Scrum, you probably imagine its use in software development. I often hear these voices in many Japanese communities. However, my image is a little different.

あなたのScrumといえば、ソフトウェア開発での活用をイメージするでしょう。多くの日本のコミュニティで、こうした声をよく聞きます。しかし、私のイメージは、少し異なります。

This time, key staff members, especially Matsuura-san who made an enthusiastic love call to me, asked me to talk about examples and methods of utilization outside of software development.

今回は主要なスタッフ、特に熱烈なラブコールされた松浦さんから「ソフトウェア開発以外での活用事例、活用方法を話して欲しい」との要望を受けました。

In response to these requests, this session may change the image of Scrum a little, from examples of its use in projects other than software development and how it is used.

こうした要望を受け、本セッションでは、ソフトウェア開発以外のプロジェクトでの活用事例、活用方法から、少し Scrum のイメージが変わるかもしれません。

アジャイル開発の解説はたくさんあるので、逆に、アジャイル開発になれない方法をざっくり紹介します。
成功する方法を見つけるのは難しいけど、失敗する方法を知るのは簡単だったり。

ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

心理的安全性という言葉、皆様は聞いたことありますか？

心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う？」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ！」という声が帰ってくると思います。

しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか？心理的安全性という言葉がキャッチー（かつ、流行っている）こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

開催年月 開催地 チャンピオン
2022年6月 大阪 yattom
2022年5月 新潟 yattom
2022年1月 お茶の水 yattom

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
その他のドライバーにはこれから声をかけます。
出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します！

今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました！！！

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
https://forms.gle/oFih3o1mk6P8gTGK8

毎日ふりかえりをして、毎週ふりかえりをして、自分たちのこと、チームのこと、プロダクトのことに向き合い続ける。

毎回１つとて同じふりかえりはなく、その場に合わせて新しいふりかえりが自然発生し、チームによって生み出されていく。

そういったふりかえりを全力で行い、プロダクトを全身全霊で作るうちに、ふりかえりが日常に溶けていく。

そんなチームが出来上がるまでの2年間をふりかえると、ふりかえりだけでない、いろんな要素が絡み合っていました。

• ふりかえりを楽しむということ。
• チームの文化を作り続けるということ。
• ひとりひとりのオーナーシップ。
• メンバーそれぞれの価値観の共有。
• みんなが大切にしている想い。
• ゴールをともに作り上げ共有すること。

このセッションでは、ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素をお伝えします。

マネする必要は全くありませんが、少しでもふりかえりを身近に感じられたり、ふりかえりの周辺にある何かを感じ取っていただけたら嬉しいです。

J. Richard Hackman著の書籍Leading Teamsによると「安定したチームほど良いパフォーマンスを発揮する」とあります。

まったく異論はありません。

ただ、嬉しくもあり、残念でもあるのですが、チームでの活動がうまくいった結果、プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。

そうすると、いつまでも安定したチームで居続けられなくなるのもまた事実です。

安定したチームがよいパフォーマンスを発揮するとはわかっていても、なかなか許してもらえない。

そんな状況を受け身になげくのではなく、それを受け入れ、不確実な状況に適応するために、積極的にチームや組織をダイナミックにリチーミングすることはできないでしょうか？

 Heidi Helfand 著の書籍Dynamic Reteamingより、チームをダイナミックにリチーミングするための５つの方法を、実際に現場でチームと関わるなかででてきた事例とともにご紹介します。

もうリチーミングは、怖くない！

• 今日は本を読むぞと決めたけど、結局ゲームをやってしまった

• 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

• 貯金をしたいのに、欲しいものがあると思わず買ってしまう

このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか？私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

みなさん、こんにちは！

アジャイルコーチの清水弘毅です！
日本在住だとおそらく３人ほどしかいない、CTC認定をスクラムアライアンスから受けています！

本セッションでは、スクラムマスターやアジャイルコーチの方の、必要なスキルの探求をしていきます。

私自身がどんな場面に遭遇し、どのように考え、どのような道を辿ってきたかお伝えしますので、スクラムマスターを極めたいと考えている方たちの一助になれば幸いです。

CSM, A-CSM, CSP-SM, CTC, CECで求められるコンピテンシーに照らし合わせながらお話する予定です。

スクラムマスターを極めたい方は集まってください！

私は筑波大学の情報系の学生です。３年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。

３年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。

そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。

当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ（コーラス：haradakiro）でお送りします。
いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

前回のプロダクトバックログ（https://slide.meguro.ryuzee.com/slides/107）に引き続き、今回はスプリントプランニングのすべてを完全解説!!

スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

• (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
• (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
• (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
• (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
• (e) スプリントプランニングの前に、先にタスクに分解しておく

もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば（SCRUM BOOT CAMP THE BOOKも是非読んでみてください）、陥りがちな罠は避けられます。

本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

なお、望ましくないものは、(c)以外のすべてです。

スクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。

そういった方々に向けて、誰しも親しみのある「料理」を題材に、完成の定義（Definition of Done）の理解を助けるワークショップを作りました。

スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう！

※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。→ 直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。

すべてがフィードバック、なんでもフィードバック - Feedback is Life

フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない！と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

• すべてがフィードバック、なんでもフィードバック。
• テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
• フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
• フィードバックでは自分自身を大事にすることが大切です。
• フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
• 「フィードバックください！」とよく言ったり言われたりしますが、実は……

みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

ぜひ、楽しい時間を皆さんと分かち合いましょう！

Metrics on employee happiness, theoretical value, and work not done are just plain dumb. I will reveal the metrics that you need. That mean something. And that get results. Join us as we discover THE BEST AGILE METRICS!

あなたのチームのインセプションデッキは役に立ってますか？

インセプションデッキは、書籍「アジャイルサムライ」の中で紹介されたツールです。

"プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキ"

インセプションデッキは10個の質問で構成されていて、質問に答えていくことでプロジェクト開始前に確認しておくべきことが明らかになるツールです。これだけ聞くと簡単そうに聞こえますが、実際に現場でインセプションデッキを作成して活用するまでにはさまざまなお悩みポイントにぶつかります。

「デッキ作成にどれくらい時間を確保すればよいの？」  
「デッキ作成するときは具体的にどう進めたらよいの？」  
「デッキを作ったのはいいけれどそのあとどうしたらいいの？」

本セッションでは、インセプションデッキの紹介からこれらの現場で実践する際のお悩みポイントを解決する方法までお話します。

また、インセプションデッキは作成したデッキ以上にチームの関係性をつくることに価値があります。ただデッキを作成するだけでなく、チームの関係性をつくるためのインセプションデッキについてお話してみます。

"You better bring it!

Oh, it's already been broughten!"

The purpose of cheerleading is to support and encourage their team to achieve peak performance - they give the team the extra oomph to carry them over the goal line! The cheerleaders not only support and celebrate the wins, they also encourage the team when they need to push through their trials and tribulations. Cheerleaders build the hype of the team fans by creating infectious energy, just imagine your stakeholders hyped up because of your awesome team!

In this session we will take lessons from professional cheerleading and apply them in an agile team context.

We will cover the 3 pillars of agile cheerleading - chants, dances, and symbols and explore the fundamentals and benefits of an agile cheer so that you can super-charge your teams.

BE! AGILE! BE! BE AGILE!

振り返りはどんな頻度で、どのように実施されていますか？

私のチーム（複数プロダクトを持つ部署内のQAチーム）では、以下の課題がありました。

• チームメイトはそれぞれの担当領域があり、業務上関わりが少ない。
• さらにフルリモート化ということで、そもそも話す機会も少ない。

そんな時、チームメイトが「月次で振り返り会をやりませんか？」と提案してくれました。

この会がとっても楽しいので、他の方にもぜひ知っていただきたいと思い、体験コーナーをご用意します。

「初対面の人たちが集まってうまくいくのか？」ですって？ご心配なく！

• 業務上関わりが少ない
• 話す機会も少ない

という中で運用を開始しています。まさに、セッションに参加する私たちと似た状況ですね。

ワークショップを通して、スクラムイベント外での振り返りのメリットを実感していただくことを目指します。

そのまま自チームで実施してみるのもよし、カスタマイズして行うのもよし。チーム内外との相互理解、コミュニケーション強化のためのアクションのきっかけになる、チャッカマンのようなセッションを目指します！

This session is a twinkle in my eye! I have drafted an outline but haven't completed it yet, so it is very much a work in process. I usually write the abstract last, so this is a change for me. Essentially it's about how an agile coach needs to practice the fine art of ZFG. This session is mostly about the "why". For example, I review how fear is the "mind killer" and how fear prevents many coaches from speaking truth to power. As another example, I review "clean bias" and how a coach should not only be explicit about bias, but also also understand what their biases are so that they can provide objective feedback. In contrast, I also cover how ZFG does not mean "I don't care" and I distinguish between the two. My goal in this session is to help coaches understand the philosophy of ZFG and how it is a critical skill to embrace in order to be a truly effective agile coach.

スウォーミングとは、ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。私が所属しているスクラムチームでは、最も優先順位が高いタスクを最速で完了させることを目的にスウォーミングを実施しています。

スウォーミングの手段の1つにモブプログラミングがあります。私たちのチームも結成当初は、フロー効率最大化のためモブプログラミングで1つのタスクに群がっていました。しかし、開発が進みタスクの不確実性が下がってくると、開発メンバーは「フロー効率重視の開発スタイルを維持したままリソース効率を高めていきたい」と考えるようになりました。

そこで、Swarming: One-Piece Continuous Flow** のキャプテンの仕組みを参考に、ソロプログラミングを主とした開発でもフロー効率が下がらない方法を編み出し、チームに適用しました。私たちはこの仕組みをキャプテン制度と名付けて運用しています。

本セッションでは、スクラムチームで実践しているスウォーミングの紹介、キャプテン制度の策定の背景、得られた効果についてお話ししたいと思います。また、私自身スクラムマスターとエンジニアを兼務している立場であるため、スクラムマスター、エンジニアそれぞれの立場で、キャプテン制度を運用してみた所感についても共有させていただきたいと思います。

多くの書籍やサイトで、アジャイル開発やスクラムは不確実性が高い領域へのアプローチとして有効だとされています。
例えば、More Effective Agileでは以下のように言及されています。

> プロジェクトに関して不確実性が高ければ高いほど、煩雑系（シーケンシャル）のアプローチよりも複雑系（アジャイル）のアプローチのほうが有利になる。
「More Effective Agile “ソフトウェアリーダー”になるための28の道標」 Steve McConnell

しかし、不確実性という単語にはマイナスイメージが強いためか、不確実性との付き合い方に失敗してしまう場面も見受けられます。自分が見たり経験してきた具体的なものだと、以下のような場面が挙げられます。

• 不確実性は減らせば減らすほど良いものだと解釈してしまい、なかなかはじめの一歩が踏み出せなくなってしまう
• 制御可能な事象や一方的な要求が不確実性という言葉で包まれてしまう
• 「不確実性が高い領域だったので失敗したのは仕方がない」と、うまくいかなかった理由として短絡的に結びつけられてしまう

本セッションでは、金融領域や数学の領域を中心に据えながら、様々な視点から不確実性とは何かを探っていくことで、不確実性という言葉に対する理解を深めると共に、不確実性とはどのように付き合っていくことができるのかや、不確実性をどのように活用していくと良いのか...を考えていきます。
具体的には、以下のような視点が登場する予定です。

• モンテカルロシュミレーション(金融領域で意図的に入れ込む不確実性)
• マクロ経済学
• カオス理論

スクラムを実践していくにあたって、不確実性をどのように捉え、どのように不確実性に向かい合っていくのかを考える一助になれば幸いです。