コラボレーション開発の再考：Tokyo Tech Leads Circleでの講演
Keenan ThompsonとPaul Consalviが、曖昧なアイデアからミッションに沿った実行へと変換する実践事例をTokyo Tech Leads Circle Meetup #14で発表しました。
2月9日（月）、東京大学大学院新領域創成科学研究科のPaul Consalvi教授と共に、Tokyo Tech Leads Circle Meetup #14で講演する機会をいただきました。Rethinking Collaborative Developmentと題した講演は、研究チーム向けのコラボレーションプラットフォームCollabojinを共に構築する中で得た実体験に基づくケーススタディです。
コラボレーションが壊れる場所
冒頭では、誰もが認識しながらもシステムとして対処されていない問題を取り上げました。優れたアイデアは、インサイトから実行への持続的な橋渡しがないために早期に消滅します。クレジットはアカウンタビリティから切り離され、目に見える貢献なしにオーサーシップが主張されます。そして、アイデアがある人の頭から別の人の手に渡るたびに、意味が失われていきます。
これらは単なる対人的な摩擦ではありません。設計上の失敗です。そして、私たちが一緒に仕事を始めた時にまさに直面した問題です。
実際の働き方
Paulはクリティカルシンキングとビジョンを持ち込みました。「意味のあるコラボレーション」とは何かを定義し、前提に疑問を投げかけ、アイデアを具体的なドキュメントに書き起こしました。私はシステム設計と実装を担当し、常に明確化のための質問を投げかけ、原則をプロダクトの挙動に変換し、各ステップで人間のレビューを伴いながらAIエージェントを積極的に活用しました。
これは理論的な演習ではありませんでした。プロダクトを共に構築するために開発したワークフローが、そのままプロダクトの設計パターンになったのです。
コミュニケーションはロッシー
私たちのコラボレーションから得た重要な知見の一つ：口頭でのコミュニケーションは意味を圧縮するということ。Paulにはビジョンがある。それを言葉にする。私はその言葉から絵を描く。しかしその絵は、元のビジョンと同一にはなりません。
解決策はシンプルでしたが、スピード重視のプロジェクトとしては意外なものでした—書き留めること。Paulにビジョンを詳細にドキュメント化してもらいました。そのドキュメントは私たち二人にとっても、ビルドを支援するAIエージェントにとっても共有コンテキストとなりました。彼の志はコードと共にコードベースの中に生きています。
Compound Engineeringの実践
私たちの作業はcompound engineeringのサイクルに沿って構成しました：brainstorm、plan、work、review、compound。brainstormフェーズでは、コードに触れる前に曖昧さを明らかにします。planフェーズでは、エージェントがコードベース、ドキュメント、制約を調査します。workフェーズでは、AIエージェントと人間の判断力を組み合わせます。reviewは複数の角度から行います—品質、セキュリティ、当初の意図からのずれ。そしてcompoundステップで意思決定を記録し、次のサイクルがよりスマートに始められるようにします。
リポジトリは単なるソースファイルではなく、組織の記憶となります。
プロダクトへの反映
計画したわけではありませんが、興味深い発見がありました。私たちのコラボレーションパターンがCollabojinの設計にそのままマッピングされたのです。一人の頭の中の曖昧な意図があった場所に、プラットフォームでは明示的なスコーピングを伴うイニシアティブパイプラインがあります。実装前の明確化のための対話があった場所に、プラットフォームではなぜをどのようにの前に揃えるオンボーディングの意図的な摩擦が組み込まれています。文書化されたコンテキストと共有メモリがあった場所に、プラットフォームでは貢献ログと透明な監査証跡が維持されています。
一緒に働くために必要なツールを作り、それが他の研究チームにも必要なものだったのです。
Collabojinの原則
講演では、プラットフォームを導く4つの原則を示しました。
ステータスよりスチュワードシップ。 学生がプロジェクトを管理でき、教授が貢献者になれる。役割は序列ではなく責任に基づきます。
意図的な摩擦。 プラットフォームは、実行に飛び込む前に目的を揃えるために必要最小限だけ減速させます。これは官僚主義ではなく、ミスアラインメントの複利的な悪化を防ぐための最小限のオーバーヘッドです。
透明なクレジット。 オーサーシップは目に見える貢献を通じて獲得され、事後に主張するのではなく、システムによって追跡されます。
レントシーキングの排除。 システムは設計によってクレジットの独占を阻止します。貢献なしにコラボレーションから価値を引き出すことはできません。
なぜ使い慣れたツールが重要だったか
Bun、React、Drizzle、PostgreSQL、Railway、Inngestという既知のスタックで構築しました。これはデフォルトの選択ではなく、意図的なものです。AIエージェントと集中的にコーディングする場合、使い慣れたパターンがあればエージェントのドリフトをより早く検知できます。パターンが体に染み付いているから、何かがおかしい時に気づけるのです。時間はツールの学習ではなく問題解決に使われます。そしてコンテキストが複利的に蓄積されます—各セッションは前回のセッションのAGENTS.md、ビジョンドキュメント、意思決定ログの上に構築されます。
Collabojinを試す
イベントでCollabojinを紹介したところ、その場で複数の参加者がベータ登録してくれました。研究コーディネーション、マルチステークホルダーのプロジェクト、あるいはアカウンタビリティとクレジットが重要なあらゆるコラボレーションに取り組んでいる方は、ぜひお試しください。Collabojinベータに参加していただければ、アクセス準備ができ次第ご連絡いたします。
まとめ
コラボレーションはデザインの問題です。より良いシステム、より良い質問、より良い共有メモリ—これらがレバーです。この講演は、コラボレーションをデフォルトで起こるものとしてではなく、エンジニアリングすべきものとして扱うとどうなるかを示す試みでした。
Tokyo Tech Leads Circleコミュニティの皆様、お招きいただきありがとうございました。会話を続けたい方は、ぜひお問い合わせください。
Keenan ThompsonはArcnem AIのCEOです。Paul Consalviは東京大学大学院新領域創成科学研究科の教授です。