スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

過去の放送

https://youtu.be/5BZI9A3jhsY

https://youtu.be/0JDjMDSLqrE

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

私が所属しているチームは、結成されてからこれまでの間に経験してきた開発は、受託開発（部署または会社の外から欲しいソフトウェアの要望が来ることから始まる開発）が少なくありませんでした。その要望を出す人たちは、ソフトウェア開発の経験や知識が無い方々が殆どでした。しかし、その人達が予算を持っており、開発を誰に依頼するのかを決める決定権を持っています。そのため、その人達にとって、もちろん開発したプロダクトのユーザーにとって魅力的でなければいけません。そのために我々は最初のデモを重要視しています。常に受注を続けてこられたわけではありませんが、受注につながったのではないかと思える実感を得られるやり方が見えてきたような気がしています。そこで、このセッションでは、そのやり方を直近で携わっているプロジェクトを例に紹介したいと思います。

スクラムマスターのトレーニングを完了した直後にスクラムマスターがハマる罠。
その一つに、トレーニングで得た知識をそのままチームに適用する！というものがあるのではないでしょうか？
知識の押し付けですね。

私も初めてスクラムマスターに挑戦したとき、思いっきり失敗しましたw
トレーニングでこう教わったからこうなんです！！！
あぁ、恥ずかしい…

月日は経ち1年半後、新チームの立ち上げに関わることに。

初挑戦の失敗と、それまでの経験を活かして取り組むことを心に誓い臨んだチーム作り。どのように取り組んだのでしょう？

知識の押し付けで失敗した初挑戦。
それなら、知識は教えない！教えるにしても最小限。

体験を最大限に活かす！

開発者にスクラム経験者が1人いたものの、はたして教えるより体験重視の方針で上手くいくのでしょうか？

チーム開始時点でのスクラムの意識はこれくらい。

• スクラムのイベントは全部やってみよう
• スクラムの作成物は全部作ってみよう

各イベントと各作成物の概要だけ伝えて、いざスタート！

当然のことながらスタート時点ではイベントをこなすだけ、プロダクトを作るだけ、とりあえずやってみてます！の活動が続きます。

そんなチームですが、
チームで良い活動をしていこう！
良いプロダクトを作っていこう！
そんな気持ちは持っています。
ふりかえりも真剣にしています。

真剣に取り組んでいるので、
ふりかえりで、課題がどんどん出てくる。
出てきたものを少しずつ改善していく。
上辺の改善だけではダメだと気づき、意味を考えるようになる。

形だけで始めたスクラムが、いつの間にか、

スクラムの良さに気づき

チームで取り組んでいる状態に。

本セッションでは、2年間毎日書き留めたチームの活動記録とふりかえりを元に、チームがどう変わっていったのか、チームメンバーの視点を中心にお話します。
スクラムマスターとしてどう関与していったのか、ちょっぴり入れられればなとも目論んでいます。

スクラムマスターとして活動されている皆さん。皆さんの中には、自分が話す内容が、チームメンバーにうまく届いていないなあと感じた経験はありませんか？

スクラムマスターは、他のメンバーと少し違った視点で考えることも多く、前提知識の有無も含めて、なかなか理解・共感を得づらい場面もあります。

その場合、いきなり本題について話すのではなく、1クッション入れるのが効果的です。本題に至った思考の過程や前提知識を共有する場があると、よりメンバーからの理解や共感を得やすくなります。また、副次的な効果として、共有のために言語化する中で自分の考えを整理でき、後のふりかえりにも流用できるようになります。

本発表では、チームメンバーにスクラムマスターの頭の中を共有しながら、チーム・プロセスに関する取り組みを推し進めていった例を紹介します。月1ペースでLT発表する場を通じて、「どういう状況下で」「どういう課題を感じていて」「どのような前提を共有しつつ」「どういった取り組みを進めて」「結果どうなったか」を、いくつかのケースに応じてお伝えします。

企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。

毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。

私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。

本セッションでは、Agile 2014  での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか？

"名詞" では 「"名詞"、"名詞"、"名詞"」をまとめてなんと呼んでいるでしょうか？

みなさんはどれくらいスクラムを知っているのか？すっとその知識を出せるのか？不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにスクラムのクイズを出してその知識や引き出し方を確認してもらえればと思います。

当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

「QAさんからバグを指摘されたので、このバックログアイテムはDoneにできませんでした」
これはQAエンジニアである私が度々出会う、最もモヤッとする言葉です。

なぜこのような発言が出るのでしょうか？

これはテストによって発生したフィードバックを、開発者が「差し込みで発生した作業」と捉えてしまうからではないかと考えています。自分の手で実装したものなのに、自分ごとにできなくなってしまう瞬間があるのです。

開発者の実装が完了した後、1Sprint遅れでQAエンジニアがテストを行うやり方を採用しているアジャイルチームを時折見かけます。これはあまり推奨できるやり方ではありません。
QAチームがテストを実施している頃、開発チームの心はすでに後続のバックログに向いていて、テスト対象となっているアイテムは「すでに終わったもの」と認識しているからです。

しかし、たとえ1Sprintの中で実装からテストまで行ったところで状況は変わらないでしょう。「QAにテストを任せた瞬間に心が離れてしまう」という点は同じだからです。

また、QAエンジニア自身にも甘えや油断が発生しているのではないでしょうか？
あるバックログに対して要件に不明な点があったとき「これはテストをするときに確認すればいいか」と解決を先延ばしにしてしまうことがあります。やがてそれがSprintの終盤にバグとなって吹き出すのです。

考えられる解決手段は2つあります。

1. 開発者自身でテストを行うこと
2. 実装に着手する前に、要件の解像度を上げること

今回は後者についてお話ししたいと思います。

バグの多くは、要件の認識ずれによって引き起こされます。
そしてその認識ずれは、プロダクトに関わる各ロール (PO、開発者、デザイナー、QA、etc.) が細かく対話を重ねることで解消できるものも多いでしょう。

テストだけが品質保証の手段にあらず。
重厚なテストに頼りすぎず、より早い段階で対話を重ねることで品質を担保するチームにシフトしていきませんか。

はじめまして。
日々、プロダクトやチームの成長を、子供の成長を見守るのと同じように楽しみながら奮闘している母ちゃんスクラムマスターです。

私、この2年間、専任でスクラムマスターとして活動しています。

当初、社内SE出身で非エンジニアの私が、現役バリバリのエンジニアのなか、スクラムマスターを担えるのか?
という不安はありました。(私自身はもちろん、チームメンバーも)

そんな不安と葛藤のなか、私は、チームメンバーがプロダクト開発を「楽しく！」取り組めることに注力してきました。
それは、「楽しく！」はたらくことでチームが強くなり、どんな困難もチーム一丸となって乗り越えていけると信じているからです。

今回は、メンバーがプロダクト開発を楽しむことに全力を注いだ私の事例をメンバーから見た意見を交えながらお話したいと思います。
ただ楽しいだけじゃない、社内一賑やかといわれたスクラムチームの日常をのぞいてみませんか？

聞いていただいた皆さんが「楽しい！」をどんどん広げて、強いチームがどんどん増えることを想像するだけで「楽しい！」

顧客を理解することが大切とはいっても、どのように考えればいいのかそれほどあきらかではありません。

これまで18年間、新規事業や新製品開発、リニューアルといったプロダクトの今後を左右する活動に関わってきました。2010年代からはソフトウェア開発でも、仮説検証やリーンキャンバスといった方法が認知され、プロダクトオーナーやプロダクトマネージャーにとって、顧客を理解するための様々な選択肢があります。

しかし、いったいどのようになったら顧客を十分に理解できたといえるでしょう。

また、顧客理解の新たな課題も登場してきています。チームによる顧客理解です。2010年代中旬頃までは、プロダクト開発においては一人の強力なリーダーシップによって進められることが少なくありませんでした。しかし、チームによってプロダクト開発を進める流れが起こりつつあります。顧客への深い理解はプロダクトオーナーだけの仕事ではなくなり、スクラムマスターや開発者にとっても重要な関心事になりつつあります。

知識や関心にバラツキのあるスクラムチームで、いったいどのようにすれば顧客の理解を深められるでしょうか。

このセッションでは以下の様々な切り口から顧客の理解を深める方法を紹介します。
・顧客の理解を度合いから評価する
・チーム全員で顧客を理解する

・顧客との接点はどれくらい持ちやすいだろうか
・顧客をどれくらい理解しているだろうか
・顧客の悩みを考えよう
・顧客の悩みが解決されない理由を考えよう

顧客の理解を育み、よりよいプロダクトを提供していきましょう!

スクラムマスターのロールを学び続けることは、スクラムを離れてもこれからの時代に求められるチームビルディングにつながっている

1. スクラムとの出会いと学び
2. スクラムは人生そのものと思った翌月にスクラム終了した話
3. 2年ほどチームと共に育つことを支えたくれた人と言葉
4. アジャイルジャパンの安田さん講演からの社長に「Joy,Inc化しよう」と言ってみた話
5. 今～スクラムからは離脱しているけどチームビルディングと所属組織の変容に口出しする末端社員になった話

医療従事者向けの書籍「コンコーダンス　患者の気持ちに寄り添うためのスキル21」から、相手の行動変化を促す対面コミュニケーションの考え方とスキルを共有します。

「コンコーダンス」とは「調和」「一致」を意味する英語であり、「患者の価値観やライフスタイルに、患者にもたらされる医療や福祉のあり方が、調和する」ことを表す医療用語でもあります。

「コンコーダンス」という言葉は1997年に英国国立薬剤師会により公式の場に登場したとされます。薬の飲み忘れや通院の中断などのノンコンプライアンス問題への対策から始まりましたが、服薬行動にとどまらず、健康問題における当事者と専門家の関係性やその成果を示す概念へと広がっていったそうです。

書籍は英国で地域精神看護師向けに開発された技術集「コンコーダンス・スキル・マニュアル」の影響を受け、に日本人向けに調整したものとあります。自己主張が苦手な日本人向けのスキルが追加されています。

書籍は医療従事者向けの技術集ですが、コーチングなどのエンジニア間で語られるコミュニケーションスキルとの共通項が多くあります。服薬行動などの「行動を変えてもらうために相手に納得してもらう」考え方／スキルが体系的にまとまっており、医療に関する知見がなくても理解しやすい内容です。

本発表では、コンコーダンスを紹介し、エンジニアへの応用の可能性について話します。また、書籍にあるスキルを抜粋して紹介します。

自分は、2020/11/1〜2022/9/22の間で、1,019回のカンファレンスやイベント(勉強会)に参加してきました。(2020年 : 55回 / 2021年 : 439回 / 2022年 : 525回)

どのカンファレンスやイベントも学びや刺激に溢れる素晴らしいものではありましたが、参加し始めたての頃は、自身や自身の周りに大きな変化が起きるわけでもなく、正直参加するメリットをあまり感じにくい状態でした。

しかし、カンファレンスやイベントに参加している人を観察したり、イベント参加を太い経験にするための工夫を自身で考えて試行錯誤していくうちに、徐々にカンファレンスやイベントの経験が行動変容に繋がるようになり、次第にカンファレンスやイベントに参加する意義を大きく感じられるようになっていきました。(イベントに参加する意義を感じられると共に、イベントに参加する頻度も増えていきました)

本セッションでは、イベント参加を太い経験にするために自身が行ってきた試行錯誤や、カンファレンスやイベントの種別ごとにどのように工夫するポイントを変えているか紹介することで、皆さんがカンファレンスやイベントで得られる経験をより太くし、参加者がカンファレンスやイベントをこれまで以上に楽しめるような話をしていきたいと思います。

アジャイル／スクラムを採用するチームが増えたことで、ふりかえり（スプリントレトロスペクティブ）を行なうことが当たり前になりつつあります。しかし、ふりかえりの実践にはツールだけではなく、参加するメンバーの心構えも重要な要素であり、参加者から前向きな意見を引き出すのに苦労している方も多いのではないでしょうか。

このセッションでは、このような課題をお持ちの方が、前に進む勇気やヒントをお持ち帰り頂ければと思っています。

ふりかえりマニアのふたりが、それぞれのふりかえりの原点（オリジン）と、ふりかえりの未来像（ライジング）を語ります。

僕らふたりも、最初からうまくふりかえりをできていたわけではありませんし、今でもいつもうまくふりかえりを行なえているわけではありません。多くの経験を通して様々な知見を得てきています。僕らの成功や失敗の経験談を伝えるとともに、ふりかえりの未来をみんなと一緒に考えてみたいと思います。

デイリースクラムがなんとなく進捗確認だけの場になっていませんか？
スクラムマスターだけが頑張って課題をヒアリングしてリカバリをしてませんか？

KDDIでは大規模スクラムで開発を進めており、1スプリントでより多くの価値を届けるためにカイゼンを繰り返してきました。
その中で、どうやったら楽に、スプリントゴールを達成するためにチームで協力して再計画を繰り返し、スプリントを走り切ることができるか考え、その方法を確立しました。

スクラムマスターも開発者も、指示するのでも、毎回教えるのでもなく、みんながんばらなくても自然にできるMiroを活用したデイリースクラムの方法をお話しします。
実際に皆さんの環境でも再現できるよう、なるべく詳細にやり方をお伝えしますのでご参考いただければ幸いです。

今年、私は新卒から慣れ親しんだスクラムチームを離れ、新天地でチャレンジし始めました。
フルリモート勤務という働き方や新チームで必要となる業界知識など、どんどん押し寄せる新たなものに立ち向かいつつ、新チームのことを観察していました。
その中には、職種に関わらず顧客価値につながる施策か議論する様子などアジャイルな精神が見えつつ、一方ではどうしてこうなってるのかと疑問に思うようなものもありました。

チームの人から相談を受け、一緒にカイゼンしようと活動する中で、前スクラムチームではどうだったか考える機会がたくさんありました。
考え続けるうちに、スクラムじゃなくてもできるけど、スクラムだともっと嬉しいことがあることに気がつきました。
今回は、そんな気づきについてお話ししたいと思います。

確約・集中・公開・尊敬・勇気、これら5つのスクラムの価値は何もアジャイル開発の現場に留まるわけではございません。スクラムの考えを実践することは、エンジニアであっても非エンジニアであっても、キャリアの形成や人生に大きく寄与する可能性を秘めております。

非エンジニアであり、人材育成・組織開発に関わる企業の経営者として、自身のキャリアを少しふりかえりながら、スクラムの価値基準がどのように人生に寄与したかをお伝えしたいと思います。

学びのポイントとして、「勇気を出して自身の目で一次情報として経験する（もちろんオンラインもOK）こと」です。どこかで誰かが話していたことを又聞きしたり評論したりするのではなく、現地・現物を大切にすることで、きっと見えてくる世界があると信じております。

そして経験したことは、せっかくなのでふりかえってみましょう。ポイントは一人でふりかえる内省だけでなく、仲間と一緒にふりかえってみることです。経験したことを仲間にオープンにすることで、きっと何かフィードバックを得られ、新たな気づきや学びに繋がるはずです！

本セッションでは、ふりかえって見たらスクラムの価値基準をもとにアレやコレやを個人や組織レベルで実践してきた経験を元に、皆さんのキャリアや人生がほんのちょっとでも豊かになるためのTipsをお伝えしたいと思います。

こんにちは、世界。

私は、テストの街「葛飾」を運営者の一人、”ただのテスター”のおおひらです。

みなさん、イベントを楽しんでいますか。

最近、スクラムフェスなど、大規模イベントが増えていますね。

ただ、大規模イベントが増えていることはとても喜ばししいですが、なんとなく物足りなさを感じることはないでしょうか。

特にオンラインだと、発表の視聴はワイワイするし、あとで発表動画を見直して勉強になるけど、ただそれ以外は。。。で、もっと能動的に楽しみたい！と思っている人もいるかもしれません。（オンサイト参加でも、発表を視聴するだけで帰るだけだと、物足りないかもですね）

そんなときこそ、「DIY縦軸」です。

”縦軸”とは、24時間テレビのマラソンのような、バラエティ番組でメインコンテンツに合間に挟まれる続き物のサブ企画のことをいいます（諸説あり）。
参考：https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1151175311

「DIY縦軸」では、”縦軸”という仕組みを応用して、イベント中に自分が考えたサブ企画を勝手にやり、能動的にイベントを楽しむ考え方です。

今回は、この「DIY縦軸」を実践した私の事例を紹介したいと思います。

ぜひ、みなさんも「DIY縦軸」実践し、イベントを能動的に楽しみましょう。

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!

「カルチュラル・インテリジェンス」（CQ）とは、文化の違いを超えて円滑にコミュニケーションを図る能力のことです。文化の違いと聞くと国や宗教のような大きなものを想像しがちですが、組織にも、部署にも、チームにも、そしてひとりひとりの個人にも文化的背景はありますよね？

知らず知らずに考えたり、当たり前に行動しているその価値観。根幹には、本当はもっと多くの次元の価値観の軸があるのではないでしょうか？

ここでは手始めにCQで語られるホフステードの6次元モデルを参考に、CQとは何かのざっくりとした説明と、どのように使っていくといいのかをみんなで一緒に考えてみたいと思います。

https://speakerdeck.com/spring_aki/cq-introduction?slide=2

アジャイル開発/スクラムを導入しているあなた、こんな発言を耳にしたこと、発言したことはないでしょうか？

• 「当事者意識を持って！」
• 「スクラムには階層は存在しないから、指示待ちせずに行動！」
• 「それはアジャイルじゃない！」
• 「ふりかえりはしなきゃダメだよ。」
• 「チームは自己管理型(※)なんだから～」

こんな言い方ですと、チームのメンバは委縮してないですか？あなたの「アジャイル」価値観を押し付けてないですか？

私は、複数のスクラムチームでの開発を通じて、アジャイルマニフェストを読んだだけ、スクラムガイドを読んだだけ、で出来るほどアジャイル開発/スクラムは甘くはないことを痛感してきました。

・ドキュメントの文面だけを捉えて行動しても、それは薄っぺらいものになってしまう

・背後にある理念を理解しないと、ただの「作業指示」になってしまう

・やらされ感を感じ、チームの雰囲気が悪化してしまう

その結果、Be Agileを目指しているつもりが、Do Agileになり、気づけば「押し付けアジャイル」になってしまった。

こうなってしまうと、負の連鎖は止まらない。なんとか悪循環から脱出したいと思い、押し付けアジャイルは「ダメ。ゼッタイ。」をスローガンにカイゼンを始めてみた。

このセッションでは、私がスクラムマスターとして、開発メンバとして、複数のスクラムチームで経験/目の当たりにしてきた

「押し付けアジャイル」による失敗事例、アンチパータンとそれらを生み出していた根本原因、

そして、悪循環からの脱出に向けた改善に向けた取り組みについて、お話します。同じ悩みを抱える方々のご参考になれば幸いです。

※自己管理型とは、

2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。

～スクラムガイド２０２０より～

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf