デモ主導開発: 言うより見せる

1. Demo Driven Development(DDD) は、文書よりも実際のデモを優先し、素早くフィードバックを得て方向性を検証するソフトウェア開発戦略である。
2. DDDは初期実装物を通じて、チームとステークホルダーの双方に実質的な体験を提供することで、テキストベースの説明よりも効果的に要件を把握できるようにする。
3. 文書化は依然として必要だが、デモをもとに洗練された情報を反映した後で行うほうがより効果的である。

---

1. Demo Driven Developmentとは?

• 従来の方式: PRD/RFC のような文書を先に作成してから開発を開始。

• DDD方式: 文書の代わりに動くデモを先に作って見せ, リアルタイムでフィードバックを収集。

• 利点:

  • 直感的で即時のユーザー反応
  • 抽象的なアイデアを具体化
  • 小規模チームでも迅速に検証可能

---

2. デモの条件と構成要素

• インターフェースが存在する: Web/モバイルUI、CLI など、ユーザーが操作可能
• 生きたビジョン: PRD とは異なり、すぐに体験できる形
• 体験中心: 説明よりも実使用を通じて伝える
• 完成品ではない: 核心概念を伝えるのが目的であり、フィードバック収集が第一の目標
• 少人数で制作可能: 1~2人で制作できるようアジャイルに設計

---

3. チームに適用する方法

• デモ制作を奨励: 文書よりもプロトタイプを優先
• アクセシビリティ向上: 誰でもデモにアクセスできるように構成
• ワークフロー統合: デモレビューを定期的に実施
• 中核的フィードバックを促進: 見た目よりもアイデア検証に集中
• ツールへの投資: 実際の製品に近い高速プロトタイプツールを確保

---

4. 文書化が必要な時点

• デモ後: デモを通じて得られたフィードバックをもとに洗練された文書化
• 本番システム設計: 信頼性、性能、アーキテクチャの定義には明確な文書が必須

[techiemann]

口先だけでは安い、コードを見せてくれ！

[bluekai17]

プロトタイプは自分一人だけで見ておくべき..

[schang124]

同感…。デモの水準次第ではあるだろうが、開発者とデザイナーにとっては疲弊を招く方法論になる可能性が高い。Demo Drivien が成功するには、プロダクト企画のレベルがかなり重要になりそうだ。

[baeba]

変わった(?)テーマなので持ってきましたが..
ブログの一番下の内容を見ると..
AIで文章を生成したようですね。

[savvykang]

アジャイルの看板の掛け替えのように感じますね

[nobae]

開発者をすり潰さなければならない方法論…

[regentag]

プロトタイプモデルでしょうか。
最大の欠点は、顧客がプロトタイプを見ると開発がすべて終わったと思ってしまうことですね（笑）

[cgl00]

口先だけでは安い、コードを見せてくれ

[techiemann]

笑 ちょうどこれをコメントで付けようと思ってスクロールしていたら、まったく同じコメントを投稿した方がいましたね