新任スクラムマスターがベテランチームと勇気を持ってスクラムの再スタートを踏み出した話
背景
スクラムマスター未経験の状態で前任者から引き継ぎを受けた駆け出しスクラムマスターのお話。
引き継ぎを受けた時点でチームにはある程度自律的に動けるメンバーが揃っていたため、引き継ぎ後も前任者のスタイルを概ねそのまま踏襲していた。
それから2年ほど経ち、メンバーとの1on1やスプリント毎のレトロスペクティブ(振り返り)を通して、チームには以下の課題があると感じるようになった。
- スキルセットの関係から、スプリント開始直後から優先度の低いバックログに着手するメンバーがいた
- 優先度の低いバックログのため、せっかく実装が完了してもテスト、リリースに着手できるまで数ヶ月かかることがざらにあり、メンバーのモチベーション低下に繋がっていた
- ペアプロやモブプロといったチーム内のスキル平準化につながる手法を何度か取り入れるもなかなか定着せず、結局1人1バックログを担当する文化が定着してしまっていた
- 「このままこのチームにいてもスキルアップが望めない」「数年後にスキルが身についている自信がない」というメンバーからの率直な意見が出ていた
- リモートワークに突入するとチーム内の会話やコミュニケーションの量が減り、上記の一人バックログの文化とあわさりチームという意識が減少してきてしまった
「これだけの課題がある以上、スクラムマスターとしてなにかアクションを起こさなければ!」
そんな考えを持ちつつも、彼は彼で人知れずこんな葛藤を抱えていた。
- チームやプロジェクトに対して駆け出しの自分なんかが変化を起こしてしまって良いのか、もはやどこかのアジャイルコーチに任せるべきことなのではないのか
- そもそも先述の課題を課題だと思っているのは自分だけなのではないか
- メンバーやPOは特に変化を望んではいないのではないか
- ベロシティを見る限りでは表面上は特に問題があるように見えず、自分がアクションを起こすことでかえってベロシティが大幅に下がってしまうのではないか(というかほぼ間違いなくそうなる)
- そうなる可能性が高い以上は説明責任を果たさなければならないが、POやステークホルダーからの理解を得られるのか
- むしろ「余計なことをするな」と言われてしまうのではないか
- 日々の業務だけでも時間が足りていないのに、果たしてチームの改革までやりきれるのか
実はプロジェクト内では去年からパイロットチームが立ち上がっており、一足先に「なんちゃってスクラムチーム」からの脱却に成功し、成果を上げていた。
そんなこともあり、今ならプロジェクトの後押しを受けながら変革を推し進めることができるのではないか、と考えていた。
ある日、チームの抱える課題についてSoSMや上記のパイロットチームを含めた他のチームのスクラムマスターに相談する機会があった。
そのとき言われたほんの些細な一言が、一歩を踏み出すきっかけになった。
『とりあえずダメ元でもいいから、いったん率直にPOに話してみたらどうです?もしダメならダメで次の手を考えましょう』
その一言に背中を押され、早速POとチームのメンバーに話をしてみると自分の今までの葛藤は何だったのかと思うほど状況が前進した。
POやチームメンバーからの賛同が得られ、「なんちゃってスクラムチーム」から「真のスクラムチーム」への第一歩を踏み出すことができた。
これから「なんちゃってスクラムチーム」から脱却し、「真のスクラムチーム」への変革を目指す方に向けて、
駆け出しスクラムマスターが実際にチームのカイゼンのために実施した取り組みについて、少しでも参考になるお話ができればと思います。
こんな人に聞いてほしい
- なんちゃってスクラムから脱却し、真のスクラムチームへの変革を目指す全ての方
- スクラムガイド通りのスクラムが実践できているか自信が持てないスクラムマスターやスクラムチームメンバー(デベロッパー)
- 自チームのスクラムマスターが思ったような動きをせずに悩んでいるプロダクトオーナー
- 冒頭に挙げた、チームが抱える課題感に共感した人
Outline/Structure of the Talk
- 今回の取り組みに至った経緯
- チームが抱えていた課題感
- スクラムマスターの抱えていた悩み
- 従来のやり方からなかなか脱却できなかった理由
- 従来のやり方から脱却できたきっかけ
- 取り組み内容の詳細
- チームの抱える課題についてチームに共有してみた
- 同じくPOにも情報を説明し、チームを改善するための時間がほしいと伝えてみた
- 「自分たちにとっての理想のチーム」はどんな姿だろうか
- 具体的に見直しを行うプロセスの洗い出しと改善方針のすり合わせ
- 取り組みの結果
- チームの雰囲気の変化
- バックログのとり方
- スクラムマスター目線での気づき
- 同じような悩みを抱えている方へメッセージ
Learning Outcome
- 変化を起こすための勇気をもらえる
- 気がついたらスクラムっぽくないスクラムになっている時のチーム改善のヒントとなる
Target Audience
スクラムガイド通りのスクラムが実践できているか自信が持てないスクラムマスターやスクラムチームメンバー(デベロッパー)、 自チームのスクラムマスターが思ったような動きをせずに悩んでいるプロダクトオーナー
schedule Submitted 4 months ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yasunobu Kawaguchi - 川口恭伸の全国スクフェスにズームイン!!
30 Mins
Talk
Beginner
スクフェスオーガナイザー川口恭伸が全国のスクフェスにズームイン!!
地域トラックの見どころを紹介しちゃいます!!!
朝から盛り上がっていきましょうね!!!
-
keyboard_arrow_down
Yoh Nakamura - スクラムマスターってなにをもたらすの?
20 Mins
Talk
Beginner
組織で初めてScrumに取り組んだ時によく出てくる話題の1つに"スクラムマスター"が出てきます。
理由は様々でしょうが、その1つに"これまでの組織の役割になかった"ということがありそうです。そのため、そもそもどんな目的なのか?なにをすればいいのか?なにはしないのか?などの疑問が湧いてくることあります。
このような疑問をうまく消化できないとスクラムマスターとして活動している人たちもスクラムチームも、そしてよりよいプロダクトを届け事業成長したい組織にとっても損失が生まれることもあります。
このセッションでは、そのような残念な結果にならないために、"スクラムマスターってなにをもたらすの?"というテーマでお話します。
-
keyboard_arrow_down
Jean-Baptiste Vasseur - Fun Done Learnの原点に立ち返る・・チームが本質的にアジャイルであり続けるには何が大事か
45 Mins
Talk
Intermediate
Fun Done Learnが誕生してまもなく5年。
これを機に原点回帰してチームとして本質的にアジャイルであり続けることとはどういう意味なのか、そのためには何が大事なのか、そしてそれがどうFun Done Learnに繋がったのか、ふりかえります。Fun Done Learnで。
-
keyboard_arrow_down
Yuichi Tsunematsu - 技術プラクティスの整理に1年半向き合ってわかったこと
45 Mins
Talk
Intermediate
アジャイル開発の実践には「プロセス・チーム運営」に関するプラクティスだけでなく、「技術・ツール」に関する技術プラクティスも重要です。真正面から技術プラクティスの取り組みを取り上げ、良い知見を広く探求してきたいという思いからRegional Scrum Gathering Tokyo 2022で登壇機会をいただき、さらに登壇をきっかけに『アジャイルプラクティスガイドブック』という本を書く機会をいただきました。
書籍として形にしていく過程では色々なことを考える必要がありました。「アジャイル開発の技術プラクティスを扱った書籍は無いのか」「技術プラクティスをまとめた情報が少ないと感じる理由はどこにあるのか」「2023年に出版する書籍としてどの技術プラクティスを紹介するべきか」などなど。
本講演は書籍が出版されるまで1年半ほど技術プラクティスの整理に向き合うことでわかったことを紹介し、知見を体系立てて整理するために必要だと学んだことをお伝えします。
-
keyboard_arrow_down
Satoshi Harada - 社内アジャイル勉強会コミュニティの火を燃やせ!製造業に入社して4か月でやったこと全部見せます!
45 Mins
Talk
Beginner
このセッションで伝えたいこと
本セッションでは、製造業にアジャイルコーチとして入社したSatoshi Haradaが、社内アジャイル勉強会コミュニティの火を燃やすために何を考え・何をしているのか、可能な限り全部お見せしようと思います。
このセッションを見た方には、社内でアジャイル勉強会コミュニティを立ち上げた実例を知っていただきます。そして、社内アジャイルコミュニティを立ち上げよう・盛り上げようと思っている方に、コミュニティ活動はFUNが大事であることを知ってもらい、一歩目を踏み出す勇気を持って帰ってもらいます。
私が社内コミュニティ活動を開始した理由
現在の会社にアジャイルコーチとして入社して4カ月になりました。
勤めている会社は、創業150年・従業員数4500人超の国内製造業です。この会社では既にDXやアジャイルといった取り組みが進んでおり、スクラムの研修開講やプロジェクトでのアジャイル適用が行われていました。素晴らしいことです。
この素晴らしい取り組みをさらに加速させるためには何が必要だろう?
そう考えた私は、もっと”FUN”が必要で、そのための社内コミュニティ活動の楽しい"場"が必要だと感じ、行動を始めました。・社内のアジャイルコミュニティをもっと楽しく!さらに盛り上げたい!
・有志による楽しい学びの場を作りたい!そんな気持ちで、社内のアジャイル勉強会コミュニティを自ら立ち上げて運営を開始したのです。
しかし、順風満帆・全てがうまくいっているわけではありません。
勉強会に誰も来ない…
盛り上がらない…
運営が大変…
自分だけが運営を頑張っているのかも?
そんなふうに思うときもありました。そんなとき私は、「コミュニティ運営は焚火に似ている」と思うことにしています。
焚火は火をつけてからだんだんと太い薪に着火させて炎を大きくしていくのですが、その様がコミュニティ運営に似ていると思うのです。そこで私は、社内アジャイル勉強会のコミュニティでいろいろな企画を投下してきました。焚火でも薪を投入する順番はよく考える必要があります。コミュニティ運営も同じです。
その結果、少しずつではあるのですがコミュニティ参加者が増え始め、勉強会の運営も参加者が主体的に関わってくれるようになってきています。そして忘れてはいけないのは”FUN”です。焚き火も楽しいですよね?コミュニティ活動にも楽しさは不可欠だと思うのです。
なぜこのセッションをやろうと思ったか
私の社内アジャイル勉強会コミュニティの立ち上げと運営はまだ4か月ですが、まだフレッシュな状態で私が何を考え・何をしてきたかを発表することで、同じように社内のコミュニティを盛り上げたい!と考えている人の背中を押すことができるのではないかと思いました。
社内でアジャイルを進めるにあたって、「仲間がほしい」「共通の話題で相談できる場所が欲しい」「学びを深めることができる場所が欲しい」と思ったことはありませんか?
もしまだそのような場がないという方、ぜひ自らそのような楽しい場を立ち上げましょう!そのような一歩目を踏み出す方に勇気を持って帰ってもらえる焚火のようなセッションにしようと思います。
-
keyboard_arrow_down
Shogo Kinjo / Yui Yoshida / Yuu Hashimoto - モブの旅:チームの進化と1年間の歴史 〜私達が「モブの皆さん」と呼ばれるまで〜
Shogo KinjoApplication EngineerRakuten Group, inc.Yui YoshidaApplication EngineerRakuten Group, inc.Yuu Hashimotoapplication engineerRakuten Group, inc.schedule 4 months ago
45 Mins
Talk
Beginner
私達について
私達は楽天グループでラクマというフリマアプリを開発する部署に所属しているSoftware Engineerでして、主に広告や事業者向けの機能を開発しています。
ラクマは現在楽天グループが運営・開発しておりますが、前身は日本初のフリマアプリ「フリル」でして現在は3500万ダウンロードされております。
私達3人は同じチームに所属しているのですが(マネージャーを含めると4名体制です)、基本的に毎日始業から終業までをほぼモブプログラミング・モブワークをしています。(以下モブワークと総称します)
チームとしてもScrumを取り入れていて、ほぼ全てのバックログをチームで取り組んでおり究極の一個流しをチームで実現させようとしています。
毎朝Daily Scrumでその日に取り組む事を皆で話し合って決め、そこから途中こまめに休憩を挟みつつ基本1日中終業までモブワークを行っています。
これまではリモートで仕事をすることが中心だったので、Zoomを繋げっぱなしにしつつコードシェアをしながら役割を10分タイマーで交代しながらモブワークをしています。
コロナが落ち着いてきて関係で楽天では出社が増えてきておりまして、全員出社してる時は一つの場所に集まって同じ画面を見ながらワイワイモブワークをしています。
モブの皆さんと呼ばれるまで
私達は今組織の中で「モブの皆さん」と呼ばれています。
これは個人としてではなく、チームとしてモブワークを実践してきた事が周りの皆様にも認知してもらっている結果だと思っています。
ですがチームが出来た1年半ほど前はそんな事は全くなくて、発足当初はメンバーの4名中2名が入社したばかりでRails経験が浅い状態かつOJT中だったのもあってか、多くの課題を抱えていました。
- 業務の量に偏りがある
- レビュアーがいない
- さらに育成者もいない
そしてリモートワークが長引いていた関係で、メンバーの一人一人が不安を抱えながら開発をしていたという状況にもなっていました。
そんな状況を見て当時のマネージャーがモブワークを取り入れてみることを勧めてくれました。
そこからおよそ一年半、チームメンバーが減ったり、新しく増えたりなど色んな歴史を経て今に至っています。
途中チーム外の方から「分担作業の方が良くない?」というご意見をいただいてうまくチームとして方針を伝えられなかった事がありましたが、その時はマネージャーが間に入って盾となってくれて色々と関係各所との調整を行ってくれました。
試練の訪れと振り返りのきっかけ
そんな私達に大きな衝撃が走ったのは、私達にモブワークを導入して支援してくれ、チームの文化を築いてくれたマネージャーの退職が決まった時です。
当たり前の事なのですが盾となってくれていたマネージャーがいなくなった事で「これからは自分達で戦っていかないといけない」となり、改めて「私達はなんでモブワークをしているんだっけ、なんで良いと思ってるんだっけ」と考えさせられました。
そこからモブワークについて改めて調べ直し、言語化していく中で他チームから「モブワークについて教えてほしい」と言われる事が増えてきました。
自分達では何かを教えられるほどモブワークについて上達したつもりはなかったのですが、それでも通ってきた悩みや良かったことを共有することで双方で学びや発見がたくさんある事に気付けました。
これからの私達
現在絶賛トライ中なのが「目標設定とモブワーク」の問題です。
私たちも会社員ですので、目標設定とその評価というビッグイベントから逃れることはできません。
チームとしてタスクを成し遂げるのに、目標を立て評価をされるのは個人単位です。
これにどう向き合っていくのが良いのでしょうか。
今季の目標設定では「チームとして共通の目標を作ってそれを個人目標に組み込む」という新しいアプローチを試みています。
これはマネージャーと相談して、チームでのモブ活動に対して理解してもらおうと試みた一例になりますので、皆さんに紹介したいと思っています。
今回のセッションでは以上のような私たちのモブワークの歴史を共有いたします。何かの発見や学びに繋がったら幸いです。
-
keyboard_arrow_down
Daisuke Ashihara - スクラムアンチパターンを踏みまくったときの話をしようか
20 Mins
Talk
Beginner
スクラム開発うまくいってますか?
うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。
つまり守破離って大事ですよねと。
”スクラム アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ!」と散々警鐘が鳴らされています。
そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。
例えば・・・
- エンジニアが3人未満のチーム構成
- 全員が他の開発業務を掛け持ち
- スプリントバックログが常に終わらない
- 不完全なインクリメントでスプリントレビュー
- デイリースクラムをやめる ...etc
なぜ安直なアンチパターンを踏みまくったのか。
起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。
アンチパターンを踏みまくった結果、このチームやプロダクトはどうなってしまったのか。
スクラムアンチパターンを踏みまくったときの話をしようか。
-
keyboard_arrow_down
Junki Kosaka - みんなで試そう!自分やチームの本領発揮を引き出すペップトーク!
45 Mins
Workshop
Beginner
〜選手は体を鍛え技を磨くように、リーダーは言葉の力を磨く〜
各地で大変ご関心をいただいているペップトーク
今回は概要はきちんと押さえつつ、
簡単なワークショップを交えた形式で体験いただきます。今まで気になっていた方も
初めて目にして気になった方も
ペップトークに触れてみませんか?このセッションでは、
声がけからチームの本領発揮を引き出したり
自分や周りへの言葉の選び方だったりに役立つペップトークについて、
簡単な体験を通じてその日から使えるTipsをお持ち帰りいただきます。
<ペップトークとは>
アメリカで生まれた、スポーツの試合前で行われる
選手に向けた激励のショートスピーチから生まれて、
現在、教育やビジネスの現場でも活用されるようになってきた
自分や周りへの声がけのことを言います。 -
keyboard_arrow_down
keiichiro kawano - 日々の活動の中でマインドフルネス(雑念を脇に置く、イマココ)を意識して、ムダを省き、本質に集中する
20 Mins
Talk
Intermediate
チームが何かに夢中になると俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいがちです。目の前のタスクに集中すればするほど近視眼的になってしまうのです。そういう経験はありませんか?
僕は以前プレイングマネージャーをしていたことがありますが、成功させたい!と想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまうようなこともありました。
もう同じ過ちは繰り返したくない!専任スクラムマスターをすることになったのを機に「俯瞰して観る」ことを大切にしています。
スクラムはリーン思考に基づいており、スクラムガイド2020には「ムダを省き、本質に集中する」と書かいてあります。それって、マインドフルネスの「雑念を脇に置いておき、イマココに集中する」と同じでは?スクラムはチームでマインドフルネスをすることなのでは!と僕は解釈しこれまでスクラムマスターをしてきました。
日々の様々な活動の中でマインドフルネスを意識することで、雑念に囚われることなく、ムリ/ムダ/ムラをなくし、より良い活動ができるようになったと実感しています。その甲斐あってチームからも「俯瞰して観てくれて助かります」という声が何度かありました。この知見をみなさんと共有したいです。※毎日瞑想しましょう!というお話ではありません
-
keyboard_arrow_down
Kenta Sasa - 悩み方の考え方 〜悩みのモンスター化を防ぐために〜
20 Mins
Talk
Beginner
Scrum Festに参加する多くの方は、複数人でチームを組んで仕事をしていると思います。
また、所属するチームの外側には様々なチームがあり、複数のチームで構成される大きな組織の一員として働いている方が多いと思います。そういった様々な人々が関わる中で仕事をしていると発生してくるものが「悩み」です。例えばこのようなものです。
お悩み例
- なんでうちの上司はペアプロの良さを理解してくれないんだろ…
- お偉いさんと営業が勝手にお客さんと約束してきちゃったけど…どうすんのこれ?
- 会社の方針が分かりづらいし、みんなバラバラに動いてる気がするんだよなぁ…
このような状況に身を置くのはツラいものです。ツラい環境にいるのは居心地が悪く、ストレスも溜まりやすいため、いくつかの反応を行います。
- 私は関係ない、どうでもいいや、と割り切る
- 自分1人でもできそうなことをやってみる
- 自分の意見をぶつける、愚痴を言う
- どこか違う組織に移る
悩んだ時に、どんなことを考え、どんなアクションを取るかは非常に重要です。うまくいけば悩みが小さくなったり解決することができます。
しかし、落とし穴もあります。悩みを解決できる、もしくは悩みを感じなくなるような良さそうなアクションを取った結果、長期的には悩みが肥大化することがあります。肥大化が進み、悩みがモンスターに育ってしまうと周りの人も自分自身も傷つけてしまいます。
私も過去に色々やっちまった経験があります。今になってはいい経験ですが、その時は「こんちくしょー!」と思ったものです。そういった経験から、悩みとの付き合い方を学び、悩みが育っていかない体になって来ました。今は悩みとか全然なさそうと良く言われますし、Scrum Fest 札幌ではこんなセッションをやったりしています。
本セッションでは、私の元気な話は置いといて、悩んでいた過去の話、そこから学んだこと、今悩みを抱えた時にどう捉えどう考えどう行動しているか、をお話しします。皆さんがお持ちの小さな悩みがモンスター化するのを防ぎ、皆さん自身も、周りの人も少しでもハッピーになることを期待してます!
-
keyboard_arrow_down
Mirei (Kotone) Itaya - 「書いてみたい」のその先へ:経験がプロポーザルとして芽吹くまで
45 Mins
Talk
Beginner
「プロポーザルを出してみたい」
そう思っても実際に提出に至ることができる人は多くありません。それは普通のことです。なぜならプロポーザルを書いて提出するという行為は自らが生み出したモノを人の目に触れる場所に曝け出すことであり、それはとても勇気のいることだからです。それでも私がプロポーザルを提出できたのはコミュニティの皆さんが背中を押してくれたからでした。
はじめてのプロポーザルを書き上げるまで
私が初めてプロポーザルを投稿したのはスクフェス福岡でした。そこで私は初めて参加したRSGT2023に会社の仲間たちと一緒に参加して学んだことについて書き綴りました。書きながら私はいくつもの「内なる悪魔の声」と戦いました。「別にこの話は会社の他の誰かがしても同じじゃない?」や「こんな個人的な話を聞きたい人なんて本当にいるの?」といった声が脳内に響き渡りました。
そういった自己否定の気持ちと戦い抜くことができたのは、RSGT2023で「初めてのプロポーザルで自信がないのでアドバイスをください」と発言したのがきっかけで「スクフェス福岡のプロポーザルを読んでYYする会」の存在を知ったからでした。そこに草稿でもプロポーザルを持ち込めばフィードバックをもらえる。その気持をモチベーションにしてなんとか書き上げました。
フィードバックに背中を押された
プロポーザルを読んでYYする会で書いてきたプロポーザルについての話をする中で私は本文に書かなかった色々な気持ちを自然と口にしていました。RSGTに参加するまではカンファレンスに参加する強い意志がなかったこと、誘われて初めて「みんなで行くなら......」と腰を上げることができたこと、頭取に言われるまでプロポーザルを書いてみようという発想すらなかったこと。そんな何気なく言葉として紡がれた「私のストーリー」を皆さんは拾い上げて「それそれ!」「その話が聞きたい!」と言ってくださいました。
そしてその時に一緒に初めてのプロポーザルを書いた烏帽子さんとおーのAさんにも、今度は私も同じようにプロポーザルを書くに至った経緯を聞く中で「ぜひそれを語って下さい!」と言う側になっていました。この時に私は「結論が一般的でも経験は唯一無二だ」ということ、そして「私が誰かをすごいと思ってもその人にとってはそれが普通で、私が自分を普通だと思ってもそれは誰かにとってはすごいことがある」ということを学びました。そうしてYY会で受け取ったフィードバックを元にプロポーザルのリファインメントをし、ありがたいことに採択していただき登壇することができました。
この経験を届けたい
スクフェス福岡に参加した後、その次のスクフェス新潟の情報について調べていく中で「テストやメンタルヘルス」といった私が個人的にとても興味のあるテーマを取り扱っていることを知りました。私は「そこでプロポーザルを書いて得た学びを共有したい!」と思い締め切りが迫る中プロポーザルを書き始めました。「スクフェス新潟のプロポーザルを読んでYYする会」の当日も無我夢中で書き続けて『「あなたすごい人、私ふつうの人」を乗り越える!経験をプロポーザルにしてみよう』の原案を投稿しました。
YYする会に間に合わせるために気合でなんとか最後まで書きましたがこの時も私は「プロポーザル書いたなんて話私じゃなくてもできるし......」「もっとすごい人がプロポーザルを書いてるし......」という気持ちに負けそうでした。でもいざYYする会でプロポーザルの話をしていると「ぜひ聞きたい!」という声や、より伝わるようにするための具体的なアドバイスをいただくことができて取り下げずにがんばろうと思うことができました。そして再び得たフィードバックを元にプロポーザルをリファインメントし、再度登壇の機会をいただくことができました。
何度でも伝えよう
嬉しいことに新潟での発表を見て「プロポーザルを書いてみよう」と勇気を出してくださった方々がスクフェス大阪にプロポーザルを書いてくださりました。そして「スクフェス大阪のプロポーザルを読んでYYする会」で背中を押してもらっている姿を見て「ああ、あの時勇気を出してプロポーザルを書いて良かった」と心の底から思いました。でも同時に「自分じゃなくてもいいんじゃないか」という感情はそう簡単に克服できることではないということを改めて痛感しました。とても素敵なストーリーを持っているのになかなかプロポーザルを書く手が進まない。であれば何度でもこの想いを伝えよう。「あなたの唯一無二の経験にはきっと価値があるはずだ」というメッセージを送り続けようと思いました。
経験をプロポーザルとして言語化している時に私がどういうアプローチを取っているのか。プロポーザルを書き切る為にどういうことを考えているのか。採択されるためにどういう書き方をするのがいいのか。スクフェス大阪に向けて改めてプロポーザルを書きながら気がついたことについても盛り込みつつできる限りの私の想いをぶつけます。
-
keyboard_arrow_down
Tomonori Fukuta - 田舎で17.5年スクラムやってもままならないから面白いんじゃん 〜It would not be fun when life is easy done by 17.5 years scrum in the countryside〜
Tomonori FukutaAgile Evangelist / AgileLab. directorRICOH IT Solutions Co., Ltd.schedule 4 months ago
20 Mins
Talk
Intermediate
受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました!が、JTCの荒波に揉まれる我々!
- 期待している形で案件が来ない!
- 支援って、ちゃんと評価されるのか?給料下がっちゃうんじゃないの?
- 3年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく!
毎年お送りしている田舎スクラムチームの状況をお伝えします! -
keyboard_arrow_down
takehito koizumi - 中間管理職のおっさんがDX組織を作る辞令を受けてどう学んだか? 「ちょっと何言っているかわかんない」と共にした1年間
45 Mins
Talk
Beginner
・大規模ウォーターフォールの受託開発のマネジメントを大阪で10数年ずっと実施していたマネージャーがアジャイルでのプロダクト開発組織を作るべく、辞令をもらいました。短期間でアジャイルを学ぶため、どのような事をどのように学んだか?その中で感じた葛藤と解決策をお話しします。
前半パートでは
新たな用語だらけで、ウォーターフォールとの文化の違いが今一つわからない中で、短期間で学習する上でのTipsをお伝えします。中盤パートでは
「ちょっと何言っているかわかんない」というワードを使いながら、新しいことを学ぶ際にわからない事を前向きに増やしていく重要性とそのマインドセットのコツをお伝えします。後半パートでは
学習すればするほど、先人のアジャイル先駆者やアジャイルネイティブの若い世代と比べてしまい、恥ずかしさや今までの仕事に対して後悔を感じたこと。逆に学べば学ぶほど自社内では先駆者として孤立してしまうこと
それらに対して、過去の経験をプラスに活かし、仲間と共にどのようにポジティブに乗り越えたかを説明します。DXでのリスキリングの必要性が謳われている昨今、リスキリング対象のミドル層が、これから、新規ビジネス創出やアジャイルに取り組む際にヒントになれば幸いです。
<前半パート(短時間で学習するTips)の事例>
・本を読み、勉強会資料を作り、勉強会実施を繰り返して机上で学ぶ(「アジャイル/本」の検索ワードでトップとなる)
・アジャイル先駆者との過去時点のDiffを取る
・コミュニティが怖かったところから、3ヵ月で150本コミュニティの参加ブログを書くに至った変化<中盤パート(学習のマインドセット)>
・「ちょっと何言っているかわからない」を重視した学習方法(「完全に理解した」⇒「ちょっと何言っているかわからない」を素早く繰り返す)
・Majorityならではのアジャイルの入り方 (EarlyAdopterと違ってMajorityは効果の確実性を気にする)
・仮説検証型の学習方法<後半パート (ミドルとしての乗り越え方)>
・会社生活、折り返してから始めたアジャイルと20年間の意味
・仲間と乗り越える
・仕事だから(外発的動機)とやりたい(内発的動機)をマッチできるのはミドルの特権
・これから始めるミドル層へのエール(本セッションでは組織の変化よりお個人の変化に着目しての説明となります。実際にどんな風に組織が変化したかは興味があれば参考資料を確認ください)
-
keyboard_arrow_down
Yutaka Kamei - コードは自分のもの、だから組織横断でコードレビューをする
20 Mins
Talk
Intermediate
私が開発者としてコードレビューをするのは「コードは自分のもの」という意識があるからです。その意識は自分の所属チームだけにおさまりません。別チームがメインで変更を行うコードにも及びます。
今回のセッションではこのモチベーションとそれに伴う行動に至った私の体験談をお伝えします。
私は Rakuten Rakuma の開発組織に所属しております。 Rakuten Rakuma は開発メンバーだけでも大規模な組織であり、複数のチームがいくつかのアプリケーションを開発、メンテナンスしています。 Rakuten Rakuma に join した当時、まだ組織の開発スタイルがよくわからないので、とりあえず、組織内の主要な repository を watch することにしました。 Rakuten Rakuma に join する前に所属していた組織では、「pull request は open されたら自分の手を止めてでもレビューするのが当たり前」というような環境にいた事もあり、 join したてでわからないなりにもレビューをしてみようと思ったのです。このようなきっかけで組織横断でコードレビューをしてみると、だんだんと以下のような気持ちを持つようになりました。
- ユーザーに影響するような変更がプロダクトに入るのかどうかを知りたい
- 将来、自分が関わるかもしれないからどのような変更が入るのか知っておきたい
こういったことを経てどうやら私には「コードは自分のもの」、別の言い方で言えば、オーナーシップという意識が芽生えてきたように思います。
「コードは自分のもの」という意識でコードレビューを行っていくと、コードの変更を自分ごととして考えるようになるので、より真剣にコードレビューをするのは想像に難くないと思います。そして、他のチームのコードが気になって仕方がなくなってきます。そういった経緯で今日も元気に組織横断コードレビューを行っております。
一人の開発者のプロダクト開発への取り組み方を、楽しんでみてください。
-
keyboard_arrow_down
Norihide Fujiki / Hirokazu Sasaki / Naoyuki Okita / Tomoaki Matsuda / Yasuyuki Tsuda / Yoshiko Iori - 大きくなあれ!!アジャイルコミュニティ!! ☆はじまり・広がり・立ち止まる、そしてその先へ☆
Norihide FujikiManagerYokogawa Electric CorporationHirokazu SasakiDeveloperYokogawa Electric CorporationNaoyuki OkitaSoftware EngineerYokogawa Electric Corp.Tomoaki MatsudaYasuyuki TsudaYoshiko IorimarketingYokogawa Electricschedule 4 months ago
45 Mins
Talk
Beginner
私達は、約6年もの間、1万人を超える規模のグローバル企業でアジャイルコミュニティを運営してきました。
発足のきっかけは、あるアジャイルイベントの講演に、偶然にも同じ会社の人が同席していたことに始まります。
その講演で刺激を受け、社内には「アジャイルに興味がある」、「アジャイルをやってみたい」という仲間がもっといるはずだとの想いから、口コミで広がり、草の根として立ち上がりました。当初は20名の会員と幹事6名で運営をスタートしました。
しかし、数年後に、草の根が故の課題に直面するとは思ってもいませんでした。
コミュニティは徐々に広がり発展しました。
自分達がまずは学ぶことからはじまり、社外のアジャイルイベントに積極的に参加しました。
手探りながら、実践者も増え、アジャイルへの理解も深めてゆきました。
次第に活動が認知され始め、複数の部署からトレーニングの要求を受け、新人への教育も含め、のべ100名以上に実施してきました。
また、毎年の社内講演(平鍋さん、川口さん、久末さん、山田さん)も実現でき、常に新しい学びを得る機会も多く、楽しいコミュニティ活動が続きました。
そんな楽しい日々がずっと続くかのように思えましたが、次第に、「予算がない」「幹事メンバーが抜ける」「形骸化(マンネリ)と不調和」など、草の根で始まったコミュニティならではの課題や苦悩が現れ始めました。「予算がない」:
会社は、組織に対して予算を決めます。しかし、草の根のコミュニティには予算はつきません。
社内講演で誰かを呼ぶにはお金が必要です。社外イベントに参加するにもお金が必要です。
私たちは、予算のある組織や権限のある人を、どうやって探し、働きかけを行ったのでしょうか。「幹事メンバーが抜ける」:
幹事メンバーはいつまでも、コミュニティ活動を続けられる訳ではありません。退職、昇進、組織ガチャによりコミュニティ活動ができなくなることがあります。しかし、メンバーが抜けることは決してネガティブな面だけではありませんでした。「形骸化(マンネリ)と不調和」:
長く続けることで、コミュニティ活動が形骸化し、徐々に不調和をもたらしました。
「毎週全員が定例会に集まらない」「バックログが全然進まない」「支援するのが当たり前?」などの問題が起こり、一体、誰のための活動なのか?という状態となっていました。
そこで、活動の方向性を明確にするためにインセプションデッキの作成を行いましたが、なかなか意見がまとまらず、何度も同じ議論の繰り返しとなり、もう嫌だという気持ちが高まり、さらなる不調和を招きました。
ある時、みんなで話し合いがもたれ、「互いにリスペクトしているのか?」「このまま続けていいのか?」「この活動をやめるか?」という問いが出され、皆がハッとなり、踏みとどまることができました。
これをきっかけに、草の根の活動では毎回は出席できないという前提を受け入れて、「お互いの尊重」と「やりたい人がやりたいことをやる」という方針になりました。担当を割り振ることをやめ、社内からの要望も、メンバーが嫌だと思ったら断るようにしました。普通だとそこで活動が停止しそうなものですが、その後は各メンバーが主体的に活動したおかげで空中分解せずに今に至っています。 -
keyboard_arrow_down
Motoki Hirao - 形式スクラムの功罪
20 Mins
Talk
Beginner
私はスクラムまたはアジャイルライクな開発に幾度として触れてきており、何度も導入するタイミングで関係者として参加してきました。
個人的にはプロダクトをよりよく作る方法として進めやすく、学びも多く良い手法だと感じていました。その経験からある企業のあるプロジェクトでスクラム導入やリードを行うことになりました。それまでウォーターフォールだったチーム体制に、スクラムの概念を教えました。浸透するまでには時間がかかりましたが、ようやくスクラムイベントがこなせるようになってきたころ、ある日私は気づきました。「あれ?これアジャイルじゃなくない?」この発表では1年近くスクラムマスターを行い、形式的にスクラムを導入したことにより起こった良い点、悪い点についてお話しさせていただきます。 -
keyboard_arrow_down
Yasuhiro Kimesawa / 三好直紀 Naoki Miyoshi - Scrumチームの健康状態を可視化する 〜SPACEフレームワーク・FourKeys〜
20 Mins
Talk
Intermediate
アジャイルやScrumでチームを回していると本当にうまく回っているのか不安になるものです。
私どものチームも同様で、チームの状況を可視化するため色々検討してみましたがうまくいきませんでした。
FourKeysも計測していますが、どうすれば数値が上がっていくのかわからないまま。
最近知ったSPACE(達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency))という考え方を導入し、私達のチームでは多面的にチームの状況を可視化しようと試みているところです。
その意義と成果をほぼリアルタイムでご紹介できればと思います。
また、SPACE自体は具体的にどの指標を計測するかまでは指示していないため私達がどの項目を選択したのかもお伝えします。
-
keyboard_arrow_down
Takao Oyobe / kyon _mm / Mori Yuya / Toshiharu Akimoto - Deep Dive Experts - プロダクトマネジメントの光と闇 -
Takao OyobeアジャイルモンスターHoloLab Inc.kyon _mm執行役員デロイトトーマツコンサルティング 合同会社Mori YuyaProduct Management Coachwitch&wizards inc.Toshiharu AkimotoCoach / CatalystKumu Inc.schedule 4 months ago
45 Mins
Talk
Intermediate
達人たちの見ている世界を覗いてみませんか
「あの人はこの問題に対してなんて答えるんだろう?」
「あの人はもしかして、あの偉人?あの概念?からこの答えに辿り着いたのだろうか?」
「あの人の頭の中身が見てみたい!!」
と思ったことはありませんか?同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。このセッションでは達人たちが見ている世界を覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。今回は「プロダクトマネジメントの光と闇」をテーマにDeep Diveします。
過去のDeep Dive Expertsとトークテーマ
- Deep Dive Experts - 達人が見ている世界を覗いてみよう - @Scrum Fest Osaka 2021
-
スクラムとヨリを戻した時ってどんな時でしたか?
-
過去や未来問わず。これは一番タフクエスチョンだな... と思った問いはなんですか?
-
スクラムに合ってる人、合ってない人、がいると思っております。スクラムに合っていない人がメンバーにいると思った時、どのような対応をしておりますか?
-
皆さん様々な発明やアイデア出しをされ、同時に様々な勉強を日々されていると思いますが、日々の勉強をアイデアに繋げるまでの過程を知りたいです
-
いつから○○を拗らせましたか?
- 当日のMURALはこちら
-
- Deep Dive Experts - 達人が見ている推しの世界を覗いてみよう - @Scrum Fest Osaka 2022
- 心の底から本当にアジャイル推してるの?
- みなさんのオシは何ですか?
-
お互いの推しポイントをDeep Dive目に推し合って欲しい!
- 当日のMURALはこちら
- Deep Dive Experts - 達人が見ている世界を覗いてみよう - @Scrum Fest Osaka 2021
-
keyboard_arrow_down
Takao Oyobe - Scrum Fest Sendai 2023 & Scrum Fest Mikawa 2023のプロポーザルを見ながらYYする会
45 Mins
Talk
Beginner
プロポーザルの数だけストーリーがある
数年前からRegilnal Scrum Gathering TokyoやScrum Festでは、プロポーザル制によってセッション採択されるようになりました。どのイベントでもたくさんのプロポーザルが提案され、そこからたくさんの素晴らしいセッションが生まれています。
私も採択されてセッションが実現されることを目指していろんなイベントにプロポーザルを出してきました。そして、面白そうなプロポーザルに投票をしてきました。
そんなある日、
- 採択されるかされないかに関わらず、このプロポーザルおもしろそうだからもっと話を聞いてみたい!
- プロポーザルに書かれている内容だけだとわからないけど、実はおもしろいプロポーザルがたくさんあるのでは!?
- セッションにならないというだけで埋もれてしまうのはもったいない!
という想いにかられて、「プロポーザルを見ながらYYする会」というイベントをはじめました。
実験的にはじめてみたところ、参加してくださった皆さんのプロポーザルへの想いやストーリーを聴くことができて、胸がアツくなる瞬間が何度もありました。各イベントのセッションも面白いですが、それと同じくらいプロポーザルYY会もアツいです。
今回はそのプロポーザルYY会の素晴らしさをぜひみなさんにも味わってほしいと思いプロポーザルを出してみました。Scrum Fest Osaka 2023のイベント開催期間中に、ちょうどScrum Fest Sendai 2023とScrum Fest Mikawa 2023のプロポーザルを募集しています。出されているプロポーザルを見ながらYYしましょう。
- Srum Fest Sendai 2023 Proposal
- Scrum Fest Mikawa 2023(募集開始前)
プロポーザルを書いた方へ
プロポーザルを書いた想いを語りたい方、プロポーザルへのフィードバックが欲しい方はぜひ持ち込んでください!
書ききれていなくても、メモレベルでもOKです!まずは持ち込んでみることが大切です。
プロポーザルを書いてみたい方へ
プロポーザルを出すことに興味がある方、プロポーザルを書きたいけどネタがないと思ってる方、ぜひ参加してみてください!
出した人たちがどんな思いでプロポーザルを書いているのか、どうやって書けばいいのか雰囲気がわかると思います。
とにかくプロポーザルを見てYYしたい方
一緒にYYしましょう!
過去のプロポーザルYY会
-
keyboard_arrow_down
Shinya Ogasawara - PTMFを使って自分の物語を考えてみる
20 Mins
Talk
Beginner
2016年のXP祭りで、牛尾さんがお話されていた内容の中でとても印象に残っていることがあります。(当時の資料が見つけられないので、記憶違いでしたら申し訳ないのですが)
それは、『大人になるというと、日本では「我慢する」というようなニュアンスが強いけど、アメリカでは「自分が幸せになれる行動をする」こと』というお話です。この考えを私はとても気に入っています。
自分にとっての幸せとは何か、ということを考えたときに、大事なことの1つとして「他人が考えた幸せではなく、自分の考えが持てること」があるのではないかと思っています。1人1人の人生は異なるので、何が幸せかも異なるはずで、それを決められるのは自分である、というような考えです。モティベーション理論でいうところの「外発的動機づけ」と「内発的動機づけ」の違いに近い話かもしれません。
このような「自分で決めたり、自分に合ったものを選んだりすることの大切さ」を表現するために、私は過去に以下のようなテーマの話をしてきました。
- 自己調整学習
- フロー理論
- 意思決定理論
たとえば、「自己調整学習」のテーマでは、「学びにおいて、自分に合ったものを自分で発見していくことが重要」という話をしました。
私がこれまで扱ってきた内容は「学び」に関するものでしたが、今回はPTMFというメンタルヘルスに関する内容をご紹介したいです。
誤解の無いようにしたいのですが、私はメンタルヘルスに詳しいわけでもありませんし、PTMFについても豊富な知識があるわけではありません。
ただ、PTMFの方法論は、自分を知ったり、自分の中の大切なことについて気付いたりするためのやり方として役立つものだと感じました。
もちろん、これで全てが解決するようなものではないと思いますが、1つの考え方として紹介させて頂きたいです。
PTMFは「パワー・脅威・意味のフレームワーク」(the Power Threat Meaning Framework)です。あるものごとが自分にとってどのような「パワー」「脅威」「意味」があるのかを自分の物語として考えます。
同じものごとであっても、人によって与える影響は異なります。同じ症状であっても人によってそこに行き着く過程は異なります。フレームワークを通じてこうした違いが生まれる自分の物語を掘り下げていきます。
では、実際にはどんなものになるのでしょうか?
このセッションでは、PTMFとはどんなものなのか簡単にご紹介しつつ、実際に私が自分の物語を考えてみて、その内容をお話したり、そうしたアクティビティを通じて感じたことなどをお話したいと考えています。