この記事について
SES案件に新しく参画する際、この記事は初日にスマホやPCで開いてカンペとして使うことを想定してまとめたもの。
想定読者は、Next.js + React / Node.js / AWS あたりの構成でWeb開発案件に参画するエンジニア。
ただし他の技術スタックでもほとんどの項目はそのまま使える。
あいさつテンプレ
初日の自己紹介はシンプルでいい。長々と話す必要はない。
本日からお世話になります、〇〇と申します。
前職（前案件）では△△のプロジェクトでReact / Node.js を使ったWeb開発を担当しておりました。
早くキャッチアップできるよう努めますので、よろしくお願いいたします。
ポイントは自分の得意領域をさらっと伝えること。相手がタスクを振りやすくなる。
リモート参画で初日からオンラインの場合も、Slackやチャットツールでの自己紹介文は同じ構成でよい。
環境構築でやること・確認すること
アカウント関連
- メールアドレス（社内ドメイン）の発行
- Slack / Teams / Chatwork など、チャットツールへの招待
- GitHub（または GitLab / Backlog）のOrganization・リポジトリへの招待
- Jira / Redmine / Notion / Linear などタスク管理ツールへのアクセス
- Figma / XD などデザインツールへの閲覧権限
- VPN接続の設定（リモート勤務がある場合はほぼ必須）
- AWS IAMアカウントの発行（開発環境・ステージング環境へのアクセスに必要）
→ アカウント発行は申請から時間がかかることが多い。午前中のうちにまとめて依頼して、待ち時間にドキュメントを読むのが効率的。
開発環境
典型的なNext.js + Node.js + AWS構成の案件を例にすると、以下を確認・セットアップすることになる。
- PC（支給 or BYOD）のスペックとOS。macOSかWindowsか、Windowsの場合はWSL2を使うかどうか
- WSL2を使う場合、ディストリビューション（Ubuntu等）のバージョン指定があるか
- Node.js のバージョン（
.node-versionや.nvmrcがリポジトリにあるか。nvm / volta / asdf のどれを使っているか） - パッケージマネージャの指定（npm / yarn / pnpm）。lockfileの種類を見ればわかる
- Docker / docker-compose の利用有無とバージョン
- DBのローカル環境（MySQL / PostgreSQL をDockerで立てるのか、ローカルインストールか）
- 環境変数の管理方法（
.env.localのテンプレートはあるか。APIキーなど秘匿情報の受け渡し方法） - エディタ／IDEの指定やチーム推奨の拡張機能（VSCode + ESLint + Prettier が多い）
→ README.md にセットアップ手順が書いてある場合と、Confluenceや Notion など別の場所にある場合がある。
「ローカル環境の構築手順について、何か参考になるものはありますでしょうか？orどこにありますか？」と最初に聞くのが一番早い。
外部API連携がある場合
Microsoft Graph API や Google API など外部サービスと連携している案件では、以下も確認が必要。
- 開発用のAPIクレデンシャル（クライアントID・シークレット）の取得方法
- サンドボックス環境やテスト用アカウントの有無
- OAuthの認証フローの仕組み（どこにリダイレクトされるか、スコープの設定など）
- APIのレートリミットやクォータの制約
→ これらは自分で勝手に発行できないことが多い。誰に依頼すればいいかを初日に確認しておく。
セットアップでハマったら
初日に環境構築が完了しないのはよくあることで、焦る必要はない。ただし以下は意識する。
- エラーが出たらスクリーンショットかログをそのまま貼って質問する（「動きません」だけで聞かない）
- 30分調べて解決しなければ質問する。初日に一人で半日潰すのはもったいない
- 手順書に不備があった場合は、修正内容をメモしておく。後日プルリクやドキュメント修正で貢献できる
ドキュメントで確認しておくこと
初日にすべてを読み込む必要はないが、存在と場所を把握しておくことが重要。
- システム構成図 — フロントエンド・バックエンド・DB・AWS各サービス・外部APIの全体像
- API仕様書 — Swagger / OpenAPI / Postmanコレクションなどの場所。バックエンドのエンドポイント一覧
- DB定義書（ER図） — テーブル構造とリレーションの把握。マイグレーションツール（Prisma / TypeORM / Knex など）を使っているかどうか
- ブランチ戦略 — Git Flow / GitHub Flow / trunk-based のどれか
- デプロイフロー — CI/CDの仕組み（GitHub Actions等）、ステージング環境と本番環境の関係。AWSのどのサービスにデプロイされるか
- コーディング規約 — ESLint / Prettier の設定、命名規則、コンポーネントのディレクトリ構造ルール
- デザインカンプ — Figma の共有URL。MUIのテーマカスタマイズの方針
→ これらの場所を一覧でメモしておくと、翌日以降の立ち上がりが格段に速くなる。
開発フロー・運用ルールの確認
口頭で聞かないとドキュメント化されていないことが多い領域。初日〜数日以内に把握する。
- プルリクエストのレビュー体制（誰にアサインするか、何人のApproveが必要か）
- コミットメッセージの規約（Conventional Commitsなど）
- 日報・週報の提出有無とフォーマット
- 定例ミーティングの曜日・時間・ツール（デイリースタンドアップがあるか）
- 勤怠の報告方法（SES元への報告とクライアント先への報告が二重に必要な場合がある）
リモート勤務の場合に追加で確認すること
在宅中心の案件では、以下も初日に把握しておく。
- 画面共有・ペアプロのやり方（Zoom / Meet / Discord のどれか）
- 質問するときのチャンネルや作法（DMで聞くのか、パブリックチャンネルか、スレッドを立てるか）
初日の終わりにやること
- 今日もらったアカウント情報を整理する（パスワードマネージャに保存）
- ドキュメントの場所をメモにまとめる
- 明日以降のタスクや予定を確認する
最初の一週間で意識すること
- 最初から成果を出そうと気負わない。まずは「聞ける人」と「情報の場所」を把握するのが最優先
- コードを読む時間を意識的に確保する。既存のコードベースの設計思想（ディレクトリ構成、状態管理、API設計）を理解してから書き始めるほうが手戻りが少ない
- 小さいタスク（typo修正、ドキュメント更新、Lint警告の修正など）でも早めにプルリクエストを出す。レビュープロセスに慣れる意味でも有効
- チームのSlack/Teamsのチャンネル一覧を眺めて、どんな情報がどこで流れているかを把握する
- 1人SE（自分だけがSESで参画する）の場合は特に、孤立しないよう意識的にコミュニケーションを取る