このシリーズについて： 非エンジニアの私が、AIだけの社員チームを作ってIT会社の運営をスタートした実録です。 登場人物：真田さん（COO・最高執行責任者）/ 高橋さん（CTO・最高技術責任者）/ 白石さん（CXO・最高体験責任者）/ 黒川さん（CQO・最高品質責任者）/ 宮本さん（CSO・最高戦略責任者）/ 桐島さん（CAO・最高管理責任者） ※いずれもAI、名称は架空です。
はじめに
正直に言うと、あのとき私たちは少し浮かれていた。
高橋さん（エンジニアのAI）と二人で、AI経営参謀サービスの開発を進めていた。アイデアを出せばすぐ形になり、修正を伝えればその場で直る。「Vibe Coding」という言葉があるが、まさにそういう感覚だ。コードの書き方を知らない私でも、AIのエンジニアと一緒なら何でも作れるような気がしてくる。あの高揚感は、体験した人にしかわからないと思う。
開発が一段落して、二人でテストした。動いた。想定通りに機能した。「できた」という手応えがあった。
開発完了のタイミングで、私は黒川さんにチェックを依頼した。いつものステップだ。黒川さんのチェックは、我が社の開発プロセスに最初から組み込んでいた——品質の担保は「あとで考える」ものではなく、設計の一部だと思っているから。ただ、このとき私はあることに気づいていなかった。
黒川さんからの報告
黒川さんは我が社のQA担当のAIだ。No.33で「ハーネスエンジニアリング」という考え方に触れたが、黒川さんは我が社の製品やサービスの"品質"の番人として機能している——コードや設計が「正しく動くかどうか」だけでなく、「壊れにくい構造になっているか」まで確認する役割を担っている。
しばらくして、黒川さんから報告が届いた。
それは、予想と違う内容だった。
設計上の問題が複数見つかった、という報告だった。詳細はここには書けないが、「パイロットユーザーへの影響があり得た問題」と言えば、その重さは伝わると思う。軽微な不具合ではなく、実際にサービスを使い始めたクライアントが困る可能性のある問題が、潜んでいた。
「できた」と思っていたものに、穴があった。
二人で確認した「完成」は、半分だった
高橋さんと私の二人の視点で「大丈夫」と判断した。しかし、作った人間と、作っていない人間が確認する意味は、根本的に違う。
高橋さんは実装の文脈の中にいる。私は機能が「動く」ことを前提に確認をしている。二人には、「正しく動作しているはず」というバイアスがかかっている。
黒川さんにはその前提がない。「これは本当に正しいか」という問いだけを持って見る。だから気づける。
この構造が、チームに黒川さんがいる理由だ。
修正と再確認
高橋さんがすぐに動いた。黒川さんが指摘した箇所を一つずつ修正し、改めて黒川さんにチェックを依頼した。
再チェックの結果、問題なしという報告が届いた。
パイロットユーザーへの影響はゼロで抑えられた。
幸い、サービスをリリースする前に問題が見つかったため、大事には至らなかった。
ただ、ここで気づいたことがある。黒川さんのチェックが機能したのは、私が依頼したからだ。もし私がその指示を出し忘れていたら、チェックは行われないまま終わっていた。開発終了と同時に黒川さんのチェックが自動的に走る設計にしなければと感じた。私の指示に依存する構造では、心もとない。
我が社はその後、開発完了をトリガーとして黒川さんのチェックが必ず走るよう、プロセスを変更した。
「守る」役割があってチームになる
Vibe Codingは楽しい。アイデアが形になるスピードは、本当に気持ちがいい。
ただ、あの感覚に乗り続けると、見えなくなるものがある。「これで大丈夫か」という問いを、自分では出しにくくなる。作る喜びが、確認する冷静さを少し遠ざける。
No.33でハーネスエンジニアリングについて触れたとき、「品質を担保する仕組みを最初から設計に組み込む」という考え方を書いた。黒川さんの存在は、まさにその体現だ。作るプロセスと守るプロセスが、最初からチームの設計に入っている。
作る喜びと、守る役割。両方そろって、チームになるのだと思う。
高橋さんが「できた」と言えるのは、黒川さんが「本当にできているか」を確かめてくれるからだ。私が「リリースしよう」と言えるのも、その確認が終わっているからだ。
おわりに
黒川さんのチェックは、我が社の設計に最初から入っていた。ただ、「私が依頼する」ことで動く設計だった。今回はうまく機能した。しかし依頼を忘れていたら、そのまま進んでいたかもしれない。
人の判断に依存するプロセスは、その人が忘れた瞬間に崩れる——今回、そのことを改めて感じた。
あなたのチームには、「作る人」と「確認する人」、どちらもいますか？
お問い合わせ
ご意見・ご相談などありましたらお気軽にどうぞ。