敏捷開發並不適合SI（系統整合商）業者的委外專案。這或許對某些人來說並不是什麼新鮮事，但筆者認為，這樣的觀點仍需更明確地闡述。因此，本文將整理出「敏捷開發為什麼不適合日本SI業者的委外開發」的原因。
在開始之前，先說明筆者的背景：我主要從事SI業者內的AI相關專案，範疇涵蓋從數據分析到模型構建的PoC（概念驗證），再到AI模型運營所需的系統開發。由於AI專案的特性，難以採用傳統的瀑布式開發，因此我們經常進行類似敏捷的開發流程。
為什麼難以採用瀑布式開發？原因在於，AI專案中無法在簽訂合約時就明確定義系統的需求。AI專案的需求定義需要對AI技術、數據科學以及業務知識有深刻理解，而AI本身的性能與特性通常在PoC之前是未知的。因此，專案無法按照「需求定義 → 設計 → 實作 → 測試」的傳統流程推進，而是需要分階段進行小型專案，逐步累積資訊，並根據結果隨時調整或結束專案。
因此，AI專案通常傾向於使用類似敏捷或Scrum的方式，將專案劃分為短期的衝刺（Sprint），並通過需求清單（Backlog）進行管理。然而，在SI業者承接的委外型專案中，敏捷開發的實施往往會遇到許多障礙。以下將具體說明這些挑戰。
1. 團隊溝通成本過高（特別是會議）
在SI業者的專案中實施敏捷開發，其中一個最大的挑戰就是溝通成本過高，甚至難以進行有效溝通。敏捷開發需要即時且頻繁的同步，而Scrum的實施更是加劇了這項需求。
Scrum中，開發團隊的Scrum Master（SM，敏捷教練）和客戶端的Product Owner（PO，產品負責人）需要頻繁進行協作。然而，實務中若將PO角色交給SI業者的專案經理（PM）或業務人員，通常效果不佳。這是因為SM與PO的會議中若無法當場做出決策，還需要額外時間與客戶確認，導致時間延誤，甚至最終因雙方意見不合而推翻原決策，專案進展因此受阻。
此外，Scrum本身要求進行多種會議，例如每日站立會議（Daily Scrum）、衝刺規劃會議（Sprint Planning）、衝刺檢視會議（Sprint Review）等，並且相關人員必須全體參與。這些會議的實施成本（會議時間 × 參與人數）自然居高不下。
以筆者經驗為例，若以兩週為單位進行衝刺，每週至少需召開一次與客戶的進度報告會，並與內部團隊進行多次會議。為了準備報告會，通常需要花費一天以上的時間製作資料，會後還需花半天整理會議記錄。這樣的高頻率會議模式對所有參與者來說都是一種負擔，也可能導致團隊成員對專案的投入度下降。
在企業間的委外專案中，會議的決策具有法律約束力，因此需要詳細的準備和記錄。然而，這種溝通模式不僅增加了精神壓力，還可能使專案進展陷入僵局。
2. 團隊目標意識難以統一
敏捷開發（尤其是Scrum）強調統一的團隊目標，但在SI業者的委外專案中，這幾乎是不可能實現的。筆者曾在內部專案中學習並實踐Scrum，但當應用到涉及客戶的專案時，發現其理念難以落地。
首先，客戶方的專案負責人可能對專案並無強烈的責任感。例如，這些專案可能是由前任主管留下的，或者只是為滿足某些業務需求而發包的系統。在這種情況下，很難要求客戶投入足夠的精力或關注專案細節。
開發團隊內的目標意識也難以統一。對於大多數成員來說，參與專案只是工作的一部分，真正重要的是生活中的其他事物。更何況，SI業者的專案通常涉及多家企業的成員，包括二次、三次外包的情況。跨企業的協作進一步增加了目標統一的難度。
在這樣的情況下，要求所有參與者對專案高度投入，甚至達到Scrum的高標準，顯然是不切實際的。
3. 任務容易因人員依賴而中斷
敏捷開發鼓勵快速迭代，並減少過度文檔化。然而，在SI業者的委外專案中，這種方式容易導致關鍵資訊僅存在於特定人員的腦海中。一旦某位成員離開專案，進度可能立即停滯。
特別是在AI專案中，數據分析結果、數據準備的指導方針、模型構建過程等關鍵資訊，若未適當文檔化，將難以傳遞給其他人。
SI業者的專案人力配置通常是流動性的。成員可能被調派到其他專案，或因合約到期由其他人接替。協作的外包公司和派遣工程師也經常更換。這種高度流動的環境使得專案極易因人員變動而陷入停滯。
因此，委外專案必須確保任何人都能在任何時候接手並完成任務，這就需要詳細的文檔支持。然而，這樣的做法又與敏捷開發的理念相悖，導致專案進退兩難。
4. 難以明確定義專案成果
敏捷開發中，專案成果往往缺乏明確的定義，這對於SI業者的委外專案而言是致命的問題。特別是在AI專案的早期階段，許多事情都是未知的。例如，AI模型的性能、適用範圍及後續的運營系統需求等。
這種模糊性可能導致專案變得方向不明，甚至使人無法理解其實際價值。例如，專案成果可能僅僅是一份報告，或者是一個未完成的PoC模型。這樣的成果往往難以滿足委外專案的需求。
一種解決方法是改用準委任（Time & Material）合約，將每次衝刺的進展視為專案成果。然而，這也要求客戶方頻繁進行決策，並持續參與專案管理，最終可能加重負擔，並導致專案方向進一步模糊。
結語
總結而言，AI專案既不適合瀑布式開發，也不完全適合敏捷開發。當前的最佳實踐或許是採用混合開發模式，但筆者認為，AI專案成功率低的原因不僅是技術問題，更可能是專案推進方式本身存在問題。我們需要探索完全不同的進程管理方式。
未來若有新的見解或方法，筆者將繼續分享。
コメント