はじめに
「野良参加」とは、事前にチームを組まずに1人でハッカソンに申し込み、当日決められた初対面のメンバーと開発すること。友達と参加するのとは全く違う難しさがある。
5回の野良参加で、うまくいったチーム・空気が悪くなったチーム両方を経験した。その中で見えてきた「ギスギスしないコツ」を共有したい。
1. なぜ野良ハッカソンはギスギスしやすいのか
まず前提として、ギスギスが起きやすい構造を理解しておく。
| 要因 | 説明 |
|---|---|
| 時間的プレッシャー | 短期間で成果物を出す焦り |
| スキル差 | 経験者と初心者が混在 |
| 期待値の違い | 勝ちたい人、学びたい人、交流したい人 |
| 作業スタイルの違い | 夜型/朝型、計画派/即興派 |
| 初対面の遠慮 | 言いたいことが言えない→不満が溜まる |
ギスギスの正体は「期待値のズレ」と「コミュニケーション不足」。 これを意識するだけで対処しやすくなる。
2. チーム結成時のコツ
2.1 最初に目標を全員で共有する
- 「優勝を狙いたい」
- 「新しい技術を試したい」
- 「完走できればOK」
- 「ポートフォリオに載せたい」
これを共有していないと、後半で温度差が生まれる。優勝を狙いたい人は「なんでもっと頑張らないの？」と思い、完走できればOKの人は「なんでそんなに焦ってるの？」と感じてしまい、不信感が生まれる。
2.2 開催期間中の予定を共有する
野良チームでありがちなのが、「この日は予定があって参加できません」が後から発覚すること。開発が佳境に入ったタイミングで主力メンバーがいなくなると、計画が崩壊する。
最初に全員の参加可能時間を確認しておく。 以下のようなテンプレートをDiscordに投げて、全員に書いてもらう。
【開催期間の予定】
参加可能時間を教えてください！
■ 2/14(金) →
■ 2/15(土) →
■ 2/16(日) →
■ 2/17(月) →
■ 2/18(火) →
■ 2/19(水) →
■ 2/20(木) →
■ 2/21(金) →
■ 2/22(土) →
■ 2/23(日) →
記入例：
■ 2/14(金) → 22時以降
■ 2/15(土) → 終日OK
■ 2/16(日) → 13時〜18時
■ 2/17(月) → 参加不可
これを見れば「土日にガッツリ進めて、平日は夜だけ」といった計画が立てられる。全員が揃う時間帯にミーティングや重要な意思決定を入れるなど、戦略的に動ける
3. アイデア出し〜話し合いのコツ
3.1 アイデアを否定から入らない
理由のない否定は、話し合いを停滞させるだけで意味がない。
悪い例：「それは難しいと思います」
これでは「なぜ難しいのか」がわからず、議論が前に進まない。相手も「じゃあどうすればいいの？」となり、空気が悪くなる。
否定するなら、必ず理由と代替案をセットで伝える。
良い例：「APIの制限があるので難しいかもしれません。代わりに〇〇はどうですか？」
理由があれば相手も納得できるし、代替案があれば議論が前に進む。
また、「でも」「だって」から話し始めると、内容に関係なく否定された印象を与えてしまう。まず受け止めてから意見を言う。
悪い例：「でも、時間かかりませんか？」
良い例：「面白いですね。ただ、実装に時間がかかりそうなので、スコープを絞りませんか？」
3.2 決定事項は「全員納得しているか」を確認する
議論が進むと、なんとなく決まった雰囲気になることがある。でも実は納得していない人がいると、後から「やっぱり違うと思ってた」と蒸し返しが起きる。
Discordのリアクション機能を活用する。 👍を押してもらうだけで、全員の意思確認ができる。発言しづらい人も、リアクションなら気軽に意思表示できる。
例：「技術スタックはReact + Amplifyで行きます。OKな人は👍押してください。意見がある人はコメントでお願いします！」
→ 全員が👍押したのを確認してから進める
これを習慣にするだけで「実は納得してなかった」が減り、ギスギスが起こりにくくなる。
4. 開発中のコツ
4.1 15〜30分に1回「今何やってる？」を共有
SlackやDiscordで軽く報告するだけでいい。
これがないと「あの人何やってるんだろう…」という不信感が生まれる。
4.2 Discordのチャンネルを分けてコミュニケーション導線を作る
1つのチャンネルで全部やると、情報が流れて追えなくなる。
#general → 雑談・休憩の連絡
#dev → 開発の進捗報告・質問
#design → デザイン関連の共有
#resources → 参考リンク・ドキュメント置き場
#decision → 決定事項のログ（後から見返せる）
特に #decision チャンネルは重要。「あれってどう決まったんだっけ？」を防げる。
チャンネルを分けることで、必要な情報を必要な人が追いやすくなり、「見落とした」「知らなかった」というすれ違いを減らせる。
4.3 コードレビューをしない
ハッカソンは時間との勝負。コードの品質を指摘しても、直す時間がない。指摘された側は「じゃあどうしろと」となり、指摘した側は「なんで直さないの」となる。
悪い例：「この書き方よくないですね、直してもらえますか」
良い例：動けばOK。リファクタリングは後でいい（というか多分しない）
品質は後で直せるが、動かないデモは発表できない。
4.4 相談しやすい環境を作る
野良チームでは「迷惑かけたくない」「こんなこと聞いていいのかな」と遠慮しがち。その結果、1人で1時間ハマった挙句「それ、最初から聞いてくれれば5分で解決したのに」となることが多い。
相談しやすい環境を作るには、チーム全体でルールを決めておくのが効果的。
質問・相談ができるテキストチャンネルなどを用意しておくとよい。
「聞いていい」という空気があるだけで、相談のハードルは一気に下がる。経験者が「何か困ってることあります？」と定期的に声をかけるのも効果的。
4.5 休憩を一緒に取る
コードを書いていない時間に雑談することで、心理的安全性が生まれる。「この人はこういう人なんだ」とわかると、開発中も相談しやすくなる。
逆に、ずっと黙々と作業だけしていると、お互いが「話しかけていいのかな」と遠慮し合い、コミュニケーション不足でギスギスする。
「ご飯行きましょう」「ちょっと休憩しません？」
5. 終了後のコツ
5.1 終わったら「ありがとう」を言う
結果が良くても悪くても、初対面で短期間一緒に頑張った仲間。感謝を伝えることで、
お互い気持ちよく終われる。
野良参加の最大のメリットは「人脈が広がること」。SNSで繋がっておくと、次のハッカソンで一緒に組めるかもしれない。逆にギスギスしたまま終わると、その人脈は永遠に失われる。
「短い間でしたけど、ありがとうございました！」
6. それでもギスギスしたときは
正直、どうしても合わない人はいる。
- 自分の意見を絶対曲げない人
- 作業をしないのに口だけ出す人
- 約束した期限を何度も破る人
そういうときは 「こういう人が苦手ということがわかった」と割り切る。
苦手な人を言語化しておくことで、今後は自分の中で境界線が引けるようになる。「この人とは距離を取ろう」と早めに判断できるようになり、無理してストレスを溜めることがなくなる。自分を守れるようになる
まとめ
| フェーズ | コツ |
|---|---|
| 開始時 | 期待値とスキルを正直に共有 |
| アイデア出し | 否定しない、詳しい人に任せる |
| 決定時 | 全員の👍を確認してから進める |
| 開発中 | チャンネルを分ける、こまめに共有、15分でヘルプ |
| 発表前 | デモ優先 |
| 終了後 | 感謝を伝える |
ギスギスを恐れず、どんどん野良参加してみてほしい。