開発契約書に記載すべき事項＆ SLAで注意すべき点 [まぐまぐ！]

2006/12/25

開発契約書に記載すべき事項＆ SLAで注意すべき点

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
IT法務入門（効果的なIT契約書やSLAの積極的導入）　第４号
（旧タイトル　IT法務入門　Win-Winになるためのシステム関係の契約書作成講座）　　　

　　             発行　壇一雄行政書士事務所
                 http://www.dan.jimusho.jp/index.htm
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　
　このメルマガは、システム開発・運用の現場で活躍されている技術者の
方や、ユーザ部門の方を対象に、IT法務の入門として、契約書やSLA等
を通じてベンダー・ユーザ企業双方がWin-Winの関係を築いていけるかを、
ポイントを絞ってお伝えしていきます。

　なお今号より、内容を契約書だけでなくIT法務全般やSLAについても充実
させていきたいという思いもあり、タイトルを
『IT法務入門（効果的なIT契約書やSLAの積極的導入）』に変更致しました。
今後ともよろしくお願いいたします。

………ＣＯＮＴＥＮＴＳ………………………………………………………………
１．開発契約書に記載すべき事項
２．SLAについて注意すべき点
________________________________________________________________________
１．開発契約書に記載すべき事項

  ソフトウェア開発は、ユーザから委託を受けてベンダーがシステムを開発・納入
し、ユーザーが代金を支払うという取引です。
　契約形態としては、請負契約または委任契約で行われることが一般的です。

　ソフトウェア開発は主に、
　１．ユーザとベンダーが共同で仕様を策定する工程、
　２．策定された仕様によりベンダーが実際に開発する工程に分けられます。
　そのため契約としては、ひとつの開発契約で全てまとめるだけでなく、
　『基本契約＋各個別契約』という構成でまとめる場合もあります。

　まとめ方は色々ありますが、システム開発の契約書として特に留意する事項と
　しては以下のような項目があります。
　　・開発内容
　　・開発工程の定義
　　・成果物
　　・仕様の確定／変更
　　・納品
　　・検収条件
　　・瑕疵担保責任
　　・知的財産（著作権、著作人格権の扱いはシステム開発においては重要な意味を
　　　持ちます）等。
　　・損害賠償
　
　　等の留意事項は双方合意しておかないと後々問題になることがあります。
　　特に、著作権等の知的財産権と損害賠償額については、双方思いがありますので、
　　なかなか合意に達しずらい項目です。またそもそも開発内容などは契約時に明確に
　　なっていないほうが多いので、それに対するリスク対応を考慮する必要がありま　
　　す。

　契約書の構成としては、
　　契約の主目的を定める『主たる法律関係』、
　　決めておかないと『主たる法律関係』がうまく回らない『従たる法律関係』、
　　そして『一般条項』
　　の構成でまとめていけば、契約の漏れなどを防ぐことができます。

　【主たる契約関係】
　　契約の主目的を定義します。
　　『誰と誰が』、『何について（契約対象はなに）』、
　　『どういう債権債務をおうか』、『いつまでに』などを定めます。
　　　ただし、契約対象を明確に定めることは難しい場合もあります。

　【従たる法律関係】
　　　主たる法律関係を実現するために必要な事項を定義します。
　　　・仕様変更への対応方法
　　　・情報提供方法、会議体
　　　・検品方法、知的財産権の移転方法　等

　　　・瑕疵担保への対応
　　　・知財補償条項　　等

　　　・納品物の他社への転用　等

　【一般条項】
　　　・解除条項
　　　・権利義務譲渡の禁止
　　　・損害賠償
　　　・合意管轄
　　　・仲裁　　等

　上記をうまく盛り込み、リスクプランニング（リスク対応の工夫）とパフォーマンス
　プランニング（履行円滑化の工夫）が十分考慮された契約書にしていく必要がありま
　す。

________________________________________________________________________
２．【トピックス】SLA（Service Level Agreement）について注意すべき点
　最近運用部門などでSLAを締結する企業が徐々に増えてきました。そのこと自体
いいことだと思いますが、目的を誤るとなんのためのSLAかわからなくなるので、
注意が必要です。
　そもそもなぜSLAを導入するのでしょうか？。いろいろ理由があるとは思いますが
要はITサービスの品質を維持/改善するために導入するのが本来の目的ではないで
しょうか。
　決して目的を達成できなかった場合のぺナルティを定義するのが、目的ではありません。
サービスの提供者と利用者双方で、ITサービスの品質を維持/改善する活動の指標とし
て利用していくのが望ましい姿といえます。そういう意味では、導入当初はペナルテ
ィは盛り込まないほうが、建設的なSLAが合意されるのではないでしょうか。
　ITサービスを維持/改善するのに必要な項目である、「サービスレベル項目（Service
Level Objective：SLO）」を明確化し、SLOの計測・記録・分析を継続的に実施し、
サービスレベル管理（SLM)を行っていくことが重要です。そのためSLAの値も一度決め
たらそのままにしていくのではなく定期的に見直し、常に品質の維持/改善につながる
PDCAサイクルをまわしていくことが大事なのです。（SLMの実現の為に、SLAを使う）
　SLAを導入する場合、合意したサービスレベルであるSLAだけ決めるのではなく、そ
れを用いて品質向上につなげる管理方法（SLM）も構築しなければ、効果よりも、SLA
構築に労力のみかかり、生産的な話ではなく、双方とも疲労感だけ得ることになる可
能性すらありますので注意が必要です。
　
________________________________________________________________________
　当メルマガは、法律問題の解説にあたり、十分な調査を踏まえた上で発表
　しておりますが、読者がこれを実行されるにおいては、一切責任を負いま
　せんので、ご注意ください。　　　　
________________________________________________________________________
IT法務入門（効果的なIT契約書やSLAの積極的導入）
    発行システム：『まぐまぐ！』 http://www.mag2.com/
    配信中止はこちら http://www.mag2.com/m/0000214826.html
________________________________________________________________________

発行者　壇一雄（システム監査技術者、ITコーディネータ、PMI認定PMP)
　　　　壇一雄行政書士事務所
        URL     http://www.dan.jimusho.jp/index.htm　
        E-Mail  info@dan.jimusho.jp
________________________________________________________________________