ス ク ラ ム マ ス タ ー と プ ロ ダ ク ト オ ー ナ ー を 1 年 や っ て み て 改 め て 自 分 が 考 え た こ と は な ん だ ろ う ？ の ま と め 2 0 2 5 / 1 v e r . 1 . 0 5 k e i t a r o m a t s u k u r a

目 次 進 歩 の 仕 方 に つ い て の 小 話 01 な ぜ ス ク ラ ム を 始 め た の か 02 ス ク ラ ム で 変 わ っ た こ と 03 具 体 的 な 改 善 策 04 最 後 に 05

進 歩 の 仕 方 に つ い て の 小 話 01

01 進 歩 の 仕 方 に つ い て の 小 話 スペースXは多くの失敗から始まり、改善を繰り返して世界一のロケット打ち上げ数となった。 その開発手法は「アジャイル」でした（https://diamond.jp/articles/-/324537） ※スペースXのラプターエンジン

01 進 歩 の 仕 方 に つ い て の 小 話 健全に回るスクラムの基本はこの流れを１週間などの短いスパンで繰り返す。 ただし、「誰かが決めてくれるのではなく、自分で決めて行う」。トップダウンで誰かが決めるのではなく。 だから自分で答えを作っていくことができるようになる。

01 進 歩 の 仕 方 に つ い て の 小 話 私たちのマネジメントの一般体系化は職場の人たちを破壊してき た。人は生まれながらにして、内発的動機づけ、自尊心、尊厳、学 びたいという好奇心、学ぶことの喜びを備えているものだ。

01 進 歩 の 仕 方 に つ い て の 小 話 こういう風に繰り返していくことが、学びなのだと思う。 進んで、少し止まって、また進む。それを人は「進歩」と呼ぶ（ってあひるの空で言ってた。言いたいだけ）

な ぜ ス ク ラ ム を 始 め た の か 02

02 な ぜ ス ク ラ ム を 始 め た の か 個人に依存し、個人が抱え込み過ぎていたこと（結果、個人がボトルネックとなった） 自分の担当範囲以外に踏み込もうとしない 個人の判断で業務を行ってしまう 作業内容が不透明なこと、それをそのままにしてしまっていたチーム風土 開発チーム内でのコミュニケーション不足 問題が多発していた時期 スクラムに期待されたこと チーム風土を変えたい 個人ではなく、チームで補う体制に変更したい できる人に集中する風土から、誰もができるようになりたい コミュニケーションを活発に行うようになりたい 中間に入る人を減らして、認識ズレが起きないようにしたい 品質の安定化をしたい

スクラムとは、アジャイル開発手法で最もポピュラーな型の一つであり、透明性、検査、適応を重視するフレームワークです。 スクラムの3本柱（重要としている考え） 透明性：プロセスや作業をする人と受け取る人の双方に見えるようにすること。いつでもどこでもだれでも見える。また、常に更新されるプ ロセスや作業が見えることで、フィードバックや支援する行動にも変化を及ぼすことができる 検査：望ましくない変化や問題に気づくために、作成物や進捗状況を頻繁に検査する必要がある。スクラムイベントでも、いつでもどこでも だれでも、気付いた問題を挙げよう 適応：プロセスやプロダクトが許容範囲を逸脱する場合、早急に軌道修正を図る。いつでもどこでも誰でも、チームの変化に寄与してよい スクラムの5つの価値基準※3つの柱を支えるマインド 確約：ゴールを決めて、それに向けてお互いにサポートすることを確約する。 勇気：問題やアイデアを怖がらずに意見を言える勇気、困難な課題に取り組む勇気、失敗を公開する勇気。 尊敬：多様な意見や視点を受け入れ、健全な対話とフィードバックの文化を育む。心理的安全性がパフォーマンスと学習意欲に繋がる。 公開：作業や課題を公開することで、意見を集められるように。 集中：役割や課題に、集中することで問題に気づく。（兼務って非常に効率が悪くなる） 02 な ぜ ス ク ラ ム を 始 め た の か スクラムの基本

02 な ぜ ス ク ラ ム を 始 め た の か スクラムの基本（LeSSベース） プロダクトオーナー ビジョンと方向性を提供する フィーチャーの優先順位付け ユーザーと市場を理解する 組織の戦略的方向性をサポートする チーム（開発者） プロダクトを作る プロダクトをデリバリーする 協調と統合 プロダクトの作り方を改善する フィーチャーを明確化する ユーザーとドメインを理解し協働する マネージャー 開発能力を向上させる 構造とポリシーを決定する スクラムマスター 組織をコーチする 継続的改善をサポートする 【役割について】 プロダクトオーナー（PO）：顧客にとって価値あるこ とを常に考え、優先順位を決める。WhyとWhatの責任 を持つ。 チーム（開発者）：常に最適・最良を目指し、実作業を 担当する。Howの責任を持つ。 スクラムマスター（SM）：チームが成果を出すことを 支援し、業務プロセスや組織の課題解決を支援・推進す る。気づきのきっかけや場を作る。サーバントリーダー シップスタイルを採用する。 （マネージャー：組織能力を改善するためのチームの協 力者） （ステークホルダー：チームを信頼し、コラボレーター としてプロダクトに関与する。※図になし） ※図はLeSSでの役割イメージ

02 な ぜ ス ク ラ ム を 始 め た の か 本音を言うと パートナ企業含め一人一人に聞いたら 多くのメンバーが「やってみたい」 って言ったから

03 ス ク ラ ム で 変 わ っ た こ と

03 ス ク ラ ム で 変 わ っ た こ と スクラム前の体制イメージ 「→」はコミュニケーションライン 自社とパートナーの両社にPMがいて、細かなプロ ジェクトマネジメントをしようと努力する 両社に開発がいて、開発同士の知見が共有されない 両社にQAがいて、二重でのテストが行われるケー スなどがあった マネージャーやビジネスチームは、一部の人間とし かコミュニケーションせず、実態が掴みづらい

03 ス ク ラ ム で 変 わ っ た こ と スクラム後の体制イメージ 「→」はコミュニケーションライン チームがステークホルダーと話し合うことが増えた 開発者とPO、SMは随時コミュニケーションを取り 合う コミュニケーションは非常にシンプルになった

会議時間 2022/11 2022/12 2023/1 2023/2 2023/3 2023/4 2023/5 2023/6 2023/7 2023/8 2023/9 2023/10 2023/11 2023/12 2024/1 2024/2 2024/3 2024/4 2024/5 2024/6 2024/7 0 20 40 60 80 100 66 82 65 61 66 70 74 92 84 98 77 86 81 77 89 68 88 78 88 75 79 03 ス ク ラ ム で 変 わ っ た こ と スクラムは定期イベントが多いので、会議時間が増えそう な印象はあるが実際はどうか？実会議時間は少し増えてい た。2023年8月よりスクラム体制へ移行。スクラム前の月 平均は73.34時間。スクラム後は月平均は81.73時間。週平 均で2時間程度はMTG時間が多かった。（PMだった人間が PO・SMになったときの比較） 会議の中身に関しては、以前は議題を出す人が主に話しそ れに参加者が呼応するような会議体が多かったのに対し、 スクラム以降双方向で話をする会議時間が圧倒的に多くな っている スクラム以前は関係者20人が集まる会議で3～4人しか話さ ないような会議体も設けられていた。 またスクラム開始後は相対的に定期的な予定が占める割合 が多くなっている。 補足、スクラム導入初期は特に、スクラムへの体制移行準 備などで会議が増えていた。 会議時間の変化 スクラム以降 ※開発者が知りたいけど、調査難航のため諦めてます

03 ス ク ラ ム で 変 わ っ た こ と リリース後の平均インシデント スクラム以前 スクラム以降 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 スクラム導入後、リリースのたびに起きていたインシデン トが6分の１に減った 適切なテストコードを書くことを完成の定義に入れたこと で、複雑なアーキテクチャでもデグレが起きることが減っ たことが可能性として挙げられる 認知していない既存バグが減った可能性ももちろんあるた め、あくまで参考です 品質の変化

03 ス ク ラ ム で 変 わ っ た こ と デプロイできる人 スクラム以前 スクラム以降 0.0 2.0 4.0 6.0 8.0 スクラム前はチームメンバー20人程度いたのにリリース作 業（デプロイ）自体2人しかできなかった（STG/本番共 に）→体制縮小したが、８名程度に減った時には全員が可 能な状態となっていた。 以前はテストがQA担当メイン → みんなできる＆みんなで やっている フロントエンド・バックエンドなどの業務区分 → 特になく なった モバイル開発・WEB開発の区分け → 属人性は残るもの の、チームでの共有しながら進める方式は取れている 属人性の緩和

03 ス ク ラ ム で 変 わ っ た こ と 状況の変化を含み、体制を縮小しているため、人数が半減していま す。（本来は一定の人数を維持するのが良いとは思います） チケット消化数という面では、半減までしていません。 また、チケットの考え方が変わったため、あくまで参考値です 人数が多すぎることで効率が悪かったという話もあると思いま す また、スクラム導入半年後からのみの計算だと、人数はさらに減っ た上で、チケット消化数は伸びています 導入初期はいわゆる混乱期があり、生産性が下がっています 関与人数とパフォーマンス（月間チケット消化数） 平均人数 チケット消化数 スクラム前 スクラム後 スクラム導入半年後以降 0 5 10 15 20 25 30 35

チーム内コミュニケーションが活発で、議論とアイデアが生まれやすい。 チーム全体で要件理解と合意に基づいた見積もり（誰かが勝手に作った見積もりがない） 個人の忙しさに依存せず問題や質問が共有されやすい（一人で問題を抱え込まなくていい） スケジュール重視ではないため、低品質の納品や無理なリリースが少ない。 フィードバックを容易に得られ、開発途中での変更が可能。 ビジネスと開発の間のコミュニケーションとコラボレーションが促進される。 技術的負債と機能開発を同じ粒度で考えることができる。 メンバーの仕様理解度が高まり、設計への責任感が強まる。 役職や立場がフラットになり、心理的安全性が高まることで自由に意見が言えるようになる。 細かいチケットの粒度とUTによるデグレチェックで、デグレーションが少なくなる。 開 発 者 ： ス ク ラ ム や っ て よ か っ た こ と 04 ス ク ラ ム で 変 わ っ た こ と ※ある時点での開発者意見です。成長に応じて変わるものだと思われます

自主性が求められ、適応できない人もいる 開発者の意見が弱いとPOの意見が強まる コミュニケーションに時間がかかる 一人で集中・考える時間が少ない（いい部分も悪い部分もあるけど） チーム評価が中心で個人評価が難しい 個人タスクはウォーターフォールの方が明確 個人にフルスタックが求められ、専門領域に集中できない 開 発 者 ： ス ク ラ ム で 惜 し い こ と 04 ス ク ラ ム で 変 わ っ た こ と ※ある時点での開発者意見です。成長に応じて変わるものだと思われます

04 ス ク ラ ム で 変 わ っ た こ と 元々の課題だった点は半年以内でクリア。 スクラムを利用した上で、チームが改善を重ねたことで 自然と解決した。

具 体 的 な 改 善 策 04

04 具 体 的 な 改 善 策 スクラムにおけるベーシックなルールとプラクティスは初期に導入 プロダクトゴール 定期的なゴールと、なぜそのゴールなのかを明確にすることで迷うことが減る ヴィジョン策定 サービスが目指す方向性をPOが中心となって言葉にした プロダクトバックログ チームのやることリスト。課題と解決案のリストになってるとベター。なにをチームが取り組んでいるかわかる＆優先順位が今どうなっているか一目瞭然となる。 各種スクラムイベント（スプリントプランニング、スプリントレビュー、レトロスペクティブ、デイリースクラム、リファインメント） 通常通りのイベントを開催 スクラムオリエンテーション スクラム開始前に、自己紹介やワーキングアグリーメント、完成の定義、星取表、チーム名決めなどのチームワークショップを開催 ユーザーストーリー 「誰に」「なぜ」「なにを」を一文章にまとめた形式。チケット名称に用いることで、誰が見ても理由がブレなくなる。また、具体的な「なぜ」の理由が話さなくてもわかる 完成の定義 一つのチケットを終わらす毎に、品質基準を設けてチェックするルール集。これがあることで技術品質を向上させることができる。 相対見積もり 基本的に「見積もり」は正確性を担保できないため、素早くほどほどに見積もる方法として優秀。難易度や規模で見積もる モブプログラミング（ペアプログラミング） 作業をペアワークないし複数人で行う。ナレッジシェアができる上、意外と1人で作業よりも捗る時もある。（考える人と作業する人で分かれる等でマルチタスクになりづらい） 持続可能なペース 意外と忘れがち。定時退社が当たり前になる業務プロセスになっていると良いと思う。終礼を導入することで意識づけ デプロイの自動化 理想はCI/CDと呼ばれる領域だが、まずは手動でデプロイしていたものを自動化することで、リリース作業時間が減り、人的ミスがなくなった リファクタリング（品質改善） コードの視認性・可読性を高めることで、長期的に不具合や生産効率を高めるコードの改善 スクラム導入後では小さな開発毎に随時行う方法を取っている バーンダウンチャート テストコードのルール化 E2Eテスト リグレッションテストの自動化し、リリース作業の工数削減

Why(なぜ）とWhat（何を）に責任を持つ ROIを常に考える重要性 1つの投資で2つ以上の益を狙っていく（PBIの狙いを一つにしてはいけない） 1つの指標でパーフェクトを目指さない 高めようと努力するものが指標 当てようと思うのはギャンブル 小さい力で大きな価値を生む発想 アイデアがいっぱいあるのが良いPO プロジェクトの要件管理者ではない 会話の中で、柔軟に要件を変えていく必要 摩擦が起きないほうが問題。程よい対立を作る POの理屈を押し付けるのはPOの怠惰 マインドセット：やり方より心構えがまず重要。対等な関係であると捉えているか POがセルフブランディングをしないと適切に情報が集まらない 情報が集まる関係性を作っていく タイムスケジュール守れる人 チームにスケジュールのことを言うのだから、まず自分が守れるように。会議に遅れるなどしないように 役職と役割を混同しない 役割上、スクラムチームメンバーは完全な対等である 対等と同様は似てる。友人より自分に相談してくれる数を増やすことに注力 時間に余裕がある時は Undoneを減らす努力に時間を使う リリーススプリントはリスクを高めている行為 プロダクトバックログの優先順位の管理者 ステークホルダー・開発者とよく話し合って、順位を決める なぜ、今これをやるのか、の持論は持っておくこと 信頼するスクラムマスターを持つこと POの暴走を止めるのがスクラムマスター。スクラムマスターの言うことを真摯に聞けない関係はよくない 自分が決めたことの9割は会話をして決めている ステークホルダー、開発者、スクラムマスターと会話せずに決めたことは・・・多分ない 04 具 体 的 な 改 善 策 （ 主 に プ ロ ダ ク ト オ ー ナ ー と し て ） 自分のプロダクトオーナーの基本的な言動は以下のようなイメージ

POは中期視点、開発者は短期視点、そしてスクラムマスターは長期視点 常に長期的なチームの成長と、成果に焦点を当てる（ただし、ステークホルダーからのチーム評価を下げないようにだけは常に意識） よく観察し、気になった問題を改善するためのリストを作る 観察して、「あまりよくない」と思った事実をメモ 仮説を立てて、「なぜ、これはこうなったのか？」を考案 改善案を立てて、実行。実行した上で、改善したかを観察して確認する 基本的にはコーチに相談。組織としてスクラムマスターが増えれば、スクラムマスター同士での相談 最終的には課題をチームにオープンにしていき、チームで解決できるように支援 自分がチームの成長の妨げにならないよう、できる限り何もしない PMの癖でステークホルダーとの調整役などをしてしまうと、チームが主体的に話す機会を奪ってしまう 沈黙に耐えること。何分の沈黙ができるのか 組織や会社のことで気になったことはチームに相談してみるを繰り返す 失敗を推奨する 特にレトロスペクティブなど、チーム内だけの影響範囲の場ではグランドルールとして設定 自分ができないことに積極的に行動、「やって、うまくいかない」ことも見せていく姿勢。スクラムマスターが一番失敗する姿を見せる 慣れてきたら答えを言わない（最初はティーチング色強めで始めるが、だんだんとコーチング強めに） 議論が難航したときに「今の問題は何か？」を良いタイミングで質問し書き出してもらう ふわっとした議論で結論が出そうな時は「なぜやるのか」を良いタイミングで質問し、書き出してもらう 最初、人手不足でPOとSMの兼務をしようとしたが3日で断念 スクラムマスターの視点は一歩引く必要があるため、両立させるのは非常に困難（映画見ながらゲームやるみたいな感覚になる） POと開発者の兼務の方がしやすい印象はある（社内コミュニティ内で、やってみた感想） サーバント・リーダーシップスタイル チームメンバーが成果を出すため、なんでも支援。チームにはできるだけなんでもオープンに話す。組織のこと、自分のこと。 功成事遂、百姓皆謂㆓我自然㆒〈功成り事遂げて、百姓皆我が自然なりと謂ふ。〉 自分が常に間違っている、という前提を持っておく。認知バイアスは誰にでもある 現地現物主義。百聞は一見に如かず。聞いた話にはそれ相応の認知バイアスが存在する。また実感が湧かない。現場を見る方が本質的な課題を理解するのが早い 議論が足りない事項で優先度が高いものがあれば「場」を作る 場をつくる、アジェンダをつくる、目的を明確にする、ができれば8割完成（コーチングスタイルを取るなら、全て書いてもらいながら） スクラムマスター同士での本音トークは、助けになる。スクラムマスターも人間です。相談相手は必要 04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） 自分のスクラムマスターの基本的な言動は以下のようなイメージ

フェーズ1：チームの立ち上げ〜混乱期 スクラムの基礎ルールは徹底する POがネックになりやすいので、POとの連携を最重要視（特にROI・価値の創出など） 癖づけ期間 イベントのファシリテーションは慣れるまで、スクラムマスターが行う ステークホルダーには少し我慢してもらう期間 フェーズ2：実践 スクラムイベントの一部はチーム（開発者）が行えるように チームの様子を見ながら、改善ポイントを見ていく ステークホルダーとの関係性や、組織との関係性も少しずつ見ていく 小さくても結果を出すこと 改善が定期的に生まれていること チーム独自のカルチャーが生まれ始める フェーズ3：顧客に目を向ける どういった価値を成し遂げるかに注力 チームと組織の課題を結びつけ、組織課題の改善も始めていく 結果を出す必要性 チーム独自のカルチャーとそのナレッジを他チームへ共有 フェーズ4〜 理想を目指す。理想とは何か 04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） チームのフェーズによって、注力するポイントを変える

04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） 主要なスクラムイベントは下記のような感じ チーム主体のスクラムイベント（主にプランニング、リファインメント）も最初はスクラムマスターがファシリテート ５〜10分単位でのアジェンダ作り チームが慣れてきたら、ファシリテートをチーム（場合により、やりたい意思の強いメンバー）に渡す 最終的には観察とコーチのみを行う レトロスペクティブは主にスクラムマスターがリード こちらは最初は癖づけのため「事実」「仮説」「アイデア」→「いつ、どこで、どうやって」の言語化から始めた 途中からは、5つ以上の振り返り手法を持っておくことを意識 セイルボートレトロ、KPT、焼肉レトロなど遊び含めていくつかやってみたり ファシリテーターとなるスクラムマスターが「次は○○をしよう」と号令をかけるような振り返りになりがち。チームの会 話が主体にすることの難しさが出てきて、最終的に主体をチームに任せる方が無難 スプリントレビュー 基本は開発者とPOにお任せ 今スプリントでどんな価値を生んだか、ステークホルダーとどんな会話をしたいか、が重要 スプリントレビューはステークホルダーとのコラボレーション機会の一つという感覚 リファインメント（独自色多め） 長期リファインメント：リリース計画を大雑把に立てるために、1チケット5分程度で見積もりだけ行う 詳細リファインメント：２週間以内に着手するチケットを、詳細な要件詰めと調査も含めて行う 調査を終えて、不明点がないPBIをReadyステータスにするプラクティスを後に導入

POコーチング なりたいPO像の策定（調べてもらったりしながら） そこに至る要素とアクションを策定 やってみる やってみた感想をもとに、次の課題を策定 やってみる 以下ループ POペア作業（POがドライバー、スクラムマスターはナビゲーターに近い動き） プロダクトバックログアイテムを一緒に書く プロダクトゴールを一緒に書く ファシリテーターコーチング 基本はPOと同じ そもそもファシリテーションの目的とは何か？みたいな話もしながら キャリアの話（自分の実践ベース） 楽しいと思うこと、楽しくないものを書き出してみる 仕事で「自分の中のいい感じ」とは何かを書き出ししながら、繋げていく キーワードを羅列しながら、最後に職種や未来像を言葉にするなら何か？に落としてみる 04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） コーチング／個別育成／キャリアの話

目標設定ワークショップ（4半期見直し） チーム目標ワークショップ この1年でチームで成し遂げたいこと（ロードマップの焼き直し的） このチームのいいところ このチームの課題 この1年チームでさらに伸ばしたいこと・できるようになりたいこと 個人目標ワークショップ チームで伸ばしたいことに貢献できる自分の技術・知識列挙 チームで伸ばしたいことに足りない自分の技術・知識列挙 チームで成したい事以外でやりたいことはあるか? その中で1年で取り組んでみたいことを3つ~4つ決める サービスロードマップワークショップ（ステークホルダーとPO、開発者がオープンに話あう機会） 過去にサービスが提供できた価値を出し合う 過去にサービスが提供できなかった価値(提供したかった)を出し合う 2年後顧客にどういう感情になってほしいか出し合う やれることアイデア出し なぜやりたいかアイデアへのコメント やらないアイデア出し なぜやらないかアイデアへのコメント やりたいアイデアのやりたい順序考えて並び替え ロードマップ確認・調整 他オンサイトワークショップをいくつか。 04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） ワークショップの一部 サービスロードマップワークショップ チーム目標ワークショップ

04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） 他に重要だなというメモ スクラムマスターがどういうことをどういう時にやるべきかはケースバイケース チームの状況、組織の状況に応じて、「今や今後の課題」に関わることを優先順位つけてやっていくもの 最初は特に、チームの内部。チームが回るようになってきたら、組織を巻き込んでの改善へ繋げていく チームファースト チームの成長が、組織の結果に紐づくと信じていく ただ、組織が結果を出せていないとチームも存続できないため、事業が初期の頃は特に結果も重要になる 多様性があるから面白くなる 違う知識から生まれるアイデアがある 間違った発言から、良いアイデアが出ることもある チーム内の作用とは予測できない化学反応であり、その反応を楽しむのがスクラムマスターだと思う ステークホルダーとの関係 チームの状況を理解してもらうのは難しい アウトプットで判断してもらうしかない（「出荷は、言葉よりも声が大きい」） より少ない時間、より小さな作業で大きな価値を生むことが一番（二番目に、コミュニケーションを取ること） どんなにすごい人でもわからないことはある、だから知っていることで完璧な計画を立てるのは限界がある 作りながら適応していく必要がある コーチングは人の成長を感じることが楽しい 特に、「コーチの想定を超える結果」が生まれた時が一番楽しい チームが成長するには時間がかかる それこそ10年かかるという気持ちで挑んでいる 「いつかやりましょうはいつまでもできない」 いつ、どこで、だれが、どうやって、はやると決めたものに関しては重要 「人は変化に抵抗するのではない。変化させられることに抵抗するのだ」

04 具 体 的 な 改 善 策 （ 主 に ス ク ラ ム マ ス タ ー と し て ） 誰かが指示する仕事や習慣 これは、教育現場から始まっている。先生と生徒という関係性にも近い。 システム開発の慣習としてウォーターフォール的な上流工程の担当がいる仕事の仕方が圧倒的に多いため、その癖が抜けない 権限の移譲ができていない 「ゴールを決める」をしてもらうということは、ある種の権限と責任を移譲していることになる 失敗をしづらい環境になっている 失敗を許容して改善していくので「失敗」をしないような仕事を推奨する場合には、スクラムがうまく回りづらくなる ただ、「失敗」をしないために、スクラム以外の業務プロセスを行っても、失敗しないわけではない 事業も、組織も、チームも全部実験と改善なのでは マイクロマネジメントしてしまう 不安に駆られるマネジメントが、細かく状況を知りたがることで余計な認知負荷を与えてしまう 心理的安全性にも大きな影響を与え、結果として自分たちで決めるのではなく「承認」で決めてしまう チームの妨害となっている事柄を放置している 組織上の課題などが原因となって生産性を落としているものは、チーム以外の人間も含めて改善に当たらなければならない 適切な変化が起きていない 半年経って、全く同じ仕事の仕方をしているようならスクラムじゃない スクラムの価値基準である「勇気」「尊敬」「公開」「集中」「確約」が欠けている 他、参考：https://www.ryuzee.com/contents/blog/3637 スクラムが失敗しやすい理由は何か

最 後 に 05

05 最 後 に わからない、から始める 不確実性が高いことからしか、多くのことは始められない 「やっていき」の精神 人は「できる」という考えから始める 私たちは、まずあることを宣言するところから始めなければなりません。それは「人はもともと想像力 と才知にあふれ、欠ところのない存在である」ということです。人は「できる」存在なのです。答えを 見つけることも「できる」し、計画通りに進まない時でも立て直すことが「でき」ます。そして、何よ りも学ぶことが「できる」存在です by コーチング・バイブルより ただ、「信頼はするけど、期待はしない」という精神 スクラムをやっていると人生の優先度も考えるようになる 仕事だけじゃなく、仕事より優先度が高いものは何か？どう生きて、どう死ぬか 「面倒なことから逃げない」 「速く進めるために、ゆっくり進めよ」

05 最 後 に 自分がやったこと、が正解ではないです。 色々とやったことで「起きた価値」について深ぼっていないのは、再現性がないからです。 それこそケースバイケースだから。 スクラムマスターなら、チームの課題に対し、 自分で悩んで、自分で仮説を立て、自分で取り組むしか道はない。 様々な手法はあっても、答えはどこにもないです。

参考 2020-Scrum-Guide-Japanese.pdf (scrumguides.org) ScrumReferenceCard-jp.pdf アジャイルプラクティスマップ | Agile Studio (agile-studio.jp) 書籍「大規模スクラム」等 だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ (zenn.dev) 完了予定も出せないから、いつまで経ってもお前のチームは社内受託なんだよ (zenn.dev) スクラム開発の中途半端な導入で無駄にアウトプットが低下したお前たちに告ぐ｜s_semiya (note.com) スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya (note.com) スクラム導入後にアジリティが減少してしまう理由：プロダクトオーナーの役割に対する誤解、その悪影響および対処法について - スク ラムマスター (scrummaster.jp) 17th State of Agile Report | Analyst Reports | Digital.ai https://less.works/jp/less/scrum-guide​

THANK YOU! あ り が と う ご ざ い ま し た