初めてプロダクトオーナーを担当したら大規模アジャイル開発だった件

プロダクトオーナーを担っててこんな思いしたことありませんか?
・権限が委譲されず意思決定できない
・意思決定の判断基準が決められない
・ステークホルダーが多すぎて合意できない
・ステークホルダーがアジャイル開発を理解しようとしない
・スクラムチームとのコミュニケーションがうまくいかない
・プロダクトオーナーが呼ばれるミーティング多すぎる
まさに私がそうでした。
ヤフーとイーブックジャパンを統合しwebサイトのリニューアルを大規模アジャイル開発で実施し2017年に掲げた2020年に取扱高200億円の目標を達成するまでの日々の奮闘をお話します。 

 
 

Outline/Structure of the Talk

・なぜプロダクトオーナーを担当したか
・なぜ大規模アジャイルを採用したか
・プロダクトオーナーとして組織をアジャイルにした日々の奮闘

Learning Outcome

・意思決定ができるプロダクトオーナー
・ステークホルダーの巻き込み方
・チームとの関わり方
・大規模アジャイル導入判断

Target Audience

プロダクトオーナー 、課題を抱えているチーム、ステークホルダー 、大規模アジャイル開発に興味ある方

schedule Submitted 10 months ago

  • Arissa Nakamura
    keyboard_arrow_down

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

    Arissa Nakamura
    Arissa Nakamura
    Scrum Master
    CI&T
    schedule 11 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate


    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.

  • Yuya Kazama
    keyboard_arrow_down

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

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

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

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

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

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

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

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

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

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

  • 45 Mins
    Panel
    Advanced

    早く行きたければ、ひとりで行け。
    遠くまで行きたければ、みんなで行け。

    プロダクトをちゃんと作り、育てていくために必要なものは何でしょうか?
    ビジョンや現実的なロードマップ、MVPや顧客仮設の検証はもちろんとして、プロダクトチームを育てていく必要があるんじゃないかと思います。
    近くに行きたいなら一人で行け、遠くまで行きたいなら、みんなで行け。

    チームを維持するためには、政治も必要、カネも必要、ユーザーはもっと必要。
    プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。
    エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

    プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

    発表者は、黒田樹さん(リクルートテクノロジーズ)、絹川達也さん(楽天)、横道稔さん(LINE)。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

  • Hiroyuki Ito
    keyboard_arrow_down

    Hiroyuki Ito - Tips of Product Management for Internal Tools/社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所

    Hiroyuki Ito
    Hiroyuki Ito
    Agile Coach, DevOps Consultant
    -
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    私たちLINEのSETチームは、プロダクト開発チームのプロセス改善と生産性向上を実現・推進するため、多くの社内ツール・サービス・プラットフォームを提案・開発・運用しています。

    その経験で私たちは、技術的に優れた最先端のモノを提供し続けるだけでは不足で、ユーザの真のニーズの発見とその実装、施策を続けるための意思決定者からの支持の取り付け、社内でのプロモーション活動といった、プロダクトマネジメントの要素が必要不可欠であるとの認識に至りました。

    一方で、ThoughtWorks社の"Technology Radar"などによると、プロダクトマネジメントの知見・方法論を社内ツール・サービス・プラットフォームへ適用する傾向が世界的に広まりつつある一方で、そのための知見がまだまだ不足していることも分かりました。

    そこで当セッションでは、特に社内ツール・サービス・プラットフォームにおける、プロダクトマネジメントの適用の勘所・Tips・パターン・アンチパターンについて、私たちの現場での実践例を元に、参加者の皆さまが活用できる知見として紹介します。

  • Kazuyoshi Takahashi
    keyboard_arrow_down

    Kazuyoshi Takahashi - アジャイルコーチとVPoE、あるいはEMの間にあるもの

    20 Mins
    Talk
    Executive

    10年前から5年前まで、アジャイルコーチとして2,000人以上の開発組織を抱える企業のアジャイルトランスフォーメーションに挑戦していました。
    現在はその立場を離れ、事業会社のVPoEとして開発組織の運営をしています。

    アジャイルコーチとVPoE、両方の経験からチームを見る視点にどのような違いがあるのか、アジャイルコーチの先にどのようなキャリアがあるのか、個人的な経験を交えながらお話します。

    RSGT2020 Closing Keynote「NEXT→ACTION」の後日談でもあります。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - ふりかえり手法のおもちゃばこ

    45 Mins
    Panel
    Intermediate

    ふりかえり/スプリントレトロスペクティブで、みなさんはどんな手法を使っていますか?

    「KPT・YWT・Fun/Done/Learn あたりは試してみたものの、他の手法は知らない」という人も多いはず。

    色々な手法を試してみると、「あぁ、ふりかえりってこういうものなのね」とあらためて見えてくるものがあるんです。

    だから、色んな手法を試してみてほしい!楽しんでほしい!

    そんな想いで、このセッションを実施します。

     

    このセッションでは、トコトンHowを追求します。

    目的の話は一切しません(目的の話は関連リンクをご参照ください)

    とにかく色んな手法を、手法の進め方、実施イメージ、ポイントなどに絞ってお話します。

    1手法1分~2分くらいで、とにかくたくさん、面白い手法を話します。

    メジャーなものからマイナーなものまで、色々話したいと思います。

    きっと、「あ!これ楽しそう!私もやってみよう!」という手法が見つかるはずです。

     

    話せるとよいなと考えている手法

    • DPA
    • 3Dots
    • 連想ゲーム
    • Timeline
    • Story of a Story
    • 象、死んだ魚、嘔吐
    • 斜に構える/構えないを切り替える
    • Starfish / Small Starfish
    • Following up on Action Items
    • Celebration Grid
    • 質問の輪
    • Sailboat / 熱気球 / スピードカー / ロケット
    • ORID
    • 4Ls
    • Repeat / Avoid
    • Effort & Pain
    • SMART Goals
    • 360度感謝
    • Hapiness Door

    このセッションは、参加者との双方向で作り上げていきます。

    KANEが参加者からのコメントを拾い、森が解説する。

    気になる手法を、この場で明らかにし、楽しいふりかえりを作り上げていきましょう!

  • Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Toshiharu Akimoto - 本当に大切なものは余白から生み出される。ゆるい1on1のススメ

    45 Mins
    Talk
    Beginner
    • コーチやSMは特に横の繋がりをうまく作らないと知識の幅や、学習の幅が狭まりませんか?また悩み事やこんな時にどうしたらいいの?みたいな具体的な話も、オープンな相談会ではしにくいことがあると思います。
    • 一方で、勉強会などのイベントだと自分の興味範囲を必ずしも話題にできるとは限らず、その時々の状況に応じたトピックを話す場合が多いのではないでしょうか?
    • そんな人たちに、このゆるい1on1を提案し、ゆるい紐帯(つながり)だからこその新しい気付きやアイディアの源泉となっている事例をご紹介します。
    • この考え方はふりかえりやチーム内での対話にも有効です。
  • Yosuke Matsuura
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

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

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

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

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

    ち・がーーーーーーう。

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

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

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

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


    チーム作りのプロセス

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

     

  • kyon _mm
    keyboard_arrow_down

    kyon _mm / neno neno - アジャイルを忘れるチーム Unlearn Agile

    45 Mins
    Talk
    Advanced

    「チームが生き生きしつづける予感はどこからきますか?」

    予告編動画 => https://www.youtube.com/watch?v=5Ro5_c5kFaY

    20200904164048_original.jpg

     

    アジャイルをUnlearnし、生き生きとした開発を見つけたチームがいました。そこにはアジャイルマニフェストもスクラムガイドもなく、自分達のパタンランゲージがありました。開発するシステム、立ち居振る舞い、プロセス、価値観、イベント、成果物などありとあらゆるものが記述されていました。パタンランゲージの語彙は200を超え日々編纂されていました。

    私達チームが新しい形に変化していくこと自体が漸進的で、自然で、納得しやすい必要がありました。Unlearnしていくこと、アレグザンダー理論を導入していくこと、実践していくことは一見難しくおもえました。ですが、私達は徐々にできてきました。この漸進的な変化こそが私達が見つけたかったものです。これこそがチームにおける決定の遅延であり、漸進的変化でした。これらの具体例そして考察をおとどけします。

    時を超えた開発の道とは何かを考えるきっかけにどうぞ。

  • Harada Kiro
    keyboard_arrow_down

    Harada Kiro - スクラムをスケールするとはどういうことか?

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    DXという言葉がいろいろなところで見かけるようになり、それに伴ってスクラムをスケールする手法も色々と出てくるようになっています。

    たくさん見かけるからといっても、うまく行っている例は多くありません。むしろ、例ばかりが増えすぎて混乱しているようにも見えます。過去にも用語だけ先行する例はたくさんありましたね。

    このセッションでは、特定のスケーリング手法を説明するのではなく、スクラムがスケールできた状態とはどういうものか、スケーリングを妨げる障害について議論したいと思っています。

     

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - 組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」

    20 Mins
    Talk
    Intermediate

    ScrumやXPなどを用いて、みなさんのチームがアジャイルになっていっているとします。

    そのチームの活動がプロダクトを構築することが主なら、次はプロダクトをより使い続けてもらえるプロダクトづくりができるチームを目指してもいいかもしれません。

    その時には開発をする役割以外にも、ユーザーのことを知る活動、ユーザーに買ってもらう活動、ユーザーのサポートをする活動など様々な活動が必要になります。そしてその活動を担う人達やチームと連携して動く(少し大きな)チームになる必要があります。

    このようなチームがうまく機能する要素の1つに「組織がアジャイルな価値観や考え方、それに根ざした活動ができているか?」というのがあります。
    もし1つ、2つのチームしかアジャイルな価値観や考え方を持っていなければ、このようなチームはうまく機能しないかもしれません。

    このセッションでは、組織がアジャイルな価値観や考え方、それに根ざした活動をうまくできるようになるために取り組んできた事例をお話します。
    組織の中の一員としてやっていた(昔の)事例、ギルドワークスの現場コーチとして様々な現場を外から支援していた事例をお話できればと思います。

    みなさんの組織がアジャイルになっていくヒントになればと考えています。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    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

    45 Mins
    Talk
    Intermediate

    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.

  • 平鍋健児
    keyboard_arrow_down

    平鍋健児 - 野中郁次郎のスクラム再訪問(Nonaka's Scrum Revisited)

    平鍋健児
    平鍋健児
    CEO
    ESM, Inc.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    これまで、Scrumの1つの源流ととらえられてた "The New New Development Game" ですが、今回は、一連の野中先生の著作や論文の中に発見される、組織論コンセプトと、現在の Scrumとの関係について、整理してお話したいと思います。

    1. 2つの知の形態:暗黙知と形式知
    2. 自己相似系(マトリョーシカ)組織と「海兵隊」
    3. 消耗戦と機動戦。OODA モデル。
    4. 第3の知=実践知(Phronesis)
    5. 「共感」の本質、You-I-It(二人称・一人称・三人称) 

    などのコンセプトを中心にお話します。

     

     

     

  • KazuhideInano
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

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

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

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

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

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

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

  • Akihiro Kosako
    keyboard_arrow_down

    Akihiro Kosako / Hiroki Noguchi / Masataka Mizuno - 「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます

    45 Mins
    Panel
    Intermediate

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

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

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

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

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

    20 Mins
    Talk
    Intermediate

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

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

    sgt01.jpeg

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

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

  • Minoru Yokomichi
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

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

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

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - A ScrumMaster Way - #ScrumMasterWay の歩き方

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムを成功させるためには、スクラムマスターの活躍が欠かせません。自身がサーバントリーダーとしてチームを支援する立場でありながら、スクラムマスターも日々の実践を通じて成長することが求められます。

    キーノートスピーカーのZuzana 'Zuzi' Šochováが著書「The Great ScrumMaster(日本語版: SCRUMMASTER THE BOOK)」の中で提唱している #ScrumMasterWay は、スクラムマスターの成長過程の理解の助けになる概念です。

    本セッションでは #ScrumMasterWay の各レベルを参照しながら、実際に私がスクラムマスターとして取り組んできた活動をふりかえり、スクラムマスターの成長について考えたいと思います。

  • Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu - Six trumps for Scrum with Terrific Tips -スクラムのセレモニーを最大限楽しくする原則とその実践のヒント-

    Koki Shimizu
    Koki Shimizu
    Scrum Master
    N/A
    schedule 11 months ago
    Sold Out!
    100 Mins
    Workshop
    Intermediate

    スクラムのセレモニー(イベント)が長い、退屈だ、誰か一人だけ話している、お通夜・・・
    なんてことありませんか?

    学習熱心なスクラムマスターに相談しましょう!
    ・・・でもスクラムマスターも困っています。

    スクラムのセレモニーを効率的に効果的に楽しく、みんなの学習効果を最大化できる方法なんてどこにも載ってないんです!

    そこで、Six trumpsをご紹介します。

    この原則を元にスクラムのセレモニーのみならず、ワークショップ、カンファレンス、エグゼクティブミーティング、全社会議、株主総会、国会審議をアレンジしてみてください!!
    ものすごい良いミーティングになると思います!
    人が集まるところにおいて、人と人との関係性、学習効果を高めるために、すべてに応用できます!

    このワークショップは、
    Six trumpsの概要をお伝えし、スクラムのセレモニーにどのように応用するかを参加者同士深くディスカッションする形式
    となります。

    加えて、清水自身がScrumにSix Trumpsをどのように適応しているかお伝えします!

  • Kenta Sasa
    keyboard_arrow_down

    Kenta Sasa - アジャイルコーチで得た経験知 〜大企業へ完全オンラインで寄り添ってみたら変化した私のアジャイルコーチスタイル2021冬〜

    20 Mins
    Talk
    Intermediate

    アジャイル開発を始めたいと思ってるけどどうやったら良いか分からない…

    新しいやり方がうまくいくか不安だ…

    そんな現場ではアジャイルコーチを呼んでスクラムチーム立ち上げを一緒に行うことがあります。

     

    アジャイルコーチ支援の多くは個人による支援なので、個人毎に違った得意技があります。

    また、学習・経験を経て個人のスタイルは変化し続けます。

    またまた、知識・スキル以外にも個別のキャラもあります。

     

    私はアジャイルコーチとして2年ほどスクラムチームの支援をしてきました。

    その中で車業界のHさんや半導体業界のTさんといった大企業で仕事もさせていただきました。

    さらに、コロナの影響もあり完全オンラインでの支援に移行するといった変化もありました。

    色んなチームと関わり、色んな失敗や学びを経て、徐々に自分に合ったアジャイルコーチスタイルが見えてきました。

     

    というわけで!

    とても個人的な内容になりますが「笹のアジャイルコーチスタイル」について話させてもらいます。

    スタイルは日々変化して現時点のスタイルになっていますが、その過程でどんな経験を経てどんな変化があったのかについてもふりかえってみます。

    その中でチームを成長させていく上で重要だと考えていることをまとめていこうと思います。

     

    アジャイルコーチを始める方や始めたばかりで悩んでいる方が、自分自身をアップデートするための刺激になれば幸いです!

help