システム開発と契約分割 - システム開発・導入 - 専門家プロファイル

専門家の皆様へ 専門家プロファイルでは、さまざまなジャンルの専門家を募集しています。
出展をご検討の方はお気軽にご請求ください。

注目のQ&AランキングRSS

対象:システム開発・導入

システム開発と契約分割

法人・ビジネス システム開発・導入 2009/01/31 20:54

? システム開発における要件定義と、要件定義後の契約を
分割することはどの程度一般的なのでしょうか?

システム開発の案件は要件定義から稼動後のサポートまでを範囲として
契約したほうが事務的には楽だと思いますが、ある程度複雑な
システムにおいては要件定義を行わずに全体の金額を算出するのは
困難だと考えられますので、要件定義作業と、それ以後の作業の契約を
分けて、別ものにするという考え方があると思います。

発注側から見て:
・要件定義についてはシステムコンサルタントなどの会社に任せ、開発は
開発会社に任せるなど、適任と思える会社に依頼が出来ると思います。

・要件定義がしっかり終わっていれば、開発作業の見積精度が上がり、
リスクがそれだけ省かれますから開発コストを抑えられると思います。

・見積に必要な材料が揃っているならば、それぞれの作業に別会社が
参入しやすくなるので、相見積をとり易く、業者選定がしやすくなります。

請負側から見て:
・開発作業を請け負う際、隠れた要件は無いという前提で見積が出来るため、
受注時のリスクが小さく、見積の根拠も説明しやすくなります。

? 契約の分割には上記のようなメリットもありますが、発注側担当者の
事務的な負担も増大しますし、配慮すべき事柄も出てきますので、
それをらを考慮すると、どのような分割の仕方をするのがお勧めでしょうか?

業務の背景や、システムを取り巻く環境によりけりとは思いますが、
趣旨ご理解の上、特色あるご回答をいただければ幸いです。

mtさん ( 東京都 / 男性 / 42歳 )

回答:6件

濱田 崇 専門家

濱田 崇
ITコンサルタント

- good

分割契約の背景

2009/01/31 22:37 詳細リンク
(3.0)

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

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

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

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


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

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


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

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

評価・お礼

mtさん

遅い時間にご回答いただきまして恐縮です。

? 契約分割はあまりメジャーではないという見解でいらっしゃるのですね。

適用業界ごとに契約分割の採用率が分かればいいのですが、契約自体
機密事項ですから、そのような数字を得ることは難しいのでしょうね。

それでも、こうした方法で業務を推進することに抵抗を感じる
必要はないことは分かりました。


? 要件定義以外の契約分割ポイントがあればどこに設定するか、また、
何分割するのが適当かということを求めたかったのですが、濱田様が
仰るように、要件定義とそれ以降の作業契約分割自体も浸透していない
となると、あまりバリエーションがないのかもしれないですね。

参考になる内容を、
大変ありがとうございました。

回答専門家

濱田 崇
濱田 崇
(神奈川県 / ITコンサルタント)
代表取締役
090-6002-4611
※お電話の際は「"プロファイル"を見た」とお伝え下さい。

そのシステムは必要か?見積りは適正か?第三者の立場から助言

「金をかけたのに使えない」これらはシステムを導入した企業からよく聞かれる言葉です。致命的な問題を回避し、高いパフォーマンスが得られるシステムを導入できる手法を書籍でも紹介しています。お陰様で高い評価とご満足を頂いております。

質問やお悩みは解決しましたか?解決していなければ...

※あなたの疑問に専門家が回答します。質問の投稿と閲覧は全て無料です。
村本 睦戸 専門家

村本 睦戸
ITコンサルタント

- good

開発規模で分割を考えるのがわかりやすいのでは?

2009/02/01 14:56 詳細リンク
(3.0)

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

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

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

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


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

ポイントとしては・・・

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

だと思います。

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

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

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

評価・お礼

mtさん

日曜日のご対応、ありがとうございます。
恐れ入ります。

? 予想以上に契約分割がメジャーであることが分かりました。

しかし、ウォーターフォール型の案件が減ってきているというのは意外でした。
経験上、スパイラルモデルやアジャイル開発という形態をとっている案件というのは、ほとんど聞いたことがなく、一件例外があったのみでした。
やはり、専門家に聞いてみるものです。

? 契約分割ポイントの例示をありがとうございました。
最後の、「運用指導&体制作り」を分けているのが特徴的に思いました。

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

念頭におき、業務に活かしたいと思います。
ありがとうございました。

回答専門家

村本 睦戸
村本 睦戸
(石川県 / ITコンサルタント)
ホロデックス 
050-5539-7874
※お電話の際は「"プロファイル"を見た」とお伝え下さい。

集客・販促・提案できる組織の「見える化」で会社力アップ

集客・業務改善(営業・管理)の課題をITで攻めの組織づくりのご相談承ります。情報戦略と地方事情にあったひとづくりとマーケティングで業務の「見える化」をプランニングし、地場密着の会社力をアップをご支援いたします。

村本 睦戸が提供する商品・サービス

メール相談

会議やプレゼン企画書外部チェックサービス

~30代からの現場力アップシリーズ~

メール相談

行政ウケする助成金、補助金申請書チェックサービス

~30代からの現場力アップシリーズ~

竹波 哲司

竹波 哲司
Webプロデューサー

- good

ブレインを抱えることもおすすめです

2009/02/01 09:54 詳細リンク
(3.0)

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

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

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

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

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


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

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

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

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

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

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

評価・お礼

mtさん

日曜日のご対応ありがとうございます。

? 要件定義とそれ以降の契約分割は小規模システムでは一般的ではなく、大規模ならばある、という見解と理解いたしました。

いただいたコメントより、開発発注の選定段階で、ある程度要件定義に相当する活動がなされてしまうのも分かります。(見積上の要件定義と捕らえられますね)
確かに、小さいシステムではそれだけで開発に進める可能性もあり、「Web システムにおいては、あまり一般的ではないでしょう。」という言葉の裏づけにもなっています。

本件における要件定義は、次のステップである開発に必要となる要件定義ということになります。ですから竹波の仰る一定規模以上の案件にあたります。

「要件定義後の発注先を別のところにするのが道徳的にはばかられる」というのはなるほどと感じました。ビジネスとしてパートナーに理解が得られるよう配慮したいと思います。

> 要件定義までは無償で働いてもらってますので。
> もしも実装する内容が制作会社の苦手な部分であるとすると、
> まるまる外注することになるので、費用も高くなるかもしれません。
契約分割が前提ならば、無償ではなく要件定義にも対価を支払い、それ以降の開発にも別契約として対価を支払うということになりますね。
実装内容のリスクについては次の開発のステップに連動させるように注意したいと思います。


? ご助言の内容から、契約分割の場合、要件定義と開発作業の間のインターフェースが重要ということが分かってきました。ありがとうございます。
要件定義の成果物への要求(要件定義の要件)にも配慮し、案件規模によってはコンサルタントの助言についても検討したいと思います。

参考にいたします。

伊藤 友紀

伊藤 友紀
ITコンサルタント

- good

メリット、デメリットを明確に意識して契約を

2009/02/01 11:03 詳細リンク
(5.0)

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

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

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

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

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

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

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

評価・お礼

mtさん

日曜日のご対応、恐縮に存じます。

? 具体例を挙げていただきまして、非常に心強く思います。このような情報を基に、説得力をもって説明できるのでありがたく思います。官公庁ではメジャーなのですね。

? 伊藤様に示していただいた、分割例を拝見すると非常に妥当と感じるものがあり、参考になります。
> ・用件定義(いわゆるコンサル)
> ・設計
> ・詳細設計および実装

契約分割に伴う、計画と実装の差異の問題に関する実例は興味深いです。
また、同一業者における契約分割はかなり有力と感じました。

注意点も分かり、大変参考になりました。
ありがとうございました。

岡本 興一

岡本 興一
ITコンサルタント

- good

経済産業省は分割を推奨しています

2009/02/02 10:32 詳細リンク
(5.0)

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

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

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

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

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

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

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

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


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

評価・お礼

mtさん

(1) 契約分割がどの程度一般的なのか
始めは、それほど普及しておらず、社内で提案すべきかどうかと思っていましたが、助言をいただき、むしろ推進すべき方法と考えるようになってきました。


(2) 契約分割の仕方
ご提供いただいた具体的情報を参考に、よくよく吟味しようと思います。

大変助かりました。
ありがとうございました。

上原 正吉

上原 正吉
Webプロデューサー

- good

会社のプロダクトに縛られない

2009/02/02 14:02 詳細リンク
(3.0)

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

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

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

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

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

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

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

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

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

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

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

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

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

評価・お礼

mtさん

これをきっかけに、約一週間、色々なことが頭を巡りました。

要件定義は要件定義書という成果物を作成するものだとすれば、それが完成した(要件を満たした)という状態を定義しなければならず、客観的基準を作らなければならないと感じました。

上原様のご指摘された例をわたくしがきちんと理解できているか今ひとつ自信ございませんが、セッション管理や利用者環境を要件定義書に適切に盛り込むための基準というのはかなり、難しいと分かります。

上記のようなことを考慮し、要件定義書と、要件定義作業内容を SOW に落とし込み、契約の内容に適切に反映しようと思います。

ご回答をありがとうございました。

(現在のポイント:1pt このQ&Aは、役に立った!

このQ&Aに類似したQ&A

WEBシステムの瑕疵担保期間 norikominekoさん  2009-03-13 11:08 回答3件
セキュリティー上の欠陥について andy3さん  2010-11-18 11:04 回答2件
システム開発のトラブルについて ナオちゃんさん  2009-10-07 03:22 回答4件
システムの改修について タミさん  2009-04-03 10:53 回答3件
専門家に質問する

タイトル必須

(全角30文字)

質問内容必須

(全角1000文字)

カテゴリ必須

ご注意ください

[1]この内容はサイト上に公開されます。

  • ご質問の内容は、回答がついた時点でサイト上に公開されます。
  • 個人や企業を特定できる情報や、他人の権利を侵害するような情報は記載しないでください。

[2]質問には回答がつかないことがあります。

  • 質問の内容や専門家の状況により、回答に時間がかかる場合があります。
気になるキーワードを入力して、必要な情報を検索してください。

表示中のコンテンツに関連する専門家サービスランキング

田川 耕

フードビジネスコンサルタントオフィス シナプス

田川 耕

(飲食店コンサルタント)

メール相談

事業継承、会社売買のお気軽相談

事業継承M&Aコンサルティング

中井 雅祥

株式会社プレスクリエイト

中井 雅祥

(求人とキャリアのコンサルタント)

対面相談

後継者がいない!事業承継安心相談

事業承継に備えて、早めに準備しましょう

大黒たかのり

大手町会計事務所

大黒たかのり

(税理士)

メール相談 ホームページSEO診断
小菅 太郎
(ITコンサルタント)
メール相談 独立、起業、法人成り アドバイス
谷 理恵子
(心理カウンセラー、起業コンサルタント)