filter_list help_outline
  • Liked Naoyuki Ide
    keyboard_arrow_down

    Naoyuki Ide - よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~

    Naoyuki Ide
    Naoyuki Ide
    CEO
    Yoho Brewing Company.
    schedule 5 months ago
    Sold Out!
    60 Mins
    Keynote
    Beginner
    一人ひとりが個性を発揮できる環境を作ることが、企業成長の原動力となる。
    創業以来8年連続赤字の危機的状況から、13年連続増収増益・国内クラフトビールNo.1に至るまでの軌跡について、「チーム作り」の側面から事例を交えてお伝えします。
  • Liked クリス Chris Lucian
    keyboard_arrow_down

    クリス Chris Lucian - Learning to Experiment

    90 Mins
    Keynote
    Intermediate

    The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this talk I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.

    私にとっての過去最高の組織的変化は、緊急事態の結果、起こりました。ふつう、仕事上で実験できるのは、今のやり方がうまくいかないときです。危機的状況においては、抜本的な再建が可能です。しかし、指を加えて危機を待つ必要があるのでしょうか?本講演では、ハンター社が行った実験について話します。そして、継続的改善と継続的実験の文化を発展させて、危機的状況に陥ることなく、望ましい状態に進むことをお勧めします。

    Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This presentation is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.

    現在、私は新しいソフトウェア開発部門のディレクター(責任者)を務めています。私たちはモブプログラミングと他の多くのプラクティスを継続的に使っています。本講演では、ソフトウェア開発を通した私の旅、そして特にソフトウェア見積りのプロセスで経験したことについて話します。私たちの部署では、27人が6つのモブで終日作業しています。各チームはソフトウェアを見積もるのではなく、純粋なKanbanを実践し、ソフトウェアの垂直スライスを毎日提供しています。私がプロジェクトのソフトウェア見積もりを廃止したのは、ハンター社が初めてではありません。2007年にわたしがいた環境化学と民間軍事の組織は、もっと伝統的なウォーターフォールの現場でした。わたしたちがその時作ったのは、やり方を少し変えざるをえない事態が起きない限りはプロジェクトの先行きを見通せる、といったガントチャートでした。私はソフトウェア開発の長い旅を通じて、多くの実験を繰り返してきました。私たちの現在の状況からスタートし、どんなプラクティスを議論し、どんな発見をしてきたのかを話していきます。

  • Liked Gabrielle Benefield
    keyboard_arrow_down

    Gabrielle Benefield - Outcome Delivery: delivering what matters

    Gabrielle Benefield
    Gabrielle Benefield
    Founder
    Outcome Delivery
    schedule 5 months ago
    Sold Out!
    90 Mins
    Keynote
    Intermediate

    Today, most products and services organizations focus their collective attention overwhelmingly on delivering things right – on schedule, on budget, with complete scope and quality. Relatively little collective attention is paid to whether they are delivering the right things that solve their real problems. Gabrielle will talk about moving to an outcome delivery model; including case studies and how to get started.

    Outcome Delivery uses Mobius double-loop learning , helping you to focus on what problem to address, how to detect if it’s the right problem to address, how to get and analyze feedback to decide whether to continue or change tracks.

  • Liked Mitsuo Hangai
    keyboard_arrow_down

    Mitsuo Hangai - 悩めるManagerたちがお互いの皿回しっぷりを共有してスッキリする会

    Mitsuo Hangai
    Mitsuo Hangai
    Manager
    Rakuten, Inc.
    schedule 5 months ago
    Sold Out!
    100 Mins
    Workshop
    Intermediate

    現場でScrum MasterやProduct Ownerとしてバリバリやってて、昇進してManagerとか課長とかに(望む望まないにかかわらず)なったという方、多いんじゃないでしょうか。私もそのクチなんですが、Managerになってからというもの、何もうまくいった覚えがなくて、苦しいです。いろいろ本を読んだり実践したりもしてみてますが・・・毎日悩んでいます。

    そんな折、「エンジニアのためのマネジメントキャリアパス ――テックリードからCTOまでマネジメントスキル向上ガイド」が発刊されました。

    https://www.oreilly.co.jp/books/9784873118482/

    貪るように読みました。

    特にこの一節に非常な共感を覚えました。

    部長レベル以上の管理職が味わっている感覚を表現するとしたら、「皿回し」が最適です。回転速度が一定レベル以下に落ちた皿は棒から落ちてしまうため、どの皿にも注意を払っていなければなりません。こうした皿回しの「皿」が、技術部長であるあなたにとっては監督対象である部下たちでありプロジェクトであって、どのタイミングでどの部下なりプロジェウトなりにどの程度注意を払うかを見定めるのがあなたの務めです。

    なんという言い得て妙感!!なんだ、みんなそうなんだ!!と思いました。
    社内で「この本を語る会とかやりたいね」とかって話をしていたりしたので、どうせならRSGTにProposal出しちゃってもいいかなーと思い、筆をとっております。

    悩めるManagerたちと悩みを共有し、一緒にうまいビールを飲みたいです。

  • Liked Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - コミュ障仕事術 - Customer Interaction Patterns から学ぼう -

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    Rakuten, Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    スクラムでチームの状態がよくなったとしても、プロダクト開発やお客さんの成功のために、お客さん自身から必要な情報や発見をどれだけ引き出せるかが重要です。

    私はコミュ障です。人と話す時にどのように応じればいいのかわからずに、あたふたしながら無駄に汗をかいてしまいます。そんな私でも、お客さんのところへ毎週出向き、直接話しをしながらプロダクトのこれからについて、お客さんの本当に成し遂げたい成果について議論するということをしています。そんな私にとってとても参考になったのが、Linda RisingさんのCustomer Interaction Patternsです。

    このセッションでは、Customer Interaction Patternsについて、自分のこれまでの実践を合わせて紹介いたします。

  • Liked Mitsunori Seki
    keyboard_arrow_down

    Mitsunori Seki - プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処

    45 Mins
    Thought & Practice
    Intermediate

    エンタープライズアジャイルを実現するにあたり、プロダクトオーナーは、プロダクトマネジメント組織の中心として振る舞うことが求められます。しかし、プロダクトオーナーが抱える悩みは多岐に渡ります。本セッションでは、それらの悩みごとを整理した上で、解決に向けた取り組みについてご紹介いたします。

    • プロダクトオーナーとは
    • プロダクトオーナーが抱える悩み
    • なぜプロダクトオーナーが悩むのか
    • どう対処したらよいか
    • プロダクトオーナーがやるべき3つのこと
    • まとめ
  • Liked shihara shinji
    keyboard_arrow_down

    shihara shinji - アジャイルを組織に取り入れるために、人財育成始めました

    20 Mins
    Thought & Practice
    Beginner

    弊社プロダクト部門は、長い間、プロダクトアウト思考のプロダクト開発を行ってきました。
    プロダクトアウト思考の組織文化が形成されており、同じような会社は多いと思います。

    現在は、VUCA時代。
    お客様のためになるプロダクトやサービス開発は、アジリティが高いアジャイル開発が主流です。

    完成された組織文化に新しい取組みを導入するのは、非常に困難です。
    同じような悩みを抱えている会社も多いと思います。

    何のためにアジャイルなのか?
    その答えとして、”お客様のためになるプロダクトやサービスを開発する”と考え、デザイン思考に着目しました。

    デザイン思考もアジャイル開発と同様に、新しい手法を導入するという点では同じため、単に方法論や手法の導入ではなく、それが必要な動機付けを行う取組みにチャレンジしています。

  • Liked Shinya Yaginuma
    keyboard_arrow_down

    Shinya Yaginuma - データ分析チームにスクラム型開発フローを取り入れてみた

    Shinya Yaginuma
    Shinya Yaginuma
    Data Scientist
    Globis
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    スクラムは主にサービス開発に用いられるフレームワークですが、私たちGlobisのデータチームではデータ分析系のタスクにおいてもスクラムを取り入れられないかと試行錯誤してきました。

    試行錯誤を続け約半年経過した今、開発系タスクとの違いや工夫してきたポイント、現在どのように開発を進めているのかということをお話しさせて頂きます。

  • Liked Matsushima Masahiro
    keyboard_arrow_down

    Matsushima Masahiro - 非エンジニアの視点から考察する、Scrum開発でビジネスメンバーの能力を引き出す方法

    Matsushima Masahiro
    Matsushima Masahiro
    Product Owner
    Cyberagent
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    はじめまして。このセッションに興味を持って頂き、有難うございます。

     

    世の中には、チームビルディングに関する素晴らしいTipsは数多くあるものの、ビジネスメンバー※1の視点から考察されている事例はあまり多くはないように感じます。

    (※1エンジニア以外のメンバーをPO含め、ビジネスメンバーと記載しております。)  

     

    私は、何も開発の知識を持ち合わせていないところから、POとして、開発チームにジョインしました。

     

    良いプロダクトを創っていきたいという思いは同じではあるものの、最初は、なかなかうまくいかないScrum開発&コミュニケーション。

     

    ビジネスメンバーが躓きやすい落とし穴には共通点があるのでは!?

    なぜビジネスメンバーが躓くのかを、バックボーンを整理しながら、要因を考察していきます。

     

    私が経験したことを元に、非エンジニアの視点から、どこのチームでも起こり得る、この問題に対して事例を元に解決策を紹介していきます。

     

    明日から、皆さんのチームのビジネスメンバーと、エンジニアメンバーが垣根を越えて、より良いチームに向かう、一助となることを目指します。

  • Liked Tomonari Nakamura ( ikikko )
    keyboard_arrow_down

    Tomonari Nakamura ( ikikko ) / Yusuke Kokubo - プロダクトの急成長を支えるチームの仕組みとプロセスを考えて行き着いた今とこれから 〜エンジニアリングマネージャーとアジャイルコーチのコラボレーション〜

    20 Mins
    Advanced Case Study
    Intermediate

    ここ数年で、エンジニアリングマネージャーという職種が脚光を浴び始めています。個々のエンジニアだけでは解決しづらい組織的な課題を解決し、組織全体の生産性を高めることが求められるようになりました。

    私達が所属する組織・チームでも、プロダクトの成長にともないチームも増大した結果、チーム間でうまくコミュニケーションが取れない・フローが整備されていないために意思決定が遅いといった、組織的な課題が徐々に顕在化していました。

    個々のチームだけではなく、組織全体としてより大きな成果を出すために、必要なことはなにか?

    それを考えていった結果、エンジニアリングマネージャーとアジャイルコーチという2つの視点からプロダクトとチームの成長を支えることが一つの答えなのではないか、ということに行き着きました。

    本セッションでは、私達が上記の職種の必要性に至った背景と、両者がどのように組織・チームに働きかけるかの構想について紹介します。

  • Liked Ryosuke Nakamura
    keyboard_arrow_down

    Ryosuke Nakamura - 自律的で協調的なチームの作り方 ~複数拠点、多言語、職能型組織で始めるScrum~

    20 Mins
    1st Step Case Study
    Beginner

    職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
    私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。

    • プランナー(プロダクトデザイン、企画、グロースを担う役割)
    • デザイナー
    • フロントエンドエンジニア
    • サーバーサイドエンジニア
    • QA(Quality Assurance)


    また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
    もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
    プランナー側には以下のような不満があり、

    • エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか?)
    • エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか?)
    • エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか?, オーバーエンジニアリングしてないだろうか?)
    • 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)

    エンジニア側には以下のような不満がありました。

    • 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
    • 開発する機能に関して背景や目的があまり納得できない
    • 開発する機能の優先順位がわからない
    • プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする


    そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
    仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない?とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
    以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。

    • プランナー組織構造の都合上、1人のPOは選出しにくい
    • QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
    • 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)

    私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。

    この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。

  • Liked Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima / Norihiro Hashimoto - ミッションクリティカルでマルチベンダーな製品開発をスクラムに移行する ~ リモートアジャイル開発20スプリント目 ~

    45 Mins
    Thought & Practice
    Intermediate

    私が所属する永和システムマネジメントは、2018年10月に、福井本社にアジャイル開発拠点「Agile Studio Fukui」を立ち上げました。

    Agile Studio Fukui では、Web/モバイル/IoTサービス等、リモートでのスクラム開発プロジェクトが複数実施されておりますが、そのうちの一つは、ミッションクリティカルな新製品開発のためのプロジェクトで、競争力向上のために、ウォータフォールからスクラムへの移行を実施中です。

    マルチベンダーゆえのマルチカルチャー/リモートでの開発/要員を育成しながらのプロジェクト遂行など、複数の課題を抱えつつ、エンジニアとスクラムマスターの継続的な改善努力により、チームは目に見えて成長しています。

    今回の発表では、ここまでのスプリント(および、準備段階)における取り組みについて、チームビルディングや、リリース計画などスクラムイベントにおける具体的な工夫と成果(および、苦労)について、このチームのスクラムマスターである、橋本と共にふりかえることで、私たちの得た知見を、皆さんに共有したいと思います。

  • Liked Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta / Ken Tajima / Sanae Endo - Biz、Dev、そして「IT部門」と企むアジャイル

    20 Mins
    Advanced Case Study
    Intermediate

    大きな企業の中で「IT部門」と協調して課題解決を目指すには?

    とあるアジャイルプロジェクトの取り組み事例を、ビジネス/開発/IT部門それぞれの観点から共有します。

  • Liked Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Tadataka Ebihara - プロダクトオーナーは突然に 〜メカ屋出身プランナーと奇妙な冒険〜

    20 Mins
    1st Step Case Study
    Beginner

    プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。

    確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。

    一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。

    未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。

    このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。

    本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。

    複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。

  • Liked yumi kanehira
    keyboard_arrow_down

    yumi kanehira - チームが、二度と同じ目に遭わないようにする事を目的に、長期リプレースプロジェクトのビックふりかえりをした話

    yumi kanehira
    yumi kanehira
    ScrumMaster
    KDDI Commerce Forward
    schedule 5 months ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    約1年がかりのプロジェクトが(最後は炎上しながらも)無事に終わったため、
    ビックふりかえりを計画・実施する話をします。

    少しでも多くの方にとって、ビックふりかえりの参考になったり、
    今回私のチームが経験した事を共有できればと思います。

    ■プロジェクトの背景

    ・なんちゃってスクラムだったが途中で止めた

    ・コンポーネントチーム

    ・ステークホルダーが多い

    ・リリース日と機能が固定

    ・メンバーの増減が激しい

    ・レガシーなシステム起因の制約

    ■ビックふりかえりについて

    ・振り返りの計画(時間や目的の整理等)

    ・実施した内容(前日にやること・当日の流れ等)

    ・実施した結果

  • Liked Tomokazu Hiroi
    keyboard_arrow_down

    Tomokazu Hiroi - 心理的安全性の上げ方(スクラムと1 on 1を導入した、とある実例)

    Tomokazu Hiroi
    Tomokazu Hiroi
    System Owner
    Fringe81
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner
    どうやったらチームメンバーがハッピーに働きつつ、最高のパフォーマンスを出せるのか?

    その答えの一つの鍵として、心理的安全性に着目
    こんな問題に直面したことはありませんか?(これは私自身が直面した問題の一部です)

    • - 問題があっても報告があがってこない
    • - 生産性が低い
    • - モチベーションが低く、何事にも後ろ向き
    • - 積極的な新しい意見が出てこない
    • - 議論が建設的に行われず、空回りしがち

    心理的安全性をあげることで、上記の問題は解決できるかもしれません
    手法として、スクラム、1 on 1を取り入れたことで、どう心理的安全性があがったか、どんなメリットがあったかをお話します
  • Liked Tomokazu Hiroi
    keyboard_arrow_down

    Tomokazu Hiroi - そのスクラムは定着するか?スクラム導入と、チェンジマネジメント

    Tomokazu Hiroi
    Tomokazu Hiroi
    System Owner
    Fringe81
    schedule 5 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner
    このセッションは、心理学とチェンジマネジメントをベースに、新しい仕組みを取り入れるコツをお伝えします

    スクラムや新しい仕組みを導入したものの、メンバーが期待した通りについてきてくれない
    教科書通りのやり方なのに、何故かうまく回らない
    皆、導入に賛成だったはずなのに、気づけば管理ができていない

    人は新しいことにチャレンジしたいという気持ちと、変更コストに対する恐れの両方を持っています
    組織に新しい仕組みを取り入れる時、反発が起こるのは仕方がないことかもしれません
    だからといって新しい仕組みを取り入れず、ずっとレガシーなやり方を続けるわけにもいきません

    私自身、新しい仕組み(スクラム含め)の導入に失敗する瞬間、成功する瞬間を何回も見てきました
    そこから学んだことを、心理学やチェンジマネジメントの理論を交えながらお話します
  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Kei Nakahara / Yasushi Hagai - Energize your Team with Games, Drawing and Communication.

    45 Mins
    Thought & Practice
    Beginner
    • How do we motivate people?
    • How can we improve teamwork?
    • How can we reward our colleagues for their good work?

    People are the most important parts of an organization and you must do all you can to keep people active, creative, and motivated.

    In this energizing workshop you will learn three tools of Management 3.0 which you can use at the next day in your office:

    • Personal Maps for increasing Communiction & Collaboration
    • Moving Motivators for improving engagement
    • Kudo Cards for saying thank-you
  • Liked Kotanin
    keyboard_arrow_down

    Kotanin - スクラムに「煽り」を取り入れた新しいチームビルディング

    20 Mins
    Advanced Case Study
    Intermediate

    「え?いけるっしょ?」

    感情を逆撫でしかねない煽り文言が、メンバーを鼓舞する魔法の言葉になる。
    そんな心理的安全性の高いチームこそ、チームビルディングの目指すところ。
    チームメンバー全員がフラットに煽り合い、鼓舞し合い、高め合う。
    自立してるって素晴らしい。

    スクラムに「煽り」という激辛スパイスを加えて、
    安定したチームを作り上げるに至ったまでの経緯や苦難、
    行動心理学や哲学や組織論から拝借した隠し味、
    それらを調和するクッキングをお見せします。

    隣のスクラムは青く見える、そんな素敵なチームの組成についてのお話。

  • Liked Yosuke Kammei
    keyboard_arrow_down

    Yosuke Kammei - 「人やチームの主体性を高めるアプローチ」を探究するワークショップ

    Yosuke Kammei
    Yosuke Kammei
    Sr. Manager
    SEPTENI ORIGINAL,Inc
    schedule 5 months ago
    Sold Out!
    45 Mins
    Thought & Practice
    Intermediate

    皆さんが関わるScrumチームやプロジェクトメンバーは、業務を主体的に取り組めていますか?
    またもっと主体性を高めることが出来れば、より効果的な活動が出来るのに・・・と思うことはありませんか?

    この時間は「探究型学習」のアプローチを活用し、参加者自身の「主体性に関する悩み」を解決するためのヒントを探ります。具体的には2~3人程度でグループを作り、ご自身の「(相手の)主体性を上げたいと思った出来事」についてグループ内の会話を通じて、解決方法を探っていただきます。

    また会話を深めることに役立ちそうな「科学理論」もインプットさせて頂き観点を増やしながら、現実世界の課題解決につなげるヒントを持ち帰って頂けたらと思います。