JIRO MAKINO LAW OFFICE
JIRO MAKINO LAW OFFICE

システム開発対策

システム開発トラブル対応策 重点ポイント

弊事務所では、システム開発についての契約等についての法務や訴訟案件を複数取扱っています。

以下に、システム開発で問題となりやすい重点ポイントをまとめてみましたので、これからシステム開発を行う、あるいは行っているユーザやベンダの皆さんの参考にしていただければ幸いです。

 

<これから開発を始めようと思ったら>

・・・まずはユーザの要望を明確に

 

現在の業務をより効率的に迅速に行うために、新たなシステムを導入したい、というご希望と思います。その場合、どの業務のどの部分を効率化したいか、業務全体のフローをどうするのか、適正化・効率化のバランスをどう考えるか、具体的な機能として何が欲しいか、などを綿密に検討する必要があります。ユーザ側がその点を明確にしないと、他人であるベンダには理解できないのです。

そこで、RFPRequest For Proposal)提案依頼書を作ることになります。ユーザの要求事項をまとめ、それに応じたベンダの提案を求めるものであって、ユーザの基本的立場、要望を明示する、とても大切なものです。これが、要件定義や仕様の確定の基礎になります。 

 

RFPができたら、一度外部の人間に見てもらいましょう。業務要件、システム要件、機能面、非機能面の要求が適性に抽出されているか、希望するレベル感が明確になっているか、などを総合的に検討しておく必要があります。できれば中立的な立場の人が良いでしょう。特定ベンダ、特定事業者の関係者ですと、どうしても得意分野に引き込んでしまうことになりますので、注意が必要です。

相談相手が見つからないときは、ぜひ、弊事務所にご相談ください。

 

法律の専門家が、システム開発トラブルにおける裁判の経験に基づき判断します。また、システム構築の経験の豊かな専門家にも参加してもらい、しっかり吟味します。

 


契約をしようと思ったら>

・・・ベンダもユーザも合意内容をしっかり精査

 

RFPが完成したら、これを複数の開発会社、いわゆるベンダに提供して、提案を求めることになります。これに対して、ベンダ側からは「提案書」が提出されることになります。

ユーザはその内容を検討し、そのベンダに開発を依頼するか検討することになります。

ところが、開発を依頼するといっても、作業内容は、要件定義、設計、開発(プログラミング)、テストなど複数の工程を経ることになります。この工程ごとに作業を進めるのか(いわゆるウォーターフォール型開発)、それとも、一部の機能ごとに開発を進めるのか(いわゆるスパイラルアップ型開発)など、開発方法の検討も必要です。また、既存のパッケージを利用するのか(パッケージベース・アプローチ)、一から開発するのか(カスタマイズベース・アプローチ)の判断も必要でしょう。その上、開発してもらう範囲等も確定しなければなりません。

初めて開発を経験することが多いユーザには、こうした作業は大変困難なものでしょう。

また、さらにユーザは、ベンダが本当に、そのような作業を行うことが可能なのか、実現可能性が高いのか、なども検討しなければならないでしょう。

こうした時、ユーザはベンダの提供する契約書を鵜呑みにしてしまい、ベンダのぺースに載せられる危険があり、また、ベンダはユーザの希望が膨らむため、どの様に契約に盛り込むか困惑することが多いはずです。

契約はできるだけ実情に沿って、やるべきことを明確にして、時期もしっかり定めて置く必要がありますが、その作成には法的要素が多いため、十分注意する必要があります。

 

この段階では、システムの知識と共に、法律の知識が必須となります。ベンダの場合はシステムの知識は豊富ですが、ユーザとの合意形成、条件設定など法的検討が弱くなります。ユーザの場合は、法律もシステムもよくわからないということもあり、丸投げの危険があります。ボタンのかけ違いや、言った言わないといったトラブルが発生する前に、争いを未然に防ぐ対策が必要なのです。弊事務所は、システム開発トラブルを未然に防ぐべく、契約締結段階からアドバイスをさせて頂いております。ぜひ、弊事務所にご連絡下さい。


<おかしいと思ったら>

・・・ ベンダとユーザで方向性を共有

 

契約を締結しシステム開発作業を開始したのだけれど、なんだかおかしい、違和感がある、ということがあります。ベンダ側であれば、いつまでたってもユーザの要求が止まらないなどといったことがあります。ユーザ側であれば、ベンダが必要なヒアリングをしていない、業務を理解しようとしないなどといったことがあります。そのような場合は、論点整理、交通整理、方向性の確認、スケジュール感の調整などが必要となります。

違和感があると思ったことは重要で、それを放置していると、違和感が乖離現象へと広がり、深刻化して後戻りできなくなります。おかしい、と思ったらすぐに手を打ちましょう。

 

 論点整理、交通整理をするためには、安全、確実なシステム開発に向けた方向性を検討することが必要です。ただ、正確な分析のためには、それまでの開発開始の経緯、合意などについての詳細な資料が必要となります。それらを集めて相談しましょう。おかしいと思ったら、弊事務所にご相談ください。

システム開発トラブルの対応経験の豊かな弁護士と、システム構築の経験の豊かな専門家が協力して、対応いたします。


<意見が食い違ったら>

・・・合意内容を検討して、相手方と交渉

 

開発に着手したが、合意したはずの内容と異なる話が出てきた、といった場合には、すでにボタンのかけ違いが発生している危険性があります。ベンダ側であれば、当初の合意と異なる作業まで要求されているなどがあります。ユーザ側であれば、ベンダにこの機能は開発範囲ではないと言われたなどがあるでしょう。契約・合意の内容、開発対象の範囲や深さ、サービスレベルなどについての食い違いが生まれているかもしれません。こうした食い違いは、今後、重大な障害となる危険があるので、早期に発見し対応すべきでしょう。

 

 契約に専門家である弁護士、それもシステムトラブルの訴訟の経験があり、契約書の重要性を理解した弁護士と、システム構築の経験が豊かな専門家によって、契約、合意内容を明確にして、合意内容の検証を行い、必要な場合には相手方と交渉を行い、契約内容の明確化や、修正などを実施することが必要となります。そうした場合には、ぜひ、弊事務所にご一報ください。


<トラブルと思ったら>

・・・ 開発業務の解消、場合によっては法的措置も検討

 

開発が頓挫した、ベンダとユーザの意見の食い違いが明確になり、開発がスムーズに進まなくなったといったような場合には、開発業務の解消・精算になるのか、仕切り直しの可能性があるのか、を検討する必要があります。開発業務が解消となれば、それまでの費用はどうするのかなど、非常に難しい問題を解決しなければならなくなります。また、訴訟に踏み切った場合、いずれの立場にも敗訴の危険もある上、十分な賠償が得られるという補償はありません。そうした現実から、開発を継続する方向を徹底して模索することも必要です。すでにベンダ側とユーザ側の溝は大きくなってしまっていることが多いことから、訴訟になることも念頭に入れて対応する必要があります。

 

この段階となったら、ベンダ側、ユーザ側ともに、開発業務を解消するメリット・デメリット、今後発生すると考えられるリスク等を慎重に検討する必要があります。ベンダ側、ユーザ側で意見が対立することが一番多く見られる場面です。そのため、裁判も見据えて、今後の対応を検討することもあります。裁判となった場合、また、裁判とはなっていないが、なる可能性が十分考えられるような場合には、裁判を遂行できるだけの証拠がそろっているのかなど法律的な観点からの検討が必要です。

弊事務所は大型の開発トラブルの訴訟を多数抱える他、さまざまな事案での経験値を重ねております。ぜひ、弊事務所にご相談下さい。