AIに書かせ 人で磨き チームで回す 仕様駆動開発

ハッカーズチャンプルー2025のLTです

Transcript

1. © Scalebase Inc. 2025/08/02 Hackers Champloo 2025 AIに書かせ ⼈で磨き チームで回す 仕様駆動開発
2. © Scalebase Inc. はじめに ⾃⼰紹介 村濱 ⼀樹（Kazuki MURAHAMA）むらー/mura- • Scalebase株式会社 執⾏役員 VPoE プロダクト部⾨⻑ • X: @muraaaaa_san 2011年に⼤⼿通信設備会社にネットワークエンジニアとして ⼊社。その後、ウェブシステム開発会社に転じフルスタック開 発や、開発プロセス改善に従事。 2015年に独⽴、SaaSを利⽤したアジャイル開発を中⼼に活動 するとともに、エンジニアコミュニティにも積極的に参加‧⽴ ち上げ。 2019年にアルプ株式会社（現:Scalebase株式会社）に⼊社 し、開発およびエンジニアリングマネジメントを担当。 現在はプロダクト開発全般を管掌。
3. © Scalebase Inc. 提供するプロダクト ⾒積〜請求/決済〜収益管理を⼀気通貫で網羅 サブスクリプションビジネスのための販売管理システム「Scalebase」
4. © Scalebase Inc. サブスクリプションビジネスにおける主な課題を解消します！ 成⻑の先にある販売管理業務の複雑性 • ユーザー数の増加や提供プランの多様化といった サブスクリプションモデル特有の課題 • 料⾦体系の複雑化（⽇割、請求サイクル、利⽤量 に応じた従量課⾦）、アップ/ダウンセル、割引‧ キャンペーン適⽤などが発⽣ • 「契約期間」というサブスクリプションビジネス 特有の概念での管理の必要性 既存の仕組みでは乗り越えられない壁 • 請求計算ミスや売上計上漏れのリスク増⼤、これ による顧客不満や機会損失 • 新しいプランやモデルを試したい時に、システム 側の制約で迅速に実⾏できない • サブスクリプションビジネス特有の重要指標が正 確に把握できない • 業務プロセスごとにシステムが分断され、データ ドリブンな意思決定につなげられない 業務⼯数の増加 属⼈化 請求ミスの リスク 事業成⻑への ブレーキ データ管理の ⼀元化
5. © Scalebase Inc. © Scalebase Inc. みなさんAIを開発に どのように活⽤していますか？
6. © Scalebase Inc. よくある失敗パターン • 出⼒の質がバラバラ、曖昧なインプットが多い • 幻覚や抜け漏れが発⽣しやすい • 個⼈で完結しがち → チームに知⾒が回らない • ナレッジが残らない / 平準化できない コードをLLMに書かせたが、要件がもれていたり、思ったのと違うコード/成果物がでて結局⾃分で書き直し… →課題の定義が曖昧なまま進めてしまうのが原因。これはAIにお願いしやすいからこそ起こることでもある LLMをそのまま使うと微妙なことが...
7. © Scalebase Inc. 課題（Issue）の定義からAIにやってもらう 1. ClaudeCodeにIssueを作らせる a. 対話的に要件ヒアリング b. 類似Issueの確認、コード調査 c. Issueテンプレートに準拠して⾃動⽣成 2. GitHubにIssueを登録 3. 朝会や定例でチームが吟味‧修正 4. 問題なければ実装へ a. 実装⽅法はAIでも⼈でもOK いきなり開発をまかせるのではなく、 AIと⼀緒に要件考えることからスタートして、 なにをやるかをきっちりIssueに書く 解決策：Claude Code × ISSUE駆動フロー 要件定義 /仕様策定 Issue登録 確認・修正 実装
8. © Scalebase Inc. 下記をClaude Codeで実⾏させる • 類似のIssueがあるか検索 • 疑問点を質問し、コードを調査して反映 • .github/ISSUE_TEMPLATE/* から適切なテンプレートを選択 • 要件に応じてIssueを更新（コード断⽚や参考実装を含む） Claude Codeが⾏うこと（詳細）
9. © Scalebase Inc. .claude/commands/create-issue.md --- allowed-tools: Bash(gh issue:*), Bash(gh pr:*) description: 要件を元に、issueを作成‧更新する --- # create-issue - 対話的に要件（$ARGUMENTS）をヒアリングし、issueを作成‧更新する - 類似のissueが存在するか確認する - 疑問点は確認し、コードを調査し、実装予定の詳細をissueへ反映する - issueのフォーマットはテンプレートに準拠する - .github/ISSUE_TEMPLATE/* - 要件にあわせた適切なテンプレートを選択する create-issue コマンド定義（.claude/commands/create-issue.md）
10. © Scalebase Inc. © Scalebase Inc. 実際にやってみる
11. © Scalebase Inc. 実例 PDF表示部が狭いので 見づらい... 実際に⾒積もり作成画⾯のPDF表⽰部の修正をしてみる
12. © Scalebase Inc. 実際のコマンド例 実例：ClaudeCodeコマンド /create-issue （コマンド実⾏、既存Issueの検知） /create-issue PDFのプレビュー表⽰領域を⼤きくしたい [Image #1] ⏺ 既存のIssue #1521が⾒つかりました！この issue はあなたのリクエスト「PDFのプレビュー表⽰領域を⼤きくしたい」と完全に⼀致する内容で す。 既存Issue #1521の内容 - タイトル: PDFプレビューの表⽰サイズ改善：6:4表⽰‧フルスクリーン対応 - 状態: オープン（未実装） - 提案内容: a. 6:4⽐率での表⽰改善 b. フルスクリーン表⽰機能の追加 次のステップをお選びください： 1. 既存Issue #1521をそのまま使⽤ - 既に詳細が記載されているため 2. 追加要望があれば既存issueにコメント追加 3. 新しいissueとして別途作成 - 異なる要望の場合 ClaudeCodeの出⼒（既存Issueを検知） 曖昧な依頼でも、咀嚼し、 既存のIssueをまずは探してきてくれる 今回は3の新しいIssueを作成する
13. © Scalebase Inc. 実例：ClaudeCodeコマンド /create-issue（Issue作成のための要件ヒアリング） ⏺ Issue作成のための要件ヒアリング 利⽤可能なテンプレートを確認しました： - 🔧 改善タスク (improvement_task.yml) - 既存機能の改善⽤ - ✨ 機能開発 (feature_request.yml) - 新機能開発⽤ 「PDFのプレビュー表⽰領域を⼤きくしたい」という要望は既存機能の改善なので、改善タスクテンプレートを使⽤します。 詳細をお聞かせください： 1. 現在の状況‧問題点について： - どの画⾯のPDFプレビューでしょうか？（⾒積書作成画⾯、⼀覧画⾯など） - 現在のプレビューサイズはどの程度で、どのような不便さがありますか？ - この問題はどの程度の頻度で発⽣しますか？ 2. 改善提案について： - どの程度⼤きくしたいですか？（具体的なサイズや⽐率） - レスポンシブ対応は必要ですか？ - フルスクリーン表⽰機能は必要ですか？ 3. 確認⽅法： - 改善後、どのような操作で確認できれば良いでしょうか？ これらの情報をもとに、適切なissueを作成いたします！ テンプレートを判断し 詳細を対話的に確認
14. © Scalebase Inc. Issue作成完了メッセージ 実例：ClaudeCodeコマンド /create-issue（Issue作成） ⏺ ✅ Issue作成完了！ Issue #1524 を作成しました： 🔧 改善: ⾒積書作成画⾯のPDFプレビュー表⽰サイズ改善‧フルスクリーン機能追加 URL: https://github.com/xxxx/xxxxx/issues/1524 作成したIssueの内容: - 現在の状況: ⾒積書作成画⾯のPDFプレビューが⼩さく⾒づらい - 改善提案: プレビューサイズ拡⼤ + フルスクリーン表⽰機能追加 - 技術詳細: 実装場所やファイルパスを具体的に記載 - 確認⽅法: 実装後の動作確認項⽬をチェックリスト形式で明記 Issue作成フローのポイント: 1. テンプレート確認 → 改善タスク⽤テンプレートを選択 2. 要件ヒアリング → 具体的な要望を詳細に聞き取り 3. コード調査 → 実装箇所を特定して技術的詳細を追加 4. 詳細なIssue作成 → テンプレートに沿って構造化された内容で作成 これでIssue作成の流れが完了です！ ヒアリングと調査を重ね 最終的にIssueを作成
15. © Scalebase Inc. 簡単な指⽰だけで実際にIssue を起票してくれている 調査も含めているため、どこ を直すか、あたりをつけるこ とができ、⾒積もりの精度も あがる
16. © Scalebase Inc. © Scalebase Inc. 何がかわったか？
17. © Scalebase Inc. 朝会や定例での確認フロー • 朝会や定例でIssueを確認 • 必要に応じて修正‧優先度調整 • 間違っていたら再度指⽰をしていいし、⼈がIssueを修正してもOK • 思ったより⼤規模になる場合優先度を下げるなどコントロールしやすい • Issueに⼀度書き出すことで、個⼈で閉じない • プランや課題が正しいかをチームで確認できる • 「なぜその解決策なのか」をレビューできる • 知⾒が共有され、ナレッジとして残る • 意外な落とし⽳に気づき、⼿戻りがすくなくなる セーブポイントとしての役割 • ここを起点に次のフェーズに進める • チーム全体で前提‧背景が揃う Issue作成後のチームの関与ポイント
18. © Scalebase Inc. 個⼈がインプット→LLMアウトプットで完結していた流れを、ISSUEで⼀度「⾒える化」することがポイント。 セーブポイントとして区切ることで、安⼼して前に進める。 実装⽅法の選択肢（例） • A. ⼈⼿実装（Human-first） • コアドメイン∕⾼リスク変更時は⼈間が中⼼ • 受け⼊れ基準に基づき設計→実装、LLMは補助的に利⽤ • B. ClaudeCode主導（Plan→Diff→PR） • /plan-from-issue や /implement-issue などコマンドで⾃動化も可能 • PR作成、テスト結果も⾃動反映 • C. Cursor / Copilot 等IDEアシスト • ⼩規模改修やUI変更など既存パターン踏襲の作業に向く • Issue本⽂をエディタに貼り付けてEdit適⽤ • D. Devin 等のエージェント型 • 調査→設計→実装→検証を⾃動化。 • Devinの場合は複数のリポジトリにまたがることもやりやすい • E. 混合（Pair/Mob + AI） • 不確実性が⾼いタスクはペア/モブ作業＋AIのサンプル実装 Issue精査後：セーブポイントからの実装の分岐 弊社の場合は、Claude Code ActionやDevinにやってもらう ことが多い 少しずつ進みながら考えたい 場合はCursor利⽤など、⼈間 がドライバーになる
19. © Scalebase Inc. Before： • 各⾃がIssueを拾う → LLMを使ってコード⽣成 → バラバラ、後戻り多発 • 知⾒も共有されにくい After： • ClaudeCodeがIssue化 → Issueをチームでレビュー‧修正 → セーブポイントから分岐して開発 • 正しいインプットが揃うのでコードの品質も向上 • やる‧やらないの判断、⽅向修正ができる • Issueによって最適な⼿段を取れる • Issueがナレッジのハブになる • 結果、チーム全体の⽣産性が底上げされる LLMのコードアウトプットの質はインプット次第。 Issueでセーブポイントを設け、チームで共有‧確認してから進めることで精度とスピードが上がる。知⾒もたまる。 まとめ‧Before / After
20. © Scalebase Inc. • ここでは説明してませんが、実装と確認までLLMにやってもらっています • Issueの作成は、ClaudeCode以外からもできるように考えており、営業や顧客からの要望からシームレスに Issueを⽴てれるように計画中です • ボトルネックになりがちなコードレビューも改めて⾒直しています 今後の展望
21. © Scalebase Inc. © Scalebase Inc. Thank you 🙇