「会話」って疲れますよね。
上司：「これ、前にも言ったよね？」
私：「あ、はい……」
心の中の私：
いや絶対聞いてない。初耳なんだが。
でも、
「いや、聞いてません」
と言うと、
「いや言ったよ」
不毛な「言った・言ってない」戦争が開戦されます。
他にも、
上司：「この資料、もう少し分かりやすくして」
私：「分かりました」
翌日。
上司：「いや、そうじゃなくてさ…もっとこう……」
いや何が正解だったんだよ。
こういうの、全部疲れます。苦しいです。
そこで、ふと思いました。
最初から会話そのものをGitとして管理すれば楽なのでは？
まず結論
会話をGitとして考えると、だいたいこうなります。
要するに、
聞く
↓
確認する
↓
考える
↓
チェックする
↓
話す
↓
伝わったか確認する
です。
Gitと会話の対応
まずはざっくり対応表。
| Git | 会話 |
|---|---|
| Repository | その案件の会話全体 |
| Working Tree | 頭の中 |
| Staging Area | これから言おうとしている内容 |
| Commit | 発言 |
| HEAD | 現在の共通認識 |
| Branch | 話題・論点 |
| Diff | 認識差 |
| Merge | 認識の統合 |
| Conflict | 意見・前提の衝突 |
| Fetch | 相手から情報を聞く |
| Push | 自分の考えを伝える |
| Log | 議事録・チャット履歴 |
| Tag | 決定事項 |
| Stash | 一旦保留 |
| Revert | 訂正 |
| Pull Request | 提案 |
| CI | 発言前チェック |
意外と対応させることができそうな気がしてきましたね🤔
ではこれを踏まえて、Repositoryを考えてみましょう
自分と相手は別Repository
まず大前提です。
ここで重要なのが、
Pushしたからといって、同じ内容が相手側に保存されたとは限らない
ということです。
例えば。
私：「この機能、技術的にはできます」
上司：「じゃあ来週までによろしく」
私：「え？」
上司：「できるって言ったよね？」
私：「いや、技術的に可能って意味で……」
Git的に考えると、
自分のRepository
+ 技術的に実現可能
相手のRepository
+ 来週までに実装可能
という感じで、Pushには成功しています。
でも、Merge結果が壊れています。
だからまず git diff
そもそも会社や企業など問わず、すべての会話での大前提って認識のずれをなくすことだと思います。
例えば...
上司：「この資料、もう少し分かりやすくして」（最初に結論を出してほしいなあ...）
私：「はい」（図を減らせばいいのかな？）
よくありそうですよね？
これは互いに 「分かりやすい」 の定義が違うためです。
ここで、
git diff
します。
要は、
「分かりやすくというのは、図を減らす感じですか？
「それとも、結論を先に出す感じですか？」
と同じことがgit diffです。
「それってつまり○○ですか？」は git status
上司：「Aは今月やって、Bは一旦後回しで。Cは田中さんと相談かな」
数分後。
誰か：「で、結局どうなったんでしたっけ？」
こういうのもありますよね。
ちゃんと話聞いておけよと思いつつ、議論が発散したりして前の結論が追えないことはよくあります。
なので定期的に、
git status
します。
ここでやりたいことを言語化すると、
私：「一旦整理すると、Aは今月、Bは保留、Cは田中さん確認待ちで合っていますか？」
...ということです。
On branch: project-a
Done:
✓ Aを今月対応
Pending:
? Bは保留
Waiting:
? Cは田中さん確認
Nothing else committed.
めちゃくちゃGitです。
分からないならCommitしない
ちょっとピりついているミーティングなどだと、
（何か答えないと）
という謎の圧があります。
上司：「今回のトラブルって、原因何？」
私：「…………えーっと、（多分）DBですかね……😣」
で、結局違ってて、あとでまた詰められる。
圧制政治そのものですね。良くないです。
これがGitなら、
分からないファイルを勝手にCommitしません。
そのため、
私：「まだ原因は分かってません。DBも候補ですが、そこは未確認です」
でいい。（現実でこう言えたらどれだけ喜ばしいか...🥺）
STATUS: UNKNOWN
Possible causes:
- DB
- API
- Batch
Need:
- Log確認
つまり、
分からない
=
Failure
ではなく、
分からない
=
Waiting for dependency
です。
会話が脱線したらBranchを切る
上司：「今回の機能についてなんだけど」
誰か：「そういえば予算ってどうなってます？」
別の人：「去年の障害も関係ありますよね」
誰か：「採用増やした方がよくない？」
私：（これ何の会議だっけ？）
みんないろんな懸念があるのがわかりますし、本題に関係していますが、
徐々に本質からずれていくことはよくありますよね
これをGitで見ると、
となります。
このbranchは
「その話も重要なので一旦別論点で置いておいて、先にこの機能の話を決めませんか？」
と言語化できます。
今話さなくていいなら stash
上司：「そういえば別件なんだけど」
私：「（うるさい別件出すなよ）あ、それ重要ですね。ただ今これを決めたいので、後で戻ってもいいですか？」
これは、
git stash
です。
STASH
- 来期予算
- API仕様
- 山田さん確認
余計な話で脳のメモリを食わないようにするため、git stashをしっかり使いましょう
意見はPull Requestにする
これも結構大事です。
私：「業務効率化のためにPythonで自動化しましょう（提案）」
と言うと、
上司：（おっ...業務効率化やってくれるんだ...じゃあ業務決定で。）
と 決定事項 っぽく聞こえます。
でも本当は、
「提案」
ですよね。
なので決定事項とする前に提案を明文化するために、PRにします。
私：「一案なんですけど、ここPythonで自動化するのはどうでしょう？」
上司：「メリットは？」
私：「月20時間くらい削減できそうです」
上司：「保守は？」
私：「そこは課題ですね」
Git的には、
PR #27
Title:
Excel作業をPython化
メリット:
月20時間削減
懸念:
保守担当が限定される
Rollback:
Excel運用へ戻せる
です。
完成度が低いなら、
Draft PR。
私：「まだ雑なんですけど、方向性だけ見てもらえます？」
これでOKです。
意見が合わないならMerge Conflict
私：「品質を優先したいです」
上司：「いや、今回は納期優先で」
私：「でも品質が……」
上司：「いや納期が……」
それぞれの目指しているKPIが異なるから、目線が異なり険悪になる。
これもあるあるですね～
でもGitに落とし込んでみると、ただの、
Merge Conflict
です。
<<<<<<< 自分
品質優先
=======
納期優先
>>>>>>> 上司
しかもConflictには種類があります。
今回なら、
Priority Conflict
です。
つまり、
「どちらが正しいか」
ではなく、
「何を優先するか」
の話。
こう考えると少し冷静な目線で会話ができます。
発言を間違えたらRevertする
私：「A社には連絡済みです」
5分後。
私：あ、まだ連絡してなかった。（大嘘）
ここで最悪なのが、
「いや、連絡する予定って意味でした」
みたいな言い訳をすることです。
やってしまいたくはなりますが、どう考えても悪手ですね...
これは、
git push --force
です。
これは他人のbranchなどにもめちゃめちゃ大きく影響を及ぼすため、基本的には利用が非推奨です。
こういう場合は素直に、
「すみません、先ほど連絡済みと言いましたが、正しくは社内確認済みでした。まだA社には連絡していません」
としましょう。
つまり、
git revert
です。
Commitは小さくする
会話でも巨大Commitは危険です。
私：「今月数字落ちてるんですけど、多分広告の影響で、ただ季節要因もありそうですし営業側でも何か変わったらしくて、とりあえずチャネルごとに見るのがいいかなと思います」
上司：「え、結局何が言いたいの？」
私：「😣😣😣😣😣😣😣😣😣」
結論ベースかつ問題を切り分けて離せない典型的な例ですね。
これをcommitとして考えてみます。
私：「まず事実として、CV率は先月より10%下がっています」(#Commit 1)
上司：「うん」
私：「原因候補として、流入構成の変化を疑っています」(#Commit 2)
上司：「なるほど」
私：「なのでチャネル別に追加分析したいです」(#Commit 3)
上司：「OK」
素晴らしいコミュニケーションです。
小さいCommitはレビューしやすい。
会話の本質も同じです。
ここまで考えてCIを入れたくなった
ここまで「会話」というものをGitで考えてみました。
ただし問題があります。
間違った発言をPushする前に止めたい。
誰にだって失言はあります。人間ですもの。
でも取り返しのつかない失言はできるだけ避けたいですよね。
そこでCIです。
Conversation CI
例えば、
私の脳内：
「この売上分析、マジで意味ないですね。私がやったほうがマシな示唆出ますよ😆」
考えうる限りのBad Communicationです。
そのままPush（=発言）すると終わります。
なのでCIを通過させましょう。
チェック内容はこれくらい。
Fact Check
→ 本当に事実？
Intent Check
→ 相手の質問に答えてる？
Assumption Check
→ 勝手に前提を補完してない？
Tone Check
→ 強すぎない？
Confidence Check
→ 確信度以上に断定してない？
例えば、
「この売上分析、マジで意味ないですね。私がやったほうがマシな示唆出ますよ😆」
CI結果。
❌ Tone Check
❌ Confidence Check
⚠ Assumption Check
となるはずなので、修正をしましょう。
「現時点のデータだけでは、この方法で原因を切り分けるのは難しそうです」
CI：
✓ Fact
✓ Intent
✓ Tone
✓ Confidence
はい、いい感じにPushできました。
Unit Test
せっかくなのでUnit Testも考えてみます。
私：「田中さんが間違ってます」
田中さん：「！？」
会話としてもUnit Test上でも全然だめです。
CI：
Fact UNKNOWN
Evidence FAILED
Necessity FAILED
Wording FAILED
この場合はDeploy禁止となります。
Integration Test
私：「できます」
発言だけ考えると、単体では問題なし。
でも前提となっている会話が、
上司：「明日までにできます？」
私：「できます」
だと非常に危ないですね。
技術的に可能 ≠ 明日までに納品可能
なので、文脈込みでテストします。
Regression Test
これもよくありそうなパターンですね。
私：「（流石に全機能の実装は厳しい...）今月中は難しいです」
今日。
私：「（機能絞って最低限の実装だけなら）来週できます」
上司：「えっ？？？」
大切な行間があまりに省略されすぎています。
これではRegression Testは失敗ですね。
例えば、
「前回は全機能対応だと今月中は難しいとお伝えしました。今回はA機能だけに絞れば来週可能です」
これなら意味も正しくなり、会話の筋が通ります。
せっかくならGitHub Actionsも欲しい
会話は相手の発言をきっかけに生まれることが非常に多いと思います。
そこで相手の発言をTriggerにします。
on: ambiguity
上司：「例の資料よろしく」
脳内Action：
⚠ Ambiguous request
どの資料？
期限は？
完成版？
叩き台？
私：「先週の売上分析資料ですか？ 今日中に叩き台で大丈夫ですか？」
on: conflict
上司：「今回は納期優先で」
私：「品質を落としたくないです」
Action実行。
Conflict type:
Priority Conflict
自分:
Quality
相手:
Delivery
on: emotional_signal
上司：「……まあいいけど」
私の脳： （なんか怒ってる！？）
と即断しない。
Possible:
- 不満
- 諦め
- 本当にOK
Confidence:
Low
なので、
私：「念のためですが、何か懸念残ってます？」
Fetchする。
Pre-commit Hook
実際の会話中に毎回CIをフル実行するのは無理です。
なので普段はこれだけ。
話す直前チェック
1. 事実？
2. 推測？
3. 質問に答えてる？
4. 断定しすぎてない？
5. 分からないなら分からないと言える？
これがPre-commit Hookです。
重要な話だけPre-push Hook
聞き漏らしや認識齟齬があると非常に危ないのは、
- 納期
- 金額
- 契約
- 障害原因
- 顧客への説明
- 人事
- 責任
です。
こういう内容が伴う会話は厳格にします。
□ 数値確認済み
□ 日付確認済み
□ 事実確認済み
□ 自分に決定権がある
□ 本当に約束できる
1つでも何かあれば、
私：「そこだけ確認してから回答します」
としてPushしないようにします。
Protected Branch
正式回答はmainです。
そしてmainには直接Push禁止。
例えば、
顧客回答
契約
障害原因
経営数字
法務判断
はProtected Branchと考えます。
CODEOWNERS
さらに、
私：「これ法的にOKですよ（知らんけど）」
とか勝手に言わないようにしましょう。。
/legal/
→ 法務
/security/
→ セキュリティ
/accounting/
→ 経理
つまり、
私：「そこは法務確認が必要です」
とちゃんと考えて、
CODEOWNERSにReview Requestを送りましょう。
Environmentもある
同じ内容でも相手によって言い方が違います。
これは環境が異なるため仕方ないですが、以下のようなことが考えられます。
dev
同僚：「これDB設計ミスっぽくない？」
私：「っぽいですね」
staging
チーム会議：「DB設計に起因している可能性があります」
production
顧客：「現在、DB設計を含めて原因を調査しています。現時点では原因は確定していません」
なかなか面白いと思いますが、
同じ内容でも内容の粒度が異なることはよくあると思います。
すべての議論の終着点であるRelease
会議の最後。
疲弊している頭の中で思うのは、
（（（（で、結局どうなった？））））
ここでReleaseが登場します。
Release v1.4
決定事項
✓ Aを採用
✓ Bは延期
✓ Cは田中さん担当
✓ 公開日は10/15
正直これだけ欲しいですよね？
Tag
Releaseで重要になってくるのはTagです。
v1.0
2026/09/22
「10/15公開で合意」
これなら、
上司：「前から11月って言ってたよね？」
私：（10/15公開で合意取ってるのにな）「確認します...」
となりません！
上司：「前から11月って言ってたよね？」
私：「10/15公開でTag切ってますね」
で一発論破です。
そして冒頭の問題
上司：「俺、前にもこれ言ったよね？」
私：「いや絶対聞いてないです」
で上司と揉めるのではなく、
Logを確認
↓
Diffを見る
↓
いつ認識がズレたか探す
にします。
git bisect
9/1。
双方：「Aでいきましょう」
認識一致。
9/10。
上司：「Bで進める話だったよね」
私：「え？」
認識不一致。
では中間を見る。
調べる。
9/9。
上司：「じゃあ対応する方向で」
自分の理解： 調査開始。
上司の理解：実装決定。
ここだ。
Root Cause:
「対応する」の意味が違った
つまり、
「言ったか言ってないか」ではなく「どこで認識が分岐したか」
を探します。
一連の会話をGitとして見る
最後に全部一本にするとこうです。
もう少し実際の会話っぽくすると、
Git的には、
fetch
↓
diff
↓
issue
↓
commit
↓
push
↓
review
↓
merge
↓
tag
です。
Conversation DevOps
全部まとめるとこうです。
問題があれば、
です。
Perfect CommunicationではなくFault-Tolerant Communication
ここまで会話のGit化について考えてみましたが、
絶対に間違えない会話は無理です。
人間なので。
大事なのは、
誤解したら気づけること
です。
つまり目指すのは、
Perfect Communication
ではなく、
Fault-Tolerant Communication
です。
まとめ
会社の会話をGitにすると、
聞く
→ fetch
認識確認
→ diff
現在地確認
→ status
話す
→ commit / push
提案
→ Pull Request
別の話
→ branch
後回し
→ stash
意見衝突
→ merge conflict
訂正
→ revert
決定
→ tag
履歴
→ log
発言チェック
→ CI
重要事項
→ protected branch
専門家確認
→ CODEOWNERS
事故分析
→ postmortem
になります。
そして、
分からない
=
Waiting for dependency
返答に詰まる
=
Insufficient Requirements
意見が違う
=
Merge Conflict
間違えた
=
Hotfix Required
くらいに考える。
個人的には、
「次に何を言えばいい？」ではなく、「今Repositoryがどういう状態？」
と考えるだけでも、会社での会話は少し楽になる気がします。
会話ってすごい
改めてこの概念を考えた時、
複雑なbranchを管理しつつ、自分の経験に基づくActionを利用して、CIを高速で回し、どんな議題にもpushして、conflictは自律的に修正まで仕様としてくれるわけですから、
到底Gitで管理は追いつかない気がします。
逆説的ではありますが。
これだけ複雑だからこそ、会話に疲れるのは当たり前であるのかもしれないですね。
過去記事は以下のリンクから！
X / GitHubで色々公開してます！
