lego-708086_1920

システム改修の際の見積

 

システムの改修や新規機能の追加をお願いするとき、悩むのが費用だと思います。思った以上に高額だったり、それほどでもなかったり。

どこでどんな風に費用が変わってくるのか、見積依頼のときのヒントと、高くなる要因などをご紹介します。

 

業務の流れを変えたり、新たなサービスが追加されたり、既存のシステムを変更したくなる場合、システム開発業者に依頼します。

ちょとした機能追加だと思ったけど、想像以上に費用が高かったり。
大きな変更だと思ったけど、思ったより安かったり。

とかく、解りにくいと言われるシステム開発の見積ですが、こんなところで費用が変わってくる-という一般論をご紹介します。

※一般的な事例なので、契約やプロジェクトの内情により変わってくることがあるかと思いますが、ご参考までに。

 

一般的な見積は、人月単価と工数(時間)

システム開発の場合、その多くは工数といわれる作業時間を元に算出します。

これは、要望を満たしたアプリケーションを作成するのに要する時間(日数)が基準になります。

実際の制作には、設計・モノづくり(製造)・テスト・ドキュメント作成などの工程があり、それぞれに対してかかる日数を計算して、全体の作業時間が決まります。

これは、システムの改修や追加の場合でも、同じ工程を実施します。
つまり、新規開発でも、改修や小規模追加でも、工数の発生要因は変わることはありません。

では、費用を下げるために依頼者側ができることはどのようなことでしょう。

 

依頼内容を明確にする

改修やシステム追加の場合、ある程度の土台ができていますので、依頼者側で対応できる費用削減策としては、まず、「設計費用」を考えます。

修正する内容があいまいだったり、追加する機能が明確でない場合、開発者側での提案や調整で設計費用の見積は大きくなります。

それを押さえるためには、画面のハードコピーを使って修正箇所を具体的に提示したり、操作説明書などに追記/修正を加えた資料を用意して、できるだけ直したい点を明確に提示します。

依頼内容が明確な場合、開発者側の設計費用も軽減されるとともに、より正確な作業時間を予測できるため見積の精度もあがってきます。

見積には、打合せ途中で、仕様が変わったり、追加の要望が出たりする要素が多いと、打ち合わせ時間の想定や開発者側のリスク見込みがより多く含まれる原因になりますので、できるだけそれを軽減します。

 

細かな修正を繰り返すより、ある程度まとめて依頼する

小さな修正でも、プログラムに手を加えるときには、前述の制作工程を行います。
そのため、小さなボリュームを何度か行うより、まとめて依頼する方が全体費用として軽減できる場合があります。

これは、製造の環境を整えたり、テストデータを用意したりの作業をある程度一度にやることにより、重複した作業を減らせるためです。

弊社のクライアントでは、新製品の発売に合わせた年に1回の改訂の際に、改善点を一緒に依頼されることを前提に、改善内容などを取り纏めておかれご相談されるケースもあります。

 

マニュアルなど自社で修正できるものは、成果物から除く

システムの改修や追加に合わせて、納品してもらう成果物を明確にするとともに、仮に、操作マニュアルや運用マニュアルなど自社で修正可能であれば、それらを作業から除いてもらうのも軽減になります。

新規構築の際は、こうしたドキュメントは大量になる場合があるので、業者にお任せした方が良いですが、その後の改訂などは自社でできる体制がとれれば、社内で受け持つこともできると思います。

特に、運用マニュアルなどはスタッフの入れ替えや組織改定などにより変更する必要がでてくる図書になりますから、メンテナンスは自社でできるような体制を整えられると良いでしょう。

 

テストデータやテストパターンを用意する

テストに関しては、多くの場合開発者側がテストデータを作成しますが、あらかじめ、依頼者側でデータを用意したり、考えられるテストパターンを提示するなどすることで開発者側の効率化を図ることができます。

また、本番(実際に動作しているシステム環境)とテスト環境を常に用意しておくこともお勧めの一つです。
開発者側で用意してくれる場合もありますので、相談されてみると良いと思います。

 

 

次に、どのような修正が費用が多くかかるかですが、

依頼者側にとっては、簡単な仕様変更だと思うのに、どうしてこんなに費用が高いの。と思われることもあるかと思います。

仕様が簡単でも、システム内部の作りや影響範囲によって、想定以上の作業がかかる場合があります。
そのケースをいくつかあげてみます。

 

対象の修正箇所が、多くの機能に及ぶ場合

例えば、画面の表示ガイダンスを変える。などの修正を加える場合、対応する画面数が多ければ多いほど、改修量は多くなります。

ただ、その場合でも、ある程度共通化してプログラムされていれば、画面数には関係なく費用は積みあがりませんので、例外も多くあります。

 

修正がデータベースの改修や追加を含む場合

画面上の項目を追加し、管理する情報を付加する場合などは、データベースの改修をしなければならない場合があります。

これも、元の設計やプログラムによって差はありますが、データベースを変更するために従来のデータを移行しなければならなかったり、変換ツールを別途制作して本番前に実行しなければならない、などの作業が発生する場合もあります。

 

テストパターンが複雑、またはデータ量が多い

改修の内容によっては、テストしなければならないパターンが複雑だったり、テスト項目数が多かったりすることで、工数は大きくなります。

費用削減策の中でもご紹介しましたが、データ量が多いシステムなどの場合などは、本番データを流用してテストデータを作成するなど、依頼者側からの提案も有効になります。

※その場合、実データですので、個人情報の部分はマスク(他の文字や記号などに置き換えて、判別できなくする)などの配慮も開発者側に相談してみてください。

 

 

 

システムは、その業務や環境、開発の手法などにより、ここであげた例に沿わない場合もあるかとは思いますが、ヒントとして参考にしていただければと思います。

 

 

 

 

The following two tabs change content below.

田邉弘美(たなべひろみ)

メーカーのプログラマーを経て27歳で独立起業。数々多くの企業のシステム構築を手掛けてきました。得意な分野は基幹システムや営業支援、顧客管理など社内業務のシステム構築。プロジェクトでは、主にお客様の要望整理や業務改善などのコンサル部分を担当。私の無理難題も難なくこなす頼もしいスタッフ(技術者)に囲まれ、奮闘の毎日を送っています。

最新記事 by 田邉弘美(たなべひろみ) (全て見る)