AI 時代的專案經理該何去何從？從日本 JSOL 一場「利益」定義之爭，看懂 PM 的五個新基本功
同一家公司、同一個詞「利益」，經理部門算出來的數字，和事業部門手上的報表對不起來。兩邊都沒算錯，只是各自指的東西不一樣。
這是日本系統整合商 JSOL 的專案經理坪內進史，在一家大型製造商的成本管理專案裡所遇到的瓶頸。人跟人開會，這種模糊可以靠默契和經驗補過去；可是一旦要讓 AI 去分析資料，AI 沒有默契可言，它只會照字面把不同定義的數字混在一起算。
我想從這個案例出發，回答一個很多 PM 心裡都在打轉的問題：當 AI 大幅提升做東西的速度之後，企業是否還需要專案經理？
我當過專案經理，所以我對這個議題特別感興趣。
先看清楚 AI 拿走的是哪一塊
2019 年 3 月，Gartner 發了一則後來被引用無數次的新聞稿，預測到 2030 年，今天專案管理工作中有 80% 會被 AI 接手。很多人只記得 80% 這個數字，忘了 Gartner 點名的是哪些事：資料蒐集、進度追蹤、產出報告。這些本來就佔掉 PM 大把時間，也最容易被機器做得又快又準。
換句話說，被拿走的是 PM 工作裡「搬運資訊」的那一層。剩下來的，是決定該搬什麼、往哪裡搬、搬給誰看。
PMI（美國專案管理協會）在 2023 年的新聞稿（另開新分頁）中，則給出了另一個數字：只有 18% 的專案管理人員表示自己對 AI 工具有扎實或良好的實務經驗，49% 對專案管理脈絡下的 AI 幾乎沒有經驗或理解（PMI 註明這是未公開的內部研究）。工作內容在變，多數人的準備還沒跟上。
把這兩個數字擺在一起看，問題就很具體了：搬運資訊的活交出去以後，PM 要靠什麼留在場上？
坪內進史的答案：「其實沒有變太多」
Ledge.ai 在 2026 年 10 月刊出的這篇專訪（另開新分頁）裡，記者問坪內，AI 有沒有改變 PM 的工作？他的回答出乎意料：「作為 PM 的工作方式本身，我覺得其實跟以前沒有太大差別。」
先說明一下文章性質：這是 JSOL 的徵才專訪，文末附上了求才連結，所以我們讀的時候要記得它帶有招募目的。不過裡頭描述的專案過程很具體，值得拆開來看。
坪內（另開新分頁）說的「沒變」，指的是 PM 的核心任務：理解客戶、抓出課題、提出假設、把專案往前推。變的是這些任務的分量。以前 PM 花大量力氣在協調排程和追進度，現在那些交給工具，前面那幾件事直接決定專案成敗。
我從他的專案裡，整理出 AI 時代 PM 該練的五項基本功。
基本功一：把業務語言翻譯成資料語言
回到「利益」那道牆。坪內的團隊發現，要讓 AI 做出可信的分析，得先把「業務用語」和「實際資料欄位」一一對應起來。日本業界叫它「ビジネスセマンティクス」，技術上的載體是語意層（semantic layer）：哪個數字代表什麼、這家公司怎麼定義毛利、營業利益算到哪一層。
坪內原話是：「AI 要做高度的分析，就必須把商業用語和實際資料連結起來。」
這件事以前也存在，只是被藏在資深員工的腦袋裡，大家用默契繞過去。AI 一進場，這些默契全部要被寫成明文。誰來寫？工程師不懂業務，業務不懂資料結構，PM 正好站在兩邊中間。
所以 PM 不必會寫 SQL，但要能聽出「同一個詞，兩個部門在講不同的東西」，並且主持一場把定義講清楚的對話。
基本功二：先端出假設，再請客戶挑錯
定義要怎麼講清楚？坪內的團隊一開始也試過直接請客戶「定義一下」，結果沒有答案。經理、各事業部主管，每個人看的業務不同、要的數字也不同，光是對「哪個數字才是對的」達成共識就很難。
他們換了做法：自己先從實際資料裡列出可能的幾種模式，再根據使用者的角色和業務，提出哪種模式比較適合的假設，拿給客戶看。坪內說：「當然不可能一開始就拿一百分。我們先把假設端出來，請對方給回饋，再根據結果增加模式或整併。」
這是我覺得整篇訪談之中，最值得 PM 抄回去的一段。請客戶從零講出需求，對方往往講不出來；給他一個具體的東西挑錯，他馬上知道「這個不對」「這種情況會變成那樣」「那我也想看這個」。
坪內用了一個很好記的說法：客戶說了一，你能不能在背後想出十個假設。PM 的價值，在於讓客戶手上有東西可以做下一個判斷，而不是枯等需求自己浮現。
基本功三：決定先做哪一個原型
假設要驗證，就得做出東西來。過去的原型多流於靜態畫面展示，缺乏核心邏輯與動態交互，難以有效驗證使用者體驗：如果只看幾張畫面示意圖，客戶只能針對外觀給意見，沒辦法判斷「這套東西在我們的業務裡真的用得起來嗎」。
這次專案，坪內的團隊用 Databricks 在短時間內做出直接連上客戶真實資料的原型，還用了它的 AI/BI Genie 功能，讓使用者用自然語言直接對資料提問。客戶看到用自己的數字跑出來的結果，連原本沒察覺的課題都冒出來了。
做東西的成本降下來，看起來 PM 的壓力變小，其實是反過來。文章裡有一句我很同意：做的成本愈低，「該做什麼」「先解哪個問題」的判斷就愈值錢。可以試十個方案，就得決定先試哪三個、每個做到多細才問得出有用的回饋。這種排序能力，我在〈當答案變得不值錢，判斷力就是你唯一的複利資產〉也談過，放到專案現場，它就是 PM 的日常。
基本功四：預先看見團隊分工會怎麼變
這段比較少人注意。坪內在專案開跑前，就先實測過 Databricks 的 AI 功能，判斷「蒐集資料、加工資料」這類傳統資料工程的工作會被壓縮。於是他組隊時刻意不照舊配置一群資料工程師，改找偏分析師型、能直接跟客戶討論指標的工程師，讓他們把資料加工也一起包下來。
專案進行下來，這個配置真的跑得動。坪內的判斷是：「狹義的資料工程，也就是只做資料加工的那部分，單獨存在的價值會愈來愈小。」
對 PM 來說，這是一項新的工作內容：在別人還照舊編制報人力之前，自己先摸過工具，推估哪些角色會縮、哪些角色要擴，再據此組隊。這件事沒辦法外包給 AI，因為它需要你對自己的專案和自己的人都有判斷。
基本功五：從本行往旁邊多跨一步
最後一段，坪內被問到什麼樣的人適合這類工作，他的回答是：「想把自己現有的技能，和另一個領域相乘的人。」
他舉了兩個方向。工程背景的人，可以跟熟悉 SAP 和客戶產業的同事一起做專案，把專長往業務端延伸；在企業裡做過特定業務、聽到客戶講一就能想像背後十件事的人，則可以補上 AI、系統開發和專案管理，讓業務知識換一種方式發揮。
AI 讓實作門檻下降，於是 PM 可以自己動手碰工具驗證假設，工程師也能更深地走進客戶的業務。職務之間的牆變矮了，原本守著單一專長的人，反而容易被兩邊夾擊。
有人會問：那 PM 不就只剩軟技能？
讀到這裡，可能有人覺得這篇文章在講「溝通、同理、領導力最重要」這種老生常談。不過，我的看法剛好相反。
坪內這套做法之所以能成立，前提是他自己先測過 Databricks 的 AI 功能，知道它能做到哪裡；他敢跟客戶說「我們先做一個連真實資料的原型」，是因為他知道這件事兩三週就做得出來。沒有對工具的實際手感，假設會提得太保守，組隊會照舊，判斷也會失準。
PMI 那個 18% 的數字，指向的正是這個缺口。AI 時代的 PM 要當懂工具的業務翻譯者：手要碰得到工具，腦要聽得懂業務，嘴要主持得了跨部門的定義對話。缺了哪一塊，這五項基本功都練不起來。
這個月可以開始做的三件事
這三件事不需要預算，也不必等公司導入 AI，一個 PM 自己就能開始：
- 挑一個你手上專案裡最常被提到的指標（營收、毛利、活躍使用者都可以），分別去問兩個不同部門的人怎麼算。如果答案不一樣，你已經找到第一個語意層的工作。
- 下一次需求訪談，不要空手去問「你們需要什麼」，先帶一個粗糙的假設版本，請對方挑錯。
- 花一個週末，親手用一個 AI 資料工具或程式開發工具，做一個能跑的小東西。目的不是轉行當工程師，是讓你下次估工時、組團隊時，知道現在的工具做得到哪裡。
做東西會愈來愈快，但專案不會自己往前走。坪內在訪談最後說，商業上的成功本來就沒有標準答案，PM 的工作是跟客戶一起試，直到回頭看時覺得「那個選擇是最好的」。這句話放在 AI 時代，一樣成立。
參考資料
- Ledge.ai〈答えのない課題を、どう前に進めるか。AI時代のPMに求められる力とは〉，2026 年 10 月 27 日：https://ledge.ai/articles/jsol_career_interview_pm（另開新分頁）
- Gartner, “Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over”, 2019-03-20：https://www.gartner.com/en/newsroom/press-releases/2019-03-20-gartner-says-80-percent-of-today-s-project-management（另開新分頁）
- PMI, “Demand Increases for Project Professionals with AI Skills, Yet PMI Research Finds Only 18% Have Practical Experience”, 2023：https://www.pmi.org/about/press-media/2023/demand-increases-for-project-professionals-with-ai-skills（另開新分頁）
讀完，下一步
把內容做成一套系統
AI 內容產製系統工作坊
一份素材，自動產出六種格式
繼續讀：AI 實戰應用指南動手試：AI 協作界線卡（另開新分頁）
