皆様の会社では、システム開発で開発業者とうまく折り合いがつかないと思っていることは無いですか?
(うまく行っている場合は、以下は読む必要はありません。)

よくあるケースは、以下のようなものです。

・操作性が悪い
・トラブル時にすぐ動いてくれない
・仕様変更がすぐにできない
・業務に対応できていない
・何かにつけ、別費用がかかる

なぜ、そのようになるのでしょうか?

表面的な原因はさまざまですが、本質的な原因は1つです。
それは、(受注側のご説明不足も含めて)最初の発注時の確認作業にすべての本質的な原因があると長年の経験から感じています。

システム開発をする際の、スタート時によくある会話のケースは以下のとおりです。

発注側:「こんなんしたいのだけど、できる?」
受注側:「(簡単に)できますよ?こうやって、こうやれば出来ますよ。」
発注側:「どのくらいかかる?」
受注側:「だいたい××万円ぐらいでしょうか?」
発注側:「そしたら見積りしてくれる?」
受注側:「はい、了解しました。ありがとうございます。」

後日、見積りが出来上がって、提出時の会話
受注側:「(見積書を提示しながら)おおよそ、このぐらいです。」
発注側:「結構かかるね?もう少し安くならない?」
受注側:「うーん、厳しいですね?かなりお安くしているのですが・・・」
発注側:「もう1度検討してみてよ?」
受注側:「はい、会社に戻って上司と相談してみます。」

後日、最終見積りの提出時
受注側:「これが限界というのを持ってきました。もうこれ以上は勘弁して下さい。」
発注側:「わかった。これでお願いします。」
受注側:「ありがとうございます。」

かなり普通のやり取りだと思いますここまでの会話で、システムを開発する際の問題点を発見できますか?少し考えてみて下さい。

















まず、見積りを取る際に、どこまでを見積もるのかが明確でないのです。
したがって、受注側のスタンスにより、さまざまな見積りが出てきます
(1)システム開発だけなのか?
(2)操作指導は?
(3)マニュアルは?
(4)どこまでの仕様変更までこの費用の中でやってくれるのか?
(5)業務の保守も入っているのか?
(6)業務以外の保守(ハード保守・汎用ソフト保守など)も入っているのか?

などなど、今少し考えただけでも、これだけ思いつきます。

発注側は、一番下を除いて、基本的にすべて入っていると思っているケースがほとんどです。
一番下でさえも、入っていると思われているケースがあります。

それに対して、受注側は、さまざまです。
見積りを安く見せるために、開発費用だけを見積りするところもあります(そうすると後で高くつく、もしくは払わないとやってくれない)。
すべて入れると、どのようなケースがあるかを想定できず、上記で言うと(1)(2)(3)のみの見積りとなるケースがほとんどです。
そして、(4)と(5)は備考欄におおよその金額を記入したり、別費用となっている場合が多いです。
(6)については、基本的に入っていないのが通常です。

ここにすでにお見積りの中に入っているサービスの範囲の認識が違うのです。

しかしながら、この認識の違いは、開発中のヒアリングを通じても、なかなか顕在化しません
だって、(1)以外は、その時点では必要の無いサービスだからです。

開発が終わり、操作指導が終わり、マニュアルが届けられ、いよいよ運用がはじまりました。

運用が始まると、「あれ、これが違うな?」とか「こんな機能があったら良いのに?」とか「この操作、何だかおかしいな?」など、さまざまな不具合が見つかり始めます。そして、いわゆる「バグ」も出てきます。

そこで、受注会社に「バグ」の報告をします。ついでに、「仕様変更」を依頼します。
受注会社としては、「バグ」を出してしまったので、申し訳ない気持ちもあり、運用当初は、開発中に出なかった変更内容として、簡単な「仕様変更」は受け付けます。しかしながら釈然とはしていない状況ですが、落ち度もあるので、仕方ないという状況です。

そんなこともあるので、「保守契約」を結んでくれるようにお願いに行きます。
基本的には結んでくれますが、この時点で上記の(6)がお客様の意識の中に組み込まれます。
結んでくれないこともあります。その際は「スポット保守として、1回1回請求します」ということをご了承いただきます。
しかしながら、これも結んでくれない場合があるのです。こうなってくると、両者のすれ違いが始まります。

そして、日常業務の中で、双方のスタンスに違いが時々出始め、それが積み重なると、大きな問題となり、人間的なトラブルに発展します。そして、ケンカが勃発し、最終的には業者変更となります。もしくは我慢して使うようになります。

この問題は多くの場所で頻発しています。何故でしょうか?

本質は確認不足ということですが、もっと根深い本質的な問題があります。
発注側も受注側もシステム開発経験が少ない、ということです。

発注側は何度も開発することは難しいので、当然なのですが、受注側も長年やっていてもすべてのお客様のスタンスを経験し、最初のお見積り時点で、きちんとした説明が出来るかというと、目の前のニンジンがあるため、まず受注し開発後に言えば良いやと思ってしまうのです(この選択こそがトラブルの経験が少ないからです)。

「受注側はプロなのだから、受注側のプロとしての問題でしょう?」と言われてしまえば、そうなのですが、競合他社さんがいる中で、あえて受注を難しくする見積りを提出するのは、厳しい状況である昨今なかなか出来るものではありません。それが出来れば、受注は出来ずらくなりますが、トラブルは減るでしょう?

だからこそ、見積り時点で、どこまでを入れた見積りにするのか?を、双方が確認する必要があります。
相見積りを取るなら、同じ土俵の上で戦わせて下さい。

長いスパンから見れば、失敗から学ぶということも大切ですが、弊社は、多くの皆様に、そんな失敗を繰り返して欲しくないと思います。
有限会社プラスカムでは、そんな失敗を繰り返さないために、同じ土俵になるように、ヒアリングシート(β版)を作成しています。お気軽にご用命下さい。

また、弊社は受注開発を縮小する方向です。理由は、クラウドコンピューティングがますます発展し、地域の業者でなくても、全国からさまざまなITサービスが受けられるようになるからです。地域のIT企業が果たすべきことは、これまでの経験を基に、サービス選定や有効利用の支援など、第3者の立場で、システム開発・運用コンサルタントもしくはIT有効利用コンサルタントとして、お客様の側に立ちノウハウを提供し、双方がうまくいくようにサポートしていきたいと考えています。

「安かろう、悪かろう」にならないように、「少しぐらい高くても良いもの」を構築する、構築することに主眼を置くのではなく、いかに有効利用するかに主眼を置いて、お客様の情報化を支援してまいりたいと存じます。

お問合せは、「TEL:0877-49-5206、FAX:0877-49-5297」です。お気軽にどうぞ!


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください