話し合うを体験するワークショップ:LEGO® SERIOUS PLAY®メソッドと教材を活用したワークショップ体験会

location_city Osaka schedule Jun 26th 02:00 - 03:30 PM place 広島 people 5 Interested

【課題】
オンラインでの仕事の場も増えてきて、コミュニケーションの課題が取り立たされています。また会議などの話す会う場に対しては、これはオンラインの仕事が増える以前からの課題でもありましたが、合意形成が難しいという課題が。

そんな中、対話(話し合う)の仕方というものに注目が集まっています。
手法としても、インタビューや、1 on 1。さらにはOST、リーンカフェ、etc...

【提案】
今回提案するワークショップは、レゴブロックを使った話し合いのやり方です。その活用や効用は、話し合い方という単一なものではないのですが、私は話し合いの体験として非常に示唆多き場を体験することができたので、みなさんにも体験をお届けできればと思っています。

【ファシリテータープロフィール】

高柳 謙
クラスメソッド株式会社 CX事業本部
プロジェクト内製化ファシリテーター

複業:
 顧問ファシリテーター
 研修内製化コンサルタント
 LEGO® SERIOUS PLAY®
 メソッドと教材活用トレーニング修了認定ファシリテータ
 認定スクラムマスター(CSM)
 Management 3.0 修了認定

 
 

Outline/Structure of the Workshop

レゴシリアスプレイについての説明

レゴシリアスプレイのワークショップ

Learning Outcome

参加者全員が、自分の伝えたいことをしっかりと持ち、話し合いの中でも自分の考えと他の人の考えを尊重を持って話し合う体験

Target Audience

スクラムマスター

Prerequisites for Attendees

【注意】
専用のレゴキットを利用するため、事前に参加者の人数を確定し、キットを郵送します。
(返却込みで実費:1000円程度)
送付はBoothというサイトを利用して、参加者の住所取得を個人的に行うことなく発送します。
レゴキットは使い回すものですので、ワークショップ後に回収(返却)させていただきます。

当日に参加を決めていただいた方はワークの様子を見学という形でご参加いただくことになります。

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

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

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

  • Fujihara Dai
    keyboard_arrow_down

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

    45 Mins
    Track Keynote
    Advanced

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

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

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

  • 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

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

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

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

  • 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

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

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

     

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

     

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

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

     

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

     

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

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

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

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

  • 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"より中身を見ていただければと思います。

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui / Yoh Nakamura - 紙芝居で2人のアジャイルコーチがScrumのあるあるをちょっとだけ語ってみる

    20 Mins
    Talk
    Beginner

    スクラムやアジャイルに初めて取り組むときにありがちなことをネタにして、2人のアジャイルコーチが、紙芝居でRPG風の物語のワンシーンを演じつつ、スクラムやアジャイルでの落とし穴について解説をします。

     

     

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

     

  • Yasuharu Nishi
    keyboard_arrow_down

    Yasuharu Nishi / Azuma Miwa / Kaori Tokiwa / Kunio Yamamoto / Naoki Kojima / Takefumi Iseki / Yusaku Tokuda - 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)

    45 Mins
    Talk
    Intermediate

    スクラムで品質に悩んでいるチームや組織へのアプローチを整理する話をします。


    品質を向上するためにテスターやQAエンジニア、SETやSREを増やそうとする組織は多いですが、スキルセットやキャリアパスをどのように決めていけばよいのかについて困っているところも多いと思います。また、当面はテストを外部発注してしのぐとしても、どう内製化するか、どうスケールするか、どう組織全体に根付かせていくか、について悩んでいる組織も多いと思います。


    そうした悩みを解決するために、本プレゼンテーションではQMファンネル(3D版)を使って整理するお話を紹介します。


    頂点が下向きになっている三角錐を想像してください。まず三角錐の側面はエンジニアのスペシャリティ(得意技)です。スペシャリティをTE(Test Engineer、いわゆるテスター)、QA(Quality Assurance、いわゆる品質保証)、DA(Delivery Accelerator、いわゆるSETやSRE)の3つに分けて整理します。もちろん、それぞれのスペシャリティがサイロ化しないように、側面の境界をスムーズにするような境界的なスペシャリティも考えないといけません。


    次に、三角錐の深さはレンジ(範囲)になります。レンジを、外部発注したり専門組織によるサービスという役割分担から、スクラムチームの内部だけで頑張るインプロセス、チームと一緒に開発しながら高度なスペシャリティを浸透させるコーチ、それぞれのチームの外部からスペシャリティを移転するコンサルタント、組織全体にスペシャリティを浸透させていくプロモーターといった5つのレンジに分けて整理します。


    品質を向上するには、TE、QA、DAの3つのスペシャリティが全て必要です。これらをまとめてQM(品質マネジメント)として捉えることで、バランスのよい品質向上が実現できます。同時にオールレンジの活動を意識することで、組織全体でバランスよく品質向上を浸透させることができます。


    またQMファンネルは、伝統的なプロジェクトのようにPMとエンジニアを区別する考え方ではないという点にも注意する必要があります。スクラムチームでは、テスト計画・テスト設計・テスト実行を分割してサイロ化させるのは得策ではありませんし、コンサルタントやプロモーターが偉いわけでもありませんので。


    私たちのQMファンネル(3D版)について聞いて頂いて、皆さんの組織の品質がスムーズに加速できればとても嬉しく思います。たくさん議論させてくださいね!

  • Kei Murabayashi
    keyboard_arrow_down

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

    Kei Murabayashi
    Kei Murabayashi
    engineer
    for Startups, inc.
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

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

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

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

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

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

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

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

    Jean-Baptiste Vasseur - リーダーとは何か、その答えをずっと探していたがCAL2を受けてやっと理解し始めた話

    45 Mins
    Talk
    Intermediate

    昨年弊社のメンバーが徐々に増えてきて、自分としてよりリーダーらしい立場と振る舞いをとっていきたいと考え始めましたが、そもそもリーダーとは何か、そこからスタートする必要がありました。

    色んな書籍やネット記事を読めば大体のことが理解できますが、相反する考え方もあれば自分としてこういうリーダーになりたいというものがちゃんとフィットするものも見つかりませんでした。

    そこで2020年9月にScrum AllianceのCAL(Certified Agile Leadership)プログラムに出逢いました。

    よし!CAL1とCAL2を取得してヒント探しに行くぞ、と。

    そして2021年4月現在、無事終わりました。確かにヒントは得られました。

    しかし、経験したこと、学んだこと、得られたものは想像を遥かに超えていました。

    皆さんにもぜひアジャイルリーダーの旅に出て欲しいという気持ちを込めて私のアジャイル・リーダー・ジャーニーを語りたいと思います。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - プロダクトオーナーマニアックス! POとSMの原点の原点をさかのぼって学ぶ初代主査 中村健也の働き方

    45 Mins
    Talk
    Advanced

    ■チーフエンジニアというプロダクトオーナーとスクラムマスターの原点

    スクラムではプロダクトオーナーという役割が用意されています。この役割はどのように作られたのでしょう。ジェフ・サザーランドが書いた『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』では次のように解説しています。

     プロダクトオーナーという役割は、トヨタのチーフエンジニアから発想を得たものだ。

     

    続いて、スクラムマスターの着想もチーフエンジニアからだったことが解説されます。

     チーフエンジニアはただこうしろと指示を出せばいいのではない。メンバーを納得させ、うまくその気にさせて、自分が提案するやり方が正しくベストなやり方だということを示さなければならない。普通ならその道で三十年くらいの経験がなければ務まらない役割だ。そこでこの役割を二つに分け、仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオーナーが管理する分担制にした。

    もちろんチーフエンジニア以外からも参考にされたものはたくさんあるでしょうが、POとSMというアイデアに大きな影響を与えたようです。

     

    ■機能しないチーフエンジニア

    しかし、チーフエンジニア制度と半世紀近く携わり、自らもセリカ、カリーナ、スープラのチーフエンジニアであった和田明広は次のように述べています。『和田明広オーラル・ヒストリー』 から引用してみましょう。

    トヨタのチーフエンジニア制度について様々な企業から相談が持ち込まれますが、うまく機能しないことを述べています。※文中の主査は、チーフエンジニアの前の名称。

     和田 チーフエンジニアという制度はあるのですが、トヨタみたいな機能はしないのです。マーケットを見ていますけれども、新しい車をクリエイトするというようなことがなかなかできないのです。
     尾高 日本の中ではどうですか。
     和田 同じです。


    また現在のトヨタにおいてもチーフエンジニア制度は、機能しているか疑わしいと述べています。

     和田 よそのチーフエンジニアですか。でも、いまはトヨタのチーフエンジニアもそうですからね。いまはそんなに能力のある人間はいません。そんな2年や3年ちょこちょこっとやったぐらいで十分な能力ができるわけないですよ。我々だってどのくらい失敗したかわからないわけです。10年から実質的には何十年やっていますけれども、どれくらい失敗したかわかりません。

     

    ■トヨタのチーフエンジニア制度が生まれる過程

    ジェフ・サザーランドがスクラムを構築する過程にチーフエンジニア制度があったように、トヨタのチーフエンジニア制度においても過程がありました。その中で和田明広は中村健也という人物に焦点を当てています。

     松島 トヨタの場合は、なぜ他社とは異なる主査制度が生まれてきたたのでしょうか。
     和田 それは前回申し上げたかもしれませんが、中村健也さんが素晴らしい実績を残されて、会社内全体が、主査のいうことは社長の言うことだ、そういうムードになったのだと思います。

     

     尾高 外国から主査の役割についていろいろ聞いてきたとおっしゃいましたね。その結果、外国で何か起きたのでしょうか。
     和田 起きないと思います。どうしてトヨタでは主査というのがうまく機能するのか、ということですから。それはどうしてかと私に聞かれれば、それは中村健也さんから始まって全社的な組織とは違ったパーセプションを得られて、それでうまく動いているのだと説明するしかないのですけれども(略)

    ※和田明広 日本初の乗用車である初代クラウンや、初代カローラのボディ設計を担当し、トヨタで大主査と呼ばれるようになった中村健也や長谷川龍雄と共に開発をした。その後、自身もセリカ、カリーナ、カリーナED、スープラの主査(チーフエンジニアの前の名称)、またプリウスのプロジェクト責任者を担当。トヨタ副社長、アイシン精機会長、日本機械学会会長を歴任。

     

    トヨタ自動車株式会社名誉会長である豊田章一郎は『未来を信じ一歩ずつ : 私の履歴書』の中で、節をまるまる用いて中村健也を取りあげています。

     その後、1962年(昭和37年)はにモデルチェンジした2代目クラウンには、より剛性の高い「Xフレーム」を採用した。
      このときも、私は、技術部で中村さんと一緒に仕事をした。フレームをできるだけ薄くし、車高を低くすることを目指したが、X型フレームに対しては社内の反対も多く、まさに冒険そのものたった。
      テストコースの悪路耐久試験ではフレームに亀裂が生じたが、中村さんは決して諦めなかった。私は、「これが失敗したら2人で一緒に会社を辞めましょう」と言って中村さんを励ました。いつも不退転の決意で臨む中村さんも同じ思いだった。

     

     中村さんの主査としてのやり方が骨格となり、今日のトヨタのCE制度がだんだんと築き上げられ、それがトヨタの特徴となり財産にもなった。
      初代クラウンとともに主査中村健也は、いつまでも私の心に残る技術者だ。いかに情熱を持って仕事に取り組むか。そのような精神の持ち方を訓練すれば、私のような若い技術者でも大いに活躍できると思った。

    ※CE制度とはチーフエンジニア制度のこと

    いったい中村健也とは何者なのでしょうか。どのような仕事や仕事の仕方をしてきたのでしょうか。

     

     

    ■このセッションでは何をするか、何が得られるか

    スクラムのPOとSMはジェフ・サザーランドによればトヨタのチーフエンジニア制度から着想を得ましたが、和田明広によればチーフエンジニア制度は他社では積極的に導入を試みるもうまく機能しておらず、まして現在のトヨタでも機能しているか疑わしいと厳しい評価をしています。

    このセッションでは、私たちがプロダクトオーナーという役割をより効果的に果たしていくために「そもそもチーフエンジニア(主査)とはなんだったのか」を「中村健也」という人物を中心に、POとSMの原点(チーフエンジニア制度)の原点(中村健也)を70年ほどさかのぼり、プロダクトオーナーが効果的に力を発揮するための知恵を探ります。

     

     

    参考文献

    『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』ジェフ・サザーランド, 早川書房, 2015
    『和田明広オーラル・ヒストリー』 松島茂, 尾高煌之助編 東京理科大学専門職大学院MOT研究センター, 2008.12(非売)
    『未来を信じ一歩ずつ : 私の履歴書』豊田章一郎, 日経BP, 2015
    『トヨタ自動車開発主査制度』塩沢茂, 講談社, 1987(絶版)
    『主査 中村健也』和田明広編, トヨタ自動車株式会社, 1999(非売)
    『トヨタの製品開発』安達瑛二, 白桃書房, 2014
    『初代クラウン開発物語』桂木洋二, グランプリ出版, 2015(底本1991)
    『トヨタ チーフエンジニアの仕事』 北川尚人, 講談社, 2020
    『プロジェクトX 挑戦者たち われら茨の道を行く ~国産乗用車 攻防戦~』NHK

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - mogiri - オンラインカンファレンスの受付業務を改善するDiscordボットの話を聞いてください

    45 Mins
    Talk
    Beginner

    昨年の Scrum Fest Osaka 2020 @ Online から、カンファレンスの参加者の交流やさまざまな連絡にDiscordを使うようになりました。それからいくつかのカンファレンスで使ってきたのですが、スタッフ側でちょっと頭の痛い作業が「受付」です。

    もちろんリアルのカンファレンスでも結構大変で、長年頭を悩ませてきたのですが、Eventbriteのアプリの出来がいいのが救いでした。しかし、Discordの受付にはそれが使えず、しぶしぶGoogle Spreadsheetを使いながら、スタッフがポチポチ確認作業をするということをしてきました。

    それから約一年たちまして、さすがに運用も安定してきましたし、DiscordのボットとEventbriteのAPIを使って、自動化をやってみようかなということで、やってみました。プログラムとしては大したことはないですし、うれしいのもほとんどスタッフだけですし、これといった感動する苦労話もないのですが、こんな話を聞いてもらえるのもスクフェス大阪くらいかなと思い、プロポーザルを書いてみます。

    mogiri
    https://github.com/kawaguti/mogiri

    この小さなアプリを、どのように維持したり、育てて行ったらいいか、皆さんをご意見やご示唆をいただければ幸いです。

     

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - アジャイルなチームをつくる『ふりかえり』のガイド++

    45 Mins
    Talk
    Beginner

    ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。

    ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。

    COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。

    そんな世界の中でも、変化に柔軟対応でき、価値を生み出し続けられる「アジャイルなチーム」。そして、それを作るための一歩目である「ふりかえり」と、その導入をガイドします。

    このセッションは「Developers Summit 2021(デブサミ)」でベストスピーカー賞8位を受賞したセッションの再演です。
    ただし、アジャイル・スクラムの知識を前提として導入部分をバッサリカットし、デブサミではお話のできなかった+αの内容をあわせてお届けしたいと思います。

  • 川渕 洋明 (bucci)
    keyboard_arrow_down

    川渕 洋明 (bucci) - モヤモヤからスクラムまで - 雑談と目的が生む探索型もの/組織づくり

    20 Mins
    Talk
    Beginner

    雑談と目的。おそらくこれを読む方の多くは、COVID時代においても、これらを日常的に効果的に活用され、日々をイキイキと過ごされてるんじゃないかと思います。

    本講では、モヤモヤしてる方、また、ものづくり・組織づくりに困ってる方に、スッキリ・改善・成功のヒントになりそうな私の半年間の体験と、そこから導出した法則めいたものをお伝えします。

     

    自分のこと

    2ヶ月前、私はモヤモヤしていました。

     

    日本オフィス3人目としてCI&Tに入り丸5年が経過。その間、

    • 国内マーケ
    • 現場プロジェクト
    • 組織変革とファシリテーション
    • 2019/2020 AgileJapan実行委員
    • 30人にオフィス拡大(日本人3割)

    など経験しつつも、そこにいたのは 自信と方向性を見失った自分(45歳)でした。

     

    そんなとき目に止まったのがはちさん(蜂須賀大貴)の記事「FA宣言の結論、お伝えします!」でした。

     

    気づいたら送っていたFBメッセ:

    はちさん、こんにちは。もしよければ、今度雑談させていただけませんか?いまの会社5年いて、少し今後のことでモヤモヤしていて。はちさん動画拝見して、似たような状態からFA宣言されて対話を経て道筋を見つけられらようだったので、自分もすこし周囲とお話ししてみたいなと思った次第です。お忙しいと思いますので、まずはご検討いただけたら嬉しいです。 ブッチ

     

    3/22に開催されたこの雑談を皮切りに、今日時点(5/22!ピッタリ2ヶ月!)で延べ80人と雑談などしてきました。

     

    そして気づいたら、2ヶ月前とは全くちがう自分になっていました。

    • 目的/価値ドリブン
    • 抽象化を使いこなす
    • 3年後の自分像を描けた
    • 当面の人生ビジョンが見えた
    • 過去の後悔を消化/昇華できた
    • コミット&フォーカスな行動の連鎖
    • 相手/周囲のサポートを得る、働きかける
    • モヤモヤを小さいアクションの積み重ねで払拭
    • 後悔のない挫折と判断という結果/成果を得られた

     

    他者と仕事

    さらに、他者との関係や仕事にも好影響が出始めています。

    • 傾聴
    • 交渉力の向上
    • リーダーシップの発揮
    • 明瞭な業務コミュニケーション
    • ワークショップでの振舞い/ファシリテーション

     

    雑談と目的の威力

    このように私は、雑談という、様々な違和感を感じ得る、小さな目的をもった仮説検証アクション、を重ねることで、高解像度な腹落ち感のあるビジョンを手にし、すべての思考・行動がそこに向かうようになりました。

    これはチームや組織、プロダクトにも言えること。

    関係者の間で共有された/されきっていないビジョンや目的があり、いかにそこに向かい、違和感や意図にもとづいた意味と価値のあるアクションを関係者それぞれが積み重ねることができるか。学びを得られる失敗を設計できるか。

     

    本講をご覧いただくことで、スクラムやものづくり・組織づくりの現場で、
    精度の高いビジョンを「玉ねぎの薄皮を剥ぐように」少しずつ共有し、
    関係者全員が紙1枚程度の小さな目的とアクションを積み重ね、
    挫折はあっても後悔はない高品質な成果を、
    掴みとっていただけたら本望です。

     

     

    川渕 洋明(bucci)

    hiroaki.kawabuchi@gmail.com

    LN: https://www.linkedin.com/in/hiroaki-kawabuchi/?locale=en_US

    FB: https://www.facebook.com/hiro.kawabuchi/

    TW: https://twitter.com/bucci_bass(最近、言語化がんばり中)

     

     

     

     

help