Fun Done Learnが誕生してまもなく5年。

これを機に原点回帰してチームとして本質的にアジャイルであり続けることとはどういう意味なのか、そのためには何が大事なのか、そしてそれがどうFun Done Learnに繋がったのか、ふりかえります。Fun Done Learnで。

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

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

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

マネジメント 3.0には、33の魅力的な楽しいツール、ゲーム、実践があります。
今回のミニワークショップでは、ストーリーを語る時にとてもパワフルな２つの「即興カード」を体験していただきます。物語として語ることは、普通に話をするよりも相手の心に響き、印象に残りやすくなります。
ストーリーテリングとは何か、相手に届く伝え方とは？
複雑な問題を解決するためのアプローチや、語る力を鍛えることで、どのように変化するのかをお伝えします。
普段はマネジメント3.0の即興カードを使いますが、今回は語ることの練習として、グループ内で面白いストーリーを作るのに適したカタルタを使います。
語り（ストーリーテリング）は、複雑な話題の説明や相手を説得する時、新しい洞察や過去の出来事とそこからの学び、変化を起こす時など、多くの場面で役立ちます。
優れたストーリーテリングのスキルは、ビジネスや日常生活のコミュニケーションにおいてとても重要です。
チームでの語りに最適なマネジメント 3.0 の即興カードとカタルタのストーリーテリングカード。
どちらもとても楽しく、すぐに実践できるカードなので、次の日からそれぞれの職場に合わせて使えます。ゲーミフィケーションを通して、２つのカードの魅力をお楽しみください。

即興カードの使い方

 ストーリーテリングを語ることは、最も古い情報伝達の方法であり、新しいアイデアを開花させる場でもあります。聴衆と効果的につながるために、語り手は即興で話をすることができなければなりません。生まれつきのストーリーテラーはほとんどおらず、マスターするにはかなりの練習が必要です。即興カードは、ストーリーテリングと即興のスキルを向上させるための素晴らしい練習方法です。また、チームビルディングにも最適です。 

このセッションは、プレゼンは少なめにし、体験をメインで行います。一緒に楽しみながら学びましょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラム開発うまくいってますか？

うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。

つまり守破離って大事ですよねと。

”スクラム　アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ！」と散々警鐘が鳴らされています。

そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。

例えば・・・

• エンジニアが3人未満のチーム構成
• 全員が他の開発業務を掛け持ち
• スプリントバックログが常に終わらない
• 不完全なインクリメントでスプリントレビュー
• デイリースクラムをやめる  ...etc

なぜ安直なアンチパターンを踏みまくったのか。

起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。

アンチパターンを踏みまくった結果、このチームやプロダクトはどうなってしまったのか。

スクラムアンチパターンを踏みまくったときの話をしようか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お悩み例

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

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

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

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

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

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

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

「観察さえ上手くなれば、もっとチームのことを理解できるはずだ！」

以前の私は、そう考えていました、、、

このセッションでは、人類学のゼミに参加した経験をもとに、人類学的視点がどのようにチーム支援に役立つかをお話します。

支援する立場として感じた効果は、下記のようなものです。

• チームメンバーと向き合い、チームで起きていることに気がつくことがよりできるようになる
• チームで起きていることに向き合い、受け入れることができるようになる
• 自分の持っている思考の偏りやフィルターに自覚的になることができる

また、チームの支援を行う立場にいなくても、自分のいるチームをより良くしたいと思う人が、実際に働きかけを行う時に人類学的視点がどのように効果を発揮するか、私の経験をもとにお話ししたいと思います。

自分のいるチームをより良くしたいと思う立場として感じた効果は、下記のようなものです。

• 始めるべき難しい会話を始める勇気が出る
• 相手と分かり合えない状況になった時に、その場への向き合い方を持ちやすくなる
• 対話を避けるのではなく、小さく対話(会話)から始める動機が持てる

私たちIIJ名古屋支社は、開発ベンダーとして約4年間アジャイル・スクラムでお客様のビジネス拡大に貢献していきました。

手応えを感じた理由として、ビジネスへ前のめりなスクラムチームが成長してきたからです。

スクラムチームは開発者もビジネスを意識することが価値を生み出す上で重要なポイントとなります。

しかし、ベンダー主体のスクラムチームでは開発者のビジネスへの意識が弱くなる傾向にあります

これは受発注の関係性やお互いの立場、地理的問題が大きく影響すると感じています。

そして、開発者のビジネスへの意識が弱くなると以下ような問題が発生します。

• プロダクトオーナーの言われた通りに "作る" だけになる
• "作る" だけに専念してしまい、提供する価値を意識しなくなり、"作る" が目的になる
• 価値を意識しなければ結局従来型開発と同じ結果となり、両社とも「こんなはずじゃなかった」となる

少し極端ではありますが、実際経験された方もいるのではないでしょうか？

プロダクトオーナーが遠くなりがちなスクラムチームに起きやすい問題であり、私たちはこの問題に対し真摯に向き合ってきました。

私たちアジャイルベンダーがどのようにこの問題に対しアプローチしていったか、そして組織に適用するためにどんな組織作りをしていったかをお話したいと思います。

これはベンダーだけが起きる問題ではなく、ビジネスサイドと開発サイドの意識の差によってはどのスクラムチームでも起きる問題と思います。

内製しているチームでもプロダクトオーナーと開発者が別組織や立場が異なると、同じ問題は発生するでしょう。

スクラムチームが上手く機能していない、プロダクトオーナーと開発者の関係がギクシャクしているなどの悩みを持っている方は是非聞いてほしいセッションです。

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

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

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

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

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

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

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

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

この経験を届けたい

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

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

何度でも伝えよう

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

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

変化の激しいモバイルゲーム市場では、変化に適応してより良い体験をユーザーに届けることが必要です。エンジニアチームも柔軟に変化する状況に適応できるチームであることが求められます。例えば「特定の機能は特定の人しか触れない」属人化状態だと、その機能の改修要望がたくさん来たときに、その人がクリティカルパスになってしまいます。

若手リーダだった頃の私は変化に強いチームでありたいと考えたときに「私がリーダーなのだから、私が全ての変化をリードしないといけない」と考えていました。しかし、リーダーとして色々な取り組みをする過程で「リーダーだけではなくエンジニアチーム全員がリーダーシップを持つことが、変化に強くなるためのポイントである」と考え方が変わりました。

実際に変化を起こしていくのはリーダーではなくメンバーです。私たちのチームでは、個々人がリーダーシップを持ったエンジニアチームを起点として、プロダクトに良い影響を与える取り組みをしています。例えば、モブワークの取り組みを広げたり、非エンジニアの業務効率化ツールを自主的に作成したり、機能開発のやり方を少しずつ変えてみて高品質なアウトカムを模索したりしています。

本セッションでは、変化に適応するエンジニアチームとはどんなチームでなぜ必要なのか、そして、そのようなチームになるためにリーダー、またはエンジニアはどのようなことができるのかについてお話します。

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

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

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

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

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

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

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

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

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

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

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

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

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名以上に実施してきました。
また、毎年の社内講演（平鍋さん、川口さん、久末さん、山田さん）も実現でき、常に新しい学びを得る機会も多く、楽しいコミュニティ活動が続きました。

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

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

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

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

The biggest challenge for organizations is adapting fast enough before smaller, nimble competitors take their market. Creating an outcome-driven organization is about aligning every aspect of the business toward achieving the outcomes that matter. It requires a shift in mindset, processes, and culture. Gabrielle Benefield, with her vast experience in guiding organizations through Outcome Delivery for the enterprise, will delve into the essential principles and practices necessary to drive successful outcomes. 

スクラムフレームワークに沿ってイベントをこなしながらプロダクトを作る。

一般的なスクラム開発を進める中で、ふと違和感を持ったことありませんか？

「ウォーターフォール開発を短期間で分割して開発してるだけでは・・」

「ラグビーチームのような一体感を持ったイメージと何か違う・・」

私がスクラムマスターを担当した ”とあるチーム”も、上記のようにスクラムを淡々とこなしているチームでした。

プロダクトの価値やチームの成長について熱く語るようなチームになって欲しいと願い、スクラムマスターの立場から色々とチームに働きかけても変化を起こせずにいました。

そんなある日、ちょっとしたことがきっかけでチームが生まれ変わりました。

それはチーム内から起きた内発的動機付けによるものでした。

生まれ変わったチームは、優れたプロダクト体験・機能を素早く届けることにこだわり、メンバー間が相互のタスクに興味を持って助けあい、スプリントゴールを懸命に追いかけるようになりました。

振り返ると劇的な変化が起きたので、他チームでも活用できるようにいつか情報を整理したいと思っていました。

今回の発表はちょうど良い機会なので、チームを変えた内発的動機付けについて考察のうえ言語化したいと思います。