[LSM] 認定スクラムマスター(Licensed Scrum Master)合格体験記/研修概要

LSM/研修の概要

LSM(Licensed Scrum Master):認定スクラムマスター

  • スクラムマスター資格として有名な、二つ(LSM, CSM)の一つ
  • LSMはScrumの生みの親のジェフ・サザーランドが監修している

LSMとCSMどっちがいいか?

  • 結論としてはどちらでもOK
    • 会社で枠が空いている方にしました。また、個人で費用を払うならLSMの方が安価
  • LSM研修について
    • Scrumの生みの親が監修しているだけあって、内容は素晴らしかったです
    • スクラム経験者から見ても、為になるプラクティスが多かったです。後輩にも受けさせたい
    • 少なくともLSMにして後悔することはないと感じました
  • CSM: Scrum Aliance 認定スクラムマスターは以下のようなイメージ
    • 講師は意図的に厳しいスタンスを取る為、演習が非常にハードらしい
    • CSMは2年で有効期限を向かえて2年毎に更新料$100が発生する
  • 以前取得したEXIN Agile Scrum Foundationで得た知識もとても役立ったが、メジャーな資格ではない
    • LSMを受けるまで表面だけしか分からないプラクティスも多かった

LSM研修概要

  • Scrum Inc. Japan主催
  • 2日間 9~17:30
  • ワークがメイン
    • 参加者達を複数のスクラムチームとして分ける
    • スクラムを学ぶという行為自体をスクラム開発PJとして進めます
  • 各チームにScrum Inc.のトレーナーがつく
    • 質問の機会が多く、普段の業務で溜まっていた疑問を全て解消できた

試験の概要

  • 試験準備
    • 研修終盤に、Scrum Incのサイトで登録を行う
    • 指示に従って、マイページ登録を完了すれば受験可能な状態となる
    • 好きなタイミングで受験可能だが、推奨受験期間は90日以内
  • 試験概要
    • 形式:オンライン
    • 選択式30問
    • テストは2回まで無料で受験可能(3回目から有料)
    • 試験中に手元の資料を参照することができる

試験までの学習

  • 学習すべき事項は以下の三点
  • スクラムの別の資格を取得済みで基礎知識があったので、研修受講後に即受験した
  1. スクラムガイド
    • 以下が重要
      • スクラムの理論、価値基準
      • ロールと役割
      • Event
      • Output
    • スクラムの理論(透明性、検査、適応)と価値基準(確約、集中、公開、尊敬、勇気)が各イベント、アウトプットにどのように関係しているか理解しておく
  2. アジャイルソフトウェア開発宣言
    • スクラム開発を始めた際にメンバによく見せるページ
  3. アジャイル宣言の背後にある原則

試験本番

  • ScrumIncのサイトから開始
  • 時間制限は特になし
  • 資料を見ながら受けられる
    • 細かい用語はスクラムガイドや研修のスライドで確認しながら進めるイメージ
  • 講習受講後に即受験して正答率は 28/30(93%)
    • 元々別のスクラム資格を持っていて、スクラム開発を経験していることもある
    • スクラム経験無しの場合、研修受講だけでは少々戸惑いそうな問題も散見された
      • スクラムガイドや研修のスライドを読み直してから受験すると良さそう
  • 受験後に間違えた問題も確認できる
  • 合格後に試験を受けたサイトで認定証(pdf)をダウンロード可能になる
  • 期限は1年間
    • 更新料は5,000円

LSM取得後のラーニングパス

研修のノート

自身のScrumチームに適用できそうなこと

  • スプリントパターンの適用(研修スライド参照)
    • スウォーミングが重要
      • 「チームの全員が、最優先のバックログアイテムが完了するまで、それに集中すること」
      • タスクの担当を確定せずに手が空いたメンバが消化していくべき
      • 優先度の高いPBIがIn Progressであれば、リソースを集中させるべき
  • アフィニティ見積もり(用語リスト参照)
    • PBIを想定的なポイントで見積もる方法の一つ
    • S,M,Lだけでやっていたが、必要に応じてXS等も追加してよい
    • その後数値のポイントに変換する
    • ラベルごとに定義するPointはフィボナッチ数が望ましい
  • PBI毎の受け入れ条件
    • Task毎には設定しなくて良い
    • Task毎のDoDはAPI、フロントエンド等のカテゴリで同様になるため、共通のDoDにまとめる
  • SP計画について
    • 計画段階で担当者を確定させるとスウォーミングができなくなるのであまり望ましくない
    • 手が空いた人がやって良い
  • デイリースクラムについて
    • 朝会ではSPボード(カンバン)を映し、Milestoneの%を毎日見る
    • 可能であればPBI & タスクのバーンダウンを両方表示
    • パーキングロットを適用する
      • 議論を掘り下げる必要があるが、デイリースクラムから溢れる時に活用するプラクティス
      • パーキングロット(駐車場)を作って議論が必要なものを一時停車しておく
      • 議論に参加する必要のある人だけが後に残り、他の人はSPバックログの仕事に残る
  • SPレビューについて
    • Velocityはステークホルダーにもここで見せるべき
    • スプリントサマリ(スライドp210)
    • PBIを基に、リリースまでのバーンダウンチャートも見せる(SP毎のバーンダウンとは別)
  • レトロスペクティブについて
    • 改善バックログを採用する
    • Velocityは本来PBIで図るべきだが、Velocityの低い状態ではタスクで図ってもOK
  • Scrum of Scrumについて
    • サービス群を管轄している上位者をCPO(チーフプロダクトオーナー)と置き、ハイレベルのバックログを提示して頂く
  • Scrum@Scare
    • 大規模な組織にスクラムを広げていく手法。良いチームをまずは二つ作って、そこを真似る形でスケールしていく。自社でも適用できそう

ノート

デイリースクラム

  • コミュニケーションの浸透度と仕事の進み方に相関がある
  • 前回のDSから何をしたか?
  • SPゴールの達成を妨げる障害物はないか?
  • SPゴールを確実に達成するには次に何をすべきか?
  • パーキングロット
    • 議論を掘り下げる必要があるが、デイリースクラムから溢れる時に活用するプラクティス
    • パーキングロット(駐車場)を作って議論が必要なものを一時停車しておく
    • 議論に参加する必要のある人だけが後に残り、他の人はSPバックログの仕事に残る

Scrum of Scrum(SoS) p156

  • 協力する必要があるチームの集まり
  • チームの中のチーム
  • チーム毎のSCMが連携する
  • POも複数にして良い
    • ハイレベルのバックログを作るチーフPO
    • Teamごとのバックログを作るPO
      • TeamごとのPOは一人
  • ハイレベルのバックログを作るチーフPO

Scaled Daily Scrum(SDS) p157

  • スクラムオブスクラムマスター(SoSM)がファシリテートするイベント
  • チーム横断の調整を可能にする
    • SoSのSpゴールを実現するために再計画をする機会
    • 可能であれば、障害物を表面化させて除去
    • 継続的改善のための学習を共有する

Scrum@Scale

  • チームの集合をSoSと呼ぶ

  • Whatの整理方法

    • Shared Backlogに責任を持つのがCPO
    • Module毎にPOを立てる
    • CPOとPOたちが集まってTeam Backlogに分解していく
  • 各Teamのインクリメントを統合することで一つの価値になる

  • Scaled Daily Scrumでチーム間調整を実施

  • ハイレベルのバックログをCPOに作ってもらうとよい

  • PdMについて

    • POより業務範囲が広いイメージ

PBの見積もりについて

  • デルファイ法についての研究

    • 人間は絶対的な見積もりよりも想定的な見積もりが得意
    • 専門家は1人で見積もる必要がある
      • アンカリング(他の意見に引きずられる)を避けるため
  • アジャイルな見積もりの戦略 p156

    • speed, time, distanceのうち調整できるのはdistanceのみ
      • そこで見積もるStory Pointを調整する
    • 時間を見積もらない
      • ストリーの相対的な大きさを見積もる
      • SPごとにベロシティを測定する
      • リリース計画を導出する
    • 見積もりは実際の作業をする人たちが行う
    • PJの開始前だけでなく、期間を通じて常に見積もりを行う
    • 詳細に記述したドキュメントよりも、口頭での会話を用いる
  • MSにおける見積もりの正確さ p157

    • Pointの方が正確
  • NJ Telecom

    • Pointの方が見積もりにかける時間も50倍早い
  • アフィニティ見積:相対サイズに選別

    • XS,S,M,L,XLをPBIごとに定義
      • 足りなければX○を増やしても良い、チームで考える
    • 相対サイズをポイントへ置換 p161
  • 国防コントラクター

    • チームはポイントの方が幸福
  • リファレンスストーリー

    • 相対サイズの見積もり
      • これからやる仕事と、よく知っているorDone済みの仕事とを大きいか小さいかを比較すること
    • 様々なサイズのリファレンスストーリーを選び、「ものさい(定規)」を作成する
    • 古くなったらUpdateする
    • フィボナッチ数にする理由
      • 数理的分析により、指数的に大きくなる方が、線形に大きくなるより見積もりに向いている
  • プランニングポーカーの無料アプリ

    • iPhone: Scrum Inc Poker
    • Android: Scrum Planninf Poker
  • 正確な見積もりの手法: Planning Poker

    • 開発者メンバーフィボナッチ数が一つづつ書かれたカードを配る
    • 合計の数字が三つの数のハニに治っていれば、合計して平均値を出し、次のタスクに移る。(平均して四捨五入)
    • 4つ以上に跨っている場合
      • 最小値と最大値を出したメンバが根拠を説明
        • 議論はしない
      • 再度全員でカードを出す
      • 合計3回繰り返しても治らない場合は、最大値と最小ちを除外し、残った数の平均をとる
    • すり合わせは不要。コンセンサスを目指しているわけではない
    • 最終的な見積もり値はフィボナッチ数にならなくてもいい
    • 基準を一つきめて、そこにフィボナッチ数を定義してからスタートする
  • 見積もりでの重要な点

    • 決してチーム間で見積もりを標準化しない
    • 決してチーム間でVelocityを比較しない
    • Velocityが50ポイントのチームは30ポイントのチームより実際は遅いかもしれない。ポイントはチーム内の相対値。したがって標準化はできない
    • ベロシティの傾向(トレンド)はチーム間で比較できる

リリースプランニング

  • POがリリース計画、日付、ROIを受け持つ
  • 1つのSP分を準備完了(Ready)のPBにする
    • →チームが始められる
  • 2つのSP分を準備完了(ReadyのPBにする)
    • チームが加速する
  • リリース計画を立てる
    • 顧客がデリバリー日を信頼できる
    • 会社が収入を予測できる
  • 年間ロードマップを作る
    • 会社の戦略を顧客に簡単に説明できる
    • 会社に明確なビジョンができる
  • リリース日に関する重要な数値
    • PBの見積もり
    • Undone作業(DoDの外側の、デプロイに必要な作業)
    • 後発的な要求

PBI

  • PB→リスト自体のこと(一つ一つのことではない)
  • PBIがPBの項目
  • 例:〜〜の情報を管理できる=エピック
  • ストーリー=PBI
    • 登録できる/編集できるなどのアクション単位のイメージ
  • PBIを分解したタスク
      • 登録機能のAPI開発
      • フロントエンド開発

Velocityの測り方

  • タスクにSmall, Middle, Largeを定めているが、Velocityの測定方法としてどうか?
    • タスクレベルの見積もりは不要で、PBIのみが望ましい
    • Story Pointの方がいいか?
      • SMLをポイントに変換すれば良い
    • 3段階程度にしなければ破綻すると別の研修で習ったことがあるが、XS, XLも足して良い?
      • 問題ない、必要があれな足すべき
  • PBIに関して、一部の作業のせいで開発後半までDoneとできない場合はどうする?
    • チームとしてのDoneを決めて、Doneとしても問題ない
    • ただし、Undoneを定義する
      • チームのDoDとユーザーに提供するまでのGAP
      • これをバックログとして何SPか見積もっておく
      • リリーススプリントの作業はここに定義される

POが開発するのは問題か?

  • ミニマムなチームで回るのであれば問題ない
  • POの稼働もVelocityに数えてもいい

スプリントボードの注意信号

  • 目で見るフロー管理ツール

  • スプリントボード

  • SPプランニング時点で明確にアサインしない方が良い

    • スウォーミングができなくなる
    • 手の空いているメンバにアサインし直していくべき
  • スクラムボード

    • TO DO, DOING, DoneがあればOK
    • To Do
      • PB
      • Release Burndown Chart
    • Doing
      • Sprint Board(看板)
      • SP Goal
    • Done
      • Reviews
        • インクリメント
      • Velocity
        • 毎回のSPでどの程度のVelocityか
  • ex. Miro/Muralでスクラムボードをまとめる

バリューストリームマッピング

  • 制約理論と継続的なフロー

    • ビジネスチームの検討や投資審査がボトルネックになっている
    • 対応 → 審査単位を小さくする
  • 無駄な待ち時間を減らすには

    • PBIの最小化
  • スライド p209例

    • 開発開始まで6ヶ月待ち → 開発期間は3ヶ月というパターンが多い
    • プロダクト開発の高速化は、要員追加よりも、プロセスの改善で達成できることが多い
    • バリューストリームマッピングはボトルネック検出の優れたツール
    • スクラムはボトルネック除去に優れたツール
      • 落とし穴:局所最適化
      • 開発チームだけでスクラムをやっても効果が薄い
      • 関連チームまで含めたスクラムが必要

スプリントレビュー

  • インクリメントをステークホルダーにデモし、フィードバックを求め、バックログに反映する

    • スクラムチームはSPゴールとSPで作成したインクリメントについて、デモと話し合いを行う
    • ステークホルダーの反応とプロダクトのFBを収集することが重要な成果
  • インクリメント:最終的な成果物

    • 調査、研究や新しいプロセスも含む
    • 価値があるもの、検査できるもの
  • プロダクトインクリメント

    • SPゴールを達成した全てのPBIの総和
  • 完成の定義はプロダクトのインクリメントに対するコミットメント

  • SPレビューからの成果物

    • 出荷可能なプロダクトインクリメント
    • Velocity(完成したもの)
    • フィードバック
  • SPサマリーの参考 スライド p217

ストーリーに含まれないユーザーにとって価値のない作業はどう扱う?

  • PBIとして含めていい
    • 例:CI/CD Pipelineのような共通作業
    • チームがやるべき仕事は全てPBに入れるべき

スクラムマスターが置かれる状況と対策例

  • Case: チームの中の上級エンジニアの存在

    • 問題
      • 議論の全てを個人が支配している
      • 人的依存
      • 作業に取り掛かる際にまず相談
    • どのようにコーチできるか?
      • ルールで心理的安全性を作る
        • 自由に意見を出しやすい環境の整備
      • メンバの自立を促す
      • 作業に取り掛かる際にまず相談
        • -> SP計画 アーキテクチャを定めてしまい、曖昧さを残さない
  • Case: 繰り返される持ち越しバックログ

    • 根本原因
      • ❌SPの期間が短い?
      • チームはできると思っていたか?
      • 能力不足だった場合?
      • SP計画がうまくできていない
        • Velocityを把握できていない、バーンダウンを見ていない
    • SCMとしてどのようにチームを助けられるか?
      • 期間の変更をPOに提案
        • 納得感のある改善案とセットでなくてはだめ
      • レトロスペクティブ
        • KPT出し→障害物のバックログを設ける
      • PBIを小さくできないか?
      • 能力不足だった場合は?
        • ->見合ったものにする
      • Velocityをうまく把握させる
        • バーンダウンチャートを使う
      • 外部のテックリードに支援を仰ぐ
      • Velocity以上にできると言わない
      • レビュー以外のタイミングでいつでも見れるメトリクスを用意する?
        • バーンダウンチャートを見せる
  • Case: デイリースクラムの問題

    • やる気がない、気が散っている、状況報告以外話さない
    • 原因
      • スクラムボードをみんなで見る機会を設けていない?
      • 固定的なアサインがされている
        • デイリースクラムの目的が理解されていない
    • どのように助けられるか
      • まずは理由を聞く
        • 幸福指標を図る
      • 時間の見直し
        • 昼回にする?
        • 何かとかぶらない時間にする
      • スクラムボードやバーンダウンチャートを見るコーナーを設ける
  • Case: 孤立した専門職のチームメンバー

    • 起こりうるリスク
      • 人的依存によりタスクが滞留
    • 彼にアジャイルなマインドを少しでも理解してもらうために何ができるか?
      • アジャイル憲章を理解させる
      • 助け合いの空気感を出す
      • チームとしての成果を共有する
      • 弟子をつける

ベロシティを高める11の方法

  • 小さなチーム
  • Readyのバックログ
  • T字型の人

効果が高そうだが、適用が難しいプラクティスと対策

  • スウォーミング
    • 難しくしている要因
      • メンバのスキルが限定的
      • 割り込みが多い
    • 改善策
      • スキルアップ/育成
      • T字型メンバを一人は入れる→周りにも教えてもらう
      • 会議時間の効率化/短縮
      • スキルマップを作って計画的に育成していく
  • 俗人化の排除
    • 難しくしている要因
      • メンバのスキルが限定的
    • 改善策
      • 手順化 → 自動化(CFn/SAM Templateなど)
      • 一般的に使われていないフレームワークを避ける
      • 必要な技術スタックを減らす
        • フロントエンドエンジニアがいたら、バックエンドにNodejsを使うなど
  • 開発チーム以外も含めたスクラム的な進め方
    • 難しくしている要因
      • WF前提のルール
      • ステークホルダーの理解
      • 審査プロセス
    • 改善策
      • ステークホルダー(上位者)の理解
      • 実績と効果を見せる
      • お客さんがいない場で取り込んでいく
      • 投資対効果を見せていく
      • ステークホルダー/上位者向けに教育する
        • Scrum Inc研修にリーダークラスを入れる
        • アジャイルのマインドセットだけの研修をよく開催されている
      • アジャイルが適している理由が示せればいい
      • 承認を小さく通す
        • プロトタイプで承認を通す
        • PoCで年間いくらで通す

SCMやPOが倒れたら?

  • POサポートが一人入ることは多い(PBIをReadyにする等)

幹部に生産性を示せと言われたらどうする?

  • ROI 投資対効果を示す
    • インクリメントのビジネス価値
    • これだけの費用/労力でこれだけの価値を産みましたと話す
    • プロダクトの価値を判断するメトリクス/KPIを策定して示す
  • 価値説明はPOの責任
  • Velocityの変化率を示す

自分がPOでSCMが未熟な場合は?

  • SCMをコーチングして育成する。SCMには横の連携が重要

参考

関連記事

その他

EXIN Agile Scrum Foundation 合格体験記 [スクラムマスター資格]

Exin Agile Scrum Foundation 概要

  • EXIN社が提供しているアジャイル/スクラム開発に関する認定資格
  • 現役のスクラムマスターによる二日間の研修と資格試験がセットになっている
    • スクラム開発をマネジメントする中で、細かいレベルまで具体的にどうすべきか?が分かりとても有益であった
    • 他の参加者とワーク形式でストーリーマッピングや優先度付、分割、バックログ化といった流れも体験できる
      • 参加者は経験者と初級者が半々程度
    • 会社に受講料を出してもらえるなら、受講しておいて損は無い
  • 難易度
    • 元々アジャイル開発を学習/実践していた為、あまり難しさは感じなかった
    • 研修受講後にまともに学習をすればほぼ確実に合格する
  • 位置付け
    • スクラム開発に関する資格と言えば、認定スクラムマスターとスクラムマスター認定の2つが有名
    • 上記は結構難易度も高いと聞くので、この資格を先に取得してから挑戦すると良さそう
    • どちらかというと、これからスクラム開発を始める人や、良く分からず何となく進めてしまっている人向け
  • 試験はオンラインで受験可能

合格までの流れ

EXIN社研修を受講

  • 2日間リモート形式

    • Zoomのブレークアウトルームやmural(オンラインホワイトボード)を使用
    • muralは自社でのテレワーク時のワークにも使えそうであった
  • PDF教材をもらえる

  • ワーク形式で以下の工スクラム開発の工程を具体的に体験できた

    • ユーザーストーリー出し ⇒ 分割 ⇒ 優先度付け ⇒ プロダクトバックログ ⇒ スプリントプランニング ⇒ スプリントバックログ ⇒ スプリント ⇒ レトロスペクティブ(振り返り)
    • 優先度や重み付けの手法やDoD(完了の定義)など、具体的な手法を多く知れた
  • レトロスペクティブ(振り返り)のKPT出しは、どんなPJにも即取り入れられるものだと感じた

    • K: keep
      • 良かったこと、キープしたいこと
    • P: Problem
      • 問題/課題や心配事となっていること
    • T: Try
      • 次に改善したい、トライしたいこと
  • 現場経験豊富な講師が参加しており、質疑も多くできた

  • アジャイル開発の研修ではスプリントは412wと習ったが、スクラム開発では2
    4w程度が適するなど、スクラムの特徴も知ることができた

模擬試験/学習

  • 研修の最後に模擬試験を受ける

    • 一度目 25/39点 合格点25
      • アジャイル開発経験者が受講した直後の点数
    • 二度目 39/39
      • 間違えた問題と試験頻出事項の振り返りと、研修のノート全体の見直しを実施
      • 学習期間は1日
  • プライベートをあまり削らずに取れる、実用的でコスパの良い資格という感触

試験を予約

  • 試験はコロナの影響もあり、オンラインのみ

  • 研修初日の夜にメールでバウチャーコードが送られてくる

  • 必ず試験環境の動作チェックを実施する

    • カメラの性能が悪いPCだと受験できないこともあるので注意(会社のPCではダメだったので、自分のMacを使用)
      動作チェック

オンライン試験

  • 研修二日間の翌日に学習して受験
  • 試験監とオンラインで対面するのではなく、録画して、後に試験監がそれを確認する形式
    • なので、夜など好きな時間に受験できる
  • 部屋を一周撮影したり、受験前の作業で落ちたりなど、かなり面倒でUXは最悪であった
  • 試験中に部屋に人が入ると失格になる為、子供がいる方は注意が必要そう
  • モニターをつなげることも禁止されている
  • 難易度
    • 研修全体と模擬問題やポイントをまともに復習すれば問題なく解けるレベル
    • 日本語的に微妙な問題が多いので注意
  • 無事合格

合格後のステップアップ

上位の資格

英語が特別得意でない人は、LSMかCSMを取るイメージ

書籍

研修で現役のスクラムマスターがおすすめしていた書籍は以下

参考

関連記事

@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×