哪些業務系統可以自己開發、哪些該繼續用SaaS｜看資料更新頻率

大家好，我是株式會社TIMEWELL的濱本 隆太。

這是「解約高價SaaS、自己重新開發」五篇系列的第二篇。第一篇判斷基準整理了考慮解約時要看的項目。這一篇處理更前面的問題：公司裡用了幾十套SaaS，應該從哪一套開始列為重新開發的候選？

我的看法很簡單，從資料更新頻率低的開始。合約清冊、內部常見問答、企業入口網站、設備與請購的申請、報價清冊。這些系統的資料欄位幾乎不會變，一天寫入的筆數也不多。生成式AI讓開發的工夫大幅降低之後，我認為自己做、自己維護，已經不太會出問題。

不過，這個說法有個陷阱。依變化速度替業務系統分類，最具代表性的框架是Gartner的步調分層（Pace-Layered），而照原文的讀法，變化慢的核心系統反而應該用標準套裝軟體。如果只說「因為變化慢所以可以自己做」，等於說了和原文相反的話。所以本文在變化速度之外，再加一個「輕重」的軸（複雜度、交易量、法規負擔），把業務分成四類。像清冊、常見問答這種又慢又輕的，是自行開發的候選；像會計、薪資這種慢但重的，繼續用SaaS。文中也附上各業務的速查表。

先說清楚一點：以資料更新頻率來決定自建或採購的公開框架，在我們查得到的範圍內並不存在。兩個軸的整理是我們自己的看法。我們以FDE的身分進到客戶現場時，也是依這個順序挑選候選。

SoR、SoE、SoI與步調分層，先把名詞對齊

替業務系統依性質分類的說法，主要有三個出處。

最早的是美國管理顧問Geoffrey Moore在2011年白皮書中提出的SoR（Systems of Record，紀錄系統）與SoE（Systems of Engagement，互動系統）。Moore把SoR描述為企業過去數十年來承載業務流程的工具、資料存放處與系統；SoE則疊加在對SoR的大量投資之上，提供網頁存取、跨軟硬體平台的易用性，以及跨組織的協作¹。把會計、訂單紀錄正確留存的是SoR，員工與客戶互動的場域是SoE，這樣記大致不會錯。

2015年，美國研究機構Forrester的Brian Hopkins加上了SoI（Systems of Insight，洞察系統），定義是「掌握洞察、並持續把資料轉化為有效行動的業務紀律與技術」²。可以把它想成：把累積在SoR的紀錄、發生在SoE的互動，轉成判斷與行動的那一層。

步調分層的切入點不同。這是Gartner在2012年2月發布的框架，依變化速度把應用程式分成三層³。第一層SoR，是支撐核心交易處理、管理組織重要主檔資料的成熟套裝軟體或既有的自建系統。原文說它變化慢，是因為流程已經成熟、大多數組織共通，而且常受法規要求約束。第二層Systems of Differentiation（差異化系統），支撐公司獨有的流程或產業特有的功能，生命週期是一到三年的中等長度，需要配合業務做法或客戶需求頻繁調整設定。第三層Systems of Innovation（創新系統），是為了回應新需求或新機會臨時建置、通常在零到十二個月內結束任務的一層。

Moore的SoR和Gartner的SoR名字一樣，軸卻不同。Moore依角色分（紀錄或互動），Gartner依速度分。搜尋「SoR SoE 差異」時，常會看到兩者混在一起的說明；但思考自建或採購時，真正派得上用場的是Gartner的速度軸。

這些名詞在日本也已經普及。日本經濟產業省在2024年9月第一次「老舊系統現代化委員會」提出的資料中整理指出，核心系統（SoR）的資料也可以用在前台系統（SoE）與資料分析、洞察領域（SoI），並寫道前台服務隨著雲端普及，SaaS等的運用正在增加⁴。日本的IT Passport國家考試大綱，也把SoR與SoE列為用語範例⁵。

照原文讀，「變化越慢越該買」

這裡就和開頭的看法衝突了。原文把SoR定義為成熟的套裝軟體或既有的自建系統，並要求支撐核心業務的環境要安全、具成本效益³。照這個定義，變化慢的SoR正因為大多數組織共通，與其各家自己做，不如用多家公司分攤開發費的標準套裝軟體比較合理。「資料更新頻率低所以可以自己做」，照原文直接讀，方向是反的。

日本的公部門指引也朝同一個方向。經濟產業省2020年12月的「DX報告2」寫道，企業在協作領域應排除凡事自己做的心態，推動業務流程標準化，運用SaaS與套裝軟體⁶。日本數位廳在2025年5月修訂的政府資訊系統雲端運用基本方針（DS-310）也要求，基於減少開發量的觀點，應廣泛且優先評估使用SaaS，甚至設了「徹底採取不自己做的做法」這一項⁷。前面提到的現代化委員會資料，也寫到讓業務配合新系統或SaaS、整體搬遷過去的「Fit to Standard」有多重要⁴。

企業的實際做法也是如此。依日本IPA（資訊處理推進機構）的「DX動向2025」，在非核心、非競爭領域的系統取得方式上，日本企業導入套裝軟體占33.8%、導入SaaS占24.4%，自行開發只有16.6%。同一題美國企業的自行開發是40.1%，SaaS是11%⁸。日本企業一直是用SaaS和套裝軟體來撐起業務的周邊。

那麼，在原文和公部門指引的前提下，還有哪裡能說「可以從變化慢的開始自己做」？線索就在DS-310裡。DS-310一方面強力推薦SaaS，一方面提醒這不是無條件的推薦。它的寫法是：預期使用者人數會逐步增加時，營運階段的SaaS使用費可能變得很高，因此必須從生命週期成本的角度，審慎評估是否真的能省錢；如果其他代管服務（managed service）也能做到和SaaS相同的功能，就該把兩種方式拿來比較；對依帳號數計費的SaaS和高價SaaS要特別留意⁷。同一份文件同時也要求在開發中運用生成式AI。

政府的指引自己就把選SaaS的理由，和不選SaaS的條件並列寫出來了。我認為，分辨的關鍵就藏在這段例外的寫法裡。

在變化速度之外，加上「輕重」的軸

回頭重讀Gartner說SoR變化慢的理由，有兩個。大多數組織共通。以及，常受法規要求約束。兩者都是選套裝軟體的理由，性質卻完全不同。

「因為共通所以買」，是分攤開發費的邏輯。與其一百家公司各做一套，不如一家公司做好賣給一百家，比較便宜。開發越貴，這個邏輯越有力。生成式AI降低開發的工夫之後，系統越單純，分攤帶來的好處就越小，反倒是依人數每月一直付下去的費用變得顯眼。

「因為受法規約束所以買」，是分攤追法規變化成本的邏輯。這部分即使用生成式AI，也幾乎不會縮小。要讀懂修法、轉成計算規格、在期限前測試完畢，出錯時還得負責。這些都和寫程式的速度無關。

所以我在變化速度的軸之外，再加上輕重的軸。變化速度用資料更新頻率來量，並拆成兩部分：一天寫入幾筆紀錄，以及一年想改幾次欄位、畫面或規則。輕重則看三件事：計算與例外的複雜度；交易量（筆數、同時使用人數、停擺時會卡住的業務）；法規負擔（被外部規定要求修改的頻率，以及出錯時的責任）。

	輕（單純、量少、法規負擔輕）	重（複雜、量大、法規負擔重）
變化慢	① 自行開發的候選（清冊、內部常見問答、企業入口網站、申請、報價清冊）	② 繼續用SaaS或套裝軟體（會計、薪資、核心系統讀取的主檔正本）
變化快	③ 做完用完就丟（雛型、一次性統計、行銷活動）	④ 組好團隊再審慎判斷（對客戶的服務、CRM核心、生產排程）

和Gartner的三層對照，②就是原文所說的SoR，③大致相當於Systems of Innovation，④大致相當於Systems of Differentiation。①在原文裡也算SoR，但選擇套裝軟體的兩個理由中，只剩下「因為共通」這一個。我們的看法是，生成式AI讓開發變便宜時，最先翻轉損益的就是這一格。

研究結果和這條界線並不矛盾。2023年的一項實驗中，使用GitHub Copilot的組別用JavaScript實作HTTP伺服器，比對照組快了55.8%，而那是一個規模小、規格明確的題目⁹。另一方面，METR在2025年做的隨機對照試驗裡，16位在大型開源專案（平均超過2萬2,000顆星、100萬行以上程式碼）貢獻多年的資深開發者，在可以使用AI的條件下，完成任務反而多花了19%的時間。他們事前預估會快24%，事後也仍然覺得快了20%¹⁰。METR在2026年2月又推估，2025年底的工具讓作業時間縮短18%，但信賴區間是負38%到正9%，跨過零點，METR自己也註明參與者的篩選偏誤讓真正的效果難以看清¹¹。Google的DORA 2025年報告也指出，AI的使用和軟體交付的產出量呈正相關，和交付的穩定性呈負相關，並總結說：AI不會修好一個團隊，只會放大團隊原本的樣子¹²。

小而單純的工作會變快，大而複雜的工作，速度和穩定都沒有保證，這是我的解讀。①容易自己做，②和④要審慎，理由就在這裡。

我之前在AI要自己做到什麼程度一文中寫過，變更越頻繁的東西越該放在公司內部。聽起來可能和本文相反，但問的問題不一樣。那篇談的是提示詞、確認流程這類「調整由誰掌握」，理由是每次調整都要對外發包，改善就會停下來。本文談的是「繼續付月費，還是做一次自己擁有」。變化慢的系統上線後很少需要動，就算開發時借助外部力量，之後自己維護的負擔也小。兩篇合起來，就是變化快的調整留在公司內，變化慢的容器便宜地做好、自己擁有的分工。

各業務速查表

套用到具體業務。下表是我們以一般企業為前提的參考。

業務	變化速度	輕重	判定	判斷關鍵
內部常見問答、知識庫	慢。每週新增幾篇，欄位幾乎固定	輕	① 自行開發候選	是否需要依部門區分可見範圍
企業入口網站（公告、規章、連結）	慢	輕	① 自行開發候選	會不會和既有的群組軟體重複管理
合約、設備、證照等清冊	慢	輕	① 自行開發候選	是否要保存電子合約本身
簽呈、請購的申請與簽核	慢。簽核路徑一年調整幾次	輕到中	① 自行開發候選	例外路徑有幾條、是否要把分錄交給會計
報價清冊（編號、歷史、與案件的連結）	慢	輕	① 自行開發候選	報價的計算本身是否就是競爭力
費用報帳	每月、全員寫入	重（發票與憑證保存等法規）	② 繼續用SaaS	可以只把申請入口自己做
出勤管理	每天、全員寫入	重（全員每天使用，連到薪資計算）	② 繼續用SaaS	可以只把打卡入口自己做
會計	結構變化慢，但每天都有分錄	重（稅制、發票法規）	② 繼續用SaaS	從周邊清冊把分錄資料送進來
薪資計算	每月。規則幾乎年年變	重（稅制修正、年度扣繳結算）	② 繼續用SaaS	無
料號、往來廠商等主檔正本	慢	重（核心系統會讀取）	② 放在核心系統	自建的清冊只讀取正本
分析儀表板、雛型	快	輕	③ 做完就丟	是否有用完就刪除的規則
客戶管理（CRM）核心	快	中到重（全體業務人員、與其他系統串接）	④ 組好團隊再判斷	能否只切出周邊的清冊

①列出的業務，多半已經是用SaaS來處理的領域。依日本總務省的「令和7年通信利用動向調查」，在使用雲端服務的企業中，把「內部資訊共享、入口網站」列為使用項目的占61.4%，僅次於「檔案保管、資料共享」的73.3%，排名第二；「薪資、財務會計、人事」也有56.3%¹³。前者是可以列為重新開發候選的大母體，後者則是繼續付費比較好的領域，這是本文的整理。

把會計和薪資放在②，是因為修法的頻率。以日本為例，2023年10月1日開始實施適格請求書制度（Invoice制度）¹⁴。2024年6月起定額減稅在薪資扣繳中實施，支付薪資的雇主必須在扣繳稅額的計算上反映這項減稅¹⁵。2025年12月的年末調整（日本由雇主代為結算員工全年所得稅的程序），又必須配合令和7年度稅制修正中基礎扣除與薪資所得扣除的調整¹⁶。大約兩年之間，至少來了三次有期限的變更。台灣也一樣，最低工資自105年以來已連續10年調漲，115年1月1日起每月最低工資調升為29,500元、每小時196元¹⁷，薪資計算每年都得跟著確認。會計、薪資SaaS的業者是替所有客戶一次承接這些追趕工作。系統若自己擁有，就得自己養人去讀法規、轉成規格、在期限前測試。AI能縮短的只有實作的部分，讀懂法規和承擔責任，並不會變短。

表中的判定只是起點。Gartner自己也寫道，同一個應用程式可能因使用方式及與商業模式的關係，在不同公司被歸到不同層，而且會隨著成熟在層與層之間移動³。報價就是好例子。只管理報價編號與歷史的報價清冊屬於①；但對於要從圖面和製程往上累計成本的製造業來說，報價的計算本身就是競爭力，屬於④。同樣叫「報價」，放在哪一格因公司而異。

會計與人事勞務，也不必整套放在SaaS

速查表把會計、薪資、出勤放在②「繼續用SaaS」，但更精確地說，留在SaaS的是原始紀錄與法定處理。會計與人事勞務的SaaS裡，同時裝著「法令決定的部分」和「公司自己決定的部分」。可以自己開發的，只有後者。

業務	留在SaaS（或交給專業人士）的部分	可以自己開發的部分
會計	分錄的原始紀錄、結帳、報稅、電子交易資料的保存	費用申請的入口、預算管理、管理會計的彙總與畫面
人事勞務	薪資計算、社會保險與就業保險的手續、年末調整、個人編號（My Number）的管理	考核、目標、培訓、到職手續的說明、公司內部的申請畫面
報價與請款	開立請款單、收款核銷、交易文件的保存	報價的計算方式、單價表、案件與報價的清冊

做法是：全體員工會碰到的畫面自己開發，資料再透過API寫進會計或人事勞務的SaaS。會打開SaaS畫面的只剩會計和人事的負責人，其他員工的帳號可能就不再需要。越是依帳號計費、帳單隨使用者人數膨脹的SaaS，這種做法的效果越大。借用Moore的說法，就是不動SoR，在上面疊一層公司自己的SoE¹。

報價特別適合這種做法。在日本，適格請求書制度的要件是套用在請款單等文件上¹⁴，報價單主要面對的是以電子方式往來時的保存要件¹⁸。而且報價的方式，從單價怎麼定到折扣怎麼給，每家公司都不同。如前一節所說，對製造業而言，報價的計算本身就是競爭力。請款與收款核銷留在SaaS，產出報價的部分自己掌握，這是比較務實的切法。

有一點要注意。部分SaaS或套裝軟體的合約中，有條款規定：讓沒有授權的人透過API或串接間接使用，也要付費（一般稱為間接存取或multiplexing）。在把畫面改成自己開發、減少帳號數之前，請先在合約中確認有沒有這類條款。如果有，能減少的帳號數就會不同。

本公司的內部入口網站也採用這種做法：透過API讀取會計SaaS的資料並顯示，分錄的原始紀錄則留在會計SaaS那一側。

看起來輕、其實很重的情況

就算看起來屬於①，動手之前還有五件事要確認。每一件，都是重量藏在單純外表底下的情況。

第一，是否要保存電子文件本身。依日本國稅廳的說明，若以電子資料收受或交付相當於紙本時必須保存的訂購單、合約、報價單、請款單等，就有義務以電子方式保存這些資料，原則上要做到三件事：防竄改的措施、備置可供確認的螢幕等設備，以及能用日期、金額、交易對象三個要素搜尋¹⁸。合約清冊如果只管「哪份合約何時到期」，就還是輕的；如果還要兼作電子合約的存放處，就得做成能留下更正與刪除紀錄的系統。不是做不到，但一開始有沒有把它列入需求，之後的返工會差很多。

第二，這份清冊是不是正本。依Gartner的定義，管理組織的重要主檔資料是SoR的工作³。把會計、訂單會讀取的料號、往來廠商、會計科目等主檔搬到自建的清冊，本來以為是①，結果卻把②扛在身上。比較安全的做法是讓自建清冊只讀取正本，寫入留在核心系統那一側。

第三，權限有多細，以及是否有外部人員使用。在2023年資安國際會議ACM CCS發表的一項實驗中，可以使用AI助理的參與者，寫出的程式碼比不能使用的人更不安全，而且更容易相信自己的程式碼是安全的¹⁹。這是當時模型的結果，但我認為登入、權限、稽核紀錄，不是每次都讓AI從零寫起的地方，應該放在已驗證的共用基礎上。像供應商使用的入口網站這樣對外開放的系統，請把輕重的判定往上調一級。

第四，停擺時會卡住什麼。內部常見問答停擺半天，業務照樣運作；用來下出貨指示的清冊一停，出貨就停了。即使寫入筆數少，停擺影響大的系統也要放在重的那一側。

第五，有沒有人長期維護。在同一份IPA調查中，正在推動自行開發的日本企業，把「人才難以確保與培育」列為第一大課題，占82.3%⁸。開發成本再低，如果沒有人加欄位、回答使用者的問題、處理一年幾次的變更，只是多了一個沒人管的應用程式。DORA說AI會放大原本的樣子，在沒有負責人的組織裡，放大的就是沒有負責人這件事。

通過這五項確認的，再排出優先順序。我們建議的盤點步驟如下。

1. 在使用中的SaaS清單上加五欄：每天寫入筆數、過去一年修改欄位或規則的次數、相關法規、串接的其他系統數量、使用人數與計費方式
2. 依變化速度與輕重，把每套SaaS放進①到④
3. 在①之中，優先挑選依帳號計費、費用隨使用人數增加而膨脹的（這正是DS-310特別提醒留意的類型⁷）
4. 確認資料能否匯出，以及格式與步驟（SaaS解約與系統移轉實務）
5. 比較自建並擁有，與繼續付費的五年總額（SaaS五年總額試算）
6. 決定要放在哪裡（把業務應用程式放在自家雲端的設計）

步驟1的五個欄位，都限定為看帳單、各SaaS的管理後台，再加上和使用者簡短聊一下就能填好的項目。如果到步驟3時候選能縮到一兩個，就算很好的結果了。

與委外開發的不同

決定要做①的系統之後，找誰做會影響結果。

用委外開發做①，通常是每家公司從零開始做清冊或常見問答，再依工時請款。可是①的系統，換了公司骨架也很像：登入與權限、變更歷史、搜尋、簽核關卡。不同的大概只有欄位名稱和簽核路徑。每次都重做骨架，這些工時就由客戶每次買單。

我們的FDE把這副骨架當成產品端的共用機制，只把各家不同的欄位與簽核路徑，放成那家公司的設定。在現場找到的共通模式會回流到產品，下一家公司就能相應地做得更快、更便宜。所以對我們而言，現場的工時不是營收，而是投資，每家客戶的工時越少越好。結束的方式也不同。不是驗收就結束，而是等到客戶的負責人能自己加欄位、改簽核路徑時才結束。我們不在也能運作，才算完成。

我認為這個形式，接近日本經濟產業省在「DX報告2」中預期的關係。該報告寫道，使用者企業轉向自行開發的過程中，內部人才往往無法立刻因應，因此支援轉型、一邊從旁協助一邊移轉技能的需求會增加；並主張不應把它做成派駐客戶端的生意，而是要成為一起培育、一起開發的關係⁶。重新開發①的系統，正好是用小規模嘗試這種關係的大小。

我們的FDE能做什麼

我們的FDE（Forward Deployed Engineer，進到客戶現場、把課題變成可運作軟體的工程師），在重新開發SaaS功能時承接的範圍如下。

首先，我們會一起參與盤點。和客戶一起看SaaS清單與帳單，填好前一節的五個欄位，把每套放進①到④。哪些不該自己做，也在這個階段講清楚。放在②的，就從重新開發的名單中拿掉。

接著，從①裡只挑一套，在第一天就讓客戶看到用遮蔽個人資料後的實際資料運作的雛型。我們不會一次替換好幾套。期間是45到90天，一開始就決定結束條件（例如負責人能自己加欄位、改簽核路徑）。費用依期間決定，不以工時累加計算。

系統原則上放在客戶自己的雲端環境。處理資料的地區，會設計成可以依客戶需求選擇。使用的AI模型與服務，只挑不會拿客戶資料做訓練的。TIMEWELL已取得ISO/IEC 27001認證（認證範圍：運用AI技術之SaaS產品的企劃、開發與提供）。

解約的時程也一起安排：從續約日倒推的通知期限、資料匯出的試跑、雙軌並行的期間。系列第四篇SaaS解約與系統移轉實務的內容，就是我們實際使用的步驟。整體做法整理在FDE服務頁面。

我們的實踐與限制

我們自己公司內部，也是依這條界線區分系統。內部入口網站是自己開發、自己營運的，上面有合約清冊與到期管理、電腦與器材的財產清冊、使用中的SaaS清冊、簽呈的申請與簽核、出差申請、公司規章、資安訓練、每週目標、工作日報。速查表中放在①的項目，幾乎原封不動地排在那裡。另一方面，會計、人事勞務、報價單的開立，仍然使用雲端SaaS。財產清冊是自建的，但會計上的固定資產帳在SaaS那一側，自建的清冊只記下它的編號。等於我們自己也照著前一節第二項確認點在做：正本只讀取，不自己持有。

出勤的做法稍微不同。打卡的入口放在自建的入口網站，出勤紀錄的正本與軌跡則留在SaaS那一側。這正是Moore所說，把SoE疊在SoR之上的形式。報價單的開立之所以留在SaaS，是因為它一路連到請款與收款，也受日本適格請求書制度的要求約束。自建這一側持有的，只有把報價和案件連起來的清冊。

也有不順利的地方。我們在內部入口網站做了工作日報的輸入畫面，但剛上線時幾乎沒人使用。後來才加上依前一天的行程與紀錄自動準備草稿的機制，以及傍晚的提醒。開發成本降低了，讓人願意使用的設計工夫卻沒有減少。要自己做，就得把這份工夫也算進去。

不承接的事也寫清楚。把會計、薪資、出勤的正本從SaaS搬到自建系統的案子，我們不承接。那是②的領域，等於讓客戶自己去扛追法規的工作。搬移核心系統讀取的主檔正本也一樣。公司內部連一位能長期維護的負責人都定不下來時，我們不會開始。供應商等大量外部人員使用的系統，就算看起來屬於①，也當成重的處理，期間和團隊另外討論。

兩個軸的整理本身也有限制。以資料更新頻率決定自建或採購的想法，在公部門指引或研究機構的框架裡都找不到，只是我們的看法。速查表的判定，也只是以一般企業為前提的參考。另外，我們是小公司，能同時進駐的現場數量有限。

結語

• SoR與SoE是依角色分（Moore，2011年），步調分層是依速度分（Gartner，2012年），軸不一樣
• 照Gartner原文讀，再看日本的公部門指引，變化慢的核心系統都以套裝軟體或SaaS為主。只說「變化慢所以能自己做」，會和原文相反
• 原文說SoR變化慢的理由有「共通」和「受法規約束」兩個。作為選套裝軟體的理由，生成式AI只會削弱前者
• 所以要在速度之外加上輕重（複雜度、交易量、法規負擔）。又慢又輕的清冊、常見問答、企業入口網站、申請、報價清冊，是自行開發的候選
• 會計與薪資慢但重。2023到2025年間有期限的修法接連而來，繼續用SaaS比較合理
• 但留在SaaS的只有原始紀錄與法定處理。全體員工會用的畫面可以自己開發，把SaaS帳號減到只剩負責人（先確認合約中的間接存取條款）
• 動手之前，先確認文件保存、是否為正本、權限與外部使用、停擺影響、由誰維護這五點

自建還是採購，不是一次替所有系統決定的問題。先在SaaS清單上加五欄，找出一套屬於①的系統，確認它是不是真的那麼輕。從這裡開始，就算失敗也只是小失敗。

想一起找出①的候選，或希望重新開發後能由自家團隊持續維護的話，歡迎看看FDE服務頁面，或透過FDE個別諮詢和我們聊聊。下一篇，我會用數字比較繼續付費與自建擁有的五年總額。

Footnotes

1. New Geoffrey Moore White Paper on Future of Enterprise IT（AIIM，2011年1月19日）。白皮書「Systems of Engagement and the Future of Enterprise IT」中對SoR與SoE的說明出自此文（筆者翻譯） ↩ ↩²

2. All your big data will mean nothing without systems of insight（Brian Hopkins，Computerworld，2015年9月21日） ↩

3. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation（Gartner，2012年2月14日，MarketScreener轉載的新聞稿）。三層的定義、SoR變化慢的理由、對核心流程環境的要求、同一應用程式可能因公司而被歸到不同層等，皆出自此新聞稿（筆者翻譯） ↩ ↩² ↩³ ↩⁴

4. 關於老舊系統現代化委員會（日本經濟產業省商務資訊政策局資訊產業課，第一次老舊系統現代化委員會資料3，2024年9月12日，日文）。SoR、SoE、SoI的整理在第14頁，Fit to Standard在第13頁 ↩ ↩²

5. IT Passport考試大綱 Ver.6.5（IPA，日文）。戰略目標的用語範例中列有SoR與SoE ↩

6. DX報告2（期中彙整）（日本經濟產業省，2020年12月28日，日文）。在協作領域排除凡事自己做的心態見本文第22頁，轉向自行開發的協助與技能移轉見第24至25頁 ↩ ↩²

7. DS-310 政府資訊系統適當運用雲端服務之基本方針（日本數位廳，2025年5月27日數位社會推進會議幹事會決定，日文）。對依帳號計費SaaS的提醒、以生命週期成本比較、「徹底採取不自己做的做法」皆出自此文件 ↩ ↩² ↩³

8. DX動向2025（IPA，2025年6月26日，日文）。系統取得方式見圖表2-13（日本非核心領域 n=1,475，美國 n=509），自行開發的課題見圖表2-16（正在推動自行開發的日本企業 n=334） ↩ ↩²

9. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot（Peng、Kalliamvakou、Cihon、Demirer，arXiv，2023年2月13日） ↩

10. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR，2025年7月10日） ↩

11. We are Changing our Developer Productivity Experiment Design（METR，2026年2月24日） ↩

12. Announcing the 2025 DORA Report（Google Cloud，2025年9月24日） ↩

13. 令和7年通信利用動向調查 報告書（日本總務省，2026年5月29日公布，日文）。使用中的雲端服務內容見圖表4-3（n=2,133，複選） ↩

14. 關於適格請求書制度（日本國稅廳，日文） ↩ ↩²

15. 定額減稅（薪資）專區（日本國稅廳，日文） ↩

16. 令和7年度稅制修正之所得稅基礎扣除調整等（日本國稅廳，日文） ↩

17. 最低工資連十漲！審議會決定自115年1月1日起，每月最低工資調升至29,500元，每小時最低工資調升至196元（勞動部，2025年9月26日） ↩

18. 電子帳簿保存法：2024年1月以後電子交易資料的保存方式（日本國稅廳，2024年11月，日文） ↩ ↩²

19. Do Users Write More Insecure Code with AI Assistants?（Perry、Srivastava、Kumar、Boneh，ACM CCS 2023）。實驗使用的是以OpenAI codex-davinci-002為基礎的AI助理 ↩