コンテンツにスキップ

02. Docsフォルダ

Docs/フォルダは、本プロジェクトに関する全てのドキュメントのソースファイルを一元管理する場所です。 ここに格納されたドキュメントは、静的サイトジェネレータ（例: MkDocs）によってビルドされ、開発者や関係者が閲覧可能なドキュメントサイトとして公開されることを想定しています。

唯一の正しい情報源 (Single Source of Truth)

プロジェクトに関する仕様、ルール、議事録などの公式な情報は、全てこのDocs/フォルダ内に集約します。 情報が外部のWikiや個人のメモなどに分散することを防ぎ、常に最新かつ信頼できる情報源として機能させます。

標準的な構成

Docs/フォルダ内は、情報の種類に応じてカテゴリ分けすることが推奨されます。以下は、本プロジェクトで採用している標準的な構成です。

Docs/
├── README.md           # ドキュメントサイトのトップページ
│
├── 00_はじめに/        # (A) プロジェクトへの導入
├── 01_システム仕様/    # (B) システム全体の仕様
├── 02_ユースケース/    # (C) 利用者の視点でのシナリオ
├── 03_設計仕様/        # (D) 技術的な実現方法の定義
├── 04_開発ルール/      # (E) 開発の進め方に関する規約
├── 05_運用・リリース/  # (F) 運用とリリースに関する情報
├── 06_テスト仕様/      # (G) 品質の保証方法に関する定義
│
└── assets/             # (H) ドキュメント内で使用する静的ファイル

(A) 00_はじめに

  • 目的: プロジェクトに新しく参加したメンバーが、迅速に全体像を理解し、開発を開始できるようにするための導入情報を提供します。
  • 主な内容:
    • プロジェクトの目的と背景
    • ドキュメント全体の歩き方
    • 開発環境のセットアップガイドへのリンク

(B) 01_システム仕様

  • 目的: プロジェクトが提供するシステム全体の機能的・非機能的な要求を定義します。
  • 主な内容:
    • システム要求仕様
    • 機能一覧
    • 非機能要求（パフォーマンス、セキュリティ、可用性など）

(C) 02_ユースケース

  • 目的: 利用者の視点から、システムがどのように利用されるかを具体的なシナリオとして記述します。要求仕様を補完し、開発者が利用者の文脈を理解するのを助けます。
  • 主な内容:
    • 主要な利用者（アクター）の定義
    • ユーザーストーリー
    • 具体的な業務フロー、操作シナリオ

(D) 03_設計仕様

  • 目的: 要求仕様やユースケースを「どのように」技術的に実現するかを詳細に記述します。実装の基礎となる設計情報です。
  • 主な内容:
    • システムアーキテクチャ
    • UI/UX設計（画面遷移図、ワイヤーフレーム）
    • API仕様書
    • データベース設計（ER図、テーブル定義）

(E) 04_開発ルール

  • 目的: 開発プロセスの一貫性とコード品質を保つための規約を定めます。
  • 主な内容:
    • フォルダ構成の規約（このドキュメント）
    • Git利用ルール（ブランチ戦略など）
    • コーディング規約
    • コードレビューのガイドライン

(F) 05_運用・リリース

  • 目的: 完成したシステムのリリース手順や、リリース後の運用・保守に関する情報を集約します。
  • 主な内容:
    • リリース手順、バージョン管理方針
    • インフラ構成
    • 監視・モニタリング計画
    • トラブルシューティングガイド

(G) 06_テスト仕様

  • 目的: システムの品質を「どのように」保証し、検証するかを定義します。
  • 主な内容:
    • テスト戦略、テスト計画
    • テストケース、テストシナリオ
    • 自動テストの設計

(H) assets

  • 目的: ドキュメント内で共通して利用する静的ファイルを格納します。
  • 主な内容:
    • 画像ファイル（スクリーンショット、図表）
    • ロゴ、アイコン