2026年7月10日(金)
今日やったこと
- TSUMOO-56 一括管理機能に向けたタスク操作設計整理を完了した
- 一括登録は既存の
POST /api/tasks/bulkと/app/tasks/bulk-newとして維持する方針を確認した - TSUMOO-56 は新しい一括管理機能の実装ではなく、既存の一括登録、単体操作、一覧操作の責務整理として扱った
- 今すぐ直すもの、後続へ送るもの、触らないものを分け、後続タスクで迷わないようにした
- 一括登録は既存の
- TSUMOO-57 一括管理API契約・エラー形式整理を完了した
- 一括登録以外の一括完了、完了取消、削除、一括編集は現時点では予定しないことを明確にした
useTaskBulkCreateの validation、API error mapping、payload 作成を整理した- Laravel 側では一括登録まわりの Request / Action にコメントを追加し、既存挙動を変えずに読みやすさを上げた
- TSUMOO-58 振り返り機能の責務整理を進め、完了扱いにした
useReviewPageSummaryから defaults、表示用変換、型を切り出し、タスク管理側と共通で使える表示変換も整理したDailyReviewListを日別詳細、メモ入力欄、補助計算に分けたWeeklyCompletionChartをグラフ計算、座標同期、animation 制御、tooltip 表示に分けた- backend 側では
ReviewDaySummaryBuilderを追加し、今日 / 日別 summary の組み立てを共通化した GetTodayReviewActionとGetWeeklyReviewActionは入口責務に寄せ、関数単位のコメントも追加した
- ドキュメントとPR準備を行った
- TSUMOO-58 の開始ファイルに、backend 側で直した内容と TSUMOO-59 へ送る内容を追記した
- 達成状況・振り返りの機能実装ガイドに、
ReviewDaySummaryBuilderの読み方を反映した - frontend / backend / docs のコミット、push、PR文作成まで進めた
- 開発プロセスの説明も整理した
- Tsumoo 個人開発をスキルシートに書くため、フェーズ分け、タスク開始前ファイル、AI活用、テスト確認の説明を整理した
- AIを単なるコード生成ではなく、要件整理、設計方針の壁打ち、レビュー、リファクタリング、テスト観点整理に使っていることを短く説明できる形にした
ロードマップ
フェーズ1: タスク管理MVP
進捗: 54 / 67件
今日対応したタスク
- 完了 TSUMOO-56 一括管理機能に向けたタスク操作設計整理
- 完了 TSUMOO-57 一括管理API契約・エラー形式整理
- 完了 TSUMOO-58 振り返り機能の責務整理
完了したタスク
- TSUMOO-58 振り返り機能の責務整理
- TSUMOO-57 一括管理API契約・エラー形式整理
- TSUMOO-56 一括管理機能に向けたタスク操作設計整理
- TSUMOO-55 カテゴリ機能に向けたタスク管理設計整理
次に取り組むタスク
- TSUMOO-59 振り返りAPI契約・エラー形式整理
- Review API の validation error、Resource 化、response contract key の扱いを確認する
- その後、設定、認証まわりの責務整理とAPI契約整理へ進む
考えたこと
TSUMOO-56〜58 は、どれも派手な新機能を足すというより、これまで作った機能を次の拡張に耐えられる形へ整える作業でした。
特に振り返り画面は、タスク管理より軽いと思っていましたが、実際には今日の達成状況、週間グラフ、日別リスト、メモ保存、タスク集計がつながっていて、責務を分ける価値が大きい部分でした。
また、AIとの開発の進め方をスキルシート向けに言語化したことで、Tsumooでは「実装前に目的、対象範囲、対象外、完了条件を整理してから進める」運用がかなり定着していると感じました。
決めたこと
- 一括登録は既存機能として維持し、一括管理APIや一括管理UIは現時点では予定しない
- TSUMOO-57 では、一括登録と単体操作の責務境界を混同しないことを優先する
- TSUMOO-58 では、振り返り機能の既存挙動を変えずに、画面 hook、日別リスト、週間グラフ、backend summary 組み立てを整理する
ReviewDaySummaryBuilderは TSUMOO-58 では response shape を崩さない範囲で追加し、API契約そのものの整理は TSUMOO-59 へ送る- Tsumoo の個人開発では、AIを開発パートナーとして使いながらも、採用判断と品質確認は自分で行う方針を説明する
次にやること
- TSUMOO-59 として、振り返り API の契約とエラー形式を整理する
PUT /api/review/memos/{date}の validation error を Task API と同じ形式にそろえる- Review API の response shape を Service ではなく Resource 側へ寄せるべきか確認する
reviewSummaryApi.tsの型と mapper を分け、API呼び出しの挙動は変えずに読みやすくする