何かを変えようと思っている。勉強会を開いてみたい。学んでみたい。

そんな事を考えるスタッフは社内にいると思いますが、「言って怒られたらどうしよう」「勉強会を開くのは、ちょっと怖い」などが頭をよぎり、一歩踏み出せない状況にいるスタッフがいるかもしれません。

本セッションでは、周りを巻き込み継続し次につなげれるような心理的安全性を確保する活動の、想い、経過、時期に応じた対応に関してお話できればと思います。

 
8 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • なぜ活動を始めようと思ったのか
  • この1年で取り組んでいる支援活動
  • 支援活動を開始し継続する為の根回しと準備
  • 時期に応じた対応と広げ方

Learning Outcome

  • Don’t ask for permission, beg for forgiveness
  • 計画的に緩くやる
  • 店を開いて待つ
  • 少しの幸せを連鎖・継続させるコツ

Target Audience

みんながもっと幸せになって欲しいと願う人。心理的安全性を高めたい人。スクラムマスターとして支援したい人。

schedule Submitted 2 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Tatsuya Sato
    By Tatsuya Sato  ~  1 week ago
    reply Reply

    ※後で書き換える

    更新お待ちしております。

    • Kazunori Morita
      By Kazunori Morita  ~  1 week ago
      reply Reply

      は!

      更新を忘れておりましたが、改めてカテゴリ変更含め更新させて頂きました。ありがとうございました。

  • Yasunobu Kawaguchi
    By Yasunobu Kawaguchi  ~  1 week ago
    reply Reply

    投稿ありがとうございます!

    現在「組織変革とプロセス改善-organizational-change-and-process-improvement」のカテゴリは大変混み合っておりまして、競合のLike数も多いようです。

    「達人スクラムマスターへの道-a-way-to-be-a-pragmatic-scrummaster」カテゴリなども合わせてご検討されてはいかがでしょうか。

    • Kazunori Morita
      By Kazunori Morita  ~  1 week ago
      reply Reply

      ありがとうございます。
      初めての挑戦ですが、こう言った公募プロセスもなるほどなと驚いております。

      組織変革するかどうかよりも、支援活動で誰かが幸せになってもらえたらという活動から始まりましたので、スクラムマスター視点での方向にしたいと思います。

      カテゴリを変更しました。


  • Liked Toshiyuki Ando
    keyboard_arrow_down

    Toshiyuki Ando - モブプログラミングやってみよう!

    100 mins
    Workshop
    Beginner

    モブプログラミングは、Hunter社のWoody Zuill氏らが作り上げた、全員が同じ時に、同じ場所で、同じコンピュータ上で仕事をするソフトウェア開発手法です。

    ブログや動画を見て興味はあるんだけど、実際どんな感じなんだろう? と思っている方、この機会にモブプログラミングを体験してみませんか?

    【どうやるの?】 準備するのは大きなディスプレイと、PC1台(2台あるとなお良い)。長机と、人数分の椅子。 1人がPCを操作するドライバ、残りの人はドライバのガイド役、ナビゲータを担当します。 15分くらいでドライバを交代しながら、みんなでプログラミングをします。

    以下の動画をみるとその様子が良く分かると思います。
    https://www.youtube.com/watch?v=p_pvslS4gEI

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Aki / Minoru Yokomichi - Delegation Poker でチームの自律性を高めよう ! 権限境界を明確にしてモチベーションを高める方法。(Management 3.0 体験ワークショップ)

    100 mins
    Workshop
    Beginner

    Delegation Board自己組織化の高いレベルのチームは他のチームと比べてより効果的です。意思決定はより正確に、もっと早く行うことができます。その上、モチベーションはより高くなります。したがって、自律的なチームを作ることは、各チームとそのマネージャーの目標である必要があります。
    マネジメントは、マネージャーだけではなく、グループの責任です。
    しかし、どのように我々はそのようなチームを作ることができますか?
    どのように私たちの組織の人をエンパワーメントできますか?

    Delegation PokerManagement 3.0 では、0/1の選択肢ではないので、7レベルの権限を使用しています。 このワークショップでは、デリゲーションポーカーを使用してチームのエンパワーメントと権限移譲を管理する方法を体験します。
    デリゲーションポーカーはManagement 3.0の1つの活動です。これをすることで、本質的なリーダーシップのトピックに取り組む準備をし、参加者に幸福のための行動計画を作成できるよう促します。

    世界で展開している進歩的な経営改善考え方であり、Management 3.0 を広めることで、日本の企業のワークシステムを改革し、個人の幸せと日本の社会に貢献することになり、エンゲージメントがされるとともに、企業の生産性が上がる。
    最終的には、顧客を満足させることが出来ます。

    Management 3.0 はオランダ出身のヨーガン アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念で、「人ではなく、システムをマネージするべき」という考え方です。

  • Liked Takeshi Arai
    keyboard_arrow_down

    Takeshi Arai - 心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法

    45 mins
    Talk
    Intermediate

    全社にカイゼン文化が浸透していて、それぞれの現場で独自のカイゼンが実践されています。

    エンジニア、総務、広報・販促、データ作成、インフラ、新規ビジネスなど、あらゆる部門で日々カイゼンが繰り返されています。
    総務や広報・販促のメンバーも「スプリント」「WIP」「レトロスペクティブ」など、アジャイル用語を日常的に使っており、コモンセンス化しています。

    もちろん、たった一人の人間の力だけでそんなソシキカイカクはできるわけありません。

    でも、そのリテンションのコツやマンネリ化を打破する方法など、根底に流れる価値観や
    私が実践する「たった一滴の魔法」を紹介します。

    会社も身体もリーン体質になる魔法です。
    お楽しみに。

  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Yuichiro Yamamoto - 帰ってきた地獄のデイリースクラム

    100 mins
    Workshop
    Beginner

    innocent 地獄のデイリースクラムやります!yell

    地獄風景

    スクラムの中でも、比較的とっつきやすいイベント『デイリースクラム』
    しかし、現場ではこんな光景をよく見かけますね・・・?

    • 毎日できていない
    • 時間通りに始まらない
    • 特定の人しかしゃべらない
    • デイリースクラムがお通夜みたい…
    • そもそもやっていない…

    このワークショップでは、そんな悩みを解決いたします!

      『どうやったらデイリースクラムが良くなるの?』
      『スクラムマスターは何をしたら良いの?』

    皆さんと楽しく体を動かしながら、一緒に体験していきたいと思います。

    (名前は怖いですが、内容は恐くないですヨ!)

    Hell Card!!!!!!

    イベント終了後、私たちが知らなかったデイリースクラムの一面を発見出来るかもしれません。

    セッションに採択されましたら、職場で手軽に地獄を味わえる、自作『~地獄のデイリースクラム~ 地獄カード』の配布や『地獄カードデータ』のダウンロードサービスなどを検討いたします!!

    ~毎日のことだから ちょっとの工夫で大きな差!~


    『地獄のデイリースクラム』とは?

    地獄のデイリースクラムとは、2004年10月にデンバーのScrum GatheringでWilliam C. Wake氏によって行われたチームでデイリースクラムについて学ぶ ことができる「Daily Scrum From Hell」をもとにしたワークショップです。

    https://1drv.ms/i/s!Al3jqJiulpFhhigcusb1hJmqCcjm

  • 45 mins
    Talk
    Intermediate
    2017年9月、私は42歳にしてそれまでの「アジャイルコーチ」という肩書きを捨て、SET(Software Engineer in Test)として LINE 株式会社に入社しました。

    LINE 初の SET として、私は多くのことをイチから手がける必要がありました。テスト自動化に関する現状の把握、課題の明確化、達成すべき目標の提示、関係各者との協力関係の構築、そして施策の実施…。 入社したばかりの人間がやることとしては、なかなかタフなミッションに見えるかもしれません。
    しかしいざ始めてみると、自身の当初の想像をはるかに超えて、私は非常にスムーズにこれらを実施することができています。なぜならば、私がこれまで培ってきた、スクラム・XP・リーンなどのアジャイルの知識・経験の多くが、上記ミッションの実現に大いに活用できることが分かったためです。

    アジャイルの知識・経験は、新しいチャレンジを行う上で、非常に強力な武器となり得ます。

    当セッションでは、新しい会社・役割・ミッションのもとですぐに成果を出すために、また新しいチャレンジを行うために、アジャイルの知識・経験をどのように活かしていけば良いのかについて、自身の経験に基づいて具体的にご紹介させていただきます。
    また併せまして、SET として活動していくために役立つ、テスト自動化のスキルと方法論についてもお話させていただきます。
  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - 「ふりかえり」の始め方と続け方

    20 mins
    Case Study
    Beginner

    このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

    ”ふりかえり”の目的は大きくは以下の2つです。

    1. 自分達の仕事のやり方をもっとうまくできるようにすること
    2. (うまくできるやり方を考えるために)仕事の手を止めて立ち止まること

    この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

    • どのようなデータを収集すればよいか?
    • どういう話し合いのやり方をすればよいか?
    • 継続的にうまくできるように気をつけることは何か?

    また以下のような"ふりかえり"あるあるに出会うこともあります。

    • ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
    • うまくできるようにするアイデアが実行されない
    • なんとなく続いているんだけど効果がわからない

    このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

  • Liked Takao Kimura
    keyboard_arrow_down

    Takao Kimura - Large-Scale Scrum(LeSS) 導入時の勘所(仮)

    Takao Kimura
    Takao Kimura
    Agile Coach
    Gaiax Co.Ltd.
    schedule 1 month ago
    Sold Out!
    20 mins
    Case Study
    Advanced

    アジャイル開発プロセスも大分認知されてきており、規模の大きいアジャイル開発プロセスに取り組む企業も多くなってきました。
    そこで、2016年に、「NexusとLeSSの概要と比較」にて、大規模なスクラムとしての、Less(Large-Scale Scrum)を紹介させていただきました。
    今年は一歩進んで、LeSSをどう導入していくのかというお話をさせていただきます。

  • Liked Daisuke Kasuya
    keyboard_arrow_down

    Daisuke Kasuya - リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく

    45 mins
    Case Study
    Beginner

    ぼくがディレクターをつとめる、Mackerelというプロダクトの開発チームは、東京オフィス・京都オフィス・愛知にあるエンジニアの自宅の3拠点体制で、3年以上開発を続けています。

    日常的にリモートチームで開発をしているのですが、リモートワークはメリットばかりではありません。

    とてもとても、難しいのです。

    このセッションでは、「リモートワークの難しさ」に焦点をあてます。

    リモートワークの何が難しいのか。チーム開発においてどのような困難や問題点があるのか。

    そしてそれでも僕たちがリモートワークを選択する理由やメリットは何なのか。

    赤裸々にお話しようと思います。

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - Teamwork Revolution - モブプログラミングという働き方 -

    45 mins
    Case Study
    Beginner

    モブプログラミングとはチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターで行うことです。

    日本においても、2017年に一気に話題となりました。
    そのきっかけとなったモブプログラミングという働き方で紹介した楽天のモブ=チームがその後どうなったのかについてお話します。

    私達のモブでは、時間を決めてワークショップ形式で行うのではなく、朝来てから帰るまで働き方として実施しています。そのため、開発だけでなく資料作りや営業やモブプログラミングの体験会などすべてにおいてモブワークをしています。

    • スクラムを中心としたアジャイル開発を精力的に行ってきたメンバーがモブプログラミングを通してどのように変化したのか
    • 実際に仕事の成果が出せたのか
    • モブとその外の関係性はどうなのか
    • モブ=チームのその後(※今後の活躍次第)

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

    スクラムとモブプログラミングは、チーム全体のアプローチやチームビルディングという点で共通項も多い一方で、別の視点で仕事の本質やチームの本質について考えるきっかけになりました。

    モブプログラミングに興味がある方はもちろん、そうでない方にとってもチームについて考えるきっかけを得られるようなセッションにしたいと思います。

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - 見せる化活用、チームで活かすファシリテーショングラフィックの学び方

    45 mins
    Workshop
    Beginner

    みなさん、ファシリテーショングラフィックしてますか?

    会議の場で使われるのが一般的ですが、私は人の話を聞く時も、ちょっとした立ち話をする時になんかも「描きとる」ようにしています。描くことをすること自体が、フォーカスしてしっかり「聴く」ことにもなっていますし、描いたものからフィードバックを得て、話し合いが、物事が進みやすくなります。

    どんな場で、どう使いたいか?

    まずはファシリテーショングラフィックを始めてみようと思っても、どういう場で、どう使いたいかを想定してみないと、あまり素敵な結果を生まないこともあったりします。そこで、今回のワークショップは参加した方々の想定する場に対して、どういうポイントで描くのがよいのかなど、お話していきたいと思います。

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Walking Scrum History with Patterns

    Harada Kiro
    Harada Kiro
    Senior Consultant
    Attractor Inc.
    schedule 1 month ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Scrum is a set of well-defined rules that enable teams to work effectively to deliver valuable products. Scrum Guide is the rule book of Scrum. You are requested to follow the rules to get benefits of Scrum.

    But why do you need to follow Scrum rules? Scrum says it is crucial to inspect and adapt. So why not inspect how Scrum rules work.

    This session explores the history of Scrum with patterns. The first Scrum paper was published in a form of pattern language. By looking how these patterns have evolved, we hope to see how these Scrum rules are formed and have better understand why they are rules.

    This session concludes with the update of ScrumPLoP.

    This session can also be delivered in Japanese.

  • Liked Pondd Suwitcha Sugthana
    keyboard_arrow_down

    Pondd Suwitcha Sugthana - MASTERING CUSTOMER JOURNEY: creating artifact to bind the team

    20 mins
    Talk
    Beginner

    "What are we building? And why?"

    "I need this info! Where do I get it?"

    "I've got a lot of user research, what's next?"

    Chances are you will hear these words from your team many times in any project.

    Is your team making wasteful decisions because they didn't have a common understanding - especially across different roles? Is your team slowing down because the knowledge and decisions are owned by just a few key people? And what if some of these key people who own the knowledge take a vacation when you most need them?

    In this talk you will learn how convert all the great user insights you gathered and discovered into easy and actionable items that your team can use to move your project forward.

    You will learn to:

    - Externalise knowledge from your team
    - Consolidate and align vision
    - Create a core onboarding journey
    - Make better user of empathy
    - Understand "as-is" state and how to drive to an ideal "to-be" state

  • Liked Oscar Lopez Alegre
    keyboard_arrow_down

    Oscar Lopez Alegre - Why we do scrum? incremental product development

    20 mins
    Experience Report
    Intermediate

    I will start with something that most people in the software industry will not like. Building software is easy, you can get some tutorial and get code working. When you try to build good quality software, well that's complicated. You need to understand what you're doing. But then, what is complex? Creating the right product for your users.

    Most teams focus more when applying scrum on Software and Quality software, but forget about the problem of creating the right product.

    The output of each iteration of scrum is a software increment, and I think that's the core of the problem on many teams failing on scrum. They build the increment, but they forget why they build it. Scrum teams need to recover the view on the reason to apply scrum and why we embrace iterative development.

  • Liked takashi imagire
    keyboard_arrow_down

    takashi imagire - 開発プロセスだんどり

    20 mins
    Case Study
    Intermediate

    スクラムは「トヨタ生産方式」と源流を同じくしており、継続的に組織を良い状態に向けて進めていくという考え方は同じであるし、トヨタ生産方式を基盤としたリーンの考え方がその根本にあることは良く知られています。

    ただ、リーンは欧米から輸入された考えであって、トヨタのおひざ元の日本でそれをありがたがって使うのって、どうかと思いませんか?このセッションは、トヨタ生産方式以降のトヨタの考え方をソフトウェア開発のプロセスに載せて、スクラムを発展させられないかという試みについての結果をお話ししたいと思います。

    具体的には、自工程完結で重要な「段取り」の考え方をチーム開発と個人研究に適応してみて、改善を行いながらプロセスのフォーマットとセレモニーを構築していった事例となります。

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-

    Yusuke Amano
    Yusuke Amano
    Scrum Master
    Cybozu, Inc.
    schedule 1 month ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    作るものに納得感がない、いつも納期に遅れる、改善ができない…

    このような問題を解決してチームワークを発揮するために、サイボウズでは2016年10月から私が所属するkintone開発チームでスクラムを導入しました。

    チーム全員が未経験の状態でスクラムマスターになり、沢山の壁にぶつかりながら試行錯誤を繰り返してきました。このセッションではサイボウズでのスクラム導入で取り組んだ活動をふり返りながら、開発プロセスや品質・チームの文化に起きた変化をご紹介します。

    さらに他チームや他部署のみならず総務や営業の現場にまで及んだマインドセットの変化・アジャイルプラクティスの導入についてもお話します。アジャイルの考え方は開発以外の現場でも活用できることを実感し、現場改善や組織変革のヒントにしていただければと思います。

  • Liked Kazunori Morita
    keyboard_arrow_down

    Kazunori Morita - 『ベヨネッタ2』におけるゲーム品質を上げる為の自動化 ~オートプレイと継続的なパフォーマンス計測~

    Kazunori Morita
    Kazunori Morita
    QA Engineer
    PlatinumGames Inc.
    schedule 4 days ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    関西で開催されましたゲームクリエイター向け大規模勉強会 GAME CREATORS CONFERENCE '16 や、日本最大のゲーム開発者向けカンファレンス CEDEC 2016、地方開催 CEDEC+KYUSHU 2016 にて講演させて頂きました3Dゲームにおける自動化の講演となります。

    開発者ブログでの記事公開が2014年という事で技術的にも古い内容とはなりますが、
    少ない作業時間の中から作成し最大限効果を出したオートプレイ。

    品質を上げる為の継続的なパフォーマンスチェックと、そのデータの見える化への技術選定と運用について

    必要な最低限の機能を「小さく素早く実装」したお話させて頂きたいと思います。

  • Liked Eiichi Hayashi
    keyboard_arrow_down

    Eiichi Hayashi - 共創による組織改革の進め方

    100 mins
    Workshop
    Beginner

    プロジェクトチームのマネジメント品質は、その母体となる組織のマネジメント品質を超えることは難しいものです。

    チームの活性化のあとはどのようににして組織全体を共創的な場に変えていくのかがが次の課題になります。

    このセッションでは共創的な組織をつくるためにどのようなアプローチが有効かを事例を交えながら参加者と一緒に考えます。

  • Makoto Takaesu
    Makoto Takaesu
    CEO
    Studio LJ, Inc.
    schedule 2 weeks ago
    Sold Out!
    45 mins
    Tutorial
    Beginner

    アジャイル開発を実践、導入支援、他のコーチとの交流の中で蓄積された、雑多な小ネタを集めました。

    今の現場にそのまま導入するもよし、何かと入れ替えるもよし、自分たち流にアレンジするもよし、お好きな感じで使ってもらえればと。

  • Liked Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - THE ONE - ヒトリからヒトツへ

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    Rakuten, Inc.
    schedule 3 weeks ago
    Sold Out!
    20 mins
    Case Study
    Beginner

    One for All, All for One, To become The One

    - LIVE AT WEMBLEY / BABYMETAL

    登壇者は、スクラムでの開発を続けた後、ひとりでの開発、そしてモブプログラミングのチームで働くという経験をしてきました。また、現在ではモブプログラミングの原型から離れ、一見バラバラに見えつつも、ひとつの共通認識を持ちながら道なき道を突き進んでいます。本セッションでは、この経験を元に、両極端なひとりぼっちの開発とモブでの開発のそれぞれの良いことと悪いことをエンジニアの視点から紹介します。

    このセッションに参加した人が、ひとりでの開発ではなく、チームでの開発を望むようになっていただければ幸いです。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - Scrumが難しいのは幻想 -情熱の再定義-

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 3 weeks ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。

    このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。

    チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、

    なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

    我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。

    結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。

    チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。