タグ

契約に関するjoltkunのブックマーク (7)

  • 急増、「開発費不要」の受託開発

    開発費を求めずに、顧客の要求どおりのシステムを開発する――。そんなビジネスモデルを採用する受託開発会社が増加している。ユーザー企業はシステムを利用した期間や、システムを使って得られた売り上げに応じて対価を支払う。ユーザー企業のリスクを軽減すると共に、ベンダーのモチベーションを上げられるという、受託開発の新形態をレポートする。 (中田 敦) 記事は日経コンピュータ4月28日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。「クローズアップ」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。 なお号のご購入はバックナンバーをご利用ください。 「ネット直販を、初期コストゼロで始めることができた」。そう語るのは、大阪市の印刷会社、新進社の高橋孝一常務取締役だ。同社のネット直販システムは、受託開発会社のバズーが、初期

    急増、「開発費不要」の受託開発
  • システム開発に欠かせない見積もり前提条件について | DevelopersIO

    こんにちは!おおはしりきたけです!今日はシステム開発に欠かせない見積もり前提条件について書きたいと思います。 ■はじめに 弊社では、受託開発を多くやっております。受託開発は、最初のスタートが重要です。私見ですが最初のスタートで成功確率の80%は決まっているといっても過言ではないと思っております。そのくらいスタートというのは大切だと思っております。エンジニアの方々の中には、営業さんが「あとはヨロシクッ!」と言って金額しか決まっていないプロジェクトを経験し苦い思いをした方も多いのではないでしょうか。弊社では、そのような事が起こらないよう営業さんとは密な連携を取りプロジェクトが成功可能かという判断をし、成功可能なプロジェクトに対し開始するということを行っています。その作業の中でも特に重要なのは、見積もりの前提条件です。 ■なぜ前提条件が必要か 見積もりを出すときの流れは大まかにいうと以下のように

  • 「社員着服のつけ」下請けに 楽天モバイルが契約解除で経営危機 | 毎日新聞

    楽天モバイル社員による46億円着服疑惑の影響で、下請け企業が経営危機に陥っている。楽天がその社員と関係の深かった取引先との契約を解除したため、そこに連なっていた下請けの資金繰りが連鎖的に悪化しているのだ。発注元の不正が、立場の弱い下請けにしわ寄せされた格好だ。 楽天モバイルが、不正に関わった社員の解雇を発表したのは2022年9月2日のことだった。関係者などによると、この社員は取引先である物流会社「日ロジステック」(東京都千代田区)と「TRAIL」(港区)の2社の役員らと共謀し、コンサルティング料などの名目で楽天モバイルに水増し請求していたとされる。損害は46億円に上るとみられる。不正発覚を受け、楽天は2社との取引を停止した上で裁判所に預金口座の仮差し押さえを申請し、認められた。 「楽天モバイルから契約を解除された」「明日からは仕事は休みになります」

    「社員着服のつけ」下請けに 楽天モバイルが契約解除で経営危機 | 毎日新聞
  • 見積・提案書に書いておくと不幸を減らせる前提条件

    はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません(うろ覚えで書いてたり、大人の事情) これを流用しておこったすべての事項について、何らかの責任をとることはできません 稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

    見積・提案書に書いておくと不幸を減らせる前提条件
  • アジャイル開発に向けたITベンダーとの契約の結び方【第6回】

    前回、デジタルシフトのためのプロジェクトを成功に導くためには、パートナーたるITベンダーを見つける必要があると指摘し、そのためには事業会社が自発的にITベンダーを探さなければならないとしました。今回は、新たに見つかったITベンダーへ発注する際の契約内容について考えます。 前回、デジタルシフトに向けたITベンダーを探すためには、事業会社が積極的にカンファレンスや技術者が集うセミナーなどに参加し、技術トレンドを把握してITベンダーと対等に話せるようになる必要があるとお伝えしました。 そのようにして、眼鏡にかなうITベンダーが見つかれば、ソフトウェア開発の契約を結ばなければなりません。アジャイル開発に適したITベンダーとの契約は、どのようなものであるべきでしょう。 一括請負契約はアジャイル開発には根的に向いていない ソフトウェアの開発契約は大きく、(1)一括請負型契約、(2)準委任型契約の2種

    アジャイル開発に向けたITベンダーとの契約の結び方【第6回】
  • アジャイル開発契約は契約不適合責任を負うか?|コウモリIT法務

    「ソフトウェア開発における請負契約と準委任契約の違い」で請負契約と準委任契約の選択をわけるのはなにか、ということを書きました。 その中で、「準委任契約は主に善管注意義務を負い、請負契約は完成義務と瑕疵担保責任を負います。」と書きましたが、これはいったい何なのか、ということを書こうと思います。 なお瑕疵担保責任は民法改正で「契約不適合責任」に改められました。 民法の構造はじめに、民法は以下のような構造になっており、上位の階層の定めは下位の階層すべてに適用されます。 編 └章 └節 └款 └目 請負契約、準委任契約の位置づけは以下のようになっています。 第3編 債権(399条〜724条) └第2章 契約(521条〜696条) └第9節 請負(632条〜642条) └第10節 委任(643条〜656条) ※準委任と委任は同じものと捉えてください。 瑕疵担保責任・契約不適合責任とはなにか?両者はと

    アジャイル開発契約は契約不適合責任を負うか?|コウモリIT法務
  • 秘伝のソースは門外不出。お客さまには差し上げません

    秘伝のソースは門外不出。お客さまには差し上げません:「訴えてやる!」の前に読む IT訴訟 徹底解説(40)(1/3 ページ) システムの開発を発注した会社が廃業することになった。今後のメンテナンスのためにソースコードの引き渡しを求めたが、契約書で約束していないからと断られた。よし、訴えてやる! 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。前回は「請負契約で実施したソフトウェア開発では、要件定義書やテスト結果の納品が必須であるか」について裁判所が下した判決を取り上げた。 裁判所は「納品したシステムが当に契約の目的を果たすものであったかどうかを判断する上でも、これらのドキュメントは必要である」との判決を下したが、多くの読者から、「そもそも、なぜこれらを納品物とすることを契約書に明記しなかったのか」という声が寄せられた。 もっともな意見である。私も納品物を明記し

    秘伝のソースは門外不出。お客さまには差し上げません
  • 1