location_city Tokyo schedule Jan 8th 02:00 - 02:45 PM place sola city Hall(WEST) people 41 Interested

大企業で新規事業を始めるために必要なものはなんだと思いますか?予算ですか?社内政治ですか?そう!違う!そう!

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

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

発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

 
 

Outline/Structure of the Panel

1. はじめに (10分)
 なぜこのセッションを行うのかについて説明します。
 企業のなかでプロダクトオーナーをしていくためには、
 カネと政治のプラクティスをうまく使いこなすことが必須条件です。
 しかし正面から「カネと政治がんばります!」というと感じが悪いので、
 もうちょっと真面目そうなお題目を考える必要があります。
 ストレッチをしたりしながら、このセッションの趣旨を共有します。

2. パネリストのみなさんの発表 (10分 x 3)
 - 絹川達也さん(楽天) 「事業を作るならまず文化から」
 - 太田敦士さん(NTT西日本) 「古い組織と新しいビジネス」
- 森正弥さん(楽天技術研究所ファウンダー)


3. 質疑応答 (5分)
 各パネリストの皆さんの発表を受けて、会場からの質問に答えます。
 (時間がなくなる可能性はありますので、その場合は会場外やパーティでご質問ください)

Learning Outcome

企業でプロダクトオーナーを進めていく上で重要な、予算管理と社内調整についての見識を得られる。

新規事業を生み出していく仕組みを企業内に実装する上での経験談を得られる。

質問を通じて、自分なりの見解への意見を得られる。(ネットワーキングパーティもご活用ください)

「真似しないほうがよいこと」を避けられるかもしれません。

Target Audience

主に大企業の新規事業関係者、プロダクトオーナー、ビジネス担当、開発チーム

Prerequisites for Attendees

スクラムおよびプロダクトオーナーの基本的な知識があると楽しめると思います。
大きな組織でのアジャイル適用や、新しいことを始めた経験があるとわかりみが深いと思います。
参考図書をLinkの方に上げておきます。

schedule Submitted 1 year ago

  • 90 Mins
    Keynote
    Intermediate

    2011年に開催された初回のRSGTの実行委員長だったので、実行委員会を離れスタートアップに入ってからも毎回RSGTの動向はなんとなく横目で見ていました。国内でアジャイル開発やスクラムに取り組むのが当たり前になっていき、RSGTも参加者が増え、スポンサーの集まりやチケットの売れる速度が増していくさまを、途中まではヤフーのアジャイルコーチとして、そのあとはスタートアップの現場から、驚きながら見ていました。

    このたびクロージングキーノートのご依頼をいただきまして、前回・前々回の登壇された方と比べて見劣りするであろう僕でいいのかと、実行委員会のメンバーに質問したくらい恐れおののいています。でも、特別ではない普通の人だからこそ伝えられることがあるのではと思いましたし、前職においては大きな成果を挙げられたとも感じているので、お話しすることにしました。前職でアジャイルコーチをすることになったきっかけを話すと「なんでその状況でそんな面倒なことに首をつっこむのかわからない」という感想を抱くらしいです。参加者の皆様は少なくとも何かを変えたいと思ってスクラムに取り組んでいるはずですし、その取り組みはきっと怖いことの連続です。怖いからこそ強がったり、理論武装したり、面倒臭がったり、見えないふりしたり、冷笑的になったりします。そういった斜に構える弱さを、何を考え、どうやって乗り越える力を保ち続けたのかを話すことはできるかもしれない、と思っています。Tipsとかテクニックを支える何かを共有できたらいいな、と思っています。どうぞよろしくお願いいたします。

  • James Coplien
    keyboard_arrow_down

    James Coplien - The Ten Bulls of the Scrum Patterns

    90 Mins
    Keynote
    Intermediate

    Most Scrum practitioners today follow the katas of their training, dutiful to all that they correctly answered during the certification exam. For many, it is a struggle to get even this far: letting go of old waterfall ways to work in small, cross-functional teams that deliver at lightening pace. Yet the framework and certification are only the beginning. Patterns drive to the why beneath the framework and its practices so you discover your most fully human self that you were born with, and which the university and your job drove out of you. We’ll explore this why a bit. But even patterns are only a taste of the transcendence that comes with insight. In that transcendence we find the secret that few know about Scrum, or that they ever find about patterns: that each is only a path to finding your own deeper self, not only in a way that contributes to its respective discipline, and to work, or to design, but to the greater good of the self and humanity.

  • Michael Sahota
    keyboard_arrow_down

    Michael Sahota - Lost in Translation: The Manager’s Role in Agile

    90 Mins
    Keynote
    Intermediate

    Your organization has moved to autonomous, self-organizing teams. Everyone is trained and coached on their new role. But what about managers? The role of a manager is _undefined_. Management is told, “Go figure out your new role” or simply “Stop micromanaging”. They are often still responsible for the outcomes, yet are stripped of authority. It turns out managers are people too - and their treatment is often inhumane and unhelpful for creating lasting change. Managers were seen as the glue that holds an organization together … now what happens? How can we all journey together?

    We offer an alternate view, where Agile Transformation is understood as an evolution of organizational culture. Success depends on shifts in the behaviours of both staff and management. The Agile Mindset or Being Agile is a prerequisite for making structural changes. Jumping to advanced stages of evolution where there is high autonomy is a painful trap. An incremental and iterative (Agile) approach to shifting power away from managers to individual contributors is more effective.

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Ayumi HOSOZAWA / Etsuo Yamada / Masashi Arino / Miho Nagase / Minoru Yokomichi / Misa Takeba / Teppei YAMAGUCHI / Yamato Naka - Afternoon Mingle

    45 Mins
    Workshop
    Beginner

    Let's mingle and create "Ba" together!
    In this time slot, the organizers of Regional Scrum Gathering Tokyo will do a brief workshop to create "Ba" for Agile practitioners. You can meet new people, make new friends, connect with Agile community members from a lot of countries.

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?

    20 Mins
    Talk
    Intermediate

    現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか?」というものです。

    このような話題の時、OutputとOutcomeの話をします。

    • Outputとは、リリースした機能の数や質のことをここではいいます。
    • Outcomeとは、利用者がどう変わったのか?利用者の課題が解決したのか?と利用者視点での効果のようなことをいいます。
      • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。

    たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

    1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
    また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。


    プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)



    このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
    みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!

    Alex Sloley
    Alex Sloley
    Alex Sloley
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

    Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

    And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

    Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

    Join the fun and come learn what horrifying results await!

  • 中村 薫(Kaoru Nakamura)
    keyboard_arrow_down

    中村 薫(Kaoru Nakamura) - 10年たってやっとアジャイルがわかりかけてきた話

    中村 薫(Kaoru Nakamura)
    中村 薫(Kaoru Nakamura)
    CEO
    HoloLab Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。

    2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

    このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術

    20 Mins
    Talk
    Beginner

    世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
    アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
    アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

    一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
    これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。

    本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki / 河野 彰範 - アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り

    45 Mins
    Talk
    Beginner

    ふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
    昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

    2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

    古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
    そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
    実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

    このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
    取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
    地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

    • アジャイル組織の変遷
    • 現行ルールのしがらみとの闘い
    • アジャイル開発を少しずつ組織に浸透させていく方法
    • 組織を拡大していくための対内・対外的な取り組み
    • 拡大していく組織で発生した問題
    • 成果を出し続けていくための組織やチームの意識改革
  • Hiroyuki Ito/伊藤 宏幸
    keyboard_arrow_down

    Hiroyuki Ito/伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 -

    45 Mins
    Talk
    Intermediate

    我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。

     
    一連の活動に際して我々は、様々な技術・ツールとアジャイルプラクティス・マインドセットとを組み合わせ、日々実験を繰り返しながら、ビジネス的成果へとつなげています。
     
    当セッションでは、特定の開発チームから組織横断活動までに活用できる、技術とアジャイルの組み合わせ方を、LINEでの実例をもとに、参加者の皆様が現場に持ち帰って試せる形でご紹介します。
    また当セッションは、SETチームをこれから作ろうとされている会社・担当者の皆さま向けの具体的なアプローチ集とすることも想定しています。

  • Arissa Nakamura
    keyboard_arrow_down

    Arissa Nakamura - キャリアパス考察:開発者と動くQAテスターからチーム支援するスクラムマスターへ

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

    CI&Tではスクラムマスター(以下SM)のキャリアパスは通常テスター役から始まります。

    テスターは開発者達と日々タスクを実施するので、開発の流れ、プロダクトの使い方、技術などについて良く知ることができます。

    しかし、SMはプロジェクトマネージャーやプロジェクトオーナーと仕事をすることが多いのでどちらかというと「マネージメント」グループに含まれており、ビジネス要件にしか深く関わることができません。多数の案件を管理するようになると、チームが実際何に困っているか簡単に気づいてあげられない時もあります。

    お客様と開発チームとの関係性をより良くするためにはどうすればいいのか。
    どちらにも偏らないように、どうすればバランスを保つことができるか。
    テスターとして積み上げた知識はSMになった私にどう役立ってるのか。

    現在勤めてるプロジェクトの経験も通して、テスターからSMになって感じた変化についてお話したいと思います。

    On CI&T, people who are willing to become Scrum Master (SM) usually starts the career path as a Tester.
    The tester works daily with the developers so they are able to follow the development process closely, they are able to know a lot about the product itself and all the technologies involved.

    However the SM works closer to the Project Manager and the Project Owner, which makes the role to be considered a "management" type. Also, the SM is only able to have deep knowledge about business requirements, since they need to manage several kinds of subjects at the same time. The multi-tasking makes it hard for the SM to realize what are the real needs of the team sometimes.

    As a SM, what can I do to improve the relationship between the team and the client?
    How the SM should keep the balance between negotiate team advices and PO requests?
    How my experiences as Tester can help me as SM?

    I'd like to share my experiences on this transition from Tester to SM, and my project.

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - チームの再定義 -進化論とアジャイル-

    kyon _mm
    kyon _mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    チームの再定義 -フラクタルスプリントとフラクタルチーム-

    1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

    私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

    異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

    そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

  • Sam Huang
    Sam Huang
    Scrum Master
    Titansoft
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    After we adopt Agile and Scrum in 2014, we found there are more and more communications for product development and team development.

    To make our communication more effective, we invited experts to conduct facilitation training to our staff to improve efficiency and quality of our communication in early 2016.

    However, the following challenge is the implementation of organizational tasks
    related to recruitment, training and public affairs were easily neglected after facilitation process.

    Facing this challenge, the next thing we tried is the framework of Sociocracy in 2017.
    The circle structure and double-linking formed, and driving the execution of organizational tasks.

    (Complete story of Titansoft's experiments from Agile to Sociocracy is in the book BOSA nova, sharing by Yves Lin)

    During the try of Sociocracy, I took part in facilitating the election of roles for circles, and experienced Sociocracy’s impact on us.

    In this talk, I will share some basic idea of Sociocracy, the practices we have tried, and the impact of this try in our Scrum teams.

  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

    45 Mins
    Talk
    Intermediate

     アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

    軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

     しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

     チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

    制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

    軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

  • Tomoharu Nagasawa
    keyboard_arrow_down

    Tomoharu Nagasawa - Going Agile with Tools - たまにはツールの話もしようぜ

    20 Mins
    Talk
    Intermediate

    English follows Japanese.

    ---

    アジャイルな開発においては、アナログなツールもデジタルなツールも大切な活動のための友達です。

    このセッションでは、アジャイルもテクノロジーも成熟してきたなかでうまれ、乱立されてきたデジタルなツールについて、基本に立ち返ってどんなツールが求められているか、どんなツールをあなたの現場で選べばいいのかを考察していきます。

    せっかく使うツールならば自分たちのための、自分たちの創り出す価値のためのものを選びましょう。

    ツールから学ぶバリューチェーンのような内容にするつもりです。

    なお、本セッションでは特定のツールにフィーチャーすることはありません。

    ---

    It is important to become friends with tools (both analog and digital) as Agile team. In this session, I will consider about digital tool(s) following points of view returning to the basics.

    • What tool(s) are needed with Agile
    • What tools(s) should you choose at your Agile team

    I will share to learn "flow of value" from tool(s) with you in this session.

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - Team-Based TEAM - 会社を越えるチーム -

    45 Mins
    Talk
    Advanced

    あなたのチームはいつ死にますか?

    スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM(安定したチーム)」はScrum Patternsの1つになっています。

    安定したチームは本当によいチームなのでしょうか?

    私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

    私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM(安定したチーム)」はSAME TEAM(同じチーム)ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

    あなたのチームはいつ死にますか?

    このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Jean-Baptiste Vasseur / Kazunori Otani / Kenta Sasa - スクラムの理解を深めるスクラムショーワークショップ

    100 Mins
    Workshop
    Beginner

    スクラムショーワークショップは、スクラムの説明をショー(寸劇)形式で行うワークショップです。
    このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

    スクラムショーワークショップは、yycr2019(アジャイルコーチとスクラムマスターの宴、通称:よなよなコーチングリトリート)
    生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
    会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

    皆さんも、スクラムショーワークショップを実施してみましょう!

    紹介動画はこちらから!

    詳細はこちらの記事をご参照ください。

  • Tetsuya Tarumoto
    keyboard_arrow_down

    Tetsuya Tarumoto - アジャイルUXリサーチLive! ~ 「即席」ユーザーテスト見学会

    Tetsuya Tarumoto
    Tetsuya Tarumoto
    代表
    利用品質ラボ
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    UX屋さんは言います「ユーザーテスト(ユーザビリティテスト)は製品の利用品質を目覚ましく向上する」と。でも、専門家に頼むと結構な金額の請求書が届くかもしれませんし、社内でやると結構な手間がかかるかもしれません。結局、まだ「やったことがない」「見たことがない」という人が多いのかもしれません。

    そこで、このセッションではスマホアプリを題材にしたユーザーテストを会場で実演します。「実演」と言っても大げさなものではありません。①その場にいる人で、②その場にある機材を使って、③約30分で完了する(ただしセッションは45分)ーーという「即席」スタイルです。

    「UXとは?ユーザーテストとは?」という小難しいプレゼンテーションを聞いたり、その分野の本を読んだりするのも悪くありませんが、まずは自分の目で見て、自分で価値を判断してみてはいかがでしょうか。意外と気に入るかもしれませんよ。

  • Matteo Carella
    keyboard_arrow_down

    Matteo Carella - ORGANIC agility®: an evolutionary approach to organizational resilience

    Matteo Carella
    Matteo Carella
    Agile Coach
    Agile42
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Today market cycles are rapidly shortening and there has been a shift in focus from agile at the team level to agility within the organization as a whole. That's why today to survive organizations needs to be adaptable, flexible and resilient. This is the purpose of ORGANIC agility® that is both an acronym and a metaphor that suggests a natural and biological context. The core concept behind the approach (developed by Agile42 working with hundreds of companies around the world) is to shift the paradigm of organizational design thinking and change management away from the engineered or manufactured, towards something that grows and evolves naturally.

    As every organization is different, the practices and operational tools that will emerge while applying the principles might be considerably different from one to the others. ORGANIC agility is based on 5 Principles that enable organizations to evolve to a more resilient state, in order to avoid a reorganization every 2-3 years or coping with scaling frameworks in order to survive in uncertain and volatile market. In this talk we'll explore the 5 principles behind in order to promote and sustain an emergent and genuine change within your organization.

  • Ikuo Suyama
    keyboard_arrow_down

    Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum

    Ikuo Suyama
    Ikuo Suyama
    Engineer
    CyberAgent
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Advanced

    はじめに

    本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません
    アジャイル開発における見積りについては「アジャイルな見積りと計画づくり」という素晴らしい書籍でその有用性や有効な実践方法が示されています。

    ここで、あえて問わせていただきます。

    「あなたのチームの見積りは、どれくらい正確ですか?」

    前回の RSGT 2019 Key Note において、 Chris Lucian@christophlucian 氏は #NoEstimates のコンセプトと、見積りのコストについて言及しました。
    彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。

    私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。
    以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

    この私達のプロセスでは、モブプログラミングが鍵となっています。

    本セッションでは、私達がどのように見積りをせず開発をしているのか、見積りをやめたチームで何が起こるのか、という事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

    見積りの負の側面と価値 - なぜ見積りをやめたのか

    少し見積りの負の側面について触れておきます。
    私達が考える見積りの負の側面は、以下に集約されます。

    • 見積りのコスト
      • 見積りを行うためにかかる時間
      • 数値化したことによる、納期コミットの圧力
      • 数値化したことによる、仕事量の最大化(パーキンソンの法則)
    • 見積りの難しさ
      • ソフトウェア開発はそれ自体が複雑で不確実性を含む
      • 殆どの場合で経験したことがないことへの対応が必要になる
      • このため、正確な見積りを行うことが困難

    もちろん、見積りは負の側面ばかりではありません。
    しかしながら、見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。

    • 見積りの価値
      • 見積りから得られる計画
      • 共通理解の促進
        • e.g. プランニングポーカー

    見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。

    スクラムと見積り

    タイトルの通り、私達はスクラムを実践しています。

    見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。

    スクラムガイドには「見積り」という言葉が9回登場します。
    それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

    • 計画づくり
      • PBIの優先順位付け
        • ROIの ‘I’ の算出に必要
      • スプリントのキャパシティを測る
    • 追跡
      • スプリントの進捗状況を把握する

    見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。

    我々は、以下の方法でこの意思決定を行っています。

    • PBIの優先順位付け(ROIの ‘I’)
      • PBIのサイジング
        • 直近2Sprint分のPBIはすべて1スプリント以下のサイズに調整
      • CD3(Cost of Delay Divided by Duration) による優先順位付け
    • スプリントキャパシティ&追跡
      • モブプロによるWIP制限
        • 安定性・予測可能性の向上
      • 過去データからの ‘予測’
        • タスクのサイクルタイムをヒストグラム化
        • タスクカウントとスループット

    まとめ

    Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
    見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

    私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

    AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念かもしれません。
    我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。