2.7 開発スタイル

1. 開発スタイルとは
2. 手作業を前提とした開発手法
3. ウォーターフォールモデル／Vモデル
4. プロトタイピング
5. 反復型・インクリメンタル開発
6. スパイラルモデル
7. アジャイル開発
8. DevOps
9. AIエージェント協業型の開発手法
10. バイブコーディング
11. AIペアプログラミング
12. 仕様駆動開発
13. 対話型反復開発
14. タスク委任型エージェント開発
15. 自律型・マルチエージェント開発
16. 仕様で土台を固め、対話で育てる
17. 開発スタイルを使い分ける
18. 参考サイト

開発スタイルとは、プログラムを完成させるまでの作業を、誰が、どのような順序で、どのように確認しながら進めるかを定めた考え方である。たとえば、最初にすべての仕様を決めてから実装する方法もあれば、動くものを少しずつ作り、利用者の反応を見ながら仕様を決める方法もある。どれか一つが常に正解なのではない。要件の明確さ、失敗したときの影響、納期、参加人数などによって適切な方法は変わる。

従来の開発手法では、多くの作業を人間が手作業で行うことを前提としていた。人間が資料を読み、設計し、コードを書き、テスト結果を確認するため、作業の分担、順序、成果物を明確にする必要があった。AIエージェントを使う開発では、調査、コード作成、テスト、文書更新などの一部をAIへ任せられる。しかし、目的を決め、結果が適切かを判断し、責任を負うのは人間である。この役割分担を理解することが、AI時代の開発スタイルを選ぶ出発点になる。

ここでは、手作業を前提として発展してきた代表的な6つの開発手法を取り上げる。これらはAIと対立する古い方法ではない。AIエージェントを利用する場合にも、プロジェクト全体の進め方を決めるための基礎として利用できる。

ウォーターフォールモデルは、要求定義、設計、実装、テスト、運用という工程を、上流から下流へ水が流れるように順番に進める方法である。Vモデルは、要求定義や設計の各工程と、それを確認するテスト工程をV字形に対応させる。詳細設計は単体テスト、基本設計は結合テスト、要求定義は運用テストというように、何をどのテストで確かめるかを計画する。

観点	内容
適用しやすいプロジェクト	要件が明確で、品質基準、契約、承認手順が厳格な開発
ベネフィット	工程と成果物が明確で、進捗、役割、品質を管理しやすい
リスク	途中の仕様変更に弱く、完成品を使って初めて分かる問題の発見が遅くなりやすい

プロトタイピングは、完成品を作る前に、主要な画面や操作を試せる試作品（プロトタイプ）を作る方法である。利用者に試作品を使ってもらい、意見を集めて仕様を具体化する。見た目だけを確認する試作品もあれば、重要な機能だけを実際に動かす試作品もある。

観点	内容
適用しやすいプロジェクト	新しいサービスや、画面と操作方法を事前に決めにくいアプリ
ベネフィット	利用者と開発者の認識の違いを早期に発見できる
リスク	試作品を完成品と誤解されたり、場当たり的な修正を重ねて設計が崩れたりする

反復型開発は、設計、実装、テストを繰り返し、同じ製品の完成度を少しずつ高める方法である。インクリメンタル開発は、システムを複数の機能に分け、動く機能を一つずつ追加する方法である。実際のプロジェクトでは、この二つを組み合わせることが多い。

観点	内容
適用しやすいプロジェクト	機能を分割でき、優先順位の高い部分から提供できる開発
ベネフィット	早い段階で動く成果を確認でき、学んだことを次の反復へ反映できる
リスク	全体設計が不十分だと、機能追加のたびに構造が複雑になる

スパイラルモデルは、目標設定、リスク分析、開発、評価という一連の作業を繰り返し、渦巻きが外へ広がるように製品を完成へ近づける方法である。各周回で技術上、費用上、運用上のリスクを調べ、重大な問題を先に解決する点に特徴がある。

観点	内容
適用しやすいプロジェクト	規模が大きく、新技術や高い安全性など不確実な要素を含む開発
ベネフィット	重大なリスクを早期に見つけ、試作や検証によって損失を抑えられる
リスク	リスク分析に専門知識と費用が必要で、小規模開発には重すぎることがある

アジャイル開発は、変化への対応と利用者との協力を重視し、短い期間で計画、実装、テスト、評価を繰り返す考え方である。スクラム、XP、カンバンなどの具体的な手法がある。最初から全機能を固定するのではなく、価値の高い機能から作り、利用者の反応を次の計画へ反映する。

観点	内容
適用しやすいプロジェクト	市場や利用者の要求が変化しやすく、短期間で成果を提供したい開発
ベネフィット	変化に対応しやすく、利用者にとって価値の高い機能を優先できる
リスク	利用者の継続的な参加が必要で、全体像や最終費用を予測しにくい

DevOpsは、開発（Development）と運用（Operations）が協力し、プログラムの変更を安全かつ継続的に利用者へ届ける考え方である。自動テスト、継続的インテグレーション、継続的デリバリー、監視などを組み合わせ、公開後に得られた情報を次の改良へ戻す。

観点	内容
適用しやすいプロジェクト	Webサービスなど、公開後も頻繁に更新し続けるシステム
ベネフィット	テストや配布の自動化により、変更を速く安定して届けられる
リスク	自動化環境の構築と運用に知識が必要で、誤った自動化は問題を急速に広げる

AIエージェントは、指示を受けて文章を返すだけでなく、プロジェクト内のファイルを調べ、複数のファイルを編集し、コマンドを実行してテストすることができる。この能力を開発へ取り入れると、人間がすべてのコードを手で書く場合とで、作業の分担と進め方が変わる。以下の6つは、AIエージェントの実際の使い方を理解するための分類である。名称や範囲が厳密に標準化されているわけではなく、一つのプロジェクトで複数の方法を組み合わせてよい。

バイブコーディングは、作りたいもののイメージを自然な言葉でAIへ伝え、生成されたプログラムを動かしながら、追加や修正を繰り返すスタイルである。コードの細部よりも、実際の動作や見た目を手掛かりに対話を進める。思いついたアイデアを短時間で形にできる一方、内部の仕組みを理解しないまま変更が積み重なる危険もある。

観点	内容
適用しやすいプロジェクト	個人用ツール、試作品、画面の調整など、結果を見て良否を判断できる小規模開発
ベネフィット	プログラミング経験が少なくても、アイデアを素早く動く形にできる
リスク	設計、セキュリティ、保守性、テストが不足し、原因を説明できない問題が残りやすい

AIペアプログラミングは、人間とAIが同じ課題に取り組み、人間が目的と判断を担当し、AIがコード作成、説明、修正、レビューを支援するスタイルである。人間同士のペアプログラミングと異なり、AIは最終的な責任を負わないため、人間が提案を理解し、採用するかを判断する必要がある。

観点	内容
適用しやすいプロジェクト	学習、小規模な機能追加、既存コードの理解や改善
ベネフィット	質問、実装、説明を一つの流れで行え、作業と学習を同時に進められる
リスク	AIのもっともらしい誤りを見抜けないと、不具合のある提案を採用してしまう

仕様駆動開発は、目的、利用者、機能、画面、データ、制約、受け入れ条件などを仕様書へ明記し、AIエージェントがその仕様を基準に計画、実装、テストを進めるスタイルである。本講座では、人間にもAIにも読みやすく、Gitで変更履歴を管理できるMarkdown形式のプログラム仕様書を使用している。

観点	内容
適用しやすいプロジェクト	個人用ツールから業務アプリまで、目的と完了条件を説明できる幅広い開発
ベネフィット	人間とAIが同じ基準を共有でき、実装漏れ、認識違い、引き継ぎ時の情報不足を減らせる
リスク	仕様の誤りや曖昧さも忠実に実装される。変更後に仕様書を更新しないと実物と食い違う

対話型反復開発は、人間が一度に小さな課題を与え、AIが実装し、人間が結果を確認して次の指示を出すスタイルである。「指示→実装→動作確認→修正」という短いサイクルを繰り返す。アジャイル開発や反復型開発の考え方を、個人とAIの協業へ応用したものと考えると分かりやすい。

観点	内容
適用しやすいプロジェクト	機能を小さく分割でき、途中の成果を人間が確認できる開発
ベネフィット	誤りを早く見つけられ、方向を修正しながら着実に完成へ近づけられる
リスク	目標と全体設計を持たずに対話を続けると、変更が場当たり的になる

タスク委任型エージェント開発は、バグ修正、機能追加、テスト作成、文書更新など、開始条件と完了条件が明確な作業をAIエージェントへ任せるスタイルである。人間は何を達成するかと変更してよい範囲を示し、AIは必要なファイルの調査から実装、テストまでを進める。

観点	内容
適用しやすいプロジェクト	既存プロジェクトのバグ修正、機能追加、テスト整備など、作業範囲を区切れる開発
ベネフィット	人間は目的と確認に集中でき、調査や編集などのまとまった作業を効率化できる
リスク	指示範囲や完了条件が曖昧だと、意図しないファイルや機能まで変更されることがある

自律型エージェント開発は、人間が目標と制約を与え、AIエージェントが調査、計画、実装、テスト、修正を連続して進めるスタイルである。マルチエージェント開発では、複数のAIに調査、実装、テスト、レビューなどの役割を分担させる。人間が逐一操作しなくても広い範囲を進められるが、権限と停止条件を明確にする必要がある。

観点	内容
適用しやすいプロジェクト	作業を独立した役割に分けられ、自動テストとバージョン管理が整った開発
ベネフィット	複数の調査や実装を並行でき、大きな作業を短時間で進められる
リスク	誤った判断が広範囲へ波及し、エージェント間で重複、矛盾、統合失敗が起きる

本講座では、AIエージェントを利用する幅広い開発に仕様駆動開発を推奨する。最初にMarkdown形式のプログラム仕様書を作り、人間とCodexが共有する基準にする。要求、設計、実装、テストを対応させる点では、手作業で使われてきたウォーターフォールモデル／Vモデルの考え方を踏襲する。ただし、最初から巨大な仕様書を作る必要はない。個人用の小さなツールであれば、目的、利用者、機能、画面、データ、通信、禁止事項、テスト条件などを簡潔に記載すればよい。

段階	人間の役割	Codexの役割
目的を決める	利用者、解決したい問題、完成の条件を決める	不足している情報や曖昧な点を質問する
仕様を作る	提案を確認し、採用する仕様を判断する	Markdown仕様書の作成と整理を支援する
計画する	作業範囲、優先順位、危険な変更を確認する	プロジェクトを調査して実装計画を作る
実装する	機能単位で作業を委任する	コード、テスト、文書を作成・更新する
検証する	利用者の目的を満たすか確認する	自動テストを実行し、仕様との一致を調べる
改良する	実際に使い、改善したい点を自然な言葉で伝える	影響範囲の小さい変更を素早く反映する

最初の実用版が完成した後は、実際に使わなければ分からない表示や操作感を、バイブコーディングで調整する。「ボタンを少し大きくする」「一覧を日付順に並べる」「エラーメッセージを分かりやすくする」といった変更は、結果を見て良否を判断しやすい。ただし、確定した変更は仕様書にも反映する。仕様書を更新しなければ、次にCodexへ作業を頼んだとき、古い仕様へ戻されるおそれがある。

データ保存形式、認証、権限、課金、個人情報、データ削除などに関係する変更は、軽い気持ちで進めてはならない。先に仕様書を改訂し、影響範囲とテスト条件を確認してから実装する。試して簡単に戻せる変更は対話で素早く進め、失敗の影響が大きい変更は仕様から慎重に進めるという区別が重要である。

AIエージェントを利用するからといって、ウォーターフォール、アジャイル、DevOpsなどを捨てる必要はない。たとえば、要件と品質基準が明確な業務システムではVモデルを使い、各工程の資料作成、コード作成、テストをCodexに支援させることができる。新しいサービスではプロトタイピングやアジャイル開発を採用し、短い反復ごとにCodexへ機能を実装させることができる。継続的に提供するWebサービスでは、DevOpsの自動テストや配布作業をAIが支援できる。

大切なのは手法の名前ではなく、プロジェクトの目的とリスクに合った進め方を選ぶことである。AIはコードを書く速度を高めるが、何を作るべきか、利用者にとって適切か、公開して安全かを自動的に保証するものではない。人間が仕様と判断を担当し、AIエージェントへ調査、実装、検証を委任する。この役割分担を土台に、必要なところでは計画的に、試せるところでは対話的に進めることが、Codexを活用する開発の基本となる。

• Codex Quickstart：OpenAI
• Subagents：OpenAI
• アジャイルソフトウェア開発宣言
• スクラムガイド：Ken Schwaber、Jeff Sutherland
• DevOpsとは：Microsoft Learn
• DORA
• Markdown：Daring Fireball