人も自然も輝く未来に

ブログ

2019年2月26日

<システム開発紛争の予防>

今月15日、JIA(日本情報振興協同組合)関西支部で、「システム開発紛争を予防するために」と題して、セミナーをしました。

プロの方々ばかりなので緊張しましたが、幸い、好評をいただけました。

 

システム開発は、法律関係でみると、建築工事に似ています。

システム開発では、建築工事の施主を「ユーザ」、建設業者を「ベンダ」といいます。

法律関係は、システム開発も建築工事も、「請負契約」が基本的です。

「請負契約」の基本的要素は、請負人の「仕事の完成」の義務、と、注文主の「報酬支払」の義務です。

システム開発が紛争になりがちなのは、建築工事と比べて、完成させるべき「仕事」の内容、や、「完成」の有無、が目で見えにくいところにあります。

なので、システム開発を受託(あるいは委託)する場合は、

・先ず、契約の種類が、請負なのか準委任(後で説明します)なのか、確認しましょう。

・次に、請負なら、完成させるべき「仕事」の内容、すなわち、プログラムの機能の範囲や内容、を機能(ファイル)名の一覧や構成図で、きちんと確認しましょう。

・そして、「完成」を認める検査の方法や内容、その時機、をきちんと確認しましょう。

 

裁判例は、「完成」を「最後の工程まで終えている」こととしています(東京地裁平成14年4月22日判決)。これは建築工事など他の請負と同じということです。

また、完成後の「瑕疵」について、バグ程度の不具合があっても遅滞なく補修を終えるなどすれば瑕疵にあたらないとしています(東京地裁平成9年2月18日判決、前掲判例)。

 

元請ベンダが下請ベンダに支援作業を委託した場合に、「仕事の完成」を前提とせず、作業だけなら、「準委任」契約となります。この場合、下請ベンダは、委託された作業量さえこなせば、報酬を請求することができます。

ただ、システム開発の見積もりは、請負であっても、作業量すなわち人日(人月)見積もりなので、区別がつきにくい原因になっています。

特に下請ベンダは、応援作業だけのつもりがプログラムの完成まで求められていた、なんてことのないように注意してくださいね。

 

経産省も、システム開発の契約適正化には問題意識を持っているようで、平成18年頃から研究会を設置して、情報システムモデル取引・契約書を示しています。下記サイトを下にスクロールしていくと、「情報システムの信頼性向上のための取引慣行・契約に関する研究会」~情報システム・モデル取引・契約書~ があります。

http://www.meti.go.jp/policy/it_policy/softseibi/index.html

 

 

もう一つ、システム開発が紛争になりがちな要因は、ベンダにはITやシステム開発の専門知識や技術、経験があっても、システム開発の対象であるユーザの業務については、その専門知識や技術、経験はもっぱらユーザ側に在る、という「偏在」です。

 

ユーザのなかには、システムさえ導入すれば我社の業務も一挙に最先端!という勘違いをしている経営者がいまだにおられるようですが、自社ビル建ててね、だけで建築工事ができるわけはありません。

さらに、システムの導入には、業務自体がアナログ作業でもシステマチック?に整備されていることが必要です。

 

裁判例は、IT専門家であるベンダには「プロジェクトマネジメント義務」が在るとしています。その内容は、専門家として、契約書や提案書で提示した開発手順や開発手法、作業工程に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、適切に対処する「進捗管理・阻害要因対処義務」と、ユーザのシステム開発への関わりについても適切に管理し、専門知識を有しないユーザが開発作業を阻害することのないよう働きかける「発注者管理義務」です(東京地裁平成16年3月10日)。

もちろん、ユーザにも「協力義務」があります。ヒアリングに協力し、機能や画面レイアウト、帳票の出力項目を決めることや、成果物の検収、などです。ユーザがシステム担当(窓口)部門と業務部門に分かれている場合、その意思疎通を図っておくことも必要です。

 

中小企業が生き残る道の一つは、IT化です。

システム導入を、自社の業務内容や業務の流れを見直す契機とするのも一つのやり方です。

ITはあくまで「道具」であって、魔法の万能薬ではありません。

先ずは、周りの知り合いのシステム開発会社さんに、何でも相談してみることから始めてはどうでしょうか?

 

 

 


このページのトップへ


Copyright (c) 2011 赤津法律事務所 ALL Rights Reaserved