location_city Tokyo schedule Jan 12th 02:00 - 02:20 PM JST place [Sponsor sessions] 2F Terrace Room (48) people 11 Interested

Although almost all the Scrum Masters in general would have world class certifications, many of the Scrum Masters play non-significant or non-impactful role!

These people know the framework well, but still won't command respect for their role from teams or the management. The important aspect many people tend to ignore is, being a Scrum Master is to be a leader of the team. A leader who doesn't have a given/traditional authority, but when rightly understood & done can change the team as well as the whole organization.

This presentation would go through the topics about what to avoid and what to focus to become a Real Scrum Master.

 
 

Outline/Structure of the Talk

  • A quick introduction to Scrum Master role expectation that is generally known to all.
  • Sharing multiple unhelpful methods/practices that is based on self experience as well as others.
  • Sharing multiple helpful methods/practices again, that is based on my own experience and of others.
  • Summarizing with purpose of the role & provide a guidance about skills/practices that will make an impactful Scrum Master.

Learning Outcome

  • Skills & practices that will help build one an impactful Scrum Master.
  • Methods to identify the skills & practices.

Target Audience

Scrum Masters, Management Members

Prerequisites for Attendees

Good knowledge & working knowledge of Scrum would help a lot.

Slides


Video


schedule Submitted 1 month ago

  • 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)をあなたに提供します。
    ふりかえりを始めたばかりの人でも、新しい知見を得たい人にも。あなたのふりかえりを変えるきっかけが、ここにあります。

  • Hiroyuki Ito
    keyboard_arrow_down

    Hiroyuki Ito / Shigetaka Kumagai - 「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -

    45 Mins
    Talk
    Intermediate

    お互いの論点がずれていて、会話が一向に噛み合わず、時間ばかりが過ぎていく。あるいは、「あの人の言っていることはいつも訳が分からない」「あの人とは相容れない」と憤った経験は、多かれ少なかれ皆さんも経験されたことがあるのではないでしょうか。また、このような会話や対立を「空中戦」と表現するのを見聞きしたことあるのではないでしょうか。

    ※以下、「噛み合わない会話と対立」の意味で「空中戦」と表記します。

     

    こうした「空中戦」は、output/outcomeを出せずチームや個人のパフォーマンスを低下させるだけではなく、チームや個人のストレスを高め、チームの分解や離職のリスクにもつながり得ます。

    一方で「空中戦」には、ある一定のメカニズムがあります。これを理解することで、解決を図ることは十分可能です。加えてそれらの方法は、後天的に習得できる、再現性のあるスキル・技術です。

    このセッションでは、「空中戦」を終わらせ、相互理解や合意に辿り着けるようにするためのスキルおよび技術を、アンガーマネジメントNVC(Nonviolent Communication)マインドフルネスの3つの観点から、講演者自身の実践事例を含めて、「エモさ」を抜きに整理しお伝えします。

    このセッションの内容を通じて、一人でも多くの方が「空中戦」を克服し、自信を持って行動しoutput/outcomeを出し続けられるようになり、結果多くの人の笑顔を花咲かせられるようになれば幸いです。

  • 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

  • 45 Mins
    Talk
    Beginner

    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.

    WO8kxKI.png

    Japanese interpretation provided.

  • Takahiro Hiasa
    keyboard_arrow_down

    Takahiro Hiasa - 1つのアプリを開発する複数の職能横断チームの運用と今後 - タクシーアプリ「GO」の現状と未来

    20 Mins
    Talk
    Beginner

    皆さんは、リソース効率を重視するあまり、プロダクトの急拡大に組織が追いついておらず、フロー効率をないがしろにしたまま、プロダクト開発を続けてしまって、大変だった経験はございますか?

    少人数だったときは、それでも問題なかったでしょう。しかしながら、プロダクトの規模拡大に伴い、人もどんどん増えて行き、徐々にリリースのリードタイムが遅くなってしまいます。

    株式会社Mobility Technologies (以下、MoT)は、JapanTaxi株式会社とDeNAのオートモーティブ事業の一部が統合して2020年4月に誕生しました。
    統合前は競合であった『JapanTaxi』『MOV』両アプリのそれぞれの強みを活かす形で、MoTとして最初の顔となるタクシーアプリ『GO』を統合からわずか5ヶ月でローンチしました。

    タクシーアプリ『GO』は、2021年9月に500万ダウンロードを、2022年9月に1000万ダウンロードを達成し、約1年でダウンロード数が500万も増加し、そのユーザー基盤を急激に大きくしていっています。

    この1年半、複数の職能横断チームでタクシーアプリ『GO』のユーザー向けアプリを開発してきました。

    本セッションでは、職能別組織と職能横断チームでそれぞれプロダクト開発を行った話と、複数職能横断チームの運用について話します。

  • 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年生
      • 開発者

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

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

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

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

  • Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu - 「教えない教え方」を活用してスクラムを理解して実践するワークショップ 〜Training from the back of the Room!〜

    Koki Shimizu
    Koki Shimizu
    Agile Coach
    Red Hat
    schedule 4 months ago
    Sold Out!
    100 Mins
    Workshop
    Beginner

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

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


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

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

     

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

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

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

     

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

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

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

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

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

     

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

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

  • Mori Yuya
    keyboard_arrow_down

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

    45 Mins
    Talk
    Advanced

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

     

     

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

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

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

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

     

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

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

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

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

     

    いつ問題に気付くのか

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

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

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

     

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

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

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

     

     

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

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

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

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

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

  • 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割以上が運用業務。決して少なくない(むしろ多い)量の運用業務をおこないながら、それぞれのプロダクトで求められることにも応えていかなければなりません。

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

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

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

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

     

     

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

     

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

     

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

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

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

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

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

     

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

  • FUMIKO NAOTSUKA
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

  • kyon _mm
    keyboard_arrow_down

    kyon _mm / Daisuke Kasuya / Gota Miyazaki - Living Management -Good bye Scrum,  Hello Semilattice-

    45 Mins
    Talk
    Executive

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

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

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

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

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

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

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase - 超ハッピー スーパーハッピー のりのりマサノリ〜!! とにかく明るいセッション ✌️(^o^)

    Miho Nagase
    Miho Nagase
    Agile Coach
    Attractor Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Workshop
    Beginner

    こーんにーちはー!!!!!!!!

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

    このセッション、明るくなーい!???

  • Satoshi Harada
    keyboard_arrow_down

    Satoshi Harada - 見積りの不確実性と向き合う - 不確実性コーンをスクラムという入れ物に入れてみた話

    45 Mins
    Talk
    Beginner

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

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

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

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

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

     

     

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

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

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

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

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

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

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

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

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

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

     

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

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

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

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

     

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

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

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

     

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

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

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

     

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

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

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

  • Ryota Arakawa
    keyboard_arrow_down

    Ryota Arakawa - クロスファンクショナル(機能横断型)がもたらすメリットとその推進方法

    45 Mins
    Talk
    Intermediate

    クロスファンクショナルという言葉をご存知でしょうか?

    クロスファンクショナルは日本語版のスクラムガイドで「機能横断型」と翻訳されています。
    「スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。」

    これは非常に大事なことで、チーム内で完結しないことがあると、社内外注状態になっていきます。
    そして長い待ち時間、各部門での部分最適が進むといった様々な問題を引き起こします。
    チームがクロスファンクショナルであることは非常に重要です。

    では1つのチームに全ての職種を集めておけばスキル(職能)の問題は解決するのでしょうか?
    実際には複数の問題が残ります。
    SmartHRではプロダクトエンジニア、デザイナー、プロダクトマネージャー、QA、UXライターなどプロダクトサイドの全ての職種を集めたチームを作りました。
    しかし人数が増えたことによるコミュニケーションコストの増大、チーム内のボトルネックなど様々な問題が残りました。

    それらの問題を解決していく方法に、メンバー個人がクロスファンクショナルになるという考え方があります。
    つまりデザインやQAといった複数のスキルを学んだメンバーを増やしていくということです。

    このセッションでは個人がクロスファンクショナルになっていくことのメリット、そしてその推進方法についてSmartHRでの事例をもとに話していきたいと思います。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - 「プロダクト開発ってまるでクソゲー!」問題を解きほぐし、信頼で結ばれた組織を実現し、顧客のアウトカムにいかに貢献するかを思い切り楽しむプロダクトマネジメントゲーム

    45 Mins
    Talk
    Beginner

    このセッションは、混乱と理不尽にまみれたクソゲーになりがちなプロダクト開発を、最高に面白いゲームとして捉え直し、今日から簡単にできるポイントを一気に押さえるセッションです。プロダクト開発で重要だけれども、ふわっとした認識のままにしやすい「問題」や「顧客」、「不確実性」「信頼」の解像度が高まり、自在に扱えるようにお届けします。これらに振り回されることがぐっと減り、仕事が面白くなります。

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

    ゲームは「分からないとつまらないけれど、分かってくると面白くなる」という性質があります。しかし、ゲームの面白さはめったに教えてもらえません。実はプロダクト開発も一緒です。

    ゲームとプロダクト開発の共通点
    ・分からないとつまらない
    ・分かってくると面白くなる
    ・面白さはめったに教えてもらえない

    野球、サッカー、将棋、ビデオゲームは分かれば分かるほど面白くなります。しかし、ゲームのルールそのものには「分かってくると面白くなる」ことは触れていませんし、みんなが実感できるようになるわけではありません。残念なことに、面白さが分からないままゲームをやめてしまうことも多いでしょう。ですから、「ゲームが分かって面白くなってきた」というのは実は幸運なことです。

     

    企業のミッションや、プロダクトヴィジョンには輝かしいプロダクトの活躍が描かれます。それらに惹かれて、入社して、いざ働こうとしても、現実は違う仕事をしている日々が続くこともあります。これでは、まるで「最高に面白いゲーム」とパッケージに書かれたクソゲーです。

    私たちは仕事を通して、プロダクトを作り、顧客に貢献する仕事をしようとしていますが、様々なことから振り回されることばかりです。顧客の無茶な要求、他部署の突発依頼に翻弄され、上司の尻拭いをしているうちに一日が終わってしまってしまう日もあります。

    そうしてプロダクト開発の面白さと楽しさに気付くことなく、混乱と理不尽にいかに耐えるかという日々を送っているとしたらもったいないです。もしかしたら、そのまま10年、20年たってしまうかもしれません。

    プロダクト開発は現代でも一番ホットなゲームだと私は考えます。面白くなれば、毎日がもっと楽しくなるでしょう。しかも、プロダクト開発はうまくいくほど世の中に貢献できる与えるゲームです。しかし、簡単にクソゲーになりかねないゲームです。ポイントを押さえれば、これ以上にないほど面白いゲームになりうると思います。

    あるアルバイトの方がいました。その方は与えられた仕事をたんたんとこなすだけで、毎日、真顔で8時間過ごされていました。ところが、プレイしている仕事が分かると、楽しみはじめ、あっという間にベテラン正社員よりもヒットをバンバン生み出してしまいました。何より、笑顔で仕事に関わるようになり、声には楽しさが灯るようになりました。

    「プロダクト開発というゲーム」における重要な要素を紹介し、スクラムが直接取り扱ってはいないけれどもプロダクトの成功に不可欠な要素を解説し、そしてそれを楽しむゲームのプレイ方法を紹介します。「分からないとつまらないけれど、分かってくると面白くなる」を時間や運に任せず、ショートカットしてしまいましょう。

    ■セッション内容の一例
    私たちは仕事を通して、いったいどのようなゲームをプレイしているか
    ・少ないヒントを元に組みあわせるジグソーパズル
    ・進んでいるのか、進んでいないのか分かりにくいルービックキューブ
    ・飛躍したアイデアが必要な知恵の輪

    私たちは複数のゲームをプレイしている
    ・チームや組織の問題を解きほぐしたりする
    ・信頼で結ばれたチームを実現しようとしている
    ・様々な不確実性を乗り越えようとしている
    ・顧客のアウトカムに貢献しようとしている

    ■セッション内容
    ・真剣に遊ぶように仕事をするためのプロダクトマネジメントプレイブック
    ・私たちは仕事を通してどんなゲームをプレイしているの?
     ・ゲームの面白さはどこにあるのか?
     ・伝説のゲーム ひげ親父とカメの間にあるもの
     ・料理 生とコゲの間にあるもの
     ・小学校サッカー 面白さの誤解
    ・ゲームのルール
     ・顧客、問題、不確実性、信頼、組織
    ・問題解決とは何か
     ・問題が解決されると何が起こるの
     ・問題はどのくらい難しいのか
     ・顧客に問題定義を委ねるな
     ・問題を解決しないという解決策「見過ごしとやり過ごし」
     ・一時しのぎの量的解決「スケールしているのは人件費でした」
     ・外部性の闘い「手を抜けば安くなる」
     ・見過ごすべき、やり過ごすべき本当の問題は何か
    ・クソゲーの条件
     ・良定義問題と不良定義問題
     ・残機ゼロ
     ・形勢評価
     ・ノーフィードバック、ノーゲーム
    ・チームで問題解決する
     ・ 人と人が信頼して協力するためのアラインメント
     ・ゴールまでの経路を指し示すルーティング
     ・見過ごしたりやり過ごせない厄介な問題を片づける
     ・つきっきりにはなれないから、行動を促す状況を構築する
     ・あちらを立てればこちらが立たないトレードオフ
     ・権限や予算で解決できることは限られている
    ・組織で問題解決する
     ・明日を支配するものと明日を創るもの
     ・コーゼーション
     ・エフェクチュエーション
    ・顧客と問題解決する
    ・自分達のゲームを楽しむために今日からすること
     ・プレイボール!!

    ■過去の関連セッション
    RSGT2021 『ヒット商品を生み出すプロダクトマネジメントブースター』
    なんでもかんでも不確実性のせいにしてしまっていないか。私たちが「知らない/できない/興味ない」に陥ってしまうのは、いったいどのような力が働いているのか。いかにして乗り越えるか。
    https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022

    RSGT2022 『ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか』
    「最高のプロダクトを作ろう」とはじめたのに、いつのまにか「最高の利益を上げよう」という会社になっていた。顧客の悩みに寄り添っていた私たちが、今では顧客のサイフばかり気にしている。いかにして起こるのか。何が機会となりえるのか。
    https://speakerdeck.com/moriyuya/product-management-booster

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - チームが育つ委譲型の課題解決アプローチ

    20 Mins
    Talk
    Intermediate

    「課題を解決する」

    これはシステム開発だけではなく、仕事をする上で日常行うことの一つだと思います。
    課題の解決方法は様々ですし、環境や状況、関わる人によっても変わります。
    自分自身が解決する役割であったり、解決を指示する役割であれば、その「解決方法」は自分の中にあれば良いでしょう。しかし、チームが育つ、つまりは自分以外の人が「課題を解決する」という場合、みなさんならどうしますか?
    今回、私自身の経験として、支援しているチーム自身が課題を解決する経験をしました。その時に、支援する私にとっての「課題の解決方法」が自分自身で解決する時の「課題の解決方法」とアプローチが違っているということにきづいたので、そのお話をしたいと思います。

  • Nicholas Wilson
    keyboard_arrow_down

    Nicholas Wilson - ベロシティとの決別

    Nicholas Wilson
    Nicholas Wilson
    Senior Principal
    Slalom LLC
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Advanced

    Do you remember the last time you explained velocity and story points to your client? Was it an easy conversation? Does your sprint planing session take all day? Do you find that task estimation is wildly different from team to team, and between developers? Has your scrum team lost faith in the whole approach? It may be time for a radical change. Intrigued?  Join me.
    前回、クライアントにベロシティとストーリーポイントを説明したときのことを覚えていますか?それは簡単な会話だったでしょうか?スプリントプランニングのセッションに一日中かかっていませんか?タスクの見積もりはチームによって、また開発者間で大きく異なっていますか?スクラムチームは、このアプローチ全体への信頼を失っていませんか?それは、根本的な変化の時かもしれません。興味ありますか?  私に参加してください。

  • Hiroyoshi Ida
    keyboard_arrow_down

    Hiroyoshi Ida - スクラムチーム×ストレングスファインダーで相互に強みを発揮するチームになった話

    45 Mins
    Talk
    Intermediate

    スクラムチームには多種多様な人がいます。

    あなたのスクラムチームは、全員がなんでもできるようになろうと、チームが苦手な方法をとっていませんか?

    苦手を克服しようとするあまり、本来の強みを活かせないチームになっていないでしょうか?

    自分の強みを使うことにフォーカスする人々は、生活の質が非常に高いと報告する確率が3倍高く、仕事に積極的に取り組む確率が6倍高いという調査結果があります。

    もしかしたら、あなたのいるチームの強みに目を向ける時が来たのかもしれません。

    このセッションでは、ストレングスファインダーを用いて個人の強みに目をつけるところから始まり、個人が集まったチームの強みの理解へと進み、そのチームが成果を出すための活動についてお話しします。

    認定ストレングスコーチが外部からスクラムチームに関わることによって得られた知見を共有します。

help