システム開発の見積の作り方と AI の使いどころ

「この開発、いくらでできますか」と商談中に聞かれて、根拠を出せないまま持ち帰った経験はないでしょうか。システム開発の見積は 工数と単価の掛け算 が土台で、そこに工程ごとの積み上げと前提条件が乗っています。中身がわかれば、金額の理由をその場で説明しやすくなります。

この記事は、システム開発の見積について一般的に使われている考え方と手法を整理したものです。KDDIアイレットの見積方針や算定基準を示すものではありません。実際の見積の方法や金額は、ご依頼の内容や契約形態によって個別に決まります。

---

見積は 4 つの工程を積み上げて作る

請負を前提にすると、システム開発は要件定義・設計・開発・テストの 4 工程に分かれます。家づくりに置き換えると、それぞれの役割がつかみやすくなります。

金額そのものは「何人が何ヶ月動くか」に単価を掛けて出すのが基本です。人月は 1 人が 1 ヶ月働く量を指す単位で、3 人が 2 ヶ月動けば 6 人月です。この 6 人月に単価を掛けたものが開発費の本体にあたり、機器の購入費・運用保守費・交通費などは内訳として別に積まれます。

工程のなかで削りたくなるのはテストですが、検査を薄くすると、リリース後の不具合の調査や対応、業務への影響といった形で、最初に浮かせた金額を上回る負担が発注側と受注側の双方に出やすくなります。 要件定義も同じで、どんな家にするかが決まらないまま施工に入れば、建て直しの手間がかかります。

見積手法は「いつ使うか」と「何が必要か」で選ぶ

見積の作り方は 1 つではありません。よく知られた手法を、使う時期と必要な材料で分けると、どれを選べばよいかが見えやすくなります。

すべてを使い分ける必要はなく、まず押さえたいのは類推法とボトムアップ法の 2 つです。似た過去の開発と比べて当たりをつけ、機能を 1 つずつ洗い出して積み上げ、2 つの数字が近いかどうかで自分の見立てを確かめます。ボトムアップ法では、作業を数日以内で終わる程度の単位まで細かく割ってから積むと、抜けに気づきやすくなります。

手法を知っておくと、他社の見積を読む手がかりにもなります。どの考え方で作られた数字かがわかれば、金額の妥当性を検討しやすくなります。

金額がブレる原因は前提のズレ

同じ手法を使っても、条件が変われば金額は動きます。ブレを生むのは主に次の 3 つです。

• 機能が増える: 「キッチンをつけてください」と言われて 3 口コンロと広い作業台を想像しても、相手は 1 口で十分だと思っていることがあります。同じ単語でも要件が一致していません
• 納期が短い: 人を増やして並行で走らせる分、調整と管理のコストが積み上がります
• 前例がない: 誰もやったことのない実装は、どれだけ手間がかかるか読みにくいため、不確実性に備えた予備を見込むか、検証の期間を先に切り出して確かめる必要があります

これらを吸収するのがバッファと前提条件です。バッファは想定外に備える予備で、前提条件は「この条件ならこの金額」という約束にあたります。まだ決まっていないことは仮で置いたうえで、何を前提にした金額かを書き残します。

前提条件は金額の内訳とは別の欄にまとめて書かれることが多いため、金額だけを見て合意すると、条件の食い違いが後から表に出てきます。 「言った・言わない」になりやすいのもこの部分なので、金額の説明と同じ場で前提条件も読み合わせておくと、認識のズレが残りません。

請負と準委任で見積の形が変わる

ここまでは請負を前提にしてきましたが、準委任では見積の形そのものが変わります。

請負は完成を約束する契約なので、合意した範囲の中で想定より工数がかかった分は受注側が負担します。範囲そのものが変わる場合は、変更契約で見直すのが一般的です。作業範囲と前提条件を詰める必要があるのはこのためです。

準委任は業務の遂行を引き受ける契約で、見積は「どんなスキルの人が何人、何ヶ月、単価いくらか」という形になります。完成責任がないぶん超過時のリスクは小さいものの、何をどこまでやるかの合意は準委任でも必要です。実務では、要件が固まりきらない要件定義フェーズを準委任、要件が確定してからの開発を請負として、工程で分けることがよくあります。決まっていないうちは時間で、決まったら範囲で見積る、と覚えておくと選びやすくなります。

なお、準委任にも成果物に対して報酬を払う成果完成型があるなど、責任範囲は契約内容によって変わります。個別の契約で迷ったら法務に確認してください。

AI に見積を任せきりにしない

見積づくりに AI を使うこと自体は有効です。機能や作業の洗い出し、抜け漏れのチェック、前提条件の文案づくりは AI の得意な領域で、ボトムアップ法や標準タスク法のたたき台がすぐ手に入ります。

進め方の一例を挙げます。

1. 自分で「何人で何ヶ月くらいか」の概算を出す
2. AI に機能と作業を洗い出させ、たたき台を作る
3. 1 と 2 の差がどこから来ているのかを確かめる
4. 工数の妥当性を、実装を担うエンジニアに確認して確定させる

先に自分の感覚値を出しておくと、AI の出力と食い違ったときに理由を追えます。先に AI へ聞いてしまうと、その数字が基準になってしまい、違和感を持ちにくくなります。

AI が出した金額をそのまま使えないのは、自社の単価もメンバーのスキルも過去の実績も AI 側が持っていないからです。もっともらしい数字ほど、根拠を確かめないまま通してしまいがちです。

筆者が手元で試した範囲では、AI が出した工数と過去の実績をもとにした概算の差は思ったほど大きくありませんでした。ただし、AI の見立てを過去の実績からの概算と比べるときは、参照している実績が AI 活用前のものだと、いまの開発の実態とずれている可能性がある点にも注意が必要です。見積の前提を見直すには、どの作業がどれだけ短縮されたかに加えて、AI の出力の確認・修正に時間がかかった作業や、古い技術・独自仕様のように AI で短縮しにくかった条件の記録も役に立ちます。

見積の前に聞くこと・出す前に見直すこと

見積の精度は、材料が揃っているかどうかに大きく左右されます。見積に取りかかる前と、提出する前で、押さえる項目が違います。

見積の前に顧客に聞いておく 5 項目

「見積を出してほしい」と言われた段階で、ここまで聞けていれば見積の精度を上げられます。

• 目的: 何を解決したいのか
• 利用者数: 誰が何人使うのか
• 既存システム: 連携や移行はあるのか、リプレイスか新規か
• 納期: いつまでか、その理由は何か
• 予算感: どのくらいを想定しているのか（予算に合わせて範囲や段階の分け方を提案するため）

提出前に見直す 3 項目

見積を出す直前に、次の 3 点を見直します。

• 説明できるか: 概算と積み上げの差や、金額の大きい項目の理由を自分の言葉で説明できるか
• 前提条件と対象外: 何を含み、何を含まないかを書き出しているか
• 読み合わせの場: 金額と前提条件を顧客と一緒に確認する機会を設けているか

前提条件と対象外を書いていない見積は、すべて込みだと受け取られかねません。 金額が明らかにおかしいと感じたときは、高すぎる場合も低すぎる場合も、早めに共有して見直したほうが、後の関係悪化を防げます。

要件定義の段階で聞くべきことを標準化しておくと、見積の材料も自然に揃います。KDDIアイレットでは、要件定義を型にして手戻りを減らすAIDD 要件定義を提供しており、要件定義の標準化で手戻りを削減した導入事例も公開しています。

まとめ

• 見積は工数と単価の掛け算が土台で、工程ごとの積み上げでできている
• 金額がブレる原因は前提のズレにある。ヒアリングと前提条件の明記で防ぐ
• AI はたたき台として使い、数字は自分の感覚値とエンジニアの確認で裏を取る

完璧な見積を作れるようになる必要はなく、まずは「なぜこの金額なのか」を説明できる状態と、自分のなかの相場感を育てることから始められます。なお、本記事で紹介した内容は一般的な考え方であり、KDDIアイレットが実際にお出しする見積の算定方法を示すものではありません。見積や要件定義の進め方でお困りのことがあれば、お気軽に KDDIアイレットへご相談ください。