IT・ベンチャーの企業法務

アジャイル開発にまつわる法律と契約の問題とは

2019.10.25

2023.01.19

システム開発の進め方には方法論があります。もっとも古典的かつ一般的なのはウォーターフォールモデルであり、多くのシステム開発を扱う法律書籍も、このモデルを前提として論じられています。本記事では、書籍などから情報を得難いアジャイル開発モデルに基づくシステム開発に関して、どのような法律上の問題があるかを解説します。

この記事の目次

アジャイル開発モデルと法務

システム開発におけるモデルとは

システム開発プロジェクトには、その進捗の全体把握のための枠組みとして、開発モデルというものがあります。この代表は、いわゆる「ウォーターフォールモデル」でしょう。すなわち、川の「上流」から「下流」まで一気に下り落ちる水と同じように、要件定義・設計・実装・テスト等の各工程を一気通貫でやり抜くというものです。極力手順の手戻りや二度手間を減らすことを目指し、計画的に業務を進めることに適したやり方です。

一方、アジャイル開発モデルでは、小さなプログラムを実装してはテストを行うということを繰り返します。こうして小さなプログラムを実装してはテストするという反復作業を繰り返すなかで、徐々に大きなシステムを作り上げていくのです。なお、こうしたシステム開発モデルのより詳細な説明と、両開発モデルのメリット・デメリットの比較については、以下の記事にてより詳細に行なっています。

システム開発の開発モデルごとの法律上のメリット・デメリットとは

アジャイル開発モデルの特徴

アジャイル開発モデルによる開発の大きなメリットは、スピード感をもって実作業に入っていける点にあります。要件の定義や設計書の作成といった「上流工程」の業務と、プログラムの実装業務が分かれていないため、機能の追加・修正、仕様の変更などへの対応も含めて、柔軟に舵取りを進めていくことに適しているのです。法律的にみて、アジャイル開発モデルを成功に導くために特に重要となる点は、文書管理と変更管理それぞれをいかにして行うかです。アジャイル開発モデルにおいては、ウォーターフォールモデルほど、役割や担当が明確に分かれていません。また、「管理」ではなく実行・着手に至る「スピード」を重視する手法であることから、各種設計書・仕様書・議事録の不徹底につながりやすいのです。

さらに変更管理という点に関連していうと、アジャイル開発モデルは変更への対応がスムーズであることから、決裁者への承認プロセスを飛ばして、現場レベルで仕様変更のリクエストに応じていくうちにプロジェクトが炎上していくといった事態になる危険もあります。こうなれば、「事後の変更への対応がスムーズである」という開発モデルのメリットも、それ自体がプロジェクトの炎上リスクとなりかねません。

アジャイル開発での文書管理と変更管理のやり方

文書管理の重要性　

アジャイル開発モデルに基づく開発プロジェクトにおいて、法律的に懸念される点は、口頭ベースでのやりとりが蓄積され、ドキュメントの不足を招くことです。なお、この点につき、そもそもシステム開発プロジェクトで文書管理がなぜ重要になるのかという点については、以下の記事にて詳細に解説を行なっています。

法律的観点からみたシステム開発における議事録の残し方とは

当該記事では、紛争の事前予防（つまり「予防法務」）と、紛争になった際の証拠保全（つまり「危機管理」）という二つの観点から、システム開発プロジェクトにおける文書管理の重要性を説明しています。

連絡協議会の設置が文書管理に有効

アジャイル開発モデルを採用する場合、ウォーターフォールモデルの場合と異なり、事前に明確な計画が用意されているわけではありません。そのため、計画と実績の乖離をただ管理していけばよいわけではなく、現場任せでは金銭的にも時間的にもコストが膨れ上がってしまうという懸念があります。

そこで、責任者がプロジェクトの円滑な進行に向けて、定期的な連絡協議会の開催を行うようにするという施策が有効です。開発規模が小さい場合には、たしかに、定期的な連絡協議会などを開催するよりは、逐次責任者同士で集まれるときに集まるといったやり方が好まれがちです。しかし、アジャイル開発モデルの場合は特にタイムリーな課題を会議で扱い損ねる危険も大きくなりがちです。そのため、定期的な連絡協議会の開催は契約書等でも盛り込んでおくことが安全だといえます。規定の仕方としては、経産省モデル契約書では以下のように示されています。

（連絡協議会の設置）
第 12 条甲及び乙は、本件業務が終了するまでの間、その進捗状況、リスクの管理及び報告、甲乙双方による共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決その他本件業務が円滑に遂行できるよう必要な事項を協議するため、連絡協議会を開催するものとする。但し、（中略）。
2. 連絡協議会は、原則として、個別契約で定める頻度で定期的に開催するものとし、それに加えて、甲又は乙が必要と認める場合に随時開催するものとする。
3. 連絡協議会には、甲乙双方の責任者、主任担当者及び責任者が適当と認める者が出席する。また、甲及び乙は、連絡協議会における協議に必要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに応じるものとする。
4. 乙は、連絡協議会において、別途甲乙間にて取り決めた様式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を確認するとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、本章で定める推進体制の変更（人員の交代、増減、再委託先の変更など）の要否、セキュリティ対策の履行状況、個別契約の変更を必要とする事由の有無、個別契約の変更を必要とする事由があるときはその内容などの事項を必要に応じて協議し、決定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認するものとする。
（以下、５項、６項、７項は省略。）

連絡協議会という会の存在に、契約条項でも一定の正当性を付与し、その他の場当たり的に開催されるような会議とは異なる意味を付与していることが最大のポイントです。

連絡協議会を変更管理に活かしていく道筋　

また、アジャイル開発では、両当事者が当初合意していた事項が事後で変更されることは、前提事項となります。そのため、事後的な仕様変更の状況をいかに管理するかも非常に重要となります。

この際、連絡協議会が定期開催されていると、変更管理もやり方も非常にスムーズになります。たとえば、変更協議は連絡協議会で行うこととし、一方から変更協議の要請があった場合に、相手方にその協議に応じる義務を契約に盛り込むのです。（以下に経産省モデル契約の規定を抜粋します。）

（変更管理手続）
第 37 条甲又は乙は、相手方から（中略）に基づく変更提案書を受領した場合、当該受領日から○日以内に、次の事項を記載した書面（以下「変更管理書」という。）を相手方に交付し、甲及び乙は、第 12 条所定の連絡協議会において当該変更の可否につき協議するものとする。（以下、記載事項については省略）

上記規定のポイントは、以下のように整理できます。

変更の申し出を受け付ける方法を「変更提案書」というフォーマットで一本化している点
提案書を受領してから、それについて協議するまでの日付に期限を設けている点　→「◯日以内」というような記載でなくとも、「速やかに」などの語に置き換えることも考えられます。
変更の可否について協議する場を、「連絡協議会」という会議に一本化している点

すなわち、口頭ベースで「変更の申し出をした、していない」、「変更の可否について返答をした、していない」といった認識の齟齬を引き起こさないように、手続きの方法を明確化しているのです。

誠実義務や信義則への理解が問われる

なお、ここまで、「連絡協議会」、「変更協議」などに関する契約条項のモデルを紹介してきました。しかし、それらの本質的な理解のために重要なことは、「誠実義務」、「信義則」といった事項になります。そもそもアジャイル開発モデルは、発注側と受注側の信頼関係なくしては進行が困難になりがちです。なぜなら、実作業への着手のスピードのほうを重視しており、着手にいたるまでの手続きは最小限に抑えられるのが通常だからです。そのため、相手方に「誠実義務」課す条項を盛り込むことも実務上多くなるのです。

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

これは、当初信頼関係を基礎に進んできた交渉につき、突如として、「契約変更に応じるか否かは、専ら申し出を受ける側の自由であり、強制に応じる義務はない」などと、形式ありきの法律論で相手を裏切るようなやり方を防止するものです。システム開発に限らず、私人間の取引にかかわる法律の原則を反映したものでもあります。

民法第一条二項
権利の行使及び義務の履行は、信義に従い誠実に行わなければならない。

法は、必ずしも形式ありきの「契約書の記載内容」や「条文の文言」のみを重んじるわけではありません。とくに相手方のいる取引であれば、実質的な「信義」や「誠実さ」を取り込みながら柔軟に用いるべきものでもあります。なお、法律上課される「義務」というものが、必ずしも「契約」という手続を基礎にもつものではない点については、以下の記事でも詳細に解説を行なっています。