ビガーさん、こんばんは。

私も勘違いしていたのですけれど(^^;
委任契約にも瑕疵担保責任はあります。

「瑕疵担保責任の規定はすべての有償の契約に適用される」

らしいです。

それはさておき、フリーランサーの方が意識が高いというのは、まぁ、当たり前のことかもしれませんが、昔は「朝早く起きれない」とか、「半年働いたら1ヶ月休む」とかいう人も、ザラに居ましたから、技術的も、アクも強い集団です。

今は、不況のおかげでそういうチームでやってます。好景気だとなかなか揃わなかったのでちょっと楽しいかな。

火を出さないことには興味があったけど、火の消し方ってそう言えば考えたことがなかった。力技で消してきたので……。

生島さん、コメントありがとうございます。

>「瑕疵担保責任の規定はすべての有償の契約に適用される」
仰る通り、法律的にはその通りみたいですね。
ただ、瑕疵担保責任は「成果物」に対して発生すると思います。今までのお客様(厳密には紹介会社)との契約では、その成果物の定義をあいまいにしてきたので、「基本的に成果物に瑕疵担保は発生しない」という表現を使いました。
また、作業自体に価値を出すという意味と契約終了後のお守りは有償にしないと食べていけないんですという意味を込めました。

>今は、不況のおかげでそういうチームでやってます。好景気だとなかなか
>揃わなかったのでちょっと楽しいかな。
7月末まで委託契約していましたが、そこまで生き残ったフリーのヒトは、それなりにできるヒトばかりでした。ただ、やっぱり纏めようとしても纏まらない。自律的に動けるタスク割振りが大事で、スピード感はそういうチームならではかなと思います。楽しいですよね^^

>火を出さないことには興味があったけど、火の消し方ってそう言えば考えた
>ことがなかった。力技で消してきたので……。
火がでないと案件数が減るという現実もあるのが悲しいです。最初からそういう問題がありそうな案件絡めれば、未然に防げるから理想なんですけどね。

ビガーさん、おはようございます。

　コメントありがとうございました。フリーの話は意外？といろいろな方から意見
を頂けたので正直驚いています。賛成にしろ反対にしろやはり興味がある人が多い
んでしょうね。特に今は先行きが不透明なだけに。

> 普通の仕事なら、社員や特定派遣がやればよいことで、フリーエンジニアには、
> どこかに優れた価値がなければならないと思います。

　これは同感です。何を持って「優れた価値」かという部分は難しいですが、ただ
コードが書けます、設計できます、では通用しないのは間違いないと思います。も
っともこれはフリーだけに限らない話でしょうけど。ちなみに私の場合、夏場は圧
倒的に「エアコン取り付け」の依頼が多いです（笑）

　私も良く火の噴いたプロジェクトに参加しますが（させられてるかな？）原因を
作った本人が分かっていない事が多いです。私のコラムでも良く書きますが、とに
かく動けば、というスタンスで作り込んで行くためコードを見ると直す方が早いか
それとも設計し直した方が早いかという極端なケースが昔に比べて増えています。
本人の為を思って説明しますが、作り込んできた自負とプライドから反発し、火に
油を注ぐ結果になって雰囲気が険悪になる事も多々あります。ただ、上の人は説明
すれば理解してくれるので私の方は粛々と作業を進めるだけですが。

　私はプロのエンジニアが最近少なくなったと感じます。正社員は「使えない」だ
けでは解雇できないので、そのぬるま湯につかってしまっている人が多いと感じま
す。正社員が悪い訳ではありませんが、緊張感を持って仕事を進めて欲しいと思い
コラムを書いていますが、現実は･･･難しいですね。

ビガーさんおはようございます。
何時もコラムを読むばかりでは申し訳ないので、今回は私が知っている事を書きます。
フリーで気をつけたほうがよい事があります。
それは「契約書を無視された時の対応が難しい」点です。
こっちが契約を破ったら先方は当然普通に対処できます。
しかし先方が破った場合は案外難しいのです。
というのも、こちらは資金がない一人ですので、
弁護士を雇って、書類を書いて、裁判をして・・・
という流れが非常に面倒かつお金がかかって実現し難いのです。
裁判が引き伸ばされるだけでこっちに多大な負担が来ますし、
そんな法律を軽視する会社は色々な妨害活動までしてきます。
おまけに裁判に勝ったところで、
日本出の裁判は「言うだけ」なので先方が判決を無視すればこれまた厄介です。
契約書を結べば大丈夫だと信じきっている人が居ますが、
契約書はただの紙であり、日本は極めて法律が甘いですので信じては駄目です。
結局は信頼しかありません。
これからどんどん不景気になってきますので、契約書を守らない会社が増えてくると思います。
気をつけて下さい。

にゃん太郎さん、コメントありがとうございます。

>とにかく動けば、というスタンスで作り込んで行くためコードを見ると直す方が
>早いかそれとも設計し直した方が早いかという極端なケースが昔に比べて増えています。
そうですね、何かしらの基準をもって実装されている方のコードなら尊重しますが、ない場合は、私は容赦なく破棄します、時間がないので。そういう方に限って確かに面倒が多いし、気がつかない内に退場していることが多いかな。

>正社員が悪い訳ではありませんが、緊張感を持って仕事を進めて欲しい
歴史については、無知でアレなんですが、高度経済成長時代のサラリーマン思考がそもそも違和感のある考え方のような気がします。その前までは、それぞれのヒトが自営でプライドと責任をもって、一生懸命仕事をしていたんでしょうから。ソレに戻りつつあるだけなのかなと思います。

インドリさん、コメントありがとうございます。

>それは「契約書を無視された時の対応が難しい」点です。
これについては、実のところ最初の頃、結構ビクついていました。私は、幸い良い契約先ばかりに恵まれ、入金が滞ったことはありません。
私のこのあたりのリスクヘッジの仕方としては、契約先の代表者と必ず面談することにしています。その代表者がどういう人間なのか(企業理念の背景だったり、その理念が現場に伝わっているかだったり)を判断して、契約してもいいかなという会社のみに絞っています。倒産リスクもあるので、可能な限り財務情報も調べます。

それでも、入金がされない契約先があるなら、自分の目が悪かったと次回に向けた反省になりますのので、理由を必ず聞こうと思っています(まだないので何とも)。裁判なんて時間とお金の無駄かなと思います。

こんにちは。

「適切なテスト仕様を提示でき、愚直に実行できること」
これは大事(必須)で素晴らしい事だと思います。
特に、「適切なテスト仕様を提示でき」と言う部分はかなりの重要ポイントだと思います。

昔こんなことがありました。
本番稼働後の火消しで行ったあるプロジェクトで、

私：「テスト仕様書はできてますか？」
Ａさん：「最初に使ったものがそのまま使えます」

(見るのは面倒だなぁ・・)

私：「テストデータはあるの？」
Ａさん：「最初に使ったものがそのまま使えます」

（なんかあやしいなぁ・・）

私：「テストデータはのバリエーションは、考えうる限りの物が用意されてるの？　量も考えてってことですけど」
Ａさん：「だいじょうぶですよ」

私：「何件用意してあるの？
Ａさん：「２００件くらいです」

私：「組み合わせ？で２００種類ですか？」
Ａさん：「いえ、代表的な操作と、量で２００件くらいです」
私：「何かこう、ジェネレータとかツールとかないのですか？手で作ったの？」
Ａさん：「そうです」
私：「年度の切り替えは考慮されたデータなの？」
Ａさん：「いえ、そこは旧年度と新年度が並行して別スキーマで動くので大丈夫です。」

（あ～、だめだこりゃ。）

そうして本番のデータを吸い上げさせてもらうために、お客さんに泣きつきに行くのでした。
4000万件あるDBへの操作パターンと量と考えて200件って・・・そら火吹くわなぁ・・

PS.愚直に実行ってのは、苦手です（＾＾；

Oumiさん、コメントありがとうございます。

>本番稼働後の火消しで行ったあるプロジェクトで、
本番稼動後の火消しは経験ないです。それは、顧客調整とか相当キツソウですね。

>Ａさん：「いえ、代表的な操作と、量で２００件くらいです」
そういうテスト仕様の甘さって、多分、設計でちゃんと考えられていないからというのが根本原因だと思います。火を噴いたプロジェクトは、往々にして設計思想がナッテナイので、テスト仕様≒設計思想みたいな構図になり、個人的には結構楽しい部分もあります。

前にテストエンジニアについて、いろいろとコラムが立っていましたけど、そういう意味でテストエンジニアなるポジションは、ある意味設計者以上のスキルが求められるかなと個人的には考えています。

ビガーさん返信有難う。
その考えでOKだと思います。
私も裁判は無駄だと考えております。
案外これを知らなくて、裁判は正義を体現するものだとか、
契約書があればいいと妄信している人が結構居るんですよね・・・
やはり、商売は結局のところ信頼ですよね。
本当のところは、政府がしっかりしてくれたらこんな無法地帯な状態にならないのですが・・・
結局のところ現実は変わりませんので、自分の目を信じるしかないですよね。
私もそうしています。
互いに頑張りましょう。

はじめまして、Earlgreyと申します。
フリーの方の意見を拝見する機会がめったにないため、
大変興味深く拝見させていただきました。

>そもそもなぜこのような火を噴いた事態が起きるかというと、
>世間一般に云われているプロジェクト管理ができていないということもあるのですが、
>社内の開発プロセスやルールなどの基準が定まっていないことが大きいと思っています。

まさにおっしゃるとおり、と思いました。
ルール自体はあるのに周知されていない、とか、
逆にある部分ではルールが多すぎて、逆にルールへの関心が薄れる
→守られない、という本末転倒な症状が、わが社でも起こっています。
といって、小うるさく言っても聞き入れてもらえないという(苦笑)。
上手く回っているところは、何か工夫がおありなんですかね･･･。

あと、コラムとは若干ずれるのですが、「瑕疵担保責任」について、
実務上は準委任契約でも発生するものなんでしょうか。
だとすると、契約上は要注意、ということになりますね。
てっきり、準委任の場合は債務不履行責任(善管管理義務違反)くらいしか、
問題にならないと思っていました･･･。

長文失礼しました。

Earlgreyさん、コメントありがとうございます。

>ルール自体はあるのに周知されていない、とか、

ルール自体が適切かどうかを検証してブラッシュアップしていく「体制」が大事かと思います。
おっしゃる通り、周知というのはヒトの入れ替わりが激しい組織とか組織の規模が大きくなるほど難しいですよね。

私がよいと思う方法は、背景を含めた意図を常に残すという基本的な作業をWIKIなどのツールで検索しやすいようにしておくこと、ContinuumとSVNを連動させてWIKIとの紐付けをしておくこと(設計の意図と実装の意図の整合性担保)。
それとフェーズ毎の担当者だけが更新できるようにして、担当者がするべき作業を明示すること(コントロール可能にすること)が大事と考えています。
そういうプロジェクトは、回帰テストもスムーズにできるので、ほとんど問題でない感じでした。導入初期の構築段階が面倒なんですけど。

>実務上は準委任契約でも発生するものなんでしょうか。
少なくとも私の契約先(東京都内)は、準委任契約を締結する際、「成果物」を要求される場合に限り発生します。(通常、基本契約書と注文書の2つに分かれますが、基本契約書に記載がある場合がほとんどです)
実務上はお客様によります。私の取引先では要求されることはありませんでした。
成果物を要求されるようなニュアンスのときは、ちょっと注意する必要があると思います。

契約不履行による訴訟問題は、商道徳の問題なので、置いときます。
フリー技術者に対しては、スペシャリスト性が求められるので、
派遣のような通常の役務提供では、カバーできない仕事とも言えますね。
でも、実際の契約は、月額幾らの契約(役務提供的な契約しか存在しない)の場合もあります。
成果給の成果の測定尺度が存在しないので、仕方のない面もあると思います。

テスターに関して。テスターの重要性を認識して欲しいです。
スザンなテスターによる火災の例は適切感があります。よく見かける例です。
テストサンプリング数の甘さは昔からあって、正常系のデータしか作成しないプロジェクトがあったりします。
開発者にテスト仕様書/テストデータを書かしている段階で駄目だろうと思います。
開発者に悪意はなくても、都合の悪いデータはOmmitしがちです。
できれば、開発に携わっていない人にテストパターンを作ってレビューするのが望ましいです。コスト面で厳しいですが。
・テスターは異常系のデータを作るのが仕事
・自分がそのシステムを使う担当者になって試用する
この二点を心がけるだけでも前進するのですがねぇ。
そして、プログラム作成物だけのテスターだけでなく、各段階(外部、内部)の仕様書のテストも含めて。

> 実務上は準委任契約でも発生するものなんでしょうか。

私もフリーになってから現在に至るまで十数年、委任契約では瑕疵担保責任はないと判断してきたしそれで問題なかったのですけれど、恥ずかしい限りです。
法律は怖いものですね。

委任契約で、それまでの作業で明らかな瑕疵があれば責任を問われることになるようですが、完成責任はなく、すべてのテスト工程を終えてなく、その後に別の人の手が入ることも多いので、現実的には立証が難しいので勘違いする人が多いのかな？

私も関連法をすべて読んだわけではないので、間違っているかもとも思っているのですが。

余談ですが、契約不履行に対して。

企業の最大の目的はゴーイングコンサーンです。

経営者の立場に立てば、高々、フリーランサー1人分の契約を踏み倒すリスクは、その金額の何倍も高くつきます。
相手が立場の弱いフリーの方であっても、契約不履行があってはゴーイングコンサーンできなくなりますので、普通はやらないものです。

やるとしたら、火を噴いたプロジェクトに火を消してくれることを期待して委任で入れたフリーランサーが油を注いだとか……。そういう場合はあり得るでしょうね。現実に見たことありますけれど、それって見せしめですよ。
企業側としてはそんなことをした方が損なのですが、「半端な技術者には、契約書があっても払わんぞ！」って、結果的に損をしても、悪しき前例を作らないために他の技術者に見せつけるための企業側の意地でしょう。

他には、倒産寸前で本当に払えないことがありますけどね。
（そうならないようにがんばってます）

できるフリーの方は抱え込みたいから、企業側もきれいに終わりたいものなので、技術があるなら、倒産しそうか？だけを見れば十分です。

AZさん、コメントありがとうございます。

>テストサンプリング数の甘さは昔からあって、正常系のデータしか作成しないプロジェクトがあったりします。
>・自分がそのシステムを使う担当者になって試用する
そうですね、ISO9126程度がプロジェクトの各フェーズで意識されるような状況が生まれるとよいと個人的には考えていますが、最低限、ユーザ視点での操作を網羅するテストは必須です。異常系については、モノにより難しい部分もあると思いますが、システム構築の目的と照らして最低限の重要な部分はテストデータなどを準備し、問題を発覚させお客様に説明できるようにするのが大事かと思います。

余談ですが、マスタデータなどの基幹データがそもそも想定外となっているケースなどは、正直ガッカリします。

生島さん、コメントありがとうございます。

>その後に別の人の手が入ることも多いので、現実的には立証が難しいので勘違いする人が多いのかな？
SVNなどを追跡すれば可能でしょうけど、無論実装物は責任もって提供していますし、よほどお客様と険悪な関係になっていなければ、問題ないかと。

>やるとしたら、火を噴いたプロジェクトに火を消してくれることを期待して
>委任で入れたフリーランサーが油を注いだとか……。そういう場合はあり得る
>でしょうね。現実に見たことありますけれど、それって見せしめですよ。
私が入ったプロジェクトもそんな(やれるもんならやってみろや的な)ムードはありましたね。多分、見せしめというか、誰もが何を信じられなくなっている状態だからではないかと。基準を示しつつ、問題を認識(見えるように)させてあげると安心してくるので、その後はある程度スムーズにコトが進みました。

倒産リスクの回避手段として、今の契約先は上場しているか、財務情報を部分的に公開してくれるところに限っています。どうでもいいけど、簿記3級を持っているんですが、投資にしてもそのあたりにしても使えるモノなので有益な技術だな～と思います。

>やるとしたら、火を噴いたプロジェクトに火を消してくれることを期待して委任で
>入れたフリーランサーが油を注いだとか……。そういう場合はあり得るでしょう
>ね。現実に見たことありますけれど、それって見せしめですよ。
>企業側としてはそんなことをした方が損なのですが、「半端な技術者には、契約書
>があっても払わんぞ！」って、結果的に損をしても、悪しき前例を作らないために
>他の技術者に見せつけるための企業側の意地でしょう。

>他には、倒産寸前で本当に払えないことがありますけどね。
>（そうならないようにがんばってます）

性善説で考えすぎです。
私が実際に遭ったケースでは、「なるべくただで盗った方が儲かる」と言って踏み倒した社長が居ます。
私が作っていたのは、発明に関する事や基幹業務システムなどの規模の大きく、契約金が高いもの（1000万以上）だという事も影響していたと思います。
ですから、現在私はそういったものの依頼は極力避けて、小口で現金前払いの仕事をしかしません。
そうするほうが確実に稼げるので案外儲かります。
この国は法治国家なので、法律に則って安心して大きな仕事が出来る環境になって欲しいです。
デスマーチは嫌だけど全力を出せる仕事が欲しい・・・
毎日鍛錬を怠っていないのですが、その実力を発揮できる場所が無いのは技術者として非常に苦痛です。

ビガーさん、返信ありがとうございます。

>私がよいと思う方法は、背景を含めた意図を常に残すという
>基本的な作業をWIKIなどのツールで検索しやすいようにしておくこと、
>ContinuumとSVNを連動させてWIKIとの紐付けをしておくこと
>(設計の意図と実装の意図の整合性担保)。

やっぱりそこですよね。予防が一番大事、という。
なかなか定着しないので、動機付けをどうしたものか･･･、
というのが最近の悩みだったりします。
一度痛い目に遭って学習する人もいれば(こういう人はその後徹底してくれる)、
そうでない人もやっぱりいまして(苦笑)

あとすみません、私も余談です。
「瑕疵担保責任」と「債務不履行責任」ですが、調べた範囲では、

　委任契約の場合、債務不履行責任として追求(過失責任)
　請負契約の場合、瑕疵担保責任として追求(無過失責任)
　　　　　　　　　(債務不履行としても追求できる)

大枠ではこんなところになるようです。

請負契約の場合、納品物に問題があればそれだけで責任追及できる。
委任契約の場合、納品物に問題があった場合は、
その納品物の作成プロセスに問題があったことを、
納品を受ける側で証明しなければならない。
(あるいは納品側で、過失がなかったことを証明しなければならない?)
こんなところで、差が出てくるのですかね。

ただどちらも、特約(契約書)の記載のほうが優先されるので、
委任なのか請負なのか区別が付かない契約書もあるようです。
「契約のベースが委任なのか、それとも請負なのか」
を契約書に記載しておくほうがいいのかもしれませんね･･･。

>法律は怖いものですね。
ほんとうに怖いです。痛感しております(汗)。

こんんちは。

>私が作っていたのは、発明に関する事や基幹業務システムなどの規模の大きく、契約金が高いもの（1000万以上）だという事も影響していたと思います。

フリーの立場でないので判りませんが、1000万円規模のシステムを一人で作業するフリーランサーに任せるのでしょうか？
単純に考えても10人月の作業にはなると思うのですが。

というか、契約金が高いことが何に影響してるのでしょうか？
高いものほど踏み倒されやすい？

一つ言い忘れていました、

>「信じてよい仕様を明確にすること」

これににプラスして、「細かく正否を明らかにして、明確で細かなところまで決まっている契約を結ぶ事。」も必要となります。
※フリーとなると仕様書と契約書の両方を見なければならないのです。
これは日本には馴染みがない商習慣なようですが、これをしておかないから後で契約でもめるケースを多々見聞きしております。
庇護責任は正否を明確に決めておかないと大変な事になります。
ビガーさんご注意を！

すみません間違えました。

誤：庇護責任
正：瑕疵責任

ビガーさん

1日から旅行に行っていたので、コメント遅くなってすみません。
（ちょっとイーハトーブを探してきました）

>すなわち、「適切なテスト仕様を提示でき、愚直に実行できること」。
これってフリーじゃなくてもテストエンジニアには必須のスキルですね。
私は火を噴くプロジェクトに関わったことはまだありませんが、
何かあったときに私の力が必要になるのかな、と気持ちが引き締まる思いがしました。

そういう意味では、私はある意味とんでもない道に進んでしまったのかもしれません。
しかし、もう後戻りしないという覚悟はできています。

第3バイオリンさん、コメントありがとうございます。

旅行いいですね、私もフリーになって以来初めて8月上旬に沖縄へいってきました。
サイパンにも行ったことがあるのですが、海は思ったよりキレイでなくて(私の行ったところがよくなかったのかも)、環境について考えさせられましたが、家族の能天気ぶりにかき消されました。
イーハトーブ(楽園という解釈でいい？)は見つかりました？私のイーハトーブは、トイレです^^;

業務系にしても組込系にしてもテストの位置付け(重要性の評価)が低いと感じています。ただ、テストの重要性は今後も変わらないと確信しています。
これからますます複雑化するシステムを俯瞰的に捉えてテストを最適化できるスキルというのは、暗黙的なニーズになるかもしれませんが、確実に「売れるスキル」です。それには、いろいろなフェーズのいろいろな観点が必要だと感じています。

ファイアープロジェクトにダイビングするのもスピード感があって楽しい部分もあるので、そういう機会があったら一度は経験してみると確実にスキルは高くなるし、うまくいけば自信が相当つくと思います。ただ、体調がいいときにした方がいいかも^^;

ビガーさん

>イーハトーブ(楽園という解釈でいい？)は見つかりました？
はい、見つけてきました。
イーハトーブとは、童話作家の宮沢賢治が理想とした世界のことです。
（エスペラント語で「岩手県」という意味らしいです）
岩手の花巻、遠野をめぐって宮沢賢治ゆかりの地を旅してきました。

>ただ、テストの重要性は今後も変わらないと確信しています。
>いろいろなフェーズのいろいろな観点が必要だと感じています。
それは私も思いますね。
テストエンジニアの仕事をするまではテストが大事とは思わなかったのですが
この仕事を始めてからは「これからの時代はテストだ！」と思うようになりました。
テスト対象物の仕様を把握するには、要件定義から設計・実装のことも理解する必要があります。
そのうえで素人のユーザーの目線で対象物に触るという一見すると矛盾するようなことをやるんだから、なかなか難儀な商売です。

>ただ、体調がいいときにした方がいいかも^^;
妙にリアルな一言ですね（汗）
でも、やってみたい気はあります。