電通デジタル開発部から新たに2人が認定スクラムマスターになりました
こんにちは！電通デジタル開発部のリチャードです。このたび弊社開発部から私を含む2人が以下の研修・およびその後の試験を受け、Scrum Alliance認定スクラムマスター(CSM: Certified Scrum Master)になりました。
20人ほどの組織である弊社開発部には、Scrum Inc.から認定されたスクラムマスターが以前から1人いるので、スクラムマスター有資格者は合計で3人となりました。
個人的には「スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介」という記事を私が書いた時に感じた、
「断片的な知識や経験で乗り切るのではなく、基礎からしっかりとスクラムを学び直したい！」
という希望をScrum Alliance公式の研修と認定という形でかなえられたので、大変うれしく思っています。
研修内容紹介
冒頭でリンクを貼った株式会社アトラクタのウェブサイトにも記載がありますが、3日間の研修日程は以下の通りでした。
- 6月14日(月) 14:00-18:00
- 6月15日(火) 10:00-18:00
- 6月16日(水) 10:00-13:00
研修を主に担当されたのは原田 騎郎(はらだ きろう)さんです。また吉羽龍太郎(よしば りゅうたろう)さん、永瀬 美穂(ながせ みほ)さんも研修に同席され、チャットツール上での補足説明や参考資料の共有、参加者からの質問に答えるなどサポート役に従事されていました。
原田さん、吉羽さん、永瀬さんは冒頭で紹介した記事「スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介」で紹介した下記の書籍の執筆・翻訳を担当されています。
SCRUM BOOT CAMP THE BOOK
西村 直人 著、永瀬 美穂 著、吉羽 龍太郎 著、翔泳社
みんなでアジャイル
Matt LeMay 著、吉羽 龍太郎 訳、永瀬 美穂 訳、原田 騎郎 訳、有野 雅士 訳、オライリー・ジャパン
プロダクトマネジメント
Melissa Perri 著、吉羽 龍太郎 訳、オライリー・ジャパン
研修には伝統ある大企業やスタートアップなど、幅広い所属会社から集まった20人ほどが参加し3チームに分かれて取り組みました。講義形式よりもチームで行う作業が多くの時間を占め、特に2日目はスプリントを2周回すことにほとんどの時間が費やされました。研修ではソースコードは書かず、簡易な描画ツールでアプリケーションのモックアップを作ったのですが、各種スプリントイベントをこなし、その講評も含めるとスプリント2周がやっとという時間配分でした。
主体的に作業や議論に取り組む時間が長く、その分スプリント自体のやり方をあまり説明されなかったので、研修当初私はだいぶ戸惑っていました。しかし終盤にはそういった進め方の意図も十分に説明を受け「習うより慣れろ」という方針なのだと理解しましたし、最終的にはたくさんのことを学べた爽快感が残る研修でした。
認定試験
研修後の認定試験は簡単だったように思います。全問正解は難しいものの、研修にしっかり参加してスクラムガイド読んでいれば解ける問題ばかりです。
研修を受けての学び
ここからは私が個人的に研修で得た学びの紹介です。研修を受ける前に私がスクラムに対して持っていた誤解がいくつかあるので、それがどう解消されたかという形で紹介します。スクラムに対して研修前の私と同じような印象を持っている方もいると思うので、そういった方の参考になれば幸いです。
誤解その1:「スクラムは開発を速くする方法」→「スクラムは遅い」
スクラムはアジャイル開発の中に位置づけられるので「アジャイル = 速い」開発だと捉えられがちです。しかし、講師の原田さんは研修中2、3度「スクラム開発は遅くなる」と言及していました。
ここで誤解を招かないよう「遅い」の意味を明確にする必要があります。スクラムでは頻繁で同期的なコミュニケーションが必要で、そのため特に慣れないうちはスプリントごとの進捗が小さくなる、というのが「遅い」の意味です。
この意味を理解するためには、まずはスプリントレビューの目的を把握する必要があります。
スプリントレビュー: スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対す
る進捗について話し合う。 - スクラムガイド 2020年版
スプリントレビューでは検査可能であることが重要視され、そもそもちゃんと動かない、動作が遅すぎて検証に耐えない、動いても要件の充足が判別できない、といった状態だとレビューが成り立ちません。
検査可能な状態を壊す最大の要因のひとつは統合(インテグレーション)の失敗です。現代のソフトウェア開発ではCI(Continuous Integration)によって統合の失敗を軽減できますが、ここでいう失敗はCIで検出できるソフトウェアのビルドエラーだけではありません。
- 議論の不足による要求の誤解
- 各メンバー間の解釈の齟齬
- スプリント最中に判明する事実の共有が遅延
といった原因で起こる、
- 要求を誤解したまま作り上げてしまう
- 意図した動作をしない
- 全体をつなげるとランタイムエラーが発生
などの失敗を含みます。これらは全員で頻繁に同期的コミュニケーションを行えば避けやすくなります。
研修の中でこの同期的コミュニケーションの大切さを実感する場面がありました。簡易な描画ツールを使ってアプリケーションのモックアップを作る際、2人で同時に編集するとあっという間にモックアップは配置がずれて壊れてしまったのです。たった2人で同じ画面を見ながら作業してもこうなったので、実際の開発の現場でひとりひとりが非同期に別々の作業をすれば、統合が失敗する可能性が格段に上がることは容易に想像できます。
スプリントごとの進捗という分かりやすい「速さ」だけを求めるのではなく、統合の失敗を避ける、間違ったものを作りそうになったら早く気づく、といった開発全体を見渡した時の「機敏さ」を重視するという意味で、スクラムはアジャイル開発らしいと言えます。
誤解その2:「スクラムは20年前から変化がなく、クラウド・ネイティブなど近年の技術的な発展を全然加味していない」→「近年の技術的な発展にキャッチアップするのは重要だが、それはスクラム外の関心ごと」
スクラムが誕生した20年ほど前と比べると、ソフトウェア開発のやり方はだいぶ変わりました。さまざまなクラウド・サービスや無数のOSSから取捨選択してソフトウェアを構成するのが当たり前になり、技術は細分化して進化のスピードも速くなっています。
すべての技術トレンドをむやみに追う必要はありませんが、技術的なキャッチアップに失敗すると利用中のライブラリやインフラ構成が何世代か前のまま固定され、開発速度の低下やセキュリティ・リスクの放置などにつながります。
技術の進歩が速くなった一方でスクラムの方法論は20年前から大きく変わっていないので、研修前に私は「技術の進歩に合わせてスクラムの方法論も変わるべきではないか？」と感じていました。
これについては、そもそも研修前の自分の前提が間違っていました。技術的なキャッチアップは当然重要ですが、それはスクラムのフレームワークの中で定義するものではありません。進化のスピードが速く細分化した技術に対して、どのような方法でキャッチアップするかまでスクラムの中で定義してしまうとフレームワークが巨大化しますし、陳腐化しやすくもなります。
スクラムのフレームワークに習熟するだけでソフトウェア開発の全てがうまくいくわけではありません。技術的なキャッチアップはそれぞれの開発の現場で自分たちに合った方法を見つけ出していく必要があります。
誤解その3:「バックログに入れるのはユーザーストーリーだけ」→「リファクタリングやセキュリティ対応もバックログに積んでいい」
アジャイル開発においては要求をユーザーストーリー形式、「『ユーザーペルソナ』は、〇〇のため、△△を実行したい」というように記述することが多く、スクラムも例外ではありません。
スクラム関連の本を読むと、ほとんどがユーザーストーリー形式になっているバックログ・アイテムにのみ言及しており、また「バックログに入れるのはユーザーストーリーのみである」と強固に主張する人々もいるため、それが正しいスクラムなのだと私は勘違いしていました。
「バックログに入れるのはユーザーストーリーのみである」がもし正しいのだとすると、
- リファクタリング
- 依存ライブラリのバージョン更新
といった開発者視点のバックログ・アイテムは「開発者としてソフトウェアの内部品質を向上させるため、リファクタリングを行いたい」のような、むりやり開発者をユーザーペルソナにした意味不明な記述になります。
もちろんこれは正しいユーザーストーリーではありません。研修の中では原田さんから明確に「必ずしもバックログ・アイテムはユーザー・ストーリー形式のものだけではない。」「普段からユーザーの期待に応える開発ができていれば、リファクタリングなど開発者視点のバックログ・アイテムも抵抗なくステークホルダーに受け入れてもらえるようになる」といった話がありました。
研修を終えた所感
以上のように研修前の誤解も解消でき、大きな不満はなかった研修ですが、あえて1点あげるとすれば、研修の中では旧来型の硬直的なプロジェクトとの対比でスクラムが語られることが多く、スクラム導入初期の課題に集中した内容になっていた点です。
個人的にはもう一段階進んで、スクラムが根づきつつある開発現場での問題をたくさん議論したかったのですが、それは今後自分自身が研鑚を積んでいくことなのだと思っています。研修後は今回の参加者も含めたスクラムマスターのコミュニティとのつながりを作っていただいたので、 そこで話し合う機会はありそうです。
まとめ
1人だけでは学べないこと、自社内だけでは得られなかったであろう知見が多く得られた研修でした。現在ではスクラム関連の書籍は多数出版されていますし、書籍以外の情報源も大変充実しています。それでもスクラム実践者である講師陣の方々との対話や、同じ悩みを持つ他の参加者との共同作業はたくさんの刺激をもたらしてくれました。
スクラムに対する誤解をいくつも解消でき、また自分の理解が以前から正しかった部分についてもより自信を持てるようになりました。
弊社開発部は3人のスクラムマスターがいる体制になったので、今後はよりスクラム習熟度を上げて開発に邁進できると思います。