システム開発の見積もりが高いと感じたら｜発注前に確認したい内訳と前提

システム開発の見積もりが高いと感じたら、その違和感は率直に開発会社へ伝えてよいと思います。金額は、作る範囲や品質の条件、まだ分からないことへの備えでも変わります。まず、どの作業にどれだけ時間がかかるのか、提示された金額でどこまで対応するのかを確認してください。

私自身、AIを使ってWebサービスを開発する中で、従来の見積もり方には限界を感じています。作りたいものを伝えると、ひとまず動くものが短時間でできる。以前はそこまで到達するだけでも、多くの作業時間（工数）が必要でした。

ただ、早く形になることと、ユーザーが求める品質まで仕上がることは別です。私の感覚では、後者にかかる労力は従来と同じか、むしろ増えている部分もあります。

「AIを使えば全部安くなる」とも、「品質にお金がかかるから従来どおりでよい」とも言い切れません。見積もりでは、AIで短くなった作業と、依然として時間をかけるべき作業を分けて説明してもらいたいところです。変化の多い開発なら、予算上限を決めて短く区切り、成果と費用を確かめながら進める方が合うと考えています。

システム開発の見積もりは、実装以外の内訳も確認する

見積書にある「開発費」には、コードを書く作業以外も含まれます。会社によって工程名やまとめ方が違うため、次の区分を目安に、含まれる仕事を確認してください。

「開発一式」とだけ書かれている場合は、内訳を出してもらうと話を進めやすくなります。特にデータ移行、公開後の修正、保守運用は、見積もりに含まれると思っていたのに別料金だった、という認識違いを避けたい項目です。

人月は作業量の単位。人数や納期とは分けて考える

一人が一か月働く分の作業量を「1人月」と呼びます。工数に担当者の単価を掛け、その合計をもとに見積もる方法があります。

たとえば、人月単価100万円で3人月なら、その作業費は300万円です。これは計算方法を説明するための仮の数字で、市場相場ではありません。単価には会社の管理費や利益を含む場合があり、担当者の給与そのものとも違います。

また、3人月の仕事へ三人を入れれば必ず一か月で終わる、という意味ではありません。先に仕様を決めないと着手できない作業や、関係者の確認を待つ時間もあるからです。

妥当性を確認するには、「何人月ですか」に続けて、「その工数はどの作業を積み上げたものですか」「過去の案件とは何が同じで、何が違いますか」と聞きます。

費用相場は、同じ条件の案件と比べる

「Webシステムならいくら」という相場だけでは、手元の見積もりを判断しきれません。画面数が同じでも、社内の数人で使うものと、多数の顧客が使い、決済や既存システムとの連携があるものでは、確認すべき範囲が違います。

相場記事を見る場合も、対象業務、利用人数、連携先、データ移行の有無、運用条件が自社に近いかを確認してください。条件が分からない金額をそのまま値下げ交渉の基準にすると、必要な仕事まで削ってしまいます。

AIで「80％まで一瞬」と感じても、残り工数が20％とは限らない

私がWebサービスを開発していて感じる変化は、最初に形を作るまでの速さです。作りたいものをAIへ伝えると、80％くらいの仕上がりに見えるものが、すぐに出てきます。

以前は、使う技術を選び、手元で開発する環境を整え、実際に動かす本番環境を用意するところから、多くの時間を使っていました。今は、その候補出しや構築作業もAIに手伝わせ、動く状態まで一気に進められる場面があります。もちろん、提案された構成が用途に合うか、安全に公開できるかの確認は別に必要です。

感覚を図にすると、次のようになります。

ここでいう80％は、完成までの仕事が八割終わったという意味ではありません。画面があり、基本的な操作ができると、かなりできたように見える。それでも、実際の業務で使うには確認と修正が残っています。

この段階までが速いからといって、開発費全体を八割削れるとは考えていません。むしろ、その先を見積もる難しさが増したと感じています。

仕上げには、AIが書いたコードを理解し直す時間もかかる

自分で一つずつコードを書いていた頃は、どの処理をどう作ったか、細部まで把握しながら進めていました。AIがまとめて作ると、その理解が追いつかないまま、目の前に動くものができあがります。

直したいところを見つけても、内部の動きを把握せず、想定だけで変更を重ねるのは難しい。コードを読み、業務の仕様と照らし合わせ、変更の影響を確かめる必要があります。私が、仕上げの労力は従来と同じかそれ以上だと感じる理由の一つです。

業務固有の事情を十分に渡さないと、AIは一般的にはもっともらしい処理を作ることがあります。見た目が自然でも、自社のルールを満たしているとは限りません。

たとえば受注システムなら、注文を登録できるか、取り消したときに在庫が戻るかを確かめます。同時に注文されたときの重複や、権限のない人による顧客情報の閲覧も防ぐ必要があります。これは確認項目の例で、私の案件で起きた不具合の報告ではありません。

GitHubの公式説明でも、AIが生成したコードは、要件への適合、エラー、セキュリティを含めてレビューとテストを行うよう案内されています。

私の実感では、AIで形にできる範囲が広がるほど、その先で作り手の知識が問われます。経験がないままでは、何を確認すべきかも、AIの修正が正しいかも判断しにくい。技術者がいない会社には、AIで作れたという理由だけで重要な業務へ投入せず、技術を評価できる人を確保してほしいと思います。

不確実な開発を一括で見積もると、費用に余裕を見込む

発注時点では、既存システムの仕様が分からない、実データを調べられていない、部門ごとの要望がまとまっていない、ということがあります。それでも総額と納期を先に決めるなら、開発会社は想定外への備えを見込むことになります。

この余裕分が「バッファ」です。見積書で独立した項目になるとは限らず、各工程の工数に含まれる場合もあります。私の感覚では、大規模で長期間の開発ほど、先を読みきれない難しさがあります。

バッファがあるだけで、不当な請求とは判断できません。ただ、何を想定した余裕なのかは聞いてよいはずです。

「データ移行が不安なので多めに見ています」という話なら、先にデータを調べ、難しさが分かってから移行を見積もり直す方法があります。要件整理や技術的な検証を先に行い、その結果を見て次の工程へ進む方法も考えられます。

IPAの資料「システム開発の健全化に向けて」でも、仕様が明確になった段階で見積もりを見直す、多段階契約の考え方が示されています。

私も、開発をこまめに区切り、不確実なことを減らしてから次の費用を決める方が納得しやすいと考えています。分割すれば必ず安くなるわけではなく、調整や契約の手間は増えます。それでも、まだ分からない仕事まで長期間まとめて確定するより、判断材料を増やせます。

相見積もりでは、金額より先に「完成」の条件をそろえる

同じ依頼書を渡しても、各社が同じ仕事を見積もっているとは限りません。一社はデータ移行と公開後の対応まで含み、別の会社は新しいシステムを作るところまで、ということも考えられます。

比較するときは、少なくとも次の条件をそろえます。

• 作る機能と、今回は作らない機能
• 性能やセキュリティを含む、品質確認の範囲
• データ移行、本番公開、操作説明の有無
• 納品後の不具合対応と、追加の機能開発の区別
• 仕様が変わった場合の追加費用・納期の決め方
• 保守運用、サーバー、外部サービスにかかる継続費

コードや仕様資料の引き渡し、管理用アカウントを誰が持つかも確認しておくと、運用や将来の引き継ぎで困りにくくなります。

以前、私は発注者として、開発会社がこちらの意図を十分に理解せず、期待と違う成果物が出てきた経験があります。私たちにも技術者がいたため、問題を具体的に指摘できました。金額だけでなく、何を満たせば受け入れるのかを発注側でも確認する必要があると感じた経験です。

その話は、システム開発を外注に丸投げしないためにで詳しく書いています。今回の見積もり確認でも、価格と受け入れ条件を切り離さずに考えたいところです。

私なら、変化の多い開発は準委任で週ごとに確かめたい

AIによって実装の進み方が変わった今、私は、長期間の開発を最初の見積もりで一括して請け負うことに難しさを感じています。特に、作りながら仕様や優先順位を修正するWebサービス開発では、現時点で実装工数を正確に読みきるのは難しいと思います。

一方で、顧客が何に困っているかを聞き、どの業務を変えるかを整理する要件定義の労力は、私の感覚では今までと大きく変わっていません。AIが仕様書の下書きを作れても、その内容が業務に合うかを顧客と話して確かめる仕事は残ります。

私が今依頼を受けるなら、顧客の課題から一緒に考え、修正と確認を繰り返す進め方を選びたいです。準委任契約で顧客と一つのチームを作り、週ごとに成果物と優先順位を確認しながら進む形が合うのではないか、と考えています。

人月と請負・準委任は、別の話

人月は工数の単位で、請負・準委任は契約の種類です。準委任でも、稼働時間や人月をもとに費用を決めることがあります。

請負は仕事の完成を約束する契約です。準委任は業務の遂行を委ねる契約で、専門家として求められる注意をもって業務を行う義務があります。準委任だから品質を問われない、成果を確認しなくてよい、ということではありません。報酬や責任の具体的な条件は、契約内容を確認する必要があります。

IPAのアジャイル開発外部委託モデル契約でも、開発中に機能や優先順位が変わる進め方には準委任がなじみやすいと説明されています。同時に、仕様が明確な部分を請負にする選択肢も示されています。

私が限界を感じるのは、人月という単位そのものより、AI以前の実装工数を前提に、変化の多い開発を長期一括で固定する見積もり方です。範囲が固まった仕事なら、請負という選択肢も残ります。

週次の確認は「いくら使って、何が確かめられたか」まで

準委任を提案された発注側には、費用だけ増えて完成しないのでは、という不安もあると思います。そのため、開始前に対象期間、予算の上限、優先する業務、成果を判断する人を決めておきます。

週ごとの確認で話したいのは、次の内容です。

1. 実際に動かして、どの業務ができるようになったか
2. どんな条件で試し、何がまだ未確認か
3. 使った費用と残り予算、新しく分かった難しさ
4. 次の週に何を優先し、何を後回しにするか

これは、私が今後の案件で取りたい進め方です。週次で確認すること自体が品質や予算を保証するわけではありません。区切りごとに、継続するか、範囲を小さくするか、いったん止めるかを相談し、予算を超える場合は着手前に合意します。

発注側も、業務を理解した人が成果物を確認し、優先順位を決める時間を取る必要があります。契約の名前を変えるだけでは、開発は進めやすくなりません。

費用を下げるなら、確認を省く前に作る範囲を見直す

予算が合わないときは、最初に必要な業務を絞り、後から追加できる機能を分けます。既存のサービスで足りる部分まで一から作ろうとしていないか、業務フロー自体を変えれば開発を減らせないかも検討できます。

AIで短くできる実装工数は、見積もりへどう反映しているか聞いてよいと思います。ただ、値下げのためにテストや業務との照合をまとめて削るのは避けたいです。早く作れたものを、そのまま使えるものと取り違えてしまいます。

技術的な説明を自社だけで評価できなければ、発注前の見積もりや設計を、外部の技術者に確認してもらう方法もあります。技術顧問に依頼できることにも、その関わり方を書きました。

高いと感じた部分を、そのまま開発会社へ聞いてみる

見積書を受け取って疑問があれば、専門用語に置き換えずに聞いてよいと思います。

「この実装費が高いと感じたのですが、どの作業に時間がかかりますか」

「AIを使う前提ですか。使うなら、減る作業と残る作業を教えてください」

「まだ分からないことは何ですか。そこを先に調べてから、次の見積もりを出せますか」

説明を聞いた結果、必要な費用だと納得できるかもしれません。範囲や進め方を変える方がよいと分かることもあります。

AIで実装が速くなったからこそ、見積もりには、何を早く作れて、どの品質確認に時間を使うのかが表れていてほしい。私は、短い期間で成果物と費用を確かめながら、その判断を顧客と一緒に更新していく開発を選びたいと考えています。