あなたのアジャイルテスティングに血は通っていますか? ~“納得感の共感”による組織バグの撲滅~

現代のソフトウェア開発は、ソフトウェアやサービスが密接に一体化してプロダクトを構成しています。

質の高いプロダクトを生み出し続ける一つの方法は、プロダクトと開発チームの間や開発チーム内部、複数の開発チームの間、ユーザと開発チームの間にある組織結合度について、実質的な密結合と疎結合のバランスを上手にデザインしカイゼンすることだと私たちは考えています。

プロダクトバグの原因になる組織バグは、
工数が足りないから密結合になるべき組織結合度を疎結合にしようとして必要なコミュニケーションを無理に減らしたり、
やらされ感やこなし感にコミュニケーションがまみれ実質的に疎結合化してしまっていたり、
不必要な自称ステークホルダーを排除できず疎結合化できなかったためにノイズが増えて優先度などの意志決定がブレるなど、
密結合と疎結合のバランスの崩れの現象が起きていると捉えられるからです。

我々SEA-SIGSQAでは、疎結合と密結合を上手にバランスさせるための大事なマインドセットの一つとして「納得感の共感」を挙げています。

 

本講演では、ユーザ・プロダクト・開発に関わる組織において網の目のように“納得感の共感のチェーン”をたくさん構築するというアイデアをお話ししたいと思います。

伝統的なテストや品質保証では、カバレッジ達成やプロセス準拠といった品質基準が一人歩きしてしまい、プロダクトや組織の質の低下につながった現場もありました。

一方アジャイル開発では、アジャイルテスティングやHolistic testing、Whole-team approachという技術やアプローチが提示されていますが、まだそれらは局所的だったり部分的なプラクティスとしてしか理解されていないような気がしています。

 

私たちは、網の目のように張り巡らされた“納得感の共感のチェーン”がアジャイルテスティングやHolistic testing、Whole-team approachを動かす組織の大動脈や静脈、毛細血管から構成される血管網になり、優れた品質文化を醸成していくと考えています。

すなわち、プロダクトに対する開発チームの納得感の共感が品質保証の基礎となり、開発チームの内部(現場)での納得感の共感がよいチームとなり、
複数の開発チームの間での納得感の共感が上手な大規模化を導き、経営層と開発チームの間での納得感の共感が持続的な進化につながっていくわけです。

この講演によって理解が進み、納得感の共感によって組織バグを低減させることで、アジャイル開発における品質保証を上手に進めていただければと願っています。

 
 

Outline/Structure of the Panel

- アジャイルテスティングやHolistic testing、Whole-team approachに対する盲信や誤解

- 品質保証で最も基本となる「納得感の共感」(チーム全員が納得感を持てる仕事をして、それを全員が共感できる開発というマインドセット)

- 開発に関わる組織・プロダクト・ユーザにおいて網の目のように張り巡らされる“納得感の共感のチェーン”の重要性

- “納得感の共感のチェーン”が切れることによる疎結合・密結合のバランスの崩れと組織バグ・プロダクトバグ

- “納得感の共感のチェーン”の構築による血の通った品質保証の実現

Learning Outcome

  • “納得感の共感”によって組織バグを減らしていくという考え方
  • Whole-team approachをきちんと機能させるための考え方
  • アジャイルテスティングやHolistic testingなど、アジャイル開発における品質保証を上手に進めるための考え方

Target Audience

アジャイル開発における品質保証に悩んでいる方々アジャイルテスティングやHolistic testingに興味のある方々

Prerequisites for Attendees

アジャイルテスティングやHolistic testing、Whole-team approachの理解を少々。

schedule Submitted 3 months ago

  • Zuzi Sochova
    Zuzi Sochova
    Agile Coach and Trainer
    sochova.cz
    schedule 3 months ago
    Sold Out!
    90 Mins
    Keynote
    Intermediate

    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.

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - スプリントレビュー Deep Dive

    45 Mins
    Talk
    Beginner

    ★★★Deep Diveシリーズ第3弾!!★★★

    Deep Diveシリーズでは、主にスクラムを始めたばかりの人、実践しているもののこれでいいのか?と不安を持っている人に向けに、スクラムの要素を詳細に解説しています。

    これまで以下の2つをお届けしてきました。

    シリーズ3作目となる今回は、「スプリントレビュー」についてです。

    スクラムの3本柱である透明性、検査、適応は、スクラムのあらゆる役割やイベント、作成物に関係します。
    作成物の1つであるインクリメントも当然対象となります。そして、インクリメントの検査と適応の場が、スプリントレビューです。
    不確実性の高い問題の解決に取り組んでいる私たちは、スプリントレビューを通じて、自分たちが作っているものが正しい方向に向かっているのかを短い間隔で検査し、学習した内容や環境の変化を踏まえて、適応していかなければいけません。

    アジャイルマニフェストには「包括的なドキュメントよりも動作するソフトウェアを」という項目があります。
    これが意味するところは、現物の重要性です。私たちはビジネス上の目標を達成するためにプロダクトを作っています。充実したドキュメントがたくさんあっても、プロダクトをユーザーに渡せなければ無意味です。プロダクトを使うユーザーがいなくても無意味です。プロダクトを使ったユーザーが、自分たちの課題を解決できなくても無意味です。
    つまり、プロダクト(動作するソフトウェア)は核となるものであり、定期的にプロダクトそのものや、プロダクトに加わった変化(インクリメント)を実際に検査し、適応し続けなければいけません。

    一方で、スプリントレビューが単なる進捗報告の場であったり、意味のある検査ができないようなものを披露していたりするような現場をたくさん見てきました。
    これではスプリントレビューの意味がありません。
    スプリントレビューはスクラムのイベントのなかで、いちばん重要なイベントです。このイベントをうまく運用できるかどうかで成果は大きく変わってきます。

    以下に挙げるようなスプリントレビューの鉄則をはじめとして、スプリントレビューを圧倒的に効果的に活用するための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

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

     

  • Tsuyoshi Ushio
    keyboard_arrow_down

    Tsuyoshi Ushio - ログの書き方がチームの生産性を爆上げする話

    45 Mins
    Talk
    Intermediate

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

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - Effective Retrospective++~楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ~

    45 Mins
    Talk
    Beginner

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

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

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

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

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

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

    以前は

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Yamato Naka
    keyboard_arrow_down

    Yamato Naka / Kaori Tokiwa / Manabu Shibahashi - 体感しよう、狼狽と不安と希望と安堵に満ちた共感を 〜仲間の内面から自分と対話〜

    100 Mins
    Workshop
    Intermediate

    私が経験した中でもっともハードな「人の気持ちになるワーク」をRSGTの参加者の皆さんだからこそ届けたい。
    説明や本だけでは得られない実感を味わい、見えていたのに見ていなかった視界を手に入れて下さい。

    スクラムやアジャイルに限らずさまざまな場面で「共感する」「相手の気持ちになる」「相手の立場になる」という言葉を聞きます。いったいどうなれば「共感する」「相手の気持ちになれた」「相手の立場になれた」と言えるのでしょうか?この問いに対して、私が持つ一つの答えであるワークショップを行います。

    RSGTを終えたあと
    1on1や家族との対話で今まで以上に相手の考えが理解できるようになったら嬉しくありませんか?
    同僚の内面から自分を見て、同僚に伝わる言葉を使えたら嬉しくありませんか?
    「お前は人の気持ちがわからない」と言われていたのに、人の気持ちがわからないのは「お前は人の気持ちがわからない」と言っている人だったと気づけたら、対策が取れるようになりませんか?

    このワークショップでは実際に相手の立場と自分の立場のそれぞれに自分で立って対話をしてもらいます。有意識下では「気づいていなかった」「気づきたくなかった」相手や自分の考えや主張が見えてきます。あくまで貴方が持っている相手の情報から相手を推測するに過ぎません。しかし、無意識ではわかっていた、気づいていなかったことはたくさんあります。今、時点でわかり得る情報を元に全力で「相手の気持ち」を考えてみましょう。

    • ある人は上司と向かい合い、上司が常々言っている良い評価を受け止められるようになった。
    • ある人は配偶者と向かい合い、目を瞑って避けていた配偶者の思いを少しずつ受け止められるようになった。
    • ある人は義母と向かい合い、夫婦と義母の軋轢を解消する糸口を見つけ出した。

    このワークショップでは、参加者ペアで行い、参加者にとって実在する相手を題材に行います。大っぴらに言いづらい事を言わざるを得ない場合があるのでご注意下さい。お互いの加えて守秘義務を守ってご参加下さい。

    体感してもらう場であり、やり方を教授する場ではありません。やり方を身につけたい方は専門家の支援を受けてください。

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - The Stable Team - 機能する安定したチームをつくる -

    45 Mins
    Talk
    Advanced

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

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

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

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

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

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

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

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

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


    でも待ってください!

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

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

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

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


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

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

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

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

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - チームのパフォーマンスを引き出す、ワクワクするプロダクトゴール/OKR

    45 Mins
    Talk
    Intermediate

    プロダクトゴールについては、昨年のRSGTで長沢さんが素晴らしいセッションを提供してくださいました。では、私が語り得ることは何か?

    自分の経験に基づいた話。
    ゴールを設定する手前の、そこにいる人がワクワクしていくためのプロセス。
    そんな話をしたいと思っています。

    目標管理手法のひとつOKR。Scrum Fest Mikawa 2022において「OKRはツリーではない」という発表を行いました。

    その発表の中では、OKRにおいて何よりも重要なのは「目指さずにはいられないワクワクする目標を作ること」だと説明しています。

    これはスクラムのプロダクトゴールに対しても同じことが言えると、私は考えています。ワクワクする、そのゴールを達成せずにはおられないからこそ、私たちは自分たちの状況を公開し、失敗する勇気をもち、互いに尊敬しあいながらゴールに集中し達成を確約するのです。
    私が関わってきた組織、チームでもワクワクするOKRを設定できているかどうかがプロダクトゴールの実現度合いと密接に関わっていることを観測してきました。ワクワクOKRを持ったチームは「ありたい姿」と「プロダクトゴール」の一致度が高くなり、主体的にプロダクトゴールに向かうため達成度が高くなりました。それに対しシナシナOKRが手元にあったチームは「こんな目標、達成できると思ってません」とゴールへ向かうモチベーションさえ湧かず、したがって達成度は低い状態でした。
    であれば、ワクワクしたOKRを設定しない手はないですよね。

     

    言うは易し。

     

    「『ワクワクする目標を作る』?それができねぇから七転八倒してるんだろうがッ!!」そんな声がきこえてくるようです。少なくとも私の胸の奥からはそのような叫びが聞こえてきました。名著「Measure What Matters」でいうところの「組織全体に目的意識と連帯感をもたらし、多様な活動を結びつける」ような目標は、ゴールはどうやって作ればいいのでしょうか。

    OKRオタクを自認する小田中がこれまでに経験したうまくいった(ワクワクした)目標設定、うまくいかなかった(シナシナした)目標設定についてふりかえります。
    どうやったらワクワクさせられるのか、シナシナを避けられるのかについても触れていきます。そして、目指さずにはいられないOKR、ワクワクいきいきする目標を作り上げるための再現性のあるプロセスについて解説します。ワクワクの源は千差万別、だからこそ再現させるのは難しい。けれども内発的動機を駆り立て、互いのビジョンを共有しながら深く対話することで、壁に張り出したくなるようなOKRはできるんです。おっと、ここから先は本編で。

  • Kazuhide Inano
    keyboard_arrow_down

    Kazuhide Inano - アジャイルコーチング × システムコーチング 〜Agile & ORSC are eating the world〜

    Kazuhide Inano
    Kazuhide Inano
    Agile Coach
    JEI LLC
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

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

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - ソフトウェア開発関係ない人向けに作ってみた、アジャイルにものを作るってどういうことか?

    45 Mins
    Talk
    Beginner

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

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

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

     

  • HIROYUKI HANAI
    keyboard_arrow_down

    HIROYUKI HANAI / Etsuo Yamada / Makoto Takaesu / Ryo Tanaka / Saito Norihiko / Satoka Chibana - 魔法使いLyssa Adkinsの『Coaching Agile Teams』をひも解く

    45 Mins
    Panel
    Intermediate

    2日目のKeynoteスピーカーであり、世界的なアジャイルコーチでもあるLyssaの書籍『Coaching Agile Teams』は素晴らしい知恵の宝庫であるものの、その量と深さに圧倒されてしまいます。

    カルチャー,マインドセットの変革 、組織構造の改革、マネジメント,リーダーシップ層の抵抗など(The State of Agile Coaching Report 2022より)とあるように、世の中のアジャイルコーチは日夜、様々な困難の中に立ち続けています。

    同書にはこうした困難を克服するためのヒントがたくさん紹介されおり、その証拠に、2010年5月の刊行以来、10年以上経った今でも版元上位50位以内の売上を誇っています。

    本セッションでは、同書の翻訳に携わるメンバーが書籍の中からアジャイルコーチになる、あるいはスキルを磨くのに使える、お気に入りのワークショップ、スキル等を実際の活用事例を踏まえて紹介します。

    一例として、11章「アジャイルコーチの失敗、回復、成功モード」。

    「アジャイルコーチも当然ながら失敗します。私がミスをしたのはチームの決断がシステム障害を起こす可能性があったときに、コーチとしてではなく、シニアメンバーとして全部を取り仕切って解決してしまいまったことです。この振る舞いは事態を解決したが、やり方としてアジャイルコーチといっていいのか疑問をかかえて過ごすことになりました。Lyssaが紹介していた失敗モードの"エキスパート"を参照した時、すっと憑物が落ちたようにアレは失敗だったんだと整理とふりかえりができ、次に進むことができました」 といった形で、それぞれの体験と本書から学べる気づきなどを紹介するセッションになります。

  • Hiroyuki TAKAHASHI
    keyboard_arrow_down

    Hiroyuki TAKAHASHI / Yasuko NAITO - 「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論-

    45 Mins
    Talk
    Executive

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

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

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

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

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

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

    だがしかし。

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

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

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

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

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

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

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

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

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

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - だったら WF でやればいいぢゃない! 〜 ところでホントに WF をご存知ですか? 〜

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

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

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

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

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

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

  • Tomoharu Nagasawa
    keyboard_arrow_down

    Tomoharu Nagasawa - スクラムチームが自信をもってアウトカムとスプリント活動に集中するためのコツ

    20 Mins
    Talk
    Intermediate

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

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

    例えば、

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

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

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

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

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

    • PBIの経過期間(年齢)
    • サイクルタイム

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

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

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

     

    More Effective Scrum シリーズ(?)

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

    FmEcf-JaUAIszbN?format=jpg&name=large

  • Hayato Yamamoto
    keyboard_arrow_down

    Hayato Yamamoto / HIROSE SHIYU / Koki Saito / Naoya Hitaka / Shota Fujie - 聴覚障害のある大学生チームによる臆さない発言環境の形成

    45 Mins
    Talk
    Beginner

    私たちは筑波技術大学のチーム、「うきうきなっとう」です。

    9月末に琉球大AgileTeamCampに参加し、初めてAgile開発を経験しました。4日間という短い期間でした。実際にプロダクトの開発を行ったのは2日間です。非常に短い期間の中でたくさんの発見がありました。

    うきうきなっとうは聴覚障害のある大学生だけで構成されたチームです。メンバーの紹介をします。

    • Hayato Yamamoto : 3年生
      • PO 兼 開発者
    • Shota Fujie : 3年生
      • 2日目SM 兼 開発者
    • Koki Saito : 2年生
      • 3日目SM 兼 開発者
    • Naoya Hitaka : 3年生
      • 4日目SM 兼 開発者
    • Shiyu Hirose : 4年生
      • 開発者
    • RSGT不参加メンバー : 3年生
      • 開発者

    一概に聴覚障害と言っても個人差があります。

    聴力の重い軽いはもちろんのこと、音を言葉として捉えることができるかどうかも異なります。物心ついた時から手話を使っているメンバーや高校/大学に入ってから手話を学び始めたメンバーもいます。

    全員が同じ情報を受け取れるようにさまざまな手段でアイデアや意見の可視化・言語化を工夫していった結果、チームの知見がどんどん表に出て共通認識を作ることができるようになりました。

    本セッションでは、臆さない発言環境の形成にあたって、わたしたちが実際に行った工夫とその結果、そして聴覚障害という特性を絡めてお話しします。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法

    45 Mins
    Talk
    Advanced

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

     

     

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

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

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

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

     

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

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

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

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

     

    いつ問題に気付くのか

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

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

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

     

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

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

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

     

     

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

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

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

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

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

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - [Day0] (online-only) 知り合いを増やしてRSGTへのドキドキをワクワクにする会

    100 Mins
    Workshop
    Beginner

    (実行委員会より: 本セッションはオンラインのみで行います。ぜひ事前にDiscordでの受付を済ませていただき、Discordに記載のZoom URLからご参加ください) 

    • RSGTには初めて参加するので、どんな感じなのか分からず、本当に自分が参加して良いのか不安だな
    • オンライン参加で、Discordを使うみたいだけど、どう使えば良いのか分からないし、大丈夫かな
    • 現地に行っても他に知り合いはいないので、ぼっちになってしまうのではないかな
    • 何度か参加しているけど、久しぶりだから誰か自分のことを覚えてくれているかな

    このように、初めてRSGTに参加される方や、久しぶりのRSGTだという方など、RSGT参加が近づくに連れて何となく不安でちょっとドキドキしてくる方は多いのではないでしょうか。

     

    私は、RSGT2021とRSGT2022で知り合いを増やすためのワークショップを行いました。参加頂いた方には大変好評で、知り合いが増えることでRSGTをより楽しむことが出来たという感想をたくさん頂くことができました。

    一方で、開催後に「Day 0にこの会をやって欲しかった」というフィードバックを多く頂きました。(これまではDay 1の最後にネットワーキングの一部として開催していました)

    たしかに、Day 1が始まった時点で知り合いがいる状態になっている方がより望ましいですし、ネットワーキングパーティではその繋がりから、さらに知り合いが増えるかもしれません。何より、知り合いがいる安心感が、Day 1への参加を楽しみでワクワクするものにしてくれます。

     

    そこでDay 0でRSGT2021とRSGT2022で開催したものと同様な「知り合いを増やす会」を実施することを提案します。

    主なターゲットは初参加や久しぶりに参加する方ですが、よく来ている人にも参加して頂いて、これまでの楽しみ方を話してもらうのも良いなと思います。

    参加に向けての不安点を解消したり、注目しているセッションについて共有したりするのも楽しそうです。

    そしてこれがDay 1以降の深い議論や学びに繋がっていくことを期待しています。

  • Saiko Nakai
    keyboard_arrow_down

    Saiko Nakai - 運用業務とスクラムは本当に組み合わせにくいのか?プロダクトオーナーから見た2つのプロダクトを担当するチームでの試行錯誤の軌跡とこれから / Is there chemistry between Operation work and Scrum? - Path of trial and error in our team -

    Saiko Nakai
    Saiko Nakai
    Product Owner
    Yahoo Japan Corporation
    schedule 4 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

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

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

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

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

     

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

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

     

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

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

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

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

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

     

     

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

     

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

     

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

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

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

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

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

     

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

  • Kotoe Ishige
    keyboard_arrow_down

    Kotoe Ishige - アジャイルな組織改善 〜手法とマインドセット〜

    45 Mins
    Talk
    Intermediate

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

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

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

     

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

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

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

     

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

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

  • FUMIKO NAOTSUKA
    keyboard_arrow_down

    FUMIKO NAOTSUKA / Yuhei Koito - ラグビー元日本代表がスクラムやってみた

    20 Mins
    Talk
    Beginner

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

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

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

  • Shuichi Matsubara
    keyboard_arrow_down

    Shuichi Matsubara - OSTを120%楽しもう‼︎ 誰でも簡単に実践できるtips教えます。

    Shuichi Matsubara
    Shuichi Matsubara
    Scrum Master
    あらうんど83
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    このセッションは、RSGT最終日に行われるOpen Space Technologyを120%楽しんで帰ってもらうために、OST初めての方から経験者の方まで、そしてオフライン参加でもオンライン参加でも簡単に実践できるちょっとしたコツやテクニック、マインドを持ち帰ることができるセッションです。
    紹介するtipsはRSGT最終日のOSTで早速実践できるだけでなく、別の場所や皆さんの職場でOSTを立ち上げてみる、もしくは参加してみる場面でも役に立つでしょう。

    ------------------------------------------

    RSGTが大事にしているのは"gathering"ですよね。
    会場、ホワイエ、廊下、下の中華、Discord…いたる所で自然発生するギャザリング。
    もちろんセッションも魅力的ですが、参加者同士でワイワイ交流する文化がすごく素敵で私は大好きです。
    ですが、私が初めて参加したアジャイル系カンファレンスでは、知らない人たちと自分から会話するなんて怖くて特に交流できないまま帰宅したのを今でも覚えています。

    私はRSGTのギャザリングのメインステージはOSTだと思っています。
    参加者のみなさん一人ひとりが尊重される場です。そして、お互いのパッションがぶつかり合う場です。
    この場をただの傍観者として参加するのではなく、最高の価値体験の場として欲しいです。
    しかし、そんな素敵なOSTの楽しみ方を伝えるセッションが無いことに気付いてしまいました。

    RSGT2020のOSTをきっかけに人生が変わった私が、あの時行動したことや体験したこと、あれから約3年間で数多く参加してきたオンライン/オフラインOSTの経験をふりかえり、誰でも簡単に実践できるtipsをお伝えします。
    皆さんにはこれらを知ることで、RSGTの3日目に控えるOSTを120%楽しみ、人生を変える体験をしてもらいたいと思います。

    特に、初めてRSGTに参加する人や、OSTを経験したことがない人、テーマが思い浮かばない人に聞いてもらいたいセッションです。

    もし、RSGTのOSTに参加できなくても大丈夫!このセッション動画を見ていただき、スライドを利用してもらって、皆さんの職場でOSTを立ち上げてみたり、別の場所でOSTに参加する機会がありましたら実践してもらえたら嬉しいです。

    ------------------------------------------

    ■セッション内容

    ・なぜ、このセッションを提案したのか
     ・人生初のOSTでの経験と後悔
     ・OST初参加にはハードルが高い
     ・OST参加への心の準備を高める

    ・Open Space Technologyとは
     ・OSTの起源
     ・1つの法則と4つの原則

    ・こんな時、どうしたらいい??OSTで実践して欲しいtips4選
     ・どんなテーマを出していいか分からない!
     ・何から話せばいいかか分からない!
     ・何を話したらいいか分からない!
     ・OSTでは盛り上がったけどそこから先に進まない!

    ・一緒にテーマを考えよう
     ・「実は」トーーク!

help