TEMPLEモデル｜社内・地域コミュニティ設計の6つの観点

この記事の要点（30秒で読める）

- 結論: TEMPLEモデルは「みやこでIT」の運営経験を6つの観点へ整理した仮説モデルで、当てはめれば成功する法則ではありません

- 6つの観点はTheme・Environment・Members・Persistence・Local・Evolutionです

- 観点ごとに「確認する指標」を付けています。答えではなく、判断に使う問いとして読んでください

- 社内コミュニティにも地域コミュニティにも当てはめられますが、当てはめない方がよい状況もあります

- 土台は京都での7年・開催済み153回の運営で観察した出来事です

TEMPLEモデルは、京都のITコミュニティ「みやこでIT」の運営経験を、地域・社内のコミュニティを考えるための6つの観点へ整理したものです。Theme、Environment、Members、Persistence、Local、Evolutionの頭文字から名づけました。

このモデルは、当てはめれば成功する法則ではありません。2019年から京都でコミュニティを運営するなかで、続いた企画、止まった企画、参加者が定着した場、内輪で閉じた場を振り返り、判断に使える問いとして整理した仮説です。ほかの運営者が、自分の組織や地域の条件を考えるための下敷きとして使ってください。

---

TEMPLEモデルの6つの観点

6つは手順ではありません。立ち上げのときはT・E・Mの順で決めることが多いものの、運営が始まったあとはどの観点からでも点検できます。以下、観点ごとに「何を決めるか」と「あとで確認する指標」を並べます。

---

T｜Theme — 何を一緒に考える場か

テーマは、イベントのタイトルではありません。次の点が決まって初めてテーマになります。

• 誰の、どの関心を扱うか
• 一回で終わる話題か、継続できる問いか
• 参加者が自分の経験を持ち込めるか
• 専門性と参加しやすさのバランスはどうか
• ほかの場と何が違うか

「AI」「Web3」「キャリア」のような広い言葉だけでは、参加者は何を持ち帰れるかを判断できません。テーマは、問いへ変えます。

• AIエージェントへどこまで権限を渡すか
• 地域企業とITエンジニアがPoCを始める前に何を決めるか
• 初めてLTをする人が5分で何を話すか
• 量子力学を身体感覚と結びつけると何が見えるか

社内コミュニティでも同じです。「DXを進めるための場」「イノベーションを促進する場」は抽象度が高すぎて、参加者が自分ごと化できません。「半年後に各事業部のAI活用事例を持ち寄り、横展開できる形へ整理する場」のように、聞いた人が出るべき場かどうかを判断できる解像度まで落とします。

「みやこでIT」の場合は「京都のITとローカルの接続点を作る」と一文で書けます。この一文があるため、Webエンジニアもスタートアップ経営者も自治体職員も、自分に関係があるかを自分で判断できます。

確認する指標

• 初参加者が内容を理解できるか
• 継続開催できるか
• 登壇者や共同企画が増えるか
• テーマ外の勧誘が増えていないか

テーマ設計そのものの掘り下げは、地方コミュニティは「テーマ設計」で差が出るにまとめています。

---

E｜Environment — どの環境なら参加できるか

環境には、会場、時間、参加費、定員、雰囲気、設備、オンライン対応が含まれます。

京都のお寺や町家で開催するのは、写真映えのためではありません。日常の職場と異なる空間が、参加者の会話や記憶へどう影響するかを考えて選んでいます。「みやこでIT」は佛現寺（京都市中京区・六角油小路）を2024年4月から継続して使っており、本堂は外の音が入りにくいこと、山門をくぐって靴を脱ぐ動作が仕事モードの切り替えとして働くこと、お寺でコードを書く体験そのものが地域とITの接点を作ることの3点を理由と考えています（事例: 佛現寺）。

一方で、会場の魅力だけで運営は続きません。決めておく項目は次のとおりです。

• 駅からの距離
• 電源、Wi-Fi
• 暑さ、寒さ
• 音
• バリアフリー
• 未成年参加
• 撮影
• 飲食
• 緊急時対応
• 会場費と撤収時間

環境の良し悪しは、参加者の属性と企画目的によって変わります。社内で開催する場合も、いつもの会議室では業務モードが解除されにくいため、社外のレンタルスペース、社内カフェテリアの業後利用、取引先オフィスの訪問、節目のオフサイトなど、場所の選択肢を持っておくと空気が変わります。

確認する指標

• 申込後の参加率
• 初参加者の不安
• 会場トラブル
• 準備・撤収工数
• 継続利用の可否
• 会場とテーマの一致

会場を資産として扱う考え方は、会場がブランドになるで詳しく書いています。

---

M｜Members — 誰がどの役割で関わるか

参加者を全員同じ立場として扱うと、主催者へ負荷が集中します。役割を分けます。

主催者、企画担当、当日運営、登壇者、常連、初参加、会場提供、共催、スポンサー、記録・広報、次回企画者。

重要なのは、肩書を与えることではなく、小さな役割を渡すことです。受付、写真、タイムキープ、会場案内、レポート、次回テーマの提案など、参加者が無理なく関われる入口を作ります。

「2回目」を設計する

見落とされやすいのは、初回参加者へ2回目を促す仕組みです。離脱は初回参加の直後に最も起きやすく、母数が限られる社内や地方では、新規を集め続ける設計は数か月で息切れします。「みやこでIT」で続けているのは次の6点です。

• 参加のハードルを下げる: 参加費を高くしない
• 一人参加を前提にする: 一人参加歓迎を毎回明示し、主催者が最初の紹介役を担う
• 最初の5分で全員に声をかける: 受付時の30秒の会話が歓迎されている印象を決めます
• 帰り際に次回の案内を渡す: 口頭に加えて通知が届く導線を案内します
• 途中参加・途中退出を明示的にOKにする
• スキルレベルで排除しない: 各自が自分の作業を進めるもくもく会形式なら、スキル差が参加体験に影響しません

社内では「上司の前で本音を言いにくい」という懸念が出やすいため、冒頭のチェックイン時間、役職呼びを外す宣言、議事録の共有範囲の明示を毎回繰り返します。

確認する指標

• 運営者が一人に集中していないか
• 初参加者が再参加しているか
• 参加者から登壇者・企画者へ移る人がいるか
• 常連だけで閉じていないか
• 勧誘やハラスメントへ対応できるか

---

P｜Persistence — どの頻度と負荷なら続けられるか

継続は、意志の強さだけでは決まりません。決めるのは次の項目です。

• 開催頻度
• 準備工数
• 会場予約
• 集客期間
• 参加費
• 協賛
• 記録
• 主催者の生活
• 休止条件
• 再開条件

毎月開催が正しいとは限りません。テーマ型イベントは四半期、もくもく会は月次、交流会は季節ごとなど、形式ごとに周期を変えます。参加者が少ない回もあります。初期に人数が安定しないことを失敗と決めず、継続できる最小規模を先に定めます。

「みやこでIT」で置いている運用目安は3つです。普遍的な正解ではなく、当方の条件で機能してきた基準として読んでください。

• 月1回を基準にして止めない: 来月もやっているだろうという予測可能性そのものが信頼になります
• 参加者数のKPIを置かない: 10名以上を目標にすると8名の回を失敗と感じ、主催者が消耗します
• 開催を義務にしない: もくもく会を基本形にし、余力のある月だけ交流会やLT会を足します

開催と開催の間が無音になると、コミュニティは存在感を失います。当日中のお礼と次回告知、1週間以内の記録共有、次回1週間前のリマインドを回すと、参加者の頭のなかに開催が残ります。

会場・記録・広報・新規開拓といった役割は、早い段階で常連へ渡します。属人化したまま年単位で進むと、あとから仕組み化するコストが上がります。

確認する指標

• 年間開催数
• 主催者工数
• 一回あたり費用
• 無断キャンセル
• 継続参加
• 休止・中止の理由
• 運営者の交代可能性

止まり方の類型は、コミュニティ運営でよくある失敗7パターンに整理しています。

---

L｜Local — 地域の文脈とどう接続するか

地域性は、地名をタイトルへ入れることではありません。京都の場合は、寺院、町家、大学、行政施設、地域企業、文化、観光、学生、国際交流など、複数の資産があります。

地域資産を使う場合に確認する点は次のとおりです。

• 会場側にどの価値があるか
• 地域のルールを尊重しているか
• 役割と費用を明確にしているか
• 写真や広報の許可を得ているか
• 一回のイベント後も関係が続くか
• ほかの地域へそのままコピーしてよいか

京都で成立した企画が、別の地域で同じように成立するとは限りません。モデルは移植するのではなく、その地域の資産へ合わせて使います。

「みやこでIT」は現在14の団体・機関と関わりがあり、佛現寺（会場）、京都知恵産業創造の森（交流会共催）、Digital Nomad Kyoto（もくもく会共催）、大正大学京都アカデミア（会場）などが含まれます。いずれも当方から声をかけて始まった関係で、続いているものには相手側の目的（会場の認知、学生のキャリア接点、地域の技術人材の可視化など）が同時に成立しているという共通点があります。関係の作り方はコミュニティ連携ガイドと連携先・パートナーにまとめています。

確認する指標

• 地域組織との継続関係
• 会場の再利用
• 地域参加者
• 共同企画
• 地域側が主導する企画
• 成果の役割表記

---

E｜Evolution — 活動をどこまで広げるか

コミュニティは、規模を大きくする必要はありません。もくもく会からLT、勉強会、交流会、ハッカソン、産学連携、PoCへ広がる場合もあれば、定例会を小さく続ける方が価値のある場合もあります。

進化を考えるときは、活動を3つに分けます。

• 接点: 初参加しやすいイベント
• 関係: 継続参加、登壇、共同企画
• 価値化: 研究、採用、技術広報、事業、PoC、地域プロジェクト

接点から価値化へ無理に誘導すると営業色が強くなり、参加者の信頼を損ないます。参加目的と事業目的を分け、成果の帰属を明確にします。たとえば「みやこでIT」を通じた接点のあるメンバーのチームがHACK+2023で最優秀賞を受賞しています。受賞は主催者による評価であり、コミュニティの成果として書くことはしません。 チーム形成の経緯はHACK+2023の記録に譲り、この記事では断定しません。実運用や事業化の有無も述べません。こうした線引きを先に決めておくと、成果を語るときに帰属を盛らずに済みます。

確認する指標

• 継続参加
• 登壇・企画
• 共催
• 共同研究
• 採用接点
• PoC
• 派生プロジェクト
• 成果発生までの期間
• 役割と帰属

---

6つの観点をいつ使うか

運営中の場を点検する6問

• 主題を一文で書けるか（T）
• 会場と開催時間を、参加者の生活に合わせて選べているか（E）
• 主催者以外に、明示的な役割を持つ人がいるか（M）
• 次回開催の予定が、参加者から見て予測できる状態か（P）
• 外部（他部署・取引先・地域団体・他コミュニティ）との接続点があるか（L）
• 接点・関係・価値化のどの層にいるかを説明できるか（E）

答えられない項目が複数あるときは、その観点から見直します。すべてに答えられることが良い運営という意味ではありません。

---

当てはめにくい状況

次の条件では、TEMPLEモデルを当てはめる前に、コミュニティという形式が適切かを検討してください。

• 上司命令だけで参加させる
• 短期の営業リード獲得だけを目的にする
• 主催者以外が判断できない
• 予算や会場が単年度で終了する
• 行動規範や通報先がない
• 参加者データを過度に収集する
• 地域や会場の名前だけを利用する

これらは観点の設計以前の問題で、モデルを当てはめても解消しません。

---

「みやこでIT」での位置づけ

「みやこでIT」は2019年2月の第1回もくもく会から継続しています。現在の開催数や登録者数は活動統計ページで更新しており、2026年7月17日時点で固定した分析は京都ITコミュニティ白書2026で公開しています。数値は開催済みイベント数とconnpass登録メンバー数であり、実参加者の延べ人数ではありません。

TEMPLEモデルは、その数字から成功法則を導いたものではありません。運営の出来事と判断を振り返り、ほかの運営者が自分の条件を考えるための問いへ整理したものです。今後は観点ごとに、成功例だけでなく、失敗、費用、参加率、役割移行、当てはめられなかった事例も追記していきます。

---

関連記事

• 地方ITコミュニティ運営の教訓 — 2019年から2026年の記録
• TEMPLE-T: 地方コミュニティのテーマ設計
• TEMPLE-E: 会場がブランドになる
• コミュニティ運営でよくある失敗7パターン
• ITエンジニアコミュニティの作り方 — connpassで3人から始める手順
• エンジニア交流会が怖い人へ

一度見に来てください

読んで設計するより、動いている場を1回見る方が早いことがあります。「みやこでIT」のイベントは開催予定ページで公開しています。初めての方は初めての方へから、当日の流れを確認できます。