Git 研修 チーム開発とGit / GitHub【MIXI 25新卒技術研修】

本スライドは、MIXIの2025年度新卒向け技術研修で使用された資料です。
　
MIXI 2025新卒技術研修
『Git 研修 チーム開発とGit / GitHub』
　
▼動画
https://youtu.be/DTY3RBkXQBA
　
───────────────────────────────
※皆様へのお願い※ 資料・動画・リポジトリのご利用について
───────────────────────────────
公開している資料や動画は、是非、勉強会や社内の研修などにご自由にお使いいただければと思いますが、以下のような場でのご利用はご遠慮ください。
- 受講者から参加費や授業料など金銭を集めるような場での利用
（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用

1. ©MIXI ©MIXI MIXI 25新卒技術研修 チーム開発とGit / GitHub
2. 22 ©MIXI 講師紹介 森⼭ 堅樹 もりやま けんじゅ 2022 年度新卒⼊社 • 業務：開発本部 たんぽぽ室 映像開発グループ • ARを⽤いた映像合成、その他R &D • C++ Python TypeScript Shader UE5 • 趣味：ゲーム Steamで300くらい持ってます • 好きなGitコマンド：git reflog
3. 3 ©MIXI 本講義について 本講義の⽬的 • Gitを⽤いたチーム開発のノウハウ • GitHubを使ったチーム開発のノウハウ • 「気遣い」ができるエンジニアを⽬指す
4. ©MIXI Q. そもそもなぜ Git が⽣まれたのか
5. ©MIXI Q. そもそもなぜ Git が⽣まれたのか A. Linuxを開発するため
6. 6 ©MIXI Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 　非フリーソフトの BitKeeper を 　利用してよいのでしょうか。」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が 　あるなら代わりの VCS を教えて 　ください。」 みんな 「...」 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git は多くのプロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しくは Git 略史で 調べてね
7. 7 ©MIXI Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 　非フリーソフトの BitKeeper を 　利用してよいのでしょうか。」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が 　あるなら代わりの VCS を教えて 　ください。」 みんな 「...」 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git は多くのプロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しくは Git 略史で 調べてね
8. 8 ©MIXI Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 　非フリーソフトの BitKeeper を 　利用してよいのでしょうか。」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が 　あるなら代わりの VCS を教えて 　ください。」 みんな 「...」 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git は多くのプロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しくは Git 略史で 調べてね
9. 9 ©MIXI Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch
10. 10 ©MIXI Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch Git の merge と checkout はかなり高速 特に「履歴の遠さ」は merge や checkout の時間に影響を与えない ※ 「Git の内部構造」で詳しく話しています
11. 11 ©MIXI 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカルのみのシンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業の管理と共有がしやすい デメリット： 　単一障害点になる＆変更の競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる
12. 12 ©MIXI 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカルのみのシンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業の管理と共有がしやすい デメリット： 　単一障害点になる＆変更の競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる
13. 13 ©MIXI 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカルのみのシンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業の管理と共有がしやすい デメリット： 　単一障害点になる＆変更の競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる
14. 14 ©MIXI Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch branch 機能のおかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチの使用」「Git の内部構造」で詳しく話しています しかし、無秩序な branch 運用には問題点がある • 様々な branch でコンフリクトが発生してしまう ◦ 複雑なコンフリクトの解消に失敗してバグが混入する可能性がある • どの branch にどの機能が実装されているのかわからない ◦ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用には いくつかの方法論がある！ 1番有名なのが 『Git Flow』
15. 15 ©MIXI Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • 高速な merge と checkout • 分散型 • branch branch 機能のおかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチの使用」「Git の内部構造」で詳しく話しています しかし、無秩序な branch 運用には問題点がある • 様々な branch でコンフリクトが発生してしまう ◦ 複雑なコンフリクトの解消に失敗してバグが混入する可能性がある • どの branch にどの機能が実装されているのかわからない ◦ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用には いくつかの方法論がある！ 1番有名なのが 『Git Flow』
16. 16 ©MIXI Git Flow とは ブランチ戦略の一つ。分散型だが、集中型。 → 集中型の「管理のしやすさ」を分散型に導入 → チームでリモートリポジトリ(GitHub, BitBucket, 　 GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限) 参考：A successful Git branching model feature develop release hotfix main
17. 17 ©MIXI Git Flow とは 参考：A successful Git branching model feature develop release hotfix main 余談：複数リモートリポジトリ状態もあるよ 例1　GitHub ができる前から Git 使っている OSS は 自前の Git サーバと GitHub を両方使っていたり する(git log 残すためとか) 例2　fork したリポジトリを、fork 元のリポジトリに 追従したい時に複数リポジトリを扱う場合がある 例3 もう片方はバックアップ用 ブランチ戦略の一つ。分散型だが、集中型。 → 集中型の「管理のしやすさ」を分散型に導入 → チームでリモートリポジトリ(GitHub, BitBucket, 　 GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限)
18. 18 ©MIXI Git Flow： main と develop main と develop は無限のライフタイムを 持つメイン branch。 • develop ◦ 基本的にこの branch で開発する。 • main ◦ develop branch が安定してリリースする準備が できたら全ての変更を main ブランチに merge する ◦ 変更が main に merge されるたびに新しい リリース tag を打つ ◦ main の先頭が常にプロダクトの最新のリリース になる 参考：A successful Git branching model feature develop release hotfix main
19. 19 ©MIXI Git Flow：feature feature は複数人で develop を開発するため のサポート branch。 • 1機能＝1 feature で develop から branch を切る ◦ 複数機能＝1 feature はデメリットが多い ▪ どの機能がどの branch にあるか把握し ずらい ▪ 差分が大きくなってコンフリクトしやすい ▪ 機能単位で revert しずらい ◦ 大きい機能開発の場合は feature からさらに feature を切る • 機能の開発が終われば develop に merge する • 機能の開発がうまくいかなければ破棄する ◦ 実験・実証は feature で実施する 参考：A successful Git branching model feature develop release hotfix main
20. 20 ©MIXI Git Flow：release release は develop から main へ merge する 「準備」のためのサポート branch。 • release は develop から branch を切る • 安定した release は develop と main に merge する • チームによっては staging と呼ぶかも • 具体的な「準備」の内容はプロジェクトによる ◦ 新規実装を凍結して bugfix のみに使う ◦ version 表記やタイムスタンプを更新する • release で新規機能を追加しないようにする (新規機能追加は develop から切った feature で！) 参考：A successful Git branching model feature develop release hotfix main
21. 21 ©MIXI Git Flow：hotfix hotfix は本番環境で発生したバグの内、 緊急性の高いものを即座に対処するための サポート branch。 • hotfix は main から branch を切る ◦ develop 以外で唯一 main から切られる branch • 安定した hotfix は develop と main に merge する • hotfix から main を更新した場合は、patch バージョンをあ げることが多い ◦ 1.2 → 1.3 ではなく、1.2 → 1.2.1 参考：A successful Git branching model feature develop release hotfix main
22. 22 ©MIXI Git Flow：まとめ Git Flow は長期的な開発サイクルと厳密な ルールを持つ。全体像は右図。 大体のチームでは Git Flow をそのままではなく ちょっとアレンジして使っている。 組織やリポジトリの特性などから適したものを 選びましょう。 参考：A successful Git branching model feature develop release hotfix main
23. 23 ©MIXI Git Flow：カスタム例 Git Flow は長期的な開発サイクルと厳密な ルールを持つ。全体像は右図。 大体のチームでは Git Flow をそのままではなく ちょっとアレンジして使っている。 組織やリポジトリの特性などから適したものを 選びましょう。 参考：A successful Git branching model feature develop release hotfix main
24. ©MIXI “GitHub を⽤いたチーム開発のノウハウ” を話す前に！ GitHub の機能について
25. 25 ©MIXI GitHub の機能 GitHub は Git をチームで使うにあたって便利な機能がいっぱいある 基本的な機能はリポジトリのトップページのタブでまとめられている
26. 26 ©MIXI GitHub の機能 ② Collaborative coding で開発し、 ③ CI/CD and DevOps で開発工程を自動化＆開発と運用を円滑に回す ① Project Management でプロジェクト・タスク管理をしつつ、 ④ その他 参考：GitHub Docs
27. 27 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する
28. 28 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する
29. 29 ©MIXI 開発で大活躍する GitHub 機能 ① Project management Issueにはsub-issueを紐づけることも可能です
30. 30 ©MIXI 開発で大活躍する GitHub 機能 ① Project management sub-issueはタスクリストのような使い方や、 issueの細分化などの用途で使えます
31. 31 ©MIXI 開発で大活躍する GitHub 機能 ① Project management issueからbranchを作成したり、 branchを紐づけることも可能です
32. 32 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する Projects アジャイルやスクラム開発でよく使うタスク管理ツール • 作業の進捗状況を可視化 • 優先度やマイルストーン、ストーリーポイントを管理 様々なレイアウトがある • Team Planning • Feature release • Kanban • Bug tracker • Iterative development • Product launch • Roadmap • Team retrospective 画像引用：GitHub Issues/Projects/ビューのカスタマイズ
33. 33 ©MIXI 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前のレビューとフォローアップをする Q.　なぜ「Merge Request」ではなく「 Pull Requests」？
34. 34 ©MIXI 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前のレビューとフォローアップをする Q.　なぜ「Merge Request」ではなく「 Pull Requests」？ A. Linux 開発の名残。 特定の branch や fork 元のリポジトリに「私の作業を取り込んでください」と依頼 できる機能だから。「 Pull = 取り込み」 　Linux 開発で、Linus のもつメインのリポジトリに自分の作業内容を取り入れてほしいとき 「このブランチにあるものを取り込んでください」とお願いしていたことが由来。 　※ git request-pull というコマンドもあるくらい Linux の開発者 「私の作業を Linus 氏の メインリポジトリに 　 取り込んでください。」 Linux と Git のパパ Linus Torvalds 氏 「承知しました。レビューします。」 レビュー結果OK：「OKなので取り込みます。」 レビュー結果NG：「ここを直して欲しいです。」 Pull Request コードレビュー Developer Reviewer
35. 35 ©MIXI 開発で大活躍する GitHub 機能 ③ CI/CD and DevOps 目的：リポジトリ内でイベントが発生した時のワークフローを実行する GitHub Actions とは GitHub が提供している、ビルド、テスト、デプロイのパイプライン自動化のための 継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォーム Actions を使うメリットたくさん！ • GitHub 上にあるコードをそのまま使用し、他のサービスと連携させる必要がなく簡単に導入し使用できる • エコシステムが充実している • パブリックリポジトリは無料で使用できる • Hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると 勝手に走ってくれる ◦ GitHub で公開されている actions/starter-workflows にたくさんの yaml 例がある
36. 36 ©MIXI • Security ◦ Security policy … 脆弱性報告の手順をユーザーに示す ◦ Security advisories … 非公開で脆弱性について議論・対策し、解決後は公開できる ◦ Dependabot alerts … 脆弱性のある依存関係を使用していれば検出しアラートを飛ばす ◦ Code scanning alerts … コードをスキャンして隠された脆弱性を検出する • Insights ◦ リポジトリの活発度を様々な指標で確認できる ▪ 時系列で commit 数や差分の量がグラフ化されている ▪ メンテ具合がわかりやすい（新しいライブラリやツールの導入検討に便利） • Settings ◦ リポジトリの設定を変える ▪ デフォルト branch の変更、merge に関するルール設定、etc… ▪ (重要) Branch protection rules (直 push 禁止や force push 禁止) ▪ (注意) private → public の変更、オーナー権限の委譲、リポジトリの削除 開発で大活躍する GitHub 機能 ④ その他
37. 37 ©MIXI 他の開発手法 他にもチーム開発を効率的に行うために、シンプルな運用で理解がしやすく、 頻繁にデプロイを行う手法もある。 • GitHub Flow 軽量のブランチベースのワークフロー • トランクベース開発 細かく頻繁にリリースする開発手法 etc…
38. ©MIXI 10分休憩
39. ©MIXI GitHub を用いたチーム開発のノウハウ
40. 40 ©MIXI 大前提 チーム開発は、チームごとにお作法・文化が異なります。 GitHub を用いたチーム開発の仕方や工夫について紹介していきます。 必ずしも真似する必要はありません あくまでも一例です チームに合わせてより良い開発方法を模索していってください
41. ©MIXI Q. チーム開発で⼤切なことは？
42. ©MIXI  Q. チーム開発で⼤切なことは？  A. 『HRT』from Team Geek 謙虚(Humility) 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 尊敬(Respect) 一緒に働く人のことを心から思いやろう。相手を 1人の人間として扱い、 その能力や功績を高く評価しよう。 信頼(Trust) 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば仕事を任せることができる。 ※ 読み方は「ハート (heart)」 出典「Team Geek – Google のギークたちはいかにしてチームを作るのか」 P15 参考 Understanding Team Effectiveness, Google Research いい仕事をして成果を出すには 『チームが重要』 そのためにはチームの 『心理的安全性を高める』 ことが大切
43. ©MIXI  Q. チーム開発で⼤切なことは？  A. 『HRT』from Team Geek 謙虚(Humility) 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 尊敬(Respect) 一緒に働く人のことを心から思いやろう。相手を 1人の人間として扱い、 その能力や功績を高く評価しよう。 信頼(Trust) 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば仕事を任せることができる。 ※ 読み方は「ハート (heart)」 余談：「謙虚」と「謙遜」の違い 「謙虚」 　持続的な状態。相手の考えや気持ちを素直に受け取る。 　→ 自分にも周りにもポジティブな影響がある (人を寄せ付ける) 「謙遜」 　一時的な行為。自分の能力や価値などを下げて評価する。 　→ 周りにネガティブな影響がある (人を遠ざける) 「ありがとう」 相手の言葉を受け入れて肯定 「いえいえ、そんな..」 相手の言葉を受け入れず否定 ※シチュエーション例 「褒められた時」 出典「Team Geek – Google のギークたちはいかにしてチームを作るのか」 P15 参考 Understanding Team Effectiveness, Google Research
44. ©MIXI このHRTを実感するエピソードがあります
45. 45 45 ©MIXI 講師紹介 森⼭ 堅樹 もりやま けんじゅ 2022 年度新卒⼊社 • 業務：開発本部 たんぽぽ室 映像開発グループ • ARを⽤いた映像合成、その他R &D • C++ Python TypeScript Shader UE5 • 趣味：ゲーム Steamで300くらい持ってます • 好きなGitコマンド：git reflog ⼤学まで建築をやっていました 実務経験ほぼなし！！
46. 46 46 ©MIXI 講師紹介 森⼭ 堅樹 もりやま けんじゅ 2022 年度新卒⼊社 • 業務：開発本部 たんぽぽ室 映像開発グループ • ARを⽤いた映像合成、その他R &D • C++ Python TypeScript UE5 • 趣味：ゲーム Steamで300くらい持ってます • 好きなGitコマンド：git reflog ⼤学まで建築をやっていました 実務経験ほぼなし！！ ここからは 今までの経験から、こうした⽅がよかったな とかの失敗談を伝えます （個⼈的意⾒も含まれます）
47. 47 ©MIXI Commitを積まなかった 最初に受けた仕事をよく覚えています UEでUDPを受けとって、それを Parseしてその情報を元に xxx してほしい リファレンスはこの辺を見て
48. 48 ©MIXI Commitを積まなかった UDP C++の書き方 UE / C++
49. 49 ©MIXI Commitを積まなかった UDP C++の書き方 UE / C++ ⾃分で抱えすぎた
50. 50 ©MIXI Commitを積まなかった 本番のプロジェクト 練習のプロジェクト こっち触るの怖 いしな こっちで練習 しながら作ろう
51. 51 ©MIXI 当時作っていたのはこんな感じの流れ Commitを積まなかった リファレンスサ イト 自分の要件に 合わせて改善 動作 動くものは できた
52. 52 ©MIXI Commitを積まなかった リファレンスサ イト 自分の要件に 合わせて改善 動作 動くものは できた 全部練習用のプロジェクトのお話 当時作っていたのはこんな感じの流れ
53. 53 ©MIXI Commitを積まなかった リファレンスサ イト 自分の要件に 合わせて改善 動作 動くものは できた 全部練習用のプロジェクトのお話 ここまでの期間で CommitとPushも0 当時作っていたのはこんな感じの流れ
54. 54 ©MIXI Commitを積まなかった リファレンスサ イト 自分の要件に 合わせて改善 動作 動くものは できた 全部練習用のプロジェクトのお話 ここまでの期間で CommitとPushも0 タスク進んでいるのか なぁ 当時作っていたのはこんな感じの流れ
55. 55 ©MIXI Commitを積まなかった • Commitは後でも整理できます。 ◦ タスクの進捗が見えるために、自分がやってきたことはローカルに閉じないよ うに！！ • 本番プロジェクト触るの怖くないよ ◦ ブランチさえ切っておけば、戻せる、なんとかなる ◦ そのための Git / GitHub • わからなければペアプロも積極的に！ ◦ 人を頼ろう！！ 参考：Working Out Loud
56. 56 ©MIXI 〇〇がなぜか動かないなぁ コミュニケーション テキストのコミュニケーションは注意が必要です おや、エラーログや状況などを詳しくお願いします すみません、ただの状況報告のつもりでした
57. 57 ©MIXI コミュニケーション 相手の雰囲気が 伝わる 今のはこういう 意図かな？ 物理コミュニケーションは、伝えるコストが低い代わりに時間をとります エンジニアは特に非同期のコミュニケーションをとる機会が多いです
58. 58 ©MIXI 〇〇がなぜか動かないなぁ コミュニケーション テキストではそうもいきません 困っているの かな 助けてほし い？
59. 59 ©MIXI コミュニケーション issue、PRのコメント、全て同じことが言えます タイトルは明確？ 背景がわかりやすい？ やりたいことは明確？
60. 60 ©MIXI コミュニケーション issue、PRのコメント、全て同じことが言えます タイトルは明確？ 背景がわかりやすい？ やりたいことは明確？ これは将来の⾃分のためにも
61. 61 ©MIXI コミュニケーション • 自分の前提 ≠ 相手の前提 ◦ 自分は「つぶやき」のつもりでも、相手がどう受け取るかわかりません ◦ 自分と相手の知識は違います • どこでのやりとり？ ◦ 同じプラットフォームでも、運用が違えば書く内容や精査する必要があります ◦ [FYI]や[IMO]などを先頭につけるのもいいかもしれません • 主語を明確に！！！
62. 62 ©MIXI レビュー 私もレビューしたり、されたりすることが増えてきました このケースは〇〇よりも△△で書くのがいいですよ わかりました
63. 63 ©MIXI レビュー 私もレビューしたり、されたりすることが増えてきました このケースは〇〇よりも△△で書くのがいいですよ わかりました 1ラリーで終わる
64. 64 ©MIXI レビュー レビューお願いします！！ ここはどうしてxxxにしたんですか？ リファレンスがここで、こう書いてあったので …
65. 65 ©MIXI レビュー レビューお願いします！！ ここはどうしてxxxにしたんですか？ リファレンスがここで、こう書いてあったので … ⾃分の意図や考えをしっかりと述べましょう
66. 66 ©MIXI レビュー 他の人のレビューを見てみると、きちんとレビューしている このケースは〇〇よりも△△で書くのがいいですよ 一般的にはそうですが今回のケースでは〇〇の方が適切だと ではこの部分は残して …
67. 67 ©MIXI レビュー そもそも「打ち返すこと」がちょっと怖かった 自分より歴長 いしなぁ この人が言うなら そうなのかな
68. 68 ©MIXI レビュー • レビューすることには責任の分散、認識のすり合わせなど、様々な意味があります ◦ より良いものを作ろうとしていている、と言う前提でレビューをしてみましょう ◦ 属人化なども防ぐことができます ◦ Draft PRなども積極的に利用しましょう • 実装している人が一番、要件も詳しいです ◦ 恐れずに「議論」を！ ◦ あくまでレビュー中の主語は「仕組み」や「コード」です • 相手の負担にならないようなレビューを心がけましょう ◦ 変更差分の大きいレビュー ◦ 意図が明確でないレビュー • 積極的にレビューを出したり、受けましょう！！
69. 69 ©MIXI セルフレビューも積極的にしてみましょう。 Copilotの活用なども有用だと思います デバッグログの削除、タイポの確認など、簡単なものはセルフチェック！ レビュー
70. 70 ©MIXI まとめ どこでも通用するチーム開発の基礎を学びました。 ・Git を用いたチーム開発のノウハウ 　→ Git の誕生秘話 　→ Git の特徴 　→ Git の branch 戦略 (Git flow について) ・GitHub の機能 ・GitHub を用いたチーム開発のノウハウ 　→ チーム開発に大切なこと(HRT, 気遣い) 『気遣い』ができるエンジニアになりましょう！
71. ©MIXI