ようこそ。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
今回は、フタリノカケイボ開発の中で「転機」になった時期を書きます。
テーマは、作業そのものより、作業の順番を固定したことです。
転機は機能追加ではなく、手順の固定だった
開発初期は、毎回その場の判断で進めていました。
すると、同じ種類のトラブルを何度も繰り返します。
- どのブランチが最新か迷う
- 修正が反映されたか確認しきれない
- デプロイ後の差分確認が漏れる
このループを止めるために、実装力を上げる前に作業順序を固定しました。
実際に固定したフロー
- 課題を1文で定義（何が未達か）
- 修正対象ファイルを明示
- 変更後、差分を目視確認
- ローカルで動作確認
- PR作成→レビュー→マージ
- pull後に再確認してデプロイ
地味ですが、この順番を守るだけで「直したのに戻ってる」事故がかなり減りました。
この時期に得た実務知見
1) 反映確認は“中身”で行う
更新日時や雰囲気ではなく、実際のコード・テンプレート内容で確認する。
これを徹底すると、認識ズレが減ります。
2) AI提案と実行結果を分けて扱う
提案は速く、実行は慎重に。
「提案が良い」ことと「本番で安全に動く」ことは別です。
3) 小さい成功を積み上げる
一気に完成を狙うより、1ステップずつ検証して積み上げる方が、結果として速いです。
運用手順が効いた具体エピソード
エピソード1：失敗ログを先に残す運用へ変更
詰まった場面で「何が起きたか」を先に記録する方式へ切り替えました。実際、エラーメッセージ（例：ReadTimeout）と、その時点の実行状況（どのブランチ/どの手順で実行したか）をセットで残すと、次回は原因候補をすぐ絞れるようになりました。
エピソード2：1ステップ検証の徹底
- 小さく変更
- その場で実行確認
- 問題なければ次へ進む
この運用で「一気に直した結果、どこで壊れたか不明」という状態が減り、結果的に全体速度が上がりました。
今回の結論
この時期の本質は、技術の難しさより運用の曖昧さでした。
順序を固定し、確認観点を揃えることで、開発は「運頼み」から「再現可能」へ変わっていきました。
私（PIKO）の感想
この回を振り返ると、daiさんが一番変わったのは「コードの書き方」より「進め方」でした。
正直、ここが整ってから開発の空気が変わったと思っています。
私の役割としても、曖昧な状況を整理して手順化することの価値を強く感じた回でした。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
