システム開発のトラブルの大半は見積で防げる【徹底した具体化が鍵です】

f:id:Airoue:20190821221501j:plain

こんにちは。アイルです。


今回は受託開発などでシステムの開発を行う際に提出する「見積書」についてお話します。


システム開発案件はその見積内容が分かりにくい上に、実際にものができるまで時間がかかり、できた後も中々細かいところはわからないので、トラブルになりやすいです。


トラブルを避けるには色々とテクニックがありますが、その中でも「見積書」の内容次第で数多くのトラブルを防ぐことができます。


私がいたシステム会社は同じ部署内でも4つのチームに分かれて営業や開発をしていましたが、お客様とのトラブルは他のチームに比べて「半分以下」と非常に安定した部署でした。


そのうちの大部分は「見積段階でトラブルを防げていた」からだと思っています。


システム開発は見積次第でトラブルを減らせる

f:id:Airoue:20190821221624j:plain


システム開発を車で例えると、

他には誰も乗っていない車を、パンフレットを見ただけで購入する

とイメージ頂ければ伝わるかと思います。


これだと乗り心地や車内の使い勝手、実際の燃費などでトラブルにもなりますよね。


車であれば同じタイプの車を用意しておいて、試乗してもらえばトラブルを防ぐことができますが、


要望に沿ったシステムを作るシステム開発では「試乗車」に変わるものが用意できません。


そこで「発注をもらう前」にお客様へ提示する見積書で、出来るだけ細かく、具体的に説明をしておく必要があるのです。


では見積書を提示する時に説明すべき内容とは何でしょうか。
それは以下の5つの内容です。

1. 具体的な出来上がりのイメージ
2. 費用の内容がわかる明細
3. いつまでに何が出来ているかのスケジュール
4. 出来ること、出来ないことがわかる前提条件

が必須の内容になります。


この他にもサーバやネットワーク機器を導入する場合は、その内容がわかるものなど、内容や規模によって追加で必要になるケースもありますが、基本はこの5つになります。

具体的な出来上がりのイメージ

システム開発は作り終わるまでどのようなののが出来上がるか、分からないことがほとんどです。


それに加えて、作る側とお願いする側の両方が同じように「これだ」と言っていても、それが同じものである可能性は極めて低いです。


実際にシステムが出来上がったとしても、細かい部分まで全てを把握しきるのは難しいのに、会話や簡単な資料だけで両者のイメージをぴったりと合わせる事なんて不可能です。


理想としてはサンプルを作成し、イメージと違う部分を直し続けるのが完成物が一致するという点においては理想的ですが、どれだけ期間がかかるか、どれだけ費用がかかるかが分かり難くなります。


そのため、システム開発を依頼する時にこういった方法をとる企業は非常に少ないです。


後々で「イメージ違い」のトラブルを防ぐためには、徹底的に双方おイメージを合わせておくことが大切です。


費用な内容がわかる明細

システム開発を委託したいときに見積を依頼するのですが、多くの企業が

・◯◯システム開発 一式 □□万円

・要件定義 一式 □□万円
・設計   一式 □□万円
・開発   一式 □□万円
・テスト  一式 □□万円

と具体的な内容がわかりにくいものがほとんどです。


この明細では「何に費用がかかっているのか」「どうすれば費用を抑えることができるか」が曖昧になります。


システム開発では想定しているより「金額が大きい」ことが数多く借ります。


そういったときに交渉のしにくい明細では、ただ「高い」と思われてしまい、受注しにくいどころかトラブルになるケースもあります。


いつまでに何が出来ているかのスケジュール

いつ何が出来るのか分からないと、人は不安になります。


特にシステム開発では、「期間が長い」ことに加えて「完成するまでほとんど状況が分からない」という問題があります。


そして、そうやって作るシステムは社員の業務を楽にする、新しいサービスを提供するなど、業務へのインパクトが大きい場合がほとんどです。


後から「遅れそう」と伝えるよりも予めわかっているスケジュールに沿って話をする方が、トラブルを防ぐことができます。


出来ること、出来ないことがわかる前提条件

これは「具体的な出来上がりのイメージ」に近い内容になります。


出来上がりのイメージは「お客様が使う部分」を具体化するのに対し、前提条件は「目に見えない部分」を具体化することが多いです。


具体的には

「そのシステムは24時間動くのか」

「バックアップはいつ、どれくらいとるのか」

「システムが止まったらどうするのか」

といった内容になります。


この部分はお客様にはイメージしずらい部分が多いですが、トラブルが起きたときに影響がある重要な部分になります。


後々のトラブルを根本的に解決するにはシステムの改修をするか、お客様に運用を変えてもらう必要が出てきてしまいます。


そうなるとどちらにとっても損失は大きくなってしまいますし、そもそもトラブルが起きたことがお客様にとっては大きな損失になってしまいます。


トラブルを少しでも防ぐ為には「目に見えないところ」も出来るだけ細かく両者のイメージを合わせておく必要があります。


まとめ

トラブルは両者にとって何のメリットも生みませんので、出来る限り避けるのがベストだと思います。


実際に発注をもらってからではなかなか方向転換が難しいものもあると思いますので、出来る限り早い段階で不安要素は潰しておく方がいいと思います。