出典://www.youtube.com/watch?v=rtyg-khmVp0
HTML変換するにはDillinger（個人アカウントでサインインする必要あり）
マークダウン形式で見るには　https://markdownlivepreview.com/
　
# エンジニア経営者のセイトです

こんにちは。
今日は「プロジェクトを進める上で必要なドキュメント」についてお話しします。

## ❓ なぜドキュメントが必要か

ビジネスでWebアプリやモバイルアプリを開発しようとすると、「行動よし、書こう！」ではなく、その前に必要なドキュメントがあります。

ドキュメントがないと…

- 人が辞めたら何がどうなってるかわからない
- 過去の情報が頭の中だけ
- スケール時に新しい人へ毎回1から説明＝超非効率

つまり、**ドキュメントがないとプロジェクトは破綻する可能性大**。

---

## ✅ 対象者

- リードエンジニア
- プロジェクトマネージャー
- 案件発注側の経営者

---

## 📚 プロジェクト成功のための10大ドキュメント

### 1. 画面設計書（ワイヤーフレーム）⇒要確では不要（開発が作成）

- デザインの前身
- UI部分の設計
- 見た目だけでなく「どこを押したら何が起きるか」も定義

---

### 2. サイトマップ⇒　1.に付随するものなので不要

- ページの一覧と遷移関係
- 複数のユーザータイプがある場合も網羅
- 管理画面忘れがち問題を防ぐ

---

### 3. スタイルガイド（デザインルールブック）⇒　1.に付随するものなので不要


- 使用色（ベースカラー・アクセントカラー）
- NG例（やってはいけないこと）
- サービスの一貫性を保つ
- デザイナー交代にも耐える

---

### 4. コーディングルール⇒不要

- エンジニア側のルールブック
- 「まるで一人が書いたようなコード」が理想
- バグ発見や機能追加時の混乱を防ぐ

> 例: Googleの公開しているコーディングガイドラインを参考にするのもアリ

---

### 5. 機能一覧書・仕様書⇒主にA6の中に

- 機能名、期待値、詳細仕様を一覧化
- 例：サインアップ機能 → Facebook連携？メール認証？登録情報は？
- 優先順位やスケジュールの議論にも有用

---

### 6. API仕様書⇒不要

- フロントエンドとバックエンド間のやり取りを定義
- 入出力パラメータ・エラー条件などを明記
- API設計・利用の両面で役立つ

> おすすめツール：AppIary、もしくはスプレッドシートでの管理も◎

---

### 7. テーブル定義書⇒A8,A9他

- データベースの構成表
- 保存対象（ユーザー名、メールアドレス、出身地など）を定義
- プログラミング時の重要資料

---

### 8. ER図（エンティティリレーション図）⇒開発アイテム

- データベースの相関図（構造の概要）
- オブジェクト間の関係性を視覚化
- テーブル定義書とセットで使うと理解が深まる

---

### 9. インフラ構成図⇒開発アイテム

- サーバー・ネットワーク構成の設計図
- 使用サービス例：AWS（EC2、CloudWatch など）
- ユーザー数や負荷に応じて柔軟に設計する必要あり

---

### 10. フローチャート⇒A5

- 各機能の動作フローを可視化
- 条件分岐、エラー処理、リダイレクトなどを明示
- 特に複雑な機能に有効

---

## 💡 補足

- 全部を最初から揃える必要はない
- プロジェクトの規模やスピード感に応じて後回しでもOK
- ただし、「無いよりは圧倒的にマシ」なドキュメントばかり

---

## 🙏 最後に

このチャンネルでは、
**プログラミング・ライフハック・Web業界の情報**を日々発信中です。

気に入ってもらえたら  
**チャンネル登録・高評価**をよろしくお願いします！

ではまた次の動画でお会いしましょう！  
**バイバイ！**