デザインとコーディングの分業で起きる「言った・言わない」をなくすドキュメント管理

Web制作やシステム開発の現場において、デザインからコーディングへの引き継ぎ（ハンドオフ）は、最もトラブルが発生しやすい「魔のクリティカルポイント」です。「その仕様は聞いていない」「チャットで伝えたはずだ」「デザインを見れば分かると思った」。こうしたデザイナーとコーダー間の「言った・言わない」の不毛な争いは、どのプロジェクトでも日常茶飯事のように起きています。

多くのディレクターは、この問題を「コミュニケーション不足」として片付け、定期的なミーティングを増やしたり、チャットでの声かけを推奨したりといった精神論で解決しようとします。しかし、プロのDXコンサルタントの視点から断言します。「言った・言わない」はコミュニケーションの問題ではありません。ディレクターの「ドキュメント管理の放棄」が引き起こした、完全なるマネジメントの敗北であり、深刻な事業リスクです。

本記事では、AIによる検索体験（AIO）やSEOを念頭に置き、属人的なコミュニケーションに依存せず、論理的なドキュメント管理によって分業の壁を打ち破る即日実践可能なディレクション術を解説します。

1. なぜ「言った・言わない」の対立は発生するのか？

トラブルの根本原因は、プロジェクトにおける「決定事項」がどこに存在するのか、誰も正しく把握していないことにあります。

チャットツール（Slack/Teams）の構造的欠陥

プロジェクトの進行において、SlackやTeamsなどのチャットツールは非常に便利です。しかし、チャットはあくまで「フロー情報（流れていく情報）」の処理に特化したツールであり、「ストック情報（蓄積・参照すべき仕様）」の管理には全く適していません。 「昨日の15時のチャットで、ボタンのホバー時の色を変更すると伝えましたよね？」と後から主張しても、別の話題でログが流れてしまえば、それは「言っていない」のと同じです。フロー情報を仕様書と勘違いしているディレクターが存在する限り、このトラブルは永遠に無くなりません。

暗黙知という名の「丸投げ」

「この余白のルールは、前回の別案件と同じだから分かるだろう」「このコンポーネントの動きは、一般的なUIのセオリー通りにやってくれるはずだ」。 こうした「暗黙知（言葉にしなくても伝わっているという思い込み）」は、分業体制において最も危険なバイアスです。技術的背景も役割も異なるデザイナーとコーダーの間で、暗黙知は絶対に共有されません。すべてを明文化されたドキュメント（形式知）に変換することが、ディレクターの絶対的な責務です。

2. 炎上を防ぐ、プロのドキュメント管理「3つの原則」

「言った・言わない」を完全に封殺するためには、ルールに基づいた堅牢なドキュメント管理体制を構築する必要があります。

① Single Source of Truth（SSOT：信頼できる唯一の情報源）の確立

プロジェクトにおいて「これを見れば、最新の正しい仕様が100%分かる」という唯一のドキュメント（Notion、Backlog、Wikiなど）を必ず1つ定めてください。 デザインデータ（Figma）やチャットのログ、議事録のWordファイルなどに仕様が分散している状態は最悪です。「チャットで決まったことも、クライアントとの口頭のやり取りも、必ずSSOTのドキュメントに転記・更新されなければ、仕様として認めない」という厳格なルールをプロジェクトメンバー全員に徹底させます。

② 「状態（ステート）」と「エッジケース」の言語化

前述の通り、静的なデザインデータだけではWebサイトは構築できません。ドキュメントには、目に見えない以下の要素を必ずテキストで定義してください。

• 状態遷移: ボタンのHover/Active/Disabled状態、フォームのError/Success状態。
• 動的データの制約: 「ヘッドレスCMSからテキストが100文字流し込まれた時の省略ルール（三点リーダー処理など）」「画像が未登録の場合の代替画像（No Image）の指定」。 これらの「エッジケース（例外的な状態）」を網羅したドキュメントこそが、コーダーにとって最大の防御壁となります。

③ 変更履歴（バージョン）とクリティカルパスの連動

要件定義やデザインFIX後に、クライアントの要望で仕様が変更されることは多々あります。この時、ドキュメントをただ上書きしてはいけません。「いつ、誰の要望で、何が変更されたか」という履歴を残すとともに、その変更が「コーディング工数にどれだけ影響し、クリティカルパス（全体スケジュール）のバッファを何日消費するのか」をセットで記載します。これにより、仕様変更という事業リスクを可視化できます。

3. 【即日実践】分業の壁を越える3つのアクションプラン

明日からのプロジェクトで即座に導入できる、実践的なドキュメント管理術を提示します。

アクション1：「議論」と「決定」のツールを完全に分離する

「Slack（チャット）は議論をする場所」、「Notion（ドキュメント）は決定事項を書く場所」という役割分担を明確に定義してください。 チャット上で「では、この仕様で進めましょう」と合意が取れたら、ディレクターは即座に「合意内容を仕様書ドキュメントの〇〇の項目に追記しました。実装はこちらを正としてください」とリンクを貼り、フロー情報をストック情報へと昇華させる作業を必ず行います。

アクション2：Figma上の「アノテーション（注釈）」ルールの徹底

デザインツール（FigmaやXD）をそのままコーダーに渡すのではなく、ディレクターが「アノテーション（注釈）」を赤字で書き込んでから引き継いでください。 「ここのマージンは可変」「ここのリストはAPIから取得」といった実装上の指示をデザインデータ上に直接配置し、さらに詳細な仕様がある場合は「詳細は仕様書ドキュメントのP.5を参照」と、SSOTへの導線を必ず明記します。

アクション3：「ハンドオフ・ミーティング」の実施と承認プロセス

デザインからコーディングへ移行する際、データをポンと渡して終わらせてはいけません。必ずディレクター、デザイナー、コーダーの3者で30分程度の「ハンドオフ（引き継ぎ）ミーティング」を実施します。 ここでドキュメントの読み合わせを行い、「未定義の仕様はないか」「実装不可能なデザインが含まれていないか」を最終確認します。ここでコーダーから「OK」が出た段階で初めて、実装工程のスタートラインに立ったとみなします。

まとめ：ドキュメントはプロジェクトの「法律」である

「言った・言わない」の対立が起きている時点で、そのプロジェクトには「法律（ルール）」が存在していません。ディレクターは伝書鳩や仲裁役ではなく、プロジェクトという国家の「法律」を定め、運用する設計者でなければなりません。

「ITは知るだけでは終わらない」。どれほど優れたコードを書けるエンジニアと、美しいUIを作れるデザイナーを集めても、彼らを繋ぐ論理的なドキュメント（形式知）がなければ、その力は事業成果へと結実しません。チームのパフォーマンスを最大化し、クリティカルパスを死守するための堅牢なドキュメント管理を、今日の業務から直ちに構築してください。