共通言語で共通の課題に相対するチームを作るゲーム

location_city Osaka schedule Jun 26th 02:25 - 02:45 PM place 品川 people 13 Interested

皆さん、チームの意識がバラバラで困ってたりしませんか?
チームがあなたが抱えている課題感を理解してくれなくて悲しい思いをした人は少なくないのでは。

あなたが抱えているあなたしか認識していない課題感はどうすれば効果的にチームに伝わるでしょうか。
私がおすすめするやり方は「新しい言葉」をチームに導入することです。

例えばアウトカムにフォーカスせずアウトプットばかりにフォーカスしてしまう状態。
ある特定の領域が得意な人に難しい仕事が集中し、得意ではない人との差がどんどん開いていってしまう状態。
これらの状態を単語一つでチームに伝えられると捗りますよね。

現象に対する言語的、認知的な表現が不足していると必要な対策が取れなかったり認識の共有が取れなかったりと色々な問題を引き起こします。
(これをHypocognitionといいます)

逆に言うとチームに言葉を導入するとチームに概念が生まれます。
例えば「心理的安全性」という言葉を輸入すると心理的安全性という概念が生まれます。

このセッションではチームに共通言語を作ることのメリット、具体的にどうやってチームに共通言語を輸入したか、
それによってチームはどう変わっていったかを私のチームの具体的な事例を交えてご紹介します。

 
 

Outline/Structure of the Talk

  1. チームに課題が伝わらない時のよくある構造
    1. そもそも課題を課題と認識できていない
    2. 課題を捉える概念、価値観がチームに存在しない
    3. Hypercognitionとは
    4. 新しい言葉を導入することで課題を認識できる
  2. チームで共通言語を作った実例
    1. 輪読会でみんなで新しい言葉を学ぶ
    2. テックブログ、勉強会で輸入する
    3. ふりかえりで新たな言葉を生み出す
      1. 名前をつける時のコツ
  3. その結果チームはどうなったか
    1. 共通言語を使いこなし共通の課題に相対する
    2. 更に新しい言語、概念を積極的にチームに導入

Learning Outcome

  • チームに課題を認識してもらう方法
  • チームの目線をあわせる方法
  • 楽しく生き生きとしたチームの作り方
 

Target Audience

チームに課題感が伝わっていない人、チームを成長させたい人

schedule Submitted 3 months ago

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - チームの状況にあったいろいろなタイプのスクラムマスターの見つけ方

    20 Mins
    Talk
    Beginner

    「どういう人がスクラムマスターをやればいいんだろうか?」

    この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
    Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

    しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

    スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を 持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。

    では、どのような人がスクラムマスターに向いているのでしょうか?
    またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか?

    このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか?」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

    よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

  • 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回のセッションが終わった段階、
    旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

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

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

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - アジャイルコーチ、スーパーアジャイルコーチ、ウルトラアジャイルコーチ、それぞれの10年

    45 Mins
    Track Keynote
    Advanced

    2010年にフロリダで開催されたAgile conferenceに参加していらい、「よりアジャイルなチームを作るためには?」を考え続けてきたようにおもいます。僕の関心は常に「アジャイル開発」です。

    当初は企業内のアジャイルチームとして活動し、のちにアジャイルコーチと名乗るようになり、開発現場に立ったり、チームや組織開発を考えたり、「どうやったらもっとアジャイルになるか」を考え続けてきましたが、今もアジャイルコーチとして新しい現場に立つたびに、10年前と変わらず悩み続けています。

    10年の経験を得て、これまでにできてきたこと、まだできていないことをふりかえりながら、次の10年をスーパーアジャイルコーチとして現場を成功させ、その次の10年でウルトラアジャイルコーチとして過ごすために必要なことを考えるセッションです。

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

    スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員(+希望者は誰でも)向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

    こちらのセッションでは、サイボウズ社内で実施している研修(講義)を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

  • 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のコミュニケーションだから、チームの話とは違う印象をもつかもしれません。
    でも仕事を行う以上、人と関わるのは必然。複数人行ううちに共通の課題も見えてきます。
    いろんな現場にいくと、対話をしているようでできていない現場をよく見ます。
    もちろんこんな風に書いている私もうまく話せなかったなぁという体験はあります。

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

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

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - ゲームのように学ぶアジャイル開発

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル開発に興味のあるみなさん、どうやって学んでいますか?

    XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?

    そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。

  • Kenta Sasa
    keyboard_arrow_down

    Kenta Sasa - チームや組織を良い感じにするためにやっていること紹介 〜社外アジャイルコーチと社内チェンジエージェントの両面から〜

    45 Mins
    Talk
    Beginner

    アジャイルコーチをやっていてよく聞く悩みとしてこんなのがあります。

    • もっと良いチームを作りたいのになかなかメンバーが変わってくれないんですよ…
    • うちのチームはアジャイルなんですが周りのチームが理解してくれなくて…
    • 弊社は古くて堅い文化なので新しいことを始めるのは難しいんです…

     

    では支援を提供している自社ではこのような問題はないのか?と問われると、程度こそ違えどチーム・チーム間・組織の単位で色々な問題はあります。もちろん、私が力になれそうな問題であれば良い感じになるように色々な動きをしています。

     

    社外のアジャイルコーチの場合、期限・頻度・役割といった観点で考えると、実際の現場のチームやメンバーと同等の動きは取りません。一緒に問題や解決案を考えたりはしますが、実際に解決のために動くのは現場のメンバーになります。

    逆に社内を良い感じにしようと思った場合、自分自身が当事者であり、実際にアクションを行うのは周りの誰かではなく私です。

     

    私は自身の勤務時間の半分を他社向け、もう半分を自社向けに使っています。アジャイルコーチとして現場の支援をすることもあれば、アジャイルコーチの皆さんに相談をして支援を受けることもあります。社外のメンバーの背中を押すときもあれば、社内のメンバーの背中を押すときもあれば、社外のメンバーから背中を押してもらうこともあります。支援や改善活動の単位も個人/チーム/複数チーム/組織全体と様々です。

     

    といった様々な立場や規模で動いている経験から、チームや組織を良い感じにするために実際にやっていること、結果としてどんなことが起きたのか、気をつけているポイントなどを紹介させていただこうと思います。あくまでもコンテキストありきの事例集ですが、事例ごとに参加者の皆さんとそれぞれのコンテキストで活用できることがあるかも議論しながら進めようと思っています。

    私の事例を肴にわいわいしましょー!

  • Koki Kawagoi
    keyboard_arrow_down

    Koki Kawagoi / manami Ozawa - チームの能力向上はどっちに向かっていますか? アジャイル開発と相性の良い能力アップとは?

    45 Mins
    Talk
    Intermediate

    チームの能力を高めるといったとき、どんなことをイメージしますか?
    能力アップ(熟達)には、レシピ通りに手早く正確に作れるようになる定型的熟達と、材料が揃ってなくても状況に合わせて調理をする適応的熟達があります。
    これは、チームの考え方や、マネジメントの接し方によって影響を受けます。

    開発現場に置いて、定型的熟達と適応的熟達がどんな行動をするのか、どうしたら適応的熟達に近づけるのか紹介します。

  • 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冊弱の読書をしていました。

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

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

  • eroccowaruico  
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

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

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

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

  • Sakano Nao
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

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

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

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

  • Hiroki Hachisuka
    keyboard_arrow_down

    Hiroki Hachisuka - First Commitの前にやっておきたいプロダクトオーナーのお仕事

    Hiroki Hachisuka
    Hiroki Hachisuka
    parallel PdM
    -
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    あなたのチームはなぜスクラムをやっていますか?

    少なからず、そこには事業の成功や成長と深く関係していると思います。

    今回はスクラムチームにおいて最も事業への貢献を司る「プロダクトオーナー」にフォーカスし、

    "開発チームが最初のコードを書く前に必要なお仕事"

    についてお話ししたいと思います。

    【なぜ、今、私がこの話をするのか】

    • 事業会社時代(~2021/3)に複数プロダクトの立ち上げ経験があり、いずれもPOとしての立ち上げを経験していた
    • 上記経験をもとに現在"複業PdM"として複数社のプロダクトに参画させていただき、比較し、型が少しずつ見えはじめてきた
    • 自身の整理と壁打ちの意味でもこの機会に言語化し、Feed Forward / FeedBackを得たいため

    【お話しすること】

    • 「アイディア~ビジョン~事業収益~仮説検証~指標(KGI)~施策~チームの組成~Sprint0」の全体像
    • 各ステップでのやるべきこと、心構え、フレームワーク、参考資料の紹介

    【お話ししないこと】

    • それぞれのステップを具体的に掘り下げること(時間が足りないので / それぞれ45分ずつできそうw)
    • Sprintがまわり始めてからのPOの立ち居振る舞い(別の機会に)
    • PdM、PM、PO、事業責任者の違いなど (今回の内容では重要ではないため)

    詳しくは右下の"VIEW DETAILS"より中身を見ていただければと思います。

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

     

  • KazuhideInano
    keyboard_arrow_down

    KazuhideInano / Etsuo Yamada / Kei Nakahara / Yasumi Nakano - 4人のアジャイルコーチに聞いてみた ~アジャイルコーチ IPPON GRAND PRIX~

    45 Mins
    Talk
    Beginner

    「アジャイルコーチは何やってくれるの?」
    「アジャイルコーチが入るのと入らないのとでは何が違うの?」
    「コーチしてもらうのには、いつから入ってもらうのがいいの?」

    時々、このような声を聞くことがあります。モヤモヤがモヤモヤを呼ぶモヤモヤ感、ありませんか?(汗)

    このセッションでは、これからアジャイルコーチを活用してみようと思う方にむけて、
    色々なアジャイルコーチが良くある質問やシチュエーションにおける対処方法を紹介します。
    社内外といった立場の違い、得意分野の違いなど、多様な観点で複数のコーチの生の声をお届けします。
    このセッションを通して、皆さんの現場にはどのようなタイプのコーチが合っているのか、どんなことを期待できるのかが分かります。
    コーチを活用したい人にとって、活用のヒントを持ち帰っていただける場にできればと思います。

    注)本セッションでは大喜利はやりませんので予めご了承ください

  • Yoshio Miyake
    keyboard_arrow_down

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

    90 Mins
    Talk
    Intermediate

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

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

  • Kenta Sasa
    keyboard_arrow_down

    Kenta Sasa - スクラムマスター的な振る舞いと効果を見てみよう -子供3人とプレイしたFortniteの現場から-

    45 Mins
    Talk
    Beginner

    スクラムを始めたばかりのチームで稀によく聞く質問に下記のようなものがあります。

    • スクラムマスターって具体的に何をすれば良いんですか?
    • スクラムマスターって必要なんですかね?
    • 開発してもらった方が効率いいよね?

     

    ではスクラムガイドにはどんなことが書いているか確認してみましょう。スクラムマスターの責任については下記のような記述があります。

    • スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。
    • スクラム チームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任 を果たす。

     

    支援については、スクラムチーム・プロダクトオーナー・組織を対象に、さまざまな支援が記載されています。スクラムチームへの支援だけとってみてもこのような説明が書いています。

    • 自己管理型で機能横断型のチームメンバーをコーチする。
    • スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できる よう支援する。
    • スクラムチームの進捗を妨げる障害物を排除するように働きかける。
    • すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックス の制限が守られるようにする。

     

    このような説明を読んでみると、ふわっとしたイメージは掴めるものの「具体的に何をすれば良いんだろうか?」という疑問は残ります。そんな時に経験の長いスクラムマスターが近くにいれば振る舞いを見て学ぶようなこともできますが、初めてスクラムを始めるようなケースではモデルになる人がいないことも多いと思います。

     

    ということで!

    スクラムマスター的な振る舞いを実践している所を見て学ぶ場を用意したいと思います!

    題材はFortniteというゲームです。Fortniteとは、4人でチームを組み25組100人の中で1番を目指すサードパーソン・シューティングゲーム(TPS)です。

    今回は子供3人+笹の4人でプレイした時の動画を題材に、スクラムマスターとして必要な動き・考え方・観点を確認していきましょう!

    私が一方的に説明するだけではなく、参加者の皆さんの意見ももらいながらポイントをまとめていこうと思っているのでワイワイやりましょう!

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - 学びについて学び続けて(現時点で)学んだこと

    Shinya Ogasawara
    Shinya Ogasawara
    Vice Manager
    Rakuten Group, Inc.
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2016年11月に始まった教育心理学関連 勉強会/読書会では、三宅芳雄先生,三宅なほみ先生の『教育心理学概論』から始めて、教育心理学概論の参考文献や関連する分野の本を用いた読書会をおおよそ月に1回のペースで続けてきました。

    4年半ぐらい読書会を続けていますが、これだけの期間続けて実施しているコミュニティはそんなに多くはないのかなと思っています。

    私は初回からこの会に参加していて、直近まで参加を続けています。今回、Scrum Fest Osakaでこのコミュニティに関連したセッションを持つことになったと聞き、長く参加している者としての私の観点から、これまでのことをふりかえってみようというのが、この発表の趣旨になります。

    ※「学んだこと」とタイトルにありますが、具体的な理論の紹介というよりは、自分の気付きを中心としたお話になります。

     

    コミュニティ活動を通じて感じた以下のような内容をお伝えできればと考えています。

    • 興味がある内容を話合える楽しさ、協調学習の楽しさ
    • 楽しく続けていくことの難しさ
    • 楽しい場に居座ることの大切さ
  • Tsuyoshi Sega
    keyboard_arrow_down

    Tsuyoshi Sega - アジャイル推進組織奮闘記 ~NTTコムウェアの場合~

    20 Mins
    Talk
    Beginner

    社内に多数のScrumチームが立ち上がっているが、Scrum間の連携の必要性がなく、各Scrumが独自に活動。その結果、質の差が大きく出たり、会社としての統制が難しかったり・・・そんな悩みはございませんか?

    弊社も同様です。弊社は社員数6000人を超えるNTTグループ会社で、もともと(今でも)WF脳の会社です。そんな会社にもアジャイル開発の波が到来しました。現在、年間数十件のアジャイル開発が立ち上がります。各開発はサービス的にはほぼ横連携はなく個別に活動をしていることが多いのが実態です。

    この状況になることは、2016年当時から予想できたため、社内にアジャイル推進組織を作りました。推進組織では、アジャイル開発が増えても最低限の開発の質を担保することや、各チームの困り事の解決のサポートと解決策の横展開を目指した活動をしてきました。

    それなりの歴史があり社員数も多い会社であるため、一筋縄ではいかず、今でも悩み多き活動です。また、推進組織のメンバもアジャイル経験の希薄なメンバの集まりという状況で活動をしてきました。推進メンバをどう育てながらどう活動してきたいのかをご紹介いたします。

  • Muneyoshi Iyama
    keyboard_arrow_down

    Muneyoshi Iyama - プロダクトの品質とユーザ視点の品質を考えてみる

    Muneyoshi Iyama
    Muneyoshi Iyama
    Engineer
    NTT COMWARE Corporation
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    NTTコムウェアはNTTグループの一員として、長年インフラを支えるキャリアグレード品質のシステムを提供してきました。
    そんな我々が変化への適応を求められる今の時代において、アジャイル開発でプロダクトを開発する際に考えている『品質』について一部ご紹介します。

    「つながってあたり前」「止まらないことがあたり前」というビジネス側やユーザーの期待と、アジリティ・価値を両立するために、
    参考にしているモデルや取り組み方の考えなど、アジャイル開発の品質を考えている方々にとって参考になる知見を提供できればと思います。

help