SECIモデルとBa（場）で紐解く“知識が育つ場づくり”と、教育現場・企業での実践例
「社内ポータルを作ったのに、誰も見てくれない」
「マニュアルは増えたのに、“本当に知りたいコツ”は相変わらず人に聞かないとわからない」
教育現場でも企業でも、こんなモヤモヤを感じたことはないでしょうか。
弊社でも教育コンテンツをつくる中で、まさに同じ問題に何度もぶつかってきました。
そのとき、ヒントになったのが 一橋大学・野中郁次郎名誉教授 らの SECI モデルとBa（場）、そしてKnowledge Assets（知識資産）という考え方です。
この記事では、難しい理論用語はできるだけ抜きにしながら、
- SECI / Ba / Knowledge Assets を「感覚的にわかる」レベルで整理しつつ
- なぜ「ITシステムだけ」では知識共有がうまくいかないのか
- ガリレオがマイクラ教材でどんな「場づくり」の工夫をしているか
を、具体例を交えてご紹介します。
1. まずはざっくり：SECI・Ba・Knowledge Assetsって何？
SECIモデル = 知識が増えていく「回し方」
SECIモデルでは、知識が増えていく流れを4つに分けて考えます。
- Socialization（共同化）
先輩の仕事ぶりを横で見て覚える、現場同行、雑談、飲み会…
👉「暗黙知 → 暗黙知」：感覚や勘どころが、人から人へ直接伝わるフェーズ - Externalization（表出化）
「こういう時はお客さん、ここを不安に思ってるんだよ」と比喩や図で説明したり、ホワイトボードで描いたり
👉「暗黙知 → 形式知」：頭の中の“もやっ”を言葉や図にするフェーズ - Combination（連結化）
資料をまとめ直す、マニュアルを統合する、FAQやデータベースを作る
👉「形式知 → 形式知」：バラバラの情報を整理・統合するフェーズ - Internalization（内面化）
マニュアルを見ながら何度もやっているうちに、「もう見なくてもできる」状態になる
👉「形式知 → 暗黙知」：知識が“体に染み込む”フェーズ
これがぐるぐる回ることで、個人の知識が組織全体に広がっていく、というのがSECIの基本イメージです。
Ba（場）= 知識が生まれる「空気」と「環境」
ただし、「知識の回り方」だけを語っても、どこで起きるのか・誰と起きるのかがわかりません。
そこで登場するのが Ba（場） です。
Nonakaは Ba を「知識創造のための共有コンテクスト」と呼びました。
イメージとしては：
- 一緒に汗をかきながら現場で作業している場所
- ざっくばらんな本音トークが許される会議
- オンラインでも、気軽に試して失敗できるサーバー空間
など、空間＋人間関係＋雰囲気のセットです。
Baも4つに分けられます。
- Originating Ba：少人数での濃い経験共有の場
- Dialoguing Ba：メタファ・コンセプトを議論する場
- Systemizing Ba：マニュアル・DBなど、知識を整理する場
- Exercising Ba：トレーニング・OJTで実践する場
Knowledge Assets = 組織が持っている「知識の中身」
さらに、組織が持っている知識の“中身”を、野中教授ら は Knowledge Assets（知識資産）と呼び、4つに分けました。
- Experiential Assets（経験的知識資産）
- 現場の経験、身体感覚、信頼関係、勘どころ
- 例：消防士の「この煙の色は危ない」、営業の「この表情のときは押さないほうがいい」
- Conceptual Assets（概念的知識資産）
- コンセプト、ブランドイメージ、キャッチコピー、図やモデル
- 例：商品コンセプトシート、サービスの世界観図
- Systemic Assets（システム的知識資産）
- マニュアル、仕様書、DB、手順書、特許
- 例：操作マニュアル、FAQ、ナレッジDB、チェックリスト
- Routine Assets（ルーチン知識資産）
- 組織の日常のやり方、暗黙のルール、文化
- 例：「困ったらまず◯◯さんに相談」「この順番で会議を進める」
2. よくある“失敗”パターン：Systemizing Ba（ITシステム）偏重
ここからが本題です。
理論上は、
- Ba（場）
- SECI（プロセス）
- Knowledge Assets（中身）
がバランスよく設計されているのが理想です。
ところが、現実の多くの組織では、こんなことが起こります。
高価なナレッジDB・ポータル・FAQシステム（＝Systemizing Ba）に投資したのに、
現場の経験（Experiential）やルーチン（Routine）はほとんど入っていない。
具体的なイメージ
ある企業で、こんなことが起きていました（実際によくあるケースです）。
- 数千万円を投じて、立派なナレッジポータルを導入
- マニュアルやFAQはぎっしり
- しかし、若手が検索しても「きれいすぎる手順」しか出てこない
→ 本当に知りたい「例外処理」や「現場の空気を読むコツ」は書いてない - 結局、若手は
→「◯◯さん、ちょっといいですか…」と直接聞きにいく
→ ベテランは「それ、さっきも別の人に説明したんだけどな…」と内心モヤモヤ
DBはあるのに使われない。
使っても現場感がないから役に立たない。
これが、Systemizing Ba と Systemic Assets だけが肥大化して、Experiential / Routine が置き去りになっている状態です。
3. なぜ「現場のコツ」がDBに乗らないのか？
このミスマッチが起きる理由を、4つに整理してみます。
① 「知識＝文書」と思い込みがち
知識共有と聞くと、すぐに
「じゃあ、ポータルを作ろう」「マニュアルを整備しよう」
となりがちです。
つまり、codification（文書化）偏重になりやすい。
でも本当に欲しいのは、
- 失敗談
- 例外処理
- 「このお客さんはこのパターンだと怒る」みたいな微妙なニュアンス
であり、そこはテキストだけでは切り取りづらい領域です。
② 書くのは大変。でも評価されない
ベテランからすると、
「書くより、現場で見せたほうが早い」
「どうせ誰も読まない」
という気持ちもあります。
しかも、「暗黙知を書き起こす」作業はかなり頭を使います。
- 書いても評価されない
- 時間もかかる
- ボーナスにもほぼ影響しない
となると、「ナレッジを書きましょう」と言われても、本気では取り組みにくいのが現実です。
③ ツールが「文章前提」になっている
多くのナレッジシステムの入力欄は、
- タイトル
- カテゴリ
- 本文（テキスト）
という構造になっています。
しかし、暗黙知に近い情報は、本当は
- 30秒の動画
- 1分の画面キャプチャ
- その場での音声メモ
のほうが向いていることが多い。
ツールがそこを前提に設計されていないので、結果として「硬い文章」だけが増えていきます。
④ 「失敗談」や「グレーな判断」は書きづらい文化
実務で一番役立つのは、むしろ
- 「あのとき、マニュアル通りにやると炎上しそうだったので、こう変えました」
- 「本当はこう書いてあるけど、このお客さんにはこう伝えるといいです」
といったグレーゾーンの判断です。
でも、それを正直に書き残すと、
- ルール違反に見えるのでは？
- 責任を問われるのでは？
という不安が立ちはだかります。
結果、「一番おいしい部分」がナレッジDBに乗らない、という状況が生まれます。
4. 建設会者の現場の事例で考える「Baづくり」と「知識の見える化」
ここからは、建設会社の現場の事例に寄せてお話します。
例1：建設現場での Ba 設計
たとえば、ある中堅の建設会社で、
「若手現場監督の育成」と「属人的なベテランノウハウの見える化」をテーマにしたプロジェクトを考えます。
若手とベテランが、同じ現場で一緒に工程を組み、リスクを議論しながら現場巡回をする
→ Originating Ba（創発の場）
「なぜ今日はこの手順を入れ替えたのか？」「この施主にはなぜこの説明をしたのか？」を、写真や図面を見ながらホワイトボードで振り返るミーティングを行う
→ Dialoguing Ba（対話の場）
振り返りで出た“判断のポイント”や“NGパターン”を、事例シート・チェックリスト・社内ポータルの記事として整理する
→ Systemizing Ba（システム化の場）
整理した事例シートを使って、別の現場や次の新人OJTで同じケースを模擬的に再現し、判断を練習する
→ Exercising Ba（実践の場）
という形で、Baの4タイプを1つの「現場×育成プロジェクト」の中に埋め込むように設計しているイメージです。
ここで蓄積される Knowledge Assets を大雑把に整理すると：
- Experiential：
ベテランと一緒に現場を歩いた経験、天候悪化時の判断、職人さんとのリアルなやりとり、工程トラブルの実体験 - Conceptual：
「雨のときはこの順で判断する」「こういう施主にはこの説明フロー」といった判断フレーム、ホワイトボードで描いた図解・パターン - Systemic：
事例シート、チェックリスト、工程変更のガイドライン、社内ポータルの記事、教育用スライド - Routine：
毎週の振り返りミーティングのやり方、朝礼での情報共有の流れ、「トラブルが起きたらまずここを確認する」という現場ルール
こうした「場（Ba）」と「中身（Knowledge Assets）」をセットで設計することで、
単なる“立派なマニュアルと高価なシステム”ではなく、知識創造のサイクルが回る現場育成の仕組みになっていきます。
例2：建設会社における「暗黙知」の扱い
今度は、同じ建設会社が「ベテラン現場代理人のノウハウ継承」をテーマに取り組むケースを考えます。
ベテラン現場代理人へのインタビューや、1日の仕事への密着取材を行い、
「どのタイミングで何を見ているのか」「何を危険サインと感じているのか」を聞き出す
→ まずは暗黙知の“掘り起こし”（Originating / Dialoguing Ba）
ヒアリング内容をもとに、
「こういうときはこう感じる」「この現場は“ピンと来ない”」といった感覚を、
比喩・ストーリー・漫画風の図解などに落とし込む
→ Externalization ＆ Conceptual Assets への変換
そこから得られた判断ストーリーやチェックポイントを、
- 若手向けの事例集
- 「雨天時の判断フロー」ガイド
- 研修用ケーススタディ資料
として整形し、社内ポータルや研修コンテンツに組み込む
→ Systemic Assets として蓄積（Systemizing Ba）
現場研修や社内研修で、
- 同じケースをロールプレイ・シミュレーション
- 若手が自分の判断を言語化・振り返り
を繰り返すことで、
「ベテラン流の“安全な判断のクセ”」が若手の中に徐々に身についていく
→ Internalization ＆ Routine Assets 化（Exercising Ba）
という流れを意識して設計していくイメージです。
ここで重要なのは、最初から「全部マニュアル化しよう」としないことです。
- まずは、「人と人が一緒に仕事をしながら話せる場（Ba）」をつくる
- そこで出てきたエピソード・比喩・判断の言葉を丁寧に拾う
- それを少しずつ、事例集・ガイドライン・研修コンテンツ（Knowledge Assets）として整形していく
という順番を踏むことで、
Systemizing Ba（ITシステム・マニュアル）だけに投資して、
肝心の“現場のコツ（Experiential／Routine）”が一切吸い上がらない
という典型的な落とし穴を避けることができます。
5. じゃあ、どうやって自分たちの現場に活かす？
最後に、「うちの現場だと何から見直せるか？」のヒントを、3つの問いにまとめます。
質問1：Ba（場）のポートフォリオはどうなっているか？
- Originating / Dialoguing / Systemizing / Exercising
→ どこに時間と予算をかけているか？ - 「システム導入」と比べて、「一緒にやる場」「対話の場」への投資は十分か？
質問2：Knowledge Assets のバランスは？
- マニュアルやDB（Systemic）だけが増えていないか？
- 経験（Experiential）やルーチン（Routine）、コンセプト（Conceptual）はどうか？
質問3：SECI のどこで止まりがちか？
- 経験共有（S）まではあるが、言語化（E）されていない？
- アイデアは出るのに、整理（C）して次に使える形にできていない？
- 文書はあるのに、実践（I）されず、形骸化していない？
この3点を簡単なワークシートにして、
社内のプロジェクトや学校の授業をふりかえるだけでも、「どこに手を入れるべきか」がかなりクリアになります。
コメント