続・Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた

Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた - wired ravenの続き。

スクラムのアプローチは正解だった。もちろん、ほかにもいいアプローチはあると思う。

よかったこと

• チケット管理
  • とりあえず思いついたことは起票しておく
  • 実装中に別対応が必要になったものも起票する
• チケットの整理
  • 重要度が高いものを優先、前後関係がありそうなものは順番に
• TDD
  • Claudeが自発的に不具合に気が付き対応してくれる
  • そのテストパターンだとこれ足りないのでは、と気が付いて指摘がしやすい
• E2Eテスト導入
  • TDDの一環
  • UIの挙動変えたときの品質が担保できる
  • エラーが出たときにClaudeに E2E の何番がこけている。エラーメッセージはこれ、と伝えやすい
• 意図（CLAUDE.md）と仕様（SPEC.md）の管理
  • これで人間もClaudeも迷う場面が減った
• 状態遷移図の作成
  • どこが複雑なのかが一目でわかる
  • コードを直す以外のどうやったら状態遷移をシンプルにできるかという観点が持てる
• 計測、計測、計測
  • 「体感遅い」『理論上はやい』と違う基準で話していたのが実測値で繋がった
• /review
  • Claude Code のレビューコマンド、いい感じに不具合をみつけてくれる
• /simplify
  • Claude Code の冗長なコードを排除してくれるコマンド。便利な反面、コード壊す可能性があるので慎重に
• RETROSPECTIVE.md
  • 作業毎に振り返り
  • フォーマットは「良かったこと、伸びしろ、ネクストアクション」
  • ネクストアクションのうち、ドキュメントで対応できるものはその場で更新
  • 実装が必要なものは issue 作って次
• 根治 や 徹底的 、 念入りに と強調するワード
  • ソースコードを探索するときの精度があがった、気がする
    • 根治は方針として効いたのか、コードの調査中に不具合に遭遇した時、簡単な修正で終わらせずに不具合の原因を取り除きにいってくれた
  • 強い言葉で指示するより、こういう言葉の方がしっくりくる
  • もしかしたら、ベストを尽くそう、といったらベストを尽くしてくれるかもしれない。ただ、Claudeが本気出したらいくら追加料金払っても足りないので試してない
• Claude に 着手前に作業手順や仕様で質問ある？ と聞くこと
  • 仕様の確認をお願いされた。コミュニケーション大事

伸びしろ

• Antigravty + Gemini 3.1 Pro でレビュー・壁打ち・実装
  • 賢すぎるのか、フォルダ構成か何かで判断して、返してくることが多く断念
  • 「深く読みこんで」「処理を把握しながら読み進めて」と言えばやってくれるがしっくりこなかった
  • Antigravity で Claude 呼び出しても挙動が違うので、そもそもの使い方を間違えている可能性が高い
• 大量のファイル変更で VSCode がクラッシュする
  • ファイルの変更を検知して、文法チェックなどする仕組みが仇になっている
  • Terminal での運用に切り替えて様子見中
• Web版の Codex 利用
  • 管理がややこしくなってしまったので見送り
  • Codex CLI は仕様レビューやコードレビューで活用している
• Opusフル活用
  • 最初から最後までOpusのほうがよいのでは、と思ったが、そうでもない
    • これはお金の問題もあるけど、限りある計算機資源を有効に使いましょう、ええ
  • 仕様を固める途中、ややこしい実装や不具合はOpus。調査と実装はSonnetの使い分けでよい
    • 適切な切替タイミングがわかっていない
      • Sonnet が20分はまったら中断して claude --model --resume {hogehoge} するか
      • 同じエラー3回なら Opus 、異なる手順でエラーが出て3回なら仕様や計画見直すとか
• 「迷いなく実装できる状態が望ましい」が何をもってして迷いなく実装できるのか
  • トークン使い果たしました的なエラーメッセージが出たら検索しすぎなので、ディレクトリ構成やリファレンスを CLAUDE.md に追記する

ネクストアクション

成功の再現性を見つけること。

いつから使い始めるかで大きくわかれる。

初期から Claude Code 導入

• 初動はSPEC.mdを作ってレビューを繰り返す
  • 作りたいものはあるか、重複しているものはないか、考慮漏れはないか
• 実装計画を立て、レビューを繰り返す
  • ここで妙なことに気が付ける
• ガイドライン作り
  • やりたいことと方針を伝える CLAUDE.md
  • そのプロダクト固有のルール（これは動かしながら拡充してきたけど、実装計画が明確であればあるほど作りやすい、はず）
• 実装フェーズは小さく作る
  • 最初のコードは徹底的にリファクタリングとレビューを繰り返してきれいなものにする
  • このコードが基準になる
• テスト基盤を整える＆計測を徹底する
  • これが人間とAIで共通の認識に至れる
  • 手戻りも減らせる
• ドキュメント類含めて定期的にレビュー
  • やりたいこと書けているか、やってほしいことや守ってほしいことが書いてあるか
  • それらに沿って動いてくれているか（ここは人間が判断する）

既存のプロジェクトへの導入

• コード分析、仕様書に落とし込む、レビューの繰り返し
  • 大きく全体の構成を掴んで深掘りさせるアプローチだと効率よさそう
• テスト基盤を整える・テストを増やす
  • リファクタリングするにしても何にしてもまずはこれ
• 小さく試してみる
  • 意図通り動くかどうかみる
  • 意図と違ったらどうやったらうまくいくのか考える
    • 暗黙の知識やルールを言語化する形になると思う

共通

• やりたいことを最上段から伝える。小出し、後出しをしない
• これからやることを一言で表すならどうするか意識する
• ドキュメント類で人間側が何をしたいのか、何をさせたいのかを理解しておく
• Claude のリトライが多かったり、熟考する場合は仕様や実装を再検討する
• 迷いなく実装できる状態とは、これやりたい・これができたらOKを目指す
  • Claudeの実装計画の粒度がＷBSかスクラムのスプリントバックログのチケットぐらいになっているとよい
  • 実装計画はもちろん、レビューしてやりたいことできていることをチェック。不明点あれば聞いてみる
• 小さく試して小さく振り返り
  • 初手は大体何か起きるのでミニマムで作って、躓いた点を洗い出して、次に活かす
  • 安定してきたら、手順確立した証なので、徐々に大きなタスクを任せる
  • 使う技術や言語の異なる部分は別の躓き方をする点は要注意

雑感

今回は Rust + Tauri と自分にとって未知の領域で試した。知らない言語であっても、計測手段とゴールが揃っていれば任せられるとわかったのは予想外の収穫だった。

UIはどうあるべきなのか。フロントエンドとバックエンドの責務。開発者が欲しい情報とは何か……未知の領域でも今までの経験が活かせることもあった。未知の領域なのでお作法の違いに引っ掛かったりした。公式ドキュメントを読んだり、ChatGPT で Deep Research してみたり、従来通りの手段で対処していたが、Claude がクレートのコードとコメントを読んで揺らぎようのない事実を突き止めたのには唸ってしまった。とても正しい。

タイトルに話を寄せると、ツールはかくあるべしを示し続ける PO の比重が大きかったと思う。

一通り実装し、PR 作ったら振り返り。次は何をしたらよくなるか、何を試すか、を考える。そして、次の振り返りで試した結果はどうだったかを考える。

開発の障害があればそれを取り除いて、Claude が爆速で走れる状態を作るのがとにかく楽しい。

この辺はスクラムマスターとしての経験が活きているし、スクラムマスターが性にあっていたのかもしれない、と改めて感じた。

コツはつかめたと思うので次はどうしようかな。しばらくは今作ったツール2つを使って、ブラッシュアップをしていくのは確定。コードを読んでみるのもいい勉強になりそう。

仕事に関する何か、実利のある何か、と考えたけれど、趣味なんだから楽しいほうがいい。