撤収設計とは、伴走を始める前に「何ができていれば終われるか」を決めておくことです。ベンチャーネットは、動くものだけでなく、なぜそう作ったかという設計の意図と、判断の基準を社内に残すことを、終わりの条件にしています。
この記事では、外部の支援から抜けられなくなる仕組みと、それを避けるために何を残せばよいのかを整理します。契約書の書き方ではなく、実務として何がどこに置かれているかの話が中心です。
「うまくいっているのに、抜けられない」
外部の支援がうまくいかなかった話は、よく聞きます。けれども、もっと厄介なのはその逆です。
仕組みは動いている。現場も使っている。数字も改善した。それなのに、契約を切ることができない。切った瞬間に、誰も直せなくなるからです。
こうなると、支援は保険に変わります。成果のために払っているのか、止まらないために払っているのか、区別がつかなくなる。費用の性質が、投資から保険料へ変わるわけです。
依存は、たいてい悪意から生まれません。目の前の課題を解くことに集中していると、自然にそうなります。急ぐから、外部の人が手を動かす。うまく動くから、次も頼む。そのうち、なぜそう作ったのかを知っている人が、社外にしかいなくなる。
つまり依存は事故ではなく、設計の欠落として起きます。防ぎ方も、だから設計にあります。
何が残れば、終われるのか
「成果物は納品します」では足りません。動いているものだけを渡されても、それを維持できないからです。
残すものは4つあります。
図：残すのは動くものだけではない。設計の意図と判断の基準、そして読める人まで含めて撤収と呼ぶ。
①動くものは当然として、問題は②以降です。
②設計と意図は、「なぜその作りにしたか」の記録です。ここで大事なのは、採用した理由より捨てた理由のほうです。「この方法も検討したが、この業務では合わなかった」が残っていないと、担当者が代わったときに同じ失敗を繰り返します。
③判断の基準は、どこまでAIに任せ、どこから人が決めるかの線です。これがいちばん残りにくい。作業のなかで口頭で共有され、そのまま消えていくからです。
④直せる人は、社内に一人以上いる状態を指します。①〜③が揃っていても、読む人がいなければただの文書です。ここは「全部を理解している人」でなくてかまいません。どこを見れば分かるかを知っている人で足ります。
②と③は、置き場所を決めておかないと必ず散らばります。ベンチャーネットは言葉の基盤に集めます。
知財は「誰のものか」より「どこに置いてあるか」
契約書で知財の帰属を決めるのは、当然やることです。ただ、それだけでは足りません。
帰属が自社になっていても、実際にアクセスできなければ、実務としては同じことだからです。
図：契約上の帰属と、実務上のアクセスは別物。確かめるのは置き場所のほう。
確かめるのは、この4つです。
- アカウントの名義：AIサービスも、業務システムも、自社名義で契約されているか。支援側の名義で借りている状態だと、切った瞬間に止まります
- 設計の記録の置き場所：相手の社内文書に書かれているのか、自社が読める場所にあるのか
- 鍵と権限：管理者権限を自社も持っているか。「必要なときに渡します」は、必要なときに渡らないことがあります
- 止めた翌日に何が動くか：これを一度、頭の中で試してみてください。答えられない項目が、依存している箇所です
これは相手を疑う話ではありません。急いで進めると、誰でもこうなります。だから最初に決めます。
撤収は、最後にやる作業ではない
引き継ぎを終盤の一括作業にすると、うまくいきません。数か月分の判断を、最後の数日で言葉にするのは無理だからです。そのときには、なぜそう決めたかを本人も忘れています。
だから、撤収は3つの時点に分けて進めます。
図：終わりの条件は開始30日目に置き、理由は作業のたびに残し、終盤は社内の人が実際に手を動かす。
開始30日目は、最初の90日でいうゲート①にあたります。ここで、終わりの条件を置きます。
ただし、この時点で書けるのは仮のものです。何ができていれば終われるかは、業務を見る前には正確に決められません。だから30日目に一度置いて、90日目に書き直す前提にします。書けないから置かない、が最も危ない状態です。
終盤にやるのは、説明ではなく実演です。社内の担当者が、小さな変更を実際にやってみる。ここで詰まった箇所が、残せていなかったものの在処です。説明を聞いて分かった気になるのと、自分で直せるのは別物です。
終わっても、ゼロにはならない
正直に書いておきます。撤収したからといって、手間がなくなるわけではありません。
作ったものは、動かし続ける限り手間がかかります。使っているサービスの仕様が変われば直す必要がありますし、動かなくなれば原因を探すことになります。作るコストは下がっても、動かし続けるコストは下がっていないからです。
だから撤収の条件には、「誰が面倒を見るか」と「いつやめるか」を含めます。維持する前提だけを引き継ぐと、増えたものが積み上がって、数年後に別の重さになります。この先の話は作れるようになった会社が、次にぶつかる壁で扱っています。
「終わる」とは、支援がゼロになることではありません。自社で回せる状態になり、外部を使うかどうかを自社が選べることです。選べるなら、また頼んでも構いません。選べないことが問題なのであって、頼むこと自体が問題ではないからです。
見積の段階で、聞いておく質問
パートナーを選ぶときの基準はFDEを中小企業で使うには？に5つ挙げましたが、そのうち撤収に関わるものを、ここでは聞き方まで具体化します。
質問1「知財はどちらに帰属しますか。あわせて、アカウントはどちらの名義になりますか」
前半だけだと、たいていの会社が「御社です」と答えます。後半をつけると、実務の設計が見えます。
質問2「終了時に、何が引き渡されますか。動くもの以外に何がありますか」
ここで「ドキュメント一式」とだけ返ってくる場合、中身を聞いてください。設計の意図と、判断の基準が含まれているかどうかが分かれ目です。
質問3「引き継ぎは、どの時点から始めますか」
「終了前にまとめて」という答えなら、実質やらないのと同じになりがちです。作業のなかで残していく設計になっているかを見ます。
答えの正しさより、即答できるかどうかを見てください。撤収を設計している会社は、この3つをいつも考えています。考えたことがない会社は、答えを組み立てる時間が要ります。
よくある質問
Q. 撤収を前提にすると、支援会社は嫌がりませんか？
A. 長く続けたい会社は嫌がるかもしれません。ただ、終わり方を決めた仕事のほうが、進め方はむしろ明確になります。何を残すかが決まると、途中の作業の優先順位もはっきりします。
Q. 社内に「直せる人」を置けそうにありません。
A. 全部を理解している人である必要はありません。どこを見れば分かるかを知っている人で足ります。伴走の期間中に、その人が一緒に手を動かす時間を組み込んでおくのが現実的です。
Q. 契約書には、どこまで書くべきですか？
A. 知財の帰属と、終了時の引き渡し物の中身は書いておきます。ただし、契約書に書いてあることと、実際にアクセスできることは別です。アカウントの名義と権限は、契約書とは別に確認してください。
Q. すでに依存してしまっている場合、どうすればいいですか？
A. まず「止めた翌日に何が動かなくなるか」を一覧にします。全部を一度に解くのではなく、止まると困る順に、記録と権限を取り戻していきます。作った人が辞めた仕組みは、中身を読み解くより先に、止めてよいかを決めるほうが早いことがあります。
Q. 撤収したあと、また頼んでもいいのですか？
A. 構いません。自社で選べる状態なら、必要なときに頼むのは合理的な判断です。依存とは、選べない状態のことを指します。
Q. 内製化を目指すべきですか？
A. 目指す先はそこですが、最初から内製だけを狙うと続きません。外部と組んで成果を出しながら、社内に記録と担当者を残していく。撤収設計は、その移行を現実にするための仕掛けです。
Q. 終わりの条件が、始める時点で決められません。
A. それが普通です。だから30日目に仮で置き、90日目に書き直します。決められないから置かない、という状態がいちばん危ないところです。
まとめ：終わり方を決めると、途中が変わる
FDE型の伴走で残すのは、動くものだけではありません。設計と意図、判断の基準、そして社内で直せる人。この4つが揃ってはじめて、終われます。
そして知財は、帰属より置き場所です。契約で自社のものだと決めても、アカウントと鍵が相手側にあれば、実務としては動けません。止めた翌日に何が動き続けるか。この問いに答えられる状態を、最初から作っておきます。
ベンチャーネットは、中小・中堅企業向けにFDE型の伴走支援を行う会社です。数字の基盤（NetSuiteまたはOdoo）と言葉の基盤（Notion）の上でAIを動かし、業務と経営を組み替える。これをAX（AIトランスフォーメーション＝AIを前提に業務と経営を組み替えること）と呼んでいます。そして、始める時点で終わり方を決めます。設計の意図と判断の基準は言葉の基盤に置き、社内の担当者が実際に直せる状態を作ってから離れます。
最後に、これも道具の話ではありません。何を残し、何を止め、どこまで外部に任せるかを決めるのは、経営者の側です。AIも外部のパートナーも、その判断を引き受けてはくれません。
ただ、終わりの条件は、始める時点では正確に書けないことがほとんどです。業務を見る前に「何ができていれば終わり」と言えるなら、そもそも困っていないからです。だからベンチャーネットは、仮で置いて、途中で書き直す形にしています。その書き直しを一緒にやるところまでが、撤収設計だと考えています。
「今の外注先から抜けられる気がしない」という段階でも構いません。止めたときに何が止まるかを、一緒に並べるところから始められます。売り込みではなく、まず壁打ちから。
次に読むなら
「伴走が実際どう進むのか知りたい」
→ FDE型伴走の進め方——最初の90日で何が起きるか
「パートナーの選び方を知りたい」
→ FDEを中小企業で使うには？——エンジニアを雇わずに「現場に入り込む伴走」を手に入れる方法
「撤収したあとの運用が心配」
→ 作れるようになった会社が、次にぶつかる壁——増えたツールを「動かし続ける」コストの話
「記録をどこに置くのか知りたい」
→ 数字の基盤と言葉の基盤——NetSuite・Odoo×Notion×AIの設計図
「そもそもFDEとは何か」
→ FDE（Forward Deployed Engineer）とは？仕事内容・SESとの違い・中小企業での使い方
