概要
- Tano入社から6週間での業務改善体験のまとめ
- 単純作業の自動化とインフラ整備による生産性向上
- 並列作業や検証プロセスの効率化
- エージェント活用による役割変化とマネジメント視点の強調
- 改善ループの継続的な進化と楽しさ
Tano入社6週間での業務改善体験
- Tano 入社から約6週間の コミット履歴 の変化
- コミット数 自体は成果指標として不十分だが、 可視化しやすい アウトプット
- 業務の進め方が根本的に変化したことを実感
単純作業の自動化
- 入社当初は 全てのプルリクエスト を手作業で作成
- 変更ステージング、コミットメッセージ記入、PR説明文作成、GitHubでPR作成
- この作業が 単純作業（grunt work） であることに気づく
- 自分は「実装者」から「実装するエージェントのマネージャー」へ役割転換
- Claude Code 向けの /git-prスキル を開発
- 変更内容を自動要約し、より詳細なPR説明文を生成
- 単純作業から解放され、 メンタルの負荷軽減 を実感
- コマンド一発でPR作成、次のタスクへ即移行可能
待ち時間の排除
- 変更確認のたびに ローカルでプレビュー → サーバー再起動 の繰り返し
- サーバービルドに1分ほどかかり、 集中力が途切れる 要因
- SWC へのビルド切り替えで サーバー再起動が1秒未満 に短縮
- 作業フローが中断されず、 没入感（flow） を維持
エージェントによるUI検証
- 以前は全てのUI変更を自分でローカルプレビューし目視確認
- 自分が 全てのボトルネック となっていた
- Claude Codeのプレビュー機能 へ移行
- エージェント自身がプレビューし、UI検証まで自動化
- 検証の 委任 により、エージェントが自己完結型で稼働
- 最終レビューのみ人間が担当、 長時間の自律稼働 が可能に
並列作業の最適化
- ビルド高速化 と 自動プレビュー の導入で新たな課題が顕在化
- 同時に複数作業を進める際の 環境変数やポート競合
- ワークツリーごとにポート割り当て を自動化
- 10個以上のプレビューを同時稼働可能
- 5つのワークツリーでエージェントが並列に機能開発
- 計画段階で関与し、 コードレビュー時のみ介入
- エージェントの 自己検証能力 が重要性を増す
- レビュー作業も効率化、セットアップ不要で即確認・マージ
インフラ構築の価値
- 以前は 複雑なUI設計 や 問題解決 に喜びを感じていた
- 現在は エージェントの生産性を最大化するインフラ構築 が楽しみ
- マネージャー的役割 へのシフト
- 地味だが重要な「配管」 （plumbing）作業が、開発体験の質を左右
- 最も価値の高い仕事 は新機能実装ではなく、 インフラ改善
改善ループと理論
- 各段階で 異なる摩擦 を排除
- /git-pr： PR作成の手間 を削減
- SWC： 待ち時間 を排除
- プレビュー： 検証作業 の効率化
- ワークツリー： 並列作業の摩擦 を解消
- ボトルネック理論（Theory of Constraints） の実践
- 一つ解決すると次の課題が現れる
- 作業サイクルの高速化 が新たな楽しさに
- タスク発行→エージェント実装→プレビュー確認→フィードバック→次タスク発行
- 注意力の分散がなくなり、開発がエンターテインメント化
/git-prとGraphiteについて
- コードベース のCLAUDE.mdでは Graphite 推奨
- 著者は シンプルなgit運用 を好み、/git-prを活用