最近、会社の新しいプロジェクトのサブプロジェクトで、新しい開発方法を実験しました。できるだけ多くのコードをAI（Cursor）で書き、人間の介入を最小限に抑えることで、未来のソフトウェア開発モデルを理解しようとしています。
AIの助けを借りて開発サイクルを大幅に短縮できることを期待していました：
もしあなたも少し大きなプロジェクトでこれを試したことがあるなら、初期の結果がどうだったか想像できるでしょう：
AIに少し多くのことをやらせようとすると、期待通りに動かないことがよくありました。一度で完了できる作業は、通常、簡潔で明確で曖昧さのないタスクです。これらは通常うまくいきます。
もちろん、これでAIを使った開発をやめるわけではありません。今では80〜90%のコードをAIで開発しています。対話を通じて大量の開発を行っています。AIには深い技術力があるので、私は真剣に監督者として、彼の仕事が期待通りに完了するようにしています。
しかし、どうすればこの段階に到達できるのでしょうか？プロジェクトにAIを導入する前に、チーム内で通常どのようにソフトウェアプロジェクトを開発しているかを振り返る必要があります。
従来のソフトウェア開発の議論
従来のソフトウェア開発プロセスでは、チームは製品の観点から戦略的な議論を行い、エンジニアリングチームが技術的なソリューションについて議論します。会議と文書化を経て、最終的に合意に達した後、反復的な開発を通じて製品が徐々に開発されます。
ソフトウェア開発プロセスで重要なのは、チームの合意とコンテキストです。数語でAIに理想的なシステムを作成することを期待するだけでは、最も重要な合意とコンテキストを伝えることができません。
AIはあなたの心を読むことはできません。短い会話からこれらのコンテキストを知ることはできません。
チームは会議と文書を通じて合意を形成し、コンテキストを整理できます。では、AIにこのような情報をどのように提供すればよいのでしょうか？いくつか試してみることができます。
ルールで方向性を定義する
Cursorではルールを定義できます。質の高いルールを書くには多くの時間をかけて検討し改善する必要がありますが、ルールはAIに大まかな方向性を示し、チームのスタイルにより近づけることができます。
たとえば、テストを書くべきか？どの程度まで書くべきか？どのようなgit commit messageを好むか？コンポーネントの記述規則、命名規則、採用する技術スタックは何か？これらを説明しないと、彼はしばしば好き勝手にします。チームに加わったばかりで、開発文化にまだ適応していないソフトウェアエンジニアのようなものです。
仕様（Spec）を分割し、段階的に進む
実装前に機能仕様を書きます（もちろん彼に書いてもらいます）。仕様を十分に読んで議論し、彼がやりたいことがあなたがやりたいことと同じであることを確認してから、実装を依頼します。
機能仕様をすべて自分で書く必要はありません。私たちの場合、通常、プロジェクト管理サービス（Asanaなど）でタスクを作成した後、私がそのタスクで何をすべきかを伝え、仕様を書いてもらいます。その後、展開された仕様について議論し更新し、仕様が完成したら新しいChat Contextを開いて、その仕様に従って実装してもらいます。
仕様の質が良くないと感じたら、specを生成するruleを修正し、チームが今後specを生成する際により良い文書品質が得られるようにします。
仕様の長さはチームの習慣によって異なりますが、短い方が読みやすく、私たちの意図に沿って開発しやすくなります。これは目標をより良く達成するのに役立ちます。
前述したように、コンテキストや合意がないと、望む製品を作ることは非常に困難です。Ruleを通じてコンテキストと合意を確立することに加えて、この問題を回避する別の方法は、目標を設定した後、すべての仕様を一度に書かずに、完成しようとしている機能の仕様だけを書くことです。
彼が書いたspecに基づいて進む方向を修正するため、specを書いて実装するたびに偏差を修正できます。これにより、プロジェクトがアイデアから実際の製品への道を予想される方向に進むことができます。
仕様には受け入れ条件が必要
仕様の内容はチームごとに異なりますが、受け入れ条件（Acceptance Criteria）を含めることをお勧めします。この受け入れ条件は、AIに何が完了したかを明確に伝えるためのものです。このような明確な条件により、AIはどの程度まで完成させる必要があるかをより具体的に知ることができます。
受け入れ条件にはさまざまな方法があります。エンジニアの観点から見ると、単体テストや統合テストなどの自動化されたテストや検証で代替できます。また、Webアプリケーションを開発している場合は、microsoft/playwright-mcpを使用してAIにブラウザを開いて現在の結果を確認するように指示し、Webページを操作して検証させることができます。
現在の成果をより適切に判断できれば、完成度を判断し、後続のアクションを取ることがより簡単になります。
自動検証ができない場合は、手動テストの方法をリストアップしてもらい、開発者が自分で検証してから結果を伝えることもできます。もちろん、彼が自分で検証し、自分で修正できる方が良いです。
これまでのところ…
私たちもこのような開発モデルを試している最中で、このプロセスで調整が必要な部分が多くあります。現在、rules -> spec -> implementationというワークフローはまずまずうまく機能していると感じています。specを書く際にAIと議論し、計画を更新する機会があるため、作業を開始する前に、私たちが完成させたい形に調整できます。
しかし、Cursorがルールを守るのがあまり得意でないという問題にも直面しています。時間が経てば、これらの問題は徐々に修正されるか、より良い実践方法が蓄積されるはずです。しかし、その日が来るまで、私たちは頻繁にルールを修正する必要があります。現在、ルールが長すぎると忘れがちになり、明確で短い方が良いと感じています。また、ルールの記述も重要です。なぜなら、AIが特定のルールを適用したいと思うタイミングに影響するからです。
また、最近多くの人がVibe Codingについて話しています。これは、ほぼ直感的な方法で対話を通じて開発し、実装の詳細をあまり気にしないというものです。
しかし、実際には「直感」の大部分は、ある分野で深い背景知識と経験を持っているために、労せずして「直感」で完成させることができるように見えるだけです。実際には誰もができることではなく、表現力も関係しています。
この段階に達するには、操作する人がその製品の分野について十分に深い見解を持ち、十分に繊細で明確な表現力を備えている必要があります。
私は、誰もが自分の視点から、AIと一緒にソフトウェアプロジェクトを協働開発する方法を見つけるべきだと思います。ソフトウェアエンジニアであり好奇心旺盛な人として、また長年の執筆で一定の表現力を蓄積してきたため、私に適した方法でAIと協働し、ニーズをより正確に記述し、作業を分割し、受け入れ条件とソフトウェア開発の好みを設定し、自動化テストの方法を使用してAIがより良い仕事をできるようにします。
私は自分の視点から出発し、自分が何が好きで何が得意かを理解し、AIとのワークフローをカスタマイズしました。この相互作用の中で、コードを書くことよりも製品を作ることの方が好きだということに気づきました。AIと対話することで、この2つをより明確に分離し、自分自身を理解する機会が得られました。
そして、誰もが異なります。私のアドバイスは、自分が何が好きで何が得意かを振り返り、AIと協働する適切な方法を見つけることです。自分自身を理解することに近道はなく、誰もが多くの時間をかけて探求する必要があります。
もしあなたの興味が自分でコードを書くことであり、そのプロセスが幸せをもたらすなら、AIを使わない方があなたにとって最善かもしれません。浦沢直樹のインタビューでは、AI絵画についての見解が述べられています。彼は言います：「私は絵を描くことがとても楽しいと思っていて、私のように仕事の中で楽しみを見つけられる人にとって、AIに任せてしまうのはもったいないと思いませんか？」
大衆が追求しているものが、必ずしもあなたに適しているとは限りません。自分がどのような人間で、何に情熱を持っているかを振り返り、自分自身の視点で次のステップを踏み出す必要があります。
AIが人の言葉を理解できなくても構いません。あなた自身を理解しようとすることの方が重要です。