何を言っている条項なのかというと、簡単に言うと「エンジニアがヘマしてシステムに問題があったときは無償で直してね!」ということです。
業務委託基本契約書はみなさん、きちんと見ているでしょうか。私は立場上見ています。
(最終的には法務部署がチェックしてくれますけど・・・)
最近、瑕疵担保責任にまつわる面白い話を聞けたのでまた記事にします。
とある火吹き現場の面談に進んだエンジニアの所属会社が、
『担当作業と納期が読み難い案件に参画した場合、予定通りに進まなかったら、経験上責任問題になるので見送りたい』
と言ってきたそうです。
ちなみにこれはSESでの契約です。一括請負ではないです。
元請企業は、「個々の外注エンジニアが責任問題になるわけないし・・・何言ってんの????」となったそうです。
ここで責任問題という言葉がおそらく当てはまるであろう業務委託基本契約書の条項が「瑕疵担保責任」です。さて、ここでもう1つ瑕疵担保責任の条項を記載します。
これはSES会社がよく用いている業務委託基本契約書の瑕疵担保責任の条項です。
はっきり言います。SES会社が業務委託基本契約書に記載している「瑕疵担保責任」の条項は、SESではほとんど役に立ちません。むしろSESオンリーの会社であれば、何で記載しているのかも理解に苦しみます。
成果物が明確ではない
請負型の開発であれば、顧客の要求と、要求に対する成果物というのは明確です。簡単に言えば求められたアプリケーション、システムを開発して収めるのですから。
一括で請け負ったシステム、アプリケーションに重大な不具合があった場合は、それは請け負った会社は無料で直して収めるのは当たり前でしょう。
しかし、SESではエンジニアリソースの提供、技術力の提供が主目的であるので、個々の外注エンジニアにとっては各担当もあり、顧客からの要求とその成果物というのは曖昧です。見積書や注文書の件名、作業内容についても全て曖昧です。酷いところであると、
件名:開発支援業務
作業内容:自社内に置けるシステム開発および付随する業務への支援
といった感じでフワフワです。まあ他の現場であろうとSESの場合は大体上記と同じです。共通して言える事は、求められる成果物が曖昧ということです。
そうすると、SESの場合は、個々のエンジニアに求められる成果物自体が明確でなく、収めるべき納入物すら正確ではないのですから、瑕疵担保責任を問うには、これをはっきりさせない限り全く意味がないのです。
そういう意味で、一番最初に上げた瑕疵担保責任の条項はうまく準委任型と請負型に分けていますが、次に上げた瑕疵担保責任は、漠然とし過ぎていて当てはまり難いのです。
成果物って何?
SESにおいて求められる成果物とはそもそも何なのでしょうか?
「ソースコードだ!」という人もいるでしょう。半分アタリで半分ハズレです。
正解は、現場の作業指示を完了することです。
最近ではSE一人で設計して、コーディング、テストまでこなすこともあります。色々な作業を一人でこなさないといけないのです。さらにSESだと契約期間もあります。もちろんフェイズもあります。そうすると、単に設計までの人もいれば、テストのみの人もいます。その人によって求められる成果物というのは、全く違います。唯一の共通回答は、現場の作業指示を完了することなのです。
そして現場の作業指示を完了するということは、マネージャー等の現場作業者の指示が重要になってきます。
SESは技術力の提供です。となると活かすも殺すも現場の指示で決まります。現場の作業指示が全く本人にされていないのに「稼働が上がっていない」「成果物が出ていない」というわけのわからない主張は間違っています。
もし現場からロクな指示もないのに「稼働が上がっていない」「成果物が出ていない」等のクレームを請けた場合は、「作業指示もロクに出ていなく、放置なのに成果物って何ですか?」と逆に詰めましょう。
SESで問われるとすれば
SESで瑕疵担保責任に問われるとすればどのようなことでしょうか。専門の法律家ではないので、正確なことは言えませんがこんな例ではないでしょうか。
マネージャー等からの現場での作業指示に対して虚偽の報告をして完了した旨を伝えておいて実際は全く行っていない。
これはアウトだと思います。
ウソをついて全く出来ないのに終わったという報告をするのは、詐称なのでアウトです。
逆に、「出来ていない」「終わらない」「わからない」等の作業報告が出て来た場合は、その時点でマネージャー側判断になりますが、スキルが全然足りないと判断すれば、終了にすることが出来ます。こういったパターンはセーフです。たった一回の面談で参画が決まるSESですので、面談を踏まえてクライアント側がいけるかな?と判断したものの実はスキルが足りなかった、という事態はある程度しょうがないので瑕疵担保責任にまでツッコミません(大体の場合は、稼働した分金額は支払われると思いますが、稀に減額、もしくはゼロということもあるかもしれませんが・・・)。
こういった虚偽報告のタイプはアウトはアウトですがそもそも瑕疵担保責任なのかすら怪しいですね。ただの詐欺かもしれません。
ちなみにいかにもこの2つ目に載せた瑕疵担保責任の条項の文脈からプンプン臭う、バグが出た場合についてですが、色々と私も調べているのですが、おそらく問われる事は無いのではないかと思います。
上記でも記載しましたが、そもそもSESということも当然ありますが、どうもシステム開発の場合は、バグというのはある程度はどうしても存在していてしょうがないもの、という認識のようで、相当数のものや悪意があるもので無い限りは問われないようです。
ですから、SESで現場に入っていて、リリースまで稼働していて終了した後に、「バグが出たから無償で直しにこい!」というのはよっぽどの酷い場合でなければ、問われないでしょう。また、同様にSESでいただけの現場で「バグが出てシステムが起動せずクライアントから損害賠償請求されているからオマエのせいね!」と言われても、だいたいはなんとかなるでしょう。
(一応、それぞれみんな条件は異なるとおもいますので、都度専門家に確認してね!)
終わり
というわけで『SESなのに瑕疵担保責任を恐れて火吹き現場にビビるSES会社はどうかしてるぜ』でした。
個人的には、こういった話で責任問題になるというのは、現場のマネージャー等が自分のマネジメントが甘く、プロジェクトを失敗したのを、誰かのせいにするためにこういった問題が起こる場合がほとんどだと思います。
エンジニアの皆さんはSESの本質を理解し、自分を守るためにきちんと説明し、自分を守るようにしましょう。
本当に訴えられたらシャレになりませんので。
弁護士費用はイニシャルで50万円とかいっちゃうよー。
こわいこわい。
ちなみに今回例であげた、火吹き現場を責任問題を理由に断った話ですが、個人的には、火吹き現場で責任問題になるのを恐れて見送ったのではなく、稼働が高くなるのが嫌だっただけではないのかなと思います。もしくは火が吹いてピリピリして怒号が飛んで責任問題をムチに稼働させられるのが嫌だったかのどちらかかなと。
はっきりと見送り理由は言って欲しいもんですね。だれも怒ったりしないのに。
業務委託基本契約書はみなさん、きちんと見ているでしょうか。私は立場上見ています。
(最終的には法務部署がチェックしてくれますけど・・・)
最近、瑕疵担保責任にまつわる面白い話を聞けたのでまた記事にします。
とある火吹き現場の面談に進んだエンジニアの所属会社が、
『担当作業と納期が読み難い案件に参画した場合、予定通りに進まなかったら、経験上責任問題になるので見送りたい』
と言ってきたそうです。
ちなみにこれはSESでの契約です。一括請負ではないです。
元請企業は、「個々の外注エンジニアが責任問題になるわけないし・・・何言ってんの????」となったそうです。
ここで責任問題という言葉がおそらく当てはまるであろう業務委託基本契約書の条項が「瑕疵担保責任」です。さて、ここでもう1つ瑕疵担保責任の条項を記載します。
これはSES会社がよく用いている業務委託基本契約書の瑕疵担保責任の条項です。
はっきり言います。SES会社が業務委託基本契約書に記載している「瑕疵担保責任」の条項は、SESではほとんど役に立ちません。むしろSESオンリーの会社であれば、何で記載しているのかも理解に苦しみます。
成果物が明確ではない
請負型の開発であれば、顧客の要求と、要求に対する成果物というのは明確です。簡単に言えば求められたアプリケーション、システムを開発して収めるのですから。
一括で請け負ったシステム、アプリケーションに重大な不具合があった場合は、それは請け負った会社は無料で直して収めるのは当たり前でしょう。
しかし、SESではエンジニアリソースの提供、技術力の提供が主目的であるので、個々の外注エンジニアにとっては各担当もあり、顧客からの要求とその成果物というのは曖昧です。見積書や注文書の件名、作業内容についても全て曖昧です。酷いところであると、
件名:開発支援業務
作業内容:自社内に置けるシステム開発および付随する業務への支援
といった感じでフワフワです。まあ他の現場であろうとSESの場合は大体上記と同じです。共通して言える事は、求められる成果物が曖昧ということです。
そうすると、SESの場合は、個々のエンジニアに求められる成果物自体が明確でなく、収めるべき納入物すら正確ではないのですから、瑕疵担保責任を問うには、これをはっきりさせない限り全く意味がないのです。
そういう意味で、一番最初に上げた瑕疵担保責任の条項はうまく準委任型と請負型に分けていますが、次に上げた瑕疵担保責任は、漠然とし過ぎていて当てはまり難いのです。
成果物って何?
SESにおいて求められる成果物とはそもそも何なのでしょうか?
「ソースコードだ!」という人もいるでしょう。半分アタリで半分ハズレです。
正解は、現場の作業指示を完了することです。
最近ではSE一人で設計して、コーディング、テストまでこなすこともあります。色々な作業を一人でこなさないといけないのです。さらにSESだと契約期間もあります。もちろんフェイズもあります。そうすると、単に設計までの人もいれば、テストのみの人もいます。その人によって求められる成果物というのは、全く違います。唯一の共通回答は、現場の作業指示を完了することなのです。
そして現場の作業指示を完了するということは、マネージャー等の現場作業者の指示が重要になってきます。
SESは技術力の提供です。となると活かすも殺すも現場の指示で決まります。現場の作業指示が全く本人にされていないのに「稼働が上がっていない」「成果物が出ていない」というわけのわからない主張は間違っています。
もし現場からロクな指示もないのに「稼働が上がっていない」「成果物が出ていない」等のクレームを請けた場合は、「作業指示もロクに出ていなく、放置なのに成果物って何ですか?」と逆に詰めましょう。
SESで問われるとすれば
SESで瑕疵担保責任に問われるとすればどのようなことでしょうか。専門の法律家ではないので、正確なことは言えませんがこんな例ではないでしょうか。
マネージャー等からの現場での作業指示に対して虚偽の報告をして完了した旨を伝えておいて実際は全く行っていない。
これはアウトだと思います。
ウソをついて全く出来ないのに終わったという報告をするのは、詐称なのでアウトです。
逆に、「出来ていない」「終わらない」「わからない」等の作業報告が出て来た場合は、その時点でマネージャー側判断になりますが、スキルが全然足りないと判断すれば、終了にすることが出来ます。こういったパターンはセーフです。たった一回の面談で参画が決まるSESですので、面談を踏まえてクライアント側がいけるかな?と判断したものの実はスキルが足りなかった、という事態はある程度しょうがないので瑕疵担保責任にまでツッコミません(大体の場合は、稼働した分金額は支払われると思いますが、稀に減額、もしくはゼロということもあるかもしれませんが・・・)。
こういった虚偽報告のタイプはアウトはアウトですがそもそも瑕疵担保責任なのかすら怪しいですね。ただの詐欺かもしれません。
ちなみにいかにもこの2つ目に載せた瑕疵担保責任の条項の文脈からプンプン臭う、バグが出た場合についてですが、色々と私も調べているのですが、おそらく問われる事は無いのではないかと思います。
上記でも記載しましたが、そもそもSESということも当然ありますが、どうもシステム開発の場合は、バグというのはある程度はどうしても存在していてしょうがないもの、という認識のようで、相当数のものや悪意があるもので無い限りは問われないようです。
ですから、SESで現場に入っていて、リリースまで稼働していて終了した後に、「バグが出たから無償で直しにこい!」というのはよっぽどの酷い場合でなければ、問われないでしょう。また、同様にSESでいただけの現場で「バグが出てシステムが起動せずクライアントから損害賠償請求されているからオマエのせいね!」と言われても、だいたいはなんとかなるでしょう。
(一応、それぞれみんな条件は異なるとおもいますので、都度専門家に確認してね!)
終わり
というわけで『SESなのに瑕疵担保責任を恐れて火吹き現場にビビるSES会社はどうかしてるぜ』でした。
個人的には、こういった話で責任問題になるというのは、現場のマネージャー等が自分のマネジメントが甘く、プロジェクトを失敗したのを、誰かのせいにするためにこういった問題が起こる場合がほとんどだと思います。
エンジニアの皆さんはSESの本質を理解し、自分を守るためにきちんと説明し、自分を守るようにしましょう。
本当に訴えられたらシャレになりませんので。
弁護士費用はイニシャルで50万円とかいっちゃうよー。
こわいこわい。
ちなみに今回例であげた、火吹き現場を責任問題を理由に断った話ですが、個人的には、火吹き現場で責任問題になるのを恐れて見送ったのではなく、稼働が高くなるのが嫌だっただけではないのかなと思います。もしくは火が吹いてピリピリして怒号が飛んで責任問題をムチに稼働させられるのが嫌だったかのどちらかかなと。
はっきりと見送り理由は言って欲しいもんですね。だれも怒ったりしないのに。