オンボーディングドキュメントの目的
オンボーディングドキュメントは「新しいチームメンバーが最短で自走できる状態になる」ために存在します。 ベテランメンバーの暗黙知を明文化し、毎回の口頭説明を不要にすることが主なゴールです。
💡 オンボーディングドキュメントの品質指標
「このドキュメントだけを読んで、新メンバーが最初の Pull Request を出せるか」が最も実用的な品質指標です。定期的に新規参加者に試してもらい、詰まった箇所を即座に修正する文化を作りましょう。
プロジェクト概要・アーキテクチャ
新メンバーが全体像を把握するために必要な情報を定義します。
| 定義項目 | 内容 |
|---|---|
| プロダクトの目的 | 何を解決するサービスか・誰が使うか |
| アーキテクチャ概要 | 図(モノリス/マイクロサービス/サーバーレス等)とサービス間の関係 |
| 主要なリポジトリ一覧 | リポジトリ名・役割・対応チーム |
| 技術スタック | 言語・フレームワーク・DB・インフラ(AWS/GCP/Azure) |
| デプロイ環境 | dev / staging / production の違い・URL・アクセス方法 |
| ドキュメント一覧 | ADR の場所・仕様書の場所・Slack チャンネル |
環境構築手順
環境構築手順は「コマンドをコピペすれば動く」レベルに具体的に書きます。バージョン番号は必ず明記します。
## 環境要件
| ツール | バージョン | インストール方法 |
|--------|-----------|----------------|
| 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 | コードレビュー・PR | EMに Slack で依頼 | エンジニアリングマネージャー |
| AWS (dev環境) | 開発環境のデプロイ・ログ参照 | Jira チケット起票 | インフラチーム |
| Datadog | 本番ログ・メトリクス参照 | 上記に含む | インフラチーム |
| Slack | チームコミュニケーション | IT ヘルプデスクに申請 | IT部門 |
| Notion | ドキュメント参照・編集 | EM に Slack で依頼 | エンジニアリングマネージャー |
開発ワークフロー
PR を出すまでの一連の流れを定義します。
| ステップ | 内容・ルール |
|---|---|
| ブランチ命名規則 | feat/jira-123-add-order-export、fix/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 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🎉 すべての環境チェックが完了しました!開発を始めましょう。")
② 依存パッケージのバージョンを自動出力
"""
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)
□ 最終更新日と保守フローの定義