はじめに
契約についてしっかり知識を身に着けようと思ったので、個人的な備忘録として残しているため、簡潔ではありません。
1.契約とは
二人以上の当事者の意思表示が合致することによって成立する法律行為のこと
出典元：Wikipedia
だそうです。
契約を結んでいない限り、法的な拘束力がないので、お金を貰う約束をしても、法律が私達を守ってくれないんですねぇ。法律が守ってくれないとなると、お金を貰えるかどうかは、道徳の領域ですね。もちろん、「法律が守ってくれるから」とノーガード戦法も良くないですよね。法律は手段ですね。
法律っていう拘束力を発揮してもらうために契約は必要なんですね。
2.契約が結ばれたことになるのはいつ？
契約は、紙面に限らず口頭も含め「当事者の合意」があればいいそうです。契約書や覚書って法律上の要件では必須ではないんですね。
契約書が必要な理由は、様々な理由がありますが省きます。
3.契約の形態
IT業界には請負契約、準委任契約、派遣契約をよく聞くので取り上げます。
契約が力を持つ内容を各フェーズに記載すると
| フェーズ | 契約が力を持つ内容 |
|---|---|
| 作成中 | ①受注側がやらなくてはいけないこと ②契約期間中の発注側の権限（指揮命令権） ③完成責任の有無 |
| 納品 | ④契約完了による報酬の支払い |
| 納品後 | ⑤瑕疵担保責任の有無 |
に分かれます。
各契約形態でどのように異なるのでしょうか。
①受注側がやらなくてはいけないこと
請負 ・・・仕事の完成
準委任・・・業務の処理
派遣 ・・・労働の従事
①.1 仕事の完成
内容が抽象的すぎて、腹落ちしにくいですね。。
仕事の完成は、システムの完成ですね。
システムの完成には瑕疵担保責任がつきます。
瑕疵担保責任は、納品したら、システムがリプレースするなり、無くなるなり、しない限り、永遠なんでしょうか。
いえ、瑕疵担保責任を背負うのも、契約時に期間を決めます。リリースから3か月など。
①.2 業務の処理
業務の処理は、「善良な管理者の注意義務」だそうです。つまり人依存。
発注側の権限が弱く、指揮命令系統は受注側にあります。
発注側の立場からしたら不安でいっぱいですね。発注側はその不安をどこで取っているのでしょうか。
とは言っても、実態はお金を出している側が力が強い。むしろ、しっかりコントロールすることが腕の見せ所です。コントロールも、お金やスケジュールだけでなく、システム・業務的観点でコンサルタントのようにファシリテートしていく必要があります。
①.3 労働の従事
派遣は、完成の責任のない請負ですね。発注側の言うことを聞かなくてはいけないけど、仕事の完成責任はないんですね。
余談
転職先の配属プロジェクトでは顧客とやり取りしている発注側に癖があり、元請の立場だった人間として「それはどうなん？」と思うことが多々。。今後戦う場面があるかもしれないので、しっかり整理しようと思ってこの記事を書きました。
各契約を差分のある項目でマトリクスを作成するのが一般的だと思うのですが
マトリクスはぱっと見キレイに見えますが、理解となると、追体験や論理の疑問点を自分なりに埋めていくことの方が理解が深まると考えています。
マトリクスや簡潔な説明は、正しい資料に見えて、前後関係が見えず、実務に活かせくなります。資格のみだったら問題ないですが、顧客に説明するときに「なんで？」攻めをされてもしっかり回答できるようにする必要があると思います。