Regional Scrum Gathering Tokyo 2021 Day 1

Wed, Jan 6
Timezone: Asia/Tokyo (JST)
09:00
09:30

    Welcome Note - 15 mins

09:45
10:00
10:25
10:45
11:00
  • Added to My Schedule
    keyboard_arrow_down
    Yoshimasa Iwase

    Yoshimasa Iwase / Junki Ueda - Remote Work Native な働き方を志向した結果、Agileな状態に爆進しているとあるHRチームの話 - 組織全体への波及を添えて

    schedule  11:00 - 11:20 AM place 2F Main Hall WEST手前 (90) people 19 Interested star_halfRate

    2020年初頭よりコロナウィルスの流行により、私達の働き方は激変しました。もともと、オフィス出社が当たり前だった状態から、フルリモート中心に変化しています。

    自身の人事系チームにおいても、コロナ前はオフィス出社があたりまえのチームでした。そのため、リモートに適したチーム運営・コミュニケーション・ITフル活用を進めていかねば、リモート時にパフォーマンスが悪化してしまいます。

    そこで、在宅でも高いパフォーマンスを出すために、Remote Work Native な働き方を考え続け、継続的にふりかえり、試行錯誤を繰り返していきました。その結果、自然とBeing Agileな状態に進んでいることがわかりました。

    本Talkでは、どのようにAgileな状態へ進んでいったのか、またその取組みを組織全体・会社全体へ波及させるために何をしているのか、といった実例についてお話いたします。

  • Added to My Schedule
    keyboard_arrow_down
    Akiyo Urano

    Akiyo Urano / Rui Kamiyama / Mika Mochizuki / Taeko Kasuga - [Online Interpretation] 患者さんや顧客に最大の価値を提供するために ~外資系製薬企業が組織全体の変革を目指しアジャイル導入~

    schedule  11:00 - 11:45 AM place 2F Main Hall EAST奥 (90) people 11 Interested star_halfRate

    [English abstract follows Japanese]

    1. 患者さんや顧客に最大の価値を提供するために 

    ~外資系製薬企業が組織全体の変革を目指しアジャイル導入~ 

    • 背景 

    MSDは、これまでも常に患者さんや顧客に対し、サイエンスや画期的な医薬品をお届けするために取り組んでいました。しかし、急速に変化する医療環境の中で、さらに患者さんや顧客に最大の価値を提供するために、2020年1月にエンタープライズ・レベルでアジャイル組織を発足しました。 

    グローバルでも部門・部署単位でアジャイルを導入している国はありますが、全社的に採用したのは日本が初めて。当社が把握している限りでは、日本の製薬業界においても、MSDはエンタープライズ・アジャイルを導入した初の企業です。 

    • アジャイルMSDに向けたプロセス 

    小さく始め、成果を出すというアジャイル・マインドセットを基に、まずは一部の組織でパイロットとして2018年11月に主要疾患領域である不眠症チームがアジャイルを導入しました。このプロジェクトでは、社員エンゲージメントやチームの満足度、生産性が向上したことが確認できました。そして、2019年6月には、プライマリーケアマーケティング部門全体にも、アジャイルな働き方を拡大する事を即座に決定しました。 

    • 何が変わったのか 

    このアジャイルな働き方の試行により、意思決定の効率化やパフォーマンスの向上、独創的かつ革新的なプロジェクトの創製力や解決方法の策定などで成果を上げることを確認しました。 

    • Scrum Master Journey 

    アジャイル組織発足の一環として、MSDは独自のスクラムマスターの育成にも注力し、社内からTalentを見出しました。 アジャイルとは違った背景からスタートしたスクラムマスターが、彼らのストーリーを共有します。 

    • 結果 

    パイロットの成功を実感した経営陣は全社レベルでアジャイル組織へと変革することを決定しました。そして、トライブ・スクワッド)を立ち上げ、スクラムの手法を日常業務として実践しています。そして変化し続ける事業環境に今後も柔軟かつ素早く対応する為、四半期ごとに事業を振り返り、優先事項を決め、組織の全員が優先事項を理解できるよう、会社全体と各部門のOKR(Objectives and Key Results、目標と成果指標)を設定するプロセスも導入、実施しています。 

    • COVID-19 

    新型コロナウイルス感染症の流行が拡大する中、多くの企業が新しい働き方を実施していますが、MSDでは既にアジャイル導入を行っていた為にビジネスへの影響を最小限に留めることが出来ました。2020年第2四半期には、「リモートワーク・スクワッド」を立ち上げ、スクラム手法をリモートで継続して行く為の環境を短期間で整える事ができました。 

    また重要なことですが、新型コロナウイルス感染拡大の状況下において、顧客価値を最大化するため、リモートによる顧客エンゲージメントを優先することに焦点を当てています。このような対策を取ることができたのは、すでに「アジャイル」な働き方が導入されており、意思決定や優先事項・リソース配分の見直しにより、変化により柔軟に対応できたためです。 

    2021年は、アジャイル組織として2年目を迎え、さらに成熟していく中で、「サイエンスと医療の最前線に立つヘルスケア企業へ。すべては、患者さんのために」というビジョンの実現に向けて常に成長を目指していきます。 

    To deliver innovative medicines and vaccines, and maximize value to patients and customers in Japan  

    ~ A Global Pharmaceutical Company has Transformed into an Agile Organization. ~ 

    • Background 

    MSD Japan transformed into an Agile organization in January 2020, aiming to ensure that we continue to deliver innovative medicines and vaccines, and maximize value to customers in Japan amid a rapidly changing healthcare environment.  MSD Japan embraced Agile on an enterprise level for the first time in MSD’s global network where Agile has been implemented on a team/department level in several countries. As far as we know, we are also the first in the pharmaceutical industry in Japan to apply Agile on an enterprise level.  

    • Process towards becoming Agile MSD  

    We took an Agile approach of “starting small and producing a result” in our transformation. We first adopted Agile in November 2018 as a pilot project with insomnia, one of the key therapeutic areas at our company. Then, we decided to expand this working style to the entire Primary Care Marketing organization in June 2019.  

    • What changed  

    We experienced successful results, such as increased efficiency in decision making and overall performance, increased employee engagement, and customer satisfaction.  

    • Scrum Master Journey 

    As a part of Agile transformation, MSD also focused on developing own Scrum Masters and found talent within. Scrum Masters have started this journey from non-Agile background and will be sharing their stories. 

    • Result  

    Based on the success from the pilot phase, we decided to transform into an Agile organization on an enterprise level. 

    In designing the new organization, we placed the utmost focus on how we can maximize value for our customers and patients.  The Agile organization at MSD Japan consists of cross-functional “Tribes/Squads” that operate by common objective and “Chapters” formed by expertise.  

    We also conduct business review and set priorities on a quarterly basis to stay flexible and nimble in the changing business environment. OKR (Objectives and Key Results) for the company as well as all departments are transparently shared so that everyone in the organization understands priorities.  

    • COVID-19 

    Agile ways of working enabled us to operate with minimal disruption to business amid COVID-19. In 2Q2020, we launched “Remote Working Squad” dedicated to support a seamless working environment for employees in teleworking.    

    We also refocused our priority to remote engagement for our customers, so as to maximize customer value. All this was possible because we have already been in the “Agile mode” that allowed us to respond to changes more flexibly by making decisions and revisiting priorities and resource allocation.  

    As we mature and move onto Year Two as an Agile organization in 2021, we will constantly reflect how we can improve to realize our vision to “Become the leading company at the forefront of science and healthcare. Everything for patients.”  

  • Added to My Schedule
    keyboard_arrow_down
    Masayuki Yarimizu

    Masayuki Yarimizu - たった一人からはじめて70人の縦割り組織にスクラム導入した話

    schedule  11:00 - 11:20 AM place 1F Room B (48) people 37 Interested star_halfRate

    私は現在70人規模のソーシャルゲーム開発の現場で働いております。

    70人規模ともなると、プロジェクトの運営は難易度が高くなります。そのため、マネジメントしやすいようにチーム編成や組織構造の最適化が図られます。その結果よくあるのが、職種ごとでチームが組まれそれぞれにリーダーが存在し、さらにそのリーダーをまとめるためのリーダーが存在するといった縦割りのピラミッド構造のような組織です。

    こうした組織では往々にして以下のような問題が発生しがちです。

    • 誰が何をやっているのかわからない…
    • リーダーがタスク調整で忙殺…
    • 職掌間の仲が悪い…

    私の所属する組織も例に漏れずゴリゴリの縦割り組織で、上記の問題が大変深刻なレベルで発生していました。

    しかし、あることをきっかけに組織構造も縦割り組織から職能横断組織への変貌を遂げ、上記の問題が解決してきました。

    本セッションでは、そうした組織改変を何も権限のない1人のエンジニアがどのように推進していったか、そのプロセスとコツをご紹介できればと思います。

  • schedule  11:00 - 11:20 AM place 1F Room C (72) people 21 Interested star_halfRate

    R&D(研究開発)チームは常に不確実性と向き合っているため、アジャイル/スクラムを取り入れることは必然のように思えます。
    私が所属するR&Dチームや隣のR&Dチームもスクラムに取り組み、自分たちで働き方を問い直しながら変化し続けるようになっています。
    今ではスクラム導入前にどう働いていたのか思い出せないほどにチームに浸透しています。
    新しく配属された新人は、このやり方こそがスタンダードだと感じています。

    しかし、最初から難なくスクラム開発に取り組むことができたかというと、そうではありませんでした。
    スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ…
    スクラムイベントの名を冠する予定は定期的に開催されていたものの、そこに透明性はなく、よって検査と適応もない状態でした。

    形だけのスクラムがもたらした閉塞感から脱却し、透明性・検査・適応によって変化していくために実施したこと。
    取り組む中でどのような壁にぶつかり、どう適応し変化していったのか。いつ自分たちの開発スタイルに自信を持つことができたのか。
    そして、今はどこに向かっているのか。

    現在進行形の現場から、チームの学びと成長をお届けします。

  • Added to My Schedule
    keyboard_arrow_down
    Takashi Kunimoto

    Takashi Kunimoto / Tomoko Emi - 「変わりたいのに変われない」チームがアジャイルで変わった話

    schedule  11:00 - 11:20 AM place [Sponsor sessions] 2F Terrace Room (18) people 14 Interested star_halfRate

    我々楽天のECインキュベーション開発部(略してECID)では、改善グループという部署横断でサポートするチームがあります。
    改善グループはプロダクト開発グループには所属せず、それぞれの高いスキルをもっていろんなチームの難しい課題を一緒に解決することをミッションにしています。

    そんなECIDに去年の5月新しく仲間が増えました。
    このチームはマネージャも含めてチーム運営と開発に関する経験が浅く、ちゃんと開発をしたいのに思う通りにできない状態が続いていました。

    当時の彼らは、

    • 仕様変更をリクエストされても突発対応が入ってもProjectの納期は変えられない
    • 色々とシステムの作りがよくないのが分かっていてもどう手をつけていいかわからず悩む
    • そしてバグもいっぱいでる
    • 結果、残業が常態化

    という状況でした。

    そこに改善グループから派遣されたメンバーがもたらしたいくつかの変化とは?
    この変化によって今チームがどのように変わったかも含めてお話させていただきます。

11:25
11:45
13:00
13:25
  • Added to My Schedule
    keyboard_arrow_down
    Minoru Yokomichi

    Minoru Yokomichi - アジャイルつまみ食いしたい人向けの「アジャイルから学べること(私が学んだこと)」〜アジャイルに興味をもってもらう方法を添えて

    schedule  01:25 - 01:45 PM place 2F Main Hall WEST手前 (90) people 21 Interested star_halfRate

    私が最初に本格的にアジャイルと出会ったのは 2012年の Developer Summit でした。その後、書籍や記事、アジャイルコミュニティにいる実践者、研修トレーナー、同僚などから様々なことを学びました。

    その本質が理解できていた(る)かはさておいても、その中には、次の日から意識や行動が変容するような、私の中でそれまでの考え方が大きくかわった考え方もたくさんありました。

    ここ数年、「アジャイル」という言葉にはこだわることなく、これらのアジャイルから学んだことを、部分的であったとしても、様々なロールの人と働く中で実践しその考え方をおすそ分けしてきました。それがアジャイルから学んだことであることを明かすことで、結果としてアジャイルに興味を持って頂くシーンもとても増えてきました

    このセッションでは、私自身が初学者だった頃にさかのぼって、今でも印象深いことを広く浅くごった煮駆け足でお伝えできればとおもいます。(なるべくその後その知識を深められるように、参照元を紹介する予定です)

    さまざまなロールの方が、その中から一つでもひっかかり、つまみ食いでも良いのでアジャイルに興味を持つきっかけになればと思います。
    または、アジャイル実践者の方は、まわりでアジャイルのファンを増やす活動のヒントや材料にしていただければと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Nobuhisa Hirata

    Nobuhisa Hirata - シリコンバレースタートアップから日系大企業までの組織別DX

    schedule  01:25 - 01:45 PM place 1F Room B (48) people 29 Interested star_halfRate

    日系メガベンチャーや日系大企業で行われたデジタルトランスフォーメーションと現場オペレーション、
    シリコンバレースタートアップ創業フェーズからEXITフェーズまでの組織規模の変化に伴い、直面した組織課題及びその解決策の立案・実行。

    はたから見ると最先端でモダンなイメージの会社、でも実態はAgileとはかけ離れた文化。
    ソフトウェアのことをしらなそうな日系大企業、でもこんなにもモダンな開発ができている。
    イケイケのチームであるはずなのに、なんかだんだんと変わってきてるように感じてきた。そろそろ解決しないとやばいけど、根本的な問題はなんだろう。

    様々な文化、組織規模、事業フェーズにおいて実際に体験し、悪戦苦闘しながら問題と立ち向かってきたお話を、組織論を踏まえてお伝えしていきます。

  • Added to My Schedule
    keyboard_arrow_down
    Yasunobu Kawaguchi

    Yasunobu Kawaguchi - コロナ禍でのオンライン研修とハイブリッドカンファレンスを支える技術

    schedule  01:25 - 01:45 PM place [Sponsor sessions] 2F Terrace Room (18) people 12 Interested star_halfRate

    ※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションです。

    コロナ禍で、私たちも研修をオンライン開催する必要に迫られました。
    時差、同時通訳、Zoomの扱いなど、様々な技術要素を学んできましたので、本セッションではそのお話をしたいと思います。
    アギレルゴコンサルティングのオンライン研修、スクラムフェス大阪、スクラムフェス三河、スクラムフェス札幌、
    品川アジャイルでの活動を経て、RSGTのハイブリッド開催は行われています。

    技術的な背景と、プロダクトとしての考え方を話してみたいと思います。

     

14:00
14:25
14:45
15:15

    Sponsor Talk / Keynote Preparation - 15 mins

15:30
17:00

Regional Scrum Gathering Tokyo 2021 Day 2

Thu, Jan 7
Timezone: Asia/Tokyo (JST)
09:00
09:30

    Welcome Note - 15 mins

09:45

    Sponsor Talk / Keynote Preparation - 15 mins

10:00
11:30
13:00
  • Added to My Schedule
    keyboard_arrow_down
    Ryutaro YOSHIBA (Ryuzee)

    Ryutaro YOSHIBA (Ryuzee) - スクラムにおける「完成」とはなにか?

    schedule  01:00 - 01:20 PM place 2F Main Hall WEST手前 (90) people 64 Interested star_halfRate

    スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します(弊社調べ)。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
    つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。

    しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。

    sgt01.jpeg

    ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません(と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが)。

    そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。

  • Added to My Schedule
    keyboard_arrow_down
    Jean-Baptiste Vasseur

    Jean-Baptiste Vasseur / Antony Chane-Hive - [Online Interpretation] 破?scrumからFLATを生み出して実験してみた話し / FLAT: the story of an experiment moving from scrum to our new framework

    schedule  01:00 - 01:45 PM place 2F Main Hall EAST奥 (90) people 18 Interested star_halfRate

    株式会社メルカリは2年前から本格的にスクラムを導入し、実践してきました。

    ところが、とあるLogisticsキャンプ(同じビジネスドメインに専任をする複数のチームのこと)ではスクラムから少し離れてFLATというフレームワークを生み出そうとしていました。FLexible Agile TeamはDynamic Reteamingからインスパイアされ、スクラムパターンの「安定チーム」を意図的に反する複数なアジャイルチームのための実験的なものであった。

    FLATの狙いは限られたスキルと人数でキャンプメンバーをエンパワーして、複数の新機能及びリファクタリングをより柔軟に実現できるようになること。

    果たしてそれは無謀な試みなのか、アンチパターンだらか失敗はされていたのか、あるいは素晴らしい学びと成長につながるきっかけだったか、守破離の破なのか、どうなのか?!?

    本セッションではメルカリのスクラム導入背景及びLogisticsキャンプで行われたFLAT実験について詳しくご紹介致します。

    ---

    Once upon a time, about two years ago, Mercari adopted scrum and started practicing and learning a new mindset and methodologies.

    In the galaxy of Logistics, a group of people decided then to move away from strict scrum and gave birth to a new framework, FLAT. FLexible Agile Team was inspired by the book "Dynamic Reteaming", and deliberately broke the sacred scrum pattern "Stable Teams" for its multiple teams.

    The main goal of FLAT was to empower logistics members and give them a chance overcome their challenges, such as limited resources for specific competencies, new awesome features to increase the user experience and the product value but at the same time a lot of maintenance and refactoring work to carry out.

    What will be ultimately the destiny for FLAT? Was this a reckless attempt? Was breaking a scrum pattern a guarantee to fail? Or did was this an opportunity for amazing learnings and growth?

    In this session we will talk about Mercari's Agile journey, scrum adoption, Camp Structure, the birth of FLAT and the learnings acquired from this experiment.

     

  • Added to My Schedule
    keyboard_arrow_down
    KazuhideInano

    KazuhideInano / Etsuo Yamada / Yasumi Nakano - 【現地登壇】アジャイルコーチそれぞれの歩み 〜今夜くらべてみました〜

    schedule  01:00 - 01:45 PM place 1F Room B (48) people 9 Interested star_halfRate

    「アジャイルコーチってどうやったらなれるんですか?」
    「自分でそう名乗っちゃっていいのかな?」
    「”明日からアジャイコーチやってよ”と上司に任命されたんですが、何をすればいいんでしょう?」

    時々、このような声を聞くことがあります。モヤモヤがモヤモヤを呼ぶモヤモヤ感、ありませんか?(汗)
    これからアジャイルコーチを目指してみようと思う方にむけて、このセッションでは

    • コーチになる経緯って実際のところどんな流れがあるんだろう?
    • コーチになるために意識しておくと良さそうなことって何だろう?
    • コーチが大切にしてることって何だろう?

    といったことをそれぞれのコーチが自身の経験や考えを示し、そこからコーチングにおいて大切にしている事、価値観、コーチになるまでの経緯から生まれる多様性や共通点などを整理することでコーチを目指す人、あるいはコーチをお願いしたい人にとってのヒントを持ち帰っていただける場にできればと思います。

    私たちコーチも、うまくやれる方法を毎日探し続けている身です。このセッションは、決してアジャイルコーチになるためのHowToを示したいわけではなく、ましてコーチを代表して語ろうというものでもありません。ただ、サンプルとして自身の情報を共有することによって、これから目指そうとする人の気づきのひとつにでもなれれば幸いです。

    ※ みなさんサブタイトルの「今夜くらべてみました」はご存知ですよね?え、まだ?であればこちらをご覧ください

  • Added to My Schedule
    keyboard_arrow_down
    Mori Yuya

    Mori Yuya - ヒット商品を生み出すプロダクトマネジメントブースター

    schedule  01:00 - 01:45 PM place 1F Room C (72) people 26 Interested star_halfRate

    顧客に愛されるヒット商品を作るための、ソフトウェア開発以外の重要なポイントを一気に抑えてしまうセッションです。次のような悩みに効きます。

    プロダクトが良くなってきたもののライバルに負ける。
    「ユーザーが増えた! サービスが成長した! ところが大手企業が丸パクリしてきて、資本力で顧客を奪ってく!!」

    お客さんに下手に出てお願いしないと買ってもらえない。
    「いいプロダクトだねー! でも、高いなー、もう少し安かったら買うかも」


    「不確実性への適応」というテーマがよく話されています。

    不確実性とは、一般的には「直接コントロールできないが、目標達成に重大な影響を与える要素」とされています。経営組織論では「組織が活動するために必要な情報と、実際に組織がすでに入手している情報との差」と表現されることもあります。つまり十分に分かっていたら確実性が高い行動がとれるわけですね。

    たとえば、いつ大地震がやってくるのか、大雪がいつ降るのかは私たちにはコントロールできません。ところが物流や公共交通機関に仕事として関わる人たちに大きな影響を与えます。

    同じように、お客様の考え、市場の不特定多数のユーザーの考えを直接マインドコントロールのように操作できませんが、私たちの仕事の前途に大きな影響を与えます。これらは不確実といえるでしょう。

    もし直接コントロールできたり完全な情報を知れたら有利にプロダクト開発ができるでしょう。ですから、私たちは不確実性に適応していくために様々な取り組みをしています。不確実への適応は重要なはずです。

    しかし、私たちが感じている不確実なさまざまな事柄は、本当に不確実なのでしょうか。
    実は不確実ではないものまで不確実だと思い込んでいないでしょうか。


    私は新規事業やヒット商品を20代はじめから関わってきました。そこで分かったのは『不確実性が重要な領域は実は限られている。しらない、できない、興味ないという態度のほうが影響が大きい。つまり積極的な無知、無能、無関心が大きな障害となっている』ということです。

    これはプロダクト開発の隠れた真実だと思います。

    不確実とは言い換えれば「十分な知識や経験を持つ専門家でも判断に迷う、分からない」と言い換えれます。つまり、乱暴ですが、専門家でも分からなかったら不確実といえるでしょう。ちょっと専門家が調べれば分かる事柄は不確実ではないということです。


    私たちは本当は不確実ではないものまで、不確実に押し込んでしまっていないでしょうか。例えば私たちの仕事を乱すチーム外の人たちからの関わり…役員の依頼だったり、他の部署の人たちの行動があったりします。

    「営業が無茶な案件を押しつけてくる」
    「上司が前例がないからと許可してくれない」
    「社長が変なことを言い出した」

    企業の外側でもいろいろなことが起きます。

    「お客様が突然契約キャンセルしてきた」「お客様に価格を下げるよう強く主張された」
    「大企業が、自社製品にそっくりなプロダクトをリリースしてきた」

    自分達のプロダクト開発でも様々なことが起きます。
    「プロダクトを紹介するwebページどうしよう。競合との機能比較表がよくあるけれど、これでいいのかな」

     

    これらは全てが不確実というよりも、「しらない、できない、興味ない」によるところが多く、うまく対応できるところも多いはずです。これに真っ向から立ち向かうのがプロダクトマネジメントです。

    プロダクトマネジメントとは製品開発、組織開発、財務、マーケティング、流通、セールス、保守、顧客サポート、業務提携、企業間競争といった諸活動を通じて、現在から未来にかけて顧客の要望をこれまでにない高い水準で満たすことにより、業界内で独走状態を築くことを目標にしたマネジメントと私は考えます。

    プロダクトを成功させるためには必要な様々な専門領域があり、うまく協力することで経済活動として成り立ちます。このセッションでは、これらの「スクラムが直接扱わないがスクラムを通してプロダクトの成功に不可欠な領域」についてポイントを抑えてお話ししたいと思います。

    ヒット商品作りの隠れた真実
    ・不確実性と、無知・無力・無関心

    組織開発を学ぶ
    ・企業内の大きな無駄
    ・社内競争を止める
    ・ブルシットジョブ(クソどうでもいい仕事)を減らす
    ・全員で問題解決

    製品開発以外のビジネス
    ・顧客を学ぶ
    ・競合と競争を学ぶ
    ・独占を学ぶ
    ・収益を学ぶ
    ・セールス(成約)を学ぶ

  • Added to My Schedule
    keyboard_arrow_down
    Akinori Tokita

    Akinori Tokita - 社外のはじめてPO経験される方との歩み方を「遠い昔、はるか彼方の銀河系...」に学ぶ

    schedule  01:00 - 01:20 PM place [Sponsor sessions] 2F Terrace Room (18) people 2 Interested star_halfRate

    年末年始に一気観したスターウォーズに、

    我々の実践している社外のPO経験される方と一緒に、プロダクト初期フェーズを歩む活動のポイントは、

    全部つまっていました。

     


    KDDI DIGITAL GATEは主にお客さま企業のDX(Digital Transformation)を支援する組織です。

    新しいサービス作りたい方や、業務改善などの課題を解決したい様々な企業の方とチームを組んで、

    ごく初期フェーズのプロダクトのPoCのために、サービスデザイン、スクラム開発、プロダクト価値の検証の支援しています。

     


    支援の中で、関わるお客様企業のプロダクトオーナーは、スクラム開発はもちろん、

    ソフトウェア開発や、サービス開発の経験を持たれていない方も多くいらっしゃいます。

     


    そんなPOをはじめて経験される方々が安心して能力を発揮できるようなサポートのポイントは何だろうか?

    これまでの活動の中で感じた小さな工夫をフォースと共にご紹介したいと思います。

13:25
13:45
14:00
  • Added to My Schedule
    keyboard_arrow_down
    Arissa Nakamura

    Arissa Nakamura - プランニング会議は実験室 !チームと顧客に支えられるスクラムマスターの日々の試み

    schedule  02:00 - 02:20 PM place 2F Main Hall WEST手前 (90) people 15 Interested star_halfRate


    CI&Tに入社して4年目、スクラムマスターになって1年半、今までは教えられた通りにプロセスを回していました。
    しかし、プロセスは私たちを目的地までたどり着かせるツールであり、全てを解決してくれるわけではありません。

    プランニングではいつもスプリントバックログを細かいタスクに分けて、それらを時間で見積もっていました。
    その見積もりを時間ではなく、日にち単位で見積もったらどうなるのか?
    それについて考えて、お客様とより良い関係を築けるように、チームと新しい方法に挑戦してみました。

    新しいことに挑戦させてくれる会社、一緒についてきてくれるチーム、その経験について話したいと思っています。


    It has been 4 years since I joined CI&T, and 1 year and half since I became a Scrum Master.
    When I joined, I learned CI&T process and all these years I've been running it exactly the way I was taught.
    Along the time, I also learned that the processes exist to lead us to a certain Goal, they are not a magical solution to all our problems.

    On our planning, we used to split the Sprint Backlog into smaller tasks and estimate every one of them in hours. However, what would happen if we changed the estimation from hours to days?
    This question was made to me when I was looking for a way to improve the team relationship with the customer. Not accurate estimations was one of our struggles at the time.
    Finally, I decided to talk with my team and make an experiment: try a new methodology with my team that could also help us to get more trust from the client.

    In this short talk, I'd like to share my experience of new trials, learnings with my team members and how CI&T supported us on this trial.

  • Added to My Schedule
    keyboard_arrow_down
    Masanori Kawarada (Mark Ward)

    Masanori Kawarada (Mark Ward) - [Online Interpretation] 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    schedule  02:00 - 02:45 PM place 2F Main Hall EAST奥 (90) people 14 Interested star_halfRate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Added to My Schedule
    keyboard_arrow_down
    Yosuke Matsuura

    Yosuke Matsuura / Ken Matsumoto / Yasunobu Kawaguchi - アジャイル戦略論 「チーム作りの巻」~すべての基礎はチーム作りにあり。

    schedule  02:00 - 02:45 PM place 1F Room B (48) people 51 Interested star_halfRate

    「ボトムアップでのアジャイルチームづくりは、どうしたらよいか?」
    「アジャイルチームを作ったものの、なかなかその先に進まない」
    「顧客要望やトップダウン指示で、アジャイルチームを早急に作り成果を求められているが何から始めたらよいか、わからない」
    こうしたご質問を数多くいただくようになりました。日本企業の経営層から開発エンジニアまで、みんな悩んでいるみたいです。

    みなさんご存じの通り、アジャイルにおけるマネジメントの基礎は、チームにあります。チームがなければ、ベロシティも測れないし、見積もりもできないし、デリバリーできません。しかし、いまだに、作るものが決まって、予算が取れてから人をかき集めるプロジェクトが後を絶ちません。どうやって調達・開発するのかが決まっていないのに、なぜか金額や期間は決まってしまう。

    まあ日本人、子供のころからチームチーム刷り込まれてますし、集まれば仲良くやることには長けてます。なんとかしますよ。大人ですし。

    「うちの会社にいる人間はまじめな奴が多いから、
     チームというのは勝手に集まればできるもので、
     まあ、よいチームを作るためにワークショップでもして、親睦を深めたらいい」
    ....などと、簡単に思っているマネージャーも結構多いのではないかと思います。

    ち・がーーーーーーう。

    そんな風にしたって、簡単にはうまくいかないこと、みんな体験してますよね?
    小学校の掃除の班でケンカが絶えない。遠足のグループ活動が楽しくない。
    あいつの言うことが納得できない。一人でやった方が仕事が早い。
    特定の人が仕事のほとんどを背負って周りは動けてない。
    うまくできない人がいるけど十分に教える余裕がない。

    私たちのチーム作りは失敗の連続。
    でも仕方ない。人間関係って難しいから。
    私一人が我慢すればよいのだ。
    ...いつもそうやって、うまくいかないことに蓋をして、めんどくさいことを先送りしようとします。

    じゃあ、どうやってチームを作るのか?
    本セッションでは、ここに答えていこうと思います。

    大企業から中小企業まで経験を持つ、アジャイルコーチ三人衆が、それぞれの経験から話をしていきます。
    チーム作りの各段階で、どんなことを考えながら作っていくのか、参考になる話もならない話もあると思いますが、
    参考になるところだけ持って帰っていただければと思います。


    チーム作りのプロセス

    1. 一人目の仲間を作る
    2. 話し合いながらアウトプットする
    3. ものの置き場を確保する
    4. 成果をアピールする
    5. やったことをふりかえる
    6. 技術的負債を解消する

     

  • Added to My Schedule
    keyboard_arrow_down
    Arata Fujimura

    Arata Fujimura - モダンオフショア開発のすすめ

    schedule  02:00 - 02:45 PM place 1F Room C (72) people 15 Interested star_halfRate

    オフショア開発と聞いて皆さんは何をイメージしますか?

    • 安かろう悪かろう
    • 技術力不足
    • 低品質

    未だにこのようなイメージを抱いている方も少なくないかもしれません。

    クラスメソッド社で2019年7月に立ち上げたグローバルチームでは、上記イメージのようなオフショア開発をレガシーオフショア、我々が目指すオフショア開発をモダンオフショアと明確に分けて定義し、ベトナム開発パートナーとともにモダンオフショア開発を実践してきています。

    -56-1024.jpg?cb=1581658760

    レガシーオフショアとモダンオフショアの違いを上記のように定義していますが、モダンオフショアを一言で言うと"アジャイル×オフショア開発"となります。

    当セッションでは、実際にモダンオフショア開発を進める上で得た学びを、事例を交えて熱くお話しさせて頂きます!

  • Added to My Schedule
    keyboard_arrow_down
    Tadahiro Yasuda

    Tadahiro Yasuda - 「企業文化は戦略に勝る」アジリティの高い組織/チームを創ろう!

    schedule  02:00 - 02:20 PM place [Sponsor sessions] 2F Terrace Room (18) people 14 Interested star_halfRate

    この環境の変化が激しい今だからこそ企業として基盤となる文化(カルチャー)が重要です。

    私達自身が企業文化形成のためにどんな取り組みをしてきたのかをご紹介します。

    クリエーションラインでは製造業、物流業、小売業をはじめとして多くの業界の企業に対してアジリティの高い組織/チームを創る支援を行っています。ツールの導入や技術面だけでなく、人、環境、文化の改革が必要です。私達の「みんなが幸せに働ける職場」を創るための活動をご紹介します。

    (このセッションはスポンサーセッションとなります。)

14:25
  • Added to My Schedule
    keyboard_arrow_down
    Nao Takeuchi

    Nao Takeuchi - Project Manager が Global Scrum Gathering に参加したら、 一年後 ScrumMaster に転生していた件について。

    schedule  02:25 - 02:45 PM place 2F Main Hall WEST手前 (90) people 21 Interested star_halfRate

    Scrum での開発に興味のある Project Manager はいらっしゃいませんか? 
    ScrumMaster を始めてはみたものの、何となくプロジェクトマネジメントの延長になってしまっている Project Manager はいらっしゃいませんか?

    以前の私がまさにそんな人物でした。

    Technical Project Manager として LINE アプリ内スタンプショップ開発に参加したものの、開発規模も大きく苦労の連続。 
    Scrum に魅力を感じ、それならばと CSM を取りに行くも、秋葉原では心を削られ、現場に戻ってもやはり壁は高い。
    そして、なかなか一歩が踏み出せない、、、

    と、そんな私ですが、昨年の Global Scrum Gathering に参加し、そこで学んだ経験を糧に、ScrumMaster 稼業を始めました!

    実際に ScrumMaster を始めてみると、プロジェクトマネジメントとは考え方が全く違うこと、たくさんありました。
    分かったつもりでいたのに、実際にやってみたら勘違いだったこと、たくさんありました。

    Project Manager だった私が、知りたかったことを実例と共にお伝えし、ScrumMaster に挑戦してみようと思えるようなセッションをお贈りします。

14:45
15:15
  • Added to My Schedule
    keyboard_arrow_down
    Yuya Kazama

    Yuya Kazama - Scrumチームに「テストは単純作業ではなく創造的な活動だ」という意識を浸透させて良品質&低コストの製品を作るようになるまでの物語

    schedule  03:15 - 04:00 PM place 2F Main Hall WEST手前 (90) people 31 Interested star_halfRate

    皆さんはテストを「作業」としてやっていますか?それとも「活動」としてやっていますか?

    • 沢山の羅列をしたチェック項目を確認することがテストである
    • とりあえずプログラムの実装をして、実装が終わった後に、確認すべきことを考えてテストする
    • 実装したプログラムに対してバグを検出することが、唯一にして最大のテストをする目的である

    上記のような考え方をしている方々は、おそらくテストを「作業」として行なっています。

    もしくはテスト駆動開発(TDD)がテストの全てだと考えている人もいるかもしれません。

    そして残念ながら、テストを作業として行なっているorTDDがテストの全てだと考えているScrumチームが多くあると感じています。

    一方私は、テストは創造的な活動であり、プログラムの実装前の時点でもテストの活動を行うことが可能だと考えています。これは、TDDを行うよりももっと前の話です。

    例えば、テストの活動を利用することで、リファインメント時点で今まで以上に仕様を明確にすることができます。(しかもそんなに時間をかけずに!)

    また、テスト技法を用いることで、Planning時点(開発実装前の段階)で行うべきテストを考えることができます。

    これらの活動により、品質の良い&コストのかからない製品を作り出すことができます。

    本講演では、「テストは作業である」「テストについては実装後にQAに任せれば良い」と考えていたScrumチームに対して、どのようにして「テストは活動である」という考え方を染み込ませていったかの物語をお伝えします。

  • Added to My Schedule
    keyboard_arrow_down
    Woohyeok Aaron Kim

    Woohyeok Aaron Kim - Integrate your cycle with OODA (Extended Edition of Scrum X Army at ‘RSGT2020’)

    schedule  03:15 - 04:00 PM place 2F Main Hall EAST奥 (90) people 33 Interested star_halfRate

    世界中で著名な人物である野中先生やScrumのCo-CreatorであるJeff氏の歩みからも分かるように、Agile・Scrumの哲学は長い間の研究で発達してきた軍隊の組織論に基づいています。軍隊はただ一度のミスが作戦の失敗をもたらすという厳しい状況で、どうすれば戦闘力を最大化し勝ち続けていけるのかの未来図を示しています。軍隊がいつも力を入れているこの点は、Velocityを最大化し、どのようにビジネスの成功を導くか工夫している点でAgile組織と同じだと言えます。

    その軍隊が、成功のために必須不可欠だと強調しているものがOODAループです。

    PDCAというサイクルはすでに、ビジネス世界で基本中の基本となっています。ただ計画性が重要視されるだけに、予期できなかったことが起きた場合またPlanningから始めなければなりません。Agileが主流になっている今、PDCAが持つ限界は明確ですが、この弱点を補うのがOODAです。最初から全てを計画するのではなく、現在の出来事を観察(Observe)し、その分析結果により(Orient)次のアクションを取る(Decide, Action)ことで、変化に対する素早い対応ができるようになります。

    OODAループはどこからきたのか、どういうものなのか。そしてPDCAとのハイブリッド的な運用で、組織に対して何を示すことができるか。4年間士官として軍隊に勤めていた私からご提示させていただきます。

    (このセッションは、RSGT2020で好評をいただけた「SCRUM X ARMY」の再演ではなく、拡張版となります。)

  • schedule  03:15 - 04:55 PM place 1F Room B (48) people 4 Interested star_halfRate

    The craft of Agile Coaching fundamentally requires deep, insightful, meaningful communication. In everyday execution, this typically involves a coach and the coachees having a conversation, or dialog. However, there are other ways that an Agile Coach and their coachees can connect – nonverbal communication.

    Explore the different aspects of nonverbal communication in the domain of the Agile Coach! This workshop overviews nonverbal communication in Agile Coaching and provides a starting point for developing this critical skill.

  • Added to My Schedule
    keyboard_arrow_down
    SATORU KAWABUCHI

    SATORU KAWABUCHI - NTTみたいな企業で新アプリをスクラム開発してみんなが笑顔になった

    schedule  03:15 - 03:35 PM place 1F Room C (72) people 18 Interested star_halfRate

    NTTグループでサービスをアジャイル/DevOps的に運営をしてきた。しかしながら、現在提供中のスマホアプリがNow Up To Dateなものではなくなってきたため、新しいアプリに作り変える必要性があることがわかってきた

    そして決めたのは

    ・一般的にトラディショナルな会社ではアプリの刷新は、既存機能を全て要件定義し、マイグレーションを行うが、この方法をとらずアジャイルスクラムで新アプリをつくることとした

    ・すなわちユーザーの価値が高いものからプロダクトバックログを作り、動くモックを作ってレビューするを繰り返してきた。そのときに既存機能でも価値が低いものは作らないこととし、リリース可能担ったタイミングでリリースすることとした

    ・トラディショナルな会社の中でこのやり方を承認してもらい、メンバーが取り組んでいく中で、ステイクホルダーまで含めて盛り上がってきた

    ・結果的に良いものができた。できることは限られているが、とても高速で動きユーザーにとって一番あってほしい価値を実現できた。

    大企業の中でアジャイルを生き延びさせるには?起きてくる現場と社内との課題、その時マネージャーにできることは?この取り組みのようなことをトラディショナルな企業でも考えていくべきと思うので学びにしていってもらいたい!

  • schedule  03:15 - 03:35 PM place [Sponsor sessions] 2F Terrace Room (18) people 15 Interested star_halfRate

    ソフトバンク社員が「情報革命で人々を幸せに」を実現するために、日々、邁進していることは言うまでもありませんが、我々、IT 本部は、いわゆる情報システム部門で、主に通信事業に必要な IT サービスを提供するためシステムを開発・運用している組織となります。

    ソフトバンクと言うと、フットワークの軽い、チャレンジングなイメージがあるかと思いますが、通信事業は皆さまの生活を支える重要なインフラですので、これまで堅牢、堅実なシステム開発が主流でした。一方で、我々 IT 本部では 2017 年から、アジャイル開発に取り組んできており、これまでにいくつかの成功と挫折を乗り越えて現在に至っています。

    私が所属しているスクラムチームは、プロダクトオーナー1人、開発者4人、開発者兼スクラムマスター4人という構成になっています。
    開発者兼スクラムマスターは 4 人のうち 3 人は最近スクラムマスターの資格を得たばかりで、実際に業務として開発者とスクラムマスターを兼任しているのは 1 人です。
    開発者とスクラムマスターを兼任することは賛否両論ありますが、実際に開発業務を行う中で得られた知識や感想、兼任することの利点、欠点について紹介していこうと思います。
    開発者とスクラムマスターを兼任している方と共感していただいて互いによりよいチームを作るためのきっかけになればいいなと思っています。

15:40
16:00
16:15

Regional Scrum Gathering Tokyo 2021 Day 3

Fri, Jan 8
Timezone: Asia/Tokyo (JST)
09:30

    Registration - 15 mins

09:45

    Welcome Note - 15 mins

10:00

    Open Space Technology - 120 mins

12:00

    LunchBreak - 45 mins

12:45

    Sponsor Talk / Keynote Preparation - 15 mins

13:00

    Keynote - 90 mins

14:30

    Closing - 15 mins

help