スクラムマスターがいるチームで学んだスクラム開発のこと
スクラムマスターがいるスクラムチームで開発している
この2ヶ月間、スクラムマスターがいるスクラムチームで開発しています。私のキャリア上、スクラムマスターがいるスクラムチームで開発をするのは初めてです。
アジャイル で Web アプリケーションを開発した経験は4年ほどあり、前職ではアジャイルに詳しいテックリードと同じチームで開発したり、スクラムに詳しいがスクラムマスターではない先輩エンジニアと Do Agile ではなく Be Agile な開発ができていたと思っています。
そのおかげで、アジャイル開発に対する知識や経験が溜まっていきました。それはスコープ・納期・予算・品質といった荒ぶる四天王とそのトレードオフスライダーやストーリーポイントや見積もりや、チームでの開発に対する心構えなどです。これは今でも役に立っているスキルです。
しかし、スクラムマスターのいるスクラムはやはりしっかりしていると思ったこと、スクラムというフレームワークの有用性を肌身に感じているので、所感レベルではあるものの記事に書き記しておきます。
スクラムマスターのいるスクラムがしっかりしている
スクラムマスターのいるスクラムがしっかりしていることとは、スクラムマスターが「スクラムの原則を徹底している」ことと「目の前の現象をスクラムの原則から捉え直す」ことを指しています。
まず、チームが結成されたときにスクラムガイド 2020年版を読み合わせしました。チームメンバーは、エンジニアリングマネージャー（EM。スクラムマスター）1人、プロダクトオーナー（PO）1人、バックエンドエンジニア4人、フロントエンドエンジニア2人の8人構成で、私はフロントエンドエンジニアとして所属しています。
なお、現職の会社ではスクラムマスターという役職はないものの、エンジニアリングマネージャーが認定スクラムマスターの資格を保有しているため、チームのエンジニアと週1で1on1をしながらスクラムマスターとして開発の計画会でファシリテート（司会進行）してくれています。
スクラムの原則を徹底している
さて、スクラムマスターが「スクラムの原則を徹底している」とは、スクラムイベントを省略せずに行っているということです。これは当たり前のようでいて中々実践できるものではないと思います。なぜなら、「スクラムは会議が多い」という現場からの圧力で何かのスクラムイベントを省略するケースがあると聞いたことがあるからです。
スクラムイベントは省かない
自分が所属しているチームでもスクラム開発をしていこうと意気込んだものの、2,3週間が経った頃に「会議が多いのでは」という声がエンジニアから挙がりました。しかし、スクラムマスターは「これは情報が集まりきっておらず、次のアクションに必要なことが決まっていないから」とメンバーを説得し、スクラムイベントを省略しない判断をしました。
後からわかったことなのですが、会議が多いとエンジニアが感じたのは、開発のフェーズから考えると仕方がないことでした。社内のあるチームが使う社内用ツールに対する新機能の開発でチームが組成されたものの、2ヶ月前は要求も仕様も固まっていませんでした。
社内のチームにPOがヒアリングをしていた段階だったこと既存機能をベースにした改修だったため、既存機能の DB やバッチ処理周りの調査がメインであり、コードを書いて手を動かせない状況だったため、エンジニアが「会議が多く先に進んでいない」と感じてしまっていたのです。
その後大まかな仕様が固まり、実際にコードを書き始めると「やっぱり必要なことを話し合っている」という意識が醸成され、会議が多いという意見は挙がらなくなりました。
デイリースクラムは15分
また、スクラム開発を始めて1ヶ月経った頃、デイリースクラム（デイリースタンドアップ、朝会）が短すぎて話が終わらないという意見が挙がりました。デイリースクラムは15分と設定されていたからです。
自分が今まで所属していたチームでは、朝会を昼休み前に行って好きなだけ話すというケースや、作業内容と進捗の共有だけを手短に終わらせて、個別で相談・議論が必要な場合は「〇〇さん、このちょっと後いいですか？」と声を掛けるケースを経験していました。
それに比べると、デイリースクラムは全員で参加して15分で終わり、全員が話題を知っていることを良しとするためデイリー後に個別で話し合うこともしていませんでした。それでは確かに全員が作業の進捗を共有してスプリントのゴールの障害の有無を確認すると議論の時間がなくなります。
自分も「それなら時間を延長して30分の枠を確保したらいいのではないか」と話したのですが、スクラムマスターによるとエッセンシャルスクラムという本がデイリースクラムを説明している箇所では15分以内とされているので、24ページ目を参照して欲しいとのことでした。
エッセンシャルスクラムはチームの希望者全員に配布されています。自分も該当のページを参照したところ、確かに15分以内で行うとの記述がありました。さらに、「デイリースクラムは検査と適応の場であるため、問題解決のアクティビティではない」ともあります。結局、スクラムマスターから「デイリーは15分で終えるが、その後の15分を議論や雑談の時間に使おう」という提案があり、今ではその形に落ち着いています。
この一連の出来事を通して、プラクティスを徹底するとはこういうことなんだと理解が深まりました。スクラムに限らず重いプラクティスをアレンジするということはままあると思うのですが、デイリーのように一見軽いものに見えてもスクラムの原則を徹底するという姿勢こそが、ただの肩書きではなくスクラムマスターをスクラムマスターたらしめるものだなと思いました。
目の前の現象をスクラムの原則から捉え直す
もう一つ、「目の前の現象をスクラムの原則から捉え直す」こともスクラムマスターは行っています。エッセンシャルスクラムやスクラムガイドは聖書ではありません。しかし、開発の際に起きる事象がそこに既に書かれていることが多いです。
これはスクラムに限ったことではありませんが、目の前にある個別具体的な事象を理論や原則の視点から捉え直すことで、その事象の構造や背景、問題が起きるところと解決できる道筋が見えてくることがあります。
コーディングを例に挙げると、AとBはXの関係にあるからここではZパターンが適用できるというようなケースです。Zパターンを知らなければ自分でそのパターンを発見するかZパターンに永遠に気づかないままです。そして、これがエンジニアの自主学習による知識の獲得や新人エンジニアに対する教育が奨励される理由です。
同じものを見ていても、知っている人と知らない人では捉え方が異なります。POやエンジニアの質問に対してスクラムマスターが Slack で回答しているところを見ると、「それについてスクラムでは以下のように考えます。A、B、C。よければエッセンシャルスクラムのXページを参照してみてください」というパターンだなと気付きました。
これは簡単なように見えて、開発のアクティビティをスクラムの視点から考えようと常日頃から思っていないと実践できないと思います。調査する（学ぶ）コストは大きいため、人は自分なりの解釈、判断に従いがちだからです。孔子の言うように「思いて学ばざれば則ち殆（あやう）し」ですね。
例えば、メンバーから「ベロシティの考え方がいまいちわからない。ストーリポイントでアイテムの大きさを見積もり、過去のベロシティと同じくらいになるようにスプリントでアイテムを選ぶことはわかるが、選んだアイテムをスプリント内で全て消化しなければならないと思ってしまう」という発言がありました。
それに対してスクラムマスターは、「ベロシティは過去の参考値だから絶対に達成しなければならないものではない。チームの状況を知る体温のようなものです。勤務時間は週に40時間が一番パフォーマンスがいいという研究もありますし、毎日遅くまで働きすぎると持続可能性がなくなります。エッセンシャルスクラムのXページを参照」と回答していました。
（正直、この節タイトルに対する例の内容が合ってない気がしていますので、そのうちいい例があったら書き換えます。ここでは「メンバーがある現象が起きていると話したら、スクラムマスターがそれはスクラムではこういう名前がついていますと回答した」という例が適切ですね）
私見を述べると、ベロシティの例えは山登りの例が一番わかりやすいかなと思います。それは以下のようなストーリーです。
バックログアイテムは優先順位通り（登山ルートに沿って）に並んだ地図上のチェックポイントです。平均2スプリントではA地点まで登れました。同じように考えると、同じ距離を次のスプリントでも登ることができます。
しかし、山の天候は変わりやすいです。雨が降って道がぬかるむかもしれないし、霧が出て視界が悪くなるかもしれません。地図になかった川が出てきたり、安全（セキュリティ）のために今までになかった谷沿いの道をゆっくり慎重に進まなければならないこともあります。
先のことは誰にもわからないため、実際に進むしかありません（経験主義）。このため、ベロシティはあくまで参考値なのですと。まあ例なので伝わればなんでもいいのですが、自分ではなかなか良い例えなのではないかと思います。XPのプラクティスの「メタファー」ですね。
スクラム開発に対する所感
さて、次に2ヶ月ほどスクラム開発をした所感を紹介していきます。
スクラム開発のキモはスプリントレビュー
スクラムイベントの一つに、スプリントレビューというものがあります。自分が所属するチームでは、このスプリントレビューで社内のチームのメンバーに対するユーザーインタビューを行なっています。
具体的には、POが機能を使うシナリオを予め考え、社内チームのメンバーにそのシナリオに沿ってその機能を使ってもらい、フィードバックを貰います。スプリントレビューでは、社内チームのメンバーが画面を操作する様子を Zoom で共有してもらい、会話で出た内容と開発メンバーが画面操作を見ながら気づいたポイントを議事録に書いてきます。これを毎週行います。
社内メンバーに対するプロトタイプのレビューでありながらも、できるだけバグを出さないように事前チェックをしたり、片付いてないアイテムを終えなければならないという心理的なプレッシャーが毎回かかります。それでもレビューは収穫が多いです。
その機能を使う社内のチームにとっては、初期リリースでは最低限ここまで欲しいという要望がすぐに出せること、ある機能が欲しいと思っても開発の観点からは求めすぎているのか、或いは簡単に実現できるのか、動くソフトウェアという実物を見ながら期待値の擦り合わせができることがメリットです。
また、プロダクトオーナーにとっては、「おそらくこのチームはこの機能をこのように使うだろう」という推測ではなく、現実に使って貰う姿を見ることで、頭の中で生まれた現実には起こり得ないケースに対する対処を省けたり、そのチームの興味関心がどこにあるのかリアルに把握できます。
さらに、エンジニアにとっては、新機能を使って貰える人の顔が見えることと、操作に困っていそうなら画面や表示するメッセージを改善しなければと自発的に考えることなど、同じチームメンバーに閉じていては得られない情報が山ほどあります。
しかも、ソフトウェアエンジニアにとってはユーザーの喜ぶ姿を見ることが一番のモチベーションにつながる（「顧客の満足度向上が仕事に対するモチベーションを向上に繋がる」という章を参照）こと、レビュー会はそのような場になっていることから、難しい判断を迫られることがあっても開発チームのメンバーのモチベーションは高いままでいられます。
そして何より、両チームともにこの機能に関して何かあっても隠したり躊躇ったり責めたり文句を言うのではなく、すぐに連絡し合って問題の解決に向かうという信頼感が醸成されていると私は感じています。
アジャイルソフトウェア開発宣言が重視する「個人と対話」「動くソフトウェア」「顧客との協調」（認識合わせや擦り合わせ）「変化への対応」（フィードバックに対する新しい対応）の全てがレビュー会に凝縮されています。スプリントレビューがスクラムイベントにビルトインされていることで、スクラムに従えばしっかりアジャイルを体現できるのだと再認識させられます。
スクラムは軽量フレームワークである
もう一つスクラムに対して理解が深まったことがあります。それはスクラムガイドに書かれているように、スクラムは軽量フレームワークであるということです。
個人的にアジャイルといえば XP （エクストリームプログラミング 2nd Edition）が好きで、またLeanとDevOpsの科学を読んでから DevOps のプラクティスを実践していきたいと考えていました。結論から書くと、スクラムはこれらを実践することに何の妨げもありません。
チームで実施している XP と DevOps のプラクティス
まず、XP と DevOps で実践しているプラクティスを紹介します。
今のチームではエンジニアが合計6名います。このため、ペア・モブプロで開発をしたいと提案し、また私が Software Design に TDD を実践する特集を寄稿したことから（寄稿の経緯）、チームのバックエンドエンジニアから TDD を実際にやってみたいという話があがったので、ペアプロで TDD をしつつ開発しています。XPのプラクティスですね。
ツールは Gather というオンラインミーティングのツールと、 PhpStorm の Code With Me を使って開発しています。昼休憩やデイリー、1on1 がある時以外はずっとみんな Gather にログインしており、常にどこかでペアプロがされています。
開発が進むにつれて、テストケースも順調に増えていっています。
もちろん CI でテストを実行しており、リグレッションにすぐ気づけるようにしています。
また、LeanとDevOpsの科学で紹介されているトランクベース開発を実践しています。まだリリース前の機能なのでリリーストグルではなくダークローンチという手法を使っていますが、おそらくブランチを切ってコードの変更をコミットしてから PR のデプロイまでにかかる時間は最短1時間、平均1日半、長くても2日半ほどかと思います。
午後の初めに書いたコードが、夕方にはレビューが終わってデプロイされるというようなスピード感です。これには Gather 上での同期レビューと、レビューの指摘はリファクタリングとして別ブランチで対応するテクニックが功奏してます。後日、ちゃんと計測してグラフ化しようと思っています。
スクラムは開発プラクティスを阻害しない
さて、スクラムが XP や DevOps のプラクティスとバッティングしない軽量フレームワークであるということは、スクラムイベント以外はそのプラクティスに集中できるということです。
具体的には、現在チームではスプリントの期間を1週間とし、毎週火曜日にスプリントレビューとスプリントレトロスペクティブを行なっており、水曜日にバックログアイテムのリファインメントとスプリントプランニングを実施しています。ここで達成したことを見てもらい、やったことを振り返り、これからやること洗い出してストーリーポイントをつけて優先順位を決めます。
すると、残りの木、金、月は開発に集中できます。XP や DevOps の開発寄りのプラクティス（DevOps はスクラムなどアジャイルな開発プロセスと組み合わせることを良しとしている）はこの日に実行すればよいのです。
これがスクラムは軽量であるという理由です。実際、スクラムガイドでも以下のように書かれています。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
まとめ
先日スクラムマスターが言ってくれた言葉が嬉しかったので以下のツイートをしました。
そして、このツイートに反響があったのでこの記事を書くことにしました。
アジャイルの開発は不確実性に対応するだけではなく、不確実なことから手をつけ始めるので、未来を引き寄せているイメージがあります。その分、情報集めと判断の連続で大変なんですけど、チームでやってるからめげずに進められるのです。
この記事で少しでもスクラム開発の雰囲気が伝われば幸いです。
Happy Coding 🎉
