AIを前提とした企業設計 binary LLC

第2章 AI時代の開発組織

開発が変われば、組織も変わる

AI駆動開発が成立するなら、それを回す組織も、あわせて作り変えてこそ、その速さが価値になります。

第1章で述べたとおり、人の役割の中心は「作ること」から「価値を生むこと」へ移ります。この変化は、いまの職種の形を、両側から溶かしていきます。

これまで、価値創造はビジネスやプロダクトマネージャーが担い、エンジニアは作ることを担当してきました。ですが「作る」をAIが担うようになると、両側で境界が動きます。エンジニアは、技術の専門性を持ったまま、価値創造そのものへ深く入っていきます。 そしてビジネスやプロダクトマネージャーも、構造が担保された仕組みの上で、自らモノをつくれるようになります。

両側が価値創造へ寄っていくのは、良い価値創造そのものが、技術とビジネスの両方の知見を必要とするからです。何を作るべきかは事業の理解から、どう作るのが筋かは技術の理解から出ます。これまで別々の人に分かれていたこの両面が、AIを介して一つの価値創造へ束ねられていく ── こうして、いまの職種の分けは必然的に曖昧になり、行き着く先は、ビジネスとエンジニアがAIと一体になって価値創造へ向かう組織です。

本章では、その組織の姿を仮説として描きます。

分けるべきは、職種ではなく責任

職種の境界が薄れるなら、「ビジネスが要件を出し、開発が言われたものを作る」という従来の分業も、前提を失います。この分業は、作ることに専門の人手が要ったからこそ成り立っていました。その作る作業をAIが担う以上、分けるべきは職種ではなく、責任になります。

人に残る責任は、性質の違う二つに分かれます。

価値責任 ── 何を作るべきか、どんな価値を届けるかに責任を持ちます。顧客と事業を理解し、仮説を立て、AIへ問いを与え、返ってきたものを評価して決めます。依頼された機能を正しく作ることではなく、その結果として価値が生まれたかに責任を持ちます。担い手は、これまでのビジネスやプロダクトマネージャーと、価値創造へ深く入ったエンジニアです。

構造責任 ── 人とAIが継続して高い成果を出せる構造に責任を持ちます。システムの構造とアーキテクチャを崩れないよう守り、AIが迷わず働ける環境 ── ガードレール、品質基準、古びない Knowledge ── を整えます。そして、AIには正しさを判断できないコードを、人が読んでレビューします。すべてのコードを自分で書く人ではなく、人とAIが成果を出し続けられる状態をつくる人です。担い手として最も適しているのは、コードとアーキテクチャの規律を守ってきたテックリードです。

役割は肩書き(職種のタイトル)ではなく、この二つのどちらに責任を持つかで決まります。

構造を保つ役割を、意図して置く

先に「ビジネスやプロダクトマネージャーも自らモノをつくれるようになる」と述べました。それが成り立つのは、この構造が保たれているからです。AIは短時間で大量の成果物を生み出せますが、支える構造が無ければ、負債も同じ速さで増えます。

しかも、二つのうち構造責任は、欠けても気づきにくいものです。価値責任のほうは、果たせなければ、作ったものが顧客に刺さらず、現実が教えてくれます。ですが「いま構造を引き直すべきだ」「この判断を記録すべきだ」という手当ては、実行されなければ何も残りません。AIは構造が崩れていても止まらず動き続けるので、欠けたことに誰も気づかないまま、負債だけが静かに積み上がります。

だからこそ、この責任を誰かが確かに持って仕組み化している状態を、意図してつくる必要があります。放っておいて自然に埋まる種類の役割ではありません。

少人数で組む

人とAIのセットが、並行して動きます。ならばチームは、価値を生むのに必要な最小の人数で組むのがよいでしょう ── 問いと判断を担える、少人数で。人数を絞るほど、一人ひとりに担う力が必要で、誰でもよいわけではありません。

なぜ少人数か。かつて、生産力を上げるには、まず人を増やすのが定石でした。ですが人を増やすと、作る力は上がる一方で、コミュニケーションのコストも増え、トータルでは頭数ほどの効果は得られませんでした。AI時代には、作る速度はAIが担います。人を増やす主な理由は薄れ、むしろ人とAIのセットが増えるほど、それぞれが抱える前提や文脈が干渉し、競合して、かえって速度を落としかねません。

ただし、最適な規模は、システムの複雑さや、扱う領域の広さによって変わり、まだ確かめられてもいません。一人で保てる一貫性を複数人でも保てるか ── 第1章で「最大の空白」と呼んだ問いに、そのままつながっています。人数は固定の正解ではなく、探索して近づけていくものです。

原則は守り、チームは探索する

ここまでを、守るべき原則として整理します。原則は変えません。ですが、どう実現するかに、唯一の正解はありません。

  • 人は、問いを立て、評価し、決めます。 作る作業はAIが担い、人の力は書くことから問うことへ変わります。
  • 役割は、肩書きではなく責任で決まります。 誰が価値責任を持ち、誰が構造責任を持つかを、明確にします。
  • 価値を生む、最小の人数で組みます。 ただし最小がどこかは、探索して近づけます。
  • 構造を保つ責任を、誰かが確かに持ちます。 欠けても気づけない責任だからこそ、明示して置きます。

原則は守ったうえで、AI駆動開発が進むにつれ ── チームの人数、人とAIの線引き、ガードレールやレビューの仕組み、Knowledge を最新に保つ工夫 ── 最適なチームの形を、仮説を立て、試し、確かめながら模索していきます。


第2章では、AI駆動開発の成立を前提に、開発組織がどう変わるかを仮説として描きました。二つの責任も、少人数のチームも、まだ探索の途上にあります。そして、この考え方は開発部門の中だけの話ではありません。次章では、これを企業全体へ広げます。