アジャイル開発で「どこまで設計書を書くべきか」最適な粒度と判断基準

アジャイル開発では「設計書は minimal（最小限）でよい」と語られることが多く、「そもそも設計書は不要では？」という誤解も少なくありません。しかし、実際のプロジェクトでは、仕様変更の履歴や合意の証跡が残らず、途中参加メンバーやオフショア開発チームで齟齬が生じるケースがよくあります。

問題は“書くか／書かないか”ではなく、「どこまで設計書を書くべきか」という粒度の設計です。

本記事では、アジャイル開発における設計書の役割を“チームの認識を再現性高く維持するための仕組み”として捉え直し、粒度を判断する基準（複雑度／拠点数／責任分解）を整理します。さらに、実務で用いられる設計書の型や、会話で済ませてよい領域と文書化すべき領域の線引きも提示します。「不要かどうか」ではなく「どの段階で、どこまで残すべきか」がわかる構造で解説します。

目次

「アジャイル＝設計書不要」という誤解が生まれる理由

アジャイル宣言の“個人と対話”だけが切り取られる構造

アジャイル宣言には「包括的なドキュメントよりも、個人と対話を重視する」と記されています。本来は、ドキュメント作成が目的化することを避け、必要な議論を進めやすくするための考え方です。

しかし現場では、この一文だけが都合よく切り取られ、「アジャイルでは設計書を作らなくてよい」という極端な解釈につながるケースが多く見られます。結果、意思決定や仕様の合意が口頭ベースに寄りすぎ、後から内容を確認できない状態が発生します。

ウォーターフォール設計書との差分が誤解を助長

もう一つの要因として、従来のウォーターフォール型開発で作られる“厚い設計書”との対比があります。

アジャイルが提唱する「必要最小限のドキュメント」が「設計書は不要」「詳細は作らない」という誤読につながり、設計情報を極端に減らしてしまうケースが生まれます。本来アジャイルが求めているのは、必要な情報を必要な範囲で残すというバランスであり、ドキュメントを排除することではありません。

「多言語」「多拠点」では誤解が増幅する理由

さらに、多言語環境や多拠点での開発では、この誤解がより深刻な問題を引き起こします。

言語の違いや文化的な前提の差により、口頭で伝えた内容が正確に共有されず、チーム間で仕様の“解釈ブレ”が発生しやすくなります。対面での補足やその場の空気感が伝わらないため、設計情報を文書として残さないと、意図が変わったり曖昧なまま実装が進んだりするリスクが高まります。

このような環境では、アジャイルの原則を守りながらも、設計情報を適切に文書として残すことが必須になります。

アジャイル開発における“設計書の役割”の本質

合意形成の証跡

アジャイル開発では、仕様変更や方針転換が前提として組み込まれているため、口頭で合意した内容や議論の結果を残さないままで進行すると、「なぜこの仕様になったのか」「どの時点で判断が変わったのか」が後から追えなくなります。

設計書は、詳細な仕様書というよりも、意思決定の背景や合意内容を後から確認できる“証跡”として機能します。複数メンバーが並行して作業するアジャイルでは、この証跡があるかどうかで、後戻り工数や認識ズレの発生率が変わります。

会話ではなく文書が必要になる境界線

アジャイルでは対話を重視しますが、すべてを会話だけで処理できるわけではありません。

以下のような領域は、文書化しないと誤解や仕様の変造が起きやすくなります。

• 複数の機能が絡む動作や連携部分

• 前提条件・制約が複雑な仕様

• 想定外ケース（例外処理）が多い箇所

• 担当者が変わる可能性が高い領域

会話は“合意形成のプロセス”には有効ですが、“合意内容の保持”には向きません。アジャイルにおける文書化の目的は、誤解が起こりやすい境界だけを確実に固定することです。

「途中参加でも乗れる」ためのチーム資産化の視点

スプリントごとに意思決定が積み重なるアジャイル開発では、「途中参加メンバーがどれだけスムーズにキャッチアップできるか」がチームの生産性を左右します。

設計書を“チームの資産”として適切な粒度で残しておけば、過去の議論や意図を追いかけるために何度も説明する必要がなくなり、オンボーディング負荷が下がります。また、外部メンバーやオフショア開発チームが参加する場合でも、文書化された合意点があることで、誤った前提で実装が進むリスクを抑えられます。

どこまで設計書を書くべきか? 判断基準とケース別マトリクス

粒度を決める3軸

設計書は「すべてを書く／ほとんど書かない」の二択ではありません。

どの程度の粒度で残すべきかは、以下の3軸で判断するのが実務的です。

仕様が複雑 または他チーム・他機能とつながる部分は詳細化

機能間の連携が多い、例外処理が多い、他チームの作業と密接につながる部分は、口頭の補足だけでは認識が揃いません。以下のケースでは詳細な文書化が必要になります。

• API連携の前提条件

• データフローが複数チームをまたぐ箇所

• 業務ルールが複雑で誤解が起きやすい箇所

複雑さが高いほど、「解釈のブレ」を許容しないための明文化が求められます。

拠点・言語差が大きいなら明文化量を増やす

日本語だけの単一拠点であれば会話中心で進めやすくても、多言語環境や多拠点ではそうはいきません。

時差や言語差があると、前提のすり合わせを“その場の会話”で済ませられず、情報の欠落や変造が起きやすくなります。非同期コミュニケーションが中心になるほど、設計書の粒度を高める必要があります。

担当の境界で粒度を分ける

実装者・受入側・QAでは、必要とする情報の粒度が異なります。

• 実装 → ロジックの前提条件・仕様の意図

• 受入 → 期待される動作・判断軸

• QA → 想定シナリオ・例外系

この境界が明確でないと、関係者間で前提がズレやすくなります。

境界をまたぐ部分は、粒度を上げて誤解を防ぐことが必要です。

ケース別 設計書粒度マトリクス

前述の3軸を組み合わせると、設計書の粒度は次のように分類できます。

単一拠点 × シンプルな機能 → 最小粒度

• 会話中心で進む

• 仕様理解のブレが少ない

• チーム全員が同じ文脈を共有している

このケースでは、ユーザーストーリーや簡易図だけでも成立します。

多拠点 × 複雑な依存 → 詳細粒度

• チームが離れている

• 言語差がある

• 仕様やデータ構造が複雑

ER図・シーケンス図・前提条件の明文化など、詳細設計レベルの文書が必要です。

オフショア × 責任境界が曖昧 → 中〜高粒度

• 時差・文化差による認識ズレが発生しやすい

• 口頭説明が正確に伝わらない

• 境界の“暗黙の了解”が機能しない

オフショアでは、「どこまでが誰の担当か」「どの状態を完成とみなすか」を明文化しないと、仕様の変造や手戻りが頻発します。

会話で済ませる領域 vs 書面に落とす領域の線引き

アジャイルでは「会話で決めるべき領域」と「文書で固定すべき領域」を分けるのが現実的です。

文書化すべきは以下です。

• チーム間の境界や連携部分

• 想定外ケース・例外処理

• 曖昧なまま進めると後戻りが大きい箇所

• 完成条件（Definition of Done）に関わる要素

逆に、実装方法の細部など“当事者の裁量”に任せられる部分は文書化しすぎない方がスムーズです。

要件スナップショット化(更新し続けず"合意時点"を残す)

アジャイルでよく発生する問題が「設計書を更新し続けて疲弊する」ことです。設計書は“最新を維持するための書類”ではなく、合意した時点のスナップショットとして扱う方が運用が安定します。

• 最新仕様はバックログで管理

• 設計書には「合意時点の意図」を残す

• 実装と設計書を一致させるのではなく、後追い検証で参照できれば十分

こうした役割分担により、アジャイルと設計書の両立が可能になります。

実務で使われる設計書の型と代替手段

ユーザストーリー／ユースケース図／ERD／シーケンス

従来の詳細設計書を“そのまま軽量化”して使うよりも、目的に応じて設計情報を分散して残す方が現実的です。以下の4つは、現場で最も使われる基本的なドキュメント型です。

• ユーザストーリー

• ユーザー視点で「何を達成したいか」を簡潔に表す形式です。

• 要件定義フェーズでの合意形成に向いています。

• ユースケース図

• システム外部との関係性を可視化する図です。

• 機能範囲や外部連携の理解に役立ちます。

• ERD（データモデル図）

• データ構造や関連性を表す図で、実装の整合性を保つうえで欠かせません。

• 複数チームが同じデータを扱う場合は必須になります。

• シーケンス図

• 処理の流れやイベントの順序を示す図で、連携箇所の誤解を防ぐために非常に有効です。

これらをすべて作る必要はありませんが、チーム間の境界や誤解が起きやすい部分だけを可視化することで、過不足のない設計書になります。

Notion／Confluence／Miroなど運用の現場例

アジャイルではドキュメントを“蓄積する”よりも、“参照しやすい形で置いておく”ことが重要です。静的なWordやPDFではなく、共同編集が可能なツールが有効です。

• Notion

• 情報を階層化しやすく、要件のスナップショットや議事録の整理に最適です。

• Confluence

• チーム全体で設計情報を構造化して残す用途に向いています。

• Jiraとの連携で要件〜実装の流れを紐づけやすい点がメリットです。

• Miro

• 図でのコミュニケーションが必要な場面に強く、ワークショップや画面遷移の初期検討に使われます。

リモート・多拠点開発では、“最新の認識がどこにあるか”をチーム全員が把握できる状態が重要で、軽量ツールによる運用は相性がいいです。

Excel長文化が破綻するパターン

アジャイルで頻繁に起きる設計書トラブルのひとつが、「Excelで作った設計書が肥大化して破綻する」ケースです。具体的には次のような状況が発生します。

• シートが増えすぎて、どこが最新かわからなくなる

• 仕様の更新を反映し続ける運用が破綻し、古い情報が混在する

• 図や関係性を表現しにくく、複雑な仕様が“文章の羅列”になる

• 他チームへ共有しにくく、非同期での認識合わせが難しい

• 項目定義が長文化し、検索性が著しく低下する

Excelは表形式の一覧にする場面には向いていますが、複雑な仕様や関係性を扱う設計書として使うと、構造化の限界で破綻することが多くあります。

アジャイルにおける設計情報は、“重厚な一枚岩”としてではなく、目的に応じて複数の小さなドキュメントとして分解し、適切なツールで管理する方が、結果的に運用しやすくなります。

オフショア・リモート体制で設計書が真価を発揮する

曖昧表現/固定観念の差分がトラブルに直結

多拠点・多言語の開発では、「たぶん伝わっているだろう」という前提が成立しません。

同じ表現でも国や文化によって解釈が異なるため、曖昧な表現や“行間の理解”に期待した説明は、仕様のズレを引き起こしやすくなります。

オフショアでは、言語差よりも「前提の違い」や「常識のずれ」が問題になることが多く、曖昧なまま意思決定すると後工程で手戻りが発生します。設計書で“解釈の余地を残さない部分”を明確にしておくことが重要です。

口頭伝達が"仕様の変造"になる瞬間

口頭指示は、伝言ゲームのように受け手ごとに微妙に変化するため、同じ仕様であっても最終的な実装が異なるリスクがあります。

• ミーティングの参加者が全員同じ母語ではない

• 一度の説明で多くの前提情報を処理する必要がある

• メモの精度や量が人によって大きく異なる

• 会話の“ニュアンス”を補完しきれない

こうした環境では、口頭説明だけで進めると、実装時点で本来の仕様からズレてしまうことが珍しくありません。設計書は、この“ズレの再生産”を防ぐ役割を果たします。

文化差・言語差による"暗黙の了解"の崩壊

同じオフィス、同じ言語、同じ文化圏では成立する“暗黙の了解”が、オフショアでは機能しません。例えば、以下のような状況です。

• 「普通はこう動くだろう」という判断基準がチームごとに違う

• 要望を断りづらい文化があり、曖昧な合意が残る

• 質問しづらい雰囲気があり、誤解をそのまま抱えたまま作業が進む

こうした構造の中で、会話ベースのコミュニケーションは破綻しやすくなります。設計書を“明文化された共通基盤”として置くことで、文化的ギャップによる齟齬を減らせます。

非同期コミュニケーションでの"設計書の役割"

オフショア開発では、時差や稼働時間の違いにより、リアルタイムでの会話が難しくなります。結果としてメッセージやコメントでの非同期コミュニケーションが中心になりますが、非同期ではその瞬間に補足質問ができないため、前提の抜け漏れが起きやすくなります。

設計書があれば、非同期でも以下が可能になります。

• 「何を前提に決められていたか」を遡って確認できる

• スプリントを跨いでも意図が継承される

• リアルタイム説明に頼らず、自律的に作業を進められる

非同期環境では、設計書が“意思決定のアンカー”として機能します。

「設計書=エンジニア保険」ではなく「認識の整流板」

設計書を「エンジニアが自分を守るための証拠」と捉えてしまうと、書くこと自体が目的化し、形骸化してしまいます。本来、設計書はチーム全体の認識を整え、同じ方向に流すための“整流板（ディフューザー）”の役割を果たします。

• 誰が読んでも同じ理解に到達できる

• 前提・例外・境界が明確になる

• 実装・受入・QAでのズレを最小化できる

オフショア・リモート環境では、この“整流板としての役割”が特に有効であり、設計書の価値が最大化されます。

設計書運用で失敗しないための3つの鉄則

鉄則1 - 書く人を固定しない(属人化の回避)

設計書の作成を特定のメンバーに固定すると、ドキュメント構造や表現がその人に依存し、属人化につながります。属人化した設計書は、以下の問題を引き起こします。

• 書いた本人以外が読み解きづらい

• チーム全体で情報を“更新・補完”しづらくなる

• 異動・退職時に引き継ぎコストが急増する

設計書は「担当者がたまたま書くもの」ではなく、「誰でも書ける形式」に整えておく運用が重要です。テンプレート、用語ルール、粒度の基準を明確にして、チーム全体で維持できる状態にします。

鉄則2 - 更新しない前提でスナップショット化

アジャイルで発生しやすい失敗が、「設計書を最新状態に保とうとして疲弊する」ケースです。仕様変更が前提のアジャイルでは、ドキュメントを“常に最新化”する運用は現実的ではありません。

そのため、以下の考え方が有効です。

• 設計書は「合意した時点のスナップショット」を残す

• 最新仕様はバックログ（Issue／チケット）で管理する

• 設計書は“意図と背景”を確認するために参照する

スナップショット化することで、設計書の更新負荷を減らし、ドキュメントの陳腐化も防ぎやすくなります。

鉄則3 - 仕様変更はバックログで伝播(設計書は参照のみ)

仕様が変わるたびに設計書を修正する運用は、アジャイルとの相性が悪く、すぐに破綻します。設計書は詳細な仕様書ではなく、「意思決定の背景と合意の証跡」を残すものであるため、変更内容はバックログで管理するのが基本です。

• バックログ → 最新の仕様とToDo

• 設計書 → なぜこの方針になったのか、前提は何か

役割分担が明確になることで、文書量が必要以上に増えることを防ぎ、運用の再現性が高まります。

よくある失敗パターンと対策

アジャイル開発でありがちな設計書トラブルと、その対策をまとめます。

1. 設計書が陳腐化する

原因：更新しようとしすぎる・役割を誤解している

対策：スナップショット化し、最新仕様はバックログに集約する

2. 検索性が死んで誰もたどり着けない

原因：Excel長文化、ドキュメントの散在、階層が深すぎる

対策：Confluence／Notionなど検索しやすいツールを使い、情報設計を標準化する

3. 読まれないドキュメントになる

原因：目的と粒度が不明確、過度に詳細で本質が埋もれる

対策：粒度を「複雑度×拠点数×責任分解」で統一し、必要な部分だけを明文化する

4. “整流板”として機能しない

原因：口頭での前提を補完する情報が不足

対策：前提・例外・境界を明確に書き、認識ブレを吸収する仕組みにする

まとめ

アジャイル開発では、「設計書は minimal でよい」「会話を重視する」という原則が強調される一方で、実務では合意内容が残らず、認識のズレや仕様変造が発生しやすくなります。

本質は“設計書の有無”ではなく、どの粒度で、どの範囲を文書化するかという判断にあります。

設計書の粒度は、「複雑度／拠点数／責任分解」という3軸で決めると再現性が高まります。境界や連携部分のように誤解が起きやすい領域だけを明文化し、それ以外は会話や軽量ドキュメントで済ませるという線引きが現実的です。

オフショア・リモート体制では、言語差・文化差・時差が原因で認識ブレが起きやすく、設計書が“整流板”として特に重要になります。仕様の最新版はバックログで管理し、設計書は「合意時点のスナップショット」として位置づけることで、更新負荷を抑えながら運用できます。

アジャイルにおける設計書は、重厚な仕様書ではなく、チームが同じ方向を向くための最小限の仕組みです。「書くべきところだけを、適切な粒度で書く」という判断ができれば、手戻りや認識ズレを防ぎ、チーム全体の生産性を大きく高めることができます。

アジャイル運用やオフショア活用の設計に課題があれば、ぜひお気軽にご相談ください。要件整理から体制づくりまで、現場ですぐ使える形でサポートします。