事業会社が社内コミュニティを立ち上げる 5 ステップ — TEMPLE モデルの適用

# 事業会社が社内コミュニティを立ち上げる 5 ステップ — TEMPLE モデルの適用

事業会社の事業開発・人事・組織開発の現場で、社内コミュニティの立ち上げが議題に上がる場面が増えています。新規事業の探索、技術領域の横断学習、若手のエンゲージメント維持、採用ブランディングなど目的は組織によって異なりますが、「縦割りを越えた学びと接続の場」を社内に作りたいという課題は共通しています。

一方で、立ち上げてみたものの 3 ヶ月続かない、参加者が固定化して内輪化するといった失敗もよく聞きます。本記事では、京都を拠点に 7 年 147 回・延べ 564 名で運営してきた社外コミュニティ「みやこでIT」の知見をもとに、立ち上げの 5 ステップを TEMPLE モデルの 6 柱に沿って体系化します。社内のほうが人事制度・予算・上司承認といった構造的サポートを得やすく、難易度はむしろ社外より低いと言えます。

---

1. なぜ社内コミュニティが必要か

縦割り組織の限界

事業会社の組織構造は、事業部・職能・地域などで縦に切られています。意思決定は速くなりますが、横断的な学習・情報共有・人材交流は構造的に発生しにくくなります。とくに 1,000 名を超える組織では、隣の部署の動きが見えないという声が常態化します。

社内コミュニティは、この縦割りを越えて横軸の接続点を作る装置です。技術領域・関心テーマ・キャリア課題などを軸に、事業部を越えた人が定期的に集まる場を持つことで、組織の中に「もう一つのネットワーク」が生まれます。

ソフト指標への影響

一般的に、社内に「公式の業務とは別の自発的な学びの場」がある組織は、若手の離職率が下がり、採用時の入社決定率も上がる傾向があります。これは Decoded のエンプロイー・エンゲージメント調査や Gartner の Future of Work レポートでも繰り返し指摘されています。新規事業の文脈でも、通常業務では出てこない「個人が持ち込むテーマ」が他部署の人と接続することで案件として動き出すケースが観察されています。

「勉強会」ではなく「コミュニティ」として続く構造

単発の勉強会とコミュニティは区別する必要があります。勉強会は「講師から参加者への一方向の情報伝達」が中心で、終わると関係が途切れます。コミュニティは「参加者同士の継続的な関係性」が中心で、開催と開催の間にも接続が残ります。最初から「続く構造」を設計するための柱が、次節で示す TEMPLE モデルの 6 つです。

---

2. 社外コミュニティ運営から得た 5 ステップ — 概要

みやこでIT は 2019 年に 6 名で始まり、2026 年現在で 564 名・147 回開催のコミュニティに育ちました。京都という地域特性を活かし、お寺・お茶屋・大学キャンパスなど多様な会場で月次開催を続けています。この 7 年の運営知見を 6 つの柱に整理したものこそ、TEMPLE モデルです。

柱	名称	問い
T	Theme（主題）	何のために集まるか
E	Environment（会場・形式）	どこで・どう集まるか
M	Members（メンバー設計）	誰がどう参加するか
P	Persistence（継続性）	どう続けるか
L	Local（外部連携）	外とどう繋がるか
E	Evolution（進化）	どこへ進化するか

社内コミュニティの立ち上げ 5 ステップは、最初の 5 つの柱（T/E/M/P/L）に対応します。Evolution は立ち上げ後の進化視点として、ステップの外側に位置します。

ステップ	対応する柱	主題
ステップ 1	T	主題の明確化
ステップ 2	E	会場・形式の選定
ステップ 3	M	初回設計
ステップ 4	P	反復運営
ステップ 5	L	連携拡張

5 ステップを順に実行することで、初回開催から半年後には「続く社内コミュニティ」の最低限の構造が整います。以下、各ステップを詳しく見ていきます。

---

3. ステップ 1: 主題の明確化（T）

何のために集まるか — 1 文で言えるか

社内コミュニティが定着しない最大の原因は、主題が曖昧なことです。「DX を進めるための場」「社内のイノベーションを促進する場」といった主題は抽象度が高すぎて参加者が自分ごと化できません。

主題は 1 文で言える レベルまで具体化することが必須です。たとえば「製造現場の AI 活用事例を持ち寄り横展開できる形に整理する場」「20 代エンジニアが業後に新技術を触る場」「事業部を越えて新規事業の種を共有する月次の場」など、聞いた人が「自分が出るべき場かどうか」を判断できる解像度まで落とします。

主題の解像度で参加意義が変わる

みやこでIT の主題は「京都の IT × ローカルの接続点を作る」と一文で表現できます。この明確さがあるため、Web エンジニアもスタートアップ経営者も自治体職員も「自分に関係がある」と判断できます。社内でも同じで、「社内のエンジニア同士の交流」程度では忙しい現場の人は時間を割きません。「半年後に各事業部の AI 活用事例を 10 件持ち寄って横展開設計まで行う」など、ゴールと活動が見える形に翻訳することで参加の意義が伝わります。

軸の選択 — 事業課題・技術領域・キャリア・拠点

主題には典型的な軸があります。

事業課題軸: 新規事業探索、特定領域の競合分析、横展開すべき成功事例の抽出
技術領域軸: 特定技術スタックの社内事例共有、新技術キャッチアップ、エンジニアリングプラクティスの標準化
キャリア軸: 若手キャリア、女性エンジニアキャリア、マネジメントへの移行
地域・拠点軸: 地方拠点同士の接続、本社と支社の交流

主催者の関心と組織の課題が交差する点を選びます。主催者本人が興味を持てない主題は、半年も続きません。

---

4. ステップ 2: 会場・形式の選定（E）

社内会議室で本当に良いか

会場として、まず候補に上がるのは社内会議室です。予算がかからず、設備が揃っていて、移動負担も小さい。合理的な選択に見えますが、大きな弱点があります。それは 「いつもの仕事モードが解除されない」 ことです。同じ場所・同じ椅子・同じ蛍光灯の下では、参加者は普段の業務と同じテンションで臨むため、横断的な対話・本音の共有・新しいアイデアの発露が起きにくくなります。

会場が持つメッセージ性

会場には「メッセージ性」があります。みやこでIT がお寺で開催すると参加者の集中度が上がり、お茶屋で開催すると京都の文化的文脈の中で IT を語る構図が生まれ、大学キャンパスでは産学連携・教育という意味合いが加わります。住職が登壇者として参加する、女将が会場提供する、大学教員が共同企画する。会場が主題と接続しているため、参加者は世界観を毎回体感できます。これは「会場ブランド」と呼ばれる現象で、主題を物理的に体現する装置として会場を選ぶことが重要です。

社内での会場設計の選択肢

会場の選定には工夫の余地があります。

役員フロアのラウンジ: 普段入れない場所が特別感と心理的バリア低下を生む
社外のレンタルスペース・カフェ: 業務モードを解除しやすい
社内カフェテリア・休憩エリア（業後）: 軽食を伴う形でリラックスした対話が起きる
取引先・パートナー企業のオフィス訪問: 外部接続点の機会も兼ねる
オフサイトの一日合宿: 半年に 1 回など節目で深い議論を行う

予算と規模に応じて組み合わせます。少なくとも「いつもの会議室と違う場所」を選ぶ意識が、コミュニティの空気を作ります。

---

5. ステップ 3: 初回設計（M）

初回は 6〜10 名で設計することが現実的

初回の参加者規模は 6〜10 名が現実的です。これより少ないと議論が成立せず、多すぎると一人ひとりの発言機会が確保できません。みやこでIT も初回 6 名から始め、第 2 回で 12 名、第 3 回で 18 名と段階的に増やしました。初回から大人数を集めようとすると、主催者の負荷と参加者の満足度のバランスが崩れます。

主催者・常連・初参加・連携先の 4 役割

参加者を「全員同じ立場」と扱うのではなく、4 つの役割に分けて設計します。

主催者（1〜2 名）: 主題を設計し運営を担う
常連（2〜3 名）: 毎回参加し場の空気を作る
初参加（2〜3 名）: 新しい視点を持ち込む
連携先（1〜2 名）: 他部署・社外・関連会社からのゲスト

常連だけでは内輪化し、初参加ばかりでは継続性が出ない。連携先がいないと外部接続点が生まれない。役割の比率を意識した招待が、初回設計の核心です。

全員参加型 vs 観客型の使い分け

全員が発言する「全員参加型」（ワークショップ・ライトニングトーク・ディスカッション）と、登壇者の話を聴く「観客型」（講演・パネル）を開催ごとに使い分けます。立ち上げ初期は全員参加型を中心にすることを推奨します。観客型は登壇者確保の負荷が高く、参加者同士の関係構築も起きにくいためです。3 〜 6 ヶ月続けて関係性ができてから観客型を組み合わせると効果的です。

心理的安全性の作り方

社内では「上司の前で本音を言いにくい」「自部署の悪口になってしまうかも」といった懸念が出やすくなります。具体的な工夫は以下です。

チェックイン時間を必ず設ける: 最初の 10 分は参加者全員が一言ずつ近況を共有
役職を外す宣言: 「ここでは役職呼び禁止、さん付けで統一」と明示
記録の扱いを明確にする: 議事録の有無・社内共有範囲を冒頭で確認
ネガティブ評価を持ち込まない: 発言を批判せず、まず受け止めてから返す

これらを毎回繰り返すことで、参加者は「ここでは安心して話せる」と認識します。

---

6. ステップ 4: 反復運営（P）

半年の継続で「定着」が生まれる

反復運営の最大の論点は、開催を半年間止めずに回し切ることです。3 回程度では単発イベントと区別がつかず、月次で 6 回続いて初めて参加者の側に「次もある」という前提が生まれます。みやこでIT でも 7 回目以降から自走が始まり、参加者が次回の登壇候補や会場候補を持ち寄るようになりました。

月次・固定曜日・固定時間で運営する

開催頻度は月次が現実的です。週次は主催者の負荷が大きすぎ、隔月では関係性が冷めます。さらに「毎月第 3 木曜日」など曜日まで固定することで、参加者は半年先まで予定をブロックできます。逆に毎回日程を調整する形だと、半数以上が「都合つかず」となり定着しません。

開催後レポート・フォロー連絡

開催と開催の間が「無音」になるとコミュニティは存在感を失います。標準的な連絡サイクルは以下です。

1. 開催当日 24 時間以内: 参加者全員にお礼 + 当日の写真 + 次回告知

2. 1 週間以内: 議事録・発表資料の共有

3. 2 週間後: 次回テーマの予告・登壇者募集

4. 次回 1 週間前: リマインド + 出欠確認

このサイクルを毎月回すことで、参加者の頭の中にコミュニティが常駐します。

役割分担の仕組み化 — 主催者依存からの脱却

Persistence の核心は、開催を支える役割を主催者ひとりに集中させない設計にあります。半年以内にこの分散ができないと、主催者の異動・繁忙・退職のいずれかでコミュニティが止まります。実務としては、以下の役割を 3 回目以降から常連に振り分けます。

会場担当: 毎回の予約・設営
記録担当: 議事録・写真撮影
広報担当: 次回告知・参加者募集
新規開拓担当: 初参加者の招待・接続

最初は主催者が全部抱えても構いませんが、引き継ぎ可能な状態を半年以内に作ることが Persistence の到達点です。属人化したまま 1 年を超えると、後から仕組み化するコストが急激に上がります。

---

7. ステップ 5: 連携拡張（L）

社内に閉じない接続点の作り方

ステップ 5 の論点は、外部との接続点を作ることです。社内だけで閉じたコミュニティは、半年から 1 年で「内輪化」「マンネリ化」「視野狭窄」のいずれかに陥ります。外部接続点とは、他部署・関連会社・取引先・社外コミュニティ・地域団体・大学・自治体など、コミュニティの外側にある人や組織とのつながりです。

他部署・関連会社・地域・大学との接続

接続点を作る具体的な方法は以下です。

ゲスト登壇: 他部署・関連会社の人を毎回 1 名招く
共催イベント: 半年に 1 回、別コミュニティと共同開催
訪問企画: 取引先・大学・地域団体のオフィスや拠点を訪問
クロスポスト: 社外コミュニティに自社メンバーが登壇する／その逆

みやこでIT は京都市役所・京都大学・京都リサーチパーク・京都経済センターなど地域のハブ機関と継続的に接続しており、参加者は「出ると京都の IT 関連の動きが俯瞰できる」と認識します。

単独運営から「ハブ」への進化

外部接続点が複数できると、社内コミュニティは「単独運営」から「ハブ」に進化します。ハブとは内側と外側の人・情報・案件機会を中継する装置で、社内に閉じたままでは生まれない複数種類の価値が同時に発生する状態を指します。

---

8. 進化の視点（Evolution）

個人 → コミュニティ → プラットフォームの 3 レイヤー

立ち上げて終わりではなく、コミュニティは 3 つのレイヤーで進化します。

個人レイヤー: 主催者個人の関心・活動として立ち上がる段階
コミュニティレイヤー: 役割分担と継続が確立し、組織として認知される段階
プラットフォームレイヤー: 事業・採用・地域接点の場として複数の事業プロセスに組み込まれる段階

立ち上げ初期は個人レイヤーに留まりますが、半年から 1 年でコミュニティレイヤーに移行し、2〜3 年でプラットフォームレイヤーに到達することが標準的な進化ルートです。

プラットフォームレイヤーで生まれる機能

到達後のコミュニティは、以下のような機能を持ちます。

事業のシード発掘: 議論から新規案件が定期的に立ち上がる
採用ブランディング: 招待された候補者の入社決定率が上がる
取引先との関係深化: 通常業務と別の文脈で取引先と接続し、案件機会が広がる
地域・社会との接点: CSR・地域貢献の文脈で外部から認知される
社内人材の育成・抜擢: 活躍した人材が事業部の重要ポジションに登用される

これらは一朝一夕には生まれず、5 ステップを着実に踏んだ後に Evolution の視点で運営し続けることで生まれます。

みやこでIT 7 年 147 回で観察した進化のパターン

みやこでIT 自体も、この 3 レイヤーを経て進化してきました。最初の 1 年は飯田個人の関心として動いていた個人レイヤー、2 年目から 4 年目までは役割分担と月次開催の固定化が進んだコミュニティレイヤー、5 年目以降は地域企業・自治体・大学との連携拠点として機能するプラットフォームレイヤーに到達しています。社内コミュニティもこの進化パターンを参照することで、5 ステップの先にある見取り図を持って運営できます。

---

9. 失敗パターンと回避策

社内コミュニティ立ち上げの失敗パターンには、再現性があります。代表的な 4 パターンと、欠けている柱を整理します。

パターン 1: 「誰がコミットするか」が不明瞭

主題は決まったものの、運営の中心になる人が定まっていないパターンです。立ち上げ会議では複数人が手を挙げても、いざ動き出すと「誰が次の日程を決めるのか」「誰が会場を予約するのか」が宙に浮き、初回の前に立ち消えになります。欠けている柱: M。回避策は、立ち上げ初期に主催者 1〜2 名と常連候補 2〜3 名を実名で確定させ、それぞれが負う役割を最初の開催前に書面化することです。

パターン 2: 主催者依存

主催者が全部抱え込み、3 回目以降も役割分散が進まないパターンです。欠けている柱: P。回避策はステップ 4 で示した役割分担を半年以内に常連へ引き継ぐことです。

パターン 3: 単発イベント化

毎回別テーマ・別参加者で、開催と開催の繋がりがないパターンです。欠けている柱: P + M。回避策は、月次開催の固定と常連の役割設計を最初から組み込むことです。

パターン 4: KPI 設定が浅い

「参加者数」だけを KPI にして、新規事業創出・採用効果・離職率改善などの本質的な指標を見ていないパターンです。半年で「効果が見えない」と判断され予算が打ち切られます。欠けている柱: L + Evolution。回避策は、立ち上げ時から「3 年後にプラットフォームレイヤーに到達する」前提で複数 KPI を設定することです。

---

10. 診断シート（5 問チェックリスト）

立ち上げ中・運営中の社内コミュニティが TEMPLE モデルに沿って機能しているかを Yes/No で診断します。3 つ以上 No が出た場合は、欠けている柱から見直してください。

Q1. 主題を 1 文で書けるか（T）
Q2. 同じ会場・曜日・時間帯で 3 ヶ月以上の月次開催が続いているか（E + P）
Q3. 主催者以外に明示的な役割を持つ人が 3 名以上いるか（M + P）
Q4. 他部署・取引先・社外コミュニティ・地域団体のいずれかと、定期的な接続点があるか（L）
Q5. 次回開催 1 週間前に、主催者が参加見込み数を概ね把握できているか（P）

---

11. まとめ

社内コミュニティの立ち上げは、社外コミュニティ運営の知見を借りると立ち上がりやすくなります。T・E・M・P・L の 5 ステップを順に踏むことで、半年後には最低限の構造が整います。その先には、Evolution の視点で個人レイヤーからコミュニティレイヤー、プラットフォームレイヤーへと進化させる道筋があり、到達後は事業・採用・地域接点の複合装置として機能します。

立ち上げ初期に最も重要なことは、6 柱を最初から意識した設計を行うことです。あとから柱を追加しようとすると、既に固まった運営パターンを変える必要があり、難易度が大きく上がります。立ち上げ時点で 6 柱を視野に入れ、5 ステップを着実に踏んでください。

---

TEMPLE モデルの 6 柱・自社適用 5 ステップ・診断シートを 「TEMPLE モデル：7年147回コミュニティ運営フレームワーク」 に詳細にまとめています。社内コミュニティの立ち上げ・事業開発・組織開発をご検討の企業の方は、ぜひダウンロードしてご活用ください。