はじめに
どうも、認定スクラムマスターの瀬尾です。
弊社ではエンジニアの支援制度として認定スクラムマスター取得の補助があります。これを利用して Certified ScrumMaster （CSM） を取得したので、その研修で学んだスクラムの基礎をまとめ、更にふ〜んとなったことや疑問に思ったことについて書いていけたらと思います！
私が受講したのは、Joe Justice 先生の認定スクラムマスター講座です。2日間の研修があったのち、Webテストを受けて合格しました。ちなみに合格すると合格証と下のバッジがもらえます。Linkedin にも資格を登録してもらえました。
受講の背景を簡単にまとめてみる
- 受講前の知識量は「開発部に参画してから1年くらいスクラムの開発メンバーとして働いた」程度のものだった
- 3ヶ月くらい、見様見真似でスクラムマスターのような動きをしてはいた
- スクラムがアジャイルの具体であるということを知っていたので、何を大切にすればその抽象の方をつかめるのかを知りたかった
どんなことやったか
研修は基本的にグループで進んでいきました。
スクラムに登場する役割と各イベントについて説明を聞き、その後軽いロールプレイのような形でグループワークを行います。
講師の Joe Justice 先生は海外の方ですが、通訳の方を通したやり取りや先生が頑張って話す（かわいい）日本語、良質な資料によって言語の壁でやりづらいということは感じませんでした！
あとめっちゃイケボでした。英語のリスニング問題を思い出しながら聞いてました。
また研修はオンラインでの開催でしたが、その壁もあまり感じませんでした。
基本的にはエンジニアの方が集まっていたからかオンラインツールの扱いに慣れていそうだったことや、参加者の方がみな能動的だったことが要因かも。
学び
スクラムの基礎知識
スクラムとは
スクラムは、アジャイル開発（俊敏性のある開発を示す概念）の実現方法のひとつです。
アジャイルはチームワークに基づいたスピードの速い働き方を実現する複数の手法やフレームワークの総称、概念、価値観、マインドセットのことで、単なるプロセスやツールのことではありません。
（参考：アジャイルソフトウェア開発宣言）
よく対比されるウォーターフォール開発との違いは、要件定義からテスト・リリースまでのサイクルを回す回数です。
ウォーターフォールでは大きな1つのサイクルを回しますが、アジャイルは大きなプロダクトを小さく分割して、複数回のサイクルを回します。
サイクルの違い、アジャイルは要件定義からリリースまでを何度も繰り返す
ウォーターフォールは100年くらい前に製造業の文脈で生まれたものであり、そもそも時代遅れであると言われていました。
前に戻って変更できず初期要件に大きく依存する、プロダクト全体が最後にのみテストされるといった体制が、不確実性を含んだソフトウェア開発には合わないことがほとんどです。
また、計画が機能ではなくアクティビティの完了に基づくため、一つの工程が遅れると全てが遅れます。
登場人物
スクラム開発には3種類の役割が登場します。
-
プロダクトオーナー（PO）
- プロダクトの価値の最大化に責任を持つ人
- 予算やスコープ、優先順位を決定する
- チームに可能なことを把握して設計する
-
スクラムマスター（SM）
- スクラムを促進したり、開発者の幸福度を上げたりする人
- プロジェクトを進めるにあたって障壁があれば解決する
- 心理的安全性を高める
- チームの速度を落とさないために人のアサインを調整する
- ゲームのプレイ方法を教えるコーチのような役割
- 常にプロジェクトの状態を正確に確認できる存在
- スクラムを促進したり、開発者の幸福度を上げたりする人
-
開発者（Developers）
- エンジニアやデザイナーなど、スキルを持った人たち
- フルスタックで、設計から実装まで全部できる必要がある（クロスファンクショナル）
スクラム開発では、1チームは最大10名まで（理想は6人以下らしい）で、プロジェクトの掛け持ちはせず 1つのプロジェクトに集中すること（モノタスクであること）がルールです。これめっちゃ試験に出た。
また、チームがクロスファンクショナル（機能横断型）であることが上に挙げられていますが、これは リリースまでに必要なスキルが全てチーム内にある（全員合わせてフルスタックである）ことを指しています。
しかし、一人ひとりがフルスタックであったほうがそりゃ早いので、開発者は理想的にはそれを目指すべきと言われていました。
そもそもチームがフルスタックではない場合はモブワークで進めることをおすすめしていました（モブワークはフルスタックなチームを育てる一助になるそう）
登場人物の中に「マネージャー」がいないことにも注意しなくてはなりません。
スクラムでは 自己組織化（チームや組織が自発的に動くことができる様子）が重要であるため、マネージャーの役割はメンバー全員に分散されています。
ボトムアップで管理するというわけですね。
Google も「心理的安全性は成功するチームの構築に最も重要なものである」というような言葉を残しているように、ここでは アジャイルは心理的安全性なしでは機能しない と言われていました。
これは僕も体感上そう思います。スクラムマスターとして、なんでも言い合えるチームづくりをしていきましょう〜
また、研修ではここまでの説明の後に下の問題をやって、知識を確かめる時間がありました。
成果物
スクラムでは、3つの成果物が出来ます。
-
プロダクトバックログ（PBL）
- 何を作るのか、価値のあるまとまった機能のリスト
- それぞれをプロダクトバックログアイテム（PBI）と呼ぶ
- PO が責任を持つ
- 8個くらいが理想らしい
- 何を作るのか、価値のあるまとまった機能のリスト
-
スプリントバックログ（SBL）
- プロダクトバックログをより詳細にタスク化したもの
- それぞれをスプリントバックログアイテム（SBI）と呼ぶ
- 開発者が責任を持つ
- S,M,L,XL といったサイズで各タスク消化の重さを見積もる
- プロダクトバックログをより詳細にタスク化したもの
-
インクリメント
- テストされ、リリース可能な状態の作成物
- （サイクルを繰り返して作成物が漸進的に増えるためこんな名前で呼ばれる）
スクラムイベント
スプリント
スクラム開発は、先に説明したようにサイクルを繰り返して進めていきます。
この1回のサイクルを スプリント といいます。
スプリントの期間は、計画→構築→テスト→リリースのすべての工程を含んだ長さにする必要があります。
2週間スプリントで回すことが一般的だと思っていましたが、全工程を含んだ長さにするため90日スプリントとなることもあり得るそうです。
イベント
スプリント中には、5つのイベントがあります。
SMはこれらのイベントのファシリテートを行います。
-
リファインメント
- POは、PBIの詳細や要件、優先順位を明確にする：
- DoR: ビジネスにおける開発を開始できる条件や、PBIの開発を開始できる条件
- DoD: 完了の定義（レビュー完了、テスト完了など、チームが合意して決める）
- 受け入れ基準： PBIが望ましい機能や性能をみたしているか確認するための基準
- 開発者は、PBIを技術面から解釈し、必要なリソースを見積もる
- POは、PBIの詳細や要件、優先順位を明確にする：
-
スプリントプランニング
- 開発者が、PBIの中からスプリント期間中に何を達成するか決定する
- スプリントの作業計画を立て、実行可能なことを確認する
- PBIの実装に必要なタスクを分解し、それぞれ定義する
-
デイリースクラム
- 開発者が作業について共有・調整し、スプリントの達成を促進させる
- スプリント中に毎日行う
-
スプリントレビュー
- インクリメントをステークホルダーにお披露目して完成を祝う場
- POは、PBIの優先順位を再評価し、調整する
- 開発者は、技術面などの質問に答える
-
レトロスペクティブ（ふりかえり）
- 悪かった点だけでなく良かった点も共有し、継続的にプロセスを改善する
- POは、ビジネスの側面からアイデアを与える
- SMは、ツールや手法を使って会話を促進させる
- 開発者は、様々な感想を共有して次のアクションを決定する
特に、ふりかえりは最も取り入れやすいアジャイルのプラクティスであり、アジャパーでも最初の一歩として勧められていました。
失敗し、改善していくのがアジャイルですからね！
価値基準
スクラムには、５つの価値基準があります。めっちゃ試験に出た。
- 確約：チームメンバーは、スプリントの目標達成にコミットする
- 集中：チームは目標に集中し、達成することに専念する
- 公開：チームメンバーは、作業状況、課題、アイデアなどをオープンに共有する（チームで改善点を見つける）
- 尊敬：チームメンバーは互いを尊敬し、個々の貢献を認める
- 勇気：透明性を重視し、問題を隠さずにオープンに議論する
勇気は特になくしがちなので普段の業務でも意識したい…！
ふ〜んってなったこと
PBIの見積もりは標準化する
プロジェクトを推進するとき、納期を考えるために見積もりを行います。
PBI をそれぞれ S, M, L, XL のサイズに対応するフィボナッチ数列のポイントで考えます。
フィボナッチ数列を使う理由は、その性質から隣同士の値に差があり、見積もりごとの差が明確になるからです。
ここでの「標準化」とは、工数や時間での見積もりではなく、個人のスキルに依存しない形として作業の複雑さや労力で見積もること です。
また、意見ではなく、事実を元に見積もることも重要です。
見積もりのばらつきには平均を適用する
現実には、複雑さや労力がわかりづらい不確実性の大きなタスクもあるため、このような場合はどうすればいいんだろうと思っていました。
ですがそういう場合は、みんなの見積もりから平均を取って、一番近いポイントで見積もってしまえばよいとのこと！
なぜなら、社会学や統計学的に「みんなの意見は案外正しい」もので、人間の見積もり能力はフィボナッチ数の±1程度の精度しかない ためです。
人によって見積もりがばらつくようなものは、平均すれば案外正しいポイントになるということでした。
そもそもどう見積もればいいのか分からない場合の対処
以前に完成した作業アイテムと比較するように、見積もりを類推しましょう。
類推する先PJがない場合は、ほかチームのPJを参考にするのがよいです。
見積もりがハズれて、スプリント中にPBIが達成できない場合
思ったより作業が重く、スプリントゴールを達成できずPBIを持ち越してしまうなんてことがたまにあったりします（経験談）
スプリント中に「あれ、これ見積もり間違ってね？」と感じたときにその見積もり自体を変更するべきかどうかという話です。
特にスクラムとしてルールはないですが、チームの士気が高い場合は修正せず（メンバーが学んで今後の見積もりが改善される）、チームの士気が低い場合は修正する（メンバー見積もりスキルは向上しないけどフラストレーションを軽減）のがよいと言われていました。
#NoEstimate
ここまで見積もり見積もりといってきましたが、見積もり通りに完了させようとすることは、不健全なプレッシャーとなる場合があります。
プロジェクトの初期段階では特に不確実性が多いので、それを含めた見積もりを行う必要があります。
しかし、変更される見積もりというのは、用意するだけ時間の無駄だと言われていました。
この不確実性コーンの図のように、具体的な納期というのはプロジェクトが進まないとわからないものです。
テスラのようなビヨンドスクラムな組織では、納期の見積もりは行わず、タスク消化のトレンドから完了時期を推測しているらしいです。
このへんの理解が経営側にもあるということなんでしょうね…（羨ましい）
余談なのですが、エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングでも不確実性コーンについて言及されており、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方だと述べられていました。
モブワーク
モブプロなど、チーム全員で同じことを同じ環境で行うモブワークの利点を説明されました。
ドライバー、ナビゲーターの他に、ChatGPTなどを駆使してアイデア出しをする役割も用意すれば、より効率的に回せるよーというアイデアがためになりました。
（理想は、業務コンテキストにあったオリジナルAIがあるとよいとのこと。欲しいけどむずい！）
ちなみにテスラは全ての作業がモブワークらしいです。
スクラム関連
スプリントの期間はころころ変えないべき
何らかの理由があったとき、スプリントを延長してリリースまでやりましょう！というのはよくないです。
なにかの障害でリリースできない場合は、そのスプリントでのリリースを見送って、次のスプリントでやるべきと言われておりました。
それでも全然終わらない場合は、チームのスキルに対してスプリントが短すぎるか、タスクの細分化が足りてないかが原因と思われるので、それを解決することを考えましょう。
メンバーのスキル向上をPBIとしてよいか
メンバーの自己研鑽は、よりよいプロダクト開発のために必要そうですよね。
これをPBIとしてスプリントに入れちゃうのはどうなん？というQ&Aがありました。
これは、POがそれを価値として成り立つと考えるかや、優先順位をつけられるかによるとのことです。
優先順位を付けられるかというのは言われてみればそうなんですが、難しい問題だな〜と思いました。
POの役割
研修の途中でこの動画を見る時間がありました。
POは、プロダクトの理想とステークホルダーの要望からユーザーストーリーを見出し、これをリリース可能な単位で分割します。
また、開発チームのキャパシティを考え、短期/長期のトレードオフを加味して優先度を判断し、時にはやらない決断もしなくてはなりません。
判断材料を得るために、関係者とのコミュニケーションを取る必要があります。
じゃあうちはというと…ここまで意思決定できているPOはおらず、ほとんどステークホルダーしかいない状況です；；
同じ事業なのになかなか合意を取った優先度判断がなされない状態だったりします。
この動画を通して、弊社の組織課題をより強く認識しました。
そんな現状に対処するために
レバテックには多くのプロダクトがありますが、それぞれが独立しているわけではありません。
すべてを一つのプロダクトとして見立てなくては、システムも組織もきれいに整備することはできないのではないかと思いました。
この研修での気付きや他の様々なタイミングに由来して、開発部では1個のドメインに集中するチームが立ち上がりました。
レバテックの中でも独立して意思決定が可能な範囲（今回の場合はドメインごと）に対してそれぞれPOを置いてもらい、優先度を付けながら対応していくことで事業戦略に沿ったシステムづくりをしていこうという試みです。
これについてはまだ始まったばかりなので、いつか記事にできればと思っています。
おわりに
わたしは、認定スクラムマスター研修を通して、スクラム開発もといアジャイル開発を上手く行うために必要な環境を認識できたことがよかったです。
レバテックにはアジャイルに必要な環境がまだまだ揃っていないという組織課題を認識できました。
研修で得た知識を活かして、僕のチームの範囲から小さく、インクリメンタルに解決していけたらと思っています。
私は1開発チームリーダーですので、組織全体に影響していくには力不足感があります；；
テックリードやCTO室のメンバーとして、組織とシステムの両方を改善していってくれる仲間を待っています！
Discussion