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.

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

【概要】

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

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

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

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

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

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

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

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

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

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

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

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

以前は

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

こうした「空中戦」は、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!

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

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

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

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

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

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

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』のユーザー向けアプリを開発してきました。

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

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

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

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

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

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

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

だがしかし。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

銀行の開発は？というと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば、

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

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

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

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

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

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

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

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

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

More Effective Scrum シリーズ(?)

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

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