🔧 阿川の電商水電行
結論是，我有以下的看法。
- PM需要“技術能力”
- 不過這並不是指會寫Java或能搭建AWS環境的「實作技能」，而是指 技術素養（判斷能力），使其能進行技術上的判斷。
另一方面，從現場或求職廣告來看，「PM必須包打天下」的案件 相對普遍，這導致PM所需的技術能力和工作範圍擴大到過頭（＝PM無法專心做PM），經常會發生此類情況。
在這篇文章中，我將探討：
- PM是做什麼的人？
- PM所需的「技術能力」是什麼？（應該朝哪個層次邁進）
- 為什麼「萬能PM」是危險的？
- 不合適的PM招聘是什麼？
我將以 建設（住宅建築）專案 作為例子來進行整理。
（※因為我不是建設實務的專家，如果有嚴格不合的地方請在評論中告訴我！）
1. IT專案與「蓋房子」相似
我認為，IT系統的構建可以比擬為蓋房子的過程。
在住宅建築中，大致會有如下的角色分配。
- 施主（客戶）：提出「想蓋這樣的房子」的需求並支付報酬的客戶
- 設計（架構師）：將施主的需求以結構上可行的形式進行設計，並承擔設計責任的專家
- 施工管理（PM）：負責預算、工期、品質的管理，協調現場順利運行的管理者
- 工匠（工程師）：根據設計圖進行實際建造，將房子變為現實的技術人員
這樣，各自的角色本應明確分開，這才是正常的狀態。
2. 個案研究：如果「木工」缺少一位怎麼辦？
以下是我最感到不適的點。
專案上常會出現麻煩。例如，假設團隊中的一名成員因病缺席。
2-1. 住宅建築：如果缺少一名木工
假設有一位木工因病缺席。這時，施工管理應該會這樣行動。
- 配置額外人員（工匠）
- 調整工序（變更優先順序、安排）
- 如有必要，向施主說明情況並調整交期
施工管理人員不會說 「我來替代打釘子」，這幾乎是不可能發生的事情。
（如果是小規模的DIY另當別論，但在大型環境或角色設計中，這種情況顯得不自然。）
2-2. 但是，IT行業又如何呢？
同樣的情況在IT中會怎麼樣？假設一名應用程式工程師因病缺席。從理論上來看，
- 應該進行額外人員的調整
- 確認影響範圍（會延誤什麼）
- 交涉範圍、優先順序和交期
……但是在IT行業中，卻經常出現PM同時兼任工程師以填補空缺的情況。
說PM自己打開編輯器開始編碼以進行彌補竟然被視為一種「美德」。
而且一旦發生，就會變成常態，最終導致如下情況。
「萬能的瑪莉PM（萬能PM）」的誕生
PM拋棄了原本的管理業務，自行以「技術能力」和「工時」填補設計（架構）或建造（工程師）的空缺，這是一種末期的狀態。最後甚至承擔起年輕人的OJT，PM的資源就完全崩潰了。
3. 萬能PM是正確的姿態嗎？ PM究竟是做什麼的人？
在此，我想對PM的角色進行一次語言化整理。
我認為這一整理中， IPA（資訊處理技術者考試的大綱） 是非常好用的工具，還有PMBOK也不例外。
3-1. IPA（專案經理考試）的PM人物像
IPA的專案經理是等級4（高級），處理的不是「實作」，而是 為了使專案成立的管理。
簡而言之，
- 啟動：定義目的、成功條件、體制、約束
- 計劃：範圍、時間表、成本、品質、風險、採購、溝通、持份者
- 執行與監控：進度掌握、問題與變更管理、決策、共識形成、糾正
- 終結：接受、移交、回顧（知識化）
這些都屬於「PM的工作」的核心內容。
（題外話）有準備論文考試的人會明白，如果PM在文章中深入設計和實作的部分，其午後2的評分通常會下降。
因為會被問到「PM做了什麼？」。
3-2. PMBOK（第8版）的PM人物像
PMBOK是對「專案管理的標準與知識體系」進行相當廣泛的整理。
最近的版本尤其強調：
- 價值傳遞（Value Delivery）
- 根據情況進行的調整（Tailor）
- 涵蓋預測型和敏捷的多種方法的取捨選擇
給人留下強烈的印象。
同時，PMBOK中還有定義PM能力的「PMCD框架」。
這裡PM的專業性被視為「知識（相當於ITSS）」、「執行力（達成成果的能力）」、「個人（領導力和倫理）」三個維度，明確表達出的「實作工作的代行」似乎不在其中。
4. PM所需的「技術能力」是什麼？
從人物像的定義出發，我認為PM所需的判斷能力的 “技術能力” 是以下這些能力。
4-1. 「能夠判斷的技術能力」（我的定義）
- 能理解專家和技術者所說的話（無需翻譯，能理解共同語言）
- 能夠比較取捨（成本、時間、品質、風險、擴展性等）
- 能檢測出紅燈（知道「這樣做是不對的吧？」）
- 能提出問題（知道怎麼樣問誰能減少不確定性、推進專案）
- 能夠整理出決策的前提條件（討論點、選擇、依據、影響範圍）
相對來說，PM並不一定非得具備的（擁有能加分但不是必要的）能力有：
- 特定語言的實作能力（如能用Java高效編寫等）
- 特定雲端平台的深入構建技能（如能單獨處理AWS的某些服務的設計與運作等）
- 特定產品／特定領域的個案操作經驗（如能獨自掌握詳細調整或流程的隱性知識等）
PM應該瞄準的立場是「指揮官」，而不是「專才」。
5. 「能夠判斷的技術能力」的標準：IPA的ITSS Level3
我認為，IPA的ITSS Level3（應用資訊）的範圍是判斷能力的基本水準。
應用資訊的範圍不僅限於技術，還涉及管理與策略，因此能成為PM判斷的 最低限度的共同語言與共識。
以下是我將應用資訊（等級3）轉換為「PM判斷的觀點」的表格。
5-1. PM應了解的知識與理解層次
| 領域 | 大類（應用資訊的想法） | 中類（PM需了解的要點） | PM判斷的實用方式（例） |
|---|---|---|---|
| 技術類 | 基礎理論與計算機系統 | 架構概念、虛擬化與雲端、開源軟體的基本 | 能評估架構提案的可行性、成本/運行負載、擴展性 |
| 技術類 | 技術要素 | 安全性、數據庫、網絡 | 事件時的初步判斷、變更時的風險識別、非功能（性能/可用性）討論的前提整理 |
| 技術類 | 開發技術 | 需求定義至測試的流程、品質、DevOps、CI/CD | 能判斷預測型/敏捷的合適性、維護品質的方法、發布設計（門檻/自動化） |
| 管理類 | 專案管理 | 工序、成本、品質、風險、資源、採購、變更管理 | 能透過數據與理由決策，而非單靠“毅力”（預估、緩衝、關鍵路徑、風險應對） |
| 管理類 | 服務管理與審核 | 運行設計、ITIL理念、審核/內部控制的觀點 | 不讓「只做完就結束」。能基於SLA/運行負擔/維護體系來進行決策 |
| 策略類 | 系統戰略與企劃 | 目的、ROI、需求優先順序、採購觀點 | 能夠整理出“做的理由”和“不做的理由”，來解釋為投資的原因（能進行優先順序與範圍調整） |
| 策略類 | 企業活動與法律 | 合同、個人資料、智財、分包/交易、合規 | 能夠早期消滅合同風險、信息洩漏風險、組織與責任邊界的「易發事故點」 |
※此表格的細節已經總結到不過於繁瑣，若要進一步詳細化，可以與應用資訊的大綱項目關聯。
6. 為什麼萬能PM是危險的？
我認為危險的原因很簡單，因為PM無法專注做PM。
萬能PM容易發生的因素（例）：
- 本身缺乏架構師或技術領導（或角色不明）
- 人手不足，無法迅速配置額外人員
- 預算限制嚴重，容易導致「能做的人必須參與」
- 日程安排以兼任為前提（從一開始就是不可能的）
- 技術問題不斷顯現，導致「滅火」成為常態
- 變更管理薄弱，後期的功能新增以滾雪球的方式增加
- 供應商/外包方的責任分界不明，最終仍由PM承擔
- 文件/標準化不足，導致無法轉交給其他人
- 「管理＝文書工作」被誤解和輕視
當PM向實作方向傾斜時，通常會出現這種情況。
- 利害關係者的協調延誤（決策卡住）
- 進度的可視化延誤（一旦發現已經太晚）
- 無法及早消滅風險（後期會大爆發）
- 品質門檻失效（測試/審查變得薄弱）
- 成員的士氣可能下降（「不如全交給PM就好了？我們是否不再需要？」）
- 最終導致QCD下降，更容易出現專案失控
- 一旦失控，內外部高層的介入會增加，進一步增加報告（惡性循環）
然後，專案將變成死亡行軍……
7. 不過，小規模時兼職也可行（DIY層級）
對於小規模的工作，一人兼任多個角色是很自然的。
就像在住宅中進行DIY，在IT領域也是如此。
例如：
- 团队内部的业务效率化小工具（低代码/脚本）
- 小规模的RPA与自动化（减少单调作业）
- 现有SaaS的设置更改或轻微的对接（影响范围有限）
- PoC（以失败为前提，学习目标，范围小）
- 不要求高质量或严格的时间表
在這個層級，我認為PM是多餘的，可以稱為領導者/負責人就夠了。
DIY層級還可以，但只有當真的是DIY層級的情況下……
8. 希望企業招募負責人注意的事項
有時候求職廣告上寫著「徵求PM」，但內容卻顯示
“PM兼任技術領導兼架構師兼工程師” 的情況。
將所需的所有項目都列出來並不是壞事，只是角色名稱不對而已。
（期待值不匹配的問題是關鍵）
8-1. 不良招聘範例/危險範例（樣本）
| 項目 | 「萬能PM」的招聘範例 |
|---|---|
| 職稱 | 專案經理（兼任PL/技術領導） |
| 工作內容 | - 專案的QCD（品質、成本、交期）管理 <br> - 與客戶、內部CxO及相關部門的協商 <br> - 俯瞰整個系統，制定整合性最佳化的架構 <br> - 使用AWS/Azure構建雲基礎設施 <br> - 雲基礎設施的最佳化及調整 <br> - 緊急時的錯誤修正與源代碼審查 <br> - 對3到5名年輕成員進行技術指導（OJT） |
| 必要技能 | - 持有PMP、專案經理考試（PM）等高級專業資格 <br> - 有數億元以上大型開發的專案管理經驗 <br> - 涉及策略制定、需求定義至維護運營的所有階段經驗 <br> - 有5年以上AWS/Azure/GCP等雲基礎環境構建經驗 <br> - 有5年以上Java/Python/TypeScript等的開發經驗 <br> - 使用Terraform/Ansible等進行IaC的實作經驗 <br> - 有大型數據庫設計和運行經驗 <br> - 有指導年輕成員的經驗 |
| 歡迎技能 | - 商務英語水平（能夠進行英語報告） <br> - UI/UX設計知識 <br> - 組織管理及人員管理經驗 |
| 求才形象 | - 有「自己是最後防線」的強烈自負 <br> - 擁有快速洞察並以自我動手解決的能力 <br> - 對各種難題和困難能迎頭趕上，自我承擔任務 |
如果真的希望「兼任」，在發布招聘廣告前，清楚明確「真正的需求是誰」將更值得信賴，也應該附上適當的職稱。
不過…要同時要求「管理專家」與「實作專家」……實際上能夠在專業水平同時進行兩者的人在市場中幾乎不存在，就算有也需要數千萬的年薪。
更重要的是 「不依賴他人，而是依靠自己的工時硬解決問題」的管理否定。這真的很危險。不僅專案危險，連成員的身心健康也將受到影響。
8-2. 良好的招聘範例（樣本）
| 項目 | 健全的「專案經理」招聘範例 |
|---|---|
| 職稱 | 專案經理（PM） |
| 工作內容 | - 專案的QCD（品質、成本、交期）管理，變更管理 <br> - 與客戶及內部持份者進行期待值調整與共識形成 <br> - 與架構師及主導工程師協作，提前識別技術風險並進行決策 <br> - 制定WBS、進度管理，針對問題進行資源的動態再配置 <br> - 管理專案收益（利潤率）與預算控制 |
| 必要技能 | - 對專案管理方法（PMBOK、敏捷等）的系統性理解及實踐經驗 <br> - 持有PMP、專案經理考試（PM）等高級專業資格 <br> - 具備數億元規模或數十人團隊的大型專案完工經驗 <br> - 能將技術問題翻譯為商業風險和成本並進行解釋 <br> - 能夠理清複雜的利益關係，達成共識的高級引導能力 <br> - 具備「信任技術專家並合理委派工作」的能力 |
| 歡迎技能 | - 有數十億以上或50人以上的團隊的大型專案完整經驗 |
| 求才形象 | - 重視「團隊成果」，而非「個人技術能力」的最大化 <br> - 在不確定的情況下，能夠冷靜收集信息並做出邏輯決策 <br> - 對技術者抱有敬意，並能以客觀的視角評估專案的健全性 |
PM所需的是「創造團隊能解決問題的能力」，而非「自己能動手解決問題的能力」。
信任成員，合理委派工作，整理所需的信息和判斷材料，通過共識形成與消除障礙來向前推進。
專案無法孤軍奮戰，為了在團隊戰中獲勝，PM應選擇團隊合作，而非自己解決。
因此，「能夠動手解決的能力」這樣的表述，作為PM的人物像容易產生不匹配的感覺。
雖然在特定情況下確實是必要的，但如果將其置於首位，則PM原本應負責的管理工作（如QCD、風險、共識形成）將被擱置，最終導致專案健康狀況不佳。
9. 總結
- PM需要技術能力
- 但這不是指「能實施」而是「能判斷」的技術能力
- 作為指標， 掌握IPA等級3（應用資訊）相當的知識非常有效且易於理解
- 當角色變得過於多樣化時，PM將無法專注於PM的工作，專案容易崩壞
- 在某些情況下需要兼任，但最好的方式是調整角色名稱與期待值（至少PM的角色不能單一）
原文出處：https://qiita.com/katohiro_fi/items/b91a11cbcdd0e4967b8c
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
