タグ

契約に関するkoma_gのブックマーク (64)

  • 不動産の契約でドチャクソ痛い目に遭った→次に契約する所で「絶対ここだけは見とけポイント」を教えてもらった

    たけぞー @signe705 ずいぶん前に不動産の契約でどちゃくそ痛い目にあって、その次に契約する時に半泣きで「契約書なんてクソ細かい文字で、専門用語もあって読んでも解らない。どうすればいい?」と愚痴ったら、「絶対コレはと言うなら、『解約事項』だけでも見て。無茶な解約条件、解約が難しいのはやめた方が良い」 2024-04-07 09:07:47 たけぞー @signe705 と教わった。「何が無茶な条件か解らない、ギョーカイはこうなってる」と言われたら?「持ち帰って、他のを調べる。そんな時間はーと言って契約を急かせるのはヤバいと思っていい」らしいので、それ以来サブスクでもなんでも解約のとこをまず見るようにしてる。おかげで 2024-04-07 09:12:34

    不動産の契約でドチャクソ痛い目に遭った→次に契約する所で「絶対ここだけは見とけポイント」を教えてもらった
  • IT契約入門〜雇用契約、請負契約から準委任まで - Qiita

    この記事は? 著者は、エンジニアにとって最も大事なものの一つは契約であると考えます。なぜなら、契約によって我々はお金を得ることができ、労働対価を受け取って生きていくことができるからです。プロジェクトにおいてトラブルが発生すると、契約はメンバーを守ってくれるものになります。したがって、雇用契約、請負契約、準委任契約など何の契約であっても隅々まで確認し、不利にならないようにしないといけません。社員であれば誠実に職務に向き合う必要があります。請負契約であれば対価を得るために納品する必要がありますし、準委任契約であれば善管注意義務を背負いプロとして日々業務を行なっていく必要があります。一方で、著者は長くにわたって業務委託契約でパートナーとして参加してくださっているエンジニアたちと長らく協働してきた経験がありますが、ユーザーとしてもベンダーが妨害要素なく働けるように、協力義務を果たす必要があります

    IT契約入門〜雇用契約、請負契約から準委任まで - Qiita
  • 準委任契約だけど、責任は取ってください

    連載目次 準委任契約と請負契約 今回は、システム開発の要件定義工程の契約形態についてお話しする。 連載の読者ならご存じの方も多いと思うが、情報システムの開発は、準委任契約に基づいて行われる場合か請負契約に基づいて行われる場合が多い。そして1つの開発においても、要件定義工程は「ユーザーの作業を支援する」という意味合いで、成果物の完成責任を負わない準委任契約で、設計以降の工程(ここでは便宜的に「開発工程」と呼ぶ)は「ベンダーが主体となる」ために成果物の完成責任を伴う請負契約で行う場合がよくある。準委任契約は、「専門的知識やスキルを持つ人間が契約で合意した時間働けば、その対価は払ってもらえる」というのが原則である。 では、専門家が一定時間働きさえすれば責任を果たしたことになるのだろうか。 今回取り上げる事件は、ITベンダーが要件定義工程から開発工程までを一貫して行ったが、要件定義に抜け漏れがあ

    準委任契約だけど、責任は取ってください
  • 脆弱性対応(Heartbleed)の責任の所在 東京地判令元.12.20(平29ワ6203) - IT・システム判例メモ

    クレジットカード情報漏えい事故に関し,その原因の一つと考えられる脆弱性対応が運用保守業務に含まれていたか否かが争われた事例。 事案の概要 Xは,Xの運営する通販サイト(件サイト)を第三者に開発委託し,運用していたが,その後,2013年1月ころまでに,Yに対し,件サイトの運用業務を月額20万円で委託した(件契約)。件サイトはEC-CUBEで作られていた。なお,XからYへの業務委託に関し,契約書は作成されておらず,注文書には「件サイトの運用,保守管理」「EC-CUBEカスタマイズ」としか記載されていない。 2014年4月には,OpenSSL*1の脆弱性があることが公表されたが*2,件サイトでは,OpenSSLが用いられていた。 2015年5月ころ,Xは,決済代行会社から件サイトからXの顧客情報(クレジットカード情報を含む)が漏えいしている懸念があるとの連絡を受け(件情報漏えい)

    脆弱性対応(Heartbleed)の責任の所在 東京地判令元.12.20(平29ワ6203) - IT・システム判例メモ
  • サイト開発の遅れによる契約解除 東京地判令3.12.3(令2ワ5059) - IT・システム判例メモ

    サイトの開発が遅れたことによる契約解除の可否が問題となった事例。 事案の概要 XはYに対し、美容業界のメーカー、ディーラー、ユーザーらが情報交換を行うためのウェブサービスに関するアプリケーションソフト(件アプリ)の開発を委託した(件契約)。 途中で、XY間は、クレジットカード決済機能を追加し、代金を496万8000円(税込)とすることなどを合意した。XはYに対し、前記代金を3回に分けてほぼ全額支払った。 Xは、履行期である2019年3月(具体的な履行期は争いがある。)経過後の5月31日に、 スケジュールやテスト画面もいただけなく,全く状況が分かりませんし,これ以上進めるのは不安です。 もうプロダクトはいただかなくて結構ですので,最短で返金をお願いしたく思います。 と、中止を伝え、開発作業が終了した。 Xは、その後、文書による催告と件契約の解除を通知し、原状回復請求権に基づいて、支払済

    サイト開発の遅れによる契約解除 東京地判令3.12.3(令2ワ5059) - IT・システム判例メモ
  • 【2022年最新版】3,000人に聞いたWebエンジニアの業務委託単価相場について - Qiita

    こんにちはISSUEを運営している寒河江です。 今回は情報の少ないWebエンジニアの業務委託単価相場について調べてみました。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすればいいか。ISSUEの実績をふんだんに使い記事を書いてみたのでご一読いただけると幸いです。 オリジナルの記事はこちら ISSUE DB 3,000人の実績データから相場を作成 現在(2022年11月)ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があります。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができます。その際の契約時給単価を参考に今回の相場作成の参考にしています。ISSUE上でもリアルタイムの単価相場を確認できますのでご参考ください。 Webエンジニアの業務委託単価相場 わかりやすいように各業務委託単価とその技術能力

    【2022年最新版】3,000人に聞いたWebエンジニアの業務委託単価相場について - Qiita
  • いわゆる受託開発における「プログラミングは簡単な部類」は本当なのか - Qiita

    上記ツイートについて、いわゆる「受託開発企業」で働く私の印象としては、当にその通りだな〜と思います。 そして、これまであまり意識しておりませんでしたが「受託開発における納品(完了)までの各フェーズ出し」をしてみようかと思います。 受託開発における納品までの各フェーズ出し 1. 問い合わせへの返答 「お問合せいただきありがとうございます。それでは早速Webミーティングにて詳細を」 2. 第1回Web打ち合わせ「お互い紹介」編 会社スライドにて自社紹介。依頼内容の確認・質問。 できればここで「依頼内容に対してのざっくりの予算感」をさりげなく聞きましょう。奇想天外な予算を想定しているパターンもあります。 3. 見積もりの作成 できるだけ素早く見積もりを作成し提出すると吉。(早いと喜ばれやすい) 保守費用についても記載してくださいね。(後で聞かれるパターン多い) 見積もり項目は細かい方が信頼度は

    いわゆる受託開発における「プログラミングは簡単な部類」は本当なのか - Qiita
  • 全ベンダーが泣いた!――改正民法のIT業界への影響を徹底解説

    2017年5月に成立し、2020年4月から施行されている改正民法。明治29年の制定から120年ぶりの改正となる件がIT業界に関連する項目は、主に以下の3つだ。 成果物の「瑕疵(かし)担保責任」という考え方がなくなる 請負契約において、約束した成果物を納めなくても、請負人が支払いを受けられる場合が出てくる 成果物の納品を前提とした準委任契約ができるようになる @IT eBookシリーズ 第98弾『「訴えてやる!」の前に読む IT訴訟 徹底解説 vol.4』は、上記3点の詳細とベンダーが心掛けるべきポイントを、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を長年担当してきた細川義洋氏が詳しく解説する。 もちろん、皆さん大好物のIT訴訟解説も盛りだくさん。「プロジェクトが頓挫したので、18億円請求します」「その要件定義、有償だって言わなかったからタダですよね?」「アジャイルだか何だか

    全ベンダーが泣いた!――改正民法のIT業界への影響を徹底解説
  • 自社開発/ 受託企業/ SES•ITエージェントが儲かる仕組み

    この記事は? IT企業の業務形態には大きく分けて自社開発、受託企業、SES(ITエージェント)の三形態があり、それぞれが利益を上げるために日々企業として活動を行なっています。 自社開発: 自社プロダクトのグロースによって利益を上げていく企業。 受託企業: ITプロダクトの開発を請け負いそれによって利益を上げる企業。SESとの違いは請負契約が主体で、契約内容の完了によって利益を上げる仕組みになっている。 SES/ ITエージェント: 主に業務委託形式で各現場にエンジニアの労働力を提供し、そこから得られるマージンによって利益を上げていく企業。 記事では、これらの企業が儲ける仕組みについてそれぞれ概観をしていきます。 著者は? クライアントワークを中心とするソフトウェアエンジニアとして働き、エンジニアの採用活動に関わった経験と、正社員およびフリーランスエンジニアとしての経験がある。 対象読者

    自社開発/ 受託企業/ SES•ITエージェントが儲かる仕組み
  • SES契約における期間途中の撤収の責任 東京地判令3.12.20(令2ワ20021) - IT・システム判例メモ

    顧客からのクレームに納得できず、SES契約の期間途中に(ほかの案件も含めて)要員を撤収させたこと適否が問題となった事例。 事案の概要 X社は、下記の図のとおり、A社、B社、C社からそれぞれシステム開発に関する業務を受託し、それぞれの案件に対応する要員a、b、cを、Y社から調達し、その業務を担当させていた。1カ月当たりの単価を定め、比較的短期間(1カ月から3カ月)の契約期間が定められ、必要に応じて延長、更新が行われていたので、いわゆるSES契約といえる形態だったといえる。 このうち、A社にアサインされたaに関し、A社からパフォーマンスが低いとのクレームを受けたXは、2020年5月8日、Yに対し、A社は契約途中の5月22日を以て解除を希望していることなどを伝えた。 クレームの内容が、「GitRailsのコマンドがわからないレベルだ」などというものであったが、Yは「現場レベルでの作法の話だろう

    SES契約における期間途中の撤収の責任 東京地判令3.12.20(令2ワ20021) - IT・システム判例メモ
  • アジャイルは手段ではないよ。|市谷 聡啓 (papanda)

    今日も今日とて、様々なところで相談を受けている。日中、そこかしこで課題がある。そんな中で寄せられる一つに「アジャイルができない」という話がある。 話を聞いていくと、アジャイルをやりたいのだけど上手くいかない、という。よくある話だけども、そもそも「なぜアジャイルをやりたいのか」を問うと、ごにょごにょし始めてしまう。 なぜアジャイルなのか? になると言葉に詰まる、あるいは通り一遍のフレーズ「変化に対応できるために」しか出てこない。どんな変化のことなのか、対応とはどういうことか? このあたりが言語化できないと、アジャイルを利用しようとしていて、その実、アジャイルという言葉に使われているだけかもしれない。これもよくある話。いわゆるアジャイルをやることが目的になっている。 そんなんじゃダメだから。すぐにアジャイルなるものの意義を確認しよう。 「だから、アジャイルは手段なんだ。あくまで手段なんだ。ア

    アジャイルは手段ではないよ。|市谷 聡啓 (papanda)
  • AIで契約書チェックに「違法の可能性」 揺れる法曹界 法務インサイド - 日本経済新聞

    人工知能AI)を使って契約書の内容をチェックするサービスを巡り、サービスを提供する企業などに衝撃が走っている。政府のグレーゾーン解消制度で適法性が照会され、6月6日に「違法と評価される可能性がある」との回答が出たためだ。同サービスについては以前から弁護士法への抵触を指摘する声があった。今回の照会・回答で既存サービスの提供が止まる可能性は低いとみられるが、デジタル技術で法務をサポートする「リーガ

    AIで契約書チェックに「違法の可能性」 揺れる法曹界 法務インサイド - 日本経済新聞
  • 契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから

    契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから:「訴えてやる!」の前に読む IT訴訟 徹底解説(26)(1/3 ページ) 東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。今回はパッケージソフトを使った開発のトラブルを解説する。契約にない「要件定義」をパッケージベンダーはするべきなのか? 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。前回は、主要な要件が欠落していたために使いものにならなかったシステムをめぐる裁判事例を、新国立競技場の聖火台になぞらえて解説した。 今回は、パッケージソフトをカスタマイズして開発するプロジェクト頓挫の裁判例を解説する。要件定義の責を負うべきは、ユーザーか、SIベンダーか、はたまたパッケージベンダーか? 増加するパッケージソフト導入

    契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから
  • 業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた

    業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた:「訴えてやる!」の前に読む IT訴訟 徹底解説(99)(1/3 ページ) 連載目次 システム開発契約に大切なのは、「要件」と「目的」と……? システム開発契約において、その中核をなすものは言うまでもなく、システムにどのような機能や性能などを具備するかという「要件」であろう。受注者であるベンダーは、この要件を実現することで代金を支払ってもらえる。つまり要件は契約上の「債務」の中核であり、いくら欠陥のないシステムを納品しても、要件を満たさないシステムは「債務の不履行」となり、費用の支払いを得られないばかりか、場合によっては損害賠償の請求までされてしまう。 もっとも、ここでいう「要件」とは、要件定義書に明記されたものだけを指すわけではない。たとえ文書化されておらず要件として定義されていなくても、システム開発契約の目的に照らし

    業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた
  • 質問に答えるだけで著作権契約書が作れるWebフォームが話題 文化庁が作成、その狙いは?

    このシステムの利用者として想定しているのは「著作物の創作や演技・演奏等の実演を職業としない者」と「その利用を職業としない者」、つまり個人同士が契約を結ぶ場合の利用を想定しているという。 文化庁は「著作物の利用形態は多様化し、一次利用の他に、電子媒体などでの二次利用で用いられる場面が増えている」とし「しかしその一方で、一般の人同士は口頭による契約が多く、その後の多様な著作物などの利用に際してトラブルが発生する場合も見られる」と指摘。 一方で、「著作権に関する法律や契約実務の知識がない人にとって、契約書を作るのは容易ではないのが実情」(同)とも説明。このシステムを通して、契約書締結のハードルを下げて文書による契約を推進し、著作物などの利用に関するトラブルを減らす狙いがある。 作ったひな型を使う場合は、作成した内容をよく理解した上で、当事者間で条件を確認、手直しした上で使ってほしいとしている。

    質問に答えるだけで著作権契約書が作れるWebフォームが話題 文化庁が作成、その狙いは?
  • 進化する「納品のない受託開発」

    カジュアル面談って、もっとカジュアルに していいの / informal session #jasstnano

    進化する「納品のない受託開発」
  • プログラミングファースト開発の必要性 - ひがやすを技術ブログ

    ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

    プログラミングファースト開発の必要性 - ひがやすを技術ブログ
  • 「アジャイル型開発と派遣・請負区分」@『労基旬報』2021年10月25日号 - hamachanブログ(EU労働法政策雑記帳)

    去る9月25日、厚生労働省のホームページにひっそりと「労働者派遣事業と請負により行われる事業との区分に関する基準」(37号告示)に関する疑義応答集(第3集)がアップされました。この問題に関心のある人しか気が付かなかったでしょうが、これは昨年来問題となっていたアジャイル型開発と派遣・請負区分に一定の決着をつける文書だったのです。 アジャイル型開発とは、システム開発において、計画段階では厳密な仕様を定めず、小さな単位に分けられた開発を「スプリント」と呼ばれる単位で繰り返して実施し、最終的なシステムを完成させる開発手法です。細部にわたる仕様をすべて決定してから開発工程に進むのではなく、ユーザにとって優先度の高いものから順次開発・リリースして、運用時の技術評価やユーザの反応に基づいて素早く改善を繰り返すことにより、システムの機能同士の結合リスクを早期に解消できたり、システム利用開始までの期間を短く

    「アジャイル型開発と派遣・請負区分」@『労基旬報』2021年10月25日号 - hamachanブログ(EU労働法政策雑記帳)
  • アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021

    アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応

    アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021
  • アジャイル開発を外部委託するときの契約事項をまとめた「情報システム・モデル取引・契約書」を改訂 IPA

    情報処理推進機構(IPA)は2021年10月6日、アジャイル開発版「情報システム・モデル取引・契約書」を改訂した。厚生労働省が同年9月21日に公表した「『労働者派遣事業と請負により行われる事業との区分に関する基準』(37号告示)に関する疑義応答集(第3集)」に関する情報を追加した。これに伴い、「アジャイル開発外部委託モデル契約(解説付き)」も更新した。 アジャイル開発版情報システム・モデル取引・契約書は、IPAが設置した「モデル取引・契約書見直し検討部会」と「DX対応モデル契約見直し検討WG」で検討された、アジャイル開発を外部委託する際のモデル契約についてまとめたもの。アジャイル開発を外部委託する際の契約条項とその解説、補足資料で構成されている。 発注者の意見が反映されるアジャイル開発は偽装請負になる? 改訂の基になった「労働者派遣事業と請負により行われる事業との区分に関する基準」(37号

    アジャイル開発を外部委託するときの契約事項をまとめた「情報システム・モデル取引・契約書」を改訂 IPA