チームからギルドに移るためのガイド

「チーム」は至極当たり前のあり方として定着していますが、限界を感じるようになってきました。生成 AI のおかげで、この限界を突破できそうな感触を得たため、本記事にて整理します。ギルドと名付け、チームの次のあり方として大胆に提示します。

注意:

• 本記事は筆者個人の見解であり、所属組織を代表するものではありません。また、仮説としてしっかりと提示したいため SHOULD や MUST の表現も用いています
• 情報管理や生成 AI 利用に関する記述は一般論としての問題提起であり、実運用は各組織の規程に従う必要があります

背景: チームの限界が来ている

ここ 10-20 年でチームの概念が定着してきた。かつてエンジニアはコミュニケーションが苦手であっても重宝されていたが、今は「チームに馴染めるかどうか」が第一であり、ここをクリアできなければ実力者でも弾かれる。ネットフリックスのブリリアント・ジャーク（有能だがイヤな奴）は有名だし、エンジニアリングとセットで語られる組織論もチームの構築とメンテナンスに紙面を割いている。

そんなチームだが万能ではない。主なデメリットとして合意形成に時間がかかることと、構造的に高密度な働き方になるがゆえに相性とタフさがどちらも要求される厳しい世界になりがちなことの二点を挙げたい。

一方で現代は VUCA といわれ先が見えず、読めず、変化も激しい時代だし、DEI など配慮の水準も上がってきている。チームとは相性が悪い。まず合意形成に時間がかかるため遅いし、「そのチームに合う」「タフな」人材しか生き抜けないため多様性も出にくい。これでは VUCA に対抗しづらいし、（チームとタフネスに合わない人は）配慮されなくて力を発揮しづらい。

課題: グループ → チーム → ギルド。第三のあり方「ギルド」を導きたい

新しいあり方（パラダイム）が要るのだと思う。私は ギルド と名付けた。

私は、この連帯のあり方を次のように整理している。

• 1: グループ。大きな組織を持続的に動かすためのパラダイム
  • 単一性かつ低密度
  • 組織として規律は定める。また安定性とコストのために規律は一つにして全員を画一化する
  • ただし経済的には従業員をしっかり働かせたいので高密度にされがち → 労働時間や居住地や出社頻度を固定したりする
• 2: チーム。小さな組織で「n=1 より大きな成果」を出すためのパラダイム
  • 単一性かつ高密度
  • ひとりでは出せない成果を出すために「複数人」が要る。しかし同じ方向を向かねば収拾がつかないので常時拘束や打ち合わせ過多など高密度なあり方を前提にする。構造的に一緒に過ごす時間が増えるので「合わない人」を矯正または排除する（やり方は色々）
• 3: ギルド
  • 多様性かつ低密度
  • ★この第三のあり方があると思う

グループは持続性が第一だから早く動けない。チームは前進が第一だから前にしか進めない。どちらにも構造的な限界があり、新しい構造が必要だと思う。マトリックスにすると、多様的の列が不在だ。

	単一的	多様的
低密度	グループ	？
高密度	チーム	？

そのうち「多様的かつ低密度」の方に目をつけた。チームの延長として捉えやすいからだ。

	単一的	多様的
低密度	グループ	ギルド ★ここを探求する
高密度	チーム	？

以降ではギルドなるあり方を導いていく。

(余談): 既存の「ギルド」について

ギルドという言葉自体は、すでにいくつか使用例がある。

• Spotify モデルとして登場するギルド
• フリーランス連合としてのギルド: 例としてTHE GUILD

しかし、これらはチームメンバーを動的に集めているにすぎず、あり方としては「チーム」である。本記事でいうギルドは、チームのあり方そのものから脱した、新しいあり方を提示している。

スコープ: ギルドが扱う範囲はゼロイチ（探索と収束）

そうすると、フェーズごとに求められるものが異なる、との捉え方で整理できる。

• 10 to 100～: 拡大と安定のフェーズ。グループが適する
• 1 to 10: 前進と開拓のフェーズ。チームが適する
• 0 to 1: 探索と収束のフェーズ。ギルドが適する

チームは万能と思われがちだが、構造的には「"これで行く" と決めたことを皆でやる」のに向いている。逆を言えば やることが決まっていないゼロイチの段階には向いてない。

私はゼロイチの段階を 探索と収束 と表現している。

この段階で必要なのは問題解決よりも問題定義であり、問題を定義するには調査や試作や検証、そして深い思考と整理が要ると思う。作家がひとりで作品を作るのと同じだ。一行一行や一コマ一コマを複数人でつくる、なんて真似はしない。ゼロからイチをつくるのは本質的に高度な作業であり、また個人の内面も生かすため、ひとりで行わなくてはならない。内面は他人に見られたくないからだ。

この時点では独りよがりになるため、つくったもの（完成ではなく中途でもいい）を持ち込んで、他人の目で見てもらって、としていく。ここまでが 探索。

そうして探索を続けていくと、次第に「これだ」というものが見えてくる。見えてきたら、これを形にして一つ定めればいい。これが 収束 であり、ゼロイチのイチ（の種）をつくったと言える。ここからようやくチームが生きてくる。収束したイチがあるからこそ、チーム一丸となって、ひとり以上のパワーで前に進める。

……と、書いたが、特段新しい営みではない。むしろクリエイターや研究者のスタイルと言えるだろう。サラリーマンの、チームありきな世界に、これらを持ち込もうとしていると言っても良い。

ここまでのまとめ:

• 0 to 1 は従来チームで行われていたが、チームでは向いていない
  • 合意形成と単一性により、探索がしづらいため
• 探索がしやすい構造が要るし、収束を導く必要もある → 新しい構造が要る → ギルド
• あり方はパラダイムとして整理できる
  • 第一パラダイム「グループ」は単一的かつ低密度なあり方で、10 to 100～、拡大と安定に向いている
  • 第二パラダイム「チーム」は単一的かつ高密度なあり方で、1 to 10、前進と開拓に向いている
  • 第三パラダイム「ギルド」は多様的かつ低密度なあり方で、0 to 1、探索と収束に向いている

元々グループでは足りないからとチームの概念が活性化し、IT 界隈でもここ 10～20 年で定着した。

同様に、チームでは足りない時代が来ている。私はギルドを据えたい。

ギルドのあり方

では、ギルドとはどのようなあり方になるのか。

プロトタイプ（ソフトウェアではなくドキュメント）をつくってみたので、ここで紹介する。

定義: チームとギルドの違い

• チームとは
  • メンバー全員が一つの成果物を抱えること
  • N-member 1-product
• ギルドとは
  • メンバーひとりひとりが一つの成果物を抱えること
  • 1-member 1-product

例として、SI を AI エージェントに任せて人手工数を 99% 削減する製品を新規開発するとしよう。Agentic Engineering 的に開発を行う製品と言ってもいい。

たとえば要件定義や PRD を与えるだけで、デプロイされたシステム（あるいはデプロイ可能な最終成果物）が生成される。すでに画像生成 AI では「一回生成するたびにクレジットを消費」のビジネスモデルが採用されているが、同様に、この製品では、クレジット消費で一回分の開発を完遂させる——と、現時点でも夢物語に聞こえるが、エンプラのプロダクションレベルはともかく、小さなツールであればもうできうる。

さて、チームの場合、メンバー全員が一つのプロダクトを抱えることになるだろう。何をどうつくるかを都度、合意形成して決めていくことになる。あるいはエースがプロトタイプをつくって、残メンバーは俺についてこい、のようなモデルになるだろう。

ギルドだとどうなるか。

ギルドの場合、ひとりひとりが一つ以上のプロダクトを抱える ことになる。誰が何をするかは各自に委ねられる。A さんは遊びの延長で既存のオープンソースや規格を束ねた製品をつくり、B さんは論文と著名人の発言から理論的に整理した上で空白を特定し、C さんは自社の課題を詳しく調査した上で試しに AI エージェントで解いてみたり、など様々な探索が行われるはずだ。

あとで述べるが、生成 AI により 1-member 1-product が可能となったのだ。

チームの問題点と、ギルドでどう軽減するか

• チームの問題点
  • 合意形成に相当のコストが割かれること
  • 多様性が生じにくいこと。声の強い者、実力のある者、時間があって費やせる者がメイン、それ以外がサブまたは手足の構図になる
  • 問題定義に関して主体的になりにくい（問題定義に閉じている）こと。問題解決とその分担ばかりに目が向くこととなり、問題そのものを疑えない
• チームの問題を、ギルドではどう軽減するか
  • 合意形成のコストを減らせる。探索の段階では合意形成コストをゼロにできる。また収束の段階でも（後述するが）ギルドマスターが行うため合意形成コストは少ない
  • ひとりひとりが主体的に探索・検証をするので、メンバーの数だけ多様なアウトプットが出る
  • 問題解決だけでなく問題定義にも踏み込みやすい。少なくとも踏み込めるよう開かれている

ギルドの適用範囲

• Ans: 攻略の前まで

ギルドが担うのは 攻略の前 までである。

ここまで探索と収束と述べてきた。各自が主体的かつ創造的につくり、持ち込む。各自が持ち込んだものを各自は参考にして、さらに自分の探求を深堀りする。これが探索。次に、探索を繰り返していくうちに、次第に「これをつくればいい」「これをやればいい」と見えてくる。これが 収束。

収束した後は 攻略 が待っている。たとえるなら、未踏破ダンジョンの下調べと戦略が落ち着いて、あとは攻略するだけとの段階だ。チームは、この段階ではじめて有効となるものである。一方、ギルドはその前段、攻略の前に至るまでを担当する。

つまり:

• 攻略段階では何をつくるかが決まっている（というより決める）ので、単にそれを皆でつくればいい → チームが適する
• 攻略が見えるまでは、多様なヒントを集めた方がいい → ギルドが適する

では後者のギルドとはどのようなあり方になるのか、が争点である。すでに ギルドは 1-member 1-product のあり方 と述べたが、次でさらに詳しく述べる。

ギルドの構成要素

ギルドマスター、ギルドメンバー、副マスター:

• ギルドマスターは1人、ギルドメンバーはn人、副マスターは0～1人
  • マスター:
    • 最終的な収束の決定権を持つ
    • メンバー全員の探索結果を理解し、収束に向けた方向付けを行う
  • メンバー:
    • 自分で主体的に探索しつつ、他メンバーの探索結果も見て参考にする
  • 副マスター:
    • 組織の都合上、事務作業や政治面など「非本質的な作業」が重たい場合は、それを専任で補強するサブマスターを入れても良い
    • マスターがここを兼ねるのは推奨しない

アジト:

• ギルド全員が誰でもいつでも読み書きできる、SSoT（信頼できる唯一の情報源）な情報プラットフォーム のこと
• 開発者体験の高い手段が望ましい:
  • 例: Cosense などコラボレーティブな Wiki、GitHub + Markdown などで日頃の経過と成果をプレーンテキストで配置等

装備品:

• 生成AIのこと。ブラウザやアプリから使う対話サービス、claudeやcodex-cliなどコマンド、OpenAI API や Anthropic API など API の三点すべて
• ギルド全員が誰でもいつでも使えるべき、また社外秘やプロジェクト外秘程度であれば自由に使えるべき
• ギルドの肝は生成AIにより「アイデアや文章の実装」と「外の情報やメンバーの共有物の理解」を加速させるところにある
  • これがあるからこそ 1-member 1-product ができる
  • 装備品はギルドの構成要素と言っていいくらい必須であり、そもそも装備品を用意できないならギルドは成立しない

役割とアジトと装備品の三点を取り上げた。

まず役割としてマスターとメンバーを据えている。収束を行うのは ギルドマスター であり、したがってメンバー全員の成果物を読んで深く理解する実力が必須となる。忙しくて表面的にしか見ないような従来のマネージャーや経営者には務まらない。また、ギルドメンバー には主体的に探索を行い、経過や成果も持ち込んで他メンバーが見れるように整える必要があるため、指示待ち人間には務まらないし、知的生産（他人が読んで理解できるものを提出する）ができない人間にも務まらない。もう一つ、組織によっては雑務（事務と政治）に苦戦することがあり、これを吸収する役割が要るため 副マスター を置いている。マスターの収束と副マスターの雑務は両方は行えないため、ここは必ず分けなくてはならない。収束はフルコミットできねば通用しないため、雑務の比重が重たいなら副マスターを据えるべきだ。

次にアジトという概念を置いた。GitLab 社が有名だが、誰でもいつでも読み書きできるテキストを置く場をつくって、ここを正にする。ギルドでは日々ここに情報や経過や成果を置き、また読むのである。ここさえ追いかけておけばギルドの仕事は完結できる。透明性と言ってもいい。打ち合わせしないとわかりません、はナシだ。したがって、（後述もするが） ギルドでは会議は全くないか、ほとんどない。アジトを読めばわかるし、それで成立しなくてはならない。収束の段階では会議が増えるかもしれないが、少なくとも探索段階では無い。あるいは、やりたい者は好きにしていいが、アジトに置くことを忘れてはならない。総じて、読み書きと非同期の素養が全員に要求される。

そして何より重要なのが装備品――もっというと 生成AI である。そもそもギルド型がなぜ実現できうるかと言えば、生成 AI があるからだ。生成 AI は開発の道具と見られがちだが、それだけではない。むしろ 翻訳と整理の道具 でもある。たとえば、A さんが 1 週間かけて書いた 1 万文字のテキストも、生成 AI があれば読める。生成 AI で翻訳や整理をすればいいだけだからだ。むしろ、これができないということは、生成 AI を使いこなせてない可能性が高い。使いこなせないと、この高密度な情報を扱えず、従来どおり原始的に会議で「忙しい者にも手短にわかるように」伝える政治に勤しむ（勤しませる）ことになる。

このボトルネックを減らせるのが生成 AI だ。ギルドでは生成 AI を装備品と表現し、必須に位置づけている。日常的に使えなくては話にならないし、もちろん全員にも使いこなせるだけのスキルが求められるのだ。

さて、なぜこんな構造にしたかというと、探索を最大化したいからである。

探索は個人的な営みであり、各個人がどれだけ深く集中できるかに依存する。これはクリエイターが日々行う創造と同義であり、人の数だけ解があるが、少なくとも「他者の邪魔が入らない」点では共通している。大胆に言えば 探索とは孤独なもの だ。

無論、これだけでは独りよがりになってしまうので、二段階の仕組みを入れている。

• 持ち込み。各自探索した経過や結果をアジトで共有して、他の人も読めるようにする。また自分も他の人が持ち込んだものを読む
• 収束。ギルドマスターが中心となって、これをやる、こっちに行く、これにするんだを決める

以上。

構成要素はこのくらいにして、続いて原則を取り上げたい。

ギルドの原則

ここまで述べてきたように、ギルドとしてやりたいことはただ一つで、0 to 1 の最大化だ。そのために探索を最大化したい。探索はクリエイターの創造と同じく、本質的に個人的（大胆に言えば孤独）な営みであるため、ひとりで集中できねばならず、しかし収束にも向きたい――というわけで、上記のような構成要素を据えている。今まで出来なかったのは単に手段がなかったからだが、生成 AI により可能となったのだ。

とはいうものの、ギルドの考え方は、チームに染まった頭では理解しづらい。構成要素だけではたぶんピンと来ないため、原則も整理した。

ソロワークを尊重せよ

• ギルドはチームではない
  • ひとりひとりが自分で探索して、その経過や成果を持ち込むことを前提とせよ
• メンバーにはそれぞれのペースがある
  • 同期はペースを削ぐため、使っても良いが双方合意を取ること
  • また同期的に行った場合は、必ずアジトに反映すること
  • 離席は断りなく自由に行えるはずである
• アジトを正にせよ
  • 非同期で完結する状態をキープすること
  • 例1: 30 分で話してひとりに伝えるよりも、2 時間かけて全員が理解できる or 生成 AI を使えば理解できるテキストを書け
  • 例2: 出社+対面でオンボーディングするよりも、オンボーディング用のテキストをつくって数日かけて読んでもらえ

最も争点となるのは「孤独に耐えられる人が案外少ない」点だろう。界隈でも次のスタイルが好まれがちだ:

• もくもくのように、皆集まってひとりで作業しつつ、必要なら何か喋って雑談まじりに始まる、みたいな場
• モブプログラミングやハッカソンのように、皆で同じことをやる高密度な場

これらはチームのあり方であって、ギルドが想定する 0 to 1 にはそぐわない。0 to 1 で本当に必要なのは個の尊重であり、それをソロワークと表現している。ギルドとしてこれら「集まる場」を禁止する意図はない。やりたい人はやればいい。ただし前提にしてはならない。あくまでアジトに持ち込み、それを各自が読むことで完結するのが前提なのだ。

一つの目安は Away Free（離席自由） だろう。メンバーは各自ソロワークし、アジトに置いているはずなので、拘束の必要がない。自分のタイミングで勝手に 30 分離席したり、煮詰まったから 2 時間ほど散歩がてら休憩してくるわといったことも全く問題がない。むしろ Away Free が許容されない時点で、ギルドとして成立していない。ソロワークが足りない。

装備品を身につけよ

• 装備品――生成 AI がないと太刀打ちできないと心得よ

開発としての生成 AI ではなく、翻訳や整理としての生成 AI を使いこなせる必要がある。

一つの目安は「メンバーのひとりが 1 週間かけてつくった 1 万文字のテキスト」を読めるか、だ。たとえば 1 時間かけて理解に努められるかという話になる。ギルドでは当たり前に行えなくてはならない。そして、これができるかどうかは生成 AI を使いこなすスキル次第である。できないというのは、単にスキルが足らないだけ の可能性が高い。余談だが、エンジニアでもこれが出来る人は少ないと感じる。理由は単純で、開発としての生成 AI と、翻訳や整理としての生成 AI は全く別ジャンルだからだ。

特にシビアなのがギルドマスターである。仮にギルドメンバーが 4 人いて、ひとりひとりが 1 週間ごとに 1 万文字のテキストを出してくる場合、ギルドマスターはそのすべてを読んで理解し、必要なら助言などの方向付けも行えることが望ましい。生成 AI スキルはもちろんのこと、ギルドマスターとしてのソロワークを確保する動きも必要になってくる。従来のマネージャーのように日中の大半が会議です、部下がいい感じに手短に報告してくれます、では話にならない。むしろミュートデイ（日中誰とも一言も喋らない）か、少なくとも半日のミュートを当たり前に取るくらいは欲しい。

いずれにせよ、翻訳や整理としての生成 AI スキルの有無が分かれ目となる。だからギルドとしては「装備品」として生成 AI を据えている。

また手段としては、少なくとも以下程度はすべてサポートできねばならない:

• ブラウザやアプリから使う対話サービス
• claude や codex-cli などコマンド
• OpenAI API や Anthropic API など API

この三点セットをメンバー全員が自由に使えるようにしたい（現実的に従量課金の天井を設けることはありえるが）。このレベルが揃ってないと、翻訳や整理としての生成 AI スキルは実践できない。スタートラインに立ててない。

さらに 社外秘程度の機密情報であれば AI に渡してもいい との解禁、またはできるだけこれに近づくことも事実上必須となる。ギルドとして普段活動する際は生成 AI を息するように使うため、いちいち機密情報を漂白する手間など負えない。イメージとしては、普段使っているクラウドサービスに置ける程度の機密情報であれば、同様に認めたいところだ。

※余談だがクラウドが当たり前になる前に、クラウドにデータを置くことを良しとしない組織は多かった。今では（パンデミックの後押しもあるが）ご承知のとおり、もはやクラウドがないと仕事にならない。生成 AI の業務利用も同じ波が来ており、 今置ける側を選べるかどうか が分水嶺になると思う。

この滑らかさ（堅苦しく言えば開発者体験）を削いではならないし、削がれているのならその原因を徹底的に取り除くか最小化するべきである。実務上は、おそらく副マスターが担うことになる。場合によっては上層との交渉も要るし、たぶん要る。そういう意味で、組織次第では、実は副マスターが一番難しい仕事かもしれない。

助言せよ

• 指示、命令、監督や管理をするな
• 代わりに助言せよ

ギルドではメンバーの主体性に委ねる。ギルドマスターや年長メンバーだからといって、押し付けてはいけない。どう進めるかはあくまでもメンバー本人にある。しかし、それでは独りよがりになってしまうので 助言をする。

より具体的には、次のとおり:

• 助言者に意思決定権はない
• 助言を取り入れるかどうかは受け手が決める
• 助言をどう扱ったかのフィードバックは不要

このあたりの話は、ティール組織では 助言プロセス と呼ばれている。細かい運用にばらつきはあるが、共通する点は一つで、メンバー側に委ねるということ。FYI（For Your Information）と言ってもいいかもしれない。

プロダクトで語れ

• プロダクトをつくって示せ
• プロダクトとはソフトウェアに限らないが、第三者が理解できるようにせよ

ギルドの定義は 1-member 1-product である。そもそもチーム（N-member 1-product）の限界を超えて、ひとりひとりがプロダクトを抱えるところがスタートラインだ。無論、ここでは最終的なプロダクトを抱えると言っているのではなく、それを特定するまでのプロトタイプ的なプロダクトの話をしている。

ギルドでは、プロダクトで語らなくてはならない。

ソフトウェアである必要はない。紙芝居でも、録画したプレゼンでも、Markdown レポートでも、ウィキでつくった知識グラフでも、Miro などで書いたボードでも、マイクラその他３次元ワールドでつくった建築と体験でも、SFプロトタイピングよろしく空想よりの文章でも、何でも良い。

ただし 第三者が作者本人のフォローなしに理解できるもの でなくてはならない。対面で伝えるとか、レビューやプレゼンの形で見せるといったことではない。むしろ逆で、成果物だけ置いておいて、それを各自がひとりで読む。ソフトウェアで言えば、ある程度成熟した OSS のイメージ。ドキュメントがあって、ウェブサイトで見れて、GitHub に一式が置いてあるので試せる。もちろんいつでも誰でも好きにアクセスもできる——が、正直言えば、これよりも難しい。

なぜなら問題定義の話だからだ。ギルドメンバーが行うべきは、問題の定義である。どういう背景があって、なぜこのような問題を設定するのか。またそれをどうやって解決していくのか、なぜ現実的にできるといえるのか、あるいは見えてない部分はどこなのか——。これを全部、他のギルドメンバーにわかるようにつくらなくてはならない。極めて高密度な成果物 となる。たとえドキュメントだろうと、プロダクトと呼べるほど濃密なものだ。

そんなものだからこそ、メンバーは深く向き合える。ここは合ってる、ここはよくわからん、ここは違う、と自分なりに照らし合わせながら、深く向き合うことができる。その結果もまたプロダクトに反映して、提示する。そうすることで、ギルド内で影響を与え合っていく。そうしていくうちに、本当の問題が見えてくる。というより、ここまでやるからこそ、見えてくるもの。

※ちなみに本記事の「ギルド」も、まさに私が提示するプロダクトです。チームの限界という問題を定義しています。ギルドであれば、これくらいは誰でもできるようになります。というか、なれるようにしたくて、まさに整備したい。

ともかく、プロダクトで語るということは、プロダクトをつくれなければならないことを意味する。また、プロダクトを読んで理解したり使ったりする好奇心と行動力も求められる。

ギルドメンバーに求められる資質

ここまで述べてきたとおり、ギルドのあり方はチームのそれとはかなり違う。そもそも「そんなことできるのか？？」と疑問も抱かれると思う。

そこで、ギルドの成立に必要なものを、メンバーの資質という形で整理しておきたい。正直言えばまだはっきりと見えているものではないが、それでも提示しておきたい。

ギルドはともかく、個人的にゼロイチを作る部分は、すでに一部のクリエイターや研究者にとっては当たり前の営みであり、私は言わばそれを言語化しているにすぎない（加えてチームの次の協調モデルに据えようともしているが）。とっかかりにはなるはずだ。

マスターの資質

• マスターは自身の思い（ビジョン）、事業や組織の文脈（コンテキスト）、重点的に深堀りしたいこと（テーマ）、重点的にこなしてほしいこと（ミッション）を提示・助言する
• メンバー全員が持ち込んだものすべての理解に努める
• マスターはメンバーが明らかにズレてそうなら助言をし、しかし自律性と個性を殺さない塩梅も心がけるという慈悲を、行動をもって示す
• マスターは開放的である。立場上、多くの情報を持つはずで、それを惜しみなくアジトに落とす
• マスターは自身の重圧や孤独をまぎらわすために、安易に会話には頼らない
• マスターは探索をメンバーに任せるべきであり、自身は行わない。マスターとしての責務を果たすことに集中する

現時点で資質を列挙しきれるほどの知見は無いが、6 つほど挙げてみた。

とにもかくにも、マスターの立場でありながら、ギルドらしい動き方ができるかどうかが肝心となる。通常、このような立場は非対称性を持っていて、自身は多くの情報を持ちながらも出し惜しみをして、しかし下からの情報は会議の形で引っ張ることが許されがち――だが、ギルドでは認められない。

たとえギルドマスターだろうと、アジトを用いたソロワークな読み書きで駆動できねばならない。そして収束のためにメンバーを適切に舵取りし、また動いてもらえるよう情報も惜しみなくアジトに出さなくてはならない。控えめに言っても 一日の半分くらいはアジトで読み書きする時間に費やされるだろう。これを持続的に行えるだけの資質が必要なのだ。

最も盲点なのは最後の、孤独の話だろう。私たちはチームの名のもとに、自分の孤独をまぎらわせようとしがちだ。8 時間、じっと机に座って仕事をすればいいのに、耐えられないからと安易に会議を入れたり、集まる場を設けたりする。それを仕事のため、コミュニケーションのため、関係性のためなどと正当化する――。しかしここまで述べたとおり、ギルドでは、アジト上での非同期的な読み書きがすべてである。本当に 0 to 1 に専念するために、各個人がソロワークで深堀りをし、その経過と成果をアジトに残すことで還元する。

一方で、人間なので孤独から逃れるのも難しい。特性によって得意・苦手もある。しかし、それでも安易にメンバーを拘束してはならないのである。ここで「いや非同期的に読み書きで雑談すればいいのでは」と思われるかもしれないが、そう単純でもない。人間も動物であり、対面による非言語情報や接触による情報（いわゆるスキンシップ）を欲するようにできている。後者はハラスメントとなるため現代では自制されるはずだが、前者はまだまだその域にない。

本記事では割愛するが、孤独耐性の乏しい者をどうフォローしていくかはギルドにおける一大テーマになるだろう。

メンバーの資質

• メンバーは冒険者である
  • どのような思いで何を探索するかはすべて自分で考え、実践し、共有する
  • いつ、何を、どこまでやるかなど自己管理（セルフマネジメント）する
  • 遠慮せず、自分の思いや信念も総動員する。自分に正直になる
• 経過や成果を誠意とともに持ち込む
  • 探索を最大化するために、ギルド全員にとって役に立ちうる情報はすべて持ち込む
  • 遠慮せず、情報量と情報密度を込める。装備品があるのだから問題ない。むしろメンバーを信じて出し惜しみしないことが誠意
  • しかし、度が過ぎると「荒らし」となる。塩梅を調整するための対話と議論も惜しまない
• ギルドマスターに協力する
  • 収束を担うのはギルドマスターであり、そのためのヒントを探索していると心得る
  • ギルドマスターの助言を軽視しない。また意見があれば遠慮なく出す
  • ギルドマスターそのものを疑う目線も持つ。たとえば実は別の人に任せた方が上手くいくかもしれない

メンバーとして求められる資質は、ギルドマスター以上に多様になるだろう。正直、現時点で端的にまとめきることはできないが、いったん 3x3 くらいでまとめた。

副マスターの資質

現時点で私の知見と経験値が乏しいため、割愛する。

残る論点

本記事では具体的な運用にまでは踏み込まない。たとえば次のような論点がある:

• アジトをどう実装・運用する？
  • 筆者のように読み書きに慣れた者であれば、たとえば「Cosense を使って……」「運用はこのようにして……」など実装しきれるが、ギルドを始めたい組織にこのような者がいるとは限らない
• ソロワークを全員ができるようにするには？
  • 筆者のように慣れた者にとっては日常だし、クリエイターの皆さんにとっても「言語化するまでもなく当たり前のこと」だろうが、大多数はそうではない。むしろろくに経験したことがない「非日常的な営み」だろう
• 「翻訳や整理としての生成 AI」のスキルを身に付けてもらうには？
  • すでに述べたとおり、日頃 AI エージェントを使っているようなエンジニアであっても、このスキルは持っていなかったりする。かといって理論やソフトウェアがあるわけではなく、現状はソフトスキル寄りだ。エンジニアが嫌いなソフトスキルとどう向き合ってもらう？
• 探索のやり方はどうやる？
  • 筆者のように知的生産に慣れた者であれば、ひとりで調べて考えて深堀りして、と本が何冊もできるような情報を集めたりつくったりして、かつそれを持ち込む、といったことを持続的に行えるが、これはエンジニア含めサラリーマンの営みとはあまりにかけ離れている。どうやって親しんでもらうか？
• 収束はどのように行う？（特に収束も全面的にソロワークで行うかどうか）
  • 筆者としては「全面的にソロワークで行ける」との感触はあるが、このような意思決定は（日本に限らず世界的に文化として）対面の場で儀式的に決めるものだと思っていて、いわば文化的な標準に抗うリスクがあるのではという心配がある。研究や事例もないだろうし、検証したい……。

実現性（フィジビリティ）が無いわけではない。できる、できないで言えばできる。ただ、生きた組織として運用を続ける前例がまだないと思う。こればっかりはやってみて、示してみないと説得力を出せないだろう。書くだけならできるが、ポエムや提言にしかならないし、運用レベルの話を論じて済ませるだけでは大した価値は無い（需要があったら書きたい）。

おわりに

チームというパラダイムの限界に注目し、かわりに個人の深い成果を持ち込む「ギルド」を立ち上げた。また構図としてギルド → チーム → グループを据えて、ギルドはチームの前段階、もっというと 0 to 1 に適したあり方とした。

その上で、ギルドのあり方を詳しく論じた。肝は生成 AI（装備品と表現）であり、開発と翻訳の力が強化されたからこそ、チームのあり方からの脱却が現実的に可能となったはずで、それを私はギルドと名付けた。無論、解はギルドだけではないし、モブワークや AI-DLC のような「チームの密度を強化する路線」もあるのだが、私は個人のパワーを信じている。