開発工数見積もりの考え方〜失敗から学ぶ実践プロセスと注意点〜

こんにちは。テクニカルディレクター/ソフトウェアエンジニアの池澤孝治です。
この記事は Goodpatch Advent Calendar 2025 22日目の記事です。

ここ数年、テクニカルディレクターとして様々な案件に関わってきました。また先日、開発マネージャーが育児休業中であったことから代理として開発マネージャーを務めたりもしています。その中で、商談などの早期段階での開発提案に携わる機会も多くなりました。そこで開発工数見積もりや予算、体制設計の重要性を改めて感じました。

開発工数見積もりは、プロジェクトの特性やドメイン知識によって条件が大きく異なり不確実性も高いため、万能な方法論や正解を見つけるのは難しいです。

またAIによる効率化が進む現在において、AIに任せるべき部分と人間が判断すべき部分の切り分けについても取り上げてみます。将来的にはより改善された開発工数見積もり手法が登場していくものと予想されます。

私は開発工数・予算・体制見積もりのプロフェッショナルという訳ではなく、まだまだ勉強したり試行錯誤をしている最中ですが、今回はその中で学んだ経験や失敗談を元に、開発工数見積もりの考え方や注意点をご紹介します。

開発工数見積もりの前提知識
- 一般的な開発工数見積もり方法
- 基本的な開発プロセスの全体像
ハマりやすい3つの問題
開発の工数・予算・体制をどう見積もるか
- 開発工数見積もりの全体ステップ
要件定義フェーズ
実装フェーズ
- 実装タスクの洗い出し
- 開発複雑性と不確実性の評価
  - 複雑性
  - 不確実性
テスト・品質・納品準備フェーズ
工数・体制・スケジュール算出
AI活用による時間短縮やコスト削減
まとめ

開発工数見積もりの前提知識

一般的な開発工数見積もり方法

一般的に開発工数見積もり方法には、WBS積算法（ボトムアップ見積法）、類推法（トップダウン見積法）、パラメトリック法（係数法）などがあります。

見積もり方法	説明
WBS積算法（ボトムアップ見積法）	タスクを細分化して洗い出し、それぞれの工数を合算して全体の工数を見積もる方法です。※WBS=Work Breakdown Structure（作業分解構成図）。
類推法（トップダウン見積法）	過去の似たようなプロジェクト内容や規模のデータを元に工数実績を見積もる方法です。
パラメトリック法（係数法）	過去の工数実績からタスク要素を変数にし、統計的な係数や重み計算によって見積もる方法です。

今回私が使用するのは、定番の「WBS積算法（ボトムアップ見積法）」を元にプロダクトでの各作業をタスク分解して工数を見積もる方法です。これはタスク要素が明確で、後から予算内調整やタスク追加削減、アサイン人数の調整もシンプルで試行錯誤がしやすいという利点があります。

基本的な開発プロセスの全体像

以下に、一般的な開発プロセスの流れと各フェーズで発生する主なタスクを紹介します。
ここでは、Webアプリケーションやモバイルアプリケーション開発を想定しています。

1. 要望整理・リサーチ
・ビジネスゴール・KPI確認
・現状システム・業務フロー把握
・競合・類似サービス調査
2. UX体験、提供価値設計
・体験シナリオ／ユースケース整理
・提供価値・ペルソナ整理
・ユーザーテスト／プロトタイプ（必要に応じて）
3. 機能整理・情報設計・フィジビリティ
・必要機能・優先度の整理
・UI情報設計（項目・ルール）
・技術選定・アーキテクチャ設計
・技術的フィジビリティ検証（PoC など）
・非機能要件（性能・セキュリティ・運用）の整理
4. 要件定義・設計・テスト方針
・機能要件定義・UI仕様作成
・UIワイヤーフレーム・画面遷移図・デザインガイドライン作成
・基本設計・技術構成・API設計
・非機能要件設計（表示パフォーマンス・セキュリティ・アクセス集計・運用）
・テスト計画・品質基準の策定
5. 実装（FE/BE・インフラ）
・フロントエンド／バックエンド開発
・管理ツール・CMS（必要に応じて）
・CI/CD構築、コードレビュー、ユニットテスト
6. 各種テスト・UAT
・結合／システム／E2Eテスト
・脆弱性診断
・不具合修正
・クライアント受入テスト（UAT）対応
7. リリース準備・リリース
・デプロイ計画・手順確認
・STORE申請対応（モバイルアプリの場合）
・データ移行・環境設定
・ロールバック準備
・本番リリース
・成果物納品
・サービス仕様ドキュメント、引き継ぎマニュアル等資料作成
8. 保守・運用・改善
・障害／問い合わせ対応
・監視・ログ分析
・改善提案・小規模改修

プロダクトによっては、これらのフェーズが一部省略されたり、自社や外部開発パートナーやクライアント内部開発チームで分業されたりします。関係各社での意思疎通やなぜその仕様となったのかの背景理解を深めるために、コミュニケーションや合意形成、専門用語・ユビキタス言語の整理を行い、ワンチーム性を高めることが重要です。
本記事では、特に不確実性が高くエンジニアが主体となる「3. 機能整理」以降の実装フェーズを中心に見積もり手法を解説します。

ハマりやすい3つの問題

詳細な見積もり方法の前に、私が感じた開発工数見積もりで失敗しやすい3つの問題を挙げます。
これらを踏まえた上で見積もり方法を理解すると、より実践的に活用しやすくなります。

私自身もこれらの問題に何度も直面し、失敗を重ねたり恥ずかしい思いをした経験があります。
その中で、このやり方のままでは通用しないと気づき、今は重要かつ間違えやすいポイントだからこそ特に意識して時間をかけるようにしています。

1. タスクを網羅して洗い出すことの難しさ

プロダクト像がまだ曖昧な段階で必要なタスクを漏れなく洗い出すのは非常に難しい

ベースとなるプロダクトで必要な機能や画面をビジネスゴールやユースケース、Webやアプリの一般的な機能を元に洗い出します。ここに対象プロダクト特有の要件や業界・業務特性、ドメイン知識や業務フロー、商習慣なども考慮してタスク出しをします。
しかし、この段階ではどんなプロダクトなのかがあいまいで抽象度が高い状態です。必要なタスクを漏れなく洗い出すことはとても難しいことが多いです。

対策：

Webやアプリの一般的な機能や画面パターンをリスト化しておき、サービスサイクルに最低限必要な構成を満たしているかを確認する
世の中の類似サービスや競合サービス、過去の実績案件を参考にして、必要な機能や画面を洗い出す
クライアントやステークホルダーからのヒアリングを通じて、業界特性やドメイン知識、業務フローを把握し、必要な機能を洗い出す
クライアントから必須となる要件や既存で使用しているツールの仕様を提供してもらい、見積もりに反映する
一人で作らずに複数人でタスク出しを行い、漏れを防止する

2. 工数稼働の割り当てが合っているのか分からない

複雑性・不確実性を正しく評価できないと工数は簡単に過小にも過大にもなる

洗い出したタスクに対して、各タスクの工数や稼働率を割り当てていきます。割り振り量は担当者の経験やスキルセット、プロダクトの技術選定、開発体制、サービスの複雑性や不確実性などによって大きく変動します。機能内容についても複雑性や不確実性を正しく評価できず、工数が過小または過大になることが多いです。
また商談での競合コンペの場合、価格を抑えようとするあまり、工数を過小に見積もってしまったり、逆に安全策として過大に見積もってしまうこともあります。

対策：

Webやアプリの一般的な画面・機能ごとの工数目安を用意し、そこから常識的に考えて大きく外れていないか確認する
各タスクの工数を見積もる際に、過去の類似案件の実績データやベンチマークを参考にする
機能や画面、開発対象に対して、複雑性（開発の難易度） と 不確実性（未知の要素やリスク） を評価し、工数の割り増しや調整を行う
一人で見積もりを行わずに、複数人でレビューを行ったり、スクラムポーカーなどの手法を使って客観的な評価を得る
商談時には、前提条件やリスク要因を明示して、実現可能な条件ややらないことを明確にする
セカンドオピニオンとして、他の開発パートナーや社内の別チームに見積もり内容をレビューしてもらう
AIツールを使う場合は、1つの見積もり結果に頼らず、複数のAIモデルや手法を組み合わせて検証する

3. 実装以外のタスクの抜け漏れが発生する

実装以外のタスクこそ、見積もりから最も漏れやすく、影響が大きい。

実装タスク以外にも、要件定義、システム設計、開発進捗管理、テスト計画・実施、バグ修正、リリース準備、サービス仕様ドキュメント作成、非機能要件対応、保守運用など多くのタスクが存在します。これらは具体の画面やデザイン、機能に直接紐づかないため、見積もりが漏れやすいです。
しかし、要件定義やシステム設計が不十分だと、開発途中で仕様変更や手戻りが発生し、結果的に工数増加やスケジュール遅延につながりかねません。
またテストケース作成には仕様の理解や準備期間が必要であり、テスト実施やバグ修正も工数がかかります。
リリース準備も、デプロイ手順確認やストア申請対応、データ移行、環境設定など多くのタスクが発生します。これらを見積もりに含めないと実際の工数が大幅に増加し、予算オーバーやスケジュール遅延の原因となります。

対策：

事前に最低限必要な開発プロセスやフェーズをリスト化し、各フェーズで発生する主要なタスクを洗い出して抜け漏れを防止する
特に要件定義フェーズは重要であり、十分な工数や人員を割り当て、後工程での手戻りを防止する
テストの内、脆弱性診断は外部委託での第三者検証が必要な場合が多いため、予算やスケジュールに組み込んだり、前提条件として明示する
保守運用で営業時間内対応と24時間365日対応では大きくコストが異なるため、サポート範囲を明確にし見積もりに反映する
知見のない分野の場合は、複数のAIツールでざっとたたき台や発散案を作成し、そこから人間がレビューして精査する
一人で見積もりを行わずに、複数人でレビューを行ったり、社内外の専門家にレビューをしてもらう

開発の工数・予算・体制をどう見積もるか

開発工数見積もりの全体ステップ

商談段階の見積もりで、基本的に WBS（作業分解構造）をベースに、必要タスクと複雑性を評価したものを掛けて、各職能の工数に変換する方法を使用します。進行管理などの横断的なプロジェクト進行管理や各種テストも、忘れずに含めるようにしましょう。

開発工数見積もりの全体ステップは以下の通りです。

【要件定義フェーズ】

画面・機能を洗い出してテーブル化
機能一覧、画面一覧出し
不可逆な前提条件の確認

【実装フェーズ】

実装タスクの洗い出し
開発複雑性と不確実性の評価

【テスト・品質・納品準備フェーズ】

テスト計画
成果物ドキュメント・データ作成

【工数・体制・スケジュール算出】

開発工数の算出
職能ロールのアサイン体制設計
スケジュールの算出
期間ごとの職能別の稼働とタスク出し
タスクとスケジュールの整合性確認
金額の算出
商談の場合は見積もり書やスケジュール、職能別稼働率表を作成

要件定義フェーズ

画面・機能の洗い出し

制作対象の全体量を把握するために以下を行います。

提案依頼内容（RFP）やヒアリング内容から、画面・機能を洗い出す
要望要求が曖昧な場合は、目指したいビジネスゴールや価値提供、ユースケースを元に、目標を実現するために必要な機能を洗い出す
必要となる画面や表示要素は、UI情報設計やラフデザイン、簡易な画面遷移図を作成して洗い出す（UIデザイナーと連携）

【失敗・改善ポイント】
自分が詳しくない分野の場合、必要な機能や画面を見落としたり実態と合わなかったりします。すると予算やスケジュール不足で失敗してしまいます。かといって見積もり不足を恐れて迷っていたり工数の予備バッファを盛りすぎると、要件定義フェーズに時間がかかりすぎたり、予算やスケジュール超過になります。
これには確実な対処法はありませんが、セカンドオピニオンとして多角的な確認で防止するのが良いです。一人で作らずにPMや他のメンバーと共同作業したり、複数のAIツールやAIモデルによる相互チェックを行ったりします。

機能一覧、画面一覧出し

必要な機能や画面を洗い出し一覧化する
この段階でフィジビリティスタディで実現不可能な要素があれば除外・調整する
画面遷移図やグローバルナビの仮設計をここで行い、画面間の関係性で必要な画面を洗い出す

【失敗・改善ポイント】
機能の項目をExcelで並べるだけでは、読む負担も高く理解や活用もしづらいです。そのためユーザーからの使われ方を想定した「機能ユースケース」を軸に整理するのが良いです。
これでWhy-What-Howをつなげて目的や詳細を自分で辿れるようにすると、要件定義や設計の理解が深まり、自走しやすい要件定義になります。

参考：機能ユースケース

不可逆な前提条件の確認

機能によっては後から追加や変更ができない「不可逆な前提条件」がある場合があります。
例えば以下のようなものです。

認証・認可方式（SSO、OAuth、独自認証など）
権限設計（ユーザー、管理者、役割ベースなど）
データ構造・データモデルの前提（1対1か1対多か、破棄した値の復元、アーカイブ機能など）
既存システムの利用や制約（リニューアル案件の場合など）
外部システム連携方式
運用体制・サポート範囲の前提

【失敗・改善ポイント】
後から変更できない前提（認証方式、データ構造など）を軽く決めてしまうと、後工程での手戻りコストが非常に大きくなるため、見積もり段階から慎重に扱います。
特にデータをいかに保持したり扱うかは、そのプロダクトのやりたいことや将来的な拡張性に大きく影響するので最適な方法を選べるようにします。

実装フェーズ

実装タスクの洗い出し

画面・機能ごとに必要な実装タスクを洗い出す
依頼内容や業界、ドメイン知識、開発チームのスキルセットを考慮して必要なタスクを網羅的に洗い出す
一般的なWebではホーム、一覧、詳細、フォームの他、ログイン認証や検索・フィルタ絞り込み、レスポンシブデザイン、外部システム連携、管理ツールなどが必要になることが多い
アプリ開発の場合は、プッシュ通知、オフライン対応、ストア申請対応なども考慮する
ここで必要なタスクを実現するための仕様が明らかになったら、要件定義書や基本設計書に反映しクライアントやデザイン、開発側と合意を取っていく
- このサイクル作業は時間がかかり、コミュニケーション量も多くなるので、工数をきちんと取っておく

【失敗・改善ポイント】
ここで細かな仕様を決めていきます。また着手順や依存関係も考慮します。どんなに気をつけても抜け漏れが発生するので、例えばフロントエンド実装で決めるべき項目のテンプレートを用意しておき、抜け漏れを防止するのが良いです。

参考：UIスペックのテンプレート

開発複雑性と不確実性の評価

複雑性

画面や機能などの抽象単位ごとに、開発の複雑性を分類する
既存システムを利用しながらのリニューアルの場合は、システム利用制限や外部システム連携などで多数の制限があります。これらを考慮し、作るのがどれくらい大変かで見積もります

複雑性（実装の重さ）の算出：
「作るのがどれくらい大変か」画面・機能・機能群などの抽象単位
※前提：本工数はエンジニアが100%稼働した場合の概算値です。工数は目安で実際の開発状況に応じて調整してください。
※これはあくまで私の経験上の一例です。チームや開発環境によって調整してください。

複雑性	工数目安（人日）	ニュアンス
極小	0.1〜0.4	軽微修正・AIで即終わる作業
低	0.5〜1.5	単純・迷わず実装できる
中	2〜4	標準的。設計しながら進める
やや高	5〜8	難所の入口。分解前提
高	9〜15	明確な難所。数週間規模
極高	16〜	重い機能。設計・検証・合意を含み1人月以上かかるもの

【失敗・改善ポイント】
自分が普段アサインされている稼働の感覚に引きずられがちです。例えば50％稼働と100％稼働では1つに集中できるのか、または作業の切り替えコストが発生するかもあり単純に2倍にはなりません。定例会議やコミュニケーションの量も増え、想定外の対応も発生しがちです。
また担当メンバーがシングルタスク志向なのかマルチタスクの適性があるかでも、集中力の発揮度合いも変わってきます。

不確実性

使ったことのない技術、Webやアプリ以外のもの（特殊なハード機器等）の連携など、着手前に分かっていないことがどれくらいあるかを分類する。

不確実性（未知・リスク）の算出：
「着手前に分かっていないことがどれくらいあるか」
※見積への反映倍率は目安です。実際の開発状況に応じて調整してください。

不確実性	状態の例	見積への反映倍率
低	仕様・実装内容が明確、実績あり	1.0倍（そのまま）
中	仕様調整あり、関係者との確認・調整が必要	基準工数の1.2倍
高	既存仕様が不明、外部連携が多い	基準工数の1.5倍
極高	物理ハード連動や未来の機能、重要な制約が多い	基準工数の2倍〜以上

【失敗・改善ポイント】
自分が知らないものは不確実性が高いと判断しがちです。しかしなんでも不確実性を高にすると、予算や工数が膨らんでしまいます。できれば知見のあるメンバーに相談したり、過去の類似案件を参考にしたりして、適正な評価を行うのが良いです。

テスト・品質・納品準備フェーズ

テスト計画

テストは実施の1ヶ月以上前から仕様把握やテストケース作成の期間を確保する
テスト実施で発見されたバグ修正と再テスト確認の期間も確保する
外部の脆弱性診断を実施する場合はスケジュールに組み込み、診断結果の修正対応期間も確保する
テスト環境や必要なログインアカウントやダミーデータの用意を事前に行う

【失敗・改善ポイント】
テストケース作成は仕様理解や準備が必要なため、早めに着手できる方が良いです。またテスト実施で発見されたバグ修正の工数を忘れがちなので、スケジュールに組み込むようにします。

法務・コンプライアンス対応

個人情報保護、利用規約、プライバシーポリシー、データセキュリティ、アクセシビリティ対応、コンプライアンス要件など法務などの対応が必要な場合がある
顧客企業の規模や組織体制によっては、法務回答が1ヶ月以上の長期間がかかる場合があるので注意する

成果物ドキュメント・データ作成

開発プロセスで必要なドキュメント作成工数を見積もりに含める
- サービス仕様書、要件定義書、システム設計書、API設計書、引き継ぎ運用マニュアル等
- デザインファイルや画面遷移図、デザインガイドライン等
- テスト結果報告書、脆弱性診断レポート、テストケース一覧等
データを納品する場合は、あらかじめクライアント側でGithubやFigmaを開設してもらい、そこに招待してもらう形だと引き継ぎ時の有料プラン違いやデータ移行コストを抑えられる
画像やフォント、動画などの素材データは、著作権やライセンスに注意し、必要に応じてオーナーの移行や使用許諾を調整する

【失敗・改善ポイント】
ドキュメント作成ツールは簡単に更新でき、検索や履歴管理ができるかの観点でツールを選ぶのが良いです。WordやExcelのみでのサービス仕様作成は負担が大きい場合があるので注意します。

工数・体制・スケジュール算出

開発工数の算出

画面・機能ごとのボリュームと複雑性、不確実性を元に、フロントエンド・バックエンド・管理ツールなどの実装工数を算出する
工数が見積もりづらい場合は、スクラムポーカーや類似案件の実績を参考にする
感覚的に稼働率50%と100%での違いを考慮せず自分の普段の開発速度で見積もりがち。かけもちと専任でのパフォーマンスの違いに注意する
不確実性の高い要素がある場合は、工数予備バッファを割り増ししたり、前提条件として明記した上で外部切り出ししたりして、工数不足リスクを低減する

【失敗・改善ポイント】
単にタスクとアサインの加算のみで集計するのではなく、一旦ガントチャートのように矢羽根を引いて表を作成します。こうするとこれが終わらないと着手できないなどの依存関係タスクや、並行可能タスクが見えやすくなります。

コミュニケーション・合意形成の工数

実装だけでなく、クライアントやステークホルダーとのコミュニケーション、仕様確認、合意形成のための工数も見積もりに含める。これらが不足すると、後で仕様変更や手戻りが発生し、結果的に工数増加やスケジュール遅延につながる
主なコミュニケーション・合意形成タスクには以下が含まれる
- クライアントや開発チームとの定期会議（会議が多すぎると実装工数が減ることもある）
- デザイン・開発間の仕様確認・UI調整
- クライアントとの仕様確認・合意取り
- 既存システムの理解や後から仕様が判明したり変更した場合の対応
- 外部システムベンダーとの調整・連携
- 各ツールやAIの使用承認やアクセス権限取得、社内申請の待ち時間

【失敗・改善ポイント】
クライアントによっては会議の場でUIを見ながらの意思決定を好む場合があります。その場合は会議体の回数や時間を多めに見積もる必要があります。非同期でのコミュニケーションが取れるようチケット管理ツールやドキュメント共有ツールを活用し、会議体を減らす工夫も効果的です。
使用できるドキュメントツールやAIツール利用可否によって、大きく工数差が出る場合もある。そのため契約前に確認や調整を行うのが良いです。

職能ロールのアサイン体制設計

開発に必要な職能（PM、テクニカルディレクター、フロントエンドエンジニア、バックエンドエンジニア、QAエンジニア等）を洗い出す
UI修正やサービス仕様調整のために、UIデザイナーやUXデザイナーも一部関与する場合がある
職能の割り当てとともに稼働率（0〜100%）を見積もる
スケジュールを短縮するには、人員を増やして並行稼働を増やしたり、稼働率を上げたりする。ただし要件定義やデザインや依存関係のある機能実装などは、人数を増やしても効率化しにくい場合があるため注意する
作業量が多い工程は人員追加で対応できるが、判断や合意が集中する工程は人を増やしても進みにくい点に注意する
QCD（品質・コスト・納期）で何を優先するかをクライアントと合意し、それに基づいて体制設計を行う
工数算出と体制設計は相互に影響し合うため、体制を考慮しながら工数を調整する

【失敗・改善ポイント】
要件定義や設計でテクニカルディレクター一人のみだと、セカンドオピニオンでのカバーができなく見落としが発生しやすいです。PMやUXデザイナー、他のエンジニアと協力して進められる体制を作るのが良いです。

スケジュールの算出

スケジュールは単純な作業量の合計ではなく、各工程の依存関係や判断・合意が必要となるタイミングによって決まる。

タスクの羅列を見てそこから時間軸を掴んでスケジュールに落とし込むのは、不慣れだとイメージができなかったり感覚が追いつかない場合がある。その場合は 「時間軸」ではなく「変化軸」で捉える。 スケジュールを“時間の線”として考えるのではなく、代わりに「状態がどう変わっていくか」「変化の段階を積み重ねる」という発想でイメージすると良い。

スケジュール設計の3つの観点

スケジュール設計では、「タスク量」「前後の依存関係（完了しないと次に進めない関係）」「判断・合意の有無（人の意思決定が必要か）」 の3つを常に意識すること。

基本的な算出手順：

リリース日や締め切りが決まっている場合は、まずはそこから逆算して各フェーズの目安期間を設定する
- リリース日からの逆算だけでなく、依存関係と判断ポイントを意識したスケジュール設計も行うようにする
フェーズごとの工数と期間を元に、必要な人数を算出する
日数が足りない場合は、人員を増やしたり稼働率を上げたりして調整するが、依存関係や判断が必要な工程では効果が限定的な場合がある
余裕を持ったスケジュールにしないと締め切りに間に合わなくなる。しかし無駄に期間を伸ばすと人月でのコストが増える。そのため過去の実績を元にしたり、別の開発パートナーの見積もり内容を参考にしたりして、適切なスケジュールができるよう調査・修正する

重要な制約と特性：

依存関係が直列になる工程（要件確定、設計確定など）は並列化できず、スケジュール全体の最短期間を決める要因となる
判断や合意が必要な工程は、作業量以上に時間を要することが多く、人員を増やしても短縮しにくい
実装や一部のテスト工程は短縮できる可能性がある一方で、レビュー、品質確認、運用準備などは最低限の期間を確保する必要がある

スケジュール短縮時の考え方：

スケジュール短縮が求められた場合は、どの工程を短縮でき、どの工程は削れないかを切り分けて検討する

【失敗・改善ポイント】
スケジュールが足りずに後から追加だと、予算や信頼に大きな悪影響を与えます。タスク分割の粒度や網羅性が甘いとスケジュール作成がとてもしづらくなります。他のメンバーのスケジュール見積もり意見やAIツールを活用するなどしてタスクの網羅性を高めていきます。

期間ごとの職能別の稼働とタスク出し

開発タスクと職能とスケジュールを元に、各月ごとの職能別の稼働率を算出する
各月や各週ごとに職能の稼働率表を作成する
各月や各週ごとに作業タスク概要の表を作成するか、要件が明確ならガントチャートを作成する

タスクとスケジュールの整合性確認

数値と単価の掛け算だけだと実作業の順序や複数名連携、並行作業が見極めきれない。そのため各月ごとのタスクと進行順序を表で書いて検討し、現実的に可能かを一度矢羽の表を作成して確認する
実装のアサインを満たすだけだと、進捗管理や仕様不明時の確認エスカレーション、仕様の合意取り、テスト準備・実施を担当する人員が不足しがち。そのためPMやテクニカルディレクターの稼働割り当ても確認する

金額の算出

各職能の人月単価を設定し、工数に基づいて金額を算出する
複雑性や不確実性が高い場合は、妥当な工数予備バッファを追加する
保守運用費用も見積もりに含める場合は、月額費用や年間費用を算出する。また24時間365日対応の保守運用は高額になる場合が多いので、前提条件をつけてサポートの範囲を明確にする
プロジェクトチームのバリューを最大化するために、適切な人月単価を設定する。安すぎると質が下がり、結果的にコスト増になることがある
オフショア開発を活用する場合でも、パッと見の単価の低さだけで判断せずにコミュニケーションやブリッジする人員のコストも考慮する。同じような作業が大量にある場合にオフショアは有効となるため、プロダクトの特性を考慮して判断する

【失敗・改善ポイント】
単純に人月単価×工数で計算するのではなく、プロジェクト全体や進捗管理コストも考慮に入れます。例えば、PMやテクニカルディレクターの工数が不足していると、進捗管理や品質管理が不十分になり、結果的に追加工数やコストが発生することがあります。

商談の場合は見積もり書やスケジュール、職能別稼働率表を作成

上記の内容を元に、見積もり書、スケジュール表、職能の稼働率体制表を作成する
見積もりの根拠となる機能や画面一覧、複雑性評価、工数算出方法も添付する
前提条件ページを設け、見積もり対象外のテストや機能、保守運用の範囲を明確にする

AI活用による時間短縮やコスト削減

各フェーズでAIツールを活用することで、時間短縮やコスト削減が可能です。

圧縮しやすい工程と圧縮しにくい工程

AIで効率化しやすい工程と、効率化しにくい・すべきでない工程があります。
AIは実装や情報整理などの定型作業を効率化できる一方で、意思決定の判断余地のある箇所や後戻りできない重要責務の工程は、引き続き人が時間をかけて行う必要があります。

圧縮しやすい工程	圧縮しにくい / すべきでない工程	理由
情報整理・要約	意思決定・判断	AIは情報提供はできるが最終判断は人間
ドキュメントの下書き作成	ステークホルダーとの合意形成	人間関係・信頼構築はAIでは代替不可
繰り返し作業（テストコード生成等）	責任を伴う決定（アーキテクチャ選定等）	失敗時の影響が大きい判断は人間が必須
定型的な実装（CRUD等）	プロジェクト固有の設計思想・重要責務の箇所	文脈理解やドメイン知識が必要

以下は各フェーズでのAI活用例です。

要件定義フェーズでのAI活用

要件定義では、Webやアプリなどメディアやデバイスで一般的に必要な構成は決まっている。そのため必須の構造は事前に用意した上で、プロダクト特有の要件や業界、ドメイン知識、業務フローに関する要件をAIツールで補完する。
特に概算見積もりの段階では、設計者側にまだ要件やドメイン知識がないことも多いため、それを補いタスクをテーブル出しするのに役立つ。
ただし複雑性や不確実性はAI頼りでは判断できないため、設計者側でしっかり評価する必要がある。
要件定義ドキュメントは追加や更新、抜け漏れ、整合性確認が頻発するため、AIツールでの自動生成や更新で負荷低減が期待される。

システム設計フェーズでのAI活用

システム設計では、API設計やデータベース設計、技術選定、アーキテクチャ設計などが含まれる。AIツールを活用して、一般的な設計パターンやベストプラクティスを参考にしながら、設計ドキュメントの作成やレビューを行うことができる。
また、設計の妥当性や一貫性をチェックするためにAIツールを利用することも有効である。

開発実装フェーズでのAI活用

開発フェーズでは、コード生成やコードレビュー、バグ検出などにAIツールを活用することができる。
ただし開発見積もり段階で安易に、実装をAIで短縮できると考えるのは危険である。
AIは定型的な実装（CRUD操作や仕様が明確な箇所）では効率化できるが、複雑なビジネスロジックや設計判断が必要な箇所では効率化が限定的である。
そのため見積もりでは人が実装する前提で堅実に見積もり、実際の開発時にAI活用で効率化できた場合は、品質向上やテスト強化に時間を使うのが望ましい。
実装の段階でユニットテストなどでのAI活用は、後工程のテスト工数削減にも有効なので、開発担当者側で実装段階でユニットテストなどを書けるようにするのが望ましい。

テストフェーズでのAI活用

テストフェーズでは、テストケースの自動生成やテスト実行の自動化、バグ検出などにAIツールを活用することができる。特にE2Eテストや回帰テストなど繰り返し実行するテストにおいて、AIツールを利用することで効率的にテストを実施できる。
ただし、テスト計画やテストケースの設計は人が機能仕様を理解したり、サービスサイクルやテストすべきUX体験の判断を行う必要があるため、人とAIの協働が重要である。

予算やコスト削減への影響

AIツールを活用することで、開発工数の削減や効率化が期待できるため、予算やコスト削減につながる。特に要件定義フェーズやテストフェーズでのAI活用は、工数削減効果が期待される。
ただし、クライアントによってはAIツールの利用に対して懸念や制約がある場合もあるため、事前に確認し、適切な範囲でAI活用を検討することが重要である。
できれば商談や契約の段階でAIツールの利用範囲や目的を明確にし、クライアントと合意を取っておくことが望ましい。

まとめ

個人的に開発や物作りはとても楽しいものと思っています。そして関わるエンジニアメンバーにはその「楽しい開発体験」を味わってほしいです。それが私がテクニカルディレクターとしてがんばる理由の一つです。

「楽しい開発体験」のためにはしっかりと練られた要件定義や品質管理、適切なスケジュール管理が重要です。作りやすい環境でクライアントやチームメンバーとワンチームになってプロダクトやユーザーのためにパフォーマンス高く開発していきます。
それが納品後もより良いサービスサイクルのアウトカムとなったり、一緒に働いた時のプロセス自体が、顧客組織環境への良い影響を与えられると良いです。

開発工数見積もりは、タスクの洗い出し、工数割り当て、実装タスク以外の工数見積もりなど、多くの要素を考慮する必要があります。ここで自社のケイパビリティとクライアントのニーズをすり合わせながら、適切な見積もりを行うことが重要です。

AIによって効率化できる工程は増えましたが、見積もりにおける「複雑・不確実性を洞察する力」は、今後も人の果たすべき役割が大きい部分だと感じています。
また一人の力だけではどうしても限界があります。ここは他のメンバーに協力してもらったり、過去の案件実績のナレッジを有効活用していけると良いです。

これらの取り組みの先に、より良いプロダクト開発とサービス提供が実現でき、成果としてもプロセスとしても「楽しい開発体験のプロジェクト」があるのだと思います。

そのために本記事が、商談時の概算見積もりやプロジェクトでの設計でお役に立てればうれしいです。
今後も開発工数見積もりの手法やプロセスを改善し、より良い開発体験を提供できるよう努めていきたいと思います。