判断の出発点
納期は開発工数だけでなく、決定やアクセス権にも左右されます。何が先に分かる必要があるかで仕事を並べます。途中に承認待ちがあれば、10人日の仕事が暦の10日間に収まるとは限りません。
具体例で考える
外部サービスで法人を確認するMVPを想定します。アクセス待ちでもフォーム設計は進みますが、認証情報、試験例、応答仕様がなければ連携成功を確認できません。依存事項に担当者と必要日を付けます。
日程と依存事項を一緒に管理する
必要な物、提供者、期限、準備完了の証拠を記します。APIアクセスには認証情報、テスト組織の利用許可、ネットワーク、エラー例が含まれるかもしれません。パスワードが届いただけで完了にしません。待つ開発者ではなく取得できる人に担当を置き、予測と一覧を一緒に見直します。
細い経路を最初から最後まで試す
並行作業を増やす前に重要な依存先を通る最小の流れを動かします。許可されたテスト要求、失敗した応答、利用者への状態表示までです。まだ変更しやすいうちに応答の違い、承認、足りない環境が分かります。模擬サービスが証明することと残す疑問を明記し、調査完了、連携確認、公開承認を別の到達点にします。
遅延を選択肢と結果で伝える
遅れたら影響する結果と、独立作業の続行、範囲変更、一時的な手作業、日程変更を説明します。仮の運用にも限界と担当者を付けます。日程を守ったように見せるために検証期間を全部削らないでください。分かったこと、不明点、次に予測を変える出来事を示します。早く理由が分かれば事業側が対処できます。
選択肢とその負担
独立した仕事は並行できます。模擬サービスは画面開発を進めても、実サービスの検証にはなりません。公開範囲を絞る方法もありますが、開発者を増やしても他社の承認は早まりません。
見落としやすい点
技術的な完了、顧客の受入、公開準備を分けます。休暇、原稿、データ修正、外部承認、製品判断の担当者を記録し、前提のない楽観的な日付を避けます。
依頼前に確認すること
最長の必須経路にある未解決事項は何か。遅れたらどうするか。独立して進む仕事は何か。MVP計画には、その回答と予測を更新する条件が必要です。