Tweet
システム開発と契約分割
法人・ビジネス システム開発・導入 2009/01/31 20:54? システム開発における要件定義と、要件定義後の契約を
分割することはどの程度一般的なのでしょうか？
システム開発の案件は要件定義から稼動後のサポートまでを範囲として
契約したほうが事務的には楽だと思いますが、ある程度複雑な
システムにおいては要件定義を行わずに全体の金額を算出するのは
困難だと考えられますので、要件定義作業と、それ以後の作業の契約を
分けて、別ものにするという考え方があると思います。
発注側から見て：
・要件定義についてはシステムコンサルタントなどの会社に任せ、開発は
開発会社に任せるなど、適任と思える会社に依頼が出来ると思います。
・要件定義がしっかり終わっていれば、開発作業の見積精度が上がり、
リスクがそれだけ省かれますから開発コストを抑えられると思います。
・見積に必要な材料が揃っているならば、それぞれの作業に別会社が
参入しやすくなるので、相見積をとり易く、業者選定がしやすくなります。
請負側から見て：
・開発作業を請け負う際、隠れた要件は無いという前提で見積が出来るため、
受注時のリスクが小さく、見積の根拠も説明しやすくなります。
? 契約の分割には上記のようなメリットもありますが、発注側担当者の
事務的な負担も増大しますし、配慮すべき事柄も出てきますので、
それをらを考慮すると、どのような分割の仕方をするのがお勧めでしょうか？
業務の背景や、システムを取り巻く環境によりけりとは思いますが、
趣旨ご理解の上、特色あるご回答をいただければ幸いです。
ｍｔさん （ 東京都 / 男性 / 42歳 ）
分割契約の背景
- ( 3 .0)
IT化支援ラボ 濱田です。
私の書いた雑誌の記事をご覧頂けたのでしょうか?
(もしそうでしたら非常に有難い事です)
この方法はまだまだ一般的にはなってないと思います。
この方法を紹介している私自身も誰かに教わったわけでなく、
理にかなった方法を模索した結果ようやく辿りついた方法だからです。
ただ、例えば業務パッケージの導入では最初に業務コンサルティングが別契約であり、
業務要件の分析やパッケージとの適合性、カスタマイズ費用の見積り等を行います。
業務システム導入での失敗は会社経営に大打撃を与え、安易な導入はできないから
このように進めるのです。
このように「どうしても発注者にマッチしたシステムを提供しなければならない」
という状況下で突き詰めて考えると必然的に同じ様な方法を取らざるを得ません。
統計的に現在の一括契約が危険である以上改善しなければならないはずです。
また、発注者・請負側から見たメリットについてはご理解の通りです。
補足しますと2の事務的な負担はトータルではあまり増えません。
というのも今までの方法では、開発見積りは要件定義の前に作られますので
内容の確認や費用交渉に時間がかかり、見積再作成と再確認を何度も行う必要が出てきます。
例え発注先が決まっていても見積の確定だけで1ヶ月近くかかってしまう事がザラです。
一方、要件定義後の見積は発注者にも内容がわかっていることから不安なく
すぐに通せる場合が多く、契約関連の作業負担や時間を驚くほど削減できます。
こういった事から、今までこの方法で進めた中でデメリットといえる点が正直見当たりません。
大きな開発会社では営業から社内稟議等の流れや組織体系を簡単に変えられない
弱点がありますので、大きな会社でこの方法を導入しようとししても残念ながら当分先の
話しになると思います。
この方法が広まり、発注者と開発者の双方がより良い結果を得る助けになれば嬉しい限りです(^^)
評価・お礼
ｍｔ さん
遅い時間にご回答いただきまして恐縮です。
? 契約分割はあまりメジャーではないという見解でいらっしゃるのですね。
適用業界ごとに契約分割の採用率が分かればいいのですが、契約自体
機密事項ですから、そのような数字を得ることは難しいのでしょうね。
それでも、こうした方法で業務を推進することに抵抗を感じる
必要はないことは分かりました。
? 要件定義以外の契約分割ポイントがあればどこに設定するか、また、
何分割するのが適当かということを求めたかったのですが、濱田様が
仰るように、要件定義とそれ以降の作業契約分割自体も浸透していない
となると、あまりバリエーションがないのかもしれないですね。
参考になる内容を、
大変ありがとうございました。
