前回の記事で、Boris Cherny氏が提示した「5つの役割アーキタイプ」を紹介しました。書き終えたあとも一つ引っかかりが残っていたので、その続きを書きます。
Claude Codeが変える”職種”のかたち――Anthropicの5つの役割アーキタイプ
目次
引っかかったのは、リプライ欄の一文だった
前回触れたとおり、Cherny氏のポストのリプライ欄では「6つ目のアーキタイプ、Orchestrator（指揮者）が抜けている」という指摘がありました。どの役割をいつ配置し、どう移行させるかを判断する人のことです。
これに対するCherny氏の返答は、要約すると、人とインセンティブの設計を工夫してチームが自己組織化するようにする、変化が速くなるほど中央のコーディネーターを置くやり方は機能しにくい、その役割の一部はClaude自身が担える、というものでした。
記事では中立に紹介して終えたのですが、後から疑問が残りました。自己組織化とは、勝手に起きるものだろうか。
「勝手に起きる」とは書かれていない
読み直すと、Cherny氏自身も「勝手に起きる」とは言っていません。人とインセンティブを設計する、と書いてあります。つまり、設計している誰かがいる。Orchestratorは不要だと言いながら、Orchestratorの仕事を前提に置いている、とも読めます。
さらに、明示されていない前提が二つあるように思います。
一つは採用です。あの水準の会社に、あの倍率で応募が集まる。自分でフェーズを判断して勝手に動ける人だけが入ってくる。そういう人を集めれば、確かに自己組織化します。ただしそれは組織運営の成果というより、選抜の成果です。
もう一つは目的の共有です。自社プロダクトであれば、何を作るのか、何が成功なのかが最初から全員に見えている。目的が共有された集団は調整コストが低い。一方、受託開発では目的が顧客の側にあります。そもそも条件が違います。
つまり、調整コストが消えたのではなく、事前の設計と選抜に前払いされているのではないか。そう考えると腑に落ちます。そして、前払いできない組織では後払いするしかない。それがマネージャーという役割の実体だと思います。
では、従来のマネージャーのままでよいのか
そうも思いません。マネージャー不要論には与しませんが、同じ役割がそのまま残るとも思わないからです。
従来のマネージャーの仕事は、かなりの部分が情報の中継でした。誰が何をやっているかを聞いて回り、集約し、上に報告し、下に落とす。進捗管理も工数管理も、根っこはこれです。
この部分は消えていくと考えています。開発プロセスが機械可読な形で書かれ、成果物がバージョン管理に流れ、AIの作業ログが残るようになれば、中継しなくても状況が見えるからです。中継役が必要だったのは、状況が人の頭の中にしかなかったからでした。
では何が残り、何が新しく必要になるのか。整理してみます。
マネージャーの仕事：消えるもの・残るもの
| 仕事の中身 | どうなるか | 理由 |
|---|---|---|
| 進捗の収集・集約 | 消える | 成果物がバージョン管理に流れれば、聞いて回らなくても見える |
| 上への報告資料の作成 | 消える（自動化） | ログと差分から生成できる。作る仕事ではなくなる |
| 下への情報伝達 | 消える | プロセスが機械可読なら、参照先が一箇所になる |
| 工数の見積・配分 | 薄くなる | 人月の前提が崩れる。ただし予算折衝は残る |
| 作業の割り振り | 薄くなる | 条件が整えば、フェーズ単位の自己選択に寄る |
| 未定義事項の決定 | 残る・増える | AIが炙り出す量が増える。決裁権限は委譲できない |
| 対外的な責任の引き受け | 残る | 検収・契約の主体が人である限り消えない |
| 揉め事の引き取り | 残る | 機械可読にできない領域 |
| 場とインセンティブの設計 | 新しく中心になる | 自己組織化が勝手に起きない以上、誰かが担う |
| AI出力に対する品質基準の設定 | 新しい | どこまで許容するかは技術判断ではなく方針判断 |
エンジニアの仕事：消えるもの・残るもの
| 仕事の中身 | どうなるか | 理由 |
|---|---|---|
| コードを書く | 薄くなる | ゼロにはならない。難所ほど残る |
| 定型的な設計書の作成 | 消える | 仕様が構造化されていれば生成対象になる |
| 実装しながら曖昧さを握り潰す | 消える | この判断が上に上がるようになる |
| 仕様を構造化する | 新しく中心になる | 「何を作らせるか」を決める作業 |
| 出力の検証 | 残る・増える | 量が増えるため、ここが最大のボトルネックになる |
| 「これは仕様か、AIの推測か」の判別 | 新しい | 出力からは区別がつかない。人が見るしかない |
| 現場での小さな判断 | 上に移動 | 消えるのではなく、マネージャー側に移る |
並べてみると、きれいに分かれます。消えるのは「情報を人が運ぶ仕事」、残るのは「責任が伴う判断」です。
一番効くのは、握り潰しが消えること
個人的に最も影響が大きいと考えているのが、エンジニア側の表にある「実装しながら曖昧さを握り潰す」が消える点です。
仕様書に書かれていない箇所は、これまで実装者が現場で判断して埋めてきました。聞きに行くか、経験で決めるか。この作業は工数として計上されず、無料で吸収されてきたコストです。
ここにAIが入ると、性質が変わります。AIは曖昧な入力でも止まりません。書かれていない部分を推測で埋めて、それらしい成果物を出してきます。しかも出力を見ても、仕様どおりの部分と推測で埋めた部分の区別がつきません。ハルシネーションと呼ばれる現象の一部は、モデルの欠陥というより、未定義な入力に対する正直な反応だと考えています。
だからこそ、未定義箇所を明示的に炙り出す工程が要る。そして炙り出すと、「ここが決まっていません」という問いが、これまでより早く、大量に上流へ流れます。
マネージャーから見ると、AIを導入したのに自分の仕事が増えたように見えるはずです。実際には元からあった負債が可視化されただけなのですが、そう説明しない限り、導入は歓迎されません。AIを入れるとマネージャーは楽になる、という説明で進めると、おそらく現場が壊れます。楽になるのではなく、仕事の種類が変わる。作業の進捗管理から、意思決定の処理速度へ。
まとめ
自己組織化は、条件が整った場所で起きる現象であって、放っておいて起きるものではないと思います。Cherny氏の返答も、よく読めば設計の必要性を前提にしています。マネージャーが消えるのではなく、その仕事のうち「情報を運ぶ部分」が消え、「決める部分」と「場を作る部分」が残る。むしろそこが中心になる。
Orchestrator（指揮者）という呼び名も、そう考えると少し合わない気がします。指揮という言葉には、中央から統制するニュアンスが残っています。実際に残る仕事は、統制よりも条件を整えることに近い。庭師のような比喩のほうが、実態に合っているのかもしれません。
そしてもう一つ。エンジニアの側も、手を動かすことより「何を作らせるか」と「出てきたものが正しいか」が中心になっていきます。これは従来のマネージャーの仕事に近づいているとも言えます。両者が中央に寄ってきて、境界が溶ける。5つの役割アーキタイプが職種に紐づかないという指摘は、そういうことなのだろうと受け取っています。