こんにちは。株式会社ABEJA でスクラムマスターをしている小川です。本記事はABEJAアドベントカレンダー2022の7日目の記事です！
私は前職も含めると5年ほどスクラムでの開発を開発者として経験してきました。今のチームでは２ヶ月前にスクラムマスターとしてスクラムの導入から携わっております。
スクラムマスターとしてはまだ駆け出しの私ですが、自分なりに導入にあたってケアしてきたことや、スクラムのTips、よく聞かれること等々をご紹介したいと思います！
目次
ユーザ価値ドリブンでスプリント単位*1に複数のバリューの開発スコープを定義して、きちんと完成の定義までやりきるというスクラムの基本に則って開発を進めてきました。その結果、それまでの成果を大きく上回る結果を出すことができたのです！ 開発にかける稼働自体はそれまでと変わらないのですが、システム的には小さな影響でもユーザ価値に直結する成果物をJust In Time にリリースするという進め方を徹底しました。 継続的にValue を創出する体制になったことで、私を含めチームメンバーのモチベーションにも大きく影響しています！ 柔軟性とスピード感は大事にしつつ、イベントドリブンとエンジニア的感性で開発をこなしていました。 当時のチーム内の意見を総合すると以下の課題がありました。
スクラム導入効果
スクラム導入前の課題
上記の課題は解消させつつ、自分達が大切にしている柔軟性とスピード感は維持/向上したい！というチームの想いを叶えるべくスクラムを導入して、6.2倍の成果を出す体制をチームで作ったのです！
スクラム導入において意識していること
私がスクラムマスターとして導入初期フェーズの今、特に注力していることをご紹介します。
前職での経験や失敗も活かして自分なりに２周目のスクラム人生をより良くしようとしています！
1. チーム文化の形成
スクラムはチームの文化を作ることが大切だと思っています。特に導入初期のうちは透明性をもたらす習慣作り重視でチームに働きかけています。
透明性がなければ、検査も適応もありません。透明性がなければステークホルダーからの協力も得られません。
そして、最近知った言葉ですが、「透明性は共通理解によってもたらされる」*2は家宝にしたいレベルの気づきです。
プロダクトバックログやスプリントバックログの活用、各種スクラムイベントの実施、ペアプロ、画面共有、などなど、共通理解を促す材料はチームの文化/習慣が作り出すと信じて布教していますw
2. タイムボックスの意識と遵守
スクラムでは、タイムボックスも大切です。チームメンバーのスクラムに対するモチベーションを下げないためにもタイムボックスを守りたいと思っています！
思い返すと、私もスクラム始めたての頃は、「なんでこんなに話し合いに時間がかかるの？この時間を実装に当てた方が良いのでは？」と思っていたものです...。（この考えではダメな理由も後述します）
例えば、デイリースクラムのタイムボックスは15分とよく言われています。スプリントの今の状況とゴールに向けたアクションプランなど、15分で「透明性、検査、適応」することに最大限集中します！ただの報告会ではなく、タスクや進め方の見直しまで一気に短時間でやるにはメンバー全員の協力と集中が必要不可欠です。
3. 社内リリースプロセスとの整合性
スクラムではスプリント終了時点の成果物（インクリメント）をリリース可能な品質まで担保します。なので、1週間スプリントなら毎週リリースも可能です！
しかし会社によってリリースのルールなどもありますので、実態に合わせたリリースサイクル運用が求められます。
例えば、私が携わっているABEJA Platform ではユーザ影響の最小化を考慮した品質基準ポリシーを定めており、事前周知を徹底しています。なので、完成したインクリメントを月末にまとめてリリースする「リリーススプリント」を導入しています。
リリーススプリント導入に当たって特に意識している点としては、各インクリメントの品質保証はスプリント単位に確実に行うようにすることです。
リリースまでの期間をバグ修正猶予期間にしないようにしています。実態として後で気づいて修正することもなくもないですが、最初からこれを期待するとプロダクトバックログの「受け入れ条件」や「完成の定義」が曖昧になるか、そこに満たないインクリメントの受け入れを許容してしまったり...。おそらく私のチームは、頑張り屋さんが多いので、スクラム導入前の課題が再燃してしまうことでしょう。
スクラムのよくある誤解や質問
ここからはスクラムに対する誤解や質問への回答を私なりの理解を交えてご紹介します。
4. プロダクトオーナーという上位者の下で開発者がIT ソルジャーするの？
スクラムチームは上下関係の無いフラットなチームです！*3
例えば、プロダクトオーナーの提示したバックログに納得できないとか、まだ始められないとかがあれば、開発者は自分達が理解/納得できるまできちんと議論すべきです。
また、上下関係を作ってはならない大きな理由は、チームが柔軟に変化に対応できるようにするためには、チームが自律的に動けている必要があるからだと思います。「誰かに指示されて動く」ではアジリティは得られないのです。これをスクラムでは自己管理（自己組織化）と表現しています。非常に大切なことです。*4
5. スクラムを取り入れたら開発速度が爆上がりする？
（諸説あるかと思いますが、私の意見としては、）スクラムで開発速度は短期的には向上しません。
スクラムの理論とフレームワークを活用することで、アジリティが高まり、ユーザ価値の高いJust In Timeなリリースを行う開発力は得られますが、開発スピードを短期的に向上させるものではないと思っています。
もちろん長期的には開発速度（ベロシティ）向上は期待できます！
ただし、チームを技術領域で属人化をさせたらダメです！
6. ストーリーポイントは難易度ではなく実稼働時間ベースで見積もるのが正義では？
経験上、超真面目に見積もり精度向上を狙ったり、開発者の防衛本能が働いてしまい、この形に行き着くのかなあと思います。ですが、基本に忠実に、難易度ベースのストーリーポイントで設定することをおすすめします！
実稼働時間ベースのポイントだと、開発者は見積もりをするためにプロダクトバックログの精緻化を必要以上に求めてしまいます。
- その結果...
- リファインメントの時間は長引き、雰囲気が荒れる可能性もあります。
- 場合によっては、プロダクトバックログ上でSBI レベルのTODO が定義され始めます。
- そして、リファインメントの進行を誰もやりたくなくなります！
- 「イベントを自分達主体でやりたくない」は自己管理（自己組織化）の黄色信号な気がします！
7. イベント多すぎ！開発時間が少なくて開発効率が悪くない？
人間は欲深い生き物です。
出来上がっていくものを見ると「もっとこんな機能にしたい」「後できっと使うロジックだから今のうちに入れておきたい」とか、さまざまな視点から出てきたリクエストが散発されます。リクエストをコントロールできなくなると、私のチームのスクラム導入前の課題にあったようなゴールのおあずけ的な手戻り感などでチームが疲弊します。
なので、実現したい価値を明確に定義し、関係者間で共通理解を持って、今リリースすべきバリュー（Just In Time なリリース）にフォーカスをするのです！
例えば、プロダクトバックログは関係者間での共通理解に非常に役立つ仕組みですので、リファインメントやプランニングなどのイベントを通してきちんと作って適切に作成&更新しましょう！
本来、「もっとこうしたい」「こうであってほしい」は大変貴重な意見です。たくさん収集して、それらを材料にして、新しくユーザ価値を定義しましょう！（あと、チームで協力してタイムボックスの遵守にも努めましょう！
最後に
タイトルに「開発力 6.2 倍！」と大口を叩いていますが、チームで協力してスクラムを導入できれば必然的に達成できるものでした！
もし私たちと似たような課題を抱えている方がいらっしゃったら参考にしていただけると嬉しいです！
謝辞
私がスクラムマスターとしてスクラムの導入と実践を推進できているのは、前職でのスクラムを用いての開発経験が大きいです。大変感謝しています！
この記事では「過去の過ちを繰り返さないように」的な表現もありますが、本当に素晴らしいスクラムを実践していました！私の理想のチーム像です！！
We Are Hiring!
ABEJAでは一緒に働く仲間を募集しています！ スクラムによる開発体制の中で幅広い技術を活用・習得したい、顧客・社内メンバーと協業しながら開発したい、このブログを読んで興味を持った方は是非こちらの採用ページからエントリーください！
*1:私たちは1週間スプリントを採用しています
*2:https://slide.meguro.ryuzee.com/slides/104 のスライドの内容から発見いたしました。Ryuzee さんのブログは神です！
*3:上下関係がないというのはリスペクトが無いという意味ではなく、上意下達のピラミッドな体制ではないという意味です。「尊敬」はスクラムの5つの価値基準に挙げられています。
*4:開発者の中に突出した技術力を持つエンジニアがいて、みんながその人の意見を聞くだけになっている場合も同様のリスクありです。
*5: 私の経験上、専任化対応は最長３ヶ月程度にとどめないと属人化解消が辛くなります。
*6:専任化をこじらせて属人化問題を根付かすなんてことが無いように！属人化は、例えば、「今Aさんがいないので、この機能は完成できません＞＜」というような状況を招き、継続的バリュー創出体制の維持ができなくなります...。
