time-resource-estimator

時間・リソース見積もり

過剰な約束はやめましょう。現実的な見積もりで、納期を守りましょう。

このスキルでできること

入力：プロジェクトの範囲と機能
出力：現実的なスケジュール、作業時間の内訳、バッファの計算、クライアントとのコミュニケーション

見積もりのフレームワーク

機能タイプ別の基本作業時間

認証とユーザー管理： 6～8時間

• ログイン／サインアップ
• パスワードのリセット
• ユーザーの役割
• セッション管理

CRUD 操作（モデルあたり）： 4～6時間

• 作成／読み取り／更新／削除
• 基本的な入力検証
• 一覧表示

フォーム（複雑なフォームあたり）： 3～5時間

• 入力検証
• エラー処理
• 成功時の状態表示

ダッシュボード／分析： 8～12時間

• データの可視化
• リアルタイム更新
• フィルタリング／並べ替え

ファイルのアップロード： 4～6時間

• ストレージの設定
• アップロード UI
• 表示／ダウンロード

PDF の生成： 6～8時間

• テンプレートのデザイン
• データのフォーマット
• ダウンロード／メール送信

メール通知： 4～6時間

• メールテンプレート
• トリガーロジック
• 送信インフラストラクチャ

連携（サービスあたり）： 10～15時間

• API の設定
• データのマッピング
• エラー処理
• テスト

モバイル対応： 合計時間の +20%

• レスポンシブデザイン
• モバイルでのテスト
• タッチ操作

---

バッファの計算式

バッファなしで見積もりを提示してはいけません。

目安：

• 基本見積もり：各機能の作業時間の合計
• 不確定要素や例外への対応として 25% を追加
• 修正やクライアントからのフィードバックへの対応として 15% を追加
• テストやバグ修正への対応として 10% を追加

合計：基本見積もり × 1.5

例：

• 機能の基本作業時間：60時間
• バッファ込み：60 × 1.5 = 90時間
• クライアントへの伝え方：「6～8週間」（「60時間」ではありません）

---

作業時間をスケジュールに換算する

フルタイム勤務（週40時間）：

• 40時間の作業 = 1週間
• 80時間 = 2週間
• 120時間 = 3週間

パートタイム勤務（週20時間）：

• 40時間の作業 = 2週間
• 80時間 = 4週間
• 120時間 = 6週間

以下のために、常に1～2週間を追加してください：

• クライアント側の遅延（フィードバック、アクセス、承認）
• 祝日／病欠
• 想定外の複雑さ

安全なスケジュールの計算式： （見積もり時間 ÷ 週あたりの作業時間）+ 2週間

---

プロジェクトのスケジュール内訳例

消防検査ソフトウェア（基本作業時間80時間）

第1～2週：基盤（20時間）

• プロジェクトのセットアップ
• データベース設計
• 認証
• 基本的な UI フレームワーク

第3～4週：主要機能（30時間）

• 建物管理
• 検査スケジュールの設定
• ユーザーの役割

第5～6週：現場向け機能（20時間）

• モバイル検査フォーム
• 写真のアップロード
• データ検証

第7週：仕上げとテスト（10時間）

• バグ修正
• UI の改善
• テスト

第8週：クライアントレビューと修正

• クライアントによるテスト
• フィードバックの反映
• 最終調整

合計：8週間（80時間 × 1.5 のバッファ ÷ 週20時間 = 6週間 + 2週間のバッファ）

---

クライアントへのスケジュールの伝え方

伝える内容： 「範囲に基づくと、キックオフからリリースまで 6～8週間 かかります。」

伝えてはいけない内容： 「作業時間は80時間なので、フルタイムで働けば2週間です。」

理由： クライアントにとって、作業時間は実感しにくいものです。週単位の期間ならイメージしやすくなります。

---

期待値の設定

提案時： 「スケジュール：6～8週間

以下を前提とします：

• 2営業日以内にフィードバックをいただけること
• システム／データへのアクセスをすぐに利用できること
• プロジェクトの途中で範囲が変更されないこと

いずれかが変わった場合は、スケジュールも調整されます。」

書面に残しましょう。 「なぜこんなに時間がかかっているのか」という事態を防げます。

---

スケジュールに影響する危険信号

❌ 「2週間で必要です」 → ある程度の規模があるものには非現実的です
❌ 要件が不明確 → 遅延や手戻りにつながります
❌ 関係者が複数いる → 承認に時間がかかります
❌ 「[複雑な SaaS] と同じようなもの」 → 複雑さを過小評価しています
❌ クライアントからの返答がいつも遅い → スケジュールが数週間延びます

対策： 契約にスケジュールの前提を盛り込みましょう。

---

時間がかかる場合

早めに正直に伝えましょう：

「こんにちは、[Client] さん

スケジュールについて、簡単にお知らせします。[feature] で予想外の複雑さが判明しました。そのため、スケジュールが 3～5 日延びる見込みです。

新しい納期：[original date] ではなく [date] です。

遅れてしまい申し訳ありません。急ぐよりも、きちんと仕上げたいと思っています。

[Your Name]」

期限に間に合わなくなるより、早めに期待値を調整するほうがよいでしょう。

---

見積もりチェックリスト

スケジュールを提示する前に、以下を確認してください：

• ✅ すべての機能を特定している
• ✅ 技術的な複雑さを評価している
• ✅ 統合要件が明確になっている
• ✅ クライアントの応答速度を考慮している
• ✅ 50% のバッファーを含めている
• ✅ テストにかかる時間を含めている
• ✅ 祝日や休暇を考慮している

不明点がある場合： バッファーを増やすか、「スケジュールを確約する前に、もう少し範囲を確認する必要があります」と伝えてください。

---

確信度マトリックス

確信度：高（±1 週間）：

• 類似プロジェクトの経験がある
• 要件が明確である
• 複雑な統合がない
• クライアントの応答が早い

確信度：中（±2 週間）：

• 不明点がいくつかある
• 新しい技術スタックを使用する
• クライアントの承認が遅れる可能性がある

確信度：低（±4 週間または「未定」）：

• 不明点が多い
• 複雑な統合がある
• 要件が曖昧である
• 関係者が複数いる

それに応じてバッファーを調整してください。

---

覚えておきましょう

控えめに約束し、期待以上の成果を出しましょう。

• 見積もり：6 週間
• 納品：5 週間
• クライアント：「わあ、仕事が早いですね！」

一方で

• 見積もり：3 週間
• 納品：6 週間
• クライアント：「どうしてこんなに時間がかかるのですか？」

同じ仕事でも、受け取られ方は違います。

バッファーを設けましょう。早めに納品しましょう。ヒーローのように見えます。