オンボーディングドキュメントの目的

オンボーディングドキュメントは「新しいチームメンバーが最短で自走できる状態になる」ために存在します。 ベテランメンバーの暗黙知を明文化し、毎回の口頭説明を不要にすることが主なゴールです。

💡 オンボーディングドキュメントの品質指標

「このドキュメントだけを読んで、新メンバーが最初の Pull Request を出せるか」が最も実用的な品質指標です。定期的に新規参加者に試してもらい、詰まった箇所を即座に修正する文化を作りましょう。

プロジェクト概要・アーキテクチャ

新メンバーが全体像を把握するために必要な情報を定義します。

定義項目内容
プロダクトの目的何を解決するサービスか・誰が使うか
アーキテクチャ概要図(モノリス/マイクロサービス/サーバーレス等)とサービス間の関係
主要なリポジトリ一覧リポジトリ名・役割・対応チーム
技術スタック言語・フレームワーク・DB・インフラ(AWS/GCP/Azure)
デプロイ環境dev / staging / production の違い・URL・アクセス方法
ドキュメント一覧ADR の場所・仕様書の場所・Slack チャンネル

環境構築手順

環境構築手順は「コマンドをコピペすれば動く」レベルに具体的に書きます。バージョン番号は必ず明記します。

Markdown — 環境構築手順テンプレート
## 環境要件

| ツール | バージョン | インストール方法 |
|--------|-----------|----------------|
| Python | 3.12.x    | [pyenv](https://github.com/pyenv/pyenv) 推奨 |
| Node.js | 22.x LTS | [nvm](https://github.com/nvm-sh/nvm) 推奨 |
| Docker  | 26.x 以上 | [Docker Desktop](https://docs.docker.com/desktop/) |
| AWS CLI | 2.x       | `brew install awscli` |

## セットアップ手順

### 1. リポジトリのクローン

```bash
git clone git@github.com:example/my-app.git
cd my-app
```

### 2. Python 仮想環境の作成

```bash
pyenv install 3.12.4  # 初回のみ
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install -e ".[dev]"    # 開発依存も含めてインストール
```

### 3. 環境変数の設定

```bash
cp .env.example .env
# .env をエディタで開き、以下の値を設定する(Slack #dev-secrets に記載あり):
# - DATABASE_URL
# - REDIS_URL
# - AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
```

### 4. データベースのセットアップ

```bash
docker compose up -d db redis  # DB と Redis を起動
python manage.py migrate       # マイグレーション実行
python manage.py seed          # 初期データ投入
```

### 5. 動作確認

```bash
python manage.py runserver
# → http://localhost:8000 でアクセスできれば成功
```

## よくある問題

### `ModuleNotFoundError: No module named 'xxx'`
仮想環境が有効化されていない可能性があります。
`source .venv/bin/activate` を再実行してください。

### Docker が起動しない(Mac M1/M2)
`docker compose` コマンドで `platform: linux/amd64` を指定することで解決する場合があります。
→ 詳細: [Notion - M1 Mac セットアップ Tips](https://notion.so/xxx)

アカウント・アクセス権限

新メンバーが「自分にはどのシステムへのアクセスが必要か」を一覧で把握できるようにします。 申請方法と承認者も明記してください。

システム/ツール役割申請方法承認者
GitHub Organizationコードレビュー・PREMに Slack で依頼エンジニアリングマネージャー
AWS (dev環境)開発環境のデプロイ・ログ参照Jira チケット起票インフラチーム
Datadog本番ログ・メトリクス参照上記に含むインフラチーム
SlackチームコミュニケーションIT ヘルプデスクに申請IT部門
Notionドキュメント参照・編集EM に Slack で依頼エンジニアリングマネージャー

開発ワークフロー

PR を出すまでの一連の流れを定義します。

ステップ内容・ルール
ブランチ命名規則feat/jira-123-add-order-exportfix/issue-456-timeout 形式
コミットメッセージConventional Commits 形式(feat(orders): CSV エクスポートを追加
PR サイズ最大 400 行の変更(レビュー負荷を下げるため)
PR テンプレート変更の目的・テスト方法・スクリーンショット(UI 変更時)
レビュー承認数最低 2 名の Approve が必要
CI 要件テスト全件パス・カバレッジ 80% 以上・lint エラーなし
マージ方法Squash Merge(コミット履歴をクリーンに保つ)

チームの文化・コミュニケーション

暗黙のルールを明文化します。新メンバーが「空気を読む」必要をなくすことが目的です。

項目内容
主要 Slack チャンネル#dev-general(全体)/ #dev-backend / #dev-alerts(アラート)/ #dev-deploys(デプロイ通知)
ミーティング月〜金 10:00 デイリースタンドアップ(15分)/ 水 15:00 スプリントレビュー
質問のしやすさ「質問して時間を取らせるな」は文化的にNG。Slack で気軽に質問してください。
コードレビューの姿勢コードを批判するのではなく、コードについて質問する。「なぜこうしたのですか?」
オンコール入社 3 ヶ月後からローテーション参加。Runbook は doc/ops/ を参照。

最初のタスク・マイルストーン

入社後 1 週間・1 ヶ月・3 ヶ月のマイルストーンを定義すると、新メンバーが自分のペースを評価しやすくなります。

期間達成目標
1 週目 □ 環境構築完了・アプリがローカルで動作する
□ 開発ワークフローを理解して最初の PR を出す(Good First Issue を使う)
□ チームメンバー全員と 1on1 実施
1 ヶ月目 □ 小〜中規模のタスクを自走で完了できる
□ コードレビューをレビュイーとしてこなせる
□ アーキテクチャ全体を自分の言葉で説明できる
3 ヶ月目 □ スプリントのタスクを独立してリードできる
□ 他メンバーのレビュアーになれる
□ オンコールローテーションに参加できる

Good First Issue を用意しておく

Issue トラッカーに good-first-issue ラベルを付けた小さなタスクを常に数件用意しておきましょう。コードベースを理解しながら最初の貢献ができるタスクが理想です。

Python で環境診断スクリプトを作る

オンボーディング手順の最後に「環境診断スクリプトを実行して全件 OK を確認する」ステップを設けると、セットアップ漏れを早期に検出できます。

① 環境要件チェックスクリプト

Python — 開発環境の要件を自動チェックする
"""
開発環境の要件を自動チェックする診断スクリプト。
オンボーディング手順の最終ステップで実行する。

使い方:
  python scripts/check_env.py

全チェックが ✅ になれば環境構築完了。
"""
import shutil
import subprocess
import sys
import os
from dataclasses import dataclass


@dataclass
class Check:
    name: str
    result: bool
    detail: str
    hint: str = ""


def check_command_version(
    cmd: str, args: list[str], min_version: tuple[int, ...]
) -> Check:
    """コマンドが存在し、最低バージョンを満たすか確認する。"""
    if not shutil.which(cmd):
        return Check(cmd, False, "コマンドが見つかりません", f"`{cmd}` をインストールしてください")
    try:
        out = subprocess.check_output([cmd] + args, text=True, stderr=subprocess.STDOUT)
        # バージョン番号を抽出("3.12.4" 形式を想定)
        import re
        m = re.search(r"(\d+)\.(\d+)\.?(\d*)", out)
        if not m:
            return Check(cmd, False, f"バージョンを解析できません: {out.strip()}")
        actual = tuple(int(x) for x in m.groups() if x)
        ok = actual >= min_version
        detail = ".".join(str(x) for x in actual)
        min_str = ".".join(str(x) for x in min_version)
        hint = f"{min_str} 以上が必要です" if not ok else ""
        return Check(cmd, ok, detail, hint)
    except subprocess.CalledProcessError as e:
        return Check(cmd, False, str(e))


def check_env_var(name: str) -> Check:
    """環境変数が設定されているか確認する。"""
    value = os.environ.get(name, "")
    if not value:
        return Check(
            f"env:{name}", False, "未設定",
            f"`.env` ファイルに `{name}` を設定してください(#dev-secrets を参照)"
        )
    # シークレット値の先頭4文字だけ表示
    masked = value[:4] + "..." if len(value) > 4 else "***"
    return Check(f"env:{name}", True, masked)


def check_docker_compose() -> Check:
    """Docker Compose で DB が起動しているか確認する。"""
    try:
        out = subprocess.check_output(
            ["docker", "compose", "ps", "--format", "json"],
            text=True, stderr=subprocess.DEVNULL
        )
        if "db" in out and "running" in out.lower():
            return Check("docker-compose db", True, "running")
        return Check(
            "docker-compose db", False, "DB コンテナが起動していません",
            "`docker compose up -d db` を実行してください"
        )
    except (subprocess.CalledProcessError, FileNotFoundError) as e:
        return Check("docker-compose db", False, str(e))


def run_all_checks() -> list[Check]:
    return [
        check_command_version("python", ["--version"], (3, 12, 0)),
        check_command_version("node", ["--version"], (22, 0, 0)),
        check_command_version("docker", ["--version"], (26, 0, 0)),
        check_command_version("aws", ["--version"], (2, 0, 0)),
        check_env_var("DATABASE_URL"),
        check_env_var("REDIS_URL"),
        check_env_var("AWS_ACCESS_KEY_ID"),
        check_docker_compose(),
    ]


if __name__ == "__main__":
    print("=" * 60)
    print("開発環境 診断レポート")
    print("=" * 60)

    checks = run_all_checks()
    passed = sum(1 for c in checks if c.result)
    failed = len(checks) - passed

    for c in checks:
        icon = "✅" if c.result else "❌"
        print(f"{icon} {c.name:<30} {c.detail}")
        if not c.result and c.hint:
            print(f"   → {c.hint}")

    print("-" * 60)
    print(f"結果: {passed}/{len(checks)} 件 OK")

    if failed > 0:
        print(f"\n⚠️  {failed} 件の問題があります。上記の hint を参照して修正してください。")
        print("解消できない場合は Slack #dev-general で質問してください。")
        sys.exit(1)
    else:
        print("\n🎉 すべての環境チェックが完了しました!開発を始めましょう。")

② 依存パッケージのバージョンを自動出力

Python — インストール済みパッケージと要件を対比表示
"""
requirements.txt や pyproject.toml に記載されたパッケージが
期待バージョンでインストールされているか確認する。

使い方:
  python scripts/check_packages.py
"""
import importlib.metadata
from pathlib import Path
import re

def parse_requirements(path: str) -> dict[str, str]:
    """requirements.txt からパッケージ名とバージョン制約を返す。"""
    reqs = {}
    for line in Path(path).read_text().splitlines():
        line = line.strip()
        if not line or line.startswith("#"):
            continue
        m = re.match(r"([\w\-]+)\s*(==|>=|<=|!=|~=)?\s*([\d.]+)?", line)
        if m:
            reqs[m.group(1).lower()] = f"{m.group(2) or ''}{m.group(3) or ''}"
    return reqs

def check_packages() -> None:
    requirements = parse_requirements("requirements.txt")
    print(f"{'パッケージ':<30} {'要件':<15} {'インストール済み':<20} {'OK'}")
    print("-" * 75)
    for pkg, req in sorted(requirements.items()):
        try:
            installed = importlib.metadata.version(pkg)
            print(f"{pkg:<30} {req:<15} {installed:<20} ✅")
        except importlib.metadata.PackageNotFoundError:
            print(f"{pkg:<30} {req:<15} {'未インストール':<20} ❌")

if __name__ == "__main__":
    check_packages()

ドキュメントの保守戦略

オンボーディングドキュメントは「書いたら終わり」ではなく、生きたドキュメントとして更新が必要です。

施策内容
新メンバーがドキュメント更新セットアップ中に気づいた誤りをその場で修正する PR を出す文化
四半期レビューEMがドキュメントを通読して陳腐化した箇所を更新
環境バージョン更新フローツールのバージョンを上げた PR にドキュメント更新を必須とするルール
ドキュメント最終更新日の明記「最終更新: 2026-06-20」をドキュメント冒頭に記載

まとめ

オンボーディングドキュメントで定義すべき要素

□ プロジェクト概要・アーキテクチャ図・技術スタック
□ 環境構築手順(バージョン明記・コピペで動くコマンド・FAQ)
□ アカウント/アクセス権限一覧(申請方法・承認者)
□ 開発ワークフロー(ブランチ命名・コミットメッセージ・PR ルール・CI 要件)
□ チームの文化・Slack チャンネル・ミーティング一覧
□ 1週間/1ヶ月/3ヶ月マイルストーン
□ Good First Issue の整備
□ 環境診断スクリプト(Python)
□ 最終更新日と保守フローの定義