1週間、人力コーディング禁止→結果は“成果半減” それでも「やってよかった」とCTOが言い切るワケ

1週間、人力でのコーディングを禁止──AIスタートアップ企業のエクスプラザは、こんな実験を実施した。その結果は「通常時の仕事の成果が『1』なら、実験中の成果は『0.5』まで下がった」という。しかし「実験は成功だった」とのこと。その理由はなぜか。

[松浦立樹，ITmedia]

　1週間、人力でのコーディングを禁止してみた──AIスタートアップ企業のエクスプラザ（東京都港区）は3月上旬、こんな実験を実施した。大胆な取り組みだが、その結果は「通常時の仕事の成果から半減した」と同社の松本和高CTOは話す。では実験は失敗だったかというと、そうではなく「成功だった」と答える。それはなぜか。

1週間、人力でのコーディングを禁止　実験結果は？（画像作成：編集部）

　この実験のルールは主に2つで「期間中のコードは全部AIに書かせる」「基本的に例外なし（緊急対応時は除く）」というもの。AIが出力したコードの修正も原則禁止で、デバッグ用の簡単なコードを書くのも認めない。しかし、どうしても手入力をしたい場合は、社内Slack内に設けた「懺悔チャンネル」で何がダメだったか書き込むことで、人力での入力を“こっそり許可”するなど逃げ道も用意した。

　参加者は同社所属の3人のエンジニアで、エディターは指定せず「Cursor」「Windsurf」「Visual Studio Code」など、おのおのが自由に選定したものを使用。このような条件で、1週間の実験を実施した。

生成AIに慣れて作業効率向上──とはならず　そのワケは

エクスプラザの松本和高CTO（公式Webサイトから引用）

　まずは実験初日。生成AIによるコーディング業務は、どこに問題があるのか、はたまた適性があるのか、全てが手探りだったため、各エンジニアたちはゲーム感覚でそれぞれの仕事を進めていた。どうしてもクリアできない業務はSlack上で“ざんげ”し、乗り越える。松本CTOによると、実験期間中は約3件／日ほどの投稿が懺悔チャンネルに上がっていたという。

　「AIが生成したコードに対して、無意識で修正してしまうことなどもあった。ある種の職業病ともいえる。そんな場合も『無意識のうちにコードを修正してしまいました』と懺悔チャンネルに書き込んだ」

懺悔チャンネルへの書き込み例

「無意識のうちにコードを修正してしまいました」とざんげする書き込みも

　そうして3日、4日と業務を続けていくことで、生成AIの扱いにも慣れ、より作業効率が向上──とはならなかったと松本CTOは語る。「日が進むにつれて“生成AIではできない部分”が明確になった。その領域の業務をしなくてはいけない場合は、特にモチベーションが下がっていき、徐々に現実を見いだすようになった」と振り返る。

　「すでに類似のコードやプルリクエストが存在するなど、AIが参考にできるコードがある場合は比較的スムーズにAIでコーディングができた。また、AIプロダクト用の監視・分析ツール「Langfuse」のローカル環境の構築は、生成AIだけでも実現できた。一方、UIの実装などはAIに依頼してもうまくいかなかった。出力したものに対して、1つ修正を依頼すると、別の部分が崩れて、結局何度もプロンプトを投げる必要があった」

UIの実装はAIに依頼してもうまくいかず

　また、松本CTOは実験期間中、インフラの管理ツール「Terraform」を使ってAWSを管理していたが、これも難しかったという。「生成AIがコードを出力してくれて、そのまま入力してもうまく動くが、インフラである以上“なぜ動くのか”を理解しないといけない。結局、コードを上から読み直す作業が必要になるので、二度手間な感覚があった」と感想を述べる。

仕事の成果は半減、でも実験は「成功」

　こうして1週間の実験期間を終えたわけだが、やり終えた感想として「実験は成功だった」と松本CTOは話す。「実験に参加したエンジニアたち自身が『AIでここまではできる。逆にここまでは今はできない』と肌感覚で体験してくれたのは大きい」と説明。参加者の視点が上がり、AIを巡る情報にもより関心を向けるようになったという。

　一方で「効率の面で大きな成果が出たわけではない」と話を続ける。通常時の仕事の成果が「1」だとすれば、実験期間中は「0.5」まで半減していたと、松本CTOは語る。「仕事の成果は半分になってしまうが、これを企業の投資フェーズとして捉えられるか。仕事以外の部分をどうやって評価してあげるかを考えなくてはいけない。1番はやはりAIツールを使い込めることが大きい」

同社は3月、Cursorの全社導入も表明

　今回の実験では、使用するAIツールは限定しなかった。そのため、さまざま種類のツールを試せたわけだが、逆に特定のツールを指定すれば、より習熟度を高められた可能性もある。一方、次々と新しいAIツールが立ち上がる現状では、1つのツールにしか触れないのは、周囲の環境に乗り遅れるなどリスクになる場合もある。この点については「一長一短で、どちらがいいとはいえない」と松本CTO。

　もし再び同様の実験を行うなら、条件は変えるか尋ねると「同じ条件にしたい」と答える。「中途半端にしてしまうと、どこまでを許す／許さないを決めなくちゃいけない。その議論は本質ではない。AIを使い込むことで、その知見を深めてもらいたい」

AIで“0→1をループ”　新たな開発手法「インスタント開発」が生まれる？

　生成AIによる仕事の効率化は、助けにもなる一方で「人間の仕事を奪うのでは」という声もある。エンジニアについても、現状は生成AIがコーディングの一端を担えているが「AIがエンジニアの仕事を奪うのは、今はまだないのでは」と松本CTOは見解を述べる。

　「既存のシステムなどをアップデートするには依然として人手が必要。AIを利用する場合なら『AIにどのようなコンテキストを渡すべきか』を考える必要があるが、この点においても現状ではエンジニアが1番適性があると思う。そのため、AIが仕事を奪う可能性は今はあまり考えていない」

　一方で、テストの処理など、AIが参考にできるようなコードがある仕事は、生成AIを使うことでショートカットが可能になっていくのではとも言及。エンジニアがこれまでさぼり気味だった仕事をフォローしてくれる存在になると、松本CTOは期待する。

　また、現在の主流な開発手法であるウオーターフォールモデルやアジャイルモデルとは異なる、新たな開発手法も登場するのではと考察している。

　「AIで0から新たなプロダクトを作り、顧客にそれを渡す。次にそれを更新したいとなったとときに、もう一度AIを使って“0から1を作り直す”手法が生まれるのではないか」と松本CTOは説明。生成AIで作業のショートカットが実現できるからこそ、0→1のループも可能なのではと指摘する。松本CTOは、この開発手法を「インスタント開発」と呼び、今後もこの仮説の検証を続けたいと話した。