はじめに

2022年11月にOpenAIがGPT-3.5をリリースして以降、生成AIは爆発的な盛り上がりを見せています。
活用分野は画像生成、動画生成、マーケティング支援など多岐に渡りますが現時点で最も熱い分野はやはり開発領域と言って間違いないでしょう。

毎週のようにどこかのLLMベンダーがBig Newsを出したかと思えば、翌週には競合が同じような機能をリリースしたり、誰も知らなかったような企業が突然驚くようなプロダクトをリリースしたりと目が回るような速度で進化を遂げています。

一方で展開されている主要な開発領域のプロダクトは主に実装工程をサポートするものが多いように感じています。
本来システム開発は企画-要件定義-設計-実装-テスト-運用と多段階的な工程を経て完了されるものであり、昨今AIが実装工程に与えているインパクトを鑑みると実装工程以外の工程または工程全体の在り方自体が変わってくるのではないかと思います。

そこで本稿ではウォーターフォールやアジャイルなど従来型の開発手法をおさらいしたうえで現在のシステム生成AIプロダクトの問題点を考察し、AIを前提とした新たな開発手法を考えてみたいと思います。

従来の開発手法

概要

まずは従来の開発手法についておさらいです。
開発手法というとウォーターフォール、アジャイルが浮かぶと思いますが大きくは以下4つが代表的な手法として挙げられます。

1. ウォーターフォール

2. アジャイル

3. スパイラル

4. プロトタイピング

それぞれ部分的に似ていたり全く違うアプローチだったりしますが実際にはウォーターフォールまたはアジャイルとして開発プロジェクトが進められることが多く、部分的にスパイラル・プロトタイプの要素が活用されたりします。

なのでシステム開発の手法論に馴染みのない方はとりあえず

• ウォーターフォールはしっかり進める/ドキュメントたくさん/大規模向け/時間かかる

• アジャイルは柔軟に進める/コミュニケーションたくさん/中小規模向け/早い

だけ覚えればOKです。

以下で詳細を見ていきます。

1. ウォーターフォール

概要

• 要件定義-基本設計-詳細設計-実装-テスト-運用まで、工程を順序通りに一方向で進める直線的な開発手法（V字モデル参照）

• 基幹システムなど大規模システム開発ではほぼ必ず採用される伝統的な手法で、プロジェクト管理の方法論が体系化されているため全体を管理しやすく品質管理も行いやすい

• 各工程の成果物が徹底的にドキュメント化されるためチーム間の引き継ぎがスムーズ

課題

• 途中での要件修正や変更が難しく後戻りのコストが非常に高い

• 最終成果物が出るまでに時間がかかるため、ユーザーフィードバックを得るのが遅い

• プロジェクトが炎上しドキュメント更新が後手に回ると地獄になる

2. アジャイル

概要

• 小さな単位（2-4週間の短いスプリントで開発サイクル）で素早く繰り返し開発を行う反復的な手法

• スプリントごとに実装する機能（ユーザーストーリー）を決めていくため、柔軟な開発が可能

• アジャイル開発の中でもスクラム、XP（エクストリーム・プログラミング）、ユーザー機能駆動開発など詳細な開発手法が存在する

• 代表的な手法であるスクラムの場合はスクラムチームを構築しメンバーごとにプロダクトオーナー、スクラムマスター、開発チームなどメンバーごとの役割を明確に設定する

• 「緩く進める」という印象がある人もいるが、会議体・情報管理ツールなどチーム内のコミュニケーション設計は厳格に定義される

課題

• チーム間の連携が複雑でチーム構築初期はスピードが出にくい

• ドキュメント作成が後回しになる（ほとんど行わないケースもある）

• 熟練のアジャイル経験者がいない場合、プロジェクトが崩壊する

• 大規模プロジェクトではスクラムチームをサブモジュール化して進められるが、プロセス設計・コミュニケーション設計の難易度が格段に上がる

3. スパイラル

概要

• 段階的に機能を拡張していく螺旋状の開発手法でウォータフォール同様のサイクルを繰り返す

• アジャイルに似ているが機能ごとにリリースするか全機能が完成してからリリースするか、に大きな違いがある

• 初期開発からアジャイルと言っているプロジェクトは実質的にスパイラルであることも散見される

課題

• プロジェクト管理が複雑になるため、小規模プロジェクトには過剰な場合がある

• ウォーターフォールとアジャイルの中間のような開発手法であるため、チームの能力によっては中途半端になってしまう

4. プロトタイピング

概要

• 試作品を早期に作成し、それを初期要件→プロトタイプ作成→評価→改良のサイクルで改良していく実験的な開発手法

• 要件の具体化が早期に可能で先端技術を用いるプロジェクトなど要件が不明確なプロジェクトに適している

• ユーザーテストをすぐに実施できるようになるためフィードバックを早く得られる

課題

• プロトタイプに対して延々と指摘が続き納期遅れが発生する可能性がある

• ドキュメント作成が後回しになりやすい

• 一貫性を保った機能追加を実施するためにチームの技量が必要とされる

生成AIが開発領域に与えているインパクト

システム開発の手法論についてはなんとなく理解が進んだかと思うので、ここで視点を変えて開発領域においてどのようなシステム生成AIプロダクトが台頭しているか見てみましょう。

システム生成AIプロダクトは大きく以下4つに分けられます。

1. ノーコードツール

2. アプリケーション開発

3. プログラミング補助

4. AI内蔵エディター

上から順に非エンジニアの方が使いやすい作りになっています。
続いて上記の分類を踏まえどのようなトレンドになっているか考察してみます。

全体トレンド

大きなトレンドは2つあると考えています。

1.現場レベルでのエンジニアによるエディター活用

こちらは基本線というか王道的な使い方だと思います。コードを書いているとなんとなく処理フローは頭に浮かんでいるけどコードに書くのは面倒、や細かい修正だけど修正範囲が全体に及びいちいち直していくのが大変、などあると思います。

このようなシーンでAI内蔵エディターを活用することで作業時間を大幅に短縮できます。大企業やSI業界などセキュリティが厳しい界隈ではまだまだ導入が進んでいないようですが、確実に今後伸びてくると思います。

またこれらのエディターが登場した初期は細かい関数の修正など部分的な修正にとどまっていましたが、現在はCursor Composerをはじめとするプロジェクト全体を横断した修正や新規ファイルの作成など対象が広範になっており、今後も同様の方向性で進化していくものと考えています。

2.試験的なプロダクト開発への挑戦

現在リリースされているアプリケーション開発ツールを使うことで簡単なプロダクトであればものの1時間で作れてしまう世界線はすでに起こっています。
例えば自分しか使わないツールや社内向けの小規模ツールであれば既存プロダクトを探す時間よりも作る時間の方が短いかもしれません。

一方で実運用に耐えるプロダクトとして昇華するためにはまだまだエディターを使って修正する必要があります。また生成されるプロダクトは中小規模になっており、対外的に使ってもらうレベルのプロダクトを生成するには品質が足りていないと感じています。

代表的なプロダクト

それぞれの領域の代表的なプロダクトは以下の通りです。

1. ノーコードツール

Dify

• ノーコード/ローコードでのAIアプリを開発できるようにするプラットフォームで、プログラミング知識がなくても視覚的な操作でAIアプリを簡単に開発可能

• テキスト、画像、音声などさまざまなデータ形式（マルチモーダル）に対応しており、外部システムとも柔軟に連携できるため、幅広いニーズに応じたアプリケーションの開発が可能で特に簡易ツールのバックエンド開発であればDifyで対応できる

Create

• AIを活用してWebサイトやアプリを簡単に作成できるノーコード開発ツール

• 自然言語で作りたいWebアプリやホームページの指示を入力するだけで、AIが自動的にコードを生成する

2. アプリケーション開発ツール

bolt

• オンラインエディターを開発するStackBlitz社が開発しているプラットフォーム

• AIを活用してフルスタックのWebアプリを簡単に開発できるユーザーが自然言語で要件を入力すると、AIがコードを自動生成し、ブラウザ上で開発を行うことが可能

• ReactやVueなどの様々なフレームワークに対応しており、ワンクリックでNetlifyなどを使ってアプリをデプロイすることが可能

GPT Engineer

• GPT-Engineerは先ほどのbolt同様、自然言語での指示をもとにAIがコードを自動生成するツール

• 使い勝手もほとんどboltと同様なので触ってみて好みで使い分けることを推奨

3. プログラミング補助ツール

v0

• Vercel社が提供するAIを活用したノーコードのUIデザインおよびコード生成ツール

• ユーザーはテキストプロンプトやデザインモックアップを入力することで、高品質なUIコードを自動的に生成可能

• コードをボタン一つで公開する機能やオンラインエディターのように編集できる機能、複数ファイルをダウンロードする機能など便利な機能を次々開発しており、アプリケーション開発ツールとしての様相が強くなっている

Claude

• Anthropicが開発した大規模言語モデル（LLM）を基盤とするAIチャットボット

• 他LLMと比較してReactに強くそこそこきれいなUIを出力する

ChatGPT

• OpenAIが開発したLLMを基盤とするAIチャットボット

• プログラミング領域の特色でいうとo1という高性能モデルをリリースしており、特にo1-previewは2024年11月6日時点で最高性能のモデルとなっている

https://chatgpt.com/

Gemini

• Googleが開発したLLMを基盤とするAIチャットボット

• 高性能モデル、廉価モデルともに長いコンテキスト長を持っていることが特徴

4. AI内蔵エディター

Cursor

• AIとの対話による細かい修正や対象ディレクトリのファイル横断的な修正などAI技術を活用したコードエディタ

• MicrosoftのVisual Studio Code（VSCode）をベースに開発されており、VSCodeからの移行がスムーズで使い勝手もほとんど同様

Github Copilot

• GitHubとOpenAIが共同開発したAIベースのコード補完ツール

• Visual Studio Code（VS Code）やJetBrains IDEなどのプラグインとして利用でき、コードの自動補完や関数の提案、ドキュメントの生成などCursorとほとんど同じことができる

今後の展望

全体トレンドとしてエディター、アプリケーション開発に言及しましたが、ノーコードツール、プログラミング補助ツールがどのように進化していくか少し触れておきます。

まずノーコードツールは他のプロダクトと交わることなく独自路線で進化していくと考えています。なぜならターゲットユーザーが非エンジニアである以上、ノーコードツール単体で完結するわかりやすく使いやすいUI/UXを担保する必要があるからです。
もちろん将来的にはノーコードでより複雑なプロダクトを作れるようになるという未来を見据えていると思いますが、単体で完結させる必要があることを踏まえると少し時間軸が遠くなりそうです。

続いてプログラミング補助ツールですがプロダクトによって方向性が大きく異なります。特に開発領域に力を注いでいるのはv0で生成したコードをボタン一つで公開する機能やオンラインエディターのように編集できる機能、複数ファイルをダウンロードする機能などアプリケーション開発ツールに近い位置に来ているように感じます。
開発元のVercel社はデプロイ環境のVercelを持っていることはもちろんのこと、フロントエンド（フルスタック）フレームワークとして最も勢いのあるNext.jsを開発していることからも今後より伸びてくることは間違いないでしょう。
他のClaude、Gemini、ChatGPTは開発領域に特化したプロダクトではなく、LLMベンダーという立ち位置のため、今後もブラウザ・API提供で純粋なLLMの性能強化を目指すと思います。

台頭しているシステム生成AIプロダクトの問題点

ここまでで従来の開発手法と現在台頭している開発領域のAIプロダクト及びトレンドを見てきました。
改めて現状をまとめると以下のようになっています。

• 台頭しているシステム生成AIプロダクトは実装工程に関するプロダクトが多い

• アプリケーション開発ツールを使って大規模プロダクトを作ろうとすると全体の整合性を取りにくくなるため、中小規模までのプロダクトしか作れない

• 実用レベルのプロダクトを作るにはなんだかんだエディターが必要

特にシステム開発の手法論に近い位置にいるアプリケーション開発ツールにフォーカスしてみてみると、これらのツールを使った開発は単機能を組み合わせ積み上げていく形の開発です。
それゆえ規模が大きくなってくると全体の整合性が取りずらく、追加開発の際にバグ修正で工数が取られてしまい品質・スピードともに下がってしまいます。

この問題はまさにアジャイル開発で顕在化している問題と全く同じです。

AI時代の新開発手法

ではAIを使った開発は中小規模のアプリケーション開発及びエディターのような補助的ツールにとどまり、メインストリームになることはないのでしょうか？

先述しましたがアプリケーション開発ツールが中小規模にとどまっているのは土台のないところに枝葉を加えていくことで全体の整合性を取れないことが原因です。

解決策はウォーターフォールのように土台を作ったうえで開発を進めていくことだと考えています。
ただし従来のウォーターフォールに回帰することでスピード感・柔軟性が失われては本末転倒です。生成AIによりさらに変化が激化するIT業界では致命的になるでしょう。

そこでAI時代の新開発手法として超高速軽量ウォーターフォールを提案したいと思います。

これは何かというと従来のウォーターフォールに必要なドキュメントをそのまま作成するのではなく、AIのインプットに必要なドキュメントをAIにより生成することでドキュメンテーション工数を軽量化し高速でウォータフォールを実行する開発手法です。

そもそもアジャイルがスピード感を持って開発できるのはドキュメンテーションをコミュニケーションで代替しているからであり、アジャイルでメンバーにクオリティが求められるのは空中戦になりやすいからです。
なのでアジャイルの方法論はアウトプット定義というよりもコミュニケーション定義及びプロセス定義にフォーカスされたものが多いです。

現状のLLMは良くも悪くも入力された情報を処理して出力する魔法の箱のようなものなので、入力情報が乏しいまたは人間間のコミュニケーションに特化されているアジャイルはむしろAI開発とは相性が悪いように感じています。

今回紹介しているアプローチに一番よく似ているのはスパイラルだと思います。
基本コンセプトは要件定義から運用までを高速で回すことで柔軟性を担保するという点でよく似ています。
異なる点はリリースポイントです。もちろんスパイラルのようにフェーズに区切って大きな単位でリリースするのもありですが、AIをフル活用する超高速軽量ウォーターフォールでは機能単位の実装が比較的早期に完了するので、機能ごとにリリースすることが可能です。

超高速軽量ウォーターフォールのプロセスは以下です。

1. 企画・要求をもとに要件定義書を生成

2. 生成されたアウトプットを人がチェックし修正

3. 修正された要件定義書をもとに設計書を生成

4. 生成されたアウトプットを人がチェックし修正

5. 修正された設計書をもとにソースコードを生成

6. 生成されたアウトプットを人がチェックし修正

7. デプロイ

大まかな流れは従来のウォーターフォールとほとんど変わりません。しいて付け加えるとしたらAIの出力を全面的に信頼するのではなく、必ず人がチェックしましょう、ということぐらいです。
特にポイントになってくるのは各ドキュメントに必要な粒度でAIが読みやすいフォーマットにすることが重要です。
従来のウォーターフォールではソースコードを作成するための情報以外に人間同士のコミュニケーションを効率化するための情報が多く含まれており、これらを多く入れてしまうとAIでコードを生成する際にノイズとなってしまいます。

ではどんな情報が必要なの？という問いに対して明確な解があればいいのですが、正直に言うと自分もまだ試行錯誤している段階で現時点の最適解は以下です。

要件定義

• プロジェクト概要

• 業務フロー

• 業務要件一覧

• システム化業務フロー

• 機能要件一覧

• 非機能要件一覧

設計

• システム概要

• テーブル定義

• ER図

• 画面遷移図

• 画面一覧

• ワイヤーフレーム

• API定義

• シーケンス図

• アーキテクチャ

中でも特にポイントになってくるのが機能要件一覧、テーブル定義、画面一覧、API定義の4つです。

まず機能要件一覧については言わずもがな設計のベースとして効いてきます。設計で作成されるほとんどの項目のインプットになるので重複はまだしも抜け漏れがないようにしっかり作成することを推奨します。

続いてテーブル定義ですがこちらも設計において大きな土台になる項目です。特にAIを用いたソースコード生成ではファイル間の依存関係が課題となってきやすいのですが、テーブル定義を最初に決めておくことで後述の画面一覧、API定義でどのデータをどのファイルに受け渡しするか定義できるようになります。

最後に画面一覧とAPI定義では先述の依存関係を明確に定義することが重要です。どの画面でどのデータをどこから取得しどこにデータを連携するか、同様にどのAPIでどのデータをどこから取得しどこにデータを連携するか、を定義することでファイル数が多くなってもシステム全体として整合性の取れたソースコード生成を実現できます。

その他の項目ももちろん重要ですがいずれも人間が理解しやすいためであったり、重要項目を導出するための土台であったりということが多いです。

また全く別のアプローチとしてAIが必要とする情報のみに絞って要件定義とするアプローチもあります。カンダクオンタム社の元木さんが作っているKamui.aiはこのアプローチを採用しており、AIを用いたコード生成で特に課題となってくる依存関係をyamlファイルで定義し生成のインプットとしています。

生成されたソースコードはディレクトリ構成、依存関係がグラフィックで可視化されるため、ブラックボックス化しやすい生成されたコードを人間が編集しやすいUI/UXになっています。

従来型のドキュメントに追従した項目にせよAIが読みやすいyamlにせよ、これらのドキュメントを残すことはソースコードを生成する際だけでなく、実装工程で人間が手直しする際にCursorで参照しながらコードを生成させることで破綻の少ない修正を実現できます。

ただ言うまでもなく現時点のAIの出力は全面的に信頼できる品質ではないため、必ず人間がチェックする必要があります。
従来の開発手法（特にウォーターフォール）で用いられるドキュメントをすべて生成しチェックするとなると相当に時間がかかってしまうので、やはりAIを用いた開発には適した粒度のドキュメンテーションが必要なのだと思います。

なおドキュメンテーションについては新規開発を想定して記載しましたが、追加開発の場合は既存のドキュメントを参照しながら開発することで整合性を担保した開発が可能になります。
一方で機能単位で既存ドキュメントを更新する必要があるため、更新負荷は残っています。先ほど紹介したすべてのドキュメントを更新する必要があるわけではないため、どちらかというとアジャイルのような動き方になるかもしれません。

更新もAIに任せてしまえばすべて解決ですが、先ほど述べたように現時点のAIの性能では完全に信頼できるレベルではないため、人間がチェックする必要があります。ただし人間が関与する工数はどんどん減ってくると思います。
参照用ドキュメントとして使用するのであれば最低限テーブル定義の更新を怠らなければ、今のAIの品質でも開発効率が大きく変わるように思います。

ここまで超高速軽量ウォーターフォールについて書いてきましたが、もちろん開発体制やプロダクトの規模によってアウトプットのフォーマット・管理方法は検討が必要です。
例えば個人開発や規模の小さいプロダクト（ツールレベル）の場合は要件定義や設計は多少緩くて問題ありません。
先ほど挙げた項目を含むプロダクト概要、機能要件一覧、画面一覧、テーブル定義さえ押さえておけばAIツールを組み合わせてうまく開発を進められると思います。
チーム開発の場合はシステム規模の大小に関わらずしっかり作ることをお勧めします。

超高速軽量ウォーターフォールを実行するためのプロダクト

私が開発しているGEAR.indigoは超高速軽量ウォーターフォールを実行するためのプロダクトです。

先ほど挙げたような超高速軽量ウォーターフォールに必要な項目を含むドキュメントを生成し、生成したドキュメントをもとにNext.jsのソースコードを生成することができます。

ソースコードをローカルに落とした後の実装を見据えて、生成したソースコードが含まれるディレクトリにドキュメントの情報が入ったjsonファイルを格納しているため、CursorなどのAIエディターを用いて開発する際に参照しながらコーディングを行うことができます。

上記の他に工数見積もりやリバースエンジニアリング機能を兼ね備えており、プロジェクトマネジメントへの活用やドキュメンテーション全般への活用など開発現場において生成AI活用の指針となる機能を具備しています。

現在未実装ですが、今後一部ドキュメントの修正を全体に反映させる同期機能やプロジェクトマネジメントに関する機能の追加を予定しており、ここまで書いてきた超高速軽量ウォーターフォールの実現をサポートしていきます。

最後に

本稿ではウォーターフォールやアジャイルなど従来型の開発手法をおさらいした後に現在のシステム生成AIプロダクトの問題点を考察し、AIを前提とした新たな開発手法として超高速軽量ウォーターフォールを考えてみました。

この手法はAI開発で直面するシステム規模の大規模化に伴う全体不整合の問題への解決策として伝統的なウォータフォールのアプローチをベースに、AIをフル活用することでアジャイルのような速度で開発を進められる手法です。

そしてこのアプローチを現場レベルに昇華させることは長年ウォータフォール型の開発を極めてきた日本人だからこそできることだと思います。
海外の開発はアジャイルを基本として現場のエンジニアまたはテックリードが状況に応じて修正するスタイルになっており、各メンバーの技量に大きく依存しております（その分エンジニアの給与も高い）。

標準化された一つ一つの工程を丁寧かつ愚直に実行しドキュメント化して管理するウォータフォールのアプローチは日本人が培ってきた資産であり、これから本格化するAI駆動開発時代の大きな武器になると確信しております。

しかしこのアプローチはまだ始まったばかりです。実際に現場でこのアプローチを採用するとAIの精度が不十分なことにより想定以上の修正工数がかかったり、ドキュメンテーションによりなんだかんだ柔軟性が出ない、なんてこともあると思います。
今後1人でも多くの方がこの手法を実践し知見を共有していくことで、超高速軽量ウォーターフォールがAI時代の開発手法としてデファクトスタンダードになることを願っております。

末筆になりますが以下X（旧Twitter）アカウントで情報発信しておりますのでご興味あればフォロー頂けると幸いです。
長文となりましたがここまでお読み頂きありがとうございました。