SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

EnterpriseZine編集部ではイベントを随時開催しております

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

紛争事例に学ぶ、ITユーザの心得

民法改正で変わるITの請負開発


 この記事を読まれているような読者の皆さんであれば、IT開発をベンダに依頼するとき、その多くが「請負契約」であることをご存じかも知れません。(もちろん、知っていなくても、この記事を読むことはできますので、ご安心ください。)

本連載がセミナーになります! 
■■■民法改正!判例に学ぶIT導入改善講座―失敗しないプロジェクトの掟■■■ 
主催:翔泳社 2017年12月7日(木) 19:00~21:00 @ベルサール九段   
詳細・お申込みはこちら→ http://event.shoeisha.jp/seminar/20171207/

請負契約の責任

 「請負契約」というのは、受注者が仕事の ”完成” を請け負う契約形態で、発注者に代わって行った作業に対して費用を支払う「準委任契約」とは、その責任や、報酬支払いの対象となる成果物が異なります。IT開発で言えば、発注者に変わって要件定義書や設計書を作りさえすれば (もちろん、どんないい加減なモノを作っても構わないとはなりませんが)、 受注者は、その作業に応じた報酬を請求できるのが「準委任契約」であるのに対し「請負契約」では、設計書やプログラムあるいはシステム全体が発注者の希望を満たすものであること、契約の目的に資するものであることが求められます。その成果物を作るのに受注者がどれほど時間と工数をかけようと(あるいは、かけまいと)、成果物が9割方できていようと、契約した成果物を、納期とコストを守って作らないと報酬の請求ができないのが原則です。

民法改正による「請負契約」の変化

 ところがここに来て、その考えを大きく変えなければならない民法の改正がなされる気配になってきました。請負契約関連の改正を含むその法案は、2017年度の国会で可決され、2019年頃に施行される見込みのようです。 ..

 請負契約の何が変わるのか。簡単に言えばシステム全体が完成しない場合でも受注者は、そこまでに作った成果物 (要件定義書、設計書、プログラム等) に応じて、報酬を請求できる可能性が出てきました。発注者から見ると、契約ではシステムを完成してくれる筈だったのに、なんらかの理由で作業が設計段階で止まってしまい、そのまま契約が解除となった場合でも、ユーザ側に一定の支払い義務が発生する。そんな解釈ができる条文が第634条に書き込まれました。ちょっと見てみましょう。

注文者が受ける利益の割合に応じた報酬

 <第六百三十四条>

 次に掲げる場合において、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。

 一 注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。

 二 請負が仕事の完成前に解除されたとき。

 この条文を見ると、ベンダが「仕事の結果のうち可分な部分の給付」を行って、それが「注文者の利益」になるなら、その分の報酬を請求できると言っています。全部を完成させなくても費用の請求ができる訳です。しかも、この条文は、発注者に非がなく、契約が解除されたときに適用されると書いてあります。要件定義からテストまで全行程をやってくれる筈だったベンダが、ユーザに非はないのに仕事を要件定義だけで止めてしまっても、要件定義書自体が役に立つものなら、その分の報酬を請求されるということになります。

 もしかしたら、IT開発の経験がない方からすると、この考え方も、ある程度仕方ないと思われるかもしれません。元ベンダが置いておいていった要件定義書を元に別のベンダが作ってくれるなら、結果としてシステムは出来上がるのでは?との考えもあるでしょう。確かに、そのように綺麗に行く場合もない訳ではありません。しかし多くの場合、ことは、そう簡単ではありません。元ベンダの作った要件定義書を他のベンダに見せた場合、まずは、それを正しく理解してもらう為には、それなりの時間と工数が必要になります。ただ、読んで理解するにも苦労をしますが、そもそも、自分で後続の工程を実施しようとした元ベンダの作った要件定義書は言葉の定義が足りなかったり、理解するのに前提知識が必要だったり、あるいは、「自分たちが作るんだから、書かなくてもいいや。」と割愛した部分があり、なかなか理解できないのです。まして、その記述に誤りがあれば、新しいベンダとユーザの苦労は並大抵ではありません。

 これが設計書になると、さらに苦労がまします。設計書は、ユーザの目を意識せずに書く部分もあり、自分たちの知識レベルに合わせて書きますから、元ベンダにしか分からない書き方が強くなります。プログラムに至っては、きっと、最初から自分たちで作った方が早いと、新ベンダも言うことでしょう。ITの世界では、途中までの成果物を引き継ぐのは大変な作業ですし、新しいベンダを探して契約する期間も無視できません。そうした意味で、今回の改正は発注者にとって、ややリスクをはらんだものと言えるのかも知れません。

次のページ
今までもあった「部分的な検収」の考え方

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
紛争事例に学ぶ、ITユーザの心得連載記事一覧

もっと読む

この記事の著者

細川義洋(ホソカワヨシヒロ)

ITプロセスコンサルタント東京地方裁判所 民事調停委員 IT専門委員1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より20...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/8439 2017/11/08 16:47

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング