「締め切りを守らないなら切れ」「悪いところに良いお金を投じるな」——こうしたアドバイスに事欠くことはない。
しかし、切り替えに実際いくらかかるかを語るものはほとんどない。
フラストレーションは本物だ。遅延は本物だ。コミュニケーションの遅さも本物だ。しかし、フラストレーションは予算ではない。そして、開発途中でAgencyを別のAgencyに切り替えるという決断は、たとえそれが正しい選択であっても、最もコストのかかる決断の一つだ。
切り替える際に実際に支払うものを、ここで整理しよう。
サンクコストvs.スイッチングコスト——2つの異なる問題
開発途中でAgencyを切り替えるほとんどのFounderは、サンクコストを考えている——うまくいかなかった仕事に対して既に支払ったお金。その数字は現実であり、痛い。
しかしサンクコストは固定の損失だ。すでに支払い済みだ。スイッチングコストは、これから支払おうとしているコストだ——そして決断前にきちんと計算されることはほとんどない。
スイッチングコストには以下が含まれる：新しいAgencyのオンボーディングにかかる時間、生産的に動けるまでのランプアップ期間、引き継いだコードを理解するための「コード考古学」、引き渡し中に発生するバグ、そして新しいチームが前のチームが何を作ったかを把握する間に失われる何週間もの開発速度。
ほとんどのクライアントは、悪い状況から抜け出すことに集中している。「抜け出すことのコストは正確にどれくらいか？」と立ち止まって問う人は少ない。
Agencyが去るときに失われるもの
ソフトウェアプロジェクトには、契約書には決して現れないものが蓄積される：コンテキストだ。
コンテキストとは、何が決定されたかではなく、なぜその決定が行われたかの理解だ。なぜ認証フローはこの構造になっているのか？なぜあのサードパーティ連携は避けられたのか？なぜこのモジュールには奇妙なタイムアウトがあるのか？答えは通常、3ヶ月前のSlackのスレッドの中か、もうプロジェクトにいない開発者の頭の中にある。
Agencyが去ると、そのコンテキストも一緒に消える。新しいAgencyはコードを引き継ぐ——理解は引き継がない。ファイルは読める。その背景にある理由は読めない。
このギャップは直接的に時間へと変換される。新しいチームは、元のチームが何週間もかけてたどり着いた決断を「逆エンジニアリング」しなければならない。確信が必要なところで推測することになる。その推測のいくつかは間違いで、後になって——しばしば本番環境で——気づくことになる。
コンテキスト以外にも失うものがある：
- ドキュメント ——存在していれば。多くのAgencyは締め切りのプレッシャーの下で薄いドキュメントしか残さない。
- コード規約 ——命名パターン、フォルダ構造、内部では一貫しているが文書化されていないパターン。
- 関係資本 ——コミュニケーションを速くする非公式な信頼。新しいAgencyはゼロから始まる。
- 暗黙知 ——チームがビジネス、ユーザー、優先事項について知っていること。その知識を構築するには時間がかかった。
GitHubリポジトリを送ることで、これらのいずれも回復することはできない。
見えない時間コスト
ほとんどのクライアントが過小評価している数字がある：有能な新しいAgencyが引き継いだコードベースで本当に生産的になるまでに4〜8週間必要だということだ。
遅いからではない。別の前提で、別の規約で、もう質問に答えられない人たちによって書かれたコードを理解するには時間がかかるからだ。優れたエンジニアはその時間を真剣に取る——そうしないとバグを出荷することになるからだ。
その間、新しいAgencyへの支払いは続く。そして、その週そのものも失われる——本来はスプリントの時間であるはずだった週が、オンボーディングの時間になる。
元のAgencyが4週間遅れていたとして、新しいAgencyが6週間かけて慣れる必要があるなら、問題を解決したのではない——延長しただけだ。
新しいAgencyを評価・選定する時間（通常は先方ではなく自分たちの2〜4週間）、新しい契約の交渉、認証情報とアクセスの移行、新チームへの製品説明を加えると——新しいAgencyがフルスピードで動くまでの現実的な遅延は2〜4ヶ月になる。
これが時間コストだ。金銭的コストはそれと並行して走る。
切り替えが本当に価値ある場合
これはすべて「留まれ」という主張のように聞こえるだろうか？そうではない。
切り替えが正しい選択である状況があり——スイッチングコストは現実だが、それでも留まり続けるコストよりも低い場合がある。
以下の場合は、真剣に切り替えを検討すべきだ：
コードの品質が根本的に壊れている。 遅れているとか、荒削りとかではなく——壊れている。構築されたものがアーキテクチャ的に欠陥があるか、技術的負債があまりにも深刻で新しい機能のたびに下の層を作り直す必要があるなら、留まることの方が去ることより高くつく。
信頼が崩壊している。 コミュニケーションが止まった。約束は守られない。説明は現実と一致しない。信頼のないAgency関係はパートナーシップではない——それは消耗だ。
スコープが修復不能なほど逸脱している。 作られているものがもはや必要なものではなく、Agencyが方向修正できない（またはしようとしない）なら、留まることは間違った製品を完成させることを意味する。
Agency自体が解体しつつある。 チームの離職、リーダーシップの離脱、財務的不安定——これらは、契約書に何が書かれていても必要な継続性が存在しないことのサインだ。
これらの場合は、切り替えよう。しかし、目を開けて切り替えよう。スイッチングコストはまだ現実だ。回避しているのではなく——支払う価値があると判断しているのだ。
どのAgencyを使うにしても自分を守る方法
スイッチングコストに対する最善の保護は、必要になる前に切り替えをより安くすることだ。それは初日から組み込んでおくことを意味する：
契約書にドキュメント要件を明記する。 「最後にドキュメント化する」ではなく、週次ドキュメント、マイルストーンゲート。アーキテクチャの決定は記録し、ただ実行するだけでなく。
定期的なコードレビュー。 内部レビューだけでなく——進捗30%、60%、90%で外部の目を入れる。これによりアーキテクチャのドリフトを早期に発見でき、修正コストが低い段階で対処できる。
共有ナレッジチャネル。 自分のチームがプロジェクトコミュニケーションへの読み取りアクセス（または少なくとも定期的な文書ブリーフ）を持つべきだ。知識がAgency側だけに存在しないように。
段階的なアクセスと認証情報の管理。 すべての認証情報、環境、リポジトリを初日から自分で所有すべきだ。これは交渉の余地がない。切り替えが必要になったとき、アクセス権を取り戻すための戦いも同時にしていてはいけない。
正直なマイルストーンレビュー。 主要なマイルストーンはすべて自然な停止ポイントだ。それぞれで評価しよう——成果物だけでなく、関係とプロセスの健全性も。マイルストーン2で発見された小さな問題は会話だ。マイルストーン5で発見された同じ問題は危機だ。
まとめ
Agencyを切り替えることが正しい場合もある。しかし、無料な場合は決してない。計画していなかった時間を、予算していなかったお金を、そして再構築しなければならないモメンタムを消費する。
その決断を下す前に、計算しよう。現在のAgencyで失ったものだけでなく——次のAgencyに費やそうとしているものも。
留まる価値のあるAgencyとは、切り替えを不要にするAgencyだ。何か問題があれば早めにコミュニケーションを取る。継続的にドキュメントを残す。コードベースをいつか引き渡す可能性があるものとして扱う——実際にそうなるかもしれないと知っているから。
それが、関係がどのように終わっても自分のプロジェクトを守るAgencyだ。
