(実行委員会より: 本セッションはオンラインのみで行います。ぜひ事前にDiscordでの受付を済ませていただき、Discordに記載のZoom URLからご参加ください) 

• RSGTには初めて参加するので、どんな感じなのか分からず、本当に自分が参加して良いのか不安だな
• オンライン参加で、Discordを使うみたいだけど、どう使えば良いのか分からないし、大丈夫かな
• 現地に行っても他に知り合いはいないので、ぼっちになってしまうのではないかな
• 何度か参加しているけど、久しぶりだから誰か自分のことを覚えてくれているかな

このように、初めてRSGTに参加される方や、久しぶりのRSGTだという方など、RSGT参加が近づくに連れて何となく不安でちょっとドキドキしてくる方は多いのではないでしょうか。

私は、RSGT2021とRSGT2022で知り合いを増やすためのワークショップを行いました。参加頂いた方には大変好評で、知り合いが増えることでRSGTをより楽しむことが出来たという感想をたくさん頂くことができました。

一方で、開催後に「Day 0にこの会をやって欲しかった」というフィードバックを多く頂きました。（これまではDay 1の最後にネットワーキングの一部として開催していました）

たしかに、Day 1が始まった時点で知り合いがいる状態になっている方がより望ましいですし、ネットワーキングパーティではその繋がりから、さらに知り合いが増えるかもしれません。何より、知り合いがいる安心感が、Day 1への参加を楽しみでワクワクするものにしてくれます。

そこでDay 0でRSGT2021とRSGT2022で開催したものと同様な「知り合いを増やす会」を実施することを提案します。

主なターゲットは初参加や久しぶりに参加する方ですが、よく来ている人にも参加して頂いて、これまでの楽しみ方を話してもらうのも良いなと思います。

参加に向けての不安点を解消したり、注目しているセッションについて共有したりするのも楽しそうです。

そしてこれがDay 1以降の深い議論や学びに繋がっていくことを期待しています。

Direct URL:

This session focuses on five key development practices from Extreme Programming (XP) that are sometimes overlooked but are essential for successful Scrum software development. These five practices include automating the build for continuously integrating software as it is written, collaborating with team members through pairing and mobbing, practicing agile design skills that enable testability, using test-first development to make code independently verifiable, and refactoring code to reduce technical debt. Together, these five technical practices are proving to be essential for sustained success when building software with Scrum. But many teams have not been exposed to the benefits of these practices or how to use them effectively.

In this session, we explore why these engineering practices are essential for building software in sprints, and how to use them to reduce risk and build quality in at every level of the development process. These practices are key to automating software validation and address the inherent risks and challenges in designing, building, and verifying software.

Direct URL:

アジャイルは"プロダクトそのものをうまくつくる"だけでなく、その"多くの人にそのプロダクトが使ってもらい、使い続けてもらうようにする"というのも含まれていると考えます(もちろん、そのプロダクトを提供し続けるような対価を得ることも含みます)

どうやったら使い続けてもらうか？を見つける活動の1つに仮説検証があります
仮説検証が十分でないと、ただ闇雲に開発し、OutcomeのわからないOutputを生み出し続けてしまうこともあります

では、仮説検証と開発をどのように進めていくと良いのでしょうか？
スキルセットの違い、活動のサイクルの違い、仮説検証と開発のつなぎ方、開発から仮説検証へのフィードバックループなどいろいろなトピックがあります
すべてをいきなりできるわけではなく、段階的に学んでいく作戦も必要になります

このセッションでは、「Outcomeにフォーカスするチームへのジャーニー(旅路)」を歩んでいるいくつかの現場のチームの事例を中心に、レッドジャーニーのアジャイルコーチとして80チーム以上を支援してきた自分なりの経験や考えをお話します。

※RSGT2022のプロポーザルをベースにこの1年の経験でアップデートした内容でお伝えします。

Direct URL:

このセッションは、
DXやアジャイルを進めていきたいけど、なかなか進められていない、
日本の組織文化の中で悪戦苦闘している人たち向けの
銀行DXのセッションです。
ここでは、銀行DXの4年間の実際の取組を知ることができ、
教科書的な理想論や動きの早い今どきの組織の話とは違い、
ザ・日本企業・組織での取組であるので、自組織に持ち帰って現場で推進するための後押しにしやすいという特徴があります。

銀行組織、どういったイメージでしょうか？

古い、固い、つまらない、そういったイメージを持つ人が多いかと思います。
何を隠そう、私もそうでした。

実際に入社当初感じたのは、ザ・縦割り組織。

初対面でまず確認。役職は？何年入社？
出社したらまずは上席に挨拶。帰りももちろんご挨拶。
Webで入力したのに、なぜか同じ内容を紙に手書きでもう一度。え？！
堅実が一番！一番最初に挑戦？！いやいや、どこかに事例ができてからで…
上げればキリがないくらい昔ながらの日本の組織。

銀行の開発は？というと

外注オンリー。
大事なのは外注管理と、守りのIT。
すごい額とすごい年数の開発がいたって普通。

（ちょっと誇張気味ですが）さて、想像できるでしょうか？

そんな組織に内製アジャイル開発チームを立ち上げる物語。

はじめは4人からの小さな取り組みでした。
開発組織なのにエンジニアゼロ…
衝撃的なスタートではあったものの、幸いにも現在では開発メンバーも増え、内製開発できる状態にはなりました。

ただ、その活動もまだ社内の一部でやっていること。
全社的な取り組みには程遠い。（個人的な見解）
そんなもやもやと、野望を抱えながら地道な活動を続けてきました。

4年が経とうとした頃、組織にも小さな変化の兆しが。

自主的にスクラムマスターやプロダクトオーナーに興味を持ってくれる人がちらほら。
これまで、興味持ってくれそうな人に声をかけて勧誘していたのに、向こうから声をかけてくれる。
あれ、何か変わってきた？ウキウキしていると、

ここから社内にも怒涛の変化が。

これまで守り一辺倒だった既存のIT部門から、アジャイル開発やってみたいという取り組みをかわきりに、組織全体を見据えた小さなDX推進本部が立ち上がり、組織の重要案件での内製開発もスタート。

4年半を迎えた今、全社的な取り組みへと発展させる大きな組織改正がなされました。

大きなうねりが今後も続くことを期待しつつ、これまでを振り返ります。

2020年、2022年のRSGTでは現場のスクラムマスター目線での取組を話してきましたが、
今回は、チームをマネジメントする立場の人間が取り組んできたこと、考えてきたことをお話します。
同じ内容の話でも目線が違うことにより違った気づきが得られると思います。

まだまだ成長段階で、すごい人達がすごいことをやったという話ではありませんが、
レガシーの代表とも言えるような

銀行が挑戦しているのだから、自分たちもできるはず！

そういったことを感じてもらえるようなセッションにできればと思います。

Direct URL:

本セッションではまず、大規模ゲーム開発におけるリモートモブワーク導入の前提となる、リモート下でのスクラムフレームワークの導入の事例を紹介します。
そしてスクラムの本質はコミュニケーションであることに着目しつつ、1日1時間のリモートモブワークを実際に導入してみた経緯や内容、得られた効果、発生した問題、改善事例や変遷を具体的に紹介していきます。

CEDEC2022で講演した内容をアップデートしてゲーム業界以外の方にもわかりやすいように再構築して発表いたします。

Direct URL:

アジャイリストなみなさんこんにちは。みなさん、「コーチング」という言葉を耳にする機会が増えたと感じてませんか？これはあくまで個人の観測範囲に過ぎませんが、2022年をふり返ってみると実際にコーチングを学び、探求し、実践する人がこのアジャイル界隈でも増えてきたなと思います。そしてこれはアジャイルコーチのみのことではなく、アジャイルに関わるさまざまな役割の人にも及んでいるとも感じてます。

さて、みなさんは "システムコーチング®（Organization & Relationship Systems Coaching®、以下ORSC®）"というコーチングをご存知でしょうか？

私は2021年中頃からこれを学び始め、2022年はほぼこれを学ぶことに注力しました。いえ、正確に言うといざ始めてみるとこれに注力せざるを得なかったのが実情です。ORSCを学ぶことは少なくとも私にとってはそれほどタフなものでした。正直、もし学び始めの時点まで時が戻るのであれば取り組み方をもう少し考え直すかもしれません。

とまぁしんどいってことを強調してしまいましたが、このプロポーザルを書いた時点(2022/9)ではまだ最後の学びのコースの道半ばではあるものの、決して後悔はしていないってことははっきりと言えます。大変ではあるけれど、自分にとって意味があり、価値がある学びを重ねられていると実感しています。更には既に実際に役に立った体験もしています。そしてこれはRSGT当日の2023/1ではより積み上げられているだろうと確信しています。

というわけで、このセッションでは私自身をサンプルとし、流しのアジャイルコーチとして何を思い、考え、何に価値を感じ、そして何故ORSCを学び、アジャイルコーチングとORSCを重ねることにどのような可能性を見出し、実際にどのように役立ったのかのエピソードにも触れつつ、この先何をしていきたいのかをお話します。

これらがみなさんの普段の中にある関係性への新たな視点や可能性を獲得でき、ORSCの世界へ足を踏み入れてみようと思った時の一歩目の道標となり、そしてアジャイルコーチングとORSCが交わって生まれるパワフルな力を感じられる、そんなセッションにしたいと考えています。

※システムコーチング®、Organization & Relationship Systems Coaching®、ORSC® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

Direct URL:

RSGT楽しみですかー？
楽しみの人も多いと思いますが、初参加の方や知り合いが少ない方は不安な気持ちでドキドキしている方も多いのではないでしょうか？

・他のみんなは仲良さそうなんだけど自分も混ざって大丈夫かな？
・最初なんて話しかければ良いんだろ？
・誰に話しかければ良いんだろ？
・何はともあれ話しかける勇気が湧かない…

最初に1人でも知り合いができると心強いんですが、その最初の一歩はすごく勇気が必要ですよね。

本セッションでは、そんな不安な気持ちの初参加者が1人目の知り合いを作るワークを実施します。
具体的には初参加者同士で3人グループを作り、Day1のセッション巡りプラン作りを行います。
セッション巡りプランについては、個人プランも良し、グループプランも良し。
皆さんがより楽しめるプランをみんなで考えていきたいと思っています。
また、プランニングの時はクリエーションラインメンバーも入り、一緒に考えながら仲良くなっていきたいと思います。

セッション終了後もグループメンバーやクリエーションラインのメンバーと話す仕掛けも用意してます。

Day1から2名の知り合いを作り、1人より3倍楽しめるスタートを切っちゃいましょう！

Direct URL:

スクラムチームは、顧客やユーザーの成果である「アウトカム」に集中するべきです。そのためには、プロダクトゴールとスプリントゴール、完成の定義といった「確約（コミットメント）」が重要です。しかしながら、アウトカムを生み出すのは、スクラムチームのアクティビティ（行動）とアウトプット（コードやレポートなど）です。アクティビティとアウトプットを検査し、適応させることでよりよいアウトカムが生まれてきます。要するに『アウトカムが大事であると認めながらも、アクティビティとアウトプットも大事』なのです。

このセッションでは、話し手が現場の支援をしているスクラムチームでも実践している行動変容、行動改善に用いるアクティビティとアウトプットの《事実を積み重ねて見えてきたことから検査し、適応させる》のためのテクニックによってよりよいアウトカムが意識できる方法についてそのエッセンスをお伝えします（※ 具体的な事例は公表しません）。

例えば、

• スプリントプランニングで、プロダクトバックログアイテム（PBI）とタスクをだしたのに...
  • タスクごとに作業分担して一斉に取り掛かってしまう
  • 中盤または終盤にDoneになっている（そうなる見込みがある）PBIがひとつもない
  • デイリースクラム以外でチームメンバーと成果について会話していない
• ステークホルダー（特にマネジメント層）から生産性指標やその向上について聞かれたのに...
  • ベロシティしか提供できない
  • ベロシティを他チームとの比較に使われてしまう
  • そもそも生産性指標を提示する意義がよくわからん
• 果たして我々はうまくいっているのか...
  • スクラムのルールに従っていたらうまくいっていると言えるのだろうか
  • ステークホルダー（特にマネジメント層、他のチーム）に対して胸張って活動を伝えられるだろうか
  • 自分達は自己管理しているのだろうか、それとも"自己管理"されているのだろうか

といったお悩みに対して、解決策とズバリ言えるかは現場によりますが、ヒントくらいは提示できます。

スプリントバックログ運営でのコツ:

• PBIのWIP制限
• PBIのサービスレベル期待値（SLE）

スプリントで計測すべき指標:

• PBIの経過期間（年齢）
• サイクルタイム

スプリントでの実態把握で見るべきグラフ:

• サイクルタイム散布図
• 累積フロー図

ステークホルダーにスクラムチームの活動や開発戦略について聞かれた時に「ベロシティ」くらいしか説明できない方や、それらをうまく説明できずに自信を持てないスクラムチームに向けて一つのヒケツをお伝えしたいと思っています。

More Effective Scrum シリーズ(?)

RSGT2020, 2021, 2022 で発表した内容からつながるセッションにする予定ですが、過去の発表内容を事前に知っておく必要はありません。

• RSTG2020: Going Agile with Tools
• RSGT2021: 2つのモードで学ぶ辛くないスクラム
• RSGT2022: プロダクトゴールとは？あるいはプロダクトのゴールを設定するには何が必要か？

Direct URL:

中小企業基本法で定められている中小企業の条件は、例えば製造業だと資本金3億円以下、社員数300人以下の企業で、この定義より規模が大きければ大企業だそうです。

私は、とある製造業系大企業のグループIT企業の社員として、入社以来20数年勤務しています。入社した時とはずいぶん風景は変わりましたが、会社の歴史と共に生きてきた、と言えると思います。

十数年前に私がアジャイルを学び、実践し始めたのはあくまで個人的な欲求からだったわけですが、今や私が所属する会社も、社を挙げてアジャイルを学び、企業活動に活かすべく動き出しています。それは、若き日の私が夢見たことでもあります。

ただ、当然ながら、めでたしめでたし...とはいきません。

前世紀から存在するような大企業は、それまでのやり方で上手くいったから大企業な訳で、時代や環境が変わったからといって、それまでの成功体験を一旦忘れて新しい考えを学ぶことは簡単ではありません。アジャイルの波が社内に押し寄せる中で、喜んでいる人より、戸惑い悩む人の方が明らかに多いのです。

アジャイルに魅せられて、同僚より少し先にその道を歩んで来た私に、できることはなんだろうか...

新しいビジネスの地平を目指してアジャイルを志向し始めた大企業の中で、私が経験した事象の数々を言語化することで、同じような境遇で現場づくり、組織づくりに挑んでいる方々の学びにならないか、との思いでプロポーザルを書きました。

Direct URL:

私たちのプロダクト開発現場で「スクラム」という言葉を聞くようになってから約4年が経ちました。
はじめはスクラムに興味をもっていた少数の有志が推進者となり開発プロセスのカイゼンに取り組み始めました。

そんな我々は当時「1センチでもチームを良い方向に導きたい！」「価値を迅速に生み出せるようになりたい！」という熱い気持ちに突き動かされていました。
分からないなりに工夫を凝らしたり、すがるような想いでプラクティスを取り入れてみたりなど一所懸命に目の前の課題に向き合っていました。

そうして何かを実験したり実践してみると手応えを感じつつも、どこか思い描いていたような成果や結果が得られない感覚が拭えませんでした。
ときには何かを失ってしまうことさえあり、まさに三歩進んで二歩下がるような日々と言えます。

しかし、裏返すと着実に一歩ずつ進んできた4年間でもあり今だからこそ観測できる気づきが多くあります。
さにらそれらは当時の自分達がはじめに知ることができたならば…と思えることばかりでした。

• 真剣に取り組んでいたが今になって思い返すとおかしなこと
• 当時は分からなかったけど今になったら「こうしたらよかった」と思えること
• まさかこんな結果を生み出すとは思ってもいなかったこと

など、皆さまにとって他山の石となるような内容をお届けできればと思います。

Direct URL:

最近になって改めてエンジニアリングマネージャーという役割に注目が集まっています。

この数年でずいぶん体系的な知識にアクセスしやすくなった反面で、まだまだ実践的な経験の話は少ないように感じています。

エンジニアリングマネージャーの定義は会社によっても差分はありますが、採用や評価、労務管理、といったいわゆる人事領域の仕事から、事業戦略や組織戦略といった戦略策定に関わることもあります。

私はこの数年エンジニアリングマネージャーとして仕事をしてきました。途中一度エンジニアに戻り、また改めて2周目エンジニアリングマネージャーとしてチャレンジするというバックグラウンドがあるのですが、現在2周目をやって感じることは、

• 相変わらず業務の幅は広いこと
• 自分の立ち位置がわかりやすくなったこと
• 組織的な設計がすぐに古くなってしまうこと
• やらないことを決めることが重要だと言うこと

です。

特に業務の幅広さについて、抽象度で整理すると自身の仕事も周囲とのコミュニケーションもわかりやすくなったという気づきがありました。

このセッションでは、この幅広く見えるエンジニアリングマネージャー業を抽象度で整理してその理解を深めたり、向き合い方についての解像度を高めるような場にしたいと思います。

スクラムの中にはマネージャーというロールはなく、自己組織的なチームであればマネージャーは必要ないという意見もあるかと思います。

しかし、現実的には会社という枠組みの中でチームを効果的に支援する役割が重要となります。

• チームができること、チームができないことの境目は何か？
• どうすればアジャイルなチームを長続きさせられるのか？
• エンジニアリングマネージャーがアジャイルであるとは何なのか？
• 組織全体がアジャイルになるためにエンジニアリングマネージャーは何をすべきなのか？
• エンジニアリングマネージャーはどのようなキャリアを歩めばよいのか？

チームの外にいるからこそできることを一緒に考えてみましょう。

Direct URL:

2022年夏は「マネジメント3.0」「マネージング・フォー・ハピネス」と、これまで待ちに待たれた（はずの）Managemenet 3.0の翻訳本が立て続けに出版され、日本にとってのManagement 3.0元年とも言える年になった（か現在進行形でなっている）のではないかと思います。

このセッションでは、翻訳者として「マネージング・フォー・ハピネス」を出版した立場から、Management 3.0の基盤となる考え方／捉え方に重きをおいた内容をお話しします。

チームや組織として継続的に高いパフォーマンスを維持していくためには、そうなるための変化を導入し、なおかつ状況にも合わせて常に変化し続けることが必要になりますが、そういったシーンで変化を促す立場側が重要視するべきスタンス（受け入れられやすい状況のつくり方や求めている方向への導き方）」というところに関する気づきやきっかけを提供します。

まだ本を読まれていない方やManagement 3.0を知らない方でも理解していけるような内容にしますので、前提知識がなくてもお気軽に参加いただければと思います。

ヨーガン・アペロ氏は21世紀に創造的な組織が成功し、存続していけるようにするための「少数のマネージャーによるマネジメント（メンバーがマネジメントは自分の仕事であると自覚し、各自でマネジメント活動をしていくことで「マネージャー」の役割にあたる人は少数で十分になるはずという考え方）」を導入することに伴う、具体的なゲームやツールやプラクティスを提供することを軸に主にヨーロッパで活動されています。

Management 3.0はそのなかのひとつであり、ヨーガン・アペロ氏が考案したものです。過去、RSGTでもManagement 3.0をテーマに基調講演をされたことがありました。

また、Management 3.0は上記に加えて「幸せで生産性の高い組織になるためのマネジメント」とも表現でき、ヨーガン・アペロ氏の「組織は複雑適応系であり、良いマネジメントとは、人を操作することではなく、システムに気を配ること」という信念のうえに成り立っています。

3.0のナンバリングが示すとおり、Management 1.0や2.0の状態も定義しています。Management 1.0は人を「機械」として捉えるマネジメントで、Management 2.0は人を「機械」ではなく「人間」として捉え、人が活きるための施策をとっているが、根底にはヒエラルキーが存在するようなマネジメントを指しています。

詳細はじんぶん堂記事「マネジメントは誰の仕事だろうか？」もご覧ください。

Direct URL:

私は株式会社アカツキゲームスにおいてモバイルゲーム開発の事業に所属しており、組織の課題解決をミッションとして働いています。

ひとことに組織課題の解決と言っても、取り組むことは多岐にわたっています。

• 開発組織内で大規模スクラムを導入する
• 開発組織外でアジャイルの思想を取り入れた業務改善を実施する
• ひとつのゲームを関係会社の垣根を超えて良い感じに開発・運用できるよう、各会社のミッションやメンバーの Will も鑑みつつ、色々やる

スクラムガイドには "スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。" とあります。

スクラムマスターを担当されている方や、私のように組織の課題解決をミッションとして仕事をされている方は、組織と向き合うことを難しいと感じる人も多いのではないでしょうか。

• 自分だけ、あるいは少人数のメンバーしか課題と思っていないけど、変化を起こしたいがある
• 影響範囲が大きく、職種の異なる人・同じ方向を向けていない人たちと一緒に、前に進まなければいけないことがある
• 自分は良い取り組みだと思っているけど、ネガティブな反応の人がいる
• 上司や同僚と議論が永遠に噛み合わない

以前はうまく立ち回れず、厳しいご意見をもらうことも多かったのですが、最近は関係会社も巻き込むような立ち回りができるようになりました。

本セッションでは、スクラムチームと、より⼤きな組織に奉仕をしたい方に向け、いろんな考えの人たちを巻き込んで前に進めるための、私なりの考え方や方法をお話します。

Direct URL:

「カルチュラル・インテリジェンス」（CQ）とは、文化の違いを超えて円滑にコミュニケーションを図る能力のことです。文化の違いと聞くと国や宗教のような大きなものを想像しがちですが、組織にも、部署にも、チームにも、そしてひとりひとりの個人にも文化的背景はありますよね？アジャイル的な考え方も文化といえる背景がありそうです。

知らず知らずに考えたり、当たり前に行動しているその価値観。根幹には、本当はもっと多くの次元の価値観の軸があるのではないでしょうか？

ここでは手始めにCQで語られるホフステードの6次元モデルを参考に、CQとは何かのざっくりとした説明と、アジャイルマニフェストをホフステードの6次元モデルで分解してみるとどういう価値観の背景があるのか考察してみたいと思います。

https://speakerdeck.com/spring_aki/cq-introduction?slide=2

Direct URL:

いくつもの組織とともにジャーニーを続けています。そんな中で分かってきたことをまたお届けしたいと思います。

組織が直面する状況には「共通性」があります。
伝統的な大企業、あるいはベンチャー企業、地方の企業にしても、一様に乗り越えなければならない組織課題。
なぜ、組織はやがて「最適化」の呪いの中でどうにもならなくなってしまうのか？

今現在、組織に求められるのは、
・取り巻く環境や社会に価値を提案し続けるケイパビリティ（仮説検証型アジャイル開発）と、
・その活動を持続可能にする探索適応型の組織運営（組織アジャイル）
この両輪です。そして、こうした組織活動が噛み合うためには、組織の中心部に「芯」が不可欠です。

さあ、アジャイルによる私たちの旅はいよいよクライマックスを迎えそうです。
アジャイルによって、アジャイルになる。変革に挑む組織の最前線からお届けします。

※本セッションは株式会社レッドジャーニーによるスポンサーセッションです

Direct URL:

こんな経験ありますか？

• 普段会話しない上司から突然の評価面談でダメ出しされた
• 明らかにパフォーマンスの低い同僚と比べてサラリーが低い
• 自分がどんな軸で評価されているかわからない

どれも昔、自分が経験したことです。

ずっとモヤモヤしていましたが、「これが社会人として普通のことだ」と自分に言い聞かせていました。

しかし、自分が部門のマネージャーになり、メンバーの人事評価をする立場になりました。

メンバーとは1on1をし始めて、今までそこまで会話してこなかった人に聞くと同じようなモヤモヤを持っていることがわかりました。

「評価方針が良くわからない」

「評価プロセスに対する透明性がない」

「他グループのメンバーと評価軸が同じかわからない」

「評価に対する上司からのフィードバックがあいまいでぶっちゃけ納得感はない」

うん。うん。同意です。

では他の会社の組織ではどんな人事評価をしているのか？

気になり、悩んだ結果、RSGT2022のOSTで悩みをテーマにしました。

OSTでは10～20人くらいの人に参加していただき、意見をたくさんいただきました。

「評価者から被評価者にどのように評価するかのイメージを共有していますか？」うっ

「評価面談でどうなってほしいか？またはなりたいか？等の会話はありますか？」うっ

「お互いに納得のできるフィードバックになってますか？」うっ

いろんな組織のやり方やアドバイス、また同じような悩みを聞いて、本当に勉強になりました。（参加していただいた方には感謝しております。）

OSTから学んだことをまとめると以下の2つでした。

• 評価者と被評価者の間で評価に対する納得感の確保
• そのためには評価プロセスと評価軸の言語化と透明性が大事

学びを受け、自分が試した実践は以下でした。

• QAという職種のキャリアを明確にする
• 評価方針や評価プロセスの透明性を明らかにし、公平性を確保する
• マネージャー間でメンバーに対する評価のすり合わせや、マネージャーからメンバーへのフィードバックをし、お互いの納得感を確保する
• そのための評価軸をしっかりと定義する（結果的に以下の4つの軸ができた）
  • マネジメント評価軸
  • エンジニアリング評価軸
  • 部門内の課題解決評価軸
  • コンピテンシー評価軸
• 次の評価に向けたキャリアプランの形成や目標管理

本セッションではOSTから学んだことを実際の現場で実践し、どのような結果だったのか。

成功したことや、失敗談を、伝えられる範囲で発表したいと思います。

Direct URL:

現場の状況をうまく共有したいと考えている方、アジャイルを組織に広めようとしている方、チーム状態の見える化に興味のあるような方々、こんなことで悩んだことないですか？

”エラい人”が「チームの状況を共有してほしい」と言ったら、皆さんどうしてます？
　・開発の現場に来てもらって、タスクボードやバーンダウンを見せる
　・イベントに同席して雰囲気を感じてもらう
　・動くものを見てもらってフィードバックをもらう
などなどチームごとに実際の現場を見てもらうというのはよく言われますよね。

でもこれが、少し状況が複雑だったらどうでしょう。例えば…
・”エラい人”に、多忙すぎて見に行く時間なんて無いよと言われたら？
・「現時点の情報はわかるけど、ここまでのチームの成長過程ってどんなんだったっけ？」と聞かれたら？
・チームが5チームあったら全チーム見てもらう？10チームあったら？

などです。本当は現地現物をみてもらいたいけども、すぐに大きな課題提起をするためにチームの外の力を借りたいとしたら、別の方法で情報を共有することも必要な状況もありますよね。

ただ共有するには「どうやったら第三者にアジャイルチームの状況をうまく共有できるのだろうか？」ということに対するアイデアが必要になります。WBSのように作業項目を示して”完了した”というような形では、”完了”から状況が後退することもあるわけで、常に状態が変化するアジャイルチームをうまく表せません。それにこれ、何よりアジャイルっぽくありませんよね（汗）

そこで今回、1つのチャレンジとして実践している「第三者へのチーム状態の見える化」を新しい見える化の領域として共有してみようと思います。
これまで「タスクボードをこう工夫して見やすくしました！」とか「メンバーの能力をスキルマップで見える化しました」のようにチーム内の見える化の工夫は様々な方が共有してきたと思いますが、普段チームを見ていない第三者へチーム状態を共有するという工夫は、実際には現場できっと行われてきた(と思う)反面、アイディアとして共有されることは無かったかと思います。本セッションでは、どんな内容をチーム状態として定義し、どのような形で可視化し、どのように運用しているいるか、どんな効果があるのか等を共有して、それを元にみなさんがさらに良い別のアイディアを思いつくようなきっかけになれれば良いなと思っています。

Direct URL:

Chatwork株式会社のスポンサーセッションです。

Chatworkでは、不定期で"だいくしーのスクラムBar"というイベントを開催しています。

主旨としては弊社でのアジャイル・スクラムの取り組みを紹介したり、ゲストを招いて我々が学ばせていただいたりしながら、弊社に少しでも興味をもっていただきたい、というものです。

これまでに6回の開催実績があります。

https://chatwork.connpass.com/event/268564/

いつかは本当にどこかのお店を借りて、Barみたいなイベントにしたいと考えていますが、まだオンライン開催しかやったことがありません。

今回は、スクラムBarの店主であるだいくしーと、常連客の藤井がRSGTに現地参加をする予定ですので、この機会にRSGT会場に20分だけ出張オープンしようと思います。

これまでにご来店くださったゲストもひょっとしたら来店してくださるかも...！？

Direct URL:

皆さんは、良く言えば「安定」、悪く言うと「成長が鈍化」したチームに所属したり、見かけたりしたことはないでしょうか？
長くチームが続き、コアメンバーが変わらない場合にそういった状態になりがちです。
皆さんはそういった状態を見かけたときにどういった働きかけをチームにしているでしょうか？

私のチームが1年以上経過したころから、私はチームの成長が鈍化しているように感じました。
私は次のような問題が起きていると感じていました。

• 障害があっても、すぐに発見してチームで対応できてしまっているなー。ふりかえりでもTryは出るが、簡単に対応できるレベルのもので、自分たちのやり方を見直すほどのものではないなー
  • 問題が起きない問題
• 何か新しいことを取り組もうとする雰囲気はチーム内にあるが、具体的な一歩が踏み出せていない
  • 何を目指せばいいのかわからない問題
  • コンフォートゾーンの居心地がいい問題
• 私が開発者も兼務していることによる、開発スピードを緩めたくない気持ち
  • ベロシティ下げたくない問題

チームの成長が鈍化しているとき、チームメンバーは「問題が起きていない」「居心地が良い」という点からこの問題に気づかなかったり、言及できないことがあります。
また、こういう場面でスクラムマスターが「コンフォートゾーンにいすぎじゃないか？」「最近実験している？」といった問いかけをしながらチームが新しい方法を模索するように働きかけられると良いのですが、スクラムマスターが複数チームに所属していたり、兼任していたりすると、他業務に目が奪われて、この問題に取り組めないことがあります。（私は開発者との兼任で取り組めていませんでした。。）
また、マネージャーから見ても問題なくプロダクト開発ができているチームと認識されてしまって、チーム外からの指摘が入らなかったりもします。

この状況に対し、私たちのチームは次のようなことを行いました。

• 月間のテーマを決めて課題が生まれるようにした
• 新メンバーを入れて、課題が生まれるようにした

本セッションではこの取組事例と起った効果を紹介し、タックマンモデルと関連付けて考察したいと思います。

Direct URL:

ふりかえりを少しでも好きになってほしい

みなさん、ふりかえりは好きですか？私は大好きです。
ふりかえりに苦手意識を持っている？なるほど、わかります。実は私も最初はそうだったんです。
そんなあなたにも、ふりかえりを少しでも好きになってもらいたくて、このセッションで話します。

ふりかえりは、チーム全員で立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。後ろを向いて反省会をしたり、凹んだりする活動ではありません。みんなで前を向いて、たくさんアイデアを出して、未来を描いていく、未来を現実に近づけていく活動なんです。きっと、その違いにギャップを感じている人もいることでしょう。

このセッションでは、ふりかえりに悩める・停滞感を持つみなさんが、新しい一歩を踏み出せるような、勇気をもらえるような内容にしたいと思います。

国内のふりかえりの悩みの変遷を追って

私はふりかえりエバンジェリストとして、これまで100を超える様々な現場でのふりかえりの悩みに向き合い、寄り添ってきました。また、この5年間、TwitterやFacebookや各種ブログを追い、ふりかえりに関する発信の観測を続けてきました。この活動を続けているうち、徐々に発信の内容・質が変わってきたのを実感しています。

以前は

• ふりかえりがうまくいかない
• 人が参加してくれない
• KPTでKeepが出ない／Problemばっかり出る
• 意見が出にくい

といった、導入や進め方に関する悩みを持つ方が非常に多かったです。
はじめの一歩踏み出そうとしても、一歩踏み出せない。そんな悩みが、いろんな現場から上がっていました。
そんな人たちに向けて発信したのがRSGT2019の「Effective Retrospective～とにかく楽しいふりかえり～」です。

ふりかえりの目的にフォーカスし、まずは立ち止まること。そしてチームの成長にフォーカスすること。
場づくりから始めること。学びを大切にし、ふりかえりを前向きな活動としてとらえること。

ふりかえりそのものに持たれていたネガティブなイメージを払しょくし、ポジティブな活動へとのイメージが持てるような内容にしてきました。

ただ、ここ1-2年の発信を見ていると、面白い変化が生まれています。

• ふりかえりは当たり前に続けているけれど、マンネリ化していてどうすれば
• 〇〇の手法はうまくいかなかったから、他にいい手法はないの？
• 新しい手法にチャレンジしてみた
• ふりかえり手法を自分たちで生み出してみた
• ふりかえりをふりかえったらこうなった
• うちの現場のふりかえりはこういうことをしているよ

そう、初めの一歩を踏み出したあとに、更なる一歩を踏み出すためにはどうすればいいのかといった悩みや、一歩一歩前に進み続けている人たちの発信が増えているのです。この変化はとても興味深いです。ふりかえりカンファレンスでも、2021, 2022と回を追うごとに、プロポーザルの内容が上記と同じ変化が起こっているのです。

この一因として、ふりかえりそのものの認知が広がってきたことや、各種書籍やブログなどから参照できる情報源が増えたこと、があるでしょう。

ふりかえりを始めた先に見える道を、一歩ずつ歩いていくためのHOW

この変化は、急激で難しい変化ではありません。今このセッションの概要を読んで、「私はふりかえりはまだまだうまくいっていないな」というあなたにも、先人たちが切り開いてきた道が既にあります。

今回は、「Effective Retrospective～とにかく楽しいふりかえり～」の考えをさらに拡張したセッションです（※読んでいなくても大丈夫です。安心してください）。

ふりかえりは楽しい、前向きな活動だということはなんとなくわかっている。
それを、実現するためにどうすればいいのか？一歩を踏み出している人たちは何をしているのか？

このセッションでは、ふりかえりという果てしなく続く道を歩いていくための、心強い装備（HOW）をあなたに提供します。
ふりかえりを始めたばかりの人でも、新しい知見を得たい人にも。あなたのふりかえりを変えるきっかけが、ここにあります。

Direct URL:

運用業務とスクラムは組み合わせにくい、相性が悪いという話をよく耳にします。
しかし、プロダクト開発をするうえで運用業務は切り離せません。

このセッションでは、プロダクトを継続的にユーザーに届けるためには切っても切り離せない運用業務をスクラムでどう扱うとよいのか、ところどころで必要な判断をどう考えて行ったのか、わたしたちの試行錯誤にプロダクトオーナーの視点を交えて紹介します。

また、タイトル内にある問い「運用業務とスクラムは組み合わせにくいのか？」に対するわたしなりの回答である「そんなことはなく、うまく組み合わせることはできる」に至った理由についてもお話します。

ーーー
プロダクトにはライフサイクルがあります。これにはいくつかのフェーズがありますが、後半のフェーズになればなるほどいわゆる運用業務が増えていく事が多いです。

このセッション内では下記のような、システム運用・保守業務や業務運用をまとめて運用業務と呼びます。
身に覚えがある業務も多いのではないでしょうか。

• 定期的におこなう証明書更新
• 定期的におこなうソフトウェアのアップデート
• 需要に応じたキャパシティの拡張やライフサイクルへの対応
• 負荷が高くなるイベントへの事前準備と対策
• ユーザーからの問い合わせへの対応
• 突発的に発生する障害やインシデントへの対応とその対策

私は2年間、新旧2つのヤフーを支えるプラットフォームのプロダクトを担当しているチームのプロダクトオーナーをしています。
それぞれのプロダクトは2年間の中でプロダクトとしてのフェーズが変わり、その中でやりたいことや求められていることも変わっていきました。

• 新プロダクトは導入期〜成長期
  • まだ足りていない機能もあるのでもっと開発を進めたい
  • 多くのユーザーに使ってもらうため、機能要件の拡充を求められる
  • 成長期に入ると、これからユーザーが増えていくということで安定稼働も求められる
• 旧プロダクトは成熟期〜衰退期
  • 成熟期の間はまだより便利に使ってもらうための機能追加などを行いたい
  • ユーザーの課題を解決するために、プロダクトとして開発を行うことも求められる
  • プロダクトが衰退期に入っても、まだまだ利用者は多いため安定稼働を求められる
  • 同時に、衰退していくプロダクトにはコストを掛けたくないため、コスト削減も求められる
  • プロダクトの規模が大きく運用業務や障害も多いため、対策をしたい

新プロダクトでも約4割、旧プロダクトにおいては8割以上が運用業務。決して少なくない（むしろ多い）量の運用業務をおこないながら、それぞれのプロダクトで求められることにも応えていかなければなりません。

このような状況の中で、プロダクトが置かれている状況を見極め、開発チームと一緒に運用業務への取り組み方を検討したり、プロダクトオーナーとして判断をしたりを繰り返してきました。

プロダクトの状況ごとに、その運用業務とどう向き合ってきたのか。

• 運用業務をバックログ内でどのように扱っているのか
• プロダクトオーナーとして運用業務と開発業務のバックログの優先順をどのように決めているか
• スクラムチーム内の運用業務（運用フェーズのプロダクト）と開発業務（開発フェーズのプロダクト）の割合をどのように決めているのか

などの試行錯誤の一部と今後やっていきたいことについて、うまくいったこととそうでないことの両面からお話しようと思います。

また、タイトル内の問いへの私なりの回答についてもお話します。

運用業務とスクラムは組み合わせにくいのか。

試行錯誤を経た私なりの回答は、「そんなことはない。運用業務とスクラムはうまく組み合わせることができるのではないか、むしろその方がメリットがあるのではないか」です。

試行錯誤のなかでは下記のような気づきを得ました。

• ただの運用業務に見えるものも、視点を変えればインクリメントのある開発業務にできる場合がある
• スケジュールありきの運用業務は、無理にバックログで扱わないでスプリントを固定するとうまくいきそう
• 運用業務と開発業務の優先順を判断するためには、単純なインクリメント以外の軸をつくるのがよさそう
• ステークホルダーからのプロダクトに対する期待に応えるためには、運用業務と開発業務の量をある程度コントロールする必要がある

そして同時に、これらは運用業務とスクラムは組み合わせにくい、相性が悪いと言われる要因（課題）を取り除くヒントにもなっているのではないかということに気がつきました。課題を解決できるならうまく組み合わせられるだろうし、スクラムのメリットもより活かすことができそう、と思い回答に至りました。

そんなに単純ではないかもしれないですし、課題がすべて解決したわけでもないですが、運用業務とはまだまだこれからも長く付き合っていかないといけないので、よりよくしていくための挑戦はこれからも続きます。

同じ課題を持った人にとって、なにかの参考になったり、自分たちもチャレンジしてみようと思ってもらえたら嬉しいです。

Direct URL:

2日目のKeynoteスピーカーであり、世界的なアジャイルコーチでもあるLyssaの書籍『Coaching Agile Teams』は素晴らしい知恵の宝庫であるものの、その量と深さに圧倒されてしまいます。

カルチャー,マインドセットの変革 、組織構造の改革、マネジメント,リーダーシップ層の抵抗など（The State of Agile Coaching Report 2022より）とあるように、世の中のアジャイルコーチは日夜、様々な困難の中に立ち続けています。

同書にはこうした困難を克服するためのヒントがたくさん紹介されおり、その証拠に、2010年5月の刊行以来、10年以上経った今でも版元上位50位以内の売上を誇っています。

本セッションでは、同書の翻訳に携わるメンバーが書籍の中からアジャイルコーチになる、あるいはスキルを磨くのに使える、お気に入りのワークショップ、スキル等を実際の活用事例を踏まえて紹介します。

一例として、11章「アジャイルコーチの失敗、回復、成功モード」。

「アジャイルコーチも当然ながら失敗します。私がミスをしたのはチームの決断がシステム障害を起こす可能性があったときに、コーチとしてではなく、シニアメンバーとして全部を取り仕切って解決してしまいまったことです。この振る舞いは事態を解決したが、やり方としてアジャイルコーチといっていいのか疑問をかかえて過ごすことになりました。Lyssaが紹介していた失敗モードの"エキスパート"を参照した時、すっと憑物が落ちたようにアレは失敗だったんだと整理とふりかえりができ、次に進むことができました」 といった形で、それぞれの体験と本書から学べる気づきなどを紹介するセッションになります。

Direct URL:

*このセッションはアギレルゴコンサルティング株式会社のスポンサーセッションです。

Jeff Sutherland氏, James O. Coplien氏他による書籍「A Scrum Book: The Spirit of the Game」には、様々な状況に対する適応方法として97のパターンが記載されており、それらの全体を通して「あるスクラム」の姿が総体として描かれています。
また書籍の中では、各パターンは一度に１つずつ、順序を考えながら取り組むことが提案されており、サンプルとしての実践順序（シーケンスと呼ばれます）も提案されています。

今回のセッションではこうしたシーケンスにどんなパターンがどんな順番で並んでいるかを確認することで、こうしたナレッジに触れ慣れ親しんだり、欠けている何かに気づく機会を提供したいと思います。

Direct URL:

少し前に新しいチームへEMとしてジョインしました。
新しくジョインしたチームは、BtoB SaaSの開発をスクラムっぽくやっていたのですが

• スクラム経験者がおらずなんとなくでスクラムをやっている
• 退職者が続いたこともあり混沌としている

といった状態でした。こういう状況にSMやエンジニアとしてジョインすることは慣れていたのですが、今回はEMとしてのジョインでした。
会社としてEM専門職は初の存在であり追うべき背中も社内に見当たらない中「一体自分は何をすればいいんだ」と戸惑いつつ、できることを色々やってみたり、本を読んで真似してやってみたりしたことを挙げていきます。
また色んな行動をする中での自分のモチベーションの変化や、場面場面での自分の感情なども吐露していきます。

ただ私の体験を表現するだけだと学び少ない感じもあるので、複数の書籍を参照しながら「この記述に当てはまるかも」とか「この本のこの文章を解釈してこういう行動に繋がりました」辺りも発表できればと思っています。

Direct URL:

スクラムで自己管理型の組織を目指したい、スクラムをやっていなかったとしても主体性を持って動けるチームを作りたいという話をよく聞きます。自分もそこを目指して活動しているのですが、そのような状態にしていくにはさまざまな困難にぶつかることがあると思います。

今回は自分が実際に体験したこと、その時の考えを対話という軸に沿ってお話しします。

Direct URL:

プロダクトゴールについては、昨年のRSGTで長沢さんが素晴らしいセッションを提供してくださいました。では、私が語り得ることは何か?

自分の経験に基づいた話。
ゴールを設定する手前の、そこにいる人がワクワクしていくためのプロセス。
そんな話をしたいと思っています。

目標管理手法のひとつOKR。Scrum Fest Mikawa 2022において「OKRはツリーではない」という発表を行いました。

その発表の中では、OKRにおいて何よりも重要なのは「目指さずにはいられないワクワクする目標を作ること」だと説明しています。

これはスクラムのプロダクトゴールに対しても同じことが言えると、私は考えています。ワクワクする、そのゴールを達成せずにはおられないからこそ、私たちは自分たちの状況を公開し、失敗する勇気をもち、互いに尊敬しあいながらゴールに集中し達成を確約するのです。
私が関わってきた組織、チームでもワクワクするOKRを設定できているかどうかがプロダクトゴールの実現度合いと密接に関わっていることを観測してきました。ワクワクOKRを持ったチームは「ありたい姿」と「プロダクトゴール」の一致度が高くなり、主体的にプロダクトゴールに向かうため達成度が高くなりました。それに対しシナシナOKRが手元にあったチームは「こんな目標、達成できると思ってません」とゴールへ向かうモチベーションさえ湧かず、したがって達成度は低い状態でした。
であれば、ワクワクしたOKRを設定しない手はないですよね。

言うは易し。

「『ワクワクする目標を作る』?それができねぇから七転八倒してるんだろうがッ!!」そんな声がきこえてくるようです。少なくとも私の胸の奥からはそのような叫びが聞こえてきました。名著「Measure What Matters」でいうところの「組織全体に目的意識と連帯感をもたらし、多様な活動を結びつける」ような目標は、ゴールはどうやって作ればいいのでしょうか。

OKRオタクを自認する小田中がこれまでに経験したうまくいった（ワクワクした）目標設定、うまくいかなかった（シナシナした）目標設定についてふりかえります。
どうやったらワクワクさせられるのか、シナシナを避けられるのかについても触れていきます。そして、目指さずにはいられないOKR、ワクワクいきいきする目標を作り上げるための再現性のあるプロセスについて解説します。ワクワクの源は千差万別、だからこそ再現させるのは難しい。けれども内発的動機を駆り立て、互いのビジョンを共有しながら深く対話することで、壁に張り出したくなるようなOKRはできるんです。おっと、ここから先は本編で。

Direct URL:

★★★Deep Diveシリーズ第3弾!!★★★

Deep Diveシリーズでは、主にスクラムを始めたばかりの人、実践しているもののこれでいいのか？と不安を持っている人に向けに、スクラムの要素を詳細に解説しています。

これまで以下の2つをお届けしてきました。

• プロダクトバックログ Deep Dive（https://slide.meguro.ryuzee.com/slides/107）
• スプリントプランニング Deep Dive (https://slide.meguro.ryuzee.com/slides/111)

シリーズ3作目となる今回は、「スプリントレビュー」についてです。

スクラムの3本柱である透明性、検査、適応は、スクラムのあらゆる役割やイベント、作成物に関係します。
作成物の1つであるインクリメントも当然対象となります。そして、インクリメントの検査と適応の場が、スプリントレビューです。
不確実性の高い問題の解決に取り組んでいる私たちは、スプリントレビューを通じて、自分たちが作っているものが正しい方向に向かっているのかを短い間隔で検査し、学習した内容や環境の変化を踏まえて、適応していかなければいけません。

アジャイルマニフェストには「包括的なドキュメントよりも動作するソフトウェアを」という項目があります。
これが意味するところは、現物の重要性です。私たちはビジネス上の目標を達成するためにプロダクトを作っています。充実したドキュメントがたくさんあっても、プロダクトをユーザーに渡せなければ無意味です。プロダクトを使うユーザーがいなくても無意味です。プロダクトを使ったユーザーが、自分たちの課題を解決できなくても無意味です。
つまり、プロダクト（動作するソフトウェア）は核となるものであり、定期的にプロダクトそのものや、プロダクトに加わった変化（インクリメント）を実際に検査し、適応し続けなければいけません。

一方で、スプリントレビューが単なる進捗報告の場であったり、意味のある検査ができないようなものを披露していたりするような現場をたくさん見てきました。
これではスプリントレビューの意味がありません。
スプリントレビューはスクラムのイベントのなかで、いちばん重要なイベントです。このイベントをうまく運用できるかどうかで成果は大きく変わってきます。

以下に挙げるようなスプリントレビューの鉄則をはじめとして、スプリントレビューを圧倒的に効果的に活用するための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

• なにはともあれインクリメントを見せろ
• フィードバックを得られるようなインクリメントを用意しろ
• スプリントレビュー直前にインクリメントに手を入れるな
• プロダクトの状況や進捗を表す簡単な資料を用意しろ
• デモはプロダクトオーナーと開発者全員ができるようにしておけ
• スクラムチームの外側のステークホルダーを呼べ
• スプリントゴールに応じて、どのステークホルダーを呼ぶかを選べ
• スクラムチーム全員が参加しろ
• スプリントレビューのやり方を改善しろ
• スプリントレビューから逆算してスプリントプランニングしろ
• スプリントレビューの会話のメモを取っておけ
• スプリントレビューで「次のスプリントで対応する」とかコミットするな
• そのスプリントで何も完成しなくても、スプリントレビューをスキップするな
• とはいえ、とにもかくにもインクリメントを提示できるようにしろ

Direct URL:

私たちは筑波技術大学のチーム、「うきうきなっとう」です。

9月末に琉球大AgileTeamCampに参加し、初めてAgile開発を経験しました。4日間という短い期間でした。実際にプロダクトの開発を行ったのは2日間です。非常に短い期間の中でたくさんの発見がありました。

うきうきなっとうは聴覚障害のある大学生だけで構成されたチームです。メンバーの紹介をします。

• Hayato Yamamoto : 3年生
  • PO 兼 開発者
• Shota Fujie : 3年生
  • 2日目SM 兼 開発者
• Koki Saito : 2年生
  • 3日目SM 兼 開発者
• Naoya Hitaka : 3年生
  • 4日目SM 兼 開発者
• Shiyu Hirose : 4年生
  • 開発者
• RSGT不参加メンバー : 3年生
  • 開発者

一概に聴覚障害と言っても個人差があります。

聴力の重い軽いはもちろんのこと、音を言葉として捉えることができるかどうかも異なります。物心ついた時から手話を使っているメンバーや高校/大学に入ってから手話を学び始めたメンバーもいます。

全員が同じ情報を受け取れるようにさまざまな手段でアイデアや意見の可視化・言語化を工夫していった結果、チームの知見がどんどん表に出て共通認識を作ることができるようになりました。

本セッションでは、臆さない発言環境の形成にあたって、わたしたちが実際に行った工夫とその結果、そして聴覚障害という特性を絡めてお話しします。

Direct URL:

先日、とあるカンファレンスで「アジャイルって言うと、白い目で見られる」といった発言があり、今どき珍しいなぁと思いました。

……と同時に、私には少なからず心当たりがあります。事業会社のエクゼクティブや非アジャイルな同僚が「アジャイル」や「スクラム」と聞いてため息をつくとき、それは過去の経験からー

• 「やりたいことだけやりたがるエンジニア」
• 「自己組織化を盾に約束を守らないチーム」
• 「待てど暮らせど成果がでないチーム」

ーなどを思い出すのです……

そもそもエクゼクティブは、それほど開発プロセスにこだわりがありません。

これは関心がないということではなく「ビジネスで結果を出してくれさえすれば良い」と考えているからです。ですので、大抵のチームは開発手段について一任されており、求められる開発スピードを考えて「アジャイル」や「スクラム」を選択するチームが増えているのだと思います。

だがしかし。

本気でスクラムにチャレンジした方なら経験していると思いますが、プロダクトがアウトカムを達成しビジネス的な結果が伴うまではかなりの時間（とお金）がかかります。この「結果が出るまで」の時間を、首を長くして待てるエクゼクティブは案外少ない……ということにエンジニアは気づかないことが多いです。これはエクゼクティブがせっかちという事ではなく（せっかちな場合もありますが）、世の中の変化が早いので、チームにはそれだけスピードが求められている時代ということです。

そして、スクラムという手段はときにチーム内に「変な高揚感」という病気を蔓延させます。

この病気にかかると、伸びないベロシティを無視したり、POからの要求を議論なく棚上げしたり、スプリントレビューで完成していないPBIがあっても気にもとめず、ビジネスマネジャーはリスクを管理せず、スクラムマスターは「ポンポン」を振って応援するだけ……のような症状を起こします。

これを私は「エセ自己組織化」症候群と呼んでます。

本来、「市場の要求を早く実現するため」「実験を繰り返し勝ち筋を見極めるため」にスクラムという手段をとったはずであり、「結果を出せ」は（良い意味で）最大のプレッシャーであるはずです。

ところが「今の時代アジャイルだよね」「会社がスクラムでやれって言ったから」「定時で帰れるってよ？」「だってワクワクするじゃん？」といったマインドで日々をすごしていると、本来はビジネスを成功させるためにスクラムという手段をとっていたことを忘れてしまうのです。

では、こうならないためにはどういった改善をすれば良いのでしょうか。私たちは以下のように考えています。

1. エビデンスベースの計器飛行ができるように、計測とビジュアライズを徹底する
2. スクラムマスターを含むチーム全体のマネジメント力向上
3. プロダクトに関わるすべての人が、イヌワシのような視座をもつ

上記を踏まえ、いま、株式会社ビズリーチで取り組んでいる改善活動について紹介したいと思います。

Direct URL:

みなさん、「パワーポイントカラオケ」というゲーム？スポーツ？プレゼンテーション？をご存知でしょうか。
詳しくは当日説明しますが、簡単に言えば「パワーポイントを使った、制限時間ありの大喜利大会」です。

大喜利ってテレビ等で視聴することはあっても、自分が実施することってなかなか無いんですよね。
実際に実施してみると、手に汗握る緊張と興奮と安堵を、そして熱意と愛と友情を短時間に味わうことができるとんでもないゲームでやみつきになります！！
しかも、ダイバーシティと心理的安全性を体感でき、その大切さを実感し育成できる、本当に素晴らしいゲームなんです！！！

このゲームの素晴らしさを一人でも多くの人に知ってもらいたい！！
その一念で、今回も（※）命懸けで唄います。
今回は、「スクラム」をテーマに、大物ゲストもお呼びしての実演です。こうご期待！！

※2022スクラムフェス大阪で、パワポカラオケをお披露目しました。予想をはるかに上回る反響を呼び、イベント終了後、深夜までイベント参加者が勝手にDiscordで歌い続けるという現象を巻き起こしてしまいました。

Direct URL:

「アジャイル」という概念がさまざまな場面で使われるようになって久しいですが、アジャイルを開発手法としてとらえ、これを適用すること自体が目的化されているケースがしばしばあります。

アジャイルは、”Don’t just Do Agile, Be Agile”と言われることがあるように、手法ではなく状態であり、本来は「継続的に事業、ビジネスを成功させる」という目的に対する手段として「アジャイルな状態を作る」という考え方で推進されるべきものです。

本講演ではVUCAと呼ばれるこれからの時代の事業成長に必要なビジネスアジリティを実現する、NECのアジャイルの全体像とともにアプローチを3つの視点からご紹介します。

Direct URL:

※以下、招待講演の提案です。

【概要】

新しいアイデア、特に行動に移して価値を生むことができるアイデアとは、人の欲求を満たすアイデアである。
本講演では、「個人的欲求起点」というアイデア発想法を丁寧に解説しながら、商品開発やものづくりに役立つ考え方を提案する。

Direct URL:

T.B.D

Direct URL:

ソフトウェア開発に携わってこなかった方向けに、アジャイルに開発を進めるってどういうことか？を伝えてほしい、という依頼がありまして、以下の流れで話しました。

1. ソフトウェア開発ってどういうものなのか (ユーザー企業観点)
2. 要件というのはどういう風に考えるのか (狩野モデル)
3. 新規サービス開発への狩野モデルの適用 (ユーザーストーリーマッピング)
4. スクラムとはなにか、DevOpsはなぜ必要なのか

ホロラボ社内や、クリエーションラインさんに呼んでもらって講演をしたのですが、なかなか好評をいただいたと思いますので、RSGTでもお話しできればと考えました。公開の場では今回が初のトーク提案になります。

Direct URL:

ソフトウェアサービスの開発、運用にかかわっていると「ログ」は開発チームの生産性を左右する重要な要素だと実感します。ところが、「ログ」をどのような観点で書けばよいのか？ということに関してはあまり良いガイダンスを見かけません。本セッションでは具体例や効果を示しながら、インシデントの対応時間を激減させ、インシデント対応の自動化を促進するための「ログ」のベストプラクティスをご紹介いたします。

Direct URL:

◆セッション概要

本セッションでは、この1年半で220近いコミュニティの誕生/発展/離散を見てきた自分の経験と幾つかの学問(社会学/学習科学/文化人類学/生物学...)の力を組み合わせて、以下の内容をお話します。

• コミュニティが生み出す価値
• コミュニティが価値を生み出すようになるために育みたい要素と要素の育み方
• コミュニティの不吉な匂いと対策
• コミュニティを立ち上げ/維持/発展させるための具体的なアクション

上記のお話をすることで、セッションを聴いてくださった方が、価値を生み出すコミュニティを社内/社外問わずに作れるようになることを目指します。

◆本セッションのターゲット

コミュニティの立ち上げや運営に関わっている人(関わりたいと考えている人)を想定しています。
特に以下のような悩みを抱えている方は、本セッションの内容を聞くことで悩みが解決できると思います。

• 数千人規模の会社なのにコミュニティに所属する人が数人のまま
• 書籍を読んだり人から提案されてコミュニティ活動を行っているが、意義が感じられない
• コミュニティが続かずに離散してしまう
• 愚痴を吐き出す場にコミュニティがなっている
• 特定の人に高い負荷がかかっている

また、コミュニティがもたらす価値や存在する意義がそもそもあまり腑に落ちていないという方の参加も歓迎しています。

最後に、コミュニティに参加したいと考えている人の参加も歓迎しています。
本セッションの内容を聞くことでどのようなコミュニティを選ぶといいかの意思決定ができるようになります。

◆セッションの流れ(より詳細な内容はOutline/Structureを確認ください)

最初に、コミュニティが生み出す価値をお話します。
コミュニティが生み出す価値は多種多様であり、コミュニティの規模や公なコミュニティかどうかをはじめとした変数にも影響されるものですが、RSGTに参加している皆さんのコンテキストにできるだけ寄り添った形で生み出す価値を説明します。(アジャイルやスクラム関連のコミュニティのコンテキストに近いコミュニティが生み出す価値を説明します)

コミュニティが生み出す価値を共有した後は、価値を生み出すコミュニティに備わっている要素を説明します。
自身が関わったコミュニティの事例や過去に功績を残したコミュニティの事例をベースにしながら、なぜその要素が大切なのか？その要素を調整するには具体的にどのような行動を起こせばよいか？をお話します。
ここでお話しする要素の中身は静的ではなく、日々変化するものであり、調整が必要です。
そのため、調整が必要な「コミュニティの不吉な匂い」も併せて紹介します。

最後に、書籍『コミュニティ・オブ・プラクティス』で触れられているコミュニティの発展段階を紹介し、発展段階に合わせてセッションで説明した内容をどのように活かすか説明します。
書籍『コミュニティ・オブ・プラクティス』でも、発展段階ごとにどのようなアクションを取ると良いかは記載されていますが、本セッションでは、書籍に記載されたアクションの説明ではなく、セッション内で触れた内容を発展段階ごとにどのように実装するとよいかの一例をお話します。

Direct URL:

アジャイル開発をソフトウェア企業の働き方の最大公約数として捉えるムーブメントがひろまり、アジャイル実践者たちのアイディアは世界に溶け込みつつあります。ただゆっくりとしか進まない領域もあります。そう２０年前にKent Beckが取り組みながらもいまだにそうである、ビジネスや経営と開発の接合点です。

２年前に４７機関がデロイトトーマツコンサルティング合同会社に入ったときには部分しか見えていませんでした。私たちはつねに部分しか見ることができないからです。ですが、この２年で経営というものを理解しつつあるのも事実です。私たちはそこでまた同じ様に変化を始めました。どのように全体性を高めて、チームが、部署が、会社が生き生きとしていくのかにコミットするように。

４７機関はスクラムチームとしての実践からは遠ざかったとも見えますし、最もスクラムを実践しているとも見えます。スクラムの価値基準は考慮していますが、プロダクトオーナーはいませんし、スクラムイベントもありません。私たちの活動の中心はどのように自分とチームと経営が自律的に活躍するかです。

私たちはこれをLiving Managementと呼ぶ様になりました。「私たちのマネジメントはいきいきとしているか？」が考えることです。マネジメントにはさまざまな要因があるでしょう。触れ合うマネジメントは全てがターゲットです。もちろん世の中全てのマネジメントを実践する機会があるわけではありませんが。

本セッションでは経営のことを理解するチーム、チームのことを理解する経営とはどのように作り上げられていくのか？大企業に入ったチームはどのように相乗効果をだしていけるのか？を知ることができます。

部長、経営者としてどのようにチームに活躍してもらうのかを困っている方、チームとして経営の巻き込み方に困っている方、今後このようなことにチャレンジしていく方はぜひ聞いてみてください。そしてこれからの組織のあり方を共につくりあげていきましょう。

Direct URL:

KDDIアジャイル開発センター株式会社では、
auでんきの「auでんきアプリ」の開発、運用をLarge-Scale Scrum（LeSS）フレームワークで開始し、7年目に突入しました。
4チームでスクラムオブスクラムズを構成しています。

おかげさまで月間100万人以上のお客様に利用いただけるアプリへ成長しましたが、
以下のような多くの要望があります。

• より多くの魅力的な機能を短いスパンでリリースしたい
• プロダクト運営にかかわる対応をスピーディに行いたい
• 日々アップデートされるセキュリティ対策を施したい
• エンジニアは新しい技術をプロダクトで試したい

 etc….

これにより、POが全ての内容を理解して優先順位を決めることが難しくなり、
並行作業が多くリリーススピードの停滞が見えるようになりました。

また、プロダクトの期間が長いため人も入れ替わり、今の変化したやり方が当たり前になり、変えようとする気持ちも薄れつつあります。

スクラムを採用する意味を改めて考え直し、
より素早く市場へ投入できるようにカイゼン活動を行なっております。

スクラム導入の基本である
「スクラムを組織に導入する時は小さくても完璧なスクラムチームをまずは綺麗に回すべき」を2022年に心機一転から既存のLeSSチームの中で導入しております。

そんな私たちの既存プロダクトを運営しながらのカイゼンしていった内容と結果を皆様に共有いたします。

Direct URL:

"There is nothing dumb - or easy - about making complicated information accessible to an audience." - The Buckley School

Transforming Your Tech Talk is designed to share the process behind crafting presentations that successfully make deeply technical information accessible to audiences of all backgrounds and experience levels. No matter your job title or level, effectively communicating information can be a career game-changer.  The techniques you learn here will help you take everything from team presentations to pitches to leadership, and even conference talks, to a brand new level!

Direct URL:

働き方改革が刻々と変化している昨今、弊社では働き方や個々の成長に着目して、
日々のコミュニケーションや勉強会にアジャイルの考えを適応した「異世界」活動をしています。

Direct URL:

CDO補佐官として福井県のDX推進を支援するようになってから半年以上が経過しました。兼業という時間的制約がある中での活動ですが、少しずつ、やりたかったことが実現できつつあります。

• 部門横断チームでのVSM（バリューストリームマッピング）による業務改善
• 庁内に改善と助け合い活動を広げるための仕組みづくり

などなど、他にもいろいろと、県や市町の方とタッグを組んで進行中です。RSGT2023が開催されるころには、さらに多くの取り組みが成果として実を結んでいるはずです。

このセッションでは、アジャイル実践者として学び身に着けてきたマインドセットやスキルが、何にどのように役立ったのか、また、開発者・スクラムマスター・プロダクトオーナーとしての経験を、自治体のような従来型組織の変革にどのように適用していくと良いのかについて、なるべく具体的にお伝えします。

そして、世の中をよりよくするために、技術者が人々を巻き込んで変革していくことの意義についても少しお話できたらと思います。全国に補佐官仲間が増えるようにとの思いを込めて。

Direct URL:

私はこれまでenPiTという授業でチーム開発に参加したり、メンターとして複数のチームを見たりしてきましたが、その中でペアプロは心理的安全性の向上させるのではないかという仮説にたどり着きました。

ペアプロとモブプロの間には、大きな違いがあると考えています。それは、当事者意識の高さです。2人しかいない状況では、モブと違って自分が働かないと開発が進まないので、自然と仕事量も会話も増えます。ペアプロを通してペアとの信頼関係が強まることで、チーム全体においても発言しやすくなり、結果的に心理的安全性が高くなります。これは、モブプロにはない利点ではないでしょうか。

このセッションでは、

• ペアプロがなぜ心理的安全性を向上させるのか
• モブプロとの違い
• オススメのペアプロのやり方（現地で人を募って実践）

を中心にお話ししたいと思います。今回の内容は何か統計的なデータがあるわけではなく、あくまで私の経験から考えたことをお伝えしますので、賛否両論大歓迎です。わいわい議論をしましょう。

Direct URL:

I am going to share a case study of how we as coaches kick start a large scale agile transition and supported the product teams in the one year journey in the transition in FDA (Food & Drugs Administration) regulated organisation in healthcare industry.  The product teams include members with software, electrical and mechanical background. I will share how the transition get started, what are the phases during the journey, what are the main problems we try to address and what we did to achieve significant success. 

Direct URL:

「WF の方が向いてるプロジェクトもありますよね?」そんな議論を時々見かけます。

おそらく スクラムは、学ぶ価値のあるものなのか? それを見極めたいための質問なのでしょう。「自分の周りが WF に向いてるなら、スクラムを学ばなくても…」そんな免罪符を求めているような印象を感じてました。

スクラムは難しそうで、 WF は (みんなやってるから) 簡単というニュアンスを含んでいるようにも感じます。WF が簡単そうに見えるのは幻想で、誤魔化したり、後回しにしたりする振る舞いが習慣化されているのが実態なのですが…。 どんなプロセスを採用するにせよシステム開発は難しい ものなのです。

時は進み、 B.A. (Before Agile) を経験してない人も随分と増えてきました。「もしかして、あの地獄の日々を知らないから、 WF が向いてるかも…なんて疑問を持つのでは???」ふっとそんなことに気付きました。

かつて、社会全体が WF を目指して動いていた時代があったのです。完全な要件定義ができれば、完全な設計ができれば、次はきっとうまくゆくはず…と新しいプロセスが導入され、組織が細分化し、仕事はひたすら増えてゆきました。それでも、みんなが幸せになることはく、今に至っています。当時の経験者としては、あの頃に戻りたい気持ちはまるでありません。今、かつての WF を本気で目指しても、実践できる人はいないでしょう。また、財力も持たないでしょう。

そんな昔話を、朧げな記憶を紐解きながら、今時の 受注ゴール を間に挟んで、かつて目指した WF を露わにしつつ、対比としてのスクラムをお見せしたいと思います。

発表を聴いた後でも、(いろいろな事情で) 受注ゴールに関わり続けることになるかもしれません。ですが、迷いなく真剣にスクラムと向き合う気持ちを持ち帰ってもらえるはずです。

Direct URL:

Although almost all the Scrum Masters in general would have world class certifications, many of the Scrum Masters play non-significant or non-impactful role!

These people know the framework well, but still won't command respect for their role from teams or the management. The important aspect many people tend to ignore is, being a Scrum Master is to be a leader of the team. A leader who doesn't have a given/traditional authority, but when rightly understood & done can change the team as well as the whole organization.

This presentation would go through the topics about what to avoid and what to focus to become a Real Scrum Master.

Direct URL:

デイリースクラムについて、”守破離”という観点から考察した結果を共有します。

• なぜあえてデイリースクラムなのか？
• 毎日行っているし、もう十分にやってきたよ？
• ”昨日/今日/問題”を話し、その場で解決しないなら別場にするんでしょ？
• 改善の余地って、あるのかしら？こんなものだろう？

私は、頻度の高いイベントこそ、楽しく・有意義であるべきだと考えています。楽しさやポジティブな気持ちは、創造性を向上させます。チームとして有意義な議論も同様です。それらが、生産性や効率を高め、企業や個人・プロダクトの優位性を高めていくと思うからです。

また、デイリースクラムおける重要なのは、”ストーリー”というキーワードであると考えています。そのキーワードは、”昨日/今日/問題”という構造を捉えるサポートとなり、一人ひとりの状況や想いを効率よく共有するツールになると考えています。これを’破”に位置付け、発表の中心としてご紹介します。

およそ中級（Intermediate）の方を対象としますが、初級者・上級者の方にも、それぞれ「はっ！」とする示唆が提供できる発表を目指します。少しでも多くのディベロッパーにとって、日々が幸福なものとなりますように。その一助になれましたら幸いです。

Direct URL:

このセッションは、プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。

POやプロダクトマネージャーと、開発の活動の違い

POやプロダクトマネージャーは常に忙しくしていて、様々な領域のことを考えたり、行動をします。経営者に説明しに行ったり、顧客と話をしたり、いろんなカンファレンスに登壇したりします。これによって、POやプロダクトマネージャーは、様々なことを短期間で経験し、プロダクト開発について急速にラーニングしていきます。

一方で、開発者は開発を中心にしていて、外の世界で何が起きているのか興味はあっても、POに比べたら限られたことしか経験できません。

プロダクトの成否は、社内で起きていることだけではなく、外側で起こっていることにも大きく左右されます。顧客は社外にいます。社内が混乱していてもプロダクトの成功はままなりませんが、社外でもうまく活動していかなければなりません。

社外の知識のギャップは開いていく

プロダクト開発が進むにつれて、社外の知識のギャップは大きく開いていくでしょう。とくにプロダクトのリリース後にはこの傾向は顕著になります。POはより一層、顧客と話す時間が増えたり、イベントで登壇したり、メディアに関わるようになります。社外に関心を向けて活動する時間が増えます。

もし、このままプロダクト開発の社内と社外の活動の差が広がると何が起きるでしょう。仕事は役割に応じて分担する分業が進むことになるでしょう。一緒に仕事をする機会は減っていきます。、その結果、「私考える人、あなた考える人」という状況が増えやすくなります。

チームとしての成長と、ビジネス収益の両立を目指していても、それぞれが自分の役割に集中するがゆえに、いつのまにか相手の事情も知らずに仕事を丸投げする関係になってしまうかもしれません。ビジネス側、開発側という言葉はその表れです。

いつ問題に気付くのか

では、いつこのことに気付くでしょう。プロダクトが市場に受け入れられ、上昇気流に乗っているうちは問題は起こらないため、この分業は短期的にはうまくいくように見えます。しかし、売上や利用者の拡大と共に、採用活動は進み、人は増えます。増えた人が即戦力として活躍できるように、仕事は整理され、分業は更に進みます。

POと話したことも無い人も増えていくことになります。個人名が出ることもなく､ビジネス側、開発側という言葉によって自分達を区別しはじめたら、高度な分業の構造が私たちを取り囲んでいることになります。

他社の参入や新たな技術といった、自社プロダクトに大きな変化が求められたとき、この高度な分業体制は足かせになる場合があります。たとえば、POと開発者がお互いの考えを理解するために、初期とのころとは比べものにならない時間がかかるようになります。誤解やすれ違いも頻繁に起こるようになります。問題がはっきりと分かるタイミングでは遅すぎるということです。

ソフトウェア開発は上達したが、プロダクト開発に失敗した

スクラムを続けるとソフトウェア開発がうまくなります。ところが、ソフトウェア開発はうまくなっているのに、顧客のアウトカムへの貢献が薄かったり、自社の収益への貢献が低いままのことはよくあります。たとえば、新機能開発を止めて現状維持にしたとしましょう。顧客のアウトカムに影響がないとしたら、ソフトウェア開発はうまくなっていても、スクラムはうまくいっていないのかもしれません。

このセッションでは、どのような変化が待ち受けていてもしなやかに対応できるように、プロダクトの価値作りをPO一人のスキルではなく、チームとして獲得していく方法を解説します。

■アジェンダ
POやプロダクトマネージャーどのように世界を見ているか
・時間をかけずにインプットを10倍にする方法
・消費者の世界と開発者の世界
・コンビニの商品をどのように見るか

プロダクトマネジメントの領域
・今あるプロダクトを顧客に買ってもらう商品開発
・顧客にアウトカムを提供できるだけの余力を持つ組織を作る組織開発
・既存のプロダクトでは実現できないアウトカムを新プロダクトを通して提供する製品開発

太い経験と細い経験という機会格差
・私考える人、あなた作業する人
・プロダクトマネジメントする人、される人
・説明責任という機会
・企業の3つの言語「経営の言語、マネージューの言語、現場の言語」
・時間の壁

プロダクトマネジメントを実現する組織開発
・年老いた組織と若い組織
・高信頼組織と、信頼不要組織
・開発するか、学ぶか

プロダクトマネジメントをチームで日常化する
・自分達のためのウィークリーラーニング
・学び始める習慣

Direct URL:

スタートアップ企業は資金調達やIPO/M&Aといった派手な面が注目されがちですが、本質的には創業から急激な成長を追い求め、世の中に大きなインパクトを残すことを目指すスタイルの企業のことを指しています。
資金が燃え尽きるまでに成長し、利益を出すことを目指していく様は「墜落している飛行機を地面に激突する前に直して飛びあがる」と形容されるように、お金ない、時間ない、人もいない、ないない尽くしの環境です。正しさや意識の高さだけではどうにもならないことも多いヒリヒリする環境の中で、スクラムは機能するのでしょうか？

会社は始まったばかり。従業員もまだ全然いない。当然知名度もない。世の中に与えるインパクトへの確信と野心だけがある。時にはその自信を失い、慢心なのではと自己不信に陥る。それでも事業とプロダクトに向き合う献身の日々。そういった環境でいつからスクラムに取り組むのでしょうか？

上場企業とスタートアップ双方を経験してきたスピーカーの今までの経験から考えを共有します。

Direct URL:

Who owns it?

For a software development team, ownership is the responsibility each person takes to achieve the overall project objectives and its success. Culturally, teams in Japan and the West, particularly in the US, approach ownership quite differently. For the latter, it can amount to making sure we have someone to blame when things go badly, and for the former it can be so that no one can be blamed.

There are things to learn from both cultures, and a way we have seen successful teams deliver high-value outcomes for the stakeholders can be seen as a blend of both. Taking some ideas from the book “Extreme Ownership” we will review a way of thinking about ownership on software development project teams.

Japanese interpretation provided.

Direct URL:

『スクラム』の名前の由来となっている『ラグビー』。
そんなラグビーを20年間、クラブチーム、日本代表、海外のチームなど様々な環境でプレーしてきた私が、スクラムチームのPOを担当することになりました。
POになって半年間で感じたラグビーとスクラムの共通点、相違点について語ります。

スクラム経験者のみなさまも、ラグビーという新しい視点を通じて、改めてスクラムやチームを見直すキッカケになると幸いです！

聞き手は同じチームでスクラムマスターを担当している小糸が務めます。
参加者の質問もいくつか拾えればと思うので是非多くの質問をお願いします。

Direct URL:

組織の中でスクラムマスターが活躍できる環境を作るには、スクラムマスターをどうマネジメントするか検討する必要があります。スクラムを導入した企業から非常によく聞かれるのは、「スクラムマスターの評価はどうしているのか？」という質問です。

サイボウズでは、2022年5月に大きな組織変更を実施しました。詳細はこちらの記事をご覧ください。

マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
https://blog.cybozu.io/entry/2022/11/04/173000

今回の組織変更では、職能ラインとマネージャーを整備し、新たにスクラムマスター職能が誕生しました。現在、スクラムマスター職能には約15名のメンバーが所属し、私を含むアジャイルコーチ3名がマネジメントを担当しています。

スクラムマスターを職能として確立したことで、給与レンジやキャリアラダーを定義したり、成長支援のための1on1やコーチングといった、組織としてスクラムマスターを支援するための仕組みを日々検討しています。

本セッションでは、サイボウズのアジャイルコーチ3名がスクラムマスターのキャリア支援のために検討したことや、現在の取り組み・今後やりたいことなどを座談会形式で語り合います。

Direct URL:

皆さんは、リソース効率を重視するあまり、プロダクトの急拡大に組織が追いついておらず、フロー効率をないがしろにしたまま、プロダクト開発を続けてしまって、大変だった経験はございますか？

少人数だったときは、それでも問題なかったでしょう。しかしながら、プロダクトの規模拡大に伴い、人もどんどん増えて行き、徐々にリリースのリードタイムが遅くなってしまいます。

株式会社Mobility Technologies （以下、MoT）は、JapanTaxi株式会社とDeNAのオートモーティブ事業の一部が統合して2020年4月に誕生しました。
統合前は競合であった『JapanTaxi』『MOV』両アプリのそれぞれの強みを活かす形で、MoTとして最初の顔となるタクシーアプリ『GO』を統合からわずか5ヶ月でローンチしました。

タクシーアプリ『GO』は、2021年9月に500万ダウンロードを、2022年9月に1000万ダウンロードを達成し、約１年でダウンロード数が500万も増加し、そのユーザー基盤を急激に大きくしていっています。

この１年半、複数の職能横断チームでタクシーアプリ『GO』のユーザー向けアプリを開発してきました。

本セッションでは、職能別組織と職能横断チームでそれぞれプロダクト開発を行った話と、複数職能横断チームの運用について話します。

Direct URL:

過酷な労働環境や無理な長時間労働を強いられることでおなじみの「デスマーチ」。心身の健康や身近な人との関係を壊す、とても有害なものです。

デスマーチが有害なものであることは広く知られるようになりましたが、相変わらずさまざまな局面で発生し、巻き込まれたエンジニアを苦しめています。

では、なぜデスマーチは発生するのでしょうか？よく知られているのは、無理のある受注をきっかけに設定された無理のある要件やスケジュールが原因になるものです。ですが、話者はそれ以外の原因、しかも自分の内なる声が自身をデスマーチに追い込んでいくケースを経験しています。

本セッションでは、デスマーチから身を守るたったひとつの方法と、デスマーチが発生する3つの原因についてお話しします。「たったひとつの方法」を適切なタイミングで実行するために、デスマーチの原因を知り、発生をいち早く検知するための一助となることを’目指します。

Direct URL:

みなさん、楽しく価値あるソフトウェアを生み出す開発ができていますか？

様々なアジャイルな現場で、アジャイルコーチやアジャイル導入コンサルを実践しているメンバー3名が出演。
最近の現場の苦労話や最高にチームが輝いた話を、モデラーっぽく様々な側面から話をします！
（ライブ感を大事に筋書き無しで臨むため、理解しやすく構造化した会話になるかは、当日の雰囲気）

議論は論点を分かりやすくするように、書籍『Discover to Deliver』の「プロダクトの7側面」を中心に話してみたいと思います。

「プロダクトの7側面」

1. ユーザー：プロダクトの利用者や利用者の役割
2. インタフェース：プロダクトとユーザーや他システムの相互作用
3. アクション：プロダクトが提供する機能
4. データ：プロダクトが対象とするドメインやデータ、それらの間の関係
5. 制御：プロダクトが機能する際に守るべきルールや法規制
6. 環境：プロダクトが利用される環境や開発する環境
7. 品質特性：プロダクトが達成すべき利用上、または開発上の品質

アジャイルな開発をする際に「何を起点」として対話をするのでしょうか？
チームは「何の情報」があって、「どこの価値」を見いだすのでしょうか？

「プロダクトの7側面」から、最近の開発の話とかよくある現場の悩みなど、議論していていきます。
オージス総研の社内で行われている議論をRSGT参加者にも公開！
オージス総研ってどんな会社か！を体感して欲しいです。

当たり前だけど見落としてしまう「プロダクトの7側面」から、現場の状況と問題、その解決に向けた苦労話をみなさんに共有できればと思っています。

Direct URL:

お互いの論点がずれていて、会話が一向に噛み合わず、時間ばかりが過ぎていく。あるいは、「あの人の言っていることはいつも訳が分からない」「あの人とは相容れない」と憤った経験は、多かれ少なかれ皆さんも経験されたことがあるのではないでしょうか。また、このような会話や対立を「空中戦」と表現するのを見聞きしたことあるのではないでしょうか。

※以下、「噛み合わない会話と対立」の意味で「空中戦」と表記します。

こうした「空中戦」は、output/outcomeを出せずチームや個人のパフォーマンスを低下させるだけではなく、チームや個人のストレスを高め、チームの分解や離職のリスクにもつながり得ます。

一方で「空中戦」には、ある一定のメカニズムがあります。これを理解することで、解決を図ることは十分可能です。加えてそれらの方法は、後天的に習得できる、再現性のあるスキル・技術です。

このセッションでは、「空中戦」を終わらせ、相互理解や合意に辿り着けるようにするためのスキルおよび技術を、アンガーマネジメント・NVC（Nonviolent Communication）・マインドフルネスの3つの観点から、講演者自身の実践事例を含めて、「エモさ」を抜きに整理しお伝えします。

このセッションの内容を通じて、一人でも多くの方が「空中戦」を克服し、自信を持って行動しoutput/outcomeを出し続けられるようになり、結果多くの人の笑顔を花咲かせられるようになれば幸いです。

Direct URL:

「安定したチーム」は、機能するチームの前提条件として様々なところで紹介されています。

「真のチーム」の必須条件  
1.課せられた「仕事」が明確なこと  
2.チームの内と外を隔てる「境界」も明確なこと  
3.仕事のやり方を管理する「権限」が具体的に決められていること  
4.メンバーの顔ぶれがあまり変わらない「安定性」があること
『ハーバードで学ぶ「デキるチーム」５つの条件』

安定したチームは、チームのキャパシティを知ることができるため、ビジネスの予測をしやすくなります。
『STABLE TEAMS - Scrum Patterns -』

長続きするチームに仕事が流れ込む
『Team Topologies』

なんとなく安定したチームがよさそうであることは多くの方が同意されることでしょう。

一方で、目の前にある現場のチームを見てみると、

• 受託開発をしていて、案件ごとにチームが組成されるのでチームが長続きしない
• 組織的にはチームになっていても、個人商店化していてチーム感がない
• 組織の都合でメンバーの入れ替えが定期的に起きてしまう
• メンバーはほぼ固定されたチームになっているが、うまく機能していない

など安定したチームとは程遠い現実が拡がっています。

安定したチームが理想であることはわかるものの現実とのギャップがあると、自分には縁遠いものだととらえてそこで思考を止めてしまいたくなります。

でも待ってください！

メンバーを固定できない状態では安定したチームをつくることはできないのでしょうか？
メンバーを固定さえできれば安定したチームをつくることができるのでしょうか？

これに似た構図を私たちは知っています。
そうです、アジャイル開発です。

私たちは変化が多い状況でも思考停止せずに現実を受け止め、変化に対応してチームで協力して価値を生み出し続けることを目指すアジャイル開発に共感をし、コミュニティに勇気づけられて、現場で行動し続けています。

チームづくりにも同じことが言えるのではないでしょうか。

Silver Bullet Clubは、2016年にチームが結成されて現在に至るまで6年以上存続しているチームです。そこだけ切り抜くと安定したチームのように見えるかもしれません。ところが実際には、2回のチーム転職を経て、会社も変わり、一緒に仕事をするメンバーが変わり、仕事のドメインが変わり、常に様々な変化の中にいました。

変化が多い状況でも諦めずに、Silver Bullet Clubであり続けようとしました。その活動の中で、安定したチームとはどのようなチームなのか徐々に理解ができ、機能する安定したチームになるための具体的なアイデアを試行錯誤してきました。

本セッションでは、安定したチームとはどのようなチームなのかを解説し、変化が多い状況の中で機能する安定したチームをどのようにつくっていくのかについて知ることができます。

様々な変化がある難しい状況の中でも諦めずに、機能する安定したチームを目指したい方はぜひご参加ください。

Direct URL:

世界経済フォーラム・世界銀行（World Bank）が発表した男女格差のレポートによると、ジェンダーギャップ指数は日本は116位です。女性マネージャーの数はOECD諸国の中で最も少なく、長い間、その状態が続いています。

アジャイルコミュニティで仕事をしている時はそこまで感じることがないこの話題ですが、それでも私がコーチしている非IT企業や、スクラムトレーナーとして女性達に出会うと、女性は孤軍であることが多いです。（特に管理職となるとなおさらマイノリティ！）

Harvard Business Reviewにあるように、アジャイルは開発手法ではなく、文化を作ることです。
アジャイル変革を遂行している中でうまくいっている組織、失敗した組織に関するこの調査では、
"プロセスやツールよりも個人との対話 "の重要性を改めて掲示しています。
アジャイルチームが協調的な対話プロセスを行うためには、最終的に心理的安全性（ありのままをさらけ出すことがよしとされる環境）にかかっている、ともあります。

アジャイルな環境で女性をはじめ、より多様な人々が、コラボレーティブに、リーダーシップを発揮するにはどうしたらいいのでしょうか。

私達が働くSlalom(スラロム)は、シアトルに本社を置くデジタル変革専業のコンサルティング企業です。フォーチュン誌の「最も働きがいのある会社」100社に7年連続で選ばれており、13,000人の社員のうち女性の比率が４割を超えている稀有な企業です。

ダイバーシティや、女性活躍などこの手の講演やプログラムはすでにたくさんありますが、
今もなお、見える結果が出ていないということは、まだまだやりようがあるはず。
入社してすぐに、この会社の秘密や知恵を収集して日本で活かせることがないか、
思い切って調査をしようと思い立ちました。

なぜなら私自身も、リーダーの役割を持って働いた経験がなく、なんとなく自分からは遠い存在だと思っていたからです。

このセッションは前後半を通じてアジャイル文化を体現する組織（人間中心・コラボレーティブ、フィードバックと適応、多様性など）やリーダーとは何か？を探求していきます。

◆前半
前半は調査結果とインサイトを共有します。
調査に関しては実施するにあたり２つの観点と仮説を持って調査を行いました。
 ＃統計学的観点での調査はしていません。あくまでインサイトを得るための、定性的なものが多いです
＃ID＆Eは性別だけが対象ではありませんが、今回は女性参画に焦点を当てています

(1)内的環境はどうか？
マネージャーとして活躍しようとする本人の動機があると思うがそれは何か？またはマネージャーとして選ばれる資質はあるのか？（きっとスーパーウーマンが自分で機会を勝ち取りに行っている人が多いだろう）

(2) 外的環境はどうか？
なぜ、マネージャーとして活躍できるのか？マネージャーとして活躍し続けることができる環境は何か？
（より大きな責任ある仕事や管理する仕事を任されることに喜びを見出しているんだろう）

社内のさまざまなチャネルにポストやメールをしまくり、集まった回答は約80。
その答えは私の想像するものとは正反対のものでした。
また、それらの結果にも驚くべき相関がありました！（お楽しみに！）

◆後半
後半では、Slalomで20年実験を繰り返している独自の制度や仕組み、運用方法についても具体的に共有します。
（People Leaderの定義と評価、キャリアフレームワーク、フィードバックの仕組みなど）

アメリカ各地域の女性リーダーたちが、快く、日本の女性リーダーの応援のために、また
インクルーシブな組織が生まれるように、たくさんのエールと事例を教えてくれました。
本セッションでは、日本の大きな組織で実際にリーダーを担ってきたメンバー、人事領域や組織の立ち上げを数多く行なってきたメンバーと、事例を踏まえながら発表します。

Direct URL:

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1札幌グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）

お題は下記のフォームで募集し、当日はその中から厳正なる抽選で採用されます。
https://forms.gle/2kbEnRqeAvU6EyFu7

Direct URL:

株式会社スタメンのプロダクト組織は、2022年より大規模スクラム(LeSS)を導入しました。スクラム未経験の組織の中で、LeSSを導入するに至った背景、導入に向けた活動、導入後の躓き、そして事業部全体の「アウトカム」への向き合い方に関する変化についてCTOの視点でお話します。

2021年下期に、CTOとして当時の事業部全体においてという課題を感じていました。

・プロダクトの理想状態が共有できていない
・機能リリースという結果にフォーカスし過ぎており、プロダクトの価値提供に目を向ける機会が少ない

また、プロダクト組織へは以下のような課題を感じていました。

・なんとなく一体感がない
・マネージャーへの依存が強く、現場でのリーダーシップの発揮を感じない
・意識がプロダクトロードマップありきなので、優先順位変更のコストが高く、ビジネス上の変化に弱い
・個人にちゃんと仕事がアサインされているかを気にしすぎて、価値提供スピードを意識できていない

2021年の年末にかけて、この課題感をチームへ伝え、少しずつ共通認識を作りながら、2022年1月に以下の組織体制の変更とともにスクラムを導入しました。

・コンポーネントチームの解散
・エンジニアリングマネージャーの廃止

まず3チーム同時にスクラムを導入し、2022年3月より3チームすべて統合し、本格的にLeSSに取り組みはじめました。

スクラム未経験にも関わらず、短い期間で一気にLeSSを導入しようとしたために多くの問題が生じました。まずは体制変更による混乱から始まりました。そして、LeSSのはずなのにチーム同士の助け合いが生まれなかったり、プロダクトの全体のゴールが曖昧になってしまったり、他のCXOやマネージャーの巻き込みにも苦労したりと、上手くいくことばかりではありませんでした。

それでも着実に一歩づつ前進して、1年間を通してプロダクト組織全体のプロセスやカルチャーの変化を感じてきており、徐々に事業部全体としてプロダクトの「アウトカム」への意識が醸成されてきたことを感じています。そして今では、他のCXOを含め組織全体として「アウトカム」への理解も深まり、LeSSの効果を強く実感しています。

私CTOとしてもプロダクト組織のスケールに大きな自信を持てるようになりました。このスケールへの自信がさらなる組織拡大の意思決定を後押しし、東京都内に新開発拠点を立ち上げるに至りました。

本セッションでは、スタメンの会社やプロダクトの紹介、そしてスクラム未経験の組織がLeSSを導入する際に生じる問題点や、ゼロイチでスクラムを導入していく際のCTOならではの視点でお話します。

※本セッションは株式会社スタメンによるスポンサーセッションです。

Direct URL:

オンラインのアジャイルチームのビルディング、うまくいってますか？ 私はうまくいきませんでした。

本セッションでは、オンラインでのチームビルディングの反省を通じて、オンラインネイティブなチームビルディング・チームワークの手法としての「ながら聞き」についてご紹介します。

また、「ながら聞き」の実証実験のためのアプリを開発し、それを実際にチームで利用した効果についてお話します。 

※本セッションは Team on Air のスポンサーセッションです。

Direct URL:

このセッションは、RSGT最終日に行われるOpen Space Technologyを120%楽しんで帰ってもらうために、OST初めての方から経験者の方まで、そしてオフライン参加でもオンライン参加でも簡単に実践できるちょっとしたコツやテクニック、マインドを持ち帰ることができるセッションです。
紹介するtipsはRSGT最終日のOSTで早速実践できるだけでなく、別の場所や皆さんの職場でOSTを立ち上げてみる、もしくは参加してみる場面でも役に立つでしょう。

------------------------------------------

RSGTが大事にしているのは"gathering"ですよね。
会場、ホワイエ、廊下、下の中華、Discord…いたる所で自然発生するギャザリング。
もちろんセッションも魅力的ですが、参加者同士でワイワイ交流する文化がすごく素敵で私は大好きです。
ですが、私が初めて参加したアジャイル系カンファレンスでは、知らない人たちと自分から会話するなんて怖くて特に交流できないまま帰宅したのを今でも覚えています。

私はRSGTのギャザリングのメインステージはOSTだと思っています。
参加者のみなさん一人ひとりが尊重される場です。そして、お互いのパッションがぶつかり合う場です。
この場をただの傍観者として参加するのではなく、最高の価値体験の場として欲しいです。
しかし、そんな素敵なOSTの楽しみ方を伝えるセッションが無いことに気付いてしまいました。

RSGT2020のOSTをきっかけに人生が変わった私が、あの時行動したことや体験したこと、あれから約3年間で数多く参加してきたオンライン/オフラインOSTの経験をふりかえり、誰でも簡単に実践できるtipsをお伝えします。
皆さんにはこれらを知ることで、RSGTの3日目に控えるOSTを120%楽しみ、人生を変える体験をしてもらいたいと思います。

特に、初めてRSGTに参加する人や、OSTを経験したことがない人、テーマが思い浮かばない人に聞いてもらいたいセッションです。

もし、RSGTのOSTに参加できなくても大丈夫！このセッション動画を見ていただき、スライドを利用してもらって、皆さんの職場でOSTを立ち上げてみたり、別の場所でOSTに参加する機会がありましたら実践してもらえたら嬉しいです。

------------------------------------------

■セッション内容

・なぜ、このセッションを提案したのか
　・人生初のOSTでの経験と後悔
　・OST初参加にはハードルが高い
　・OST参加への心の準備を高める

・Open Space Technologyとは
　・OSTの起源
　・1つの法則と4つの原則

・こんな時、どうしたらいい？？OSTで実践して欲しいtips4選
　・どんなテーマを出していいか分からない！
　・何から話せばいいかか分からない！
　・何を話したらいいか分からない！
　・OSTでは盛り上がったけどそこから先に進まない！

・一緒にテーマを考えよう
　・「実は」トーーク！

Direct URL:

Direct URL:

私が経験した中でもっともハードな「人の気持ちになるワーク」をRSGTの参加者の皆さんだからこそ届けたい。
説明や本だけでは得られない実感を味わい、見えていたのに見ていなかった視界を手に入れて下さい。

スクラムやアジャイルに限らずさまざまな場面で「共感する」「相手の気持ちになる」「相手の立場になる」という言葉を聞きます。いったいどうなれば「共感する」「相手の気持ちになれた」「相手の立場になれた」と言えるのでしょうか？この問いに対して、私が持つ一つの答えであるワークショップを行います。

RSGTを終えたあと
1on1や家族との対話で今まで以上に相手の考えが理解できるようになったら嬉しくありませんか？
同僚の内面から自分を見て、同僚に伝わる言葉を使えたら嬉しくありませんか？
「お前は人の気持ちがわからない」と言われていたのに、人の気持ちがわからないのは「お前は人の気持ちがわからない」と言っている人だったと気づけたら、対策が取れるようになりませんか？

このワークショップでは実際に相手の立場と自分の立場のそれぞれに自分で立って対話をしてもらいます。有意識下では「気づいていなかった」「気づきたくなかった」相手や自分の考えや主張が見えてきます。あくまで貴方が持っている相手の情報から相手を推測するに過ぎません。しかし、無意識ではわかっていた、気づいていなかったことはたくさんあります。今、時点でわかり得る情報を元に全力で「相手の気持ち」を考えてみましょう。

• ある人は上司と向かい合い、上司が常々言っている良い評価を受け止められるようになった。
• ある人は配偶者と向かい合い、目を瞑って避けていた配偶者の思いを少しずつ受け止められるようになった。
• ある人は義母と向かい合い、夫婦と義母の軋轢を解消する糸口を見つけ出した。

このワークショップでは、参加者ペアで行い、参加者にとって実在する相手を題材に行います。大っぴらに言いづらい事を言わざるを得ない場合があるのでご注意下さい。お互いの加えて守秘義務を守ってご参加下さい。

体感してもらう場であり、やり方を教授する場ではありません。やり方を身につけたい方は専門家の支援を受けてください。

Direct URL:

みなさんのスクラムは、成果を上げていますか？「期待とは違うんだけど...」なんて感じていませんか？

スクラムイベントを型どおりになぞってはいるが期待した効果が得られておらず、チームの士気が低い残念なスクラムを「ゾンビスクラム」と呼びます。クリスティアーン・フルヴァイス、ヨハネス・シャルタウ、バリー・オーフレイムの3名が、参考『ゾンビスクラムサバイバルガイド』で、そのように名付けました。ゾンビスクラムにかかると、スクラムチームはステークホルダーのニーズを知らない、プロダクトを速く出荷しない、継続的に改善しない、自己組織化しないの4つの症状が現れることが分かっています。どうです？身に覚えありませんか？

本ワークショップセッションでは、4つの症状のうちの1つ「自己組織化しない」に着目し、書籍の中にあるチームが自己組織化するのに役立つグループワークをおこないます。

さて、スクラムを使ってプロダクト開発をする際、関係する人たちを巻き込み、全員で取り掛かることが望ましい状態です。ただし、場にいる人の個性は実に様々なので、その人間的要因で機能不全に陥る可能性もあります。それを避けるためのファシリテーションツールに「リベレイティングストラクチャー」というものがあります。『ゾンビスクラムサバイバルガイド』に掲載されているグループワークはこのリベレイティングストラクチャーに基づいて構成されており、ゾンビスクラム状態から脱却するためのファシリテーションテクニックが集められています。本ワークショップを通じて、スクラムを補佐するリベレイティングストラクチャーの存在とその使い方の例もお持ち帰りいただけるでしょう。

さあ、役にたっていないスクラムに血を通わせよう！

Direct URL:

☆クラファンはじまりました☆

☆https://greenfunding.jp/thousandsofbooks/projects/6857☆

皆さんは、よく研修を受けられていますよね？

退屈な研修とそうじゃない研修の違いは何ですか？？

皆さんは、これまで学校に通っていた方がほとんどだと思います。

授業って面白かったですか？退屈でしたか？

退屈な授業とそうじゃない授業の違いは何ですか？？

このワークショップでは、これからクラウドファンディングで出版予定である、Training from the back of the Room!　のエッセンスを凝縮させて、参加者の皆様に「真の学びとは何か」「そのために講師・教師はどうあるべきか」を体験して頂きます。

実はこれ「教えない教え方」なんです。とっても興味が湧きますよね〜。もし興味が湧いた方は是非ご参加ください！

スクラムマスターの重要なスキルとして、『ティーチング』がありますよね。このティーチングを高めるためにも必要な考え方になります。

今回、Reginal Scrum Gathering Tokyoなので、「スクラム」を参加者の皆様で学びましょう！

スクラム初心者の方でも安心してご参加いただけます。スクラム熟達者の方も「教えない教え方」を学ぶことができます。

また、スクラムマスターの方に向けては、スクラムイベント・アクティビティでの応用の仕方も少し触れようと思います（ワークショップ後ご希望の方へ）。

もう『スクラムイベントが退屈だ』なんて言う人はいなくなりそうです！

Direct URL:

組織変革の必要性や方法論は現代に限ったものでなく、古くから研究実践があるテーマです。書籍やWebを探せば方法論をすぐに見つけることができます。では、その方法論を使えば実際に組織に変化が起こるのか、というとそんなに簡単な話でありません。

本当に難しいのは、「正論・方法論はわかったけど、それをどうやって実践するのか？」「どうやって実行（Execution）していくのか？」という点です。例えば、「今までのやり方じゃダメだ！これからはこうやるんだ！」と突然取り組んだとしても、周囲のメンバーがついてきてくれなければ変化は起こりません。起こったように見えても表層だけでしょう。

発表者のように歴史がある企業で変化を起こそうとする場合、数十年以上（場合によっては100年以上）に渡って蓄積された文化・制度に向き合う必要があります。本キーノートでお話しする内容は、まさに発表者が向き合ってきた内容や考え方です。つまり、蓄積された文化や制度により良い状態へ変化を起こすべく取り組んできた施策・変化が難しい要因・実際に上手くいったこと、いかなかったこと・学んだことをお伝えします。

最後に日本型企業で難しさに向き合う個人としてのキャリア観をお伝えして終わります。

Goal of this talk

本発表をお聞きいただいた後に、皆様の状態が以下となることを狙います。

• 日本的な企業で変化を起こすための考え方・プラクティスを知っている
• 変化を起こすために必要なマインドが高まっている
• 何より勇気づけられている

Direct URL: