自社でエージェント「Build Club」を立ち上げるための実践ガイド
私たちは「Build Club」を2ヶ月間運用してきました。今や社内で最もインサイトが得られる週に1時間の取り組みとなっており、他社でも真似するのは本当に簡単です。
毎週金曜日の午後、20名ほどの DataRobot 社員が オンライン上に集まります。誰かが画面を共有し、コードを叩き始めます。スライドも、デモ用のスクリプトも、最初の10分間以外の議題（アジェンダ）すらありません。たまに音楽なしの3分タイマーが鳴り、初めて参加する人を驚かせるくらいです。
この記事は「Build Club」の運用プレイブック（実践ガイド）です。もしあなたの組織でもこのような取り組みを検討してきたが、未だ踏み出せずにいるのなら、そのハードルは思っている以上に低いものです。必要なものは、定期的なスケジュール管理、Slack チャンネル、そして Google ドキュメントの3つだけです。
エージェント「Build Club」とは何か？
Build Club は、毎週開催される自由参加（ドロップイン）のセッションです。1人の「ドライバー（作業を進める人）」が画面を共有し、選択したプラットフォーム上でライブでプロダクトを構築します。他の参加者はそれを見守りながら、提案したり、ツッコミを入れたり、手助けをしたりします。ドライバーは事前に準備をしません。ユースケースは最初の10分間で参加者が決めます。そして、終了時点でプロダクトが正しく動作していなくても構いません。これらは不具合（バグ）ではなく、すべて狙い通りの設計（デザイン）です。
最も近い概念は Twitch のライブ配信ですが、チャット欄がプロダクトに対する持論を持った同僚たちで埋め尽くされている点が異なります。社内のイベントで例えるなら勉強会が近いですが、誰もプレゼンを行わず、参加者全員が主体性を維持したまま進行します。
これが機能する理由は、企業における従来の技術ナレッジ共有のあり方を逆転させているからです。一般的な社内デモは、綿密に準備され、スクリプト化された一方向的なものです。一方、Build Club は洗練されておらず、即興的であり、良い意味での対立関係を生み出します。ドライバーはリアルタイムで思考や作業を晒し、観客も巻き込まれます。結果として全員が、顧客が直面するのと全く同じ解像度で、プラットフォームの魅力、使いづらさ、そしてその回避策を理解して、業務に戻ることになります。
エージェント開発において、なぜこのフォーマットが効果的であるのか
その理由は、重要な順に以下の3点に集約されます。
- 「鑑賞」より「構築」が勝る
どのようなプロダクトであれ、手応えを得るための最高のアプローチは、自分自身が関心を持つ課題に対して実際に使ってみることです。ドキュメントやデモ、研修動画などは、隣に誰かがいる状態で手動で手を動かす45分間の価値には到底かないません。組織がエンジニア向けのプロダクトを販売・サポート・マーケティングしている場合、その現場に携わる人々が日常的にプロダクトを使って構築（Build）を行う必要があります。Build Clubは、それを実現するための最もコストがかからない手段です。 - 部署を超えたコラボレーション効果（クロスファンクショナル・エフェクト）が自発的に生まれる
エンジニア、PM、セールスエンジニア、マーケター、そしてセキュリティ担当者が同一のセッションに同席することで、即座のプロダクトフィードバックや「なぜこのような仕様になっているのか？」という迅速な対話が生まれ、部署間の連携漏れが減少します。これらを個別にスケジュール調整する必要はありません。ビルドの場さえ用意すれば、自然と議論が発生します。 - 仕様書では見えてこない課題が表面化する
他の3名のエンジニアが欠けているUXについてコメントする中、誰かが自身の個人のSlackボットへリアルタイムにPII（個人情報）ガードレールをデプロイする様子を観察することは、どのようなユーザーテスト（UX調査）よりも価値のある情報となります。微細な使いづらさ（ペーパーカット）を洗い出す基準は、「ドライバー（作業者）がそこで詰まったか否か」だけです。この基準は、Jiraチケットを切るよりも遥かに低いハードルでクリアできます。
エージェント「Build Club」の具体的なフォーマット
全体で60分間とし、3つのセクションに分割して進行します。
0分〜10分：セットアップと投票
ホストがセッションを開始します。担当のドライバーが決まっている場合は自己紹介を行います。ホストは共有の Google ドキュメントを画面に表示します。ドキュメントには、あらかじめ用意されたアイデアと、ミーティング中にライブで追加されたアイデアのリストが並んでいます。参加者は、プラス記号（+）や絵文字のリアクションなど、使用しているツールに応じた方法で投票を行います。最も多くの票を獲得したアイデアが採用されます。この作業には文字通り3分間のタイマーを使用します。絶妙な緊迫感が生まれ、これが非常にうまく機能します。
10分〜55分：ビルド（構築作業）
ドライバーが画面を共有し、構築作業を開始します。参加者は質問を投げかけたり、次のステップを提案したり、バグを指摘したり、脱線した話を楽しんだりします。脱線は基本的に問題ありません。ドライバーは作業を進めながら緩やかに実況（ナレーション）を行います。行き詰まった場合は声に出して助けを求め、参加者がそれをフォローします。ビルドを完成させることは求められておらず、何かしら興味深い出来事が起こることが期待されます。
55分〜60分：振り返り（デブリーフィング）と引き継ぎ
ドライバーは、構築したもの、失敗したこと、驚いた点を要約して発表します。ホストは次回のドライバーが決まっている場合は発表し、決まっていない場合はボランティアを募ります。誰かが Google ドキュメントに録画リンクと、「今回構築したもの」を1行でまとめた内容を更新します。以上でミーティングは終了です。
これだけです。スライド資料も、決まったテンプレートも、ドキュメントに貼り付けられた内容以上の事後レポートも存在しません。
社内でエージェント Build Club を立ち上げる方法
もしあなたの組織でこの取り組みを始める場合は、以下の手順・順序で進めてください。
日時を固定し、それを死守する
開催曜日と時間を決め、それを崩さないでください。参加率よりも一貫性が重要です。最初のセッションの参加者は少数でしょう。2回目はさらに減るかもしれません。しかし、4回目あたりから参加者が定着し始め、8回目にもなれば開催されることが当たり前になります。「6人しか参加登録（RSVP）していないから」という理由でキャンセルすると、このプログラム自体を潰すことになります。6人でも、ななら3人でも実施してください。その「枠」を守り続けること自体が資産です。
私たちは金曜日の午後に開催していますが、これは意図的に「エネルギーの低い時間帯」を狙ったものです。金曜の15時に没頭して深い作業をする社員はいません。しかし、午後のコーヒーを飲みながら、誰かが何か面白いものを構築するのを眺めるくらいなら喜んで参加してくれます。組織の中で、集中作業が一段落するような時間帯を選んでください。
告知したくなるような名前をつける
これは一見くだらないことのように思えますが、非常に重要です。Build Clubの第1のルールは「周囲全員にBuild Clubについて話すこと」ですが、名前が「AIアワー」や「プラットフォーム試行錯誤タイム」のようなものだと、このルールを徹底することはできません。名前は具体的で、少しユーモアがあり、廊下の雑談で耳にした人がSlackチャンネルをすぐに検索できるくらい記憶に残るものにする必要があります。「Build Club」という名称が機能しているのは、人々が口々にリピートしやすい名前だからです。
Slackチャンネルを開設する
チャンネルは二重の役割を果たします。ミーティング前はアイデアを投下する場となり、ミーティング中は（Web会議ツールのチャット機能だけでは収まりきらない）溢れた会話の受け皿になります。そして終了後は、録画アーカイブや振り返りがストックされる場所となります。チャンネルの概要欄（ピン留め）には、カレンダーの招待リンク、Googleドキュメント、そしてルールを貼り付けておきます。ルールは3つ以内に抑えてください。
社内Slackでは #build-club というチャンネルを用意していますが、DataRobotのコミュニティSlackにも同様のチャンネルがあります。自分の組織で始める前にブレインストーミングをしたい場合は、そこが最適です。チャンネルは週1回のセッションと残りの時間をつなぐ架け橋となるため、第1回目のセッションの後ではなく、「前」に開設しておく価値があります。
最初の数回分のアイデアをあらかじめ準備しておく
参加者の誰かにとって実用的なユースケースを用意してください。仮説上の話や現実味のないデモではなく、ドライバー自身がその成果物を本気で欲しがっているような内容です。私たちの第1回セッションでは、DataRobotのエンジニアリングリーダーであるCarsonが、自身の未読DMを整理するためのデジタルツインSlackボットを構築しました。このユースケースは彼にとって紛れもない「現実の課題」でした。
「Slackの課題を抱えています。今、未読DMがどれくらいあるか見てみましょう。Slackの個人DM、グループチャンネル、スレッドのメンションを合わせると284件の未読があります。これは問題です。」
「誰かにとってリアルであること」が基準です。誰かのリアルな課題に基づくアイデアがないのであれば、それはまだBuild Clubではなく、ただの「スケジュールの枠」に過ぎません。
最初のドライバーを指名する
始まったばかりのプログラムで、見知らぬ人を巻き込んでドライバー（作業者）になってもらうのは至難の業です。まずはチーム内で、普段から趣味でモノづくりを楽しんでいる人を見つけ、最初のドライバーを務めてもらうよう依頼してください。伝え方さえ正しければ、快諾してくれるはずです。アプローチのコツは「普段プラットフォームで面白いものを構築しているよね。それを観客がいる前で続けてみない？」と伝えることです。Carsonは誰に頼まれたわけでもなくCarson-as-a-Service（CaaS）を個人的に構築していました。私たちがしたことといえば、彼に1時間の観客（聴講者）を提供しただけです。
構築を許可する対象（プラットフォーム）を決める
構築にはDataRobotプラットフォームを使用することをルールとして義務付けています。これは意図的な制約であり、私たちの「3つのルール」の2番目に該当します。使用するプラットフォームを固定しないと、脱線（ドリフト）が避けられなくなります。誰かが業務と全く関係のないサイドプロジェクトに1セッションを費やしてしまい、部署を超えた学びの効果が薄れてしまうからです。この制約がプログラムの価値を守ります。あなたの組織におけるプラットフォームを決めてください。
3つのルール
ルールはあえて短く保っています。3つを超えるものはすべて「規程文書」になってしまうからです。
- Build Clubについて周囲全員に話すこと。
- 指定のプラットフォーム上でプロダクトを構築すること。
- 時間内に完成（動作）しなくてもよい。
ルール1はマーケティングの役割を果たします。ルール2はプログラムを事業にとって有益なものに保つための制約です。そしてルール3は、ドライバーが気負わずに参加できるようにするための「免罰証（許可証）」です。社内のデモプログラムの多くが失敗に終わるのは、暗黙のうちに「デモは完璧に動かなければならない」という4つ目のルールが存在し、動くデモを準備するコストが、観客が得られる価値を上回ってしまうからです。このルールを取り払うことこそが、成功の鍵となります。
陥りがちな失敗パターン
私たちが直面しかけた、代表的な失敗パターンと予防策を紹介します。
フォーマットを複雑化（洗練）しようとする
誰かが「事前準備ドキュメント」「事後レポート」「構造化された振り返り」「Notionによる成果データベース」「ドライバーへのポイント制」などを提案してくるかもしれません。これらは一切役に立ちません。このフォーマットは、あえて極限までシンプルに作られています。プロセスを1層増やすごとにドライバーの負荷が上がり、引き受けてくれる人の数が減ってしまいます。インフラやルールを追加したい衝動には抗ってください。
ビルド（構築）を事前に録画・練習してしまう
善意から「セッションをスムーズに進めるために、ドライバーは事前練習をしておくべきだ」と提案する人が現れます。これはBuild Clubを中止するのと同義です。この取り組みの本質は「洗練されていないこと（ライブ感）」にあります。リハーサルを重ねたドライバーが行うのはただの「デモ」であり、デモなら社内にすでに溢れかえっています。
観客を身知らず（受け身）にさせてしまう
チャットがおとなしくなったら、ホストが働きかける（問いかける）必要があります。ドライバーに対して「なぜその選択をしたのか」を声に出して質問したり、部屋全体に向かって「同じ使いづらさを感じたことがある人はいるか？」と尋ねたりします。ドライバーが知らない知識を持っている特定の人を指名するのも効果的です。「助け手としての観客」こそがこのフォーマットの価値であり、少し「お節介」になれるホストがいなければ維持できません。
テーマを厳格にしすぎる
私たちはテーマ（生産性、セキュリティ、イネーブルメント、エンジニアリングツールなど）をゆるやかにローテーションさせ、シリーズ全体の文脈を作っています。ただし、テーマを厳密に強制はしません。事前に発表したテーマと全く関係のないユースケースに参加者の票が集まった場合、参加者の意見を優先します。テーマはあくまで「おすすめのメニュー案」であり、制約ではありません。
スキルでドライバーを自選（厳選）してしまうこと
毎週最も優秀なビルダーばかりをスカウトしたくなる誘惑に駆られます。彼らのセッションが一番見応えがあるからです。しかし、これは罠です。観客は「普通の人」がプラットフォーム上でつまずく姿も見なければなりません。なぜならそれこそが、実際の顧客が経験していることだからです。私たちのセッションでも、ドライバーが「自社プロダクトのこの部分の操作方法が全くわからない」と画面越しに認めることがありました。そうしたセッションこそ、完璧なセッション以上に有用なプロダクトへのフィードバックを洗い出してくれます。
期待できる変化（何が起こるか）
最初のセッションは不格好なものになるでしょう。ドライバーは思わぬところで詰まり、観客は様子見で遠慮がちになり、少なくとも1つのツールが誰も予想しなかった形で動かなくなります。これで良いのです。これこそがフォーマットの正しさを証明しています。初回のセッションが洗練されているとしたら、それは誰にとっても学びのないセッションだったということです。
4〜5回目のセッションを迎える頃には、二次的な波及効果（セカンドオーダー・エフェクト）が見え始めます。誰も正式なチケットを切っていないのにプロダクトへの改善要望が登録されたり、異なる部署のエンジニア同士がBuild Clubでの脱線話から派生したサイドプロジェクトで協力し始めたりします。また、アピール（露出）の機会を求めて、新入社員が自らドライバーに立候補するようになります。
2か月目に入る頃には、プログラムは自走し始めます。ドライバーの待ち行列は埋まり、Slackチャンネルには独自のカルチャーが生まれます。Googleドキュメントの「来週のアイデア」セクションは、誰かが促さなくても勝手に埋まるようになります。ミーティングの主催よりも、「どのアイデアに投票するか」を選ぶ方にエネルギーを使うようになるはずです。
何を使って構築すべきか
私たちはDataRobotの社員であるためDataRobotを使用しています。「自社プラットフォームを使用する」という制約が、Build Clubをビジネスの方向に合致させ続けるための重要なガードレールとなっています。どのプラットフォームを選ぶにせよ、基準は同じです。組織が実際に使用しているものであり、45分間で誰かが何か面白いものを組み上げられるだけの領域（機能・拡張性）を持っていることです。エージェントフレームワーク、MCPサーバー、LLMゲートウェイ、評価ツール、オブザーバビリティなど、エンジニアが現実の課題に対して接続・構築できるものであれば何でも対象になります。
次回以降の4つの記事について
本シリーズの残りの記事は、概念実証（Proof of Concept）となります。実際に行われたセッションに紐づく、テーマ別の4つのプレイバック（要約）をお届けします。
- 「生産性」: CarsonがSlackをリスニングするデジタルツインを構築し、誰かが偽のパスワードを送信した後に、カメラの前でリアルタイムにPII（個人情報）ガードレールをデプロイした回。
- 「イネーブルメント」: ZachがConfluenceのクリーンアップボットの構築を開始し、あらゆる大企業に溢れかえっている古い社内ドキュメントの整理に挑んだ回。
- 「エンジニアリングツール」: LukeとMadeleineが、手書きのツールを一切使わずにコードの所有権（コードオーナー）を監査するため、モノリポジトリにエージェントを接続した回。
- 「セキュリティ」: ShreyaとBrianが1時間かけて、VPNトラブルシューティング・エージェントに許可すべきこと・禁止すべきことの限界をストレステストした回。
これらのセッションには事前準備ドキュメントなど一切存在しませんでしたが、どれも現在私たちが使い続けている成果物を生み出しました。これこそが、この取り組みのすべての価値です。
Build Clubの第1のルールは、「周囲全員にBuild Clubについて話すこと」です。もしあなたの組織で始めるなら、どのように進んでいるかぜひお聞かせください。DataRobot コミュニティ Slack の #build-club に参加して、構築しているものを共有してください。ご自身で始める前に私たちの様子を見たい場合も、録画アーカイブやアイデアプールが同じチャンネル内に用意されています。
ファイト・クラブ（Fight Club）ではなく、ビルド・クラブ（Build Club）を始めましょう。