スクラムマスターって何?-初心者スクラムマスターからDEVへのジョブチェンを通してSMを学ぶ

location_city Osaka schedule Jun 26th 02:25 - 02:45 PM place 三河 people 10 Interested

スクラムマスターの皆さん、スクラムマスターって難しいと思いませんか?私が新人スクラムマスターになった時、いろんな困惑がありました。

 

「開発者、POとどう関われば良い?」

「何か問題がありそうだけど、何が問題か見えてこない...」

「スクラムマスターってPMじゃないはずなのに...」

 

初めてスクラムマスターとして参加したPJで直面した様々な課題。スクラムフレームワークを落とし込むのは現場である。分かっていたようでで分かっていなかったその事実を目の前に突きつけられました。「スクラムマスター」というロール、ひいてはスクラムの難しさを実感しました。

その後、突然DEVへのジョブチェンジ。困惑の中見えてきたのは「開発者としてスクラムマスターにやってほしいこと」「スクラムマスターになったらやりたいこと」でした。

今回はスクラムマスター時代の困惑と、DEVへのジョブチェンを通してわかったスクラムマスターに求める事などをお話しできればと思います。

 
 

Outline/Structure of the Talk

  • プロジェクト概要
  • 新人スクラムマスターの悩み
  • SM To DEV
    • 開発者とスクラムマスターが見えている世界の違い
    • スクラムマスターのしたい事と開発者のしたい事
    • 開発者から理想のスクラムマスター像
  • スクラムマスターって何?
    • サーバント「リーダー」
    • チームのレベルに応じてスクラムマスターは「変化」しなければいけない

Learning Outcome

  • スクラムマスターとしての振る舞い方
  • DEVが出来たら良いこと
  • スクラムマスターが出来たら良いこと

Target Audience

スクラムマスターになりたての人、開発者としてスクラムPJに参画している人

schedule Submitted 3 months ago

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - 「モンダイ」が現れた!ゲームでアジャイルを練習しましょう!

    20 Mins
    Talk
    Beginner

    プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

    でも、もしプロダクト開発がゲームだったら・・・

    コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

    そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

  • Masamichi Otsuka
    keyboard_arrow_down

    Masamichi Otsuka / Hideo Kobayashi - 経験ゼロからはじめる!10年以上続くプロダクトのアウトカム創出戦略

    45 Mins
    Talk
    Beginner

    アジャイルの浸透によってプロダクトがアウトカムに目を向けることの重要性が認識されるようになりました。では、従来型の開発プロセスで10年以上開発を続けてきたプロダクト開発チームは、どのように取り組めばアウトカムに目を向けたアジャイルな開発に転換できるのでしょうか?

    今から2年前、10年以上の歴史を持つプロダクトが新たなビジネス領域に参入するためにチームを再結成して新機能を開発していくことになりました。正解がないレッドオーシャンのビジネス領域に飛び込んだ我々はまず開発プロセスをアジャイルに転換する必要性を感じてスクラム開発を取り入れようと試行錯誤していました。そんな中、関西でアジャイルコーチとして活動されている中村洋さんと秋元さんが開催していた相談会をたまたま見つけて相談しました。そこでホワイトボードの中央に書かれた言葉が「アウトカム」でした。

    何のためにプロダクト開発をアジャイルにするのか?開発プロセスを変えてアウトプットを増やすだけではなく、ビジネスの成果=アウトカムにつなげなければ我々の課題は解決しないと気付かされました。「アウトカムは何か?」を問いかけ続けてプロダクトを成長させていくことがアジャイルの本質だと気付きました。

    アウトカムを得るためにはプロダクトとその顧客をよく知る人の存在が重要だと考えました。そこで、チームで一番のベテランエンジニアが経験ゼロからプロダクトマネジメントを担当することになりました。そこから1年間、まずは開発チームにスクラムを取り入れて、新体制のアウトプットを安定させる事に取り組みました。その間にプロダクトマネージャーはスクラムのプロダクトオーナーとしての振る舞いを学びました。そして2年目、プロダクトのアウトカム創造をチーム目標に設定して本格的にプロダクトマネジメントに取り組みました。

    2年前の再結成からチームのマネジメントを担当しているエンジニアリングマネージャーと、自身も新たなステージへ飛び込んでチャレンジしているプロダクトマネージャーが、アジャイルを取り入れてプロダクトのアウトカム創造に試行錯誤してきたチームの取り組みについてそれぞれの視点でお話しします。

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno - なんちゃってアジャイルコーチが、コーチングを受けて気づいたことを共有します

    Shigeo Konno
    Shigeo Konno
    Agile coach
    NEC
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイルでは、なぜ支援者がトレーナーではなくコーチなのか?
    どっかに引っかかりを感じながら、でも、なんとなく見ないふりをして、アジャイルコーチのマネごとをしてきました。
    アジャイル支援サービスを構築して、販売して、徐々にお客さんからも評価いただくうちに、
    自分がやっていることが本当にアジャイルコーチなのかに自信を持てなくなってきました。

    ある日、流石に見ないふりが苦しくなって、
    コーチを探し始めたら、わざわざ時間をとってたくさんのコミュニティの仲間が相談に乗ってくれて
    スーパーコーチのAkiさんにたどり着きました。

    現時点では導入となる6回のセッションが終わった段階、
    旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

    ※発表内容は個人の主張・主観であり、所属している組織とは関係ないものになります

  • Kei Nakahara
    keyboard_arrow_down

    Kei Nakahara - 老舗メーカーにみんなでアジャイルを導入してみました ~「俺がやる!」から「みんなでやる!」に至るまで~

    Kei Nakahara
    Kei Nakahara
    Manager
    コニカミノルタ(株)
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

    2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
    一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
    さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
    さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

    ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

    現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - 開発が加速していくために、テストコードを書き始める前から考えるべきテストの話

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    システム開発において、テストは切っても切り離せない存在です。
    しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか?
    実は、テストコードを書き始める前に既に勝負は決まっています。

    本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

    本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

  • Koki Kawagoi
    keyboard_arrow_down

    Koki Kawagoi - スクラムマスターの任命&育成法の紹介2 〜学習科学に基づいた解説を添えて〜

    45 Mins
    Talk
    Intermediate

    皆様は、組織でスクラムマスターをお願いするときに困ったりしていませんか?
    また、スクラムマスターが、成長していると感じますか?

    多くのチームの見てきましたが、スクラムマスターの任命時から育成において
    うまく仕組みが作れている組織はあまりありません。

    スクラムマスターの任命にうまくいかなかったり、育てられないと、
    スクラムチームのアウトプット・アウトカムの向上がすごく遠回りになってしまいます。

    そこで、これまで私が実施してきた方法を学習科学の観点から解説しながら、
    スクラムマスターとしての任命から育成の方法について紹介します。

  • manami Ozawa
    keyboard_arrow_down

    manami Ozawa - 外部メンターとして現場に関わる私がメンバーとの会話で大切にしていること

    manami Ozawa
    manami Ozawa
    Freelance
    Freelance
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    スクラムの活動にはチーム内で話す場面がたくさん設計されていると思います。
    話すという行為は言われてみると当たり前なのかもしれないのですが
    ・ちゃんとチームのメンバーと話せているのか
    ・聴く耳を持てているのか
    ・チームメンバーの気持ちを尊重できているのか
    ・個々のキャリアに向き合えているのか
    といった観点を振り返ってみるとどうでしょうか。
    話すということはちゃんと考えると結構難しいことだと思います。

    私は1on1ミーティングを外部の立場から行うなど、職場のコミュニケーションに特化して組織を支援しています。
    一見、1対1のコミュニケーションだから、チームの話とは違う印象をもつかもしれません。
    でも仕事を行う以上、人と関わるのは必然。複数人行ううちに共通の課題も見えてきます。
    いろんな現場にいくと、対話をしているようでできていない現場をよく見ます。
    もちろんこんな風に書いている私もうまく話せなかったなぁという体験はあります。

    このセッションでは、「外部メンターとして現場に関わる私がメンバーとの会話で大切にしていること」として職場のコミュニケーションを行う上でどんな考え、理論をもとに普段行なっているのか、そこを考えるに至った背景や時に失敗したことなどをお話ししたいと思います。話すこととはどういうことかをセッション参加者と一緒に考えられたら嬉しいなと思っています。

    ※参考スライドとして先日発表した資料を添付します。
    この内容をそのまま話すわけではないですが、雰囲気や大枠の流れが似たものになるかと思います。
    可能な限り新作を加えた形でお話ししたいと考えています。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - コミュニティ活動で得られた知識と希望~オンライン勉強会に半年で200回参加して感じたこと~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

    そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

    素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
    気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

    そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

    今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

  • Ryuku Hisasue
    keyboard_arrow_down

    Ryuku Hisasue - 良いチームを形成する方法 〜リーダーのいない組織を大学生が挑戦〜

    45 Mins
    Talk
    Beginner

    このセッションでは,大学のPBL(Project Based Learning)でリーダーのいない組織を形成し,その活動の中でどのようにチームが成長してきたかをお伝えします.

    いま,日本の大学ではPBLという学習方法が広く実施されています.PBLとは,実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって,チーム開発やチームマネジメントの手法について学ぶことができる学習手法です.私が所属する大学でもPBLのカリキュラムがあり,スクラムを用いてプロダクトを作るという経験を得ました.しかし,私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました.そして,その結果として,とても良いチームを形成できたと感じています.

    リーダーもいなく,開発初心者が集まるプロジェクトで,どのようなことに苦労したか紹介・分析し,そのうえでチームをより良くするためにはどうすればいいかお話ししていきます.

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / kyon _mm / Mori Yuya / Toshiharu Akimoto - Deep Dive Experts - 達人が見ている世界を覗いてみよう -

    90 Mins
    Talk
    Beginner

    達人たちが見ている世界を覗いてみませんか

    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • eroccowaruico  
    keyboard_arrow_down

    eroccowaruico   - 戦いません勝つまでは(弱虫が学んだ大切なこと)

    45 Mins
    Talk
    Beginner

    開発のマネージャー職として採用されたはずなのに、
    気がつけばなぜかユーザー部署でのオペレーター業務をやらされ、
    エンドユーザーからの電話を取ることになった弱虫のeroccowaruico。

    サポート対象はバグだらけで仕様も不明確で資料もない大規模展開システム。
    エンタープライズ環境に理解のないシステム開発部署とエンドユーザーの板挟み。
    そして僕に下される開発部署とのコミュニケーション禁止の判断。

    嫌なことから逃げることしか出来ない弱虫はチームのメンバー、そしてエンドユーザー、何より自分を守るためにユーザー部署内で小さなプロダクトマネジメントとエンジリアリングマネジメントを行い、ユーザー部署からそのシステムを支えるプロダクトを作り上げ、数万人のユーザーに届ける事にしました。

    理不尽にも思える状況の中、ユーザー部署内でひっそりとプロダクトマネジメントとエンジニアリングマネジメントの手法を適用し続ける。
    その目的とその中で起こした変化をお話しします。

    (本発表は守秘義務に反しない内容とするため、脚色や匿名化を行なった内容となります。実際の会社名、案件内容は一切お話できません)

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Junki Kosaka / Yuko Kondo / Noriyuki Nemoto / Ryutaro YOSHIBA (Ryuzee) / Koji Shimada / Tatsuya Sato / Yasuo Hosotani / YUKI TORII - あなたの一歩を後押しした本やあなたの手掛けた本について話してほしい!「旅するAgile本箱」LT #2021

    90 Mins
    Talk
    Beginner

    昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び!

    旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

    今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます!

    ★旅するAgile本箱LT2021:発表順(予定)

    1. 前説:旅するAgile本箱って?
    2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
    3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
    4. 鳥井 雪さん  「ダイバシティな絵本」のご紹介(順不同)
      『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる とびきりおいしいデザート』
    5. 吉羽 龍太郎さん「エンジニア的翻訳術」
    6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
    7. 佐藤 竜也さん『達人プログラマー 第2版』
    8. 島田 浩二さん『ユニコーン企業のひみつ』
    9. 結び

    ●ハッカーライフラボスタッフ
    ・司会:コサカ ジュンキ
    ・配信:アジャイル札幌のみなさん

  • Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi - もしもエンジニアリングマネージャーが妻のアメリカ出張を一年間経験することになったら

    45 Mins
    Talk
    Intermediate

    My Wife Went To U.S.

    それは突然のことでした。「ねぇ、4月からアメリカ行っていい?」

    そこから始まる父と小学生の息子2人、トイプードルの娘1人との1年間の情熱ワンオペ育児。たくさんの不安がよぎります。しかし、この困難に正面から立ち向かうことにしました。自分の道具箱にはエンジニアリングマネージャーとしての経験があります。これをどうにか活かすことはできないかと取り組みを始めます。

    エンジニアリングマネージャーが家事育児にトライしてみると?

    実際に取り組みを始めてみると、自分のこれまでのエンジニア、マネージャーとしての経験が多くの場面で活かせることに気がつきます。実際に経験したものの一例は下記のようなものです。

    • あ、冷蔵庫行ったり来たりすると面倒だな(TPSのムダの発見と解消)
    • 仕事をどう調整つけようか、不安がる実家の親をどう安心させようか(ステークホルダーへの透明性)
    • ホットクック(自動化)
    • 水回り、お金払ってピカピカになるととってもアガるし効率がいいな(アウトソース)
    • 料理代行、ただ作ってもらうだけだとそんなに楽にならないな(リーンソフトウェアの「全体を最適化する」)
    • 大根が嫌い? なら千切りにして味噌汁に入れたらどうなるかな?夕飯で試そう(高速に実験&学習する)

    これらの活動を通して、苦労していたワンオペ育児もだんだんと楽しく、より良くなるように感じています。また、今までの経験・知識をワンオペ育児へ再適用することで、これまでの経験にもより深い理解にたどり着きました。

    このセッションについて

    このセッションでは、私が実際に経験した家事・育児での困難さを、自分のエンジニアリングマネージャーとしての経験から見たときにどう見立てられるのかを学び、どう戦っていったのかを話します。その中でのフィードバックループを回す中で、自分が持っているアジャイルやソフトウェアの知識もより深い理解にたどり着いたように感じたので、その学びについてもシェアします。

    アジャイルな思想や方法論をどのように適用したら良いのかがわからず困っている人がもしいれば、このセッションを聞いてみませんか? ソフトウェア開発とは全く異なる対象領域ですが、アジャイルな家事育児を通して、理論と実践、思想と方法論がコネクトできるヒントになると思っています。もちろん日々の家事・育児に悩んでいる人も参考になるTIPsが多いと思いますので、参考にしていただければ幸いです。

  • Sakano Nao
    keyboard_arrow_down

    Sakano Nao / Takeshi Fukasawa / yasuyuki kamitokusari - 【パネルディスカッション】オフショア×スクラム=モダンオフショアの取り組み

    45 Mins
    Talk
    Beginner

    クラスメソッド株式会社では、ベトナムの事業会社と共にクライアントワーク(受託)を行うことも多く、その中でもスクラムで開発することも多いです。

    弊社ではオフショア×スクラムを『モダンオフショア』と称して推進しており、そんなモダンオフショアのリアルな現場を、それぞれ別の案件に携わる3名のスクラムマスターとパートナーであるベトナムのオフショア事業会社から2名(予定)でお話していきます。

    本セッションではパネルディスカッション形式でお題に沿ってお送りします。
    現場の明るい部分だけではなく、暗い部分、成功から失敗まで忖度なく語っていきますのでご期待ください。

    時間の都合上、セッション中に質問回答時間を用意することが出来ませんでしたので、ぜひ質問・感想等あればDiscord上でお願い致します!

    モダンオフショア/ クライアントワーク(受託)/ オフショア/ 海外/ スクラム開発 etc...
    何かひとつでも気になるワードがありましたら、ぜひご観覧くださいませ。

  • Takahiro Kaneyama
    keyboard_arrow_down

    Takahiro Kaneyama - スクラムマスターこそ考えたい、言葉のアウトカム

    20 Mins
    Talk
    Beginner

    スクラムマスターの役割で動いていると、さまざまなところで言葉を利用したアクションが必要となります。

    スクラムマスターのみなさんは、とてもたくさん勉強をして、色々と新しい発見をして、それをチームに伝えたい!そんな思いやりのある方ばかりですよね。

    しかしながら、「伝え方が悪くて伝わらない」「うまく伝えられない」という気持ちになったことも一度や二度ではないはずです。

    このセッションでは、言葉は伝える(アウトプット)だけではなく、伝わった(アウトカム)を大切にしていくことが大切だという気づきを得た経験から、言葉のアウトカムを最大化するための方法を紹介して、皆さんの言葉の力を引き出せることを目指しています。

    チームのスクラムマスターとしての経験だけではなく、Podcastのパーソナリティとしての経験やカンファレンス運営の経験など、様々な角度から言葉のアウトカムについて考えてきた経験を基にお話をさせていただきます。

     

    言葉のアウトカムを高めるために必要なのは、ふりかえりです。

    自分の発言した言葉をふりかえることはできていますか?

    仮説を立てて、発言をして、ふりかえって、カイゼンするといったサイクルを日々考えることができていますか?

    実際に私が行っているふりかえりの方法や、簡単にできる言葉のふりかえり方法の紹介を通して、皆さんがこれから話す言葉の一つ一つを大切にできるようになります。

     

    さらに、言葉のアウトカムを高める意識が高くなっていくと、問いのスキルも向上します。スクラムマスターにとって大切な問いのスキル

    効果的な問いをチームに投げかけることで様々なことを引き出すことができると皆さんは感じていると思います。しかり、それを実践することはとても難しいことです。

    効果的な問いをするためにはどうすれば良いのか?どのように訓練をすれば効果的な問いを生み出すことができるのかをお話しします。

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 3 months ago
    Sold Out!
    90 Mins
    Track Keynote
    Beginner

    テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
    Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

     

    W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

    • quality is everyone's responsibility(品質はすべての人の責任)
    • improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)

    また、Janetがオリジナルで提唱する原則が以下の2つです。

    • if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
    • if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)

    アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
    JanetとLisaは以下のような内容で特にプロセス品質についてトークします。


    1.Question Askerであるべき
    2.例やテストを使って開発をガイドする
     ・magic bubble(魔法の泡) コード・テスト・自動化
     ・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
    3.エクササイズ(ユーザーストーリーからテストを考える)
    4.アジャイルテスティングの4象限を使ってテストを把握する
    5.探索的テスト、品質属性のテスト、スライディング・スケール
    6.コアプラクティスを使う
     ・継続的インテグレーション
     ・テスト自動化
     ・機能やストーリーの優先順位付け
     ・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
     ・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築)

     

  • Masayuki Nishida
    keyboard_arrow_down

    Masayuki Nishida / Kei Nakamura - スクラムチームが挑む!未熟プロダクト育成とビジネス成功への道

    45 Mins
    Track Keynote
    Beginner

    老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
    モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

    「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

    「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

    今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
    しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
    (悩みの一例)
    ・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
    ・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
    など。
    せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

    組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

    登壇するPO、ScMが本プロジェクトで大切にしてるマインド

    [ PO ]

    対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

    [ ScM ]

    POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

     

  • Yoshio Miyake
    keyboard_arrow_down

    Yoshio Miyake / Koki Kawagoi / manami Ozawa - チームでものづくりするときに、心のなかで起こっていることを上手く使うには?

    90 Mins
    Talk
    Intermediate

    みんなで協調してものづくりをするときに、ひとりひとりの心の中では、どのようなことが起こっているでしょうか?それぞれの人のなかで、言語的であったり、イメージ的であったり、並行的に動いているのです。それを上手くものづくりに活用するための情報を認知科学の視点からお伝えできたらと思います。

    みなさんが、わかりやすく理解するためのアクティビティもご用意できたらと考えています。
    人数に応じて、少し参加者同士で話していただくかもしれません。

  • Tomoko Sohda
    keyboard_arrow_down

    Tomoko Sohda - スクラムネイティブなスクラムマスターがやらかした失敗とそこからの巻き返しの物語

    Tomoko Sohda
    Tomoko Sohda
    Full-Stack Developer
    freee K.K.
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    freee株式会社でエンジニアをやっています。宗田(そうだ)です。
    エンジニアでありスクラムマスターでありエンジニアリングマネージャーでもあります(兼任したからこそ学べたことも多くあり兼任してよかったなと感じていますがその話は今回はやりません)。

    新卒で入社したSIer(前職)でスクラムをやっていたためエンジニア歴イコールスクラム歴です。
    前職でのアジャイルエバンジェリストや社外コミュニティ活動で先人の行動や考えを確と学ぶ機会も多くあったため実践で大きな失敗もあまりなかったように感じていました。
    が、それも自分に力があったわけではなく周囲のサポートがあったからこそだったのだと痛感する失敗を経て、現在に至ります。

    ただし、単に失敗しただけでは終わりません。
    そこからどうやって巻き返したのか。失敗から何を得たのかをこのセッションでお話しします!

help