AIで動作検証を引き取ろうとして、目的を置いてきた
AIコーディングで、エンジニアの開発は圧倒的に速くなった。これだけ速くなると、タスク管理にも影響が生じる。
僕が在籍してたチームでは、進捗をカンバンで管理していた。AIでコーディングするようになってから、目に見えて「動作検証」ステータスにタスクが滞留するようになった。以前は多くても5件程度だったのに、それが常時10件を超えて滞留していた。
当時エンジニア側のマネージャーだった僕は、これもAIを使って解消しようとした。でも、うまくいかなかった。今回は、この失敗を振り返って、チームの仕事を考えていきたい。
なお、今回も「継続型チーム」を対象にしてる。特徴は「セールスやディレクターなど、エンジニア以外の職種メンバーと共にチームが構成」されること。詳しくは以下の記事に書いた。
2026-09-16プロジェクトじゃないのに、プロジェクト管理ツールを使っていたサービスを運用しながら改善し続けるチームは珍しくない。それなのに仕事の見た目がプロジェクトだから、ツールとのミスマッチに気づかない。僕自身がそうだった。
yamataka.blog
動作検証の目的と、滞留した原因
僕たちのチームでは、エンジニアによるテストに加えて、セールスやディレクターなど、その要件を立案した（エンジニア以外の）メンバーによる「動作検証」をしていた。その目的は大きく2つある。
- 頼んだとおりに作られているか（エンジニアの理解と、ずれていないか）
- 実際に動かしてイメージを膨らませ、機能を磨き込む（要件の追加や変更）
タスクが滞留した原因は、実装フェーズが格段に速くなり、大量のタスクが検証フェーズに流れ込んだため。動作検証にかかる時間は変わらないので、滞留する。
検証がボトルネックになっていたので、その解消を狙った。
AIを活用して、動作検証もエンジニア側で引き取りたい
動作検証では、「どんな確認をするか」その内容も含めて、検証の担当側に委ねていた。エンドユーザーを理解したメンバーの観点で確認してもらうために、エンジニアの観点を含めたくない思いもあった。それに、AIコーディング以前の手でプログラムを書いていた時代は、エンジニアの実装フェーズがボトルネックだったため、動作検証などエンジニア以外が担える作業は、そちらに寄せていた経緯もある。
でもその結果、エンジニアのテストと重複に見える動作検証も多かった。テストを二重でしてる状況とも言える。
動作検証の目的のうち、「磨き込み」は価値が高い。実際に触ることでイメージが膨らみ、機能をより良く改善できるのなら、時間をかける価値がある。一方で、「頼んだとおりか」の確認は、チェックリストが要件を満たしていれば、あとは誰が確認するかは問題にならないと考えた。
そこで、動作検証の作業の一部を、エンジニア側で引き取れると踏んだ。具体的には、AIコーディングの延長で、エンドユーザーを観点としたチェックリストもAIで生成し、それにそって動作検証もエンジニア側が担う。その後、動作検証の依頼時に「この内容で既に確認済み」を共有できれば、重複した検証を削減できるはずだ。そうすれば「磨き込み」に集中でき、検証が軽くなると考えた。
滞留は解消されなかった
しかし、この引き取りはうまくいかなかった。エンジニア側で検証を引き取ったのに、検証フェーズは変わらず滞留していた。
当時を思い返してみると、検証を引き取ったはずなのに、その後も動作検証側で従来どおりの検証がされていたように思える。それは、検証担当者から返ってくる報告が、それまでと変わらず「動作確認しました」といった内容だったからだ。
実は、今回の記事を書くまで、この矛盾を言語化できていなかった。でも当時から、その正体になんとなく気づいていた。僕は無意識のうちに、動作検証の担当者にチェックリストの『レビュー』を求めていたのだ。
検証担当に「この内容で既に確認済み」を共有できれば、それ以外を確認するだけでよくなると考えていた。しかし、それを把握してもらうには、向こうはリストを読む必要がある。更に、確かめたいのは「頼んだとおりか」なので、リストに記載された内容が誤っていればまだ指摘も可能だが、リストに書かれてない仕様の存在を見極めるのは、かなりの負担になる。
エンジニア以外のメンバーにとって、レビューは慣れない作業。だから、リストを読むくらいなら、これまで通り触って確かめたくなると、僕も思う。それに、磨き込みのためには、どのみち触ることになる。それならなおさら、触って確かめるほうがスムーズだ。僕は、2つの目的を別々に考えていたが、触る側にとっては1つの作業だった。結果として、動作検証を引き取ったつもりが、引き取れていなかった。むしろ、エンジニアも動作検証をした分、チーム全体の作業は重くなった。
引き取れないものを引き取ろうとした
AIを使うことで、エンドユーザー観点のチェックリストは簡単に生成できた。しかし、AIに要件を伝えたのはエンジニア。だからリストは、エンジニアの理解が正しいことを前提に作られている。でも、要件を依頼した側が確かめたかったのは「認識に齟齬がないか」だったはずだ。
その齟齬に気付けるのは、依頼した側だけにある。いくらエンジニアの理解から動作確認をしても、その齟齬を見つけることはできない。なのに、僕は動作検証という「作業」そのものだけを引き取っていて、その「目的」を置いてけぼりにしていたのだった。
まとめ：職種をまたいで引き取れるか
今回を振り返ると、きっかけは「重複」に見えたことにある。エンジニアのテストも、セールスやディレクターの動作検証も、操作が同じなので、検証も同じに思ってしまった。でも、確かめていたものが違った。エンジニアは「作ったとおりに動くか」を、検証担当は「頼んだとおりになっているか」を見ていた。同じ作業に見えたから、引き取れると思った。
継続型チームは、多様な職種から構成される。タスクを消化するのはエンジニアでも、その出所や出口はほかの職種のメンバーにある。出口にある作業は、見た目がエンジニアの作業と似ていても、目的は向こうの職種のものだ。職種をまたぐと、作業が似ているほど、目的の違いに気づきにくい。今回、僕はそこを見落としていた。
AIで実装が速くなり、エンジニアの手には余裕ができた。余裕ができたから作業を引き取れると、安易に考えてしまった。次に引き取るときは、作業だけでなく、その目的まで引き取れるのか。そこから見ていく。