共有の土台の上に乗る「協働の作法」
前回のO-07で、手元の履歴をリモートへ送り、GitHubで共有できるようになりました。ところが、変更が共有されるようになると、今度は別の問題が出てきます。「この変更はなぜ入ったのか」「誰が確認したのか」が残っていないと、後から誰も説明できないのです。この講義は、その記録を残すための協働の作法です。土台には、O-05のブランチとO-06のマージをそのまま使います。
このスライドのポイント
- O-07: リモートとGitHubで、履歴を共有できるようになった
- 共有できると次に問題になるのは「変更の理由と確認をどう残すか」
- この講義は、共有の土台の上に乗る協働の作法を扱う
- 道具は、O-05のブランチとO-06のマージがそのまま土台になる
3点セットの技術的な定義
3つを技術用語で定義します。Issueとは、課題や要望、バグを記録する票です。M-02で学んだ課題管理を、コードの置き場の上で実装したものにあたります。Pull Request、略してPRとは、このブランチの変更を本線へ入れたい、という提案と、その差分を見える形にしたものです。差分はO-04で学んだdiffそのものです。レビューとは、そのPRの差分を確認し、指摘したり承認したりすることです。この3点がそろうと、なぜ・何を・誰が確認したか、が全部履歴に残ります。
このスライドのポイント
- Issue＝課題・要望・バグの記録票（M-02の課題管理の、コード上の実装先）
- Pull Request（PR）＝このブランチの変更を本線へ入れたい、という提案と、その差分（O-04）の見える化
- レビュー＝PRの差分を確認し、指摘・承認すること
- 3点で「なぜ・何を・誰が確認したか」がすべて履歴に残る
なぜ必要か——記録が残らない開発の困りごと
この3点セットが無いとどうなるか。変更の理由も、誰がどう確認したかも残りません。数か月後に「この処理はなぜこうなっているのか」と問われても、誰も答えられなくなります。これはN-03で学んだ、履歴を残す思想のコード版です。とくにAIと組む開発では、AIが書いた変更をそのまま取り込みがちですが、PRという単位でレビューを挟むことが、A-04で学んだ人間の確認点を仕組みとして定着させることになります。
このスライドのポイント
- 3点セットが無いと: 変更の理由と確認の記録が残らない
- 後から「なぜこうなってる？」に、誰も答えられなくなる（N-03の履歴の思想の、コード版）
- AIとの開発でも、PR単位のレビューが「人間の確認点（A-04）」の制度化になる
- 記録は面倒ではなく、未来の自分を助ける保険
3点セットの流れ（構造）
全体の流れを見ます。まずIssueで課題を立て、O-05のブランチを切って、そこで変更します。変更ができたらPRを出し、その差分をレビューで確認し、問題なければO-06のマージで本線へ合流させます。ここで大切なのは、1人で開発する場合でもこの流れが役立つことです。自分で出したPRを自分で確認する形で構いません。それでも、マージの前に差分を一度自分の目で通す。この一手間が、変更の質を守ってくれます。
このスライドのポイント
- 流れ: Issue（課題）→ ブランチ（O-05）→ 変更 → PR（差分の提案）→ レビュー → マージ（O-06）
- Issueで「やること」を決め、ブランチで安全に変更し、PRで差分を見せ、レビューで確認してからマージ
- 1人開発では「自分で出して、自分で確認」でよい
- それでも、差分を一度自分の目で見る習慣が、質を守る
Webアプリでの具体例
具体例で追います。経費アプリに、承認漏れを知らせる通知を足したいとします。まず「承認漏れの通知が欲しい」という課題をIssueに書きます。次にブランチを切り、AIと一緒に実装します。実装できたらPRを出し、その差分を自分でレビューします。ここで見るのは、O-04で学んだとおり、頼んでいないファイルまで変わっていないか、です。問題なければマージします。こうして残った記録から、未来の自分は「なぜこの通知を足したのか」を後からきちんと辿れます。
このスライドのポイント
- 題材: 経費アプリに「承認漏れの通知」を追加する
- 手順: 課題をIssueに書く → ブランチでAIと実装 → PRの差分を自分でレビュー → マージ
- レビューでは「依頼していない変更が混ざっていないか」を確認（O-04の実践）
- 結果: 未来の自分が「なぜこの通知を足したか」を辿れる
技術サンプルカード——3点セット対応表
この表は、3点セットがそれぞれ違う問いに答えることを示しています。Issueは「なぜ」、PRは「何を」、レビューは「誰が確認したか」です。読み方のポイントは2つあります。1つは、3点が重複せず役割を分けていること。もう1つは、1人で開発していても、変更内容を差分で見せるPRには大きな価値があることです。自分の変更でも、一度差分の形で見直すと見落としに気づけます。AIには、PR説明文を目的・変更点・確認したこと・影響範囲の4項目で書かせると、記録が整います。
このスライドのポイント
- 種別: table
- 目的: 3点セットが「どの問いの答え」を残すのかを、既出講義と対応づけて確認する
- サンプル本体:
混同しやすい概念——マージとPR
よく混同されるのが、マージとPRです。マージはO-06で学んだとおり、ブランチの変更を統合する操作そのものです。一方PRは、その統合をいきなり行わず、前に一段はさむ提案と確認の場です。言い換えると、PRはマージという操作の前に置く安全装置です。PRを出すことと、マージすることは別の行為です。PRを出し、レビューで確認し、そのうえでマージする。この順番を守ることで、確認しないままの統合を防げます。
このスライドのポイント
- マージ（O-06）＝ブランチの変更を統合する「操作」そのもの
- Pull Request＝統合の前に挟む「提案と確認の場」
- PRは、マージという操作の前に置く安全装置
- 「PRを出す」と「マージする」は別の行為（PR→レビュー→その後マージ）
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに機能を作らせたら、そのままマージせず、PR説明文の4項目を書かせてください。4項目とは、目的・変更点・確認したこと・影響範囲です。ここで大事な考え方があります。この4項目を書けない変更は、まだ理解されていない変更だ、ということです。これはJ-07で学んだ、逆算して確かめる思想と同じです。書けない項目があれば、取り込む前にAIへ問い直しましょう。質問例はこうです。「この変更のPR説明文を、目的・変更点・確認したこと・影響範囲の4項目で書いてください」。
このスライドのポイント
- AIに機能を作らせたら「PR説明文の4項目」を書かせる: 目的・変更点・確認したこと・影響範囲
- 4項目を書けない変更は、まだ理解されていない変更（J-07の逆算と同じ思想）
- 書けない項目があれば、AIに問い直してから取り込む
- 質問例:「この変更のPR説明文を、目的・変更点・確認したこと・影響範囲の4項目で書いてください」
一問一答とまとめ
一問一答です。変更の「なぜ」を記録するのは、3点セットのどれでしょうか。……答えは、Issueです。PRは「何を」、レビューは「誰が確認したか」を残します。30秒でまとめます。Issue・PR・レビューの3点で、なぜ・何を・誰が確認したかが履歴に残ります。1人開発でも、PRで差分を一度見る習慣が変更の質を守ります。次回O-09では、依存関係の更新と、その安全な進め方へ進みます。関連資料は「Git・GitHub 完全入門」「バグ報告テンプレート」「AIアプリ改善提案テンプレート」です。
このスライドのポイント
- 一問一答: 変更の「なぜ」を記録するのは、3点セットのどれか？
- 30秒まとめ: Issueで「なぜ」、PRで「何を」、レビューで「誰が確認したか」を履歴に残す。1人開発でもPRの差分確認は質を守る
- 次回: 依存関係の更新と、その安全（O-09）へ
- 関連資料: 「Git・GitHub 完全入門」「バグ報告テンプレート」「AIアプリ改善提案テンプレート」
