main を直接触らない(ブランチ戦略)
なぜ大事か
全員が共有する main を直接編集すると、未完成のコードや不具合がすぐ本番や他の人に影響してしまう。
具体的にやること
作業ごとに feature/○○ のブランチを切り、そこで開発してから main へ取り込む。main は常に安全な状態に保つ。
チーム開発で大事なこと 一覧表
複数人で開発するときの実践チェックリスト
一人での開発と違い、チーム開発では「他の人と足並みをそろえる」工夫が欠かせません。 そこで大事になるポイントを「項目」「なぜ大事か」「具体的にやること」の3列で 21 項目、一覧表にまとめました。 Laravel の学習で覚えたことを、実際のチーム開発でどう活かすかの実践チェックリストとして使ってください。
📝 この表の見方
- なぜ大事か… そのルールがない場合に起きがちなトラブル。理由から理解すると身につきます。
- 具体的にやること… 今日から実践できる行動のヒント。チームの状況に合わせて調整してください。
バージョン管理・Git6 項目
ブランチ戦略・コミット・コンフリクトなど、コードを共有する土台
コミットの粒度を小さく保つ
なぜ大事か
1コミットに大量の変更が混ざると、レビューしづらく、問題が起きたとき原因の特定や巻き戻しが難しくなる。
具体的にやること
「1つの意味のある変更」で1コミット。機能追加とリファクタは分ける。少し進めたらこまめにコミットする。
わかりやすいコミットメッセージ
なぜ大事か
後から履歴を見る人(未来の自分も含む)が、何を・なぜ変えたのかを理解できないと、調査に時間がかかる。
具体的にやること
「何をしたか」を一行目に簡潔に(例: ログイン失敗時のエラー表示を修正)。必要なら本文で理由も添える。
こまめに pull / push する
なぜ大事か
手元だけで長く抱え込むと、他の人の変更とズレが大きくなり、コンフリクトや作業の二重化が起きやすい。
具体的にやること
作業開始前に pull で最新を取り込み、区切りごとに push。ブランチを長生きさせすぎない。
コンフリクトを落ち着いて解決する
なぜ大事か
同じ箇所を複数人が変更すると必ず起きるもの。慌てて片方を消すと、相手の変更を失う事故につながる。
具体的にやること
両方の意図を確認し、正しい形に手で統合する。不安なら相手に確認。解決後は必ず動作を確認してからコミット。
.gitignore で上げないものを決める
なぜ大事か
秘密情報(.env)や生成物(node_modules・ビルド成果物)を上げると、漏洩やリポジトリ肥大の原因になる。
具体的にやること
秘密情報・依存フォルダ・生成物・OS/エディタの一時ファイルを .gitignore に登録。最初に整えてから開発を始める。
レビュー・品質5 項目
PR・コードレビュー・規約・テストなど、みんなで品質を守る仕組み
プルリクエスト(PR)を出す
なぜ大事か
いきなり main に入れず、変更内容を見える形で共有することで、事故を未然に防ぎ、知識も共有できる。
具体的にやること
何を・なぜ変えたかを説明文に書く。関連 issue を紐づけ、レビュー担当を指定。差分は小さめにして見やすくする。
コードレビューは人格でなくコードを見る
なぜ大事か
指摘が人格攻撃に感じられるとチームの心理的安全性が下がり、率直な意見交換ができなくなる。
具体的にやること
「あなたが悪い」ではなく「このコードはこうすると良くなる」と伝える。良い点も挙げ、敬意と感謝を忘れない。
コーディング規約で書き方を統一する
なぜ大事か
人によって書き方がバラバラだと読みにくく、レビューでも本質と無関係な指摘(スタイル論争)が増える。
具体的にやること
チームで規約を決めて共有。命名・フォルダ構成・書式のルールをドキュメント化し、迷ったら規約に従う。
Lint / Formatter で自動整形する
なぜ大事か
スタイルを人手で直すのは非効率でミスも起きる。ツールに任せれば議論せずに一貫性を保てる。
具体的にやること
ESLint・Prettier・Pint 等を導入し、保存時やコミット時に自動実行。設定はリポジトリで共有する。
テストを書く / 壊さない
なぜ大事か
テストがないと、変更が既存機能を壊していないか手作業で確認するしかなく、安心して直せない。
具体的にやること
重要な処理には自動テストを用意。変更後は必ずテストを実行し、赤(失敗)のまま main へ入れない。
CI/CD・自動化3 項目
自動テスト・自動デプロイで、main を常に動く状態に保つ
自動テスト(CI)を回す
なぜ大事か
手元でテストを忘れても、CI が自動でチェックすれば「壊れたコードが取り込まれる」事故を防げる。
具体的にやること
GitHub Actions 等で push / PR ごとにテストと Lint を自動実行。失敗した PR はマージしないルールにする。
自動デプロイ(CD)で人手を減らす
なぜ大事か
手作業デプロイは手順ミスや「本番だけ動かない」を招きやすく、担当者に依存してしまう。
具体的にやること
main へのマージをきっかけに自動でデプロイ。手順をコード化し、誰がやっても同じ結果になるようにする。
main を常に動く状態に保つ
なぜ大事か
main が壊れていると、そこから枝分かれする全員の作業が止まり、リリースもできなくなる。
具体的にやること
テストが通ったものだけを main へ。壊れたらまず main の修復を最優先(直すか、その変更を戻す)。
タスク・コミュニケーション4 項目
issue・報連相・ドキュメントなど、認識を合わせる工夫
issue / タスク管理で「誰が何を」を見える化
なぜ大事か
誰が何をやっているか不明だと、作業がかぶったり、逆に誰も手を付けない抜け漏れが発生する。
具体的にやること
作業を issue やカンバンに登録し、担当者・状態(未着手/進行中/完了)を明示。着手時に自分を担当に割り当てる。
報連相・こまめな共有
なぜ大事か
問題を一人で抱え込むと、手戻りが大きくなってから発覚する。早い共有ほど傷が浅くて済む。
具体的にやること
詰まったら早めに相談。進捗や決定事項はチャットで共有し、後から見返せるよう文字で残す。
ドキュメント / README を残す
なぜ大事か
セットアップ手順や仕様が頭の中だけにあると、新メンバーが入るたびに口頭説明が必要になり属人化する。
具体的にやること
起動方法・環境構築・主要な決定事項を README に記載。変更したら都度更新し、古い情報を放置しない。
認識合わせ(仕様の確認)をする
なぜ大事か
「わかったつもり」で進めると、完成してから「思っていたものと違う」となり、大きな作り直しになる。
具体的にやること
着手前にゴールと仕様を言葉にして確認。曖昧な点は質問し、必要なら簡単な図やメモで認識をそろえる。
環境・セキュリティ3 項目
環境の統一・秘密情報・依存管理など、安全に開発する準備
開発環境を統一する(.env.example・Docker 等)
なぜ大事か
「自分の環境では動く」問題は、環境の違いが原因で起こりがち。バラバラだと再現もサポートも難しい。
具体的にやること
.env.example に必要な設定を列挙し、Docker 等で環境をコード化。誰でも同じ手順で同じ環境を再現できるようにする。
秘密情報をリポジトリに上げない
なぜ大事か
API キーやパスワードを push すると、履歴に残り続け、公開リポジトリなら不正利用や情報漏洩に直結する。
具体的にやること
秘密情報は .env に置き .gitignore で除外。共有はパスワード管理ツール等で。誤って上げたら即座に鍵を無効化する。
依存(ライブラリ)を管理する
なぜ大事か
各自が勝手にバージョンを変えると環境差が生まれ、古い依存を放置すると脆弱性の温床になる。
具体的にやること
composer.lock / package-lock.json をコミットしてバージョンを固定。更新は計画的に行い、脆弱性情報にも目を配る。