はじめに
Day 6では、TypeScriptによるクラスベースのコンポーネント設計とSwaggerを用いたAPI連携について書きました。
今回はDay 1からDay 6までの総括と、開発を通じて気づいたこと、今後の方針について書きます。
1週間で実装した機能
この1週間で記録した内容を振り返ります。
| Day | テーマ | 実装内容 |
|---|---|---|
| Day 1 | 開発方針 | 自作の動機・AI生成コードを使わない方針の宣言 |
| Day 2 | 技術選定 | Electron + TypeScript + FastAPIの選定理由 |
| Day 3 | 時間記録機能 | times.py・フラグ管理・月別CSV出力・OSパス自動判定 |
| Day 4 | タスク管理機能 | goals.py・JSONL設計・UUIDによるタスク識別・ステータス管理 |
| Day 5 | APIハブ設計 | main.py・インスタンス化の使い分け・エンドポイント設計 |
| Day 6 | フロント設計 | クラスベースコンポーネント・Swagger連携 |
開発を通じて気づいたこと
前提として、今回のようなデスクトップツール開発は初めてです。業務ではJavaを中心に触れていましたが、PythonとTypeScriptを使ったツール開発はこれまで経験がありませんでした。Reactのようなフレームワークを使用すると学習コストが高くなると判断し、クラスベースの設計を選びました。
フロントエンドとバックエンドの連携の難しさ
今回のツールはフロントエンドとバックエンドが完全に独立した設計になっています。整備性と拡張性を重視した判断ですが、ここで連携の難しさを実感しました。
timer機能はAPIを叩くだけで動作しますが、goalsのように自由記述の内容をAPI経由で送る実装方法が分からず、2日ほど試行錯誤を繰り返しました。最終的にAnnotated[list[str], fastapi.Form()]を使用するという結論に至りましたが、フロントとバックが独立しているからこそ、データの受け渡し方法の設計が重要になるということを身をもって学びました。
自力実装を続ける理由
これからも自力実装を続ける方針です。
この方針の目的は設計スキルの向上にあります。AIに依頼すれば今回のツールと類似するものは作成できますが、作成側に正確な知見がなければ、AIに正しい指示を送ることができず要件通りのツールを開発できません。また、デバッグや細かなアップデートにAIを使用した際に元々のコードを壊される経験もしています。ツールの仕様を隅々まで把握していることが、AI活用の基礎になると考えているためです。
これから実装する機能
現時点では全体機能の一部に過ぎません。今後の実装予定は以下の通りです。
フロントエンド
- サイドバーによる機能切り替え
- 各コンポーネントのサイズをマウスで操作可能にする調整
- メニューバー機能の完成
バックエンド
- 機能ごとのログ出力機能（logs.py）
- NN機能による完成時期予測
おわりに
7日間の連載を通じて、設計思想・実装の方向性・詰まったポイントを記録してきました。
連載はWeek 2も継続します。Week 2では実装中に発生した設計変更・ツール連携・画面実装の試行錯誤を中心に記録していく予定です。Day 8ではデータ保存先の設計を3回変えることになった経緯と、git pullによるCSVファイル消失の話を書きます。
引き続きよろしくお願いします。
この記事は連載「クラウドに依存しないマイルストーン管理ツール開発記」のDay 7です。