【失敗しない】システム開発の見積もり依頼時に注意するべき項目

【失敗しない】システム開発の見積もり依頼時に注意するべき項目

IT環境の急速な進化によって企業のデジタルトランスフォーメーションの必要性が高まりシステム開発の迅速な対応が求められています。
企業担当者はシステム開発に関して専門家ではないことが多いことに加え、近年はシステムのクラウド化など、新しい技術も浸透してきているため、従来の知識と経験を持っている担当者でも、最新のシステム開発の見積り依頼時に注意すべき項目についてわからない点も多いのではないでしょうか。
そこで今回は、システム開発に失敗しないために、システム開発の見積り依頼時に注意すべき項目をわかりやすく解説します。

目次

見積もり依頼前に知っておいてほしいこと

今回のテーマであるシステム開発の見積り依頼時に注意するべき項目を考える前提として「システム開発の特殊性」と「相見積もり時の注意点」は、必ず知っておいてほしいことになります。
なぜならば、これらの大前提がぶれると、システム開発の見積り自体がうまくいかなくなる可能性がとても高くなるからです。

システム開発の特殊性

システム開発の特殊性

システムとは、人間の仕事を補佐するものです。
人間は仕事を、臨機応変に、柔軟に、習慣的に、無意識的に行っていますが、現在の一般的なシステムは、事前に定義されたことしか出来ません。
人間とシステムのギャップを埋めるためには、システムに人間の代わりに仕事をおこなうように事前に定義して、要求するための言語化をすることが必要になります。
システムとは、人間の目的達成のためのプロセスを補佐するものであるといえます。

一方で、家やビル、車などの一般的な生産物は、それ自体が目的であると言えます。

人間は目的・目標はイメージしやすいですが、目的・目標を実現するためのプロセスはイメージし辛いです。
家などを建てる建築業や車をなどを作る生産業は、家や車というイメージしやすい物を作りますが、人間の目的達成のためのプロセスを補佐するものを作るシステム開発では、イメージし辛い物を作ります。

この点が、建築業や生産業などと違うシステム開発の特殊性です。

システム開発の特殊性を理解せず建築業や生産業などと同じ感覚で発注すると、開発会社との認識の齟齬が起こりやすく、プロジェクト炎上の元になります。
システム開発には、人間が無意識に行っていることを事前に定義するために徹底的な言語化が必要だあることを十分に理解し、企業が必要とするシステムを発注者と開発会社が共に作り上げていく姿勢がシステムを導入し発注する際には大切です。

相見積もり時の注意点

相見積もり時の注意点

企業がシステムを発注する際には、ほとんどの場合、複数の業者から見積りをとって検討する相見積もりをとるはずです。
この時に注意するべき点は、要求をなるべく明確にした段階で相見積もりをとることです。

要求内容を明確にしないと、明確になっていない部分は想像で見積もりをすることになり、各開発会社からバラバラの金額や提案を受けることになります。
そうなると、妥当な比較ができません。

また、要求が明確になっていないままプロジェクトを進行すると、言語化されていなかった部分が次々に浮き彫りになり、期間も費用も想定していたより多くなる可能性があります。

そんな事態が起きないように、システム開発の正式な見積り依頼時前の段階である相見積もりを出す時点で、現場の声のヒアリングなどをおこない、言語化出来る部分はなるべく言語化し、要求を整理しましょう。
要求を明確にし、要求を実現するためのプログラム言語や開発プロセスなどの技術面を提案してもらうとよいでしょう。

そうすることで、各開発会社から要求を汲んだ見積もりをもらいやすく、妥当な比較をしやすいでしょう。

見積もりの前提条件

見積もりの前提条件

システム開発における見積りの前提条件とは、簡単に言うとシステムに人間の代わりに仕事をおこなうようにエンジニアの頭の中で想定していることであり、その内容を発注する側と受注を受ける側でプロジェクトに対する理解や見解を同じレベルにするために文章として明記することです。

また、システム開発の見積りでは文章にし辛い部分をシステム構成図などを用いて理解しやすいものにすることもよくおこなわれます。

システム開発における見積りの前提条件は以下の10項目があげられます。

見積もり範囲

今回依頼しているシステム開発の対象はどの範囲なのかを明確にします。
単一のベンダーであれば、どの範囲を依頼しているのか、ソフトウェア、ミドルウェア、ハードウェアのどこが対象になるのかなどを前提条件でしまします。
また、複数ベンダーが絡む場合は、どこまでが範囲なのかを示します。

見積もり対象外範囲

前述の見積もり範囲と同時に、見積り対象外範囲を明確することも必要です。
発注する側と受注する側のギャップを抑えるためには、やることと同時にやらないことも明確に伝えなければなりません。
具体例としてユーザー教育やデータ移行をやるかやらないかなどがあげられます。

使用技術

システム開発で使う使用技術は、必ず必要な前提条件です。
たとえば、言語、フレームワーク、クラウド、サーバーなどがあげられます。

たとえば、COBOL、Java、Python、PHP、Rubyといった、今回依頼するシステムの内容などによって開発言語を指定します。
開発言語とともにどのフレームワークを使用するのか、サーバーは、AWSなどのクラウドサービスを使うのか、オンプレミスで物理サーバーをつかうのかなどを指定します。

開発プロセス

開発プロセスとして、システム全体を連動させて「ウォーターフォール」で開発をすすめていくのか、スピードを重視して、「アジャイル」なすすめ方を選択し、開発チームを小さな単位で分けそれぞれのチームがモデル作成とテストを実行し全体のプロジェクトを完成させるのかなどを指定します。

システム開発工程についてはこちらの記事で詳しく開設しています。

プロジェクト期間

プロジェクト期間は発注側にとっても受注側にとっても重要な項目です。
それぞれの事情があるため開発プロジェクト進行中に認識のギャップが生れないように相互に打ち合わせをしておくことが望ましい形です。

プロジェクトのスケジュールが発注者側の都合で遅延した時などで受注者側の作業スケジュールの調整が発生した場合、費用の見積額の変更を迫られる可能性があるため、スケジュール遅延時の取り決めについての認識を一致させておく必要があるでしょう。

プロジェクト期間の前提条件では、プロジェクト開始と終了の期間を明確に指定するだけでなく、UAT(受入テスト)の期間も想定した日程を指定しましょう。

要件

見積りを依頼する時点で開発企業に要件定義も含めて提案を受け付ける場合など、今回依頼するシステムに必要な役割や効果を実現するための機能が明確には決まっていない場合は、想定できる範囲の機能に対し前提を示しておきます。

発注者側の担当者は、システム開発によって実現したい目的やシステムによって改善したい悩みや課題を明確に伝え、機能についても現段階で考えている前提を示します。

開発企業のもつ最新の機能があるケースもあるので、前提として示した機能にこだわらず、それぞれの開発企業の最適なプランを検討することも考えておきましょう。

プロジェクト推進方法

プロジェクトの進捗管理、推進は誰が行うのか、資料はいつまでに提供されるのか、意思決定はどのように行われるのかなどのプロジェクト推進方法についても発注者側から前提条件として示しておきましょう。

見積りの前提条件のほかの項目全体は、このプロジェクト推進方法での発注者と受注者の役割分担の前提ですすんでいきます。
ここで相互に明確化しておくことで、順調な進行や資料の作成遅延などが起こることを未然に防止することができます。

開発環境・ネットワーク環境

サーバーなどのシステム関連機器を構築するのか、購入するのか、借用するのか、誰が用意するのかといった、開発環境やネットワーク環境をどのように活用していくかも前提を示します。

近年の開発環境・ネットワーク環境はオンプレミスだけでなく、レンタルサーバーやクラウドなどさまざまな方法が提案されています。
今回のシステム開発でどのような開発環境・ネットワーク環境を使用するのか明確に伝えます。

また、システム開発では、開発企業側のサーバーなどのシステム関連機器と発注企業側のサーバーなどのシステム関連機器の連携が発生するケースがありますので、どのような作業連携でプロジェクトをすすめるのかを前提条件として決めておきます。

テスト

プロジェクトで開発するシステムには、テストで何を行うことが必要か、テストパターンはどのくらい作成するかなどを前提条件で決めておきます。
テストは、今回のシステム開発が、実際に使用して問題なく動作するかを事前にチェックできるようにおこなわなければならないため、想定される機能や要件を満たし、テストは開発環境では発見することができない、バグや不具合を見つけ出せるように設定します。

納品物

見積りの前提条件では、開発企業が納品する成果物について成果物の粒度も含めて、具体的に伝えます。

見積もり項目

見積もり項目

システム開発における見積り依頼時に注意することのひとつに、費用などの項目があります。
システム開発には、さまざまな費用がかかるため、費用項目の整理は重要です。

システム開発企業から提出された見積書の総額だけを比較して、最も安い企業を安易に選択することはリスクが大きい方法です。
費用項目を整理しておくことで、複数のシステム開発企業に見積りを依頼する場合でも、見積書比較の精度を高めることができます。

システム開発における一般的な見積り項目としては、以下の項目があげられます。

要件定義

システム開発で最初に開発企業がおこなう作業が要件定義です。
発注の際には、発注者がシステムで実現したいことやシステムで解決したい課題や問題点、想定される要件などを提供しますが、それを受けてシステム開発者が発注者のリクエストを明確化しながら、実際のシステム開発に必要な機能や性能に落とし込んでいく作業が必要となります。

その作業を要件定義といい、システム実現のための仕様や方針を具体的に分析し検討するための費用が必要となります。

要件定義についてはこちらの記事で詳しく解説しています。

設計

要件設定が終わると、具体的な作業をすすめるための開発環境を設計します。
システム開発には、ベースとなる基本設計から、詳細設計、プログラミング設計などさまざまな設計にもとづいて作業をすすめます。
その設計自体に費用が発生します。

デザイン

既存のテンプレートを使用することなく、カスタマイズしたUIデザインを採用する場合にはデザイン費用が発生します。

開発

開発費用には、システム開発にかかる費用のメインになる人件費や技術費全般が含まれます。

システム開発は実際にシステムをつくる作業をおこなうシステムエンジニアやプログラマーといった専門的なスキルと経験をもった技術者と、それらの技術者の作業を管理し順調な進捗を目指すためのプロジェクトマネージャーやプロジェクト・マネジメント・オフィスのメンバーなどのプロジェクト管理に関わるメンバーがチームとなってすすめられます。
そのためシステム開発には高い人件費がかかるのが一般的です。

テスト

開発したシステムが実際に不具合やエラーなく稼働するかどうかテストするために費用がかかります。
また、システム開発途中でも、単体テストや結合テストが必要で、テストの種類もセキュリティテスト、負荷テストと多様です。

導入

システム開発が終わって実際にシステムを導入する際には、一般的に導入費用として初期費用が発生します。
(近年は自社の物理的なサーバーを利用したオンプレミスだけでなく、レンタルサーバーやサーバーだけでなくシステム導入に必要な機器すべてをレンタルするプランが登場しています。また、初期費用を抑えることが可能なクラウドでの導入プランも提案されています。)

受入支援

システム開発によってできあがった新システムを実際の業務で使用するためには、既存システムに蓄積されたデータを新システムに移行する作業などの受入支援が必要となり費用が発生します。

導入支援費用

システム導入にあたって、実務で使用する担当者向けのマニュアルを作成したり、操作手順を解説する説明会や研修会を実施する場合導入支援費用が発生する場合があります。
(多くのシステム開発企業が導入後のサポートをセールスポイントとしており、オプション設定や無料でのサービス提供を提案しているケースがみられます。)

購入費

システム開発にはさまざまな機器などを購入する必要があるかもしれません。
そういった費用が発生した場合には購入費として見積りを作成してもらいます。

交通費

お客様先での作業など、システム開発のためにかかるであろう交通費を記載します。

保守

システム開発が完了した後も、不具合が発生する可能性がありますので、保守のためにどのくらいの費用がかかるのかを見積りに加えてもらうことも重要でしょう。
保守には、直接的にシステム自体が不具合やエラーを起こしてしまった場合だけではなく、システムを操作するやり方が分からなかった場合の問い合わせサービスなども含まれます。
(システム開発企業の多くは運用後の保守サービスについてもオプション設定しているケースも多くみられます。)

見積もり手法

見積もり手法

実際に企業でシステム開発の見積もりをおこなうときの手法は大きく分けて次の3つになります。

類推見積もり(トップダウン)

コスト、工数といったデータでシステム開発の見積りをおこなう手法です。
過去に同様のシステム開発をおこなった実績がある場合は、コストや工数が参考になるため正確な見積りが算出できる可能性が高いというメリットがあります。

一方で、過去に同様のシステム開発をおこなった実績がない場合は、企業担当者の知識や経験でコスト、工数を想定することになり正確な見積りが算出できない可能性があるというデメリットがあります。

係数モデル見積もり(パラメトリック見積り)

システムを動かす要件や設計を機械的に点数化して見積りをおこなう手法です。
企業担当者の知識や経験ではなく、機械的に点数化して見積りをおこなうため、人によるぶれが発生しないメリットがあります。
一方で、点数だけでは評価できない項目においては最適な見積りができない可能性があるというデメリットがあります。

ボトムアップ見積もり(工数積上げ)

できあがったシステムを仮定してそこから工数を積み上げていく見積り手法です。
工数を積み上げるため、ある程度の数の工数であれば精度が高い見積もりができるというメリットがあります。
一方で、大規模プロジェクトの場合、できあがったシステムを仮定してそこから工数を積み上げていくには、工数が膨大すぎて現実的に困難であるというデメリットがあります。

見積もりを受け取ったら確認するポイント

見積もりを受け取ったら確認するポイント

最後に、システム開発の見積りを受け取った際に確認するポイントを3点紹介します。

前提条件を確認する

開発業者に提示した前提条件を満たしているかを確認します。

リスクの見積も含まれているか

システム開発で発生する可能性のあるリスクに対しての見積りが含まれているかどうかを確認します。

管理工数も含まれているか

進捗管理や品質管理、変更管理、障害管理といった管理工数が含まれているかを確認します。

まとめ

システム開発の見積り依頼時に注意する点を認識して、必要な項目を準備して見積りをおこなうことで、最適な開発業者を選定することができ、システム開発を迅速にスタートすることが可能となります。
システム開発時においても開発業者とのギャップが発覚することなく順調にシステム開発を完成させることができるでしょう。

今回の記事内容を参考に、安易に見積りを依頼することなく、開発スタート後の進捗や開発業者との連携を想定しながらシステム開発の見積りを依頼することで、失敗することなくプロジェクトを実行できるはずです。

役に立ったらシェアしていただけると嬉しいです
  • URLをコピーしました!
  • URLをコピーしました!
目次