システム開発の契約書はここに注意！
先日、こちらの動画に「要件定義は準委任契約で行ったのか？」というコメントを頂きました。
(→【危険】甘く見るとシステム開発で失敗します！要件定義にまつわる本当にあった怖い話3選)
その動画でお話しした開発においては請負契約で行ったのですが、発注者の皆さんからしてみると「開発するITベンダーはどんな基準で請負契約と準委任契約を決めているのか？」という疑問を持たれているのではないだろうかと思いました。
また、発注者の皆さんの悩みごとの一つには、必ずシステム開発予算が含まれているのだと思います。発注者が「できる限り決められた予算内で開発したい。その為には、ブレない見積もりが欲しい」と思うのは当然のことでしょう。
そうなると発注者の心理としては、金額が明確な請負契約にしたいと考えるのは極めて自然なことだと思います。
しかし、受注者であるITベンダー側はそうではありません。できる限り準委任契約にもっていきたいのが本音です。
そこで今回は、
- ITベンダーが準委任契約を提案する本当の理由について
- 請負契約にもちこむ方法とは？
- 請負契約になったからと言って喜んではいけない
この3点について解説いたします。
なお、システム開発における契約についてはこちらの投稿で解説しておりますので、合わせてご覧ください。
→システム開発の契約書はここに注意！
※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。
ITベンダーが準委任契約を提案する本当の理由について
まず、ITベンダーがなぜ準委任契約を提案するのか、その「本当の理由」について説明します。
準委任契約を提案する一番の理由は、ITベンダーがリスクを最小限に抑えたいからです。システム開発は、複雑で予測が難しいプロジェクトが多く、開発の各工程において様々な問題や変更が発生します。こうした予期せぬ事態に対処するには、準委任契約がとても都合がいいのです。
これが準委任契約ではなく請負契約であるならば、問題が発生した際、基本的にはITベンダー側の予算内で解決しなければなりません。もちろん、その問題の原因が発注者側にあるならば追加費用を求めることもできますが、費用の追加というのは多くの場合厳しい交渉になりますので、できる限り避けて通りたいのが本音です。
こうした予期せぬ事態に対処するために、ITベンダーはリスクをできるだけコントロールできる契約形態を選びたいのです。
ITベンダーが準委任契約を締結することで、以下のようなメリットがあります。
① 仕様変更への対応
準委任契約では、プロジェクトの途中で発生する仕様変更や追加要求に対して柔軟に対応できます。請負契約の場合、契約時点で要件が固定されるため、途中での変更が発生し、それが明らかな仕様変更ではない場合(開発側ではグレーな仕様という言い方を用いてます)、ITベンダーがそのコストを全て負担するリスクがあります。しかし準委任契約では、追加の作業が発生すれば、その分だけのコストが請求しやすいため、ITベンダーにとってリスクが軽減されます。
② 不確実性の高いプロジェクト
特に新技術の導入や複雑なシステムの開発では、プロジェクトの進行中に技術的な課題や不確定要素が多くなりがちです。こうした不確実性が高いプロジェクトでは、ITベンダーが見積もりを行う際にリスクを正確に評価することが難しくなります。準委任契約ならば、作業の進捗に応じて支払いを得られるため、予期せぬ問題が発生してもITベンダーのリスクが少なくなります。
③ 見積もりのリスク
請負契約では契約時に見積もりが固定されるため、見積精度が低かった場合、実際発生したコストとの差額はITベンダーが負担することになります。特に、大規模なプロジェクトや要件が固まりきっていない段階での見積もりでは、このリスクが大きくなります。準委任契約ならば、実際にかかった工数や時間に基づいて支払いを得るため、見積もりに対するリスクがほとんどありません。
このように、ITベンダーが準委任契約を提案する背景には、リスクを回避しプロジェクトを柔軟に進めたいという強い意図があります。発注者としては、こうしたITベンダー側のリスクも理解しつつ、契約形態を選択することが重要です。
請負契約にもちこむ方法とは？
発注者が請負契約にしたい理由は、何と言っても予算の明確化です。契約時に費用が確定し、予算内でプロジェクトを完遂できるため、コスト管理がしやすいというメリットがあります。
請負契約に持ち込む方法は、ITベンダー側のリスクを減らしてあげることです。
ITベンダーが準委任契約を提案する一番の理由は、リスクを最小限に抑えたいからと説明しました。ならば、そのリスクを減らすための努力を発注者が行わなければなりません。
それは作るべきシステムが明確になっていること、つまり精度の高い要件が定義できていること。あるいは要件定義の準備がしっかりできていることが重要です。要件が明確であれば、ITベンダーもリスクを適切に見積もることができ、請負契約に応じやすくなります。
要件定義については、これまでも解説してきていますので、ぜひ過去の投稿もご覧ください。
→新規事業向けシステム開発の要件定義の極意 Part1
特に以下の点を注意して、要件定義を行いましょう。
- 要件の具体化: システムが実現すべき機能や性能を具体的に定義し、曖昧な部分をできるだけ排除します。
- 優先順位の設定: 各要件の重要度を明確にし、リソースをどこに集中すべきかを示します。
- リスク管理: 予期し得るリスクとその対応策を事前に検討し、ITベンダーに安心感を与えます。
また、もし可能であれば、プロトタイプやモックアップが準備できれば言う事なしです。(一般的には発注後に行う作業です。社内にデザインに関する部門やそれに長けている人材がいない場合、事前にアウトソースで作成する方法もあります。)これにより、ITベンダーに具体的なイメージを共有でき、見積もりの精度が向上します。さらに、開発中に発生する追加の作業や変更が予想される場合には、事前にその旨を伝え、追加予算や工数を柔軟に管理する姿勢を示すことも大切です。
それと、もう一つ方法があります。それは、開発しようとしているシステムの実績がある、あるいはその分野に長けているITベンダーを探し出すことです。
そのベンダーが作ったシステムとほぼそのままのシステムを作りたいということであれば、ITベンダー側も工数が見積もりやすく、リスクも軽減されますので、請負契約を受け入れやすくなります。こちらの方法の方が手っ取り早いですが、なかなか見つけるのも容易ではないというデメリットもあります。
請負契約になったからと言って喜んではいけない
最後に、請負契約になったからといって単純に喜んではいけない理由について解説します。
請負契約では予算が明確になり、発注者としては安心感がありますが、逆に言えば、契約後の変更が難しくなるというリスクもあります。発注時点で開発する範囲や機能が決まるので、契約時に想定していなかった問題が発生し、機能追加・仕様の大幅な変更が発生した場合、追加費用の受け入れ・納期の見直しなどを行わなければならないことにも繋がります。最悪の場合、プロジェクトが進まなくなることもあります。
そのため請負契約になったとしても、柔軟な対応が必要です。例えばプロジェクト中に発生する問題や変更に対して、発注者としても協力的な姿勢を示し、ITベンダーと共に問題を解決していくことが重要です。
また、請負契約でも進捗管理やコミュニケーションを怠らないことが大切です。定期的なミーティングや進捗報告を通じて、プロジェクトが順調に進んでいるかを確認し、問題が発生した場合には早期に対応できるようにしておきましょう。
まとめ
今回は「ITベンダーが準委任契約を提案する本当の理由」というテーマで投稿しました。準委任契約は、ITベンダーにとって柔軟性が高く、リスクを管理しやすい契約形態ですが、発注者としてはコスト管理が難しくなるという面もあります。そのため、請負契約を希望する場合は、しっかりとした要件定義と柔軟な対応が求められます。
また請負契約になったとしても、プロジェクト中のコミュニケーションや進捗管理を徹底することが、プロジェクトの成功には欠かせません。
予算を明確にする。それはとても重要なことではありますが、裏に隠れるリスクを鑑みたうえで、請負契約に固執せず、ITベンダーに相談しながら、皆さまにとって最適な契約形態を選定してください。
