開発フェーズは、誰もが注目する時期です。スプリントがレビューされ、デモがスケジュールされ、Slackチャンネルは活発に動きます。すべてのマイルストーンを細かく追いかけます。
そしてプロジェクトがローンチされ、エージェンシーが作業を終え、関係は静かに……終わります。
6ヶ月後、決済の連携を更新する必要が出てきます。あるいはライブラリのサポートが終了し、アプリがエラーを出し始めます。新しいメンバーが入社したのに、誰もデプロイの手順を説明できません。エージェンシーに連絡すると、担当者が変わっていたり、小さな修正の見積もりが作業量に見合わない金額で返ってきたりします。
これこそが、アウトソーシング関係が実際に破綻する場所です。開発中ではなく、その後の長い沈黙の中で。
ローンチ後こそ、信頼が試される
エージェンシーは納品フェーズで優秀であろうとするインセンティブを持っています。その時期、クライアントは見ているし、請求書も支払われます。ローンチ後のサポートは違います。多くの場合、スコープが曖昧で、価格設定が低く、新しいより収益性の高いプロジェクトの後回しにされます。
これはすべてのエージェンシーへの批判ではありません。多くの契約モデルがそう機能しているというだけです。問題は、クライアント側ではローンチ後こそエージェンシーが最も必要な時期だということです。テスト中には現れなかったバグが本番環境で出てきます。ユーザーは予想外の動作をします。インフラの調整が必要になります。6ヶ月前の判断を理解した上での機能追加が求められます。
引き継ぎがきちんとしていてSLAが明確であれば、このフェーズは管理できます。どちらも存在しなければ、困難に直面します。
引き継ぎ時に必ず存在すべき3つのもの
エージェンシーがプロジェクトを締めくくる前に、機能とは関係のない3つの成果物があります。しかし長期的には、これらが機能リスト以上に重要です。
ドキュメント。 「これはLaravelアプリです」と書かれたREADMEではありません。本物のドキュメントです。システムが何をするのか、主要なコンポーネントがどのように繋がっているか、どのサードパーティサービスと連携しているか、開発中に行われた前提や判断で新しい開発者が知るべきこと。1年後に新しいメンバーが入り、元のエージェンシーに連絡できない状況で、自力で作業を進められるでしょうか？それが達成すべき基準です。
ランブック（運用手順書）。 ランブックは、開発者、運用担当者、またはあなた自身に対して、システムを稼働させ続ける方法を伝える運用ドキュメントです。どうデプロイするか。問題が起きたときどうロールバックするか。アラートは何を意味するか。データベースが遅い場合どうするか。書くのは退屈ですが、持つことは非常に価値があります。必ず要求してください。
バスファクターの低減。 「バスファクター」とは、何人が去るとプロジェクトが維持不可能になるかという数です。その答えが1人であり、その人がエージェンシー側にいる場合、深刻な依存問題を抱えています。引き継ぎとはファイルの移譲だけでなく、知識の移転を意味します。エージェンシーのチームがあなたの開発者やテクニカルリードと一緒にコードベースをウォークスルーするセッションをスケジュールしましょう。必要であれば録画してください。
良いメンテナンスSLAとはどのようなものか
メンテナンスのSLAはしばしば曖昧で、ほとんど意味をなしません。「24時間以内に回答します」では、どんな回答か、どんな問題か、その回答が解決につながるかどうか、ほとんど何もわかりません。
機能するメンテナンスSLAは重大度レベルを定義します：
- クリティカル（P1）： アプリケーションがダウン、またはコア機能が全ユーザーに対して停止。1〜2時間以内に対応、4〜8時間以内の解決を目標。
- 高（P2）： 主要機能が影響を受けているが、アプリケーションは稼働中。4時間以内に対応、24〜48時間以内に解決。
- 中（P3）： 一部のユーザーに影響する非クリティカルなバグ。1営業日以内に対応、5営業日以内に解決。
- 低（P4）： 軽微な問題、UIバグ、UXの改善。定期メンテナンスサイクルにまとめて対応。
また、月次リテイナーに含まれるものと別途請求されるものを明確にすることも必要です。新機能の開発はほぼ常に別料金です。エージェンシーが書いたコードのバグ修正は含まれるべきです。インフラ障害は誰がインフラを管理しているかによります。これらの境界線を文書化してください。
知識の引き継ぎ：人質状況を避ける
ソフトウェア開発について最も不都合な真実があります。コードベースを理解しているのが1つのチームだけなら、そのチームはあなたを支配しています。
これが意図的であることはほとんどありません。1つのチームが数ヶ月かけて何かを構築し、その過程で知識を共有しないことで生まれる自然な結果です。彼らが去るとき、知識も一緒に消えます。
自分を守るということは、プロジェクトが終わる前に知識移転に積極的に投資することを意味します：
初日からのコード所有権。 コードはエージェンシーのアカウントではなく、あなたのアカウント配下のリポジトリに置かれるべきです。これは交渉の余地がありません。いつでも、エージェンシーの許可なく新しい開発者にアクセス権を付与できる状態でなければなりません。
アーキテクチャレビューセッション。 エージェンシーが終了する前に、あなたの社内チームや技術アドバイザーに対してシステムを説明するセッションを少なくとも2〜3回スケジュールしてください。デモではなく、なぜそのように構築されたかの説明です。
意思決定の文書化。 アーキテクチャ決定記録（ADR）は重要な選択を残すシンプルなドキュメントです。「PostgreSQLを選んだ理由は…」「このサービスにマイクロサービスパターンを使った理由は…」。書くのに時間はかかりませんが、新しいチームが数ヶ月の熟慮の末の選択を無意識に覆すことを防ぎます。
段階的な移行。 予算が許すなら、エージェンシーとの関係を突然終わらせないでください。新しいメンテナー（社内または新しいエージェンシー）が元のチームと4〜6週間並行して作業する移行期間を設けてください。質問はリアルタイムで答えられ、コンテキストは自然に移転します。
署名前に確認すべき質問
ほとんどのクライアントは納品能力——ポートフォリオ、プロセス、技術スタック、価格——でエージェンシーを評価します。ローンチ後に何が起きるかを尋ねる人は少ないです。これらの質問はすべての評価プロセスに含まれるべきです：
「標準的な引き継ぎパッケージには何が含まれますか？」 困惑した表情や曖昧な回答が返ってくるなら、それが答えです。
「他のクライアントで使用したメンテナンスSLAの例を見せてもらえますか？」 実際の例を求めることで、経験のあるエージェンシーと契約を取るためだけに約束するエージェンシーを区別できます。
「プロジェクトの元の担当者が対応できなくなった場合はどうなりますか？」 優れたエージェンシーは知識の継続性のためのプロセスを持っています。そうでないエージェンシーはそんなことは起きないと言うでしょう。
「製品を構築した後、別のエージェンシーに移行したい場合はどうなりますか？」 答えは「簡単にできます」であるべきです。あなたのリポジトリにコードが、あなたの手元にドキュメントが、あなたのアカウントにインフラがあることを意味します。それ未満はレッドフラグです。
「ホスティングとインフラのアカウントは誰が管理しますか？」 すべてはあなたの名義でなければなりません。あなたのクラウドの認証情報、あなたのドメイン、あなたのメール配信サービス。あなた自身が自分の製品のオーナーです。
長期的な視点で考える
ソフトウェアプロダクトはローンチで完成しません。廃止されるときに完成します——そして通常はそれが数年後のことです。最初のバージョンを構築するために雇うエージェンシーは、その後のすべてのバージョンの基盤を構築しています。
ローンチ後のメンテナンスは、謎や人質交渉のように感じるべきではありません。引き継ぎが丁寧で、ドキュメントが実質的で、SLAが具体的であれば、本来あるべき姿になります：正常に動いているものの定期的なメンテナンス。
これをうまくやるエージェンシーは、あなたに恩着せがましくしているわけではありません。仕事をしているだけです。評価するエージェンシーに同じ基準を要求してください——ローンチ後ではなく、署名する前に。
