システム導入費用と責任の所在 —仕様変更かバグか、その先にある責任設計—
itpjstudy
システム導入プロジェクトでは、費用負担をめぐる議論が必ず発生します。
特に「それは仕様変更なのか、バグなのか」という整理は、長く現場で使われてきた基本的な考え方です。
しかし近年では、契約形態の変化やプロジェクトの大型化により、この単純な構図が必ずしも機能しなくなってきています。
その結果、費用の議論は単なる金額の問題ではなく、「責任をどのように設計するか」というより本質的なテーマに変わってきているように見受けられます。
従来のシステム導入における費用と責任の関係
かつてのシステム導入では、費用と責任の関係は比較的明確でした。そのため、関係者間の合意形成もシンプルに進めやすい構造でした。
仕様変更はユーザ企業、バグはITパートナという整理
従来は、仕様変更であれば、ユーザ企業の負担。不具合であれば、ITパートナの負担という整理が一般的でした。
このルールは完全ではないものの、判断の軸としては非常にわかりやすく機能していました。そのため、プロジェクト内での議論も、一定の基準に基づいて行うことができていました。
請負契約が支えていた責任と費用の一致
請負契約では、原因責任と費用負担が、比較的明確に一致していました。
| 事象 | 原因責任 | 費用負担 |
| バグ | ITパートナ | ITパートナ |
| 仕様変更 | ユーザ企業 | ユーザ企業 |
このように責任と費用が対応していたことで、「誰が負担するのか」という点で大きな迷いが生じにくい構造でした。
単純な構造がもたらしていたメリット
この構造の最大のメリットは、判断コストが低いことでした。また、責任の所在が比較的明確であったため、問題発生時にも意思決定が迅速に行いやすいという特徴がありました。
仕様変更の基準に関する意見相違などの問題もありましたが、全体としては、分かりやすく、安定した運用が可能なモデルでした。
契約形態の変化と責任の曖昧化
近年では、準委任契約やアジャイル開発の普及、DXのための戦略的パートナシップなどにより、プロジェクトの進め方そのものが変化しています。
共同作業の増加による境界の曖昧化
従来のシステム開発は、請負契約が主流で、ユーザ企業から提示の要件定義書や設計書をもとに、ITパートナが持ち帰り開発を行う形態で、責任分担が比較的明確でした。一方で、昨今では、アジャイル的な設計開発など、明確な役割分担をせずに、一体となって開発を進めるスタイルが増えています。
この変化により、「どこまでが誰の責任なのか」という境界が、以前よりも曖昧になってきています。
要件定義や設計では、ユーザ企業のスキル・経験不足に起因して、ITパートナがユーザ企業の役割まで支援するケースが増えています。一方で、ITパートナ側のリスク低減の意向もあってか、開発においても、従来の請負契約から、責任分担が曖昧な準委任契約の形態が増えてきているように見えます。
責任は残るが、線引きが弱くなる構造
契約形態が変わっても、最終的な責任が消えるわけではありません。しかし、「共同作業」であるという考え方が増えていくにつれて、責任を明確にするということは難しくなってきているように考えます。
最終的な責任
- 意思決定：ユーザ企業が担う
- 実行：ITパートナが中心となる
作業と費用の関係
- 作業：作業分担から、共同作業へ
- 費用：成果物ベースから、工数ベースへ
このように、役割は存在している一方で、責任の線引きは曖昧になりやすい構造になっています。
プロジェクト大型化と「支援依存構造」
プロジェクトの規模が大きくなるにつれて、ユーザ企業側のリソース不足がより顕在化しています。
マンパワー不足を前提とした構造
昨今では、システム化範囲の拡大や、全社改革を目指すDXの増加により、大規模プロジェクトが増えています。そういった大規模プロジェクトでは、ユーザ企業が、本来自身で行うべき意思決定や確認を、単独で行うことは難しくなっています。
そこで、要件整理や仕様検討、テスト検証など、多くの領域で外部リソースへの依存を前提として、プロジェクトを編成しなければならなくなっています。
ITパートナが、実質的な実行主体になるケース
「支援」という位置づけで参画しているにもかかわらず、実際には、ITパートナが業務の大部分を担うケースも少なくありません。
その結果、実行主体と責任主体が一致しない状態が発生しやすくなります。
💬 現場でよくある感覚
「ほとんどの実務はITパートナが担っているため、ITパートナの方が、全体がよく見えている」
「意思決定と責任はユーザ側に残っているが、ITパートナの説明・意見を十分検証できずに、追認するしかない」
追加予算と期間延伸が合理化される構造
このような構造のなかでは、問題が発生した場合、追加予算や期間延伸によって対応することが常態化します。
マンパワー不足を理由とした追加予算の常態化
ユーザ企業のリソース不足は、多くの場合すでに、経営課題として認識されています。
そのため、「ユーザ企業がやるべき作業に対して、人が足りないので、ITパートナに支援を依頼する」という説明は受け入れられやすくなります。
問題は、作業主体と作業責任との間に、ズレが生じていることです。
- 作業するのは、ITパートナ
- 責任を取るのは、ユーザ企業
この構図の場合、たとえ、ITパートナ側の設計や実装、あるいはユーザ企業側の意思決定など、双方に改善すべき点があったとしても、「ユーザ企業がやるべきことができていないので...」という説明だけで追加費用が正当化されてしまう場合があります。
そうなると、無限ポンプのように、追加予算が常態化して、コストを抑制しようという感覚も麻痺していきます。
スケジュール延伸も同じ論理で正当化される
同様に、ユーザ企業側のリソース不足を理由にすれば、スケジュール延伸も自然に承認されるようになっていきます。
結果として、費用と時間の両方が、申請すれば承認される「調整可能な変数」として扱われるようになります。
時間と費用をかけて、カットオーバーを成功させる
こういったプロジェクトは非常に多いのですが、あまり認知されていないように感じます。
理由は、結果的に、カットオーバーにまでたどり着いているからです。カットオーバーすると「喉元過ぎれば熱さを忘れる」ということで、大きく問題として取り上げられることが無くなり、広く世の中に知られることがありまえせん。
しかし、カットオーバーまでに、多額の費用と長い時間を投資する羽目になっているプロジェクトは多いです。その大きな原因は、問題の本質を解消するのではなく、進行を止めないことを優先して、前述のように、お金と時間を注ぎ続ける判断をしたことにあります。
責任を曖昧にしないために必要なこと
契約形態やプロジェクトの進め方が変わっても、責任を明確にするという考え方は変わりません。重要なのは、「誰が悪いか」を決めることではなく、「何が原因で、誰が対応すべきか」を整理することです。
「仕様変更か不具合か」という議論は今でも意味がある
最近では、「準委任契約にしたのだから、仕様変更か不具合かを議論しても意味がない」「一丸となって共同で進める以上、責任問題を持ち出すべきではない」という意見を耳にすることがあります。
しかし、本来、この議論の目的は、費用負担を決めることだけではありません。問題の原因を分析し、どこに改善すべき点があるのかを明確にするための重要なプロセスでもあります。
その意味では、「仕様変更か不具合か」という考え方は、現在でも十分に有効だと言えます。
共同作業であっても役割分担は存在する
ユーザ企業とITパートナが一体となってプロジェクトを進める場合でも、それぞれの役割がなくなるわけではありません。例えば、
| ユーザ企業 | ITパートナ |
|---|---|
| 業務判断・意思決定 | ノウハウ提供 |
| 要件の最終決定 | 設計・実装 |
| 業務受入判断 | テスト支援・技術支援 |
共同作業だからこそ、お互いの役割を改めて認識することが重要になります。役割が曖昧になると、責任だけでなく、改善活動そのものも曖昧になってしまいます。
費用を議論する前に原因分析を行う
問題が発生すると、すぐに
- 追加予算が必要
- スケジュールを延ばす
- リソースを追加する
という議論になりがちです。
しかし、その前に、
- 何が問題だったのか
- なぜその問題が起きたのか
- 本来誰が担うべき役割だったのか
を整理することが重要です。
原因が明確になれば、それぞれの役割分担に従って、解決策も考えやすくなります。
責任の議論が原因分析を深めることもある
問題が発生した際、「原因分析をしましょう」と呼び掛けても、十分な議論にならないことがあります。
特に共同作業が前提となっているプロジェクトでは、
- 「もう終わったことだから先へ進みましょう」
- 「今は原因よりも対応を優先しましょう」
といった理由から、原因分析が後回しにされるケースも少なくありません。
一方で、
- 「これは仕様変更ではないか」
- 「この判断は誰が行うべきだったのか」
- 「この対応費用は誰が負担するのか」
といった議論になると、関係者は一気に事実関係を確認し始めます。
もちろん、費用負担や責任の押し付け合いが目的ではありません。しかし、責任や費用が関係することで、「曖昧なままでは済まされない」という意識が働き、結果として原因分析が深まることがあります。
その意味で、「仕様変更か不具合か」という議論には、費用負担を決める以上に、事実を整理し、共通認識を形成する効果があると言えるでしょう。
「仲良くケンカする」ことがプロジェクトを強くする。
システム導入では、共同作業だからこそ、責任の議論を避けるべきではありません。もちろん、責任を議論することは、相手を責めることではありません。原因を分析し、お互いの役割を確認し、次に同じ問題を起こさないための改善策を考えることが目的です。
そのためには、ユーザ企業とITパートナが時間をかけてでも共通認識を醸成し、「何が問題だったのか」「誰が改善を担うのか」を率直に議論する必要があります。
一時的には遠回りに感じるかもしれません。しかし、この対話を省略してしまうと、追加予算や期間延伸によって問題を先送りすることはできても、根本的な改善にはつながりません。
プロジェクトを成功に導くためには、「仲良く進めること」と「責任を曖昧にしないこと」を両立させる文化が不可欠だと考えています。お互いを尊重しながらも事実に基づいて議論する、いわば「仲良くケンカする」姿勢こそが、長期的にはプロジェクト全体の品質や生産性を高めることにつながると考えます。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
