上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

●トラブルの絶えないシステム開発契約について何点か。


●突然ですが、
取引契約ってさ、
実際のところ作った後は余り見返さない、と。
 そういうことって、
今の実務では結構多いですわね。

 ただ、
そういう実務の中でも、
やたらと後から見返すことになる類いの契約ってのがある。
 その代表的な一つが、
システム開発契約ですわな。

 自分の弁護士人生を振り返っても、
システム開発契約で揉めた案件って結構あるわけで、
大体その作成過程に弁護士がちゃんと関与していないものもかなり多い。

 そんなシステム開発契約ですが、
まぁ後でトラブルにならないようにするために、
やはり何点か勘所があるわけですな。
 本日のツボはそこらあたりを。


●まずは、
一番プリミティブなトラブルなんだけど、
未だになくならない話。

 何かと言うと、
まだ契約も何もしていないのに、
ベンダー側が走り出していたところ、
後でプロジェクト自体が潰れちゃったので、
ユーザーさん、走り出してた分の開発費用を払ってよ、と。

 この事案ってさ、
ユーザー側がそんなに弱い事案ではなくて、
むしろベンダー側が頑張って立証しないといけない事案なんだけどさ。
 そもそもユーザーからすると、
こんなトラブルに付き合わされること自体がイヤよね。
 ちゃんと、
ユーザー側から出す文書ヤメールに注意書きを入れるなどして、
動かぬ証拠を残しておくことが大事。

 「営業の一環としてサービスでやってくれてるんだと思った」

 そんな都合のよい言い訳だけだと、
後でトラブルが長引いちゃう可能性が高いのでね。

 この問題は、
ベンダー側からすると、
営業の観点を含めて非常に悩ましいんだけど、
少なくともユーザーの立場からすると、
ちゃんと気をつけていれば比較的簡単に対処可能のはず。

 もちろん、
ユーザー内の内部決裁が間に合わないとか、
そんな事情から契約書ないままベンダーを走り出させるなんてケースもあるよ。
 その場合、
得てしてユーザー側では、
自らの交渉力が強いことを背景にしてる場合が多いんだけど、
その目論見が外れてトラブルになってるケースもあるのでね。


●それから次。

 これもよくあるのが、
実際に開発を始めた途中で、
開発費用が予想よりも膨らんじゃった、と。
 さて、
どっちが負担すんだ、と。
 当然、
ベンダー側は、
ユーザーさん、ちゃんと払ってよ、と。

 これについては、
ベンダーが泣き寝入りしているケースも結構あるけど、
実際にトラブルになった場合には、
ベンダー側から出されていた見積もりが、
法的拘束力のあるような硬いものだったのかどうか、という問題。

 ここの部分についてはさぁ、
まぁ、弁護士としてもベンダーに同情したくなるような話なんだよねぇ(笑)。

 そもそも、
仕様も何も固まっていない、
プロジェクトの開始段階で、
法的拘束力のあるような硬い見積もりなんて、
ベンダー側で出せるわけがない。
 何をしたらいいのか、
ベンダー側で分からないんだからね。

 なので、
ベンダー側で何をすればいいのかが固まる時点、
要は仕様が固まる時点だよね、
この時点で改めて次工程以降の見積もりについて、
法的拘束力のある形で出してもらうというプロセスを必ず経ること。
(多少幅のある形になったり
 追加費用を許容する余地も残ったりはするけど)
 ユーザーとしては、
(よっぽど交渉力に自信があるとかでない限り)
このプロセスを飛ばしちゃいけない。

 ちなみに、
この仕様が固まる時点というのは、
もっと難しい言葉で言えば、
要件定義の工程と、その次の外部設計の工程までが終了した時点のこと。
 いつもどおりザックリと言ってしまうと、
要件定義ってのは、
そのシステムが何を実現できなきゃならんのかということを決める工程ね、
外部設計ってのは、
主にインターフェイスの作りこみ方を決める工程ね。
 これらについては、
ユーザーの要望に応じて千差万別なんだから、
ここが決まらないとベンダー側で何をすればいいのか分からんわけね。

 もちろん、
要件定義の工程と外部設計の工程までが終了してしまうと、
ユーザー側はこれらの工程を担当したベンダーに対して、
相当程度ロックインされた状態になる。
 つまりは、
次工程以降の作業について、
他のベンダーに乗り換えるということは、
理論的にはともかく実際上はかなり難しいわけね。
 とすると、
そのタイミングにおいて、
初めて確定的な見積もりが出るということだと、
ユーザー側の交渉力が弱まってしまってるわけ。
 なので、
もっと早いタイミングで、
確定的な見積もりを取らないとダメじゃないか、と。
 まぁ、
そういう議論が出てくるわけですな。
 例えば、
要件定義の工程は仕方ないとしても、
外部設計の工程の前にはとっておくべきとか。

 うん、
その問題意識は十分すぎるほど分かるんだけどさぁ、
そうは言っても実際のところ無理でしょ?
 仕様が固まっていない段階で、
ベンダー側でどうやって確度の高いのを出せるのか?
 そんなの本当は不可能だと思うんだよね。
 たとえ要件定義の工程は終わってるとしても、
外部設計の工程の部分で難題が出てくることだってあるんだから、
少しでも前倒しでっていうのも何だかなぁ、と。

 上記の問題意識について、
実際上ユーザー側ができることがあるとすれば、
交渉力が高まっていることを重々承知しているベンダーに対して、
一定の牽制をかけられるようにしておくぐらいかな。
 例えば、
外部設計の工程までについては、
おそらく開発基本契約とかが存在してるはずで、
その開発基本契約の締結にあたっては当初見積もりも出してもらってるはず。
 なので、
開発基本契約において、
①外部設計の工程が終了した段階で改めて
 ベンダーから確定的な見積もりを出してもらうこと、
②確定的な見積もりと当初見積もりとの間で有意な差異が生じた場合には、
 当該差異について合理的な説明を提供すべき義務をベンダーに課すこと
このぐらいはやっておくとかね。
 後は、
ダメ元でも、
相見積もりを取るとかね。

 もちろん、
交渉力に自信のあるユーザーは、
プロジェクト開始当初で見積もりを出させて、
それでもってベンダーに対して最後まで押し通させる、
こういうケースも事実としてはあるよね。
 これで押し通せるのならいいんだけど、
「窮鼠猫を噛む」よろしく、
そのつもりだったのにトラブルになってる事案も結構あるのでね。

 ちなみに、
開発スケジュールについても、
外部設計の工程が終了した段階で、
確定的なコミットをしてもらうべきだね。
 特にお尻がキツい場合はなおさら。


●最後に、
これもよくあるんだけど、
システムの不具合の問題。

 この点については、
まぁ、多くの方がどこかで聞いたことあるかと思いますが、
請負or準委任という論点があるわけね。
 
 確かに、
民法上ではこの二つについて、
仕事完成義務とか瑕疵担保責任とか報酬請求権の発生時期とか、
色々有意な違いはあるわけで、
あるべき姿としては、
外部設計の工程前は準委任、その後は請負でってなるんだけどさ。

 一つ間違っちゃいけないのは、
我々は別に民法の教科書を書いてるわけじゃないわけでね。
 この請負or準委任という法的性質論だけで、
延々と空中戦を繰り返しているような場合もあるんだけど、
所詮は民法を背景とした話なんであって、
最終的には契約に何が書かれているかということに注目しなきゃね。

 要は、
ちゃんとシステムとして動くものが欲しい、
じゃぁ動かなかったらベンダーに何をしてもらいたいのか、
代金はどの部分をどういう条件が整ったら払うことになるのか、
そういうことをちゃんと書き込んでいくということが第一のはず。

 後は、
このシステムの不具合ってのが、
要件定義や外部設計の工程が終了した後になって、
ユーザーが仕様変更を度々お願いしたことに起因する場合も結構ある、
そういうことに思いを致すことも大事よね。
 その他にも、
最近はユーザー側の協力義務違反というのも認定されているので、
ベンダーに全てお任せという姿勢だけでは痛い目を見ちゃうかもね。

 ちなみに、
最近はユーザー主体で開発するという建付けの下、
ベンダーから人を「派遣」する形式も多いみたいだね。
 ただ、
この形式でやろうとすると、
どうしても料金は高くなるという点、
これはユーザーでも認識しておく必要があるのかも。


●この他、
最近クラウド・サービスも増えてきてるんだけど、
これってさ、
不特定多数のユーザーに対する定型サービスの提供って場合も多くて、
その場合には利用契約(というか利用規約)について、
ユーザー側での交渉の余地はさほど無いのでね。

 なので、
契約交渉というよりは、
他の類似サービスとの比較という視点を持ったほうがいいかと。


●本日のツボはここまで。

 このシステム開発の世界というのは、
日進月歩なので弁護士がついていくのも大変ですね。

 多少なりとも新しい技術の世界を理解すべく(?)、
先月あたりからスマートフォンやGoogle+、Facebook、LINEなど、
かなりプリミティブな所から始めてみました(笑)。

 特にスマートフォンについては、

 「ガラケーがあれば良くねぇ?」、と、

ちょっと引いてた時期もありましたが、
実際に持ってみると、もうガラケーには戻れないような。
 
 後は、
LINEも結構使えますね。
 家族との遠隔コミュニケーションは、
専らLINEで済ませるようになりました。
 「電子メールがそのうち消える」説ってのも、
本当にそう遠くない話かもなぁと実感しました。
 ただ、
新しいスタンプが出ると無駄に買いたくなってしまうのが、
難点といえば難点…。


(2013年5月1日記)
関連記事
Secret

TrackBackURL
→http://bookaholiclawyer.blog18.fc2.com/tb.php/122-461a0d93
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。