イベントを走り抜けた開発陣、全員一致で「一旦、全部作り直したい」と言い出す

学園祭や展示会などのイベントが無事に終了し、打ち上げの席で乾杯した直後。 疲れ果てたプリダンのエンジニアたちが口を揃えて放った一言がこれでした。

「……一旦、全部作り直したくない？」 「うん、わかる。ゼロから書き直したい」

何百組もの来場者が笑顔でシールを持ち帰り、システムは大きな停止もなく動いた。 外から見れば「大成功」のプロジェクトです。 なのに、なぜ開発陣は**「全破壊＆再構築」**の衝動に駆られてしまうのでしょうか？

現場で積み上がった「秘伝のタレ」たち

イベント直前の深夜、現場では「何が何でも本番までに動かす」という超法規的措置が連発されます。

• 「なぜか特定のタブレット解像度でのみズレるボタンを、!important とハードコードされたマージンで無理やり中央に合わせたCSS」
• 「WebSocketの切断検知が間に合わないので、定期的にPingを打ちまくって強引に再接続させるRustの突貫リトライループ」
• 「カメラのキャプチャがたまに固まるので、裏でこっそりOSコマンドを実行してUSBポートをリセットしているスクリプト」
• 「バージョン2とバージョン3の過渡期に生まれた、誰も消せない謎のフラグ変数 is_legacy_mode_v2_final_fix」

これらは本番の過酷な環境を生き延びるための**「戦友」**であり、泥臭い工夫の結晶です。 しかしイベントが終わってコードベースを冷静に眺めると、そこには怪物のようになったアーキテクチャが佇んでいるのです。

なぜ「作り直したい」と思うのか？

一度本番を経験したことで、開発当初には見えていなかった**「正解の姿」**が全員の頭の中に明確に浮かんでいるからです。

1. 状態遷移の境界線がわかった: 「撮影」「落書き」「印刷」のライフサイクルをどう設計すべきか、失敗したからこそ正解がわかる。
2. ハードウェアのリアルがわかった: プリンタの給紙タイミング、カメラの露出制御、照明の調光プロトコルなど、現場を踏まないとわからない要件が洗い出された。
3. 「今ならもっと綺麗に、もっと速く作れる」という確信がある: 初回は手探りだった技術スタック（Rust, TypeScript, MediaPipe）を、チーム全員が使いこなせるようになった。

「セカンドシステム症候群」の罠とどう向き合うか

ソフトウェア工学には有名な教訓があります。 「最初のシステムで成功した開発者は、2回目の開発で欲張りすぎて破滅する（セカンドシステム症候群）」。

全部を白紙に戻して理想のアーキテクチャを追求した結果：

• 開発期間が伸びすぎて次のイベントに間に合わない
• 動いていた泥臭いエッジケース対応（USBリセットなど）が抜け落ちて本番で死ぬ
• 結局また直前でパッチを当てて同じ怪物が生まれる

という未来は目に見えています。

私たちの決断：「破壊」ではなく「骨格の再定義」へ

議論の末、チームは「すべてを投げ捨てて作り直す」のではなく、「中核ロジックのRustライブラリ化（pri-dan-core）」 と 「UIのクリーンな分離」 を進める方針を選びました。

• 現場で培った泥臭いノウハウ（ハードウェア制御や印刷待ちロジック）は捨てるな
• その代わり、状態管理とデータフローの「背骨」だけを徹底的に美しく再設計する
• UIは何度でも作り直せるように疎結合にしておく

「作り直したい」という衝動は、エンジニアが成長した証拠です。 この衝動をエネルギーに変えて、プリダンは次世代のアーキテクチャへと進化を続けています。

次のイベントで稼働する「生まれ変わったUmix」を、どうぞお楽しみに！