[Guild Plugin] Skillではなく組織を育てる

概要

Claude CodeのようなAIコーディングツールで開発を進めていると、コードは速く出てくるものの、すぐに別の種類の壁にぶつかります。そこで私は、AIともう少し体系的に開発を進めるためにSDD Pluginを作りました。GitHub Issueをベースに分析→設計→実装→テストの4段階を踏ませることで、分析なきコーディング・設計なき実装・会話の消失といった問題を防ぐClaude Code用プラグインです。

しかし実務で使い続けるうちに、もう一段上の問題が残っていることに気づきました。成果物(コード)は積み上がっていくのに、そのコードを作るツール自体は自ら良くなっていかないということです。この記事では、その問題が何だったのか、そしてそれを人間の働き方——すなわち組織——からヒントを得て解こうとした背景をまとめます。(そうして作ったツールが、このシリーズで紹介するGuild Pluginです。)

Guild Pluginのソースコードとインストール方法はdev-yakuza/deku-claude-pluginsリポジトリで確認できます。

この記事はGuild Pluginシリーズの第1部です。シリーズは以下のように続きます。

第1部. Skillではなく組織を育てる (この記事)

第2部. エージェント組織の構造と開発フロー

第3部. 成長エンジン①② — 成果物と開発者の共進化

第4部. 成長エンジン③ + 安全性 — 監督者(人間)も共に育つ

SDD Pluginの背景はAIコーディングの落とし穴と解決の方向性、全体構造はSDD Pluginの全体構造と使い方で扱っています。

SDD Pluginで得たもの

SDD Pluginは、AIコーディングにありがちな落とし穴をプロセスで防いでくれました。

分析なきコーディング → 要求事項を先に分析し、受け入れ基準(AC)を定めてから実装します。
設計なき実装 → 骨格(設計)を先に組み立て、テスターが実装を見ずに先にテストケースを書きます。
会話の消失 → 状態をGitHub Issue/PRに残すことで、セッションが途切れても続きから進められます。

おかげで「今回の作業」ははるかに体系的に進められるようになりました。しかしここには一つ、隠れた前提がありました。プロセスとスキル自体は、人間があらかじめきちんと作っておかなければならないということです。

ツールが成長しないという問題

AIとの開発を繰り返すたびに、私が何度も直面したのはこんな光景でした。

同じミスをプロジェクトごとに、Issueごとに繰り返します。(例:「この値はハードコーディングせず共通設定から取得すべきだ」と教えても、次回にはまたハードコーディングします。)
一度修正してあげても次のセッションでは忘れています。 会話は消え去り、スキルファイルはそのままだからです。
プロジェクトの慣習や落とし穴を、毎回人間が改めて説明し直す必要があります。
スキルを改善するには、結局人間が直接プロンプトや指示を手で書き直すしかありません。

まとめるとこうです。SDD Pluginは**「今回の作業をうまくやる」ことは助けてくれますが、「次の作業をもっとうまくやる」ことは依然として完全に人間の仕事のままでした。成果物は毎日積み上がっていくのに、その成果物を作るツールは自ら成長しません。** 改善が完全に人間の手作業に縛られているのです。

これがなぜ根本的な問題なのでしょうか。AIと共に開発する時間が長くなるほど、ツールもその経験の分だけ共に良くなっていくべきです。そうでなければ、私たちは毎回同じオンボーディングを、同じ修正を、同じ説明を繰り返すことになります。ツールが静的(static)なままでは、蓄積は起こりません。

人はどうやって成長し続けるのか

そこで問いを変えてみました。「スキルをどう管理すればもっとうまくいくか」ではなく、**「人はどうやって成長し続けるのか」**という問いです。

このヒントを得るために、私はソフトウェア開発組織を観察しました。そして、そこで見つけた共通点は次の通りです。

分業と専門家 — アーキテクト、テスター、レビュアー、セキュリティ担当のように役割が分かれており、必要なときに招集されます。
新人のオンボーディング — 新しい人が来てもプロジェクトの知識を引き継いで素早く合流します。
コードレビュー — 作った本人とは別の人が独立したセカンドオピニオンを出します。
振り返り — 何がうまくいき、何がずれていたかを振り返り、次に反映します。
人事(HR) — 得意な人は成長し、役割が合わない人は役割を変え、新しい人が必要になれば新たに採用します。
知識共有とドキュメント — 人が入れ替わってもドキュメントを通じて、あるいは引き継ぎを通じて知識が共有されます。つまり、人が変わっても組織の知識は残ります。

要点はこうです。組織とは、仕事をしながら、その仕事が残した痕跡によって自ら良くなり、メンバーが変わっても知識が残る構造だということです。良いチームが良い成果物を作り、その成果物の痕跡が再びチームを改善します。

「ツールもこうあるべきではないか」——これがGuild pluginの開発の出発点でした。

Guild pluginはレポ専用のエージェント組織

Guild pluginは、レポごとに専用のエージェント組織を生成するClaude Codeプラグインです。

/gld initを実行すると、そのレポを分析し、専用のギルド(組織)が作られます。ギルドマスターであるリーダーと、アーキテクト・開発者・テスター・QAをはじめとする役割エージェントたちが結成されます。開発フロー(分析→設計→実装→テスト→QA)は、この組織が協業して遂行します。

しかし、ここで終わりません。Guildは開発をしながら残した痕跡——人間による修正、差し戻し(revert)、繰り返される摩擦——を読み取り、組織自らが成長します。 繰り返し修正された内容は役割の習慣となり、発見されたコードの事実は組織の知識となり、テストでは捕まえきれないルールはゲートへと昇格します。

SDD Pluginが**「開発フロー」だったとすれば、Guildは「そのフローを遂行しながら自ら成長する組織」**です。Guildは、SDD Pluginの問題意識を受け継いだ後継であり、それを一段階一般化した結果でもあります。