location_city Tokyo schedule Jan 12th 02:00 - 02:45 PM JST place 1F Room B (46)

I am going to share a case study of how we as coaches kick start a large scale agile transition and supported the product teams in the one year journey in the transition in FDA (Food & Drugs Administration) regulated organisation in healthcare industry.  The product teams include members with software, electrical and mechanical background. I will share how the transition get started, what are the phases during the journey, what are the main problems we try to address and what we did to achieve significant success. 

 
 

Outline/Structure of the Talk

  • Why did the management seek external support after a successful product death march version release
  • Phase 1 - Kick start
    • How did we kick off the journey and facilitate the organisation structure change
  • Phase 2 - Scaling Scrum and Real Teams
    • How to build self-managing team to enable cross-learning and close collaboration
    • What scaling ceremonies, practices, artifacts were adopted and what were the difference from single team implementation
  • Phase 3 - Get up to speed
    • What infrastructure, tool and process change were adopt to support iterative and increment development
    • What individual level agile practices adopted to enable frequent and stable release
  • Phase 4 - Test Efficiency and Effectiveness
    • What we did to address quality issue of life-critical product release

Learning Outcome

  • What are the phases of the agile transition and the main problems we tried to address in each phase
  • Detailed demonstration and explanation of workshops, activities, practices in each phase

Target Audience

ScrumMasters, Product Owner, Management, Coaches

Prerequisites for Attendees

No

Slides


schedule Submitted 1 month ago

  • Zuzi Sochova
    Zuzi Sochova
    Agile Coach and Trainer
    sochova.cz
    schedule 1 month ago
    Sold Out!
    90 Mins
    Keynote
    Intermediate

    Unleash Your Agile Leadership Potential and Guide Your Entire Organization Toward Agility

     

    Leadership is one the most significant challenges to business agility adoption faced by

    organizations. 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.

  • SHIMPEI TAKAHASHI
    keyboard_arrow_down

    SHIMPEI TAKAHASHI - [招待講演] どうすれば新しいアイデアが生まれるのか

    SHIMPEI TAKAHASHI
    SHIMPEI TAKAHASHI
    Toy Creator
    Usagi Inc.
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    ※以下、招待講演の提案です。

    【概要】

    新しいアイデア、特に行動に移して価値を生むことができるアイデアとは、人の欲求を満たすアイデアである。
    本講演では、「個人的欲求起点」というアイデア発想法を丁寧に解説しながら、商品開発やものづくりに役立つ考え方を提案する。

     

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - Outcomeにフォーカスするチームへのジャーニー

    Yoh Nakamura
    Yoh Nakamura
    Agile Coach
    レッドジャーニー
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    アジャイルは"プロダクトそのものをうまくつくる"だけでなく、その"多くの人にそのプロダクトが使ってもらい、使い続けてもらうようにする"というのも含まれていると考えます(もちろん、そのプロダクトを提供し続けるような対価を得ることも含みます)

    どうやったら使い続けてもらうか?を見つける活動の1つに仮説検証があります
    仮説検証が十分でないと、ただ闇雲に開発し、OutcomeのわからないOutputを生み出し続けてしまうこともあります

    では、仮説検証と開発をどのように進めていくと良いのでしょうか?
    スキルセットの違い、活動のサイクルの違い、仮説検証と開発のつなぎ方、開発から仮説検証へのフィードバックループなどいろいろなトピックがあります
    すべてをいきなりできるわけではなく、段階的に学んでいく作戦も必要になります

    このセッションでは、「Outcomeにフォーカスするチームへのジャーニー(旅路)」を歩んでいるいくつかの現場のチームの事例を中心に、レッドジャーニーのアジャイルコーチとして80チーム以上を支援してきた自分なりの経験や考えをお話します。

    ※RSGT2022のプロポーザルをベースにこの1年の経験でアップデートした内容でお伝えします。

  • FUMIKO NAOTSUKA
    keyboard_arrow_down

    FUMIKO NAOTSUKA / Yuhei Koito - ラグビー元日本代表がスクラムやってみた

    20 Mins
    Talk
    Beginner

    『スクラム』の名前の由来となっている『ラグビー』。
    そんなラグビーを20年間、クラブチーム、日本代表、海外のチームなど様々な環境でプレーしてきた私が、スクラムチームのPOを担当することになりました。
    POになって半年間で感じたラグビーとスクラムの共通点、相違点について語ります。

    • ここが同じ!
      • ラグビーはコミュニケーションのスポーツ
      • なぜNZのオールブラックスは強いのか?優れたチームの特徴とは
      • One for all All for one ~1人はみんなのために、みんなは1つの目標のために~
      • 迷うな!聞いて、見て、判断。そして行動する
    • ここは違う!
      • 大事なのは過程か、結果か。勝たなきゃ意味がない?!
      • スペシャリスト or オールマイティ
      • ラグビーは1チーム何人?チームスポーツで最大の人数!

    スクラム経験者のみなさまも、ラグビーという新しい視点を通じて、改めてスクラムやチームを見直すキッカケになると幸いです!

    聞き手は同じチームでスクラムマスターを担当している小糸が務めます。
    参加者の質問もいくつか拾えればと思うので是非多くの質問をお願いします。

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - スプリントレビュー Deep Dive

    45 Mins
    Talk
    Beginner

    ★★★Deep Diveシリーズ第3弾!!★★★

    Deep Diveシリーズでは、主にスクラムを始めたばかりの人、実践しているもののこれでいいのか?と不安を持っている人に向けに、スクラムの要素を詳細に解説しています。

    これまで以下の2つをお届けしてきました。

    シリーズ3作目となる今回は、「スプリントレビュー」についてです。

    スクラムの3本柱である透明性、検査、適応は、スクラムのあらゆる役割やイベント、作成物に関係します。
    作成物の1つであるインクリメントも当然対象となります。そして、インクリメントの検査と適応の場が、スプリントレビューです。
    不確実性の高い問題の解決に取り組んでいる私たちは、スプリントレビューを通じて、自分たちが作っているものが正しい方向に向かっているのかを短い間隔で検査し、学習した内容や環境の変化を踏まえて、適応していかなければいけません。

    アジャイルマニフェストには「包括的なドキュメントよりも動作するソフトウェアを」という項目があります。
    これが意味するところは、現物の重要性です。私たちはビジネス上の目標を達成するためにプロダクトを作っています。充実したドキュメントがたくさんあっても、プロダクトをユーザーに渡せなければ無意味です。プロダクトを使うユーザーがいなくても無意味です。プロダクトを使ったユーザーが、自分たちの課題を解決できなくても無意味です。
    つまり、プロダクト(動作するソフトウェア)は核となるものであり、定期的にプロダクトそのものや、プロダクトに加わった変化(インクリメント)を実際に検査し、適応し続けなければいけません。

    一方で、スプリントレビューが単なる進捗報告の場であったり、意味のある検査ができないようなものを披露していたりするような現場をたくさん見てきました。
    これではスプリントレビューの意味がありません。
    スプリントレビューはスクラムのイベントのなかで、いちばん重要なイベントです。このイベントをうまく運用できるかどうかで成果は大きく変わってきます。

    以下に挙げるようなスプリントレビューの鉄則をはじめとして、スプリントレビューを圧倒的に効果的に活用するための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

    • なにはともあれインクリメントを見せろ
    • フィードバックを得られるようなインクリメントを用意しろ
    • スプリントレビュー直前にインクリメントに手を入れるな
    • プロダクトの状況や進捗を表す簡単な資料を用意しろ
    • デモはプロダクトオーナーと開発者全員ができるようにしておけ
    • スクラムチームの外側のステークホルダーを呼べ
    • スプリントゴールに応じて、どのステークホルダーを呼ぶかを選べ
    • スクラムチーム全員が参加しろ
    • スプリントレビューのやり方を改善しろ
    • スプリントレビューから逆算してスプリントプランニングしろ
    • スプリントレビューの会話のメモを取っておけ
    • スプリントレビューで「次のスプリントで対応する」とかコミットするな
    • そのスプリントで何も完成しなくても、スプリントレビューをスキップするな
    • とはいえ、とにもかくにもインクリメントを提示できるようにしろ

     

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - The Stable Team - 機能する安定したチームをつくる -

    45 Mins
    Talk
    Advanced

    「安定したチーム」は、機能するチームの前提条件として様々なところで紹介されています。

    「真のチーム」の必須条件  
    1.課せられた「仕事」が明確なこと  
    2.チームの内と外を隔てる「境界」も明確なこと  
    3.仕事のやり方を管理する「権限」が具体的に決められていること  
    4.メンバーの顔ぶれがあまり変わらない「安定性」があること
    『ハーバードで学ぶ「デキるチーム」5つの条件』

    安定したチームは、チームのキャパシティを知ることができるため、ビジネスの予測をしやすくなります。
    『STABLE TEAMS - Scrum Patterns -』

    長続きするチームに仕事が流れ込む
    『Team Topologies』

    なんとなく安定したチームがよさそうであることは多くの方が同意されることでしょう。

    一方で、目の前にある現場のチームを見てみると、

    • 受託開発をしていて、案件ごとにチームが組成されるのでチームが長続きしない
    • 組織的にはチームになっていても、個人商店化していてチーム感がない
    • 組織の都合でメンバーの入れ替えが定期的に起きてしまう
    • メンバーはほぼ固定されたチームになっているが、うまく機能していない

    など安定したチームとは程遠い現実が拡がっています。

    安定したチームが理想であることはわかるものの現実とのギャップがあると、自分には縁遠いものだととらえてそこで思考を止めてしまいたくなります。


    でも待ってください!

    メンバーを固定できない状態では安定したチームをつくることはできないのでしょうか?
    メンバーを固定さえできれば安定したチームをつくることができるのでしょうか?

    これに似た構図を私たちは知っています。
    そうです、アジャイル開発です。

    私たちは変化が多い状況でも思考停止せずに現実を受け止め、変化に対応してチームで協力して価値を生み出し続けることを目指すアジャイル開発に共感をし、コミュニティに勇気づけられて、現場で行動し続けています。

    チームづくりにも同じことが言えるのではないでしょうか。


    Silver Bullet Clubは、2016年にチームが結成されて現在に至るまで6年以上存続しているチームです。そこだけ切り抜くと安定したチームのように見えるかもしれません。ところが実際には、2回のチーム転職を経て、会社も変わり、一緒に仕事をするメンバーが変わり、仕事のドメインが変わり、常に様々な変化の中にいました。

    変化が多い状況でも諦めずに、Silver Bullet Clubであり続けようとしました。その活動の中で、安定したチームとはどのようなチームなのか徐々に理解ができ、機能する安定したチームになるための具体的なアイデアを試行錯誤してきました。

    本セッションでは、安定したチームとはどのようなチームなのかを解説し、変化が多い状況の中で機能する安定したチームをどのようにつくっていくのかについて知ることができます。

    様々な変化がある難しい状況の中でも諦めずに、機能する安定したチームを目指したい方はぜひご参加ください。

  • Tsuyoshi Ushio
    keyboard_arrow_down

    Tsuyoshi Ushio - ログの書き方がチームの生産性を爆上げする話

    45 Mins
    Talk
    Intermediate

    ソフトウェアサービスの開発、運用にかかわっていると「ログ」は開発チームの生産性を左右する重要な要素だと実感します。ところが、「ログ」をどのような観点で書けばよいのか?ということに関してはあまり良いガイダンスを見かけません。本セッションでは具体例や効果を示しながら、インシデントの対応時間を激減させ、インシデント対応の自動化を促進するための「ログ」のベストプラクティスをご紹介いたします。

  • masafumi takarada
    keyboard_arrow_down

    masafumi takarada - 人や組織を取り巻くシステムに刺激を与えるマインドセットとしてのManagement 3.0

    masafumi takarada
    masafumi takarada
    manager / scrum master
    -
    schedule 1 month ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    2022年夏は「マネジメント3.0」「マネージング・フォー・ハピネス」と、これまで待ちに待たれた(はずの)Managemenet 3.0の翻訳本が立て続けに出版され、日本にとってのManagement 3.0元年とも言える年になった(か現在進行形でなっている)のではないかと思います。

    このセッションでは、翻訳者として「マネージング・フォー・ハピネス」を出版した立場から、Management 3.0の基盤となる考え方/捉え方に重きをおいた内容をお話しします。

    チームや組織として継続的に高いパフォーマンスを維持していくためには、そうなるための変化を導入し、なおかつ状況にも合わせて常に変化し続けることが必要になりますが、そういったシーンで変化を促す立場側が重要視するべきスタンス(受け入れられやすい状況のつくり方や求めている方向への導き方)」というところに関する気づきやきっかけを提供します。

    まだ本を読まれていない方やManagement 3.0を知らない方でも理解していけるような内容にしますので、前提知識がなくてもお気軽に参加いただければと思います。


    ヨーガン・アペロ氏は21世紀に創造的な組織が成功し、存続していけるようにするための「少数のマネージャーによるマネジメント(メンバーがマネジメントは自分の仕事であると自覚し、各自でマネジメント活動をしていくことで「マネージャー」の役割にあたる人は少数で十分になるはずという考え方)」を導入することに伴う、具体的なゲームやツールやプラクティスを提供することを軸に主にヨーロッパで活動されています。

    Management 3.0はそのなかのひとつであり、ヨーガン・アペロ氏が考案したものです。過去、RSGTでもManagement 3.0をテーマに基調講演をされたことがありました。

    また、Management 3.0は上記に加えて「幸せで生産性の高い組織になるためのマネジメント」とも表現でき、ヨーガン・アペロ氏の「組織は複雑適応系であり、良いマネジメントとは、人を操作することではなく、システムに気を配ること」という信念のうえに成り立っています。

    3.0のナンバリングが示すとおり、Management 1.0や2.0の状態も定義しています。Management 1.0は人を「機械」として捉えるマネジメントで、Management 2.0は人を「機械」ではなく「人間」として捉え、人が活きるための施策をとっているが、根底にはヒエラルキーが存在するようなマネジメントを指しています。

    詳細はじんぶん堂記事「マネジメントは誰の仕事だろうか?」もご覧ください。

     

  • Toshiharu Akimoto
    keyboard_arrow_down

    Toshiharu Akimoto - CQ x Agile で価値観の違いを紐解き、人と組織の関係性に橋をかける

    Toshiharu Akimoto
    Toshiharu Akimoto
    Coach / Catalyst
    Kumu Inc.
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「カルチュラル・インテリジェンス」(CQ)とは、文化の違いを超えて円滑にコミュニケーションを図る能力のことです。文化の違いと聞くと国や宗教のような大きなものを想像しがちですが、組織にも、部署にも、チームにも、そしてひとりひとりの個人にも文化的背景はありますよね?アジャイル的な考え方も文化といえる背景がありそうです。

    知らず知らずに考えたり、当たり前に行動しているその価値観。根幹には、本当はもっと多くの次元の価値観の軸があるのではないでしょうか?

    ここでは手始めにCQで語られるホフステードの6次元モデルを参考に、CQとは何かのざっくりとした説明と、アジャイルマニフェストをホフステードの6次元モデルで分解してみるとどういう価値観の背景があるのか考察してみたいと思います。

    https://speakerdeck.com/spring_aki/cq-introduction?slide=2

  • Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta - 大企業がアジャイルになる途中で起きること

    20 Mins
    Talk
    Intermediate

    中小企業基本法で定められている中小企業の条件は、例えば製造業だと資本金3億円以下、社員数300人以下の企業で、この定義より規模が大きければ大企業だそうです。

    私は、とある製造業系大企業のグループIT企業の社員として、入社以来20数年勤務しています。入社した時とはずいぶん風景は変わりましたが、会社の歴史と共に生きてきた、と言えると思います。

    十数年前に私がアジャイルを学び、実践し始めたのはあくまで個人的な欲求からだったわけですが、今や私が所属する会社も、社を挙げてアジャイルを学び、企業活動に活かすべく動き出しています。それは、若き日の私が夢見たことでもあります。

    ただ、当然ながら、めでたしめでたし...とはいきません。

    前世紀から存在するような大企業は、それまでのやり方で上手くいったから大企業な訳で、時代や環境が変わったからといって、それまでの成功体験を一旦忘れて新しい考えを学ぶことは簡単ではありません。アジャイルの波が社内に押し寄せる中で、喜んでいる人より、戸惑い悩む人の方が明らかに多いのです。

    アジャイルに魅せられて、同僚より少し先にその道を歩んで来た私に、できることはなんだろうか...

    新しいビジネスの地平を目指してアジャイルを志向し始めた大企業の中で、私が経験した事象の数々を言語化することで、同じような境遇で現場づくり、組織づくりに挑んでいる方々の学びにならないか、との思いでプロポーザルを書きました。


     

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / amix edcolor / Iwao Harada / Kei Ogane / Norihide Fujiki / Ryo Tagami / Yuichi Tokutomi - 品ジャイルラジオ! カンファレンスの廊下を実況中継してオンラインとオンサイトと外の人をつなげます。

    45 Mins
    Talk
    Intermediate

    スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

    カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

    哲学(ケツバット)について
    https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

    ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

    「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
    それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

    https://twitter.com/bayashimura/status/1542480802658652160?s=21

    今回のゲスト(予定、随時更新)

    • furoshiki.fmのみなさま
    •  

    過去の放送は、links欄にあります。

    ※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

     

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - チームのパフォーマンスを引き出す、ワクワクするプロダクトゴール/OKR

    45 Mins
    Talk
    Intermediate

    プロダクトゴールについては、昨年のRSGTで長沢さんが素晴らしいセッションを提供してくださいました。では、私が語り得ることは何か?

    自分の経験に基づいた話。
    ゴールを設定する手前の、そこにいる人がワクワクしていくためのプロセス。
    そんな話をしたいと思っています。

    目標管理手法のひとつOKR。Scrum Fest Mikawa 2022において「OKRはツリーではない」という発表を行いました。

    その発表の中では、OKRにおいて何よりも重要なのは「目指さずにはいられないワクワクする目標を作ること」だと説明しています。

    これはスクラムのプロダクトゴールに対しても同じことが言えると、私は考えています。ワクワクする、そのゴールを達成せずにはおられないからこそ、私たちは自分たちの状況を公開し、失敗する勇気をもち、互いに尊敬しあいながらゴールに集中し達成を確約するのです。
    私が関わってきた組織、チームでもワクワクするOKRを設定できているかどうかがプロダクトゴールの実現度合いと密接に関わっていることを観測してきました。ワクワクOKRを持ったチームは「ありたい姿」と「プロダクトゴール」の一致度が高くなり、主体的にプロダクトゴールに向かうため達成度が高くなりました。それに対しシナシナOKRが手元にあったチームは「こんな目標、達成できると思ってません」とゴールへ向かうモチベーションさえ湧かず、したがって達成度は低い状態でした。
    であれば、ワクワクしたOKRを設定しない手はないですよね。

     

    言うは易し。

     

    「『ワクワクする目標を作る』?それができねぇから七転八倒してるんだろうがッ!!」そんな声がきこえてくるようです。少なくとも私の胸の奥からはそのような叫びが聞こえてきました。名著「Measure What Matters」でいうところの「組織全体に目的意識と連帯感をもたらし、多様な活動を結びつける」ような目標は、ゴールはどうやって作ればいいのでしょうか。

    OKRオタクを自認する小田中がこれまでに経験したうまくいった(ワクワクした)目標設定、うまくいかなかった(シナシナした)目標設定についてふりかえります。
    どうやったらワクワクさせられるのか、シナシナを避けられるのかについても触れていきます。そして、目指さずにはいられないOKR、ワクワクいきいきする目標を作り上げるための再現性のあるプロセスについて解説します。ワクワクの源は千差万別、だからこそ再現させるのは難しい。けれども内発的動機を駆り立て、互いのビジョンを共有しながら深く対話することで、壁に張り出したくなるようなOKRはできるんです。おっと、ここから先は本編で。

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - Transforming Your Tech Talk: Sharing Technical Information With Non-Technical Audiences

    20 Mins
    Talk
    Beginner

    "There is nothing dumb - or easy - about making complicated information accessible to an audience." - The Buckley School

    Transforming Your Tech Talk is designed to share the process behind crafting presentations that successfully make deeply technical information accessible to audiences of all backgrounds and experience levels. No matter your job title or level, effectively communicating information can be a career game-changer.  The techniques you learn here will help you take everything from team presentations to pitches to leadership, and even conference talks, to a brand new level!

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 自治体DXにアジャイルなマインドとスキルはどれほど役立つのか

    45 Mins
    Talk
    Intermediate

    CDO補佐官として福井県のDX推進を支援するようになってから半年以上が経過しました。兼業という時間的制約がある中での活動ですが、少しずつ、やりたかったことが実現できつつあります。

    • 部門横断チームでのVSM(バリューストリームマッピング)による業務改善
    • 庁内に改善と助け合い活動を広げるための仕組みづくり

    などなど、他にもいろいろと、県や市町の方とタッグを組んで進行中です。RSGT2023が開催されるころには、さらに多くの取り組みが成果として実を結んでいるはずです。

    このセッションでは、アジャイル実践者として学び身に着けてきたマインドセットやスキルが、何にどのように役立ったのか、また、開発者・スクラムマスター・プロダクトオーナーとしての経験を、自治体のような従来型組織の変革にどのように適用していくと良いのかについて、なるべく具体的にお伝えします。

    そして、世の中をよりよくするために、技術者が人々を巻き込んで変革していくことの意義についても少しお話できたらと思います。全国に補佐官仲間が増えるようにとの思いを込めて。

  • Yoshiki Iida
    keyboard_arrow_down

    Yoshiki Iida - エンジニアリングマネージャー業の具象と抽象

    Yoshiki Iida
    Yoshiki Iida
    Engineer
    Loglass Inc.
    schedule 1 month ago
    Sold Out!
    20 Mins
    Talk
    Advanced

    最近になって改めてエンジニアリングマネージャーという役割に注目が集まっています。

    この数年でずいぶん体系的な知識にアクセスしやすくなった反面で、まだまだ実践的な経験の話は少ないように感じています。

    エンジニアリングマネージャーの定義は会社によっても差分はありますが、採用や評価、労務管理、といったいわゆる人事領域の仕事から、事業戦略や組織戦略といった戦略策定に関わることもあります。

    私はこの数年エンジニアリングマネージャーとして仕事をしてきました。途中一度エンジニアに戻り、また改めて2周目エンジニアリングマネージャーとしてチャレンジするというバックグラウンドがあるのですが、現在2周目をやって感じることは、

    • 相変わらず業務の幅は広いこと
    • 自分の立ち位置がわかりやすくなったこと
    • 組織的な設計がすぐに古くなってしまうこと
    • やらないことを決めることが重要だと言うこと

    です。

    特に業務の幅広さについて、抽象度で整理すると自身の仕事も周囲とのコミュニケーションもわかりやすくなったという気づきがありました。

    このセッションでは、この幅広く見えるエンジニアリングマネージャー業を抽象度で整理してその理解を深めたり、向き合い方についての解像度を高めるような場にしたいと思います。

    スクラムの中にはマネージャーというロールはなく、自己組織的なチームであればマネージャーは必要ないという意見もあるかと思います。

    しかし、現実的には会社という枠組みの中でチームを効果的に支援する役割が重要となります。

    • チームができること、チームができないことの境目は何か?
    • どうすればアジャイルなチームを長続きさせられるのか?
    • エンジニアリングマネージャーがアジャイルであるとは何なのか?
    • 組織全体がアジャイルになるためにエンジニアリングマネージャーは何をすべきなのか?
    • エンジニアリングマネージャーはどのようなキャリアを歩めばよいのか?

    チームの外にいるからこそできることを一緒に考えてみましょう。

     

     

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - [Day0] 知り合いを増やしてRSGTへのドキドキをワクワクにする会

    Shinya Ogasawara
    Shinya Ogasawara
    -
    -
    schedule 2 months ago
    Sold Out!
    100 Mins
    Workshop
    Beginner
    • RSGTには初めて参加するので、どんな感じなのか分からず、本当に自分が参加して良いのか不安だな
    • オンライン参加で、Discordを使うみたいだけど、どう使えば良いのか分からないし、大丈夫かな
    • 現地に行っても他に知り合いはいないので、ぼっちになってしまうのではないかな
    • 何度か参加しているけど、久しぶりだから誰か自分のことを覚えてくれているかな

    このように、初めてRSGTに参加される方や、久しぶりのRSGTだという方など、RSGT参加が近づくに連れて何となく不安でちょっとドキドキしてくる方は多いのではないでしょうか。

     

    私は、RSGT2021とRSGT2022で知り合いを増やすためのワークショップを行いました。参加頂いた方には大変好評で、知り合いが増えることでRSGTをより楽しむことが出来たという感想をたくさん頂くことができました。

    一方で、開催後に「Day 0にこの会をやって欲しかった」というフィードバックを多く頂きました。(これまではDay 1の最後にネットワーキングの一部として開催していました)

    たしかに、Day 1が始まった時点で知り合いがいる状態になっている方がより望ましいですし、ネットワーキングパーティではその繋がりから、さらに知り合いが増えるかもしれません。何より、知り合いがいる安心感が、Day 1への参加を楽しみでワクワクするものにしてくれます。

     

    そこでDay 0でRSGT2021とRSGT2022で開催したものと同様な「知り合いを増やす会」を実施することを提案します。

    主なターゲットは初参加や久しぶりに参加する方ですが、よく来ている人にも参加して頂いて、これまでの楽しみ方を話してもらうのも良いなと思います。

    参加に向けての不安点を解消したり、注目しているセッションについて共有したりするのも楽しそうです。

    そしてこれがDay 1以降の深い議論や学びに繋がっていくことを期待しています。

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - ソフトウェア開発関係ない人向けに作ってみた、アジャイルにものを作るってどういうことか?

    45 Mins
    Talk
    Beginner

    ソフトウェア開発に携わってこなかった方向けに、アジャイルに開発を進めるってどういうことか?を伝えてほしい、という依頼がありまして、以下の流れで話しました。

    1. ソフトウェア開発ってどういうものなのか (ユーザー企業観点)
    2. 要件というのはどういう風に考えるのか (狩野モデル)
    3. 新規サービス開発への狩野モデルの適用 (ユーザーストーリーマッピング)
    4. スクラムとはなにか、DevOpsはなぜ必要なのか

    ホロラボ社内や、クリエーションラインさんに呼んでもらって講演をしたのですが、なかなか好評をいただいたと思いますので、RSGTでもお話しできればと考えました。公開の場では今回が初のトーク提案になります。

     

  • Tomoharu Nagasawa
    keyboard_arrow_down

    Tomoharu Nagasawa - スクラムチームが自信をもってアウトカムとスプリント活動に集中するためのコツ

    20 Mins
    Talk
    Intermediate

    スクラムチームは、顧客やユーザーの成果である「アウトカム」に集中するべきです。そのためには、プロダクトゴールとスプリントゴール、完成の定義といった「確約(コミットメント)」が重要です。しかしながら、アウトカムを生み出すのは、スクラムチームのアクティビティ(行動)とアウトプット(コードやレポートなど)です。アクティビティとアウトプットを検査し、適応させることでよりよいアウトカムが生まれてきます。要するに『アウトカムが大事であると認めながらも、アクティビティとアウトプットも大事』なのです。

    このセッションでは、話し手が現場の支援をしているスクラムチームでも実践している行動変容、行動改善に用いるアクティビティとアウトプットの《事実を積み重ねて見えてきたことから検査し、適応させる》のためのテクニックによってよりよいアウトカムが意識できる方法についてそのエッセンスをお伝えします(※ 具体的な事例は公表しません)。

    例えば、

    • スプリントプランニングで、プロダクトバックログアイテム(PBI)とタスクをだしたのに...
      • タスクごとに作業分担して一斉に取り掛かってしまう
      • 中盤または終盤にDoneになっている(そうなる見込みがある)PBIがひとつもない
      • デイリースクラム以外でチームメンバーと成果について会話していない
    • ステークホルダー(特にマネジメント層)から生産性指標やその向上について聞かれたのに...
      • ベロシティしか提供できない
      • ベロシティを他チームとの比較に使われてしまう
      • そもそも生産性指標を提示する意義がよくわからん
    • 果たして我々はうまくいっているのか...
      • スクラムのルールに従っていたらうまくいっていると言えるのだろうか
      • ステークホルダー(特にマネジメント層、他のチーム)に対して胸張って活動を伝えられるだろうか
      • 自分達は自己管理しているのだろうか、それとも"自己管理"されているのだろうか

    といったお悩みに対して、解決策とズバリ言えるかは現場によりますが、ヒントくらいは提示できます。

    スプリントバックログ運営でのコツ:

    • PBIのWIP制限
    • PBIのサービスレベル期待値(SLE)

    スプリントで計測すべき指標:

    • PBIの経過期間(年齢)
    • サイクルタイム

    スプリントでの実態把握で見るべきグラフ:

    • サイクルタイム散布図
    • 累積フロー図

    ステークホルダーにスクラムチームの活動や開発戦略について聞かれた時に「ベロシティ」くらいしか説明できない方や、それらをうまく説明できずに自信を持てないスクラムチームに向けて一つのヒケツをお伝えしたいと思っています。

     

    More Effective Scrum シリーズ(?)

    RSGT2020, 2021, 2022 で発表した内容からつながるセッションにする予定ですが、過去の発表内容を事前に知っておく必要はありません。

     

  • Keiji Kikuchi
    Keiji Kikuchi
    Programmer
    SQUARE-ENIX CO.,LTD.
    schedule 1 month ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    本セッションではまず、大規模ゲーム開発におけるリモートモブワーク導入の前提となる、リモート下でのスクラムフレームワークの導入の事例を紹介します。
    そしてスクラムの本質はコミュニケーションであることに着目しつつ、1日1時間のリモートモブワークを実際に導入してみた経緯や内容、得られた効果、発生した問題、改善事例や変遷を具体的に紹介していきます。

    CEDEC2022で講演した内容をアップデートしてゲーム業界以外の方にもわかりやすいように再構築して発表いたします。

  • Kei Ogane
    keyboard_arrow_down

    Kei Ogane - (新米)エンジニアリングマネージャーのしごと

    20 Mins
    Talk
    Intermediate

    少し前に新しいチームへEMとしてジョインしました。
    新しくジョインしたチームは、BtoB SaaSの開発をスクラムっぽくやっていたのですが

    • スクラム経験者がおらずなんとなくでスクラムをやっている
    • 退職者が続いたこともあり混沌としている

    といった状態でした。こういう状況にSMやエンジニアとしてジョインすることは慣れていたのですが、今回はEMとしてのジョインでした。
    会社としてEM専門職は初の存在であり追うべき背中も社内に見当たらない中「一体自分は何をすればいいんだ」と戸惑いつつ、できることを色々やってみたり、本を読んで真似してやってみたりしたことを挙げていきます。
    また色んな行動をする中での自分のモチベーションの変化や、場面場面での自分の感情なども吐露していきます。

    ただ私の体験を表現するだけだと学び少ない感じもあるので、複数の書籍を参照しながら「この記述に当てはまるかも」とか「この本のこの文章を解釈してこういう行動に繋がりました」辺りも発表できればと思っています。

help