はじめに
この記事は、自作のマイルストーン管理ツール開発の記録を1週間連載で書いていく、その初回記事です。
OSSとして公開予定のため、公開に先立ってこのツールで何ができるのか、なぜ自作したのかを記事として残していきます。
連載の初回となる今回は、自作を決めた理由と方針について書きます。
なぜ自作するのか
正直に言えば、世の中にはマイルストーン管理ツールが既に多数存在します。Notion、Trello、Jira、Asana等は機能も充実していて、サービスとしての完成度も高い。
それでも自作を選んだ理由は、過去の現場経験にあります。
クラウド型のマイルストーン管理ツールを使っていた時、通信環境の悪化によって当日のタスクを確認できない事態に遭遇しました。タスクが見えなければ作業の優先順位が判断できません。たかがタスクリストですが、見れないことで業務が止まる現実を経験しました。
この経験から、自分の作業情報は自分のローカル環境で管理したいという考えに至りました。
このツールで実現したいこと
現時点で計画している機能は以下の通りです。
- 完全ローカル動作 - 外部通信なしで動作
- タスク管理 - 期限と進捗ステータス（未着手 / 進行中 / 完了）の管理
- 時間記録 - 作業時間の自動計測と月別CSV出力
- ドキュメント管理 - wikiや方針などの.md形式で管理
- データ主権 - 全データはローカルファイル（CSV / JSONL/ .md）として保存
- OSSとして公開 - 個人利用を想定した軽量ツール
機密性の高い環境では外部接続が制限される場合があります。そのような環境でも動作するツールとして仕上げることを目標にしています。
技術選定
| 層 | 技術 |
|---|---|
| フロントエンド | Electron + TypeScript + Vite |
| バックエンド | Python + FastAPI |
| データ形式 | CSV（時間記録）/ JSONL（タスク） |
技術選定の詳細はDay 2で書く予定です。
開発方針 - AI生成コードを使わない
このツールはAI生成コードを一切使用しません。検索やアイデア出しでAIを使うことはありますが、コード生成は禁止しています。
理由は2つあります。
1. トークン数と整合性の問題
複雑なツールを作る場合、AIが書いたコードは全体の整合性が取れていない状態で出されることも多く、修正の場合においては既存コードとの一貫性が崩れやすく、結果的に手戻り作業が増えます。
2. UIで「それっぽい」コードが量産される
UIをAIに書かせると、見た目は整っているが要件と合わないコードが出力されることがあります。例えば「ボタンを1つ作って」と指示してもボタンが2つ生成される、といった具合です。
これらの経験から、今回のツールは全て自力で実装することにしました。
今後この連載で載せるコードは全て人力で書いたものです。
おわりに
今日は連載の初回として、自作の動機と方針を書きました。
Day 2では、なぜElectron + TypeScript + FastAPI という構成を選んだのか、技術選定の理由について書く予定です。
連載を通じて、設計判断の理由・実装の試行錯誤・詰まったポイントを率直に記録していきます。同じように個人開発をしている方の参考になれば嬉しいです。
この記事は1週間連載「クラウドに依存しないマイルストーン管理ツール開発記」のDay 1です。