法律的観点からみたシステム開発における議事録の残し方とは
ある会社が別の会社にシステム開発を委託するという場合、代表取締役同士の法人印で締結される契約書、責任者が作成した要件定義書だけでは、結局のところ何をいつまでに作るのか、必ずしも明確ではないケースが多いものといえます。多くのシステム開発では、担当者レベルのメールや電話等のやり取り、責任者レベルの人が主催する会議などで、当初は曖昧だった部分の仕様確定、状況変化に合わせた仕様変更、機能の追加のリクエスト、発生した問題に関する協力の要請などが日々行われているからです。
システム開発を円滑に進め、また、万一紛争が発生した場合に備えるという観点から、ひとつのシステム開発プロジェクトの進行を円滑に取り仕切るためには、ドキュメントの作成と、その管理が重要になってきます。
本記事では、システム開発の進捗会議等に用いる会議の議事録・会議資料の残し方について、法律的な目線から解説していきます。
この記事の目次
システム開発で文書管理がなぜ大事なのか
システム開発プロジェクトにおいて、確認会議でのやりとりの内容や、プロジェクトの進捗や経緯について記録を残すことは、法律という観点からみた場合にも非常に重要なことです。その理由としては、下記の二点のようなことをあげることができます。
後になって揉め事を起こさないため
システム開発は、ユーザー側にも、ベンダー側にも多数の当事者を巻きこみながら進んでいくプロジェクトとなるのが通常です。したがって、ユーザー側とベンダー側で、それぞれどれだけの役割を負い、なにを義務として引き受けるのかという点について両者の認識に齟齬があると、後のプロジェクトの進行に支障が出ることが考えられます。
また多数の人が関与するプロジェクトであるということは、見方を変えれば、「人によって言っていることが微妙に違っていて、誰の言っていることが正しいのかわからない」といったコミュニケーションのトラブルがなにかと起きやすいということでもあります。
両者の認識に齟齬がないかを確認する意味でも、形成された合意の内容を活字にまとめておくことは有意義であり、また関係者で同じものを（個々人のタイミングで）確認できる資料にまとめておくことは、関係者の足並みを揃えることにつながっていきます。
ちなみに、紛争の発生を事前に予防するための手段として法律の知見を活用していくことは、予防法務などと言われることもあります。
後に紛争が発生した際の対策とするため
また、先述の予防法務的な観点と似ているものの、若干異なる観点から文書管理の重要性を説明するならば、やはり実際に紛争となったような場面を想定したうえでの、「危機管理」という点も挙げることができるでしょう。
なにかしらのトラブルが発生し、成果物ができあがる前にプロジェクトが中断されてしまった場合や、当初の納期に間に合わなくなってしまったとして、かりに裁判沙汰になるような事態を想定してみましましょう。ユーザー側・ベンダー側双方に言えることですが、「起きてしまった事態に対して、自分の側にも言い分がある」と言おうにも、記録が文章化されていなければ、自分の側の言い分を立証しようにもできず裁判でも不利な扱いを受けることになりかねません。
特に「納期に間に合わなかった」ことに端を発するトラブルでは、その原因について、「いつどのようなタイミングで障害が発見されたのか」、「どのようなタイミングで仕様変更のリクエストがあがったのか」、「ユーザー側からの機能の追加リクエストに対して、ベンダーはどのような対応を試みたのか」といった点が、裁判の行方をも左右しかねない重要論点となる場合も多いものです。その際に「言った、言わない」の問題が多数起きてしまうようでは、公平な紛争解決も期待しづらくなってしまうでしょう。
システム開発会議の議事録として特に大事なのはなにか
システム開発における会議の種類
システム開発のプロジェクトでは、様々な会議が随時企画されながら進んでいくことが多いものです。このこと自体、多数の人が関与するプロジェクトであることから考えれば、なにも不思議なことではないでしょう。プログラムの実装を開発現場で行うプログラマー・エンジニアも、定期的に業務の進捗状況を確認するための確認会議を開くという現場が多いのではないでしょうか。また実装されたコードに対して、保守性・セキュリティ面での脆弱性などの問題がないかなどを確認するため、実際のコードを見ながらレビューなどを行うといった場合もあるでしょう。
さらに、こうした開発現場における担当者レベルの会議だけでなく、会社の取締役や、権限をもった責任者たちが集まって会議をすることもあるでしょう。この場合には、開発プロジェクトにおける全体的な方向性や方針を絞った会議となることも多いでしょう。こうした責任者レベルでの、重要事項を「握る」ための会議は、ステアリングコミッティとも呼ばれます。
特に要注意な会議はステアリングコミッティ
システム開発の現場で、かかわる人の立場に応じて、また目的に応じて様々な会議が企画されることは先述の通りですが、法務的な観点からこのうちとくに重要視すべき会議は、ステアリングコミッティです。担当者レベルでの確認進捗会議やレビュー会議などに比して、ステアリングコミッティは種々の紛争の予防と、紛争発生時の対策の観点から特に、ドキュメント化の重要性をしっかり認識すべきものです。そのようにいえる理由としては、
- ステアリングコミッティは責任者レベルの人が主催する会議であるという性質上、重要な意思決定にかかわる会議となることが多く、ユーザー・ベンダー双方の認識がどのようなものであるかを示すものとして、法律上の話としても重要視されやすいものであるから。
- 担当者レベルの会議であれば通常、その会議の内容は大抵、様々な設計書・仕様書に、あとで反映されることが多く、もともと「ドキュメント不在」といった問題が起きることは現実的にも想定しづらいことであるから。（もっとも、もしこれらについてさえドキュメント化が手薄なのであれば、そこにも改善は必要と考えられるでしょうが。）
といった点を挙げることができます。
ステアリングコミッティの議事録に関連する裁判例
以下に、ステアリングコミッティにおける議事録が、実際の裁判において、重要な証拠と扱われた事案をひとつ紹介します。下記に引用する判決文の事案は、システム開発プロジェクトが途中で頓挫した事案につき、ベンダー側のプロジェクトマネジメント義務違反が認められた事案です。そこでの議事録の内容は、ベンダーとユーザーそれぞれにの当初の認識を示すものとして、裁判においても非常に大きな意味を持つこととなりました。
ベンダーは，ステアリング・コミッティの議事録に基づいて本件システム開発の経過を認定することについて，同議事録の記載内容はユーザーから修正を加えられたものであるとして，作業等の実態を必ずしも反映していない旨指摘している。しかし，ステアリング・コミッティは，本件システム開発の上級マネジメントレベルでの意思決定を行う目的で設定されたものであり，ベンダー及びユーザーの双方から，本件システム開発の実施責任者が参加し，その総合評価，スケジュール・作業進捗の実績・課題の共有，重要課題の意思決定等を行うものであった。そして，そこで議論された要点については，会議の翌々営業日の午前中までにベンダーが議事録を作成し，議事録データベースに登録し，同議事録によって会議の最終的な決定事項を記録化することとされていた。議事録を確定するに当たっては，ベンダー及びユーザーは，議事録によって作業を記録化することの意義を十分に認識しつつ，その内容と表現を検討して，会議の実態を反映したものとして，記載内容を確定させたものと推認することができる。特にベンダーはシステム開発を業とする者であり，このような議事録作成の意義と方法を当然熟知していたものといえる。したがって，確定した議事録は，ステアリング・コミッティの作業実態を反映するものとして取り扱うのが相当であるといえ，特段の事情が認められない限り，前記作業の経過内容等については，そこに記載された内容が当該期日におけるステアリング・コミッティにおいて総括されたものと認定するのが相当である。
東京高判平成２５年９月２６日
裁判所のスタンスは、ベンダー・ユーザー双方が合意のもとで作成した会議の書面による議事録であれば、それは「証拠」としても一定の推定力を見込めるというものであると考えられます。別の観点からいうならば、議事録にあまり安易な記載をしてしまうと、それがそのまま証拠となってしまうリスクがあるという点とともに、これには十分注意しておくべきでしょう。
会議議事録に残すべき具体的な記載項目とは
会議の議事録は、万一裁判になったような場合にも証拠として（また裁判にならないとしても、当事者間で円滑にその後の交渉を進めていく際にも）重要な意義を持つものです。では、具体的に、会議録に何を文書化して記録に残すべきなのでしょうか。以下に整理していきます。
ベンダー側の立場から記録に残すべき事項
ベンダー側はプロジェクトに対して、システム開発の専門家としてのプロジェクトマネジメント義務を負います。この義務がそもそもどういった内容ものであるかについては、以下の記事で詳しく解説しています。
そうした義務があることを踏まえて、ベンダー側が特に記録に残すべきこととしては、
- それぞれの開発工程が完了したという事実と、その日付
- ユーザー側から受けた仕様の変更・機能の追加といったリクエストに、どのような回答をしてきたかについての履歴
- ユーザー側の自己都合によって、開発業務の進捗が滞っている場合に、協力を求めるために講じてきた対応策と、その経緯
などを挙げることができます。
なお、上記3.の点に関連して補足しておくと、たとえばユーザー側が検収を行わない場合にベンダー側が検討すべき事項については以下の記事で解説しています。下記の記事では、ベンダー側がユーザーの検収の遂行のためにどれほど協力的であったかによって、裁判所の判断が大きく変わることを、実際の判決文を引用しながら解説しています。
ユーザー側の立場から記録に残すべき事項
また当然ながら、ユーザーも自社の内部で使うシステムであるからには、システム開発ではベンダーの開発業務に対しても一定の協力義務を負います。この義務についての全体的な内容は、以下の記事にて解説を行っています。
- ほしい機能、画面側の外観など、ユーザー側からベンダーに伝えるべきことを伝えてきたという履歴
- ベンダー側の工程において発生した種々のトラブルの履歴（たとえば、メンバーの急な離脱や、ベンダー側の調査不足が原因で発生した開発工程のスケジュールの遅延とその原因など）
上記2.の点に関連して、特に不測のトラブルへと発展しやすいのは、旧システムの撤廃と同時に新システムの開発を進めるような場合です。旧システムのデータを新システムに移行する際には特にトラブルが起こりやすいものですが、こうしたトラブルにまつわる法律問題の詳しい解説は以下の記事にて行っています。
まとめ
以上が、法律的な観点からみたシステム開発現場における会議録の残し方の指針となります。実務的なハウツーもさることながら、「法律」、「システム開発」、「文書管理」といったテーマのつながりについての認識も深めていくことが重要でしょう。システム開発というものが多数の人や組織を巻き込んで、大規模な商取引へと発展しやすいものであるからこそ、それに付随する紛争の予防・対策が重要となるのです。そして、法律的な観点からみた証拠保全の必要性からは、誰の目にも客観的に確認可能な「文書」の存在が大きな意味を持つとことになるというわけです。
たしかに、すべてのやりとり・プロジェクトの推移を完全に言語化するというのは負担も大きく、また現実的でもないでしょう。しかし、法的にみて重要な事項がなんであるかを見極め、そして重要な事項は適宜文書化を進めていくことが大切であるという点は、なにも法律の専門家か否かにかかわらず、ビジネスにかかわる人すべてに広く認知されるべきものであるように思われます。
