Claude Codeで実装以外の開発フロー、どこまで自動化できるか？失敗と成功

Transcript

1. Claude Codeで実装以外の開発フロー、どこまで ⾃動化できるか？失敗と成功 1
2. 今⽇話さないこと Claude Code特有の技術的な話 カスタムコマンド、サブエージェントなどテクニカルTipsは、登場しません。 今⽇話すこと 意思決定プロセスに どうClaude Codeを組み込んだか デザイン検討や仕様検討にどう活⽤してみて、 どう失敗したか 2
3. ⾃⼰紹介 3
5. 会社概要 5
7. ミッション・ビジョン・バリュー 

8. SENと私とClaude Code 6
9. SENとClaude Code SENでのClaude Code活⽤状況 SENでは、特定のAIエージェントを使うという標準化はしていない。 それぞれのチームが⾃分たちの状況に合わせて、⾃由に使い⽅を決めている。 チームごとの活⽤例 • あるチームでは、Pdm含めて全員が共通でClaude Codeを 利⽤し、レビューやタスク分解も含めてフローを統⼀ • 別のチームでは、開発側からビジネス側に向けて普及活動 を⾏い、業務効率化の取り組みにClaudeDeskTopを取り⼊ れる動き 現状 チームごとにスタイルは異なるものの、 Claude Code/ClaudeDeskTopは開発現場からビジネス側にも 波及しつつあり、多様な形で浸透しているのが現状 7
10. 私とClaude Code 使⽤経緯 今年の1⽉頃からCursorをメインに使⽤ • Claude CodeのProプランが出たタイミングで乗り換え • それ以来、コードはほとんどClaude Codeに書かせる形が メイン 乗り換えの理由 実際に使ってみたときのアウトプット精度がCursorとまった く違うと感じたため 現状、ほぼClaude Codeを主軸にしながら、開発フロー全体を回しています 8
11. 今年の1⽉頃からCursorを使⽤して感じたこと 10
12. 今年の1⽉頃からCursorを使⽤して感じたこと Cursorの導⼊により、時間短縮と効率が⼤幅に向上 タスク所要時間の⼤幅短縮 Cursor導⼊後、これまで2〜3⽇かかっていた実装が、わずか1〜2時間 2週間くらいかかるであろうタスクも1⽇2⽇くらいで対応できるように 開発プロセスの劇的な加速 ユーザーからの要望対応や、バグ修正の作業が劇的に速くなる 体感では5倍くらいのスピードアップ 実装コストは⼤幅減少→実装以外の開発フローがネックに！ 1
13. チームでの「実装以外の開発フロー」の課題 11
14. スピード出ない！ ドメインの知識や現場の⽂脈理解など「コンテキストが膨⼤」 なタスク 要望の判定 要望のやるやら判定‧優先度付け 仕様策定 要望をどう仕様に落とし込むか デザイン デザインのプロセス 12
15. 実装以外がよりボトルネックに Claude Codeの導⼊により実装コストが激減したことで、 実装以外のフローがより⼀層ボトルネックに 13
16. Claude Codeでどこまで⾃動化できるか？実験してみた 要望の判定 要望のやるやら判定‧優先度付け 仕様策定 要望をどう仕様に落とし込むか デザイン デザインのプロセス 14
17. あくまで！実験 背景 • ツールやtipsが乱⽴し、Claude Codeも進化し続けている • 「これが標準フローだ」と決め打ちするのは現実的ではな い アプローチ • 何がうまくいくか、どこで失敗するかは、実際に試してみ ないと分からない • 「これはAIに任せた⽅が速い」「これは⼈間がやった⽅が いい」といった境界を探す必要がある "失敗上等で最適解を⾒つける"というチームでの共通認識 今回ご紹介する取り組みも、SEN全体の標準ではなく、私のチーム内で⼩さく進めてきた実験です 15
18. 実験で夢⾒ていたこと この実験の開始時 要望の判定、仕様策定、デザイン、テスト、さらにはプレス リリース作成まで、開発フロー全体をClaude Codeで⾃動化 できるという壮⼤な夢を抱いていた 1
19. ということで チーム内で進めてきた実験について、 失敗 なんかうまくいきそうな予感 いいかも… などなど、チームで経験したので共有します！！ 1
20. 実験1: ユーザー要望のやる‧やら判定の⾃動化 17
21. チームの開発フロー 18
22. 弊チームの開発フロー 1. 要望受け取り カスタマーサクセス＆サポートチームがユーザーから要望を受け取る 2. やる∕やらない判定 開発チーム＋CSチームで「やる∕やらない判定」を⾏う 3. 仕様確定 「やる」と決まった要望は、開発＋CSで仕様を固める 4. デザイン検討 並⾏してデザインを検討する 5. 実装 実装へ進む 実験1「ユーザー要望のやる∕やらない判定の⾃動化」 19
23. やる‧やら判定の課題 課題：意思決定のための情報収集＆認識合わせで時間が溶ける やる∕やらない判定段階では様々な観点で検証するため、その都度情報を収集するために多くの時間が必要 「この機能って、どれくらいのユーザーにどれくらい使わ れてるっけ？」 「他の要望ってどんなのがあるっけ？」 「この機能の実装って、結構複雑じゃなかった？」 「これを実装すると困るユーザーはいそう？」 20
24. どうしたか？ 会議の前にClaude Codeで すべて情報収集させちゃえ！！ 会議で質問をゼロにするのだ！！ 21
25. .claude/構成での情報⾃動収集 22
26. 具体的な⾃動アウトプット 競合調査 主要な競合サービスの同等機能 の有無や仕様 機能利⽤率集計 各機能がどれくらい現場で使わ れているか、利⽤率集計 他現場の要望集約 zohoの要望を横断的に抽出‧グ ルーピング UI‧画⾯構成の確認 対象機能の画⾯キャプチャや導 線、操作⼿順を⾃動で整理 ソースコード‧技術的影 響の可視化 対象機能の実装箇所や関連ロ ジック調査 Playwright mcpやDuckDBを活⽤しながら情報を整理していく 23
27. 例） 24
28. ユーザーの要望調査.yaml 22
29. ソースコード調査.yaml 22
30. うまくいったの？ 24
31. 実験結果：⼤幅な効率化に成功！ Claude Codeが⽣成したドキュメントを会議で活⽤することで、 以前情報収集に費やしていた時間がほぼなくなり、意思決定のスピードが⼤幅に向上 情報収集時間 情報収集に要する時間、⼤幅減 Claude Codeではわからない CSチームの知⾒やユーザーの声を共有す る時間に 判定スピード 意思決定のプロセスが⼤幅に加速 判断材料は揃っているので、 納得感のいく判断をスピーディーに できるになった 会議の質 会議が「意思決定」の場に！ 情報不⾜で決めきれないがなくなり、 さくさくと意思決定できるようになった 25
32. 定量的な効果 会議でどれくらい意思決定のスピードが向上したかというと、体感で約3〜4倍の効率アップに。 今後はもっと早くなりそう 以前の会議 30分の会議で、1つの要望の「やる∕やらない判定」を⾏うの が限界でした。 • 情報収集と認識合わせに時間がかかっていた • 議論が発散し、意思決定まで⾄らないこともあった Claude Code導⼊後 同じ30分の会議で、3〜4つもの要望を裁けるようになりまし た。 • 事前に情報が整理されているため、本質的な議論に集中で きる • 意思決定の質を落とさずに、圧倒的なスピードアップを実 現 1
33. はじめからうまくいったの？ 26
34. はじめからうまくいったの？ 全然うまくいきませんでしたw 27
35. なぜ、うまくいかなかった？ まずは「⼀気に全部のドキュメントを⽣成させる」というアンチパターンを踏んだ それっぽいアウトプットは出るけど、資料としては使えない どうしたか？ 地道に…yamlを育てました！ 28
36. yamlの育て⽅ 分割 要求定義、競合調査、利⽤率…それぞれ をYAMLで細かく分割 調整 要求定義がうまくいくまで複数の要望で yamlを調整 汎⽤化 他のyamlも同じように、汎⽤的に要望を 捌けるまで調整 地道に改善を続けてyamlを育てることでようやく会議に耐えうるドキュメントが作れた 1
37. tips 30
38. tipsについては、こちら のブログにいろいろ書き 書きしたので、割愛しま す！ 31 https://productblog.sencorp.co.jp/entry/2025/07/15/114455
39. Cursorでの試⾏とClaude Codeの成果 Cursorでの試⾏ 同様の⾃動化をCursorでも試みたが、結果は⼤きく異なった • 途中であきらめて、中⾝のないアウトプットをしている • 表⾯上は⽣成されても、資料として的外れなアウトプットが多い • 特に、深いコンテキスト理解が必要なタスクでは限界を感じた この結果から、今回の開発フロー⾃動化においてClaude Codeが不可⽋な存在かなという判断 1
40. 実験2: 仕様策定＆デザインの⾃動化 17
41. 実験2: 仕様策定＆デザイン やるぞ！仕様＆デザインフローの⾃動化 やるやら判定はうまくいったぞ！それなら、これもいけるはず！！ 仕様書の⾃動⽣成 デザイン前段階の情報整理（メンタルモデル作成） 33
42. 実験2: アプローチ 「やる‧やら判定」で収集した情報をもとに、以下の⾃動化を試みた。 仕様書の⾃動⽣成 「やる‧やら判定」会議で集約された情報から、 要件定義書や詳細設計書を⼀括で⽣成することを⽬指し た。 デザイン前段階の⾃動化 UXデザインの初期段階として、ユーザーのメンタルモデル などをClaude Codeに⾃動⽣成させ、それを基にデザイン を進める実験を⾏った。 「やる‧やら判定」での成功体験から、これらのドキュメントも⾃動⽣成できるという仮説を⽴てた。 34
43. 先に結論！ 全然うまくいかなった！！w 実際の結果 仕様書「それっぽい」だけ。 UXを考えるためのメンタルモデルも同じく「それっぽい」だけ 実際にデザイナーにAI⽣成のメンタルモデルを渡したところ、かえって混乱を招いた むしろ⼈間がインプットして悩むという⼯数が増える 35
44. ここで気づく… 代替ではなく再設計が必要 実験2の取り組みを経てはっきりしたのは、⼈間の作業をAIに代替させるアプローチはスジが悪い 既存のフローを⾒直さないまま、 部分的に⼈間の作業をそのままAIに置き換えようとしても、結局しんどい。 36
45. 実験を通じて感じたこと ✗ 代替アプローチ 既存の⼈間の作業をAIに置き換える → 効果は限定的 メンタルモデル作成をAIに代替 → 事実確認とやり直しで⼯数増 仕様書を作らせる → 結局、⼈間が⾯倒をみる必要がある ◦ 再設計アプローチ AIを前提にプロセス全体を組み直す → かなり効果的 • 実験1: 情報収集の⾃動化による意思決定⾼速化 → 会議時間 がかなり短縮 そこで視点を変えました。 必要なのは「代替」ではなく、AIを前提にしたフローの再設計 37
46. 実験3: デモ駆動開発 17
47. デモ駆動開発 デモを起点に進める開発フロー エンジニアが完成形に近いデモをClaude Codeで作成し、それを叩き台に仕様やデザインを固めちゃう！ 1 1. デモ作成 エンジニアがClaude Codeでデモを作成する 2 2. レビュー 関係者全員でレビューを ⾏う 3 3. 再デモ フィードバックを反映し て再デモを出す 4 4. 最終確認 ステージングで完成度を 確認し、最終確認を経て リリースする 38
48. デモ駆動開発に切り替えた背景 1 実装コストの最⼩化 Claude Codeを使えば仕様さえまとまっ ていれば実装コストを限りなくゼロに近 づけられるという確信 2 ドキュメント基盤の整備 「やる∕やらない判定」で、要件整理の ドキュメントをかなりの精度で⾃動⽣成 できるようになっており、すでにドキュ メント⾯の⼟台は整っていた 3 合意形成の効率化 デモをベースに議論を回すことで、ド キュメントだけでは合意形成が進みにく かった部分も、より具体的に、より早く 固められるようになるのでは？と考えた からです。 前提が揃ったことで、 「デモを起点に仕様‧デザインを固めていく⽅が効率的」 と判断 39
49. デモ駆動開発やってみて（まだ初めて3週間... 過去の試み AIに複雑な仕様やメンタルモデルを作成させるアプローチは、 • 「それっぽい」が実⽤に耐えない • 結局、⼈間の修正⼯数が増⼤ • かえって混乱を招く という課題に直⾯した。 デモ駆動開発の解決策 Claude Codeを活⽤し、 • AIは⾼速プロトタイピングに注⼒ • ⼈間は具体的なデモで認識を統⼀ • ⼿戻りなく、創造的な議論に集中できる ⼈間とAIの役割が最適化 40
50. デモ駆動開発tips 私たちのチームでは、デモ駆動開発を効率的に進めるため、こんな取り組みをしてます！ ⾮同期レビュー 集まってではなく、メンバーで ⾮同期にデモを確認しレビュー ガイドラインの活⽤ 共通‧役割別(PdM,デザイ ナー、CS)ガイドラインで、多 ⾓的な視点からデモを評価しま す。 Asanaでの記録と活⽤ 課題と改善案をAsanaに記録 し、即時反映や今後の知識とし て活⽤ 意思決定の情報は徹底的に残して コンテキストとして活⽤できるようにする 41
51. 今の課題 17
52. 今の課題 1 ⼤型プロジェクトへの適応 半年以上を要する⼤規模開発では、デモ作成前に検討事項が多く、現⾏⼿法では対応できる気がしない 課題：初期検討をどのようにスピードアップするのか。 2 コンテキスト不⾜ CSやビジネスサイドの声、顧客フィードバックなどコンテキストをデモ実装時で活かしたいが、データ基盤が整ってない 課題：知⾒を整理‧共有し、より良いデモに活かす仕組みをいかに構築するか。 1
53. 最後に まだまだ実験中です！ 他のチームでも様々な実験を⾏っているため、少しでも興味を持たれた⽅は、ぜひカジュアル⾯談しましょうー！ 42