タグ

契約に関するtjun1のブックマーク (5)

  • 【PublicNotes特集】COCOAはなぜ機能しないのか(前編)~パーソルとの契約を「変更」した経緯~|一般社団法人PublicMeetsInnovation(PMI)

    【Public Notes】とはミレニアル世代のシンクタンクPublicMeetsInnovationがイノベーターに知ってもらいたいイノベーションとルールメイキングに纏わる情報をお届けする記事です。 PublicMeetsInnovationでは、2020年7月13日オンラインイベント「NEW PUBLIC 〜ルールはつくれる、変えられる。イノベーションを社会実装するために 」を開催し、コロナの感染を抑える一つの手段として、COCOAをはじめとするテクノロジーの利活用の可能性を議論しました。 それから半年が経ち、感染抑制におけるCOCOAの効果について様々な議論がされている中、稿では、改めてその政策決定プロセスと効果を検証するとともに、感染拡大抑制のためのテクノロジーの可能性と課題を考え今後のアップデートの方向性について考えていきたいと思います。 新型コロナウイルス接触確認アプリ(CO

    【PublicNotes特集】COCOAはなぜ機能しないのか(前編)~パーソルとの契約を「変更」した経緯~|一般社団法人PublicMeetsInnovation(PMI)
  • 要求仕様戦争(その1)

    ■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100%はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ(しかも部分的だ)。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体

    要求仕様戦争(その1)
    tjun1
    tjun1 2013/02/15
  • 受託開発/議事録の証拠能力のウソ・ホント

    システム開発をめぐる契約は、年々複雑さを増している。クラウドを使ったシステム開発やアジャイル開発のプロジェクトなど、開発手法や技術の変化で契約の仕方が分かりにくい場面が増えている。開発契約に携わる法務担当者や現場担当者、弁護士などへの取材を基に、今現場が知っておくべき開発契約の知識を、「ウソ」と「ホント」で解説する。 今回は、受託開発と裁判における議事録の証拠能力についての「ウソ」と「ホント」を取り上げる。 請負でも委任でもない受託開発がある 受託開発で個別にシステムを開発するが、その開発費を請求せず、SaaSの利用料で稼ぐ開発ベンダーが登場し始めた。 受託開発でありながら、請負契約でも準委任契約でもない契約形態のサービスを提供する企業が登場している。永和システムマネジメントの「価値創造契約」、ソニックガーデンの「納品のない受託開発」がそれだ。 両社のサービス内容は共通している。まず、発注

    受託開発/議事録の証拠能力のウソ・ホント
  • Web系フリーランスをモンスタークライアントから守る契約書【テンプレートあり】

    契約書なしの口約束でお仕事を受けてませんか? 自分はまだ駆け出しのフリーランスだから…… クライアントへ契約の手間を与えてしまうから遠慮しちゃう…… 契約とか法律とかよくわからないから…… などなど、理由は様々あるのかもしれません。 でも、契約書なしで案件を受けていると必ずいつかトラブルが起きますよ。 例えば、代金以上の労働を求められたり、お金を払わず逃げられたり。 ボクも12年間、ウェブ制作業に関わってきてますが、残念なことにこうした契約に関わるトラブルをいろいろと経験しました。 確かに、契約書を自分で作るのは難しいです。行政書士へ契約書の作成を依頼するとかなりお金がかかります。 でも、契約書がたった1枚あるだけで、クライアントと友好的な関係を長く築けるのも事実です。 この記事のタイトルには「モンスタークライアントから守る」と書きました。 実際は、契約書は制作を受ける側のあなただけを守る

    Web系フリーランスをモンスタークライアントから守る契約書【テンプレートあり】
  • 著作権/アジャイル開発契約のウソ・ホント

    システム開発をめぐる契約は、年々複雑さを増している。クラウドを使ったシステム開発やアジャイル開発のプロジェクトなど、開発手法や技術の変化で契約の仕方が分かりにくい場面が増えている。開発契約に携わる法務担当者や現場担当者、弁護士などへの取材を基に、今現場が知っておくべき開発契約の知識を、「ウソ」と「ホント」で解説する。 今回は、共同開発したSaaSの著作権と、アジャイル開発の契約における「ウソ」と「ホント」を取り上げる。 共同開発したSaaSの著作権は発注者が持つ 著作権は発注者と受注者が協議して、どちらかあるいは両者が持つことを決める。SaaSの場合は受注者が持つことが多い。 複数のユーザー企業が共同利用するSaaS(Software as a Service)の開発を委託する事例が出てきた。このような場合、発注者と受注者が協議して、成果物の著作権をどちらかあるいは両者が所有するかを決める

    著作権/アジャイル開発契約のウソ・ホント
  • 1