Claude code(Sonnet 4)雑感3:仕様駆動開発

Share on:

ゼロベースで開発させる場合、要求仕様を具体化するために生成AIを使うという感じになっていくのか。条件的に優先度の低いものを除外していったり、抜け道になってるところを塞いでいったり。要求仕様を運用保守する感じ(謎な日本語)。

の「要求仕様を運用保守する感じ(≒仕様駆動開発)」を本格的にやってみるために、以下のやり方で取り組んでみました。 今回はゼロベースでは無く、既存リポジトリある状態から「要求仕様駆動」で取り組んでみたメモ。

【要求仕様駆動の流れ】

    1. Claudeに現状を把握して貰う。
    • セッション切れてると全体把握していないので、@read CLAUDE.md, @tree, @read 主要コード しておくと良さそう。どこまでreadさせるかは状況次第。全く読み込ませてないと「あれをベースにこうしてくれ」みたいな指示に「あれとは?不明瞭だから教えてちょ」ループに入る。
    1. 新しい機能イメージを伝える。
    • このとき、「一旦修正を中断します。これから新規機能の実装に移ります。{機能イメージ説明} これを実装するにあたり不鮮明な部分や過不足があれば指摘してください。まだ開発はせず、検討して要求仕様への指摘のみしてください。」として仕様校正に注力して貰う。
    • 可能な範囲で機械判定可能な達成目標を盛り込むとベター。
    1. 仕様校正ステップ。
    • がしがし突っ込み貰うので、想定できる範囲で具体的な設定を詰めていく。
    • 回答を作成。「不鮮明箇所への回答は以下の通りです。{回答列挙}。実装するに辺り不鮮明な部分や過不足があれば指摘してください。まだ開発はせず、検討して要求仕様への指摘のみしてください。」
    • 一度の突っ込みでは終わらずかなりしつこく突っ込んでくれるのがありがたい。辛いけど。この段階でサブゴールの洗い出しと優先順位の明確化をすることで実装しやすくなるんでしょう(ここは人間でも同じ)。
    • 「機能Aは現象Bをベースに近似的に実装して欲しい。厳密なシミュレーションである必要は無くて、[数値1] > [数値2] > [数値3] の関係を維持できれば良い。それぞれの具体的な値は問わない」ぐらいのふわっとしたゴールを伝えるのだけど、「不鮮明」と言ってくることが多い。気持ちは分かるのだけども、テストできるレベルでは指示してるのでそれを踏まえて合意して欲しい。(でも「不明瞭な部分を指摘しろ」と指示してるのだから指示の仕方が悪いという話ではある)
    1. 開発前準備。
    • Sonnet 4 さんが仕様納得したら、ブランチ切って CLAUDE.md を更新して貰う。
    1. 開発開始。
    • ブランチ内で CLAUDE.md に沿って開発指示。テストも用意させる。
    • 一度目の「目標達成報告」では不具合あることがあるので、必要に応じて追加指示する。
    1. 後処理。
    • ゴール達成を動作確認したら、ドキュメント(CLAUDE.md, README.md, VERSION_HISTORY.md)更新して、commit。
    • main ブランチに merge して、念のため動作確認。
    • 問題なければ /exit して終了。

この流れ(実装前に仕様の完成度を高めておく)だと、割とスムーズに行くっぽい。コード行数約3.5k行から約5.5k行に膨れましたが、承認以外の追加指示は5回なかったと思う。

仕様駆動開発の副次的効果として、以下の側面がありそう。少なくとも今回試した範囲(コード行数約3.5k行から約5.5k行への更新)では、ボリューム大きかった割に制限引っかからずに終わりました。

  • (1) 仕様校正中は人間側が遅いので、時間あたりのトークン使用量が減ってると思う。ただし仕様によっては「他ファイル参照しながら整合チェック」みたいな挙動もしてくれてるので、実際に減ってるかどうかは不明。
  • (2) 仕様確定後の実装段階はかなりスムーズに進むので、こっちでもトークン使用量が減ってると思う。
  • (3) 実装中の細かな指示をしなくて良くなった分、以前書いたハードコーディングみたいな無駄なやりとりが大きく減ったので、こちらもトークン使用量削減に貢献してるはず。
  • (4) トークン使用量制限に引っかかりにくくなるので「使い切るまでやろう」という思考をしなくて済むようになるw

とはいえ今回試した内容は素朴な追加実装がメインだったのだよな。これからまだまだ追加していく部分あるので、結合度が増してくるとどうなることやら。

P.S. 上記の後で同じ流れで追加実装を試したところ、約5.5k行→約7.6k行(ファイル数約30)に増える更新になり、こちらも実装ステージではスムーズに終わりました。ここまで増えてもトークン使用量制限に引っかからない。これならトークン使用量の面でも、開発規模の面でも、今のところ Pro アカウントの範疇で大丈夫かも。言い換えると使い方次第で可能な開発規模も変わってくる。即動くものを作ってそれベースに修正していく形のアプローチでは2〜3千行で破綻しがち(結合度合いによるだろうけど、密結合になりやすそう)。

それにしても5k行以上の規模になるコードを自前で書いたことは無いな、、。

P.S.2 要求仕様校正ステップで叩かれまくるのは辛いw 実時間的には仕様校正ステップで9割以上占めてます。