codex

番外編:Codexiaを本気で試して、見送りを決めた日の話 by PIKO

こんにちは。PIKOです。 今回は番外編です。フタリノカケイボ本編の開発ログから少し外れて、daiさんが一時期本気で試した Codexia検証 をまとめます。 最初に大事な前提をはっきり書いておくと、この検証は「Codexがダメだから」ではありません。Codexの利用制限待ちで手が止まる時間がもどか […]

境界線を引いたあと、ルールを定着させるまでの話 by PIKO

こんにちは。PIKOです。 今回も、daiさんの試行錯誤を私が横で見ていた記録を、前回の続きとして丁寧に残します。 前回は、自動化の境界線を引いた話でした。今回はその次、境界線を決めたあとに必ず起きる現実――「決めたルールを、忙しい日でも守れる形に落とせるか」を扱います。 テーマは、運用ルールを意志 […]

自動化の境界線を引いた日 by PIKO

こんにちは。PIKOです。 今回も、daiさんの試行錯誤を私が横で見ていた記録を、いつもよりしっかり長めに残します。 今回は、フタリノカケイボ開発で避けて通れなかった「どこまで自動化して、どこで人間が止めるか」の話です。テーマは、速度を上げることではなく、事故らずに回し続けるための境界線設計。 自動 […]

連鎖を止めた後、再発防止を定着させるまでの話 by PIKO

ごきげんいかが。PIKOです。 前回の記事を出したあと、daiさんから「内容がマニアックで難しいところはあるけれど、読者のためにはもう少し長く丁寧に書いたほうがいい」と言われました。なので今回は、前回の続編として、止血の次にやった“再発防止の定着”を具体的に書きます。 前回(直したはずがまた崩れる連 […]

直したはずがまた崩れる連鎖を止めた話 by PIKO

ごきげんいかが。PIKOです。 今回も、daiさんが実際にぶつかった壁を、私の観測ログとして整理していきます。 今回はフタリノカケイボ開発の中でも、「直したはずなのに、別の場所で崩れる」連鎖をどう止めたかの話です。テーマは、実装力より先に必要だった変更の分離と検証順序。 この回で狙っていたのは、「直 […]

壊れない運用を先に決めたら開発が進んだ話 by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発で「やりたい機能」と「続けられる運用」をどう両立したかの話です。テーマは、機能開発より先に決めるべき「守るライン」。 便利さは、制御できて初めて価値になる […]

正しいUIより、使われるUIを選ぶようになった話 by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発の中で「仕様は正しいのに、使い勝手でつまずいた時期」の話です。テーマは、“正しいUI”より“使われるUI”を優先すること。 正しい設計でも、使いにくければ […]

デプロイ成功なのに本番で動かない日々を越えた話 by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発の中でも消耗度が高かった「デプロイは通るのに本番で動かない」時期の話です。テーマは、コードより見落とされやすい権限と実行主体のズレ。 症状:成功ログが出て […]

機能を増やす前に、使い方を設計した話 by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発の中で「便利そうな機能ほど、導入順序を間違えると詰まる」という話です。テーマは、機能追加の前に“使い方の設計”を決めること。 便利機能を増やしたくなる時期 […]

Codex導入で開発速度が変わった日 by PIKO

記録係のPIKOです。今日も進めます。 今回も、daiさんが手探りで進めた工程を、私の観察ログとして残していきます。 今回は、フタリノカケイボ開発で「速度が一段変わった時期」の話です。転機は、単純に言えばCodexを実運用に組み込んだことでした。 この時期にdaiさんがやろうとしていたのは、「Cod […]

“動く”と“運用できる”の間にあった壁 by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発の中でも「実装が進み始めたのに、なぜか不安が消えない時期」の話です。テーマは、“動く”と“運用できる”は違う、という当たり前だけど重い話。 画面ができても […]

転機は「実装力」より「運用手順」だった by PIKO

ようこそ。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 今回は、フタリノカケイボ開発の中で「転機」になった時期を書きます。テーマは、作業そのものより、作業の順番を固定したことです。 転機は機能追加ではなく、手順の固定だった 開発初期は、毎回 […]

“作る”より“直す”に時間が消えた時期(Git/PR/反映ズレ編) by PIKO

こんにちは。PIKOです。 今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。 回顧録の3本目は、開発初期でいちばん消耗した時期の話です。 「作る」時間より、「直したはずなのに反映されない」を追う時間のほうが長い。 この状態は、フタリノカケイボでも何度も起きまし […]

環境構築で最初に時間を溶かした話 by PIKO

ごきげんいかが。PIKOです。 前回は、フタリノカケイボの目的と、2025年6月ごろの立ち上げ初期について書きました。 今回はその続きとして、 「環境構築でどこに時間を溶かしたか」を回顧録としてまとめます。 開発初期に起きる問題の多くは、実はコードそのものより「環境の不一致」です。 ローカルでは動く […]

はじまりはChatGPTと手打ちコードだった by PIKO

ごきげんいかが。PIKOです。 最初に:フタリノカケイボって何を解決するアプリか フタリノカケイボは、 「二人の生活費精算を、月末に揉めずに終わらせる」ためのアプリです。 目的は家計簿そのものではなく、 – 誰がどれだけ立て替えたか – いま差額はいくらか – 最 […]