月1回を「絶対に守る」だけでコミュニティは続く — 継続の仕組み化

ITエンジニアコミュニティの多くは、立ち上げから1年以内に更新が止まります。

connpassで「最終更新が2年前」のグループを見かけたことがあるはずです。あれは珍しいことではなく、ほとんどのコミュニティが辿る道です。

この記事では、京都で8年148回のイベントを継続してきた「みやこでIT」が実践している、継続のための仕組みを整理します。これはTEMPLEモデルのうち、P — Persistence（継続） を深掘りした実践編です。

---

なぜコミュニティは止まるのか

コミュニティが止まる理由は、だいたい同じです。

1. 主催者が疲れた — 毎回の企画・集客・運営を一人で背負い、消耗

2. 参加者が来なくなった — 最初の勢いが落ち、モチベーション低下

3. やる意味が分からなくなった — 数字も成果も見えず、「何のためにやっているのか」

4. 生活が変わった — 転職・引越し・家庭の事情で物理的に続けられなくなった

このうち、1と3は仕組みで防げます。

---

継続のための5つの仕組み

1. 月1回を「基準」にして止めない

コミュニティにおける信頼とは「来月もやっているだろう」という予測可能性です。

みやこでITは月1回を最低基準にしています。多い月は4回開催することもありますが、月1回は何があっても開く。この基準を8年間守ってきました。

10回続けると「たまたまではない」と見なされます。30回で「定着した」と認識されます。100回を超えると「信用そのもの」になります。

2. KPIを置かない

これは反直感的ですが、効果があります。

「参加者10名以上を目標にする」と決めると、8名だった回を「失敗」と感じてしまいます。毎月の開催が「目標達成/未達成」のゲームになると、主催者は消耗します。

みやこでITは参加者数の目標を設定していません。3名でも開催します。3名なら3名の良さがあり、濃い会話ができます。

3. 開催を義務にしない

「毎月やらなければならない」と考えた瞬間に、楽しさが消えます。

みやこでITが8年続いた理由は「面白いからやっている」です。「自分たちで運営したら面白そうだ」と考えて始めたことが、期待通りに面白かった。だから「来月はこんなことしようかな」と楽しみながら企画しています。

義務化は、短期間なら効果がありますが、3年を超える継続には向きません。

4. もくもく会を基本形にする

もくもく会は運営負荷が最も低いイベント形式です。

登壇者不要
資料作成不要
司会進行は最小限
会場と日時を決めれば開催可能

凝ったイベントを毎月企画しようとすると、3ヶ月で疲弊します。もくもく会を月1回の基本形にして、余力がある月だけ交流会やLT会を追加する。この設計が8年を可能にしています。

5. 運営を分散する

一人で全部やると、その人がボトルネックになります。

みやこでITは8名の運営メンバーがいます。全員が毎回関わるわけではなく、「この回は自分が幹事をやる」と持ち回りで担当します。

幹事が変わるとイベントの雰囲気も少し変わります。これが単調さを防ぎ、参加者にとっても新鮮さになります。

---

「10回・30回・100回の壁」

継続には段階的な壁があります。

10回の壁（約1年）: ここを超えると「たまたまではない」と認知される。最初の山。connpassグループにメンバーが蓄積し始める。

30回の壁（約2〜3年）: 地域の中で「あのコミュニティ」として定着する。外部からの共催依頼が入り始める。

100回の壁（約5〜6年）: 信用そのものが資産になる。会場オーナー、自治体、企業が「ここなら安心」と判断する根拠になる。参加者ネットワークが自走し始める。

みやこでITは148回。100回の壁を超えたことで、佛現寺との7年継続利用、京都府WGへの参画、Digital Nomad Kyotoとの共催など、信用ベースの連携が生まれています。

---

まとめ

コミュニティの継続は、気合ではなく仕組みで実現します。月1回を基準にして止めない。KPIを置かない。義務にしない。もくもく会を基本形にする。運営を分散する。この5つを守れば、10回・30回・100回の壁は越えられます。

詳細は代表紹介、お問い合わせはNetsujo株式会社まで。