アジャイル開発の実践には「プロセス・チーム運営」に関するプラクティスだけでなく、「技術・ツール」に関する技術プラクティスも重要です。真正面から技術プラクティスの取り組みを取り上げ、良い知見を広く探求してきたいという思いからRegional Scrum Gathering Tokyo 2022で登壇機会をいただき、さらに登壇をきっかけに『アジャイルプラクティスガイドブック』という本を書く機会をいただきました。

書籍として形にしていく過程では色々なことを考える必要がありました。「アジャイル開発の技術プラクティスを扱った書籍は無いのか」「技術プラクティスをまとめた情報が少ないと感じる理由はどこにあるのか」「2023年に出版する書籍としてどの技術プラクティスを紹介するべきか」などなど。

本講演は書籍が出版されるまで1年半ほど技術プラクティスの整理に向き合うことでわかったことを紹介し、知見を体系立てて整理するために必要だと学んだことをお伝えします。

このセッションで伝えたいこと

本セッションでは、製造業にアジャイルコーチとして入社したSatoshi Haradaが、社内アジャイル勉強会コミュニティの火を燃やすために何を考え・何をしているのか、可能な限り全部お見せしようと思います。

このセッションを見た方には、社内でアジャイル勉強会コミュニティを立ち上げた実例を知っていただきます。そして、社内アジャイルコミュニティを立ち上げよう・盛り上げようと思っている方に、コミュニティ活動はFUNが大事であることを知ってもらい、一歩目を踏み出す勇気を持って帰ってもらいます。

私が社内コミュニティ活動を開始した理由

現在の会社にアジャイルコーチとして入社して4カ月になりました。
勤めている会社は、創業150年・従業員数4500人超の国内製造業です。

この会社では既にDXやアジャイルといった取り組みが進んでおり、スクラムの研修開講やプロジェクトでのアジャイル適用が行われていました。素晴らしいことです。

この素晴らしい取り組みをさらに加速させるためには何が必要だろう？
そう考えた私は、もっと”FUN”が必要で、そのための社内コミュニティ活動の楽しい"場"が必要だと感じ、行動を始めました。

・社内のアジャイルコミュニティをもっと楽しく！さらに盛り上げたい！
・有志による楽しい学びの場を作りたい！

そんな気持ちで、社内のアジャイル勉強会コミュニティを自ら立ち上げて運営を開始したのです。

しかし、順風満帆・全てがうまくいっているわけではありません。
　勉強会に誰も来ない…
　盛り上がらない…
　運営が大変…
　自分だけが運営を頑張っているのかも？
そんなふうに思うときもありました。

そんなとき私は、「コミュニティ運営は焚火に似ている」と思うことにしています。
焚火は火をつけてからだんだんと太い薪に着火させて炎を大きくしていくのですが、その様がコミュニティ運営に似ていると思うのです。

そこで私は、社内アジャイル勉強会のコミュニティでいろいろな企画を投下してきました。焚火でも薪を投入する順番はよく考える必要があります。コミュニティ運営も同じです。
その結果、少しずつではあるのですがコミュニティ参加者が増え始め、勉強会の運営も参加者が主体的に関わってくれるようになってきています。

そして忘れてはいけないのは”FUN”です。焚き火も楽しいですよね？コミュニティ活動にも楽しさは不可欠だと思うのです。

なぜこのセッションをやろうと思ったか

私の社内アジャイル勉強会コミュニティの立ち上げと運営はまだ4か月ですが、まだフレッシュな状態で私が何を考え・何をしてきたかを発表することで、同じように社内のコミュニティを盛り上げたい！と考えている人の背中を押すことができるのではないかと思いました。

社内でアジャイルを進めるにあたって、「仲間がほしい」「共通の話題で相談できる場所が欲しい」「学びを深めることができる場所が欲しい」と思ったことはありませんか？
もしまだそのような場がないという方、ぜひ自らそのような楽しい場を立ち上げましょう！

そのような一歩目を踏み出す方に勇気を持って帰ってもらえる焚火のようなセッションにしようと思います。

鹿児島の中学生に紙飛行機ワークショップを、

鹿児島の高校生にマシュマロチャレンジを、

それぞれスクラムを知ってもらうワークを実施予定です（5月と6月に）

ワークを通して感じたこと、ホットな情報をお話しできればと思います！

〜選手は体を鍛え技を磨くように、リーダーは言葉の力を磨く〜

各地で大変ご関心をいただいているペップトーク
今回は概要はきちんと押さえつつ、
簡単なワークショップを交えた形式で体験いただきます。

今まで気になっていた方も
初めて目にして気になった方も
ペップトークに触れてみませんか？

このセッションでは、
声がけからチームの本領発揮を引き出したり
自分や周りへの言葉の選び方だったりに役立つペップトークについて、
簡単な体験を通じてその日から使えるTipsをお持ち帰りいただきます。

＜ペップトークとは＞
アメリカで生まれた、スポーツの試合前で行われる
選手に向けた激励のショートスピーチから生まれて、
現在、教育やビジネスの現場でも活用されるようになってきた
自分や周りへの声がけのことを言います。

チームが何かに夢中になると俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいがちです。目の前のタスクに集中すればするほど近視眼的になってしまうのです。そういう経験はありませんか？

僕は以前プレイングマネージャーをしていたことがありますが、成功させたい！と想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまうようなこともありました。

もう同じ過ちは繰り返したくない！専任スクラムマスターをすることになったのを機に「俯瞰して観る」ことを大切にしています。

スクラムはリーン思考に基づいており、スクラムガイド2020には「ムダを省き、本質に集中する」と書かいてあります。それって、マインドフルネスの「雑念を脇に置いておき、イマココに集中する」と同じでは？スクラムはチームでマインドフルネスをすることなのでは！と僕は解釈しこれまでスクラムマスターをしてきました。

日々の様々な活動の中でマインドフルネスを意識することで、雑念に囚われることなく、ムリ／ムダ／ムラをなくし、より良い活動ができるようになったと実感しています。その甲斐あってチームからも「俯瞰して観てくれて助かります」という声が何度かありました。この知見をみなさんと共有したいです。

※毎日瞑想しましょう！というお話ではありません

Scrum Festに参加する多くの方は、複数人でチームを組んで仕事をしていると思います。
また、所属するチームの外側には様々なチームがあり、複数のチームで構成される大きな組織の一員として働いている方が多いと思います。

そういった様々な人々が関わる中で仕事をしていると発生してくるものが「悩み」です。例えばこのようなものです。

お悩み例

• なんでうちの上司はペアプロの良さを理解してくれないんだろ…
• お偉いさんと営業が勝手にお客さんと約束してきちゃったけど…どうすんのこれ？
• 会社の方針が分かりづらいし、みんなバラバラに動いてる気がするんだよなぁ…

このような状況に身を置くのはツラいものです。ツラい環境にいるのは居心地が悪く、ストレスも溜まりやすいため、いくつかの反応を行います。

• 私は関係ない、どうでもいいや、と割り切る
• 自分1人でもできそうなことをやってみる
• 自分の意見をぶつける、愚痴を言う
• どこか違う組織に移る

悩んだ時に、どんなことを考え、どんなアクションを取るかは非常に重要です。うまくいけば悩みが小さくなったり解決することができます。

しかし、落とし穴もあります。悩みを解決できる、もしくは悩みを感じなくなるような良さそうなアクションを取った結果、長期的には悩みが肥大化することがあります。肥大化が進み、悩みがモンスターに育ってしまうと周りの人も自分自身も傷つけてしまいます。

私も過去に色々やっちまった経験があります。今になってはいい経験ですが、その時は「こんちくしょー！」と思ったものです。そういった経験から、悩みとの付き合い方を学び、悩みが育っていかない体になって来ました。今は悩みとか全然なさそうと良く言われますし、Scrum Fest 札幌ではこんなセッションをやったりしています。

本セッションでは、私の元気な話は置いといて、悩んでいた過去の話、そこから学んだこと、今悩みを抱えた時にどう捉えどう考えどう行動しているか、をお話しします。皆さんがお持ちの小さな悩みがモンスター化するのを防ぎ、皆さん自身も、周りの人も少しでもハッピーになることを期待してます！

「プロポーザルを出してみたい」

そう思っても実際に提出に至ることができる人は多くありません。それは普通のことです。なぜならプロポーザルを書いて提出するという行為は自らが生み出したモノを人の目に触れる場所に曝け出すことであり、それはとても勇気のいることだからです。それでも私がプロポーザルを提出できたのはコミュニティの皆さんが背中を押してくれたからでした。

はじめてのプロポーザルを書き上げるまで

私が初めてプロポーザルを投稿したのはスクフェス福岡でした。そこで私は初めて参加したRSGT2023に会社の仲間たちと一緒に参加して学んだことについて書き綴りました。書きながら私はいくつもの「内なる悪魔の声」と戦いました。「別にこの話は会社の他の誰かがしても同じじゃない？」や「こんな個人的な話を聞きたい人なんて本当にいるの？」といった声が脳内に響き渡りました。

そういった自己否定の気持ちと戦い抜くことができたのは、RSGT2023で「初めてのプロポーザルで自信がないのでアドバイスをください」と発言したのがきっかけで「スクフェス福岡のプロポーザルを読んでYYする会」の存在を知ったからでした。そこに草稿でもプロポーザルを持ち込めばフィードバックをもらえる。その気持をモチベーションにしてなんとか書き上げました。

フィードバックに背中を押された

プロポーザルを読んでYYする会で書いてきたプロポーザルについての話をする中で私は本文に書かなかった色々な気持ちを自然と口にしていました。RSGTに参加するまではカンファレンスに参加する強い意志がなかったこと、誘われて初めて「みんなで行くなら......」と腰を上げることができたこと、頭取に言われるまでプロポーザルを書いてみようという発想すらなかったこと。そんな何気なく言葉として紡がれた「私のストーリー」を皆さんは拾い上げて「それそれ！」「その話が聞きたい！」と言ってくださいました。

そしてその時に一緒に初めてのプロポーザルを書いた烏帽子さんとおーのAさんにも、今度は私も同じようにプロポーザルを書くに至った経緯を聞く中で「ぜひそれを語って下さい！」と言う側になっていました。この時に私は「結論が一般的でも経験は唯一無二だ」ということ、そして「私が誰かをすごいと思ってもその人にとってはそれが普通で、私が自分を普通だと思ってもそれは誰かにとってはすごいことがある」ということを学びました。そうしてYY会で受け取ったフィードバックを元にプロポーザルのリファインメントをし、ありがたいことに採択していただき登壇することができました。

この経験を届けたい

スクフェス福岡に参加した後、その次のスクフェス新潟の情報について調べていく中で「テストやメンタルヘルス」といった私が個人的にとても興味のあるテーマを取り扱っていることを知りました。私は「そこでプロポーザルを書いて得た学びを共有したい！」と思い締め切りが迫る中プロポーザルを書き始めました。「スクフェス新潟のプロポーザルを読んでYYする会」の当日も無我夢中で書き続けて『「あなたすごい人、私ふつうの人」を乗り越える！経験をプロポーザルにしてみよう』の原案を投稿しました。

YYする会に間に合わせるために気合でなんとか最後まで書きましたがこの時も私は「プロポーザル書いたなんて話私じゃなくてもできるし......」「もっとすごい人がプロポーザルを書いてるし......」という気持ちに負けそうでした。でもいざYYする会でプロポーザルの話をしていると「ぜひ聞きたい！」という声や、より伝わるようにするための具体的なアドバイスをいただくことができて取り下げずにがんばろうと思うことができました。そして再び得たフィードバックを元にプロポーザルをリファインメントし、再度登壇の機会をいただくことができました。

何度でも伝えよう

嬉しいことに新潟での発表を見て「プロポーザルを書いてみよう」と勇気を出してくださった方々がスクフェス大阪にプロポーザルを書いてくださりました。そして「スクフェス大阪のプロポーザルを読んでYYする会」で背中を押してもらっている姿を見て「ああ、あの時勇気を出してプロポーザルを書いて良かった」と心の底から思いました。でも同時に「自分じゃなくてもいいんじゃないか」という感情はそう簡単に克服できることではないということを改めて痛感しました。とても素敵なストーリーを持っているのになかなかプロポーザルを書く手が進まない。であれば何度でもこの想いを伝えよう。「あなたの唯一無二の経験にはきっと価値があるはずだ」というメッセージを送り続けようと思いました。

経験をプロポーザルとして言語化している時に私がどういうアプローチを取っているのか。プロポーザルを書き切る為にどういうことを考えているのか。採択されるためにどういう書き方をするのがいいのか。スクフェス大阪に向けて改めてプロポーザルを書きながら気がついたことについても盛り込みつつできる限りの私の想いをぶつけます。

受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました！が、JTCの荒波に揉まれる我々！

• 期待している形で案件が来ない！
• 支援って、ちゃんと評価されるのか？給料下がっちゃうんじゃないの？
• ３年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく！

毎年お送りしている田舎スクラムチームの状況をお伝えします！

・大規模ウォーターフォールの受託開発のマネジメントを大阪で10数年ずっと実施していたマネージャーがアジャイルでのプロダクト開発組織を作るべく、辞令をもらいました。短期間でアジャイルを学ぶため、どのような事をどのように学んだか？その中で感じた葛藤と解決策をお話しします。

前半パートでは
新たな用語だらけで、ウォーターフォールとの文化の違いが今一つわからない中で、短期間で学習する上でのTipsをお伝えします。

中盤パートでは
「ちょっと何言っているかわかんない」というワードを使いながら、新しいことを学ぶ際にわからない事を前向きに増やしていく重要性とそのマインドセットのコツをお伝えします。

後半パートでは
学習すればするほど、先人のアジャイル先駆者やアジャイルネイティブの若い世代と比べてしまい、恥ずかしさや今までの仕事に対して後悔を感じたこと。逆に学べば学ぶほど自社内では先駆者として孤立してしまうこと
それらに対して、過去の経験をプラスに活かし、仲間と共にどのようにポジティブに乗り越えたかを説明します。

　DXでのリスキリングの必要性が謳われている昨今、リスキリング対象のミドル層が、これから、新規ビジネス創出やアジャイルに取り組む際にヒントになれば幸いです。

＜前半パート(短時間で学習するTips)の事例＞
・本を読み、勉強会資料を作り、勉強会実施を繰り返して机上で学ぶ（「アジャイル/本」の検索ワードでトップとなる）
・アジャイル先駆者との過去時点のDiffを取る
・コミュニティが怖かったところから、３ヵ月で150本コミュニティの参加ブログを書くに至った変化

＜中盤パート(学習のマインドセット)＞
・「ちょっと何言っているかわからない」を重視した学習方法（「完全に理解した」⇒「ちょっと何言っているかわからない」を素早く繰り返す)
・Majorityならではのアジャイルの入り方 (EarlyAdopterと違ってMajorityは効果の確実性を気にする)
・仮説検証型の学習方法

＜後半パート (ミドルとしての乗り越え方)＞
・会社生活、折り返してから始めたアジャイルと20年間の意味
・仲間と乗り越える
・仕事だから(外発的動機)とやりたい(内発的動機)をマッチできるのはミドルの特権
・これから始めるミドル層へのエール

（本セッションでは組織の変化よりお個人の変化に着目しての説明となります。実際にどんな風に組織が変化したかは興味があれば参考資料を確認ください)

私が開発者としてコードレビューをするのは「コードは自分のもの」という意識があるからです。その意識は自分の所属チームだけにおさまりません。別チームがメインで変更を行うコードにも及びます。

今回のセッションではこのモチベーションとそれに伴う行動に至った私の体験談をお伝えします。

私は Rakuten Rakuma の開発組織に所属しております。 Rakuten Rakuma は開発メンバーだけでも大規模な組織であり、複数のチームがいくつかのアプリケーションを開発、メンテナンスしています。 Rakuten Rakuma に join した当時、まだ組織の開発スタイルがよくわからないので、とりあえず、組織内の主要な repository を watch することにしました。 Rakuten Rakuma に join する前に所属していた組織では、「pull request は open されたら自分の手を止めてでもレビューするのが当たり前」というような環境にいた事もあり、 join したてでわからないなりにもレビューをしてみようと思ったのです。このようなきっかけで組織横断でコードレビューをしてみると、だんだんと以下のような気持ちを持つようになりました。

• ユーザーに影響するような変更がプロダクトに入るのかどうかを知りたい
• 将来、自分が関わるかもしれないからどのような変更が入るのか知っておきたい

こういったことを経てどうやら私には「コードは自分のもの」、別の言い方で言えば、オーナーシップという意識が芽生えてきたように思います。

「コードは自分のもの」という意識でコードレビューを行っていくと、コードの変更を自分ごととして考えるようになるので、より真剣にコードレビューをするのは想像に難くないと思います。そして、他のチームのコードが気になって仕方がなくなってきます。そういった経緯で今日も元気に組織横断コードレビューを行っております。

一人の開発者のプロダクト開発への取り組み方を、楽しんでみてください。

G.O.O.D.テストとは何か？そして、なぜそれが誰にとっても大切なのか？

テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか？コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか？もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか？

もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

• G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。（Give）
• O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。（Observe）
• O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く（Open）
• D：エンドユーザーに対する安全性（例えば、プライバシー、セキュリティ、機密性）など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。（Determine）

特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか？

システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

G.O.O.D.のテストをしていますか？それともただのテストですか？

背景

スクラムマスター未経験の状態で前任者から引き継ぎを受けた駆け出しスクラムマスターのお話。
引き継ぎを受けた時点でチームにはある程度自律的に動けるメンバーが揃っていたため、引き継ぎ後も前任者のスタイルを概ねそのまま踏襲していた。
それから2年ほど経ち、メンバーとの1on1やスプリント毎のレトロスペクティブ（振り返り）を通して、チームには以下の課題があると感じるようになった。

• スキルセットの関係から、スプリント開始直後から優先度の低いバックログに着手するメンバーがいた
• 優先度の低いバックログのため、せっかく実装が完了してもテスト、リリースに着手できるまで数ヶ月かかることがざらにあり、メンバーのモチベーション低下に繋がっていた
• ペアプロやモブプロといったチーム内のスキル平準化につながる手法を何度か取り入れるもなかなか定着せず、結局１人１バックログを担当する文化が定着してしまっていた
• 「このままこのチームにいてもスキルアップが望めない」「数年後にスキルが身についている自信がない」というメンバーからの率直な意見が出ていた
• リモートワークに突入するとチーム内の会話やコミュニケーションの量が減り、上記の一人バックログの文化とあわさりチームという意識が減少してきてしまった

「これだけの課題がある以上、スクラムマスターとしてなにかアクションを起こさなければ！」
そんな考えを持ちつつも、彼は彼で人知れずこんな葛藤を抱えていた。

• チームやプロジェクトに対して駆け出しの自分なんかが変化を起こしてしまって良いのか、もはやどこかのアジャイルコーチに任せるべきことなのではないのか
• そもそも先述の課題を課題だと思っているのは自分だけなのではないか
• メンバーやPOは特に変化を望んではいないのではないか
• ベロシティを見る限りでは表面上は特に問題があるように見えず、自分がアクションを起こすことでかえってベロシティが大幅に下がってしまうのではないか（というかほぼ間違いなくそうなる）
• そうなる可能性が高い以上は説明責任を果たさなければならないが、POやステークホルダーからの理解を得られるのか
• むしろ「余計なことをするな」と言われてしまうのではないか
• 日々の業務だけでも時間が足りていないのに、果たしてチームの改革までやりきれるのか

実はプロジェクト内では去年からパイロットチームが立ち上がっており、一足先に「なんちゃってスクラムチーム」からの脱却に成功し、成果を上げていた。
そんなこともあり、今ならプロジェクトの後押しを受けながら変革を推し進めることができるのではないか、と考えていた。

ある日、チームの抱える課題についてSoSMや上記のパイロットチームを含めた他のチームのスクラムマスターに相談する機会があった。
そのとき言われたほんの些細な一言が、一歩を踏み出すきっかけになった。

『とりあえずダメ元でもいいから、いったん率直にPOに話してみたらどうです？もしダメならダメで次の手を考えましょう』

その一言に背中を押され、早速POとチームのメンバーに話をしてみると自分の今までの葛藤は何だったのかと思うほど状況が前進した。
POやチームメンバーからの賛同が得られ、「なんちゃってスクラムチーム」から「真のスクラムチーム」への第一歩を踏み出すことができた。

これから「なんちゃってスクラムチーム」から脱却し、「真のスクラムチーム」への変革を目指す方に向けて、
駆け出しスクラムマスターが実際にチームのカイゼンのために実施した取り組みについて、少しでも参考になるお話ができればと思います。

こんな人に聞いてほしい

• なんちゃってスクラムから脱却し、真のスクラムチームへの変革を目指す全ての方
• スクラムガイド通りのスクラムが実践できているか自信が持てないスクラムマスターやスクラムチームメンバー（デベロッパー）
• 自チームのスクラムマスターが思ったような動きをせずに悩んでいるプロダクトオーナー
• 冒頭に挙げた、チームが抱える課題感に共感した人

鳥取県に縁のある人あつまれ！

私達は、約6年もの間、1万人を超える規模のグローバル企業でアジャイルコミュニティを運営してきました。
発足のきっかけは、あるアジャイルイベントの講演に、偶然にも同じ会社の人が同席していたことに始まります。
その講演で刺激を受け、社内には「アジャイルに興味がある」、「アジャイルをやってみたい」という仲間がもっといるはずだとの想いから、口コミで広がり、草の根として立ち上がりました。当初は20名の会員と幹事6名で運営をスタートしました。
しかし、数年後に、草の根が故の課題に直面するとは思ってもいませんでした。

コミュニティは徐々に広がり発展しました。
自分達がまずは学ぶことからはじまり、社外のアジャイルイベントに積極的に参加しました。
手探りながら、実践者も増え、アジャイルへの理解も深めてゆきました。
次第に活動が認知され始め、複数の部署からトレーニングの要求を受け、新人への教育も含め、のべ100名以上に実施してきました。
また、毎年の社内講演（平鍋さん、川口さん、久末さん、山田さん）も実現でき、常に新しい学びを得る機会も多く、楽しいコミュニティ活動が続きました。

そんな楽しい日々がずっと続くかのように思えましたが、次第に、「予算がない」「幹事メンバーが抜ける」「形骸化（マンネリ）と不調和」など、草の根で始まったコミュニティならではの課題や苦悩が現れ始めました。

「予算がない」：
会社は、組織に対して予算を決めます。しかし、草の根のコミュニティには予算はつきません。
社内講演で誰かを呼ぶにはお金が必要です。社外イベントに参加するにもお金が必要です。
私たちは、予算のある組織や権限のある人を、どうやって探し、働きかけを行ったのでしょうか。

「幹事メンバーが抜ける」：
幹事メンバーはいつまでも、コミュニティ活動を続けられる訳ではありません。退職、昇進、組織ガチャによりコミュニティ活動ができなくなることがあります。しかし、メンバーが抜けることは決してネガティブな面だけではありませんでした。

「形骸化（マンネリ）と不調和」：
長く続けることで、コミュニティ活動が形骸化し、徐々に不調和をもたらしました。
　「毎週全員が定例会に集まらない」「バックログが全然進まない」「支援するのが当たり前？」などの問題が起こり、一体、誰のための活動なのか？という状態となっていました。
そこで、活動の方向性を明確にするためにインセプションデッキの作成を行いましたが、なかなか意見がまとまらず、何度も同じ議論の繰り返しとなり、もう嫌だという気持ちが高まり、さらなる不調和を招きました。
ある時、みんなで話し合いがもたれ、「互いにリスペクトしているのか？」「このまま続けていいのか？」「この活動をやめるか？」という問いが出され、皆がハッとなり、踏みとどまることができました。
　これをきっかけに、草の根の活動では毎回は出席できないという前提を受け入れて、「お互いの尊重」と「やりたい人がやりたいことをやる」という方針になりました。担当を割り振ることをやめ、社内からの要望も、メンバーが嫌だと思ったら断るようにしました。普通だとそこで活動が停止しそうなものですが、その後は各メンバーが主体的に活動したおかげで空中分解せずに今に至っています。

アジャイルやScrumでチームを回していると本当にうまく回っているのか不安になるものです。

私どものチームも同様で、チームの状況を可視化するため色々検討してみましたがうまくいきませんでした。

FourKeysも計測していますが、どうすれば数値が上がっていくのかわからないまま。

最近知ったSPACE（達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency)）という考え方を導入し、私達のチームでは多面的にチームの状況を可視化しようと試みているところです。

その意義と成果をほぼリアルタイムでご紹介できればと思います。

また、SPACE自体は具体的にどの指標を計測するかまでは指示していないため私達がどの項目を選択したのかもお伝えします。

達人たちの見ている世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はもしかして、あの偉人？あの概念？からこの答えに辿り着いたのだろうか？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界を覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

今回は「プロダクトマネジメントの光と闇」をテーマにDeep Diveします。

過去のDeep Dive Expertsとトークテーマ

• Deep Dive Experts - 達人が見ている世界を覗いてみよう - @Scrum Fest Osaka 2021
  • スクラムとヨリを戻した時ってどんな時でしたか？
  • 過去や未来問わず。これは一番タフクエスチョンだな... と思った問いはなんですか？
  • スクラムに合ってる人、合ってない人、がいると思っております。スクラムに合っていない人がメンバーにいると思った時、どのような対応をしておりますか？
  • 皆さん様々な発明やアイデア出しをされ、同時に様々な勉強を日々されていると思いますが、日々の勉強をアイデアに繋げるまでの過程を知りたいです
  • いつから○○を拗らせましたか？
  • 当日のMURALはこちら
• Deep Dive Experts - 達人が見ている推しの世界を覗いてみよう - @Scrum Fest Osaka 2022
  • 心の底から本当にアジャイル推してるの？
  • みなさんのオシは何ですか？
  • お互いの推しポイントをDeep Dive目に推し合って欲しい！
  • 当日のMURALはこちら

プロポーザルの数だけストーリーがある

数年前からRegilnal Scrum Gathering TokyoやScrum Festでは、プロポーザル制によってセッション採択されるようになりました。どのイベントでもたくさんのプロポーザルが提案され、そこからたくさんの素晴らしいセッションが生まれています。

私も採択されてセッションが実現されることを目指していろんなイベントにプロポーザルを出してきました。そして、面白そうなプロポーザルに投票をしてきました。

そんなある日、

• 採択されるかされないかに関わらず、このプロポーザルおもしろそうだからもっと話を聞いてみたい！
• プロポーザルに書かれている内容だけだとわからないけど、実はおもしろいプロポーザルがたくさんあるのでは！？
• セッションにならないというだけで埋もれてしまうのはもったいない！

という想いにかられて、「プロポーザルを見ながらYYする会」というイベントをはじめました。

実験的にはじめてみたところ、参加してくださった皆さんのプロポーザルへの想いやストーリーを聴くことができて、胸がアツくなる瞬間が何度もありました。各イベントのセッションも面白いですが、それと同じくらいプロポーザルYY会もアツいです。

今回はそのプロポーザルYY会の素晴らしさをぜひみなさんにも味わってほしいと思いプロポーザルを出してみました。Scrum Fest Osaka 2023のイベント開催期間中に、ちょうどScrum Fest Sendai 2023とScrum Fest Mikawa 2023のプロポーザルを募集しています。出されているプロポーザルを見ながらYYしましょう。

• Srum Fest Sendai 2023 Proposal
• Scrum Fest Mikawa 2023（募集開始前）

プロポーザルを書いた方へ

プロポーザルを書いた想いを語りたい方、プロポーザルへのフィードバックが欲しい方はぜひ持ち込んでください！

書ききれていなくても、メモレベルでもOKです！まずは持ち込んでみることが大切です。

プロポーザルを書いてみたい方へ

プロポーザルを出すことに興味がある方、プロポーザルを書きたいけどネタがないと思ってる方、ぜひ参加してみてください！

出した人たちがどんな思いでプロポーザルを書いているのか、どうやって書けばいいのか雰囲気がわかると思います。

とにかくプロポーザルを見てYYしたい方

一緒にYYしましょう！

過去のプロポーザルYY会

• RSGT2023のプロポーザルを読んでYYする会
• スクフェス福岡2023のプロポーザルを読んでYYする会
• スクフェス大阪2023のプロポーザルを生みだしながらYYする会
• スクフェス大阪2023のプロポーザルを見ながらYYする会

受託会社で複数チーム（案件）のアカウントマネージャーを務めています。

自分がエンジニアとして関わっている案件はともかく、現場には入っていない案件でもお客様がスクラムチームを組んでされるケースが増えてきました。

スクラムやアジャイルの経験の薄い社員が多く、社内でも積極的に指向する状態でない中、半期に一度の顧客満足度調査では社内でも人前で発言するのがけして得意ではないエンジニアがいるチームに対して「スクラムに積極に関わってくれないメンバーがいる（改善してほしい）」等のお客様からの声を繰り返しいただくことがあります。

また、逆に自社チーム側の進め方としてスクラムを取り入れたいと方法論を相談してくるメンバーもいます。

自身が関わっていない案件から聞こえてくるスクラムやアジャイルに関する疑問や悩み、取り組みなどをお伝えし、皆様からもぜひご意見等をいただきたいです。

私が所属しているスクラム開発チームは、メンバーが3拠点にまたがって所属している、物理的に距離があるチームです。

スクラムへの愛を広めることに燃えていませんか？
社内のスクラムチームをさらに活性化させて一緒に学び、成長したいと思いませんか？

KDDIの社内スクラムコミュニティは、まさにそのような情熱と好奇心に満ちたメンバーたちが集まり、共に「もっと社内のスクラムを盛り上げていこう！」という目的で活動しています。本セッションでは、200人を超える社員が参加したスクラムフェス開催の裏側に隠された熱い想いと実践方法について語ります。

オンラインと現地会場のハイブリッド形式で開催したこのスクラムフェスでは、Talkセッションや、スクラムクイズ、Fun Done Learnのうたなど、学びと楽しみを同時に提供しました。ただ知識が得られる勉強会のような場ではなく、同じ組織の中で苦労したり工夫してる人たちから勇気をもらえたり、共感して仲間を作れたり、楽しさを感じてプロダクトや組織を変えていくモチベーションを得られる大きな営みとなりました。

スクラムを学び、深め、そして楽しむためのスクラムフェスを成功させるための秘訣を共有します。私たちの経験から得た知識とアイデアを参加者の皆さんと共有し、あなた自身の組織でも同様のイベントを開催するための具体的なヒントを提供します。