/スマホ/詳しい内容を見る新規会員登録パスワードを忘れたら注目のQ&Aランキング対象:システム開発・導入システム開発、仕様書についてについて。システム開発における要件定義と、要件定義後の契約を分割することはどの程度一般的なのでしょうか?システム開発の案件は要件定義から稼動後のサポートまでを範囲として契約したほうが事務的には楽だと思いますが、ある程度複雑なシステムにおいては要件定義を行わずに全体の金額を算出するのは困難だと考えられますので、要件定義作業と、それ以後の作業の契約を分けて、別ものにするという考え方があると思います。発注側から見て:・要件定義についてはシステムコンサルタントなどの会社に任せ、開発は開発会社に任せるなど、適任と思える会社に依頼が出来ると思います。・要件定義がしっかり終わっていれば、開発作業の見積精度が上がり、リスクがそれだけ省かれますから開発コストを抑えられると思います。・見積に必要な材料が揃っているならば、それぞれの作業に別会社が参入しやすくなるので、相見積をとり易く、業者選定がしやすくなります。受注時のリスクが小さく、見積の根拠も説明しやすくなります。趣旨ご理解の上、特色あるご回答をいただければ幸いです。私の書いた雑誌の記事をご覧頂けたのでしょうか?(もしそうでしたら非常に有難い事です)この方法はまだまだ一般的にはなってないと思います。理にかなった方法を模索した結果ようやく辿りついた方法だからです。業務要件の分析やパッケージとの適合性、カスタマイズ費用の見積り等を行います。業務システム導入での失敗は会社経営に大打撃を与え、安易な導入はできないからこのように進めるのです。このように「どうしても発注者にマッチしたシステムを提供しなければならない」という状況下で突き詰めて考えると必然的に同じ様な方法を取らざるを得ません。統計的に現在の一括契約が危険である以上改善しなければならないはずです。発注者・請負側から見たメリットについてはご理解の通りです。補足しますと2の事務的な負担はトータルではあまり増えません。いうのも今までの方法では、開発見積りは要件定義の前に作られますので内容の確認や費用交渉に時間がかかり、見積再作成と再確認を何度も行う必要が出てきます。見積は発注者にも内容がわかっていることから不安なくすぐに通せる場合が多く、契約関連の作業負担や時間を驚くほど削減できます。いった事から、今までこの方法で進めた中でデメリットといえる点が正直見当たりません。大きな開発会社では営業から社内稟議等の流れや組織体系を簡単に変えられない弱点がありますので、大きな会社でこの方法を導入しようとししても残念ながら当分先の話しになると思います。この方法が広まり、発注者と開発者の双方がより良い結果を得る助けになれば嬉しい限りです(^^)評価・お礼mtさん遅い時間にご回答いただきまして恐縮です。契約分割はあまりメジャーではないという見解でいらっしゃるのですね。そのような数字を得ることは難しいのでしょうね。それでも、こうした方法で業務を推進することに抵抗を感じる必要はないことは分かりました。何分割するのが適当かということを求めたかったのですが、濱田様が仰るように、要件定義とそれ以降の作業契約分割自体も浸透していないとなると、あまりバリエーションがないのかもしれないですね。ITコンサルタント)代表取締役この専門家に相談する090-6002-4611※お電話の際は「"プロファイル"を見た」とお伝え下さい。「金をかけたのに使えない」これらはシステムを導入した企業からよく聞かれる言葉です。致命的な問題を回避し、高いパフォーマンスが得られるシステムを導入できる手法を書籍でも紹介しています。お陰様で高い評価とご満足を頂いております。質問やお悩みは解決しましたか?解決していなければ...※あなたの疑問に専門家が回答します。質問の投稿と閲覧は全て無料です。詳細リンク(3.0)バンブーウエイブです。長くシステム開発をしていた経歴とWEBシステム開発の実務をこなしている立場から個人的に感じることをご回答いたします。>どの程度一般的なのでしょうか?WEBシステムにおいては、あまり一般的ではないでしょう。大規模なシステム開発ではよくありますが。通常は、ひいきにしている制作会社さんにそれとなく話をしているうちになんとなく要件が出来上がっていくものでしょう。その後実際の制作が始まる際に、制作会社は作業員や外注先を確保して正式に見積もりし、最終的に工期が設定され、開発がスタートする。いう、感じかと思います。このケースのデメリットは、要件定義後の発注先を別のところにするのが道徳的にはばかられる点でしょう。要件定義までは無償で働いてもらってますので。実装する内容が制作会社の苦手な部分であるとすると、まるまる外注することになるので、費用も高くなるかもしれません。**ブレインの起用>それをらを考慮すると、どのような分割の仕方をするのがお勧めでしょうか?要件定義だけをコンサルティングしてもらうとなると、それなりに高いものになるかと思います。見栄えのする資料やプレゼンをもって来るかと思いますが。コンセプトは面白いが、実装が困難みたいな提案もあるかもしれません。弊社でお勧めするのは、要件定義やシステム開発に精通したコンサルティングをブレインとして抱えることです。要件定義の段階からブレインに相談し、発注は公募で募り、ブレインはプロジェクト全体の管理をするというものです。稼働にもよりますが、ランニングでの契約になりますので、それほど高額にはならないはずです。全体に携わるので責任感もあり、制作会社とのよい仲介役として活躍してくれるはずです。ご参考になれば幸いです。ホームページ制作・WEBコンサルティングのバンブーウエイブ評価・お礼mtさん日曜日のご対応ありがとうございます。要件定義とそれ以降の契約分割は小規模システムでは一般的ではなく、大規模ならばある、という見解と理解いたしました。いただいたコメントより、開発発注の選定段階で、ある程度要件定義に相当する活動がなされてしまうのも分かります。システムにおいては、あまり一般的ではないでしょう。」という言葉の裏づけにもなっています。本件における要件定義は、次のステップである開発に必要となる要件定義ということになります。竹波の仰る一定規模以上の案件にあたります。「要件定義後の発注先を別のところにするのが道徳的にはばかられる」というのはなるほどと感じました。ビジネスとしてパートナーに理解が得られるよう配慮したいと思います。要件定義までは無償で働いてもらってますので。外注することになるので、費用も高くなるかもしれません。契約分割が前提ならば、無償ではなく要件定義にも対価を支払い、それ以降の開発にも別契約として対価を支払うということになりますね。実装内容のリスクについては次の開発のステップに連動させるように注意したいと思います。ご助言の内容から、契約分割の場合、要件定義と開発作業の間のインターフェースが重要ということが分かってきました。ありがとうございます。要件定義の成果物への要求(要件定義の要件)にも配慮し、案件規模によってはコンサルタントの助言についても検討したいと思います。詳細リンク(5.0)コードワークス株式会社の伊藤と申します。要件定義とその後の作業を切り分けて、別の契約で行うということは、地方公共団体(県、国なども)の仕事などでそこそこの規模になると行っている例があります。程度に分割する場合が多いようです。このように分けているかと役所の人に聞きますと、全部一緒に発注すると、それぞれの費用案分が明確でなくなること、あと無駄な用件定義をされて結局無駄な実装をして無駄なお金を使うことを防ぐため、との話を聞いたことがあります。(入札という仕組みの問題も絡んでいるようですが)分割契約を行い、かつそれぞれ別の業者さんが入られるのであれば、上記の役所の人が言うとおり、無駄をなくすことや、費用についての明確化という点で大きな利点があるかと思います。用件定義した内容がきちんと、設計、実装側に伝わらずに当初の計画とずれた成果物ができてしまうという危険性がありますので、発注側は要注意です。当社の経験では要件定義側で入った案件で、実際に他の業者さんの成果物を見に行ったら、当初の目的と違ってない???という思うものがありました。同一業者さん内で契約を分割していくのであれば、メリットは双方あるかと思います。発注側も受注側も、細かくお金を動かせるのでリスクを減らせること、計画の遂行が契約単位になるので、それぞれの段階でミス、考えの変化、市場動向の変化などなどさまざまな要因に強いプロジェクトとなること、などです。営業的・経理的には面倒ですが、双方ともにそれ以上のリスク分散効果が期待できると思います。ご参考になりましたら、幸いでございます。評価・お礼mtさん日曜日のご対応、恐縮に存じます。具体例を挙げていただきまして、非常に心強く思います。このような情報を基に、説得力をもって説明できるのでありがたく思います。官公庁ではメジャーなのですね。伊藤様に示していただいた、分割例を拝見すると非常に妥当と感じるものがあり、参考になります。契約分割に伴う、計画と実装の差異の問題に関する実例は興味深いです。同一業者における契約分割はかなり有力と感じました。注意点も分かり、大変参考になりました。ありがとうございました。詳細リンク(3.0)こんにちは。ホロデックスの村本です。契約形態はさておき、ウォータフロー型の開発手法をとるプロジェクトでは、行われてきました。け新規大規模システムでは、多いように思います。現在では、このようなプロジェクト案件もすくなくなり、小規模でスタートし、現場の意見や運用形態と連携し、改修しながらシステムを構築していく案件が多くなりましたので、契約分割するようなケースも少なくなってきたのではないかと存じます。・システムサポート・運用指導&体制作り<だと思います。***この分担形態を上手にプロジェクトをすすめるノウハウが発注者側にできれば、様々なプロジェクトにおいて、IT資産(システム、人材、トレーニング)の再活用も可能になるでしょう。前に述べましたように、あくまで*発注者側が請負会社を選ぶノウハウとプロジェクト規模により、使いわけるべきだと思います。評価・お礼mtさん日曜日のご対応、ありがとうございます。予想以上に契約分割がメジャーであることが分かりました。ウォーターフォール型の案件が減ってきているというのは意外でした。経験上、スパイラルモデルやアジャイル開発という形態をとっている案件というのは、ほとんど聞いたことがなく、一件例外があったのみでした。専門家に聞いてみるものです。契約分割ポイントの例示をありがとうございました。最後の、「運用指導&体制作り」を分けているのが特徴的に思いました。クトにおいて、IT資産(システム、人材、トレーニング)の再活用も可能になるでしょう。念頭におき、業務に活かしたいと思います。ありがとうございました。詳細リンク(5.0)分割発注は発注者側の能力や手間必要となることから、大手企業や官公庁では推進されていても、中小企業ではなかなか普及していなかったと言えます。構想を表明し、そのために様々な施策をとってきました。そこで、中小企業を管轄する経済産業省では、中小企業のIT化推進のためには、中小企業経営と、IT開発者との橋渡し役が必要であると認識から、ITコーディネータと言う資格制度を立ちあげました。他の専門家の方がおっしゃっておられるブレイン役です。ITコーディネータ協会や、経済産業省は、分割発注の方が発注者側にとっても、開発者側にとってもメリットがある方法であるとして、推奨しています。プロセスガイドラインというものがありますが、その中でもシステム開発のプロセスを分解し、ケースバイケースではありますが、分割発注することを推奨しています。実際、ここ数年で中小企業のシステム開発でも分割発注の事例が増えています。その際、以下の資料は参考になると思います。発注者ビューガイドラインこれらのツールを利用しながら、分割発注をされることもよいと思います。ご参考になれば幸いです。契約分割がどの程度一般的なのか始めは、それほど普及しておらず、社内で提案すべきかどうかと思っていましたが、助言をいただき、むしろ推進すべき方法と考えるようになってきました。契約分割の仕方ご提供いただいた具体的情報を参考に、よくよく吟味しようと思います。ありがとうございました。詳細リンク(3.0)通常開発会社は、「自分の会社で得意な物」を提案します。これは当然だと思います。現在の時流でみたときにどうでしょうか?将来的に拡張性があるのでしょうか?提案だけの会社をえらんだ場合、そのしがらみから離れて本当に必要なプロダクトを提案してもらえる可能性があります。他の方がおっしゃっている通り、小さなプロジェクトでは、あまり見受けません、と言うのは、「本当に色々わかっている人間」は高いからです。開発費に対してコンサルティング費用がかさんでしまうためです。(120万/月-160/月平均、それ以上もある)ただし、安くて、いいコンサルさんがいる事も確かです。見る目を養うのも重要です。皆さんおっしゃるように特段変わった契約ではありません。「責任範囲」はどこまでかを明確にしておく必要があります。「正しいメールアドレスを入力させる」と要件定義であった場合、その曖昧な仕様を、正しい要件定義に昇華できるのは、かなりレベルの高い開発会社さんです。(極端な例ですが)「データーを送る前にIEのブラウザの更新ボタンを押し、その後URLをFireFoxにはりつけて送信ボタンをおし、すぐにキャンセルを押した後IEで送信をおしても問題なく動作する事(Firefoxでは不正な処理となり、IEでは、既にデーターが登録されていますと出ないこと)」という要求がなければ、要求定義したほうが悪いのでしょうか?それとも、常識的な対応ができない開発会社がわるいのでしょうか。(どこまでが常識?)上の文がFireFoxではなく、別のブラウザに対応しないのは、書いていないからOKでしょうか、その場合コストの関係も考えず、「全て」のブラウザに対応することと、書く要求定義が正しいのでしょうか?こういったトラブルを未然に防ぐルールを考えておく必要があります。評価・お礼mtさんこれをきっかけに、約一週間、色々なことが頭を巡りました。要件定義は要件定義書という成果物を作成するものだとすれば、それが完成した(要件を満たした)という状態を定義しなければならず、客観的基準を作らなければならないと感じました。上原様のご指摘された例をわたくしがきちんと理解できているか今ひとつ自信ございませんが、セッション管理や利用者環境を要件定義書に適切に盛り込むための基準というのはかなり、難しいと分かります。落とし込み、契約の内容に適切に反映しようと思います。ご回答をありがとうございました。選択してくださいご注意ください[1]この内容はサイト上に公開されます。ご質問の内容は、回答がついた時点でサイト上に公開されます。個人や企業を特定できる情報や、他人の権利を侵害するような情報は記載しないでください。[2]質問には回答がつかないことがあります。質問の内容や専門家の状況により、回答に時間がかかる場合があります。写真から気になるキーワードを入力して、必要な情報を検索してください。あなたの事業に「現役・事業のプロ」のナレッジを。