アプリ開発では、大なり小なりトラブルがある!と言われています。
ベンダー側とユーザー側で情報が非対称ということもあり「できた、できていない」「これは追加機能だ、いや元々の仕様」だという紛争が後を絶ちません。
そこで今回は、よくあるアプリ開発のトラブルとその対処法、予防策、企業の対策をまとめて解説いたします。
この記事の目次
アプリ開発において、契約はベンダーとユーザーの間で取り交わされる基本的な合意事項です。
この契約がいつ成立するのか、また契約書がない場合にどのように対応すべきかを理解することは、プロジェクトの成功において非常に重要です。
IT企業の経営者にとっては、プロジェクトの円滑な進行や、後々のトラブルを避けるためにも、契約の基礎をしっかりと押さえておく必要があります。
日本の民法では、契約は「申込み」と「承諾」によって成立します。これは、形式的な契約書がなくても、当事者間の合意が成立していれば、法的に契約が成立することを意味します。
アプリ開発の現場では、スケジュールの厳守が求められることが多く、契約書を交わす前に開発作業が始まることが少なくありません。
ここで注意が必要です。契約書がない状態で作業を進めることは、後に大きなリスクを伴う可能性があります。
アプリ開発において、契約がいつ成立するのかという点に基づいた判断が重要です。裁判例を見ると、以下の2つの要素が揃った時点で、契約が成立するとされています。
つまり、ユーザーがベンダーから提示された仕様書や見積書を承認し、発注を行った時点で、契約は成立していると見なされるのです。そのため、たとえ書面による契約書が交わされていなくても、法的には契約が成立していると判断されます。
しかし、注意すべき点があります。例えば、ベンダーが提案書を提出し、ユーザーがベンダーを採用する旨を通知したとしても、その提案書の内容が具体的でなかったり、ユーザーの要求に完全に応えていなかった場合、契約の成立が認められないことがあります。
名古屋地裁平成16年1月28日の判決では、このような事例に基づいて契約の成立が否定されました。
また秘密保持契約や開発基本契約が結ばれていたとしても、具体的な金額や作業範囲が記載された個別契約書や注文書が交わされていない場合、契約の成立が否定される可能性もあります。
東京地裁平成20年7月29日の判決では、まさにこの点が争点となり、裁判所は契約の成立を否定しました。
これらの裁判例から分かるように、契約書が交わされていない場合、裁判所は契約の成立に非常に慎重です。
そのため、アプリ開発を行う際には、契約書の作成が不可欠と言っても過言ではありません。契約書がないままプロジェクトが進行し、トラブルが発生した場合には、開発対象のアプリと報酬額に関する合意があったのかが最大の争点となります。
もし契約書が締結されておらず、契約の成立が認められない場合、ベンダーはユーザーに対して一切の金銭請求ができないのでしょうか? ここで注目すべきなのが「契約締結上の過失の理論」です。
この理論では、契約が成立する直前の段階に至った当事者は、お互いの財産や利益を害しないように配慮する義務を負います。
もしこの義務に違反し、相手方に損害を与えた場合、その損害を賠償しなければならないというものです。具体的には、契約が成立する直前に「やっぱりやめた」といった理由で契約を破棄した場合、相手方に対して損害賠償責任が生じる可能性があります。
例えば、東京地裁平成17年3月24日の判決では、ベンダー企業とユーザー企業がアプリ開発に関して具体的な作業を進め、シミュレーションを実施し、ユーザー企業がベンダー企業に対して内示書の提出を求めた状況が「もうすぐ契約が成立する状態」と認定されました。
このような状態に至った場合、ユーザー企業が契約を一方的に破棄することはできず、損害賠償義務を負うとされています。
この判例からも分かるように、契約書が作成されていないからといって、契約交渉を安易に破棄することは非常に危険です。
万が一、合意に至らない可能性がある場合には、その旨を事前に書面やメールで側に伝えることが重要です。そうすることで、「契約締結上の過失の理論」が適用されるリスクを最小限に抑えることができます。
反対に「契約締結上の過失の理論」が適用されるようにしたい場合には、早い時期に内示書などの提出をを求めるのがよいでしょう。
経営者として、アプリ開発のプロジェクトを進める際には、以下の点に特に注意する必要があります
これらのポイントを押さえておくことで、アプリ開発のプロジェクトを円滑に進め、トラブルを未然に防ぐことができます。
契約書の作成や合意内容の確認を怠らず、プロジェクトの成功に向けて確実なステップを踏むことが大切です。
アプリ開発でトラブルが発生して問題が深刻化し、損害賠償を請求する場合、その範囲はどこまで認められるのでしょうか?
たとえば、ユーザーがベンダーに対して損害賠償を求める場合、以下範囲の損害賠償が考えられます。
ただし、実際に請求できるかどうかは、ケースごとに異なります。特に争点となるのが「2. アプリ開発のために支出した人件費」です。
ユーザー側の人件費は損害賠償の対象になるのか? ユーザー側の人件費に関しては、以下のような問題があります。
したがって、ユーザーが人件費を損害賠償として請求するには、その費用がアプリ開発に直接関係していることを立証しなければなりません。
また、判例では、アプリ開発においてユーザー側にもベンダー側への協力義務があるとされています。
これにより、アプリ開発で自社の従業員が作業を余儀なくされたとしても、その全額を損害賠償として請求するのは難しい場合が多いです。裁判例でも、ユーザーが主張する人件費全額が認められないケースが多いです。
最終的に、ユーザーとしては人件費が「アプリ開発によって発生した」ことを証明する必要がありますし、ベンダー側は「その人件費はアプリ開発によって発生したものではない」と主張することになります。
アプリ開発のプロジェクトが途中で頓挫した場合、特にIT企業の経営者にとって、その後の対応が非常に重要です。
プロジェクトが予定通り進まず、最終的な成果物が納品されない場合、クライアント(ユーザー)は開発を請け負ったベンダーに対して契約解除や費用の返還を求めることが一般的です。
このような場合、ユーザーとベンダーの双方が、どちらに問題があったのかを明確にする必要があります。
例えば、ベンダーが納期を守れなかった場合、必ずしもベンダー側に責任があるとは限りません。
アプリ開発はユーザーとベンダーが共同で進めるプロジェクトであるため、ユーザーの協力不足が原因で進行が遅れることもあります。そのため、プロジェクトが頓挫した理由を明確にし、どちらに帰責性があるかを判断することが重要です。
ユーザーが契約を解除できる範囲についても、慎重に検討する必要があります。
例えば、建築工事のような物理的なプロジェクトでは、一部の作業が完了した後でも、残りの作業部分だけ契約を解除できる場合があります。
アプリ開発の場合、一部が完成していても、他のベンダーがそれを引き継いで完成させることは難しいことが多いです。
そのため、契約解除に際しては、ベンダーの債務不履行か、ユーザーの都合による解除かによって、損害賠償の計算方法が異なる可能性があります。
小規模なアプリ開発プロジェクトでは、各工程ごとに検収を行い、検収が完了した時点で報酬の支払い義務が発生する契約が一般的です。
後続の工程で問題が発生し、契約が解除された場合、既に検収済みの工程まで解除が及ぶのかが問題となることがあります。例えば、東京地裁の判決では、各工程ごとに検収が行われ、引き渡された部分に関しては契約解除の影響を受けないと判断されています。
アプリ開発における紛争では、請求可能な金額や範囲を正確に把握し、それに基づいて適切な対応を取ることが求められます。
具体的には、契約書を詳細に確認し、紛争が発生した際には、どの部分が解除の対象となるのか、どの程度の損害賠償を求めることができるのかを慎重に判断することが重要です。
システム開発が完了すると、次に待ち受けるのがシステムの運用・保守の段階です。
このシステム運用・保守の契約を締結する際には、いくつかの重要な点に注意が必要です。IT企業の経営者として、どのように対応すべきかを理解しておくことで、将来的なトラブルを未然に防ぐことができます。
保守契約を結ぶ際に、よく見られるのが、単に「ベンダーが保守・運用を行う」や「毎月の保守費用がいくら」という内容しか定められていない契約です。
しかし、こうした簡素な契約では、保守業務の具体的な範囲が曖昧なため、トラブルの原因となります。
多くのユーザーは、トラブルが発生すれば、すべての問題をベンダーが解決してくれると期待しますが、実際にはその範囲が契約書に明記されておらず、ベンダー側が対応を拒否することがあります。これを避けるためには、以下の項目を明確にして契約書に記載することが不可欠です。
これらの項目をしっかりと定めることで、双方の誤解を防ぎ、円滑な運用が可能となります。
保守業務の対象として、ソフトウェアのみならずハードウェアも含まれるのか、複数のベンダーが関与したアプリ全体を保守するのかなど、詳細を明確にすることが求められます。
保守の範囲として、以下の業務が含まれるかどうかを確認しておきましょう。
これに加えて、アプリの機能改善や機能追加が保守範囲に含まれるかも確認することが重要です。
アプリ運用・保守業務の条件が詳細にわたる場合、契約書とは別にSLA(サービスレベルアグリーメント)を作成することが一般的です。
SLAとは、Service Level Agreementの略で、ベンダーとユーザーとの間で結ばれる、サービスのレベル(定義、範囲、内容、達成目標等)をどの程度まで保証するかを明示したものです。
この際、上記の内容を詳細に定めることで、ベンダーとユーザー双方の責任範囲を明確にし、トラブルを未然に防ぐことができます。
今回、解説をした対策を講じることで、アプリ開発のプロジェクトを円滑に進め、トラブルを未然に防ぐことができます。
契約書の作成や合意内容の確認を怠らず、プロジェクトの成功に向けて確実なステップを踏むことが大切です。
アプリ開発で実際にトラブルが発生した場合には、まず契約書やSLAを確認し、保守業務の範囲が明確に規定されているかを確認しましょう。契約書がない場合でも、議事録やメールなどが証拠となる場合もあります。
そして、損害賠償を請求する際には、発生した損害を立証できる証拠を準備することが重要となります。
LINEの友達追加で、企業に必要な契約書雛形、