■ 1. 記事の位置づけ
- インタビュー記録:
- 楽楽請求開発部でバックエンド開発を担当するメンバーへの取材記事
- 成功事例ではない:
- SDDを導入して4つの壁に当たった経緯の記録
- 一部メンバーがClaude CodeのPlanモードでの開発に戻りはじめた経緯の記録
- 打ち手を「SDDそのものの改善」から「SDDが回る環境の整備」へ切り替えるまでの現在進行中の記録
- 半年運用した結果:
- 実装そのものは速くなった
- 速くなったのは個人の作業であり、チームとして再利用できる資産は積み上がっていない
■ 2. SDD導入の背景と目標
- 自動化を目指す理由:
- 請求業務には毎月必ず締めがあり、制度改正への対応も期日が決まっている
- 顧客の業務を止められない以上、改善を早く届けられるかどうかがそのまま顧客への価値になる
- 着手のきっかけ:
- 社内の別チーム（楽楽明細・楽楽自動応対）で先行して成果が出ていた
- 全社としてAI活用を進める方針が出ていた
- cc-sddの採用理由:
- 既存の設計ドキュメントと開発プロセスを作り変えずに導入できる点を最優先で評価した
- 自社の工程やレビュー観点をSKILL追加だけで組み込める点を評価した
- 既存のプロダクトコードを起点に整合性を検証する仕組みを持つ
- 稼働中のサービスに既存プロセスを活かしたままSDDを入れる狙いに最も合っていた
- 掲げた目標:
- 昨年度の下期から「AIによる実装の完全自動化」を目標に掲げた
- AIの進化が伴わなければ達成は難しい目標だと認識していた
- 具体的にイメージできる目標を示さなければチームが同じ方向を向いて動きにくいため、あえて掲げた
- 目標へのチームの反応:
- 反対意見はないが、前のめりに聞いてくれるメンバーもいない状況だった
■ 3. cc-sddへの5つのカスタマイズ
- 前提:
- 標準構成のままでは自社の開発プロセスに乗らなかった
- 設計書のレイヤー分割:
- 標準では設計を1枚の design.md にまとめる
- これをDB設計、ドメイン設計、API設計、その他設計の4ファイルに分けた
- レイヤーごとにレビュアーが異なるため、各自が担当領域だけをレビューできる
- 完成した設計書から順にレビュー依頼を出せる
- 影響範囲の大きいDB設計を早期にレビューでき、リードタイム短縮と手戻りコスト抑制につながった
- 工程ごとのルール読み込み:
- 標準はプロダクト概要、技術スタック、ディレクトリ構成の3ファイルのみを前提にしている
- これだけでは命名規則やマイグレーション手順といった自社の規約が設計に反映されない
- DB設計規約、API設計規約、実装ガイド、テスト実装ガイド、用語集を各工程で必ず読み込ませるステップを足した
- 親子構成での機能分割:
- 1機能が数か月規模になるとタスクを管理しきれない
- 大きな機能を要件のまとまりごとに親子構成で分割できるようにした
- タスク管理のしやすさと、分業によるリードタイム短縮を両立させた
- AI向けと人間向けの分離:
- design.md はAIエージェント向けの記述であり、人間には読みにくい
- 情報量が増えるとAIコーディングエージェントのコンテキストを圧迫し、生成物の品質が落ちる
- design.md をAIコーディングエージェント専用と位置づけ、人間向けにHTML形式の設計書を別途生成する
- HTML設計書はコンテキストの制約から外れるため、図や表を使い分量を割いて丁寧に書ける
- 当初は詳細設計書の補助ツールという位置づけだった
- 開発者からのポジティブなフィードバックが多く、詳細設計レビューが最大のボトルネックだったため開発プロセス本体に組み込んだ
- 現在は詳細設計の担当者が、AIの生成した詳細設計書をレビューするタイミングでHTML設計書を生成している
- 独自スキルの追加:
- 仕様の分割、事前調査といった独自スキルを足していった
- 現在は43スキルを運用している
■ 4. 残った4つの壁
- 品質の再現性:
- AIの生成物は確率的であり、同じ指示でも実行のたびに違う結果が返る
- 壊れているのにチェックが通ったり通らなかったりする
- AIによる自動コードレビューでも結果が確率的なため、1回ですべての指摘を拾いきれない
- ルールを書いたから守られるという前提が成り立たない
- レビューの肥大化:
- レビューの総時間自体は大きく変わっておらず、当初の想定とは問題の所在が違っていた
- AIが生成する詳細設計書にはコードの断片が埋め込まれることがある
- レビュアーは詳細設計書のレビューに加え、コードレビューまで同じタイミングで行うことになる
- 従来は詳細設計フェーズとPRフェーズに分かれていた作業が一箇所に集中する
- レビューとフィードバックが直列につながり、結果としてリードタイムが長くなった
- チーム内からは、これを全部見るならコードを見てレビューした方が早いのではないかという声も出た
- 完了基準の不在:
- 設計書の完了基準が決まっていない
- レビュー負担を下げようとして、詳細設計書にコードを記述しない、行数を500行に制限するというルールを設けて失敗した
- 設計判断に必要な情報が欠落した
- 設計情報を聞き慣れない用語で圧縮したり、1行あたりの情報量が増えたりして、かえって認知負荷が高くなった
- 完了基準は「人がレビューしやすいか」と「AIハーネスとして機能するか」の両方から定義しないと決まらない
- 片方だけを見て基準を作ると、もう片方が壊れる
- プロセスの重厚さ:
- SDDのプロセスは重いため、小規模なタスクでは個別のツールを直接叩いた方が速い場合がある
■ 5. Planモード回帰への判断
- 現場で起きたこと:
- 4つの課題が残るなかで、Planモードのほうが実装は速いという声が上がった
- 実際にPlanモードで開発しているメンバーもいた
- 回帰自体は否定しない:
- Planモードへの回帰は悪いことではなく、個人の生産性には確かに寄与していた
- 引っかかった点:
- Planモードは設計内容等のコンテキストがセッション内に閉じるため、規模の大きい開発案件ではスケールしない
- 個人単位では生産性が上がる一方、成果や進め方が組織全体に展開されない
- チームとして再利用できる資産が蓄積されていかない
- 組織としてのスケールメリットが得られていないという点が判断の決め手になった
- 目指す姿からの逆算:
- 実装を自動化し、人間が上流工程へシフトするという姿を目指している
- そこから逆算すると、Planモードへの回帰による効果は限定的である
■ 6. 環境整備への方針転換
- 方針の切り替え:
- SDDのプロセス自体をいじり続けるのをやめる
- それが回るための環境を整える方向に戻す
- ナレッジ化:
- ハーネスと暗黙知を体系化し、レビュー負荷を軽減して品質を底上げする
- 対応する課題はレビューの肥大化
- 出力の安定化:
- 単一のAIに任せず、複数のエージェントが相互に評価し合う仕組みを整備する
- 対応する課題は品質の再現性
- プロセス設計:
- SDDフレームワークを再定義し、タスクごとの適用基準と詳細設計基準を策定する
- 対応する課題は完了基準の不在とプロセスの重厚さ
- 基盤整備:
- ローカル依存から脱却し、AIエージェントが自律的に並列稼働できる実行基盤を作る
- 対応する課題は自動化の前提
■ 7. レビュー指摘のナレッジ化
- 出発点:
- 暗黙知が多く、実装レビューでの指摘がなかなか減らないという問題があった
- AIに実装やコードレビューを任せるうえでも、暗黙知を形式知にして品質の再現性を高める必要があった
- PRのレビューコメントとIssueから繰り返し出ている指摘を集め、開発ガイドライン（Claude CodeのSKILL）に反映するパイプラインを社内リポジトリとして構築した
- 3段階の仕組み:
- 集める（fetch）ではPRのレビューコメント、Issue、Claude Codeのセッション情報を取得する
- パターン化して残す（ingest）では繰り返し出ている指摘をLLM用のWikiに蓄積する
- ガイドラインへ上げる（promote → 承認 → apply）では条件を満たした指摘をSKILLに反映するPRを作る
- 段階が進むほど情報が絞り込まれる
- 運用サイクル:
- パイプラインを週次で回し、月次で lint をかけて点検する
- 集める、パターン化して残す、lint というアイデアはAndrej Karpathy氏の「LLM Wiki」と呼ばれるパターンを採用した
- 残す指摘の線引き:
- 知識層に残すのは、確定した方針やルールがある指摘だけとする
- 却下された指摘は残さない
- 後続PRで対応と先送りされたものは残さない
- 返信がないまま流れたものは残さない
- 未マージPR上の指摘は残さない
- 判断に迷うものは残さない側に倒す
- 線引きの理由:
- 直した証拠も決めた方針もない指摘をページにすると、実際には守られていないルールを知識として登録してしまう
- 知識層はAIが読む前提の場所である
- 守られていないルールが溜まるほど、AIの実装がチームの実態から離れていく
- SKILL昇格の3条件:
- 反復性は、同じ指摘が3回以上かつ指摘者が2名以上であること
- 是正実績は、実際に修正コミットが発生していてかつ2回以上であること
- 障害起因は、incident / postmortem ラベル付きIssueの再発防止策なら1回で候補とすること
- 条件を置いた理由:
- 上がってきた指摘をそのまま採用すると、内容が具体的すぎたり個人の設計スタンスが反映されたりする
- その結果、AIのコーディングルールが膨大化して品質に影響する
- 複数の指摘があることで、ルール化しにくい暗黙知を抽象化できる
- 1人の指摘は個人の好みかもしれないが、2人以上から同じ指摘が出ていればチームの規範として扱える
- ルールが増えすぎて誰も守らなくなる事態を、この線引きで避ける
- 人間に残した仕事:
- 取得、抽出、執筆、起票はAIが行う
- 人間に残したのは承認とマージの2つだけである
- 全自動にしない理由は、AIの出力がまだ承認なしで採用できる品質に至っていないためである
- 現時点ではAIが提案してPRを作るところまでを自動化し、直接pushや自動マージはしない
- LLMの進化には期待している
- スキルの配布:
- 別の社内リポジトリをClaude CodeのPlugin Marketplaceとして機能させ、/plugin install で各開発者に配布する
- 自動更新を有効にすると、セッション開始後にバックグラウンドで最新のスキルを取得する
- 次にClaude Codeを立ち上げた時点で反映され、各開発者が手動で更新する必要はない
- リポジトリを用意したのは、AI活用の事例を個人に閉じさせない文化を作るためである
- 試して改善効果が得られた内容を共有する文化を作りたかった
- 全員が共有すると開発プロセスに組み込まれているものとの区別がつきにくくなる
- そのため、安定運用の tools と試験運用の labs に分けている
■ 8. 現状の到達点
- 運用は道半ば:
- 知識層のwikiには現在およそ700件が蓄積されている
- SKILLへの昇格は20件程度であり、運用が十分に回っているとは言えない
- 週1で回す設計にしているが、そのサイクル自体をまだ回しきれていない
- 選別の負荷:
- スキル修正提案のPRも大量に来ている
- AIが投げたものと人が投げたものが混在し、チームで手分けして選別している
- 工数削減の状況:
- 詳細設計と実装の工程を対象に集計を始めており、段階的な削減を目標に置いている
- 手応えは出はじめているが、継続して再現できるかはこれからの検証次第である
- 横展開の課題:
- スキルの中にチーム固有のファイルパスやリポジトリパスが多く含まれている
- 汎用的に使ってもらえる形にするには、もうひと段階のハードルがある
■ 9. これから
- 基盤整備の現状:
- クラウド環境（Claude Code on the web）上での自動実装には対応済みである
- 完全な並列実行には至っていない
- 実行環境の制約でビルドやテストの実行が難しい
- 代替案として、クラウド環境で実装してPRを作成する進め方を採っている
- CIでテストを実行し、結果を監視して修正する
- 中長期的な戦略:
- LLMの進化は速いため、それを見据えてAI駆動開発の中長期的な戦略を立てるべきである
- 目の前のプロセスを改善し続けても、半年後には前提が変わっているかもしれない
- 現在地:
- 品質の再現性、レビュー、完了基準、プロセスの重さという4つの課題がある
- この4つを同時に潰す「環境」をいま整えている途中である