前言
最近，越來越常有機會在工具開發或提案用的 PoC（概念驗證）開發中，活用 Claude Code、Codex 這類 AI 程式開發工具。
另外，在使用 Google Apps Script（GAS）進行一些小型的業務改善時，也會運用 AI。
實際用過之後，會感覺到的不只是單純撰寫程式的時間縮短了，連對開發這件事的思考方式本身，也正在一點一點改變。
例如，不是從一開始就把細節設計全部定死再開始實作，而是先讓 AI 做出來，實際跑跑看，再修正有問題的地方；等到大致成形後，再整理設計文件或規格。
我覺得這種做法，和充滿反覆試錯的工具開發與 PoC 非常合拍。
另一方面，當開始利用 AI 進行開發之後，讓我思考的就不只是實作方式而已，連開發流程、專案管理，甚至團隊開發的意義，都會讓人想很多。
這次就來談談，透過日常使用 AI 所感受到的事，以及未來開發應該是什麼樣貌。
1. 先做出來，再邊跑邊想
過去的開發，基本流程是先整理需求、定好設計，然後才進入實作。
當然，現在仍然有很多情境適合這種做法。尤其是品質、安全性、以及與既有系統的一致性很重要的開發，事前的檢討不可或缺。
不過，像工具開發或 PoC 這種，不實際跑看看就不知道答案的東西，有時候很難從一開始就把所有事情都決定好。
因此，我會活用 AI 程式開發工具，按照下面這樣的流程推進開發。
- 把想做的東西和目的告訴 AI
- 先讓它實作出可運作的版本
- 實際執行，確認是否符合預期
- 把發現的問題和追加需求告訴它，並進行修正
- 當規格和設計逐漸清晰後，再整理文件
這種流程的好處在於，可以在實際運作的過程中，發現光靠腦中想像不容易注意到的課題。
介面好不好用、流程順不順暢之類的問題，只要有可運作的成品，就能更具體地討論。
另外，因為有 AI 協助實作，將點子化為成品的門檻也降低了。以前可能會因為考量實作成本而放棄的想法，現在更容易先試試看。
這裡要強調的是，這並不是說文件或設計就不需要了。
不是要拿掉設計與文件，而是重新思考：要整理什麼、什麼時候整理、整理到什麼程度。
如果是 PoC，就先做出可運作的版本來驗證假設；如果是要長期維運的系統，就要確實做好必要的設計、測試與安全性確認。
正因為 AI 降低了實作成本，我覺得更容易依照開發目的來選擇適合的進行方式。
2. AI 也會改變開發流程本身嗎
使用 AI 程式開發工具時，有些情況下可以縮短實作所需的時間。
不過，從整個專案來看，除了實作之外，還有很多其他工作。
- 整理需求與對齊利害關係人的認知
- 拆分任務與排定優先順序
- 檢討設計內容與技術選型
- Code Review 與測試
- 掌握進度與管理問題
- 撰寫與更新規格書、會議記錄、設計書等文件
即使實作變快了，如果這些工作仍然花很多時間，專案整體速度可能也不會如預期提升。
反而，實作愈快，決定下一步該做什麼的時間，或是確認 AI 產出的成果物所花的時間，可能會成為瓶頸。
也因此，我認為不只是用 AI 讓個別工作更有效率，更重要的是重新檢視整個開發流程。
例如，從需求整理階段就活用 AI，找出模糊不清的地方，並讓它協助設計與工作拆分；實作完成後，再進行測試與審查，並把結果接到下一步工作上。
如果能不只是依賴個人的做法，而是把這種流程設計成整個專案的機制，就有機會帶來更大的效果。
因此，我也希望進一步了解以 AI 為前提的開發方法，以及專案管理的思考方式，找出適合自己的做法。
3. 從 AI-DLC 等開發方法學習
最近，在思考以 AI 為前提的開發流程時，我特別在意 AWS 提倡的「AI-DLC（AI-Driven Development Life Cycle）」。
AI-DLC 並不是把 AI 當成單純的程式生成工具，而是把它定位成在整個開發生命週期中，從需求具體化、設計、實作到運維都一起協作的存在。
基本上，它把開發生命週期大致分成以下三個階段。
- Inception（啟動／具體化）：將商業意圖具體化為需求與工作單位
- Construction（建置）：推進設計、實作、測試等工作，把軟體做出來
- Operations（營運）：進行部署、監控等發佈後的維運工作
實際工作流程中，這些階段之內還會定義更細的步驟，例如需求分析、架構設計、工作拆分、程式碼生成、建置與測試等。
像 AI-DLC 這樣的方法論有趣的地方在於，它不只是讓 AI 去做事而已，而是把 AI 與人類各自要做什麼、在哪個階段進行確認與判斷，都當成開發流程的一部分來思考。
不過，也不是每個專案都要套用完全一樣的流程。
小型業務改善工具和大型業務系統開發，所需的規劃、審查與文件量都不同。
我想不只限於 AI-DLC，也會一併研究其他開發方法與專案管理的想法，思考依照開發規模與目的，什麼樣的流程比較適合。
重點不是把既有的方法論原封不動地導入，而是實際試著做，找出適合自己的進行方式。
4. 說到底，開發一定要以多人合作為前提嗎
在持續使用 AI 進行開發的過程中，最近還有另一件事讓我很在意。
那就是，未來的開發，是否仍然一如往常，以多人分工合作為前提？
傳統的系統開發，通常是由多位成員分別負責需求定義、設計、實作、測試等工作，並在共享各自成果物的情況下推進。
因此，也建立起了任務管理、進度管理、透過設計書與會議記錄進行資訊共享、Review 等機制。
當然，多人開發有很大的意義。從不同角度思考、彼此審查、共享專業知識、避免過度依賴特定個人，這些都是因為有多人參與才會得到的價值。
不過，當 AI 擴大了一個人能獨立處理的工作範圍之後，原本需要多人分工的事情，是否也會出現更多能由一個人搭配 AI 一起完成的場景呢？
例如，像小型業務改善這種情境，就可以用 GAS 由自己完成實作，甚至一路做到功能確認與修正。即使是工具開發或 PoC，也可能在與 AI 對話的過程中，從需求整理到實作、測試、文件撰寫，一貫地完成。
在這樣的開發中，未必一開始就需要組成多人團隊，並將任務切得很細。
由一個人來推進，有時反而能減少認知對齊與工作交接，更快地進行試錯。
另一方面，如果是由一個人加上 AI 來完成，也會有審查獨立性、品質保證、知識過度集中於個人等課題。也不能只讓 AI 檢查 AI 自己產出的內容，就認為品質已經足夠有保障。
因此，我並不認為所有開發最後都會變成一個人完成。
只是，過去理所當然視為前提的「由多人分工進行開發」這種模式，或許也會根據開發對象與風險而被重新檢視。
由一個人搭配 AI 推進的開發、少數人推進的開發、大型團隊推進的開發，是否都應該有各自適合的流程？
AI 愈普及，開發體制與專案管理的做法，可能就愈需要更彈性地思考。
5. 工程師的角色或許也會改變
如果開發流程與團隊形態都會改變，那麼對工程師的角色要求也一定會跟著變。
當 AI 不只是能協助實作，還能支援調查、設計、測試、文件撰寫等工作時，人類直接動手的範圍也可能隨之改變。
但另一方面，決定該做什麼、提供 AI 適當的資訊與限制條件，以及判斷成果是否合理的重要性，反而可能會更高。
例如，像下面這些角色：
- 明確定義要解決的問題與目標
- 提供 AI 正確的資訊與限制條件
- 判斷設計與實作是否合理
- 確認品質與安全性
- 與利害關係人形成共識，並做出最終決策
未來，除了寫程式的能力之外，整理問題的能力、把工作交給 AI 的能力、評估 AI 產出成果的能力，也可能會變得更加重要。
而當 AI 成為前提之後，團隊的價值也許不只是「由人類分工執行工作」，而是進一步擴展成「建立能結合人類與 AI 並產出成果的機制」。
當然，目前還沒有哪一種開發體制是已經有標準答案的。
正因如此，我想在實際使用 AI 的過程中，持續思考這些變化。
6. 接下來想做的事
接下來，我想一邊在日常的工具開發、PoC、以及利用 GAS 進行業務改善時活用 AI，一邊不只提升個別工作的效率，也重新檢視開發方式本身。
具體來說，我想做以下幾件事。
- 研究 AI-DLC 以及其他開發方法，加深對以 AI 為前提的開發流程的理解
- 依照開發規模與目的，思考什麼樣的專案管理方式比較合適
- 整理一人開發與多人開發的差異，以及各自所需要的品質管理方法
- 在實際開發中嘗試，確認效果與課題，找出適合自己的進行方式
我認為，比起一開始就做出完整成熟的流程，不如先小規模試行，再持續改善更重要。
隨著 AI 持續進化，開發方式也一定會跟著變化。不只是追著變化跑，我也想把它以適合自己業務與專案的方式導入。
結語
透過使用 Claude Code 與 Codex 進行開發，我感受到 AI 的價值並不只侷限於程式生成。
先做出來跑跑看。透過反覆試錯把規格具體化。整理必要資訊，接到下一個步驟。
如果不只是把這些做法停留在個人技巧層面，而是把它當成開發流程與專案運作的機制來思考，AI 的應用範圍應該還能進一步擴大。
而且，當 AI 開始承擔開發中的各種工程時，過去的團隊樣貌，以及工程師的角色，也可能隨之改變。
不是單純維持原本的開發方法，也不是把所有事情都交給 AI，而是希望透過實際嘗試，找出適合自己的開發形式。
從使用 AI 寫程式，轉向思考以 AI 為前提的開發機制。
這是我今後也想持續透過實作思考的主題。
……雖然前面寫得這麼像那回事，不過這篇文章本身也是請 AI 幫忙撰寫並潤飾過的（笑）。
總之，先從自己實際做做看開始吧。
原文出處：https://qiita.com/kizuku_tabata/items/6d5b58ad0cb832d2a4c5
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
