プロのエンジニアのワークフロー
世界中のテック企業がコードを出す手順
⏱ 想定 ~13 分
01 · 読む
個別のスキルは全部学びました：ターミナル、ファイル、 git 、 web サーバー、 API 、 Claude Code 、デバッグ、デプロイ。これらを どのプロの開発チームも従うワークフロー にまとめましょう。
ツールはチームによって違います —— GitHub の代わりに GitLab を使うチーム、 Render の代わりに AWS にデプロイするチーム、別の言語を使うチームもあります。でも ワークフロー はいつも同じです。これを学べば、どのテック企業に入っても、彼らがどうやってソフトウェアを出荷しているか分かります。
💡 想像してみてください個別のスキルは、ドリブル、パス、シュートを学ぶようなものです。プロのワークフローは実際の試合 —— 学んだことを組み合わせて結果につなげる、調整された一連の動きです。ワークフローを理解することは、コードを書ける状態と出荷できる状態の差を埋めることです。
02 · ステップ解説
完全な開発サイクル。どの機能、バグ修正、改善もこのループに沿って進みます。
1. ISSUE
誰かがバグを報告するか、機能を要望します。 GitHub Issues 、 Jira ボード、あるいはシンプルな To Do リストで追跡します。すべての仕事は、はっきり書かれた問題やゴールから始まります。
2. BRANCH
ブランチを作る： git checkout -b fix-login-bug 。 main に直接作業しないこと。ブランチが変更を隔離してくれるので、壊さずに試せます。
3. CODE
Claude Code を使って修正や機能を実装します。やりたいことをはっきり伝え、出力をレビューし、正しくなるまで反復します。実際に作るところです。
4. TEST
ローカルで動作確認。エッジケースを確認。他のものを壊していませんか？変な入力、空欄、想定外のシナリオを試します。自動テストがあれば走らせます。
5. REVIEW
git diff を実行。自分の変更を 1 行ずつ自分で見直します。他人のコードだったら承認しますか？残った console.log 、ハードコードされた値、入っていてはいけないものを探します。
6. COMMIT
stage してから、説明的なメッセージで commit します。論理的な変更ごとに 1 つの commit を。 'Fix login validation to reject empty passwords' は物語を語ります。 'Fixed stuff' は語りません。
7. PUSH
ブランチを GitHub にプッシュ： git push -u origin fix-login-bug 。変更を他の人が見て、レビューできるようになります。
8. PULL REQUEST
GitHub で PR を作成します。何を変えたか、なぜ変えたかを書きましょう。チームメイト（や未来のあなた）が、リリース前にコードをレビューする場です。文脈も入れます：バグは何？どう直した？他人はどうテストできる？
9. MERGE
レビューと承認が済んだら、 main にマージ。フィーチャーブランチは役目を終え、削除できます。あなたの変更が公式のコードベースの一部になります。
10. DEPLOY
自動デプロイを設定していれば（ Render のように）、 main へのマージで自動的にライブ反映されます。していなければ手動デプロイをトリガー。どちらにしてもループは完了 —— アイデアからライブ機能までたどり着きました。
03 · 読む
このワークフローの肝心な git の手順を、手を動かして通してみましょう。まだ git で追跡されていないプロジェクトがあります —— 初期化して、フィーチャーブランチを作り、変更を加えて、 stage します。
04 · ターミナル演習
どのプロジェクトも git init から始まります。普通のフォルダを git リポジトリに変え、変更を追跡できるようにします。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
05 · ターミナル演習
ステップ 1: BRANCH —— 新しいフィーチャーブランチを作ります。 main に直接作業しないこと。ブランチが安全に試せる場所になります。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
06 · ターミナル演習
ステップ 2: CODE —— プロジェクトに変更を入れます。 HTML ファイルにログインフォームを追加しましょう。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
07 · ターミナル演習
ステップ 3: COMMIT —— ファイルを stage し、説明的なメッセージで commit します。良い commit メッセージは 何を なぜ 変えたかを説明します。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
08 · 読む
🎯 中間チェック —— BRANCH → CODE → COMMIT 完了
プロのエンジニアの日常の最初の 3 ステップを通り終えました： ブランチを切る → コードを書く → 説明的なメッセージで commit する 。この 3 ステップはプロジェクトの規模に関わらず、どのチームもやっていることです。
後半は PR （ pull request ） → コードレビュー → マージ —— 自分のブランチをチームの本流に取り込んでもらう手順です。
なぜ直接 main にマージしないのか？ レビューなしのマージはバグの素通しになるからです。 PR はチームメイトに変更を見せ、フィードバックをもらい、問題ないと確認してから取り込むための場です。この一段の手順こそ、プロのエンジニアリングの中核です。
ポイントまとめ
- 3 ステップ： branch / code / commit （完了）
- 残り 3 ステップ： push / pull request / code review + merge
- Commit message は 何を なぜ 変えたかを書く —— 未来の自分が今日の自分に感謝します
09 · クイズ
プロのワークフローでは、コードを書き始める前に何を作りますか？
- 新しいリポジトリ
- データベース
- 新しいブランチ
- 仕事を説明する GitHub の issue
10 · 空欄補充
機能が完成したら、 pull _____ を作って変更のマージを提案します。
11 · 読む
おめでとうございます。あなたは Google 、 Stripe 、 Shopify をはじめ世界中のテック企業が使っているのと同じワークフローに沿って進みました。規模は違っても、流れは同じです： issue 、 branch 、 code 、 test 、 review 、 commit 、 push 、 PR 、 merge 、 deploy 。
大企業は 1 日に何百回もこのループを回します。あなたもこれからそれをやります。
12 · クイズ
フィーチャーブランチでバグ修正を書き終えました。 commit する前にすべきことは？
- git diff を実行して変更を 1 行ずつ自分で見直す
- main に直接 push
- pull request を作る
- ブランチを消してやり直す
13 · 空欄補充
プロのワークフローでは、すべての仕事ははっきり説明された _____ から始まります —— バグ報告か機能要望。
⚠ 全機能のインタラクティブ体験には JavaScript が必要です。JavaScript を有効にして再読み込みしてください。
※ このサイトは独立した教育プロジェクトで、Anthropic の公式製品ではありません。Claude™ は Anthropic, PBC の商標です。