複数スクラムチームは大変?〜一緒に考えるお悩み相談室〜

今まさに複数のスクラムチームに携わっている2名が、パネルディスカッション形式でリアルな悩み、困りごとの解決策を模索します。

異なる所属のQAエンジニアなので、いつもとは違う角度からのお話、新たな発見があるかもしれません。

同じような悩みを持っている方、一緒に解決策を考えてみませんか?

  • LeSSの難しさ
  • 情報量が多くて、解像度高く情報をインプットしきれない
  • 成果物が多くなると共有コストもかかるし、コンフリクトしないか心配
  • どのくらいの粒度、解像度で理解すれば良いのかわからない
 
 

Outline/Structure of the Talk

  • 自己紹介
  • パネルディスカッション
  • まとめ

お悩みのネタは事前に決める予定です。決まり次第アップデートします。

また、時間が許す限り、リアルタイムでのお悩み受付もしてみたいと考えています。

Learning Outcome

複数スクラムチームの

  • 悩みの解像度が上がる。
  • 解決の方向性を知ることができる。

Target Audience

複数のスクラムチームに携わっている方、複数スクラムチームで悩みを抱えている方、これから複数スクラムにチャレンジする方

Prerequisites for Attendees

schedule Submitted 5 months ago

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - アジャイルになれない開発入門

    45 Mins
    Talk
    Beginner

    アジャイル開発の解説はたくさんあるので、逆に、アジャイル開発になれない方法をざっくり紹介します。
    成功する方法を見つけるのは難しいけど、失敗する方法を知るのは簡単だったり。

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - スペシャリストになれなくても成長する方法 #5000dai

    45 Mins
    Talk
    Beginner

    ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

    ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

    ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

  • Satoshi Harada
    keyboard_arrow_down

    Satoshi Harada - その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策

    20 Mins
    Talk
    Intermediate

    心理的安全性という言葉、皆様は聞いたことありますか?

    心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

    あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う?」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ!」という声が帰ってくると思います。

    しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか?心理的安全性という言葉がキャッチー(かつ、流行っている)こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

    心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

     

    このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

    そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase / Kazunori Otani / Mitsuo Hangai / Teppei YAMAGUCHI / Tsutomu Yasui / Yosuke Ota / Yudai Moriya - F1 仙台グランプリ'22

    45 Mins
    Talk
    Intermediate

    Regional Super GT 2022、もとい、Regional Scrum Gathering Tokyo 2022を皮切りにスタート、5月の新潟GP、6月の大阪GPに続き、フィードバック1グランプリ'22国内ツアー、好評につき第4弾は杜の都仙台で開催します!
    初回から3戦連続、王座を守るyattom帝国の牙城は突き崩されるのか!?

    開催年月 開催地 チャンピオン
    2022年6月 大阪 yattom
    2022年5月 新潟 yattom
    2022年1月 お茶の水 yattom

    F1のFはFeedbackのFです。
    アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

    この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

    アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
    ポイントの投票は回答者自身と、聴講者によっておこなわれます。
    高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
    最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

    お題と回答の例その1
    お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか?」
    回答1「上司にベロシティについての理解を問うてみてはどうでしょうか?」
    回答2「ベロシティは顧客価値につながる指標なんでしょうか?」
    回答3「デプロイメント頻度は計測できていますか?」

    お題と回答の例その2
    お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
    回答1「テストをサボるとその足枷がどんどん重くなるのでは?」
    回答2「一度テストをまったくしないで進めてみてはどうでしょうか?」
    回答3「プロダクトオーナーを説得する役割の人はいないのですか?」

    出演者の情報です。
    実況:ながせ(miholovesq
    解説:もりや(yudmo
    ドライバー(回答者):よた(yota)、てやまぐ(teyamagu)、やっとむ(yattom)、かっちゃん(katzchang
    その他のドライバーにはこれから声をかけます。
    出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します!

    今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました!!!

    お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
    https://forms.gle/oFih3o1mk6P8gTGK8

  • Imai Takaaki
    keyboard_arrow_down

    Imai Takaaki - アジャイルであり続けるために技術スキルと向き合う

    Imai Takaaki
    Imai Takaaki
    Webエンジニア
    Retty株式会社
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    エンジニアとしてアジャイルなものづくりをし続けるためには、それを実現するだけのスキルが必要です。

    そのスキルのひとつは"技術スキル"であり、私自身の弱さとなっている部分であり、向き合わなければいけないものでした。

     

    あなたはどんな理由で、アジャイルを探求したり、スクラムを実践したり、コミュニティで学びを深めたりしていますか?

    アジャイルの考え方が好きだったり、自分たちの開発に悩みを抱えていたり、より良い価値をユーザに届けたかったり、その理由は人それぞれだと思います。

    私がアジャイルに興味を持ったのは、本質を突き詰めていくような考え方に深く共感し、自分たちもそんな風にものづくりをしたい、と思ったのがきっかけです。

     

    思想を持ちながら、書籍、コミュニティ、カンファレンスでその理解を深めていくことで、本質的に価値を届けていくことはできる、と思いながら新天地へ足を踏み入れた私は、しかし思うように動けませんでした。

    一方そこには、アジャイルのことはよく知らない、と言いながら自分なんかよりもよっぽどアジャイルな人たちがいました。

     

    実践する前にアジャイルの思想を知り、頭の中で理想の世界が膨らみ続けていた私が、いざ実践となった時に突きつけられた「自分の弱み」の話をします。

    いろんな痛みを伴ったので正直言語化するのもちょっと辛いですが、アジャイルであり続けるために頑張ります!!

  • Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto - 品質レベル+1~品質を作りこむ独自のスリーアミーゴスサンド~

    Noriyuki Nemoto
    Noriyuki Nemoto
    senior engineer
    Agile Sapporo
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    「アジャイルチームで品質を作りこむ」
    色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

    ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」(独自イベント)を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

    ### リファインメント

    言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

    • PBIのゴール
    • 設計方針
    • テストの方針+影響範囲

    POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

     

    ### 受け入れ

    私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
    POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

    お気づきでしょうか?
    DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
    良く見ると「実装」がスリーアミーゴスでサンドされています。
    自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

    • スリーアミーゴス
    • 実装
    • スリーアミーゴス

    このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

    • 作ってみたら変なモノができていた(修正)
    • テストが足りていない(追加)
    • お互いに期待値に達していなくてイライラする

    スリーアミーゴスサンドぜひお試しを!

  • Hiroyoshi Takahashi
    keyboard_arrow_down

    Hiroyoshi Takahashi - ど根性学生起業 CTO編 ~ソフトウェアの素晴らしさに目覚めた大学生が起業してみた...そして今~

    45 Mins
    Talk
    Beginner

    東京理科大発(理科大VC出資)ベンチャーShinonome(https://shinonome.io/)を学生創業してから、はや6年。

    現在では、全国の大学と提携をして大学生にIT実践教育の仕組みを提供できるようになり、500名以上のエンジニア・デザイナーを教育・輩出しています。

    しかし、創業期は...

    「金がないので、寸胴で炊き出し?!」「20時間/312日、開発体制!?」

    ソフトウェアとの出会いから、学生起業、今に至るまで赤裸々なストーリーをお話しします。 

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - 意志の弱い自分を許せるようになる(かもしれない)セッション

    Shinya Ogasawara
    Shinya Ogasawara
    -
    -
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner
    • 今日は本を読むぞと決めたけど、結局ゲームをやってしまった
    • 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

    • 貯金をしたいのに、欲しいものがあると思わず買ってしまう

    このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか?私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

    行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

    例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

    このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

    こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

    私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

    このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

    私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

  • Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu - Certified Team Coach(CTC) への道 〜スクラムマスター・アジャイルコーチのスキル探求〜

    Koki Shimizu
    Koki Shimizu
    Senior Architect
    RedHat K.K.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    みなさん、こんにちは!

    アジャイルコーチの清水弘毅です!
    日本在住だとおそらく3人ほどしかいない、CTC認定をスクラムアライアンスから受けています!

    本セッションでは、スクラムマスターやアジャイルコーチの方の、必要なスキルの探求をしていきます。

    私自身がどんな場面に遭遇し、どのように考え、どのような道を辿ってきたかお伝えしますので、スクラムマスターを極めたいと考えている方たちの一助になれば幸いです。

    CSM, A-CSM, CSP-SM, CTC, CECで求められるコンピテンシーに照らし合わせながらお話する予定です。

    スクラムマスターを極めたい方は集まってください!

  • amix edcolor
    keyboard_arrow_down

    amix edcolor - 週6時間でうまくいくスクラムのはじめかた

    amix edcolor
    amix edcolor
    Student
    University of Tsukuba
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    私は筑波大学の情報系の学生です。3年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。

    3年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。

    そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) / Harada Kiro / Miho Nagase - パワポカラオケ「スプリントプランニング Deep Dive」

    45 Mins
    Talk
    Beginner

    当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

    講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ(コーラス:haradakiro)でお送りします。
    いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
    Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

     


    ★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

    前回のプロダクトバックログ(https://slide.meguro.ryuzee.com/slides/107)に引き続き、今回はスプリントプランニングのすべてを完全解説!!


    スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

    ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

    一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

    以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

    • (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
    • (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
    • (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
    • (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
    • (e) スプリントプランニングの前に、先にタスクに分解しておく

    もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば(SCRUM BOOT CAMP THE BOOKも是非読んでみてください)、陥りがちな罠は避けられます。

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


    なお、望ましくないものは、(c)以外のすべてです。

     

  • Takeshi Kaise
    keyboard_arrow_down

    Takeshi Kaise / Ryota Saiga - [オンサイト開催] 初心者歓迎!DoD Cooking Studio

    90 Mins
    Workshop
    Beginner

    スクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。

    そういった方々に向けて、誰しも親しみのある「料理」を題材に、完成の定義(Definition of Done)の理解を助けるワークショップを作りました。

    スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう!

    ※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。→ 直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。

  • Takeshi Kakeda
    keyboard_arrow_down

    Takeshi Kakeda - スクラムマスターの自己理解から始めるチームの生命構造

    Takeshi Kakeda
    Takeshi Kakeda
    Owner
    Zensow
    schedule 5 months ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    概要

    私たちは、これまで外側の世界に対してなにか働きかけをしなければいけない、と考えて改善を行ってきました。

    しかし、本当に私たちが向かうべきは外側ではなく内側だったのです!!

    本講演は、NVC(非暴力コミュニケーション)、ザ・メンタルモデルの知見から、主にスクラムマスターの内側の世界(感情、ニーズ、痛み)に目を向けます。

    生命的な進化を遂げる組織の人間関係において必要とされるのは、表面的なコミュニケーションテクニックではなく、他者に対する理解や共感です。そして、更に重要となるのが、コミュニケーションを行う自分自身に対する理解や共感、つまり自己理解 です。

    これまでアジャイルに20年間向き合ってきて到達したいきいきとしたチームの結論が、自己理解に基づく個人の変容です。

    チェンジ・エージェントたるスクラムマスター自身が、自分自身に対しての共感・理解をすることが、チームの生命構造を生み出す最短距離ではないかという仮説をご紹介した後、自己共感・自己理解についての概要、なぜチームの生命構造を生み出すのに自己理解が必要なのかの説明した後、実際に自己理解を体験するためのワークを行います。

    本講演の最後に、引き続き自己理解・自己共感を行っていく上でのポイントをお伝えします。

  • Kenichiro Okada
    keyboard_arrow_down

    Kenichiro Okada - 組織を変革する最初の一歩に躓いたけど、それはそれで良かった話

    20 Mins
    Talk
    Beginner

    自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。

    1年半前、自分はみんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みます。

    自分が変革をはじめる最初の一人でした。
    初学者でしたが書籍から学び、知識は万全。きっとなんとかすると前のめりでした。

    ところが、憧れた会社や書籍のようにうまくいきませんでした。
    そこにはシンデレラストーリーがあるのではなく、ただただ現実的な問題ばかりがありました。
    その問題の乗り越え方は書籍には載っていません。
    自分で悩み考え、取り組んでみて学習する必要があります。
    形式知ばかりを学び、「最初の一歩」を実践したことのなかった自分は見事に頭でっかちになっていました。
    頭ごなしに知識を押し付けたところで、とうとう組織の支援を受けることはできませんでした。

    初学者が組織の変革をはじめる最初の一人になる場合、経験したことがないため乗り越えられないような問題が出てくることがあります。
    そう考えると、むしろ最初は組織から協力を引き出せないほうが、自然なのではないでしょうか。
    では、初学者が組織の変革をはじめるべきではないのでしょうか?自分はそんなことはないと思います。

    最初の一人が躓いたとき、その後の歩みを止めないためにできることは何でしょうか。

    このセッションでは、組織を変革する最初の一歩の道のりをふりかえり、自分が学んできたことをご紹介します。
    なにぶん昔のことなので、思い出せないところもありますが、書籍には載っていないような自分の実践から学んだお話をご提供できれば幸いです。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Kenta Sasa / Taku Iwamura / Tsutomu Yasui / Yosuke Ota / Yudai Moriya / Yuji Imagawa / Yukei Wachi / yumi kanehira - ワインバーグ先生の未訳本『フィードバック』のエッセンスと読書会の体験

    45 Mins
    Talk
    Beginner

    すべてがフィードバック、なんでもフィードバック - Feedback is Life

    フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

    しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない!と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

    そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

    • すべてがフィードバック、なんでもフィードバック。
    • テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
    • フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
    • フィードバックでは自分自身を大事にすることが大切です。
    • フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
    • 「フィードバックください!」とよく言ったり言われたりしますが、実は……

    みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

    本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

    ぜひ、楽しい時間を皆さんと分かち合いましょう!

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno - 小さく始めるアジャイルコーチの提案

    Shigeo Konno
    Shigeo Konno
    Specialist Lead / Agile coach
    DTC
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    私は、悩んでいました。

    アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。
    もちろん学んでいますし、超優秀なコーチから継続的にコーチングも受けています。
    でも、現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。

    まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。
    そして、自分はいつも、悩んでいました。

    そんなある日、コーチングセッションでコーチから提案を受けました。
    「小さなことでもいいので、現場で日々やっていることを書いて共有して!!」

    当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。
    やってみると、1週間で50個を超えました。
    今は、3週間で100個を超えました。

    「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります
    気づかず繰り返しでやっているものもあります。
    中には、やってみて、傷つくような失敗になったものもあります。
    思いがけずに、素敵な結果に結びついたものもあります。

    もしかすると、僕がやりたいことは
    こういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。

    発表では、私が日々現場でやってきたことを抜粋して紹介します。
    また、繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。

    それら、発表の中で紹介した中から、気に入ったものや使えそうなものを持ち帰っていただいて、
    明日から、皆さんの現場で、小さくな所からでもアジャイルコーチを始めてもらえれば嬉しいです!!
    そして、また、コミュニティの中で結果を共有できる日を楽しみにしています!!

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - チームの関係性をつくるインセプションデッキ

    45 Mins
    Talk
    Beginner

    あなたのチームのインセプションデッキは役に立ってますか?

    インセプションデッキは、書籍「アジャイルサムライ」の中で紹介されたツールです。

    "プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキ"

    インセプションデッキは10個の質問で構成されていて、質問に答えていくことでプロジェクト開始前に確認しておくべきことが明らかになるツールです。これだけ聞くと簡単そうに聞こえますが、実際に現場でインセプションデッキを作成して活用するまでにはさまざまなお悩みポイントにぶつかります。

    「デッキ作成にどれくらい時間を確保すればよいの?」  
    「デッキ作成するときは具体的にどう進めたらよいの?」  
    「デッキを作ったのはいいけれどそのあとどうしたらいいの?」

    本セッションでは、インセプションデッキの紹介からこれらの現場で実践する際のお悩みポイントを解決する方法までお話します。

    また、インセプションデッキは作成したデッキ以上にチームの関係性をつくることに価値があります。ただデッキを作成するだけでなく、チームの関係性をつくるためのインセプションデッキについてお話してみます。

  • Masami Morita
    keyboard_arrow_down

    Masami Morita - スクラムイベント外の振り返り会 体験コーナー 〜相互理解、コミュニケーション強化を目指して〜

    45 Mins
    Workshop
    Beginner

    振り返りはどんな頻度で、どのように実施されていますか?

    私のチーム(複数プロダクトを持つ部署内のQAチーム)では、以下の課題がありました。

    • チームメイトはそれぞれの担当領域があり、業務上関わりが少ない。
    • さらにフルリモート化ということで、そもそも話す機会も少ない。

    そんな時、チームメイトが「月次で振り返り会をやりませんか?」と提案してくれました。

    この会がとっても楽しいので、他の方にもぜひ知っていただきたいと思い、体験コーナーをご用意します。

     

    「初対面の人たちが集まってうまくいくのか?」ですって?ご心配なく!

    • 業務上関わりが少ない
    • 話す機会も少ない

    という中で運用を開始しています。まさに、セッションに参加する私たちと似た状況ですね。

    ワークショップを通して、スクラムイベント外での振り返りのメリットを実感していただくことを目指します。

    そのまま自チームで実施してみるのもよし、カスタマイズして行うのもよし。チーム内外との相互理解、コミュニケーション強化のためのアクションのきっかけになる、チャッカマンのようなセッションを目指します!

  • Atusuke Muratra
    keyboard_arrow_down

    Atusuke Muratra - スクラムチームで実践しているスウォーミング「キャプテン制度」の紹介

    Atusuke Muratra
    Atusuke Muratra
    Engineer and Scrum master
    Cybozu
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スウォーミングとは、ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。私が所属しているスクラムチームでは、最も優先順位が高いタスクを最速で完了させることを目的にスウォーミングを実施しています。

    スウォーミングの手段の1つにモブプログラミングがあります。私たちのチームも結成当初は、フロー効率最大化のためモブプログラミングで1つのタスクに群がっていました。しかし、開発が進みタスクの不確実性が下がってくると、開発メンバーは「フロー効率重視の開発スタイルを維持したままリソース効率を高めていきたい」と考えるようになりました。

    そこで、Swarming: One-Piece Continuous Flow** のキャプテンの仕組みを参考に、ソロプログラミングを主とした開発でもフロー効率が下がらない方法を編み出し、チームに適用しました。私たちはこの仕組みをキャプテン制度と名付けて運用しています。

    本セッションでは、スクラムチームで実践しているスウォーミングの紹介、キャプテン制度の策定の背景、得られた効果についてお話ししたいと思います。また、私自身スクラムマスターとエンジニアを兼務している立場であるため、スクラムマスター、エンジニアそれぞれの立場で、キャプテン制度を運用してみた所感についても共有させていただきたいと思います。

  • Yutaka Shiraishi
    keyboard_arrow_down

    Yutaka Shiraishi - 製造業のアルプスアルパイン スクラム奮闘記 ~3年間の難所・失敗・学び~

    20 Mins
    Talk
    Beginner

    設立74年目のアルプスアルパイン株式会社では、数々のカーナビゲーション、音響機器、電子部品を開発、製造、販売しています。

    約3年前、自発的に「スクラムやってみない?」と始めた私の所属チームは、現在もスクラムで業務を進めています。

    このセッションでは、これまで沢山の難所・失敗を経験しながら一歩ずつ成長してきた、私の所属チームの奮闘記をご紹介します。

    どのような難所・失敗が発生したか、それらにどう立ち向かったか、結果どうなったのか、をできるだけ具体的にお話する予定です。

help