システム開発の契約に関するチップス
海洋ロボコンをやってた人です。
今回はシステム開発で必要な事象としてインプットした内容を備忘録として記載しておきます。
インプット資料のベースは下記書籍になり、不足分や説明の言い回しは公開情報から引用しています。
そのため、この記事の内容は全て調べれば得られる情報の寄せ集めです。（しっかりディフェンスします）
ソフトウェア開発を着手する方に向けて、少しでも参考にしていただけれと思い記載しますので、この記事が読者の方に役に立てば幸いです。
ベースの参考書籍は以下になります。
1. システム開発とは
要件定義 > 設計 > 製造 > テスト > 検収
というフェーズに合わせて実施され、契約の効果は契約の合意で決まり、合意にない事項については民法が適用されます。
したがって、合意は口頭で簡単に取得できるが、拘束力が弱いデメリットがある。
これは
・緊急度が高い・リアルタイムで確認が必要な連絡が電話や通話
・非同期コミュニケーションがチャット
・証拠として形式的に文章に残す必要があるもはメール
・契約や成果物として形式的に書類に残す必要があるものは契約書・所定フォーマット文章
などで紙または電子情報として残す必要あり
流れとしては
・チャットやメールで契約準備の合意
・対面orオンライン会議などで稟議決裁の契約判定
・契約書調印で開発契約の成立
となる
1.1 契約書
以下に基づいて記載することが良い。
-
書かないと債権・債務が特定されない事項
どのような機能システムか、金額・納期 -
書いていなければ民法の規定が適用される事項
支払時期・損害賠償金額・契約解除 -
スクラッチ開発
ひな形を利用せず、0-1でオリジナルのシステムを開発する -
パッケージ開発
既存のパッケージを利用するので、開発が早く、安いというメリットあり -
対象PJの責任者、主任担当者を記載し責務分担を明文化
PJ管理リーダー(旗振含む)、各機能リーダー、メンバーなども明記すると円滑 -
承認プロセス
受発注のそれぞれで承認プロセスを設けることで、要件定義などのインプットと、それに対する成果物・アウトプットの責務分界点を分けることが可能 -
著作権の所在
特にソフト開発は構造的に最終的にどこに帰属するかが大切：無方式主義
反対に特許権はアイデアを保護するもので、方式主義 -
その他
見積書、発注書、請書がある
基本契約書とは企業間で反復・継続して行われる取引に対して基本的な取り決め事項をあらかじめ定めたもの
1.2 押印
押印を行う理由は、相手から承認していないと言われるリスクを排除するためで、民法にも押印に関する規定がある。
新規契約時はこの押印や稟議決裁のプロセスが何重にもなること多くボトムダウンを例にすると
提案者 > 先輩社員 > リーダ > 課長 > 室長 > 部長 > 事業部長 > 役員
という承認プロセスが考えられる（あくまで一例）
なので、新規契約の提案などは組織の利益とビジョンからトップダウンで落としていくのが効果的である。
1.2 RFP・RFI・RFQ
クラウドやソフトウェア利用については提供者と利用者で契約を交わすのではなく、利用規約によって契約関係が決まる OSSとかは正にこれに該当
2. 契約体裁
2.1 請負契約
- 仕事の完成が目的
- 仕事の完成が責務
- 成果物に対しての報酬
2.2 準委任契約
- 委託された業務が目的
- 委託業務の遂行が責務
- 労働時間に対して報酬
- アジャイル、ウォーターフォールなどソフトウェア開発では増加傾向
違いは2点
- 想定工数までに成果物が完成するか・しないか
- その場合の責任を負うか否か
請負の場合は期限までに完了できない場合は損害賠償責任を、準委任の場合は受注者側に債務違反があれば損害賠償責任を負うことになる。
2.3 プロジェクトマネジメント義務
端的に言えば
- メーカー側
システムの依頼側
開発ベンダーからのプロジェクトマネジメントは尊重し協力するという協力義務がある
準委任の場合は、下記に記載があるように管理義務がある（※ 契約形態によって異なる）
- 開発ベンダー側
システムの受注側
PJ推進責任はベンダーが負うという、プロジェクトマネジメント義務がある
情報システム・モデル取引・契約書は
にも記載があります。
このプロジェクトマネジメント責務は、メーカー側とベンダー側で見えている視座が180°ほど異なるので、進捗確認やコミュニケーションは本当に大切だと思います。
2.4 責務分担
RACI（レイシー）マトリクスを用いたスクラム開発として責務分担の見えるか、分担をしてそれぞれの役割を明確にします。
・R: Responsible 実行責任者, タスク遂行に責任を持つ人
・A: Accountable 説明責任者, タスクの成果・結果の説明に責任を持つ、承認者的役割
・C: Consulted 協業先, 相談やサポートを担う人
・I: Informed 報告先, 成果・結果の報告を受ける役割で社内なら管理部門、社外なら顧客
他にも
・S: Support サポート役,
を追加したRASIC
・V: Verifies 検証者
・F: Facilitator ファシリテーター
を追加したRACI-VS
などがあります。
3. ソフトウェア開発基本契約書
ソフトウェア開発基本契約書は
要件定義、外部設計、内部設計、プログラミング、単体テスト、結合テスト、導入・受入支援、運用テスト
これらの期間で準委任と請負を多段階で決めて契約する
3.1 要件定義書
要件は大きく2つに分類される
-
機能要件
要求を満足するためにソフトウェアが実現する要件 -
非機能要求 (NFR:Non Functional Requirement)
機能要件以外の全ての要素に必要な要件
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類
3.2 委託料
いくらの金額を、いつまでに、どのように支払うかを合意する
また、費用負担の内訳も明示的にする。
例えば、経費としていくらか、消耗品はいくらか、外注費（売上原価）はいくらかなど
3.3 作業期間、納期
契約に際して、見積の作業期間、納期、工数、人月などを定める
工数計算は以下参照。人工単位もある
3.4 業務完了報告
準委任契約の場合は、仕事の完成が目的とならないので、研修という概念がない。
そのため、作業期間にした仕事のエビデンスを明確に定めるべき。
例えばアウトプットとして、要件定義、外部設計、内部設計、プログラミングの成果物など
3.5 検収
納品物に対して、内容を点検し受け取ること。
検収を行うことで、システム開発が最後の工程まで完了したことを確認する。
ただ、これは不具合が全くないことを確認することではなく、「最後の工程」が完了したかを見ることを意味する。
つまり、バグがある場合はテスト工程が完了していない評価に該当し、検収の意図とは異なる。
仮にテスト工程の成果物に対して開発ベンダ、メーカーの双方が調印しており、検収後にバグが見つかった場合でも、契約不適合責任が問われる
4. 秘密保持契約：NDA
Non-Disclosure Agreementの頭文字をとってNDA契約とよく言われる。
企業や組織、共同研究先、個人間で重要な情報を共有する際に、情報の漏洩を防ぐために締結される契約。
詳細は下記。
また、NDAは機密情報を含むため、企業や組織の情報セキュリティポリシーに基づき、アクセス制限や取り扱いのルールが定められ、厳重に管理されるのが一般的。（下記参考）
IPAにテンプレートもある。
5. システム開発関連のReference
契約に関する主題とはかけ離れますが、Zennでシステム開発で調べるとクリティカルな内容を学ぶことができます。
下記、私がメモしておきたいリンクを記載しました。
開発ツールとかまとまっているのでとても勉強になりました。
表題の通り、システム開発フローがとても勉強になりました。
以上です。
Likeいただけると大変励みになりますので、よろしくお願いいたします。
Discussion