システム開発の見積もりは何をチェックすべき？適切な依頼先を選定するには？

システム開発の見積もりはなぜブレが大きいのか？

ただし、開発体制や得意分野の違いというだけでは説明がつかないほど、システム開発会社によって工数が大きく異なる場合も少なくありません。システム開発の見積もりに大きなブレが生じてしまう要因はまさにここにあります。

これは、最終的に具体的なイメージのできる「モノ」を作る製造業などとは異なり、人間の作業プロセスを効率化する「システム」を作るシステム開発ならではの難しさがあるからです。以下から簡単に解説していきます。

システム開発のステージで見積もり金額は異なる

すでに解説したように、ウォーターフォールモデルによるシステム開発では、上流工程の作業結果を成果物としてアウトプットし、その成果をインプットとして次の工程の作業に取り掛かります。

つまり、ピントのぼやけていた「最終的な形」が、開発工程の進捗に応じて明確になってくるイメージであり、開発初期段階では「正確な見積もりを算出するための充分な材料・情報がない」状態なのだといえます。

出典：IPA「ソフトウェア開発の標準プロセス」

依頼側がシステム開発会社に見積もりを依頼する目的は、多くの場合「依頼先のベンダーを選定するため」であり、ベンダーは材料・情報が乏しいまま見積もりを作成せざるを得ません。

プロジェクトが開始してもいない時期の見積もり金額がベンダーによって大きくぶれてしまうのは、ある意味当然のことだともいえるのです。

見積もり計算方法まで知る必要はない

システム開発会社が見積もり金額を算出する際は、

などの計算方法を使いますが、依頼側が意識する必要はありません。なぜなら、どの計算方法を使うのにしても「材料・情報」が少なければ、見積もりの精度を上げることはできないからです。

受注するシステム開発会社側としても、精度の低い見積もりでプロジェクトが炎上してしまうことを避けるため、その時々で得られる材料・情報を使って、もっとも精度を高められる計算方法を採用しています。

見積もり金額を算出するプロセスに、依頼側がかかわる必要はないのです。

開発ステージの進捗に応じて要求が増える

システム開発に必要な材料・情報を整理することで、見積もりの精度を高めることは可能ですが、一般的には、プロジェクトの開発ステージ進捗に応じて「システムに求める要求」が増えてしまう場合がほとんど。材料・情報が整理されることで「見えていなかった要件が見えてくる」からです。

出典：IPA「エンタプライズ系事業/見積もり手法」

当初想定していた仕様に変更・追加が生じれば、見積もり金額に変更が生じるのは当たり前。当初のシステム開発見積もりを決定事項としてしまうと、その後のプロジェクトの進行に支障が生じてしまう可能性が高いといえるでしょう。

システム開発の見積もりでは「要件定義」が重要

システム開発の見積もりに課題が多いのは事実ですが、依頼側の関心事は「提出された見積もりから、いかに自社に最適なシステム開発会社を選ぶか？」です。

しかし、ここまでの解説でもおわかりのように、単価・工数のブレが大きな見積もりでは、内容を比較すること自体が困難です。つまり、適切なシステム開発会社を選定するためには、比較の前提となる依頼条件を統一し、ブレに少ない見積もりを取ることが肝心。

そのためには、すぐに要件定義のステージに取りかかれる程度の「材料・情報」を揃えてから見積もりを依頼することが重要。上の図をご覧いただいてもわかるように、「システム化の方向性」「システム化計画」ができていれば、見積もりの誤差を最小限にとどめられます。これこそが「要求定義」です。

発注者なら知るべき4つの見積の算出方法

システム開発会社が費用を見積もる際は以下のいづれかの算出方法を使います。それぞれメリット・デメリットがあるため、発注者としてしっかりと押さえましょう。

類推見積（トップダウン）

過去に行った開発プロジェクトの事例をもとに見積もりを算出するのが類推見積です。

係数モデル（パラメトリック見積）

過去の開発事例から係数を設けて工数や費用を算出する見積方法です。例えば、製品を10個作った事例があれば1個あたりの制作期間と費用が分かります。これを踏まえて、同じ製品を100個作る場合の期間と費用を算出するのが係数モデルです。

ボトムアップ（工数積上げ）

求められるシステムや開発作業を分解。分解された要素ごとに必要な費用・工数を見積もり最後に全体の見積もりを出す方法です。

プライスツーウィン法

発注者が要望している開発予算に合わせて見積もりを出すのがプライスツーウィン法です。

システム開発の見積もり具体例

まずは、システム開発の見積もりがどのようなものなのか？具体的な例を紹介しておきましょう。見積書に決まったフォーマットはありません。依頼先によっても見積もり内容は異なりますが、項目・工数・概算金額を記載しているケースがあります。

システム開発の手法にはいくつかがありますが、見積もり例も含め、本記事では日本でもっとも採用されることの多い「ウォーターフォールモデル」を想定しながら解説を進めていきます。

ウォーターフォールモデルとは

ウォーターフォールモデルとは、文字通り「水が上流から下流に流れ落ちるように」開発工程・プロセスを進めていくシステム開発手法のこと。

具体的には、「要件定義」「基本設計」「詳細設計」「プログラミング」「テスト」という開発工程を経て、納品・受入テストへといたる開発手法です。

要件定義・設計を「上流工程」、プログラミング・テストを「下流工程」と呼び、上流工程でアウトプットされた成果を、次の下流工程のインプットとして活用していくことが特徴。そのため、ウォーターフォールモデルでは原則として「工程の後戻り」は想定されていません。

見積もりの内訳・費用項目

それでは、見積もり例で紹介した費用項目は、それぞれどのようなことにかかる費用なのでしょうか？簡単に表で紹介しておきましょう。

これ以外にも、クライアント側のニーズに応じて、既存システムからのデータ移管・マイグレーション費用、システム稼動後のシステム運用・保守費用が見積もりに含まれる場合もあります。

システム開発の見積もりチェックポイント

ここまでで、システム開発の見積もり例とともに、各項目がどのような作業にかかる費用なのか？何にかかる費用なのかを解説してきました。

それでは、提出された見積もりが妥当なものなのか、相見積もりの場合に比較すべきなのはどこなのか、チェックしておくべきポイントを紹介していきます。

見積もりの各項目

ウォーターフォールモデルの項目でも解説したように、システム開発は完成までにさまざまな工程を経る必要があります。これらの作業項目がしっかりと見積もりに網羅されているのか、最初のチェックポイントです。

なぜなら、システム開発の各工程でどのくらいの作業が必要なのか、概算で見積もらなければ大まかな費用を算出することさえできないからです。

特に重要なのは「要件定義」で、IPA（情報処理推進機構）でも開発費用全体の20%以上は要件定義にかけるべきだと提唱しており、極端に費用が少なくないか？チェックが必要となります。

見積もり項目ごとの単価・工数

システム開発会社によってフォーマットは異なります。工数の記入のある場合は想定人月単価をベースに、記載のない場合はスケジュールと投入リソースを確認しましょう。納得できる説明を求めることが重要です。また、説明がきちんとできることが良いベンダーを見抜く助けにもなります。

工数が記載されていた場合のチェック

見積もりの各項目ごとの単価・工数をチェックしておくことも重要なポイントです。この場合の単価は「人件費」を、工数は開発にかかる「作業量」を意味します。

たとえば、上述したシステム開発の見積もり例では、要件定義の工数が「80」となっているため、人件費となる単価は「4,000,000 ÷ 80 = 50,000円」となり、1日8時間で人件費50,000円のエンジニア1名が80日間、4名なら20日間かけて要件定義工程を担当するという意味。これを「人日単価」といいます。

また、エンジニアの単価を1か月で表した「人月単価」という算出方法もあり、この場合は「1日8時間で20日間稼動した場合の金額」になります。エンジニアの平均人月単価はおおよそ100万円といわれているため、上述した見積もり例の人月単価は「妥当」だといえるでしょう。

システム開発会社の質問・提案

要件定義や企画について指摘・質問を行ってくれる会社かどうかみると良いでしょう。「指摘・質問を行う」＝「クライアントのニーズに応えるシステムの開発を具体的に考えている証」と言えるためです。

また、システム開発の見積もりに、独自の提案があるかどうかもチェックしておきたいポイントです。システム開発プロジェクトはベンダーとの協力関係が不可欠であり、コミュニケーションを円滑にするためにも積極性が重要です。

見積もり依頼に対して独自の提案をしてくれるシステム開発会社なら、プロジェクト開始後にも良好な関係性を築けると期待できます。

見積もりのチェックポイントからわかること

システム開発の見積もり項目からは、ベンダーの概算見積もりに対する姿勢が、提案からはベンダーの積極性がわかります。

一方、項目ごとの単価・工数からは、エンジニアの人件費・作業量がわかりますが、それだけではないシステム開発に係る要素も推測可能。以下から簡単に解説していきましょう。

工数から開発体制・得意分野を推測できる

システム開発費用の多くは人件費であり、見積もり金額は「各項目の人日単価（人件費）× 工数」で決まるといっても間違いではありません。

複数のベンダーから相見積もりを取った場合、金額が大きく異なる要因になるのも人件費と工数ですが、工数からはベンダーの開発体制・得意分野を推測可能です。

一般的に、スキルの高いエンジニアが揃えられる、過去の資産（プログラム）を流用できるなど、開発体制が整っているシステム開発会社ほど、同じ作業項目でも工数が少なめになる傾向にあります。開発するシステムの分野を得意とするベンダーなら、その傾向はより強まるでしょう。

見積もりから適切なシステム開発を選ぶ方法

「見積もりはもらった。どの開発会社に依頼したほうが良いのか」これが発注者の悩みどころではないでようか。ここでは適切なシステム開発会社を選ぶ方法を解説します。具体的には以下の2つのポイントを見ると失敗しないでしょう。それぞれ解説します。

十分なサポート体制はあるか

開発後のサポート体制はもちろんですが、開発時のサポート体制があるかチェックしましょう。「要件定義からサポートしてくれるかどうか」はとても重要です。

記事の前半でもお伝えしましたが、開発の良し悪しは要件定義にかかっていると言っても過言ではありません。開発会社が要件定義の工程でサポートに入ることで開発のトラブル防止になりますし、期待どおりのシステムを手に入れることができます。

発注したいシステムと類似した実績があれば、開発における知見があります。適切なサポートを行ってくれる可能性が高いでしょう。「要件定義からサポートしてくれるか」「類似の開発実績はあるか」をとくにチェックしてみてください。

開発に必要なスキルとリソースはあるか

当たり前ではありますが、開発会社に要望しているシステムを開発しているスキルとリソースがなければ発注しても開発が頓挫してしまいます。発注者としてしっかりと見極めないといけません。

見積もり書に記載されている作業項目やスケジュールに具体性や妥当性があるか確認すると良いでしょう。具体的には「なぜこのスケジュールなのか？」といった質問を重ねて、開発会社が論理的に説明できるかどうかが一つの目安と言えます。

システム開発でもっとも重要な要求定義

システム開発プロジェクトの多くは、システム化の方向性・計画を「ヒアリング」というステージで済ませてしまう傾向がありますが、これではその後の開発工程に大きなブレが生じてしまう可能性が高くなります。

なぜなら、上流工程のアウトプットを次の工程のインプットとするウォーターフォールモデルでは、もっとも上流の工程となる「要求定義」が、システム開発プロジェクトでもっとも重要な工程となるからです。

出典：IPA「ソフトウェア開発の標準プロセス」

IPAでも、要件定義を含めたシステム化の方向性・計画を「超上流プロセス」と位置づけており、点線で囲まれた「企画」に該当する工程こそが「要求定義」です。

要求定義の責任は依頼側

それでは、要求定義はだれの責任において定義付けられるものなのでしょうか？システム開発プロジェクトの目的は、依頼側の「ビジネスの成長」に寄与する「事業・業務プロセスの効率化」です。

当然、それを決定できるのは依頼側だけであり、要求定義は依頼側の責任において策定されるべきものです。

出典：IPA「ソフトウェア開発の標準プロセス」

それでは、要求定義ではどのようなことを策定すべきなのでしょうか？原則としては、第三者であるシステム開発会社がプロジェクトの意図を理解でき、目的・ゴールのブレのない協力関係を築ける情報を与えることです。以下から簡単に解説していきましょう。

システム開発の目的・ゴール

まず明確にしておきたいポイントは、ビジネスを成長させるため開発するシステムで

がシステム開発の目的・ゴールです。<システム開発に限らず、プロジェクトが迷走してしまう要因の多くは目的・ゴールが明確ではないこと。プロジェクトの方向性を定めるためにも、シンプルかつわかりやすい目的・ゴールを設定する必要があります。

現状の課題・理想の姿（業務設計・業務要件）

システム開発の目的・ゴールを達成するためには、システム化によって事業・業務をどのように効率化・合理化するのかを定義する必要があります。

そのためには、解決すべき現状の課題（As-Is）を明らかにし、あるべき理想の姿（To-Be）とのギャップをどう埋めていくかを明確にしなければなりません。

これが業務設計であり、As-IsとTo-Beのギャップをシステムで埋めるために求める要件が業務要件です。完成したものの「使われないシステムになってしまった」といった失敗を避けるためにも、現場の声も反映しながら現実に即した解説策をまとめることがポイントです。

システムへの要求（機能要件・非機能要件）

業務設計・業務要件をもとに、開発するシステムに求める具体的な要求を「機能要件」「非機能要件」にブレイクダウンしていきます。

• 機能要件

  システムに実装したい具体的な機能のこと

• 非機能要件

  システムに求める機能要件以外の要素のこと

具体的には、検索機能・登録機能などが「機能要件」であるのに対し、システムのパフォーマンス、セキュリティ要件、アベイラビリティ（可用性）、保守性などが非機能要件です。

依頼範囲・範囲外

外部のシステム開発会社に依頼したい範囲、依頼しない範囲を明確にしておくこともポイントのひとつです。

たとえば、システム運用・保守を自社でまかなうのであれば、システム・ソフトウェアの開発のみ、自社システム部で要件定義までカバーするのであれば、設計・実装・テストのみが依頼範囲になります。

ハードウェア・ソフトウェアなどを自社調達するのであれば、機器導入は依頼しないことを明確にしておくといいでしょう。

予算・納期・自社体制・役割

システム開発の予算・納期、システム開発に関連する自社の体制や役割を明確にしておくことも重要です。

などが明確になっていれば、見積もりを依頼するシステム開発会社の側でも、自身の役割を明確にできるからです。

RFP（提案依頼書）にまとめる

ここまでに策定した要求定義は、RFP（提案依頼書）として取りまとめ、システム開発会社から提案を募る形にすることがベストです。

見積もりの前提条件となる「要求定義」をRFPで提供することにより、ブレの少ない見積もりが期待できるとともに、システム開発会社の提案力も見極めることが可能だからです。

RFP（提案依頼書）とは？RFIとの意味の違いや作成目的・サンプルを解説

要求定義をシステム開発会社にサポートしてもらう方法も

システム開発の超上流工程に位置付けられる要求定義は、システム開発会社からの見積もり精度を高めるだけではなく、プロジェクトの成否を左右する重要な工程です。

しかし、自社の現状を見直して業務設計するのはともかく、それをもとに業務要件を策定する、機能要件・非機能要件を設定することは簡単ではないかもしれません。

ITリソースが不足している企業であれば、業務目線で業務プロセスを言語化することはできても、開発目線で要求定義に落とし込むことは難しいからです。

そんな悩みを抱える企業であれば、要求定義プロセスのみをシステム開発会社にサポートしてもらうという方法があります。実際のシステム開発に着手する以前からコストが発生することにはなりますが、プロジェクトが迷走して収拾がつかなくなるリスクを最小化できます。

まとめ

見積もりは取ったものの、システム開発会社をどう選べばいいかわからないという方に向け、本記事では、システム開発の見積もりは何をチェックすべきなのか？見積もりの具体例や見方、チェックポイントを解説するとともに、なぜ見積もり金額が大きくブレるのか、適切なシステム開発会社を選定するためになにをすべきかを紹介してきました。

人間の作業プロセスを効率化することを目的とするシステム開発では、見積もりを依頼するベンダーによって金額が大きく異なる理由が理解できたのではないでしょうか？本来、システム開発と相見積もりは馴染まない面があることも事実ですが、前提条件となる要求定義を徹底することで、各社の見積もりを比較しやすくなり、プロジェクトの迷走も防げます。

どうしても自社だけでは要求定義をまとめられないのであれば、開発者にわかりやすく書面化するサポートのみ、システム開発会社に依頼することがおすすめ。「比較ビズ」なら、必要事項を入力する2分程度の手間で、要求定義策定をサポートしてくれる、優良なシステム開発会社をスピーディーに探せます。どのベンダーに相談すべきなのか？迷うようなことがあれば、是非利用してみてください。

自社にぴったりのシステム開発会社を探すには？

システム開発会社選びでお困りなら「比較ビズ」が解決します！

• 費用相場がわからず不安...
• 発注先選びを失敗したくない…
• 忙しくて探す時間がない...

今年で運営17年目の「比較ビズ」は、仕事を”依頼したい人”と”請けたい人”を繋ぐマッチングサービスです。これまでWEBシステム、スマホアプリ、業務システムの開発など多くのご相談を頂き1万社以上もの企業様の発注をサポートしてまいりました。

まずは下記のボタンより、お気軽にご相談ください。

代表社員 金谷 道

監修者

合同会社なまけもの

組み込みエンジニアからキャリアをスタートし、Techベンチャー数社と大手SIerで技術責任者と事業開発を経験。技術とデザインの両面から設計が出来ることが強み。現在は各社の経営層の相談相手・新規事業企画をメイン業務としている。大手金融機関のポータルサイト、AIを使用したタレントマネジメントツール、ウェビナーメディアの立ち上げなどの実績がある。

この監修者の記事一覧