個人開発の記録です。Mac miniが届いた翌週、つまり今週の前半は、新しいコードを書くより「何をやめるか」を決めることに時間を使いました。地味ですが、たぶん今週いちばん大事な判断だったので記録します。

Contents

まず結論

手を広げすぎていた開発を、3本だけに絞りました。それ以外は「やめた」のではなく「応募後の楽しみに凍結」です。そしてこの絞り込みを、単なる時間管理ではなく「フリーランスとして自立する」という長い目線とつなげて考え直した週でした。

前回の記事で、自分の開発の一番のリスクは技術ではなく「手の広げすぎ」だと正直に書きました。電車アプリ、ビル管理ポータル、家計アプリと連携構想、ローカルLLM学習、Docker学習、このブログ。一つ一つは筋が通っていても、使える時間は週に数時間しかありません。

今週、その診断をもう一歩進めました。技術で詰まる兆候より、注意力の分散のほうが先に来る段階だ、と。だから今週やったのは、機能追加ではなく「優先順位を紙に固定する」ことでした。

なぜ最優先か。外部の締切（コンテスト応募）があり、勝敗を分ける「蓄積データ量」は今しか作れないからです。過ぎた時間は取り返せません。前回までに身につけた検証の型──「異常値は保留」「欠測はゼロと違う」「2日一致は法則じゃない」──が、このプロジェクト最大の資産になっています。

なぜ止めてはいけないか。実装が止まっていて、「設計は立派だが動かない」という一番もったいない停滞に入りかけているからです。再開の一歩は新機能ではなく、前回書いた権限まわりの穴（自己昇格リスク）の修正と、セキュリティの実検証。認証は後から直すと一番高くつくので、ここだけは先に手をつけます。

Mac miniが動き始め、環境づくりのフェーズが終わりました。だから今後は「LLMを勉強する時間」を別に取らず、①②の作業中に相談相手として使う形で、開発に溶かします。「本来の開発が常に優先」という自分のルールの実践です。

凍結したのは、Docker学習アプリの増産・家計アプリの拡張・猫や家族の健康アプリ。どれも面白いテーマですが、応募が終わった2月以降の楽しみに回します。やらない順番を決めるのも、積み上げの一部だと考えることにしました。

今週もうひとつ考えたのが、フリーランスとして自立するには何が要るか、でした。ここで意外だったのは、答えが「新しい技術を増やすこと」ではなかったことです。

受注を決めるのは技術リストの長さではなく、「この人に頼むと何が解決するか」の証明だと気づきました。そして自分の3本柱は、実はその証明材料そのものになっています。

実績を”見せられる形”にする：実在の顧客で動くシステム・公開URLのアプリ・試行錯誤を記録したこのブログ。足りないのは中身ではなく「商談で見せられる1枚」でした。今週、その導入事例のたたき台を作り始めました
専門を尖らせる：病院SEとして「データを外に出せない現場」を内側から知っている経験は、ローカルAIと掛け算にできる希少な武器になります
作る力より運用の力：安定収入は開発より保守から生まれる。Mac miniの24時間運用・バックアップ・障害対応は、そのまま「保守で何を提供するか」の実地訓練でした

3本柱を完走すること自体が、そのまま営業資料づくりになる。そう捉え直せたのが、今週の一番の収穫でした。

機材が増え、できることが増えると、つい全部やりたくなります。でも今週学んだのは逆で、できることが増えたときこそ、やらないことを決めるということでした。

絞ったからといって夢が縮んだわけではありません。むしろ、凍結した構想は「いつかやる楽しみ」として手元に残り、目の前の3本には集中できる。初学者の自分にとっては、これが一番健全な進め方だと思っています。

個人開発 / 学習の型 / フリーランス

このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。