「開発が止まっている。ベンダーは『要件が固まらない』と言い、社内は『ベンダーの管理不足だ』と言う」——責任の所在が宙に浮いたまま、プロジェクトが漂流していく。この光景に心当たりのある方は少なくないはずです。実際、システム開発紛争の裁判例を扱った解説は、いまも各媒体で繰り返し取り上げられ、読まれ続けています。

ただし発注者にとって本当に重要なのは、訴訟の勝ち方ではありません。裁判所が「どちらの落ち度で頓挫したのか」を判断するときに見てきた材料は、そのままプロジェクトを健全に運営するためのチェックリストになります。本記事では、ベンダーの「プロジェクトマネジメント義務」と発注者の「協力義務」という二つの概念を、発注者側の実務に翻訳して整理します。

課題 ― 責任の議論が水掛け論になる

プロジェクトが荒れたとき、社内の議論はしばしば「ベンダーが悪い」「業務部門が非協力的だ」という感情論に落ちます。厄介なのは、この状態では是正の打ち手が決まらないことです。誰の何が不足しているのかを言葉にできないまま、報告会だけが重くなっていきます。

ここで判断の軸になるのが、裁判例が積み上げてきた二つの義務の考え方です。法務のためではなく、荒れたプロジェクトを構造で語り直すための枠組みとして使えます。

二つの義務 ― 何が期待されているのか

ベンダーのプロジェクトマネジメント義務 発注者の協力義務
内容 進捗と課題を管理し、開発を阻害する要因を発注者に説明・警告する。必要ならスコープ・費用・期間の抜本的な見直しを提言する 要件を確定させ、必要な業務情報・資料を提供する。意思決定を適時に行い、キーパーソンを関与させる
位置づけ 開発の専門家としての契約上・信義則上の義務 発注者として信義則上負う義務
問われる場面 遅延や過大な要求を放置した。納期・費用への影響を説明せずに受け入れた 仕様の確定後も追加要望を出し続けた。決裁が滞りベンダーを待たせた

押さえておきたいのは、近時の裁判例が一方だけを断罪するのではなく、双方の義務違反を比較して責任を分担させる傾向にあるという点です。仕様の凍結後に発注者側が多数の追加要望を出し続けたことが協力義務違反と認定された事案（旭川医科大学と NTT東日本 をめぐる札幌高裁 平成29年判決）もあれば、一審でベンダーのプロジェクトマネジメント義務違反とされた判断が、二審で発注者側の協力義務違反へと転じた事案（野村ホールディングスと日本IBM をめぐる東京高裁 令和3年判決）もあります。

つまり「ベンダーは専門家なのだから、うまくやってくれるはずだ」という前提は成り立ちません。発注者にも、果たすべき役割が明確に期待されています。

分かれ目は「記録」にある

紛争になったとき、双方の主張を裏づけるものとして参照されるのは、契約書や提案書に加えて、議事録・課題管理表・変更管理票・メール・設計書といった日常の記録です。

重要なのは、これらが訴訟に備えて特別に作る書類ではないという点です。いずれも、きちんと回っているプロジェクトなら自然に残るものばかりです。裏を返せば、記録が残らない運営をしている組織は、頓挫したときに自らの正当性を示せません。そして多くの場合、記録が残らない運営は、そもそも合意形成そのものが曖昧なまま進んでいます。

発注者側の四つの打ち手

1. 要件確定の「締め」を先に合意する 仕様をいつ確定させ、確定後の追加要望をどう扱うかを、計画段階でベンダーと文書で合意します。締めがないプロジェクトは、要望が出続けること自体が正常な状態になってしまいます。

2. 変更管理を「経路」として持つ 追加要望は、納期・費用・スコープへの影響とセットで判断する会議体に必ず通します。現場担当者が口頭で依頼を受け、それが積み上がっていく状態をなくすことが目的です。

3. 意思決定の期限と権限を決める 「いつまでに誰が決めるか」を課題管理表の項目として持ちます。決裁の遅延は、ベンダーではなく発注者の落ち度として評価されます。判断が上位に上がらないまま滞留する経路を潰しておく必要があります。

4. 業務側キーパーソンを工数として確保する 「本業の合間に、余力があれば」という関わり方では協力義務は果たせません。業務部門の参画を、稼働時間として計画に明記し、上長と合意しておきます。

この四つを日々回す主体になるのが PMO です。PMO をどの権限で置くかについては PMOの立ち上げ方と組織設計 を、複数ベンダーが関わる場合の統制の仕組みは マルチベンダー時代のベンダーマネジメント を併せてご覧ください。

よくある失敗と回避策

よくある失敗 なぜ起きるか 回避策
議事録がベンダー任せ 作成負荷を委託先に寄せている 決定事項と保留事項は発注者側でも確認・合意する運用にする
「言った・言わない」の追加要望 変更の入口が複数ある 変更要求は所定の経路に一本化し、影響評価なしに着手させない
遅延の兆候が報告されない 悪い情報が上がると叱責される 課題を早期に出すことを評価する場として、進捗会議を設計する
契約形態と実態のずれ 準委任なのに完成責任を期待している 契約類型ごとの責任範囲を、プロジェクト開始時に関係者で共有する

まとめ

システム開発の頓挫をめぐる責任は、どちらが強く主張したかではなく、それぞれが果たすべきことを果たし、その事実が残っているかで分かれます。ベンダーには説明と警告の義務があり、発注者には要件を固め、決め、人を出す義務があります。

紛争対策として身構える必要はありません。仕様凍結の締め、変更管理の経路、意思決定の期限、キーパーソンの確保——この四つを設計しておくことが、そのままプロジェクトを止めない運営になります。

FAQ

Q. 準委任契約なら、ベンダーは完成させる責任を負わないのですか。 A. 準委任では成果物の完成そのものではなく、専門家として適切に業務を遂行することが求められます。ただし完成責任がないことと、プロジェクトマネジメント義務を負わないことは別です。進捗管理や課題の説明・警告は、契約類型にかかわらず期待されると考えておくべきです。

Q. 開発が途中で頓挫した場合、支払った費用は戻るのですか。 A. 一律には決まりません。民法上、請負では可分な部分で発注者が利益を受けているときはその部分の報酬が、準委任では履行の割合に応じた報酬が請求され得ます。だからこそ、フェーズを分割し、各フェーズの成果と精算のルールを契約時に決めておくことが実務上の防波堤になります。

Q. 契約書のひな形は何を参照すればよいですか。 A. IPA が公開している「情報システム・モデル取引・契約書」第二版が出発点になります。プロジェクトマネジメント義務および協力義務が見直しの主要論点として扱われており、受託開発版・パッケージ／SaaS版、およびアジャイル開発版が用意されています。

Q. 社内の業務部門にどう協力を求めればよいですか。 A. 「協力してほしい」という依頼ではなく、参画する工数と役割を明示し、部門長と合意する形にします。要件確定の遅れが投資判断そのものを揺るがすことを、経営レベルで共有しておくことも有効です。

参考資料

  • IPA『情報システム・モデル取引・契約書』第二版（2020年12月22日公開） https://www.ipa.go.jp/digital/model/model20201222.html
  • 一般財団法人ソフトウェア情報センター『判例で読み解くシステム開発紛争』一般公開版 https://www.softic.or.jp/
  • 民法 第634条（請負の割合的報酬）／第648条第3項（準委任の履行割合報酬）

関連記事