システム開発と契約分割

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

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

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

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


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

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


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

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

バンブーウエイブです。
長くシステム開発をしていた経歴とWEBシステム開発の実務をこなしている立場から個人的に感じることをご回答いたします。

>どの程度一般的なのでしょうか?
WEBシステムにおいては、あまり一般的ではないでしょう。大規模なシステム開発ではよくありますが。

**WEBシステムでありがちな契約
通常は、ひいきにしている制作会社さんにそれとなく話をしているうちになんとなく要件が出来上がっていくものでしょう。
その後実際の制作が始まる際に、制作会社は作業員や外注先を確保して正式に見積もりし、最終的に工期が設定され、開発がスタートする。

という、感じかと思います。

このケースのデメリットは、要件定義後の発注先を別のところにするのが道徳的にはばかられる点でしょう。要件定義までは無償で働いてもらってますので。もしも実装する内容が制作会社の苦手な部分であるとすると、まるまる外注することになるので、費用も高くなるかもしれません。


**ブレインの起用
>それをらを考慮すると、どのような分割の仕方をするのがお勧めでしょうか?

要件定義だけをコンサルティングしてもらうとなると、それなりに高いものになるかと思います。見栄えのする資料やプレゼンをもって来るかと思いますが。コンセプトは面白いが、実装が困難みたいな提案もあるかもしれません。

弊社でお勧めするのは、要件定義やシステム開発に精通したコンサルティングをブレインとして抱えることです。

要件定義の段階からブレインに相談し、発注は公募で募り、ブレインはプロジェクト全体の管理をするというものです。稼働にもよりますが、ランニングでの契約になりますので、それほど高額にはならないはずです。全体に携わるので責任感もあり、制作会社とのよい仲介役として活躍してくれるはずです。

ご参考になれば幸いです。

ホームページ制作・WEBコンサルティングのバンブーウエイブ

コードワークス株式会社の伊藤と申します。
はじめまして。

要件定義とその後の作業を切り分けて、別の契約で行うということは、地方公共団体(県、国なども)の仕事などでそこそこの規模になると行っている例があります。

実際には、
・用件定義(いわゆるコンサル)
・設計
・詳細設計および実装
程度に分割する場合が多いようです。

さて、なぜこのように分けているかと役所の人に聞きますと、全部一緒に発注すると、それぞれの費用案分が明確でなくなること、あと無駄な用件定義をされて結局無駄な実装をして無駄なお金を使うことを防ぐため、との話を聞いたことがあります。(入札という仕組みの問題も絡んでいるようですが)

分割契約を行い、かつそれぞれ別の業者さんが入られるのであれば、上記の役所の人が言うとおり、無駄をなくすことや、費用についての明確化という点で大きな利点があるかと思います。
ただ、用件定義した内容がきちんと、設計、実装側に伝わらずに当初の計画とずれた成果物ができてしまうという危険性がありますので、発注側は要注意です。
当社の経験では要件定義側で入った案件で、実際に他の業者さんの成果物を見に行ったら、当初の目的と違ってない???という思うものがありました。

一方、同一業者さん内で契約を分割していくのであれば、メリットは双方あるかと思います。発注側も受注側も、細かくお金を動かせるのでリスクを減らせること、計画の遂行が契約単位になるので、それぞれの段階でミス、考えの変化、市場動向の変化などなどさまざまな要因に強いプロジェクトとなること、などです。営業的・経理的には面倒ですが、双方ともにそれ以上のリスク分散効果が期待できると思います。

ご参考になりましたら、幸いでございます。

こんにちは。ホロデックスの村本です。

契約分割というコトバはさておき、案件にかける人数や年数によって分担するのは、
契約形態はさておき、ウォータフロー型の開発手法をとるプロジェクトでは、行われてきました。

他の専門家がすでに指摘されているように
・分業のすすんだ制作およびコンテンツ系のシステム
・官公庁、大企業向け新規大規模システム
では、多いように思います。

現在では、このようなプロジェクト案件もすくなくなり、小規模でスタートし、現場の意見や運用形態と連携し、改修しながらシステムを構築していく案件が多くなりましたので、契約分割するようなケースも少なくなってきたのではないかと存じます。


**要件定義以外の契約分割ポイントがあればどこに設定するか

ポイントとしては・・・

>・要件定義
・システム開発
・システムサポート
・運用指導&体制作り<

だと思います。

***この分担形態を上手にプロジェクトをすすめるノウハウが発注者側にできれば、様々なプロジェクトにおいて、IT資産(システム、人材、トレーニング)の再活用も可能になるでしょう。

ただし、前に述べましたように、あくまで

*発注者側が請負会社を選ぶノウハウとプロジェクト規模により、使いわけるべきだと思います。

分割発注は発注者側の能力や手間必要となることから、大手企業や官公庁では推進されていても、中小企業ではなかなか普及していなかったと言えます。

しかし、日本を世界のIT先進国にしなければ失われた10年を取り返せないという理解から、e-Japan 構想を表明し、そのために様々な施策をとってきました。

そこで、中小企業を管轄する経済産業省では、中小企業のIT化推進のためには、中小企業経営と、IT開発者との橋渡し役が必要であると認識から、ITコーディネータと言う資格制度を立ちあげました。
他の専門家の方がおっしゃっておられるブレイン役です。

ITコーディネータ協会や、経済産業省は、分割発注の方が発注者側にとっても、開発者側にとってもメリットがある方法であるとして、推奨しています。
プロセスガイドラインというものがありますが、その中でもシステム開発のプロセスを分解し、ケースバイケースではありますが、分割発注することを推奨しています。

実際、ここ数年で中小企業のシステム開発でも分割発注の事例が増えています。

その際、以下の資料は参考になると思います。

ITC協会 無料ダウンロード(RFP/SLA見本等)
IPA 発注者ビューガイドライン

これらのツールを利用しながら、分割発注をされることもよいと思います。
ご参考になれば幸いです。


集客につながるホームページ
ネットとセキュリティ〜ウィジット株式会社
岡本興一

通常開発会社は、「自分の会社で得意な物」を提案します。
これは当然だと思います。

しかし、現在の時流でみたときにどうでしょうか?
将来的に拡張性があるのでしょうか?

提案だけの会社をえらんだ場合、
そのしがらみから離れて本当に必要なプロダクトを提案してもらえる可能性があります。

他の方がおっしゃっている通り、小さなプロジェクトでは、あまり見受けません、
と言うのは、「本当に色々わかっている人間」は高いからです。

開発費に対してコンサルティング費用がかさんでしまうためです。
(120万/月-160/月平均、それ以上もある)

ただし、安くて、いいコンサルさんがいる事も確かです。
なので、見る目を養うのも重要です。

そして、デメリットを一つ。
皆さんおっしゃるように特段変わった契約ではありません。

しかし、「要件定義」というものがどこまでの仕事で、
「責任範囲」はどこまでかを明確にしておく必要があります。

たとえば、「正しいメールアドレスを入力させる」と要件定義であった場合、
その曖昧な仕様を、正しい要件定義に昇華できるのは、かなりレベルの高い開発会社さんです。

たとえば、(極端な例ですが)
「データーを送る前にIEのブラウザの更新ボタンを押し、
その後URLをFireFoxにはりつけて送信ボタンをおし、
すぐにキャンセルを押した後IEで送信をおしても問題なく動作する事
(Firefoxでは不正な処理となり、IEでは、既にデーターが登録されていますと出ないこと)」

という要求がなければ、要求定義したほうが悪いのでしょうか?
それとも、常識的な対応ができない開発会社がわるいのでしょうか。(どこまでが常識?)

上の文がFireFoxではなく、別のブラウザに対応しないのは、書いていないからOKでしょうか、
その場合コストの関係も考えず、「全て」のブラウザに対応することと、書く要求定義が正しいのでしょうか?

こういったトラブルを未然に防ぐルールを考えておく必要があります。