筆者の体験談
前提
- アプリのジャンル
- 小規模、実験
- すべて小規模である
- 破壊的変更を頻繁に行う実験用のものが多い。プロトタイピングで捨てることもある
- 開発スタイル
- ※筆者の開発スタイルは、以下のシンプルなものに絞っている：
- 人間の作業
- GitHubにissueを書き、coding agentをassignする
- → PRレビューし、mergeする
- → UX検証し、issueを書く（ループ）
- ※つまり：
- していない : 人力で実装
- していない : agentの挙動を監視して、軌道修正
- ※補足：
- PRレビュー時、
- 主に目を通すのは、PRコメント、レビュー結果、レビュー指摘対応、の上流部分
- 必要に応じて、PRコメントで人間からもレビュー指摘し、coding agentに指摘対応させる
- assignからPRレビューの間に、以下の自動化されたcoding agent作業がある
- → （coding agentが実装し、PRする）
- → （coding agentが自動レビューする）
- → （coding agentが自動でレビュー指摘対応する）
- 計画
- ※計画～仕様決定などのissue作成前の段階は、以下のようにやっている：
- 検討 / ラバーダッキング
- 初手は、検討を、脳内と紙とObsidianに、ローカルに書く
- 規模が大きいものは、
- 必要に応じて、
- ラバーダッキングのために、
- SNS / デジタルガーデン / README に書く
- 小さく始める
- 曳光弾
- 曳光弾になることが多い
- プロトタイピングとして捨てることもある
- メリット
- 認知負荷が低い
- agentの挙動を監視しないため
- agentにタスクを投げて、一晩寝て起きたらPRレビューするだけ、というレベル
- agentの利用コンセプト
成果とリソースの分析
- アウトカム：
- 改善（増加）した
- 2025年は、
- 2024年以前に比べると、
- より価値のある趣味OSSを、多く公開できたと考える
- 開発生産性：
- 改善（増加）したと考える
- なぜなら、userの支払った時間リソースは「趣味OSSのissue作成とPRレビューをしている時間」
- で、実装時間を支払わずに、アウトカムを得ているので。
- 前提として、issue作成やPRレビューは複数のプロジェクトをまたいで並列で実施している
- 切り分け：
- 自分の体調が万全な時間帯：
- スコープ外。その時間帯は趣味OSS活動せず、優先タスクをしている
- このときは人力実装のほうが、LLM実装より上
- 趣味OSS活動の時間帯（疲労している）：
- このときはLLM実装のほうが、人力実装より上
- このとき人間は、仕様を決定してissue作成、PRレビュー、UX検証などに能力を発揮できるが、
- 認知負荷の高い作業たとえば「細部かつ広範囲な実装や、ソース全体の綿密な影響調査」
- は疲労のため無理である
- 一方でLLMは疲労知らずなので、このときも変わらずに成果を出せる
- ここに使う時間リソースが増えた
- 今まで疲労時には趣味OSS活動はしていなかった（できなかった）
- 価値提供リードタイム：
- 改善（短縮）した
- 案を思いついたら、issue投げて寝るだけでいい
- 朝起きたらPRが来ているから、レビューして承認してマージするだけで実現
- フロー効率：
- 改善（増加）した
- 毎日寝る前にissue投げて、朝起きてレビューして承認してマージするだけでいい
- これまで疲労してる日は進捗なくWaitだったが、今はissue投げるだけでいいから毎日Active Timeを持てて進捗がある