108年度北簡字第12369號｜民事：給付承攬報酬｜裁判日期：111 年 04 月 27 日

臺灣臺北地方法院民事判決 108年度北簡字第12369號原告子巧科學技術有限公司法定代理人蘇柏原訴訟代理人蘇奕全律師複代理人陳孝賢律師薛祐珽律師張秉鈞被告揪趣米有限公司法定代理人余祈霖訴訟代理人楊欽傑律師上列當事人間請求給付承攬報酬事件，本院於民國111年3月24日言詞辯論終結，判決如下：主文原告之訴駁回。訴訟費用由原告負擔。事實及理由一、原告起訴主張：兩造於民國107年8月21日簽立群眾募資服務平台建置合約書（下稱系爭合約），約定由被告給付價金新臺幣（下同）32萬元，並由原告依約完成委託內容(下稱系爭專案)。詎被告僅繳納1期款項9萬6,000元後即未再依約給付，尚欠22萬4,000元（計算式：32萬元－9萬6,000元＝22萬4 ,000元），屢經催討，均置之不理，爰依法提起本件訴訟等語。並聲明：被告應給付原告22萬4,000元，及自支付命令繕本送達翌日起至清償日止，按週年利率5%計算之利息。二、被告則以：原告依約原應分別於第一階段交付第1至7項之工作項目、於第二階段交付第8至16項之工作項目、於第三階段交付第17至23之工作項目，嗣兩造於107年9月28日就第一階段先驗收全部工作項目之UI即網頁頁面、原約定第一至第三階段驗收之功能，改至第二及第三階段驗收、最後完工時間不變等事項已達成共識。又依原證1所示，原告就第一階段部分僅提供1個檔案；就第二階段部分僅提供首頁、專案、提案、贊助等4項工作項目；就第三階段部分僅提供一個測試網址，故原告應舉證證明有交付其餘之工作項目予被告。另原告分別於107年10月9日、107年10月23日及107年11月6日所交付之第一至三階段之實際內容，均有工作項目不完整、功能不符合約定之情形，其中第一階段總計缺少項目包含第1.2至7.1項共19個頁面，此部分被告已於107年10月16 日通知原告；第二階段缺少及應修改之部分包含第1至15項共15個項目，此部分被告已於107年10月31日通知原告；第三階段缺少及應修改之部分共有18個項目及31個子項目，而被告亦於107年11月9日通知原告，惟原告就上開三階段缺少及應修改之部分皆未能改善，故第一至第三階段之驗收均未通過。另原告提供之工作物尚應具備網頁介面切版與組版、前後台API串接、網站正式上線服務及網站系統相關技術諮詢，惟原告所交付之工作物僅具有部分網站頁面，但無法完成前後台API串接功能、金流串接功能，亦無法完成網站運作上線。再第二、三階段驗收部分，原告先前曾向被告表示其採用之技術為Nuxt.js，係可先行將網頁和資料編譯為各個靜態網頁，亦即不須連接API和資料庫即可於瀏覽器中展示頁面內容，惟被告實際依原告提出之「4.串接資料庫後」readme文件所提供之執行指令，執行後畫面出現錯誤訊息，無法檢視頁面內容，故此部分驗收不通過。從而，原告既未依債務本旨提出給付，且未能提出改善方法及期限，顯係因可歸責於原告之事由致無法於期限內完成工作，被告自得依法終止系爭合約，拒絕給付剩餘之款項等語，資為抗辯。並聲明：原告之訴駁回。三、得心證之理由：（一）按系爭合約第2條「合作金額與付款方式」第1項約定：「甲方（即被告）因本合約專案應支付乙方（即原告）費用，共計為$32萬元整（含稅），應依以下方式分期支付之：第一期：乙方於簽訂本合約時，甲方應支付總價款30% 予乙方，為$9萬6,000元整（含稅）。第二期：乙方完成本專案之建置，甲方應支付總價款30%予乙方，金額為$9 萬6,000元整（含稅）。第三期：乙方完成本專案之建置且甲方完成本專案之驗收，甲方應支付總價款40%予乙方，金額為$12萬8,000元整（含稅），乙方於收到款項後，本合約專案即為結案。」(見臺灣士林地方法院108年度司促字第2980號卷〈下稱司促卷〉第6頁)。準此，原告於完成系爭合約專案之建置後，被告始有給付第2期款9萬6,000 元之義務；於完成系爭合約專案之驗收後，被告始有給付第3期款12萬8,000元之義務。又當事人主張有利於己之事實者，就其事實有舉證之責任。民事訴訟法第277條前段定有明文。是本件原告請求被告給付系爭合約第2、3期之款項，為被告所否認，原告自應就其已完成系爭合約專案之建置及驗收等有利於其之事實負舉證之責。（二）又稽諸系爭合約第3條「交付及驗收」約定：「本專案得依功能模組拆分建置與交付，交付的內容均需包含完整可執行之程式碼，規劃的期程自簽約完成且取得全部的完整介面設計稿以後起算，各模組之工作如下（模組細節如『附件一、揪趣米－群眾募資服務平台建置規格』所述）：第一階段：開發項目：1、2、3、4、5、6、7。開發日期：至2018年10月09日。第二階段：開發項目：8、9、10、11、12、13、14、15、16。開發日期：至2018年10月23日。第三階段：開發項目：17、18、19、20、21、22、23。開發日期：至2018年11月06日。驗收規定：乙方應於約定期間內將工作完成後交付甲方進行驗收測試。甲方應於接獲乙方交付後10個工作日內進行相關程式測試作業。甲方若於驗收測試後10個工作日內未提出異議或通知乙方改善，則視為作業驗收完成。如需改善，雙方應確認覆驗期日。甲乙雙方應於測試期間派遣適當且足夠之人員配合進行測試，以使各項測試之項目力求完整。系統運作效能、程式設計及編碼規範，均須符合雙方共同認訂之規範文件所註。」（見司促卷第6頁背面）及系爭合約附件一「揪趣米-群眾募資服務平台建置規格」（下稱附件一）第3點「服務內容」約定：「⑴網頁介面切版及組版。⑵前後台API串接。⑶網站正式上線服務。⑷網站系統相關技術諮詢服務。」（見司促卷第8頁），可認兩造原有已約定系爭專案各階段應完成之工作項目、交付、驗收測試時間及視為驗收完成之條件，且原告所應建置完成之內容尚包含：⒈網頁介面切版與組版、⒉前後台API串接、⒊網站正式上線服務、⒋網站系統相關技術諮詢。又第一階段之開發項目為：1 、2、3、4、5、6、7，驗收日期為107年10月9日；第二階段之開發項目為：8、 9、10、11、12、13、14、15、16 ，驗收日期為107年10月23日；第三階段之開發項原為：17、18、19、20、21、22、23，驗收日期為：107年11月6 日。惟稽諸原告提出之107年9月28日兩造間工作群組通訊軟體內容：「（被告人員柏宇（薯條））：剛才跟柏原（原告人員）電話討論的結果，跟各位做個說明：1.驗收內容變更，第1階段改為驗收全部UI，驗收期間再對認知不同的部分做修改。2.原123階段驗收的功能，改至23階段做驗收，然後再請柏原提出2跟3階段各別驗收的項目。最後完工時間還是一樣。3.API加密的方式，改為用一個中介層，將會提個一個加解密的DLL檔做Simple，再請柏原架中介層的API。」（見本院㈠卷第143頁），可認兩造已於107年9月28日合意變更第一階段改為先行驗收系爭合約全部工作項目之網頁頁面，而原第一、二、三階段功能之驗收則改至第二、三階段進行，但系爭合約約定之最後完工期限即107年11月6日仍維持不變，且關於前後台API串接工作部分，於原告擬將其所完成之網頁頁面與被告之伺服器API連結進行功能測試時，原告併應負責完成資料加解密的中介軟體之安裝。至原告主張因被告嗣後不斷提供錯誤資料及提出變更製作規格，故原告曾陸續向被告表示開發時程應增加云云，固據提出兩造間之訊息記錄列表及通訊軟體內容等件為憑（見本院卷㈠第179至209頁；卷㈡第 19至28頁）。然查，稽諸原告所提出之訊息記錄列表（見本院卷㈠第477頁）及兩造間通訊軟體內容（見本院卷㈠第4 79至501頁），可知被告於第一階段之107年10月9日驗收日期前，雖曾有就製作規格提出調整，抑或提供錯誤資料更正之情形，且原告人員曾向被告人員表示需要時間修改（見本院卷㈡第21頁），然由兩造嗣後於107年9月28日仍僅合意變更第一、二、三階段之驗收內容，惟各階段之驗收時間及最後完工時間即107年11月6日仍維持不變，且斯時原告未提出任何異議；又參以第一階段107年10月9日驗收日期後迄至第三階段107年11月6日驗收日期前，原告僅曾向被告表示關於API更改之部分〝覺得〞可能會影響第三階段之驗收時間（見本院卷㈡第25頁），然原告並未提出此段期間有要求被告延長完工期限及被告已同意延長完成期限之相關證明；併參以原告陳稱其仍於第一、二、三階段原訂之驗收日期提出交付，並提出寄送之電子郵件為憑（見本院卷㈠第169頁）。基上，尚難認定被告製作規格之調整及錯誤資料之提出，有礙於系爭合約之完工期限。從而，原告主張系爭合約之完工期限應延長或已延長，難認可採，亦即各階段之驗收日期及最後完工期限仍以系爭合約約定之日期為據。（三）原告雖主張其已依第一、二、三階段驗收時間為工作項目之交付，固據提出兩造間電子郵件、系爭合約規格、頁面截圖及檔案位置對照表等件為憑（見本院卷㈠第393至476頁）。惟為被告所否認，辯稱：依據原告所提供之製作光碟內容進行比對，原告之製作光碟內容所呈現之網頁頁面並不符系爭合約所要求之項目及數量，且依光碟內容之指令予以執行，其結果不具備系爭合約所要求之API串接功能，故被告並未完成系爭合約之工作項目及服務內容，故未完成驗收等語，亦據提出第一階段網頁頁面驗收測試結果對照表及執行光碟指令進行API功能驗收測試結果圖等件為憑（見本院卷㈠第251至361頁）。查參諸兩造間之通訊軟內容：「2018.09.06星期四23：49 BO－Yuan Su邀請陳怡榕Murna,Luke,柏宇（薯條）,李欣諭加入群組」、「2018.09.07星期五10：29雅晴hello All剛剛在記事本上已放了有關web相關文件（包含規格書、美術圖、api）之後如果有更新資訊會再通知大家～〝記事本〞內容spec：htt ps：//drive.google.com/open?id=1tXEhUrJq2SupgwCi6A2FYPt_LOxrVktmzeplin：https：//zpl.io/2GOOLLrAPL overflow：https：//overflowio/s/82WZAD/APL swagger ：http：//211.21.138.226/FunFundingAPI/swagger/ui/indexAPI文件：http：//211.21.138.226.9090）」（見本院卷㈠第509頁），可認兩造係於107年9月6日成立通訊軟體群組，且被告前已於107年9月7日將系爭合約附件一之製作規格檔案放置於系爭群組之記事本內。又被告辯稱107年9月7日所傳送予原告之系爭合約附件一之製作規格檔案已於108年3月15日重新轉存於「zpl.io/2yy1Eqo」網址，而本院檢視該網址上之系爭合約附件一之製作規格檔案（下稱系爭規格檔案）最後修改日期為107年9月3日（見本院卷㈡第45至46頁）係於107年9月7日被告傳送系爭規格檔案之前，，堪認被告108年3月15日重新轉存於「zpl.io/2yy1Eqo」網址上之檔案即為107年9月7日被告所傳送予原告之系爭合約附件一之規格製作檔案。另原告主張其已於第一階段107年10月9日如期完成並交付全部工作項目之網頁頁面，並可由網址「https：//letsfun-demo.herokuapp.com」查詢（下稱系爭網址）其所製作之內容（見本院卷㈠第403至476頁）。茲就被告所提出之系爭規格檔案，對照原告於系爭網址所製作之內容，情形說明如下：1、附件一約定系統功能之「1.首頁」為：「（A區）輪播專案區：點擊切換至該專案內容。規則為輪播內容為後台官方推薦所有專案，若無則顯示官網介紹圖，且圖片上顯示專案名稱、剩餘時間、查看專案內容（文字）；（B區）分類切換區：切換不同專案分類，下面專案再進行篩選。切換內容為所有專案（預設）、最多贊助、最新發起、即將結束、趨勢、熱門…」（見司促卷第8頁）。惟依被告之系爭規格檔案檢視，原告於系爭網址所製作之內容，（A 區）輪播專案區點擊切換至該專案內容部分，缺少主視覺應輪播圖片、中央應出現文字對話框、展開下拉之選單應有合理之項目文字，此有規格對照表在卷可稽（見本院卷㈡第49頁），並經本院當庭勘驗與前開規格對照表顯示相符（見本院卷㈡第39至40頁）。原告雖主張被告於107年10 月19日仍表示尚在設計此區域，故不需出現文字對話框，且設計圖上之文字原本僅係示意用途，與實際網頁功能無關，又結合API後此部分可由被告後台管理云云，固據提出兩造間107年10月19日之通訊軟體紀錄為憑（見本院卷㈡第151頁）。惟查，第一階段應驗收之範圍為全部工作項目之網頁頁面，已如前述，則網頁頁面本須呈現所有元件要素始能通過驗收；又參以107年10月19日兩造間之通訊軟體內容：「下午02：09蔡明軒『照片』下午02：32雅晴：就是預設圖，這一塊美術正在設計中。下午02：39蔡明軒：中間的文字box就不顯示嗎？下午02：40雅晴：對。…下午05：07蔡明軒：『這邊API是串GetProjectListByCollec tions這隻，那我ProjectCollectionsNo（官方推薦編號）要傳什麼？』下午05：14ㄚ弟仔：『照片』下午05：14蔡明軒：我登入之後，首頁的Project List一樣串Web/GetProjectListByAll嗎？下午05：14ㄚ弟仔：如果Type為1的就都是傳進這個API的ProjectCollectionsNo。下午05：15 蔡明軒：那如果官方推薦不只一個的話呢？下午05：16蔡明軒：『照片』下午05：17ㄚ弟仔：疑，等等...這邊要做輪播對吧。下午05：17蔡明軒：對。下午05：17ㄚ弟仔：所以可能要另外開一個API了。下午05：17ㄚ弟仔：所以這邊需要的資訊是專案編號、專案名稱、募資到期時間，就足夠嗎。下午05：19蔡明軒：還需要專案圖片網址。下午05：19蔡明軒：這背景應該是用專案的圖片吧？下午05：19蔡明軒：『照片』下午05：20雅晴：對，是使用專案封面圖片。下午05：20蔡明軒：那就需要專案圖片網址。下午05：20ㄚ弟仔：那就是一次傳全部的官方推薦專案…」（見本院卷㈡第183頁），是由被告員工（Y弟仔）稱：「疑等等… ，這邊要做輪播對吧？」，原告員工蔡明軒回覆：「對」，可認被告辯稱原告先前本即要製作輪播背景及對話框之功能，又被告員工雅晴雖稱：「就是預設圖。這一塊美術正在設計中。」及原告員工蔡明軒所稱：「中間的文字box就不顯示嗎？」，係指懷舊古老腳踏車風不顯示，即預設圖部分被告要設計一張圖取代原腳踏車的圖，並非被告自己要設計主視覺輪播區塊，且中間文字box不顯示部分，僅有文字方塊，並非整個互動區塊等情，應屬可採。從而，被告辯稱此部分因欠缺上開內容之建置而尚未通過驗收，應屬可採。 2、附件一約定系統功能之「1.首頁」為：「…（C區）專案列表區：依所列篩選項目，顯示6個專案，包含所有專案（預設）、最多贊助、最新發起、即將結束、趨勢、熱門。查看更多btn：點擊開啟至探索頁面…」（見司促卷第8頁）。惟依據被告之系爭規格檔案檢視，原告於系爭網址所製作之內容，（C區）專案列表區中間下方缺少藍色「查看更多」的按鈕，「專案卡片」缺少icon細節以及「分享」、「收藏」按鈕，此有規格對照表在卷可稽（見本院卷㈡第51頁），並經本院當庭勘驗與前開規格對照表顯示相符（見本院卷㈡第39至40頁）。原告雖主張查看更多按鈕部分，超過9個專案才會出現「查看更多」按鈕，靜態網頁設計稿僅呈現基本排版介面而已，網頁若實際上線，隨著專案資料增加超過9個後會出現此按鈕；而分享及收藏按鈕部分，此部分是串接API後才會有的靜態功能，諸如「分享」、「收藏」等，皆串接API後，有真實募資資料後才有辦法有此功能云云。惟查，第一階段驗收範圍是全部工作項目之網頁頁面，則網頁頁面本必須呈現所有元件要素始能驗收通過，故被告辯稱此部分因欠缺上開內容之建置而尚未通過驗收，應屬可採。 3、附件一約定系統功能之「2.2.會員登入&註冊」為：「2.1會員登入頁（A區）註冊方式包含站內註冊、社群串接登入（Facebook、Google+、Line登入）；（B區）登入資訊輸入Email、密碼、記住我、忘記密碼；註冊頁切換區：點擊切換至註冊頁面；登入btn：點擊檢查server資料是否填寫完/正確。2.2註冊頁（A區）社群串接註冊：Facebook、Google+、Line；註冊資訊輸入：會員姓名、顯示名稱、Email、密碼、確認密碼；同意條款：預設為不勾選；登入切換區：點擊切換至登入頁面；登入btn：點擊檢查資料是否都有填寫，且信箱是否有重複…」（見司促卷第8頁及背面）。惟依據被告之系爭規格檔案檢視，原告於系爭網址所製作之內容，2.1會員登入頁左下角出現多餘FB登入按鈕、2.2註冊頁之「登入」按鈕文字顏色錯誤，將影響色弱人士使用，且左下角出現多餘FB登入按鈕，此有規格對照表在卷可稽（見本院卷㈡第53頁），並經本院當庭勘驗與上開規格對照表顯示相符（見本院卷㈡第39至40頁）。原告雖主張出現多餘FB按鈕是當時為方便測試而經雙方同意下所暫時添增之按鈕，正式上線時將移除，並不影響功能，又按鈕顏色錯誤部分，107年9月11日被告係表示平台LOGO尚未設計完成，未來LOGO將使用藍色作為主色系，故請原告工程師先自行決定系統用色，未來將給予進一步之指示，屆時原告再依照指示更換顏色，業據提出兩造間通訊軟體內容為憑（見本院卷㈡第153頁）。惟查，紅框處出現多餘FB按鈕部分，已與系爭規格檔案不符，又縱被告曾向原告表示先自行決定平台LOGO顏色，惟第一階段驗收時顏色、網頁色碼至少仍應以系爭規格檔案之顏色呈現（見本院卷㈡第185頁），始符合系爭合約之約定。從而，故被告辯稱此部分有上開情形而尚未通過驗收，應屬可採。 4、附件一約定系統功能之「3.探索頁」為：「（A區）推薦/分類：點擊開啟下拉式選單，依選單內容篩選下方專案cards。（B區）分類篩選：已關鍵字的專案再進行分類篩選。（C區）專案列表區：依篩選項目，顯示9個專案。（C 區）頁碼切換區：顯示目前頁碼，可上下/點擊切換」；「4.搜尋頁」為：「（A區）搜尋結果：已輸入關鍵字進行專案篩選。（B區）分類篩選：已關鍵字的專案再進行分類篩選。（C區）專案列表區：依篩選項目，顯示9個專案。」（見司促卷第8頁背面）。惟依據被告之系爭規格檔案檢視，原告於系爭網址所製作之內容，關於「3.探索頁」部分，（C區）專案列表區：依篩選項目，顯示9個專案，「專案卡片」缺少icon細節及「分享」、「收藏」按鈕，下方則缺少「查看更多」按鈕，且缺少首頁右上角之「類別」，因由「類別」點選進去後，至少應有推薦及分類之選項，分類至少有8個類別名稱之選項（包含：設計、休閒、音樂、旅行、在地、藝術、運動科技），惟原告僅製作3個，且僅顯示出aaa、bbb、ccc，點選後亦無法顯示類別名稱；關於「4.搜尋頁」部分，（B區）分類篩選：左方「類別」應有合理文字而非aaa等；（C區）專案列表區：「專案卡片」缺少icon細節及「分享」、「收藏」按鈕，且缺少「類別」名稱，「類別」點選進去後，至少應有分類選項（包含：設計、休閒、音樂、旅行、在地、藝術、運動科技），惟原告僅製作2個，且僅顯示出aaa、bbb，點選後亦無法顯示類別名稱，此有規格對照表在卷可稽（見本院卷㈡第55頁），並經本院當庭勘驗與上開規格對照表顯示相符（見本院卷㈡第39至40頁、第174頁）。原告雖主張須超過9個專案才會出現「查看更多」按鈕，靜態的網頁設計稿僅呈現基本排版介面，網頁若實際上線後，隨著專案資料增加超過9個才會出現此按鈕；關於文字部分，設計圖上的文字本就僅是示意用途，與實際網頁功能並無關係，且結合API後此部分可由被告後台管理云云。惟查，第一階段驗收範圍為全部網頁頁面，故網頁頁面必須呈現所有元件要素始能通過驗收，故被告辯稱此部分因欠缺上開內容之建置而尚未通過驗收，應屬可採。 5、附件一約定系統功能之「5.專案Card內容」為：「5.1專案_內容頁（A區）影片連結區：嵌入Youtube影片，點擊即能撥放影片內容；專案資訊區：專案名稱、專案內容、提案人名稱、分類、達成率、達成率條；金額區：顯示目前募資金額&目標金額；贊助數區：顯示目前贊助人數；倒數時間區：顯示專案剩餘時間；收藏btn：以登入/未登入；社群btn：複製網址、Facebook、Line、Google+；Website btn：點擊外開網站；提案人聯繫btn：點擊即開啟1對1私訊詢問。（B區）分頁切換區：內容、進度、風險、留言、贊助者；贊助方案btn：募資結束、贊助中、登入/未登入；（C區）內容區：顯示提案人填寫內容；（D 區）贊助方案區：顯示該專案底下贊助方案。」（見司促卷第8頁背面）。被告雖稱依據系爭規格檔案檢視，原告於系爭網址所製作之內容，（C區）內容區缺少顯示提案人填寫的全部內容（此部分被告僅要求照片及文字內容之示意及文字格式，見本院卷㈡第175頁）；（D區）贊助方案區缺少顯示該專案底下贊助方案全部內容（此部分被告亦僅要求照片及文字內容之示意及文字格式，見本院卷㈡第175頁），並提出規格對照表為憑（見本院卷㈡第57頁）。然原告主張係被告引用網頁面錯誤，正確網頁頁面位置係位於107年10月9日第一次驗收信件附件2.專案/2-2-1.html中（見本院卷㈡第155頁）。查，經原告當庭開啟上開附件2.專案/2-2-1.html檔案，確有顯示如原證五所示之照片及文字之說明（見本院卷㈡第174頁；見本院卷㈠第408 頁），並非無法進入此部分之分頁網頁，是被告辯稱此部分無法開啟進入網頁，尚難憑採。 6、附件一約定系統功能之「5.專案Card內容」為：「5.2專案_進度頁：進度顯示區：顯示目前提案人進度更新，若無進度則顯示文字；月份區：顯示進度更新月份，點擊篩選該月份進度；5.3專案_風險頁：風險顯示區：顯示提案人所填寫的風險內容。」（見司促卷第8頁背面）。被告雖稱依據系爭規格檔案檢視，原告於系爭網址所製作之內容，月份區缺少顯示進度更新月份，點擊篩選該月份進度全部內容、贊助方案與5.2（D區）贊助方案區缺少內容相同、文字間距，邊界距離字距等不符要求，並提出規格對照表為憑（見本院卷㈡第59頁）。原告則主張係被告引用頁面錯誤，正確頁面位於107年10月9日第一次驗收信件中之附件2.專案/2-3-1.html中，且關於邊界距離部分，網站建置使用RWD技術製作，會依照電腦/手機螢幕尺寸不同而自動變更網頁物件尺寸，以達到最佳瀏覽效果，所以此並非錯誤，網頁的設計稿尺寸本就僅供單一尺寸參考（見本院卷㈡第157頁）。查，經原告當庭開啟上開附件2.專案 /2-3-1.html檔案，確有顯示如原證五之照片及文字之說明（見本院卷㈡第174頁；本院卷㈠第409至410頁），並非無法進入該分頁網頁。然原告主張係RWD影響寬度排列順序部分，並不能成為行距高度不符合系爭規格檔案之理由，若不符合系爭規格檔案之施作規範，本即無法驗收通過，是被告辯稱此部分未驗收通過，應屬可採。 7、附件一約定系統功能之「5.專案Card內容」為：「5.6專案_贊助頁：（A區）封面圖片區：顯示封面圖片；專案資訊區：專案名稱、專案內容、提案人名稱、分類、達成率、達成率條；金額區：顯示目前募資金額&目標金額；（B區）贊助方案區：顯示該專案底下所有贊助方案內容；贊助此方案btn：點擊即切換至填寫資料頁面」（見司促卷第9頁）。被告雖稱依據系爭規格檔案檢視，原告於系爭網址所製作之內容，頁面缺少（B區）贊助方案區：顯示該專案底下所有贊助方案內容、贊助此方案btn：點擊即切換至填寫資料頁面，業據提出規格對照表為憑（見本院卷㈡第61頁）。原告則主張係被告引用網頁頁面錯誤，正確網頁頁面位置位於107年10月9日第一次驗收信件中之附件2.專案/2-4-1.html中（見本院卷㈡第159頁）。查，經原告當庭開啟上開附件2.專案/2-4-1.html檔案，確有顯示如原證五所示之照片及文字之說明（見本院卷㈡第174頁；見本院卷㈠第414頁），並非無法進入該分頁網頁，是被告上開所辯，尚難憑採。 8、附件一約定系統功能之「5.專案Card內容」為：「5.7專案_贊助填寫頁：（A區）簡易贊助資訊區：顯示該方案內容；（B區）贊助填寫資訊區：贊助金額、寄送地區；收件人資訊：收件人、連絡電話、郵遞區域、詳細地址、備註細節；選擇收件人資訊btn：點擊開啟會員收件地址管理(彈跳式視窗)；匿名贊助：若贊助者不想公開資料，可勾選即匿名贊助；下一步btn：點擊，檢查是否填選完畢。」（見司促卷第9頁）。惟依原告提供之原證5所示之網址顯示，無法進入該分頁，業據提出規格對照表為憑（見本院卷㈡第67頁）。原告則主張被告引用網頁頁面錯誤，正確網頁頁面位置位於107年10月9日第一次驗收信件中之附件2.專案/2-5-1.html中（見本院卷㈡第161頁）。查，經原告當庭開啟上開附件2.專案/2-5-1.html檔案，確有顯示如原證五所示之照片及文字之說明（見本院卷㈡第174 頁；見本院卷㈠第415頁），並非無法進入該分頁網頁，是被告上開所辯，尚難憑採。 9、附件一約定系統功能之「7.路人頁面」為：「7.2路人頁面_發起：資訊顯示：顯示該會員有提案的cards，包含專案封面、專案名稱、達成率條、目前贊助金額、專案剩餘時間。」（見司促卷第9頁及背面）。惟依據被告之系爭規格檔案檢視，原告於系爭網址所製作之內容，「7.路人頁面」之資訊顯示缺少應有的icon細節及按鈕，亦即路人頁面左上方應該有「募資狀態」、右上方要有「剩餘時間狀態」、右下方要有「收藏」、「分享」之符號，且上方應要呈現預設文字最多之字數及行數，此有被告提出之規格對照表為憑（見本院卷㈡第63頁），並經本院當場檢視系爭規格檔案無誤（見本院卷㈡第342頁）。原告雖未否認系爭規格檔案「7.路人頁面」部分顯示有「募資狀態」、「剩餘時間狀態」、「收藏」及「分享」等符號（見本院卷㈡第342頁），惟主張該符號於系統正式上線後依據各專業募資程度，以設定來呈現，故未上線前，這些項目本即會預留版面空間給予顯示云云。惟查，第一階段驗收範圍為全部網頁頁面，故網頁頁面必須呈現所有元件要素始能通過驗收，故被告辯稱此部分因欠缺上開內容之建置而尚未通過驗收，應屬可採。 10、附件一約定系統功能之「8.專案」為：「8.2專案編輯中/送審中/已核准/已發佈/募資中：狀態顯示區：顯示目前專案狀態，包含編輯中/送審中/已退件/已核准/已發佈/ 募資中；最後修改日期；；Cards預覽區：顯示專案資訊，點即可預覽專案－封面照片、專案名稱、達成率條、募資金額：顯示目前募資金額&目標金額、倒數時間：顯示專案剩餘時間；編輯專案btn：點擊即切換專案編輯頁面。」、「8.3審查中：狀態顯示區：顯示目前專案狀態－狀態：審查中、最後修改日期；Cards預覽區：顯示專案資訊，點即可預覽專案－封面照面、專案名稱、達成率條、募資金額：顯示目前募資金額&目標金額、倒數時間：顯示專案剩餘時間；觀看專案btn：點擊擊切換專案觀看頁面。」、「8.4已退件：狀態顯示區：顯示目前專案狀態；Cards預覽區：顯示專案資訊，點即可預覽專案－封面照片、專案名稱、達成率條、募資金額、倒數時間；編輯專案btn：點擊顯示詢問視窗－確認btn：點擊即狀態改回編輯中、取消btn：關閉視窗。」。被告辯稱依據原告提供之系爭網址無法進入上開分頁云云。惟原告主張係因被告引用頁面錯誤，正確頁面位置位於107年10月9日第一次驗收信件中之附件3.提案/3-1-2.htm、3-1-3.html內（見本院卷㈡第163頁）。查本院110年3月29日言詞辯論期日當場請原告開啟其於107年10月9日第一次驗收信件中之附件3.提案檔案夾，結果顯示：「…：(1)關於8.1部分(提案夾)：3-1-2html呈現如本院卷㈠第420頁上方所示之圖片。3-1 -3html如本院卷㈠第420頁下方所示之圖片。(2)關於8.2部分(提案夾)：3-1-1html呈現如本院卷㈠第421頁上方所示之圖片。3-6-1html如本院卷㈠第421頁下方所示之圖片。3 -7-1html呈現如本院卷㈠第422頁上方所示之圖片。(3)關於8.3部分(提案夾)：3-3-1html呈現如本院卷㈠第422頁下方所示之圖片。(4)關於8.4部分(提案夾)：3-5-1html呈現如本院卷㈠第423頁下方所示之圖片。(5)關於8.5部分(專案夾)：3-9-1html呈現如本院卷㈠第424頁上方所示之圖片。2-1-3html呈現如本院卷㈠第425頁上方所示之圖片。2 -1-2html呈現如本院卷㈠第425頁下方所示之圖片。」（見本院卷㈡第343至344頁），是被告辯稱原告提出之系爭網頁無法進入「8.專案」之分頁頁面，尚難憑採。 11、附件一原約定系統功能之「20.通知」為：「20.2通知_留言（A區）狀態顯示區：顯示目前分頁標題；（B區）留言顯示區：顯示專案留言回覆資訊，點擊該欄切換至該專案留言頁面－專案封面照、專案名、內文顯示、回覆時間。」；原約定系統功能之「22.尾頁」為：「22.1常見問題_提案人：（A區）搜尋框－user可在此搜尋常見問題；輸入框；搜尋btn：點擊進行搜尋。（B區）切換區－提案人：點擊切換至提案人QA問題；點擊切換至贊助者QA問題；其他：點擊切換至其他QA問題。（C區）QA問題區：顯示簡易QA資訊。」（見司促卷第14頁背面至15頁背面）。而被告辯稱「20.2通知_留言」部分，（A區)狀態顯示區及（B區）留言顯示區均出現需要調整文字粗細、清晰度之問題；「22.1常見問題_提案人」部分，則有文字粗細及行距等細節須調整，業據提出規格對照表為憑（見本院卷㈡第6 3、65頁）。查關於「20.2通知_留言」及「22.1常見問題_提案人」字型部分，原告雖不否認當初被告係直接提供設定字型為MEIRYO字型之指令，惟因微軟系統已無此種MEIRYO字型，故原告於107年9月19日向被告表明後，被告回覆就使用微軟正黑體，故原告所使用之字型MEIRYO、字型寬度700並無違誤云云，固據提出兩造間通訊軟體內容為憑（見本院卷㈡第371頁）。惟被告辯稱：被告當初要求之字型為MEIRYO、字體寬度BOLD，且被告於原證10的通訊軟體通話中，已有表明MEIRYO是MS系統的文字，並標註微軟字體的網頁(https:docs.microsoft.com/en-us/typography/font-list/meiryo)給原告，又由MEIRYO字型之家族介紹可知，其中STYLES&WEIGHTS已表明MEIRYO字型群組包括MEIRYO及MEIRYO BOLD 等8種MEIRYO相關字型，且原告也自承其所使用為MEIRYO字型，可證明微軟仍有MEIRYO字型群組，另被告於上開通訊軟體內容係表示：「…沒有字型就是微軟正黑體」等語，係指倘若微軟上述網址無MEIRYO字型群組時，原告即可使用微軟正黑體，業據提出微軟網頁資料等為憑（見本院卷㈡第397頁），核屬相符，並有兩造間通訊體紀錄在卷可稽（見本院卷㈡第377頁），堪認被告所辯可採。又本院當場開啟系爭規格檔案「22.1常見問題_提案人」部分，對照被告系爭網頁之「22.1常見問題_提案人」部分，顯示箭頭與文字的距離為15PX、標題行高為30PX，標題與左側距離為40PX。又箭頭與文字的距離，被告指定之規格係從箭頭到文字的實際距離為15PX，原告所交付的15PX是箭頭，尚未到文字的距離；被告指定之標題行高行距為30PX， 0是文字到文字的距離，原告交付的標題行高是上面的文字到中段的距離為30PX，到下段文字的距離即為60PX；另標題與左側距離，被告指定之行距為40PX，原告所交付標題與左側距離為30PX，並有對照圖面在卷可稽（見本院卷㈡第393至395頁）。原告雖對上開畫面顯示情形並未爭執（見本院卷㈡第389頁），然主張因網站建置使用RWD技術製作，會依照電腦/手機螢幕尺寸不同而自動變更網頁物件尺寸，以達到最佳瀏覽效果，故此並非錯誤，網頁的設計稿尺寸本就僅提供單一尺寸參考云云。惟原告主張係RWD影響寬度排列順序部分，並不能成為行距高度不符合系爭規格檔案之理由，若不符合系爭規格檔案之施作規範，本即無法通過驗收，是被告辯稱此部分未通過驗收，應屬可採。（四）原告又主張其已依據第一、二、三階段之驗收時間交付網頁頁面及進行各項功能之測試，惟因兩造嗣後未確認複驗期日，依據系爭合約第3條第2項之約定：「乙方（即原告）應於約定期間內將工作完成後交付甲方（即被告）進行驗收測試。甲方應於接獲乙方交付後10個工作日內進行相關程式測試作業。甲方若於驗收測試後10個工作日內未提出異議或通知乙方改善，則視為作業驗收完成。如需改善，雙方應確認覆驗期日。」(見司促卷第6頁背面)，即應視為已驗收完成云云。被告對於原告主張其於第一、二、三階段之驗收時間有提出交付並未否認，惟辯稱：原告於第一階段所交付之網頁頁面有如下缺少之內容：「①3.4提案_已核准_發佈alert、②3.7募資中_已有人贊助_編輯off 、③4.4個資_贊助紀錄_已退款_信用卡、⑤1.2sidebar Mob ile login、⑥1.4HP login、⑦1.5HP notify、⑧1.6ca lis t、⑨1.6ca list hi、⑩5.1favorite、⑪5.2favorite list 、⑫6.2.1.1個資_會員相關_個人資料_變更信箱_驗證碼、 ⑬6.3路人甲_贊助沒資料、⑭6.3路人甲_發起、⑮6.3路人甲_贊助、⑯7.1通知_訊息、⑰7.1通知_訊息_內頁mobile、 ⑱7.1通知_留言、⑲7.1通知_留言_內頁mobile、⑳8.1Q&A s earch list、TOP icon」；第二階段所交付之工作項目有如下缺少之內容：「①首頁，缺少部分api串接，UI沒有調整、②登入註冊，缺少社群串接&條款連結、③探索頁，缺少api串接，UI沒有調整、④搜尋頁，缺少api串接，UI沒有調整、⑤專案card內容，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑥專案贊助收件人頁面，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑦路人頁面，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑧專案，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑨各狀態_提案內容，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑩預覽專案，看 UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑪ 會員相關，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑫贊助紀錄，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑬收藏管理，看UI畫面，缺少部分api串接、⑭通知，看UI畫面，沒有串接api即與第一階段內容測試結果一樣、⑮頁尾，有串接完成api」；第三階段所交付之工作項目，有如下缺少之內容：「①首頁，缺少串接收藏api、②登入註冊，缺少社群串接api、③搜尋，缺少串接收藏api、④收尋，缺少串接收藏api、⑤專案ca rd，缺少以下部分api沒串接：⑴贊助金額、⑵達成率、⑶贊助人數、⑷剩餘時間、⑸傳訊息（切頁）、⑹看網站、⑺目標金額、⑻留言（切頁）、⑼贊助者、⑽專案內容、⑾風險與變數、⑿贊助方案資訊，此部分包含方案名稱、方案圖片、方案內容、回饋數量、方案金額、寄送地址、預計寄送日期、⒀進度、⒁類別、⒂結束日期、⒃智付通（切頁）、⒄贊助詳情頁面，此部分包含寄送地區、贊助金額。⑥專案贊助收件人頁面，沒有串接api、⑦路人頁面，沒有畫面、⑧ 專案，缺少以下部分未串接api：⑴前往專案、⑵募資金額、⑶達成率、⑷剩餘時間、⑸無法新增專案（無任何專案時）⑹聯絡客服（無任何專案時）、⑨編輯中_提案內容，Api 串接，但缺少清除功能、UI畫面與示意圖不同、⑩送審中_ 提案內容，缺少再次送審api，缺少清除功能、UI畫面與示意圖不同、⑪審查中_提案內容，Api串接，UI畫面與示意圖不同且欄位沒限制、⑫已退件_提案內容，Api無串接，無法改變專案狀態、⑬已核准_提案內容，缺少進度更新 api串接，UI畫面與示意圖不同，欄位沒限制、⑭已發佈_提案內容，缺少進度更新api串接，UI畫面與示意圖不同，欄位沒限制⑮募資中_提案內容，缺少進度更新api串接，UI畫面與示意圖不同，欄位沒限制、⑯募資結束_提案內容，缺少進度更新api串接，UI畫面與示意圖不同，欄位及頁面沒限制、⑰預覽頁面，以下部分api未串接：⑴募資金額、⑵達成率、⑶剩餘時間、⑷贊助人數、⑸留言、⑹贊助者、⑺進度、⑻類別。⑱會員相關，缺少串接社群登入api、 ⑲贊助紀錄，不能測試，沒有串接金流、⑳通知，不能測試，沒有串接Firebase」，且被告均曾以電子郵件或通訊軟體通知原告提出修改及進行複驗，惟原告均未提出回應，業據提出通訊軟體紀錄為憑（見本院卷㈠第217至229頁；卷㈡第423至425頁）。查原告於第一階段107年10月9日提出交付後，稽諸兩造間107年10月16日通訊體紀錄內容：「上午10：28雅晴：@BO-Yuan Su您好，我們這邊已經整理好第一階段的回饋email至您的信箱再麻煩協助確認，謝謝。」（見本院卷㈡423頁）及107年10月22日通訊軟體紀錄內容：「（雅晴）：這邊想請問一下巧禾，明天是第二階段驗收日，麻煩提供二、三階段的驗收項目，另外，之前提供第一階段的回饋，請問都沒有問題嗎？若沒有問題，麻煩提供第一階段再次驗收時間，謝謝。」（見本院卷㈠第147頁），堪認被告已於原告交付後10日內就第一階段驗收項目向原告提出回饋，並通知原告進行複驗，惟原告並未舉證說明已就上開被告提出之回饋進行回覆及複驗，是原告主張第一階段應視為驗收完成，難認可採；又原告於第二階段107年10月23日提出交付後，稽諸兩造間107年10月31日通訊體紀錄內容：「下午05：06雅晴：hello這邊我剛寄出第二階段驗收的回饋信件，再麻煩協助確認，是否有收到信，以上，如果有任何問題再麻煩提出，謝謝。」（見本院卷㈡423頁），堪認被告已於原告交付後之 10日內就第二階段驗收項目向原告提出回饋，惟原告並未舉證說明已就上開被告提出之回饋進行回覆，是原告主張第二階段應視為驗收完成，亦難認可採；另原告於第三階段107年11月6日提出交付後，稽諸兩造間107年11月7日通訊體紀錄內容：「上午09：18雅晴已收回訊息上午09：19雅晴：請問google表單上的bug項目目前看都沒有改狀態->是都沒有調整bug項目嗎?https：//docs.google.com/spreadsheets/d/1p0_tHxPLePM0Bv0Uq47GrrxLnuxStXYLypyK4OpUKyc/edit#gid=0000000000”上午09：27柏宇（薯條）：早安。上午09：28柏宇（薯條）：請問柏原，接下來的項目跟修改，TimeTable什麼時候會給我們。」（見本院卷㈡425頁）及107年11月9日通訊軟體紀錄內容：「下午03 ：06柏宇（薯條）：請問有一個TimeTable嗎第三階段完成時間：XXXX第三階段剩餘功能完成時間：XXXX第一階段調整功能完成時間：XXXX第二階段調整功能完成時間：XXXX第三階段調整功能完成時間：XXXX下午03：27雅晴：這邊已經寄出第三階段驗收信件，再麻煩確認相關人員是否有收到信。」（見本院卷㈡第425頁），堪認被告已於原告交付後之10日內就第三階段驗收項目向原告提出異議，惟原告並未舉證說明已就上開被告提出之異議進行回覆，是原告主張第三階段應視為驗收完成，亦難認可採。（五）基上，原告於系爭合約所定之最後完工期限，仍有上述部分未完成，抑或未通過驗收之情形，是依上開說明，則原告請求被告給付剩餘之第2、3期工程款計22萬4,000元，難認有據。四、綜上所述，原告依據系爭合約請求被告給付22萬4,000元及自起訴狀繕本送達翌日起至清償日止，按週年利率5％計算之利息，為無理由，應予駁回。五、本件事證已臻明確，兩造其餘攻擊防禦方法及舉證，核與判決結果無影響，爰不另予一一論述，併此序明。六、訴訟費用負擔之依據：民事訴訟法第78條。中　　華　　民　　國　　111 　年　　4 　　月　　27　　日臺北簡易庭法官陳家淳以上為正本係照原本作成。如不服本判決，應於判決送達後20日內向本庭（臺北市○○○路0段000巷0號）提出上訴狀。（須按他造當事人之人數附繕本）如委任律師提起上訴者，應一併繳納上訴審裁判費。中　　華　　民　　國　　111 　年　　5 　　月　　6 　　日書記官蘇炫綺

臺北簡易庭108年度北簡字第12369號

關鍵資訊