前世紀の終わり頃、ソフトウェアをうまく開発するやり方を模索する中で生まれたスクラムは世界で最もよく使われているソフトウェアプロダクト開発フレームワークとなりました。

最近ではソフトウェアにとどまらず、組織運営や開発以外の業務プロセスなど適用範囲を広げる試みが続いています。

この講演では、ここまでのスクラムがたどった経緯を辿りつつ、スクラムはこれからどうなっていくのか、どうやって使っていったら良いのかを考えてみたいと思います。

新しく始めたり、今までのことを変えることは、言うのは簡単ですが、実行するのは簡単ではないことを感じる今日この頃です。

ソフトウェア開発をよりよくするためには、一歩踏み出す勇気が必要ですね。

アメリカでソフトウェア開発チームを１から作る仕事を任せられ、2019年8月から2年半、アメリカに駐在し、今年の春に日本に戻ってきました。文化や人種の異なる環境化で困難なことも多かったですが、私の中でのアジャイルな開発の原点を考える良い経験になりました。

今回は、アメリカでのソフトウェア開発の事例を中心に、日本に戻ってきた後、私自身のアジャイルなソフトウェア開発の実践の歴史をふりかえったことなどをお話しさせていただきたいと思っています。

アメリカ着任後初めにやったこと、様々なイベントが発生し変化に対応したこと、私が大事にしていることなどを皆さんと共有し、ソフトウェア開発をよりよくするための熱い議論のきっかけにできればと思っています。

作成中

【運営よりひとこと】
今年は新しい試みとして、去年まで開催していたOSTの代わりにチームで開発する様子を体感できるワークショップをオンサイト / オンラインのハイブリッド形式で開催してみようと思います。

参加したいと思った方は、11/4(金) 21:00までにこのスプレッドシートから申し込みお願いします！名前・オンライン / 現地・Discord IDを記入お願いします。

本ワークショップは全面的にやっとむさんのご厚意によって成り立っております、ありがとうございます！！

※「全員参加のOSTに代わる新しい試み」ということでより多くの方が参加できるように調整してまいりましたが、タイムテーブルやスタッフの都合上定員を設けることとなりました。ご了承ください。

ゲームの概要

チームが一致団結して開発する日々の様子を、メンバーの立場から体験できるボードゲームを作りました。以下のようなやり取りをゲームの中で体験しできます。

「えっ、スキル足らなくないですか」
「ステークホルダーがぜんぶやれって言うから…」
「この案件、内容をこう見直して、ほらこれならできる！」
「やった、なんとかなりそうだね」
「おれ、これじゃなくてこっちやりたいんすけど」
「ちょっとー！」
「任せてください。実はこんなスキルを隠し持ってます」
「すごーい。あれ、でも品質良くなくない？」
「あっ…」

4人1グループで遊ぶゲームです。ルールが多いのではじめは大変ですが、わかると1回15～20分くらいで終わるので、3回くらい遊べると思います。札幌では、会場オンサイトとオンラインのハイブリッドでボードゲームを遊ぶ予定です。

各プレイヤーは、開発チームのメンバーとして、自分のスキルを表す手札を持っています。ボード上にはタスクカードが並んでおり、自分のスキルでこなせるタスクを選び案件として実施すると、開発が進みます。開発を進めるとチームは3種類の報酬を得ます。

• グロース - プロダクトや会社の成長と売上増
• Impact - ユーザーや社会に対する貢献
• 生産性 - プロセス改善やリファクタリングによる作業効率化

メンバーは一人ひとり異なった「勝利条件」を持っています。あるメンバーはひたすら成長にコミットしており、別のメンバーは自分のスキルにしか興味がなく、また別のメンバーはプロダクトがバランスよく成長しながら社会に貢献することをモチベーションにしている。自分の勝利条件に近づくようにタスクを選んで案件を実施ししましょう。

しかし1人でできる仕事は僅かです。スポンサーの要求はどんどん高まっていき、チームが協力して開発しなくてはクビになってしまいます。チームとして案件を成功させながら、いかにして個々人の勝利条件を追求するのか。チームとしてのコミュニケーション、作戦、そして駆け引きがこのゲームの醍醐味です。

ゲームの準備およびサポーター人数の都合で、参加人数に制限があります。会場オンサイトが20名まで、オンラインが16名まで参加できます。

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

過去の放送

https://youtu.be/5BZI9A3jhsY

https://youtu.be/0JDjMDSLqrE

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1札幌グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、やっとむ（yattom）、かっちゃん（katzchang）
今回もローカルレーサーに声かけするつもりです。

お題は下記のフォームで募集し、当日はその中から厳正なる抽選で採用されます。
https://forms.gle/9ytXii1RL9wQGrwm6

2022/10/12 追記
てやまぐ（teyamagu）選手は都合により出走取消となりました。
次節の出場をお楽しみに！

「あの人はなぜいつも元気に見えるんだろう？」
「あの人はどういう経験を経ていまのスタイルになったんだろうか」
「あの人の原動力はどこから来ているんだろう」
「あの人が凹むときはあるんだろうか」

と思ったことはありませんか？

プロダクト開発に携わっていると、日々さまざまな壁にぶちあたります。

考えの合わないチームメンバー、高圧的な上司、非協力的なステークホルダー、お通夜のようなふりかえり、フィードバックのないスプリントレビュー、重厚長大な組織の壁・・・

思わず「うっ」と歩みを止めたくなってしまうこともあるでしょう。

一方で、カンファレンスで登壇している人たちを見ていると、たとえどんな壁にぶつかったとしてもへこたれず、考え続け、行動し続けているように見えます。そして人は彼らを指して『元気だよね』と言います。

ここには、最強の元気しかいない

スピーカー2人の共通点は、人から『元気だよね』とよく言われることです。
ところが、本人たちは自分たちのことをとりわけ元気だと自覚しているわけではありません。

では元気とは何なのでしょうか？
ここでいう元気とは、性格や活動的である状態を指すものではなく、他者からの相対評価です。

同じような状況に面しても、人によってまったく違うアウトプット（行動、言葉）になります。このアウトプットを他者が見て、その人のことを元気だと感じているのです。

つまり、元気に見える人のメンタルモデルを解き明かすことで、元気とは何なのかの答えが見えてくるかもしれません。そして、メンタルモデルは理解することで自分にインストールすることができるかもしれません。

本セッションでは、スクラム界最強の元気たちが見ている世界を覗いてみる実験をします。最強の元気同士が、お互いにインタビューし合うことでお互いの思考、メンタルモデルを探ります。

一緒に元気を解き明かしましょう！

札幌で開発している「Dr.Sum」という純国産データベースエンジンをどのように開発しているかをお話しさせて頂きます。

ところで、データベースエンジンをどのように開発しているかを皆さんご存じでしょうか。

データベースを使った業務システム開発やデータベース設計については、本になっていたり、Webに色々と情報が載っています。

ただ、データベースエンジンそのものの開発についてはほとんど情報がありません。（私が知らないだけかもしれませんが。。。）

そんなベールに包まれたデータベースエンジンの開発をどのように開発しているのかを紹介します。

開発当初は実装だけやって、テストは他の会社にお願いと丸投げする開発を行ってきました。

ただし、これでは品質の良いプロダクトは生み出せないことを様々なイタイ失敗を経験しながら、より良い開発プロセスに少しずつ改善してきました。

アジャイル開発のエッセンスを取り込みつつ、自分たちなりにカスタマイズした開発プロセスを紹介します。

データベースエンジンは複雑な集計やデータ更新のSQLを扱います。

もし間違ってデータを格納したり、誤った集計結果を返したら大惨事！

そうならないようにテスト自動化がとても重要です。

テスト自動化をどのように行っているか、開発中に実行される自動テスト環境をどのように構築しているかも紹介します。

データベースエンジンというニッチな領域の開発プロセスの話ですが、

開発者とQAが協力し合いながら札幌でがんばって開発している会社があるんだというところをお届けできればと思います。

私が所属しているチームは、結成されてからこれまでの間に経験してきた開発は、受託開発（部署または会社の外から欲しいソフトウェアの要望が来ることから始まる開発）が少なくありませんでした。その要望を出す人たちは、ソフトウェア開発の経験や知識が無い方々が殆どでした。しかし、その人達が予算を持っており、開発を誰に依頼するのかを決める決定権を持っています。そのため、その人達にとって、もちろん開発したプロダクトのユーザーにとって魅力的でなければいけません。そのために我々は最初のデモを重要視しています。常に受注を続けてこられたわけではありませんが、受注につながったのではないかと思える実感を得られるやり方が見えてきたような気がしています。そこで、このセッションでは、そのやり方を直近で携わっているプロジェクトを例に紹介したいと思います。

「人を育てる秘訣は、言葉遣いにあった！！」とは米海軍で屈指の潜水艦艦長が書いた書籍『LEADER’S LANGUAGE』の売り文句ですが、スクラムマスターにも当てはまると思います。リーダーシップを学ぶのに非常によい書籍なのでぜひ読まれることをお勧めします。アジャイルについても触れられています。

さて、この本を紹介したいというのもあるのですが、ここではDX宿泊業の情報システムグループで同時に4チームのスクラムマスター／アジャイルコーチを1年間やってきた私が、意識して使った言葉や自然と出た言葉で影響があった言葉など、言葉にフォーカスしてスクラムマスターを語りたいと思います。元ネタ同様、人を育てる秘訣は言葉にあるようです。

僕の発表はきっかけに過ぎません。この機会にみなさんがよく使う言葉を教えてもらえませんか？当日は discord などで共有し合えればと考えています。

スクラムマスターとして活動されている皆さん。皆さんの中には、自分が話す内容が、チームメンバーにうまく届いていないなあと感じた経験はありませんか？

スクラムマスターは、他のメンバーと少し違った視点で考えることも多く、前提知識の有無も含めて、なかなか理解・共感を得づらい場面もあります。

その場合、いきなり本題について話すのではなく、1クッション入れるのが効果的です。本題に至った思考の過程や前提知識を共有する場があると、よりメンバーからの理解や共感を得やすくなります。また、副次的な効果として、共有のために言語化する中で自分の考えを整理でき、後のふりかえりにも流用できるようになります。

本発表では、チームメンバーにスクラムマスターの頭の中を共有しながら、チーム・プロセスに関する取り組みを推し進めていった例を紹介します。月1ペースでLT発表する場を通じて、「どういう状況下で」「どういう課題を感じていて」「どのような前提を共有しつつ」「どういった取り組みを進めて」「結果どうなったか」を、いくつかのケースに応じてお伝えします。

スクラムマスターのトレーニングを完了した直後にスクラムマスターがハマる罠。
その一つに、トレーニングで得た知識をそのままチームに適用する！というものがあるのではないでしょうか？
知識の押し付けですね。

私も初めてスクラムマスターに挑戦したとき、思いっきり失敗しましたw
トレーニングでこう教わったからこうなんです！！！
あぁ、恥ずかしい…

月日は経ち1年半後、新チームの立ち上げに関わることに。

初挑戦の失敗と、それまでの経験を活かして取り組むことを心に誓い臨んだチーム作り。どのように取り組んだのでしょう？

知識の押し付けで失敗した初挑戦。
それなら、知識は教えない！教えるにしても最小限。

体験を最大限に活かす！

開発者にスクラム経験者が1人いたものの、はたして教えるより体験重視の方針で上手くいくのでしょうか？

チーム開始時点でのスクラムの意識はこれくらい。

• スクラムのイベントは全部やってみよう
• スクラムの作成物は全部作ってみよう

各イベントと各作成物の概要だけ伝えて、いざスタート！

当然のことながらスタート時点ではイベントをこなすだけ、プロダクトを作るだけ、とりあえずやってみてます！の活動が続きます。

そんなチームですが、
チームで良い活動をしていこう！
良いプロダクトを作っていこう！
そんな気持ちは持っています。
ふりかえりも真剣にしています。

真剣に取り組んでいるので、
ふりかえりで、課題がどんどん出てくる。
出てきたものを少しずつ改善していく。
上辺の改善だけではダメだと気づき、意味を考えるようになる。

形だけで始めたスクラムが、いつの間にか、

スクラムの良さに気づき

チームで取り組んでいる状態に。

本セッションでは、2年間毎日書き留めたチームの活動記録とふりかえりを元に、チームがどう変わっていったのか、チームメンバーの視点を中心にお話します。
スクラムマスターとしてどう関与していったのか、ちょっぴり入れられればなとも目論んでいます。

企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。

毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。

私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。

本セッションでは、Agile 2014  での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか？

"名詞" では 「"名詞"、"名詞"、"名詞"」をまとめてなんと呼んでいるでしょうか？

みなさんはどれくらいスクラムを知っているのか？すっとその知識を出せるのか？不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにスクラムのクイズを出してその知識や引き出し方を確認してもらえればと思います。

当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

「QAさんからバグを指摘されたので、このバックログアイテムはDoneにできませんでした」
これはQAエンジニアである私が度々出会う、最もモヤッとする言葉です。

なぜこのような発言が出るのでしょうか？

これはテストによって発生したフィードバックを、開発者が「差し込みで発生した作業」と捉えてしまうからではないかと考えています。自分の手で実装したものなのに、自分ごとにできなくなってしまう瞬間があるのです。

開発者の実装が完了した後、1Sprint遅れでQAエンジニアがテストを行うやり方を採用しているアジャイルチームを時折見かけます。これはあまり推奨できるやり方ではありません。
QAチームがテストを実施している頃、開発チームの心はすでに後続のバックログに向いていて、テスト対象となっているアイテムは「すでに終わったもの」と認識しているからです。

しかし、たとえ1Sprintの中で実装からテストまで行ったところで状況は変わらないでしょう。「QAにテストを任せた瞬間に心が離れてしまう」という点は同じだからです。

また、QAエンジニア自身にも甘えや油断が発生しているのではないでしょうか？
あるバックログに対して要件に不明な点があったとき「これはテストをするときに確認すればいいか」と解決を先延ばしにしてしまうことがあります。やがてそれがSprintの終盤にバグとなって吹き出すのです。

考えられる解決手段は2つあります。

1. 開発者自身でテストを行うこと
2. 実装に着手する前に、要件の解像度を上げること

今回は後者についてお話ししたいと思います。

バグの多くは、要件の認識ずれによって引き起こされます。
そしてその認識ずれは、プロダクトに関わる各ロール (PO、開発者、デザイナー、QA、etc.) が細かく対話を重ねることで解消できるものも多いでしょう。

テストだけが品質保証の手段にあらず。
重厚なテストに頼りすぎず、より早い段階で対話を重ねることで品質を担保するチームにシフトしていきませんか。

はじめまして。
日々、プロダクトやチームの成長を、子供の成長を見守るのと同じように楽しみながら奮闘している母ちゃんスクラムマスターです。

私、この2年間、専任でスクラムマスターとして活動しています。

当初、社内SE出身で非エンジニアの私が、現役バリバリのエンジニアのなか、スクラムマスターを担えるのか?
という不安はありました。(私自身はもちろん、チームメンバーも)

そんな不安と葛藤のなか、私は、チームメンバーがプロダクト開発を「楽しく！」取り組めることに注力してきました。
それは、「楽しく！」はたらくことでチームが強くなり、どんな困難もチーム一丸となって乗り越えていけると信じているからです。

今回は、メンバーがプロダクト開発を楽しむことに全力を注いだ私の事例をメンバーから見た意見を交えながらお話したいと思います。
ただ楽しいだけじゃない、社内一賑やかといわれたスクラムチームの日常をのぞいてみませんか？

聞いていただいた皆さんが「楽しい！」をどんどん広げて、強いチームがどんどん増えることを想像するだけで「楽しい！」

顧客を理解することが大切とはいっても、どのように考えればいいのかそれほどあきらかではありません。

これまで18年間、新規事業や新製品開発、リニューアルといったプロダクトの今後を左右する活動に関わってきました。2010年代からはソフトウェア開発でも、仮説検証やリーンキャンバスといった方法が認知され、プロダクトオーナーやプロダクトマネージャーにとって、顧客を理解するための様々な選択肢があります。

しかし、いったいどのようになったら顧客を十分に理解できたといえるでしょう。

また、顧客理解の新たな課題も登場してきています。チームによる顧客理解です。2010年代中旬頃までは、プロダクト開発においては一人の強力なリーダーシップによって進められることが少なくありませんでした。しかし、チームによってプロダクト開発を進める流れが起こりつつあります。顧客への深い理解はプロダクトオーナーだけの仕事ではなくなり、スクラムマスターや開発者にとっても重要な関心事になりつつあります。

知識や関心にバラツキのあるスクラムチームで、いったいどのようにすれば顧客の理解を深められるでしょうか。

このセッションでは以下の様々な切り口から顧客の理解を深める方法を紹介します。
・顧客の理解を度合いから評価する
・チーム全員で顧客を理解する

・顧客との接点はどれくらい持ちやすいだろうか
・顧客をどれくらい理解しているだろうか
・顧客の悩みを考えよう
・顧客の悩みが解決されない理由を考えよう

顧客の理解を育み、よりよいプロダクトを提供していきましょう!

スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ（超生産的）チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。

各パタンの概要はこちらの記事で紹介しました。
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)｜note

筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト（通称フロリア）」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。

プロジェクトの概要やチーム体制は下記の記事で解説しています。

• kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
• 30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ

本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。

• Teams会議で呼びかけても反応がない・・・！みんな聞いているのかな・・・？
• こんな調子でチームのパフォーマンスは良くなるのだろうか？
• 直接会ったことのないメンバー同士がどうしたらポジティブに動けるだろうか？

皆さんはリモートワーク下でのチームビルディング、どのように乗り越えましたか？
それぞれの個性が見えづらく、自分の想いも伝えづらい。私は相当苦戦しました。

申し遅れましたが、現在リクルート様の採用管理サービス「Airワーク 採用管理」の開発チームで
マネジメント業務をしております、イイダカです！
昨年度漠然とした課題感を抱えるフロントエンドチームに飛び込み、改善活動を行いました。

飛び込んだチームは、プロダクトの忙しさやメンバー交代などから、日々メンバーに対して答えを与えがちになり、
メンバーの主体性を育てることができず、チームのスキルアップに繋げられないという状態から抜け出せなくなっていました。

そんなチームをなんとか負の連鎖から抜け出し、自走できるチームにしていきたい。
皆さんだったらどのようにこのチームを変えていきますか？

トップダウンのやり方もあるでしょう。でも、私は全員に考えを吸収してほしいんです・・・！
全員にマインドを吸収してもらう選択をとり、同じ目線で協力し合える関係性を築きました。

私は自身の経験から、チームづくり・改善活動には、メンバーの納得・協力が絶対であると考えております。
正直に現状を共有し、どういった意図でどういうチームを目指していきたいかを説明し、共通認識を持ってもらうところから始めていきました。
そこからはまるで小姑のような泥臭行動の連続・・・

本編ではより詳しく、リーダー依存脱却・新たなチーム文化の醸成にどのように繋げていったか、
考えたこと・工夫ポイントを交えながら、新米の私だからこそできた泥臭奮闘記をお伝えします！

皆さんがどこか懐かしい気持ちになり、良い刺激を与えられたら幸いです。

スクラムマスターのロールを学び続けることは、スクラムを離れてもこれからの時代に求められるチームビルディングにつながっている

1. スクラムとの出会いと学び
2. スクラムは人生そのものと思った翌月にスクラム終了した話
3. 2年ほどチームと共に育つことを支えたくれた人と言葉
4. アジャイルジャパンの安田さん講演からの社長に「Joy,Inc化しよう」と言ってみた話
5. 今～スクラムからは離脱しているけどチームビルディングと所属組織の変容に口出しする末端社員になった話