filter_list help_outline
  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - ファシリテーションの難しさと楽しさ

    20 Mins
    Thought & Practice
    Beginner

    ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

    そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
    そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

    その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。


    ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)


    このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

  • Liked Matteo Carella
    keyboard_arrow_down

    Matteo Carella - Coaching resilient Scrum teams

    Matteo Carella
    Matteo Carella
    Agile Coach
    Vodafone
    schedule 4 weeks ago
    Sold Out!
    45 Mins
    Thought & Practice
    Intermediate

    The concept of antifragile (things that gain from disorder according to Taleb's definition) is crucial if you want to coach a resilient team. In other words, a resilient team is able to survive uncertainty, volatility, stress and variability by changing adaptively rather than always remaining the same. We will see how this can be possible in some contexts, working on the boundary conditions that allow resilience to emerge as a bottom-up property of a work group, through experimentation and continuous learning on the field. I will also explain how in Vodafone (actually involved in one of the biggest agile transformation on scale) we conceived a framework to promote resilience and scrum teams agility on scale.

  • 45 Mins
    Thought & Practice
    Beginner

    みなさんは楽しくふりかえりをできていますか?

    スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

    マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。

    場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。

    場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。

    以下のことを中心にお話いたします。

    • ふりかえりの3つの目的と3ステップ
    • ふりかえりにおける「場」とは
    • 物理的・心理的に場を作るための方法
    • ふりかえりをより楽しくするための方法
    • ふりかえりのさまざまな手法
  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting

    Narichika Kajihara
    Narichika Kajihara
    Agile Coach
    eureka,Inc.
    schedule 3 weeks ago
    Sold Out!
    20 Mins
    Advanced Case Study
    Advanced

    「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。

    その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
    トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。

    開発部門以外にも適用した事例について、お話させていただきたいと思います。

  • Liked Shigeki Morizane
    keyboard_arrow_down

    Shigeki Morizane - 全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~

    Shigeki Morizane
    Shigeki Morizane
    CTO
    Levtech Co., Ltd.
    schedule 3 weeks ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。

    これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。

    でも、どちらもSCRUM!全部SCRUM!

    規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。

  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Misa Fukuhara - 「自分を立てなおす対話」をやってみよう! ♥ 智慧の車座ワークショップ

    100 Mins
    Workshop
    Beginner

    みなさん、仕事上で理不尽な思いをしたり、毎日の仕事で目標が見えず不完全燃焼していませんか?

    自分でもなくても、仕事を「こういうものだ」、前はバリバリと精力的に活動していたのに、今は元気がないなぁって人がまわりにいませんか?

    社会人生活や人生において、ロジカルには解決できない問題がたくさんあります。

    そのような問題を解決・解消するひとつの方法として、皆さんに「対話」を紹介し、少しでも健やかに日々を過ごしていただきたいというのが、このプロポーザルを出した理由です。

    本セッションでは、プロコーチ、組織コンサルタント加藤 雅則さんの著作『自分を立てなおす対話』で紹介されている『智慧の車座』をやってみたいと思います。

    https://www.amazon.co.jp/dp/453231707X

    智慧の車座は、問題を抱えたテーマオーナー(相談者)と、複数の支援者の対話を通して、「問題をほぐし」「智慧を出し合い」解決方法を模索する対話法です。

    このワークショップ参加後に、以下のような状態になればよいなあと考えています。

    1. 「自分を立てなおす対話」とは何かを知る
    2. 「自分を立て直す対話」を(なんとなく)できるようになる

    人生に迷っているあなた、このワークショップに参加して、暗闇荒野に進むべき道を切り開いてみませんか?

    興味を持たれた方はぜひ、投票をお願いいたします。

    「対話こそ、金より輝かしく光よりいのちあるもの」(ゲーテ)

  • Liked Masamichi Otsuka(radiocat)
    keyboard_arrow_down

    Masamichi Otsuka(radiocat) - あきらめないスクラム -事業拡大を続ける会社と成長を続けるサービスの中でチームがアジャイルであり続けるための闘い-

    20 Mins
    Thought & Practice
    Beginner

    株式会社ラクス は中小企業向けのクラウドサービスを提供し、18期連続増収で事業拡大中の会社です。私が所属するチームは主力サービスである 楽楽精算 の開発を担当する大阪の開発チームです。これまでに社内初のモバイルアプリやAIによる入力補助機能など、サービスの成長を支える新機能の開発を行ってきました。その取り組みを活かしてチームをさらに加速させサービスのさらなる成長を支えるために、2018年からスクラムの実践にチャレンジしています。

    本セッションでは、成長を続ける会社と主力サービスをとりまく不確実性の高いビジネス環境の中で、様々な変化に向き合いながらチームがアジャイルであり続けるために取り組んだこの1年間をスクラムの現場の視点で総括します。

    過去の発表資料はスクラムを始めた最初の半年がベースとなっており、スクラムを知らない人も対象としているためやや抽象化した内容となっていますが、本セッションではスクラムの実践についての知見があるかたを対象にスクラムの現場のコンテキストでお話する予定です。

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - 学習する/Unlearnするチーム入門 ー スクラムとモブプログラミング ー

    45 Mins
    Thought & Practice
    Intermediate

    チームがうまくなるために、学習と向き合うことはとても大切です。

    私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。

    ところが、モブプログラミングに出会って、これまでやってきたことは「分担する=効率がいい」「分担をいかにうまくやるのか」という先入観の上で成り立っていたことに気づき、衝撃を受けました。

    また、新卒向けの研修に携わった際に、多くのプロフェッショナルチームが導入や改善に苦労している仕事の進め方を、言葉すらはじめて知った彼らがいとも簡単に使いこなしてしまう姿を目の当たりにして、衝撃を受けました。

    私達は、

    • 学習し続けていく中で固定観念に囚われてしまうことがあること
    • 学習をしていないことが圧倒的成長スピードを生むことがあること

    という事実に向き合う必要があります。

    学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。

    もっとうまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。

  • Liked Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

    20 Mins
    Advanced Case Study
    Intermediate
    モバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。

    アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。

    ・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった
    ・開発業務中に運用業務の差し込みが入り、度々開発が中断していた

    これらの根本課題に対処するため、以下を実施しました。

    1. 開発チームを分割し、コミュニケーションパスを設計
    2. Scrumをベースに、複数のチームが並行バージョン開発出来るように開発フローを設計
    3. 次々バージョン開発チームが運用業務を行うようにし、次バージョン開発チームの業務中断を抑止

    本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。
  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - プロダクトバックログアイテムの価値をどう扱うか?

    20 Mins
    Advanced Case Study
    Intermediate

    Scrumで「プロダクトバックログアイテム(PBI)の価値をどう考えて、どのように扱うか?」というのは時々聞く質問の1つです。

    1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
    また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。


    プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)



    このセッションでは、"プロダクトバックログにおける価値の取り扱いのやり方”のいくつかの事例や現場コーチとしての知見や考えをお伝えします。
    みなさんのプロダクトバックログがより良くなるヒントになればと思います。

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Ikuo Suyama - Fail fast, learn fast - Celebration Grid:Management 3.0の組織を変えるプラクティス

    45 Mins
    Thought & Practice
    Intermediate

    Celebration Grid

    チームメンバー、チーム、および組織は、すばやく失敗し、学習することによって、毎日の改善が必要であるため、成功と失敗から学ぶことは重要です。失敗を祝う方法、なぜ実験を行うことが重要であるか、そのような実験をマネージする方法を学びます。
    Management 3.0 はオランダ出身のヨーガン アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念で、「人ではなく、システムをマネージするべき」という考え方です。Celebration Grid は Management3.0の中でもAppelo氏が「最も重要なもの」と位置づけるプラクティスです。

    CyberAgent AdTech Studioでの事例紹介

    CyberAgent ではこれまで2度ステファン氏によるManagement3.0社内研修を実施しており、20名以上の参加者が1年以上にわたり Management3.0 の取り組みを続けています。
    今回はその中でも「セレブレーショングリッド」のプラクティスを社内でどのように運用し、どのような成果が得られたのかを、成功と失敗の事例を交えてお話します。
  • Liked Fumitaka Inayama
    keyboard_arrow_down

    Fumitaka Inayama / Kazuki Mori / Ken Takayanagi / Shigeki Morizane / Toshiaki Nomura - フルバージョン登場!「プロばこ」で学ぶ作業プロセス・デザイン・ワークショップ

    100 Mins
    Workshop
    Beginner

    「考えていた作業計画と実際の作業が全然違っていてチームの作業が進捗しない」
     「改善をしているはずだけどトラブルが起きてからの事後対処になっている」
    などの経験をしたことはありませんか。

    チームメンバを招集して、チームビルディングも儘ならないでプロジェクトを始めてしまって、後手後手にチームの仕事のルールを決めたり、メンバ同士の関係作りに時間を使うくらいなら、最初に『プロばこ』でワークショップをご体験ください!!

     フルバージョンで登場する「プロばこ」は、チームの作業プロセスのデザインと合意形成のフローを体験できるパワーアップしたワークショップです。

    rsgt 2018では、QualityとDeliveryの2つを制約条件にチームの作業プロセスをデザインしました。フルバージョンでは、さらに2つの制約事項がチームの制約として追加されます。

     あなたのチームは、さらに複雑になる制約条件をくぐり抜けられる作業プロセスをデザインできるでしょうか…

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Scrum@Scale Guide を読んでみよう

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 4 weeks ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    Scrum@Scale Guide を読んでみましょう(RSGT2019までには日本語版が出ているはず)。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - 心理的安全性ゲーム

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 3 weeks ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

    「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。

    このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。

    20分なので、ゲームそのものを体験するのが中心になります。心理的安全性という考え方の紹介、参加者同士でのふりかえりは最小限になります。

  • Liked Satoru KawaBuchi
    keyboard_arrow_down

    Satoru KawaBuchi - NTTみたいなトラディショナルな企業でアジャイルな取り組みを実現するたった一つの必要なもの!

    20 Mins
    1st Step Case Study
    Beginner

    大企業の中でファーストケースとしてのアジャイルを生き延びさせるには?

    起きてくる現場と社内との課題、その時マネージャーにできることは?

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Thought & Practice
    Advanced

    チームがうまくいっていることはスクラムチームの大きな目標です。

    いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

    良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

    数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

  • Liked Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイル開発でコールド負けしないための5つのポイント

    45 Mins
    Thought & Practice
    Beginner

    多くの組織では、うまく進めるためのショートカットやツールを求める傾向にありますが、足元が固まっていない状態でさまざまなプラクティスやツールを導入しても無意味で、混乱したまま成果も出せずに終わってしまうこともあります。また、そのような状態で大規模な開発を進めるのは自殺行為です。

    本セッションでは、アジャイル開発をうまく進めるために最低限考えなければいけないポイントをスクラムの文脈で紹介いたします。これらのポイントは多くのアジャイルコーチングの場において強く伝えていることです。

  • Liked KazuhideInano
    keyboard_arrow_down

    KazuhideInano / Yoh Nakamura - 受託開発だったりロケーション離れてたりなど課題たくさんの中で支援している現場の話

    20 Mins
    1st Step Case Study
    Beginner

    「もっとビジネスのスピードを上げたい」という課題意識があり、それの解決方法として「今までのやり方のままでは難しい。だからアジャイル開発手法を導入したい」と考える企業は多いです。

    とはいえ「さあ始めよう」とするにしても、関わる人のマインドや協力会社との関係性、とりまく環境などなど変えて行かなければならないことがたくさんある場合が多く、実際のところそれがなかなか大変だったりします。人も組織もなかなか急には変われないものですよねぇ。

    よく直面しがちな課題の例を挙げてみると...

    • 受託開発でPOが発注側、DevチームとSMが受注側という関係性
    • 復数Devチームだがコンポーネントチーム
    • Devチームが個の集団
    • 複数POが織りなす複雑なビジョン
    • 得られた成果やアジリティが見えない
    • POとDevチーム、SMのロケーションが別
    • コミュニケーションしづらい座席レイアウト

    などなど。

    さて、このセッションではこのような課題を抱えつつもスクラムの実践に取り組み奮闘している現場のひとつをケーススタディとして、実際にどんな課題があり、スクラムチームやコーチがどのように取り組み解決を試みたのかの成功談や失敗談をみなさんの参考になるべく紹介したいと思います。

  • Liked Fumitaka Inayama
    keyboard_arrow_down

    Fumitaka Inayama - いっけなーい✏️✏️『リーダーシップスタイル簡易診断ワークショップ!』あなたの『リーダーシップ・スタイル』はどのタイプ❣️

    Fumitaka Inayama
    Fumitaka Inayama
    PMP
     
    schedule 3 weeks ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    <ようこそ>

    1)『リーダーシップ・スタイル簡易診断』の進め方の説明(5分)

    2)自分が信じているリーダーシップスタイルをチェック(3分)

    3)『リーダーシップ・スタイル簡易診断』もパパッとチェーック!(5分)

    4)信じていたリーダーシップスタイルと簡易診断結果を比較と周りと共有(7分)

    <参加ありがとう>

  • Liked Arata Fujimura
    keyboard_arrow_down

    Arata Fujimura - 結局DevOpsって何だろう? 〜10年目の定義ぐらい大目に見てよ〜

    Arata Fujimura
    Arata Fujimura
    Manager
    Classmethod, Inc.
    schedule 4 weeks ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner
    2009年にDevOpsという言葉がうまれてからそろそろ10年。
    元はDevとOpsが対立せずに連携して協力していこう開発スタイルに過ぎなかったこの造語が、明確な定義を持たないために様々な意味合いが後付され、DevOps担当者である私を苦しめます。

    そこで私自身、「俺のDevOps」を定義しました。
    これやっとけば、俺がDevOps認定するぜ!ってことを、事例交えてお話します。