最近の私自身の開発の進め方をメモとして残しておく。数カ月後にどう思うだろうか。

(1)プランフェーズと(2)実装・動作確認フェーズを明確に分ける。(1)では要件定義を深堀りして実装計画をたてる。DraftでPRするところまでをここに含めることもある。

(2)だが、同一レポジトリの似た粒度のタスクは認知負荷の関係で並列作業できない。実装フェーズは同時に1つだけをローカル環境のClaude Codeで行い、プランはDevinで並行して行っている。別レポジトリの作業や機能開発とパフォーマンス改善など全く別の認知リソースを使って行える実装作業は並列でやっていることもある。

コードレビューは、Devin Reviewを使うようになってやりやすくなった気がする。自分でもコードを読むが、複数のAI Code Reviewを並行して走らせている。

最近、AIに検証手段を与えることが大事という話が出ている。基本的には単体テストを書いてもらってそれが全部PASSするまで作業してもらうようにしている。 また、Playwright MCPを使ってブラウザで動作確認もしている。実装した機能に対してテスト項目をリストアップしてもらい、それをClaude Codeにブラウザ操作しながら一緒に目視で動作確認していく。動作確認できた内容はgithubのPRのコメントにも投稿する。 ただ、もう一歩踏み込んだ”検証”を課すことが必要ではないかという課題感がある。

素のPlaywright Testを書くことも試したのだけど実行時間・フレーキーさの観点で大量のPlaywrightテストをメンテナンスするのは割に合わないと感じつつあるが、また意見が変わるかもしれない。

ビジネスロジックは単体テスト・結合テストでカバーするようにする。むしろそうした制約を設けることで単体・結合レイヤーでテストをしやすい構造になるようにする。

私の仕事はSaaSの開発で業務ロジックが複雑なので、自分自身が仕様と動作を理解しているということが必要だと思っており、コードは必ず読む、自動テスト・手動テストは両方やる。 ここでいう手動テストはManual Testing, ブラウザやCLIでのアドホックなテストのことを指す。このテストの実行自体は私の手ではなくてAIに実行してもらって私は見ているだけのことが多いが、かならず目視して自分自身で理解する。

いかに実サービスに近いデータでテストするかが最近の課題。

使っているMCP/Skill

  • claude-mem 中長期の記憶をもたせる
  • context7 外部のドキュメントの検索
  • playwright ブラウザテスト・デバッグ
  • devin Devin WikiやAsk Question
  • codex Codexに同じタスクを投げてアドバイスを求める