エンジニアに必要な「共通言語」とは？設計・対話・文化をつなぐ知の土台

「この設計、YAGNIじゃない？」

「それ、SOLIDのOに反してるかも」

こんな会話がスムーズに通じるチームには、共通言語があります。

逆に、言葉の定義がバラバラだと、話しているのに伝わらないというズレが生まれがち。

この記事では、エンジニアにとっての「共通言語」とは何か、なぜ必要なのか、どうそろえていくのかを考えていきます。

---

共通言語がないと、何が起きるか？

• 設計レビューで「抽象的」「ざっくり」「ニュアンス頼り」の会話になりがち
• 「冗長だよね」「テストが甘いかも」など、感覚に依存したフィードバックが増える
• 意図が食い違っているのに、気づかず進んでしまう

つまり、思考の粒度が揃っていないと、対話がズレる。

これが継続すると、設計品質も、関係性も、どちらも不安定になります。

---

「共通言語」があるチームの強さ

状態	効果
「DRY」「KISS」「責務」などが自然に使われる	設計の意図が素早く共有できる
「コンテキスト」や「ドメイン」などの言葉をそろえている	ビジネスと技術が対話しやすくなる
書籍や原則に基づいたレビューができる	論点が感覚ではなく“学習済みの軸”になる
会話の再現性が高い	過去の判断が言葉で追えるようになり、学びが蓄積される

---

そもそも「共通言語」とは？

✅ 単なる“単語”ではなく、「知の土台」

• 「YAGNI」「ポリモーフィズム」「オブジェクト指向」「関心の分離」など、概念に名前を与える言葉
• 抽象的な設計思想・アーキテクチャの方向性・行動原則などを共有可能にする“ことばの粒”

🔑 言語は、文化の前提であり、設計のインフラ

---

どうやって「共通言語」をそろえていくか？

🧩 1. 書籍・原則を共有する

• 『Clean Code』『The Pragmatic Programmer』『ドメイン駆動設計』など

  → チームで「同じ文脈で学ぶ」ことが言語をそろえる近道

---

💬 2. 対話の中で“定義”を確認する

• 「今の“責務”って、どのレイヤーを指してる？」
• 「“関心の分離”って、ここでは何と何を切ってる？」

→ 日々のレビューやふりかえりで、曖昧さを言葉にする文化を育てる

---

🛠 3. ドキュメントやツールにも言葉を刻む

• 設計資料・PRテンプレ・レビューコメントに、意図と用語を一貫して使う
• 意識的に共通言語を“運用可能な言語”にすることで、定着率が上がる

---

まとめ：共通言語は“コード外のインフラ”である

設計・対話・文化──そのすべてを支えているのは、**チームが持つ「言葉」**です。

共通言語は、それらを接続する“知のインフラ”。

強いチームは、同じ概念を、同じ名前で語れる。

その状態を少しずつ、意図的につくっていくことが、エンジニア文化を育てる第一歩になります。

---

文化を生む言葉 vs 壊す言葉：対比チャート

シーン	文化を育てる言葉	文化を壊す言葉	解説・背景
🧪 ミスや失敗のあと	「学びになったね」「次どうする？」	「なんでそんなことしたの？」	前向きな再構築 vs 責任追及型で委縮を招く
🧠 設計や議論の途中	「その視点、面白い」「別の観点でも考えてみよう」	「いや、それはおかしい」「普通こうだよね」	多様性の歓迎 vs 正解圧の押し付け
🙋‍♂️ 質問や相談に対して	「いい質問だね」「それよく聞いてくれた」	「え、それ知らないの？」「前にも言ったよね」	安心して尋ねられる文化 vs 恥ずかしさを植え付ける文化
💬 ふりかえりでの発言	「話してくれてありがとう」「気づけてよかった」	「まあ、前からそうだと思ってた」「言っても変わらないし」	本音を出せる文化 vs あきらめと沈黙の文化
🤝 レビュー時のフィードバック	「ここの意図、すごくわかりやすい」「ここ、どう考えた？」	「ここ、意味不明」「マジで読みにくい」	認知の確認と問いかけ vs 一方的な否定とトーンの強さ

---

🧭 活用のヒント

• ふりかえりやチームキックオフの時に共有すると効果的です
• 「どんな言葉を“使いたい文化”にするか？」をチームで話し合うきっかけに
• 定期的にこの表を振り返ることで、“文化のメンテナンス”が可能になります