30日間で専任の開発チームを立ち上げる方法

はじめに

アウトソーシング契約の多くは、初年度ではなく、最初の1ヶ月で失敗に終わります。エンジニアの資質も高く、料金も適正であるにもかかわらず、チームは数週間にわたり、アクセス権や背景情報、明確な優先順位が与えられないまま過ごしてしまいます。作業が開始される頃には、クライアントはすでにこのモデルへの信頼を失っているのです。

クライアント側が準備を整えていれば、専任の開発チームは30日以内にフル生産性を発揮できるようになります。ベンダーが採用や雇用手続きを担当しますが、製品、コードベース、ビジネス目標を説明できるのはクライアント側だけです。オンボーディングは共同プロジェクトであり、知識の移転の大部分はクライアント側が担います。

初日前に準備すべきこと

開始日の1週間前が、チームの動きの速さを決定づけます。リポジトリへのアクセス権を得るまで3日間待たされるエンジニアは勢いを失い、その遅れがプロジェクト全体の基調を決定づけてしまいます。

準備にはクライアント側で数時間の作業が必要です。その大部分は事務的な作業であり、1人でリスト全体の担当をこなせます。

• アクセス権とアカウント。コードリポジトリ、タスクトラッカー、クラウドコンソール、コミュニケーションチャネルのアカウントを作成してください。開始日前に、各ログインをテストしてください。
• 技術ドキュメント。アーキテクチャ図、APIの説明、セットアップガイドを一か所にまとめてください。変更箇所が明記されていれば、古いドキュメントでも問題ありません。
• 窓口。クライアント側で、1営業日以内に質問に回答できる担当者を1名指定してください。この担当者は通常、テクニカルリードまたはプロダクトオーナーです。
• 初期バックログ。複雑度が低～中程度のタスクを10～15件用意します。チームには、本番環境にリスクを与えずにコードベースを習得できる作業が必要です。

第1週：アクセス権、背景知識、最初のタスク

最初の1週間はオリエンテーションに充てられます。チームは、製品の機能、ユーザー層、コードの構成について学びます。

この週の成果物は、意図的に少なくなっています。目標は、機能のリリースではなく、作業環境の整備と最初のマージされた変更です。

1～2日目：環境のセットアップ

1日目、クライアント側がキックオフ会議を開催します。プロダクトオーナーがビジネスモデル、主なユーザー層、現在の優先順位について説明します。テクニカルリードがアーキテクチャとデプロイプロセスを解説します。

会議終了後、エンジニアはローカル環境をセットアップし、アプリケーションを実行します。セットアップに関する問題の多くはここで発生するため、クライアントの担当者は迅速に対応できるよう待機しておく必要があります。

3～5日目：最初の小規模なタスク

各エンジニアは、初期バックログから1つまたは2つのタスクを担当します。この段階では、バグ修正、小規模なUI変更、テストカバレッジの向上などが適しています。実際のコードを扱うものの、リスクは低くなります。

すべてのタスクは、コードレビュー、テスト、デプロイという完全なサイクルを経ます。これにより、チームはクライアントの業務体制を理解し、プロセス上の課題を早期に洗い出すことができます。

第2週：プロセスとコミュニケーションのリズム

2週目には、チームは個別のタスクからチームとしてのルーチンへと移行します。クライアントとベンダーは、作業の計画、協議、報告の方法について合意します。

分散型チームは、同一拠点のチームよりも厳格な体制が必要です。タイムゾーンや文化の違いにより、非公式なコミュニケーションが難しくなるため、コミュニケーションのリズムを明確に定義する必要があります。

• デイリースタンドアップ。両タイムゾーンが重なる時間帯に、短い電話会議を開催してください。進捗状況と障害要因の確認には15分で十分です。
• スプリント計画。1～2週間のスプリント単位で作業を計画します。クライアント側のプロダクトオーナーが優先順位を設定し、チームが工数を見積もります。
• コードレビューのルール。誰が何を、どのくらいのスピードでレビューするかを合意します。レビューの遅延が1日を超えると、チーム全体のペースが鈍ります。
• 書面による進捗報告。共有チャネルで毎週の短い要約を提出するよう依頼します。これにより、追加の会議を開かずにステークホルダーに状況を可視化できます。
• エスカレーション手順。双方において、障害要因を解決する担当者を明確に定義します。ベンダー側のアカウントマネージャーがチームの課題を、クライアント側の担当者が製品に関する質問に対応します。

第3～4週：主体性と成果測定

最後の2週間は、オンボーディングが機能したかどうかを検証する期間です。チームは真の責任を担い、双方が明確な基準に基づいて結果を検証します。

この段階では、プロセスのどの部分にまだ調整が必要かも明らかになります。小さな問題は、90日目よりも25日目のほうが修正しやすいものです。

実際の機能の引き渡し

第3週には、プロダクトロードマップから1つの完全な機能をチームに割り当てます。その機能は、設計上の決定を必要とし、コードベースの複数の部分にまたがり、本番環境へのリリースが必要であるべきです。

開発開始前に、クライアント側の技術リーダーが技術的なアプローチをレビューします。その後、見積もりからデプロイまで、チームが作業を主導します。この段階で過度な監督を行うことは、本来の目的を損なうことになります。

30日目に追跡すべき指標

月末に、ベンダーとのレビュー会議を開催します。結果を第1週に設定した期待値と比較し、可能な限り数値を用いて評価します。

• デリバリーペース。直近2スプリントにおける計画値と実績のストーリーポイントを比較する。高いペースよりも安定したペースの方が重要である。
• コード品質。1回目または2回目のレビューで通過したプルリクエストの割合を確認しましょう。頻繁な手直しは、文脈理解の不足を示しています。
• 質問件数。エンジニアがクライアントに支援を求める頻度を追跡します。この数は毎週減少するはずです。
• ステークホルダーからのフィードバック。プロダクトオーナーとテクニカルリードに簡単な評価を依頼しましょう。彼らの視点からは、指標では捉えきれない問題が明らかになることがよくあります。

オンボーディングでよくある失敗

オンボーディングの遅延のほとんどは、いくつかの共通した原因に起因しています。各原因が当初は些細に見えるため、企業は同じ過ちを繰り返してしまいます。

• アクセス遅延。3日目にアクセス権が得られるアカウントは、チームに3日分の遅れをもたらします。セキュリティ承認は予想以上に時間がかかることが多いため、早めに手続きを開始してください。
• プロダクトの文脈の欠如。ユーザーを理解していないエンジニアは、技術的には正しいが役に立たない決定を下してしまいます。1時間のプロダクト説明が、数週間にわたる手戻りを防ぎます。
• 連絡窓口が多すぎる。5人が指示を出すと、優先順位が食い違う。意思決定者を1人に絞ることで、方向性を明確に保てる。
• チームを外部扱いすること。別々のコミュニケーションチャネルや制限された会議は、二層構造を生み出します。クライアントの日常業務に溶け込むチームほど、迅速に統合されます。

まとめ

30日間あれば、専任チームをフル稼働させるのに十分です。結果はベンダーに左右されるというより、クライアントがアクセス権限、背景情報、明確な優先順位をどれだけ適切に準備できるかにかかっています。

オンボーディングを、責任者、期限、最終レビューが定められたプロジェクトとして扱ってください。体系的な最初の1ヶ月は、長期的な契約に必要な信頼関係を築く基盤となります。