AI時代のチケット駆動開発──ARDCMが生まれた背景

はじめに

生成AIがコードを書く時代になってから、開発者の役割は大きく変わりました。
「AIがコードを出してくれる」のは便利な反面、当初の設計と実装の乖離という新たな課題が生まれつつあります。

私はこの課題に直面したとき、ふと「AIと開発をうまくつなぐためには、チケット駆動の考え方が活きるのでは？」と思ったのが出発点でした。
ここから、後に「ARDCM（Agent-Reversible-Documentation-Cycle Method）」と呼ぶことになる構想が生まれます。

設計と実装のズレがもたらす課題

生成AIを用いたコーディングでは、指示内容を変えるたびにコードが大きく書き換わることがあります。
たとえ最初に設計を明確に伝えていても、
AIが生成するコードはその意図を正確に反映し続けるとは限らないのです。

特に大きな課題になるのが次の2点です。

• 設計書と実装の内容が時間とともに乖離していく
• どの変更がどの意図に基づいたのかが後から追えない

結果として、「人間がレビューしづらい」「再現性が低い」という問題に直面します。
これは、AIの力を活かそうとするほど浮かび上がってくるジレンマでした。

チケット駆動開発という再定義のヒント

この課題を解決する糸口となったのが、チケット駆動開発（TiDD: Ticket-Driven Development）です。

もともとTiDDは、タスクやバグ修正といった「チケット単位」で開発を進めることで、
要件・設計・実装・レビューを一元的に管理する手法です。

しかしAI時代のTiDDでは、この「チケット」が単なる管理単位ではなく、
AIにとっての命令書であり、開発プロセスのトリガーになります。

つまり、チケットを介して
「どのエージェントが、どの文脈で、何を生み出すか」を制御できる仕組みが重要になるのです。

Claude Codeが示した“分業するAI”という発想

この考えをより具体的にするヒントを与えてくれたのが、
Claude Codeのサブエージェント構造でした。

Claudeでは、開発の工程ごとに異なる役割を持つ「サブエージェント」を定義できます。
設計、実装、テスト、ドキュメント作成といった工程を、それぞれ独立したAIが担当し、
最終的に全体を連携させる――まるでチーム開発のようなAIの分業です。

この「AIの分業設計」という考え方は、
まさに人間のチケット駆動開発における役割分担と情報共有の概念と一致していました。

着想の融合から生まれたARDCM

AIによる分業とチケット駆動開発の思想を組み合わせることで、
「チケットを起点にAIエージェントが設計・実装・ドキュメントを循環的に更新する」
という仕組みが構想として立ち上がりました。

それが、ARDCM（Agent-Reversible-Documentation-Cycle Method）の原点です。

この方法論では、AIエージェントが実装内容を理解し、
そこからAs-Built Documentation（実装からのリバースドキュメント）を生成する。
さらにそのドキュメントが次の開発サイクルの設計情報として再利用される――
そんな「循環型の開発ドキュメント生態系」を目指しています。

AI時代における“開発効率と品質”の再定義

ARDCMの発想の根底には、次の2つの価値があります。

1. 開発効率の向上
   　AIがチケット単位で役割を分担し、同時並行的に作業を進めることで、
   　個人でもチーム並みの開発速度を実現できる。
2. ドキュメントによる品質向上
   　実装から自動生成されるドキュメントにより、
   　コードの透明性・再現性が飛躍的に高まる。

これにより、「AIを使って早く作る」だけでなく、
「AIを使って正しく作る」開発が可能になります。

今後の展開：ARDCMを実際の開発に適用してみた

次回の記事では、このARDCMの考え方を
実際にアプリ開発（自作プロダクト）へ導入したときの
運用プロセス・成果・課題を具体的に紹介します。

理論としてのARDCMが、どのように現場で機能し、
どのような改善や発見につながったのか。
そのリアルな開発記録を共有していく予定です。

次回予告

「ARDCMをアプリ開発で運用してみた」
── チケット駆動 × AIエージェントがもたらした実践的な成果と課題