この記事はアソビュー！ Advent Calendar 2025の8日目（裏面）です。

はじめに

こんにちは。アソビューでフロントエンドエンジニア兼スクラムマスターをしています、白井です。いつもフロントエンドの記事をメインに書いていましたが、本日はチーム作りのお話になります。

私は去年の3月に結成された7名のスクラムチームで開発を行っています。このチームのメンバーは去年・今年に参画された方がメインとなっており、技術レベル・経験年数が異なり、実装やプロセスの方法に個人差があることでチームは様々な課題を抱えていました。

そこで今回はその課題解決のために プランニングポーカー と 完了の定義（Definition Of Done） を導入してみて、実際にどうだったかのお話をしていきたいと思います。

プランニングポーカーの導入

チームでは以下の課題を抱えていました。

チームメンバーの技術レベルの違いで、開発スピードに差があった
勤続年数による知識量に起因して、タスクに対する「影響範囲」「難易度」等の認識に違いがあった
バックログリファインメントでは主に「要件」を詰めていて、実装の詳細を合わせる場がなかった

コードレビューの際も「なんでこの実装になったんだっけ？」という話になり手戻りが発生することがありました。どう実装されるかは全員で細かく話し合っていないため、実装は早いもののそのあとのレビューや修正に時間を割かれている状況でした。

また、スプリントのタスクについては全員が同じ認識でスタートできれば…と考えていました。

そこで、プランニングポーカーを導入することにしました。もちろんプランニングポーカーはストーリーポイントの見積もりにも必要というのはあるのですが、どちらかというと上記の課題解決をメインに推し進めることにしました。

やったこと

バックログリファインメントを行った後に、プランニングポーカーを活用して開発者で以下を実施しました。

実装方針やざっくりした設計、疑問点を含めてまず全員で話す
ストーリーポイントを提示し、大きくポイントがズレた人の理由を深掘り
そこで出た懸念点、影響範囲、簡単な設計など、意見をまとめる

ストーリーポイントの見積もり精度よりも、実装前にチームの認識を共通化し、手戻りを減らすことを目的として進めていきました。

やってみた結果...

大まかな設計、修正箇所、修正方法の疑問などが、有識者から回答されることにより、全員「こう直せばいけそうだ」というところからスタートできるようになった
最初にある程度の実装方針を決めて進めるため、コードレビューで大きくブレるということが減った

開発者間で詳細を話していくと、「この要件だとここも考慮が必要じゃない？」といったような、要件の抜け漏れも発見できるようになりました。

また、個人的に嬉しかったポイントとしては「誰かを指名することなく、チームの全員が自ら発言してくれている」ことです。誰かが意見を出して、それに対して誰かが答えてくれる・・全員がタスクに対してしっかり向き合ってくれているのを実感しています（今回の主題とは関係ないですが、意見の出しやすいチーム作りができているのでは、と思いたいです。チームの皆さんにはいつも感謝です）。

逆に言うと、誰かを指名しないと意見が出なかったり、スクラムマスターばかりが発言している状態だとまだうまく機能しない可能性もあるなと感じました。

ストーリーポイントについての集計方法についてもさまざまあると思いますが、どのように集計していくかは今後チームに合った方法を考えていきたいです。

完了の定義の導入

プランニングポーカーによって、ある程度実装に関する課題を解消することができました。

ですが、リリースまでのプロセスや開発における汎用的なチェックポイントの漏れなど、実装以外の面でもいくつか課題を抱えていました。

タスクによって、誰をレビュワーにしたらいいのか、確認が必要な人は誰なのか、関連する人がバラバラで個人による判断が大きかった
非機能要件（ログ、パフォーマンスなど）があまり考慮されずに漏れがちだった

どのプロダクトのコードを修正した際に、誰をレビュワーに設定するか、というルールはあったのですが、抜け漏れてしまうことがありました。このあたりの確認は最後にスクラムマスターである私がチェックしていたのですが、「この人のレビュー通ってません！」というような指摘をしたりすることもあり、確認コストがかかっている状況でした。

大きな開発では非機能要件をしっかり議論していた一方で、細かなタスクになると「どこまで検討すべきか」を話す機会がほとんどなく、非機能要件そのものが議題に上がらないまま進んでしまうことがありました。

そこで、リリースまでに必要なチェックリスト「完了の定義」を作成することにしました。

やったこと

タスクごとに必要な「完了の定義」の項目を、チームメンバー全員で議論
都度考えるのではなく、別シートに「完了の定義」の一覧化して、そこからピックアップ

以下のような「完了の定義」テンプレートを用意して、タスクごとに定義を決めていきました。

元々「完了の定義」自体は Jira チケットの概要欄に記載しておきたかったのですが、今のチームで運用している企業管理型のプロジェクトではタスクの Template が利用できないこと、そして Template の代わりに利用していた Automation （タスク作成時に定型分を概要にセットする）ではチェックボックスが使えませんでした。

そのため、Confluence のページに「完了の定義」を記載、都度そこからピックアップする方式を採りました。

やってみた結果...

「どの確認が誰に必要か？」を毎回人力で思い出す必要がなくなった
「完了の定義」を見ればリリースまでにやるべきことがすべて明確になり、迷わなくなった
非機能要件の抜け漏れが減った

普段の開発で、誰に確認するのか、何をどこまで考慮するのか、など細かい疑問を抱えて作業が止まってしまうこともあると思いますが、その辺りの細かい質問を事前に記載しておくことで、スムーズに開発が進められるようになりました。

ただピックアップする方式は、毎回すべてを一つ一つピックアップするため、多少の時間がかかっています。定義の方法については今後も検討していきたいところです。

まとめ：最初に時間をかける価値

今回プランニングポーカー・完了の定義の導入をしてみましたが、全員を集めてしっかり話すためそこそこ時間がかかります。しかし以前は、設計齟齬・確認不足など後から発生する問題が多く、後に支払うコストが高い状況でした。最初に時間をかけてでも事前に問題点をつぶせるようになったと考えれば、実施する価値はあったかなと思いました。

今はタスクについての疑問点を解消した上で、全員がタスクについて何をやろうとしているのか大まかに把握している状態を作れたので、誰かが休んだときの巻き取りやヘルプをお願いして一部タスクのフォローをする、といったこともスムーズに行うことができました。

またリリースまでの確認フローが明確になったことで開発メンバーが全員自ら動いて、依頼者やデザイナー、関係各所に確認も行っていただき、主体性あるチームに一歩近づくことができました！😄

しかし、これはゴールではありません。特に「完了の定義」は策定後も常にアップデートされ続けており、まだまだ発展途上です。今後もチームメンバーとの会話を重ねて改善を続けていきたいと思います。

現在アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！
ご興味がありましたら、ぜひご気軽にご応募ください！