從法律角度看系統開發中如何留下會議記錄

當一家公司委託另一家公司進行系統開發時，僅憑由代表董事簽署的契約和負責人製定的需求定義文件，往往無法明確確定到底要在何時完成什麼，這種情況非常常見。在許多系統開發中，每天都會進行負責人級別的電子郵件和電話交流，由負責人主持的會議等，以確定最初模糊的部分規範，根據情況變化進行規範變更，添加功能的請求，以及對出現的問題進行協助的請求等。

為了順利進行系統開發，並為萬一發生爭議做好準備，創建和管理文件對於順利進行一個系統開發項目的管理至關重要。

本文將從法律的角度解釋如何在系統開發的進度會議等中保留會議記錄和會議資料。

為何在系統開發中文檔管理至關重要

在系統開發項目中，無論是確認會議的交流內容，還是項目的進度和經過的記錄，從法律的角度來看，這些都是非常重要的。其原因可以歸結為以下兩點：

避免後續爭議

系統開發通常是一個涉及眾多參與者的項目，包括用戶端和供應商端。因此，如果用戶端和供應商端對各自的角色和責任的認識存在差異，可能會對項目的進行造成障礙。

另外，由於涉及眾多人員，這也意味著容易出現各種溝通問題，例如「每個人說的話都有些許不同，不清楚誰的說法是正確的」等。

為了確認雙方的認識是否一致，將達成的協議內容整理成文字是有意義的，並且將其整理成所有相關人員都可以（在各自的時間）確認的資料，有助於保持參與者的步調一致。

順帶一提，利用法律知識來預防爭議的發生，這種做法也被稱為預防法務。

為應對後續爭議做準備

另外，從與前述的預防法務相似但略有不同的角度來解釋文檔管理的重要性，本所可以提到「危機管理」這一點。

假設出現了某種問題，項目在成果物完成之前就被中斷，或者無法在原定的交付日期前完成，甚至可能導致訴訟。無論是用戶端還是供應商端，都可能會說「對於發生的事情，本所有自己的說法」，但如果沒有將記錄文字化，就無法證明自己的說法，這可能會在訴訟中處於不利的地位。

特別是由於「無法按期交付」而引發的問題，其原因可能包括「何時發現了問題」、「何時提出了規格變更的請求」、「對於用戶端的功能添加請求，供應商嘗試了哪些對策」等，這些都可能成為影響訴訟結果的重要議題。如果在這種情況下出現大量的「說了，沒說」的問題，那麼公平解決爭議的期望可能會變得遙不可及。

系統開發會議的議事錄中特別重要的是什麼

系統開發中的會議類型

在系統開發的項目中，經常會隨時計劃各種會議。這本身並不奇怪，因為許多人參與這種項目。在開發現場實施程式的程式員和工程師也經常會開會，以確認業務的進展情況。此外，他們可能會審查實施的代碼，以確認是否存在維護性和安全性等問題。

此外，不僅僅是開發現場的負責人級別的會議，公司的董事或有權限的負責人也可能會開會。在這種情況下，會議通常會討論開發項目的整體方向和政策。這種負責人級別的會議，用於掌握重要事項，也被稱為指導委員會。

特別需要注意的會議是指導委員會

在系統開發現場，根據參與者的立場和目的，會計劃各種會議，這已經提到過。但從法務的角度來看，特別需要重視的會議是指導委員會。與負責人級別的進度確認會議或審查會議相比，指導委員會在防止各種爭議和應對爭議發生時的策略方面特別重要，應充分認識到文件化的重要性。這樣說的原因是：

1. 由於指導委員會是由負責人級別的人主持的會議，因此往往涉及重要的決策，並且用戶和供應商的認識如何，從法律的角度來看，這是重要的。
2. 如果是負責人級別的會議，通常會議的內容大多會反映在各種設計文件和規範文件中，因此實際上很難想象會出現”文件缺失”的問題。（當然，如果這些文件的文件化不足，那麼也需要改進。）

可以舉出這些點。

關於指導委員會議事錄的相關判例

以下，本所將介紹一個實際案例，其中指導委員會的議事錄在實際的訴訟中被視為重要的證據。下面引述的判決書案例涉及的是系統開發項目在中途停滯的情況，並確認了供應商方面的項目管理義務違反。在這裡，議事錄的內容作為供應商和用戶各自最初的認識，在訴訟中具有非常重大的意義。

供應商根據指導委員會的議事錄確認本案系統開發的進程，並指出該議事錄的記載內容是由用戶進行修改的，並不一定反映工作等的實際情況。然而，指導委員會是為了進行本案系統開發的高級管理層的決策而設立的，供應商和用戶的雙方都有本案系統開發的實施負責人參加，進行綜合評價，共享進度表、工作進度的實際情況和問題，並進行重要問題的決策等。並且，對於在那裡討論的要點，供應商需要在會議的第二個工作日的上午之前製作議事錄，並將其登錄到議事錄數據庫中，並通過該議事錄記錄會議的最終決定事項。在確定議事錄時，供應商和用戶都充分認識到記錄工作的意義，並審查其內容和表達方式，並確定記載內容為反映會議實際情況的內容。特別是供應商作為系統開發的業者，當然熟知這種議事錄創建的意義和方法。因此，可以說確定的議事錄應被視為反映指導委員會的工作實際情況的內容，除非有特殊情況，否則對於前述工作的進行內容等，應認定記載在其中的內容是在該日期的指導委員會中總結的內容。

東京高等法院，平成25年（2013年）9月26日

法院的立場是，如果是供應商和用戶雙方在達成共識的基礎上製作的會議的書面議事錄，那麼可以認為它具有一定的推定力作為「證據」。從另一個角度來說，如果議事錄的記載過於隨意，那麼它可能會直接成為證據，這是有風險的，本所應該對此保持高度的警覺。

會議議事錄應記錄的具體項目

會議議事錄在訴訟等情況下具有重要的證據價值，即使不涉及訴訟，也對於當事人之間順利進行後續談判具有重要意義。那麼，具體來說，會議議事錄應該記錄哪些內容呢？以下本所將進行整理。

作為供應商應記錄的事項

作為供應商，您需要承擔系統開發專家的項目管理責任。關於這種責任的具體內容，本所在以下文章中進行了詳細解釋。

https://monolith-law.jp/corporate/project-management-duties[ja]

考慮到這些責任，供應商應特別記錄的事項包括：

1. 各開發階段的完成事實及其日期
2. 對用戶方提出的規格變更、功能添加等請求的回應歷程
3. 由於用戶方的自身原因導致開發工作進度滯後時，所採取的協助措施及其過程

以上就是一些可以列舉的事項。

另外，關於上述第3點，例如，如果用戶方不進行驗收，供應商應考慮的事項在以下文章中有所解釋。在下面的文章中，本所引用了實際的判決文，解釋了供應商對用戶驗收的協助程度如何可能大大影響法院的判決。

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

作為用戶應記錄的事項

當然，作為用戶，由於是自家內部使用的系統，對於系統開發，您也需要對供應商的開發工作承擔一定的協助責任。關於這種責任的整體內容，本所在以下文章中進行了解釋。

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

1. 用戶方應向供應商傳達的事項的歷程，如所需功能、界面外觀等
2. 供應商在工程中發生的各種問題的歷程（例如，成員的突然離職，或由於供應商的調查不足導致的開發工程進度延遲及其原因等）

關於上述第2點，特別容易引發意外問題的是，在廢除舊系統的同時進行新系統的開發。在將舊系統的數據遷移到新系統時，特別容易出現問題，關於這些問題的法律問題的詳細解釋，本所在以下文章中進行了。

https://monolith-law.jp/corporate/the-transition-from-the-oldsystem[ja]

總結

以上就是從法律角度看待系統開發現場會議記錄保存方式的指導原則。除了實務操作方法外，對於「法律」、「系統開發」、「文件管理」等主題的關聯性也應深化認識。正因為系統開發容易涉及大量人員和組織，並容易發展為大規模商業交易，因此，預防和應對相關爭議變得尤為重要。從法律角度看，證據保存的必要性使得任何人都能客觀確認的「文件」的存在具有重大意義。

確實，將所有交流和項目進展完全語言化的負擔可能很大，也可能並不現實。然而，確定法律上重要的事項是什麼，並適時將重要事項文件化，這一點對於無論是否為法律專家的所有商業人士來說，都應該被廣泛認識和理解。