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

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

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

「プロダクトの7側面」

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

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

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

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

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

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

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

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

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

スクラムを型どおりに実践しているけど、「期待通りではない」「スクラムが役に立っているのか疑問だ」とか感じることはありませんか？ 遠くから見るとスクラムを実践しているようでも、チームの近くでよく見るとどこかがおかしく、残念な状態ではありませんか？ 毎日デイリースクラムを開いているし、スプリントの最後にはレトロスペクティブも実施してます。完成の定義もあります。しかし、チームの士気は低く、自律性も、改善もありません。

クリスティアーン・フルヴァイス、ヨハネス・シャルタウ、バリー・オーフレイムは、そのようなチームの状態をゾンビスクラムと呼び、そこから回復するための方法を41個の実験にまとめ、『Zombie Scrum Survival Guide（邦題：ゾンビスクラムサバイバルガイド）』を書きました。この本には、ゾンビスクラムの症状は次の4つの領域に現れると書かれています。

• ステークホルダーのニーズ
• 速い出荷
• 継続的改善
• 自己組織化

このセッションでは、『ゾンビスクラムサバイバルガイド』の翻訳者である3名が、書籍の内容を元にゾンビスクラムから回復するための実験をそれぞれの領域から1つずつ紹介します。また、チームを診断する方法についてもご紹介します。みなさんのチームがもっと良くなるヒントになれば幸いです。

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

遠くから見るとスクラムのようでも、近くで見るとそれとは程遠い、やる気を失わせる残念なスクラムを「ゾンビスクラム」と呼びます。スクラムイベントを型どおりになぞってはいても、期待した効果が得られていない――そんな状態です。ゾンビスクラムにかかると「ステークホルダーのニーズを知らない」「速く出荷しない」「継続的に改善しない」「自己組織化しない」の4つの症状が現れることが分かっています。どうです？身に覚えありませんか？

本ワークショップは、ゾンビスクラムの見分け方や回復するための様々な実験を紹介した書籍『ゾンビスクラムサバイバルガイド』をもとに、ゾンビスクラムの症状・原因をお話しします。そして、4つの症状のうち「継続的に改善しない」に着目し、チームが改善する能力を高めるのに役立つ実験を体験していただこうと思います。

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

プロダクト開発をするとき、みなさんはユーザーのニーズを発見するために、どのような方法を使っていますか？ ユーザーへのヒアリングをしたり、ユーザーの行動を観察したり様々な方法がありますが、実際にやってみてうまく進められない、思ったような効果が得られないなど、課題を感じてはいませんか？ ヒアリングや行動観察にはうまく進めるためのコツがあります。

オージス総研は、「行動観察」のパイオニアとして15年以上にわたって多くの新価値創造のご支援を実施してきました。このセッションでは、弊社のこれまでの経験から、次の手法における陥りがちな誤りと上手く進めるためのコツをご紹介します。

• インタビュー
• 行動観察

（このセッションはスポンサーセッションです）

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が刊行されもうすぐ2年が経ちます。導入事例が少しずつ広まってきたものの、本だけ・成功事例の話だけを元に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか?

Rettyでは2019年10月に全社でLeSSを導入・推進することを決定し、1年をかけてtoC向けのWeb/アプリ開発、toB向けWeb開発が合流しました。導入過程で問題もありましたが、一つずつ改善を行い、導入して効果があったと言える程に成功を収めています。

本セッションでは大規模スクラム本の翻訳者の水野さんをモデレーターに迎え、Product Ownerを務めるプロダクト部門担当執行役員 野口、VPoEを務めるエンジニアリング部門担当執行役員 小迫の2名が、成功事例の紹介だけでなく、導入過程の悩みや苦しみ、失敗事例なども包み隠さずお話しします。皆様の大規模スクラムの導入に少しでも参考になる情報が提供できればと考えております

1チームがそれなりに成果出すにはかなりの努力が必要です。

ましてや、普通に複数Scrumチームは難易度hardですよね…？
チームがScaleするには、どんな現実の「制約」が問題なのでしょうか？

より上の、より先のチームや開発を目指したい方にSAFeとLeSSから学んだことを伝えます。

大規模なアジャイルの難しさ

「大規模アジャイルってどんなものなの？」

大規模≒Enterpriseという認識で大規模開発にアジャイル開発を始めても多くの人が失敗しています。もしくは、そのような不安から大規模開発に踏み切れない人の相談を多く聞いています。
現場のマネージャ、チームのリーダー、その中で働くメンバーたち…悩みは、それぞれです。

私たちには何が足りなかったのでしょうか。

大規模アジャイルのエッセンスを絞って、「これだけ」分かって欲しいことをお伝えします。

大規模アジャイル開発で気を付けること

「大規模アジャイル開発で、まず何から始めたらいい？」

そんな疑問を大規模アジャイルの開発手法であるSAFeとLeSSから良いポイントを抜き出し、考えるべき重要なポイントを紹介したいと思います。

お話しするのは、実際にSAFeと LeSSを学習したり、実際に体験して気が付いた事です。
単なる手法の比較ではなく、それぞれの良いポイントを挙げたいと思います。

二つの手法から分かる、大規模なアジャイル開発でおさえておくべき“大切にしている”ことを話します。

アジャイルコーチから見た大規模アジャイル

「大規模アジャイルって、実際どうよ？」

研修や本からは読み取れない大規模アジャイル開発手法に見えた「秘訣」があります。
例えば、大規模アジャイル手法には、1チームのScrumでも使える良い考え方やプラクティスが実際、あります。

普段のアジャイル開発に役立つ考え方やプラクティスを伝えます。

参考

SAFe 日本語サイト
http://jp4.scaledagileframework.com/

LeSS 日本語サイト
https://less.works/jp/

大規模アジャイル開発手法の全体像

■SAFe4.5（英語版のみ。日本語サイトは4.0）

■LeSS

というか、普通に複数Scrumチームになっただけで難易度hardですよね…？
チームがScaleするだけで難しくなる現実は何が問題なのでしょうか？

大規模なアジャイルの難しさ

「大規模アジャイルってどうやったらいいの？」

大規模≒Enterpriseという認識で大規模開発にアジャイル開発を始めても多くの人が失敗しています。もしくは、そのような不安から大規模開発に踏み切れない人の相談を多く聞いています。
現場のマネージャ、チームのリーダー、その中で働くメンバーたち…悩みは、それぞれです。

私たちには何が足りなかったのでしょうか。

大規模アジャイル開発で気を付けること

「大規模アジャイル開発で、まず何をしたらいい？」

そんな疑問を大規模アジャイルの開発手法であるSAFeとLeSSから良いポイントを抜き出し、考えるべき重要なポイントを紹介したいと思います。

お話しするのは、実際にSAFeと LeSSの研修を受けてみて気が付いた事です。

二つの手法が大規模なアジャイル開発で“大切にしている”ことを中心に、単なる手法の比較ではなく、それぞれの良いポイントを挙げたいと思います。

それは皆さんが「大規模なアジャイル開発」に関わる時、失敗しないように考えなければならないポイントに他ならないです！

大規模は難しいと敬遠されていた方や、これから挑戦しようとしているが不安を感じている方、実際に自己流で大規模開発しているが上手くいっていない方に参考になるはずです。

参考

SAFe 日本語サイト
http://jp4.scaledagileframework.com/

LeSS 日本語サイト
https://less.works/jp/

大規模アジャイル開発手法の全体像

■SAFe4.5（英語版のみ。日本語サイトは4.0）

■LeSS