システム開発を受託する際には、当然のことながら費用項目を明確にしてクライアントと協議し、理解を得た上で契約に至ることが大切です。一括請負という形でシステム開発を受託する場合もあり、その際は該当する費用項目も多岐にわたる場合があります。
いずれにしても正確な見積を作ることはシステム会社にとって利益を確保するための要です。正確な見積や作成時のポイントについて解説します。
見積対象となる費用項目やその内容
システム開発における見積では多数の費用項目を含めて、その金額を算出します。一般的な費用項目は次の通りです。
| 費用項目 | 内容 |
|---|---|
| 要件定義費用 | これから開発するシステムの仕様の調整や実現方針を決定する際にかかる費用 |
| 設計費用 | 基本設計、詳細設計、プログラミング設計等の設計業務にかかる費用 |
| UIデザイン費用 | テンプレート等を使用せず独自のUIデザインにこだわる場合に別途見積もる費用 |
| 進行管理費用 | 作業スケジュールを調整したり管理するための費用 |
| 開発費用 | システム開発のためのプログラミングにかかる人件費と技術費 |
| 導入費用 | 導入時に行う初期設定にかかる費用 |
| 導入支援費用 | システムの操作マニュアル作成やエンドユーザー向けのトレーニング実施にかかる費用 |
| 購入費用 | システム開発の際に必要なサーバーやソフトエア等を購入するための費用 |
| 旅費・交通費用 | クライアントとの打ち合わせ等で発生する費用。宿泊などが伴う場合はその費用。 |
| 保守費用 | 導入後に発生した不具合の修正や機能の改善にかかる費用 |
システム開発において正確な見積を作成するポイント
まずは見積作成のポイントからご紹介します。
見積金額の算出根拠となる項目を明確にする
システム開発における見積関連のトラブルとして最も多いのが「想定外の費用がかかった」ということです。この原因はシステム会社とクライアントで見積り金額の算出根拠に対して、曖昧さを残したままプロジェクトが進行することに大きな要因があります。
ベンダーはクライアントに対して「なぜこれくらいの費用がかかるのか？」を分かりやすく説明する責務があり、理解を得る必要があります。ただし要件が一部未確定のまま工数を算出する場合や、後々追加作業の要請や要件の変更による工数の再見積もりが必要になります。
しかしながら、プロジェクト初期フェーズでは吸収できるバッファもあり、対応できる場合は見積の範囲内で調整していたものの、そのバッファがなくなることで、突然追加費用を請求すると言ったことがよく発生します。
システム開発において請け負う業務範囲を明確にする
システム開発における見積では、クライアントから開発や改修を請け負うシステム会社がその範囲やフェーズを明確にしなければ正確な工数算出は不可能です。そのためシステム会社はクライアントから請け負う範囲について正確に説明を受けることが大切で、その内容も記録に残しておくことが望まれます。
一口にシステム開発といっても、操作マニュアルやユーザトレーニング、問い合わせ対応など、システムを利用するために必要となる工数も含まれることが多く、請け負う範囲を明確にした上で責任の所在についてもハッキリとさせておき、未然にトラブルを防ぐことが大切です。
IT関連の訴訟問題の中には見積において工数や業務範囲を明確にしないままプロジェクトを進めて、後々訴訟問題に発展するという事例が少なくありません。
システム開発工数を明確にし妥当性を持たせる
システム開発プロジェクト全体の工数は小さなタスクの集合体です。見積に妥当性を持たせるためには1つ1つの工数を明確にしておくことが大切です。工数算出にはWBSを作成し、自社独自に保持している実績をベースに算出するという方法がよく用いられます。そのため、クライアントに正しく金額根拠を伝えるために、工数を算出に関係するタスクの規模や難易度、稼働時間など、価格構成要素を元に積み上げることで、金額を算出していきます。
備品や物品のコスト、旅費交通費の計上も忘れない
システム開発の工数算出時に忘れがちなのが、プロジェクト運用に欠かせない備品や物品の調達にかかるコストや交通費（宿泊が伴う場合は旅費も含む）です。長期的なプロジェクトになると次第に人員が増えていき、細かいコストが最終的に大きく響きます。そのため、プロジェクトを推進する上でかかるコストを算出し見積に加算しておくことが大切です。
システム開発の管理・調査・分析にかかる工数も明確にする
システム開発では要件定義、基本設計、詳細設計、プログラミング、各種テストといった決まりきったプロセスで開発が進むわけではありません。既存システム環境の事前調査や分析、開発者や外注先を適切にマネジメントするための工数も発生します。
通常、調査及び分析や管理工数にかかる工数は別途計上されますが、これを忘れてしまうとプロジェクトの利益を大幅に下げてしまうことになります。PM(プロジェクトマネージャー)に関しては自分自身の稼働状況も含めて工数を算出することが大切です。
見積は継続的に変更を加えていく
システム開発ではプロジェクト途中の仕様変更等が発生することは日常茶飯事であり、それによって新しいコスト（工数）が生じます。事前に協議できている場合はその条件に従って追加費用が発生しますが、個別に追加見積を提示する場合もあり、プロジェクト全体で発生している見積について常にクライアントと共有することが大切です。
プロジェクトの進行に伴い、徐々にしわ寄せが溜まっていくような形になると、本来予定していたタスクの工数を切り崩して他のタスクに割り当てるなど、プロジェクトの透明性が失われていくことで最終的にはプロジェクトのコントロールできなくなってしまいます。
システム開発における訴訟問題について
2003年に発生したシステム開発での訴訟問題※では、ベンダーが追加開発の見積をクライアントに事前提示せず、プロジェクト完了後に追加費用として請求したことでクライアントが支払いの意思を見せず訴訟に発展した判例があります。裁判所はこの訴訟に対して次のような判定を下しました。
“本件のようなソフトウエア開発作業においては、当初の契約の際に想定されていない追加作業が発生するのがむしろ通常であるから、追加作業の発生が明らかになった時点で、注文者が請負人に対して、当該追加作業の費用を負担する意思がないこと、または一定の限度額を明示してそれ以上の費用を負担する意思がないことを明らかにしないまま、当該追加作業を行うことに承諾を与えた場合には、当事者間に追加費用の額についての明確な合意が成立していない場合であっても、注文者は当該追加作業についての相当の報酬を支払う義務を負うと解するのが相当である。”
ベンダーはクライアントから追加工数分の費用を支払ってもらうことに成功しましたが、それは本来受けるべき正当な対価であり、それよりも大口のクライアントを失ったことの方がよほど大きなダメージだと言えます。
この事例のように訴訟問題が起きてしまうこと自体ベンダーにとってマイナスなので、それが起こらないよう都度見積をクライアントに提示し合意を得ることが大切です。
※「訴えてやる！」の前に読む IT訴訟 徹底解説（22）：見積もりに合意してないから、要件追加分のお金は払いません！ (1/3)
見積書は必ずフォーマットを統一する
意外と多い問題はプロジェクトの担当者ごとに見積書のフォーマットが異なり、管理が大変になり変更を加える際に問題が発生するということです。いわゆる“ドキュメントの属人化”がされた環境では正しい見積もりを作成できず、あるいは担当者が休職・離職された際に後任にうまく引き継げず問題が顕在化します。
誰でも同じように作成でき、誰でも正しく内容が確認できるようにするため、フォーマットやルールを統一しておくことが望ましいです。そのためにプロジェクト管理のツールなどを使用すると管理しやすく便利です。
まとめ
いかがでしょうか？システム開発における見積作成では押さえるべきポイントが意外と多く、難しい問題もあります。当然システム会社側も作業見積の段階でいくつかチェックプロセスを設けていて、顧客へ提出する前にレビューを行うことで、リスクを把握する努力も多く見られます。
ただ、その多くは明確になっている作業に対するコストの算出やスケジュールの妥当性について確認されて責任者の承認を取ることが多く、プロジェクトの進行に伴い発生する変更や追加などに関しては、進捗管理を徹底する必要があり、事前の見通しの甘さなどにつながりかねないこともあり、顧客との関係を悪化させたくないと言った心理も働きがちです。
