Scrum Fest Mikawa初開催おめでとうございます。
今回の会場である三河、そして豊橋は実は私のルーツ（故郷）です。この地でキーノートをさせてもらえることが本当に嬉しいです。イェイイェイ！
※今回のイベントは参加者の皆さんはオンラインでの参加です

さて、自分にも皆さんにもそれぞれのこのイベントに参加するまでにたどってきたスクラムのルーツがあります。

• なぜスクラムにたどりついたのか

• いまスクラムと携わっているのはなぜなのか

• そして、これから先スクラムとどう向き合っていくのか

このキーノートではそれぞれのルーツをたどりながら、スクラムに真正面から向き合ってみる時間にしましょう。

Agile and Scrum

変化に柔軟に対応し顧客の求める価値を素早く提供する。Agile時代の今、Scrumは私たちエンジニアにとって１つの楽しめるコンテンツとなっています。

しかし「Agile＝Scrum」という関係が成立しないということは、みなさんご存知だと思います。成立もしなければ、歴史が最も長い訳でもありません。

Agileを示すフレームワークは他にもあります。

１）Kanban

２）Extreme Programming(XP)

３）Feature-Driven Development(FDD)

４）Crystal Methodology

Scrum for Happiness

では、何がScrumをAgileのメインストリームにしたのでしょうか。

それはScrumが単に「素早さ」だけを求めるのではなく、最高の価値としての「幸せ」に焦点を合わせているからではないでしょうか。

Rakuten Ranking's Challenge : From Kanban to Scrum

大阪に拠点を置いている楽天ランキングサービスグループのフロントエンドチームはKanban方式でプロジェクトを進めてきましたが、Scrumが持つ価値に共感し、Scrumへのマイグレーションを推進しました。現在、導入してから半年が経ちますが、私たちのチームは幸せになっています。

何を持って幸せだと言えるか。

マイグレーションは決して順調ではありませんでした。

その過で何が大変だったのか、また何が私たちを強くしたのかなどをKanbanからScrumへの移行を考えてる方、Scrumの導入をためらっている方にお伝えします。

「アジャイルと一歩距離を置いたつもりで、変化に対応するってよくつかっていませんか？」

良いシステム開発を目指してスクラムを中心に経験をつんだチームがいました。チームは機能するようになり、システム開発の様々なスキルも習得していきました。スクラムという門を潜って見えてきたのは、アジャイルをやりたいわけではないという言葉がかわされつつも、「変化に対応する」という言葉を盲目的に使い、アジャイル開発の信念に疑いがないことでした。スクラムをうまくできるようになっていても、アジャイルの概念を盲目的に信じているのではないかと。

チームは自分達を見直すために、変化に対応するというのはどういうことかを考えなおし、自分達の開発をみつけはじめました。
アジャイルやスクラムに停滞感を感じている人達に共感をもってもらえるストーリーがはじまります。

2020年6月、新しいプロダクトを開発するために、1つのスクラムチームが生まれました。

このスクラムチームは、PO・SM・Devの3人からなる小さいチームです。
そのうち2人はアジャイル・スクラムの未経験者でした。

最初はプロダクトの掛け持ちにより、全員が1週間のうち2日しかプロダクトの活動が出来ない
という状態からこのチームははじまりました。
このチームの周辺では、掛け持ちが当たり前の世界観であり、どのチームも成長・変化はゆるやかなものでした。
きっと、他のチームと同様、このチームも成長していくには、時間がかかると思われていました。

このチームがはじめにやったことは、アジャイル・スクラムの世界を広げることでした。
経験者に連れられて、コミュニティに参加して、様々な本を読んで、チームで語り合って。
プロダクト開発に必要な業務の傍らで、自分たちの世界を広げよう、と手を伸ばし続けてきました。

そして、チームに転機が訪れます。
それが、「Scrum Fest Osaka 2020」です。

チーム全員で、このフェスへ参加したことがきっかけで、私たちの変化のスピードにブーストがかかりました。

永瀬美穂さんのキーノート、「今あえてのスクラム」。
kyon_mmさんと及部さんのキーノート、「Agile Wars − アジャイルチームの夜明け −」。

これらのセッションに参加したり、登壇者・参加者たちの話を聞いたり、ワークに参加したり、参加者同士で語り合ったり。
セッションの合間では、チームで「明日からこうしたいよね」「これは試したい」など感想戦を行っていました。

きっと、一人でフェスに参加するだけでは、
　「こうしたいなぁ」
　「でも難しいだろうなぁ」
という願望で終わってしまっていたでしょう。
熱量を心に秘めたまま、発露できずに終わっていたでしょう。

でも、チーム全員で参加することで、フェスで得た熱い想いが霧散することなく、
　「こうしよう」
　「やってみよう」
という実験をする勇気が湧いてきました。

そして、フェスの夜が明けて。
次のスプリントから、私たちの実験が始まりました。

手始めに行ったのは、フラクタルスプリント。
1週間だったスプリントを3時間単位に区切り、3時間ごとにインクリメントを作り上げるようにしました。

そして、モブプログラミング。
モブ・ペアでのワークをチームの文化として積極的に取り入れ、
チームが「チームである」ということをより実感できる動き方を実現しようとしてきました。

このプロポーザルを書いている今、まだSprint#8の途中です。
でも、フラクタルスプリントを取り込んでからは、変化のスピードが劇的に加速しているのを感じています。

Scrum Fest Mikawaでは、きっと、
　大きく変化した私たちの姿と、
　それまでたどってきた変化の軌跡（奇跡）
を見せることができるでしょう。

今まで、コミュニティに参加したこともなかった、登壇もしたこともなかった、
ブログなどへのアウトプットもしたことがなかった。
そんなチームメンバーが、どのように変化していったのか、を皆さんにお見せします。

そうすることで、私たちがそうだったように、
次の新しいチームへ、この勇気のバトンを渡せると信じています。

7月に漫画最終回を迎えた「ハイキュー!! がアジャイル方面のコミュニティでもじわじわと盛り上がってきています。チームの成長の物語であり、個人がチームや自分の実力・振る舞いとどのように対峙するかを丁寧に描く作品に、多くの人が共感と学びを感じています。バレーボールのルールを知らなくても大丈夫。6人で強い方が強い。ハイキュー!! の物語を通じて、チームで業績を上げる方法について考えてみましょう。

田原の出身なのですが高校は豊橋に通ってまして、バレーボール部の部員でした。といっても、大した運動能力もなくずっと補欠で楽しくやっていたのですが、先輩方から様々なことを学ばせていただいた気がします。出場選手6人だけでない周りを含めたチームの動き方は、そこで学んだんじゃないかと思います。そのあと、企業ITの道に進んだり、スクラムに出会ったりする中で、Production IG制作であるところのアニメ「ハイキュー!!」、そして原作の漫画に出会うわけです。

約一年前、他社向けアジャイルコーチとして転職し、10チーム以上でのスクラム導入を支援してきました。

社員と会社の関係だけではなく、働き方も変わりました。
例えば、アメリカでたくさん大きい会社には十二月まで社員が事務所に行けないです。だから、会議とトレーニングが変化しなければなりませんでした。コーチとしてそれは私の仕事です。

この発表には、新しいと役に立つのスキルでRemoteの会議とトレーニングをパーワーアップしましょう！

3人の小さなスクラムチームで、とあるプロダクトの新規開発、リリース、運用をしています。

スクラムはフレームワークであり、スクラムのスキルを身につけた上で、実際のプロジェクトではプロダクトの特性、開発フェーズ、組織フェーズなど、その状況に応じてプラクティスやツールを取捨選択していく必要があると感じています。

本セッションでは、8ヶ月間スクラムチームで開発をしながら、開発チームの1メンバーとして考え、実践したこことについてお話します。

スクラム開発を1年くらい経験しています。

日々リファインメントを行っていますが、気の赴くままに会話を重ねてその結果を転記している感じでした。

そんな時に出会った Scrum Fest Osaka 2020 ！

そこでの学びをプロジェクトに活かしたお話をします。

入社４年目の若手SEです。

配属から２年間、開発PJに携わりたい！と訴え続け、待ちに待った開発PJへの参画。

アジャイルやるよ！って始まった新規チームの軌跡。

涙なくして語れない大失敗からの学びをお伝えします。

始めてのスクラムは難しい。今回の学びが少しでも皆さんの助けになれば幸いです

大学生と院生が対象のアジャイル開発プロジェクト（enPiT）の
担当教員になって7年目になります。

授業には、受講生、メンター（この授業の修了生）、教員がいます。
その間には「教える」「教わる」という縦の関係があり、
講義・演習系の授業に比べると近くはあるものの確かに縦の関係は存在していました。

それが、去年あたりから研究活動をアジャイルに進める試みを有志で始めたのをきっかけに、
教員、メンター、受講生の関係がフラットになり始めたと感じています。

教員とメンターが研究という共通の「複雑で不確実なもの」に対峙することで同じ視点に立つことになり、アジャイルに研究する方法を作り上げていく同志となりました。

さらにその活動を受講生のDiscordやSlackで公開して進めていくことで興味を持った受講生もそこに混じりはじめ、ともにアジャイルに模索をする戦友という関係が生まれ始めました。

そんな話をしようと思います。

スクラムチームにおいて、日々ぶつかるチームの課題。

多くのスクラムマスターがふりかえりやあらゆる対話の場でこれらを解決すべく、ファシリテートを行なっていると思います。

一方でスクラムイベントについては書籍や勉強会学べるものの、その場その場で起こる問題解決の変え方(≠手法)は学べません。

　そこで本セッションを通じて、下記に軸をおいた課題解決の考え方に触れていただき、自身のチームへ持ち帰っていただければと思います。

• 「問題思考」ではなく「解決思考」(参考：ティール組織におけるSDMIモデル)
• スクラムマスターではなく、チームが課題解決するためのファシリテーション(参考：自己組織化への具体的なプロセス)
• 「承認プロセス」「合意(コンセンサス)」「助言プロセス」の考え方

デンソーのデジタルイノベーション室は、自社サービスを立ち上げるために新規に作った組織です。

開発スタイルとしてスクラムを取り入れて素早く市場のフィードバックをプロダクトに取り込んでいます。

一般的にスクラムでのエンジニアは多能工と言われていてチーム内ですべての必要なスキルを持つべきと言われていますが、商用サービスを開発していくうえで"性能"、”信頼性”、"クラウドの知識"、"セキュリティ"といった特に専門性が求められる領域で技術的な課題がでてきました。

これら特に専門性が求められる領域のスキルを持つエンジニアは限られており、かつどのプロダクトでも考慮しなければいけない共通の課題でした。

デンソーではこれらの課題を解決するべく、チーム横断のSite Reliability Engineering(以下SRE)チームを立ち上げてチーム共通の課題に日々向き合っています。

本プレゼンではSREチームの活動について

1. 技術的課題の解決のための取り組み
2. コミュニケーション改善のための取り組み

についてお話します。

努力・根性・忍耐がとにかく苦手で弱虫な僕
嫌なことには一切手がつけられません。
ずっと罪悪感と劣等感に押しつぶされそうに生きていく中、
あるときふと気がつきました。
嫌なことをやめるだけでチームの価値が上がる！
今回は、その経験や価値観を交えてどうすれば嫌な事をやめれるか？をご紹介しようと思います。

弱虫な僕の活動

SIerでマネジメントをしながら、夫婦で小さな照明屋さんを起業したeroccowaruico。
オリジナル商品を開発して製造して販売する。
その過程には僕には絶対できない事務処理以外にも、想像を超えた法規対応など嫌なことが大量にありました。
それでもなぜ起業し、eroccowaruicoの休職や転職も乗り越え今でも続いているのか？
赤字が続く事業を家庭に持ち込んだ僕たち夫婦はどう歩んでいるのか？

そこにはSIerのマネージャーとして取り組んだ『嫌なことを徹底排除する』取り組みがあります。

自分ができない事を他人に押し付けるためマネージャーになった弱虫が、
嫌なことをやめる過程でチームのメンバーから学び、個々のメンバーの苦手な事を取り除いた結果、めちゃめちゃ個性豊かで優秀で最高なチームができいた話も織り交ぜながら、嫌な事を止めるとなぜ最高のチームになるのか？その秘訣をお話しします。

この考え方はチームビルディングの初期段階から導入できる上、
スクラムをはじめとしたアジャイル手法とも相性が良くチームの成長を加速させれると考えています。

この内容を発表しようと思った理由

スクラムフェス大阪2020の三河トラックで
『弱虫じゃダメですか？（ダメ人間がチームビルディングをしたら最高のチームと歩めた話）』の発表時に
「嫌なことを止めるだけでチームの価値が上がる事を信じられますか？」と質問したところ、
「信じれる」が6人に対し「信じない」が8人という結果となりました。
その割合を見るも「嫌なことをやめる」こと自体が出来そうで出来ないと思う人や、
そもそも嫌なことはなくならないと思っている人が多いと思いのではないのではないか？
それならみんなで嫌なことをやめればいい。
みんなの価値がもっともっと上がると思ったんです。

弱虫の経験や目線を通して、少しでも仕事が楽になるような考え方も交えながら、どう価値が上がったのか？をお伝えしたいと思います。
大切なことは何回も伝えるので、『弱虫じゃダメですか？』の内容を知らない方も、安心して聴ける内容になっています。

このセッションに参加すると

嫌な事をやめるだけで

• なぜメンバーを大切にできるのか？
• なぜチームの価値が上がるのか？
• 尖ったチームになり得るのか？
• スキルの高くないメンバーも活躍できるのか？
• お客様に価値を認めてもらえるのか？

が、わかるだけでなく、次の日から実践できちゃうかも知れません。

Rettyには７つのスクラムチームがあります。
これまではホワイトボードと付箋を使って物理的なカンバンを使っていましたが、リモートワーク主体の働き方へと移行するにあたり、電子ツールの利用を開始しました。

実際に各チームで使っているカンバンを通して、リモートワークでの運用事例をご紹介します。

入社3ヶ月、複数人での開発経験(ほぼ)なし

導入されたばかりのスクラムチームに配属され2ヶ月、チームの分割に伴い新たなスクラムマスターが必要となりました。

「新卒でもできるよ」なんていう甘い誘いにのり、スクラムマスターになった新卒の自分語りをします


スクラム開発なんて

「スプリントというものがあり、その中にいくつかのイベントがあり、

なんかその時にポイントがタスクごとに割り振られるので、頑張ってポイントを消化しよう」

程度の理解しかしていない状態からのスタートでした。


9ヶ月ほどのスクラムマスター経験の中で感じたメリット/デメリット、ぶつかった壁などを話して行きたいと思います


「スクラムマスターいいじゃん、やってみよ」と思っていただければ嬉しいです

このセッションでは、元々SIerでアジャイル開発をやったりアジャイルコーチをやったりしていた人間が、全く環境の違うスタートアップでどういう価値発揮をしたかに関して話します。

SIerでずっとアジャイル？なにそれ？というプロジェクトに赴き、アジャイル、スクラムの概要を説明して、ちょっとイベントのファシリテートして、そして帰ってくるということをずっと繰り返していました。
このままではアジャイルにだけ詳しい何も出来ない人になってしまうと焦っていたときに、なんとなく憧れていたスタートアップ。

自分が理想郷を夢見ていったスタートアップで出会った現実、そしてやったことなどをユーモアを交えつつ話せればと思います。

また、SIerで培った自分のアジャイルコーチとしての能力はスタートアップで役に立つのか、スタートアップでどんなことをしているのか、今スタートアップで働いていてどうなのかとかなども話す予定です。

去年までバリバリのメーカー下請けソフトウェア制作を8年続けてきました。

会社の異動があり、新しくできた製品開発部門へ。そこで取締役から役割の説明が。

「プロダクトの面倒を見てほしい、プロダクトマネジメントをやってほしい」

ん？僕今まで請負しかやってこなかったし、そもそもプロダクト開発フローってちゃんとしらないし（ウォーターフォール万歳）。

やったことないけど、でも面白そうだから頑張ってやってみるか！

しかし、今までプロダクトマネジメントの文化すら無い企業で、

どうやってプロダクトマネジメントを浸透させればいいのか？

企業特有の世代間ギャップに悩まされながら、他メンバーの請負根性と闘いながら、データドリブンじゃない感情に任せた企業文化と闘いながら、

1年間社内で戦ってきて分かったことと、次の1年どうしていこうかと、そんな話をしようと思います。

僕みたいに「受託ソフトウェア開発会社からプロダクト企業へ」という転身を考えられている方の一助になればと思います。

小学校の先生であるIKUにmiroを教えて、歴史の授業を小さくmiroで始めた話です。
制約が多い学校の中で新しいことにトライするには色々な障害がありましたが、IKUは心が折れかけながらも一歩ずつ頑張りました。
何よりも子供たちが一生懸命に、そして楽しそうに勉強している姿はとてもうれしいものです。
あっ 最近は歴史だけじゃなくて、理科の授業でも使いたいと子供たちから提案がありました！

当日はnemorineとIKUの二人でお話する予定です。

このセッションでは、スクラムの導入から、スクラムチームをスケーリングして複数のフィーチャーチームに拡大するまでの取り組みについて、取り組み内容とその気づきをお話しします。

私たちは約2年前にスクラムチームを立ち上げ、当時は10名程度だったスクラムチームも、現在では5チームになり約40名を数えるまでに拡大しました。

最初は、アプリ(iOS/Android)チームにスクラムを導入しました。当時はバックログはサーバーチームと別々に存在し、POはそれぞれのチームに仕様を説明していました。また、仕様はPOが作成し、開発チームは決まった仕様を作る・・・そんな状態でした。

現在は、アプリとサーバーが同じチームになり、フィーチャーチームとして最優先のバックログに取り組むことができるようになりました。

ここに至るまでに様々取り組んだことや、苦労した(している)ことなどを是非シェアできればと思います。