Unleash Your Agile Leadership Potential and Guide Your Entire Organization Toward Agility

Leadership is one the most significant challenges to business agility adoption faced by

organizations. Leadership is a key factor―individuals who welcome complexity and know how to leverage influence, culture, and organizational design to align widely distributed teams are integral to success.

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

【概要】

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

★★★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)の吉羽が体系的に解説します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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!

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. 

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は人を「機械」ではなく「人間」として捉え、人が活きるための施策をとっているが、根底にはヒエラルキーが存在するようなマネジメントを指しています。

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

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

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

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

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

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

言うは易し。

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

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

アジャイリストなみなさんこんにちは。みなさん、「コーチング」という言葉を耳にする機会が増えたと感じてませんか？これはあくまで個人の観測範囲に過ぎませんが、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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

です。

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

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

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

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

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

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

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

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

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

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

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

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