正解は 「build と test が並列に実行され、両方が成功してから deploy が実行される」です。GitHub Actions の jobs はデフォルトで並列実行されます。YAML に書いた順番は実行順序を意味しません。順序を制御したいときは needs キーワードで依存関係を宣言します。この例では deploy が needs: [build, test] と書かれているので、build と test の両方が成功するのを待ってから動き出します。build と test 自体には依存関係がないため、同時に走ります。jobとstepの違いを正しく押さえる初学者が最も混乱しやすいのがここです。step: 1つのジョブ内の処理単位。同じ仮想マシン上で上から順番に直列実行される。前のステップの結果（ファイルや環境変数）を引き継げるjob: 独立した仮想マシン（ランナー）で動く処理のまとまり。デフォルトで並列実行。ジョブ間ではファイルシステムも環境変数も共有されないつまり「順番に実行したい処理」を別ジョブに分けると、それだけで並列に走ってしまいます。逆に「並列に動かしたい重い処理」を1つのジョブの中にステップとして並べても、絶対に並列にはなりません。needsを使うべきとき、使わなくていいときjobs: lint: runs-on: ubuntu-latest steps: [...] test: runs-on: ubuntu-latest steps: [...] deploy: needs: [lint, test] runs-on: ubuntu-latest steps: [...]lint と test はお互いに依存しないので並列で走らせて時短する。deploy は両方の成功が前提なので needs で待たせる。これが定番のパターンです。「全部 needs で繋げばいい」と考えると、本来並列化できる処理まで直列になってCIが遅くなります。ジョブ間でファイルを受け渡したいときジョブは別マシンで動くので、build ジョブで作った成果物を deploy ジョブで使いたい場合は actions/upload-artifact と actions/download-artifact でファイルを明示的に受け渡す必要があります。「build したのに deploy で見つからない」というハマりどころは、ジョブが別マシンで動いている事実を忘れていることが原因です。「github actions ジョブ 順番」で検索する前に、まず needs とアーティファクトの2つを思い出してください。