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

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

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

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

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か月ですが、まだフレッシュな状態で私が何を考え・何をしてきたかを発表することで、同じように社内のコミュニティを盛り上げたい！と考えている人の背中を押すことができるのではないかと思いました。

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

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

私達について

私達は楽天グループでラクマというフリマアプリを開発する部署に所属している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 札幌ではこんなセッションをやったりしています。

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

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

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

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

私が初めてプロポーザルを投稿したのはスクフェス福岡でした。そこで私は初めて参加した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 したてでわからないなりにもレビューをしてみようと思ったのです。このようなきっかけで組織横断でコードレビューをしてみると、だんだんと以下のような気持ちを持つようになりました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラムマスターは孤独、と言われますが、どう思われているでしょうか？

前職で、（外部コーチの方はいたものの）社内にアジャイル・スクラムの導入を進め、スクラムマスターとして、チームと伴走を続けていました。

スクラムマスターが自分1人という状況で、頼られることは、嬉しいことでしたし、貴重な経験とレベルアップにつながったと思っています。

一方で、僕自身がアジャイル・スクラムについて壁打ちしたい、スクラムフェスやコミュニティから持ち帰ったものを議論したい、というときに、社内ではそれができず、少し物足りなさを感じていました。（今、客観的に思えば、自分のマインド・巻き込み力のなさゆえで、立ち回りようはいくらであったと思いますが…）

その後、色々と事情があり、現職に転職することになるのですが、配属先以外にもスクラムで開発しているチームがいる、と聞いた私は一人、「他のスクラムマスターやアジャイル実践者と、相談や情報交換を気軽にできる場を社内に作れたら、めっちゃ楽しいんじゃね？」と思うのでした。

始動から約1年半、ちょっとずつ参加してくれる人も増え、コミュニティ内の相談や情報交換だけでなく、スクラムマスター不在のチームが外から相談に来てくれたり、会社的にスクラムマスターの立ち位置を作る運動がおきたり、想定外の効果も発生しだしているのを、わくわくしながら眺めています。

このセッションでは、私が社内アジャイルコミュニティをどう立ち上げ、運営を続けるために何をしてきたか、コミュニティがあることでどんな嬉しいことがあったかをご紹介します。

かつての私と同じように、もっと会社でアジャイル・スクラムの話をしたい、社内でアジャイルコミュニティを作りたい、と思っている方に、実際にやってみた一例を伝えると共に、行動のきっかけになれるようなセッションにしたいと思っています。

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

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

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

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