構築を始める前にプロジェクトにデザインドキュメントが必要な理由

デザインドキュメントは、何を構築しているか、なぜ構築しているか、どのように機能するかを説明する書面による計画です。ユーザーマニュアルではありません。タスクリストでもありません。構築が始まる前に起こる思考です。 その核心として、デザインドキュメントは3つの質問に答えます。どんな問題を解決しているのか？提案されている解決策は何か？そして検討したトレードオフと代替案は何か？その他のすべて、技術的な詳細、スコープの境界、タイムラインの見積もりは、この3つの質問に付随します。 デザインドキュメントは業界によって異なる名前で呼ばれます。ソフトウェアチームはそれを技術デザインドキュメントまたはRFCと呼びます。ゲーム開発者はゲームデザインドキュメントを書きます。製品チームは製品要件ドキュメントを書きます。フォーマットは異なりますが、目的は常に同じです。計画を頭の中から取り出して、他の人、または将来の自分が読んで理解できるドキュメントに入れることです。

直感に反して感じます。構築を始めることに興奮しています。アイデアは頭の中で明確です。ドキュメントを書くことは、自分を遅くする余計な作業のように感じます。だからスキップして実装に飛び込みます。 2週間後、アーキテクチャが簡単だと思っていた機能をサポートしていないことに気づきます。または、チームメンバーがアプローチが何であるかを書き留めていなかったため、あなたのアプローチと矛盾するものを構築しました。または、十分に考えていなかったデザインの決定に突き当たり、リファクタリングしなければなりません。 デザインドキュメントはこれらの問題が本当の時間を消費する前にキャッチします。何かがどのように機能すべきかを書き留めると、詳細を考えることを強制されます。エッジケースを発見します。依存関係に気づきます。「シンプルな」機能が実際には3つの異なるシステムへの変更を必要とすることに気づきます。 デザインドキュメントの作成に費やす時間は、ドキュメントがキャッチしていたであろう問題の修正に費やす時間よりも常に少ないです。差は歴然としています。数時間の執筆が何週間もの手直しを節約できます。

厳格なテンプレートは必要ありませんが、良いデザインドキュメントは通常これらのエリアをカバーします。 概要から始めましょう。このドキュメントが何をカバーし、なぜ重要かを説明する1〜2段落。誰でもこのセクションを読んでスコープを理解できるべきです。 次に問題を定義します。何が壊れているか、欠けているか、または必要か？具体的に。「ユーザーはより良い検索が必要」は漠然としています。「現在のリストビューがフィルタリングやソートをサポートしていないため、ユーザーは過去のプロジェクトを見つけられない」は有用です。 そして提案された解決策を説明します。これがドキュメントの大部分です。何を構築する予定か、どのように機能するか、ユーザーエクスペリエンスはどのようなものかを説明します。チームの他の誰かがこの説明だけから実装できるくらいの詳細を含めましょう。 検討した代替案のセクションを追加します。どんな他のアプローチを評価しましたか？なぜこれを選んだのか？これは推論を示し、将来の読者が決定を理解するのに役立ちます。 最後に、オープンな質問とスコープ外のアイテムをリストアップします。意図的に何をしないと決めましたか？まだ議論が必要なのは何ですか？これはスコープクリープを防ぎ、ドキュメントが何をカバーし、何をカバーしないかについて正直に保ちます。

デザインドキュメントは一度書いて忘れるものではありません。最良のデザインドキュメントはプロジェクトとともに進化します。 構築するにつれて、何かを学びます。いくつかの仮定が間違っていることが判明します。計画のいくつかの部分が変わります。それは全く普通のことです。ドキュメントはそれらの変更を反映すべきです。何が変わったか、なぜかについてメモを追加しましょう。現実に合わなくなったセクションを更新しましょう。修正された決定をマークしましょう。 これはデザインドキュメントをプロジェクトの歴史に変えます。6ヶ月後に誰かが「なぜこのように構築したのか？」と聞いたとき、答えはドキュメントにあります。何ヶ月も前の会話を誰かが覚えているかに頼る必要はありません。 重要なのはドキュメントの更新を簡単にすることです。実際のプロジェクトから切り離されたツールにあれば、誰も更新しようとしません。タスクやタイムラインのすぐ隣にあれば、更新することがワークフローの自然な一部になります。IndieDevBoardにはプロジェクト内に存在する構造化されたセクションを持つデザインドキュメント機能が含まれているので、仕様は説明する作業の近くにあり続けます。

ゲーム開発をしているなら、これが通常GDDと呼ばれるゲームデザインドキュメントとどのように関連するか疑問に思うかもしれません。それらは関連していますが異なります。 GDDはゲームに特化しています。通常、ゲームのコンセプト、メカニクス、ストーリー、レベルデザイン、アートディレクション、オーディオ、UIなどをカバーします。ゲームのバイブルです。ゲームについてのすべてがGDDから説明できるべきです。 広い意味でのデザインドキュメントは、あらゆるプロジェクトや機能についてです。ゲーム内の単一機能、APIデザイン、ウェブサイトのリデザイン、または新しいプロセスを説明できます。より集中していて、GDDよりも通常は短いです。 実際には、多くのゲームチームは両方を使います。GDDは高レベルのビジョンドキュメントです。個別のデザインドキュメントは戦闘システム、インベントリ、またはマルチプレイヤーネットワーキングレイヤーなど、ゲーム内の特定のシステムや機能をカバーします。GDDは「ゲームにインベントリシステムがある」と言います。デザインドキュメントはインベントリシステムが正確にどのように機能するか、データモデルがどのように見えるか、他のシステムとどのように相互作用するかを説明します。

最初の試みで完璧なデザインドキュメントを書く必要はありません。基本から始めましょう。何を構築しているか、なぜかを書き留めましょう。有用なくらいの詳細で解決策を説明しましょう。不確かなことについてはオープンな質問を追加しましょう。 より慣れてくると、自然により多くの構造を追加するようになります。どのくらいの詳細で十分かの感覚を養います。プロジェクトの種類にとって最も重要なセクションを学びます。 重要なのは始めることです。書くのに1時間かかる大まかなデザインドキュメントは、書く機会が永遠に来ない完璧なものよりも無限に有用です。将来の自分とチームメンバーは感謝するでしょう。