日本におけるソフトウエア契約の問題
ソフトウエア契約でなぜ揉めるのか。それは、相手が存在するからである。ソフトウエア開発プロジェクトが開始すると、そこに物理的には存在しない「責任」というものが生まれる。プロジェクトが混乱したとき、この責任は突然誰からも嫌われ、相手への押し付け合いが始まる。 日本では、ユーザー企業がソフトウエア開発をSIベンダーに請負契約で委託する場合が多い。請負人であるSIベンダーに、完成責任が伴う契約だ。 請負契約は、ユーザー企業にとっては完成責任まで委託できる一方、SIベンダーは努力次第で利益を増やせる。そのため両者にとってメリットの高い契約といえる。 ところが順調に進んでいたプロジェクトで予定通りに成果物が完成しなかったり、希望する成果物と実態に乖離が生じたりすると、ユーザー企業とSIベンダー間で争いとなる。 これは、現在の日本におけるソフトウエア契約のあり方に起因する問題だ。日本では現在、ソフトウエ
次のアジャイルソフトウェアプロジェクトに使える10の契約
2009/4/29 by peterstev 以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 ソフトウェア開発プロジェクトの最初の頃というのは、顧客であれサプライヤ であれ、口約束だけでいろんな仕事をやらなくちゃいけない。契約書とは、言っ てしまえば、競技のルールがだらだらと書かれてあるものにすぎない。ルール が正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げ てしまう。それでは、アジャイルプロジェクトに使える競技ルールにはどんな ものがあるのだろうか？そして、最も適したルー
情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか
こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな
ディレクターが押さえておきたい営業取引の基本的な流れと頻出ワード : LINE Corporation ディレクターブログ
こんにちは、小久保です。 私の経歴は、受託開発のディレクター → 自社媒体のディレクター → 事業責任者 という流れを経ておりまして、以前「受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは？」という記事を書きましたが、実はキャリアパスの中で一番焦ったのが営業面での知識不足でした。 受託開発を担当している時は、開発工数と人月単価さえおさえておけば渉外対応はある程度事足りていたのですが、自社メディアの場合だと提携内容の検討と営業的な話は一体となって進むことが多く、必然的に営業的知識が必要になってきました。 今回は、営業職の経験が無いディレクターの方でも、ビジネス上で最低限これだけは知っておいたほうが良いと思う、営業面での知識について紹介します。 まずは、一般的な取引成立までの流れをまとめてみましょう。以前、弊社の「ビジネススキル勉強会」というブログに「取引行為についての勉強
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/files/000004091.pdf
https://www.ipa.go.jp/files/000005404.pdf
日本におけるアジャイル開発に適した契約モデル案と事例：IPA 独立行政法人 情報処理推進機構