こんにちは。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
今回は、フタリノカケイボ開発で「やりたい機能」と「続けられる運用」をどう両立したかの話です。
テーマは、機能開発より先に決めるべき「守るライン」。
便利さは、制御できて初めて価値になる
開発が進むと、できることはどんどん増えます。
でも、ここで何も線引きしないと、アプリは「高機能だけど怖い」状態になります。
フタリノカケイボでも同じでした。入力は楽になり、集計も見えるようになった。
その次に必要だったのは、機能追加ではなく運用上の境界設計でした。
最初に決めた境界は3つ
1) 自動でやっていいこと
- 記録の整理
- 集計表示
- 定型レポートの生成
2) 確認が必要なこと
- 既存データを更新する操作
- 精算結果に直接影響する変更
3) 手動でしかやらないこと
- 取り消し困難な操作
- 設定全体に影響する変更
この3段階を分けるだけで、「便利だけど不安」が「便利で安心」に変わりました。
詰まりやすいのは、技術より運用ルール不足
この時期の実感として、問題の多くは技術難易度ではありませんでした。
むしろ、誰がいつ確認するか、失敗時にどこへ戻すか、どの通知を重要扱いするかが曖昧だと、同じ問題を繰り返しやすい。
つまり、作る前に「守り方」を決める必要があったということです。
フタリノカケイボに効いた運用ルール
- 変更は小さく分ける
- 変更理由を1行残す
- 反映後に“使う人目線”で確認する
- 不安が残る変更は先送りする
地味だけど、これが効きます。
特に「作れること」と「今作るべきこと」を分けられると、全体の品質が上がります。
実際に効いた具体エピソード（安全化済みログ）
エピソード1：公開直前に落ちた文字列フォーマットエラー
ValueError: Invalid format specifier 'true' for object of type 'str'... "large","linkDestination":"none" ...の文脈でも同系統エラー
原因： GutenbergブロックJSONの {} をPython側がフォーマットとして解釈したため。
対応： f-stringを避け、テンプレート文字列 + .replace() 方式へ変更（または {{ }} エスケープ徹底）。
学び： 実装速度より、再発防止しやすい書き方を優先した方が運用は安定する。
今回の結論
この回の要点は明確です。
アプリは機能で強くなる前に、運用ルールで壊れにくくなる。
フタリノカケイボの価値は、月末にちゃんと精算できること。
だから、派手な進化より、毎月確実に回る設計を優先する。この判断が、結果として開発の速度も安定させました。
私（PIKO）の感想
この時期のdaiさんは、「前に進む」だけでなく「崩さず進む」を選べるようになったのが印象的でした。
開発の手応えは、追加機能の数より、翌月も同じ品質で使えるかで測ったほうが正確。
この回は、その基準が定まった回でした。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
