アプリ開発・ウェブ開発

結局いくらかかるの?業務システム改修の適正な見積

今日は関西で打ち合わせ。

業務システムの改修見積が妥当な金額かどうかを見て欲しいという、変わったご相談で京都の某社に訪問してきました(^_^;)

稼働している業務システムに機能追加をする場合、既に付き合いのある会社に依頼するのが普通だと思いますが、既に付き合いがあるが故に、いい値の見積になりがちです。

アプリ開発を新規で依頼する場合の見積 は以前に書いた通りですが、システムの改修となるとまた考え方が違ってきます。

また、適切な見積を考える前にそもそもの体制が整ってるかどうかなど考える必要があります。

今日はそういうところを色々書いてみました。

開発会社に依存していないかどうか

どの業界でも、一社依存はリスクありますよね。

その会社が倒産するリスク、別の会社へのスイッチが難しくなるリスク。

当然、一社依存が多ければ多いほど、いざ別の会社にスイッチした時のコストも多くなります。

改修も開発も一社依存しないのが鉄則ですし、開発時に一社に依存した設計をしていないかが大事です。

技術的依存がないかどうか?

その会社が使ってる技術の中に独自技術があると他社への移管は難しくなります。

結果、一社依存の見積になり高くなりがちです。

開発言語は依存していないか?

開発言語は汎用性の高いものを使用しておくのが良いです。

言語依存で一社に依存するケースはまれですが、問題になるところで、よくあるのはフレームワーク依存です。

PHPなどの言語は昔からフレームワークが乱立していたりして、主流だと思われていたオープンソースのフレームワークが開発終了したりして混沌としてた歴史があったりします。なので、開発会社がオープンなフレームワークを採用せず独自フレームワークを制作して採用していたりします。

開発会社側はそれでもいいのですが、発注側はその開発会社が作成したフレームワークを使ったシステムを使い続けることになるので、規模の拡張に比例してその会社への依存が強くなります。

そうなると他社への移管は難しくなります、なぜなら他社が改修する場合、そのフレームワークの仕様から把握する必要があるからです。

その学習コストは見積に上乗せされます。

初期の開発時にはあらかじめ独自技術をできる限り取り入れない選択をするのがベターです。

環境依存していないかどうか?

開発環境、サーバー環境を依存していないか確かめましょう。

開発したシステムが別環境で構築可能なのか、構築する場合の技術的要件も確認しておきましょう。

できれば、社内でソースコードを触れる人がいなくても、最初の開発時に社内向けに開発環境を用意してもうのがベストです。

好きに編集できる開発環境があれば、その環境を別の開発会社に見せて見積を取るのもやりやすくなります。

開発会社に依存している場合

一社依存していない場合、人月計算したり機能単位で計算したり、基本的な見積の計算を考えることができますが、依存が多い場合、当初の開発会社の言い値で改修するしかなくなってきます。

そうなってくると適切な見積の計算は難しく、政治的な部分で見積が決まる要素が大きくなります(´・ω・`)

依存せざるを得ない場合は開発会社と仲良くやっておきましょう\(^o^)/

開発工数以外の要素

見積の内容は工数を計算する以外に、打ち合わせコスト、資料作成も含まれていたりします。

打ち合わせをする時間は発注側からにもコストが発生しているので、基本的には今まで取引している会社と仲良くやるほうが色んな手間が省略できるので楽なんですよね。

新しい会社に頼んだところで、信頼できるのかどうか、ちゃんと納品してくれるのかどうかもわからないわけで。

そういう意味では今まで取引している会社が信頼できる会社であれば、発注側は打ち合わせ時間が節約できる代りに、多少上乗せされるのは仕方ないかなぁと思ったりもします。

会社規模と案件規模による見積金額の違い

会社規模による見積金額の違い

開発には原価はほぼなくて、人件費だけなんですが、それ故に開発会社の規模で見積が変わります。

例えば従業員数100人くらいの会社に発注すると堅牢な開発体制ですが、その分その人数を賄うオフィスの費用や管理費などが上乗せされてきます。

逆に数人でやってる会社に発注するとフットワークは軽くて、費用も大幅に安いですが、プログラマー1人に依存していたりします。

案件規模による見積金額の違い

また、既に稼働しているものですと、案件規模の大きさによって改修の工数は大きく変わります。

例えば、顧客管理のシステムで既にデータが何万件も登録されている場合とか、色んな機能が入って肥大化しているものの場合、少しの改修で全データの整合性を見直したりバグをチェックする必要があります。ちゃんと見積もろうと思ったらそれだけで何日かテストしないといけなくなります。

適正な見積はどう計算するか?

色々な要素を考えると、改修で適正な見積を出すのって実際なかなか難しいんですよね(^_^;)

  • 元のデータを変えることになるのか?
  • どれくらい機密なデータを扱うのか?
  • 本番環境に与える影響は?
  • 改修後に業務に与える影響はどれくらいか?
  • テストはどれくらいやるか?
  • バックアップ体制はどこまで用意するべきか?

などなど、考えるべき要素がたくさんあります。

 

結論

案件によるので見積は簡単ではないです\(^o^)/

一度ご相談下さい\(^o^)/

 

The following two tabs change content below.

SNS