開発をAIで高速化した現場で、静かに消えていくもの

開発にAIを入れて、実装は速くなった。ところが、リリースまでの期間は思ったほど短くならない。そういう状態にある企業から、テストについてのご相談をいただくことが増えました。

業種も規模もさまざまですが、入り口にある問いは、だいたい共通しています。テストの工程は、いずれ全部AIで処理できるようになるのではないか。だとすれば、費用は大きく下がるはずだ。そして、人の関わりも減っていくのではないか。

先に申し上げておくと、これらは的外れな見通しではありません。実行の部分は、実際に人の手を離れつつあります。規模によっては、人が全数を確認するほうが非現実的です。費用の発生構造そのものも変わります。半分は当たっている、というのが私の実感です。

ただ、残りの半分がどこにあるのかは、あまり共有されていないように思います。それはAIの性能の話ではなく、速くなったときに、何が一緒になくなるのか、という話です。この記事では、そこについて書きます。まず、なぜこうした期待が生まれるのか、いま現場で起きていることから始めます。

まず、開発に何が起きたのか。この1、2年で最も大きく変わったのは、その進め方でした。AIが設計を助け、コードを書く。実装のスピードは、以前とは比較にならない水準になりました。

一方で、テストはどうか。テスト計画を人が立て、テストケースを人が書き、人が実行する。ツールを使っていても、動かしているのは人です。工程としての形は、数年前とほとんど変わっていません。

つまり、いま多くの現場で起きているのは、開発とテストのうち、開発だけがAIになった状態です。

この状態では、開発がどれだけ高速化しても、リリースまでの期間はあまり短くなりません。

理由は単純で、開発の速さは、多くの場合、期間を縮める方向ではなく、同じ期間により多くの機能や変更を作る方向に使われるからです。開発が倍の量を出せば、テストに渡される量も倍になる。一方、受け取るテストは、実行するのが人で、一日は八時間しかない。増えた分は、そのまま後工程に積み上がります。押し出された先にテストがあり、リリース日は動かない。この構造自体は以前からありました。変わったのは、押し出される量です。

では、詰まったときにどうするか。従来の答えは決まっていました。人を足す。外部に出す。オフショアを使う。いま、この選択肢は取りにくくなっています。技術的に破綻したからではなく、私の見る限り、経営が許容しなくなったというほうが実態に近い。AIによる生産性向上が期待されるなかで、増員の稟議は通りにくいのです。

自動実行ツールを入れた、という話もよく聞きます。多くが同じところでつまずきます。動くようにはなるが、改修が入れば作ったものをまた直すことになり、変更に追従できない。ここでも変わったのは実行の速さだけで、何をテストするかを決め、ケースを起こし、結果を判断する部分は、人に残ったままです。

そして、代わりに降りてくるのが「AIで解決しろ」という号令です。商談でお会いする方の多くは、選択肢を比較してAIに辿り着いたというより、他の手を封じられたうえで、AIを前提に考えることを求められています。

ここまでは、多くの方が実感されているところだと思います。開発だけが速くなり、テストが追いつかない。量の問題です。ただ、この開発だけがAIになったという状態が抱えているのは、量の問題だけではないのではないか。それが本題です。

一度だけ、商談でこう言われたことがあります。

「開発で使っているAIに、テストも全部任せられますよね」

そのときは、深く議論せずに終わりました。同じことを言われたのは、後にも先にもその一度きりです。

ただ、この言葉はずっと引っかかっています。頻繁に聞くからではありません。むしろ逆で、一度しか言われていないのに、条件のほうはどの現場にも揃いつつあると思うからです。前の章の状態を素直に見れば、開発で使っているものをテストにも使うのは、次に来る発想として自然です。開発の延長でテストまで完結できたら理想的だ、と考えている方は少なくないと思います。

しかも、この発想には利点があります。開発を担ったAIは、その仕様書をすでに読んでいます。何を作ろうとしているのか、どういう前提で設計したのかを、文脈として持っている。ゼロから読み込ませるより効率的であり、仕様の取り違えによる手戻りも減りそうに見えます。多くの工程では、これは正しい判断だと思います。ただ、テストに関しては、この利点がそのまま弱点になります。

品質保証の世界では、古くから言われてきたことがあります。作った主体とテストする主体が同じだと、確認できることは限られる、というものです。仕様の読み方に誤りがあった場合が分かりやすい。誤った読み方のまま実装し、同じ読み方のままテストすれば、実装は仕様どおりに見えます。読み違いは、読み違いとして検出されない。確かめられるのは「解釈どおりに作られているか」であって、「仕様どおりか」ではない。だから開発とテストは分け、第三者の目を入れる。

そして、先ほどの利点——すでに仕様を読んでいるから話が早い——は、言い換えれば「同じ解釈を引き継いでいる」ということです。効率的である理由と、危ない理由が、同じところにあります。

AIの場合、これが少し厄介な形で効きます。組織としては、開発チームとQAチームが分かれていることが多いと思います。担当者も承認フローも違う。形式的には独立しています。しかし、両者が同じモデルに同じ仕様書を読ませていたら、どうなるか。

厳密に言えば、同じモデルでも出力は毎回同じではありません。だから「同じ答えが返ってくるから危ない」という話ではない。問題は、同一性ではなく相関です。同じ訓練を経たモデルは、同じ癖で仕様を読みます。開発が読み違えた箇所は、テストも同じように読み違える見込みが高い。テストが、独立した試行になっていないということです。組織図の上では分かれていても、間違い方が分かれていません。

人が相手なら、この感覚は自然に働きます。自分のコードを自分でレビューするのは望ましくない、とは言われなくてもわかる。ところが、同じAIを二つの工程で使うことに違和感を覚える人は、あまりいません。ツールは統一されているほうが良い、という感覚のほうが先に立つ。しかも、AIの出力に、どのモデルがどう解釈したかは書かれていません。分けたつもりで分かれていなくても、成果物からは気づけない。

対処のしようはあります。テスト側に別のモデルを使う、読ませる情報を変える。難しい話ではありません。ただ、私が気になっているのは、そこではありません。

この独立性は、誰かが設計したものというより、作る人と確かめる人が別だったから、自動的に成立していたものです。意識的に守ろうとしなくても、自然に維持されていた。だから、失われるときも誰も気づかない。決めて手放したのではなく、いつのまにか無くなっている。

そして、こういう性質のものが、もうひとつあります。

こちらは、独立性ほど知られていないと思います。

システムの品質には、層があります。仕様どおりに正しく作られているか、という層。そして、実際に業務で使ったとき、利用者の役に立つものになっているか、という層。前者を「作る品質」、後者を「使う品質」と定義します。

この二つのギャップ自体は、今に始まった話ではありません。「作る品質」の基準は詳細に書かれます。書かれていなければ実装できないからです。一方、「使う品質」は、要件定義書に「使いやすいこと」「業務が滞りなく回ること」と書かれていても、そこからテストケースは起こせません。では、なぜこれまで大きな問題にならなかったのか。人が時間をかけていたからだと思っています。

テスト設計では、仕様書を隅々まで読むことになります。何を確かめるべきかを考え、条件を洗い出していく過程で、書かれていないことに気づきます。この画面、実際の業務ではこの順番で使うのではないか。この項目、毎回入力するとしたら現場は大変ではないか。仕様には反していない。ただ、使う人のことを考えると違和感が残る。テスト実行でも同じで、仕様どおりに動いてはいるが、これを一日に何十回もやるのはつらい、と気づく。こうした指摘は、テスト設計者やテストエンジニアから実際に上がってきます。

重要なのは、これが依頼された作業ではないことです。「使う品質」を確かめてくれと頼まれたわけではない。「作る品質」を担保するために仕様を読み込み、手を動かしているうちに、副産物として出てきたものです。そして副産物である以上、それは作業時間の中にしか存在しません。

AIが短くしたのは、まさにその時間です。仕様を読み込む時間、ケースに分解する時間、手を動かして確かめる時間。「作る品質」の担保という目的から見れば、純粋な改善です。ただ、その時間の中で発生していたものは、一緒になくなります。

正確に書いておくと、AIもこうした指摘をすることがあります。頼んでいないのに「この項目は入力の負担が大きいのでは」と返してくることは、実際にあります。ただ、人と違うのは、出てくる理由です。人の気づきは、時間をかけて読み、手を動かすという作業の構造から生まれていました。読む以上、必ず通る道だった。AIの指摘は、出ることも出ないこともあり、出なかったことには誰も気づけません。偶然の産物であって、確保された保証ではない。そして、それを確かめる責務は、いまのところ誰にも割り当てられていません。

私は「ネムラナイ」という、テスト設計から実行までを担うAIテストソリューションのプリセールスとして、AIに仕様書を入力してAIがテストケースを出力する工程を日常的に見ています。印象に残っている例があります。ある業務システムの仕様書は、画面項目ごとの入力チェックが丁寧に書かれていて、AIはそれを網羅するケースを出しました。一見、不足はありません。ただ、その画面が実際には電話で相手と話しながら使われ、入力が何度も中断される——それは仕様書のどこにも書かれていませんでした。中断と再開を確かめるケースは、AIの出力には出てきません。足したのは、ヒアリングでその使われ方を知っていた、人のテスト設計者でした。

仕様書に書かれていることは、テストケースまで渡ります。書かれていないことは、渡りません。だから当社でも、AIの出力をそのまま成果物にはしていません。

正直に付け加えると、これを課題として口にされたお客様の声を、私はまだ伺ったことがありません。相談は、何かが起きてから来ます。そして、この種の抜けはすぐには表に出ません。仕様どおりに動くシステムは、変わらず出来上がるからです。

これも、独立性と同じ形をしています。

二つ挙げました。作る人と確かめる人が別だったことで、自動的に成立していた独立性。作業に時間がかかっていたことで、副産物として出ていた「使う品質」への気づき。どちらも、誰かが設計した仕組みではなく、これまでの進め方の中に、たまたま含まれていたものです。だから、コストとして計上されたこともなければ、効率化の検討で、失われるものとして数えられたこともない。こういうものは、なくなっても気づかれません。

ここで冒頭の三つの問い——全部AIで処理できるようになるのか、費用は下がるのか、人の関わりは減るのか——に、答えられます。

全部AIで処理できるようになるのか。書かれていることの処理は、任せられます。そして、書かれていないことへの気づきも、AIが担えないわけではありません。書かれていない領域を類推させる、確かめるべき観点を先に与えて思考のガードレールにする——そうした設計次第で、AIはそこに踏み込めます。ただ、それは放っておいて起きることではなく、誰かがそう設計したときに起きることです。気づきを偶然に任せるか、仕組みにするか。その設計は、まだ人の仕事です。

費用は下がるのか。速くなった分の効果は出ます。ただ、これまで無償でついてきていたものは、ついてこなくなります。

人の関わりは減るのか。減ります。ただ、「作る品質」を担保する作業は圧縮できても、そこに同居していたものをどこで確保するかを決める必要は残ります。

では、どうするか。二つ挙げておきます。

一つ目は、確保のしかたも場所も、変えてよいということです。テスト工程で人が時間をかけて拾う形に戻すのが正解とは限りません。もともと工程に紐づいていたものではなく、たまたまテストの作業時間の中で発生していただけです。設計レビューの持ち方を変える。受入のタイミングで、業務の視点から確かめる場を一度だけ置く。リリース後に、実際の利用状況を観測する。自社の体制に合った場所で構いません。ただし、変えるのであれば、変えると決める必要があります。決めたうえで形が変わったのなら、それは判断です。気づかないうちに無くなっているのは、判断ではありません。

二つ目は、AI化を検討するときに、一緒に落ちるものを書き出しておくことです。検討資料には、たいてい効果が書かれています。どれだけ速くなるか、どれだけ工数が減るか。一方で、その工程が短くなることで一緒になくなるものは書かれません。もともと目的ではなかったからです。そこに一行、欄を作る。この工程を短くしたとき、これまでその時間の中で起きていたことは何か。書けなければ、落ちたときにも気づけません。逆に言えば、この一行が埋められる組織は、何をAIに任せるかを、安心して決められる組織だと思います。

これは外部委託かどうかとは関係のない話です。内製で回すのであれば、むしろ自分たちで決めておく必要があります。

開発が速くなって、テストが追いつかない。冒頭に書いたこの状況の解決を、私たちは「ネムラナイ」というソリューションで模索しながら、日々お客様と向き合っています。この記事に書いたのは、その過程で見えてきたことです。テストを速くしたとき、何が一緒になくなりがちなのか。同じ課題と向き合っている方にとって、この記事がそれを確かめる手がかりになれば幸いです。