分割契約の背景

IT化支援ラボ 濱田です。
私の書いた雑誌の記事をご覧頂けたのでしょうか?
(もしそうでしたら非常に有難い事です)

この方法はまだまだ一般的にはなってないと思います。
この方法を紹介している私自身も誰かに教わったわけでなく、
理にかなった方法を模索した結果ようやく辿りついた方法だからです。

ただ、例えば業務パッケージの導入では最初に業務コンサルティングが別契約であり、
業務要件の分析やパッケージとの適合性、カスタマイズ費用の見積り等を行います。
業務システム導入での失敗は会社経営に大打撃を与え、安易な導入はできないから
このように進めるのです。
このように「どうしても発注者にマッチしたシステムを提供しなければならない」
という状況下で突き詰めて考えると必然的に同じ様な方法を取らざるを得ません。

統計的に現在の一括契約が危険である以上改善しなければならないはずです。


また、発注者・請負側から見たメリットについてはご理解の通りです。
補足しますと2の事務的な負担はトータルではあまり増えません。

というのも今までの方法では、開発見積りは要件定義の前に作られますので
内容の確認や費用交渉に時間がかかり、見積再作成と再確認を何度も行う必要が出てきます。
例え発注先が決まっていても見積の確定だけで1ヶ月近くかかってしまう事がザラです。
一方、要件定義後の見積は発注者にも内容がわかっていることから不安なく
すぐに通せる場合が多く、契約関連の作業負担や時間を驚くほど削減できます。


こういった事から、今までこの方法で進めた中でデメリットといえる点が正直見当たりません。
大きな開発会社では営業から社内稟議等の流れや組織体系を簡単に変えられない
弱点がありますので、大きな会社でこの方法を導入しようとししても残念ながら当分先の
話しになると思います。

この方法が広まり、発注者と開発者の双方がより良い結果を得る助けになれば嬉しい限りです(^^)