この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。2026春QAエンジニアリレーブログ、ついに最後の6本目の記事となります。
こんにちは。kintone拡張基盤チームQAエンジニアのmassanです。拡張基盤チームではここ1年半ほど、チーム全員（EM・PdE・QA）でPBIのストーリーポイント（SP）を見積もっています。今回はその経緯、リファインメントでの会話の変化、効果についてお話しします。
なんとなくで見積もっていた従来方針
チームが立ち上がった当時はスクラムを厳密に取り入れるタイミングもなく、各自自分の見える範囲の作業を中心に見積もっていました。
QAはチームに専任で所属しているためリファインメントにも参加していましたが、PBIについての話は検討の背景や仕様、実装面のやりとりが多めでした。QAも見積もりに参加するものの、実装部分をメインに見積もっている気がしてしまい、自分が担当しない作業の見積もりやテスト工数の扱いなどにやりづらさを感じていました。
余談ですが、社内の開発チームごとでスクラムの取り入れ状況やリファインメントの進め方は多様です。私自身は以前リファインメントに出るもののQAは見積もりしない、というチームにいました。拡張基盤チームでは立ち上げ当時からチーム全員で見積もる方針を採用しており、やりづらさに気づくきっかけとなりました。
テストを含むPBI全体のSPを見積もる方針に変更
従来方針でのやりづらさをチームに共有し、改善を検討しました。QAが上流工程でどれくらい発言して良いのか、テストまでチームに考えさせることでより優先すべき懸念点を見落としてしまわないかなど悩みながらの相談でした。
QAはQAの作業分だけを見積もって実装工数と足しあげる案もありましたが、結局スクラムの作法に従いリリースまでの全行程をチーム全員で見積もる方針で合意しました。話し合う中で各自の見積もり方針にばらつきがあることや、全体的にコミュニケーションを増やす余地があるということにも気づけました。
これ以降はQAも実装部分を含めて見積もり、他メンバーも実装後の作業を見積もり、見積もりが出せない時はお互いに質問するようにしています。
会話の変化
見積もり方針の変更により、リファインメントでの会話にいくつか変化がありました。
QAも実装を見積もる
方針の変更により、実装しないが実装も含めて見積もるという自分の立場を明確にできました。これによりそれまで聞きづらかった質問もしやすくなりました。以下は一部の例です。
- 作業量の目安に確信はあるか
- 実装の難易度をPdEはどう感じるか
- 外部仕様から見た影響範囲の認識は合っているか
もちろん質問内容はPBIによって変わりますが、実装方針を理解するよりも実装工程で生まれるリスクはどれくらいあるかを洗い出すイメージで会話しています。不確実な部分を事前に知っておくと回収のための心算もできますし、QA側からそれらを解消できるアイデアを出せるかも知れません。
他メンバーもテストを見積もる
他のメンバーがテストについてどれくらい知っているか、自分自身も未知でした。テストについてのイメージがばらばらだと、いくつかの弊害をもたらすことがあります。
- テストが終わり次第リリースしたい場合、日程の認識がずれる
- テストが重そうに見えると、開発の心理的なハードルになる
- 不要/過剰なテストについて、QA以外の視点で判断できない
新しい方針では他のメンバーにもテスト以降を見積もってもらうという前提で、積極的に情報を出すようになりました。例えば、詳細な機能テストが必要か、β版なので最低限でよいのかの質問や、具体的なテストケース、実際にテストするときにこそ認識合わせが発生しそうな箇所などです。これによってPBIで目指す品質に大きな認識の齟齬がないかも確認できますし、リリース可能になるまでのイメージをより明確にメンバーで共有するきっかけにもなります。
他にも、自分のスキルや経験的にすぐできるテストかどうかや、タスクに関連するAIの活用状況など、直接工数に影響する観点も共有しています。もちろん毎回のリファインメントで劇的に成果を出すわけではありませんが、テスト周りの状況を共有することで他のメンバーからアドバイスやアイデアをもらえることもあります。
効果
リファインメントでの情報量が上がった
従来方針でも、新しい方針の開始したてでも、自分（QA）だけが異なる見積もりを出してしまうことへの心理的なハードルがありました。実際にQAなど特定の職能だけが違う見積もりを出すこともあり、その度に一人ひとりコメントを出してすり合わせていきました。（拡張基盤チームはリファインメントの参加者が概ねいつも４人以下なので全員発言することが多いです。）そうして回数を重ねるごとに職能による見積もり差は減っていきました。チームで合意をとったことにより質問への心理的なハードルは下がり、言い意味で雑に気になったことを聞けるようにもなりました。
QAからのコメント出しについて、どうしてもテストの話をするとリリースが遅くなるような、消極的なイメージを伴ってしまうことがあります。もちろん必要なテストを遠慮を理由に削ることはできませんが、守るべき観点を守りつつ、より早く安心してリリースできる方法を模索したいという気持ちもこめてテストの情報を出すようになりました。
会話量を増やすと情報量は増え、お互いの作業について複数の視点から見ることができ、知らない・見えないことによる不確実性を下げることができます。テストを含む実装以降の認識合わせをすることでリリース可能な状態になるまでのタスクがより明確になり、リリース日程やリリースする機能単位の認識合わせも以前より自然に行えるようにもなりました。
（副次的）協力が柔軟になった
QAも一員としてチームに所属していますが、自分自身にあった習慣や慣れにより、テスト活動に関してQAしか知らない領域を作ってしまっていたように思います。例えば、チームのカンバンにはテスト実施がわかるステータスはありますが、テスト設計をいつどうやってしているかはほとんど見えません。
方針を変えてからはQAである自分の発言量が少し上がり、テスト設計の話をするようになったのはもちろん、QAが主導するPBI（テスト全般の改善など）についてもリファインメントで話すようになりました。これによりチームにQAの仕事を知ってもらえる機会ができ、テスト改善のレビューをしてほしい場合など協力を依頼しやすくなりました。
まとめ・LTの反応
自分にとってのやりづらさを解消したかっただけのところが、QAがチームの開発でより動きやすくなるきっかけになりました。リファインメントでPBI全体のタスクを見積もる方針にすることで情報量は増え、リリースまでの工程や各タスクでの懸念をチームで確認することができます。
このLTをまとめるにあたってスクラムマスターに壁打ちの相談をしたところ、「見積もりがずれることに対してネガティブに感じるケースは多いが、この話ではポジティブに受け止められていそう」という感想をもらえました。チームの大きさや開発の進め方によってこのような見積もり方針が合うかは違いそうですが、個人作業の多い自チームで効率よくQAの考えを上流工程にもっていく仕組みができたのかなと思っています。
リレーブログのおわりに
2026春QAエンジニアリレーブログでは「テスト実施以外の、QAエンジニアの活動」をテーマに記事を発信してきましたが、いかがだったでしょうか。私自身は開運冬まつりのいちLT登壇者でしかありませんでしたが、社内で多くのメンバーに聞いてもらえたLTを社外に見える場所にも発信したい、そして社外交流のきっかけにもしたいという思いから今回のリレーを提案しました。
幸い、QAエンジニアレーンの登壇者全員にリレーブログへの参加を快諾してもらうことができました。まだ桜が咲き終わらないうちに全ての記事が無事公開に至り、陰ながら嬉しいばかりです。
各記事をご覧くださったみなさまに、少しでもサイボウズのQAエンジニアの活動について知ってもらえたら幸いです🌸
