オンボーディング資料の作成

オンボーディング資料の作成

オンボーディング資料は、新メンバーが自律的に立ち上がり、爆速でデプロイまで到達するための実戦仕様です。

なぜオンボーディング資料が重要なのか

問題のあるオンボーディング

問題のある状況:

- オンボーディング資料が存在しない
- 資料が古いままになっている
- 環境構築でつまずく
- 誰に質問すればいいか分からない
- プロジェクトの全体像が把握できない

影響:

• 新メンバーの早期戦力化が難しい
• 同じ質問が繰り返される
• オンボーディングに時間がかかる
• 新メンバーのストレスが増える

オンボーディング資料に含めるべき内容

1. はじめに

含める内容:

• ようこそメッセージ
• オンボーディングの目的
• オンボーディングの流れ
• 質問・相談のルール

例:

# ようこそ！

この資料は、新メンバーのオンボーディングのための資料です。
この資料に沿って進めることで、プロジェクトの全体像を把握し、
**自律的に立ち上がり、最短でデプロイできる**ようになります。

## オンボーディングの目的
- プロジェクトの全体像を把握する
- 開発環境を構築する
- チームのルールを理解する
- 早期に戦力化する

## オンボーディングの流れ
1. 環境構築（1日目）
2. プロジェクトの理解（2-3日目）
3. 簡単なタスクに取り組む（4-5日目）
4. 本格的なタスクに取り組む（2週目以降）

## 質問・相談のルール
- **15分ルール**: 15分悩んで分からなければ、#help に投稿する
- **フォーマット**: 何を/どこで/何を試したか/ログの4点を必ず書く
- **タイムリミット**: 返信が30分ない場合は @oncall へエスカレーション

2. 環境構築

含める内容:

• 自動化スクリプトの実行
• devcontainerの起動
• 失敗時のFAQ（トラブルシューティング）

例:

# 環境構築

## 1コマンドで完了させる
手順書は書かない。**スクリプトを実行して終わらせる**。

### 推奨コマンド
make setup
# もしくは
devcontainer up

### 成功条件
- ローカルでサービスが起動する
- ヘルスチェックが通る
- テストが1件以上動く

## 失敗した時のFAQ（最初に見る場所）

### Q1. make setup が失敗する
- 失敗ログを #help に貼る（全文）
- エラーメッセージに含まれるコマンドを再実行して詳細を取得

### Q2. devcontainer が起動しない
- Docker Desktop が起動しているか確認
- `devcontainer up --log-level trace` の結果を貼る

### Q3. テストが動かない
- `npm test -- --runInBand` のログを貼る
- 依存関係の更新が必要か確認（lockfile差分）

3. プロジェクトの理解

含める内容:

• プロジェクトの概要
• アーキテクチャ
• 主要な機能
• 技術スタック
• フォルダ構成
• 選定理由（ADRへのリンク）

例:

# プロジェクトの理解

## プロジェクトの概要
[プロジェクトの概要を記載]

## アーキテクチャ
[アーキテクチャの説明を記載]

## 主要な機能
1. ユーザー認証
2. 商品管理
3. 注文管理
4. 決済処理

## 技術スタック
- フロントエンド: Next.js 14, TypeScript, Tailwind CSS
- バックエンド: Rails 7, PostgreSQL
- インフラ: AWS (ECS, RDS, S3)

## なぜこの構成か（ADR）
- ADR一覧: docs/adr/README.md
- 例: ADR-0003 フロントエンドにNext.jsを採用した理由
- 例: ADR-0012 DBはPostgreSQLを採用した理由

## フォルダ構成

project/ ├── frontend/ # フロントエンド │ ├── src/ │ │ ├── components/ │ │ ├── pages/ │ │ └── utils/ ├── backend/ # バックエンド │ ├── app/ │ │ ├── models/ │ │ ├── controllers/ │ │ └── views/ └── docs/ # ドキュメント

4. チームのルール

含める内容:

• 開発の流れ
• コードレビューのルール
• コミットメッセージのルール
• デプロイのルール
• コミュニケーションのルール

例:

# チームのルール

## 開発の流れ
1. Issueを作成
2. ブランチを作成
3. 実装
4. プルリクエストを作成
5. コードレビュー
6. マージ
7. デプロイ

## コードレビューのルール
- レビュー依頼前に自己レビューを実施
- レビューコメントには必ず返信する
- 指摘された内容は必ず修正する

## コミットメッセージのルール

feat: 新機能の追加 fix: バグ修正 docs: ドキュメントの更新

## デプロイのルール
- 通常のデプロイ: 平日の10:00-17:00
- 緊急デプロイ: 必要に応じて実施（承認が必要）

## コミュニケーションのルール
- **15分ルール**: 15分悩んだら #help に投稿
- **投稿フォーマット**: 何を/どこで/何を試したか/ログ
- **返信待ちの上限**: 30分で @oncall にエスカレーション
- **スレッド運用**: 会話は必ずスレッドで完結

5. 最初のタスク

含める内容:

• 簡単なタスクの例
• タスクの進め方
• 質問・相談先
• 文化体験（レビューの雰囲気）

例:

# 最初のタスク

## 推奨タスク
1. ドキュメントの改善
2. 小さなバグ修正
3. テストの追加
4. UIの微調整
5. **わざと小さなミスを含む修正を入れ、レビューで直してもらう**

## タスクの進め方
1. Issueを確認
2. ブランチを作成
3. 実装
4. プルリクエストを作成
5. コードレビューを受ける

## 文化体験のゴール
- **間違いが許される空気**を体感する
- レビューでの指摘が「攻撃ではなく支援」であると理解する
- 自分の変更がチームに受け入れられる体験を作る

## 質問・相談先
- 15分ルールに従って #help に投稿

オンボーディング資料の管理方法

1. 更新頻度

• 定期的な更新: 四半期ごとに見直し
• 変更時の更新: プロジェクトやルールが変更された際に即座に更新
• フィードバックの反映: 新メンバーからのフィードバックを反映

2. 更新の責任者

• オーナー: オンボーディング資料の更新を担当する人を明確にする
• レビュー: 更新内容をチームでレビューする
• 承認: 重要な変更は承認プロセスを設ける

3. アクセシビリティ

• 場所: 誰でもアクセスできる場所に配置
• 検索: 検索しやすい構造にする
• ナビゲーション: 目次やリンクでナビゲーションしやすくする

オンボーディングの実践

1. オンボーディングの準備

1. オンボーディング資料を準備
2. 環境構築の確認
3. メンターを割り当て
4. 最初のタスクを準備

2. オンボーディングの実施

1. オンボーディング資料を共有
2. 環境構築をサポート
3. プロジェクトの説明
4. 簡単なタスクに取り組む
5. フィードバックを収集

3. オンボーディングの改善

1. フィードバックを収集
2. 問題点を特定
3. 改善案を検討
4. オンボーディング資料を更新
5. 次回のオンボーディングに反映

まとめ

オンボーディング資料の作成：

• 含めるべき内容: はじめに、環境構築、プロジェクトの理解、チームのルール、最初のタスク
• 管理方法: 定期的な更新、責任者の明確化、アクセシビリティの確保
• 実践: オンボーディングの準備、実施、改善

適切なオンボーディング資料により、新メンバーの早期戦力化を実現できます。