こんにちは。freeeの課金基盤チームでQAエンジニアをしているkairiです。
この記事は freee QA Advent Calendar2025 の9日目です。
ここ数年AIの登場によって様々なことが本当に便利になりました。私自身2年以上プライベートでChatGPTに課金しているヘビーユーザーですし、業務においても日常的にGeminiやNotebookLM、askDevin、Roo CodeといったAIツールをフル活用しています。
いま、どこの企業でも開発やテストの現場でAIによる効率化が急速に進んでいることでしょう。一方で、AIが出した「正しそうな答え」をそのまま採用して、後から「あれ、なんか思ってたのと違う」となるケースはどの現場にもあるのではないでしょうか。
今回は、そういった「すれ違い」を防ぐ、「たったひとつの冴えたやりかた」をご紹介します。
解決策は、シンプルで泥臭いこと
手戻りを防ぐ最も確実な方法は、派手な自動化やAIではありません。
それは、チームで「認識を合わせる」ことです。
どれだけツールを導入しようが、ここを怠ると結局すれ違いは繰り返されます。
この場合の「認識合わせ」は、以下のようなことを指します。
- 各関係者（ステークホルダー）を集めて認識のすり合わせを行い、齟齬が発生しないようにすること
- 特に運用担当者やサポート担当者、法務の方など、開発に直接関わらない職域の方々も巻き込むこと
- 製品が出来上がっていく段階でこまめにデモを行い、方向性が誤っていないことを認識合わせしながら進めること
製品は作って終わりではありませんし、大抵の場合は一人で作るものでも、一人で運用していくものでもありません。であれば関係者全員でしっかり認識を合わせて着実に進めていくことが結果的に一番効率が良いと言えます。そのためには、必要に応じてその「話し合いの場」を設けることも重要です。
なぜ、AI時代に「話し合い」なのか？
大前提として、この記事はAIを否定するための記事ではありません。ただ、現時点でのAIにははっきりと苦手な分野が存在しているのは事実です。それは『与えられた指示に対し「そもそもなぜそれをやるのか？（Why）」と問うこと』です。
AIは「How: どう作るか」「What: 何を作るか」において最適解を出すのが得意です。ですが、そもそもその根底にある「Why: なぜそれをやるのか」がずれていると、間違った方向に全力疾走してしまいます。
有名なところで、「自動車王」と呼ばれたヘンリー・フォードの言葉に、以下のようなものがあります。
もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。
この場合、私たちは「もっと速い馬が欲しい」とAIに問うことになるでしょう。実際AI（Gemini 2.5 Pro）に聞いてみた結果が以下のようなものです。
速い馬、憧れますね！ どのような「速い馬」にご興味がおありでしょうか？ 競馬で活躍するような、サラブレッドのような馬ですか？ それとも、ご自身が乗馬で楽しむための、スピードの出る馬でしょうか？ もしよろしければ、どのような目的でお探しか教えていただけますか？
最近のAIはかなり賢いので、ここで「目的」を聞いてくれます。ここで「移動したい」と答えたら「馬である必要はないのではないか」と答えてくれるかと思いきや…
馬に乗って「移動」されたいということですね！ 「速い馬で移動する」というと、とても爽快で楽しそうです。 それは、例えば次のようなイメージでしょうか？ 外乗（がいじょう）： 森や海岸など、景色の良い場所を馬に乗って（時には速足や駆け足で）散策・移動すること。 エンデュランス（耐久）競技： 数十キロから時には100キロを超える長距離を、馬の体調を管理しながら走りきる、馬のマラソンのような競技。 単に「速く走る」体験： 乗馬クラブの馬場（トラック）などで、力強く速く走る感覚そのものを楽しみたい。 どのような「移動」にご興味がおありか、もう少し具体的に教えていただけますか？ 例えば「外乗で速く走れる馬に乗りたい」といった形ですと、さらに詳しいご提案ができるかもしれません。
AIは特に最初に入力した言葉に引っ張られる傾向があるので、「馬に乗る」という前提から離れることができません。ここで人間が「馬である必要はない」と入力することができれば離れることができますが、当時の人々からして馬以外に高速で移動する手段は思いもよらないはずです。ですから、「人間の指示した範囲内でしかAIは答えを出すことができない」と言ってしまっていいでしょう。
そして、先述の回答を見てもわかるように、AIの出す答えというのは非常に「それっぽい」です。ですので、人間はそれを思考停止して受け入れがちです。結果として、AIが考慮していない「ビジネス固有のドメイン知識」や「法務・運用上の制約」が抜け落ちてしまった場合、AIはそれを指摘することはできず、後工程で致命的な手戻りを生みます。バグ発見は後工程になればなるほど修正に時間がかかるというのは有名な話ですから、AIの考慮の及びにくい「Why」の領域に光を当てるのがAI時代においては何より重要になってきます。
それが今後のQAの重要な役割になってくるでしょうし、そのための土台になるのが関係者を交えた「認識合わせ＝話し合い」だと私は考えています。
freeeのQAエンジニアが実践する「認識合わせ」の技術
フリー社内では、この「認識合わせ」のために大小様々な場が設けられています。必ずしも全てを行わなければいけないというわけではなく、そのチームに属するQAの裁量に委ねられている部分もあります。
- 起きては困る事象を認識合わせするための、「リスク洗い出し会」*1
- 案件について実例を使用して話し合う「実例マッピング」*2
- PdM, SWEと認識を合わせてテストケースを仕様として扱う「ATDD（受け入れテスト駆動開発）」*3
- 「この要件を元にテストできるか？」ということを確認するための「要求・要件一覧」*4
- 後工程寄りにはなりますが開発関係者を集めて成果物を眺める「ミニぽち会」*5
などなど、具体の方法論はたくさんありますが、今回はその詳細を一つ一つ語ることはしません。（興味があれば脚注に関連リンクを貼り付けておくので読んでみてください！） 共通しているのは、「関係者を集めて、全員で品質について考え、認識を合わせて前に進む」ということです。
その中で、QAエンジニアは主に以下のような役割を果たしています。
- 関係者全員で「ゴールの解像度」を上げる
- 「本当にその課題は解決されるのか？」「別の課題は発生しないか？」といった視点の提供
- 「開発者以外」をいかに巻き込むか
- 手戻りの多くは、運用・サポート・法務など「後工程」の視点漏れで発生する。
- QAがハブとなり、彼らの懸念を「開発初期」に引き出す。（例：サポートが困る問い合わせパターン、法務的なリスクなど）
- 「完璧なデモ」より「雑なプロトタイプ」
- AIが生成したモックアップなども活用し、「作ってから見せる」のではなく「作る前に見せる」文化を作る。
課題と乗り越え方
おそらく、ここまで読んで「認識合わせが大切なことはわかった（もしくは最初から分かっている）けど、実際やろうと思っても難しい」と思う方もいらっしゃると思います。
- 「忙しくて集まれない」と言われる
- 「仕様書に書いてある」と言われる
などがその一因かと思います。「チームで品質を良くしていこう」という認識がチームにないと、こういった問題が発生しがちです。これに対し、たとえば以下のような試みができます。
- QAが「問いかける」役割を担う（例：「このリリースで〇〇さんは困りませんか？」と、あえて特定のステークホルダーを指名して問いを立てる）
- たとえば法務やカスタマーサポートなど、普段直接開発に関わることはないもののリリース内容を知っておきたい方にとって、情報を共有される機会は結構貴重だったりします（実体験あり）。特にリリース後に知った場合、最悪トラブルシューティングでその人の仕事が増えるのでそれはそうですよね…。
- 小さく試しにやってみる（例：必要な準備は全部QAが行った状態で実際に場を設けてみる）
- 効果を実感できていないものに対し乗り気になる人は少ないです。まずはQAが音頭を取ってやってみることで実際に体験でき、「これいいね！」となることがあります。
- たとえば「ミニぽち会」などは15分ほどですが、さすがにその時間が取れないということはあんまりなさそう。
終わりに
AIはあくまでも「ツール」です。ですから、結局それを使いこなす人間が進むべき方向をきちんと示してあげなくてはならないし、そのための泥臭いともいえる「認識合わせ」がなくなることは当面ないんじゃないでしょうか。（少なくとも今後数年レベルではなくなる未来が見えてないです）
AIでスマートに仕事をこなすのにも憧れますが、ここ最近物量テストやらここにも書いた認識合わせやらが多く、「地道な仕事」もたくさんあるよな〜と思う今日この頃です。
明日は、グローバルQAのson-sanが「Performance Testing 101: The Importance of Performance Testing」について語ってくれます。お楽しみに〜！
それでは、良い品質を〜
*1: freeeの品質トゥギャザー：リスク洗い出し編 https://developers.freee.co.jp/entry/risk-together
*2: チームで実例マッピングをやってみた https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day5
*3: freee Tech Night「事故ゼロで実現！ freee人事労務の権限管理機能、進化の舞台裏」 https://www.youtube.com/watch?v=izTlGhVmAuY
*4: 仕様検討段階でのQAの関わり方やチームでの品質保証について https://developers.freee.co.jp/entry/freee-qa-adventcalendar-2024-day4
*5: 仕様検討段階でのQAの関わり方やチームでの品質保証について https://developers.freee.co.jp/entry/freee-qa-adventcalendar-2024-day4
