はじめに

2025年11月、私は「58ハッカソン@関西学院大学」に出場しました。結果から言うと、プロジェクトは完遂できず、私は宿で倒れて救急搬送されるという、エンジニア人生で最も過酷な経験をしました。

幸い身体に大きな異常はありませんでしたが、この失敗から得た「マネジメント」と「セルフケア」に関する教訓は、全てのエンジニアに共有すべき重いものだと感じています。

チーム構成と技術選定

チームは5人構成で、技術スタックは以下のように選定しました。

メンバー構成:
- 筆者: PM、テックリード、FEチームリーダー、メイン実装
- Aさん: FE（スタイリング苦手）
- Bさん: BEリーダー、メイン実装
- Cさん: BE、デザイン
- Dさん: BE
技術選定:
- Backend: Flask (メンバー3人がPythonを使えたため)
- Frontend: Tailwind CSS + Alpine.js (学習コスト低減のため)

JSを書けるのが自分一人、Git未経験者が複数人という状況下で、私は「自分が動けばなんとかなる」という過信を抱いたままスタートを切りました。

ハッカソン期間中、私の心身は段階的に蝕まれていきました。

診断結果は「内科的異常なし」。精神的な極限状態による身体のシャットダウンでした。

本来、PM・テックリード・実装者の役割は分担すべきものです。私はこれらを一人で抱え込み、コンテキストスイッチのコストを無視しました。「自分がやった方が早い」という思考は、チームを「自分がいなければ何も進まない」というSPOF（単一障害点）に陥らせました。

これらは本来 CRITICAL ERROR として処理すべきアラートでしたが、私は WARNING 程度にしか捉えていませんでした。人間の身体は無限のリソースではありません。

チーム内にGit未経験者がいる中で、教育コストをスケジュールに組み込まず、機能削減の判断も遅れました。報連相の習慣がない環境では、進捗確認そのものが高コストなタスクとなり、さらに私のリソースを削っていきました。

この経験から、以下の3点を強く心に刻んでいます。

「機能削減」は勇気ある決断である
ハッカソンのような短期間プロジェクトでは、教育よりも「今あるリソースでできること」への機能削減を優先すべきでした。
撤退も戦略の一つ
「完走すること」を目的にしすぎた結果、健康という最も重要な資産を危険にさらしました。時には「諦める」という選択肢をテーブルに乗せる勇気が必要です。
身体のアラートを無視しない
エンジニアにとって、脳と身体は唯一のハードウェアです。ハードウェアが故障すれば、どんなに優れたソフトウェアも動きません。

プロジェクトとしては失敗でしたが、この経験を通じて「人間の限界」と「チームビルディングの本質」を学ぶことができました。

もし今、無理なスケジュールや属人化に苦しんでいる方がいたら、私の二の舞になる前に、一度立ち止まって「機能削減」や「役割分担」を検討してみてください。

健康な身体があってこその、楽しい開発です。