top of page
失敗しないシステム開発の発注方法

なんで相見積もりの金額がこんなに違うの?

追加料金ラッシュになるのはなぜ?

​期待通りのシステムにならない

費用の明確化を考えてみた

 

ちゃんとした費用を算出するためにすることは実はたくさんあって曖昧なところがあるとシステム開発会社は高めに見積もりをせざるを得ないということが開発会社に勤めてみてよくわかりました。

​とくに以下に挙げたようなところがはっきりしていないと高くなるな、というところをまとめてみた。

01

仕様は確定しているか

03

サーバ構成などインフラは確定しているか

02

基本設計書や画面構成図などドキュメントはあるか

04

開発期間などを少なく見積もっていないか

​発注前にだいじな2つのこと

01 仕様は確定しているか

慣れないと結構大変な作業になるのですが作ってもらうものは最終的に自分たちで使うものなので使い勝手が良いように作ってもらわないとまずクレームが出ます。

​いざ作り始めると、どうも違うなぁ・・とか、なんか思ってるのと違う進行になりつつあって不安になる・・というのはホントよくある話です。発注者と開発会社目線で書き出してみました

発注者目線

【1】ざっくりと必要な機能とか書き出して後はシステム会社と詰めればいいや。

【2】画面構成図とかイマイチ作り方わからないのでシステム会社に頼めばいいや。

【3】決済ツールとか必要なパーツとかわからないから後回しでとりあえず設計に入ってもらおう。

​【4】サーバ構成とか仕様とかよくわからないからその辺は触れないでおこう。

​【総括】

​ちょっとわからないところあるけどその辺はシステム会社との打ち合わせで詳細キメて行けばよいからまずは先に進めましょう。

​打ち合わせだからそこまで費用かからないでしょ。

開発会社目線

【1】要件が決まっていないので工数は多めに見積もらないと危ないなぁ。

【2】過去実績で似たようなケースを担当してたPMをアサインしてなんとかするか。

【3】確定していないのであれば調査期間を少し多めに見積もっておかないと危ないなぁ。

​【4】インフラの話がでてないけどこちらで担当するのであればインフラ系も触れておくか。

【総括】

​要件定義から保守・メンテまでの作業になるかもしれないからPMやインフラ部署にも話をしてしっかりと対応できるように準備しておこう。

打ち合わせ時間が長時間だから見積り加算しないと利益率が下がってしまうな。

要件定義はGoogle先生で探せばテンプレートなどは見つかるので加工して使うなりすると良いです。

要件定義は細かければ細かいほど良いです。

 

開発会社で過去に手掛けたケースなどと合致すると分かればその分工数が少なくなるので費用は安くなる傾向があります。

例えば、外部サービスである決済システムなど、あらかじめどこを使うかわかっていれば書き込んでおくことです。開発会社で過去に同じサービスのつなぎこみをしていればその工数は少なくなりますが、使ったことが無ければ調査からスタートしますからどうしても工数がかかるので高くなります。

02 基本設計書や画面構成図など書類はあるか

​発注費用を抑えることは発注会社であればどこでも普通に行っていることです。

相見積もりを取ることはもちろんのこと、概算見積もりをもらう段階で費用を抑えることが出来ることはあまり知られていないように思えます。

​別ページで記述しますがシステム開発には大きく分けて以下の工程があります。

企画

どのようなシステムを開発するかを練る作業

単体テスト

作成したプログラム箇所の稼働確認を行う作業

要件定義

作るものを洗い出してエクセルなどにまとめる作業

結合テスト

​全体でバグが出ないかを確認する作業

設計

要件定義に基づきどのように実現するかをまとめる作業

実装

​完成したプログラムを本番環境に設置する作業

構築

基本設計に基づき具体的にプログラムを構築する作業

保守

​稼働中のシステムにバグが出た場合の修正作業

ここに書かれた基本的な工程から外注で何を頼むかを決定していくわけですが、依頼する工程が多ければ多いほど費用は高くなります。

また企画、要件定義、設計などから外注する場合は上流工程もシステム開発会社にお願いすることになります。

仕事のできるPMやシステムエンジニアが参加してくれますから安心して任せられる一方、費用は高くなります。

​反面、要件定義書、基本設計書、画面構成図、画面遷移図などが出来上がっているのであれば構築からお願いすることが出来ますから費用を抑えることが出来ます。

費用を抑えるのであれば各種ドキュメントを自社内で作成するようにしましょう。

​それだけで費用はだいぶ変わります。

03 サーバ構成などインフラは確定しているか

 

すでに稼働しているシステムの改修であればたいていの場合、サーバ構成はすでに決定しています。

サーバ構成や仕様書などが開示できるのであれば他ドキュメントと一緒に開示しておくことでサーバ周りの費用を抑えることが出来ます。(状況によります。)

​すべてを丸投げでお願いするような頼み方をするとシステム開発会社は最良の選択肢を考えます。

あらゆる状況を想定し、構築するシステムが厳しい状況になっても止まらず、データを守るためにできる最高の設計を考えます。

これは当然の選択ですから決して悪いことではありません。

ただし、費用は比例して高額になります。

発注者側が無尽蔵に開発資金を捻出できるようなケース(新技術など開発ではこれに近い状況は存在します。)であればそれでも良いのですが、改修作業や規模の大きくない案件で予算が無尽蔵にあるなど少なくとも私はこれまでの経験で聞いたことがありません。

そこでインフラについては、あらかじめ決定しているならばそのことを伝えることは作業を明確化するにあたりとても重要な作業です。

また作業が明確化することで費用が明確化されます。

結果として想定している内容に近い見積もりを手にすることが出来ます

​04 開発期間を少なく見積もっていないか

ここも発注者とシステム開発会社で見解が分かれるところです。

可能であれば発注者側はゆとりがある開発期間を設定することでトラブルを回避できると考えています。

​それぞれの目線で見解を書き出してみました。

発注者目線

【1】上司から「なるはや」といわれてるから短めに設定するか。

【2】この辺りは時間がかからなそうだから短めに設定するか。

【3】プロが構築するのだから自社よりも早くできるだろう。

​​【総括】

​過去実績から似たような開発をしてるのだから理解した上で開発してくれると思うので出来上がりも早いはずだ。

開発会社目線

【1】プロジェクト自体がタイトな工期なので人材を確保しておく必要がある。

【2】100%わからないから調査・検証期間はすこし多めに取っておかないと危険だ。

【3】クライアント側で情報を持ってるなら開示してもらうほうがよさそうだ。

​【総括】

​通常の開発期間より短いので人材を確保して工期に間に合わせる必要がある。

​調査箇所について予算反映しなければならない。

トラブルになる原因の1つに調査・検証にかかる時間が両社で異なっている点です。

もう少し書くと、発注者側は1日で答えが出ると想定しているような検証でも実際には3日ほどかかってしまったりすることがあります。

調査検証とは本来、見えない部分を見えるようにする作業ですから時間軸で考えることはできないのです。

あくまでも目安であるため思ったより難しい調査になってしまうことも多々あります。

システム開発会社はそのあたりも工数に読み込まざるを得ないので調査検証を短くすることが費用を抑えるポイントになります。

結論として、調査検証についてはできるだけドキュメントに詳細を記載することでカバーできる場合があります。

見積もりは詳細な費目を書いてもらう

 

システム開発の規模にもよりますが発注者側として考えることは、見積もりはできるだけ費目を分けて作ってもらうことが大切ではないかと思っています。

私が発注側で働いていた時は必ず相見積もりを取り、費目についてはできるだけ詳細をお願いしますと各システム開発会社に依頼していました。

 

​見積もりに記載されている費用と費目、記載内容を読み込むことは依頼するシステム開発会社を選別するのに多いに役立ちます。

​参考ですが私が見積もりで重視していた点を書き出してみました。

​あくまでも最適解を導き出すための我流ですから参考程度に見ていただきたいです。

見積もりに必要な情報の見出しと費目が合っているか

​依頼する工程と見積もり記載の工程が合致しているか

​見積もりが出てくるまでの時間はどのくらいか

​曖昧になっている箇所は無いか

見積もりに備考などがどれくらいあるか

費目ごとに他社比較をし工数算出の平均値を出す

開発期間の想定とどのくらいズレているか

​見積もり作成者と打ち合わせ担当者が一致しているか

bottom of page