DocDD(ドキュメント駆動開発)のまとめ

かずま | デザインエンジニア

DocDD(ドキュメント駆動開発)とはDocumentation-Driven Developmentの略称です。コンセプトは「最も重要なのはドキュメント(仕様書)で、ドキュメントを中心に開発を進めていきましょう」という開発フレームワークです。

DocDD(ドキュメント駆動開発)の歴史

Documentation-Driven Developmentという造語は、2007年10月にVincent Massolさんのツイートで最初に出現しています。(対象のツイート)

そして実際に現状のコンセプトに近い形でまとめれたのは、2014年3月にZack SupallaさんのGithubの内容です。(対象のGithub)そこでは略称はDDDとされています。その中の最初の一文が最も今回のDocDDの本質を表現しているので引用します。

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

日本語訳
ドキュメント駆動開発の背後にある哲学はシンプルです。ユーザーの観点から見ると、機能がドキュメント化されていない場合は存在しないことになり、機能が誤ってドキュメント化されている場合は壊れていることになります。

https://gist.github.com/zsup/9434452

最近だとYUMEMIさんとかが、AIを使ったDocDDについて推し進めようとする動きがある(対象のサイト)

DocDDはエンジニアの未来の姿

上の引用文を見ると「ふーん、当たり前じゃん」とか「AIの開発ならドキュメントすら要らんやろ」とか思いますよね。自分も思いました。

しかし一つの例を挙げます。あなたはとある会社の超多忙なエンジニアです。部下のエンジニアのAくんは、コーディングは高速ですが、主体性がありません。あなたはAくんと最も少ないコミュニケーションで最高の開発物を作るにはどうしたら良いでしょうか？

これが現在の私たちとChatGPTの関係です。

私たちは10000文字入力するべきプログラミングを、コード補完(code completion)を使い5000文字を入力するようになり、Github Copilotを使い2500文字を入力するようになり、ChatGPTを使って1文字もコードを入力せずに開発ができるようになりました。

あなたはまだコードを書きますか？

(補足)
ツラツラと書いてみたもののシンプルにコード書くの楽しいよね！みたいな気持ちもありコードを書く体験は今後「趣味としてのお絵描き」とか「趣味としての料理」みたいな趣味的な考え方になるのかなと思いました。

DocDDの基本的な流れ

  1. ドキュメントを書く
    開発するものに対しての全ての情報をドキュメントとしてまとめます。特に機能要件を中心に書き、必要あれば、非機能要件、テーブル定義、ER図、画面推移、UIなどををまとめておきます。

  2. ドキュメントに対してフィードバックを受ける
    コードのように他のエンジニアやPMからフィードバックをもらい、それに合わせて修正します。

  3. 開発(テスト駆動開発を推奨)
    ドキュメントに応じてテストから開発を行います。機能が開発できたらテストに通して通過するかをチェックします。

  4. 開発途中で機能変更を行う場合は先にドキュメントを変更する
    開発していく中で機能の内容を変更したい場合はまずドキュメントから変更を行います。変更が完了したら再度2のフィードバックを行い、3の開発を行っていきます。

全体的に「コードのようにドキュメントを扱う」のがDocDDの基本です。

AI時代のDocDD開発

上記の基本的なDocDDに対してAIをどのように活用できるのか考えていきます。全体的にAIを活用することも可能ですがわかりやすいように開発の部分だけに注目してまとめます。

  1. ドキュメントを書く

  2. ドキュメントに対してフィードバックを受ける

  3. 開発

    1. AIへのドキュメント学習
      ドキュメントをAIに学習させます。マークダウンなどAIが学習しやすい形にしておくのが良いです。

    2. AIによるテストコードの作成
      ドキュメントを元にAIにテストを作成してもらいます。必要に応じてテストコードをフィードバックしていきます。(ポイントは自分自身は絶対にコードを書かないことを意識すること)

    3. AIによる機能開発
      ドキュメントを元にAIに開発してもらいます。一気に全ての機能を作ることは難しいので機能ごとなど分割して開発してもらいます。(分割についてもドキュメントでまとめるのも良いと思います)

    4. 2のテストを通過するかチェック
      3で1回コード生成をしたら都度テストを通過するかチェックします。テストを通過しない場合は再度作り直すように伝えてください。(ここでも自分自身でコードを修正しないことを意識すると良いです)

    5. 3と4を繰り返しながら開発

  4. 開発途中で機能変更を行う場合は先にドキュメントを変更する

AIを用いたDocDDに向いている開発エディター

Cursor(カーソル)

xcodeベースなのでxcodeを使っていた人からすると切り替えしやすい。(というかxcode使ってる人はすぐCursorに切り替えた方が良い。100倍くらい開発効率が変わる)

具体的なAIを使ったDocDDの開発の流れ

反響が多そうなら書きます！ハートください！




いいなと思ったら応援しよう！