「同じ言葉で違うことを指している」問題
スプリントレビューの場で、こんな会話が起きることはないでしょうか。
「この機能、完了しましたか？」
「はい、実装は終わりました」
「テストは？」
「あ、それは別で……」
「完了」という言葉を、開発者は「実装が終わった状態」として使い、
プロダクトオーナーは「リリースできる状態」として使っていた。
言葉は同じでも、意味が違う。この「言葉のずれ」は、スプリントの進捗だけでなく、判断・優先順位・品質基準のあらゆる場面で発生します。
そして多くの場合、そのずれは表面化したときにはすでに大きなコストを生んでいます。
プロジェクト・ランゲージとは
前回の記事（B-01）では、チームの暗黙知が共有されない構造的な理由と、その解法としてのパターン・ランゲージを解説しました。
プロジェクト・ランゲージは、このパターン・ランゲージの考え方を、特定のプロジェクトチームのためにローカルな形で作成することです。
プロジェクト・ランゲージが対象にするのは、汎用的な知識ではなく、そのチーム・そのプロジェクトだからこそ生まれた固有の言葉・判断基準・暗黙のルールです。
- このチームでの「完了」の定義
- 「緊急」と「重要」の区別の仕方
- この種類の問題が起きたら誰に相談するか
- このプロジェクトでうまくいったパターン・失敗したパターン
これらをパターンとして記述・共有・定着させることで、チームの共通言語が生まれます。
その共通言語が、すれ違いを減らし、引き継ぎのコストを下げ、チームの学びを資産に変えます。
4ステップの実践ガイド
プロジェクト・ランゲージを作るプロセスは、以下の4ステップで構成されます。
Step 1：認識のメガネを使ったディスカッションの実施
最初のステップは、チームでの対話です。
ただし、ただ「知識を共有しよう」と呼びかけるのではうまくいきません。「認識のメガネ」となる問いを使うことで、暗黙知が言葉として出てきやすくなります。
有効な問いの例:
- 「このプロジェクトで、Xはどういう意味で使っていますか？」（言葉の定義の確認）
- 「この判断をうまくできた人は、何を見て判断していますか？」（暗黙の判断基準の掘り起こし）
- 「このプロジェクトで、うまくいったときの共通点は何ですか？」（成功パターンの抽出）
- 「新しいメンバーに最初に伝えるとしたら、何を伝えますか？」（コアの暗黙知の特定）
このディスカッションの目的は、完成したドキュメントを作ることではありません。
「チームの中にある知識」を言葉として外に出すことです。
Step 2：プロジェクトランゲージを作成する
ディスカッションで出てきた言葉・判断・知見を、パターンとして構造化します。
一つのパターンは、以下の3つの要素で記述します:
- 状況：このパターンが当てはまる場面・文脈
- 問題：その状況でよく起きる困りごと・判断の難しさ
- 解法：このチームで有効だと確認された対処・判断の仕方
例えば「完了の定義」であれば、チームで「レビューまで済んで完了」というプロジェクトランゲージを作成します:
- 状況：スプリントレビューで進捗を確認するとき
- 問題：「完了」の意味が人によって異なり、認識がずれる
- 解法：「レビューまで済んで完了」——テストが通り、レビューが済んだ状態を指す
完璧を求めず、まず3〜5個のパターンから始めることを推奨します。
チームが使いながら育てていくことが前提です。
Step 3：プロジェクトランゲージを活用する
作ったプロジェクトランゲージは、実際の業務の中で使われて初めて意味をもちます。
活用の起点として有効な場面:
- 新メンバーのオンボーディング——チームの言葉・文化を最初に伝えるためのリソースとして活用
- 判断の迷い場面——「このケースはどう判断するか」と迷ったときに参照する
- 振り返り（レトロスペクティブ）——「今回うまくいったこと」「困ったこと」をパターンに照らして言語化する
- 引き継ぎ——担当者が変わる際に、文脈ごと渡すためのドキュメントとして活用
「使われない」ランゲージは存在しないのと同じです。
チームの日常に組み込まれることで、知識は生きた資産になります。
Step 4：プロジェクトランゲージを組織の活動に組み込む
最後のステップは、プロジェクトランゲージを一時的な取り組みで終わらせず、チームの継続的な活動として根付かせることです。
具体的な組み込み方:
- 定期的な更新の仕組み——スプリントごと、あるいは四半期ごとに「新しく気づいたパターン」を追加・更新する時間を設ける
- チームの合意形成ツールとして使う——判断に迷ったとき、「プロジェクトランゲージにはこう書いてある」を基準にすることで、属人的な判断を減らす
- プロジェクトをまたいだ継承——プロジェクトが終わるとき、次のプロジェクトに引き継げるパターンを選別・保存する
組み込みの成否を分けるのは、誰かが「使う」と決めることです。
チームリーダーや推進役が意図的に活用の機会を作ることで、定着が加速します。
なぜ続かないのか
プロジェクトランゲージの取り組みが定着しないチームには、いくつかの共通パターンがあります。
- 完璧主義——「ちゃんとしたものができてから共有しよう」と思うあまり、最初の一歩が踏み出せない。プロジェクトランゲージは「育てるもの」であり、不完全でいい
- 専用ツールへの依存——「どのツールで管理するか」の議論に時間をかけすぎる。Confluenceでも、Notionでも、Markdownファイルでも、チームが見られればどこでもいい
- 使われない場所への保存——誰も見に行かない場所に保存すると、存在を忘れられる。チームが日常的に触れる場所に置く
- 作って終わり——最初の作成で満足し、更新・活用が止まる。「使い続ける」仕組みがなければ、どんなドキュメントも陳腐化する
これらを避けるためのコツは一つです。小さく始めて、使いながら育てる。
3つのパターンから始めて、スプリントのたびに1つ追加するだけでも、半年後には立派なチームの共有財産になっています。
まとめ
プロジェクト・ランゲージは、チームの暗黙知を言語化し、共通言語として定着させるための実践的なアプローチです。
4ステップのプロセス——ディスカッション、作成、活用、組み込み——は、どのチームでも試せる実践的な手順です。
完璧を目指さず、チームの日常の中で育てていくことが、定着の鍵です。
「チーム象限」における品質改善は、ツールやプロセスの導入だけでは完結しません。
チームの中にある知識を共有財産にし、変化に強いチームをつくることが、持続的な品質改善の土台です。
次回（B-03）では、作ったプロジェクト・ランゲージを導入したチームに何が起きるのか——知識共有がもたらす変化と、自律的なチームを育てるための継承・引き継ぎの実践を掘り下げます。