はじめに：感じていた課題
エンジニアとして若手エンジニアを指導する中で、ずっと感じてきた課題があります。
それは「どうすれば思考プロセスを伝えられるか」ということです。
コーディング規約やSOLID原則といったルールを教えることはできます。
けれど、 “どういうコードが原則に従っているか” や、
“なぜそのように設計したのか” という判断基準は、
言葉だけではなかなか伝わりません。
結局のところ、それらは一度自分の中で解釈して腑に落とす必要がある。
その「解釈の仕方」こそが最も教えにくく、しかし最も重要な部分です。
1. 「見て学ぶ」は怠慢ではない
最近では、「見て学べ」という言葉が“教える側の怠慢”と受け取られがちです。
しかし、私はそうは思いません。
「見て学ぶ」ことは、言語化できない領域を伝えるための大切な手段です。
寿司職人の世界では、弟子が師匠の手元を見て学びます。
手順だけでなく、力加減、判断のタイミング、全体の流れ。
それらは言葉で教えられるものではなく、観察を通じて感じ取るしかありません。
エンジニアリングの世界にも、同じような“非言語的な知”があります。
「この設計はまだ重い」「この抽象化は早すぎる」──そうした感覚的判断です。
ところが、その“手元”が見えないのが問題です。
2. エンジニアは「手元が見えない」
エンジニアは、思考の中で設計し、手を動かすのはキーボードの上。
つまり、外から思考が観察できない。
寿司職人のように作業が見えるわけでもなく、
完成したコードだけを見ても、
そこに至るまでの試行錯誤や判断の流れはほとんど分かりません。
- どんな迷いがあったのか
- どんなトレードオフを考えたのか
- どの時点で方針を変えたのか
それらが“見えない”からこそ、若手エンジニアは先輩の思考を観察して学ぶことができないのです。
3. コミットは「思考を見せるツール」になる
この課題を考える中でたどり着いたのが、
「コミット履歴を思考の記録として使う」 という考え方です。
コミットの単位とメッセージを意識すれば、
コードの変化そのものが、設計の思考プロセスを映し出す鏡になります。
コミットは“作業の記録”ではなく、“思考の記録”にできる。
若手エンジニアは、コミット履歴を追うことで、
あなたがどういう判断をしながら実装を進めたのかを学ぶことができます。
4. コミットは“思考の単位”で切る
多くの人は「作業単位」でコミットを分けます。
しかし、若手エンジニアが学びやすいのは「思考の単位」で切られたコミットです。
❌ 悪い例（作業ベース）
fix bug
add feature
refactor
✅ 良い例（思考ベース）
refactor: Split UserService into AuthService and NotificationService
Reason: SRP violation — authentication and notification mixed in one class
💡 1コミット＝1判断。
動作の区切りではなく、考えが変わった瞬間でコミットを切る。
5. コミットメッセージは「なぜ」を書く
コミットメッセージは「何をしたか」よりも、
「なぜそうしたか」を書くことで学びの価値が生まれます。
❌ 悪い例
refactor: tidy up code
✅ 良い例
refactor: Extract validation logic into separate class
Reason: Improves SRP and testability by isolating validation concern
💡 “Why”を書くことで、設計の意図が読み取れる教材になる。
コードは“結果”を、コミットは“思考”を伝える。
6. 英語で書く場合の注意
チームで英語のコミットメッセージを書く場合も多いと思います。
そのとき、英語でなんと書けばいいか分からないまま済ませないことが大切です。
❗ 曖昧な表現や和製英語で妥協せず、正確に書く。
迷ったら辞書で調べるか、ChatGPTに英訳を聞くのがおすすめです。
ChatGPTに「この意図を自然な英語で書きたい」と伝えれば、
技術的なニュアンスを含んだ英文を生成してくれます。
また、コミットメッセージが長くなるときは注意信号です。
メッセージが長いのは、1つのコミットに複数の判断が詰まっているサイン。
「書くのが難しい」と感じたら、コミットを小さく分けるタイミングです。
7. コードの質も“背中の一部”である
もちろん、コミット単位だけではなく、コード自体の質も若手エンジニアの学びになります。
若手エンジニアはコードからも、次のようなことを読み取っています。
- 命名から設計意図を感じ取る
- 責務の分割に一貫性があるか
- テストの構造に思想があるか
💡 “読むだけで理解できるコード”は、それ自体が最高の教材。
コードは「手本」であり、「背中」でもある。
8. AIが“背中を読む”時代へ
良いコミットログを積み重ねると、AIがそれを解析して、
開発者の思考プロセスを再構成できるようになります。
💡 良いコミットは未来の教育資産。
ChatGPTにコミット履歴を読ませれば、
あなたの設計判断を“再生”することもできる。
9. 教えるためではなく、“見せるため”に残す
重要なのは、「教育のために書く」のではなく、
自分の思考を正確に残すために書くということです。
寿司職人の手元が美しいのは、見せるためではなく、
正確に動くために洗練されているから。
エンジニアも同じで、思考を残す姿勢が結果として学びを生むのです。
10. まとめ：コードで“背中”を見せよう
エンジニアが若手エンジニアに伝えるべきものは、知識ではなく思考の跡です。
それは、コミットログという自然な形で残せます。
コードは結果で語らず、
コミットで“思考”を語ろう。
それが、エンジニア版「見て学べ」です。
✅ 今日からできるチェックリスト
- コミットを「思考の区切り」で切っている
- メッセージに“Why”を1行書いている
- 英語に迷ったらChatGPTで自然な表現を確認している
- コミットが重くなりすぎていない
- コード自体が“読んで学べる”状態になっている
これが、
「教えずに伝える」ための実践的な方法であり、
現代の“見て学ぶ”を再構成するエンジニアのあり方です。
このスタイルをチーム全体で続けると、
「見て学ぶ」が自然に機能する文化が生まれます。
先輩が何か特別に教えなくても、
若手エンジニアはコミットとコードを通じて思考を追体験できる。
それこそが、現代の“デジタル職人文化”です。