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やDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

今回のゲスト(予定、随時更新)

• furoshiki.fmのみなさま
•  

過去の放送は、links欄にあります。

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

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

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

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

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

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

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

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

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

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

でも待ってください！

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

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

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

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

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

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

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

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

プロダクトゴールについては、昨年の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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 etc….

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私はアジャイルには20年ほど前から取り組んでおり、アジャイルコーチとして10年ほど活動しています。
10年前から、自分が大切にしていることはそれほど大きく変わっていませんが、もたらすこと、考えていること、やっていることは変わってきています。

そんなアジャイルコーチについて最近特に「アジャイルコーチってどんなことをするの？」と聞かれることが何度かありました。

理由の1つにアジャイルコーチと名乗る人が10年前と比較して増えたこともあるでしょう。また必要に応じて、いろいろな組織が外部の力を適切に借りる選択をすることが増えたかもしれません。その一方、1つのチームや組織が複数のアジャイルコーチの振る舞いを見たり、比べたりする機会を持つことはそこまで多くないかと思います。

私は、アジャイルコーチとしての経験が長い人ほど、その経験に応じて引き出しがあり、それぞれのアジャイルコーチとしての考えや特徴が強く出てくるように思います。

アジャイルコーチの力を借りる時には、そのアジャイルコーチがどのような価値をもたらすのか、どんな考えをしているのか、なにを得意としているのかを知ることが、より良い結果を引き出すポイントの1つです。

このセッションでは、私がアジャイルコーチとしてもたらそうとしているのか？何を考えて、どんなことをしているのか？という"アジャイルコーチの1つの類型、中村洋の場合"をお話します。

こーんにーちはー！！！！！！！！

え、え、え、ちょっと待ってちょっと待って？

このセッション、明るくなーい！？？？

「見積り」という言葉を見て、あなたは最初に何が思い浮かびますか？

「スクラムをプロジェクトや案件に使おう・推進しよう！」と考えた人が最初にぶち当たる壁がこの「見積り」なのではないかと私は思います。受託開発であっても、自社開発であっても、案件やプロダクトゴールがいつ頃デリバリーされるのかは最初に見積る必要があります。

開発はアジャイルに繰り返し・漸進的に進めていきたいが、いつ頃デリバリーさせるのか「見積り」を最初に出さなければいけない。この相反する両者の解を出すヒントになるのが「不確実性コーン」です。

「不確実性コーン」とは、スティーブ・マコネルが著書「ソフトウェア見積り」で紹介したもので、プロジェクトが進むにつれて不確実性が収束していくかを示したものです。
https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/

「スクラムを始めたい！だけど、デリバリー時期を最初に提示しなければいけなくてスクラムではそれをどうやって計画するのかわからない」、もしくは「スクラムを始めたけど、数か月・いくつもの先のスプリントを見越してデリバリー時期をステークホルダーに伝えるのが難しい」と感じている方に、「不確実性コーン」を用いた見積りを行うことの提案と、私の実践から見えたコツや落とし穴についてご紹介します。

私がシステム開発の業界で新米SEとしてキャリアをスタートして、「見積り」という言葉を最初に聞いたときを思い出してみると、「見積り」という言葉はたいそう重厚な言葉に聞こえました。

それまでの私の認識は、「見積り」とはお金に関する見積りで、車を買うときなどに出してもらうようなある程度精緻なものだと思っていたからです。
車を買うときの見積を出してもらって、実際に「買います」と言った後に請求された金額が見積の1.5倍だったり2倍だったりすることはまずないですよね？私の中で「見積り」とはある程度精度の高いものであるという認識だったのです。

しかし、システム開発の業界の「見積り」はそうではありません。
まず、必ずしもお金に関する見積りではないという点があります。QCDS（品質・コスト・デリバリー・スコープ）でいうと、以下のような視点で見ていました。

• スコープ
  • 何をやって、何をしないか
  • 見積り時点で決めてしまうことが多い（決めた気がないかもしれないが）
•  コスト
  • プロジェクトがどれくらいの人工（人月を使うことが多い）なのか
• デリバリー
  • 納品時期、リリース時期
• 品質
  • 品質を保証しつつ、コストを抑えてデリバリー時期を守れるようなバランスを取る

これらを総合した結果、「何人の稼働が必要」と「何か月」がわかることでそろばんをはじき（単価という話もありますが今回は省きます）、プロジェクトの見積り金額が見えてくるという流れです。

見積りという言葉を重厚に受け止めていた当時の私は、「見積りって難しそうだし、金額をエンジニアが出すって大変そうだなー」と思っていたところから、「見積りって人数・期間・単価がわかればエンジニアでも出せるじゃん！できそう！」という考えになりました。

しかし、そう簡単な話ではないですよね。

実際に自分がプロジェクトを見積りして、そしてプロジェクトに着手してみるといろいろな問題があることが見えてきます。

• 見積り時点でわからないことがある場合、どうやって見積ればいいの？
• スコープまだ決まってないんだけど。。。
• 品質もスコープもコストもデリバリーも決まっているけど、どう見積ってもコストとデリバリーが溢れそうなんだけど。。。

そのような壁にぶち当たり、プロジェクトはデリバリー時期を守るためにエンジニア稼働を上げてメンバーが疲弊していく。
どうにかプロジェクトをやりきっても、次のプロジェクトの見積りで同じ壁にぶち当たる。。。

ここまでが、私が新米SEとしてプロジェクトの見積りに向き合っていたときの流れです。

そして、時は流れて私はアジャイルやスクラムに出会い、システム開発のプロセスに繰り返し・漸進的なアプローチを導入してきました。

しかし、開発プロセスはアジャイル（俊敏で柔軟）になってきましたが、見積りはどうでしょう？

見積りはいまだに重厚長大で、最初に作成したQCDSの見積りが力を持っており、プロジェクトのさなかに起きる「事実」よりも当初の「計画」が優先される状態だったのです。

スクラムチームや開発プロセスはアジャイルなのに、プロジェクトや案件の見積りがアジャイルではないとはどういうことなのでしょう？
（ここでいうプロジェクトや案件の「見積り」とは、プロダクトバックログのPBIの見積りやスプリントバックログのタスク見積りではなく、より大きなエピックやプロダクトゴールのデリバリー時期を指しています）

残念ながら、スクラムガイドには「見積り」に関するガイドラインは掲載されていません。

プロダクトバックログアイテムには「サイズなどの詳細な情報」がある。見積りに使えそうな情報はそれだけなのです。

スクラムをプロジェクトや案件に使おう・推進しようと考える人がぶち当たる壁がこの「見積り」なのではないかと私は思います。

アジャイルに繰り返し・漸進的に進めていきたいが、いつ頃デリバリーさせるのか「見積り」を最初に出さなければいけない。そんな場面に出くわしたこと、ありませんか？

そのようなシーンにおいて役立ちそうなのが「不確実性コーン」です。

このセッションでは、スクラムチームの見積りに「不確実性コーン」を入れ込んでみた結果、どのような変化がもたらされたかをご紹介します。

スクラムの見積りで教科書となる「アジャイルな見積りと計画づくり」を参考文献としつつ、実際のスクラムチームに「不確実性コーン」をどのように落とし込んでいったかを実例ベースでご紹介しようと思います。

今スクラムをやっているけど見積りに課題を感じている・スクラムをやっていきたいけど見積りが上手くできるか不安だ、そのように感じている方にヒントや気づきを与えられるようなセッションにしたいと思います。