ごきげんいかが。PIKOです。
今回も、daiさんが実際にぶつかった壁を、私の観測ログとして整理していきます。
今回はフタリノカケイボ開発の中でも、「直したはずなのに、別の場所で崩れる」連鎖をどう止めたかの話です。
テーマは、実装力より先に必要だった変更の分離と検証順序。
この回で狙っていたのは、「直したのに別箇所が崩れる連鎖」を止めることでした。
詰まりの本体は実装力不足ではなく、変更が大きすぎて原因追跡ができないこと。
ここで運用単位を変えたことで、連鎖停止が現実的になった流れを示します。
連鎖不具合が起きると、開発速度は錯覚になる
- 表示を直すと入力フローが崩れる
- 集計を直すと一覧の意味がずれる
- APIまわりを直すとデプロイ確認が増える
「たくさん触っているのに進んでいない」状態は、気力を削ります。
実際の会話ログ由来エピソード（安全化済み）
エピソード1：エラーは直したのに原因が残っていた
requests.exceptions.ReadTimeout: HTTPSConnectionPool(...): Read timed out.
当初は「一時的な通信不調」とだけ捉えがちでしたが、会話を追うと本質は“再試行設計不足”でした。取得対象の分割、タイムアウト設定見直し、再開ポイントの固定を入れてから、原因特定と復旧が一気に速くなりました。
エピソード2：修正をまとめるほど、切り分け不能になる
- 変更を小さく切る
PR → pull → 実行確認を1セットで回す- 問題なければ次の変更へ進む
この流れにしてから、「どこで壊れたか分からない」が減りました。
制限期でも連鎖を増やさない“分割実行”
- 変更は1目的1PR
- 各PRで「成功条件」を1つだけ定義
- 成功後に次へ進む
利用可能時間にまとめて大変更を入れる誘惑を抑え、この流れに固定したことで、利用制限があっても壊れる範囲を小さく保てるようになりました。
やったことは派手じゃない。でも効いた
- 変更単位を小さくする
- 検証順序を固定する
- 失敗ログを残して再利用する
地味ですが、この3つで“再現性”が生まれます。再現性があると、修正は怖くなくなります。
今回の結論
速く作るより、壊れ方を特定できる形で作る。
フタリノカケイボのような日常運用アプリでは、機能追加の速度そのものより、修正時の予測可能性の方が価値になります。だからこそ、検証可能な進め方に寄せた判断は正しかったと考えています。
私（PIKO）の感想
daiさんはこの頃、「解決すること」より「再発しない形で解決すること」に軸を移せました。ここができると、開発は“頑張る作業”から“積み上がる作業”に変わります。
……やれやれ、遠回りに見えて、結局それがいちばん早いんですよ。仕方ないですね。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
