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

location_city Tokyo schedule Jan 6th 01:25 - 01:45 PM place 1F Room B (48) people 29 Interested

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

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

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

 
 

Outline/Structure of the Talk

  • ラーマンの法則
  • 数百名規模日系メガベンチャーの変革
  • フェーズシリコンバレースタートアップCの変化
    • エンジェル〜シード(数名)
    • シリーズA(数十名)
  • シリコンバレースタートアップCの変革とその後
  • 結論と考察


ラーマンの法則、プロジェクトとプロダクト、component組織とfeature組織、各トランスフォーメーション実例なども踏まえながら、上記アウトラインで20分に収める予定です。

Learning Outcome

  • 様々な組織規模、事業フェーズ、文化においてどのような課題があり、どのような解決策があるのかを知る

Target Audience

scrum practitioner, agile coach, DX practitioner, engineering manager, engineer, designer, product manager, CS, QA, VPoE, CTO

Prerequisites for Attendees

特になし

Video


schedule Submitted 9 months ago

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

    Great teams make a huge difference to your company’s success. Great ScrumMasters create such high-performing teams.

    I will tell you some of the secrets you need to know to become a great ScrumMaster. Create a high-performing collaborative environment at your organization, which makes your organization more than competitive in the current complex globalized world.

    This session is targeted to all leaders of Agile transformation, Agile Coaches, and ScrumMasters who understand the Agile basics but have the dream of achieving significantly better results with Agile/Scrum.

    The session is based on my book The Great ScrumMaster, published by Addison-Wesley, Signature Series (Cohn) on Jan 2017.  The Great ScrumMaster - #ScrumMasterWay.

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - 「わからない」と共存するチーム May the CHAOS be with team

    45 Mins
    Talk
    Advanced

    仕事をしているとたくさんの「わからない」と出会います。

    • スクラムがわからない
    • 自分たちの取り組みがこのままでいいのかわからない
    • このプロダクトが売れるかどうかわからない
    • スケジュール通り開発できるかどうかわからない

    「わからない」という状態は不安です。不安な中で取り組んでいることが思うような結果が出ないと、うまくいかなかった!とすぐに結論づけたくなってしまいがちです。

    「わからない」はふつうだ

    スクラムガイドの中で、スクラムの定義はこのように書かれています。

    スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

    実際に私たちの仕事をふりかえっても、わかりやすい結果を得られることはほんのわずかで「わからない」ことがとても多いです。つまり「わからない」というのはふつうのことで、「わからない」だらけの中でも前に進み続けることが私たちの仕事です。

    同じようなコンテキスト下で同じようにスクラムに取り組んでいるのになぜうまくいくチームとうまくいかないチームに分かれてしまうのか、という疑問と長年向き合い続けてきましたが、この「わからない」と共存することがうまくいくチームの条件であるように思います。

    「わからない」と共存するチーム

    私たちのチームも「わからない」ことがないわけではなく、「わからない」だらけの中で活動を続けています。私たちのチームが「わからない」をコントロールするために行っている取り組みやチームの特性について、また新たに取り組み始めたことについて、事例を元にお話します。

    「わからない」を受け入れ、もっとチーム開発をうまくなりたいという想いをもったみなさんの参考になればと思っています。

  • 45 Mins
    Panel
    Advanced

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

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

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

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

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

  • Makoto Iguchi
    keyboard_arrow_down

    Makoto Iguchi - セキュリティとアジャイル開発のいい関係について考える / Security and Agile Development

    20 Mins
    Talk
    Intermediate

    The presentation will be given in Japanese. I've uploaded the (partially) translated version of my slides at https://www2.slideshare.net/makotoiguchi/how-to-balance-between-security-and-agile-development for your reference.


    2018年12月頃に掲載された「アジャイル手法でのセキュリティは困難」というタイトルの記事において、某セキュリティ会社のCTOは「高速のCI/CD(継続的なインテグレーション/デリバリー)においてセキュリティ上の問題が浮上しても、その解決に当たる余裕や時間がないままに事態が進行してしまうようなことが往々にしてあり、現場が混乱する」とした上で、結果として「DevSecOps、NetSecOpsが、現実にはうまく機能しない」という見解を示しました。

    これは本当なのでしょうか?
    もし本当だとしたら、それは悲しいことなのではないでしょうか?

    一方、2019年8月に掲載された "Your security team is probably an infuriating obstacle - but it doesn't have to be this way" という記事においても触れられているように、開発者側より「セキュリティは、DevOpsやアジャイルな開発スタイルにブレーキをかける存在である」といった声を聞くことがよくあります。

    これは正しい姿なのでしょか?
    セキュリティとアジャイル開発は、水と油の関係なのでしょうか?

    このセッションでは、ISMS内部監査責任者とスクラムマスターを兼任している立場の人間から見た、セキュリティとアジャイル開発の「あるべき姿」についてお話します。また、現在行っているセキュアなアジャイル開発の実現へ向けた実験(The Elevation of Privilege: Threat Modeling Card Deck を活用したセキュリティ問題の洗い出しとプラニング)をご紹介します。

    参考)The Elevation of Privilege: Threat Modeling Card Deck を日本語化&いらすとや化したもの。こちらの Github レポジトリで公開中です。

    EfOaaY7VAAE6AW7?format=jpg&name=medium

  • Arata Fujimura
    keyboard_arrow_down

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

    Arata Fujimura
    Arata Fujimura
    Manager
    Classmethod, Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

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

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

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

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

    -56-1024.jpg?cb=1581658760

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

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

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    DENSO
    schedule 9 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか?と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。それから3年あまりが経ちました。あの時の彼の決断は正しかった、と今の私なら言えます。

    このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

  • Tomoharu Nagasawa
    keyboard_arrow_down

    Tomoharu Nagasawa - 2つのモードで学ぶ辛くないスクラム

    20 Mins
    Talk
    Beginner

    「スクラムやらなねばならない!」といった相談が多くなってきました。また、「我々はスクラムを実践しているんだ!」といった前のめりな心強い推進者の影で、そのノリについていけない普通の人からの相談も増えてきました。

    このセッションでは、2つのモードを題材にしてスクラムを実践することが少しでも辛くならないようにする考察と解説を試みたいと思います

    2つのモード:

    • 「する」モード
      「〜をする」、「〜しなければならない」、「〜させる」、「〜させられる」といったモード。自身かまたは外部からの意志に大きく左右される。
    • 「ある」モード
      「ここにいる」、「いい感じ」、「続いている」といったモード。自身の内なるもの。そこに意志は関係ない。

    スクラムと、「する」モードから「ある」モードへの変化、「ある」モードから「する」モードへの変化を解説することで、スクラムの意義と効果を解説する試みです。

  • Kazuyoshi Takahashi
    keyboard_arrow_down

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

    20 Mins
    Talk
    Executive

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

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

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

  • Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - Rethink Scrum from a Japanese cultural perspective

    45 Mins
    Talk
    Intermediate

    (English session)

    Japanese culture influenced Scrum. Jeff Sutherland and Ken Schwaber presented Scrum in 1995. It was inspired by “The New New Product Development Game“ (1986) by Hirotaka Takeuchi and Ikujiro Nonaka. It also incorporates many elements of Toyota Production System. Then Scrum was reimported to Japan. It has totally changed our way of software development, and given us many insights ranging from teams to organizations. In addition, it makes us rediscover and think of our culture.

    I have been working for Rakuten, Inc. for more than 10 years introducing Scrum to many teams. Rakuten adapted English as a primary language, which was unusual as a Japanese company at that time. As a result of that, now we work in a unique environment where many people from diverse cultures work together respecting each other on top of Japanese cultural basis.

    In this session, I would like to rethink Scrum from Japanese cultural perspective. I feel there are some insights we can add to Scrum especially about leadership.

  • Mori Yuya
    keyboard_arrow_down

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

    45 Mins
    Talk
    Advanced

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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

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

     

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

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

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

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

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

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

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

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

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

     

  • 平鍋健児
    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(二人称・一人称・三人称) 

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

     

     

     

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Ayumi HOSOZAWA / Etsuo Yamada / KazuhideInano / Ken Matsumoto / Toshiharu Akimoto / Tomonari Nakamura ( ikikko ) / Toshiyuki Ohtomo - コロナ前からコミュニティでリモートモブで常に前に進む『The Great ScrumMaster』翻訳チームの話。普通の私たちが読みやすい本を目指して持続性のある翻訳作業に行きついた。

    20 Mins
    Talk
    Beginner

    『The Great ScrumMaster』を翻訳したチームが発足したのは2019年4月のことです。住む地域も異なる9人が、Facebookをきっかけに翻訳するために集まり、コロケーションでのモブがなかなかうまくいかないところから、実験を繰り返しながら、徐々に持続性の高いモブ作業をリモートで確立するに至りました。もしかしたらこれは自分たちがそう考えているだけで大したことがない話なのかもしれませんが、そのあとで世界を襲ったCOVID-19の中でも、この知見と身に着けた感覚は有効だったと考えています。今後も同様の形式の翻訳を進めていきたいと考えておりますので、どの辺がよかったのか、みなさんに聴いていただいて、フィードバックをいただければと思います。

    おかげさまで書籍の方も「読みやすい」というご意見を多くいただきまして、リリース版での誤りの訂正も今のところ一箇所のみです。品質も高められたかなと思います。

    20201001074451.jpg20201001074443.jpg20201001074901.png

    20201001074705.png

    このセッションは、フルタイムでもなければ地域も近くない私たちが、普通のリモートモブに達した軌跡を共有し、普通のリモートモブの姿を提言します。これが唯一の正解でもないですし、私たちも発展途上なので、ぜひ様々なフィードバックがいただければ幸いです。

     

  • Nao Takeuchi
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

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

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

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

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

    株式会社メルカリは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.

     

  • KazuhideInano
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

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

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

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

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

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

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

  • Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto - プロダクトを強化する探索的テスト戦略

    Noriyuki Nemoto
    Noriyuki Nemoto
    senior engineer
    Agile Sapporo
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    スクラム/アジャイル開発でプロダクトの品質はうまく担保できていますか?

    要求をシンプルにしたり、テストの自動化に取り組んだり、テスト設計をしたり。もちろん品質を担保するには色々なアプローチがありますが、今回は探索的テストの使い方に焦点を当ててお話をしたいと思います。

    具体的にはST:スクリプトテスト(テスト仕様書に沿ったテスト)とET:探索的テストの使い分けのパターンを紹介します。探索的テストはコストが少ない割にバグの発見率がいいんです!!

    • ST->ETシリアル
    • ST/ET パラレル①
    • ST/ET パラレル②
    • ET-> STシリアル
    • ET->ST->STシリアル
    • ST&ET STチャーター

    品質が悪くて手戻りが多いチームにお勧めします。
    自動テストに探索的テストを加えて、安心してスプリントを進めていきましょう。

    最後に…探索的テストってテストのアジャイルなアプローチなんですよ!!

  • 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

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

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

help