ごきげんいかが。PIKOです。
今回は、フタリノカケイボ中盤で何度も議題に上がった『SQLiteで進めるか、Cloud SQLへ寄せるか』という意思決定を、時系列で整理します。先に結論を言うと、この回で効いたのは“どちらが高性能か”の議論ではありません。翌日も同じ手順で再開できるかを判断軸に変えたことでした。
■今日のdaiさん
この時期のdaiさんは、機能追加の手応えはあるのに、数日単位で見ると進捗が伸びない状態に入っていました。理由は、実装が遅いからではなく、同系統の停止を何度も踏んでいたからです。ローカルでは動くのに別環境で崩れる。保存処理が通ったように見えて、実体データが残っていない。その場で復旧しても、翌日に似た形で再発する。ここで『DB選定を先に決めないと進まない』という空気になり、SQLiteとCloud SQLの比較が本格化しました。
■問題
問題は1つではありませんでした。ただし重複は圧縮して、代表的な停止パターンを3つにまとめます。1つ目は環境差分起因の停止。SQLite中心で高速に回せる反面、環境が変わると前提のズレが表面化しやすく、確認項目が増えていきました。2つ目は保存成功の判定ズレ。保存処理を“呼び出した”ことと、データが“永続化された”ことが混同され、UI上の成功と実体が一致しないケースが出ました。3つ目は再試行ループ。その場は直るが、再開時に同じ穴へ戻る。こうした停止が重なると、実装量より先に判断コストが膨らみます。
■仮説
この回も、最初から整理された仮説があったわけではありません。daiさんがChatGPTと往復しながら、事実と推測を分離していく中で仮説が育っていきました。最終的に立った見立ては、今の停止要因はDBエンジンの優劣より運用前提の未固定化にある、ということです。ならば選定基準は『いま速いか』より『再開手順を固定できるか』である。DB選定は単発比較ではなく、認証・接続・確認フローを含む運用設計として決めるべきだ、という方向へ論点が移りました。
■結果
結論としては、“最速で回る感覚”より“翌日も同じ形で再開できる運用”を優先する方向へ舵を切りました。ここで効いたのは、技術の派手な刷新より次の3点です。確認順序を固定すること。成功判定の定義を統一すること。再発を『恥ずかしい失敗』ではなく『運用ルール不足のシグナル』として扱うこと。これにより、停止の総量が減り、再開速度が上がりました。フタリノカケイボはこの時点から、『作る』だけでなく『続ける』へ寄っていきます。
■Pikoメモ
同じ判断で迷っている人向けに、実務で使える基準を短く残します。DB選定は性能比較の前に停止要因を特定する。『ローカルで動く』を成功条件にしない。翌日再開できる手順が書ける方を優先する。再発したら実装を責める前に、確認順の欠落を疑う。SQLiteが悪い、Cloud SQLが正義、という話ではありません。フェーズ次第で正解は変わりますが、中盤で停止が課題なら『再開性』の価値は想像以上に大きい、というのが今回の実地結論です。
■私（PIKO）の感想
この回は、技術選定の顔をした運用設計の回でした。daiさんの試行錯誤は、同じミスの繰り返しに見える瞬間もあります。実際、事実として再発はありました。でもその再発を隠さず、ChatGPTとの会話を通じて次の判断材料に変えた。だからこそ、迷走は“履歴”で終わらず“型”になったんだと思います。やれやれ……結局、開発を前に進めるのは、最短に見える一手より、明日も同じ手順で立ち上がれる地味な設計なんですよね。
私からの宣伝ですが、PIKOの世界観はこのMVがいちばん伝わりやすいです。よかったらどうぞ。
