1. 撤退戦のコストシミュレーション
サンクコスト（埋没費用）は経営判断を鈍らせます。
従来の一括請負型と、いつでも停止可能な準委任/DaaS型で、プロジェクト中断時の損失額がどう変わるか比較します。
累積コスト推移の比較
下のスライダーで撤退（プロジェクト中止）月を変更してください。
従来型（一括請負）のリスク
契約解除の違約金 + 途中成果物の買取義務などが発生し、サンクコストが最大化しやすい。
DaaS型（柔軟契約）のリスク
実働分の精算のみ。いつでも停止できるため、傷口が浅い段階で撤退判断が可能。
『いつでも解約できる』という条件そのものが、ベンダー側の品質担保へのインセンティブとして機能します。
2. ベンダーロックインの正体と透明性
ロックインの恐怖は中身が見えないことから生まれます。
ブラックボックス化を防ぎ、自律的なコントロールを取り戻すための要素を比較します。
ブラックボックス開発
詳細仕様はベンダーの頭の中
-
✕
コード所有権が曖昧
独自のフレームワークやライブラリに依存し、他社が引き継げない。
-
✕
ドキュメント不足
動くものはあるが、なぜそう動くかの記録がない。
-
✕
人的依存
特定の担当者が辞めるとシステムが停止するリスク。
ホワイトボックス開発
いつでも引き継ぎ可能な状態を維持
-
✓
標準技術の採用
市場に技術者が多い言語・FWを選定し、代替可能性を確保。
-
✓
GitHub等での常時共有
顧客のリポジトリに毎日コミット。進捗も品質もリアルタイムで可視化。
-
✓
Exit Strategyの明記
内製化への移行プランを契約当初から設計。
パートナー選定のための評価軸（リスクレーダー）
ベンダーを選定する際、単なる見積もり金額だけでなく、以下の5つの軸で撤退のしやすさ（可逆性）を評価することが重要です。
- 透明性：情報へのアクセス権
- 標準性：技術スタックの一般的普及度
- 契約柔軟性：解約のハードル
- ドキュメント：設計意図の記録
- 自律支援：内製化への協力姿勢
3. 依存からの脱却：Exit Strategy
契約期間で縛るのではなく、価値でつながる関係へ。
万が一の際にスムーズに撤退・移管するためのロードマップを定義します。
Step 01 資産の所有権確保
ソースコード、デザインデータ、ドキュメントの著作権および所有権が発注側に帰属する契約を結びます。
リポジトリ（GitHub等）のアカウントは発注側が作成し、ベンダーを招待する形式をとります。
Step 02 ナレッジの非属人化
定例会議の議事録だけでなく、コード内のコメント、アーキテクチャ選定理由（ADR）をドキュメント化します。
なぜこのライブラリを使ったのかという文脈を残すことで、引き継ぎコストを最小化します。
Step 03 並走期間（オーバーラップ）
内製化またはベンダー切り替えの際は、1〜2ヶ月の並走期間を設けます。
この期間にペアプログラミングやコードレビューを通じ、実務レベルでの権限委譲を行います。
Goal 完全な自律（Independence）
外部パートナーがいなくなってもシステムが回り続ける状態。
これこそが、リスク管理の最終ゴールであり、経営者が目指すべき健全なシステム開発の姿です。