みなさんのチームのスプリントレビューは機能していますか？

スプリントレビューは、スクラムの中でも特に勘違いされやすいイベントの中の一つです。
「レビュー」という単語に引っ張られ、POへプロダクトバックログの受け入れをする場にしてしまったり、ステークホルダ―に進捗報告をする場になってしまったり…。

RSGT2023で講演された「スプリントレビュー Deep Dive」でも、各種のアンチパターンが公開されるとともに、スクラムに悩める人たちに衝撃を与えたのは記憶に新しいですね（読んでない人は是非読みましょう）。

スプリントレビューの形は千差万別。
ただし、どのスプリントレビューも、チームの生み出す「価値」をさらに高めたり、「未来」を共に創りあげるものであると私は信じています。

このセッションでは「こんなスプリントレビューもあるんだ！」「面白そう！やってみたい！」と思えるような実践の姿をお伝えします。

「自分たちでデモをしない」スプリントレビュー

じゃあ誰がデモをするかって？
チーム以外の、その場に来てくれた人がデモをするんです。

私たちのチームは、ソフトウェア開発のみを行っているチームではありません。
事業企画、マーケティング、ブランディング、営業、契約、設計、開発、リリース、運用。プロダクトに関わるあらゆることをチーム全員で行っています。
その活動に関わってきた色々な人たちに、スプリントレビューに来ていただいています。そして、こう言います。

『ようこそ私たちのスプリントレビューへ！この時間は、皆さんと一緒にプロダクトの明るい未来を考えたいと思います。私たちのプロダクトを是非自慢させてください！いえ、むしろ、みなさんに自慢してほしいんです！是非、楽しんでご参加下さい！』

「毎週必ず価値を届ける」とチームで誓いを立ててから2年半、欠かさず価値を届け続けてきたチームが行っているスプリントレビューを皆さんに紹介します。

このセッションを聞けば、スプリントレビューに悩むみなさんの固定概念を打ち崩し、新たな道を開くきっかけになることでしょう。

※このセッションは、2022でお話しした「ビジネス x テスト。ビジネスのいろんな場所で活きる、アジャイルとテストのエッセンス」の続編です。是非こちらから過去のスライド（Miro）をご参照ください。

※実際にこの場にチームのステークホルダーを召喚出来たらいいなと考えています

※スクラムガイドの提示するスプリントレビューからはイメージが異なる場合があります。あくまでそういう姿もあるんだ、という風にとらえていただければ幸いです

組織変革を試みると様々な壁にぶつかる

より良いソフトウェア開発のため、より楽しく仕事をするためにと情熱を持って組織変革を試みると、様々な壁にぶつかることは少なくないと思います。

人と人とが関わる中で異なる意見に出会うことは避けられません。なんでわかってくれないんだろうかとしんどくなります。同じように悩んでいる人にもよく出会います。

アドバイスをもらうも理解しきれなかった

一方で、まるでしんどくないかのように活動し続けているように見える人もいます。苦しい場面に出会わないのでしょうか、彼らは超人だから壁にぶつかっても、ものともしないのでしょうか。

相談してみるとそんなことはないようで、コミュニティで色々なアドバイスをもらい、それらをまとめて発表させてもらう機会もありました。

しかし彼らのアドバイスだけでは、まだ自分のしんどさは解消しきれませんでした。

「他人を変えることはできない、変えられるのは自分だけ」

と聞いても、それは自分の夢や理想を諦め、情熱を捨て我慢するということなのかと悩んでいました。当時の自分は、彼らの言葉を表面的に捉えることしか出来ていませんでした。

アドバイスをどのように理解することができたか

そんな中

• 「誰もが正しい、ただし部分的には」（『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意 メタスキル、学習、心理、リーダーシップ』）

というアジャイルの基本姿勢、対話の考え方に出会い、さらにその具体的な方法として

• 「表現の奥に隠れているニーズを理解する」（『NVC 人と人との関係にいのちを吹き込む法』）
• 「想定や関係情報を揃える」（『ファシリテーター完全教本: 最強のプロが教える理論・技術・実践のすべて』）

にも出会い、相互理解を目指す対話主体のコミュニケーションで心の負担を軽減できることに気づきました。

以前コミュニティでもらっていたアドバイスを見返すと、その裏のロジックを理解することが出来ました。

そしてここにマインドフルネスを組み合わせると効果が高まることにも気づきました。

対話を心がけていても、意見の異なる相手の言動によってはついついファイティングポーズをとってしまう瞬間もあります。少しでもその拳を上げずにおくために、心の情動を抑え対話を続けるためにマインドフルネスが役立つのです。

情熱を持って組織変革を試みる人はとても貴重です。

そんな人が心の負担で押しつぶされないために、自分の情熱を諦めるのではなく、異なる意見と対面した時の捉え方、コミュニケーション方法を変えることで心の負担を軽減できた例をお話ししたいと思います。

アジャイル業界でもコーチングや関係性に着目するシステムコーチングが近年大事だと語られるようになってきました。アジャイル業界に関わらず、ここ数年で1on1ミーティングが実施される企業も増えており、職場の研修などでも「聴く」ということが大切だという話をよく聞くようになったかなと思います。

でも実際、「聴く」というのは難しいものです。

私自身、1on1を専業としてある意味「聴く」ことを仕事にしていますが（組織コンサルタントでもありますが）深めていくほどに「聴く」ことを理解して実行しているようで、まだまだだと身にしみることが多いものです。

コーチングやカウンセリングを実践する人たちは聴く技術を訓練した人であり、会社の外部からアプローチをするケースが多いからこそできるものがあります。

しかしながら社内で行う場合は多重関係（関係性で色々ある、上司部下など）であり、そもそも聴く体験をしたことがない人が行うので、より難易度が高いのです。

けれども「聴くこと」で社内にいるからこそできるアプローチがたくさんあります。

今回はそもそも「聴く」とはどういうことなのか、なぜ難しいのかにフォーカスしてお話したいと思います。

理論的な話もしますが、私自身が普段感じること、経験も含めてお話できたらと思います。

このセッションを通して、そもそも「聴く」ことは難しいことであるから、はじめからうまくできなくて大丈夫だという安心を渡せたらと思うとともに

「聴く」ことが我慢するなどしんどいイメージから、自分にとってメリットがあると感じてもらえる機会になったら幸いです。

一緒に「聴く」ということを考えていくセッションになれたら嬉しいです。

要件定義してますか？テストの洗い出しできてますか？テスターはアジャイルテスターとしてプロダクトバックログ作成時点で入りこめてますか？

本セッションではプロダクトオーナーのバイブルの一つ『ユーザーストーリーマッピング』について解説してみます。日本語版出版からもう8年ほどたっているので、後続のプロダクトマネジメント書籍も出てきていて、知らない方もいらっしゃいそうなので、アジャイルでプロダクトと言えばこの本、というところを紹介していきたいと思います。

また、2009年出版の実践アジャイルテストでも、アジャイルテスターはプロダクトオーナーに助言を与えていくべきというモデルが提案されていますので、そうした話もできればなと思っています！

コミュニケーション、チームビルディング、チーム運営などを学び始まると人と人との関係性にまつわる様々なテクニックが出てきます。その中には、
- やってみて素晴らしい効果がでるもの
- やっても全然効果がでないもの
- 効果は出たけど別のヤバイ問題がでてくるもの
- 胡散臭くてやってみる気にもならないもの
などがあります。
神経言語プログラミングを学び、職場、TOCfE Bootcamp、リーダー塾といったコミュニティで経験・観測した、誤解や誤用とそれに対する回答について好きに話します。

2021年にXP祭で阿鼻叫喚となった発表に、新に誤解や誤用の危険を感じたものを加え、よりマイルドかつ切れ味鋭く再構成しました。

皆さん、ふりかえりしてますか？

KPTとか、YWTとか、Fan/Done/Learnとか、手法は色々あって迷いますよね。
でも、ふりかえりを始める前にDPA(Design the Partnership Alliance)をやっている現場って、まだまだ少数派なのではないでしょうか？
私もふりかえりはいくつもの現場でやってきて、何十回とふりかえりはしてきたのですが、DPAを実際にやってみたのは最近だったりします。

DPA(Design the Partnership Alliance)とは、ふりかえりのための「場作り」や「雰囲気作り」のための手法です。
KPTやYWTといったふりかえりの本題に入る前にDPAで場作り・雰囲気作りをしておくことで、ふりかえりの本題での意見交換が活発になり、より効果的なふりかえりになることが狙いです。
詳しいことは黄色いびばさんがQiitaに紹介記事を書いてくれているので、そちらが参考になりますね。

このセッションでは、実際にふりかえりの前にDPAを行った事例を紹介しようと思います。

スクラムフレームワークに沿って、スクラムイベントの一つとしてふりかえりをKPTやYWTで行っているケースは多いと思います。しかし、なかなか意見が出てこないために冷めた雰囲気になってしまう、もしくは意見が対立して険悪な雰囲気になってしまうことは無いでしょうか？

せっかくのふりかえりの時間がそのような望ましくない状況になってしまう前に、意見を言いやすい場・意見を言っても大丈夫な場であるということを認知してもらう、そして安心してもらうことが大切です。
そのような場づくりに役立つツールがDPA(Design the Partnership Alliance)なのです。

DPAの実施前と実施後でどのようなメンバーの行動の変化があったのか、そしてDPAを実施したことでその後のふりかえりの本題にどのような影響があったのかをご紹介します。

昨日まで一緒に頑張っていた仲間がいて
ある日突然、バランスを失ってしまったこと、ありませんか？

組織で誰かを
信用できなくなったり
尊敬できなくなったり
頼れなくなったり

そんな時、あなたはどうしますか？

誰かに相談、したいですか？

本当の声は、第三者や相談窓口には聞こえてきません。
組織内に受け取れる場所がなければ、悲劇は突然訪れるだけです。

組織がこんなギリギリの状態にならない方が良いのは間違いありません。
一方で、瀬谷さんのお話は身近なところでも起きてしまっていると感じてもいます。

このセッションでは、
自分の辛かった体験をベースに
機械的ではない組織の作り方についてお話します。

過去、SIer時代に「アジャイルって品質悪いんでしょ？」って言われてカッとなって作った資料を元にブラッシュアップして発表したいです。
基本的な内容はスライド欄にその当時発表した資料があるのでそちらをご参照下さい。

Web系プロダクトの開発に従事して得た経験が反映されると思います。

マインドフルネスとは、雑念を脇に置いておき、イマココに集中します。

また、スクラムはリーン思考に基づいており、スクラムガイドには「ムダを省き、本質に集中する」と書かれてあります。

とはいえ、実際には、何かに夢中になるとモノゴトを俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいます。これを防ぐためにスクラムではスクラムマスターという役割（責任）が定義されていて、スクラムマスターがチームを俯瞰して観ることでマインドフルネスな状態を維持できると僕は考えます。

スクラムマスターが（だけではないけど）日々の活動の中でマインドフルネスを意識すると、雑念に囚われることなく、ムリ／ムダ／ムラをなくし、より良い活動ができるようになります。そうすると、自ずと平穏な日々を過ごせるようになるのではないでしょうか？

僕自身、プレイングマネージャーをしていたことがありますが、成功させたいと想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまいました。まったくもって近視眼的だったなと思います。もう同じ過ちは繰り返したくない！だからこそ「俯瞰して観る」ことを大切にしたい！

心の健康と体の健康は別のものでしょうか？それとも相互に関連しているものでしょうか？

「体力がない人はメンタルヘルスが悪化しやすい」という研究結果もあり、適度な運動によって体力を維持することが心の健康にとっても重要だと私は考えています。

そこで、書籍「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」を参考にして計測とふりかえりを繰り返しながら健康のリファクタリング（身体的負債の解消）を行なっています。

基本的には1週間スプリントで以下を繰り返します。

• 計画づくり
• エクササイズとストレッチを実行
• 自分の身体のさまざまな数値を計測
• ふりかえり

とはいえ、理解は容易ですが実践は難しいのはスクラムと同じです。

継続するためには、楽しみを見つけること。
実行した結果が数値として見えてくる、身体や心の調子が良くなってくる。
自分自身の変化を感じとれるようになると、健康のリファクタリングが楽しくなってくるでしょう。

本セッションでは、計測項目として使えるフィットネスのユニットテストを解説し、肩こりや腰痛解消に効くヨガのエクササイズやストレッチを紹介します。

参考図書「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」より

健康の定義

• 健康な人物とは、ライフスタイルから病気を生じさせてしまうリスクが低い人物のこと

アジャイルダイエット宣言

• お仕着せのメニューよりも個人の好みを
• 得意なダイエットよりも栄養素のバランスを
• トレンドへの追従よりもカロリーの計測を
• ダイエットのプランへのこだわりよりも、自分自身の環境への対応を

３つの質問

• 昨日、健康促進のために何をしましたか？
• 今日、健康促進のために何をしますか？
• 健康であることを阻害する要因が何かありますか？

フィットネスのユニットテスト

• 1.5マイルウォーク/ラン
• プッシュアップ
• ハーフシットアップ
• シットアンドリーチ
• 体組成

アジャイルコーチの見習いを1年したのですが、スクラムの誤解にはパターンがあると気づきました。
今回はスクラムの誤解あるあるを紹介しますので、みなさんのチームでもその誤解にはまっていないかチェックしてみてはいかがでしょうか。

このセッションでは、スクラムの3-5-3に着目していくつか誤解を紹介します。

• 「スクラムマスターって障害を取り除くのが仕事ですよね？」(責任編)
• 「スプリントレビューってスクラムマスターが仕切るんですよね？」(イベント編)
• 「デイリースクラムって要は進捗会議を言い換えた物ですよね？」(イベント編)
• 「バーンダウンチャートが理想線に乗ってるので順調です！」(作成物編)

こんな話を聞いたこと・言ったことはないですか？

私も誤解していたことはありました。
今回は、そういった経験を元にして、みなさんとスクラムについての理解をより深めて行ければと思っています。

また、そもそもどういうふうに考えることでこのような誤解を避けられるようになるのか、自分の体験も含めて共有します。

スクラムはアジャイルソフトウェア開発のうちの一つのフレームワークであり、プロジェクトチーム内のメンバーが互いに協力しあい、迅速かつ効果的にソフトウェア開発を進めるための方法として、多くの企業が採用しています。しかし、スクラムは必ずしもすべてのチームにとっての最適な方法ではありません。

スクラムを導入すべきでないチームがスクラムを導入した結果、逆に非生産的な状況になっているケースも散見されます。また、スクラムマスターとして仕事をしていると「私のチームはスクラムを導入すべきですか？」もしくは「チームにスクラムを導入しているがうまく行っていないように感じる」などの相談を本当に良く受けます。果たして、チームがスクラムを導入するべきかどうか、どのようにして判断すれば良いのでしょうか？

本プロポーサルでは、スクラムガイドや自分の経験をベースに「チームがスクラムを導入・継続すべきかどうか」をチェックリスト形式で整理し、スクラム適性度で判断できるように発表します。