エンジニア見積もり面接の対策：不確実性を判断材料にする

工数、経過時間、チーム容量、インフラ費用、概算規模は別の数字です。誰が何の判断に使うか、完了に含む範囲、期限・範囲・品質のどれを動かせるかを聞きます。

曖昧な依頼をすぐ人日に変換しません。手元の情報に合った確度を示します。初期見積もりは計画の幅であり、約束ではありません。

調査、設計、実装、データ移行、テスト、公開、運用後の確認に分けます。依存関係、未経験領域、並行できる作業を示します。コードを書く時間だけでなく、連携とレビューも含めます。

過去の実績は、本当に比較できる場合に使います。分野、チーム習熟度、データ量、外部依存の違いを説明し、数字だけを流用しません。

「既存認証を使いデータ移行がなければ2〜3人週です。新しい認証方式や外部事業者の承認が必要なら4〜6人週です」のように話します。前提が、幅が動く理由を示します。

根拠のない一律バッファを隠して足しません。不確実性を特定の作業に付け、調査、試作、サンプル移行、依存先確認で減らす方法を言います。

初期版を一つの事業者、予定作成と取消、トークンの安全な保存、再試行、同期状態表示、テスト、段階公開とします。定期予定と双方向の競合解消は除外します。既知の作業を見積もり、事業者承認とトークン更新をリスクとして分けます。

2日間の連携調査後に初期幅を実装見積もりへ更新し、定期予定を対象外のままにするか決める、と確認時点を置きます。最初の数字が新しい情報でも変わらないふりをするより現実的です。

計画日と確度、条件を一緒に答えます。「外部承認が8月15日までに完了する前提で、9月30日を約70%の確度で計画します。遅れた場合は手動出力を代替にするか、公開日を変更します」のようにします。

その後、範囲削減、並行できる箇所への経験者追加、日付変更の交換条件を示します。密結合した作業や未知の仕事は、人数を増やしても比例して短くなりません。

実際に公開した機能を、所要時間を見ずにもう一度見積もります。範囲、作業分解、幅、前提、確認時点を書き、実績と比べます。差を、作業漏れ、範囲変更、依存先遅延、技術的発見、実行差に分けます。

面接では、実績をどう追い、いつ再見積もりするかで終えます。チームに必要なのは、学習に合わせて良くなる見積もりです。