はじめに
現場で役立つためには、華やかな新技術 の知識だけでなく、開発の土台となるツールを徹底的に使いこなす地味なスキル が不可欠です。
この記事は、特にチーム開発の効率を左右する以下の6つの頻出ツール について、わたしが実際に使用して学んだこと・気をつけたことを整理したものです。
なぜチーム開発ツールを学ぶのか
React や Next.js といった技術スタックの学習に比べて、Git や GitHub をはじめとしたツールの学習は正直地味です。でも、実際にチーム開発の現場では、コードを書く時間と同じくらい、これらのツールを使います。
例えば、素晴らしいコードを書いても、PR（プルリクエスト）の説明が不十分だとレビュアーが内容を理解するのに時間がかかります。逆に、丁寧な PR 説明があれば、レビューがスムーズに進み、チーム全体の開発速度が上がります。
Git・GitHub：個人練習
基本操作の習得
最初は「改訂2版 わかばちゃんと学ぶ Git使い方入門」で基礎を学びました。この本は漫画形式で理解しやすく、初学者に最適でした。
よく使うGitコマンド一覧
Gitは覚えることが多いですが、実際によく使うのはこのあたりです。
特にadd → commit → push の流れは、呼吸するように繰り返します。
git stash（作業を一時退避）は「少し別の作業」の時に重宝します。
git status と git diff は、「今どういう状態？」を確認するために頻繁に使います。コミット前に必ず確認する癖をつけましょう。
| コマンド | 用途 | 使用頻度 |
|---|---|---|
git init |
リポジトリを新規作成 | 低 |
git clone |
リポジトリをコピー | 中 |
git add |
コミット対象のファイルを登録 | 高 |
git commit |
変更内容をローカルリポジトリに記録 | 高 |
git push |
ローカルの変更をリモートリポジトリに反映 | 高 |
git pull |
リモートの変更をローカルにマージ | 高 |
git status |
作業ツリー内の差分ファイルを表示 | 高 |
git log |
コミット履歴を表示 | 中 |
git diff |
ファイル内の差分箇所を表示 | 中 |
git branch |
ブランチの作成／一覧表示 | 中 |
git checkout |
処理対象ブランチの切り替え | 高 |
git merge |
別ブランチから変更点をマージ | 中 |
git stash |
作業ツリーの状態を一時的に保存 | 中 |
git reset |
直前のコミットを取消 | 低 |
git revert |
特定のコミットを取消 | 低 |
git rebase |
派生元ブランチに変更点をマージ | 低 |
git tag |
コミットにタグを付ける | 低 |
git mv |
ファイルを移動／ファイル名を変更 | 低 |
git gc |
リポジトリを最適化 | 低 |
コンフリクトの解決
最初は怖かったコンフリクトも、自分で意図的に起こして練習しました。
練習方法：
- main ブランチで
README.mdの1行目を編集してコミット - 別ブランチで同じ
README.mdの1行目を別の内容で編集 - マージしてコンフリクトを発生させる
<<<<<<< HEAD
# 個人開発プロジェクト - バージョン1
=======
# マイポートフォリオサイト
>>>>>>> feature/update-readme
このような状態になったとき、どちらを残すか（または両方を統合するか)を判断して解決します。最初は戸惑いましたが、数回練習すると慣れました。
GitFlow の実践
実務に活かすため個人開発でも GitFlow を意識してブランチ運用しました。
main # 本番環境
└─ develop # 開発環境
├─ feature/user-auth # 新機能
└─ feature/dashboard-ui # 新機能
実際の作業フロー：
-
developからfeature/user-authブランチを作成 - 機能実装後、
developにマージ - 複数の機能が揃ったら、
developからmainへリリース
一人でやると「やりすぎでは？」と思いましたが、後から見返したときにコミット履歴が整理されていて、「あの機能いつ追加したっけ？」がすぐ分かりました。
GitHub：チーム開発
PR（プルリクエスト）の書き方
チーム開発では、自分以外の誰かがコードをレビューします。そのため、PR の説明は「自分が分かる」ではなく「他人が分かる」レベルで書く必要があります。
悪い例：
ログイン機能追加
良い例：
## 概要
ログイン機能を実装しました
## 変更内容
- ログインフォームコンポーネントの作成（src/components/LoginForm.tsx）
- バリデーション処理の追加（メールアドレス形式チェック、パスワード8文字以上）
- ログインAPI との連携処理
## 動作確認
- [ ] 正しい認証情報でログイン成功
- [ ] 誤った認証情報でエラーメッセージ表示
- [ ] 空欄で送信時にバリデーションエラー表示
## 補足
ログアウト機能は次のPRで実装予定です
最初は「こんなに書く必要ある？」と思いましたが、1週間後に自分の PR を見返したとき、詳細な説明があって助かりました。未来の自分も、レビュアーの一人です。
参考までに、以下はその他の具体例です。
PRの文面例（実際に書いたもの）
👇 PRタイトル
fix: タスク削除時にconfirmダイアログを表示するよう修正
👇 PR本文
- タスク削除時に誤操作が多かったため、確認ダイアログを追加
- UIはMaterial UIのDialogを使用
- 削除処理は
handleDeleteに集約- 動作確認済み（Chrome / Firefox）
「なぜ」「何を」「どうしたか」を端的に。
Slackでのレビュー依頼文面（実例）
@team
PR作成しました。お手すきの際にレビューお願いします！
[PRリンク]
変更点：タスク削除時のconfirm追加
所要時間：5分程度で読めると思います🙇♂️
Slackでは「相手の時間を奪わない」ことを意識して、所要時間や要点を添える。
コードレビューのコメント
メンバーのコードに対するレビューも、品質や教育、信頼などさまざまな観点から重要です。自分の知見を広げたくて、実際にチーム開発ができる有料サービスの利用経験もあります。
レビューで心がけたこと：
-
具体的な指摘：「ここ微妙」ではなく「この変数名は
userDataよりcurrentUserの方が、役割が明確になると思います」 - 理由を添える：「useState より useReducer が良いです」だけでなく、「状態更新のロジックが複雑になってきているので、useReducer にすると管理しやすくなります」
- ポジティブなコメント：良いコードには「このエラーハンドリング、分かりやすいですね！」と肯定的なコメントも
その他のツール経験
Slack
日常的に使うコミュニケーションツールだからこそ、相手の立場に立った「心理的安全性」と「わかりやすい伝え方」を意識しています。
実践例：
- 雑談チャンネルも活用して心理的安全性を確保。意見が言いやすくなる。
- 相手の読みやすさ重視。基本は「結論 → 理由 → 補足」の順で書く。
- 決定事項はスレッド外に要約し、共有。
- 「〇〇という認識で合っていますか？」 など、相手にYes/Noで答えられる質問を投げる工夫をし、不要な往復を減らす。
Zoom / Google Meet
Slack同様、相手の立場に立った「心理的安全性」と「わかりやすい伝え方」を意識しています。
事前準備：
- 画面共有する資料の準備：資料やコードは事前に開いておくとスムーズ。
- 議事録をメモ：会議後にSlackへ共有すると感謝されやすい（小さな工夫が信頼につながる）
- 会議中の「聞き返し方」や「表情・リアクション」への配慮
- マイク・カメラのテスト
- 背景のぼかし設定（必要に応じて）
タスク管理ツール（Jira）
自分の知見を広げたくて、実際にチーム開発ができる有料サービスの利用経験もあります。そのチーム開発の練習環境で Jira を使う機会がありました。Jira はアジャイル開発に特化したツールで、スプリント管理やバックログの優先順位付けなど、本格的なプロジェクト管理ができます。
Jira の特徴：
- チケット（課題）管理：バグ、タスク、ストーリーなど種類ごとに管理
- カンバンボード / スクラムボード：視覚的なタスク管理
- スプリント機能：2週間単位などで区切って開発を進める
- 詳細なフィルタ・検索：JQL（Jira Query Language）で高度な検索が可能
実際に使ってみた印象：
TODO → 進行中 → レビュー → 完了
このような基本的なワークフローに加えて、担当者、優先度、ラベル、期日などを細かく設定できます。最初は「設定項目多すぎ…」と感じましたが、大規模プロジェクトでは必要な機能だと理解しました。
主要タスク管理ツール：
- Trello：シンプルで直感的。個人開発や小規模チーム向け。ドラッグ&ドロップで簡単にカードを移動できる。設定が少ない分、すぐに使い始められる
- Backlog：日本企業が開発したツール。ガントチャート機能があり、ウォーターフォール開発にも対応。Git リポジトリ機能も内蔵
- Jira：エンタープライズ向け。アジャイル開発に最適化されており、大規模チームでの複雑なプロジェクト管理に強い。カスタマイズ性が高い反面、学習コストもやや高め
個人的には、「まずは Trello で基本を学び、チーム開発の規模が大きくなったら Jira に移行」という流れが自然だと感じました。
ドキュメント管理（Google ドライブ）
チームでの小規模プロジェクトで Google ドライブを使いました。
意識したこと：
- フォルダ構成を階層化しすぎない（3階層まで）
- ファイル名に日付をつける（例：
要件定義_20250115.md） - 共有設定の確認（閲覧のみ / 編集可能）
「あのドキュメントどこだっけ？」を減らすために、README 的なドキュメントを作って、主要ファイルへのリンクをまとめました。
まとめ
エンジニアの成長は、派手な技術スキルだけではなく「チームで動けるか」によっても左右されます。
Git、GitHubをはじめとするツールは、一見地味でも開発効率を大きく左右する部分。
個人開発で基本を身につけ、チーム開発で実践する。その過程を記録すること自体が、自分の強みになると感じました。
この記事が、チーム開発をより良くしていきたい人の参考になれば嬉しいです。