お客様の業界問わず最適なITソリューションを提供しています。

フリーでの委託契約についての考察

»

■はじめに

 にゃん太郎さん生島さんのコラムで大変興味深い内容が語られていました。その繋がりで今回は、フリーの委託契約でプロジェクトに参画したときの実話と所感をお伝えしたいと思います。

※このコラムでの委託契約とは、準委任契約をベースとした基本的に成果物に対する瑕疵担保が発生しない、作業自体に責任を負う契約を指します。

■フリーの委託契約を始めた頃

 委託契約自体は、2006年頃から関係があります。コンサル会社で1年くらい、フリーで2年くらいのお世話になっているモノです。フリーの委託契約を始めたのは2007年後半からで、自分の周りでもフリーに転身するヒトが結構いました。

 いまと比べると、案件の数も大体30倍(わたしと取引ある紹介会社数社の平均)以上あったと思います。しかも、案件で求められる質もわりと低く、Javaで実装がちょっとできれば、ほぼ稼動が保障されるような時代でした。

■フリー初のプロジェクト参画

 そんな時代だったこともあり、最初のお客様は、ほぼフリーパスのような状態で契約したわけですが、最初の契約ということもあって少々緊張しました。証券の投信関連プロジェクトで約30名ほどのチーム、わたしの役割は10名程度(8割方フリーエンジニア)のサブチームのリーディングでした。社員の感覚が抜けていなかった当時のわたしからすると、フリーエンジニアという癖のある人々(2名ツワモノがいました)をまとめようと考えても、そう簡単にまとまるモノではありませんでした。

 で、いろいろと無駄なコトを考え、実行してみたわけですが、結局管理ができていれば特にまとめる必要はないかなという考えにシフトし、ツワモノとそれ以外を区別して、仕事の役割を振って進めていきました。

 ツワモノは、実装スキルや目的意識を高く持っていました。いろいろな現場を見てきているので、いろいろな技術を適材適所に適用してくれ、リーディングが楽で助かりました。わたしは、業務分析や他のサブチームのインタフェース設計に集中でき、システムアーキテクチャの基盤部分の設計や実装レビューでも有益な意見を述べてくれました。

 ツワモノ以外の方々も、ある程度の実装スキルを持っているヒトがほとんどだったので、30名全体のプロジェクトマネージャと基準を決めさえすれば滞りなくプロジェクトは進捗していきました。そのツワモノ以外の方々の中には、社員になれなかったのでフリーやってます的なヒトもいましたが、わたしが社員でやっていたときに見てきたエンジニアよりは遥かにスキルも目的意識も高いヒトばかりでした。

 このプロジェクトは、約3カ月でシステムアーキテクチャの基盤まで固まったので退場しましたが、その後の委託契約での活動の自信に繋がりました。

■プロジェクトの合間の活動

 前のコラムで、わたしがフリーに転じた理由を述べましたが、その理由の根幹となるいまのところの最終目標は、

「自分の地元でいつナンドキも仕事がとれるエンジニアになる」

です。

 ソレを実現するためにわたしは活動しているため、委託契約の合間に地元同業者の請負案件や市況調査などの営業活動を粛々としています。

 営業活動を続けていくと、その地元業者と契約内容を詰めるのですが、その地元業者自体の下請案件比率が高いと、わたしの最終目標に繋がらなかったり、地元業者のメンバーを管理する権限をもらえなかったり、上流の技術がない業者だと瑕疵担保範囲の定義が困難などの理由でリスクだけ高いという仕事がかなりありました。

 そういうリスクだけ高い案件に飛びついても得るものは少ないと当時は考えていて(いま現在は切り口を変えて攻めています)契約まで至らず、無償で活動することもけっこうあったわけですが、お金に余裕がなくなってくると、都心の委託契約に飛びつくという流れで仕事をしていました。

 飛びついた案件は、中小企業で火を噴いたプロジェクトが多く、面談で大体わかりますが、スキルを高めるために敢えて飛び込むようにしていました。

■火を噴いたプロジェクトへの参画

 わたしが社員で活動していたころは、自社内でスキルのある人が数人選別されて、役割毎にプロジェクト送り込まれます。数カ月缶詰にされて、事態がある程度収束すると「解散」という感じでした。実際、プログラマとしてJavaの案件に借り出されて、冷たいスパゲッティを一生懸命ほぐした経験をしました。そのとき、リーディングしていたヒトは、けっこうな「丸投げさん」でした。しかし、自社内の火消しということもあって「適切な権限」が与えられており、リカバリーの実装者が結構できるヒトが多かったので、あまり苦労している風には見えませんでした。(実際大変だったかもしれませんが)。

 自社内でのソレに対して、フリーエンジニアが火を噴いたプロジェクトに参画するときは、お客様(プロジェクト自体)が火が噴いていることに気付いていないか、気付いていても火を消せるスキルを持ったヒトがいないか、の何れかではないかと考えています。

 わたしは、現場で両方を見てきましたが、いづれにしてもフリーには「適切な権限」は与えられません。

 そのため、リカバリープランなる大上段なモノを定義する時間など当然ありませんし、どこに問題があるのでこのようにするべきですみたいな提案行為自体、受け入れられません。

 そういう状況なので、現場レベルで本当に意味のある行動をするしか、打開策はありませんでした。

 ソコで何が一番大事なのかというと「テスト」である、とわたしは考えています。

 テストというと計画や実施ばかりに目を奪われがちと思いますが、最も大事なのはテスト仕様です。そもそもプロジェクトの存在理由は、エンドユーザが求めるコトの実現です。実現のため、「要件定義 → 設計 → 実装 → テスト」というプロセスで進めるプロジェクトが多いと思いますが、そういう意味でやっぱり要件定義フェイズで満たすべきテスト仕様は何であるかが肝になるわけです。

 で、火を噴いたプロジェクトも同様にソレが大事なわけで、プロジェクトを通常の状態に戻すために、要件の納期を基準にした優先度を決めて、優先度の順に要件のテスト仕様作成(これは有識者にヒアリングしながらわたしが担当)→即実行(メンバーに割り振るネゴくらいは可能でした)を繰り返しました。

 そうすると、ざっくりですが、どこができていてどこができていないかが分かってきます。

 その後、できていない部分をフォーカスして詳細なテスト仕様作成(これはわたし以外も実施可能) → 即実行。その繰り返し。

 本来ボトムアップで単体テスト → 結合テスト → シナリオテストみたいな流れが一般的だと思いますが、その逆のアプローチも状況によっては実行可能だし、有益なことです。日々、テストという活動の本質を捉えながら問題意識を持ち活動していれば、火急の自体にも柔軟にスキルを発揮することができると考えています。

 そんな感じで、火がある程度おさまったら細かい実装やテストを進めていけばよいわけですが、そもそもなぜこのような火を噴いた事態が起きるかというと、世間一般に云われているプロジェクト管理ができていないということもあるのですが、社内の開発プロセスやルールなどの基準が定まっていないことが大きいと思っています。

 それらの基準を策定する重要性を伝えて(コノ状況になるとフリーでも信頼関係が構築できているので聞く耳を持ってもらえます)、お客様と一緒に基準を決めていき、これから残るメンバーにある程度伝えることができたら、そのプロジェクトを退場するというように活動してきました。

■おわりに

 フリーの委託契約で仕事をする上で大事なことは、プログラマにしてもシステムエンジニアにしても、「信じてよい仕様を明確にすること」だと考えています。

 すなわち、「適切なテスト仕様を提示でき、愚直に実行できること」。それには、さまざまなフェーズの技術が必要であると感じています。

 普通の仕事なら、社員や特定派遣がやればよいことで、フリーエンジニアには、どこかに優れた価値がなければならないと思います。特定の技術領域に特化することにも価値はあると思いますが、両方兼ね備えて真のプロフェッショナルであると思います。わたし自身、道半ばですが技術者としてソレを目指していきたいと考えています。

Comment(24)

コメント

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

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

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

らしいです。

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

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

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

ビガー

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

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

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

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

にゃん太郎

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

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

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

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

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

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

インドリ

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

ビガー

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

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

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

ビガー

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

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

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

K.Oumi

こんにちは。

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

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

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

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

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

(なんかあやしいなぁ・・)

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

私:「何件用意してあるの?
Aさん:「200件くらいです」

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

(あ~、だめだこりゃ。)

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


PS.愚直に実行ってのは、苦手です(^^;

ビガー

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

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

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

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

インドリ

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

Earlgrey

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

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

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

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

長文失礼しました。

ビガー

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

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

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

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

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

AZ

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

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


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

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

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

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

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

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

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

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

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

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

ビガー

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

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

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

ビガー

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

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

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

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

インドリ

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

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

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

Earlgrey

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

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

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

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

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

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

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

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

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

ヴァン

こんんちは。

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

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

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

インドリ

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

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

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

インドリ

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

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

第3バイオリン

ビガーさん

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

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

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

ビガー

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

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

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

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

第3バイオリン

ビガーさん

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

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

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

コメントを投稿する