★★★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年の経験でアップデートした内容でお伝えします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2021年下期に、CTOとして当時のプロダクト組織へ以下のような課題を感じていました。

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

当時は、プロダクト組織のパフォーマンスに懸念を感じており、また今後開発者が増えたとしても全体のパフォーマンスが上がらないのではとプロダクト組織のスケールに自信がありませんでした。

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

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

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

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

それでも着実に一歩づつ前進して、1年間を通してプロダクト組織全体のプロセスやカルチャーの変化を感じてきました。

そして今では、他のCXOを含め組織全体としてスクラムへの理解も深まり、LeSSの効果を強く実感しています。私CTOとしてもプロダクト組織のスケールに大きな自信を持てるようになりました。このスケールへの自信がさらなる組織拡大の意思決定を後押しし、東京都内に新開発拠点を立ち上げるに至りました。

本セッションでは、スクラム未経験の組織がLeSSを導入する際に生じる問題点や、ゼロイチでスクラムを導入していく際のCTOならではの視点で赤裸々にお話します。そしてプロダクト組織のスケールのヒントになれば幸いです。