制作会社との納品後トラブル

質問

お世話になります。

WEB制作会社にあるサイトの作成を依頼して、
納品物を見て完成したと思い入金をしました。

入金は3回に分けて行っていました。
１．着手金
２．中間支払い
３．納品月翌月払い

全て支払ってしまった自分が悪い部分もあるかとは思うのですが、
実際に納品後に色々とチェックをしていたらおかしなバグがあったり、
仕様的にどう考えてもおかしい箇所があったりしています。

バグについては、調査の上バグかどうか、バグであれば大体どの位で
修正ができるのかを追って報告しますということなのですが、なかなか
その結果報告もきていません。

仕様的におかしいと思われる箇所については、いや、それはお互いに合意をしているはずだ、
事前に画面遷移書で確認をしていますよね、という話をされてしまいます。
例えば大手サイトでは実装されているようなエラーや入力データのチェックなども
抜けておちていたりします。

細かいそこまでの設計部分で話し合いをしていないのですが、
これは話し合いがなかったということで向こうは突っぱねられるものなのでしょうか？

また、設計書や仕様書が無く、たびたびの機能修正や追加などもあり、
現状の仕様や設計を把握するのも一苦労です。

契約では、確かに設計書や仕様書といったものを納入するという記載は無いのですが、
もちろん設計自体やテスト、開発などといった部分は記載されています。

設計書が無くても設計をするというのが普通で、その場合は提出義務も無いのでしょうか？
仕様書が無くても、これを追加して欲しい、これを修正して欲しい、そういった要望と、
それに対した答えがあるのみで、あとは初期に作成した今はあまり原型を留めていない
画面遷移書だけですが、これはあくまで契約書に記載が無いというだけで
契約違反にはならず、こちらが我慢をしなければならないのでしょうか？

結論として、別に返金を求めたいわけではなく、より完全な形での納入と、
追加開発を行うため、設計書や仕様書が無いと相手先の業者しかまともにいじれない状況を
改善したく思っています。

相手に色々話しをしても、保守契約を結んでいないので、通常は納入後は
対応ができないという話をされてしまいます。

もちろんこちらの至らないところが多いとは思うのですが、
お金を払っているこちら側の立場がものすごく弱く感じてしまいます。

どうしたらよろしいでしょうか？
よろしくお願い致します。

回答No.6

oioi_douda

まともにいくなら仕様書ができた段階でクライアント側がチェックして
判子なりサインなりしてその仕様が間違いでないことを双方の合意の元
行います。

>また、設計書や仕様書が無く、たびたびの機能修正や追加などもあり、
これは質問者側となるクライアントが悪い。
要求定義書を作って双方が合意した後の段階で機能修正や追加なしで開発させるべき。
開発中での機能修正や追加は開発側からするとものすごく迷惑なこと。
そのためにソースの変更やデータベースの設計を大幅にやり直すこともある。
しかも、それはクライアントがわからしたら些細な簡単な内容かもしれないけど
実際の開発現場からしたらものすごく大量の変更が必要になることもあるから。

>保守契約を結んでいないので、通常は納入後は
バグではないなら無理です。
>仕様的におかしいと思われる箇所については、いや、それはお互いに合意をしているはずだ、
事前に画面遷移書で確認をしていますよね、という話をされてしまいます。
例えば大手サイトでは実装されているようなエラーや入力データのチェックなども
抜けておちていたりします。
それにこれバグでは無い。
処理の方法の問題。

回答No.5

lv4u

Ｎｏ．２です

>>大手サイト～云々については発注前から初期にかけてもたびたび、大手サイトのように作成してくださいという話はしており、わかりましたという事で先方から言われ信用していたのですが・・・。
どうやらそれだけでは難しい、ということなのですね。

そうだと思います。きっちりと「この入力欄は、こんなチェックをして、エラーだったら、こんなメッセージを出す」ってことを、手書きのメモでもいいので書面にして伝えておかないと、実際に作る設計者やプログラマには、正しく伝わらないと思います。
質問者さんにしても、その書面があれば「このメモの仕様どおりに動作しません！直してください。」と強く言えたはずですよね？

ちなみに、「まあ、解るだろう」として、お互いが仕様をきっちり決めないで開発を進めたあるプロジェクトは、発注したお客さんは追加の修正費用で、受けたソフトハウスは、実際の工数よりもずっと少ない請求しかできず、双方が大きな損失を出す結果になりました。

とはいえ、Ｗｅｂサイトの場合、作って使ってみると、「ここはこう変えたい！」という仕様変更が沢山でるものですので、「仕様をかっちり作れってのは、わかっちゃいるけど、それは難しい。」っていうのが現実かもしれませんね。だから、アジャイルとかリーンなんて開発手法が出てきたりするわけですけどね。

また、最近思うのですが、開発完了までにかかる費用だけを考えて「できるだけ安く！」という考え方だとシステム開発に限りませんが、ダメなのではないかと思っています。
開発して実際に何年か運用していったときの費用と利益をトータルで考えるなら、何度かのバグ修正、システムの機能拡張が必ず入ると思います。そうなると、当然ながら「保守契約無し」ってことはあり得ないことだと思います。（もちろん、自分たちで全部保守ができるなら別ですが・・・）

「とりあえず完成してシステムを納入したら終わり」っていう考え方は、システムを使ってのビジネスのことを十分に考えていないのでは？と思うこのごろです。

回答No.4

moflion

皆さんが仰られている通りだと思いますが、
基本的には、契約書の内容をじっくりと読みましたでしょうか？
その上で不明点は契約前に確認を行い、納得の上押印すべきです。

契約書の締結も行い、検収も行ってから不都合な点があったからと
修正や追加作業を求められても、制作会社側は不利益がかさむばかりです。

また、本件は３度にわたって入金をされたとのことですが、
これは良心的な部類に入ると思います。

その都度、納得をした上で入金をされたのではないでしょうか？

明らかに、制作会社の責任で起きている不備（技術的な問題であって、仕様の気に入る入らないではないです）以外は全て有料でのご対応になると思います。

補足

技術的な問題との境界線が非常に難しい判断になっています。
セキュリティのことやなるべく負荷の軽いシステム、そういった専門的な指示を出すことはできませんし、いや、全力を尽くしていますという話だけしかされないので・・・。

もちろん、これはこう作ってくれ、という部分の指示出しの上で作ってもらったものには納得はしています。

回答No.3

potatorooms

＞　これは話し合いがなかったということで向こうは突っぱねられるものなのでしょうか？

できます。仕様は書面で決めたもの以外を満たさなければならないという義務は、ふつう、契約書に盛り込まれないはずです。

＞　設計書が無くても設計をするというのが普通で、その場合は提出義務も無いのでしょうか？

発注時の契約書の明細によります。
フェーズフェーズの納品物件は、契約時に発注側は規定し、その納品物の作成に対して支払いをします。ご質問者さん側が設計書を製作する期間とそれにたずさわる人の費用を払っていないのなら、当然、作成する義務はありませんし、受注側は作成してはなりません。仮に作成していてもそれは作業に必要な内部資料であって、発注側に見せる体裁を取っている必要はないし見せる必要もありません。
見積もり金額に対して、開発に慣れていない人も慣れている人も、真っ先に値切るのが仕様を確定しにいくフェーズでの料金で、この部分を要件定義、納品物の名称はいろいろありますが、要件定義書といいます。これがないと、こういうことをするんだと決めたよね、というベースでの話ができなくなります。
ご質問者さんのいう画面遷移図は、ふつうは、その後の工程の、設計での納品物で、設計書はその際に納品を求めるものです。開発費の削減を求めた場合（ご質問者さんのケースがこれに当てはまるかは知りませんが）、この工程を削ってくるのは、開発側は最後の最後です。安売りの会社さんにはこの辺がいい加減のところもあるので、発注選定時の目安になります。
ご質問者さんのような状況になるのが怖い人は、この２つの工程と納品物に、金額と期間の半分以上をあてます。ここをケチってすんなり完成した開発を、社内で見たことがありません。

＞　これはあくまで契約書に記載が無いというだけで
＞　契約違反にはならず、こちらが我慢をしなければならないのでしょうか？

その状態での開発をこれまで我慢してやってきたのは、先方だと思いますよ。発注側が受注側にいろいろと要求をした状況を書かれていますが、それと同時に、開発側が何を欲しがっているかを、追加費用とともに確認をすべきでした。

＞　お金を払っているこちら側の立場がものすごく弱く感じてしまいます。

いえ。私は、開発を発注する側、おそらくご質問者さんと同じ立場の仕事（職種は編集ですが、いまは本だけを作れば良いって時代じゃないので）をしていますが、そのやり方で開発を進めて来れたのは、お金を支払っているという立場をかなり強烈に主張または利用した結果ではないでしょうか。私がお願いしている開発会社さんに同じやり方を取ったら、２度目は受注してもらいないか、思いっきり高額の見積もりがくると思います。
開発はコモディティ化されていない典型的な商品なのは、いま困っているご質問者さんが一番よく分かっていますよね。どんなに相見積もりをとっても、同じ商品が買える状態ではありません。購入側の立場は弱いんです。この辺は、フリー　って本に状況が具体的に書かれているので、時間があるときに読んでみても良いかも。
そして、完全な労働のみから成り立つ商品なので、天才が１人いれば、思いっきり安く完成させることができますが、そうして作ったものは、天才以外には理解できない、修正ができないものになります。
工程や中間納品物、仕様をきちんと作れば、誰でも作れるものに変わります。作り手側のメリットでは標準化、買い手側のメリットではコモディティ化ですね。
安く　早く　は、作り手側はとてもありがたい話のはずで、すべての工程を外して、ものだけできれば良いんだろう？　という合意を取ったということになります。コモディティ化（標準化）しなければ、次の受注も確実ですしね。
なので、発注側がしっかりして、その辺のお金を払って、手順を踏んでもらう必要があるんです。

＞　相手に色々話しをしても、保守契約を結んでいないので、通常は納入後は
＞　対応ができないという話をされてしまいます。

プログラムを検収する工程を踏んで、支払いになるはずです。検収書は発行していますか？　最後の支払いは、検収が済んでいる合図でもあるので、省略している場合は、対応の仕方は限定されます。
仕様書（できれば発注側の視点での何がやりたいかを書いている要件定義を合意していると強い）がしっかりしている場合、納品後一定期間（ふつうは半年か１年）は、金額の有無は別にして、修正を義務づける瑕疵条項を適用できます。
納品した本に落丁・乱丁があった場合、ちゃんと直して、と言える権利のことです。ただ、誤植があったよ、とか内容が気に入らないというのではこれに当てはまりません。
こういう仕様のはずじゃなかった　とう内容ではダメで、仕様どおりに動かないよ、ということに対しての対応ということですね。

＞　どうしたらよろしいでしょうか？

契約がしっかりしていない、開発の手順を踏んでいない　ということだと思うので、真っ先にやるべきことは、著作権所有者の確認です。
ソースプログラムは、まったく契約書に記載されていない場合、利用権が発注側に、著作権が開発会社にあります。また、著作権には、著作人格権というのがあって、他人が勝手に改変をしてはいけないという　法律で守られた権利があります。
今回納品してもらったプログラムの著作権がどちらにあるかの確認をして、もし先方のあるのなら、「改変をする権利」とセットで著作権の譲渡契約を急いで結ぶことです。本来はもちろん、契約書に盛り込まれている項目です。もし、盛り込まれていないなら、急ぎ、別途契約書を起こすことです。

＞　追加開発を行うため、設計書や仕様書が無いと相手先の業者しかまともにいじれない状況を

を、法律的に解除するために、必須です。
その後で、ソースプログラムを納品してもらい、いま動作するものと、そのソースプログラムから設計書、仕様書を起こし直すことです。多分、開発に書けた費用かそれ以上かかると思いますが。
法律的根拠と、実物の確保を真っ先にしましょう。それがあれば、いつやるかを含めて、主導権をご質問者さんが握ることができます。

補足

著作権や、所有権は移転しています。
また、ソースプログラムの納品というのでしょうか、いわゆるサーバーへのアップロードという形で完了はしています。
技術的な側面から、あまりにもブラックボックスすぎて、たとえばの話手抜き工事をしていても外部からはわからないような状態でも良いとされてしまうのが不思議です。

仕様については、仕様書が存在していない時点で具体的な仕様が策定されておらず、逆に言えばご指摘頂いた仕様通りに動かないよ、という事さえもいえないような気がするのですが違うのでしょうか？

確かに相見積も全く意味がなく、金額の高い安いでは発注を決められずに悩んだ挙句ではあったのですが・・・。

回答No.2

lv4u

No.1さんの言われるとおり、明らかなバグ以外の問題は、発注側の責任となりますね。

また
>>例えば大手サイトでは実装されているようなエラーや入力データのチェックなども抜けておちていたりします。
ということがあっても、発注側が、「大手サイト○○にある以下のようなエラー表示をすること、また、画面○の入力データは△のチェックをすること」
という仕様が無いなら、それも発注側の責任ですね。

ただし、「そういうのをきちんと作り込むのがソフト開発のプロだろう？こっちは素人だ。わかるわけないだろう？」という言い分があるのも解りますが。

いずれにしても、こういうソフト開発発注のトラブルは、依頼元がきっちりと要求仕様を出さずに開発して、完成後、受け入れ確認作業の手抜きをして金を払ったら、ありがちなことだと思います。

通常は、発注側が「高い金出しての勉強代となった」ということで、そのシステムを「お蔵入り」にして、次のシステム発注に生かすことにするか、バグと修正を切り分けて、バグ分は無償に、修正分は費用を払って改修してもらうことになると思います。
また、設計書や仕様書の納品を求めることも必要ですね。でも出してこない可能性が高いですし、仮に出してきても有償となりそうです。

いずれにしても、契約書が無いと、我慢するか、相手に金を払うしかないように思います。

なお、制作したサイトの著作権がどこにあるかを明確にしておかないと、大きなトラブルになることがあります。
例えば、質問者さんが、「お宅の会社は信用できないので頼まない。別会社に金払ってソフトを改修してもらう！」と言ったとき、相手の会社は「著作権は当社にある。他社に頼んでソフトを修正することはできません。もしそうするなら裁判所に訴えます。」なんて可能性もあります。

実際に、そういう流れで大きなトラブルになり、コンピュータ雑誌の誌面にその経緯が掲載されたこともあります。

補足

回答ありがとうございます。
著作権や所有権についてはこちらに移転しています。
大手サイト～云々については発注前から初期にかけてもたびたび、大手サイトのように作成してくださいという話はしており、わかりましたという事で先方から言われ信用していたのですが・・・。

どうやらそれだけでは難しい、ということなのですね。
契約については、書面化せずとも成立するという一般論によりすぎて脇が甘かったのでしょうか。

回答No.1

jaham

明らかなバグ以外は、発注側の責任です（仕様を明示しない、受領し検収を承認した）

仕様打ち合わせや中間の確認で、適切な指示が出せなかった発注者の責任です

修正や機能追加を行いたい場合には改めて契約してください
一般的にはこのようなことに対応するために保守契約を締結します
（それも見積もり段階から話題になります)

費用は　仕様がきめ細やかなほど少なくて済みます、大雑把なほど高くなります（受注側の手間がかかる）

補足

仕様を作成するのは先方だと思うのですが、違うのでしょうか。
設計や開発、用件定義など発注内容に含まれているのですが、あまりに細かい専門的な指示出しとなりますと、こちらが設計しているように感じるのですが・・・。

ただ、きめ細かい仕様のほうが後々のことを考えて安くなるのは理解できます。