AI コーディング、バイブコーディングが流行り始めて1年ほどが経ったと思います。一時期流行ったかにみえる「仕様駆動」ではありますが、各所、どのようなところに落ち着いたでしょうか？ という状態だと思います。
GMO の件、PHP2Shell の件でも分かる通り、AI コーディングは凄まじい勢いで発展（あるいは暴走？）していて、当初感じていた「AI コーディングの新人度具合」は消えてきています。まあ、分野にもよるんでしょうが、少なくとも Web アプリケーションを作る上では、ほとんど設計から実装までを自動化できます。暫く、半年ほどスマホアプリや組み込みから遠ざかってはいますが、今であればかなり良い線までいくのではないでしょうか。
ただし、ソフトウェア開発といっても分野はさまざまです。Web アプリケーションの場合は、Web サーバー（あるいは AWS のようなクラウド環境）とブラウザのみの知識と環境があれば大丈夫なのですが、組み込みなどではそうはいきません。AI の知識モデルが蓄積している量もそうなのですが、実機でのテストや試行錯誤などで人間の介在する部分が多いです。ある程度までは AI 任せにはできるのですが、Web アプリケーション開発のように、やたらめったらの試行錯誤をやられてしまうと人間側が疲弊してしまいます。アジャイル開発的な頻繁な要件の変更と実装への反映の自動化は、AI が 24 時間文句なく働いてくれる（課金はあるのですが）からこその開発方法であり、ここに人手が介在してしまうと、途端にそれが「ボトルネック」となり開発が頓挫してしまいます。
制約理論（TOC）の視点から言えば、このボトルネックを強化するか活用するのが最初の手段です。勿論、完全なバイブコーディングとして人を脇に追いやって自動コーディング環境を整えるのもひとつの開発手法ではあるのですが、現時点では組み込みシステムの場合はそうはいきません。ちなみに、スマホアプリの開発については、かなりの部分で adb と Appium 等を使って自動化できますね。これは別の機会に書いておきたいところです。
AI バイブコーディングを含めたとき、組み込みのテスト要員として「人間」が参加するのもよいのですが、これは限界があります。と言いますか、人間＝自分なので疲弊してしまいますね。AI に、こき使われるようなスタイルは好ましくありません。嫌です。
となると、最初の要件や設計をうまく AI に伝えていくことが、おおきな「ボトルネック」の活用になります。
半年ぐらい前には「仕様駆動」という形で、流行った時期もあるのですが、残念ながら「仕様駆動」の方法は人間に重たすぎます。正確には、IT 開発業界のトッププレイヤーには楽かもしれませんが、一般のひと達には無理です。あれほど厳密な要件定義や設計を書くことはできません。
だからといって、要件や設計が曖昧なままに進んでしまうと、AI バイブコーディングが無限のスパゲッティコードを吐いてしまいます。どれだけ AI に課金しても動かないゴミばかりを作ってしまうのです。これにより、AI コーディングを諦めて、人手のコーディングに戻ってしまった人も多いでしょう。
そのどちらが良いというわけではありません。いまのところ、AI コーディングにせよ、AI の活用にせよ、それは途中であることは間違いありません。
ならば、ひとつ手前に戻って「計画駆動/ウォーターフォール開発方式」の形で、要件定義や設計の工程を見直しておこうというのが、私の主旨でもあり、この講座の主旨でもあります。
もちろん、設計書作りに AI を参加させても構いません。ただし、AI が主として要件や設計をまとめるのではなく、あくまで AI の参加は従としてのサポート係に留めます。根本的な方針や方向づけは人間のほうがハンドルを握ります。
特に、組み込みシステムや業務システムの開発の場合には、この方法が有効です。
ただし「計画駆動」とはいえ、文書をたくさんつくって整合性を人の目だけで合わせる必要はありません。従来の計画駆動/ウォーターフォール開発では、要件/設計のトレーサビリティが大変だったのですが、今ならば、トレーサビリティ・マトリクスを AI に作成して貰うことも可能です。設計漏れや試験項目の漏れなどのチェックに AI を活用することもできるでしょう。
この講座では、主にソフトウェア工学の開発プロセスの基礎知識を解説するものですが、これからの AI 時代のコーディングを視野にいれて作成していますので、興味のある方は是非…とはいえ、有料ではありますが。
手戻りを防ぐソフトウェア仕様書・設計書の作成法とそのポイント