システム開発プロジェクトの「炎上」にまつわる法律とは

システム開発というプロジェクトは一朝一夕に達成しうるものではなく、多数の人と組織・巨額の資金・そして長きにわたる開発期間など、多くのリソースを投じてはじめてなしうるものです。本記事では、システム開発におけるプロジェクトの「炎上」という現象が、法律的な枠組みのもとではどのように整理されうるものであるかを解説するとともに、解決策の指針となるものをまとめていきます。

プロジェクトはなぜ「炎上」するのか

一個のITシステムは、それがたとえ格別大規模なプロジェクトでなかったとしても、大量につくられたプログラムファイル・ソースコードの積み上げがあってはじめて正しく機能するものです。画面側からみた操作感からでは到底想像がつかないほど（あるいはむしろ、画面側からみた操作感がシンプルで簡潔であるようなITシステムほど）、細やかで緻密な作りをしていることが多いものです。

• 納期だけが先に決まっていて、仕様も要件も曖昧なまま時間がすぎてしまっている
• 社内政治の問題にばかりメンバーが気を取られていて、人間関係のストレスから途中でドロップアウトしてしまうメンバーが多い
• PMをはじめとするマネジメント階層にも交渉力の不足があり、メンバーに適切な報告・連絡・相談を求めらていない

など、具体的な炎上理由はプロジェクトごとに様々でしょう。しかし法的にみれば、プロジェクトの炎上理由は、いくつか複数の類型によって比較的シンプルに整理することができます。

炎上類型１：プロジェクトが途中で頓挫する場合

システム開発の進行において、その途中で頓挫してしまう理由の典型として、ユーザー側とベンダー側のコミュニケーション不全が挙げられます。そもそもシステム開発というプロジェクトは、ベンダー側がもつシステム開発のための専門的な技術力・組織力が必要なのはもちろんのこと、最終的にそのシステムを使用するユーザー側の協力もあってはじめて成り立つものです。

そのため、ひとつのプロジェクトに対し、互いがどのような役割を負うのかという点についての整理が曖昧なままプロジェクトが進行し、ある種の「業務の押し付け合い」のようなものが生まれた場合に、その円滑な進行が阻害されることになります。なお、ユーザー側の義務、ベンダー側の義務、それぞれについての法的な考察については、以下の記事をそれぞれ参考にしてください。

それぞれが負う責任がいかなるものであるかについての詳しい内容は、上記の記事を確認していただくとして、ここでの話の要点は、ひとつのシステム開発プロジェクトにおいても、ユーザーとベンダーそれぞれに一定の責任を負っているという点です。大まかな区別としては、要件定義・画面等の外観に関する設計（つまりは基本設計）・検収など、ユーザー側の協力なくして完了しない部分については、ユーザー側の協力義務というものを過去の判例・裁判例は認めています。

また一方でベンダー側も、上記のような点でユーザー側の協力を受けた上で（また同時に、上記のような協力を求めるコミュニケーションの努力を行ったうえで）、プロジェクトの円滑な進行と、その阻害要因の発見とその除去にむけた包括的な義務を負っています。

こうした考え方のもとで、内部のシステムとして、ユーザーが内部からガバナンスを効かせていく義務と、ベンダーが外部の専門家として専門性・技術力を発揮したうえで業務にあたる義務を双方示し、あらゆる紛争を公平に扱っていこうとするする姿勢を裁判所は示しています。

また、こうした「頓挫」が発生しやすいのは、検収の場面です。検収に関しては下記記事にて詳細に解説しています。

こうした場合に、ひとたび紛争になれば、そこでは過去のプロジェクトの推移・会議のやりとりの内容など、客観的に確認可能な証拠がなにかと重視されます。したがってそこでは、事前に記録されてきたドキュメントが大きな意味を持つことになることが多いものです。自身の立場を不利にしないためにも、文書管理の徹底は重要なのです。なお、システム開発における文書管理の重要性という観点からは、以下の記事にて詳しい解説を行っています。

炎上類型２：ユーザー側の自己都合で解約する場合

またプロジェクトの途中で、ユーザー側の希望により、中止が言い渡されるといった事案も想定されます。たとえば、海外拠点も含めて人事管理を一括で行うITシステムを作りはじめたところ、企業の海外進出という販路拡大戦略そのものが取り下げられたとしましょう。そうした場合には、着手しかけたそのシステムの開発は、もはやユーザーにとっても不要となるかもしれません。

そもそも、企業で使われるITシステムがいかに構築されるべきかという問題は、その前提として、「その企業のなかに、まずどのような業務があるのか」といった問題と切っても切れるものではありません。したがって、組織体制・事業部編成の大幅な変更、戦略の抜本的な見直しなどの影響をうけて、必要となる（あるいは不要となる）システムの要件が事後で変わってしまうことは実際考えられるものです。

こうした事情によって、途中でプロジェクトが中断される場合もまた、さまざまな法律問題が生まれます。その場合は通常、ユーザーの自己都合であることから、完成割合に応じた報酬請求など、ベンダー側にも一定の法的な権利が認められます。どのような契約類型が採られていたかによって、根拠となる条文には差はあるものの、その内容は以下のように整理されます。

・請負契約の場合：民法６４１条
民法６４１条
→請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる。
・準委任契約の場合：民法６４８条３項（状況次第では、民法６５１条に基づく損害賠償請求も）
民法６４８条
→委任が受任者の責めに帰することができない事由によって履行の中途で終了したときは、受任者は、既にした履行の割合に応じて報酬を請求することができる。
民法６５１条
→１.委任は、各当事者がいつでもその解除をすることができる。
→２.当事者の一方が相手方に不利な時期に委任の解除をしたときは、その当事者の一方は、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。

炎上類型３：納品されたシステムの不備が、後から発覚した場合

ユーザー側はシステムの出来を画面側の操作感から把握することが多いものですが、仕事を受ける側からみてむしろ難解なのは、データベースの設計であったり、あらゆる操作法を想定したうえで、テスト項目を洗い出すことであったりします。

つまりは、使い始めた初期には問題なく動いていたかにみえたシステムであっても、

• 登録されるデータの量が増えるとともに、処理スピードが遅くなってきた
• 日々の基本業務では問題なく動いていたかにみえたシステムも、数ヶ月あるいは数年に一回発生するような特殊なオペレーションではバグが生まれることがわかった
• 表面上は、正しく結果の出力が行われているように見えても、その実ロジックは合っていなかった（卑近な例をあげると、１＋１というユーザー側からの入力に対し、正しく”2”が出力されていても、正しく計算処理を行えているとは限りません。どんな計算式を入力しても”2”という出力を返してしまうという、”ロジックの誤りは、漫然と画面操作をするだけでは発見できないことが多いものです。テスト工程にもこの意味で、ある種の”技術力”が求められると言えます。）

などということは実際起こりうるものです。こうした事案をあえて法的な観点で分析するなら、可能性としてはベンダー側のプロジェクトマネジメントの義務違反、つまりは民法上の不完全履行の問題となる可能性が考えられます。

この場合において、契約上特別になにか決まりごとを用意していないという場合には、通常請負契約に関する規定が及んでくることとなります。

その場合に検討すべきポイントは以下のように整理されます。

といったように整理されます。

まとめ

個々のシステム開発のプロジェクトは、様々に、そして多様に紆余曲折を経て進んでいくものでしょう。しかし、法律上のプロジェクトの「炎上」という話になれば、本記事において提示したような枠組みが、ひとつの見取り図となります。システム開発に関連する法律問題は、たしかに非常に多様なテーマを含んでいます。

しかしシステム開発という業務が構築的な思考力を要するのと同様に、それに付随するリスク管理というものもまた、分野の全体像を見失わないことによって、より建設的に執り行うことができるようになるのではないでしょうか。