Lessons from Running a Regional IT Community: What 153 Kyoto Events and 623 Members Showed About Continuing (2026)

Key points (30 seconds)

- Conclusion: This article is a record of what a regional IT community in Kyoto went through between 2019 and 2026

- It changed across five phases: launch (2019), moving online (2020–21), differentiating by place (2021–23), becoming established (2024–25), and connecting outward (2026)

- The regional disadvantage is density; the regional strength is context. In some phases, place and experience became the differentiator

- Both what worked and what did not are recorded here. The same order will not necessarily work elsewhere

- The definitions of the perspectives (the TEMPLE model) are collected in their own article

It has been 7 years since we started an IT engineer community outside the largest cities. 153 events have been held, and connpass membership has gone from two people to 623.

This article organizes what worked and what did not along the way. It is written for people who want to start a community in their own region and for those already running one.

---

Why we started an IT community in Kyoto

In 2019, Kyoto had almost no setting where IT engineers could gather informally.

• Few IT study groups
• Contact between engineers closed inside their employers
• An information gap with Tokyo and Osaka

The people were there but were not connected. Changing that required three things: a platform, recurring opportunities for contact, and a low psychological barrier.

Honestly, it began from a light motive: travelling to Osaka had started to feel like a chore, and if Kyoto did not have one, we would make one.

Seven years of change

Phase 1: Launch (2019)

• A monthly co-working session
• From that summer, a series of preparation sessions for the G-test certification, through which we met people who became core to the community
• Hypothesis: the need exists

→ This was a validation phase. Phase 2: Expansion (2020–2021)

• Moved online during the pandemic
• Participants from outside Kyoto increased
• Hybrid sessions began

→ We learned that participation appears to grow when geographic constraints disappear. Phase 3: Differentiation (2021–2023)

• Sessions at temples and machiya townhouses
• Work in the blockchain field
• International exchange with a Korean community
• The HACK+ grand prize

→ Differentiation through place combined with experience took hold. Phase 4: Becoming established (2024–2025)

• Regular sessions at KOIN
• Continuous use of Butsugenji, in Rokkaku Aburanokoji, Nakagyo-ku, Kyoto, from April 2024
• Integration as a Netsujo business activity
• Stronger collaboration with companies

→ The community's foundation became stronger. Phase 5: Connecting outward (2026)

• Held a lightning-talk event on AI agents in the former Kyoto Prefectural Assembly Hall, in collaboration with a public facility
• Ran an introductory quantum-computing series across three sessions, continuing a research-oriented theme
• Took part in Impact Kyoto Hackathon 2026 as a sponsor and gave the sponsor award to the team YARIGAI
• Published the Kyoto IT Community White Paper 2026, an analysis fixed as of July 17, 2026

→ The role is widening from borrowing venues to taking part in regional programmes. Whether this settles is not yet known.

How we organized this record (the TEMPLE model)

The perspectives we use when reviewing 7 years of operation are six: Theme, Environment, Members, Persistence, Local, and Evolution. From their initials we call it the TEMPLE model.

The definitions and the indicators to check for each perspective are collected in The TEMPLE model: six perspectives for designing internal and regional communities. Rather than repeat them, this article deals only with what actually happened in Kyoto.

Reading Phases 1 to 5 against the perspectives gives the following. This does not mean that applying them produces the same result; it means we could explain the phases afterwards.

What did not work is worth recording too. During the period when we set attendance numbers as a target, sessions that fell short felt like failures and wore the organizing side down. Sessions where we broadened the theme to reach a larger pool left first-time participants unable to judge what they could take away, and did not lead to repeat attendance. Neither was verified with figures; both are observations from the organizing side.

Current challenges, stated rather than avoided

• Involvement of IT engineers at regional companies is weak
• The route from the community to project work is weak
• Core operating roles are not distributed enough; dependence on individuals remains

For people who want to start a regional IT community, on realistic terms

Starting an IT community in a region is not that difficult in itself. What is genuinely difficult is still existing a year later.

1. First, create existence on connpass or similar

The first thing to do is not to build a perfect programme. It is to reach a state where people outside can recognize that a community on this theme exists in this region.

What matters is creating a place where event information is continuously visible. Being unknown is less damaging than a state in which nobody can tell whether you are still running.

2. Choose a venue you can keep using

In a region, a venue can become the brand. Having a usual place gives participants a psychological base.

What to look at when choosing: whether people can reach it from the station without strain, whether it keeps the participation fee low, whether the organizer can keep borrowing it without psychological cost, and whether it works with a small group.

3. Start the first event as a co-working session, without over-preparing

A co-working session is simple. At the extreme, it works with only a place and a time settled. In a region where the pool is small and new arrivals are limited, that low load matters greatly.

4. Do not read too much into the first attendance figure

Three people is enough if there is real conversation and people want to come again. In a region, whether the same person comes a second and third time matters far more than how many attend once.

5. Set monthly as the standard you keep

Trust in a community is the predictability of "it will probably be on again next month". Monthly is enough; what matters is not stopping.

6. Use social media as a device for building trust

People who are undecided do not register immediately. They look at past posts to see who attends and whether beginners are welcome. Social media works less as advertising than as a device for building trust.

7. What really matters is passing the walls at 10, 30, and 100 events

After ten events, it is finally seen as more than a coincidence. After thirty, it starts to be recognized as a fixture in the region. By the time it passes a hundred, the credibility itself has become an asset.

Summary

After 7 years, the three things we consider to have worked in a regional community are these.

• Spend time on the design that brings a first-time participant back, rather than on recruiting new people continuously
• Do not stop the monthly rhythm. Predictability becomes trust
• Connect place and regional context to the theme

The experience of writing code in a Kyoto temple works because of the Kyoto context. We do not think that carrying the same form to another region produces the same result. Read it on the assumption that it will be rebuilt around the assets that region has.

Come and see one

Attending once is sometimes faster than reading. Upcoming dates are published on the events page. If this would be your first time, the first-time guide describes the flow of a session. If you are interested in providing a venue or co-hosting, see collaboration and sponsorship.

Related articles

• Regional communities differ through theme design (TEMPLE-T)
• When the venue becomes the brand (TEMPLE-E)
• The TEMPLE model: six perspectives for designing internal and regional communities
• What co-working sessions do: three reasons focus, connections, and learning rhythm improve
• Fifteen IT engineer communities worth knowing
• How to build an IT engineer community: starting with three people on connpass
• Seven common failures in community operation

Related links

• Miyako de IT official site
• connpass
• Netsujo Inc.