CSM研修の内容と学んだこと

認定スクラムマスター情報まとめ

NTTドコモ　サービスデザイン部の@dcm_takehiroです。
2021年10月に認定スクラムマスター(CSM)を取得して以下の3つをまとめました。
これからスクラムを学ぶ方や、CSMでどんなことを学ぶのかなどに興味がある方の参考になれば幸いです。

1. 重要だと感じたこと
2. 実際の開発現場でのスクラム状況
3. 研修で学んだこと
＊最後にスクラムについての良い情報リンクまとめ

CSM研修で学んだことを時系列で記載しておりますので長文になっております。
1の**重要だと感じたこと**だけでも参考になれば幸いです。

~ 重要だと感じたこと ~

1. アジャイル4つの価値とアジャイルの12の原則は非常に重要。
2. スクラムガイドは重要で特に「透明性」「検査」「適応」が重要。
3. 失敗を恐れない、人に対しての責任を追求しない。スクラム開発での失敗を個人評価に結びつけない(極度の失敗したくない精神はアジリティを低下させる)
4. スクラムフレームワークは課題の解決ではなく、課題を表面化させるフレームワーク(課題の可視化)
5. スクラムマスターはエンジニアの知識は必須ではない。エンジニアがスクラムマスターの役割を担うと技術的な発言を強くしてしまい失敗するケースがある。
(スクラムマスターはスクラムチームや組織に対してのサポートをするのであって、技術的な問題は開発チームが主体的に働きかける)
6.　プロダクトオーナーは「1人」で「時間的に余裕があり」「決定権」がある人が担う。常に忙しく時間の無いメンバーは向いていない。
7. スクラムマスターはチームだけでなく組織全体をサポートする。
8.　TDDは激しく推奨されていました。
9.　技術的負債(リファクタリング)などはPBIを別に作るのではなく、各PBIの完成の定義に含めて常に取り掛かる。
10. PBIは「いつでも」「誰でも」作ることができ、最初から見積もり可能である必要はない。
11. スクラムチームのメンバーは常に何らかの作業をしていなければならない訳ではない。
12. 完成の定義は全てのPBIに適応される。個別の完成の定義と含めて受け入れ条件を考える。
13.　フィーチャーチームであるべき、コンポーネントチームにしてはいけない。
14. スプリントの途中でもリリースしても良い。
15. モブプロ推奨(ペアプロだと1対1でストレスを感じる人もいる)
16. スクラムを正しく運用するには組織自体変更する必要がある。
17. スクラムに不必要な中間層を設定すべきではない。
18. LeSSでも1人のPOと1つのプロダクトバックログで運用する。
19. LeSSでのリファインメントは対応する可能性の高いチームがそのPBIのリファインメントを行う。
20. 人数を増やすのは最終手段であり、小規模で運用する方が望ましい。
21. 従来のマネジメント(ヒエラルキー)から脱却してスクラムフレームワークを利用しないと大企業でもスタートアップに負けてしまう。

~ 実際の開発現場でのスクラム状況 ~

リリースサイクル

スクラムとして1SP終了時にリリース可能なインクリメントを作成することになります。
開発現場では1SPを2週間で行っています。
担当しているプロダクトでは1SP(2週間単位)サーバー側もアプリ側もリリースすることができるようになりました。
スクラム運用当初は数SPを経てからリリースをしていたが現在ではSP単位でリリースできるようになった。

スクラム運用の定期的改善

担当しているプロダクトに参加しているメンバーは全員CSMのライセンスを取得致しました。
スクラム運用についての知識をつけて改善のサイクルを定期的に回しています。
また、下記のスクラム運用改善に対して以下4つのアプローチを行なっています。

• レトロスペクティブ(振り返り)
• オーバーオールレトロスペクティブ(全体振り返り)
• スクラム運用プロセス改善
• QAチームを発足しスクラム運用での品質向上

プロダクトではLeSSの運用になっているのですが、各チームの振り返りでチーム内では解決できない組織的な問題や課題については特に全体振り返りで解決に向けて取り組むようにしております。

他にもスクラムフレームワークのアクティビティを取り入れるだけでなく常に改善に取り組んでおります。
CSM研修を受けたメンバーも多くまだまだ「こんな課題がある」と個人個人で積極的に提起できており、運用自体もまだまだ進化させております。

~ 研修で学んだこと ~

# 1日目

講師「CSM研修で得た知識を自分の所属している組織に対してすぐに適応させることはとても難しい」

No.1 イテレーティブでインクリメンタルとは

• スクラム開発はイテレーティブかつインクリメンタル両方を持つもの
• イテレーティブ(反復)は既存の組織としては不自然とされることが多い
• スクラムはミスを恐れず反復的に取り組み、反復の中でのミスから気づきを得て少しずつ成果物を大きくしていく

イテレーティブ

• ミスをしても大丈夫という前提
• ミスから学んでもう1回やってみることが重要
• ミスを恐れない
  => ミスをしないようにすることではなく、ミスは発生するのは当たり前と認識しておきそこから学ぶことが重要

インクリメンタル

• 少しずつ増やしていく
• イテレーティブで毎回0から取り掛かるのではなく前回から少しずつ増やしていくようにする

No.2 スクラムが適切な状況は？

• 予測不可能でどのようにすれば良いかが定まっていない状況で有効
• 予測可能でやり方も定まっている場合には有効とはいえない

No.3 「経験的なプロセス制御」の3本柱

1. 透明性
2. 検査
3. 適応

スクラムイベントにはこの3本柱に基づいている
デイリースクラム
ステータスの報告の場ではなくチームが昨日からできたものを検査して修正する必要があるか適応するという機会
スプリントレビュー
製品を共有することで透明性と製品の検査を行う
振り返り
チームの働き方を検査する

Q. スクラムではチーム部外者に対して進捗をどのように可視化することが望ましいか？
A1. バーンダウンチャートなどを利用する(仮説と経験を表現する)
A2. スプリントレビューで実際に動くソフトウェア

透明性だけで検査と適応ができなかった失敗例

スクラムのイベントに則って運用し、バーンダウンチャートなどを使って可視化しておりスプリントを上手く進めていた。
しかし10SP進んだ段階で初めてリリースしたところ様々な問題が浮き彫りになりその後崩壊してしまった。
なぜならユーザーが実際に利用してフィードバックを貰う機会がなく、サービスに対して検査できておらず問題に対しての適応ができなかったためです。
透明性、検査、適応の3つはどれも欠けてはならないものです。

No.4 1日目で重要だと感じたところ

• 失敗を恐れず、失敗から学ぶことが重要。失敗に対して責任や評価などがある文化ではスクラムは根付かない。
• スクラムは開発のためのフレームワークというよりも組織の中の障害を排除するためのフレームワーク
• 何かを加えるのではなく削除するためのフレームワーク
• 障害を可視化して取り除くフレームワーク

変化変更が容易にできるか

方向性を気軽に変えられるかどうかが重要。すぐに行き先が変えられるようになるには組織構造を変える必要がある場合が多い。
方向性を変えるには組織を変える必要がある。
スクラムという鏡は実践することで前よりも今が美しくなったように見せてくれるものではない。
スクラムを実践したら良くなったと思い込んでしまう組織が多いが本当はそうではなく、実際には改善されていないケースが非常に多い。

スクラムは銀の弾丸ではない

• スクラムは働く環境を良くするためのフレームワーク
• なぜ自分の組織にスクラムを導入する必要があるかしっかり検討する必要があり、スクラムが適切ではない場合もある

見積もりはポイントではなくサイズ

フィボナッチ数列を利用することが一般的で実際に利用してきていたがS/M/L/XLといった見積もりを学んだ
見積もりについて重要なことは将来の予測ではなく、次のスプリントでスクラムチームがこれだけのワークができるかという見積もりであること。
S, M, L, XLの4つでXLとなった場合は分割する必要があるという意味。次のスプリントで終わらないサイズということで。

# 2日目

No.1 アジャイルソフトウェア開発宣言をチームで解釈して暗記する

1. ユーザーファーストで早く継続的に提供
2. 仕様変更を受け入れる(歓迎でも回避でもなく当たり前として)
3. 短期間でリリース
4. ビジネスサイドと一緒に価値を作る(言われたことに従うだけでなく)
5. やる気あるメンバーを信頼しよう(信頼して任せる)
6. face to faceの伝える
7. 動くソフトウェアを見せよう
8. 無理せず、継続できるチームで(持続可能なチーム)
9. スピードアップするにはスキルアップと良い設計
10. 優先順位をつけて無駄なことはやらない
11. 主体的なチームは良い設計ができる
12. 定期的に振り返ろう

No.2 POについて

• POは権力がある人がなる必要がある
• 権力、決定権、ビジョンが必要
• 今一度POの役割を考えましょう。本当の意味でPOなのか、出荷を受け入れるだけのPOになっていないか
• (超重要) 時間的に余裕がないとPOとしてダメ
• 権力と決定権は解決策があるがビジョンに関しては解決策がない

No.3 SMについて

• SMは対応すべき問題に対して注力するのではない。またそれはSMの仕事ではない
• SMは振り返りなどで問題を吐き出させるようにするのが仕事
• 振り返りで問題が出てこないのであればLeSSの場合全チームでの振り返りで問題としてあげる
• (個人的に重要)SMはチームだけではなく組織全体に責任を持つべき

No.4 INVEST

プロダクトバックログアイテム(PBI)を上手に作成するためにINVESTという基準がある

I: Independent(独立した。依存関係がない)
N: Negotiable(交渉可能)
V: Valuable(価値のある)
E: Estimable(見積もり可能)
S: Small(小さなサイズ)
T: Testable(テスト可能)

No.5 PBIの作成について

• (いつ作る)PBIを作成するのはプロダクトのビジネス価値が見つかり次第作る
• (誰が)誰もがPBIを作る、書くことができる
• (優先順位)POだけが変更できる
• (良いPBI)独立しており(Independent)、交渉可能で(Negotiable)、価値があり(Valuable)、見積もり可能で(Estimable)、小さく(Small)、テスト可能(Testable)です。

No.6 2日目で重要だと感じたところ

1. SMはエンジニア出身が殆どのケースかと考えていたがエンジニアの知識やスキルはマストではない
2. POは権力者(改めて大事だと気付かされた)
3. POに時間的余裕がないのはNG(担当プロダクトでは慢性的に起きているので改善しないといけない)
4. SMはチームだけでなく組織全体に責任を持つ
5. TDDの重要性とTDDでビジネスサイドとエンジニアサイドの架け橋ができる(テストシナリオを共有することで受け入れ条件は不要となる)
6. PBIの記載事項(内容、優先順位、サイズだけがわかれば良く、d払いは書きすぎのようです)
7. 技術的負債への取り組み方(PBIとして定義しない。レストランの例がわかりやすかった)
8. PBIはビジネス価値が判明した段階で作成する。見積もり可能である必要はない。
9. PBIは誰でも作成可能

# 3日目

No.1　Doneの定義

• スプリントの終わりまでに利用可能でリリース可能な状態になっていることが重要。
• Done(完成)の定義は全てのチームが作るPBIに共通して適応される

// Doneの定義のサンプル
1. しっかりとテストがされている
2. 完全に結合されている 
3. コードのレビューがされている、またはペアプロやモブプロで開発されている
4. ドキュメントが作成されている(必要な場合)
5. コードの可読性が維持または改善されている

No.2 インクリメントとは

インクリメント == 出荷可能なプロダクト

• リリースはPOが必要と判断すればスプリントの終了を待たずにリリースすることは可能
• スプリントが終了した時には必ず出荷可能な状態にする必要がある。テスト不足やリリース準備が終わっていないなどは出荷可能ではない
• 学習(検査と適応)のサイクルを早く回す必要がある

* 技術的に優れているエンジニアが良い設計をして複数の機能を完璧に作り市場にリリースする。
=> 時間がかかってしまい、リリースした時には既に需要がなくなっている可能性やユーザーからのフィードバックを反映させるために時間がかかってしまう。

* フィードバックなどを受けてプロダクトに反映させるサイクルを早く回すことによって需要のあるものを作成できる。
=> 素早く市場にリリースすることで学習サイクルを早く回すことができ、学習したことをプロダクトに素早く反映できる。

No.3 縦切りと横切り

横切りの例

従来型
多くの従来型のプロジェクトでは予想される依存関係を前提にフェーズ単位に仕事を分割し、管理されてきた。計画通りに進めることができ、予測可能で要求と解決策がよく理解できているのであれば従来のアプローチは有効。
問題は全てのフェーズが終わらないと何も出荷できないこと。出荷できないということは仕掛かりの在庫(WIP)を抱えているといえる。

// 横切りの例
1. 要件定義
2. 設計
3. 実装
4. 試験
5. 受入

縦切りの例

スクラム
スクラムは従来型とは異なり、不明確な要求と予測が難しい技術的なリスクのある仕事環境に向いている。短期的な効率性は最適化する対象のゴールではなくなる。
経験豊富なスクラムチームは大きなPBI(エピック)を小さな単位に分割し小さな状態でも出荷可能なビジネス価値を持ち続けられる状態にする。
薄く縦切りにされたアイテムの中に複数の活動が含まれており、フェーズ別に仕事をすることになりません。このような分割にすることでPOがROIに基づいた細かな優先順位づけを行うことが可能となる。

// 縦切りの例
- 要件定義(小)、設計(小)、実装(小)、試験(小)、受入(小)
- 要件定義(小)、設計(小)、実装(小)、試験(小)、受入(小)
- 要件定義(小)、設計(小)、実装(小)、試験(小)、受入(小)

No.4 コンポーネントチームとフィーチャーチーム

コンポーネントチーム例

• 単一の機能を備えたチーム
• チーム内には特定スキルのメンバーで構成されている

- フロントエンド開発チーム
- バックエンド開発チーム
- インフラチーム

フィーチャーチーム例

• プロダクトのリリースに必要な機能を備えたチーム
• チーム内にはプロダクトをリリースするために必要なスキルを全て備えている

- フロントエンド、バックエンド、インフラのメンバーを含む
- プロダクトをリリースできる能力がある

No.5　技術的負債について

技術的負債 == レガシーコード
Q. スクラムでは新しい機能を開発していくための取り組みは理解できたが、既存のコードのリファクタリングや不具合などの対応はどうすれば良いか？
A. レガシーシステム上に新規機能を追加する場合は追加する部分に自動テストを組み込みわかりやすいコードにする。
＊少しずつ改善していく必要がある。

No.6 3日目で重要だと感じたところ

• 全ての作業者は何かを常にしていることではない。何かを常にしていないといけないと考えてはいけない
• 作業者に必ず作業があるようにする偏見を持ってはいけない。作業者が未来の作業を整理したり、作業を作る必要もある(技術力向上も必要)
• 技術的負債に関しては「リファクタリング」などのPBIを作るのではなく各PBIの中で少しずつ改善していく必要がある
• 完成の定義は全てのPBIに適応される
• コンポーネントチームになってはいけない(必ずジェネラリストになる必要はない)

# 4日目

おすすめされた書籍
最強組織の法則
＊最強の組織にするために体制や組織自体が変わらないといけない場合がある
https://www.amazon.co.jp/%E6%9C%80%E5%BC%B7%E7%B5%84%E7%B9%94%E3%81%AE%E6%B3%95%E5%89%87%E2%80%95%E6%96%B0%E6%99%82%E4%BB%A3%E3%81%AE%E3%83%81%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B-%E3%83%94%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%BBM-%E3%82%BB%E3%83%B3%E3%82%B2/dp/419860309X

No.1 組織構造

スクラムの文化を根付かせて正しく運用するには組織構造を変更しなければならないケースが非常に多い

プロセスや組織が正常に動いているかについて4つの尺度

1. 顧客満足度
2. 労働者満足度(組織自体、プロセスが好ましくなければ労働者もハッピーでない。関わる人は作って見せたいが会社の事情でブロックされるとアンハッピーになってしまう)
3. 問題発生率、障害発生率(バグが発生するのは？開発した人が理想と動作に違いがあればバグが発生する。コード自体がわかりにくい。読みやすいとバグが発生しにくい)
4. サイクルタイム、リリース頻度(いいアイデアからリリースまでのラグタイム。)

上記4つの指標が完璧だった例

• 1日に数回りリースをしている(スプリントの終わりまで待ってリリースするなどの制限はない)
• 開発者のスキルアップに時間とお金を投資している(努力対利益が高い)
• チームメンバーが同じ場所で一緒に働いている
• モブプログラミングを行っている(15分間隔でドライバーを変更している。ドライバーは自分でコードを創造するのではなくナビゲータが創造して記入する)
• SMは何か言いたくても何もしないこと(これが一番難しい)
• SMは「なぜ」と問いかけることと他のメンバーのためにより良い事例を紹介する
• SMはチームの管理者でもマネージャーでもない(「何か」をやらせるのではなく「サポートする」)
• 目的: 学習できる組織　手段: モブプロ

No.2　フィーチャーチームについて

• システム全体を見ることができるチーム
• 1つのチームが作業が終わって出荷を待機する必要がない
• (例)各チームのiOS開発メンバーは他のチームのiOS開発メンバーとコミュニケーションを取る必要がある

Q. エンジニアとして特定のスキルを伸ばしたい場合にスクラム開発をするのでジェネラリストが求められていているのであれば自分のキャリア形成と相反するのでは？
A. 必ずしもジェネラリストになる必要はない。リリースに必要なスキルを個人個人で全て持つ必要はなく、リリースに必要なスキルをチームが持っていることが重要

No.3 不必要な中間層の設定

ウォーターフォール型の開発や委託開発などを行なっていると指示するメンバーと作業をするメンバーという構成に慣れてしまっている。
大勢の人間はヒエラルキーのあるマネジメントする伝統的な手法に慣れており、代替する仕組みを考えるのが苦手である。
結果的に組織は様々な役職(ヒエラルキー)を用意してしまう。
スクラム開発では「プロダクトオーナー」「スクラムマスター」「開発チーム」の3つの役割しかないが、組織は既存の役割のメンバーに対してスクラムに不必要な「チーフプロダクトオーナー」「ビジネスオーナー」といった役割を作ってしまう。
「チーフプロダクトオーナー」や「ビジネスオーナー」の名称を用いるということは、不必要な中間層の設定という病の症状が出ているということです。
スクラム及びLeSSにおいて、真のビジネス上の決定権者にはシンプルにプロダクトオーナー

No.4 LeSSについて

LeSSの構造

• チームを組織の基本単位とし、個人ではなくチーム単位で組織を構成すること
• それぞれのチームは「自律的」「クロスファンクショナル」「同一ロケーション」「長期間存続」であること
• ほとんどのチームは顧客中心のフィーチャーチームであること
• SMはLeSS導入が問題なく行われることに責任を持つ。そしてチーム、PO、組織、技術的手法の改善に注力し、1チームだけの改善にとどまる事なく、組織全体の改善を行う必要がある。
• SMは専任でフルタイムであるべき
• 1人のSMが複数チームを担当することができる
• LeSSではマネージャーの存在は任意だが、存在する場合は役割が変わる可能性が高い。マネージャーはプロダクトの一部だけを見るのではなく、プロダクト開発全体の価値提供をみるようにする
• マネージャーの役割はプロダクト開発の改善を推進すること。異常があったらすぐに止めて直すことを推奨する。現状維持ではなく実験的な試みを推奨する
• スタートから完璧にLeSSの構造を適用させることが重要。LeSS導入の肝となる
• LeSSの導入を単一のプロダクト開発グループだけでなく、組織全体に広げていくことで、実験や改善が当たり前となる環境を作っていくことができる

LeSSのプロダクト

• 1つの出荷可能なプロダクトに対して1人のPOと1つのプロダクトバックログで運用を行う
• POは一人でPBLリファインメントを行うべきではなく、いくつかのチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、POをサポートしている状態であるべき
• 全ての優先順位付けはPOに集約すべきだが、要求や仕様の詳細確認は極力チーム間や顧客、ユーザーまたはステークホルダーと直接やるべき
• 全てのチーム共通での共有するDoneの定義を持つ
• 各チームで個別の拡張版Doneの定義を持つことができる
• 最終的なゴールは毎スプリント出荷可能な製品を作れるようになることである(さらに頻度を上げることに挑戦するのも良い)

LeSSのスプリント

• 各チームは同じスプリント周期を守ること。スプリントの終わりにはプロダクト全体が1つに結合されている状態にすること
• スプリント計画は2つのパートに分かれる。1部は全てのチームが一緒に行う。2部は各チームに分かれて別々に行う。但し関連性の高いアイテムを持っているチームは同じ場所で行う
• 1部はPOと全チーム又はチームの代表にて行われる。各チームが次のスプリントで何をするかを選び、他のチームと協働する部分がないかや不明確な点はないかを議論して最終的に各チームがやることを決定する。
• 各チームはチーム毎のスプリントバックログを有する
• スプリント計画2部は各チームがどうアイテムを実現させるかを考える場であり、設計とSBLを作ることになる
• デイリースクラムはチーム単位で行う
• チーム横断での調整はチームに委ねられている。中央集権的で形式的な調整ではなく、個別の判断で自ゆに調整する方が好ましい。重要なのはお互いに会話をすること、コード上でのコミュニケーション、チーム横断での会議。
• リファインメントは各チームでそのチームが対応する可能性が高いアイテムをリファインする。チーム間での共通認識作りや調整機会を増やすために領域が近いアイテムや広い領域の理解が必要な場合には複数チーム又はオーバーオールリファインメントを行う
• スプリントレビューは全てのチームで行う。検証と適応を行うのに十分な情報を得られるように必要なステークホルダーが参加しているようにすること
• 振り返りは各チームで行う
• オーバーオール振り返りは各チームの振り返りの後に行われる。ここでは複数チームの共通課題や広い領域の課題を扱い、改善に向けての試みを決める。この場にはPO、全SM、チーム代表とマネージャ(いる場合)が参加する

No.5 4日目で重要だと感じたところ

• ペアプロは1対1でストレスを感じる人も多いがモブプロはストレスが減る
• アジャイルのプロジェクトでは人を増やすのは最後の選択肢
• アジャイルは大規模になってしまうとアジャイルの実践が難しい
• 大規模、複数拠点、オフショアはしないほうが良い
  例) アメリカで防衛システムを大人数で大規模に開発を行っていたが、もう一回同じものをゼロから作るにはどうするか？=> 少人数の優秀なメンバーを選んで作る

# 5日目

No.1 完成の定義

• 主に「テスト」「ドキュメント作成」「リファクタリング」「技術的負債解消」を完成の定義として含める
• 大規模だと1SPで出荷可能な状態にすることは難しくなるが毎回のSPで出荷可能な状態にすることが難しいのであれば組織的な問題
• 組織的問題はオーバーオール振り返りで見直すことをおすすめする

弱いDoneの定義

• 各スプリントが終わっても「リファクタリング」や「テスト」「ドキュメント」などが作成できていない状態
• 各スプリントが終わってもリリースできる状態になっていない

しっかりとしたDoneの定義

• 各スプリントで出荷可能なプロダクトインクリメントが作られる

Doneの定義は以下の3つのことを検討し、問題があれば改善が必要

1. POが「今見せてくれたものをすぐに出荷してほしい」と言ったら全てのスプリントでその要望に応えられるか？
2. 各SPで出荷可能なインクリメントが作られていないとして、出荷可能にするために何が最も変えることが難しいか？
3. 出荷可能なプロダクトを毎スプリント作るためにあなたの組織が「諦めなければ」ならないことは何か？

1SPで出荷可能なインクリメント

• 1SPでできることを書き出してみる
• 1SPで残作業を発生させないためには何が必要か考える
• 1SPで残作業を発生させないためには組織変更が必要か考え、必要があれば組織変更に取り組む
• 1SPで出荷可能なインクリメントを作成するためにはどういうスキルがチームに必要か考える

No.2 スクラム導入後にアジリティが減少する理由

組織がアジャイルにしないといけないと思ってスクラムの勉強しようとして実践したら小さなスクラムチームができてしまって、
以前の管理者が管理する今まで通りの体制ができてしまう。
足指だけスクラムになっているがそれ以外は従来の開発になっている。
従来のマネジメント体制にしようとするとリーンスタートアップの会社に比べると圧倒的に遅れて失敗してしまう。
昔からある大きな会社でも小さなリーンスタートアップの会社に負けてしまう。
大きな会社であったらスクラムを実践しようとする。実践方法に誤りがあり、早く行動できる会社が出てきて競争に負けてしまう。

No.3 5日目で重要だと感じたところ

• 1SP終わったタイミングでリリースできていないのであれば非常に大きな問題
• 1つのPBIが完成してリリースできる状態としてテスト実施やドキュメント作成も含まれる。テストやドキュメント作成をPBIから外だしして別のPBIにすべきではない
• スクラムフレームワークを取り入れるのであれば従来のマネジメント体制を変更しなければならない。そうでなければ大きな会社でもスタートアップとの競争に負けてしまう可能性がある。

認定スクラムマスター(CSM)とは