Techサークルのプロジェクトはなぜ失敗するのか
〜7つの開発を回して分かった「成立するプロジェクトの条件」〜
はじめに
Techサークルを運営していると、よくこんな話を聞きます。
- 「プロジェクト立ち上げたけど、途中で消えた」
- 「最初は盛り上がったのに、誰も来なくなった」
- 「結局、代表一人で終わった」
正直に言います。
これは普通に起こります。
私たちのTechサークルでも、これまで 7つのプロジェクト を回してきましたが、
すべてが順調だったわけではありません。
この記事では、
- Techサークルでプロジェクトを成立させる方法
- 学生 × 実案件（企業・外部連携）のリアル
- 実際に「失敗したプロジェクト」から学んだこと
を、できるだけ生々しく書きます。
このサークルの前提
- プロジェクト数：7個
- 内容：
- バスの時刻表作成
- HP作成
- 学内掲示板作成
- ゲーム制作
- 観光DXプロジェクト など
- 規模：1プロジェクトあたり最大6人
- 期間：
- 期限あり：2ヶ月前後
- それ以外：長期でゆるく継続
基本は プロジェクト駆動型サークル です。
プロジェクトはこうして始まる
① アイデアはDiscordに投げる
新しいプロジェクトは、だいたいこんな感じで始まります。
「こんなの作ってみたいんだけど、興味ある人いる？」
Discordに投げて、反応を見る。
説明会も資料も最初は作りません。
② 代表者は名乗り制
ここが一番重要です。
- 代表者（責任者）は名乗り制
- 代表者がいないプロジェクトは、基本的に没
理由は単純で、
代表者がいないプロジェクトは、100%止まる
からです。
③ 「この人なら回る」代表者の条件
実際に回る代表者には、共通点があります。
- 人が集まらなくても「自分一人でもやる」覚悟がある
- タスクを言語化して人に振れる
- 期限を意識している
逆に言うと、
「誰かやってくれるだろう」型の代表はほぼ失敗します。
メンバー集めとチーム形成
募集方法
- Discordで声かけ
- 定例で募集
かなり原始的ですが、これで十分です。
人が集まらなかったら？
割り切っています。
- 代表者1人で続行
- もしくは没
中途半端に続けるより、
早めに終わらせる方が全体に優しいです。
初心者が入ってきたとき
基本方針はこれだけです。
「できるタスクを渡す」
設計・実装・資料作成・調査など、
関わり方はいくらでもあります。
タスクと進捗管理のリアル
タスク管理
- Notion を使用
- タスクはできるだけ細かく
進捗確認
- 毎週の定例
- Discordで適宜
「進捗どう？」を
聞ける空気を残すことを大事にしています。
タスクが止まる典型パターン
一番多いのはこれです。
みんな忙しくて、手が回らなくなる
学生なので、これは避けられません。
だからこそ、
- 期限を切る
- 無理なら止める
- 代表者が判断する
この割り切りが必要でした。
失敗談：観光DXプロジェクト
一番大きな失敗は 観光DXプロジェクト でした。
何が起きたか
- 先方とのやり取りの速度が遅い
- フィードバックが返ってこない
- お金が絡み、衝突が起きやすい
結果として、
メンバーのモチベーションが徐々に下がっていった
という、かなり典型的な失敗をしました。
失敗から学んだこと
この失敗以降、ルールを変えました。
- 代表者（PM）を明確に決める
- 判断はPMに従う
- 「やる」と決めたら、やる
実案件ほど、
民主制は向いていないと痛感しました。
成果はどう可視化しているか
プロジェクトの成果は、主にこの2つです。
- デモ
- 記事化
「完成度100%」よりも、
外に出せる形にする
ことを優先しています。
プロジェクトが回る最低条件
最後に、これだけ守れば回るというルールを3つ。
- 代表者がちゃんと動く
- メンバーもちゃんと動く
- 期限を定める
かなり当たり前ですが、
守られないと本当に回りません。
おわりに
Techサークルのプロジェクトは、
- 失敗して当たり前
- 止まって当たり前
- 人が抜けて当たり前
だと思っています。
大事なのは、
失敗から学び、次で同じ失敗をしないこと
次回は
👉 「Techサークルで“ガクチカ”が生まれる瞬間」
について書く予定です。