著者インタビュー（後編）：一流シェフのレシピは町中華では使えない、ビジネスセンスを持つQAの育て方とAI時代の生存戦略

——QAの価値が経営層に理解されたとして、現場のメンバーをどうやって巻き込んでいくのですか？

小林：いくら僕らが持っている知見やノウハウが「おいしいカレー」だとしても、今日カレーを食べたくない人に「このカレーはおいしいよ」と言っても食べてもらえないですよね。だから開発チームの中に入ったり、オブザーブしたりしながら、現場が何を求めているのかをずっと探り、こちらのやり方を押し付けないようにしています。その上でチームが困っていたら、「こんな考え方もあるけどどう？」「一緒に試してみよう」などと課題解決のお手伝いをする。そうやって少しずつ信頼を得るようにしています。

山本：現場の人たちそれぞれの品質に対する考え方があるから、エンジニアには開発の方法論やコードの問題点などの対話をするし、デザイナーやプロジェクトマネジメント担当にもその人たちに合った課題感で品質の話をしています。あとは、テストの腕っぷしを見せるのも大切で、実際に手を動かして問題を解決してあげると納得してくれることが多いです。

——経験豊富なお二人はうまく立ち回りができるわけですが、他方で、自分の意見を押し付けて失敗するQAエンジニアもいるのでしょうか？

山本：押し付けるというか、大企業のフレームワークを小さな会社にそのまま適用しようとした途端に、過剰品質になってしまい、スピード的にも規模的にも、コスト的にも合わないという失敗はしばしば起きています。相手に合わせてどうテーラリングするか、アジャストさせるかは大事。僕はたまたま数社でQAの仕事をやるうちに、そうしたスキルが身に付きました。

小林：品質管理やテストの方法論、フレームワークに関する書籍は世の中にたくさんあるから、それをまねすればいいと思うかもしれません。でも、それって一流シェフのレシピを町の中華屋がそのまま採用するようなもの。「こんな材料ないよ」となるわけです。開発チームのケイパビリティと成熟度に適したTIPSだけを取り入れて、渡してあげなければ駄目なのです。

——人材育成についてもお伺いします。QAエンジニアを育てる中で、どういうところを見て「この人は育つな」と判断してきましたか。

小林：「教科書通りにやればいいはず」といった原理主義に寄りすぎている人は、育つ、育たない以前に、単純に方向性が合わなかったという印象が正直なところです。ビジネスがまだ成功するかも分からない段階で、完璧なテストやスケジュール順守を求めて、「なぜ守らないんですか？」などとやられると、周囲は途端にストレスを感じてしまいます。

僕自身はこれまで接してきたメンバーに対して、「ビジネスを考えたら何をすべきか？」という考え方を伝えてきました。具体的に言うと、このプロダクトはどのようなユーザーに利用されているのかを念頭に置いて、品質を考えてほしいということです。例えば、バグが出た際、ユーザーが10人しかいないのに、多額のコストをかけて完璧にテストをする必要はあるかどうか。逆に、1回の施策で億単位の売り上げを出すようなゲームであれば、それに関するバグは徹底的につぶしたほうがいいと思うかどうか。そういったビジネスセンスがほしいですね。

——山本さんの場合、そもそもQAをやりたいわけではなくコード書きたいんだ、といった開発チームメンバーも多かったのではないかと思います。いかにモチベーションを持たせていったのでしょうか。

山本：僕自身の原体験なのですが、昔、システムインテグレーターでSEをやっていた頃、リリース前に重大な不具合を見つけると先輩に怒られました。「どうして今さらこんなものを見つけるんだ」と。でも、その後に転職した電機メーカーで同様のことをやったら、「ありがとう」とお礼を言われました。不具合を発見してくれたおかげでリコールが起きなかった、世の中の人に迷惑をかけずに済んだと。それがすごくうれしかったです。

だから僕もサービス開発の上流工程でクリティカルな不具合を見つけてくれたメンバーを称賛し、やってくれたことの価値をきちんと伝えるようにしています。そうすると、より上流で品質を担保しようとするマインドが少しずつ刷り込まれていくんです。場合によっては、開発側のレビューなど、領域を広げてもらうような提案もします。

——生成AIの活用が広がる中で、従来のQAのアプローチが通用しにくくなっている部分もあると思います。この現実にはどう向き合っていますか。

小林：コーディングがAIで自動になっていくのと同じで、テスティングもどんどん自動になっていくでしょう。そうなると、開発プロセスのどこにどういうQAエージェントを設計するのかを考えなければならない。金融系サービスや医療系サービスは品質管理の強度を高めなくてはいけないけれども、UIのボタンを1、2個変えるだけなのに同じようなコストをかけていたら、AIのトークンコストがかさんでしまいます。

従って、リスクベースでQAを開発プロセスに実装していくことが一つのポイントです。もう一つは、機械可読性の高いテスト環境やデバッグ機能を整えること。今まで人間がなんとなくやっていたテスト環境作りを、AIがアプローチしやすいように変えていかなければなりません。

——AIを使った開発モデルの進化に関してよく言われるのは、プロンプトエンジニアリングからハーネスエンジニアリングに来ていて、さらにはヒューマン・イン・ザ・ループ（HITL）※1 からヒューマン・オン・ザ・ループ（HOTL）※2 へという見方です。今、QAとしてはどのフェーズにいると感じますか。

小林：現実的に動いているのは、ハーネスエンジニアリング（AI活用のための実行環境や連携基盤を設計する考え方）とヒューマン・イン・ザ・ループのフェーズかなと思います。それ以上はまだですね。やろうと思えばできるのかもしれないですけど、AIのトークンコストの問題があって。

※1 AIによる処理や意思決定の過程に、人間による確認や判断を組み込む運用形態
※2 AIが自律的に処理を行い、人間は監視や必要時の介入を担う運用形態

山本：ビジネス的にはヒューマン・オン・ザ・ループよりもヒューマン・イン・ザ・ループの方がコスパはいいです。また、こまめにたくさんサービスを出すのが事業としていいのかどうかについて、アップデートも含めた時間軸で考えると、ヒューマン・オン・ザ・ループはコスパ、タイパ的にまだよくない状況です。1年後にはどうなっているか分かりませんが。

——AI活用が進む中でも生き残っていくために、QAエンジニアはどんな技術をキャッチアップすべきでしょうか。

山本：ヒューマン・イン・ザ・ループの中で、各プロセスの中間成果物が一定基準を満たしているかどうかを判断するためのテスト技術や設計技術、品質保証の技術は必要だと思います。システムテストをやってみたらまだ不具合残っていたという話がある時に、その検出状況が妥当かどうかを自分の中に経験として持っていることが重要です。AIに「仕様書からテストケースを作って」と言えば、ある一定のものは作れてしまいます。

でも、どういう観点を出すか、どのテスト技術を適用するかについての知見がないと、後から重大な問題が起きてしまいがちです。テスト技術力や品質保証力といったベーシックなスキルを身に付けていなければ、結局、AIに振り回されて終わってしまうと思います。

小林：僕はもう一つ、組織のコンディションを見る力もこれからの人間の価値だと思っています。AIはデータ上でしか理解できませんが、僕らはチームで働いている人たちの表情を実際に見られるじゃないですか。心理的安全性が高い組織の方が開発生産性も高いというデータもありますし、究極の品質管理とは組織のコンディションではないかという考え方もあると思います。

今、あちこちの開発現場において「AIでうまくいきました」という声を聞きますが、それらは大抵、その組織にもともと決まった開発プロセスがあって、それをAIに置き換えているだけなんです。このこと自体は間違っていないし、生産性も上がっているのでしょう。ただ、単なる置き換えで、AIにとっての最適なプロセスではないわけです。ですから、プロセスの改善よりも、プロセスのリビルディングをQAが先導しなくてはならないと感じています。人間が読む仕様書ではなくて、機械可読性の高い仕様書を作れば、AIが間違えずに実装できるし、そこからテスト項目も作れる。テストの答えが仕様書になければ仕様書側を直すというループを回せる仕組みを、QAが構築していく必要があるでしょう。

——最後に、読者へメッセージをお願いします。

小林：この本は、学術的にきれいに体系立ててまとめたものだとは思っていません。あくまで僕ら二人の経験談を書いたものです。いろいろな人たちから「スタートアップ向けの QA の本がない」「最近のクラウドやSaaS系サービスに適した品質管理をまとめた本がない」という声を聞いてきました。僕らも調べてみたところ、体系的にまとまった実務書が見当たらなくて、僕らの生の経験が一番だと思っています。

山本：僕としては、事業を進める上で端から端まで薄く広く、重要なポイントを踏まえて書いたつもりです。皆さんが困っていることにもヒットする部分がきっとあるのではと思います。この本はインデックスというか、入門書みたいなもの。興味を持った領域があったら、そこからさらに深掘りして、他の本や世の中の事例を見てもらえるとうれしいですね。

——ありがとうございました。