location_city Tokyo schedule Jan 5th 02:00 - 02:45 PM JST place 1F Room B (48) people 18 Interested

Last April, when Covid-19 began to rage, I became Head Of Engineering (VP). I didn’t know if I was accepted by everyone or not, if I was welcomed by everyone or not. There is a huge difference between moving from a physical environment where trust and relationships can emerge easily to a remote environment in which trust and relationships are more difficult to put in place. Moreover in a remote environment the cognitive effort to solve problems it’s even higher. In this session, we will talk about what we have learned managing an engineering organization in the last pandemic year, in a remote setting. We’ll explore the challenges and failures we faced and our path to improvement, as well as the development process and organizational development efforts with Matteo, who joined us as an Agile Coach. COVID was a very disruptive event that changed the worldwide way of working forever but thanks to company resilience and fast ability to adapt and change we were able to reduce the impact of some organizational issues. This is a story about how our company culture helped us to face difficulties, meanwhile our journey towards agile values, principles and practices is still proceeding.

Covid-19が猛威を振るい始めた昨年4月、私はHead Of Engineering(VP)に就任しました。自分がみんなに受け入れられているかどうか、歓迎されているかどうかはわかりませんでした。

信頼や関係が生まれやすい物理的な環境から、信頼や関係を築くのが難しいリモート環境に移るのは大きな違いです。さらに、リモート環境では、問題解決のための認知的な努力がさらに必要になります。このセッションでは、昨年のパンデミックの際に、リモート環境でのエンジニアリング組織の運営について学んだことをお話しします。

アジャイルコーチとして参加してくれたMatteoとともに、直面した課題や失敗、改善への道のり、開発プロセスや組織開発の取り組みなどを紹介します。COVIDは、世界の働き方を一変させる非常に破壊的な出来事でしたが、会社の回復力と適応・変化するための迅速な能力のおかげで、いくつかの組織的な問題の影響を軽減することができました。

これは、私たちの企業文化がいかにして困難に立ち向かうことを助けたかという物語であり、一方で、アジャイルの価値、原則、実践に向けた私たちの旅は今もなお続いています。

 
 

Outline/Structure of the Talk

  • Company presentation and agile teams structure
  • the VPoE’s mission
  • How COVID19 impacted our organization disrupting our plans
  • Impact on people, impact on product, impact on organization
  • How Wealthpark quickly responded to change over following a plan
  • How we tackled challenges
  • How we leverage on opportunities
  • The cognitive impact of remote working
  • Difference between in presence and remote working, challenges and opportunities
  • Trust building in a remote environment

Learning Outcome

More companies are nowadays moving in a remote or hybrid setting (physical-remote), so the number of situations in which people will build relationships from scratch remotely, will increase even in Japan in the future. We hope this talk will be useful for all the people and companies that are reconsidering or will be forced to reconsider their way of working.

Target Audience

Managers, Scrum Masters, Executives, Team members, Product Owners

Prerequisites for Attendees

None

schedule Submitted 1 year ago

  • Tsuyoshi Ushio
    keyboard_arrow_down

    Tsuyoshi Ushio - アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話

    90 Mins
    Keynote
    Beginner

    世の中、さまざまな陰謀論やフェイクニュースが世間をにぎわしています。Scrum をはじめとしたソフトウェア開発の考え方、世界的に有名なサービスやツールの多くはアメリカから排出されています。ですので、「ソフトウェアの先端の国はアメリカである。」というイメージを持たれている方も多いかもしれません。

     

    … で、本当のところはどうなのよ?

     

    そこで、元アジャイルコーチの私が自ら、ガチ三流プログラマとして米国に移住して米国の超巨大クラウドのサーバーレスプラットフォームの中の人になってみましたので、アメリカのシステム開発の本当のところを、皆様から多くいただく質問に答える形でシェアしてきたいと思います。

    秘密さえ知れば、恐れるに足らず!日本を最高にソフトウェアに強い国にするための一歩を一緒に踏み出してみませんか?

    こんな質問に答えてほしい!というリクエストがある方は twitter @sandayuu までお知らせください。

  • Diana Larsen
    keyboard_arrow_down

    Diana Larsen - Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model

    90 Mins
    Keynote
    Intermediate

    Approaches to leading software development rely on building trust in team skills. Reciprocal trust between leaders and teams contributes to employee engagement and higher performance. Both are key to business success. Skilled, collaborative teams assume responsibility for the results they produce. To engage teams, leaders communicate the strategic purpose and enable growth. Leaders have a role as coaches to ensure that team members fully align on the product or service "why". By unleashing the potential of skilled agile teams, leaders can accelerate learning loops, create customer-oriented missions, and provide increased value for their organizations. But first, leaders can only impact teams if they are open to change themselves. 

    In this keynote talk with Q&A, Leading Skilled Agile Teams, Diana Larsen will lead participants to examine the role of trust, team member engagement, and investing in team outcomes. Leaders will consider ways for communicating purpose and expectations for teams. Each leader will draft a brief plan for enabling better outcomes from skilled teams. And, we’ll include plenty of time for asking questions. 

     
  • Johanna Rothman
    keyboard_arrow_down

    Johanna Rothman - Agile Program Management: Scaling Collaboration Across the Organization

    90 Mins
    Keynote
    Beginner

    Your product requires several teams working together. But most of the scaling frameworks add control points, which create hierarchy and less collaboration. You don’t need a framework to release a complex product. Instead, organize the work to remove the barriers to collaboration. You can create an effective agile and lean program to create and release products your customers want.

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - プロダクトバックログ Deep Dive

    45 Mins
    Talk
    Intermediate

    プロダクトバックログのすべてを完全解説!!

    スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。

    スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います(それはそれで素晴らしい)。

    一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。

    本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

     

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

    2012年、新たな著作のタイトルが "The Battle" だと知った時、すごくがっかりしたのを覚えています。あれだけ分割しても理解できないと主張していたのに、システムA、システムBにように分断するのかと。

    それから10年がたち、パタンランゲージとしてのスクラムも世に出すことができたところで、スクラム・アジャイルにとっての The Battle とは、何だったのか、何なのかを考えてみたくなりました。

    Agile Manifesto が発表されてから、アジャイル・スクラムはずっと対立軸の片側として語られてきました。アジャイル開発が一般的に使われるようになり、スクラムが最も利用されるフレームワークとなったとき、The Battle は終わったのでしょうか?それとも、まだ別のシステムが存在するのでしょうか?

    ここまでの状況をふりかえりながら、現在のアジャイル・スクラムの場所を確かめてみようとおもいます。

     

     

  • Ryo Tanaka
    keyboard_arrow_down

    Ryo Tanaka / Takao Utsumi - インプロヴィゼーション:ふりかえりの新世界

    45 Mins
    Talk
    Advanced

    ※ インプロヴィゼーション(improvisation) = インプロ、または即興演劇

     

    私はアジャイルコーチとして数々の現場・チームを見ていく中で、ふりかえりに対してマンネリ感を覚えるようになりました。

    スクラムにおけるレトロスペクティブをはじめ、ふりかえりの時間は確保されるようになってきたと感じる一方、多くのふりかえりでは次に向けたアクションアイテムが近視眼的なものになり、長期的な行動変容を中々起こすことができていないように感じました。

    そんな時、インプロに出会い、インプロバイザーの方々と話をする機会が訪れました。そして、インプロがもたらす、行動変容に対する強力な刺激・数々のプラクティスが生み出す高い熱量に触れ、大きな驚きと感動を覚えました。
    そして、インプロの実践やアジャイルのコラボレーションを重ねていく中で、これまで感じていた頭打ち感を振り払うようなふりかえりが生まれていきました。

    一方、インプロを実践するインプロバイザーも、アジャイルやシステム・シンキングの考え方に感動を覚えていました。インプロにおけるふりかえりにアジャイルやシステム・シンキングの考え方を取り入れ、インプロにも変化が生まれていきました。

    本セッションでは、アジャイルとインプロのコラボレーションの様子を実際に見ていただき、コラボレーションの結果生まれた誰もが予想したことのないようなふりかえりの話を紹介したいと思います。

     

    インプロバイザー:内海隆雄より

    「計画に従うことよりも変化への対応を」――アジャイルの考え方に出会って僕が思ったのは「これはインプロのことか!」でした。インプロは即興を意味するImprovisationの略です。そしてImprovisationの語源はIm(しない)+pro(前もって)+visation(見ること)すなわち「前もって見ることをしない」ことを意味します。

    先の分からない世界でいかに振る舞うかについて、インプロは愉快に教えてくれます。このセッションではその一端と、アジャイルやシステム・シンキングとの出会いによる変化についてもお話できればと思います。

    ----

    このプロポーザルは aki.m さん協力のもと作成されました。ありがとう!

  • C.J. Hostetter
    C.J. Hostetter
    Head of Design
    yamaneco
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    「アジャイルとデザインは絶対にうまくいかない。」アジャイルに関するなスタートアップに入社する前、私はこう考えていました。それまでのエージェンシーやプロダクトデザインの経験とは全く異なるものだったからです。

    yamanecoで働いた3年間で、革新的なアイデアを実現するためには、デザインにとってアジャイルの助けは必要だと学びました。アジャイルもまた、ビジネス上の必要性に留まらず、ユーザーのニーズに合った製品を作るためにデザインの助けがいることを学びました。私の成功、失敗、そして学びを皆さんと共有したいと思います。

    “Agile and design will never get along.” This is what I thought before I joined an agile startup, completely outside of my previous agency and product design experience. In the three years working at yamaneco, I have learned that design needs help from agile to make innovative ideas real and agile needs help from design to make products that fit a user need, not only a business want. Let me share my successes, failures and learnings with you.

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか

    45 Mins
    Talk
    Advanced

    プロダクトには価値はあり、だからこそ顧客は利用している。しかし同時に副作用も生んでいる。

     「最高のプロダクトを作ろう」とはじめたのに、いつのまにか「最高の利益を上げよう」という会社になっていた。顧客の悩みに寄り添っていた私たちが、今では顧客のサイフばかり気にしている。

     

    最高のプロダクトを目指していたのにブルシットプロダクトになっちゃった!

    この10年でUXデザインや、ユーザーストーリーマッピング、デザイン思考といった顧客理解の知識や技術が普及してきました。しかし、顧客を助けるふりをして、巧みにつけ込むようにみえるプロダクトはたくさんあります。

     パッケージや広告だとプロダクトはめちゃくちゃステキ。ところは実物が届いたらひどいものだった。コレジャナイ感がすごい。

     サービス加入は簡単なのに退会は困難を極める。入会はwebフォームから簡単にできるのに、退会するには迷路。くぐり抜けてやっと退会できるかと思ったら、電話をするほかなく、電話はいつかけても混雑中で先に進まない…。

     サービス契約前は大量の広告や案内が届くのに、サブスクリプション契約したら一切届かなくなり、契約自体を忘れてしまった。気づいたらお金は払い続けているのに全く利用せずに数年たっていた。

    これらはあからさまなものです。しかし、ユーザーの立場でみてみると、プロダクトを利用する中で違和感を覚える場面はあふれています。スマホにアプリをダウンロードし、いくつかの入力を済ませ、いざ利用開始というタイミングで利用規約にサインをさせる…そんな不意打ちです。ユーザーの頭の中ではすでにサービスを利用している気になっているので、複雑な規約に向き合える気持ちにはなれないでしょう。

     


    「顧客が本当に必要だったもの」の継続は難しい

     はじめは顧客に寄り添って「顧客が本当に必要なもの」を届けられていたのに、長く開発しているうちに寄り添わないことが起きはじめた。「顧客の○○さん」というように一人ひとり名前が付いていた顧客が、1人2人と単なる数字で管理するようになり、顧客の声が遠くなった。昔はクレームが届けば顧客の意見をヒアリングしにいったのに、今では一律定型文を返すようになっていた。いつのまにか黙らせることがうまくなっていた。

     プロダクトが顧客に受け入れられるにつれて売上は伸び、企業規模は大きくなる。規模が大きくなるにつれて、資金に余裕ができ、才能が集まりやすくなる。本当なら素晴らしいことがもっと成し遂げられるようになるはず。にもかかわらず、以前と比べて価値を生み出せなくなったように感じる。

    素晴らしいプロダクトを生み出すのは難しいことですが、素晴らしさを続けていくことはもっと困難です。業務を効率化したり、企業の大規模化にともなって、「顧客が本当に必要だったもの」を生み出す力は少しずつ阻害されていきます。

     

     

    あるプロダクトの急成長物語

    顧客を助けようとする情熱からプロダクトが始まったとしましょう。顧客とヒアリングしたり、開発を続ける中で、チームは豊かな体験をします。プロダクトがリリースされ、顧客に「これが欲しかったんだ!」と熱烈に歓迎され、顧客が殺到します。プロダクトがヒットしたのです。

    すると、増えた顧客から顧客対応や新たな要望がどしどしよせられるようになります。チームはてんてこ舞いです。また手強い競合が参入し、競争が激化します。圧倒的な人手不足から採用に取り組み始めますが、これまでのチームの仕事は属人化し、またそれまでの経験がなければ分からなくなっていました。

    ぐちゃぐちゃな仕事を整理して、分割して、分かりやすくします。新しく入ってきた人でも即戦力になれるようにするためです。手分けして仕事に当たれるようになりました。このようにして混乱した状況に秩序をもたらし、急成長の痛みを乗り越えたのです。

     

     「この仕事は何のためにあるのか分からないが、やることになっている」

    即戦力でも活躍できるように、手分けができるように整理されてコンパクトになった仕事とはいったいどのようなものでしょう。プロダクトのほんの僅かな部分しか担当していないため、プロダクト全体のことはわかりません。プロダクトオーナーは何をしているのか、営業は顧客から何を言われているのか、広報はどのような狙いを持っているのか、おぼろげにしか見えません。これを細い経験と呼びましょう。

    一方で、プロダクトを成長させたプロダクトオーナーやチームは、その貴重な経験を活かせるように、さらに重要な仕事に携わるようになります。これを太い経験と呼びましょう。

    経験という側面から考えてみます。組織には、分担された仕事による細切れの経験の大勢の人と、稀少な経験を重ねるごく僅かな太い経験の人という分布の偏りが生じるということです。貴重な太い経験をもつ人は、売れっ子の新人女優のように次々と新たな役に恵まれて、さらに豊かな経験をします。細い経験の人はそうではありません。

    さらにプロダクトは急成長したとしましょう。一度手分けされた仕事はさらに分けられ、もはや元々がどのような仕事だったのか分からない人もたくさんでてきます。どんどん細分化が進み、部門は管理しやすいように縦割りが進んでいきます。業務効率化が促されるようになり、サポートでは手早く顧客の問題を解決したことにするため定型文を返すようになる…かもしれません。

     

     

     「いざ改革」に乗り出すも…

    このような状況で、危機を覚えた初期の優秀なチームは、顧客の声が遠くなったことや縦割りが進んでいることを理解しています。そこで部門を横串する「ユーザー中心チーム」や「○○経営組織」が発足し、改革を担うようになります。

    さて、もう一度、体験の分布を考えてみましょう。僅かな太い体験と、大量の細い体験の二つがありました。「ユーザー中心チーム」や「○○経営組織」という改革の取組はどのような影響を与えるでしょう。是正するでしょうか、それとも強化してしまうでしょうか。

     


    「顧客が本当に必要なもの」を追求しつづける

    ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。

    このセッションでは、ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。

     

    目次
    ブルシットプロダクトとは何か
    ・ブルシットプロダクト
    ・顧客につけ込むダークパターン

    組織システムは何に自己組織化しようとしているのか
    ・分業の功罪
    ・太い経験と細い経験
    ・負の自己組織化
    ・官僚主義や大企業病は自己組織化の双子
    ・ブルシットプロダクトマネジメント
    ・負をマネジメントする

    顧客を助けるプロダクト組織へ
    ・顧客を助ける
    ・顧客の能力を高める
    ・無知/無能/無関心から、知ってる/できる/当事者意識へ

  • 45 Mins
    Talk
    Intermediate

    In order to change an organization, leaders have to change first. Be one of them and turn your organization into a successful Agile organization.

    In today’s complex, fast-changing, and unpredictable world, radically agile organizations thrive when they combine strong local autonomy with deeply shared goals. Leadership is a key factor―individuals who welcome complexity and know how to leverage influence, culture, and organizational design to align widely distributed teams are integral to success.

    Let's hear a few stories from forming an agile organization. 

  • Tomoharu Nagasawa
    keyboard_arrow_down

    Tomoharu Nagasawa - プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か?

    20 Mins
    Talk
    Beginner

    『スクラムガイド』2020年11月版より登場した「プロダクトゴール」。ガイドによれば、以下のように説明されています。


    プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットとなる。(中略)プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。(後略)


    ここでだけみても非常に重要なゴールであることがわかります。しかしながら、自分たちのプロダクトにとってのゴールを具体的に設定するには、考慮すべきパラメータが多いのではないかという印象をどうしても受けてしまいます。それでいてあらかじめ決められた目標や予算、期日にロックオンされ、有名無実なプロダクトゴールにならざるをえなく、建設的なプロダクトゴールを諦めてしまっていないでしょうか。はたまた硬直化したプロダクトゴールは経験主義と矛盾した概念や結果につながりかねず、従来思考の経営者やマネジメントへの誤解の元にもなるという議論も積み重ねてきました。

    このセッションでは、「プロダクトゴール」を解説しつつ、できるだけ具体的で成果につながるプロダクトゴールを設定するために、アジャイルコーチが支援先でも共に取り組んでいる「エビデンスベースドマネジメント」を用いたプロダクトゴールの設定と達成(あるいは放棄)についての考察を共有します。


    エビデンスベースドマネジメント(EBM)とは
    EBMは、組織が不確実な条件のもとで顧客の成果や、組織の能力、ビジネスの結果を継続的に改善するために役立つ経験的アプローチです。組織が価値を提供する能力を向上させ、戦略的ゴールに向けた道筋を模索するための経験主義に基づくフレームワークで、Scrum.orgによって考案されたものです。


    セッションの提案するために書いたポンチ絵:

    ProductGoalwithEBM.png

    ThePathToMoreEffectiveAgileFull2.png

    このセッションで取り扱わないこと:

    • 正解・正答(考察セッションです。正解は聞いていただき、実践の中で見つけてください)
    • プロダクトバックログの作り方
    • エビデンスベースマネジメント(EBM)の自体の詳細解説
  • Kazuhide Inano
    keyboard_arrow_down

    Kazuhide Inano - あなたのSprint Goalは、機能してますか?

    Kazuhide Inano
    Kazuhide Inano
    Agile Coach
    JEI LLC
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラム実践者のみなさんこんにちは。
    唐突ですがタイトルのとおり、ひとつ質問です。

    「あなたのSprint Goalは、機能してますか?」

    さて、どんな答えが返ってくるのでしょう。「何それ?」「まだ活用できてないなぁ」「一応設定してるけどね」「当たり前じゃん」などなど、いろいろありそうです。

    そもそもですが、スプリントゴール自体は過去のスクラムガイドでも記述されており特に目新しいものではありません。ただスクラムガイドがアップデートされるに伴い、より強調されてきているように見えます。そしてスクラムガイド2020においては作成物に付随するものとしてではなく、「スプリントの価値・目的を表すステートメント」や「スプリントバックログの確約(コミットメント)」として明確な位置付けがされています。

    私は外部のアジャイルコーチとして今までいろんなスクラムチームに関わってきました。その経験の中で感じていることとして、スプリントゴールの扱いに苦慮しているチームが多かったということが挙げられます。みなさんはいかがですかね?

    そこで、このセッションでは今まで私が見て来たスプリントゴールをケーススタディとしつつ、意義や効果あるいは実際に活用するための勘所はどこかを整理・深堀りし、スクラムチームの活動により一層の効果をもたらす「機能するスプリントゴール」とはどのようなものかを探求してみます。

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - その開発計画は最初から間違えている! - アジャイルにおける開発計画の考え方について

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    新しいプロジェクトへの参画が決まると、開発計画書を見せていただくことになります。私は、ファイルを開いてから、わずか 3 秒でそっと閉じ、溜息と共に瞑想に入ります。「ふぅー。いつも通り、間違った開発計画だな。さて、今回はどんな作戦で進めてゆこうか…。」

    さて、多くの開発プロジェクトの現場では、たいていのマネジャーが "プロジェクトが計画通りに進まない!" と嘆いています。そんな現場では、必ず "アジャイル用語を使った行き当たりばったり開発" で進められていて、しばらくして進捗が問題になり、増員して、残業して、段階的リースをすることになります。そして、開発メンバーが入れ替わり、ナレッジが失われたプロジェクトは、二次開発以降の開発コストが高騰する道を歩むことになります。"ここまでテンプレ" ってやつです。誰しも、既視感がありますよね?

    違う現場なのに、なぜ、みんなこうなるのか? その理由は簡単です。 "開発計画が間違っている" からです。順調に進まない開発プロジェクトは、開発計画の時点で、既に同じ間違いを犯しています。おもしろいほどに。

    このセッションは、開発計画がどう間違っているのか? なぜ間違えてしまうのか? の解説から始めさせていただき、どのような計画を立て、どう運用してゆくのが望ましいのか? まで、その考え方をお伝えしたいと思います。

    そうそう、 "アジャイルはスプリント分しか見積もりしないんでしょ?" とか "アジャイルは計画しないんでしょ?" といったような誤解も解けると思いますよ。 :-)

  • Shusuke Fujii
    keyboard_arrow_down

    Shusuke Fujii - 非ITの宿泊業なのに、なぜDXを推進できるのか?

    Shusuke Fujii
    Shusuke Fujii
    Hotel
    Hoshino Resorts
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    宿泊業である星野リゾートは、従業員の多くは、接客中心の職場であるが、ITへの関りは少ない。

    そのようなITとの関りが少ないイメージの強い企業の星野リゾートはアジャイル開発を促進し、多くの成果を上げることで、DXを推進する企業として認知され始め、宿泊業界に厳しいコロナ禍でも躍進を続けている。

    非IT組織においてアジャイルを推進するのはも簡単ではないと思われるかも知れない。しかし、星野リゾートではアジャイル開発に向いている組織文化を長年続けており、そのエッセンスをうまく活用することで、アジャイル開発を実践し、DXを推進する企業としての成長を図ることができている。

    本セッションでは、アジャイル開発を下支えする組織文化とその取り組みについてお話します。

  • Tomonori Sano
    keyboard_arrow_down

    Tomonori Sano - スクラムチームとアジャイル開発ガイドライン

    20 Mins
    Talk
    Intermediate

    【重要】ラグビーの話は一切しません。

    スクラムが組織内で広がる際に、アジャイル開発標準のようなルール作成を検討したことがある、もしくは作成したという組織は多いのではないでしょうか。

    個別のチームではスクラムガイド+αで十分だったものが、組織が大きくなるにつれ、標準化や効率化を目的としてルールを制定したくなります。その際に、アジャイル開発標準ガイドラインのようなドキュメントが作成されることになります。

    一方で、策定したルールをドキュメント化したものの、読まれない、更新されない、作って終わりのような残念な結果にもなりがちかと思います。

    本セッションでは、私が所属するKDDI DIGITAL GATEで作成し2年間運用され続けているルールを、ドキュメントをお見せしながら、何を書いて、何を書かないか、どのようなルールで書いているかをお伝えしたいと思います。

     

    大事な事なので、ラグビーの話は一切しません。

  • Hiroyuki Ito
    keyboard_arrow_down

    Hiroyuki Ito - 社内アジャイルコーチの卒論: 9年間の多くのしくじりと、いくばくかの成功を添えて/Messages from Ex-Internal Agile Coach

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

    English follows Japanese.

    私は2013年から、自社サービスを展開する事業会社で、社内アジャイルコーチとして活動してきました。

    チームビルディングから、開発生産性向上のための(テスト自動化・DevOpsなどの)技術支援、新規プロダクトの共創、さらには経営層を巻き込んだ組織改革と、活動範囲は多岐に渡りました。そして、多くの失敗と、いくつかの成功とを重ねてきました。

    この度、社内アジャイルコーチを辞めるにあたり、改めてこれまでの活動結果およびそれらの自分なりの分析結果とを整理し、社内/外のアジャイルコーチ、および同世代/次代のアジャイル実践者へ提供することが、自分を育ててくれたアジャイルコミュニティへの貢献になるのでは?との考えに至りました。

    そこで当セッションでは、特に事業会社の社内アジャイルコーチというコンテキストで、自身が悩み、試し、伝える価値があると判断したものを、特にチーム・技術・組織の3点から整理してお話しします。

     

    I had worked as an internal Agile Coach in several internet service companies since 2013.

    I had done a wide variety of activities such as team building, implementing technical foundations for enhancing developer productivity, founding totally new products, and leading organizational changes with the management. There were lots of failures, and some successes.

    I convince that sharing ideas and knowledge earned through the experience of those my internal Agile coaching activities will contribute to the Agile community.

    In this session, I will talk ideas and knowledge earned through my internal Agile coaching activities from 3 aspects like 1) team, 2) technology, and 3) organization.

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - (スクラムやアジャイルを)よく学びよく試行錯誤する~継続して学び現場に持ち帰るために~

    aki matsuno
    aki matsuno
    engineer
    -(Coming Soon)
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムの実践を通して叶えたい未来を実現することは、場合によっては途方もない道のりに思えるかもしれません。
    特に、経験がなくて支援者や経験者が少ない状態でスクラムを学ぶというのは、中々ハードルが高いのかもしれないと個人的には思っています。

    自分の場合は、プロダクトやチームをより良い方向に進めたいという想いからスクラムを始めましたが、何も分からない状態で闇雲に学び始めたこともあり、多数の悩みにぶち当たることになりました。(本に書いてあることがなかなか実践できない、自分のやりたいことを強引に押し付けをしているだけな気がする、コミュニティやカンファレンスに参加するもどこか遠い世界のように感じられて今一つ学びがない気がする...)

    そんな中、今の自分にできることを探し、500回近くのコミュニティに参加したり、400本近い本数のセッションをカンファレンスで聴いたり、読書をしたりして少しずつ学び、学んだことを現場や自身の日常で実践し、社内外問わず多数の皆さんに支えてもらいながら日々試行錯誤をしていきました。

    そうして少しずつ歩みを進めてきた結果、チームの空気やデリバリーまでのプロセス、顧客との関係性...が確実に変化していきました。
    また、自分自身少し不思議な感じがしますが、自分が大事にしたかったものが徐々に思い出されるような感覚を持つようになりました。

    本セッションでは、自分がスクラム/アジャイルを中心に1年間学びを加速し続けられたのはなぜか、コミュニティやカンファレンスといった学びの場をどのような過程を経て現場に適用していったのか、といった話をすることで、現場をより良くしていくために試行錯誤している方々に向けた話をしようと思います。

    スクラムを実践して良いプロダクトを届けよう、現場を改善しよう...簡単な道のりではないことが分かりつつも、新しいことにチャレンジしている(あるいはチャレンジしようとしている)素敵な皆さんを少しでも後押ししたり、小さな変化が起こるきっかけになるようなセッションにしたいと思います。

  • Omar Galeano
    keyboard_arrow_down

    Omar Galeano - How to communicate the ROI of test automation to your business - テスト自動化のROIをビジネスサイドに伝える方法とは?

    20 Mins
    Talk
    Intermediate

    In the era of modern software development, test automation has gone from a ‘nice to have’, to a critical component of delivering quality software at velocity.

    Business decision makers generally agree that test automation is a good idea, but may hesitate to commit appropriate resources, especially when budgets or deadlines are tight.

    We will interactively walk through scenarios that highlight the key factors that deliver test automation value. You will learn how to quantify the ROI of test automation and influence fiscally-minded decision makers with confidence!

    1*xhslp76-jPekWH_lYdfqqQ.png

    Note:Simultaneous interpretation will be provided in English and Japanese for this session, so please feel free to attend even if you are not comfortable with English!

     

    現代のソフトウェア開発において、テストの自動化は「あったらいいな」程度のものから、高品質なソフトウェアを迅速に提供するための重要な要素となっています。

    ビジネスの意思決定者は、テスト自動化が良いアイデアであることには同意しつつも、特に予算や納期が厳しい場合には、適切なリソースの投入決定にはためらうかもしれません。

    本セッションでは、テスト自動化の価値を高めるために、重要な鍵となる要素をシナリオを用いながら対話形式で紹介します。また、以下について学ぶことができます。

    ・テスト自動化のROIを定量化方法

    ・財政観点を重要視する意思決定者に対して自信を持って切り込む方法

    ※なお、本セッションは英語・日本語の同時通訳がつきますので、英語が苦手な方もお気軽にご参加ください!

     

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    アジャイル・スクラムに関するカンファレンスプロポーザルは『「気がついたこと」「心構え」「事例」に関する話が多い』と感じています。たまに見かける技術の話であっても「テスト駆動開発」「モブプログラミング」「DevOps」ぐらいのざっくり粒度、またはそれらを取り入れるときの心構え的なものではないでしょうか?

    アジャイルのゴールを実現するにはチーム環境だけでなく、開発環境も必要なはずです。もっと真正面から技術面のトピック・取り組みを取り上げ、もっと良い知見を広く探究していきませんか? Retty株式会社での事例を紹介することで、アジャイルなソフトウェア開発を支える技術面の取り組み水準を底上げしたいと思っております。

    ---

    In order to realize the goals of Agile, we need to enrich not only the team environment, but also the technical side. We would like to cover topics and initiatives on the technical side more head-on. By introducing case studies at Retty Inc., I hope to raise the level of technical efforts to support agile software development.

  • Ken Matsumoto
    keyboard_arrow_down

    Ken Matsumoto - 仕事や家庭の中でのリーダーシップのありようについての回想

    Ken Matsumoto
    Ken Matsumoto
    Agile Coach
    Agilergo Consulting
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

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

    最近自分の関心は、サーバントリーダーシップやLeaders Go Firstのあたりにあって、
    仕事や家庭を含めた生活の中でどう振る舞うと物事が流れるのか、もしくはそうでないのか、といったことについて個人的なお話ができればと思います。

    心持ちとしては
    ・ごちゃごちゃいわない
    ・離れずに側にいる
    ・質問をして話を聞く
    ・自分にできそうなことや一緒にできそうなことを申し出る(もしくはしない)
    ・やってみれたことや小さな結果が出たことを喜ぶ
    ・阻害する人やものには対処する
    ・自分の心の平静を第一に
    といったことを保ちながら周囲と接し続けることかと思っています。
    また、難しい状況は突然好転することもないのが常ですが、そうした状況を受け入れること自体が、そこではないどこかへ行く出発点になるのかなとも思います。

    現在アギレルゴコンサルティングが提供させていただいている研修類には
    - 著名なトレーナー陣によるAdvancedレベルまでのScrum Alliance®認定研修各種
    - スクラムパターン研修
    - 認定アジャイルテスティング研修
    などがありますが、ここ数年こうした研修類の運営を行う中で自身が受けた影響についても、各研修の特徴を紹介しながらお伝えできればと思います。

  • Yudai Moriya
    keyboard_arrow_down

    Yudai Moriya - 異動することでもはじめられるScrum

    Yudai Moriya
    Yudai Moriya
    Engineer
    Yahoo Japan Corporation
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    学生のころからScrumを実践する機会があり、RSGT2017でその事例をスピーカーとして話したことをきっかけにコミュニティ活動を始め、 就職後もScrumの勉強を続けてきました。

    その一方で、配属先で導入されていた"Scrum"は、それまでの経験が活かせるものではなく、自分が思う開発チームのイメージとのギャップがある状態がずっと続いていました。

    そのギャップを埋めるためには、これまでに経験してきたScrumの良さを伝えてチームを変えていくしかないと思い込んでいました。しかし、コミュニティでいろんな話を聞く中で、今いる組織だけが組織ではないと気づくことができました。

    そこで、業務上のつながりはないものの、社外のコミュニティで出会った同じ会社の人に相談してみようと思いました。結果的に社内異動の希望が通り、Scrumに組織的に取り組んでいる部署で働くことができるようになりました。

    異動後は実践的な学びを得ることができ、プロダクトもプロセスも楽しむことができています。

    本セッションでは、Scrumで開発をするために異動という選択肢をとった経験と、異動後に得られた気づきや喜びについてお話しします。

help