法律的観点からみた、システム開発における変更管理の行い方とは

システム開発プロジェクトでは、ユーザーが事前に説明していた内容が、仕事が進む過程で後から変更するということが往々にして起こります。そのため、仕事を受けるベンダーとしても、一度締結した契約した契約についても、後から契約内容の変更に応じる必要が出てくることがあるものです。

本記事では、なかなか想定通りに進まないシステム開発プロジェクトというものに対し法的な観点から、事後で行われる「変更」という現象をどう扱っていくべきかを解説しています。

システム開発プロジェクトはなぜ事後で「変更」されるのか

システム開発はベンダーとユーザーの共同作業

システム開発は一般的には、企画・提案段階を経て、開発の要件が定義され、契約が締結されます。そして契約が締結されて以降は、各種設計を経て、設計通りに実装がなされる工程を終え、最後にテストを行って終了するという流れをたどるのが一般的です。そして、工程全体では、仕事を受けるベンダーがシステム開発の専門家として広範に義務を負うことはもちろんですが、ユーザー側にも一定の協力義務が課せられます。つくるべきシステムが持っておくべき機能の洗い出し（＝要件定義）や、画面側の外観や操作感（＝基本設計）、そして、要件通りのものができたかどうかの確認（＝テストもしくは検収）といった工程では特に、ユーザー側の協力が重要となってきます。なお、システム開発において、ユーザーが負っている義務についての一般的な解説は、以下の記事にて詳しく扱っています。

協力義務はあれど、ユーザーはなにかと変更を求めてくるもの

しかしシステム開発の専門家でもないユーザーが、常に計画性を持って、システム開発に必要な情報を常に不足なく網羅的にベンダーに伝えきれるかといえば、そうではありません。現実には、細かく緻密な作業であるがゆえに、どういった事実が後工程において決定的な意味を持ちうるかなどはユーザーにも予測しえないことも多いものです。そのため皮肉にも、重要な事実ほど後から小出しに出てくるといった事態にもなりかねないのです。こうした事情から、現実のプロジェクトでは、「上流工程から下流工程まで一気通貫」というのが理想ではありつつも、事後で様々な変更が行われうるという想定のもと、「変更管理」をいかにして行うかという点が重要になってくるのです。

変更管理書とは

変更管理書が用いられる場面とは

変更管理書とは、ユーザーがベンダーに対し、事前にしていた説明の内容から、仕様の変更や機能の追加を依頼する際に用いる文書のことを言います。先述の通り、要件定義や基本設計といったフェーズで、ユーザーもベンダーの業務に対し協力する義務を負いますが、その後の工程で後から異なる要望をあげるということは実際にも起こりうるものです。

変更管理書が必要となる場面として例をあげるなら、たとえば、

• 要件定義や基本設計で検討に漏れがあり、事後で機能の追加をリクエストする場合
• 開発の途中で、事業の方針などに見直しが行われ、仕様変更が必要となる場合

などが考えられます。

なお、機能の追加・仕様の変更といった話題に関連していうと、仕事を受ける側にとってなにより気になるのは、見積り金額の変更が法律上認められるのかどうかという点でしょう。この点については、別記事にて詳細に説明を行っています。

こうした事後的な見積りの増額を行う際に、その内容の見積りの妥当性を推し量るための根拠となるのが変更管理書です。後で増額された見積りに基づいて請求を行う際、相手方と揉め事を起こさないためにも（また揉め事になった際に自身の言い分に説得力を持たせるためにも）、変更管理書の作成が重要になるというわけです。

変更管理書の記載事項

では、法律上、変更管理書に記載しておくべき事項にはどのようなものがあるのでしょうか。変更管理書を利用して、仕様変更・機能の追加に応じるという契約の仕組みはすでに一般的にも広く認知されているものです。したがって、経産省モデル契約などの、官庁が示す契約条項の雛形を確認することで、どのような事項を記録として残すべきかが概ねわかるようになっています。

（変更管理手続）
第 37 条 甲又は乙は、相手方から第 34 条（システム仕様書等の変更）、第 35 条（中間資料のユーザによる承認）、第 36 条（未確定事項の取扱い）に基づく変更提案書を受領した場合、当該受領日から○日以内に、次の事項を記載した書面（以下「変更管理書」という。）を相手方に交付し、甲及び乙は、第 12 条所定の連絡協議会において当該変更の可否につき協議するものとする。
① 変更の名称
② 提案の責任者
③ 年月日
④ 変更の理由
⑤ 変更に係る仕様を含む変更の詳細事項
⑥ 変更のために費用を要する場合はその額
⑦ 検討期間を含めた変更作業のスケジュール
⑧ その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響

直接条文を読んで、記載が推奨されている項目を確認すれば、もうこれ以上の解説は不要でしょう。後で「言った・言わない」の問題にしないためには、詳細かつ具体的に変更の経緯を記録すべきであるということです。

こうした記載事項を明記のうえ、ベンダーとユーザー双方の責任者・決裁者の署名ないしは捺印などとセットになることで、万一裁判になるようなことがあろうとも、証拠として契約書と同等の意義をもつことになるというわけです。

変更管理に関連して知っておくと良いこと

変更管理は大抵、課題管理とセットで行うべきもの

変更管理書を作成する理由は、変更履歴を管理することによって、プロジェクトを達成に導くこと（あるいは、達成に導けなかった場合に、不当な責任追及を回避すること）にあるといえます。そうした目的を達成するために実務上は、変更管理書の作成は、課題管理一覧表の作成・更新とセットで行われることが多いものです。すなわち、変更履歴を変更管理表で管理したら、その合意された変更項目は、今後取り組むべき課題として課題管理一覧表の項目に取り込まれるというわけです。

変更協議の行い方についてもあわせて規定をするのがベター

変更管理のやり方だけでなく、変更に関する協議の行い方についても、あわせて規定を設けておくと、変更の対応がスムーズにいくことが期待できます。この点は、特にアジャイル開発など、事後にさまざまな変更がなされることが前提となっている開発手法を採用する場合には、特に重要な点でしょう。実務上も、変更管理に関する協議の要請があった場合に、相手方がいつまでに協議に応じるべきなのかなどを規定する例は多くみられます。

変更協議と誠実義務

両当事者が一度合意した契約について、事後でそれを変更するという場合、いわばそれは新たな契約を締結するということでもあります。契約が当人の自由意志に基づくものであることからすれば、原則論としては、ベンダーが変更契約に応じる義務はないことになります。しかし、こうした権利の面が強調されすぎると、現実問題システム開発プロジェクトが円滑に進まなくなることが懸念される場合もあるでしょう。

そのため、実務上はよく契約書内に、「変更の協議に誠実に応じる義務」なるものについて明記されていることも多く、ベンダーが変更に誠実に応じない場合には損害賠償請求などが可能となるような記載となっている例もあります。

記載例としては、たとえば以下のような文例です（以下に、条文の記載例を掲載。独立行政法人 情報処理推進機構公式作成の『ff基本/個別契約モデルの基本契約書案』より引用しています）。

第4条3項　変更協議においては、変更の対象、変更の可否、変更による代金・納期に対する影響等を検討し、変更を行うかについて両当事者とも誠実に協議する。

変更方法についての規定

先述の通り、変更を行う際には、逐一変更に関する協議を開催することとしたほうが、法的には「安全」です。しかし、小規模なプロジェクトであれば、わざわざ変更に関する協議の行い方まで定めないという場合もあるでしょう。その場合には、協議についての規定をおくのではなく、協議はなくとも変更管理書にユーザー・ベンダーそれぞれの責任者の署名・捺印を行うなどによって、はじめて変更がなされるといったやり方にすることが考えられます。口頭による合意のみで安易に変更できるようにすると、変更がなされたのか否かがなにかと曖昧になりがちで、後で大きなトラブルになるという意味でも、文書管理は徹底すべきでしょう。

もっとも、毎回変更管理のために別途書類を用意することさえ負担が重く、臨機応変な対応を行うことをより重視したいということもあるかもしれません。そうした場合には、会議の議事録のなかに変更に関する事項をドキュメント化しておくというやり方にすることも一案でしょう。システム開発における会議の議事録の残し方という点に関しては、以下の記事で詳細に解説しています。

まとめ

頻繁に仕様変更が行われる現場ではたしかに、なにかとトラブルや揉め事のリスクと隣り合わせになりがちでもあります。しかし、そうした臨機応変さが求められる現場において、ただ四角四面に「管理の重要性」を強調しても、現実的な施策を講じることは難しいことが多いのではないでしょうか。

ビジネスに要求されるスピード感と、万が一の事態への備えをいかにして両立していくべきかという問題は、会社の状況・プロジェクトの内容によっても最適解が異なることが多いものであるように思われます。本記事のような内容を踏まえつつも、会社ごと・プロジェクトごとに、適切なやり方を各々模索していく姿勢も重要となるものと考えられます。