認定スクラムマスターへの道
Odd-e主催の認定スクラムマスター研修に参加しました。
認定スクラムマスター（CertifiedScrumMaster®）とは？
スクラムとは？
スクラム開発とはアジャイル開発の手法の一つです。多くの方がイメージする「5人から１０人程度のチームで毎日フェイス・トゥ・フェイスでミーティングを行って、進捗成果の確認をするアジャイル開発手法」とまとめることもできそうです。
スクラムがウォーターフォール型のシステム開発と異なる点は、開始時点で全要件が確定されていなくても進められる、という点と、コンポーネントチームで分業せず、クロスファンクショナルなフィーチャーチームが小さいプロダクトを逐次開発していくことが挙げられます。適応的に二週間から一か月ごとに開発期間を区切り、区切り事に開発し、区切りが終わった時点で、テスト済みの動くソフトウェアで成果を確認していくため、随時の要件変更に対応しやすいためです。区切りのことはスプリントと呼びます。
随時の要件変更に対応できる状態になることで、待ちや無駄や遅れを避け、敏捷に機能の作り込みができる点が、スクラム開発（アジャイル開発）の最大のメリットです。
スクラムマスターとは？
スクラム開発を行うスクラムチームの構成員には、
三つのポジションがあります。
一つ目はチーム。スクラム開発を担うメンバー全体を指します。5人から9人で構成されるのが望ましい、と言われています。
二つ目がプロダクトオーナー。
プロダクト（製品）の最終決定権を持ち、同時にプロダクトに対しての責任も担う人のことを言います。優先順位付けやスケジュールの管理、市場で事例を含めてプロダクトについて把握している立場になります。
三つ目がスクラムマスター。スクラムを理解した上で、スクラムの進め方が出来ているか管理し、円滑に進めて行く役割を担っています。つまり、チームで協力した開発が出来ているかを管理します。
スクラムチーム（ソフトウェア開発チーム）の全体が、スクラムとは何かを理解した上で開発を行っているかチェックします。その上で、チームが協力しやすい環境にあるか確認しながら、サポートする役割を担当します。
直接、スクラム開発の進捗を管理しませんが、文字通りスクラム開発に精通したプロフェッショナルとして助言を与えるなど、スクラム開発が滞りなく進むように支援するのがミッションとなります。
スクラムマスターになるのに資格は必要ありませんが、スクラムマスターの知識を持っていることにお墨付きしてくれる資格があり、それが認定スクラムマスターと呼ばれています。
今回は、認定をする団体のひとつであるScrum AllianceのCertified Scrum Master® を取得しました。
どんな研修？
Scrum Alliance®認定スクラムトレーナー（Certified Scrum Trainer®：CST®）による「 スクラム をプロダクト開発の仮説検証のフレームワークとして活用する」ための研修・トレーニングです。
本研修・トレーニング中に能力を評価されたら、認定スクラムトレーナーCertified Scrum Trainer®:CST®によってScrumAlliance®に登録されます。
対象者
スクラム を始められたいまたは興味があるビジネスリーダー、プロジェクト推進者、マネージャー、メンバーまたはそれに該当する役割の方 となっています。
なお
注意
学習意識が低い方、研修・トレーニング内容をご自身の環境で活かそうと考えていない方のご参加はご遠慮ください。
スクラムを知識として体系的に学習したい方は、本研修・トレーニングはご遠慮いただき、スクラムの概要研修・トレーニングをご相談ください。
とあるように、お金で資格を買う 研修ではなく、実践者にスクラムを植え付けるトレーニングとなります。
研修・トレーニング内容の構成
1日目〜2日目
スクラム の概念、背景、各役割、経験に基づくプロセス制御、 スクラム と他の新製品開発手法との違いについて学びます。
3日目〜5日目
実践的なケーススタディ。現場で スクラム を行う上で必要となる具体的な知識と理解を深めます。
なにを学んだ？
体系的に全てのスクラム要素を網羅する講義はありません。講義の前に予習として、アジャイルソフトウェア開発宣言（マニフェスト）、アジャイル宣言の背後にある１２の原則、スクラムリファレンスカード、スクラムガイドを熟読を命じられ、またトレーナーの方から、２４のアセスメントが与えられ、スクラムに対する自分の考え方を述べるように命じられます。
その自分の考え方をもとに、スクラムの考え方との差異を確認し、スクラムのスタンダードを植え付けていくようなスタイルとなります。
以下、メモポイント
「スクラムがうまく導入できない」はおかしい
スクラムは手段であり目的ではないから、スクラム導入が先にくるのは間違っている。
スクラムをやりなさいという指示で始めることはしない。
スクラム的なやりかたとして、要素をつまみ食いするという運用をする場合は、反作用副作用を理解して使う必要があるだろう。
試作品を作ることは重要
主導権争いをしないこと（MBA卒業生より幼稚園児がいい結果を残した）
経験的に学んできたことが仇になる、邪魔されていることが多い
アジャイルとは状態
振り返った時にアジャイルだったとは言えますが、アジャイルを行うとは言えない。
スクラムは１００％反復的ではないし１００％インクリメンタルでもない
インクリメンタルに反復的
竜巻のようなもので表現されることがおおい
Empirical
科学の実験で、起こったものを観察することを通じて、次の行動をする。
スプリントレビューでテストされた動くソフトウェアで検証することがEmpirical。
従来型手法が無駄な話
生産性が人の努力に水を指している。
誰が悪いのかを見つけることが、力を出すもとにはならない。
失敗所在を明確にして責任を明確にすることで、失敗する。
評価することにエネルギーを使うことで、他に使うエネルギーが減る。
それはリスクである。
構造や進行やシステムが複雑になる。その明確さや正確さを目指すあまり、すべての進行を止めてしまう。
人格を攻撃することで非効率に不平等をもたらす
結果、４０〜８０％の時間を無駄にしてる
アジャイルが不要なケース
アジャイルのしごとは成果とプロセスが明確な場合には必要ない。
なにが必要でどう作ればいいのか明確でない場合に有効。
不確実なことが増えている場合に、計画的にすすめることは害をなす可能性がある。
計画どおりすすめる場合には向かないアプローチ。
学習が知識創造における唯一の制約条件
ソフトウェア開発するときに重要視すべきはタイピング速度ではない。
いかに学習を早くしていくか（学習というのは経験の獲得）。
スクラム・アジャイルは雑なウォーターフォールではない
計画できないウォーターフォールは計画をまずすべき
スクラムはプロジェクト管理方法論ではない
プロジェクトとは有期的な活動
スクラムは継続したインテグレーション
マネージャー（≠スクラムマスター）の役割
数値管理ではなく、
ものづくりする組織全体の能力向上がマネージャーの役割
そこは組織全体をかえていく場が必要
組織のマネージャーもレトロスペクティブに参加する
組織の変革が可能な人を巻き込み変えていくこと。
必ず、スプリント内で出荷可能なproductを作り続ける
１００人規模の１productを２週間でつくって出荷可能にするのは難しい
いろんな原因があるが、大きい要素は組織の構造
他のチームに依存して、出荷可能なものを作れない、というケース。
組織課題としてあつかっていく必要ありそう
→チームにも考えてもらい、組織のマネージャーと議論してもらいたい
プロダクトバックログ
productに対してひとつ
productに関してPOが優先順位管理する
productのアイデアが入っている
開発チーム、ステークホルダー、ユーザーと一緒に話ができるものが好ましい。
できる限りユーザー視点で書かれたものとすることが好ましい。
プロダクトバックログアイテム（ユーザーストーリー）
ユーザーストーリーは将来の会話を約束することである。
◯◯として□□ができる。なぜなら・・・
あるいは、失敗するテストの書き方をする。
→受け入れ条件がかかれている。
仕様を渡すことではない。
カードで状況が伝わるようにすべき、会話をするきっかけである。
理想的な組織はビジネスと開発がわかれていない組織
ビジネス上の課題を解決するために働いているから。
実現するために、ビジネスを知っている人を開発の人と一緒に働いてもらう
問題を解決するためのいちばんの解決策は、組織構造
ユーザーストーリーを書くかわりに Specification By Example の手法で書いていくことができる
仕様をかいて、副産物としてテストができる
嘘をつかない仕様書ができあがっていく
実証的に見えるものとして書いていける
ユーザーと話せる共通の言葉を使って、本来の目的を理解してすすめることができる。
ユーザー視点で書いていくことが好ましい。
スクラムはDoneを重要視している
テストまで完了したことがDone
テストは自動テストであるべき、そうでないとテストのコストが上がり続ける
キャプチャテストツールはおすすめはしない
重厚長大な問題がスプリントで発覚したとき
スプリントゴールをPOとSMが相談して、他の方法でゴールにできないかをスプリントで検討する
どのようにバックログアイテムを小さくしていくのか
アクティビティ
縦斬り 横切り
何に対して最適化すべきかによって変わる
顧客のニーズをより確かなものとしてより速く知る
多くの仮説は自信過剰
謙虚にユーザーが本当にほしいものを知らない
ユーザーが本当にほしいものを知らない
リーン・スタートアップ
顧客のニーズを小さい単位で検証していく
ザッポスの仮説
人はオンラインで靴を買うのか？→人は返品無料であれば買う
従来 オンラインストア、ロジスティクス、決済を構築 ※
靴の写真をとって靴を買いに行って配達する ※失うものは少ない
制約
建設や製造業の物理的制約とは違い、
ソフトウェア開発には制約は少ないはず
制約なり得るもの
・スキル・知識
・ポリシー（責任・役割・ルール）
→本当に依存関係があるのかを疑う（思い込みをなくす）
→チームが学習するチームになっていく
POの役割
大企業では誤解されがち
スクラムマスターがチームの生産性向上をバックアップ
プロダクトオーナーに意思決定権限がある。
役割はデリバリーに専念することではない。
デリバリーに専念すると、チームアウトプットオーナーになってしまう
プロダクトオーナーから全体に関する決定権限を取り去ったものが
チームアウトプットオーナーで、チームバックログの管理者と成り下がる
チーム間の調整
１ ただ話す
２ コードでのコミュニ―ション
３ オブザーバーをデイリースクラムに送り込む
４ コンポーネントのコミュニティとメンター
５ スクラム・オブ・スクラム
６ 複数チームのミーティング
７ トラベラーを活用してボトルネックを解消し、スキルを伸ばす
８ リーディングチーム
自己管理を阻む３つの要素（意図せずに）
・全員が努力しているのに、非協力的な状態の人がいる フリーライダー
・悲観的な振る舞いをずっとし続けている ダウナー
・個人的なことに口を出して失礼な態度を取る人 ジャーク
Doneできないチーム
Doneできないチームの問題はすべて組織の問題
スクラムを変えるのではなく、組織を変える
組織の課題を解決するより、組織変革
複数チーム 複数会社でのスクラム
あまりうまくいかないことが多い
複数の契約形態・ポリシー
契約がコンポーネント毎になってしまう
プロダクトバックログの優先順にならない
「ただ話す」ができない、ゲートが生まれてしまう
回避策：IFを明確にして境界線をつくる
スクラムマスターの評価
いままでの概念にない役割
既存の組織の中で評価軸が定まらない
チームのファシリテーション面だけであれば評価は難しいが
SMの役割として「組織変革」があり、それが見えやすくなる
よろしければサポートお願いします！