2013/10/11

顧客を巻き込まないとシステム化なんて出来ません 見積りのトラブル

 どうも巷で話題になっているようなので、取り上げてみたいと思います。
 問題は以下のページ、社内のシステム化のためにシステム会社に見積りを取ってみて、より詳細の提出を求めたら設計料を請求されたというもの。

 ■見積りの根拠出してくれっていったら、金くれって言われたよ

 これを見ると、発注者と受注者双方の固定観念で、どうにもならなくなっているようです。
 発注者側はシステム開発会社なんて詐欺のようにおもうでしょうねぇ。想像つかない仕事は大変かどうかなんてわかりませんから。...(システムで頭いっぱいにして、何日も考えまくって作ることになるんですけどねぇ。)

 こういった案件は、「何の目的」で「何をどうしたいのか」がわからないで、「システム化が目的」の案件のようです。
 流行に追随したいだけで、自分の欲しいものがわからず相談しているのです。

 前述のページでは、発注者側の問題を指摘する声が上がっていますが、私の意見は違います。
 まず、何が欲しいのかがわからないわけですから、プロとして、そこに付き合ってあげれば良いわけです。
 最初にシステム化は「何の目的」でしたいのか、しっかり話し合ってはどうでしょう?。
 今の業務に何の支障がでているのか、そもそも問題など無いのか、それによって荒削りの「目的」ができてくると思います。

 「目的」をしっかり決めるという事がどういう意味を持つことかわからない方もいますが、システム化とは武装化であること、武器は効果的でなくては浪費にしかならないことを、しっかりと理解してもらいましょう。

 理解していただけないようであれば、おそらくそこにはシステム化の時期が来ていないのです。時が来るのを待ちましょう。
 とにかく「目的」については必ず決めます。
 次に「目的」を実現するための方法論に入っていきます。システムの開発は概ね次のようになることを伝えます。

システム開発の流れ
(0)目的の設定
(1)業務分析
(2)要件定義
(3)概要設計(方式設計を含む場合もある)
(4)詳細設計(方式設計を含む場合もある)
(5)製造
(6)結合テスト
(7)総合テスト
(8)本番テスト
(9)稼働(納品)
(10)保守

 システム屋からすると、受注した上で設計に入っていくとしたいところでしょうが、発注者側はもう少々イメージがわかないと、社内整合もとれないでしょうから、業務概要図とシステム概要程度(発注者側の社内整合用なので数枚程度で良いと思います)までは営業費用とおもって無料で作成てはどうでしょうか。

 判断材料の次の工程からは現金化したいところです。発注者側判断が滞るなど、中途で進まなくなるリスクもあるので、段階的な契約とするようにします。

 理想は、各ひとつづつ契約を取りたいところですが、(1)〜(3)を一つの契約、(4)〜(9)までを一つの契約、(10)を一つの契約といった3段階でやりたいところです。

 当然、各契約では納品物をはっきりしてすすめるようにします。特に受注者側はとしては受注リスクを最小化するためには、(1)〜(3)は委任契約とし、結論が出なくなったら、ここで完了とします。(もちろん極力最後までがんばりますが、失敗は早めにやめたほうが良い)
 無論、発注者側も契約単位で続けるか否かを判断しますので、途中で完了とされるかも知れません。ただし、リスク共有の形としては理想だと思います。
 (4)〜(9)は委託(完成物責任あり)でしょう。

こういう風に発注者側を巻き込んでいくやり方をとれば、しっかり機能して発注者側に喜ばれるシステムが作れるのではないでしょうか?
偉そうに書きましたが何かの参考になれば嬉しいです。

0 コメント:

コメントを投稿