臺灣臺北地方法院民事判決
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日；第三階段之開發項原為：1 7、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=1tXEhUrJq2SupgwCi6A 2FYPt_LOxrVktmzeplin：https：//zpl.io/2GOOLLrAPL o verflow：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.hero kuapp.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/GetPro jectListByAll嗎？下午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弟仔）稱：「疑等等… ，這邊要做輪播對吧？」，原告員工蔡明軒回覆：「對」 ，可認被告辯稱原告先前本即要製作輪播背景及對話框之 功能，又被告員工雅晴雖稱：「就是預設圖。這一塊美術 正在設計中。」及原告員工蔡明軒所稱：「中間的文字bo x就不顯示嗎？」，係指懷舊古老腳踏車風不顯示，即預 設圖部分被告要設計一張圖取代原腳踏車的圖，並非被告 自己要設計主視覺輪播區塊，且中間文字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區）社群串接註冊：Faceb ook、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區）推薦/ 分類：點擊開啟下拉式選單，依選單內容篩選下方專案ca rds。（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+；We bsite btn：點擊外開網站；提案人聯繫btn：點擊即開啟 1對1私訊詢問。（B區）分頁切換區：內容、進度、風險 、留言、贊助者；贊助方案btn：募資結束、贊助中、登 入/未登入；（C區）內容區：顯示提案人填寫內容；（D 區）贊助方案區：顯示該專案底下贊助方案。」（見司促 卷第8頁背面）。被告雖稱依據系爭規格檔案檢視，原告 於系爭網址所製作之內容，（C區）內容區缺少顯示提案 人填寫的全部內容（此部分被告僅要求照片及文字內容之 示意及文字格式，見本院卷㈡第175頁）；（D區）贊助方 案區缺少顯示該專案底下贊助方案全部內容（此部分被告 亦僅要求照片及文字內容之示意及文字格式，見本院卷㈡ 第175頁），並提出規格對照表為憑（見本院卷㈡第57頁） 。然原告主張係被告引用網頁面錯誤，正確網頁頁面位置 係位於107年10月9日第一次驗收信件附件2.專案/2-2-1.h tml中（見本院卷㈡第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字型之指令，惟因微軟系統已無此種ME IRYO字型，故原告於107年9月19日向被告表明後，被告回 覆就使用微軟正黑體，故原告所使用之字型MEIRYO、字型 寬度700並無違誤云云，固據提出兩造間通訊軟體內容為 憑（見本院卷㈡第371頁）。惟被告辯稱：被告當初要求之 字型為MEIRYO、字體寬度BOLD，且被告於原證10的通訊軟 體通話中，已有表明MEIRYO是MS系統的文字，並標註微軟 字體的網頁(https:docs.microsoft.com/en-us/typograp hy/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技術製作，會依照電腦/手機螢幕尺寸不同 而自動變更網頁物件尺寸，以達到最佳瀏覽效果，故此並
, 台灣公司情報網
, 台灣公司情報網
, 台灣公司情報網