契約更新タイミングは、システム導入費用や進め方を見直す絶好のタイミング

2025-12-09 2026-01-15

itpjstudy

ユーザ企業とITパートナの双方にとって、契約更新は重要なイベントです。特に、プロジェクトが難航して、費用が増えているときは、なおさらです。ユーザ企業でもITパートナでも、お互いの上層部に、プロジェクト継続にOKを出して貰うために、四苦八苦しているのではないでしょうか。

しかし、お互いの会社の上層部からOKを貰うことにばかりに力を割いて、本質的・構造的な問題にメスを入れられずに、そのままプロジェクトが進むケースも少なくありません。今回は、契約更新のタイミングを利用して、どうプロジェクトをよくしていくのかについてお話します。

契約更新は、システム導入費用と進め方を見直す好機である

大規模プロジェクトの場合、金額規模も大きく、期間も長いです。そこで、大きなフェーズごとに、契約を刻むことが多いのではないでしょうか。

実際、前フェーズで定義・作成した内容をもとに、後続フェーズの進め方や体制・費用が変わってくるため、フェーズごとに契約をしていくことは、合理的です。多くの場合、そのタイミングで、費用増を抑えるために、スコープや作業内容の調整を行います。

要件定義での検討の結果、プログラム開発が当初想定100本から120本に増えました。そのため、設計フェーズ以降の費用が増えます。

プロジェクトの予算は限られているので、それだけの費用増となるのは困ります。業務チームと再調整して、プログラム開発を減らしましょう。

上記は、開発スコープのお話でしたが、他にもフェーズが変わるタイミングで、確認しておきたいことは沢山あります。プロジェクト現場の日々の進め方のためにも重要ですが、費用やリスクといったマネジメント観点でも、重要です。

プロジェクトの骨格を確認することで、費用を適正化するだけでなく、プロジェクト運営を円滑なものにする

下記は、契約更新タイミングで、確認しておきたい内容です。基本的に、プロジェクト現場で、次フェーズ開始前に確認する内容と同じです。つまり、フェーズ毎の運営方針や進め方、体制を確認することが、費用の適正化にもつながっていくのです。

主な確認内容

役割分担	ユーザ企業とITパートナの責任範囲が明確化できていないと、発生費用の帰属について合意できない
スコープと変更管理	何が契約範囲なのかが明確でないと、費用に含まれる作業対象の認識に齟齬が発生してしまう。また、作業範囲を追加する手続が無ければ、必須のものであっても追加できない
開始/終了条件と、検収基準	条件や基準が合意されていないと、いつまでも作業が完了できなくなったり、費用請求できなくなったりする
体制	参画メンバによって、作業品質、作業ボリューム、責任が取れる内容に差が出る。お互いの体制が適切であることが確認されていなければ、想定外の費用増につながりやすい
リスクと前提条件	リスク認識を共有して、問題発生時に、誰がどのように対応するのかが合意できていなければ、責任転嫁の議論に陥りやすい
契約形態と精算方法	準委任か請負かなどの契約形態により、ITパートナの責任を取り方が変わってくる

ここまでは、皆さんのプロジェクトでも、普通にやっていることが多いのではないでしょうか。プロジェクトの現場でも、現フェーズの総括、次フェーズの計画説明などを通じて、上記のような内容を整理していると思います。

そのなかで、費用についても議論され、次フェーズの費用についても合意して行っていると思います。

プログラム本数を減らせるかどうか、業務ユーザ含めて議論しましたが、すべて必要だとの結論でした。そのため、費用増は避けられない状況です。

そうですか。どうしても必要ということなら、仕方がないですね。予算を増やして貰えないか、役員会議に付議します。

だいぶ簡略化して書いていますが、多くのプロジェクトで似たような会話があるのではないでしょうか。そして、多くの場合、ユーザ企業のプロジェクトリーダやマネジメントは、モヤモヤした気持ちを抱えたまま、契約締結を行っているのではないかと思います。

どうやって、そのモヤモヤを解消するのか。その点について、掘り下げます。

契約交渉ミーティングは、ユーザ企業とITパートナがそれぞれの立場で議論できる機会である

一般的に、プロジェクトでは、ユーザ企業とITパートナの立場を超えて「ワンチーム」で物事を進めなければなりません。そのため、それぞれの責任問題になるような話は避けられがちです。その結果として、本質的・構造的な課題について議論ができないままになってしまう傾向にあります。

一方で、契約交渉のための会議は、通常のプロジェクトの会議とは異なり、ユーザ企業・ITパートナのそれぞれの立場で意見を交わす場です。つまり、多少の軋轢は生じるかもしれないが、普段は議題にしづらいトピックを持ち込める場なのです。

その点、ITパートナは百戦錬磨ですから、巧みにそういった場を利用してくることが多いです。

例えば、ユーザ企業側のスキルや人数や不足しており、ITパートナの負担が大きくなっているような状況があれば、契約交渉の場を使って、ITパートナ側の体制増強（＝追加費用）を提案したりします。

一方、ユーザ企業は、それほどうまく立ち回れていないように見受けます。ただ、これはユーザ企業とITパートナの立場の違いに起因するもので、なかなか変えるのは難しいと考えています。

過去のプロジェクト経験や、プロジェクトに関する情報量などでは、ITパートナが格段に多くを持っています。また、契約交渉が決裂して、プロジェクトが中止や停滞したときのダメージも、ユーザ企業の方がはるかに大きいです。なぜなら、不退転の覚悟で、全社DXプロジェクトをやっている場合などは、止めるわけにいかないからです。

結果として、ユーザ企業は完全には納得してないものの、ITパートナ寄りの結論で妥結することが多いように見受けます。

ITパートナには、プロジェクトの伴走者としての説明責任がある

まず、基本的な理解として、ITパートナには、ユーザ企業への説明責任があります。また、ユーザ企業には、ITパートナに説明を求めてよい立場にあると思います。なぜならば、ユーザ企業にITプロジェクトの知見・経験が不足するなか、多くのITパートナが「プロジェクトの伴走者として、ユーザ企業を支援する」という立ち位置でプロジェクトに関わっているからです。

ユーザ企業は当然「このITパートナだったら、プロジェクトが難局に直面しても、色々と支援してくれそうだ」と期待して、ITパートナを選んでいます。ITパートナも、それを期待して「伴走者」といったフレーズを提案書に入れてきます。

ですので、もしモヤモヤした疑問が残っているのであれば、ユーザ企業はITパートナに聞いても良いのです。そして、ITパートナには、ユーザ企業にきちんと説明する義務があります。

ITパートナは説明できるだけのネタがある

大きなプロジェクトでは、特に費用が膨らんでいるときには、新しい契約をする際には、ユーザ企業内でもIT企業内でも、必ず社内レビュー・承認手続きが走ります。

ITパートナは、ITプロジェクトを本業にしていますから、そのレビューは入念です。ITパートナ内に品質保証担当のマネジメントがいて、プロジェクトの状況を詳細にチェックします。個々のタスクの進捗だけでなく、課題やリスク、将来費用のシミュレーションまで多岐に渡ります。

ITパートナには、普段から色々な情報が集積していますが、契約更新のタイミングは特に、情報が整理された形でドキュメント化されているのです。

つまり、ユーザ企業は、遠慮なくITパートナに情報提供を依頼しても大丈夫なのです。もちろん、ITパートナも、自分の手の内を全部さらすわけにはいきませんから、曖昧なところを残してくると思います。しかし、ユーザ企業は、プロジェクトの主体として正しく状況を理解する必要がありますから、踏み込んで要求していくことが大事です。

そういったやり取りができる場が、まさに契約交渉の場なのです。

契約更新のタイミングは、ITパートナのマネジメントの関心・関与も高まっている時期である

加えて、契約更新のタイミングは、上記で説明したようなレビューが行われます。それらレビューの際に、ユーザ企業・ITパートナ双方のマネジメントに対して、プロジェクトの状況や課題、費用の見通しについて説明がなされます。そのため、双方のマネジメントのプロジェクトへの注目度・理解度が上がっているタイミングなのです。