AIが実装した。でも、誰が「完了」と判断するか。

AIを使うと、実装が速く終わる。

エンジニアが「できました」とSlackに書く。動いているように見える。でもそこで一つ問題が起きる。それは誰が「完了」と判断するか、という問題だ。

「動いている」と「完了」は違う

実装が速くなると、「動いているもの」が早く出てくる。早く出てくるから、確認も早く求められる。

でも「動いている」は「完了」ではない。完了には複数の判断が必要だ。要件通りに動いているか。エッジケースを拾えているか。クライアントが想定していた動きになっているか。セキュリティや負荷の観点で問題がないか——これらを誰かが確認して初めて完了になる。

AIが実装したコードは速く出てくる分、「誰が何を確認して完了と判断するか」の設計が追いつかないことがある。

完了の定義があいまいだと、手戻りが増える。

エンジニアが「完了」とステータスを動かす。プロジェクトマネージャーが確認する。「ここの動きが想定と違う」と戻ってくる。エンジニアは「要件通りに作った」と思っている。プロジェクトマネージャーは「こういう動きを期待していた」と思っていた。

どちらも間違っていない。完了の定義を最初に合わせていなかっただけだ。

AIで実装が速くなると、このサイクルが速く回る。手戻りが1日で戻ってくる。修正して1日で上がる。また戻ってくる——確認ループが高速になる。

解決策はシンプルだ。タスクを作るときに、完了の条件を書いておくことだ。

「このAPIが叩けること」ではなく、「この画面でAボタンを押したとき、Bの状態に遷移し、Cのメッセージが表示されること。エラー時はDのメッセージが出ること」。完了の条件が具体的に書かれていると、実装した側も確認する側も、何をもって完了とするかが一致する。

クライアントや発注側がタスクの完了条件を確認できる設計にしておくと、「完了と言ったけど想定と違った」の頻度が減る。完了条件への合意を、実装が始まる前に取る設計だ。

完了の条件を書くだけでなく、誰が完了を判断するかも決めておく必要がある。

AIで実装が速くなった環境では、1日に複数の機能が「できました」状態になる。それぞれについて「誰が確認するか」が決まっていないと、確認待ちのものが積み上がる。

タスクに「確認者」の役割を入れる設計にすると、「このタスクは岸本さんが確認してOKを出したら完了」という流れが明確になる。確認者がタスクのステータスを「完了」に動かす——それが完了の記録になる。

チャットで「OKです」と流れていった確認は、後から「あれ、誰が確認しましたっけ」になる。タスクのステータスが確認者によって動いていれば、「2026-08-27、岸本確認済み」という記録が残る。

外注先やクライアントが絡む場合、完了の判断は複雑になる。

外注先が「完成しました」と言っても、発注側が確認して問題なければ初めて完了だ。この確認のやりとりがチャットで流れていると、「あの件、最終確認終わってましたっけ」が後から出てくる。

タスクに外注先をゲストとして招待して、完了の条件をタスクに書いておく。外注先が「対応完了」のステータスにする。発注側が確認して「完了」に動かす——この流れを設計しておくと、「完了したと思っていたが確認がまだだった」を防げる。

AIで手が増えた分、確認を求める相手も増える。その確認のすべてに「誰が何をもって完了と判断したか」の記録が必要になっている。

AIで実装が速くなった結果、プロジェクトのボトルネックが変わった。

作るのは速くなった。でも「完了とは何か」「誰が確認するか」「確認した結果はどこに残るか」——この設計が追いついていないプロジェクトは、速く作っても確認ループで時間を使う。

完了の設計をタスクに組み込む。AIが速くなった分、ここに使う時間のコストパフォーマンスが上がっている。

完了の判断と確認記録をタスクで設計しながら外注先・クライアントと仕事を進める設計をPaqutで試せます。ゲスト招待は何人でも追加料金なし。