1. はじめに
こんにちは。UPSIDERでQAエンジニアをしているteraです。
このたび、多くのお客様からご要望をいただいていたETCカードを、ついにリリースできました。たくさんの方に使っていただけたら嬉しいです。
——さて、ここからはその開発の裏側の話です。
「この仕様、いつ決まったんだっけ……？」
開発中のある日、自分の知らない仕様決定が目の前に出てきました。仕様策定には最初から関わり、チーム全体を誰よりも把握している自信があったのに、です。
ETCカードの開発チームで、QAは私1人でした。この記事では、「QAが品質を一人で確認する」やり方から、「チーム全体で品質をつくる」やり方へ変えていった話を書きます。たどり着いたのは、拍子抜けするほど「基本」の話でした。
2. なぜ「基本を守る」のが難しかったのか
ETCカードの開発には、チームのエンジニアやPdMに加え、ビジネスチームや社外のパートナーなど、多くの関係者がいました。関係者が増えるほどやり取りの経路は一気に増えますが、まさにその状態です。
各所で生まれる情報を拾い、品質の観点で整理してチームへ届ける役割を、私が担っていました。Notionに全体仕様をまとめ、各PBI（プロダクトバックログ上の開発項目）へ参照を張り、必要な部分は転載する。ただ、この転載は情報を細切れにもしていて、全体像とつながった形で仕様を把握できるのは結局私だけでした。
開発が進むと、この構造は限界を迎えます。QAレビュー待ちは積み上がり、コメントのラリーは何往復も続き、同じ説明を何度も繰り返す。やがて、冒頭の「自分の知らない仕様決定」に出会います。
全体を知っているのが私だけということは、私が拾い損ねた情報は誰も拾えない、ということでした。
受け入れ条件を書く、レビューをする——どれも開発の基本です。ただ、それを「私が」やろうとするほど、すべてが私を経由する構造が強化されていく。真面目にやるほど、属人化が進む状態でした。
3. 1人で抱えず、仕組みに変えたこと
この構造を変えるために取り入れた仕組みを、3つ紹介します。
3-1. 受け入れ条件を、Gherkinで書く
受け入れ条件とは、「この機能は何ができたら完成なのか」の合意です。これを開発前に書く運用を始めました。
形式はGherkin。「〜という状態で（Given）、〜すると（When）、〜になる（Then）」という宣言形で振る舞いを書く記法です。例えば「ETC利用明細のCSVダウンロード」の権限まわりなら、こう書きます。
シナリオ: 管理者は全カードの明細CSVをダウンロードできる 前提(Given) 管理者としてログインしている もし(When) カード一覧から利用明細CSVをダウンロードする ならば(Then) すべてのETCカードの利用明細がCSVに含まれている シナリオ: 一般ユーザーは保有カードの明細CSVのみダウンロードできる 前提(Given) 一般ユーザーとしてログインしている かつ(And) 自分が保有するETCカードが1枚ある かつ(And) 他のユーザーが保有するETCカードもある もし(When) カード一覧から利用明細CSVをダウンロードする ならば(Then) CSVに含まれるのは保有カードの利用明細のみである
2つのシナリオはWhen（操作）がまったく同じで、Given（ユーザーのロールなどの前提条件）とThen（期待する結果）が違います。「同じボタンでも、誰が押すかで中身が変わる」——文章の仕様書では読み流されがちな違いが、この形式だと並べた瞬間に見えます。前提・操作・期待結果を同じ形で書き、チームでレビューすることで、ロールごとの差分や未決事項を見つけやすくなりました。
運用面では、サンプルを提示し、書かれたものはレビューで揃えていきました。レビューは私がいきなり見るのではなく、まずチーム内で一次レビューをする形です（詳しくは3-3で）。
書き出してみると、影響範囲の広さが見えたり、気にすべきことが洗い出されて「これ、思ったより大変だね」と着手前に分かったり。実際、あるPBIでは、ロールによって操作できる範囲が異なるという考慮漏れを、受け入れ条件を書く時点で発見できました。以前なら、実装後のQAレビューでようやく気づいていたはずの差分です。
エンジニアだけでなくPdMとも、同じ受け入れ条件を見ながら話せるようになり、認識のズレも見積もりのズレも早い段階で表面化しました。受け入れ条件を仕様の合意点としてチームでレビューするようになり、変更や食い違いを複数人が発見できるようになりました。それでも事前に書き切れず漏れるものはあり、そこを拾ってくれたのが、次章で書く中間レビューでした。
3-2. 完了までに必要な作業を、PBIごとに可視化する
受け入れ条件が「何ができたら完成か」なら、こちらは「完了までに何をするか」です。テストの範囲や、他チームとの調整のような実装以外の作業も含めて、完了チェックリストとしてPBIごとに書き出しました。確認の仕方は受け入れ条件と同じです。
例えば、先ほどのCSVダウンロードならこんな形です。
■完了チェックリスト： - [ ] コードレビューが完了していること - [ ] 管理者・一般ユーザーの各ロールでCSVの内容を確認済みであること - [ ] 正常系・境界値のテストコードが書かれていること - [ ] ステージング環境で動作確認済みであること - [ ] 実装メモの全TODOが対応済みまたは対応不要と判断されていること ■実装メモ： - [ ] 権限によるカードの絞り込みはAPI側で行う（フロントでの出し分けにしない） - [ ] 保有カードが0枚のユーザーがダウンロードした場合の挙動を確認する
リファインメント（バックログの整理）やプランニングの時点で気になることを実装メモに書き出しておき、実装中に気づいたことも追加していく。その全TODOの消化までが「完了」です。チーム共通のチェック項目はテンプレート化を進めており、PBI固有の確認事項を追記しています。
効いたのは、進捗の見え方でした。「実装は終わったが、テストや確認が残っている」タスクの状態は、以前は私の頭の中にしかありませんでした。完了までの作業がPBIに書かれていれば、何が残っているかは誰が見ても分かる。「終わった／終わっていない」の判断に、私を経由する必要がなくなりました。残作業を見て「これは影響が小さいので完了としてよい」といった判断も、私を待たずにチームの中で完結するようになりました。
3-3. QAレビューの前に、チームでレビューする
受け入れ条件と完了チェックリストを下書きするのは、PBIを担当するエンジニアです。カードチームでは、テストケースも担当エンジニアが書いていました。これらのレビューを、私がいきなり見るのではなく、まずチームメンバーが一次レビューをする運用にしました。全員で見ることもあれば、チームの誰かが見ることもあります。
エンジニアの負荷が増えないか心配でしたが、受け入れ条件や完了チェックリストで共通認識ができていたことが、レビューの支えになりました。
順序を変えただけに見えますが、効果は大きいものでした。一次レビューを通る過程でチーム内の認識が揃っていくため、私のところに上がってくる時点で、受け入れ条件や完了チェックリストの記述が明確になり、観点の抜けも減っている。結果として、コメントのラリーは目に見えて減りました。あわせて、リスクの低いものは、チームの確認だけで完了できる形へも変えてきています。
2章で書いた「すべてが私を経由する構造」は、ここで大きく変わりました。認識合わせと一次レビューはチームの中で完結し、私の役割は、リスクの高い点や観点の抜けの確認へ移りました。3-2で書いた「何が残っているかは誰が見ても分かる」状態も、チェックリストをチームでレビューして観点が揃っていたからこそ機能したのだと思っています。
4. やってみて、変えていく ― スプリント途中レビュー会
とはいえ、ここまでの仕組みが最初からすんなり定着したわけではありません。実際に運用してみると、現実的な声が出てきます。「開発前にここまで書き切るのは、正直しんどい」。
たしかに、着手前にすべてを言語化するのは負荷が高い。かといって書かずに進めば、元の属人化に逆戻りです。そこで、スプリント（開発期間の区切り）の途中で動くものを見ながらすり合わせるレビュー会が、エンジニアのNagaiさんの発案で始まりました。このレビュー会の実際の運用は、本人が別の記事で詳しく書いているので、ぜひそちらもご覧ください。
重要な受け入れ条件は着手前に合意しつつ、実物を見なければ判断しにくい部分や、実装中に見えてきた論点は中間レビューで確認する。動くものを前にすると、エンジニア・PdM・QAが同じ目線で話せます。QAとしても大きな変化でした。それまでは完成したものを確認してから指摘する、つまり手戻りが前提の関わり方でしたが、実装の途中でフィードバックできるようになりました。軌道修正も、軽いうちに片づきます。プロジェクト後半はこの形で落ち着き、スプリント終了時に「思っていたものと違う」が発覚することは減っていきました。
5. おわりに ― 遠回りして、基本に戻ってきた
受け入れ条件、完了までの作業の可視化、レビュー。個々の手法はどれも新しいものではありません。変えたのは、それらをQA一人の仕事ではなく、チームの共通理解をつくる活動として設計したことでした。
こうした基本を、忙しさの中でおろそかにしてしまった時期もありました。そして「QAの私が」やろうとするほど、属人化が進んだ。チームでできる形へ変えた途端に機能し始めた——その効き方を本当に理解したのは、一度うまくいかなくなってからだったと思います。
冒頭に書いた「この仕様、いつ決まったんだっけ」——正直に言えば、こうした場面が完全になくなったわけではありません。変わったのは、それに気づき、拾えるのが私ひとりではなくなったことでした。
まとめると——受け入れ条件と残作業を見える形にする。チームでレビューする。動くものを早く確かめる。品質をチームのものにするうえで必要だったのは、この流れをQA一人の外へ広げることでした。
アジャイル開発の定番書『カイゼン・ジャーニー』の第2部 第10話で述べられている「何をもって完成とするかをチームの共通認識にする」という考え方は、私たちが完了チェックリストを運用するうえでも参考になりました。書くことは目的ではなく、共通認識を持つための手段。それがこの記事で一番伝えたかったことです。
まだ道半ばです。いまは、チームで書いた受け入れ条件やテストケースを資産として蓄積し、自動作成につなげる取り組みを始めています。テストが資産になれば、変更のたびに確認をやり直すのではなく、ためらわず変更して素早く確かめられるようになる。品質を「守るもの」から、開発を加速させる「武器」へ——次はそこを目指します。
6. エピローグ：高速道路のバーは開くのか
ETCカードの本番走行テストの話を、少しだけさせてください。カードを発行し、3枚を区間ごとに切り替えながら走る計画で、ルート設計はAIに手伝ってもらいました。交換地点は大黒PAと海ほたる。準備は万全でした。
当日、最初の関門は渋谷の入口ゲート。バーは本当に開くのか——後ろに大型バスが迫るなか、無事開きました。
ところがその後、走行チームから連絡が入ります。「PAでカードを切り替えると、入場・退場のデータに不足が出ます」。
PAは高速道路の“中”。そこで交換したら入場記録のないカードが生まれて、明細どころか出口のバーも開かず立ち往生していたかもしれません。カードではなく、走り方の問題です。言われてみれば当たり前なのに、AIと一緒に練ったはずの計画でも、机上では誰も気づきませんでした。
走行チームがその場で「ICを一度降りて交換」に切り替えてくれたおかげで、テストは無事に終わりました。後から思えば当たり前のことほど、実際にやってみて初めて見えるものなのだと感じた出来事でした。
ここまで読んでいただき、ありがとうございました。
We Are Hiring
UPSIDER Engineering Deckはこちら📣
