🏃‍♂️

新卒エンジニアがスクラムマスターとして取り組んだ開発プロセスの改善

ray yokoyama

2025/02/17に公開

始めまして。ハコベルで、テックリードを務めている横山怜です。

本記事は先日のハコベル初のMeetupイベントにて行ったLT「スクラムマスターとして取り組んだ開発プロセスの改善」を、より詳しくテックブログの記事として再構成したものです。プロジェクトの現場で実際にどのような課題と向き合い、どのように改善を実施してきたのか、その軌跡を紹介します。

https://hacobell.connpass.com/event/342174/

 記事の内容新卒で入社した自分が当時の開発チームのスクラム体制に疑問を持ち、スクラムマスターになってから開発プロセスを改善するまでの流れを、具体的なエピソードを交えてご紹介します。

特に、QA工程の改善に苦労しながらも成功に導いた取り組みについて、詳しくお伝えできればと思います。

 そもそも何を変えたかったのか
 当時の状況：なんちゃってスクラム時代私たちのチームは、形式上はスクラムのイベントを取り入れていましたが、実際の運用は以下のようなものでした。
デイリースクラムがただの進捗報告会になっている
計画したバックログアイテムは完了できないことが当たり前。終わりきらなかったものは次のスプリントに移す
ベロシティが不安定
プロダクトバックログアイテムは個人に紐づいていて知識が属人化
開発チームは実装するところまで。QA工程はQAチームにお願いする
スプリントゴールはない


見た目はスクラムっぽいものの、単に進捗管理にスプリントの枠を使っていただけのような状態でした。

 じゃあめちゃめちゃ困っていたかというとそうでもない上述したような状況でも表面上はそこまで課題が顕在化していたわけではありませんでした。

リリース自体は継続して行えていたし、出来上がったものの認識が大きくずれているようなことはありませんでした。
ここがなんちゃってスクラムになりがちな理由でもあり、また、なんちゃってスクラムが必ずしも悪い状況というわけではないのだと思います。

ただし、改善された今思うと以下のような問題を抱えていました。

スプリントの中でやりきれない

実装は完了しても、QA工程に入るとバグや仕様漏れが見つかり、そのスプリント内で作業が完了しないケースが日常茶飯事でした。

また、バックログも「hogeAPIを作る」のように作業ベースの内容になっておりそれ単体で価値提供につながるものではありませんでした。

見積もりの不安定さ

3ヶ月～半年かかる大きな機能に関して、見積もりのブレが大きく、スケジュール通りに進捗管理するのが困難でした。

優先度の変更や差し込みなどの対応コストも高かったです。

 スクラムマスターとしての改革への第一歩
 スクラムマスターというロールを明確にまずは、スクラムを改善するんだということを対外的にもアピールするために当時はなかったスクラムマスターのロールに立候補しました。

上司は快くokしてくれたので改善が始まります。


 チーム内のスクラム知識の底上げ続いて、チーム全員が同じスクラムの基本理念を理解していることが不可欠と判断しました。そこで、書籍『SCRUM BOOTCAMP』を用いて輪読会を実施。全員でスクラムの理論や実践例を学び、共通認識を持つことで、後のプロセス改善の土台を固めました。


 お手本通りのスクラムの実践次に、まずは「守破離」の「守」からということで、まずはお手本通りに以下の改善策を実施しました。

振り返りの頻度をアップし改善トライを「やり切る」ことにフォーカスする

以前は隔スプリントで実施していた振り返りを毎スプリント行うことで、早期に問題点を洗い出し、迅速な対応を実現。

振り返りで出た改善案は、必ず「やり切る」ことにフォーカス。実行が次第に成果に繋がりました。

散らばっていたPBIの統合

分散して管理されていたプロダクトバックログアイテム（PBI）を一元化し、優先順位や関連性を明確に管理。

スプリントゴールの明確化

各スプリントの目標を明確に定義することで、チーム全員が同じ方向性を持ち、協力して目標達成を目指す体制を確立。

個人任せのタスク管理から、チーム全体の責任へ

PBIに個々の担当者を割り当てるのではなく、チーム全体の所有物とすることで、責任の分散と協力体制を強化。
その後以下のようなお手本にはないような取り組みも実施しました。

BDD（Behavior-Driven Development）の導入

仕様とテストの連携を強化するため、BDDの実践を始め、品質向上を図りました。

ユビキタス言語の整備

ドメイン駆動設計の文脈で使われるユビキタス言語を整備することでメンバー間での共通言語を作りました。
一番重要だったのは振り返りの質を向上させたことです。ここに書ききれないぐらい色んな課題に対して色んなトライを実施しましたが、それも全て振り返りでプロセスの課題を解決するんだと強く意識できたからです。

 改善の成果と、チーム文化の変革
 スプリントゴール達成が当たり前の文化へこれらの取り組みの結果、次第にスプリントゴールの達成が、当たり前の文化として根付いていきました。たとえば、デイリースクラムでは、
「こういう問題が出てきました。このあとペアプロしませんか？」
といった積極的な問題共有と解決のための提案が飛び交うようになり、スプリントプランニングでは、
「スプリントゴール達成できなかった。なんかおかしくない？振り返りで話そう」
と、常に改善を意識した議論が展開されるようになりました。

 ベロシティの安定とスケールの実現また、チーム全体の取り組みが功を奏し、ベロシティが安定。将来のリリース計画が立てやすくなっただけでなく、開発体制も大きくスケールしました。
下記は各スプリントの達成率を表したグラフですが、基本的に100%達成できるようになりました。

 最大の挑戦：QA工程のチーム内完結化チーム全体でスクラムを実践していく中で、最も大きな壁となったのがQA工程をチームのものとして、スプリント内でやり切るという点でした。

 当初の状況とその問題点以前は、開発チームは実装までを担当し、その後のQAは専任のQAチームに依頼していました。
実装完了のみがベロシティに反映されるため、実際のリリース時期が見通しにくかった。
QA工程は実装の次のスプリントに行われるため、バグや考慮漏れが見つかると計画どころではなくなる。
QA工程が特定のQAエンジニアやQAチームに依存していたため、人員の変動や欠員が品質に直結するリスクがあった。

 QA工程統合への道のり改善策として、開発エンジニアもQA工程に積極的に関与する体制を作ろうとしましたが、ここでもいくつかの課題に直面しました。
テストケース作成の知識不足
多くの開発エンジニアは、どのようにテストケースを作成すればよいか経験がなく、初めは戸惑いがありました。
役割に対する抵抗感
「開発エンジニアがテストケースの打鍵（実行）をやるの…？」という、ふわっとした抵抗感もありました。
1スプリント内で完結させる難しさ
実装とQAを同じスプリント内で終わらせるためには、従来の分業体制から大きな変革が必要でした。

 具体的な対策と実施内容こうした障壁に対して、以下のような取り組みを実施しました。
チーム全体での合意形成
「本気でやる」という強い意志を全員で共有
QAタスクの明文化とスプリントバックログへの組み込み
QAケースの作成・実施を、明確なスプリントバックログアイテムとして扱い、計画段階からタスクとして見える化しました。
スプリント開始時からのQAケース作成
スプリント開始時点で、実装と並行してQAケースの作成をスタート。後回しにせず、最初から品質保証を意識しました。
テストケース作成手法のドキュメント化
具体的な作成方法やチェックポイントを明文化し、誰でも同じプロセスでQAケースを作成できるようにしました。
ペアQAケース作成の実施
QAのプロであるQAエンジニアと、開発エンジニアがペアでテストケースを作成することで、知識の共有と技術の定着を促進しました。
自らの実践による当たり前化
スクラムマスターである私自身も、率先してQAチケットの実施に取り組み、全員が新たな体制に対して積極的になるよう働きかけました。
これらの「仕組み化」と「気合い」を両輪にした取り組みにより、最終的には「QAが完了していること」がバックログの完了の定義に組み込まれ、チーム全体でQA工程を完遂できる体制を確立しました。

その結果、

手戻りが激減し、ベロシティが実際にデリバリー可能な成果物を示す指標へと変化。

スプリントの序盤からテストケースを作るので、仕様の疑問を即座に実装にFBでき、手戻りが激減しました。また、ベロシティが同じプロダクトバックログアイテムは入れ替えが可能なので優先度変更も容易に行えるようになりました。

QAエンジニアへの属人化を防ぎ、安定した品質を維持できるように。

チームの人数は当時の3倍になりましたが、QAエンジニアの人数は変わらずでスケールできるようになりました。

 まとめ今回の改善活動を通して、改めて以下のポイントの重要性を実感しました。
基本に立ち返ること
スクラムの理論と実践の基本に戻ることで、チーム全体が一丸となり、改善の方向性が明確になりました。
仕組み化と実行の徹底
改善策を単なるアイデアで終わらせず、具体的な仕組みとして定着させることが、持続的な改善に不可欠です。
チーム全体での取り組み
部分最適ではなく、チーム全体で協力し合うことで、リリース計画の見通しと品質の両立が可能になりました。
私たちの経験が、同様にプロセス改善に取り組むチームの参考になれば幸いです。スクラムは単なるイベントの羅列ではなく、チームの文化として根付かせることで、本当の力を発揮するものだと実感しています。これからも、基本を大切にしながらチーム全体で成長を続けていきたいと思います。