【連載】失敗しないシステム開発マニュアル/月刊IM（JIIMA 公益社団法人日本文書情報マネジメント協会 発行）
「月刊IM」は、JIIMA（公益社団法人日本文書情報マネジメント協会）ホームページにおいて、無料でご覧いただくことができます。
システム開発相談会（無料）開催 受付終了
システム・ソフトウェア開発は企業にとって大変重要な業務なのですが、現実にはあまりにも多くのケースで失敗が繰り返されているのが現状です。
システム開発の失敗の原因は様々ですが、その原因を丹念に検討し、成功に導くのがシステム開発担当者の責務となります。その責務を自覚し、対応するには丁寧なリスクの洗い出しとその対応を実施することです。
弊事務所は、システム開発の最初の段階から完全稼働に至るまで、どのようなリスクのあるのか、御社の開発事例のリスクを洗い出し、そのリスクに対する最良の解決策を提示するようにします。
我々は、開発チーム、システムエンジニア、ITコーディネーターなどの専門家と連携して、問題の解決に向けて検討を重ねて来ており、その経験に基づいて、今回の相談会においても柔軟な対応を見出してまいります。
ぜひ、この機会に、ご相談ください。
例えば、
〇 契約書が提示されたが、よくわからない。問題点がな いか、見てほしい。
〇 契約書がなくて、発注書しかないが、進めていいのか 心配だ。
〇 契約しようと思うが、どんな点に気を付けたらいいの か。
〇 希望と違う開発になっているような気がする。どうし たらいいか。
〇 次々と費用が請求され、開発費が膨らんできている、 どうしようか、大丈夫だろうか。
〇 当初予定していた機能が入らないという。困った、どうしたらいいのか。
〇 ユーザーの要望が次々と変化し、翻弄されている。どうしたらいいか。
〇 開発要望が膨らんできて、工数が増加するが、納得してもらえない。
〇 開発がとん挫した。もうだめだ。どうしたらいいのか。
〇 中途半端なものが納入された。これでは業務ができない。どうしたらいいか。
などの疑問が寄せられています。
それぞれのケースで異なる事情がありますので、それらの事情をお聞きして、最良の方法を検討してみましょう。
どんな些細なことでもご相談ください。
【お申込み・お問合せ】
お申込みやお問い合わせは電話（03-6273-4445）にてお願いいたします。
ご予約は先着順に承ります。ご相談日の一週間前までにご予約ください。
ご注意）
○相談に際しては、口頭のご説明だけでは分からないことが多いので、関係資料（RFP、提案書、契約書、要件定義書、議事録、メールのやり取りなど）をご持参ください。
弁護士法上の守秘義務がございます。秘密は厳守いたしますのでご安心ください。
○今回のご相談はすべて無料です。相談により問題解決しても一切の費用はかかりません。
○ご相談後の、診断、訴訟判断、訴訟受任等は、別途ご相談となります。
牧野二郎弁護士から一言
オリンピックを控えて、システム開発が進む中、トラブルも急増しています。トラブルを抱えたまま、オリンピックを迎えるのは危険です。一日も早い解決を目指しましょう。早期発見、早期治療が大原則です。
システム開発トラブル対策
システム開発トラブル対応策 重点ポイント
弊事務所では、システム開発についての契約等についての法務や訴訟案件を多数取扱ってきました。
以下に、システム開発で問題となりやすい重点ポイントをまとめてみましたので、これからシステム開発を行う、あるいは行っているユーザやベンダの皆さんの参考にしていただければ幸いです。
＜これから開発を始めようと思ったら＞
・・・まずはユーザの要望を明確に
現在の業務をより効率的に迅速に行うために、新たなシステムを導入したい、というご希望と思います。その場合、どの業務のどの部分を効率化したいか、業務全体のフローをどうするのか、適正化・効率化のバランスをどう考えるか、具体的な機能として何が欲しいか、などを綿密に検討する必要があります。ユーザ側がその点を明確にしないと、他人であるベンダには理解できないのです。
そこで、RFP（Request For Proposal）提案依頼書を作ることになります。ユーザの要求事項をまとめ、それに応じたベンダの提案を求めるものであって、ユーザの基本的立場、要望を明示する、とても大切なものです。これが、要件定義や仕様の確定の基礎になります。
⇨
RFPができたら、一度外部の人間に見てもらいましょう。業務要件、システム要件、機能面、非機能面の要求が適性に抽出されているか、希望するレベル感が明確になっているか、などを総合的に検討しておく必要があります。できれば中立的な立場の人が良いでしょう。特定ベンダ、特定事業者の関係者ですと、どうしても得意分野に引き込んでしまうことになりますので、注意が必要です。
相談相手が見つからないときは、ぜひ、弊事務所にご相談ください。
法律の専門家が、システム開発トラブルにおける裁判の経験に基づき判断します。また、システム構築の経験の豊かな専門家にも参加してもらい、しっかり吟味します。
＜契約をしようと思ったら＞
・・・ベンダもユーザも合意内容をしっかり精査
ＲＦＰが完成したら、これを複数の開発会社、いわゆるベンダに提供して、提案を求めることになります。これに対して、ベンダ側からは「提案書」が提出されることになります。
ユーザはその内容を検討し、そのベンダに開発を依頼するか検討することになります。
ところが、開発を依頼するといっても、作業内容は、要件定義、設計、開発（プログラミング）、テストなど複数の工程を経ることになります。この工程ごとに作業を進めるのか（いわゆるウォーターフォール型開発）、それとも、一部の機能ごとに開発を進めるのか（いわゆるスパイラルアップ型開発）など、開発方法の検討も必要です。また、既存のパッケージを利用するのか（パッケージベース・アプローチ）、一から開発するのか（カスタマイズベース・アプローチ）の判断も必要でしょう。その上、開発してもらう範囲等も確定しなければなりません。
初めて開発を経験することが多いユーザには、こうした作業は大変困難なものでしょう。
また、さらにユーザは、ベンダが本当に、そのような作業を行うことが可能なのか、実現可能性が高いのか、なども検討しなければならないでしょう。
こうした時、ユーザはベンダの提供する契約書を鵜呑みにしてしまい、ベンダのぺースに載せられる危険があり、また、ベンダはユーザの希望が膨らむため、どの様に契約に盛り込むか困惑することが多いはずです。
契約はできるだけ実情に沿って、やるべきことを明確にして、時期もしっかり定めて置く必要がありますが、その作成には法的要素が多いため、十分注意する必要があります。
⇨
この段階では、システムの知識と共に、法律の知識が必須となります。ベンダの場合はシステムの知識は豊富ですが、ユーザとの合意形成、条件設定など法的検討が弱くなります。ユーザの場合は、法律もシステムもよくわからないということもあり、丸投げの危険があります。ボタンのかけ違いや、言った言わないといったトラブルが発生する前に、争いを未然に防ぐ対策が必要なのです。弊事務所は、システム開発トラブルを未然に防ぐべく、契約締結段階からアドバイスをさせて頂いております。ぜひ、弊事務所にご連絡下さい。
＜おかしいと思ったら＞
・・・ ベンダとユーザで方向性を共有
契約を締結しシステム開発作業を開始したのだけれど、なんだかおかしい、違和感がある、ということがあります。ベンダ側であれば、いつまでたってもユーザの要求が止まらないなどといったことがあります。ユーザ側であれば、ベンダが必要なヒアリングをしていない、業務を理解しようとしないなどといったことがあります。そのような場合は、論点整理、交通整理、方向性の確認、スケジュール感の調整などが必要となります。
違和感があると思ったことは重要で、それを放置していると、違和感が乖離現象へと広がり、深刻化して後戻りできなくなります。おかしい、と思ったらすぐに手を打ちましょう。
⇨
論点整理、交通整理をするためには、安全、確実なシステム開発に向けた方向性を検討することが必要です。ただ、正確な分析のためには、それまでの開発開始の経緯、合意などについての詳細な資料が必要となります。それらを集めて相談しましょう。おかしいと思ったら、弊事務所にご相談ください。
システム開発トラブルの対応経験の豊かな弁護士と、システム構築の経験の豊かな専門家が協力して、対応いたします。
＜意見が食い違ったら＞
・・・合意内容を検討して、相手方と交渉
開発に着手したが、合意したはずの内容と異なる話が出てきた、といった場合には、すでにボタンのかけ違いが発生している危険性があります。ベンダ側であれば、当初の合意と異なる作業まで要求されているなどがあります。ユーザ側であれば、ベンダにこの機能は開発範囲ではないと言われたなどがあるでしょう。契約・合意の内容、開発対象の範囲や深さ、サービスレベルなどについての食い違いが生まれているかもしれません。こうした食い違いは、今後、重大な障害となる危険があるので、早期に発見し対応すべきでしょう。
⇨
契約に専門家である弁護士、それもシステムトラブルの訴訟の経験があり、契約書の重要性を理解した弁護士と、システム構築の経験が豊かな専門家によって、契約、合意内容を明確にして、合意内容の検証を行い、必要な場合には相手方と交渉を行い、契約内容の明確化や、修正などを実施することが必要となります。そうした場合には、ぜひ、弊事務所にご一報ください。
＜トラブルと思ったら＞
・・・ 開発業務の解消、場合によっては法的措置も検討
開発が頓挫した、ベンダとユーザの意見の食い違いが明確になり、開発がスムーズに進まなくなったといったような場合には、開発業務の解消・精算になるのか、仕切り直しの可能性があるのか、を検討する必要があります。開発業務が解消となれば、それまでの費用はどうするのかなど、非常に難しい問題を解決しなければならなくなります。また、訴訟に踏み切った場合、いずれの立場にも敗訴の危険もある上、十分な賠償が得られるという補償はありません。そうした現実から、開発を継続する方向を徹底して模索することも必要です。すでにベンダ側とユーザ側の溝は大きくなってしまっていることが多いことから、訴訟になることも念頭に入れて対応する必要があります。
⇨
この段階となったら、ベンダ側、ユーザ側ともに、開発業務を解消するメリット・デメリット、今後発生すると考えられるリスク等を慎重に検討する必要があります。ベンダ側、ユーザ側で意見が対立することが一番多く見られる場面です。そのため、裁判も見据えて、今後の対応を検討することもあります。裁判となった場合、また、裁判とはなっていないが、なる可能性が十分考えられるような場合には、裁判を遂行できるだけの証拠がそろっているのかなど法律的な観点からの検討が必要です。
弊事務所は大型の開発トラブルの訴訟を多数抱える他、さまざまな事案での経験値を重ねております。ぜひ、弊事務所にご相談下さい。
