「実装駆動開発」なるものを検討しています

2026.10.16 菅原 惇

はじめに

AIスロップ地獄で疲弊する人々

先日、スレッズで下記のような投稿を見て、悲しくなりました。

上からも下からもAIで大量に生成された文章が大量に来て、手が回らない。
もうこの仕事やめたいんだが・・・。

投稿主は開発職のリーダーのようでした。
おそらく、他部門から大量のAI文書が届き、自部門の部下からAIによる成果物（コードと報告書）がばんばん届く、そんな状況なのでしょう。
大量のコード/文書を生成できるようになった一方で、特定の人に大量のコード/文書が押し寄せ、かえって業務負荷が増大しているわけです。

部分最適≠全体最適

AIの登場によって、コーディング作業が劇的に早くなった。
AIの登場によって、ドキュメントを書く作業が劇的に早くなった。専門家じゃなくても専門家のようなドキュメントが書ける。

しかし、個人単位での最適化が進んだとしても、全体の生産性がそのまま上がるわけではないです。
先にあげた、開発プロセスの例がまさにその事例と言えるでしょう。
端的に言えば、業務プロセスのボトルネックが移動した状態だということです。

つまり、本当の意味でAIが生産性に寄与させたいならば、結局は業務プロセス全体を改善するしかありません。
けっきょく、DXなどと同じ道を辿る必要があるわけで、AI導入コンサルみたいな人間が跋扈する未来しか見えなくて悲しくなりますが。

AIは確かにスゴイ。
でも、スポーツカーのエンジンを、自転車に積んでも、自転車はぶっ壊れるだけです。

現在のAIを活用したシステム開発の課題

前述したように、AIはもはや人間以上の能力を持っています。
しかし、現在の多くのシステム開発手法や組織構造は、このAIの特性を最大限に活かすために変化しきれていません。

できれば、AIの特性を最大限に活かし、人間の認知負荷もなるべく高めずに開発を進めたいところですが、それができていないのが現状です。

「実装駆動開発」の提案

上記で提示した課題をクリアするために、筆者は「実装駆動開発」を推薦したいと思います。

基本コンセプト

「さっさと動くものを作れ」

基本的なコンセプトとしては、「さっさと動くものを見せてしまったほうが効率よくね？」ってところにあります。

• AIの登場により、実装コストはぐんと下がりました。だからさっさとものを作ろう。
• 動くものをさっさと見てしまった方が、何が足りないか、どこに認識の齟齬があるか、わかりやすくない？だからさっさとものを作ろう。
• ドキュメントは机上のものであって現実ではないよね？だからさっさとものを作ろう。

「人に優しく」

AIによる大量の文章・生成物が人間を苦しめています。必要以上にドキュメントを作るべきではないです。

• AIは人間のように情報集約したり、問題を収束してくれない。必要以上にAIの文章を読みたくない。
• AIの書くドキュメントがひどい。独自用語や抽象度がバラバラで理解しにくい。その都度指摘していかないと、メモリも汚染され、変な用語が定着する。必要以上にAIの文章を読みたくない。

原則

もう少しこのコンセプトに沿って、ポイントについて整理すると、以下の通りになります。

「詳細な計画やタスク分解はするな」

詳細な計画やタスク分解は、AIスロップの地獄の入口になります。

• AIは自律的にタスクを決めて行動できるため、詳細な計画書は不要。
• タスク分解することで、逆に作業する際のAIの文脈・スコープが狭くなる。
• タスク分解することで、人間側の管理ドキュメントが増え、認知負荷が上がる。

「システムの仕様・状態を記述したドキュメントのみを更新して、AIで一気に動くものを作れ」

作りたいシステムの仕様がわかれば、実装はできるはずです。

• AIが実装するにあたって、必要なドキュメントさえあれば開発は進む。
• 人間側も見るべきドキュメントが限定されて楽になる。
• AIにより実装スピードは格段にあがった。

「動くもので関係者と合意を取れ。ずれがあったらやり直せ」

動くものが現実なのだから、ドキュメントより雄弁。

• 詳細な要求定義より、現物を見せた方が、認識のずれや間違いを発見しやすい。
• AIによる実装スピード向上により、動くものを作るコストがぐんと下がった。さっさと作って、さっさとフィードバックをもらおう。
• ずれがあったらドキュメントを更新して実装をやり直せばいいだけです。

開発サイクル

ここまでの話をもう少しちゃんとまとめると・・・

開発サイクルとして、もう少し具体化すると下記のようになります。

• イテレーションの策定

  まずはイシュー中から、重要と思われるものを選定しましょう。ただそれだけです。
  なお、このときに詳細な計画は立てないこと。イテレーションが最小のタスク粒度ぐらいのつもりで。ガントチャートも書きませんし、作業工程の分解も、タスク分解もしないように。
  「このイテレーションはいつまでにおわらせるようなかな？」程度の計画とすること。
  ※前提として、イシューによる課題管理をしているものとします。

• ドキュメントの更新

  イシューを元に、システムの仕様や状態に関わるドキュメントを更新する。
  例えば、DesignDoc（要求要件定義、UC図、システム概要、データモデル、機能仕様書等）のみを更新するなど。
  なお、実装前にすべての詳細を確定することは求めない。

• AIによる実装・単体/結合テスト

  ドキュメントを元に、AIで実装を一気に進め、合わせて単体テスト・結合テスト等も実行する。
  実装中に発見した設計上の見落としや不整合もドキュメントにフィードバックする。

• 人間による動作確認・差分レビュー

  人間が実際にうごくものをみながら、要求通りの実装か、設計通りの実装かを確認します。
  認識にずれがある場合は、ドキュメントの更新の作業の工程に戻り、再実装するだけです。

• ドキュメントの確定

  動作確認でOKとなったら、最終的にドキュメント群の承認も取るようにしましょう。
  要求者なら要求内容が反映されているか、開発者なら開発側の意図通りの設計になっているかをチェックします。
  問題なければ、ドキュメントに承認をもらい、確定版とします。

• システムテスト

  ドキュメントに基づいてシステムテスト仕様を更新し、変更対象のユースケースを中心にシステムテストを実行します。

• コミット/リリース

  テストが完了したら、コミットする。必要に応じてリリースへ進む。

フローチャート

メリット

作業単位/作業管理の単純さ

計画を極めて単純化してしまって、イテレーション単位でしか作業管理しないとしたら、とても楽ではないでしょうか。
「〇〇機能の改修」が1イテレーションだとしたら、それをいつまでにリリースするかくらいの考えでいいのです。

スクラップアンドビルドのしやすさ（失敗したらやり直せばいい）

この手法のよいところは、失敗したらさっさとやりなおせばいいよね、と割り切って考えられることです。
AIによる実装コストが下がったことで、スクラップアンドビルドがやりやすくなりました。
明らかな不具合や欠陥が見つかった場合は、作ったものはさっさと捨ててしまって、イテレーションをやり直せばいいのです。

詳細な要求定義が不要

従来のような詳細な要求定義の必要性が薄くなるはずです。
なぜなら実際に動作するものが見られるからです。
また、実際に動作するものを触ると、要求や設計の見落としも発見しやすくなります。
つまり、動くものを早めに作る行為は、要求や設計をブラッシュアップすることにつながります。

課題点

実行環境が必須、外部依存の考慮、データ移行等々

実装駆動開発は、「動くもの」を中心に見る必要があるため、作ったものが見られる環境が必要になります。
また、外部システムや他部門との依存関係などがあるときも、考慮が必要でしょう・・・。
あとは、データ移行などですね、これはきちんと計画はしないといけませんし、一時的な作業ですので、テンプレ的なドキュメント群とは別管理になると思います。

当ドキュメントは更新中です。
内容について変更になる場合がございます。