システム自体や作成文書に不備がないことをベンダーに必ず保証してもらいたい場合、契約形態は「請負契約」が適しています。そうでないものは「準委任契約」とします。
「委託範囲」で依頼したい提案の「概要」を定義します。「案件目的」「業務概要」「システム化の範囲」「全工程のスケジュール」が当たります。
「契約委託範囲」「機能、非機能要件」「作業要件」も明文化します。
上記は、必須記述項目です。提案書にどんなプラスアルファを盛り込んでくるかはベンダー次第ですが、最低限の水準は必ず示しましょう。
「納品成果物」は、契約後の「成果物一覧」と、その「納期」です。
納品成果物の「検収方法」もRFPで指定しましょう。「工程ごとの成果物(検収物)」を指定し、「ユーザー承認に要する期間」も示します。
「体制、役割分担」では、委託業務を推進する体制、委託者と受託者の役割/責任分担を定義します。
「体制図」「役割分担表」「再委託(二次請け以降)の扱い」を指定し、「現場管理責任者」の提示を求めます。
重要なのは、委託するユーザー企業がベンダーをどれだけ主体的に管理できるかです。
多重請負構造では、ユーザーやプライムベンダー(直接契約する一次請けベンダー)の統制が現場の二次請け以降のメンバーにまで浸透しないことがあります。これを防ぐため、「参画メンバーはプライムベンダーとその協力会社(二次請け)までに限る」という制約を設けることもあります。
「スケジュール」は、委託業務の「実施スケジュール」を定義します。
「マスタースケジュール」「マイルストーン」「各タスクの終了条件」を指定し、「順守すべき期日」をベンダーに示します。
各マイルストーンの達成承認における「合意形成のリードタイム」と「段取り」は、可能な限り明確化しましょう。意思決定の合意形成に1カ月必要なら、それに関係するマイルストーンは実質1カ月前倒しで設定しなければなりません。
Copyright © ITmedia, Inc. All Rights Reserved.