スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスや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 の収益の中からサポートをいただいています。ありがとうございます。

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

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

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

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

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

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、やっとむ（yattom）、かっちゃん（katzchang）
今回もローカルレーサーに声かけするつもりです。

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

2022/10/12 追記
てやまぐ（teyamagu）選手は都合により出走取消となりました。
次節の出場をお楽しみに！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ（超生産的）チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。

各パタンの概要はこちらの記事で紹介しました。
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)｜note

筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト（通称フロリア）」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。

プロジェクトの概要やチーム体制は下記の記事で解説しています。

• kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
• 30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ

本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。

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

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

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

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

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

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

こんにちは、世界。

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

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

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

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

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

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

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

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

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

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

「スクラムとはどういったものですか？」

そう聞かれたら、あなたはどう答えますか？

そのような質問があれば、おおよそ以下のようなスクラムのロールやイベントや成果物をベースに、スクラムの特徴を説明するのではないかと思います。

• 開発者、プロダクトオーナー、スクラムマスターというロールがあるんだよ
• スプリントという短い期間で開発を区切って、繰り返していくんだよ
• プランニング、デイリースクラム、スプリントレビュー、レトロスペクティブといったイベントがあるんだよ
• プロダクトバックログやスプリントバックログといった成果物があるんだよ

しかし、スクラムのフレームワークを長年利用していて親しみがある人でも、スクラムの"価値基準"をベースにスクラムを説明しようという人は少ないように見えます。

スクラムの"価値基準"とは、以下の5つです。

• 確約（Commitment）
• 集中（Focus）
• 公開（Openness）
• 尊敬（Respect）
• 勇気（Courage）

これら5つの価値基準はスクラムガイドでも明示されているのですが、それぞれの内容が何を意味しているのか・なぜスクラムの成功を左右するのかまでは踏み込んで説明されていません。

しかし、スクラムの"価値基準"はスクラムが成功するかどうかの重要なものであること、そしてスクラムの"価値基準"が具現化できていなければスクラムを支える「透明性」「検査」「適応」がハリボテになりかねないということも、スクラムガイドは示唆しています。

このセッションでは、Back to the basic of Scrum（スクラムの基本に立ち戻る）と称して、スクラムの根幹を支えるスクラムの"価値基準"についてふりかえってみようと思います。

スクラムガイドでは踏み込んで紹介されていない5つの価値基準ですが、XP（エクストリーム・プログラミング）と組み合わせて考えることで、これらの価値基準が何を意図しているのか・なぜ大事なのか・なぜスクラムの成功に関わるのかが見えてくると考えています。

For ScrumFest Sapporo 2022

本講演は2022年5月21日（土）に「スクラムフェス新潟」で初演されたものです。

「品質文化」というQA界隈で話題になっているトピックについて考察したものです。とても抽象的でシンドイ思考が必要であり、皆さんとも議論したいと思い、再演である（新作でない！）との謗りを承知でプロポーザルを提出します。

なぜ「品質文化」というものを考える必要があるのでしょうか？　ぼくたちはエンジニアであり技術知識を深め経験を積むことは重要だと簡単にイメージできますが、さて、エンジニアリングと文化とが（それも「品質」文化とが！）どれほど関係があるというのでしょう？

ぼくが考えているのは、むしろエンジニアリングの世界は不可視の文化の土台の上で成り立っているのではないか、ということです。建物を建てるには地中に杭を打ったり礎石を据えたりしますが、そうした杭や礎石は目に見えません。

見えないなら見えないままで良い気もしますが、ビジネス環境の大きな変化が、土台に目を向けないことを許してくれなくなっているように感じます。自分たちがどのような文化の上に立っているのか、今こそ再発見・再定義する必要があるのではないでしょうか。そんな問題意識から「品質文化」の話を広めてみたいと思っています。

ぼくが「品質文化」について一生懸命考えていることが皆さんの目からどう見えているか、またより発展させていくためにはどうしたらいいか、一緒に考えてくださるとうれしいです。

以下、初演時の概要説明を記載します。

▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽

『品質文化試論』というQiitaの記事を2021年12月に公開しました。JaSST東海'21に合わせて公開したわけですが、ありがたいことに、様々なコメントを界隈で貰うことができました。

コメントを眺めていると、一人ひとりの問題意識とか立ち位置（ポジション）によって『品質文化試論』の受け取られ方は異なっているのではないかと思うようになってきました。そこで今回は、改めてMark（ぼく）が何を考えてあの文章を書くに至ったのかをプレゼンしようと思います。

『品質文化試論』で語ったことは、端的に表現すれば「品質文化は組織戦略に逆らったものにはならない」でした。その結論に至るまで、大きく2つの議論をしています。

ひとつめは、縦の階層構造です。「品質文化は組織文化に従う（逆は難しい）」のではないかと提示しています。

もうひとつは、横並びの構造と捉えて「戦略と文化は組織の両輪」と考えました。

「品質文化」というものを真正面から考えるのはシンドイのでこういう手法を取ったわけですが、結果的には「品質戦略」という言葉を引き出すに至りました。魅惑的な言葉が増えてしまって、正直なところ頭を抱えています。ただ、こうした構造を表現したことで、特に「1人目のQAエンジニア」へのメッセージを発することになったかなと思っています。

さてさて、こういうちょっと変わった角度から「品質文化」を考えるに至った源泉はなんでしょうか。これも大きく2つあると思っています。

まずはMBA（経営学修士）で学んだ知識があります。特にヒト系科目と呼ばれる「人材マネジメント」や戦略系科目「経営戦略」あたりで学んだことがベースになっています。エンジニアでMBAに通う人はまだまだごく少なく、特にQAエンジニアでいえば、国内では会ったことがありません。その意味では、少々レアな経験を積んでいると思います。

もうひとつ、5年前から海外カンファレンスや洋書を通じた学びを続けており、現在は『LEADING QUALITY』という本を翻訳しています。この本はCレベルのエグゼクティブ（たとえばCEO）が品質を重要な経営課題と認識して取り組むことの価値と、いかに推進するか、その事例が書かれています。どちらかというと技術書っぽくない、経営陣向けの「ビジネス書」に近い感覚の独特な本ですが、品質エンジニア目線で経営陣をどう説得するかを学びたい方にもおすすめできる著作です（翻訳されたら買ってください、ぜひ）。

ところで、品質関係の書籍というとどんなものを想像するでしょうか。「品質とは何か」「品質をいかに測るか」を説明した書籍や規格類が、やはり多いかなとぼくは思います。その一方で「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説した信頼できる情報源は、ほぼ皆無だとも。「品質文化」という言葉はいかようにも解釈できる危険な言葉で、避ける人もいますが、それが危険なまま放置され続けてきたこともまた、注目に値するのではないでしょうか。人類の進化に火が多大な貢献をもたらしたことを考え合わせてもいいかもしれません（プロジェクトを炎上させたくないぼくたちに火の話題はタブーかもしれませんけど）。

国内では比較的レアな品質 x MBAというコラボレーション、そして『LEADING QUALITY』をはじめ、海外から学んだ知見があって『品質文化試論』につながっているのです。

そして『品質文化試論』は「試論」にすぎません。ぼくはこれを『品質文化論』に進化させたいと考えています。たぶん、数年かけて。

今回の登壇はその長い道のりの第2歩になるかもしれません。

参加者の皆さんとの対話の中で（決して保証はできませんが）広く共有できる「なにか」があればいいなと思っています。楽しいセッションにいたしましょう。長い旅路の第2歩目を、ぜひご一緒しませんか。

RSGT2021 ZuziさんのKEYNOTEから一年半。
レベル2・3のスクラムマスターとはなんだろう、と
自分なりに模索しながら組織開発と向き合ってきた。

その中でも、一年ほど継続してきて、幸いなことに良いフィードバックをいただけている活動がある。
メンターだ。
ここでのメンターは、「会社の中で異なる部署・チームの人と、フラットな関係でありながらその人がより活躍できることを応援する役割」と定義する。

元々は入社された方向けのオンボーディング支援活動として取り入れられたメンター制度だったが、
さまざまな部署のお相手の方（メンティー）たちと継続的な関係を築けたことによって、大きな変化が生まれている。
特に感じるのは、1年ほど経つとアジャイルの話ができるようになっていることだ。

このセッションでは、

• 「この制度、もっと広まった方がいいですよ！」と言われた
• 「この時間があるから1年続けられたかもしれません」と言われた
• 一年前のメモをメンティーさんと眺めてみて「今は少しは成長できたのかな、と感じました」と分かち合うことができた

といった、スクラムマスターの心を持って業務や役割が異なるチームの外の人とお話しするとどんなことが起こるのか・起きたのかを話す。
直属の上司との1on1などと異なる点も実体験を元に併せて紹介したい。

また、目の前の頑張る人を応援したいと願う思いが芽生えた状態で
PEP TALKに出会った。

知り合いが開催するようだし面白そうだな、程度の気持ちで参加したセミナーでとてつもなく大きな衝撃を受け、
実際に自分も研修に通うようになった。

いざ実践してみると、日は浅いが効果や変化が（メンター以外の場面やメールなども含む）普段のコミュニケーションで感じられているほどである。

今後のメンターやスクラムマスターの活動をする上で切り離すことができない要素になると確信した
PEP TALKについても紹介させていただきたい。

30人超所属するスクラムチームの開発で7年目に突入しました。

守・破・離の「離」に到達し、独自の文化を形成しつつ運営しております。
参画当初の方々は、それぞれの道を歩み始めており現状チームにはあまり残っていません。

「離」から生まれた独自のプロセスで、現状プロダクト開発を行っております。
プロダクトを止めない開発を行いつつ、大規模なチームのカイゼンは試行錯誤の連続でした。

今一度「守」から、「守・破・離」を振り返り、より高みに到達できるチーム、プロダクトをより大きく育てるべく日夜試行錯誤中。

長期間継続＆大規模チームの状況、新たな取り組みの１つの事例になれば幸いです。

振り返りの方法は十人十色、千差万別。

私のチームでは、6プロダクト、複数開発チームの担当をしています（QAチームとして）。各メンバーの担当領域が異なるため、業務上の横連携・知見共有が薄いという課題がありました。そこで、月次の"振り返り会"を開始しました。（スクラムのレトロスペクティブとは異なります。）お互いの業務を知るだけでなく、チーム内でのコミュニケーションの場にもなるなどの副次的効果もあったのです。

このセッションはワークショップ形式で、とあるチームで行っている振り返りを楽しく体験できるセッションです。各企業、組織構造にもよりますが、横断チームのマネジメントに困っている方もいれば、チームの振り返り方法のいろんな事例を知りたい方もいらっしゃると思います。

うちのチームでも試してみよう！そんなアクションのきっかけになる、チャッカマンのようなセッションを目指します！

旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに26ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助けた本たちです。

今年出た開発者向けの書籍の中から、著者や訳者にお話しいただき、ご自身で手がけられた思いの丈を、語っていただきます！

★旅するAgile本箱LT2022：発表順(予定)

1. 前説:旅するAgile本箱って?
2. 和智右桂さん『リーダーの作法 ―ささいなことをていねいに』
3. 永瀬美穂さん 『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』
4. 懸田 剛さん『「アジャイル式」健康カイゼンガイド』
5. 山口鉄平さん『ソフトウェアテストをカイゼンする50のアイデア』

以下、調整中

★LT大会出場者募集！

出たい方は、書籍名と書誌のURLをいわきりまで、お送りください！

お申し込みお待ちしてます！