専属開発チームの立ち上げ直後は、開発量よりも「同じ基準で判断できる状態」を作る時期です。事業やシステムへの理解が浅いままタスクを増やすと、後から確認と修正に時間がかかります。
ここでは、最初の90日を「準備」「学習」「安定化」の3段階に分けました。実際の期間は、システム規模や既存資料の整備状況に合わせて調整してください。
最初の三か月の成否は、顧客側と開発側が同じ情報を見て、同じ基準で判断できるかに表れます。その状態を「準備」「学習」「安定化」の順にどう作るかを見ていきます。
開始前：目的と責任を合意する
契約前後に、次を確認します。
- 事業目的と優先する成果
- 対象プロダクト、技術、既存課題
- 顧客とベンダーの役割
- チーム構成と必要スキル
- バックログと最初の対象範囲
- 品質、セキュリティ、知的財産
- コミュニケーションとエスカレーション
体制表だけでなく、誰が仕様を決め、誰が受け入れ、誰が技術判断するかを明確にします。
1〜30日：環境と共通理解を作る
アクセスとセキュリティ
アカウントや端末、VPN、リポジトリなど、開発に必要な環境を準備します。権限は役割に必要な範囲に限定し、付与・変更・削除の責任者も決めます。
業務とアーキテクチャの理解
ユーザー、業務フロー、用語、主要機能、システム構成、外部連携、過去の重要判断を説明します。資料だけでなく、実際の画面や業務デモを使います。
最初の小さな成果
影響が限定され、レビューしやすいタスクを選びます。目的は速度ではなく、質問、実装、レビュー、テスト、リリースの一連の流れを検証することです。
31〜60日：開発リズムを安定させる
バックログと受け入れ条件
優先順位、依存関係、受け入れ条件を整えます。開発開始前に不明点を洗い出し、完成の定義を共有します。
定例、デモ、振り返り
進捗報告だけでなく、動く成果物を定期的に確認します。振り返りで見つかった改善点は、顧客側・ベンダー側それぞれの具体的なアクションに落とし込みます。
品質基準の標準化
コードレビュー、静的解析、テストなど、完了時に必要な作業をDefinition of Doneに含めます。セキュリティ確認やドキュメント更新も、対象に応じて明記します。
61〜90日：予測可能性と改善力を高める
この段階では、単純な開発量よりも、計画と実績の差、手戻り、欠陥、レビュー時間、リリース安定性を確認します。
- チームが業務背景を踏まえて提案できるか
- 課題を早期にエスカレーションできるか
- 品質基準がメンバー間で再現されているか
- 知識がコードと文書に残っているか
- 次の増員に耐えられるオンボーディングがあるか
必要であれば、QA、DevOps、専門エンジニアを追加します。人数を増やす前に、リーダー、レビュー、環境、バックログがボトルネックになっていないか確認します。
90日レビューで見る指標
| 観点 | 確認例 |
|---|---|
| 価値 | 優先機能が利用可能になったか |
| 予測 | コミットと完了の差を説明できるか |
| 品質 | 本番欠陥、再発、手戻り |
| 速度 | リードタイム、レビュー待ち |
| 連携 | 質問・判断の滞留時間 |
| 知識 | 手順、設計判断、オンボーディング資料 |
| 安全性 | 権限、脆弱性、監査ログ |
数値はチームを比較するためではなく、改善すべきボトルネックを見つけるために使います。
顧客側に必要な役割
専属チームを外部に置いても、プロダクトの責任まで移るわけではありません。顧客側には少なくとも、優先順位を決める責任者、仕様・業務を説明する担当、受け入れ判断を行う担当が必要です。
最初の30日をアクセス申請や資料探しだけで終えると、チームが事業とシステムを学ぶ時間が後ろにずれます。AMELAの専属チーム型オフショア開発では、開始前の準備を含む体制設計から、オンボーディング、開発・QA、運用改善まで段階的に支援します。
