STANDARD

ディレクションシステムβ

このページは、プロジェクトをはじめて担当する人が「だれが・何を・いつまでに・どう進めるか」を迷わず決められるようにした実務ガイドです。チャットの使い方、困ったときの相談先、公開（デプロイ）の手順を先にそろえることで、認識ズレや手戻りを減らし、チームで安心して進められます。

🎯

段取りを一番大切にする

作業を始める前に「誰が・何を・いつまでにやるか」を決めます。これだけで現場のトラブルの9割を防げます。

📋

チーム内で言葉の定義を合わせる

進み具合（ステータス）の書き方や判断基準をそろえます。全員が同じ意味で言葉を使うことで、意思疎通が格段にスムーズになります。

🔒

ミスが起きない仕組みを作る

公開前の最終チェック（テスト）や承認の手順を最初から組み込んでおきます。確認もれによるミスを、個人の注意力だけに頼らず、仕組みで防ぎます。

PRE-LAUNCH

1. プロジェクトが始まる前にやること（準備と設計）

最初の打ち合わせ（キックオフ）から実際の作業が始まるまでに、チームの体制、進め方のルール、どんなものを作るかをお客様とすり合わせる準備セクションです。

DiSAが定めるディレクションの原則

#ゴールと段取りを決める
#周辺を巻き込んで合意形成する
#イニシアチブを握り続けて進捗する

PROJECT CONCEPT

A-0. プロジェクトコンセプト（今回の優先順位をみんなで決める）

最初に「今回のプロジェクトでは何を最も大切にするか」をお客様と合意し、メンバー全員の判断軸をそろえます。

スピード優先：まずは最低限の機能で早く公開し、動きながら改善していく方針です。
品質優先：公開後のトラブルを防ぐため、事前の動作確認や表現の仕上がりを最も重視して完成度を高める方針です。
コスト優先：決められた予算の範囲内で収めるため、まずは絶対に外せない機能だけを作り、残りは次のステップに回す方針です。
検証・学習優先：新しい技術やツールを試すことに価値を置き、チームのスキルアップやノウハウ獲得を重視する方針です。

コンセプト合意メモ（コピペ用）

# プロジェクトコンセプト合意
- 優先方針: [スピード優先 / 品質優先 / コスト優先 / 学習優先]
- 今回この方針を選ぶ理由:
- 例外条件（方針を切り替える条件）:
- 最終判断者:
- 見直しタイミング: [毎週定例 / マイルストーン到達時 など]

SETUP FRAMEWORK

A-1. ディレクション初期設計（最初に決めておくべき7つのルール）

プロジェクトが動き出す前に、以下の7つの分野について「どういう段取りで進めるか」をパチッと決めておきます。

🏔️

企画・プロデュース（方向性と体制）

「なぜこのプロジェクトをやるのか」という目的と、役割分担（だれが何を決定するか）を決めます。

体制図（誰が決めるか）の作成
目標（何をもって成功とするか）の決定
連絡ツールと会議スケジュールの決定

📐

情報設計・仕様設計（作るものの設計図）

どの画面からどの画面へ移動するか、何を作るかを緻密に整理し、「思っていたのと違う」という作り直しを防ぎます。

画面遷移図・サイトマップの作成
仕様変更（やりたいことの変更）のルール設計
プログラムの命名規則などの決定

⚙️

制作・開発（日々の進捗と品質の管理）

毎日のタスクが遅れていないか、プログラムの公開が安全に行われているか、品質をチェックしながら進めます。

ステータス記号（`[ ]` `[/]` `[x]` `[!]`）による管理
古い仕様に戻ってしまうミス（先祖返り）の自動防止
遅れ（`[!]`）が発生したときのリカバリー手順

🖱️

サービス運営・運用（リリース後の安全管理）

公開した後に、データを安全に守るバックアップの手順や、ユーザーからの問い合わせにどう答えるかを決めます。

データ削除は「ゴミ箱行きフラグ（論理削除）」を原則とする
定期的なデータ保存と復旧手順の確認
ユーザーからの要望・改善点の集約ルール

📣

プロモーション（情報の届け方とSNS運用）

新しい機能のリリースやイベントのお知らせを、SNSなどを通じて効果的に世の中に発信します。

SNSアカウントの運用ルールと責任者の決定
リリース告知の文面レビュー・承認の流れ
プレスリリース（公式発表）の確認ルート

✍️

ライティング（言葉づかいと文章の一貫性）

サイト内のボタンの文字や説明文、操作説明書の言葉遣いを統一し、ユーザーが迷わないようにします。

画面上の言葉と説明書の一文字一句の一致
言葉の表記ゆれ（例：「お問い合わせ」と「お問合せ」）の防止
記事やコピーの確認・校正プロセス

💡

ツール・効率化（AIの活用と自動化）

AI（人工知能）を使って作業を早く終わらせる方法や、新しいメンバーがすぐにチームに慣れるマニュアルを作ります。

AI向け指示書（`AGENTS.md`）の整備
繰り返しの作業を自動で終わらせる仕組みの導入
新メンバー用のオンボーディングマニュアルの用意

DIRECTION COMPONENTS

A-2. キックオフ合意テンプレート（打ち合わせでそのまま使えるメモ）

最初の打ち合わせ（キックオフ）で、お客様と必ず確認し合っておくべき「全14項目」のチェックリストと、コピペしてそのまま使えるフォーマット集です。

最初の打ち合わせで必ず確認する14項目

プロジェクトコンセプト（スピードを優先するか、品質を優先するかなど）
目的・成果指標（何をもってプロジェクトの成功とするか）
作業範囲（やること / 今回はあえてやらないこと）
役割分担（だれが最終決定するか / 承認の流れ）
連絡方法のルール（使うチャットツール / 定例会議の頻度 / 返信のルール / 議事録）
緊急時の相談ルート（どんな問題が起きたら、誰に、どう連絡するか）
作業する場所とルール（ソースコードの管理 / 担当者のアクセス権限）
使うツール、必要なアカウント、発生する費用（誰が負担するか）
デザインの設計図（design.md）を作るか（作る場合の担当者と更新ルール）
AI（人工知能）を使うルール（どの作業で使うか / 許可する範囲 / 禁止事項）
スケジュール管理（どうやって管理するか / 誰が更新するか / 大切な目標日）
公開（リリース）の手順（手順 / 責任者 / トラブル時に元に戻す基準）
作業完了の定義（これをもって完了とするお互いの合意）
変更時のルール（やりたいことが途中で変わったときの相談・決定方法）

キックオフ項目（Markdownコピペ用）

# キックオフ合意チェックリスト
- [ ] プロジェクトコンセプト（スピード優先 / 品質優先 など）
- [ ] 目的・成果指標（何をもって成功とするか）
- [ ] 作業範囲（やること / 今回はやらないこと）
- [ ] 役割分担・意思決定（最終決定者 / 承認の流れ）
- [ ] 連絡方法のルール（チャットツール / 定例 / 返信の期限 / 議事録）
- [ ] 緊急時の相談ルート（トラブル発生時の連絡先と手段）
- [ ] 作業する場所とルール（リポジトリ / ブランチ / 権限）
- [ ] 使うツール・必要アカウント・発生する費用
- [ ] design.md（デザイン設計書）の作成有無と管理ルール
- [ ] AI利用ポリシー（使う作業 / 許可する範囲 / 禁止事項）
- [ ] スケジュール管理（管理ツール / 更新担当者 / 大切な目標日）
- [ ] 公開（リリース）の手順（手順 / 責任者 / トラブル時に元に戻す基準）
- [ ] 作業完了の定義（これをもって完了とする合意）
- [ ] 変更時のルール（途中でやりたいことが変わったときの相談ルール）

AI利用ポリシー（コピペ用）

# AI利用ポリシー
## 1. 利用する作業
- [ ] 企画の整理・アイデア出し
- [ ] 設計書や要件定義の叩き台（ベース）作り
- [ ] 文章やコピーの作成
- [ ] 実装（プログラミング）のサポート
- [ ] 動作確認（テスト）のサポート

## 2. 許可する範囲
- 入力してよいデータ: [公開してよい情報 / 個人を特定できない情報 / 社内限定情報]
- AIが出した回答の扱い: [必ず人間が確認・修正して確定する]

## 3. 禁止事項
- 個人情報や機密（ヒミツ）情報をそのままAIに入力しない
- AIが作ったコードや文章を確認（テスト）せずにそのまま公開しない
- 他人の著作権や規約を侵害する恐れのあるものを納品しない

## 4. 相談・承認ルート
- ルール変更の相談先: [@お名前]
- 例外的な使い方をする場合の連絡先: [@お名前]

Web制作ヒアリングシート（コピペ用）

# 🚀 Web制作ヒアリングシート
          
## 1. 基本情報
- 会社名 / 担当者名:
- ご連絡方法（メール/Slack/その他）:

## 2. ホームページ作成の目的（ゴール）
- 解決したい課題 / 達成したい目標（売上・集客・認知など）:
- 特にアピールしたい強み・特徴:
- ホームページのゴール（問い合わせ/資料請求/購入など）:
- 参考にする競合サイト（3社ほど）:

## 3. ターゲット（どんな人に届けたいか）
- 年代 / 性別 / 個人向けか会社向けか / エリア:

## 4. ページ構成・希望する作業
- 希望する作業（企画/設計/デザイン/コーディング/開発/運用など全て）:
- 作りたいページ（新規作成 / 一部リニューアルなど）:
- 希望の公開予定日（締め切り）:

## 5. インフラ（サーバー等の準備）
- ドメイン・サーバー（新しく契約するか / すでにあるものを使うか）:
- テスト環境（本番前に確認する場所）の必要性:
- CMS（WordPressなど管理画面）の指定:

## 6. デザインの好み
- コーポレートカラー / 使いたい色:
- 素材（ロゴ・写真・紹介用の動画・文章）の有無:
- 参考にするサイト、パンフレットなどの有無:

## 7. 技術的な仕様
- 対応する端末（パソコンのみ / スマホ対応 / 両方で自動調整）:
- 検索エンジンで上位表示させたいキーワード（SEO）:
- OGP・SNS連携（SNSでシェアしたときの表示など）の有無:

## 8. その他
- 最終決定者（誰にOKをもらえば公開できるか）:
- 公開した後のメンテナンス（管理・運用）の体制:

体制図＆連絡方法設計テンプレート（コピペ用）

# 👥 プロジェクトの体制図 ＆ 連絡方法の設計

## 1. プロジェクトの体制図（だれが最終決定するか）
- **プロジェクトオーナー（最終決定者）**: [@お名前] (仕様の決定、予算やスケジュール変更の最終的な承認権限を持ちます)
- **ディレクション実務担当（窓口）**: [@お名前] (要件の整理、作業の段取り、スケジュール管理の全責任を持ちます)
- **制作・開発実務者**: [@お名前] (デザインの作成、システムのプログラミングなどを担当します)

## 2. 連絡方法の設計
- **メインで使うチャットツール**: Slack (チャンネル名: #xxx-project)
- **定例ミーティング（会議）**: 毎週 [曜日] [時間] 〜 [時間] (話す内容は前日までに関係者に共有します)
- **チャットの基本ルール**:
  - 自分宛てのメッセージには、原則24時間以内に「👀」リアクションを付けて確認したことを伝えます。
  - チャット上でやり取りが長引く（3往復以上）話は「スレッド」に移動し、決定事項だけを元のチャンネルに投稿します。
  - 会議などで決まった決定事項は、終わってから「5分以内」に要約をテキストにして関係者にチャットで共有します。

## 3. 緊急時の連絡ルート（トラブル時）
- **連絡が必要になるトラブル**:
  - 納期が24時間以上遅れそうなとき
  - 仕様（作り方）で意見が食い違い、現場で解決できないとき
  - 本番環境で重大なバグ（動かないなど）を発見したとき
- **最初の連絡先**: [@ディレクション実務担当]
- **次の連絡先（最終判断）**: [@プロジェクトオーナー]
- **連絡手段**: Slackメンション + 緊急時は電話

## 4. 作業のルールと場所
- **ソースコードの管理場所**: [GitHubのURLなど]
- **ブランチのルール**: main（本番）ブランチは直接触らず、必ず作業用ブランチを作成して他の人の確認（レビュー）を経て合流させます。
- **作業する環境の種類**: 開発者のパソコン（ローカル） / 確認用サーバー（ステージング） / 本番サーバー
- **デプロイ（本番反映）方法**: 自動ツール（GitHub Actions等）を使用（手動での上書きは禁止）
- **公開の条件**: チェックリストが完了し、最終決定者のOKが出ていること

## 5. リリース（公開）の手順
- **リリースの担当責任者**: [@お名前]
- **実行方法**: [指定の合流（マージ）後に自動でデプロイされる / 手動で実行する]
- **実行する時間帯**: [平日の何時 / 会議の後 など、アクセスが少ない安全な時間]
- **リリース時の連絡**: [Slackのチャンネルに、開始時と完了時に必ず投稿する]
- **元の状態に戻す（ロールバック）基準**: [重大なバグが発生した場合、即座に直前の動いていたバージョンに戻す]

## 6. 作業完了 of 定義（ここまでやったら「終わり」という合意）
- [ ] 最初に決めた機能やデザインがすべて形になっていること
- [ ] テスト項目（動作・表示・お問い合わせフォームの送信テスト等）がすべてクリアしていること
- [ ] 本番サーバーでの表示や機能のテストがすべて完了していること
- [ ] 納品するもの（URL、プログラムファイル、関連資料など）がすべて共有されていること
- [ ] お客様から最終的な確認（OK）のメッセージをもらっていること

## 7. ディレクションノート（その他に決めておくこと）
- **使用するツール**: [Figma / Notion / Slack / GitHub / その他]
- **必要なアカウントと権限**: [誰に何のアカウントを作るか]
- **費用**: [かかるツールの費用、誰の負担か]
- **スケジュール管理**: [どのツールで管理し、誰が、いつ更新するか]
- **補足**: [プロジェクト特有のルールがあれば追記します]

AGENTS.md（AIが迷わず動くための「取扱説明書」）テンプレート

# AGENTS.md — AIエージェント向け設計書

## 1. 重要: 自動で更新されない必須ファイル
以下はデプロイ時に自動更新されません。万が一消えてしまった場合は復旧手順に従ってください。
- `api/config.php`         : 各種設定・認証キー（パスワード等）
- `api/data/*.sqlite`      : データベースのファイル本体（保存してあるバックアップから復旧します）

## 2. データの取り扱いルール
- データを消すときは「本当に削除（DELETE）」せず、復活できるように status = 'deleted' に変更する（ゴミ箱に入れる）運用を原則とします。
- どうしても完全に削除する必要がある場合は、事前に必ずデータベースのバックアップがあるか確認してください。

## 3. デザインや表示ルールの変更ミス（先祖返り）防止
- 一度決まった画面の表示数や並び順は、プログラム側で固定（ハードコーディング）します。
- 公開用スクリプト（デプロイスクリプト）に、古い仕様に戻っていないか自動でチェックする処理を入れます。
- 意図的な変更の場合は、この自動チェックの条件も一緒に更新してください。

## 4. 公開した（デプロイ）後のチェック手順
1. 必須のファイルが正しく存在しているか確認します。
2. 古い仕様に逆戻りしていないか、自動チェックスクリプトを実行します。
3. 実際に画面を開いて動作確認をします（サーバーのセキュリティ制限がある場合はブラウザの自動化ツールを使用します）。

※ AI（人工知能）が作業する際の「取扱説明書」です。これをプロジェクトごとに用意しておくことで、AIが勝手な判断をしてプログラムを壊すリスクを防ぐことができます。

AI要件定義用プロンプト・コンポーネント

# クライアントからの要件インプット
[ここに箇条書きやメモを挿入]

# 出力ゴール
- 目的と背景の整理
- 必要な制作物（HTML/CSS/JS構成）
- 発生しうる懸念点と確認事項（3点）
上記を「段取り化（ステップ順）」して構造的に出力してください。

アジェンダ・議事録コンポーネント

# 定例MTG議事録 (2026/05/26)

## 🎯 今回の合意ゴール
- 本番リリースの日程決定
- 修正箇所の合意

## 📢 決定事項
- [x] リリース日は 2026年6月1日（月）に決定
- [x] キャッシュバスターのパラメータは「20260526」で統一

## ⏳ Next Action (誰が・いつまでに)
- [ ] @担当A : 修正対応 (5/28まで)
- [ ] @担当B : プレビュー確認 (5/29まで)

POST-LAUNCH

2. プロジェクトが始まってからやること（運用と改善）

ホームページやシステムを公開した後に発生するトラブルへの対応や、日々の品質維持、スムーズに改善を続けていくための実務セクションです。

POST-LAUNCH GOVERNANCE

B-0. 運用ルール（トラブルを防ぎ、スムーズに見直すチームの決めごと）

公開した後に「人によってやり方が違う」「勝手に書き換えてバグが出た」というトラブルを防ぐため、チームの運用スケジュールや公開のルールをあらかじめ決めておきます。

改善活動のスケジュール周期（1週間または2週間ごと）と、計画会議・振り返り会議を行う曜日を固定します。
トラブル時に「元の動いていた状態に戻す」基準（エラーの数や重大なバグなど）をあらかじめ決めておきます。
緊急の修正作業（Hotfix）が必要になった際、誰のOKをもらって、どこまで緊急対応してよいかをハッキリさせておきます。
チームの活動成績（バグの数、直すのにかかった時間など）を、スケジュール周期の終わりに毎回チェックします。
進め方を変えるときは必ずみんなのルールブック（議事録やマニュアル）に書き加え、次の作業から全員でそのやり方にそろえます。

運用ルール（Markdownコピペ用）

# ホームページ公開後のチーム運用ルール
## 1. 改善のサイクル（スケジュール）
- 期間（周期）: [1週間 / 2週間]
- 計画ミーティング（タスク決定）: [毎週○曜日 ○時〜]
- 振り返りミーティング（問題点の整理）: [毎週○曜日 ○時〜]

## 2. トラブル時の「元の状態に戻す」ルール
- 元に戻す（ロールバック）基準:
  - [ ] 画面が動かない、アクセスできないなどの重大なバグが発生したとき
  - [ ] 動作エラーが通常より多く発生しているとき
  - [ ] お問い合わせ数などの主要な成績が急激に下がったとき
- 判断の責任者: [@お名前]
- 戻す手順: [直前の安定していたバージョンへ戻す]

## 3. 緊急で修正する場合のルール（Hotfix）
- 実行する条件: [どんな緊急事態のときに即時修正するか]
- 最終承認者: [@お名前]
- 修正した後の対応: [翌営業日までに、原因と再発防止策を記録に残す]

## 4. 運用の成績レビュー
- チェックする項目: [バグの発生件数 / 復旧までにかかった時間 / 改善タスクの完了率]
- 確認する頻度: [サイクル（周期）の終わりごとに毎回]
- 改善の責任者: [@お名前]

DIRECTION PATTERNS

B-1. ディレクションパターン（トラブルを防ぐ定番の進行手順）

日々の作業やトラブルに直面したとき、スムーズに解決へ導くためのDiSA定番の進め方パターンです。

🏔️

30%の叩き台を先に見せて意見を集める

「何を作ればいいか曖昧なとき」に、ゼロから会議で話し合っても何も決まりません。まずは大雑把な「叩き台（モックアップ）」を作って見せることで、関係者から具体的なアイデアや修正の意見を引き出します。

大雑把な試作品（プロトタイプ）を作る

完璧でなくて良いので、目的の機能だけが動く大雑把な試作品を爆速で作り、関係者に見せます。

具体的なダメ出しや改善点を集める

具体的なモノがあると、「ここをもっとこうしてほしい」「これだと使いにくい」という具体的な意見がどんどん集まります。

フィードバックを元に完成度を高める

もらった意見を元にブラッシュアップを重ね、チーム全員が納得する最終的な形に仕上げて合意します。

# prompt_mockup.sh — プロトタイプ（叩き台）生成の例
if [ "$status" = "uncertain" ]; then
  echo "主要機能に絞った粗いモックアップを1ファイルで即時生成せよ"
  exit 0
fi

🛡️

先祖返り（古い仕様への逆戻り）を自動で防ぐ

「直したはずのバグが再発した」「古いデザインに戻った」といった先祖返りを、公開前の自動チェックで防ぎます。

仕様ルールをコードに固定する

表示数などのルールを、プログラムに明示的に書いておきます。

公開前チェックにルールを組み込む

本番公開の直前に、ルール違反がないか自動で検査します。

ルール違反なら公開を自動停止する

先祖返りを検知したら公開処理を止め、トラブルを未然に防ぎます。

# deploy_ssh.sh — 逆戻り（先祖返り）チェックの例
if grep -rq 'LIMIT 3' views/home.php; then
  echo "[ERROR] LIMIT 3 に逆戻り（先祖返り）しています。修正してください。"
  exit 1
fi

🌐

セキュアな本番環境での「表示崩れの自動チェック」

セキュリティが厳しく外部アクセスが遮断されるサーバーでも、プログラムを使って画面の見た目が崩れていないかを自動で確認する技術です。

通常のアクセスが防がれることを知る

セキュリティの壁（WAF）によって、簡易的な確認プログラムが遮断されることを知ります。

本物のブラウザを自動で動かして検証する

人間がスマホやパソコンで見るのと同じ動作をする「自動ブラウザ（Playwrightなど）」を使い、セキュリティの壁をクリアします。

画面写真（スクリーンショット）で自動で確認する

自動ブラウザで画面の写真をパシャリと撮影し、崩れている箇所がないかを目で見て素早く確認します。

🚨

作業が遅れてしまったときの「お助け・挽回ルート」

予定していた作業が何らかの理由で遅れてしまった（[!]マークが付いた）ときに、全体のスケジュールに響かないように素早く軌道修正する段取りです。

「なぜ遅れているか」の原因をハッキリさせる

「作り方がわからない」「人手が足りない」「急にやりたいことが増えた」など、遅れた原因がどこにあるかを特定します。

「どうやって挽回するか」の選択肢を示す

「今回は作るものを少し減らす」「公開日を数日遅らせる」「他の人に手伝ってもらう」などの具体的な解決案を作って提案します。

新しい段取りで合意し、すぐに記録する

選んだ解決案でお客様と合意し、新しいスケジュールやタスクをすぐに共有の計画書（プロジェクト管理.md）に書き換えて上書きします。

🗄️

データを消すときは「ゴミ箱マーク（論理削除）」を付けるだけにする

データを消す際、データベースから完全に削除するのではなく「ゴミ箱マーク（論理削除）」を付けるだけにします。これにより、誤削除でも簡単に元に戻せます。

「表示/非表示」を切り替える項目を用意する

データの中に status（状態）という項目を作り、消したいときは「deleted（削除済み）」というマークに書き換えるだけにします。

「本当に完全に消す」ときのルールを決めておく

サーバーの容量整理などで完全に消去したい場合は、必ずデータのバックアップを取った上で、責任者に確認をもらってから実行します。

万が一のためのデータ保存と戻し方を準備する

定期的にデータを別場所に保存し、万が一システムが壊れたときもすぐにデータを元に戻せる手順書を作っておきます。

🚀

本番公開（デプロイ）の手順をワンボタンでできるようにする

ホームページを本番公開する手順は、誰がやっても同じになるように「ボタン一つ（またはコマンド一つ）」で自動で動くように作っておきます。手作業でのコピーや手順書を見ながらの作業は必ずいつかミスが起きます。

ファイルのバージョン更新と整理を自動化する

古いファイルをブラウザが読み込まないようにする設定（キャッシュ対策）や、検索エンジン向けの地図ファイルを自動で作り直します。

本番データを保存してから安全にファイルを送る

公開する直前に本番環境のデータをまるごと別場所に保存し、その後に新しいプログラムファイルを安全に送り込みます。

公開した後に自動で問題がないかテストする

無事にファイルが送られた後、アクセス権限（パーミッション）が合っているか、画面が正しく開くかをプログラムで自動確認し、手作業によるチェックもれをゼロにします。

DO & DON'T

B-2. 実務での Do & Don't（仕事のすすめ方のルール）

ディレクションの質を保ち、チームが円滑に回るための行動ルールです。

✅ DO (推奨される行動)	❌ DON'T (避けるべき行動)
情報の一元管理（Single Source of Truth）を徹底する話し合って決まったスケジュールやタスクの変更は、すぐにチームの決定事項（プロジェクト管理.md）に書き込みます。	チャットで話しただけで「終わった」と勘違いする「Slackで伝えたから大丈夫」はNG。チャットはどんどん流れてしまうので、決まったことは必ず計画書（プロジェクト管理.md）に記録します。
データを消すときは「ゴミ箱マーク（論理削除）」を付けるだけにするデータの安全な復旧と変更履歴保護のため、削除は物理削除ではなく論理削除（status='deleted'などの非表示フラグ）にします。	確認もバックアップも取らずにデータを完全に消す十分なバックアップや検討を挟まずにデータベースからDELETEする操作は避ける。
画面の言葉と説明書の言葉を「1文字違わず」そろえるサイトやアプリのボタンの文字（例：「お問い合わせ」）と、お客様への案内やマニュアルの言葉遣いを完全に同期させます。	「まあ、大体同じ意味だから」と言葉のブレを放置する「要望投稿」「要望」など、類似した表現が混在していると、利用する人が混乱しホームページの信頼性も下がります。
AIを使ってまずは「要件の叩き台（ベース）」を作るまずはAIに大雑把なアイデアや要件を投げ、返ってきたものをベースに、人間が細かい抜け漏れやチームのルールに合わせて修正します。	AIが出した回答をチェックせずにそのまま使う AIが提案したスケジュールやプログラムをそのまま信じて使うと、実際のチームのスキルや環境に合わずにプロジェクトが崩壊します。
AI用の取扱説明書（AGENTS.md）を作ってルールを守らせる AI（人工知能）が作業するときに守るべき「禁止事項」や「確認手順」をAGENTS.mdに書いておき、AIが勝手なことをしないようにします。	「担当者の頭の中」だけにしかルールがない状態を放置する「その人しかわからない手順」は、担当者が変わったり、AIが作業に入ったりしたときに必ずトラブルを起こします。必ず文書化します。
公開する前のテストを自動化してミスを防ぐ「古い仕様に戻っていないか」「必要なファイルがあるか」を、公開時にプログラムが自動でチェックし、人間の「確認もれ」を防ぎます。	手動のチェックを「たぶん大丈夫」でサボる公開後のトラブルのほとんどは「確認したつもり」のサボりから起きます。確認を自動化することが最も安全な対策です。

ANTI-PATTERNS & SOLUTIONS

B-3. よくある失敗（アンチパターン）とDiSAの解決策

現場で陥りがちな「Webディレクションの典型的な失敗例」を、ディレクションシステムの仕組みでどのように未然に防ぐかの対比ガイドです。

💬

伝言ゲームの放置

【失敗例】お客様の曖昧な要望をしっかり整理せずそのまま開発メンバーに渡し、トラブルが起きると開発メンバーのせいにして責任逃れをする。

✅ 対策：まずは30%の試作品を見せる

言葉だけで話すのをやめ、まずは大雑把な「叩き台」を早く作って見せ、具体的な意見をもらいながら形にします。

📅

目的なき会議の乱発

【失敗例】話すテーマやゴールを決めずに会議を開き、何も決まらないまま「じゃあまた来週」と日程だけ決めて終わる。

✅ 対策：会議のゴールと議事録を徹底する

会議の前に「今日は何を決めるか」をハッキリさせ、決まったことと「誰がいつまでにやるか」をその場で議事録に書いて確定します。

🚀

要件なき公開日の独走

【失敗例】内容や人手を確認しないまま「この日に公開します」と約束し、最後は徹夜などの力技で強引に終わらせる。

✅ 対策：優先順位（コンセプト）を最初に合意する

「スピード・品質・コスト」の優先順位を最初に合意し、予定が厳しくなったら何を削るかのルールも事前に決めておきます。

📐

設計図の作成をサボる

【失敗例】設計図を作らずにプログラミングを始め、後から「これじゃ動かない」と前提が崩れて作り直すことになる。

✅ 対策：画面の設計図を最初に合意する

全体の画面のつながり（遷移図）を公開前にしっかりと決定し、途中で作りたいものが変わったときの相談ルールを用意しておきます。

🖥️

確認する画面の偏り

【失敗例】自分のパソコンの画面だけで動作を確認し、スマホで開いたときの崩れや、操作のしにくさを無視する。

✅ 対策：確認する端末（スマホなど）をあらかじめ決める

ユーザーがどの端末（パソコンかスマホか）をよく使うかを調べ、本番公開前にスマホ実機でしっかり確認する段取りを組みます。

🔍

他社を真似しただけの設計

【失敗例】「他社がこうしているから」と真似するだけで、なぜそうするかを考えず、なんとなくの雰囲気で決定してしまう。

✅ 対策：目的と自分たちの強みをハッキリ書く

このサイトで「何を解決したいか」「自分たちの強みは何か」をハッキリ書き出し、それに沿ってすべての画面や機能を決定します。

📝

要望の無計画な垂れ流し

【失敗例】お客様や他のメンバーから出た要望や思いつきを整理せず、そのまま「これやって」と開発に投げ続け、制作チームをクタクタに疲れさせる。

✅ 対策：優先順位の整理とチャットスレッドの活用

要望が出たら「今すぐやることか」「後でもいいか」を整理し、チャットで長引く議論は「スレッド」へ移動させて本流の会話を整理します。

💼

説明資料づくりが目的になる

【失敗例】社内の偉い人にOKをもらうため「だけ」の、分厚い会議用説明資料作りに何時間もかけてしまい、実務が進まない。

✅ 対策：決定者をハッキリさせてルートを縮める

「最終決定者は誰か」を最初の会議で一人に決めておき、その人に直接相談して確認をもらう最短ルートを作ります。

📈

大事な設定の後出し

【失敗例】公開直前になって急に「検索対策（SEO）をやって」「SNS設定もして」と後出しで追加し、現場をパニックにする。

✅ 対策：必要な設定は最初にリストに入れておく

検索キーワードやSNS連携などは、最初の設計段階でやることリストに入れておき、漏れを防ぎます。

📊

進捗管理の形骸化

【失敗例】スケジュールの色付けにこだわり、終わっていない作業を「終わった」とごまかし、公開直前に大バグで破綻する。

✅ 対策：進行状況を記号でウソ偽りなく管理する

`[ ]`・`[/]`・`[x]`・`[!]` の記号で実態に即したタスク管理を徹底します。AIやシステムもこれを監視し、自動で状況をそろえます。

📄

詳細ページの過小評価

【失敗例】トップページの見た目だけにこだわり、中身のページや管理画面の作成を後回しにして、最終的に時間が足りなくなる。

✅ 対策：作るすべてのページの一覧表を最初に作る

作る必要のあるすべてのページ（サイトマップ）を公開前の段階で全て書き出し、全体のボリュームをお互いに合意しておきます。

🌀

無限修正ループ

【失敗例】「何を作るか」の合意がないまま進め、完成後もお客様から「やっぱりここも直して」と修正が無限に入り続ける。

✅ 対策：仕様変更のルールと「唯一の決定記録」を徹底する

変更が生じた際の相談・承認ルールを決め、決まったことは『プロジェクト管理.md』にすぐ書き込んで「言った・言わない」のトラブルを防ぎます。

DIRECTION TOKENS

B-4. ディレクションの記法ルール（共通の記号表現）

プロジェクトの運用が走り出した後に使う、チームの共通ルール記号です。これらをそろえることで意思疎通のミスをさらに減らせます。

タスクの進み具合を表す記号（タスクステータス・トークン）

[ ] : まだやっていない（未着手・デフォルト状態）
[/] : いまやっている（進行中）
[x] : 終わった（完了・タスクをクローズ）
[!] : 警告・遅れている（トラブル発生、期限に間に合わない可能性があるアラート状態）

※ メモやタスク管理シートで使う記号です。このように表記をそろえておくことで、AIや管理システムが「今どのくらい作業が進んでいるか」を自動で読み取って判断できるようになります。

書類の状態を表す記号（ドキュメントステータス・トークン）

[DRAFT] : 下書き・作成中（まだ見せられる状態ではない）
[REVIEW] : 確認待ち・承認待ち（関係者にチェックしてもらっている状態）
[APPROVED] : 決定・確定済み（これに沿って進めます。書き直すときは再相談が必要です）
[ARCHIVED] : 過去の古い資料（参考として残してあるだけなので、最新の作業では使いません）

※ 仕様書、議事録、マニュアルなどのドキュメント名に付けて管理します。チーム内での「どれが最新の正しい資料か」の迷子を防ぎます。

チャットのリアクション記号（Slack/Discord用）

絵文字	意味定義	期待される行動
👀	「確認しました（確認中）」	メッセージを見ました、または対応中です。返信が不要な場合はこのリアクションだけでOKです。
🙌	「ありがとう・賛成です」	タスク完了の報告への感謝や、良い提案に対して「いいね！」「賛成！」を伝えるクイックレスポンスです。
💬	「スレッドに移行しました」	チャット上で会話が長引きそうなときに、他のメンバーに「スレッドで話していますよ」と伝える記号です。