法律のひろば /弁護士 莊 美奈子

週末，こんにちは。
当コラム更新につき，大分間隔が空いてしまいました。
その間も，検索等で，当「法律のひろば」にお立ち寄り下さった方々が大勢いらっしゃり，心より感謝申し上げます。
今回は，プログラム開発の受注につきまして，コラムを綴ってみたいと存じます。

プログラム開発に関連する訴訟を複数件担当したことがございますが，その際に多く問題になるのが，
①　そもそもプログラムが完成していない（欠陥，瑕疵がある）ので請負代金を支払う必要が無い。
②　作業工程日数を延期した場合につき，報酬をプログラマーの作業時間単価を乗じて計算している場合，その分を支払う必要があるかどうか（＝この場合，請負＝完成品を納品することにより報酬が発生する契約，というよりも，業務委託・委任＝労務の提供自体に報酬が発生する契約，で問題となります。）
になります（あとは，知的財産権の侵害等ですが，今回は触れません）。

プログラム開発現場では，ある大きなシステムを構築する場合，元々の発注企業が大手企業であっても，その個々のプログラム開発についてはアウトソーシングをし，中小規模の企業が受注，さらに孫請けとして受注する場合が珍しくないようです。

このような場合，大手企業とその直接の受注会社は，大手企業の定型契約書等で詳細に請負内容，あるいは業務委託内容等を取り決めている場合が殆どですが，受注会社がさらにアウトソーシングして，そこがさらに・・となると，契約書が中途半端なものであったり，実際のプログラム開発に具体的に対応していない契約書が形式的に締結されていたり，ということも多々あるようです。

さらに，受注，孫請企業によっては，人件費を抑える意味合いから，単体プログラムの開発については中国等で作業をさせ，統合テスト・総合開発（担体プログラムが仕上がった段階で，大元のシステム自体で稼働するかどうかチェックをしたり，修正したりすること，というざっくばらんな説明で宜しいでしょうか）は発注元で行ったり，という場面も少なくないようです。

このような場合，以下のことに留意頂けたら幸いです。
①　当初の契約段階で，仕様変更が生じた場合の費用関係等についてもしっかり取決めをしておくこと。必要に応じて，弁護士その他専門家のリーガルチェックを受けること。
②　設計仕様書，機能仕様書をやり取りする段階で，発注先，受注先との間で，不明瞭な点，抽象的な点については可能な範囲でしっかりとつめておくこと（当初の段階で）。
③　毎日，業務日報をプログラミング担当者に必ず作成させること。単体プログラム等のテストを行った場合には，そのテスト結果についてもきちんと記録を作成すること。
④　仕様変更が発生した場合，作業現場はどうしても目前のプログラミングの変更に追われますが，必ず，どのような仕様変更が発生したのか，仕様変更により生じる追加費用負担等について発注先，受注先のいずれがもつのかにつき，双方合意の上で確認書面を残しておくこと（この点，口約束になっていて，後日訴訟で，「言った，言わない」の水掛け論になることが多い）。
⑤　テスト段階で，できる限り，発注元の担当者に立ち会って貰い，両当事者で修正個所等の確定作業を行うこと（プログラミングにつき，作業中に修正作業が発生することは避けられないのが一般的です）。
⑥　最終納品段階では，発注元からプログラムの瑕疵なく納品を受けた旨の書面を貰うこと。
以上，一見当然のことでありながら，企業間の力関係から，なかなか整っていないことが珍しくありません。

書面を貰うことが難しければ，発注元との間の電子メールを残しておくことも，十分証拠としての価値がございます。

簡単ながら，ご参考になりましたら幸いです。