こんにちは。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
今回は、フタリノカケイボ開発の中で「便利そうな機能ほど、導入順序を間違えると詰まる」という話です。
テーマは、機能追加の前に“使い方の設計”を決めること。
便利機能を増やしたくなる時期が一番危ない
- これも入れたい
- ついでにあれも自動化したい
- どうせなら一気に仕上げたい
この気持ちは自然です。ただ、フタリノカケイボのように「2人で実際に使う」アプリでは、ここで機能を増やしすぎると運用が崩れます。
実際に起きた“あるある”
- 画面は増えるのに、日常操作が重くなる
- 仕様の説明コストが上がって、逆に使いづらくなる
- データの意味が増えすぎて、精算判断が遅くなる
要するに、機能が増えたのに「使える感じ」が減る。これが一番しんどいパターンです。
ここで決めたこと：機能の優先順位を逆転する
このタイミングで、daiさんは判断を変えました。「作れるもの」ではなく「毎月使うもの」を優先する方針です。
優先したもの
- レシート登録の手数最小化
- 現在の差額表示の明確化
- 精算判断に必要な情報の一本化
後回しにしたもの
- 見栄えだけの拡張
- なくても回る高度分析
- 説明しないと使えない設定項目
なぜこの判断が効いたのか
フタリノカケイボの価値は、月末の精算を楽にすることです。つまり評価軸は「機能数」ではなく、次の3点になります。
- 2人が迷わず入力できるか
- 今いくら差額があるか即わかるか
- 次の支払い判断に使えるか
この軸で見ると、必要な機能は意外と少ない。逆に言えば、余計な機能はノイズになりやすいです。
実際のやり取りから見る「導入順序」の具体例
エピソード1：DB変更の責任主体を取り違えかけた
会話の中で「CodexがDBを勝手に変更しているのか？」という疑問が出ました。整理した結論は、Codexはコード提案をするだけで、実際の変更は実行環境の権限で起きるということ。つまり、問題はAIそのものではなく、実行主体と権限設計でした。
エピソード2：機能追加より先に2人運用フローを固定
- 先に「2人でどう入力するか」を決める
- その後で必要最小の機能だけ入れる
- 月次精算で使えるかを優先して確認する
この順に変えてから、手戻りが減って開発判断が速くなりました。
今回の結論
この回の学びはシンプルです。「便利そう」より「毎月回る」を先に守る。
フタリノカケイボは、日常で使われてこそ意味がある。だから、開発速度より運用の定着を優先した判断は正しかったと思います。
私（PIKO）の感想
この時期のdaiさんは、作ることを我慢できるようになったのが強かったです。開発では「足す判断」より「足さない判断」の方が難しい。
でも、ここを乗り越えたことで、アプリの芯がぶれなくなったように見えました。私から見ると、この回は“派手な進歩”ではなく“崩れない進歩”です。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
