新規事業が一つうまくいっても、次の案件がまた白紙から始まる。成功事例はあるのに、会社の成功確率は上がらない。原因は、学びが成果物と担当者の経験に閉じ込められているからです。
並行する案件を切り離す設計は正しい一方で、失敗だけでなく成功も閉じ込めます。だから横展開には、「抜き出して、移す」という独立した工程が必要です。
本記事では、成功を型に変える5項目、実行・伴走・俯瞰の役割分担、日々の流れと評価ゲート、一周後の3つの判断を整理します。
【結論】AI時代の新規事業で、先に設計すること
| 案件の分離は失敗の波及を防ぐが、成功の学びも隣へ伝わらなくする横展開するのはアプリや資料ではなく、意思決定と成立条件を含む「型」である型には、決定・理由・成立条件・限界・やらなかったことの5項目を残す実行・伴走・俯瞰を分け、評価ゲートで太らせる・複製する・止めるを判断する |
輪が閉じた。しかし、話はここから始まる
第2部で、4週間のプロジェクトが輪として一周した話を書いた。締め切りが契約に入っていたこと、契約を守らせ続ける人が別にいたこと、評価の物差しを構造側に置いたこと。この3つで、一本の線が輪になった。
では、その次に何をするのか。
多くの組織がここでつまずく。一周した、良かった、で終わる。 そして次の案件は、また白紙から始まる。
なぜそうなるのかを、まず構造から説明したい。
切り離されていることの、あまり語られない裏側
案件を並行して走らせるとき、鉄則がひとつある。ひとつの案件の失敗が、別の案件を止めてはいけない。
ある顧客向けの案件が炎上しても、別の顧客向けの案件は独立して進む。だから案件はそれぞれ別のワークスペース、別のチーム、別の進行で動く。これは正しい設計である。
ただしこの原則には、あまり語られない裏側がある。
切り離しは、失敗を閉じ込めると同時に、成功も閉じ込める。
ある案件で得た成功は、放っておいても別の案件には伝わらない。切り離されているから伝わらない。これは不具合ではなく、設計通りの動作である。
4週間の案件で得られた「輪は実際に回る」という実証も、まずはその輪の中にいた人たち——現場推進のSさん、育てる役のKさん、そして事業開発の担当者——の経験として閉じている。別のクライアント向けの案件には、何もしなければ何も伝わらない。
つまり、成功を横に広げるには、意図的に「抜き出して、移す」工程が要る。 自動では起きない。ここが、この記事でいちばん言いたいところである。
抜き出すべきは、成果物ではなく型
では、何を抜き出すのか。作ったアプリそのものではない。
抜き出すのは型である。この案件でいえば、たとえば次のようなものだ。
期限の置き方 — なぜその長さだったのか。それが何を強制したのか
作る人と育てる人を1人にまとめるという判断 — どういう条件のとき、それが正しいのか
評価の物差しを構造側に置く姿勢 — 個別の出来ではなく、一周したかを見る
これらは、別の顧客でも、別の商材でも、別の期間でも成立する。だから移植できる。
逆に、これを言語化しないとどうなるか。学びはその案件の中で完結し、組織全体の資産にはならない。次の案件で、また同じことを一から学び直す。 これが「一周した、良かった、で終わる」の正体である。
型を抜き出すとき、実際に何を書くか
関連記事：BMCの9マスを埋める前に一次情報を検証する方法を見る
- 「型として言語化する」と言われても、何を書けばいいのか分かりにくい。ここは具体的に書いておきたい。
- 抜き出すときに埋めるべきなのは、次の5つである。
- 何を決めたか — 4週間で切る。作る人と育てる人を分けない。評価は輪が回ったかで見る
- なぜそう決めたか — 一周させるのに必要な最小単位として逆算した。引き継ぎのロスが専門性より大きいと判断した
- どういう条件で、それが成立したか — 少人数だったから。全員が同じ文脈を持っていたから。実クライアントとの関係が既にあったから
- どこから先は、成立しないか — 期間が3倍になったら。関わる人が2桁になったら。文脈の共有が無い相手が入ったら
- やらなかったこと — 途中で追加の要望を受けなかった。完成度を上げるための延長をしなかった
このうち、いちばん抜けやすいのが3と4である。決めたことと理由までは、議事録を見れば書ける。しかし「どういう条件下でそれが機能したか」は、意識して書かないと残らない。
そしてこの2つが無いと、移植した先で失敗する。条件を書かずに型だけ渡すと、条件の違う場所でそのまま適用されて、うまくいかず、「あの型は使えない」という結論だけが残る。
- 型を渡すというのは、やり方を渡すことではない。やり方と、それが効く範囲をセットで渡すことである。
誰が張り付き、誰が引いて見るか
ここで、役割の話をしておきたい。
この案件では、3つの層が別々に機能していた。
実行 — 育てる施策を実際に打つ（Kさん）
伴走 — 輪の中に張り付いて、日々の進行を見続ける（Sさん）
俯瞰 — 輪全体を「一周したか」で評価し、次を決める（事業開発の側）
これは能力の優劣の話ではない。必要な性質が違うという話である。
輪に張り付く仕事には、現場の変化に即座に反応する速さが要る。輪を俯瞰する仕事には、複数の案件を並べて比べる視野の広さが要る。両方を同時に一人に求めると、どちらの質も落ちる。
多くの組織が「新規事業部門」や「インキュベーション部門」を作って機能しない理由も、おそらくここにある。輪を回す仕事と、輪を俯瞰して配分を決める仕事を、同じ人・同じ会議体に押し込んでいる。 前者は現場に張り付く仕事、後者は現場から一歩引く仕事なので、混ぜると両方が中途半端になる。
箱を作ったのに機能しないとき、疑うべきは人選ではなく、この2つを混ぜていないかである。
日々は流し続け、節目で立ち止まる
進め方についても、ひとつ書いておきたい。
仕事の進め方には大きく二つある。全員の作業が揃うのを待ってから次に進むやり方と、待たずにそれぞれ流し続けるやり方である。
日々の活動は、基本的に後者であるべきだ。育てる施策も、現場推進も、何かの完了を待ってから動くのではなく、連続して流れ続けているほうが速い。待つ時間が、そのまま失われるからである。
一方で、輪が一周し終えたタイミングだけは、意識して立ち止まる。 ここは全体を並べて見る瞬間である。個別の数字ではなく、輪そのものを見る。
日々は流し、節目で止める。この使い分けができていたことが、この案件の進み方を支えていたと思う。
逆に言うと、立ち止まる瞬間を設計していないと、評価は永久に来ない。 流し続けるやり方には、自然に終わるタイミングが無いからである。第2部で書いた「締め切りが契約に入っていた」というのは、この立ち止まる瞬間を、あらかじめ予約していたということでもある。
一周したあとの、3つの選択肢
- 輪が一周し終えたとき、俯瞰する側が下すべき判断は、突き詰めると3つしかない。
- 太らせる — 追加で投資して、この輪を大きくする
- 複製する — 型として抜き出し、別の案件へ移す
- 止める — ここで畳む
大事なのは、この判断をあらかじめ決めたルールではなく、輪が実際に生み出したデータで決めることである。検証の結果、契約の妥当性、現場で出てきた学び。それらを見てから、その都度決める。
- 「新規事業は3年やる」のような固定ルールは、判断しなくてよくなる代わりに、判断していない。
そして今回の案件でいえば、問うべきなのは「このアプリを拡大するか」だけではない。より本質的なのは、「この輪の型を、他のクライアント向けの案件に複製できるか」という問いである。個別のプロダクトではなく、輪そのものを資産として扱う問いだ。
渦中の人には、渦の形が見えない
ここまでを、ひとつの原則にまとめる。
輪の中の個々の仕事を良くするのは、現場の仕事。輪を一周させるのは、伴走者の仕事。しかしその輪が持つ構造を取り出して、別の輪に移せる形にすることだけは、輪の中にいる人には構造的にできない。
渦中にいる人は、渦中にいるという理由だけで、渦そのものの形を見ることができないからである。
これは能力の問題ではない。位置の問題である。だから、輪から一歩引いた場所に、誰かが立っていなければならない。
その仕事に名前をつけるなら、インキュベーションと呼ぶのが近い。ただし部署名としてではなく、機能の名前としてである。
まとめ
- 案件を切り離すのは正しい。ただし切り離しは、失敗と一緒に成功も閉じ込める
- だから成功を横へ広げるには、意図的に抜き出して移す工程が要る。自動では起きない
- 抜き出すのは成果物ではなく型。期限の置き方、役割の畳み方、評価の物差し
- 実行／伴走／俯瞰は性質の違う仕事。同じ人に押し込むと全部が中途半端になる
- 日々は流し続け、節目でだけ立ち止まる。立ち止まる瞬間を設計しないと評価は来ない
- 一周後の選択肢は3つ。太らせる、複製する、止める。実データで、その都度決める
一本の線として始まったプロジェクトは、4週間かけて輪になった。そしていま、その輪を見て、次にどれを太らせ、どれに同じ型を移すかを決める段階にいる。ここからが本番である。
よくある質問（FAQ）
Q. 新規事業の成功事例は、何を横展開すべきですか？
成果物そのものではなく、何を決め、なぜ決め、どの条件で機能し、どこから先は機能しないかという意思決定の型です。やらなかったことも残すと、移植先での誤用を減らせます。
Q. 新規事業のインキュベーション部署を作れば解決しますか？
部署名ではなく機能が重要です。輪の中で実行・伴走する人と、一歩引いて複数案件を比べ、投資配分を決める人を分けてください。同じ人・同じ会議体へ押し込むと両方が弱くなります。
Q. 成功パターンは、テンプレートにすれば再現できますか？
テンプレートだけでは不十分です。成立条件と限界を書かない型は、条件の違う案件へそのまま適用され、「使えない型」と判断されます。型と適用範囲をセットで移します。
この連載を順番に読む
- 第1部｜AI活用で新規事業はどう変わる？「指示・回す・つなぐ」3段階
- 第2部｜新規事業のMVP検証を4週間で回す方法
- 第3部｜新規事業の成功事例を横展開する方法
- 第4部｜AIループインキュベーションとは？
公開順：第1部 → 第2部 → 第3部 → 第4部。4本を公開後、相互リンクの到達確認を行ってください。
アルチェコに相談する
| 成功した一案件を、会社の資産に変えたい方へ 再現できる「型」と投資判断の仕組みを設計しませんか アルチェコは、複数の新規事業を並行して検証し、一次データから意思決定の型を抽出します。実行・伴走・俯瞰の役割、評価ゲート、太らせる・複製する・止めるの判断まで伴走します。 ▶ 新規事業の横展開について相談する 初回相談では、現状のフェーズ・検証したい仮説・社内の意思決定条件を整理します。相談内容が固まっていなくても問題ありません。 |
この記事を書いた会社について（アルチェコ）
アルチェコ（ARCHECO）は、AI戦略・生成AI導入・AIエージェント開発・UX/UIデザイン・MVP/PoC開発・グロースを横断する新規事業の共創パートナーです。戦略だけ、開発だけで分断せず、仮説設計から実市場での検証まで一貫して支援します。
Yasu
Yuki Susai
