Introduction
株式会社medibaでエンジニア組織マネージャーと複数プロダクトの開発責任者を担当している船田です。
新規プロジェクトや新機能の検討時、ビジネス担当やクライアントからこう聞かれた経験はありませんか？
「ねぇ、これ、ざっくり1,000万円くらいでできる？」
「これってざっくりどのくらいでできるかな？」
この「ざっくり」という問いかけの裏にある、ビジネス側の真の意図は、意思決定のための目安を求めているのです。
- 投資対効果に見合うか。
- 他の並行案件と比較したプロジェクトの優先度決め。
- 大まかなリリース時期を知り、事業計画に組み込むための準備。
つまり、ビジネス担当やクライアントは「ざっくり」と聞きながらも、「根拠のある目安」が欲しいのです。
本記事のゴールは、この「ざっくり1,000万？」を卒業することです。
勘に頼らずに、自信とロジックを持って回答できる「超概算見積もり」の具体的な手法をここから解説していきます。
ビジュアル化！超概算に必要なのは「詳細さ」より「全体像」
ビジュアル化に入る前に、要件を言語化すること
まず、超概算見積もりの第一歩として、要件の可視化を行います。
依頼が口頭の会議であったり、簡潔なテキストメッセージであったりと、要件の伝達方法は様々です。まずはビジネス担当やクライアントの意向を、開発チームが共通認識を持てる言葉へと整理し、言語化する必要があります。
今回は、ビジネス担当のAさんから、以下のようなテキスト形式で要件をいただいたという設定で考えを進めるため、要件の言語化は出来ています。
○ 必須機能
■ 会員判別する会員判定APIが欲しい
■ 会員判定後にアクセス可能となる会員限定抽選ページ
■ 抽選後にアクセス可能となる抽選結果ページ
■ 会員は1日1回抽選できる抽選機能
■ エントリー／抽選履歴の保存
■ 管理画面でエントリー数／抽選結果の集計が確認できる
○ あったらいいな機能
■ 抽選結果ページにおすすめコンテンツ表示枠設置(管理者側で制御)
■ 抽選設定を期間/内容を変更可能(管理者側で制御)
要件をビジュアル化
この言語化された要件テキストを基に、いよいよシステム全体像のビジュアル化に取りかかります。今回はCacoo(カクー)を使います。
まずは、抽出した主要な要素(エントリー、抽選ページ、抽選結果)に基づき、ユーザー画面の遷移イメージとして視覚化してみましょう。
いかがでしょうか。たった数行のテキスト情報だった要件が、この図によってシステム全体の流れとして格段に理解しやすくなったはずです。これがビジュアル化です。
この調子で、まだ可視化できていないバックエンドの仕組みや管理機能などの他の要素も、具体的なイメージとして落とし込んでいきましょう。
すべての要素を可視化し、必須機能とあったらいいな機能のスコープを線引きした結果、システム全体図を描くことができました。
これで、超概算見積もりに必要な「ビジュアル化」は完了です。
工数ポイントから超概算金額への換算
ビジュアル化によって、システム全体像と洗い出された個々の機能要素に対し、工数ポイントを割り当てていきます。
※本記事で用いている工数ポイントの考え方は、ファンクションポイント法（FP法）の理念に基づき、アレンジしたものです。
工数ポイントの目安となる定義を決め
そこで、まず最小単位の機能開発、例えば「1つのシンプルなAPIの作成」というタスクが、具体的にどのような作業で構成されているかを分解し、暫定のミニマムな工数を定義します。
弊社の場合は、以下の作業が1セットとなっています。
- 詳細設計
- 実装
- 単体テスト
- レビュー(設計・コード)
それぞれの工程にどのくらいの人日がかかるか、暫定のミニマムなケースを仮定し、「難易度：小(S)」の基準とします。
| 作業項目 | 暫定工数(人日) |
|---|---|
| 詳細設計 | 1 |
| 実装 | 2 |
| 単体テスト | 1 |
| レビュー | 1 |
| 合計 | 5 |
この最小工数(5人日)を基準として、さらに超概算のシンプルさを重視し、「小・中・大」の3段階で難易度を定義し、具体的な人日を紐づけます。これは、機能の規模や複雑性が上がるにつれて、実装、詳細設計やレビューの工数も増加するという考えに基づいています。
| 難易度カテゴリー | 暫定人日 | 該当する機能の特性 |
|---|---|---|
| 小 (S) | 5人日 | 単純なCRUD操作(登録・参照・更新・削除)、シンプルな画面表示など。技術的なリスクは低いもの |
| 中 (M) | 10人日 | 複数のデータ連携やDBへの書き込みを伴う。簡単なビジネスロジックや、シンプルな外部API連携が必要なもの |
| 大 (L) | 15人日 | 複雑なビジネスロジック、複数のシステム連携、または高い集計・計算処理能力を要件されるもの |
このように、難易度を割り当てることで、「ざっくりとした勘」ではなく、「この機能はあの機能より複雑」という明確な根拠を持った超概算が可能になります。
ビジュアルに工数ポイントを付ける
前項で定義した「小(5人日)・中(10人日)・大(15人日)」の難易度に基づき、完成したシステム全体図の各要素に工数ポイントを割り当てていきます。
換算作業
ビジュアル化されたシステム全体図の各要素に割り当てた工数ポイントに基づき、すべての工数を集計します。
この集計作業では、機能の重要度や特性に応じて色分けしておくと、後の優先順位付けや、ビジネス側への説明が容易になります。
- ピンク(必須機能)：65人日
- ムラサキ(機能外の必須)：60人日
- ミズイロ(あったらいいな機能)：30人日
上記人日工数と、仮定した作業単価(1人月/20人日あたり100万円)を用いて、ビジネス側への提示に必要な金額を試算します。
超概算見積もりパターン①：必須機能のみの試算
⇒ 必須機能のみの超概算金額：625万円
超概算見積もりパターン②：必須機能+あったらいいな機能の試算
⇒ 必須機能+あったらいいな機能の超概算金額：775万円
まとめ
超概算見積もり成功のための2つの鍵の再確認
本記事で解説したもののは、「ざっくり」という曖昧な土台を、「ビジュアル」と「ロジック」で固めるというプロセスでした。この手法を成功させるための鍵となる2つを再確認します。
①ビジュアル化による共通認識： システム全体図を描くことで、スコープを明確にして要素を分解し、依存関係の可視化を行いました。
②工数ポイントによる論理的根拠： 勘や経験則ではなく、S/M/Lといった相対的な難易度と複雑性に基づいて工数を数値化し、金額の根拠を提示できるようにしました。
この超概算見積もり術は、単なるコスト算出ツールではなく、透明性の高いロジックによって、ビジネス側との信頼関係とパートナーシップを築き、予算とスコープに関する建設的な議論が可能になります。
おわり
現在medibaでは、一緒に働けるメンバーを募集しています。
ご興味ある方は、お気軽にお問合せください。
採用サイト：https://www.mediba.jp/recruit
KDDIグループの株式会社medibaのエンジニアが運営するテックブログです。 メディア事業やソリューション開発で培った技術的知見や、AI活用、開発プロセスに関する情報を発信します。