明確なビジネス要件から始める

適切なITアウトソーシング・プロバイダーは、単に最低賃金の時給ではなく、実際にビジネスが何を必要としているかに依存します。期待される成果を最初に定義します。顧客ポータル、クラウド移行、モバイルアプリ、ヘルプデスク、データプラットフォーム、または継続的なアプリケーション保守など。ユーザー、コア機能、統合、コンプライアンス要件、ローンチ日、プロジェクトの成功を示すビジネスメトリクスを記録します。

ベンダーと話す前に、必須要件と任意の改善点を分けて考える。例えばオンライン予約プラットフォームでは、初リリース時にアカウント作成、決済処理、予約リマインダー、管理者ダッシュボードが必要になる場合がある一方、ロイヤルティポイントやパーソナライズされた推奨は後回しにできる。この区分は、プロバイダーが作業量をより正確に見積もるのを助け、提案が不必要に高額または曖昧になるのを防ぐ。

適切なアウトソーシング・モデルを選ぶ

アウトソーシング・プロバイダーは通常、異なるエンゲージメント・モデルをサポートしており、それぞれのモデルは異なるマネジメントのニーズに適している。スタッフ・アジャストメントは外部の開発者、テスター、エンジニアを既存チームに加える一方、プロジェクトベースのアウトソーシングはプロバイダーが定義された製品の提供責任を負う。マネージド・サービスは、インフラ、サイバーセキュリティ、監視、アプリケーション保守の継続的なサポートが必要な場合により適している。

自社のコントロールと内部専門知識の程度を考える。プロダクト・マネージャーはいるが上級エンジニアリング・チームがいないスタートアップは、アーキテクチャとデリバリーを所有するプロバイダーの方が有益な場合がある。確立された技術リードを抱える大企業は、プロセス、リポジトリ、レビュースタンダードに従う2名の外部開発者を好むかもしれない。早期にモデルを選択すると、同様の責任を評価するため、提案を比較しやすくなる。

技術能力と業界適合性を評価する

ベンダーの、ソリューションに実際に必要となる技術（プログラミング言語、データベース、クラウドプラットフォーム、API、テストツール、デプロイ方法）における経験を確認する。あらゆる技術を列挙するベンダーであっても、有意義な経験を欠くことがあるため、類似システムの例とそれぞれのプロジェクトで果たした具体的な役割を求める。実践的なエンジニアリング作業の証拠、例えばアーキテクチャの決定、性能改善、移行計画、インシデント対応手順の証拠を探す。

製品が機微情報や規制対象情報を扱う場合、業界知識も重要になる。たとえばヘルスケア・プラットフォームでは、単なるマーケティングサイトよりも強力なアクセス制御、監査証跡、データ保持ルールが求められることがある。プロバイダーがセキュリリティ・レビュー、依存関係の更新、バックアップ、運用時インシデントの処理をどのように行うかを尋ね、営業プレゼンテーションだけに頼るのではなく、提案チームとの技術ワークショップを依頼する。

リファレンスと納品履歴を確認する

同規模のプロジェクト、技術スタック、または運用モデルを持つクライアントからリファレンスを求める。クライアントの満足度だけを問うのではなく、提供者が要件不適合、製品欠陥、範囲変更、コミュニケーション問題をどのように処理したかを尋ねる。難しい事象と解決プロセスを説明できるリファレンスは、一般的な賛辞を述べるリファレンスよりも有用な情報を提供することが多い。

機密性が許す範囲で具体的なアーティファクトを通じて提供者の納品履歴を検証する。匿名化されたスプリントレポート、リリースノート、品質ダッシュボード、インシデントの要約、またはプロジェクト管理ワークフローのデモなどが例として挙げられる。提供者が四カ月の立ち上げを約束する場合、ディスカバリー、デザイン、開発、テスト、ユーザー受け入れ、リリース準備をどのように分割するか、そしてそのタイムラインを変える可能性のある前提は何かを尋ねる。

価格、契約、所有権を比較する

総コストとビジネスリスクで提案を比較し、時給だけで比較してはいけない。低料金を提示する提供者は、あなたのチームのプロジェクト管理を more 要求したり、テストやデプロイを除外したり、現実的に必要な作業時間より少ない時間を見積もる場合がある。ディスカバリー、アーキテクチャ、文書化、プロジェクト管理、セキュリティテスト、クラウド設定、保守、ポストローンチサポートを価格に含むかを確認する。

契約は成果物、受け入れ基準、支払マイルストーン、変更要求、保証、解約権、第三者サービスの責任を明確に定義すべきである。支払い後に自社がソースコード、設計、文書、ドメインアカウント、クラウドアカウント、関連データを所有することを確認する。提供者が再利用可能なライブラリやオープンソースコンポーネントを使用する場合、適用されるライセンスとそれらのコンポーネントがどのように維持されるかを尋ねる。

コミュニケーションとチームの安定性を評価する

コミュニケーション品質は、技術的に有能な提供者の成功を左右する。作業言語、会議スケジュール、回答期待、報告形式、問題のエスカレーション経路、チケット、ソース管理、文書化、ビデオ通話のツールを確立する。実施可能なパイロットには、週次の計画会議、週に2回の短い進捗報告、未解決の意思決定にオーナーと期日が設定された共有バックログを含めると良い。

アカウントに誰が携わり、同様のプロジェクトで各人がどれくらいの経験を有しているかを確認する。名指しのソリューションアーキテクト、プロジェクトマネージャー、リード開発者が契約締結後も関与を続けるかを確認する。さらに、スタッフの離職、バックアップ体制、オンボーディング手順、知識移転についても尋ねる。1人の重要なエンジニアの喪失がビジネスの運用や製品の維持を困難にしないようにするためである。

大きなコミットメントの前にパイロットを実施する

短く明確に定義されたパイロットは、複数の提案会議よりも多くを明らかにすることがある。APIを1つ接続する、遅いレポートを改善する、クリック可能な製品プロトタイプを作成する、デプロイパイプラインを設定するなど、限定された作業を選ぶ。提供者には現実的な要件へのアクセスを与え、計画の正確性、コード品質、ドキュメント、セキュリティ習慣、対応力、リスクの早期提起のスピードを評価する。