昨年のRSGT2019などでも好評だった、心理的安全性ゲームを体験するワークショップです。

  • 心理的安全とは、気兼ねなく話せると全員が信じている状態である
  • 心理的安全がないと組織やチームとしての学びや成長が得られない
  • 心理的安全がある状態で困難な仕事に取り組んで初めて効果が上がる。ぬるま湯や仲良ししクラブが好ましいわけではない
  • 心理的安全を高めるコミュニケーションのやり方を自分たちで発見する

こうしたことを、ゲームを遊び、ふりかえりをし、解説を聞きながら理解していきます。ゲームは簡単に遊べ、時間も短く、自分の現場でやってみることもできます。

 
 

Outline/Structure of the Workshop

  1. ゲームの説明(10分)
  2. ゲームを遊ぶ・1回目(15分)
  3. 心理的安全の解説(15分)
  4. ふりかえりをして、ゲームを遊ぶ・2回目(30分)
  5. 全体ふりかえり(5分)

Learning Outcome

  • 心理的安全性とは何か
  • チームの成長になぜ心理的安全が欠かせないのか
  • 心理的安全をつくるコミュニケーションとはどんなものか

Target Audience

チームで仕事をしているメンバーやリーダー

Prerequisites for Attendees

ありません

Slides


Video


schedule Submitted 1 year ago

  • Kazutaka Matsusaki
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

    Reginal Scrum Gathering Tokyo 2020 にて講演させていただいた内容の再講になります。
    ぎゅっと圧縮してお話しさせていただきます。


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

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

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

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

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

    Jun Yamamoto - (自称)エバッキーの愛弟子!が札幌でエンタープライズシステム開発のスクラムマスターをしてみたお話

    20 Mins
    Talk
    Beginner

    基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。

    そういった固定観念が社内外充満している中、
    SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
    札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。

    特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
    札幌のエンジニア達がLeSSに近しい姿をトライ&エラーしていく
    天竺への道程(現在進行形)を等身大で聞いていただければと思います。

    • アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
    • 複数拠点横断スタッフとのリモートワークによるチーミング。
    • クライアントとのカルチャーギャップ。
    • 自分自身含めたメンバーのマインドセットの成長。
    • などなど・・・

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - Happy Lucky XP ― ケント・ベックに教わったこと

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    “I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.”

    ― J.R.R. Tolkien, The Two Towers

    スクラムのイベントなので、エクストリームプログラミングの話をしたいなと思いました。

    私が最初にアジャイルに触れたのは、2000年頃、XPの記事や書籍、さらにXPを導入したプロジェクトにプログラマーとして参画したときでした。まだアジャイルという言葉はありませんでした。ペーペーのSIerプログラマーだった私はXPと遭遇して、プログラマーがさらに大好きになり、同時にただプログラミングが好きなプログラマーではいられなくなりました。プログラミングは趣味も含めて10年以上、フルタイムジョブとしては2年目くらいという、XPに触れたタイミングは幸運でした。

    XPはプログラマーの仕事を楽しくし、人生を幸せにします。プログラマーは指示通りに手を動かす歯車ではなく、創造性と専門知識を持った一個の人間です。同時に、プログラマーは安穏としてプログラムを書いてるだけでは済まず、顧客やその他すべての職種の人とコミュニケーションし、協力して、やるべきことをしなければなりません。プログラマーはプログラマーだから愛されるのではなく、生み出す価値が故に愛されます。XPは究極(エクストリーム)なので、プログラマーは究極的に最高の仕事をします。時間不足やスキル不足に追われる代わりに、ユーザーの期待と品質のバーを最高に設定して越えていく仕事が楽しくないわけがありません。プログラミング、ものづくりという仕事の意味をXPに塗り替えられた私は幸運でした。

    2000年に発行された『XP エクストリーム・プログラミング入門』(第1版)を見返すと、XPのユニークなプラクティスとして紹介されているものがいかに当たり前になっているかに驚かされます。テスト自動化、リファクタリング、コードの共同所有、継続的結合、シンプルな設計。当時の私にとっては、XP、Java、オブジェクト指向設計は不可分なものでした(時代背景的にも多くの人が似た状況だったのではないかと思います)。アジャイルなソフトウェア開発が発達するのと、並行して進歩する開発技術は表裏一体でした。将来当然となるプラクティスに早く触れられたのは幸運でした。

    XPは日本において(だいたい世界でも)現在に続くアジャイルのムーブメントを引き起こした先鋒であり第一の波でした。私はXPに心酔するのと同時にコミュニティに熱狂しました。アーリーアダプターの人たちがたくさん引き寄せられました(一過性ではなく、いまでもずっと活動されている方もたくさんいます)。そうした中で、コミュニティに参加したり、登壇の機会をもらったり、運営側を経験することにもなりました。人前で話をするなんてまっぴら御免と思っていた私にとって、幸運な機会がたくさんありました。

    XPはソフトウェアの作り手と使い手とを引き裂いた人工的な傷口を癒やし、全体性を取り戻す試みです。私は最初にXPに触れられて幸運でした。XPはプログラマーとして守るべき規律を示しながら、プログラマーの本来の役割は顧客やユーザーに歩み寄り、価値を生み出し続けるために一緒に働くことであるという、長く続く道にそうと知らずして進み始められたからです。オブジェクト指向設計やJavaといった技術だけを追求していたら、もしかしたら一生見つけられなかった道です。幸運だったとしか言えません。

    (上記はプロポーザル時点で考えている概要で、今後おおきく変化する可能性があります。4月になったら「XP: An East Asian smiley emoticon representing a happy face sticking out its tongue.」みたいな話になってる可能性もあります。悪しからずご了承ください)

  • Mizuki Kusakabe
    keyboard_arrow_down

    Mizuki Kusakabe - ゼロからつくったリモートスクラムチームはスクラムに挫折し解散しました

    20 Mins
    Talk
    Beginner

    「ゼロからつくる!リモートスクラムチーム」からタイトルを変更しました。

    プロポーザルを出した時点では以下のようなことをお話しするつもりでした。

    小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

    会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

    その状況から、

    • いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
    • 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
    • リモートでもチームとしてワークするために試行錯誤している話

    をお伝えしたいです。

    それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。

    でも、一部メンバーによってプロジェクトは推進されています。

    チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。

  • Atsushi Nagata
    keyboard_arrow_down

    Atsushi Nagata - ここがすごい!モブプログラミング

    Atsushi Nagata
    Atsushi Nagata
    Agile Coach
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、どういうことでいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

    サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

    私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりを徹底的に取っていきました。そこからモブメトリクスというものができて来ました。そのメトリクスを改善していくうちに、虜にさせるモブのメカニズムが見えてきました。そこには、チームが不確実な問題に取り組む際のメンタリティーを高める効果ばかりでなく、高い品質をはじめから組み込んでいく仕組みを支える効果もありました。

    このセッションでは、その膨大な情報から見えて来たモブの活動の何がすごいかをご紹介したいと思います。

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - It dependsから脱却するスクラム

    50 Mins
    Talk
    Intermediate

    チーム、組織、会社、役割、契約、業種・・・
    私たちの仕事にはいろんな状況があるので、つい、
    「It depends(ケースバイケースだね)」
    と言いたくなってしまうときがあります。

    しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

    こんにちは!

    こんにちは、及部です。

    私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

    組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

    伝えたいこと

    教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

    つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ?」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

    それでは、スクラムフェス札幌大会でお会いしましょう。アディオス!

  • Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 Scrum Fest Sapporo特別編

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    会社の文化(カルチャー)変革の7年間の軌跡。

    2013年ごろ、色々な問題が噴出し、会社としても個人(経営者)としてもどん底の状態でした。
    そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化(カルチャー)が形成されるようになりました。

    その過程のなかで2017年8月「Joy,Inc.」に出会いました。
    「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

    今回はScrum Fest Sapporo特別編として
    1.コロナ禍によって全社リモートワークになり発生したメンバー間のコミュニケーションの減少という課題とそれを解決するために行っていること
    2.Menlo Innovations の現在の状況
    についてもお話したいと思います。

    https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

  • Ikuo Suyama
    keyboard_arrow_down

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

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

    はじめに

    本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

    見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
    本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
    見積りをやめてから起こった問題やその対処についてもご紹介します。

    また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
    以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
    この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

    Introduction

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

    しかしながら、見積りには負の側面があることもまた事実であるように思われます。
    RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

    そもそも、なぜ見積りが必要なのでしょうか?

    そして、本当に必要なものは見積りなのでしょうか。

    この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか?」という仮説にたどり着きました。
    それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
    以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

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

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

    見積りの負の側面と価値

    見積りの負の側面について、私達の考えをまとめます。
    私達が考える見積りの負の側面は、以下の「3M」に集約されます。

    • 数値化による「コミット圧力」… 納期の「ムリ」
    • 数値化による「仕事量の最大化」 … 仕事の「ムダ」
    • 数値化による「正確であるという錯覚」 … 精度の「ムラ」

    そしてこれらは、見積りを「数値化すること」により発生すると考えています。

    もちろん、見積りは負の側面ばかりではありません。
    見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

    見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
    計画づくりとは価値の探求なのだ。
    – アジャイルな見積りと計画づくり

    見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
    見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

    これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

    見積りの負の側面の根源である「数値化」を行わず、
    見積りから取り出したい「価値」を抽出する手法

    と定義づけています。

    スクラムと見積り

    私達はスクラムを実践しています。

    見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
    見積りをやめて以来、ずっと問い続けてきました。

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

    • リリース計画づくり … PBIの優先順位付け
    • スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
    • 進捗管理 … 残作業を確認し、計画を更新する

    見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
    これが私達のたどり着いた答えです。

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

    • 優先順位付け / バックログリファインメント
      • PBIのサイジング … 直近のPBIを 1スプリント以下のサイズ に調整
      • C3D(Cost of Delay Divided by Duration)
    • キャパシティ / スプリントプランニング
      • PBIのスループット
      • スプリントゴール
    • 進捗管理 / デイリースクラム
      • SBIのスループット
      • モンテカルロ法 … 過去データからの ‘予測’
    • スプリント(開発作業)
      • モブプロ
        • WIP制限 … 安定性・予測可能性の向上

    「見積しない」 開発と現実

    このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
    通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

    • 「見積りしない」の始め方
      • どのように上司を、ビジネスを巻き込むのか?
    • 「見積りしない」計画づくり
      • どのように先の見通しを立てるのか?
    • 「見積りしない」開発の課題
      • 見積りをやめてから、チームに降りかかる課題と対応
    • 「見積りしない」で納期を守る
      • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには?

    まとめ

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

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

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

  • Yasumasa WATANABE
    keyboard_arrow_down

    Yasumasa WATANABE - 目標管理はOKRで、プロダクトはScrumで。

    50 Mins
    Talk
    Intermediate

    ここ最近、OKR(Objectives & Key Results)が話題を集めていますね。

    Scrumを実践する人も、そうでない人も、組織に属している限りは、なんらかのやり方で目標を設定し、
    その結果を受けて、業績評価、個人への査定を受けるのではないでしょうか。

    OKRのよって運営される組織、Scrumによって生み出されるプロダクトは
    どっちが欠けてもうまくいかない両輪のようなものだと、僕は考えています。

    僕が所属している組織では、OKRもScrumも数年前から導入しているという状況でしたが、
    そのどちらも「何かがおかしい」「どこかがおかしい」「いや、全体的におかしい」といった
    どこにでもありそうな、伸びしろのある状態だったのです。

    例えば、次のようなことがあったとします...
    (あくまで例えばですよ、例えば)

    • OKRなのに、数値管理として、その達成度をそのまま評価に用いられている
    • チーム開発のはずなのに、OKRで定めた目標以外の全てが軽視される
    • 開発プロセスではインパクトを出している人の査定評価が高くない

    そんな中、ProductOwnerの役割のProduct Managerとして、
    OKRもScrumも合わせて幸せになれるよう、取り組んだことをお話しできれば
    と思います。

    • OKRに興味がある、導入しようとしている、導入したけどうまくいかない
    • ScrumMasterだけど、組織改善がうまくいかない
    • Product Ownerだけど、組織関連はSMに任せっぱなし/もっと任せたい
    • まっとうに評価されたい(!)

    という方にぜひ、共有したいなと思っています!

  • Yoshihiko Kamata
    keyboard_arrow_down

    Yoshihiko Kamata - なんちゃってScrumからの立て直しをした話

    20 Mins
    Talk
    Beginner

    私たちのチームではかつてトップダウンでScrumが導入され、2つのチームで取り組みが始まりました。半信半疑だった私たちは熟練者にレクチャーをいただきながら試行錯誤していましたが、半年ほど経ち、1チームはScrumを止めてしまいました。残るチームも、Scrumを継続こそしていましたが、成果を出せませんでした。

    導入から約2年が経ち、チーム構成は再編され、開発プロセスの見直しも実施されました。
    今回のセッションでは、何がいけなかったのか?失敗例を交えながら、現場で何を感じ、何を考えながら改善活動に取り組んでいるのかを紹介したいと思います。

  • Cherie Marina Cheong
    keyboard_arrow_down

    Cherie Marina Cheong - 初めてのスクラムマスターが三つの国をわたるチームを一年間リードしてみた経験共有

    20 Mins
    Talk
    Beginner

    新卒で入社し、2.5年目にスクラムマスターをやらせていただきました。
    (もはや、やるしかなかったですw)

    元々リーダーシップやチームワークが好きとは言え、いきなり三つの国をわたるチームのスクラムマスターになり「えええ?!」と思いながら、あっという間に一年間のプロジェクトを過ごしてきました。

    国における違いの上、20人近くのチームに様々な国籍を持ち、
    人間って本当に面白いなーと思わせてくれた一年でした。
    「えええ?!」と思った瞬間が数えきれなくなったり
    これまで勉強してきたスクラムやアジャイルの原理を違反しまくったりしたけど
    「出来ないこと」ではなくて「出来ること」に集中して
    常に改善を求めることが完璧なプロセスを完璧に適応するより大事だと気が付きました。

    自分の経験はまだまだ浅いかもしれませんが、それに関わらず
    非常に濃くてユニークな一年を過ごしてきましたので
    苦労したこと、うまく行った・行かなかったこと、次回やりたいこと、
    全てオープンに話たいと思います!

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki - コミュニティ活動ついてちょっとだけ考える from 福岡

    10 Mins
    Talk
    Beginner

    コミュニティ活動について福岡で活動しているスクラムコミュニティをベースに紹介します!

    札幌と福岡、距離にしたらものすごい遠い地ですが、地域の状況などはわりと近いものがあるのでは?と勝手に想像しています。

    そんな遠い地福岡でも2019年5月にスクラムのコミュニティを立ち上げました。
    立ち上げてからこれまでの活動など紹介できればと思います。

    箸休めに他のコミュニティについて触れてみるのはいかがですか?

  • Tomonori Abe
    keyboard_arrow_down

    Tomonori Abe - 札幌の地でスクラムを実践して得た失敗そして改善

    Tomonori Abe
    Tomonori Abe
    SE
    トラスティア株式会社
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    数年前から札幌でスクラムを実プロジェクトにて実践してきました。

    まわりではスクラムの事例が少なく、なかなか相談できる環境も多くはない状況でした。

    その中での収穫は、自分たちで考え実践したことにより多くの失敗を経験することができたことです。

    このセッションでは、これまでの経験から得た[失敗]そしてどのように[改善]していったかを紹介します。

    スクラム視点での正解ではないかもしれないですが、これからスクラムに取り組む方や実践していてうまくいかない方の微力ながらヒントになればと思っています。

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - Empathy Box体験会

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    75 Mins
    Workshop
    Beginner

    Empathy Boxというカードゲームを体験する会です。グループでのコミュニケーションを改善するツールとして、自分自身の深いところから湧き出す物語りの場として、全力で人の話を聞くという心躍る体験として、ユニークなEmpathy Boxを体験してください。

    Empathy Boxでは「話したいことを気兼ねなく話せる場」を作ります。話者はStorytellerと呼ばれ、自分が語りたい話をします。好きな話をしていいのですが、「大事なこと、印象的なこと、自分のこと(meaningful, memorable, and about me)」という指針があります。

    そして話者以外の人は、発話禁止です。聴き手は反応カードをそっと押しやることでなんらかの表明ができ、話者から聞かれて初めて感想や意見を言えます。反応カードは5種類あり、反応の種類をカテゴリ分けしたものです。

    • show some LOVE (ありがたい)
    • help me UNDERSTAND (わかりたい)
    • share an OBSERVATION (返したい)
    • offer alternative PERSPECTIVE (教えたい)
    • WILD CARD (好きにしたい)

    Empathy BoxはTribeless PLT(マレーシア)の製品です。最近このカードを手に入れて、これはすごいのではないかと思い、体験会を何回か開催しています。本プロポーザルが通れば北海道で初の体験会となります。

  • Masahiro Kimura
    keyboard_arrow_down

    Masahiro Kimura - ABDで「スクラムガイド」を読み直すワークショップ

    Masahiro Kimura
    Masahiro Kimura
    PM /Scrum Master
    Canon
    schedule 1 year ago
    Sold Out!
    45 Mins
    Workshop
    Beginner

    みなさん「スクラムガイド」を読んだことはありますか?

    「スクラムガイド」はスクラムの原点です。初めてスクラムに触れる際に一度は目を通したことがあると思います。

    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    本セッションでは「スクラムガイド」をABDという読書手法を使って読み直し、参加者全員で議論してみようと思います。

    他の誰かと一緒に読むことで、一人では流してしまうような文章や言葉から、新たな気づきや学びを得ることができるかもしれません。また昔読んだ内容でも、皆さんの経験に合わせて何か違う気づきがあるかもしれません。

    私も社内初心者向けスクラム研修で「スクラムガイド」をABDで読んでもらいました。15人で30分程ですが、ざっくりとした概念の理解とスクラムへの興味を持ってもらえ、その後の研修がスムーズに進んだ経験があります。

    準備も、宿題も、書籍の購入も不要ですので、楽しむ気持ちのみお持ちください。

    本書は日本語版だと実質13ページ程しかありません。肩ひじ張らずお気軽に参加して頂ければと思います。

    このワークショップの主役は皆さんです。


    「スクラムガイド」目次

    スクラムガイドの目的... 3
    スクラムの定義 ... 3
    スクラムの用途 ... 3
    スクラムの理論 ... 4
    スクラムの価値基準... 5
    スクラムチーム ... 5
    プロダクトオーナー.. 5
    開発チーム ... 6
    スクラムマスター... 7
    スクラムイベント... 8
    スプリント ... 8
    スプリントプランニング... 9
    デイリースクラム... 10
    スプリントレビュー... 11
    スプリントレトロスペクティブ... 12
    スクラムの作成物... 12
    プロダクトバックログ... 12
    スプリントバックログ... 13
    インクリメント ... 14
    作成物の透明性 ... 14
    「完成(Done)」の定義... 15
    最後に ... 15


    「ABDとは」

    ABDとは「ActiveBookDialogue」の略であり、
    読書が苦手な人も、本が大好きな人も、短時間で読みたい本を読むことができる新しい読書手法です。

    ABDのすすめ方

    コ・サマライズ:

    本を分割し、まとまったページ毎に参加者に割り当てる。参加者は割り当たったページを読み、B5用紙6枚程度に要約する。要約した用紙は壁に貼っていく。(アウトプットを求めることで、本への集中度を上げる)

    リレー・プレゼン:

    壁に貼った用紙を使って、各パート毎に自分の担当したページを参加者全員に対してプレゼンしていく。一人3分程度で。(わかりやすく他者に伝える、そういった観点で自分のパートを読める)

    ダイアログ:

    リレー・プレゼン後、参加者全員で疑問や感想を語り合う。(他者と話すことで本への理解を深める、自分では思いつかない解釈を知る)

    ABDのメリット

    1.分厚い本でも手軽に読める(ざっくりとした内容が理解できる)
    2.同じ本を読んでいるので参加者同士で共通言語が生まれる
    3.要約する能力を鍛えられる
    4.プレゼンする能力を鍛えられる
    5.インプット/アウトプット/フィードバックが一度に行える

  • Takahiro Hayasaka
    keyboard_arrow_down

    Takahiro Hayasaka - 開発チームでエンジニアをしながらスクラムマスターとして交わるためのコツ

    Takahiro Hayasaka
    Takahiro Hayasaka
    Scrum Engineer
    Members Edge
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    私が開発チームで開発をしながらスクラムマスターとしてチームに参加することになった経緯と、チームに関わる際に気をつけたことや意識付けるときの関わり方などを双方の視点でお伝えします。

help