BizDev公開日誌#5 AI時代にBizDevとTechが連携するほうが良い理由
――AIで1人で何でも開発できる時代に、それでもTechとチームで働きたい。
Claude Codeを使えばBizDevがコードを書ける。AIエージェントを組めば1人で業務を回せる。果たして本当でしょうか？日々、Techと連携しながら事業開発を進めている私たちなりに「なぜチームで、なぜBizとTechが一緒にやるのか？」という問いの答えを考えてみました。
前回までの議論と今回のテーマ
#3では「暗黙知を事業の武器に変えるには」という話を書きました。業務プロセスそのものがプロダクトであること、適応速度が（短期的には）競争優位になること。その延長線上で今回は、そのプロセスを誰がどう設計・運用するのか — つまりチームの話に踏み込みます。
AIの普及で、BizDevがコードに触れる機会もTechが事業要件に踏み込む機会も増えました。職種の境界は、以前より明らかに流動的になっています。それでもなお、チームを組む意味はどこにあるのでしょうか。
3つの観点で整理する
境界は溶けたが、視点は溶けない。
BizとTechの連携を考えるにあたって、3つの観点で棲み分けの濃淡を整理してみました。
思考様式 — 補完関係。Bizは「これは目的に叶うか？成果出るか？」というWHYを規定。Techは「この仕組みは壊れないか？スケールするか？」というHOWを規定。果たすべき役割の違いが出る。
スキル — グラデーション的に混在。AI時代に入って、Biz寄りのスキル（顧客理解、要件の言語化）もTech寄りのスキル（設計力、再現性の担保）も、相互に越境しやすくなりました。プロンプト設計やAI出力の評価眼は、まさにBizとTechが混ざることで鍛えられる新しいスキル領域です。
業務 — （誰がやるかに関わらず）明確に分けて考えるべき。事業要件の定義はBiz、セキュリティやアーキテクチャ設計はTech。ここを曖昧にすると品質もセキュリティも崩れます。
チーム内での議論で興味深かったのは、この3つの観点の中でスキルの境界がもっとも流動的だという実感でした。ノバセルのTechは元々「今のフェーズで本当に必要ですか？」とWHYを問いてくれるチームですし、Biz側も最近ではClaude CodeでPRを出しながらプロダクト開発を進めていきます。中間地帯が人材としても広がっている。だからこそ、溶けきれない部分 — 業務 — の存在が際立ちます。
ファクトリー構想での実際
私たちが取り組んでいる「ファクトリー構想」 — 広告クリエイティブのAI化 — では、この3観点が具体的に動いています。
Biz側では「作る前にまず成果を出す」を大事にしています。プロダクト化の前に手法で成果を証明する。Tech側も「AIで後から変えられる部分がかなり広がった」前提で、DB設計など不可逆な部分だけ先に押さえるアプローチを取ります。
チーム内でも「ファクトリーの各ラインはテック的にかなり標準化されてきた。だがさらに良いものを作るときに、テックの専門性が必要な場面が出てきている」という声がありました。BizだけでClaude Codeと会話しても最適な打ち手を選べているか — この問いは、まさに「なぜチームか」の答えに直結します。
なぜチームでやるのか
1人でもAIで開発できる時代に、あえてBiz x Techチームを組む理由は複眼でものを見られる・見やすいに尽きると思います。例えば以下のような３点が考えられます。
評価軸が違う Bizは「刺さるか？市場が動いたか？」に責任を果たし、Techは「壊れないか？再現性が落ちたか？」にコミットする。評価軸が違う人間が同席していることに価値がある。
品質基準の外部化 1人だと「これで十分」の基準が甘くなります。Bizは「エンジニアをアサインする段階で『それ本当に意味あるの？』はちゃんと答えられないといけない」意識を常に保つ必要があります。
AIへの指示精度の担保 AIへの指示はBiz言語（KPI、顧客、市場）とTech言語（設計、再現性、安全性）の両方で書く必要があります。同じチームにいるのが一番精度が上がる。
「Agent複数立てれば解決しない？」
チーム内でも出た反論です。答えは「一義的にはYes」。Biz視点AgentとTech視点Agentを分けて走らせれば、実行層やチェック層はカバーできます。
ただし、これは開発規模とバランスの問題です。個人〜2-3人の小規模なら、Claude Codeで対話しながら複数Agentを走らせれば十分回せる。しかし、組織の仕組みとして回す規模になると、判断のダウンサイドが大きくなります。「何を委託するか」「結果をどう評価するか」のメタ判断が要る。
つまり、大きな仕組みになればなるほど、判断が人間のボトルネックになる。そこの専門人材を立てておかないと、スピードがままならなくなる可能性がある。
Managed Agentが示唆するもの
ここで補助線になるのが、Anthropicが2026年4月にリリースしたClaude Managed Agentsです。Claude Codeとは性質が違う仕組みで、kgsi氏は「隣に座って一緒に作業する同僚（Claude Code）」と「依頼書を渡して翌朝までに仕上げてもらう外注先（Managed Agents）」と対比しています。
多様な人が使う大規模な仕組みには、対話型（都度FBしながら作る）から、委託型（確かな納品物を仕組みで生み出す）への移行が必要になる場面もでてきます。都度FBできる環境ではなくなるからです。確かな納品物をAIネイティブに生み出せるようシステム化する必要がある。
Anthropicが「委託型」を出したこと自体が、AIの活用が個人の対話から組織の仕組みに拡張するフェーズに入った兆候と言えます。そして、その仕組み化の設計こそがBiz x Techの協業領域です。Bizが「何を納品物とするか」を定義し、Techが「どう安定して出力するか」を設計する。個人だとこの使い分けが偏る。対話型に寄りすぎるか、委託型に頼りすぎるか。
最近よく語られる「エージェントハーネス」という概念も、こういった文脈の中でのBizとTechの接合点だとも考えられます。90%合っていても10%間違えるなら誰にも使われない業務において、決定論的なアプローチとAIの推論を組み合わせて、初めて業務で使えるものになる。この設計にはまさにBiz的な要件定義力とTech的な設計力の両方が求められます。
結論が出なかった問い
ともあれ、AIの力でチームの少人数化は確実に進みます。そのとき何を考えるべきか。
最適人数は何人か。 BizとTech最低1人ずつ＝2人で回せるのか。3人目に何の役割が要るか。市岡からは「自分がどの方向性で仕上がっていくべきか」という悩みが出ました。スペシャリストになったら機械に殺されるリスクがあるが、中途半端にジェネラルでもAIでできてしまう。ベースがAIで埋まる前提での人材設計が必要です。
「溶ける人材」が増えたとき、チームの意味は変わるか。「事業の最終責任を追うとき、技術関連のトレードオフを理解して意思決定する力」はAI前と変わらず重要です。BizDevとしてTech関連の内容を理解し、最終責任者として判断する。これは「溶ける」とは別の、責任の分担の話です。
ハーネス設計自体をAIが担うようになったとき、人間に残るのは何か。 Anthropicの新モデルがセキュリティの穴を見つけすぎて一般公開を見送ったように、テック側の領域はAIとの相性が良い、あるいは良すぎる。この先、人間に残る領域はどこか。まだ解像度は低いですが、考え続けるべき問いです。
おわりに
BizとTechの両方が大事で、なかなか両立できない。だからチームでやる。
実はこの話、AI時代だから変わったかと言えば、本質は変わっていません。エンジニアもBizDevもできた方がいいのは昔からそうです。ただ、AIでベースが底上げされたことで、「だけのBiz」も「だけのTech」もいらなくなった。重要度の傾斜が変わったのです。
私たちは引き続き、その傾斜の最適解を探していきたいと考えています。
