組織で初めてScrumに取り組んだ時によく出てくる話題の1つに"スクラムマスター"が出てきます。

理由は様々でしょうが、その1つに"これまでの組織の役割になかった"ということがありそうです。そのため、そもそもどんな目的なのか？なにをすればいいのか？なにはしないのか？などの疑問が湧いてくることあります。

このような疑問をうまく消化できないとスクラムマスターとして活動している人たちもスクラムチームも、そしてよりよいプロダクトを届け事業成長したい組織にとっても損失が生まれることもあります。

このセッションでは、そのような残念な結果にならないために、"スクラムマスターってなにをもたらすの？"というテーマでお話します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私達について

私達は楽天グループでラクマというフリマアプリを開発する部署に所属しているSoftware Engineerでして、主に広告や事業者向けの機能を開発しています。

ラクマは現在楽天グループが運営・開発しておりますが、前身は日本初のフリマアプリ「フリル」でして現在は3500万ダウンロードされております。

私達3人は同じチームに所属しているのですが（マネージャーを含めると4名体制です）、基本的に毎日始業から終業までをほぼモブプログラミング・モブワークをしています。（以下モブワークと総称します）

チームとしてもScrumを取り入れていて、ほぼ全てのバックログをチームで取り組んでおり究極の一個流しをチームで実現させようとしています。

毎朝Daily Scrumでその日に取り組む事を皆で話し合って決め、そこから途中こまめに休憩を挟みつつ基本1日中終業までモブワークを行っています。

これまではリモートで仕事をすることが中心だったので、Zoomを繋げっぱなしにしつつコードシェアをしながら役割を10分タイマーで交代しながらモブワークをしています。

コロナが落ち着いてきて関係で楽天では出社が増えてきておりまして、全員出社してる時は一つの場所に集まって同じ画面を見ながらワイワイモブワークをしています。

モブの皆さんと呼ばれるまで

私達は今組織の中で「モブの皆さん」と呼ばれています。

これは個人としてではなく、チームとしてモブワークを実践してきた事が周りの皆様にも認知してもらっている結果だと思っています。

ですがチームが出来た1年半ほど前はそんな事は全くなくて、発足当初はメンバーの4名中2名が入社したばかりでRails経験が浅い状態かつOJT中だったのもあってか、多くの課題を抱えていました。

• 業務の量に偏りがある
• レビュアーがいない
• さらに育成者もいない

そしてリモートワークが長引いていた関係で、メンバーの一人一人が不安を抱えながら開発をしていたという状況にもなっていました。

そんな状況を見て当時のマネージャーがモブワークを取り入れてみることを勧めてくれました。

そこからおよそ一年半、チームメンバーが減ったり、新しく増えたりなど色んな歴史を経て今に至っています。

途中チーム外の方から「分担作業の方が良くない？」というご意見をいただいてうまくチームとして方針を伝えられなかった事がありましたが、その時はマネージャーが間に入って盾となってくれて色々と関係各所との調整を行ってくれました。

試練の訪れと振り返りのきっかけ

そんな私達に大きな衝撃が走ったのは、私達にモブワークを導入して支援してくれ、チームの文化を築いてくれたマネージャーの退職が決まった時です。

当たり前の事なのですが盾となってくれていたマネージャーがいなくなった事で「これからは自分達で戦っていかないといけない」となり、改めて「私達はなんでモブワークをしているんだっけ、なんで良いと思ってるんだっけ」と考えさせられました。

そこからモブワークについて改めて調べ直し、言語化していく中で他チームから「モブワークについて教えてほしい」と言われる事が増えてきました。

自分達では何かを教えられるほどモブワークについて上達したつもりはなかったのですが、それでも通ってきた悩みや良かったことを共有することで双方で学びや発見がたくさんある事に気付けました。

これからの私達

現在絶賛トライ中なのが「目標設定とモブワーク」の問題です。

私たちも会社員ですので、目標設定とその評価というビッグイベントから逃れることはできません。

チームとしてタスクを成し遂げるのに、目標を立て評価をされるのは個人単位です。

これにどう向き合っていくのが良いのでしょうか。

今季の目標設定では「チームとして共通の目標を作ってそれを個人目標に組み込む」という新しいアプローチを試みています。

これはマネージャーと相談して、チームでのモブ活動に対して理解してもらおうと試みた一例になりますので、皆さんに紹介したいと思っています。

今回のセッションでは以上のような私たちのモブワークの歴史を共有いたします。何かの発見や学びに繋がったら幸いです。

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

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

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

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

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

例えば・・・

• エンジニアが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.のテストをしていますか？それともただのテストですか？

私達は、約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. 

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

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

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

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

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

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

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

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

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

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

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