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 のイメージが変わるかもしれません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「アジャイルチームで品質を作りこむ」
色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」（独自イベント）を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

### リファインメント

言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

• PBIのゴール
• 設計方針
• テストの方針＋影響範囲

POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

### 受け入れ

私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

お気づきでしょうか？
DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
良く見ると「実装」がスリーアミーゴスでサンドされています。
自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

• スリーアミーゴス
• 実装
• スリーアミーゴス

このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

• 作ってみたら変なモノができていた（修正）
• テストが足りていない（追加）
• お互いに期待値に達していなくてイライラする

スリーアミーゴスサンドぜひお試しを！

みなさん、こんにちは！

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

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

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

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

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

当初講演予定の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）の理解を助けるワークショップを作りました。

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

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

私は、悩んでいました。

アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。
もちろん学んでいますし、超優秀なコーチから継続的にコーチングも受けています。
でも、現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。

まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。
そして、自分はいつも、悩んでいました。

そんなある日、コーチングセッションでコーチから提案を受けました。
「小さなことでもいいので、現場で日々やっていることを書いて共有して！！」

当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。
やってみると、1週間で50個を超えました。
今は、3週間で100個を超えました。

「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります
気づかず繰り返しでやっているものもあります。
中には、やってみて、傷つくような失敗になったものもあります。
思いがけずに、素敵な結果に結びついたものもあります。

もしかすると、僕がやりたいことは
こういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。

発表では、私が日々現場でやってきたことを抜粋して紹介します。
また、繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。

それら、発表の中で紹介した中から、気に入ったものや使えそうなものを持ち帰っていただいて、
明日から、皆さんの現場で、小さくな所からでもアジャイルコーチを始めてもらえれば嬉しいです！！
そして、また、コミュニティの中で結果を共有できる日を楽しみにしています！！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どうもこんにちは! タフクエスチョンオタクの森です!

手強い問いかけを「タフクエスチョン」と呼んだりします。答えることがなかなか難しいですが、今まで考えたこともない観点になることもあり、停滞していた状況を打開できることもあります。盲点を突くような問いかけです。

では、簡単な問いかけと手強い問いかけにはどのような違いがあるのでしょう。

人は様々な知識を持っていて、問いかけをされると刺激されて考えが引き出されます。しかし、どのような問いかけがどのような刺激を与え、どのような結果になるのか、その関係は明らかではないように思います。たとえば、自社のプロダクトに質問をしたとしましょう。

「このプロダクトの特徴はなに?」
「このプロダクトを買うと、どんないいことがあるの?」
「さまざまなプロダクトの中から、なぜこのプロダクトを選ばなければならないの?」

下に行くほど答えるのが難しい感覚があるのではないでしょうか。

このセッションでは問いかけと答えの仕組みと働きを紹介し、参加者が効果的な仮説立案と検証について知ってもらうセッションです。

■セッション内容(予定)
・質の高い問いかけが、私たちの仕事にどのような働きをもたらすのか
・過剰にもてはやされるWHYカーゴカルト
・シンプルな質問とシンプルな答え
・複雑な質問と複雑な答え
・シンプルと複雑の違い
・問いかけの構造と機能
・質の高い問いかけを作ろう

このセッションではふりかえりの一つである「なぜなぜ分析」にターゲットを絞って考察をします。

なぜなぜ分析はふりかえり手法の中でも有名なものの1つで多くの書籍が出ており、海外でも5Whyの名称で知られている世界的に知られています。その一方で、多くの誤解があり、敬遠されがちな手法です。

• 個人を責める手法になっている
• 工場でしか適用できない
  • 現代では状況が複雑になっているので適用できない
  • 高速にフィードバックサイクルを回す状況では鈍重なフレームワークである
• etc..

このような理由を聞いたことがないでしょうか。確かに運用方法を間違えるとこのような課題が表面化してしまうフレームワークです。

しかし、このような誤解をしないで正しく適用すれば問題の分析手法、ふりかえりの手法として非常に強力なフレームワークだと思います。このセッションではなぜなぜ分析の例を通して、自分が工夫している点、注意しているポイントを説明することで、このセッションを聞いた方がなぜなぜ分析を今よりも一歩だけうまく適用できるヒントを与えられることを目指したいと思います。

ある日突然、プロダクトオーナーになる。そんな経験をされている方も少なくないと思います。

プロダクトオーナーは、スクラムチームに一人しかいないプロダクトに対する責任を持つ、とてもたいせつな役割です。
ですがその分、役割についた人は不安もたくさん。何をしたら良いのか、何が正解かもわからない。

プロダクトオーナーはスクラムチームの一員なので、チームがいい状態でいられるためには、プロダクトオーナーの言動はとても大切です。
でもそう思うとなかなか行動に移せない、なんてこともあると思います。

本セッションでは、私自身がプロダクトオーナーとして他のスクラムチームメンバーと一緒に、いいプロダクトやチームを作っていくために普段「とりあえず」おこなっていることをお話します。完璧でもなんでもない、でも少しだけ人間味がある（かなと私自身は思っている）ような行動です。

また、そんなプロダクトオーナーの行動は他のメンバーからどのように見えているのか、どう感じられているのかを、同じスクラムチームのメンバーからの生の声としてお届けします。

プロダクトオーナーなりたて当時の自分含め、不安でいっぱいのプロダクトオーナーや、プロダクトオーナーをやっているけれどなんかうまくいかないな、という方にとって、自分でもできそう。やってみようかな。と思ってもらえたらうれしいです。