よくある風景
プロジェクトが立ち上がった。チームには経験豊富なメンバーもいる。
それなのに、同じ失敗が繰り返される。
「その判断の背景、Aさんしか知らないんですよね」
「引き継いだけど、なぜそうなっているのかわからない」
「前のプロジェクトで同じ問題があったはずなのに、また同じことに」
知識はチームの中にある。でも、それは特定の人の頭の中にあって、共有されていない。
これは個人の問題ではありません。知識が共有される仕組みがないという構造的な問題です。
暗黙知が共有されない構造的な理由
「ちゃんとドキュメントを書いてほしい」「振り返りをしっかりやろう」。
こういった呼びかけで知識共有が改善することは、まずありません。
なぜか。暗黙知が共有されないのは、意識や習慣の問題ではなく、言語化を妨げる3つの構造的な障壁があるためです。
- 動機の欠如——自分の知識を言語化することで得られる直接的なメリットが、当事者には見えにくい。書いた後も「本当に伝わるか」という不確かさが残る
- 場の欠如——知識を共有するための適切なフォーマットや場が用意されていない。ドキュメントに書くべきか、Slackに流すべきか、誰に伝えるべきかが不明確
- 時間の欠如——プロジェクトの中では常に「今やること」が優先される。暗黙知を整理して共有する時間は、構造的に確保されにくい
この3つが重なることで、知識は個人の中に蓄積されたまま、チームには流れていきません。
SECIモデルで考える
知識創造の研究者・野中郁次郎らが提唱したSECIモデルは、暗黙知と形式知の相互変換を4つのフェーズで説明するフレームワークです。
- 共同化（Socialization）——共に経験することで、言語化されていない知識が人から人へ伝わる。見て覚える、隣でやってみる、という形
- 表出化（Externalization）——暗黙知を言語・図・概念として表現する。この変換こそが「知識の共有」の核心
- 連結化（Combination）——形式知同士を組み合わせ、新たな知識体系をつくる。ドキュメントの整理、マニュアルの体系化など
- 内面化（Internalization）——形式知を実践の中で身につけ、再び暗黙知として自分のものにする。「読んで知っている」を「使える」に変える段階
SECIモデルはこの4フェーズがスパイラルを描いて進むことで、チームの知識が深まっていくと説明します。
SECIモデルの課題：「どうやって表出化するか」
SECIモデルを知ったとき、多くの人が感じる壁があります。
「表出化が大事なのはわかった。でも、どうやって言語化するのか」
暗黙知は定義上、言語化されていない知識です。
「うまく動いた理由」「この判断をした背景」「このチームならではのやり方」——こうした知識は、言語化しようとしたときに初めて「どう言えばいいかわからない」という困難に直面します。
フレームワークとして「表出化せよ」と言われても、その具体的な方法がなければ実践には繋がりません。
ここが、SECIモデルが概念として広まりながらも、現場での実践が進まない理由の一つです。
パターン・ランゲージという解法
この「表出化の困難」に対する実践的な解法が、パターン・ランゲージです。
パターン・ランゲージは、建築家クリストファー・アレグザンダーが提唱した概念で、もともとは建築の設計知識を「パターン」として記述・共有するための方法でした。
その後、ソフトウェア開発の「デザインパターン」としても広く知られるようになり、今では組織・チームの知識共有にも応用されています。
パターン・ランゲージの核心は、「よく起きる状況」「そこにある問題」「有効な解法」を一つのパターンとして構造化することです。
これがSECIモデルの「表出化」の問題を解決します。
「うまくいったときに何が起きていたか」を「状況・問題・解法」のフォーマットで記述することで、言語化のとっかかりが生まれます。
「感覚的にわかっていたこと」を、共有可能な形に変換するための足場として機能するのです。
パターン・ランゲージは、暗黙知を表出化するための「言語」を提供する。
「プロジェクト・ランゲージ」へ
このパターン・ランゲージの考え方を、特定のプロジェクトチームのためにローカルな形で作成すること——それが「プロジェクト・ランゲージ」です。
一般的なパターン・ランゲージがドメインを横断した汎用的な知識を扱うのに対し、プロジェクト・ランゲージはそのチーム・そのプロジェクトでしか通じない文脈的な知識を対象にします。
「うちのプロジェクトでは『完了』の意味がXとYで違う」
「このチームでは、○○のときは必ずAさんに確認する、という暗黙のルールがある」
「前のプロジェクトで学んだ『先に仕様を固めるとあとで詰まる』という教訓」
こうした、チームの中だけで意味をもつ言葉・判断・知見をパターンとして言語化し、チームの共通言語をつくる——それがプロジェクト・ランゲージです。
次回の記事では、プロジェクト・ランゲージを実際にどう作るか、4ステップの実践ガイドをお届けします。
まとめ
チームの暗黙知が共有されないのは、意識や努力の問題ではなく、言語化の動機・場・時間という3つの構造的な障壁があるためです。
SECIモデルはこの問題の全体像を理解するフレームワークを提供しますが、特に「表出化」の実践方法が課題です。
パターン・ランゲージは、その表出化を促すための具体的な方法を提供します。
チームの中にある「誰かしか知らない知識」を、チームの共有財産にする。
その第一歩は、言語化のための「足場」を用意することです。