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

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

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

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

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

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

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

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

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

以前は

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

でも待ってください！

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

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

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

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

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

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

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

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

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

私たちのプロダクト開発現場で「スクラム」という言葉を聞くようになってから約4年が経ちました。
はじめはスクラムに興味をもっていた少数の有志が推進者となり開発プロセスのカイゼンに取り組み始めました。

そんな我々は当時「1センチでもチームを良い方向に導きたい！」「価値を迅速に生み出せるようになりたい！」という熱い気持ちに突き動かされていました。
分からないなりに工夫を凝らしたり、すがるような想いでプラクティスを取り入れてみたりなど一所懸命に目の前の課題に向き合っていました。

そうして何かを実験したり実践してみると手応えを感じつつも、どこか思い描いていたような成果や結果が得られない感覚が拭えませんでした。
ときには何かを失ってしまうことさえあり、まさに三歩進んで二歩下がるような日々と言えます。

しかし、裏返すと着実に一歩ずつ進んできた4年間でもあり今だからこそ観測できる気づきが多くあります。
さにらそれらは当時の自分達がはじめに知ることができたならば…と思えることばかりでした。

• 真剣に取り組んでいたが今になって思い返すとおかしなこと
• 当時は分からなかったけど今になったら「こうしたらよかった」と思えること
• まさかこんな結果を生み出すとは思ってもいなかったこと

など、皆さまにとって他山の石となるような内容をお届けできればと思います。

デイリースクラムについて、”守破離”という観点から考察した結果を共有します。

• なぜあえてデイリースクラムなのか？
• 毎日行っているし、もう十分にやってきたよ？
• ”昨日/今日/問題”を話し、その場で解決しないなら別場にするんでしょ？
• 改善の余地って、あるのかしら？こんなものだろう？

私は、頻度の高いイベントこそ、楽しく・有意義であるべきだと考えています。楽しさやポジティブな気持ちは、創造性を向上させます。チームとして有意義な議論も同様です。それらが、生産性や効率を高め、企業や個人・プロダクトの優位性を高めていくと思うからです。

また、デイリースクラムおける重要なのは、”ストーリー”というキーワードであると考えています。そのキーワードは、”昨日/今日/問題”という構造を捉えるサポートとなり、一人ひとりの状況や想いを効率よく共有するツールになると考えています。これを’破”に位置付け、発表の中心としてご紹介します。

およそ中級（Intermediate）の方を対象としますが、初級者・上級者の方にも、それぞれ「はっ！」とする示唆が提供できる発表を目指します。少しでも多くのディベロッパーにとって、日々が幸福なものとなりますように。その一助になれましたら幸いです。

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

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

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

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

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

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

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

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

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

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

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

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

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

だがしかし。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

☆クラファンはじまりました☆

☆https://greenfunding.jp/thousandsofbooks/projects/6857☆

皆さんは、よく研修を受けられていますよね？

退屈な研修とそうじゃない研修の違いは何ですか？？

皆さんは、これまで学校に通っていた方がほとんどだと思います。

授業って面白かったですか？退屈でしたか？

退屈な授業とそうじゃない授業の違いは何ですか？？

このワークショップでは、これからクラウドファンディングで出版予定である、Training from the back of the Room!　のエッセンスを凝縮させて、参加者の皆様に「真の学びとは何か」「そのために講師・教師はどうあるべきか」を体験して頂きます。

実はこれ「教えない教え方」なんです。とっても興味が湧きますよね〜。もし興味が湧いた方は是非ご参加ください！

スクラムマスターの重要なスキルとして、『ティーチング』がありますよね。このティーチングを高めるためにも必要な考え方になります。

今回、Reginal Scrum Gathering Tokyoなので、「スクラム」を参加者の皆様で学びましょう！

スクラム初心者の方でも安心してご参加いただけます。スクラム熟達者の方も「教えない教え方」を学ぶことができます。

また、スクラムマスターの方に向けては、スクラムイベント・アクティビティでの応用の仕方も少し触れようと思います（ワークショップ後ご希望の方へ）。

もう『スクラムイベントが退屈だ』なんて言う人はいなくなりそうです！

このセッションは、プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。

POやプロダクトマネージャーと、開発の活動の違い

POやプロダクトマネージャーは常に忙しくしていて、様々な領域のことを考えたり、行動をします。経営者に説明しに行ったり、顧客と話をしたり、いろんなカンファレンスに登壇したりします。これによって、POやプロダクトマネージャーは、様々なことを短期間で経験し、プロダクト開発について急速にラーニングしていきます。

一方で、開発者は開発を中心にしていて、外の世界で何が起きているのか興味はあっても、POに比べたら限られたことしか経験できません。

プロダクトの成否は、社内で起きていることだけではなく、外側で起こっていることにも大きく左右されます。顧客は社外にいます。社内が混乱していてもプロダクトの成功はままなりませんが、社外でもうまく活動していかなければなりません。

社外の知識のギャップは開いていく

プロダクト開発が進むにつれて、社外の知識のギャップは大きく開いていくでしょう。とくにプロダクトのリリース後にはこの傾向は顕著になります。POはより一層、顧客と話す時間が増えたり、イベントで登壇したり、メディアに関わるようになります。社外に関心を向けて活動する時間が増えます。

もし、このままプロダクト開発の社内と社外の活動の差が広がると何が起きるでしょう。仕事は役割に応じて分担する分業が進むことになるでしょう。一緒に仕事をする機会は減っていきます。、その結果、「私考える人、あなた考える人」という状況が増えやすくなります。

チームとしての成長と、ビジネス収益の両立を目指していても、それぞれが自分の役割に集中するがゆえに、いつのまにか相手の事情も知らずに仕事を丸投げする関係になってしまうかもしれません。ビジネス側、開発側という言葉はその表れです。

いつ問題に気付くのか

では、いつこのことに気付くでしょう。プロダクトが市場に受け入れられ、上昇気流に乗っているうちは問題は起こらないため、この分業は短期的にはうまくいくように見えます。しかし、売上や利用者の拡大と共に、採用活動は進み、人は増えます。増えた人が即戦力として活躍できるように、仕事は整理され、分業は更に進みます。

POと話したことも無い人も増えていくことになります。個人名が出ることもなく､ビジネス側、開発側という言葉によって自分達を区別しはじめたら、高度な分業の構造が私たちを取り囲んでいることになります。

他社の参入や新たな技術といった、自社プロダクトに大きな変化が求められたとき、この高度な分業体制は足かせになる場合があります。たとえば、POと開発者がお互いの考えを理解するために、初期とのころとは比べものにならない時間がかかるようになります。誤解やすれ違いも頻繁に起こるようになります。問題がはっきりと分かるタイミングでは遅すぎるということです。

ソフトウェア開発は上達したが、プロダクト開発に失敗した

スクラムを続けるとソフトウェア開発がうまくなります。ところが、ソフトウェア開発はうまくなっているのに、顧客のアウトカムへの貢献が薄かったり、自社の収益への貢献が低いままのことはよくあります。たとえば、新機能開発を止めて現状維持にしたとしましょう。顧客のアウトカムに影響がないとしたら、ソフトウェア開発はうまくなっていても、スクラムはうまくいっていないのかもしれません。

このセッションでは、どのような変化が待ち受けていてもしなやかに対応できるように、プロダクトの価値作りをPO一人のスキルではなく、チームとして獲得していく方法を解説します。

■アジェンダ
POやプロダクトマネージャーどのように世界を見ているか
・時間をかけずにインプットを10倍にする方法
・消費者の世界と開発者の世界
・コンビニの商品をどのように見るか

プロダクトマネジメントの領域
・今あるプロダクトを顧客に買ってもらう商品開発
・顧客にアウトカムを提供できるだけの余力を持つ組織を作る組織開発
・既存のプロダクトでは実現できないアウトカムを新プロダクトを通して提供する製品開発

太い経験と細い経験という機会格差
・私考える人、あなた作業する人
・プロダクトマネジメントする人、される人
・説明責任という機会
・企業の3つの言語「経営の言語、マネージューの言語、現場の言語」
・時間の壁

プロダクトマネジメントを実現する組織開発
・年老いた組織と若い組織
・高信頼組織と、信頼不要組織
・開発するか、学ぶか

プロダクトマネジメントをチームで日常化する
・自分達のためのウィークリーラーニング
・学び始める習慣

いくつもの組織とともにジャーニーを続けています。そんな中で分かってきたことをまたお届けしたいと思います。

組織が直面する状況には「共通性」があります。
伝統的な大企業、あるいはベンチャー企業、地方の企業にしても、一様に乗り越えなければならない組織課題。
なぜ、組織はやがて「最適化」の呪いの中でどうにもならなくなってしまうのか？

今現在、組織に求められるのは、
・取り巻く環境や社会に価値を提案し続けるケイパビリティ（仮説検証型アジャイル開発）と、
・その活動を持続可能にする探索適応型の組織運営（組織アジャイル）
この両輪です。そして、こうした組織活動が噛み合うためには、組織の中心部に「芯」が不可欠です。

さあ、アジャイルによる私たちの旅はいよいよクライマックスを迎えそうです。
アジャイルによって、アジャイルになる。変革に挑む組織の最前線からお届けします。

※本セッションは株式会社レッドジャーニーによるスポンサーセッションです

スクラムで自己管理型の組織を目指したい、スクラムをやっていなかったとしても主体性を持って動けるチームを作りたいという話をよく聞きます。自分もそこを目指して活動しているのですが、そのような状態にしていくにはさまざまな困難にぶつかることがあると思います。

今回は自分が実際に体験したこと、その時の考えを対話という軸に沿ってお話しします。

運用業務とスクラムは組み合わせにくい、相性が悪いという話をよく耳にします。
しかし、プロダクト開発をするうえで運用業務は切り離せません。

このセッションでは、プロダクトを継続的にユーザーに届けるためには切っても切り離せない運用業務をスクラムでどう扱うとよいのか、ところどころで必要な判断をどう考えて行ったのか、わたしたちの試行錯誤にプロダクトオーナーの視点を交えて紹介します。

また、タイトル内にある問い「運用業務とスクラムは組み合わせにくいのか？」に対するわたしなりの回答である「そんなことはなく、うまく組み合わせることはできる」に至った理由についてもお話します。

ーーー
プロダクトにはライフサイクルがあります。これにはいくつかのフェーズがありますが、後半のフェーズになればなるほどいわゆる運用業務が増えていく事が多いです。

このセッション内では下記のような、システム運用・保守業務や業務運用をまとめて運用業務と呼びます。
身に覚えがある業務も多いのではないでしょうか。

• 定期的におこなう証明書更新
• 定期的におこなうソフトウェアのアップデート
• 需要に応じたキャパシティの拡張やライフサイクルへの対応
• 負荷が高くなるイベントへの事前準備と対策
• ユーザーからの問い合わせへの対応
• 突発的に発生する障害やインシデントへの対応とその対策

私は2年間、新旧2つのヤフーを支えるプラットフォームのプロダクトを担当しているチームのプロダクトオーナーをしています。
それぞれのプロダクトは2年間の中でプロダクトとしてのフェーズが変わり、その中でやりたいことや求められていることも変わっていきました。

• 新プロダクトは導入期〜成長期
  • まだ足りていない機能もあるのでもっと開発を進めたい
  • 多くのユーザーに使ってもらうため、機能要件の拡充を求められる
  • 成長期に入ると、これからユーザーが増えていくということで安定稼働も求められる
• 旧プロダクトは成熟期〜衰退期
  • 成熟期の間はまだより便利に使ってもらうための機能追加などを行いたい
  • ユーザーの課題を解決するために、プロダクトとして開発を行うことも求められる
  • プロダクトが衰退期に入っても、まだまだ利用者は多いため安定稼働を求められる
  • 同時に、衰退していくプロダクトにはコストを掛けたくないため、コスト削減も求められる
  • プロダクトの規模が大きく運用業務や障害も多いため、対策をしたい

新プロダクトでも約4割、旧プロダクトにおいては8割以上が運用業務。決して少なくない（むしろ多い）量の運用業務をおこないながら、それぞれのプロダクトで求められることにも応えていかなければなりません。

このような状況の中で、プロダクトが置かれている状況を見極め、開発チームと一緒に運用業務への取り組み方を検討したり、プロダクトオーナーとして判断をしたりを繰り返してきました。

プロダクトの状況ごとに、その運用業務とどう向き合ってきたのか。

• 運用業務をバックログ内でどのように扱っているのか
• プロダクトオーナーとして運用業務と開発業務のバックログの優先順をどのように決めているか
• スクラムチーム内の運用業務（運用フェーズのプロダクト）と開発業務（開発フェーズのプロダクト）の割合をどのように決めているのか

などの試行錯誤の一部と今後やっていきたいことについて、うまくいったこととそうでないことの両面からお話しようと思います。

また、タイトル内の問いへの私なりの回答についてもお話します。

運用業務とスクラムは組み合わせにくいのか。

試行錯誤を経た私なりの回答は、「そんなことはない。運用業務とスクラムはうまく組み合わせることができるのではないか、むしろその方がメリットがあるのではないか」です。

試行錯誤のなかでは下記のような気づきを得ました。

• ただの運用業務に見えるものも、視点を変えればインクリメントのある開発業務にできる場合がある
• スケジュールありきの運用業務は、無理にバックログで扱わないでスプリントを固定するとうまくいきそう
• 運用業務と開発業務の優先順を判断するためには、単純なインクリメント以外の軸をつくるのがよさそう
• ステークホルダーからのプロダクトに対する期待に応えるためには、運用業務と開発業務の量をある程度コントロールする必要がある

そして同時に、これらは運用業務とスクラムは組み合わせにくい、相性が悪いと言われる要因（課題）を取り除くヒントにもなっているのではないかということに気がつきました。課題を解決できるならうまく組み合わせられるだろうし、スクラムのメリットもより活かすことができそう、と思い回答に至りました。

そんなに単純ではないかもしれないですし、課題がすべて解決したわけでもないですが、運用業務とはまだまだこれからも長く付き合っていかないといけないので、よりよくしていくための挑戦はこれからも続きます。

同じ課題を持った人にとって、なにかの参考になったり、自分たちもチャレンジしてみようと思ってもらえたら嬉しいです。

私は株式会社アカツキゲームスにおいてモバイルゲーム開発の事業に所属しており、組織の課題解決をミッションとして働いています。

ひとことに組織課題の解決と言っても、取り組むことは多岐にわたっています。

• 開発組織内で大規模スクラムを導入する
• 開発組織外でアジャイルの思想を取り入れた業務改善を実施する
• ひとつのゲームを関係会社の垣根を超えて良い感じに開発・運用できるよう、各会社のミッションやメンバーの Will も鑑みつつ、色々やる

スクラムガイドには "スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。" とあります。

スクラムマスターを担当されている方や、私のように組織の課題解決をミッションとして仕事をされている方は、組織と向き合うことを難しいと感じる人も多いのではないでしょうか。

• 自分だけ、あるいは少人数のメンバーしか課題と思っていないけど、変化を起こしたいがある
• 影響範囲が大きく、職種の異なる人・同じ方向を向けていない人たちと一緒に、前に進まなければいけないことがある
• 自分は良い取り組みだと思っているけど、ネガティブな反応の人がいる
• 上司や同僚と議論が永遠に噛み合わない

以前はうまく立ち回れず、厳しいご意見をもらうことも多かったのですが、最近は関係会社も巻き込むような立ち回りができるようになりました。

本セッションでは、スクラムチームと、より⼤きな組織に奉仕をしたい方に向け、いろんな考えの人たちを巻き込んで前に進めるための、私なりの考え方や方法をお話します。

皆さんは、良く言えば「安定」、悪く言うと「成長が鈍化」したチームに所属したり、見かけたりしたことはないでしょうか？
長くチームが続き、コアメンバーが変わらない場合にそういった状態になりがちです。
皆さんはそういった状態を見かけたときにどういった働きかけをチームにしているでしょうか？

私のチームが1年以上経過したころから、私はチームの成長が鈍化しているように感じました。
私は次のような問題が起きていると感じていました。

• 障害があっても、すぐに発見してチームで対応できてしまっているなー。ふりかえりでもTryは出るが、簡単に対応できるレベルのもので、自分たちのやり方を見直すほどのものではないなー
  • 問題が起きない問題
• 何か新しいことを取り組もうとする雰囲気はチーム内にあるが、具体的な一歩が踏み出せていない
  • 何を目指せばいいのかわからない問題
  • コンフォートゾーンの居心地がいい問題
• 私が開発者も兼務していることによる、開発スピードを緩めたくない気持ち
  • ベロシティ下げたくない問題

チームの成長が鈍化しているとき、チームメンバーは「問題が起きていない」「居心地が良い」という点からこの問題に気づかなかったり、言及できないことがあります。
また、こういう場面でスクラムマスターが「コンフォートゾーンにいすぎじゃないか？」「最近実験している？」といった問いかけをしながらチームが新しい方法を模索するように働きかけられると良いのですが、スクラムマスターが複数チームに所属していたり、兼任していたりすると、他業務に目が奪われて、この問題に取り組めないことがあります。（私は開発者との兼任で取り組めていませんでした。。）
また、マネージャーから見ても問題なくプロダクト開発ができているチームと認識されてしまって、チーム外からの指摘が入らなかったりもします。

この状況に対し、私たちのチームは次のようなことを行いました。

• 月間のテーマを決めて課題が生まれるようにした
• 新メンバーを入れて、課題が生まれるようにした

本セッションではこの取組事例と起った効果を紹介し、タックマンモデルと関連付けて考察したいと思います。

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

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

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

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

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

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