大野克樹

## 自社開発プロダクトでのスクラムマスター | 項目 | 内容 | |---|---| | 役割 | Scrum Master 兼 開発担当（プレイングSM） | | チーム規模 | 6〜10名 | | スプリント | 2週間 | | 実施イベント | スプリントプランニング / デイリースクラム / スプリントレビュー / レトロスペクティブ（全イベント実施） |

既存のScrum運用を引き継ぎ、形骸化しがちな各イベントを実態に合わせて機能させながら0→1フェーズというカオスな環境で日々発生しうる開発上の問題を解決していく責務がある

**主な成果** - スプリント中のブロック時間を**約30%削減** - 常習化していたスプリントゴールの未達状態を、**安定的に100%達成**へ改善 - スプリントあたり平均10〜20件発生していた高ランクバグを、**5件以下に削減** - dev / stg / preview の用途別環境を設計・構築し、**マージ待ちによるタスクのスタックをほぼ解消** --- ## 注力した取り組み：障害除去とビジネスサイドとの調整 開発を阻害していた複数の障害に対し、Scrum Master として営業・経営・CS など**事業に関わるビジネスサイド全体**と連携しながら、根本的な改善を進めました。 ### 1. スプリント中の割り込みタスクの多発 **課題** スプリント期間中に割り込みタスクが頻発し、計画していたスプリントゴールの達成が常習的に困難になっていた。 **実施したこと** - 自分がブロッカーとして一次受けし、自身で捌けるものは巻き取ることで、チームメンバーが計画タスクに集中できる状態を確保（プレイングSMの強みを活かした対応） - 営業・経営・CS など**ビジネスサイドと適宜コミュニケーション**を取り、割り込みを「事業背景」から読み解いた上で、「本当に今スプリントでやるべきか」の優先度づけを実施 - 単に割り込みを排除するのではなく、事業上の必要性を踏まえて取捨選択することで、開発とビジネス双方が納得できる形に調整 **成果** - スプリント中の**ブロック時間を約30%削減** - 常習化していた**スプリントゴール未達を解消し、安定的に100%達成**できる状態へ改善 ### 2. 高ランク（クリティカル）バグの多発 ― コードフリーズによる品質保証プロセスの確立 **課題** 重要度の高いバグがスプリントごとに多発し、品質と開発スピードの両面を圧迫していた。背景には、テスト工程の構造的な問題があった。 - QAテスト中にもコードが変わり続け、**QA結果の信頼性が担保できない** - それに伴う**再テストが頻発**し、QA・開発双方の工数を圧迫 - リリース直前まで変更が加わり、**テスト未実施のまま本番環境へ反映される変更**が発生していた **実施したこと：スプリント内コードフリーズの導入** スプリント内に「コードフリーズ」のマイルストーンを設け、そのスプリントで実装されるコードの範囲を明確化。専任QAによる品質保証の信頼性を担保する仕組みを構築した。2週間スプリントの後半に、以下の3つのマイルストーンを設定した。 | タイミング | マイルストーン | |---|---| | 2週目 火曜 | 機能テスト開始 | | 2週目 水曜 | リグレッションテスト開始 | | 2週目 金曜 | コードフリーズ（翌月曜のスプリントレビューに向けた確定） | QAは**機能テスト → リグレッションテストの2段階**で実施し、専任QAが品質を保証する流れとした。 **運用面での徹底と例外対応** - コードフリーズという明確なマイルストーンができたことで、その**前後の段取りを開発チームへ周知徹底**し、チーム全体で品質保証プロセスを共有 - コードフリーズ後にやむを得ずマージしたい実装が発生した場合は、事情をヒアリングした上で**SMである自分が最終的な意思決定**を担当。判断基準は以下に置いた。 - 他機能への影響がないか - リグレッションテストのやり直しが不要か（必要な場合も対象箇所が限定的か） - 顧客都合などで当該スプリントに出す必然性があるか、というビジネス背景の汲み取り **成果** - スプリントあたり**平均10〜20件**発生していた高ランクバグを、**5件以下に削減** - テスト結果の信頼性が向上し、テスト未実施のまま本番反映されるリスクを解消 ### 3. 開発環境の不足による開発フローの支障 ― stg / preview 環境の構築 **課題** prod / dev の2環境のみしか存在せず、検証やリリースの過程で複数の不都合が生じていた。 - **マージ待ちによるタスクのスタック**：従来は dev でリグレッションテストまで行い、問題なければ prod にマージして本番リリースする流れだったため、リリース直前まで次スプリントの機能を先行着手しているケースで dev にマージできず、タスクが滞留していた - **検証環境がビジネス／開発で混在**：検証用環境が dev のみで、ビジネスサイドとエンジニアが触れる環境が一色単になっていた。ビジネスサイドは顧客データに寄せた綺麗なデータで検証したい一方、開発は極端に長い文字列や大きな数値などエッジケースのデータを作成するため、ビジネスサイドの検証環境にノイズが混入していた - **実装途中の機能を共有する手段がない**：規模の大きい新機能では「dev にはマージしたくないが、どこかの環境にデプロイしてビジネスサイドに共有したい」ニーズがあった。開発フローが local → dev → stg → prod の順である以上、dev へのマージは最終的な本番リリースを意味するため、完成前の機能を共有する場所が存在しなかった **実施したこと：用途に応じた環境の設計・構築** 開発フローを **local → dev → stg → prod** に再設計し、各環境の役割を明確化した。 | 環境 | 役割 | |---|---| | dev | 開発者によるエッジケース検証（極端なデータでの動作確認） | | stg | ビジネスサイドによる本番相当データでの検証。リグレッションテストもこの環境に整理。prod と同等のソースコード状態を保つ | | preview | local→prod のフローから**独立した、任意の feature ブランチ専用環境**。dev にマージしたくない実装途中の機能をビジネスサイドへ共有する用途 | 特に **preview 環境**は、通常のリリースフローから切り離して運用することで、未完成の大型機能でも「現時点の状態をビジネスサイドが確認して認識齟齬を防ぐ」「商談のデモに活用する」といったことを、本番リリースのリスクなく実現できるようにした。 **成果** - dev 環境へのマージ待ちでスタックするタスクが**大幅に減少（ほぼ解消）** - ビジネスサイドの検証がスムーズになり、ノイズ混入の問題を解消 - stg が prod と同等のソースコード状態のため、**本番で発生したバグの再現・検証が容易**になった - ビジネスサイドからの**早期フィードバック**を得られるようになり、本番リリース時には双方の認識が揃った仕様・品質で機能をリリースできるようになった ---