まろんのブログ 
これは FUN Part3 Advent Calendar 2025 の記事です。
どうも、まろんです。
個人開発芸人を自称している変人です。
Part1でも記事を書いているので、そちらもぜひ読んでみてください。
保守性とか知らん。カスの構成で個人ブログを構築した | まろんのブログ
カスの構成と称して Vite + Raw HTML / Express を使い、保守性を無視して個人ブログを勢いで作った話。
まろんのブログ
12月はアドカレの季節であるとともに、p2hacks(学内ハッカソン)の季節でもあります。
そこで今回は、チーム開発において大切なことについて、私が今まで考えてきたこと(持論)を纏めるついでに語ります。
なお、ここでの話は私の経験ベースの結論であるため 「ハッカソンアンチ」 の戯言としてご理解いただける方のみこの先にお進みください。
チーム開発の経歴と「アンチ」になった理由
私は高校生の頃に本格的にプログラミングを始め、いくつかのチーム開発やハッカソンに携わってきました。規模感としては3〜8人ほどの中小規模チームがメインでした。
担当は UI/UXデザイン、フロントエンド、バックエンド、SNS Bot開発、OSS開発など。
未来大に入ってからは、高度ICT演習や開発アルバイトにも参加しています。
特にハッカソンではフロントエンドエンジニアとして参加することが多く、夏休みや10月の高度ICT演習関連などで、4〜5人のチーム開発を経験してきました。
いつぞやにバックエンド担当が消えてフロントエンドとバックエンドの両方を担当したこともありましたが。
そんな中で気付いてしまったことがあります。
それは、Cheapな個人開発勢が集うチームは、当然、烏合の衆であることがほとんどである という事実です。
個々の技術力がどれだけ高くても、チームとして機能しなければ意味がない。
そんな当たり前の事実に打ちのめされ、己の精神の屍を積み上げるたびに、私の中に「ハッカソンアンチ」としての自我が芽生えていきました。
私にとってチーム開発への不満は、技術そのものより「人間関係やマネジメントの不和」に起因します。これらを言語化し、過去の自分への戒めと、今後の誰かのチーム開発のためも兼ねてここに供養します。
1. プロジェクトマネージャーは「下手」であってはいけない
プロジェクトマネージャー(以下「PM」)とは、チーム内の役割分担、タスク管理、意思決定を行う中枢的な存在です。
基本的にハッカソンでは、発起人であるリーダーがPMになることが多いです。特にハッカソンでは「言い出しっぺ」であるリーダーがPMを兼任すべきだと私は考えます。
別のメンバーがPMになる場合、リーダーとPMが持つ思想や情熱にズレが生じ、「解釈違い」が絶えないままプロジェクトが破綻するケースが多いからです。
さて、PMが「下手」なプロジェクトは十中八九失敗します。
ここでの「下手」には二つの意味があります。
それは 「ヘタ」 と 「シタテ」 です。
PMが「ヘタ」なチーム
これはシンプルに機能不全です。
指示が曖昧、タスクの依存関係が見えていない、進捗管理がザル……
ハッカソンにおいては、「何を作るか」を決めるまでの段取りが悪く、メンバーの意見をまとめきれなかったり、汲み取りきれずに雑音として処理してしまうケースがこれに当たります。
PMが「シタテ」なチーム
より深刻なのはこちらです。これは心理的な弱さに関係します。
「メンバーに嫌われたくない」「忙しそうだから悪いな」と遠慮し、指示が出せない。
あろうことか、「遅れているメンバーに催促するのが申し訳ない」と、PM自身がタスクを巻き取り始めてしまうのです。
これは優しさではありません。チームを崩壊させる甘い毒です。
「シタテ」にならないためには、精神論だけでなく目視できるツールで殴りましょう。GitHub ProjectsやBacklogでタスクを可視化し、「チケットが滞留している」という事実を突きつけて、メンバーが各々タスクを巻き取ることを強制するのです。
これら「下手」なPMが支配するチームでは、開発速度の低下、クオリティの妥協、そして何より「楽しくない」という 嫌な体験 だけが残ります。
Tip: 曖昧な指示出しは「呪い」
特に「下手」なPMとのやり取りで、私が最も嫌悪感を覚えるのが 思考と言語化を放棄(丸投げ)した指示 です。
もしあなたがPMで、以下の言葉を口癖にしているなら、今後のメンバーとの関係のためにも、今すぐ改めてください。
「ここやっといて」
「いい感じにお願い」
「とりあえず任せる」
それはメンバーへの信頼ではなく 「職務怠慢」 です。
PMの仕事である「明確な指示」が出せないなら、マネジメントの席に座るべきではありません。適材適所。
「解像度の低い言葉」は、受け取り手の時間を奪い、精神を削り、死んだプロダクトを生み出す 「呪い」 です。
想像してみてください。
外部連携の実装で「いい感じにやっといて」と言われ、仕様も不明なまま手探りで実装し、共有すると「やっぱイメージと違うから直して」と言われる絶望を(実話)。
その無駄な学習コストと徒労感は、トラウマとして残ります。
PMに必要なのは、マネジメント手法やツールの知識以上に、「好かれようとしない強さ」と「摩擦を恐れない覚悟」 です。短期間で合意形成を行うファシリテーション能力を学ぶことこそが正義です。
2. 「意見」は出して「エゴ」は出さない
しかし、PMが「下手」だからといってあなたが何もしないなら、それはただの他責思考です。
PMはあくまでマネジメント(管理)をするのが仕事であり、0から1を生み出すのはチーム全員の仕事です。
これは主にハッカソンの開発メンバー(特に個人開発をしていて技術に自信がある人)に向けた話です。
技術選定や議論の場で、あなたは 「意見」 を出していますか？ それとも 「エゴ」 を垂れ流していますか？
Tip: あなたの発言は “Need” か “Nerd” か
会議で口を開く前に、自分の胸に問いかけてください。それはチームの Need ですか？ それともあなたの Nerd ですか？
-
「意見」 = Team’s Need(チームの必要性)
- 「このUIはユーザー体験を損なうから修正すべき」
- 「期間内に終わらせるなら、枯れた技術を使うほうが安全だ」
→ ベクトルが 「プロダクトの成功」「チームの利益」 に向いている発言。
-
「エゴ」 = Just a Nerd(ただの技術オタク)
- 「普段使ってるマイナーなこの技術を使いたい」
- 「俺がこの構成で書きたいからこれにする」
→ ベクトルが 「個人の承認欲求」「技術的自己満足」 に向いている発言。
そんなに「自我」を出して自分好みの技術スタックで俺TUEEEしたいなら、部屋に篭って個人開発をしていればいいのです。誰もあなたを責めませんし、その方がチームの平和は保たれます。
チーム開発という場において求められるのは、「Nerd(技術オタク)」としてのこだわりではなく、チームにとっての「Need(必要解)」です。
この一文字の「ズレ」が理解できないなら、どれだけ技術力があろうとあなたは必要のないミジンコと化します。
3. 「良い」個人開発勢と「悪い」個人開発勢
個人開発勢にも様々います。OSSのコントリビューターであったり、個人的な趣味としてひっそりプライベートリポジトリを積み上げている人だったり。
ここでチーム開発において「地雷」となるのは、OSS開発の作法を知らない「悪い」個人開発勢 です。
OSSの開発作法と、チーム開発での作法は非常に似ています。
彼らに欠落しているのは、「他人の環境でも、自分と同じように動くか？(再現性)」という想像力、いわばエンジニアとしての 「配慮(=優しさ)」 です。
自分ひとりのPCで動けばそれでいい。そんな普段の「オレオレ環境」のコードは、チーム開発においては役に立ちません。普段からOSSに触れ、顔の見えない誰かにコードを使ってもらう経験がないため、「他人が自分のコードを実行する」という視点がすっぽり抜け落ちているのでしょう。
Tip: 独りよがりな開発を避けるチェックリスト
OSSの開発経験がない、あるいは浅いエンジニアは、平気で他人の時間をドブに捨てさせるコードを共有します。以下のような行動に心当たりがあるなら、チーム開発をもっと学ぶべきです。
- 依存関係の秘匿: Python等において、
requirements.txt/Pipfileや仮想環境用のコンフィグを共有しない。 - パッケージの蜃気楼:
package.jsonに存在しないパッケージが使用されている(ローカルマシンにグローバルインストールされているパッケージを無意識に使用している)。 - 古文書README: 再現性のない手順しか書いていない薄っぺらいREADMEや、難解すぎて読ませる気のないドキュメント。
- セットされていないセットアップ: セットアップ手順、起動コマンド、環境変数の設定(
.env.example)を共有しない。
「動くコード」を書くことと、「誰でも動かせるコード」を書くことは違います。
「私の環境では動きました」は、チーム開発では通用しない ということを肝に銘じてください。
さいごに
ここまで散々辛辣に書き連ねてきましたが、これらはすべて私が過去に経験した「失敗」や「痛み」から学んだ教訓です。
「ハッカソンアンチ」にならないためには、技術力以前に「チームでモノを作る」という当たり前の事実に真摯に向き合う必要があります。
隣にいるメンバーへのリスペクト、未来の自分や他者への配慮、そしてプロダクトづくりのモチベーション。これらが欠けたとき、ハッカソンはただの「苦行」へと成り下がります。
これからチーム開発に挑む皆さんが、「良い」チームを作り、素晴らしいプロダクトを生み出せることを願っています。
そして、終了後に「いいハッカソンだった」と思えますように。
それでは、良いハッカソンライフを！
さて、アドカレの予定ですが、
本日は、
Part1は シルロナ さんによる UnityとClaude Codeの話 です！
Part2は オリーブ さんによる 創作物のクオリティを高めるための基本的なアプローチ です！
明日は、
Part1は すすず さんによる ハッカソンだけで終わるのはもったいないよという話 が書かれるそうです！
Part2は HY/YUKA による FUN-WINEのラベルデザインについて投稿予定 が書かれるそうです！
Part3は 未定です！