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

by ndaDayo.Sugawawa

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

今⽇話さないこと Claude Code特有の技術的な話カスタムコマンド、サブエージェントなどテクニカルTipsは、登場しません。今⽇話すこと意思決定プロセスにどうClaude Codeを組み込んだかデザイン検討や仕様検討にどう活⽤してみて、どう失敗したか 2

Slide 3

Slide 3 text

⾃⼰紹介 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

会社概要 5

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ミッション・ビジョン・バリュー  

Slide 8

Slide 8 text

SENと私とClaude Code 6

Slide 9

Slide 9 text

SENとClaude Code SENでのClaude Code活⽤状況 SENでは、特定のAIエージェントを使うという標準化はしていない。それぞれのチームが⾃分たちの状況に合わせて、⾃由に使い⽅を決めている。チームごとの活⽤例 • あるチームでは、Pdm含めて全員が共通でClaude Codeを利⽤し、レビューやタスク分解も含めてフローを統⼀ • 別のチームでは、開発側からビジネス側に向けて普及活動を⾏い、業務効率化の取り組みにClaudeDeskTopを取り⼊れる動き現状チームごとにスタイルは異なるものの、 Claude Code/ClaudeDeskTopは開発現場からビジネス側にも波及しつつあり、多様な形で浸透しているのが現状 7

Slide 10

Slide 10 text

私とClaude Code 使⽤経緯今年の1⽉頃からCursorをメインに使⽤ • Claude CodeのProプランが出たタイミングで乗り換え • それ以来、コードはほとんどClaude Codeに書かせる形がメイン乗り換えの理由実際に使ってみたときのアウトプット精度がCursorとまったく違うと感じたため現状、ほぼClaude Codeを主軸にしながら、開発フロー全体を回しています 8

Slide 11

Slide 11 text

今年の1⽉頃からCursorを使⽤して感じたこと 10

Slide 12

Slide 12 text

今年の1⽉頃からCursorを使⽤して感じたこと Cursorの導⼊により、時間短縮と効率が⼤幅に向上タスク所要時間の⼤幅短縮 Cursor導⼊後、これまで2〜3⽇かかっていた実装が、わずか1〜2時間 2週間くらいかかるであろうタスクも1⽇2⽇くらいで対応できるように開発プロセスの劇的な加速ユーザーからの要望対応や、バグ修正の作業が劇的に速くなる体感では5倍くらいのスピードアップ実装コストは⼤幅減少→実装以外の開発フローがネックに！ 1

Slide 13

Slide 13 text

チームでの「実装以外の開発フロー」の課題 11

Slide 14

Slide 14 text

スピード出ない！ドメインの知識や現場の⽂脈理解など「コンテキストが膨⼤」なタスク要望の判定要望のやるやら判定‧優先度付け仕様策定要望をどう仕様に落とし込むかデザインデザインのプロセス 12

Slide 15

Slide 15 text

実装以外がよりボトルネックに Claude Codeの導⼊により実装コストが激減したことで、実装以外のフローがより⼀層ボトルネックに 13

Slide 16

Slide 16 text

Claude Codeでどこまで⾃動化できるか？実験してみた要望の判定要望のやるやら判定‧優先度付け仕様策定要望をどう仕様に落とし込むかデザインデザインのプロセス 14

Slide 17

Slide 17 text

あくまで！実験背景 • ツールやtipsが乱⽴し、Claude Codeも進化し続けている • 「これが標準フローだ」と決め打ちするのは現実的ではないアプローチ • 何がうまくいくか、どこで失敗するかは、実際に試してみないと分からない • 「これはAIに任せた⽅が速い」「これは⼈間がやった⽅がいい」といった境界を探す必要がある "失敗上等で最適解を⾒つける"というチームでの共通認識今回ご紹介する取り組みも、SEN全体の標準ではなく、私のチーム内で⼩さく進めてきた実験です 15

Slide 18

Slide 18 text

実験で夢⾒ていたことこの実験の開始時要望の判定、仕様策定、デザイン、テスト、さらにはプレスリリース作成まで、開発フロー全体をClaude Codeで⾃動化できるという壮⼤な夢を抱いていた 1

Slide 19

Slide 19 text

ということでチーム内で進めてきた実験について、失敗なんかうまくいきそうな予感いいかも… などなど、チームで経験したので共有します！！ 1

Slide 20

Slide 20 text

実験1: ユーザー要望のやる‧やら判定の⾃動化 17

Slide 21

Slide 21 text

チームの開発フロー 18

Slide 22

Slide 22 text

弊チームの開発フロー 1. 要望受け取りカスタマーサクセス＆サポートチームがユーザーから要望を受け取る 2. やる∕やらない判定開発チーム＋CSチームで「やる∕やらない判定」を⾏う 3. 仕様確定「やる」と決まった要望は、開発＋CSで仕様を固める 4. デザイン検討並⾏してデザインを検討する 5. 実装実装へ進む実験1「ユーザー要望のやる∕やらない判定の⾃動化」 19

Slide 23

Slide 23 text

やる‧やら判定の課題課題：意思決定のための情報収集＆認識合わせで時間が溶けるやる∕やらない判定段階では様々な観点で検証するため、その都度情報を収集するために多くの時間が必要「この機能って、どれくらいのユーザーにどれくらい使われてるっけ？」「他の要望ってどんなのがあるっけ？」「この機能の実装って、結構複雑じゃなかった？」「これを実装すると困るユーザーはいそう？」 20

Slide 24

Slide 24 text

どうしたか？会議の前にClaude Codeですべて情報収集させちゃえ！！会議で質問をゼロにするのだ！！ 21

Slide 25

Slide 25 text

.claude/構成での情報⾃動収集 22

Slide 26

Slide 26 text

具体的な⾃動アウトプット競合調査主要な競合サービスの同等機能の有無や仕様機能利⽤率集計各機能がどれくらい現場で使われているか、利⽤率集計他現場の要望集約 zohoの要望を横断的に抽出‧グルーピング UI‧画⾯構成の確認対象機能の画⾯キャプチャや導線、操作⼿順を⾃動で整理ソースコード‧技術的影響の可視化対象機能の実装箇所や関連ロジック調査 Playwright mcpやDuckDBを活⽤しながら情報を整理していく 23

Slide 27

Slide 27 text

例） 24

Slide 28

Slide 28 text

ユーザーの要望調査.yaml 22

Slide 29

Slide 29 text

ソースコード調査.yaml 22

Slide 30

Slide 30 text

うまくいったの？ 24

Slide 31

Slide 31 text

実験結果：⼤幅な効率化に成功！ Claude Codeが⽣成したドキュメントを会議で活⽤することで、以前情報収集に費やしていた時間がほぼなくなり、意思決定のスピードが⼤幅に向上情報収集時間情報収集に要する時間、⼤幅減 Claude Codeではわからない CSチームの知⾒やユーザーの声を共有する時間に判定スピード意思決定のプロセスが⼤幅に加速判断材料は揃っているので、納得感のいく判断をスピーディーにできるになった会議の質会議が「意思決定」の場に！情報不⾜で決めきれないがなくなり、さくさくと意思決定できるようになった 25

Slide 32

Slide 32 text

定量的な効果会議でどれくらい意思決定のスピードが向上したかというと、体感で約3〜4倍の効率アップに。今後はもっと早くなりそう以前の会議 30分の会議で、1つの要望の「やる∕やらない判定」を⾏うのが限界でした。 • 情報収集と認識合わせに時間がかかっていた • 議論が発散し、意思決定まで⾄らないこともあった Claude Code導⼊後同じ30分の会議で、3〜4つもの要望を裁けるようになりました。 • 事前に情報が整理されているため、本質的な議論に集中できる • 意思決定の質を落とさずに、圧倒的なスピードアップを実現 1

Slide 33

Slide 33 text

はじめからうまくいったの？ 26

Slide 34

Slide 34 text

はじめからうまくいったの？全然うまくいきませんでしたw 27

Slide 35

Slide 35 text

なぜ、うまくいかなかった？まずは「⼀気に全部のドキュメントを⽣成させる」というアンチパターンを踏んだそれっぽいアウトプットは出るけど、資料としては使えないどうしたか？地道に…yamlを育てました！ 28

Slide 36

Slide 36 text

yamlの育て⽅分割要求定義、競合調査、利⽤率…それぞれをYAMLで細かく分割調整要求定義がうまくいくまで複数の要望で yamlを調整汎⽤化他のyamlも同じように、汎⽤的に要望を捌けるまで調整地道に改善を続けてyamlを育てることでようやく会議に耐えうるドキュメントが作れた 1

Slide 37

Slide 37 text

tips 30

Slide 38

Slide 38 text

tipsについては、こちらのブログにいろいろ書き書きしたので、割愛します！ 31 https://productblog.sencorp.co.jp/entry/2025/07/15/114455

Slide 39

Slide 39 text

Cursorでの試⾏とClaude Codeの成果 Cursorでの試⾏同様の⾃動化をCursorでも試みたが、結果は⼤きく異なった • 途中であきらめて、中⾝のないアウトプットをしている • 表⾯上は⽣成されても、資料として的外れなアウトプットが多い • 特に、深いコンテキスト理解が必要なタスクでは限界を感じたこの結果から、今回の開発フロー⾃動化においてClaude Codeが不可⽋な存在かなという判断 1

Slide 40

Slide 40 text

実験2: 仕様策定＆デザインの⾃動化 17

Slide 41

Slide 41 text

実験2: 仕様策定＆デザインやるぞ！仕様＆デザインフローの⾃動化やるやら判定はうまくいったぞ！それなら、これもいけるはず！！仕様書の⾃動⽣成デザイン前段階の情報整理（メンタルモデル作成） 33

Slide 42

Slide 42 text

実験2: アプローチ「やる‧やら判定」で収集した情報をもとに、以下の⾃動化を試みた。仕様書の⾃動⽣成「やる‧やら判定」会議で集約された情報から、要件定義書や詳細設計書を⼀括で⽣成することを⽬指した。デザイン前段階の⾃動化 UXデザインの初期段階として、ユーザーのメンタルモデルなどをClaude Codeに⾃動⽣成させ、それを基にデザインを進める実験を⾏った。「やる‧やら判定」での成功体験から、これらのドキュメントも⾃動⽣成できるという仮説を⽴てた。 34

Slide 43

Slide 43 text

先に結論！全然うまくいかなった！！w 実際の結果仕様書「それっぽい」だけ。 UXを考えるためのメンタルモデルも同じく「それっぽい」だけ実際にデザイナーにAI⽣成のメンタルモデルを渡したところ、かえって混乱を招いたむしろ⼈間がインプットして悩むという⼯数が増える 35

Slide 44

Slide 44 text

ここで気づく… 代替ではなく再設計が必要実験2の取り組みを経てはっきりしたのは、⼈間の作業をAIに代替させるアプローチはスジが悪い既存のフローを⾒直さないまま、部分的に⼈間の作業をそのままAIに置き換えようとしても、結局しんどい。 36

Slide 45

Slide 45 text

実験を通じて感じたこと ✗ 代替アプローチ既存の⼈間の作業をAIに置き換える → 効果は限定的メンタルモデル作成をAIに代替 → 事実確認とやり直しで⼯数増仕様書を作らせる → 結局、⼈間が⾯倒をみる必要がある ○ 再設計アプローチ AIを前提にプロセス全体を組み直す → かなり効果的 • 実験1: 情報収集の⾃動化による意思決定⾼速化 → 会議時間がかなり短縮そこで視点を変えました。必要なのは「代替」ではなく、AIを前提にしたフローの再設計 37

Slide 46

Slide 46 text

実験3: デモ駆動開発 17

Slide 47

Slide 47 text

デモ駆動開発デモを起点に進める開発フローエンジニアが完成形に近いデモをClaude Codeで作成し、それを叩き台に仕様やデザインを固めちゃう！ 1 1. デモ作成エンジニアがClaude Codeでデモを作成する 2 2. レビュー関係者全員でレビューを⾏う 3 3. 再デモフィードバックを反映して再デモを出す 4 4. 最終確認ステージングで完成度を確認し、最終確認を経てリリースする 38

Slide 48

Slide 48 text

デモ駆動開発に切り替えた背景 1 実装コストの最⼩化 Claude Codeを使えば仕様さえまとまっていれば実装コストを限りなくゼロに近づけられるという確信 2 ドキュメント基盤の整備「やる∕やらない判定」で、要件整理のドキュメントをかなりの精度で⾃動⽣成できるようになっており、すでにドキュメント⾯の⼟台は整っていた 3 合意形成の効率化デモをベースに議論を回すことで、ドキュメントだけでは合意形成が進みにくかった部分も、より具体的に、より早く固められるようになるのでは？と考えたからです。前提が揃ったことで、「デモを起点に仕様‧デザインを固めていく⽅が効率的」と判断 39

Slide 49

Slide 49 text

デモ駆動開発やってみて（まだ初めて3週間... 過去の試み AIに複雑な仕様やメンタルモデルを作成させるアプローチは、 • 「それっぽい」が実⽤に耐えない • 結局、⼈間の修正⼯数が増⼤ • かえって混乱を招くという課題に直⾯した。デモ駆動開発の解決策 Claude Codeを活⽤し、 • AIは⾼速プロトタイピングに注⼒ • ⼈間は具体的なデモで認識を統⼀ • ⼿戻りなく、創造的な議論に集中できる⼈間とAIの役割が最適化 40

Slide 50

Slide 50 text

デモ駆動開発tips 私たちのチームでは、デモ駆動開発を効率的に進めるため、こんな取り組みをしてます！⾮同期レビュー集まってではなく、メンバーで⾮同期にデモを確認しレビューガイドラインの活⽤共通‧役割別(PdM,デザイナー、CS)ガイドラインで、多⾓的な視点からデモを評価します。 Asanaでの記録と活⽤課題と改善案をAsanaに記録し、即時反映や今後の知識として活⽤意思決定の情報は徹底的に残してコンテキストとして活⽤できるようにする 41

Slide 51

Slide 51 text

今の課題 17

Slide 52

Slide 52 text

今の課題 1 ⼤型プロジェクトへの適応半年以上を要する⼤規模開発では、デモ作成前に検討事項が多く、現⾏⼿法では対応できる気がしない課題：初期検討をどのようにスピードアップするのか。 2 コンテキスト不⾜ CSやビジネスサイドの声、顧客フィードバックなどコンテキストをデモ実装時で活かしたいが、データ基盤が整ってない課題：知⾒を整理‧共有し、より良いデモに活かす仕組みをいかに構築するか。 1

Slide 53

Slide 53 text

最後にまだまだ実験中です！他のチームでも様々な実験を⾏っているため、少しでも興味を持たれた⽅は、ぜひカジュアル⾯談しましょうー！ 42