「契約書に『システム保守サービスを提供する』と書いてあるから、全部含まれているんですよね？」実際には違うことに、何か起きてから気づきます。障害が起きた日に電話をすると「明日確認します」と言われる。バックアップについて聞くと「契約書にバックアップするとは書いていません」と言われる。ベンダーを変えようとすると「コードは弊社の知的財産です」と言われる。どの答えも契約書の文言には反していません。契約書自体が何も明確にしていないからです。だまされたのではなく、契約した日に誰も細部まで詰めようとしなかっただけです。以下の 4 つの箇所は、サインする前に一字一句確認すべき部分です。
曖昧な契約は双方にとって楽です。契約時に細部を詰めなくてよく、雰囲気も悪くなりません。しかし代償は後からやってきます。
プログラムがわからなくても外注をうまく管理する方法という記事で、外注管理に必要なのは技術知識ではなく、ルールを明確にすることだと説明しました。契約書はそのルールそのものです。保守費用の 3 つの算出方法という記事で、契約でまず見るべき 4 か所に触れましたが、本記事ではそれぞれを詳しく展開します。
手元の契約書を、真ん中の列と照らし合わせてください。当てはまるものがあれば、そこが交渉すべき箇所です。
| 確認する箇所 | よくある曖昧な書き方 | 求めるべき書き方 |
|---|---|---|
| 対応時間 | 速やかに対応、合理的な期間内に返答 | 2 つの状況ごとに明確な時間を定め、何をもって「対応」とするかも定義する |
| 更新頻度 | 必要に応じて更新 | 頻度の下限を明記し、緊急の脆弱性は別途対応と定める |
| 解約条件 | 1～2 年契約、途中解約は残り月数分を支払う | 月単位の請求、いつでも解約可能、通知は最長でも 1 か月前 |
| ドキュメントの帰属 | 乙は必要な技術文書を提供する | 終了時に引き渡す一覧を明記し、契約期間中はいつでも閲覧可能とする |
対応時間が保証するのは「誰かが対応しているかどうか」です。確認すべきは次の点です。
更新頻度は目に見えないリスクを管理するものです。基盤となるパッケージには次々と脆弱性が見つかり、脆弱性が公開されると攻撃ツールはすぐに現れ、しかもネット全体を自動でスキャンします。確認すべきは次の点です。
解約条件はベンダーを変えるコストを左右します。保守は長期的な関係であり、長期であるということは、いつか予算の変化などの理由でベンダーを変えたくなる可能性があるということです。確認すべきは次の点です。
ドキュメントの帰属は、次の担当者がゼロから掘り起こす必要があるかどうかを左右し、その掘り起こしの費用はあなたが負担することになります。契約書には最低限、終了時に次のものを引き渡すと明記すべきです。
これは弊社と契約してほしいという話ではなく、比較の基準を提供するものです。この 4 項目をどのベンダーにも聞いてみてください。答えられるところだけが、交渉する価値があります。
契約が明確になった後に残るのは、それを本当に実行する人がいるかどうかです。Nerdtechnic は Helper CTO として御社のシステムを引き継ぎ、保守します。会社の技術責任者のような存在でありながら御社の社員ではなく、この約束は契約書に明記されています。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3～5 営業日以内に、読んですぐわかる 1 ページのレポートをお渡しし、そのうえで契約するかどうかご判断いただけます。今お手元の契約書が「システム保守サービスを提供する」だけのものであれば、まずはこちらからどうぞ：Helper CTO：システム保守プラン。
業界トレンド
技術責任者がいない会社では、システムの決定が経営者、外注ベンダー、社内でいちばんパソコンに詳しい人のところに落ちてしまいがちです。本記事では Helper CTO がやっている 4 つのこと、コンサルタント・人材派遣・一般的な外注との違い、なぜ同じチームであることが最も重要なのか、システム健診から始める方法を解説します。
業界トレンド
システム稼働後に「月いくらかかるか」と聞いても、直接的な答えは返ってきません。保守費用は数字そのものより構造が重要だからです。本記事では都度課金・固定月額・月額＋開発投入の 3 つの料金体系を表で比較し、月額費用に何が含まれ何が含まれないか、契約前に確認すべき 4 つのポイントを解説します。
業界トレンド
多くの中小工場は今なお Excel とベテランの勘でスケジュールを組み、機台遊休・緊急割込み・納期遅延の悪循環に陥っています。本記事は Deloitte の調査と PlanetTogether などの実例を用い、納期遵守・稼働率・在庫・ROI のレンジを定量化し、導入の約半数が失敗する三つの落とし穴を解説します。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
