Most Scrum practitioners today follow the katas of their training, dutiful to all that they correctly answered during the certification exam. For many, it is a struggle to get even this far: letting go of old waterfall ways to work in small, cross-functional teams that deliver at lightening pace. Yet the framework and certification are only the beginning. Patterns drive to the why beneath the framework and its practices so you discover your most fully human self that you were born with, and which the university and your job drove out of you. We’ll explore this why a bit. But even patterns are only a taste of the transcendence that comes with insight. In that transcendence we find the secret that few know about Scrum, or that they ever find about patterns: that each is only a path to finding your own deeper self, not only in a way that contributes to its respective discipline, and to work, or to design, but to the greater good of the self and humanity.

Your organization has moved to autonomous, self-organizing teams. Everyone is trained and coached on their new role. But what about managers? The role of a manager is _undefined_. Management is told, “Go figure out your new role” or simply “Stop micromanaging”. They are often still responsible for the outcomes, yet are stripped of authority. It turns out managers are people too - and their treatment is often inhumane and unhelpful for creating lasting change. Managers were seen as the glue that holds an organization together … now what happens? How can we all journey together?

We offer an alternate view, where Agile Transformation is understood as an evolution of organizational culture. Success depends on shifts in the behaviours of both staff and management. The Agile Mindset or Being Agile is a prerequisite for making structural changes. Jumping to advanced stages of evolution where there is high autonomy is a painful trap. An incremental and iterative (Agile) approach to shifting power away from managers to individual contributors is more effective.

アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。

2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。

世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります（アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです）。

本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

チームの再定義 -フラクタルスプリントとフラクタルチーム-

1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

大企業で新規事業を始めるために必要なものはなんだと思いますか？予算ですか？社内政治ですか？そう！違う！そう！

プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

　アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

　しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として４年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

　チーム（ないしは会社）そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

English follows Japanese.

---

アジャイルな開発においては、アナログなツールもデジタルなツールも大切な活動のための友達です。

このセッションでは、アジャイルもテクノロジーも成熟してきたなかでうまれ、乱立されてきたデジタルなツールについて、基本に立ち返ってどんなツールが求められているか、どんなツールをあなたの現場で選べばいいのかを考察していきます。

せっかく使うツールならば自分たちのための、自分たちの創り出す価値のためのものを選びましょう。

ツールから学ぶバリューチェーンのような内容にするつもりです。

なお、本セッションでは特定のツールにフィーチャーすることはありません。

---

It is important to become friends with tools (both analog and digital) as Agile team. In this session, I will consider about digital tool(s) following points of view returning to the basics.

• What tool(s) are needed with Agile
• What tools(s) should you choose at your Agile team

I will share to learn "flow of value" from tool(s) with you in this session.

あなたのチームはいつ死にますか？

スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM（安定したチーム）」はScrum Patternsの1つになっています。

安定したチームは本当によいチームなのでしょうか？

私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

• チーム転職できました #チームFA宣言 #完結編 #アフターストーリー

私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM（安定したチーム）」はSAME TEAM（同じチーム）ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

あなたのチームはいつ死にますか？

このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

スクラムショーワークショップは、yycr2019（アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート）で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

皆さんも、スクラムショーワークショップを実施してみましょう！

紹介動画はこちらから！

詳細はこちらの記事をご参照ください。

UX屋さんは言います「ユーザーテスト（ユーザビリティテスト）は製品の利用品質を目覚ましく向上する」と。でも、専門家に頼むと結構な金額の請求書が届くかもしれませんし、社内でやると結構な手間がかかるかもしれません。結局、まだ「やったことがない」「見たことがない」という人が多いのかもしれません。

そこで、このセッションではスマホアプリを題材にしたユーザーテストを会場で実演します。「実演」と言っても大げさなものではありません。①その場にいる人で、②その場にある機材を使って、③約30分で完了する（ただしセッションは45分）ーーという「即席」スタイルです。

「UXとは？ユーザーテストとは？」という小難しいプレゼンテーションを聞いたり、その分野の本を読んだりするのも悪くありませんが、まずは自分の目で見て、自分で価値を判断してみてはいかがでしょうか。意外と気に入るかもしれませんよ。

井の中の蛙、大海を知らず。A frog in a well has no knowledge of the great ocean.

As companies grow and evolve, common problems can occur. Often, the larger the company, the larger the problem.

One way many organizations choose to tackle these problems is through the introduction of immersive learning spaces, sometimes known as the "Dojo" concept. Through introduction of experimentation, Agile development, and offerings designed to build stronger teams - as well as application of novel coaching and instructional techniques - immersive learning spaces can improve efficiency and empower teams in brand new ways.

こんにちは。楽天仙台支社の半谷(はんがい)と申します。
仙台・東京・大阪・福岡にそれぞれ仲間がいる開発組織で、25人くらいのグループのマネージャーをやっています。ベースは仙台ですが、月に2回くらいは東京に行っています。

私達は、楽天市場の開発を行っています。

2019年6月にリリースした新機能開発では、もともと縦割り組織だったビジネス・デザイン・開発のそれぞれのステークホルダをワンチームにまとめ、日々数万店舗様が使ってくれるような顧客満足度の高いものを作ることが出来ました。

この体制を作るのに参考にしたのが、Jeff Pattonさんが提唱している「Product Discovery Team」の考え方でした。このおかげで、ともすると敵対関係みたいになってしまいがちな三者が、顧客に価値を届けるぞ！良いもの作るぞ！と同じ方向を向きつつそれぞれが強みを発揮するようになりました。

もちろん最初からうまくいったわけではなく、色々な書籍や文献、先達の知恵に助けてもらいつつ、もがき苦しんだ結果たまたま発見したものです。なのでセッションの内容は、うまくいったぜ！という過程ではなく、苦労話が多くなると思います。

このセッションが、大企業の中で組織改善に悩むいろんな方々のヒントになったら良いなと思います。私自身もまだまだ悩み中なので、一緒に旨い酒が飲める仲間が出来たら嬉しいです。

スクラムチームにテックリード？

「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう？」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな？」って悩むことありませんか？僕はありました。

スクラムに取り組んだ最初のころは「あれー？ここどうしようかな？とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ？」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。

スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。

こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。

僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします：プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。　

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

「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。

それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。

また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。

今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。

Joy,Inc.に出会う前のぼくらは、チームとして機能していませんでした。2013年ごろ、色々な問題が噴出し、会社としてどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなっていきました。その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それを実行してきました。
会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

While development team focus on “build it right”, product team works with “build the right thing”. Our development teams are already practicing a solid way called Test Driven Development (TDD) and the results are quite amazing which is helping them to “build it right”. When the development team is following that approach and getting positive results out of it, I believe a similar approach in our product thinking can change the whole perception of how product is being build. It is a shift in the mindset from building something and handing it off for someone else to try and prove it’s working as expected, to first thinking about how we want it to be working and then building it to meet those demands. I want to name it as Test-Driven Product Development (TDPD).

In this talk I want to focus on how we can accomplish our product development and design with test driven approach. The whole discussion will be divided in to following topics
1. Outcomes, assumptions and hypothesis
2. Design and prototyping based on hypothesis
a. User value hypothesis
b. Business value hypothesis
3. Create the MVP for testing
4. Steering the development with feedback
5. Repeat the cycle

I believe this session is going to be a great learning session for product owners and product team members to think of a new way of working through the whole product life cycle.

This is going to be a 90 minutes’ hands on workshop where participants will be doing the activities with the guidance of me and we will jointly evaluate the outcomes of the workshop. It will be a fun workshop with lots of learning and rewards. The whole session will be inspired by TBR (training from back of the room) format with interactive and engaging learning.

開発チームのスキルによって、開発の時に重要な要素である実行可能性（Feasibility）は大きく左右されます。価値のあるバックログアイテムが用意されても、それを実現でき、お客さんに届けることができなければ意味がありません。実現することこそが開発チームの本懐であると思います。

現在のソフトウェア開発において、オープンソースソフトウェア（OSS）を活用することは当たり前となってきています。もちろんOSSも人が作ったソフトウェアですのでバグはありますし、期待した機能を持っていなかったりもします。では、そういった不具合や期待した機能を持っていないことに気づいた時に、どうしたらいいでしょうか？居酒屋で見つけたバグをネタにビールを飲むことでしょうか？「こんなバグがあるなんて、酷い！」「このOSSは、○○が無いのでダメだ！」などとSNSなどで投稿することでしょうか？

残念に感じたり、時には怒りを覚えるかもしれません。ですが、それはとても素晴らしいチャンスです。そう、OSSに貢献するチャンスです。しかし、残念なことにOSSへの貢献がとても高いハードルと感じている方もいらっしゃるようです。

ようこそ、OSS Gate ワークショップへ！
このワークショップでは、OSSに貢献したいけど最初の一歩を踏み出せずにいる方の背中を後押しするワークを行っていただきます。終わった時には、小さいかもしれませんが、OSSへの貢献に確実な一歩を踏み出せたと思えっていただけるでしょう。そして、普段の開発で、それまでよりもOSSに対して身近に感じていただけると思います。

このセッションのプレゼンテーターの二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。ひとりはアジャイルコーチ、スクラムマスターとして参加し、ひとりはエンジニアとして参加しました。

そのプロジェクトは1000人を超える開発組織の中で初の「アジャイル開発を導入する」とうたったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされました。

プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。

共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。

突然ですが、スクラムマスターのキャリア設計って難しいと思いませんか？
アジャイル開発が普及するにつれてスクラムを導入するチームも増えている一方で、まだまだスクラムマスターというロールは一般的ではなく、多くのスクラムマスターは元々の役割と兼務しています。スクラムマスターとして価値を高め、今後キャリアを伸ばしていくためにはどうしたら良いでしょうか。

現在私は週3日サイボウズで正社員として働きながら、週2日は個人事業主として社外のチームをお手伝いするというちょっと変わった働き方（複業）をしています。
このセッションでは、エンジニアからスクラムマスターになり、アジャイルコーチとして複数チーム・組織を支援する立場になった事例を紹介したいと思います。スクラムマスターのキャリアの選択肢のひとつとして参考になれば嬉しいです。

アジャイル開発やスクラムに関する誤解や誤用（ScrumBut）をまとめて“ざんねんスクラム”と総称してます。
“ざんねん”なスクラムの状況を通じて、何がイケてないのかを深く理解し、どう改善すればよいのか？をSpeakerが話すだけではなく、参加者みんなで考えていこうというコンセプトのセッションです。

• 「それってうちのことですか？」
• 「どこかで見たこと聞いたことあるような。。。」
• 「なるほど、そう考えるとたしかによくなさげ」
• 「アジャイルが認知されてきたからこそ起きている、最近の状況」
• 本当にあった怖いスクラムの話

といった感じで複数の小さなテーマごとに話をしたいと思います。
（途中参加、途中退出はお気軽にどうぞ）

以前からの定番あるあるネタ、最近のアジャイル界隈などのテーマを織り交ぜて、参加者の方に１つでも生きた情報を現場に持ち帰ってもらえればと考えています。