【制作者必見】Markdownで始める制作フロー文書化｜ドキュメント作成の効率化ガイド

# 見出し1
## 見出し2

これは**太字**で、これは*イタリック*です。

- リスト項目1
- リスト項目2
- リスト項目3

[リンクテキスト](https://example.com)

<h1>見出し1</h1>
<h2>見出し2</h2>

<p>これは<strong>太字</strong>で、これは<em>イタリック</em>です。</p>

<ul>
  <li>リスト項目1</li>
  <li>リスト項目2</li>
  <li>リスト項目3</li>
</ul>

<a href="https://example.com">リンクテキスト</a>

# 見出し1（H1）
## 見出し2（H2）
### 見出し3（H3）
#### 見出し4（H4）
##### 見出し5（H5）
###### 見出し6（H6）

箇条書きリスト
- 項目1
- 項目2
  - ネストした項目2-1
  - ネストした項目2-2
- 項目3

番号付きリスト
1. ステップ1
2. ステップ2
3. ステップ3

チェックリスト
- [ ] 未完了のタスク
- [x] 完了したタスク

**太字（Bold）**
*イタリック（Italic）*
***太字かつイタリック***
~~取り消し線~~
`インラインコード`

通常のリンク
[リンクテキスト](https://example.com)

タイトル付きリンク
[リンクテキスト](https://example.com "マウスオーバー時のタイトル")

参照リンク
[リンクテキスト][ref]

[ref]: https://example.com "参照定義"

基本的な画像
![代替テキスト](画像URL)

ローカル画像
![フローチャート](./images/flowchart.png)

```javascript
function greet(name) {
  console.log(`Hello, ${name}!`);
}

greet('World');
```

```python
def greet(name):
    print(f"Hello, {name}!")

greet("World")
```

```bash
# シェルコマンド
npm install
npm run dev
```

| 列1 | 列2 | 列3 |
|------|------|-----|
| データ1 | データ2 | データ3 |
| データ4 | データ5 | データ6 |


| 左寄せ | 中央寄せ | 右寄せ |
|:-------|:--------:|-------:|
| Left | Center | Right |

> これは引用文です。
> 複数行にわたって
> 記述できます。

---

# Web制作プロジェクト 制作フロー

## プロジェクト概要

- **プロジェクト名**: 〇〇株式会社 コーポレートサイト制作
- **納期**: 2026年3月31日
- **担当者**: 山田太郎（PM）、佐藤花子（デザイナー）、鈴木一郎（エンジニア）
- **予算**: 300万円

## プロジェクトゴール

1. ブランドイメージの刷新
2. 問い合わせ数を月間50件から100件に増加
3. スマートフォン対応の実現

## スケジュール

| フェーズ | 期間 | 担当 | ステータス |
|---------|------|------|-----------|
| 要件定義 | 2/1 - 2/7 | PM | 完了 |
| デザイン | 2/8 - 2/28 | デザイナー | 進行中 |
| 実装 | 3/1 - 3/21 | エンジニア | 未着手 |
| テスト | 3/22 - 3/28 | 全員 | 未着手 |
| 納品 | 3/31 | PM | 未着手 |

## 制作フロー

### 1. 要件定義フェーズ

**目的**: クライアントの要望を正確に把握し、仕様書に落とし込む

**タスク**:
- [ ] キックオフミーティング実施
- [ ] ヒアリングシート作成
- [ ] 要件定義書作成
- [ ] クライアント確認・承認

**成果物**:
- 要件定義書.pdf
- サイトマップ.xlsx
- 機能一覧.xlsx

**注意点**:
- 仕様の曖昧さを残さない
- 追加要望は別途見積もり

### 2. デザインフェーズ

**目的**: ビジュアルデザインを確定させる

**タスク**:
- [ ] ワイヤーフレーム作成
- [ ] デザインカンプ作成（TOPページ）
- [ ] デザインカンプ作成（下層ページ）
- [ ] デザインガイドライン作成
- [ ] クライアント確認・修正対応

**ツール**:
- Figma
- Adobe XD

**成果物**:
- ワイヤーフレーム.fig
- デザインカンプ.fig
- デザインガイドライン.pdf

### 3. 実装フェーズ

**目的**: デザインをもとにコーディング

**技術スタック**:
- Next.js 14
- TypeScript
- Tailwind CSS
- Vercel（ホスティング）

**タスク**:
- [ ] 環境構築
- [ ] 共通コンポーネント実装
- [ ] TOPページ実装
- [ ] 下層ページ実装
- [ ] レスポンシブ対応
- [ ] SEO対策実装

**品質基準**:
- Lighthouse パフォーマンススコア 90以上
- アクセシビリティスコア 90以上
- すべてのブラウザで動作確認（Chrome、Firefox、Safari、Edge）

### 4. テストフェーズ

**テスト項目**:
- [ ] 機能テスト（全ページ）
- [ ] レスポンシブテスト（モバイル・タブレット・PC）
- [ ] クロスブラウザテスト
- [ ] 表示速度テスト
- [ ] SEOチェック

**テスト環境**:
- ステージング環境: https://staging.example.com

### 5. 納品フェーズ

**納品物**:
- 本番環境のURL
- ソースコード（GitHubリポジトリ）
- 運用マニュアル.pdf
- デザインデータ

**引き継ぎ事項**:
- CMSの使い方
- 更新手順
- トラブルシューティング

## 連絡体制

| 役割 | 名前 | 連絡先 | 対応時間 |
|-----|------|--------|---------|
| PM | 山田太郎 | yamada@example.com | 平日 9:00-18:00 |
| デザイナー | 佐藤花子 | sato@example.com | 平日 10:00-19:00 |
| エンジニア | 鈴木一郎 | suzuki@example.com | 平日 10:00-19:00 |

**定例ミーティング**: 毎週月曜日 10:00-11:00（Zoom）

## リスク管理

| リスク | 影響度 | 対策 |
|-------|--------|------|
| デザイン修正が多発 | 高 | 修正回数を契約で2回までと明記 |
| 技術的な実装困難 | 中 | 事前に技術検証を実施 |
| 納期遅延 | 高 | バッファを1週間確保 |

## 参考資料

- [プロジェクト管理ツール](https://example.com/project)
- [デザインガイドライン](./design-guideline.md)
- [コーディング規約](./coding-standards.md)

```mermaid
flowchart TD
    Start[プロジェクト開始] --> Hearing[クライアントヒアリング]
    Hearing --> Requirement[要件定義書作成]
    Requirement --> Approval{クライアント承認}

    Approval -->|承認| Design[デザイン作成]
    Approval -->|却下| Hearing

    Design --> DesignReview{デザインレビュー}
    DesignReview -->|OK| Development[実装開始]
    DesignReview -->|修正必要| Design

    Development --> Testing[テスト]
    Testing --> BugCheck{バグ発見？}

    BugCheck -->|あり| BugFix[バグ修正]
    BugFix --> Testing
    BugCheck -->|なし| Release[本番リリース]

    Release --> End[プロジェクト完了]

    style Start fill:#e1f5e1
    style End fill:#ffe1e1
    style Approval fill:#fff4e1
    style DesignReview fill:#fff4e1
    style BugCheck fill:#fff4e1
```

```mermaid
sequenceDiagram
    participant C as クライアント
    participant PM as プロジェクトマネージャー
    participant D as デザイナー
    participant E as エンジニア

    C->>PM: プロジェクト依頼
    PM->>C: ヒアリング実施
    PM->>PM: 要件定義書作成
    PM->>C: 要件定義書提出

    alt 承認
        C->>PM: 承認
        PM->>D: デザイン依頼
        D->>D: デザインカンプ作成
        D->>PM: デザイン提出
        PM->>C: デザイン確認依頼

        alt デザインOK
            C->>PM: 承認
            PM->>E: 実装依頼
            E->>E: コーディング
            E->>PM: 実装完了報告
            PM->>C: テスト環境URL共有
        else 修正必要
            C->>PM: 修正依頼
            PM->>D: 修正指示
        end

    else 却下
        C->>PM: 修正依頼
        PM->>PM: 要件定義書修正
    end
```

```mermaid
gantt
    title Web制作プロジェクトスケジュール
    dateFormat YYYY-MM-DD

    section 要件定義
    ヒアリング           :done, req1, 2026-02-01, 3d
    要件定義書作成       :done, req2, after req1, 4d
    クライアント承認     :done, req3, after req2, 2d

    section デザイン
    ワイヤーフレーム     :active, des1, 2026-02-08, 5d
    デザインカンプ作成   :des2, after des1, 10d
    デザイン修正         :des3, after des2, 5d

    section 実装
    環境構築             :dev1, 2026-03-01, 2d
    共通コンポーネント   :dev2, after dev1, 5d
    ページ実装           :dev3, after dev2, 10d
    レスポンシブ対応     :dev4, after dev3, 4d

    section テスト
    機能テスト           :test1, 2026-03-22, 3d
    修正対応             :test2, after test1, 3d
    最終確認             :test3, after test2, 2d

    section 納品
    本番リリース         :milestone, release, 2026-03-31, 0d
```

# 1. リポジトリを初期化
git init

# 2. ドキュメントを作成
echo "# プロジェクト制作フロー" > workflow.md

# 3. Gitに追加
git add workflow.md

# 4. コミット
git commit -m "feat: 制作フロー文書を追加"

# 5. リモートリポジトリにプッシュ
git remote add origin https://github.com/username/project-docs.git
git push -u origin main

# 新しいブランチを作成して切り替え
git checkout -b feature/update-workflow

# ドキュメントを編集
vim workflow.md

# 変更をコミット
git add workflow.md
git commit -m "docs: デザインフェーズの詳細を追加"

# プッシュ
git push origin feature/update-workflow

# GitHubでPull Requestを作成
# チームメンバーがレビュー
# 承認後、mainブランチにマージ

$ git diff

diff --git a/workflow.md b/workflow.md
index 1234567..abcdefg 100644
--- a/workflow.md
+++ b/workflow.md
@@ -10,7 +10,7 @@

 ## スケジュール

-- **要件定義**: 2月1日〜2月7日
+- **要件定義**: 2月1日〜2月10日（3日延長）
 - **デザイン**: 2月8日〜2月28日
 - **実装**: 3月1日〜3月21日

docs: 制作フロー文書を新規作成
docs: デザインフェーズの詳細を追加
docs: スケジュールを3日延長に更新
docs: 連絡体制の表を修正
docs: リスク管理セクションを追加

VSCodeでworkflow.mdを開き、以下のようにコメントを書く
# Web制作プロジェクト 制作フロー

## プロジェクト概要
Copilotがここから自動補完してくれる

「Cmd/Ctrl+I」でCopilot Chatを開き、以下のように指示
"このプロジェクトの制作フローをMarkdownで作成してください。
フェーズは要件定義、デザイン、実装、テスト、納品の5つです。
各フェーズにタスクリストとチェックボックスを含めてください。"

"以下の制作フローをMermaidのフローチャートで作成してください：

1. プロジェクト開始
2. クライアントヒアリング
3. 要件定義書作成
4. クライアント承認（承認されたら次へ、却下されたらヒアリングに戻る）
5. デザイン作成
6. デザインレビュー（OKなら次へ、修正必要ならデザイン作成に戻る）
7. 実装開始
8. テスト
9. バグチェック（バグありなら修正、なしならリリース）
10. 本番リリース
11. プロジェクト完了

開始と完了は緑、承認・レビュー・チェックは黄色で色分けしてください。"

"このworkflow.mdをレビューして、以下の観点で改善提案をしてください：

1. 構造が分かりやすいか
2. 必要な情報が網羅されているか
3. チームメンバーが実行しやすい形式か
4. リスク管理が十分か
5. Markdown記法が適切に使われているか"

project-root/
├── README.md              # プロジェクト概要
├── docs/
│   ├── workflow.md        # 制作フロー
│   ├── design-guide.md    # デザインガイドライン
│   ├── coding-standards.md # コーディング規約
│   ├── deployment.md      # デプロイ手順
│   └── troubleshooting.md # トラブルシューティング
├── meeting-notes/         # 議事録
│   ├── 2026-02-01.md
│   └── 2026-02-08.md
└── images/                # ドキュメント用画像
    └── flowchart.png

# プロジェクト名

## ドキュメント一覧

- [制作フロー](./docs/workflow.md)
- [デザインガイドライン](./docs/design-guide.md)
- [コーディング規約](./docs/coding-standards.md)
- [デプロイ手順](./docs/deployment.md)
- [トラブルシューティング](./docs/troubleshooting.md)

## クイックスタート

1. リポジトリをクローン
2. 依存関係をインストール：`npm install`
3. 開発サーバーを起動：`npm run dev`

## チーム

| 役割 | 名前 | 連絡先 |
|-----|------|--------|
| PM | 山田太郎 | yamada@example.com |
| デザイナー | 佐藤花子 | sato@example.com |

.github/pull_request_template.md
## 変更内容

何を変更したかを簡潔に記述

## 変更理由

なぜこの変更が必要かを説明

## チェックリスト

- [ ] 誤字脱字がないか確認した
- [ ] リンクが正しく動作するか確認した
- [ ] Mermaid図が正しく表示されるか確認した
- [ ] 関連する他のドキュメントも更新した

## スクリーンショット（該当する場合）

ビフォーアフターのスクリーンショットを添付

ファイル名は小文字とハイフン
workflow.md
coding-standards.md
2026-02-01-meeting.md

避けるべき命名
WorkFlow.md（大文字混在）
coding_standards.md（アンダースコア）
制作フロー.md（日本語ファイル名）