付費限定方格精選
91APP的軟體開發之道—從20人到200人的組織發展旅程
閱讀時間約 17 分鐘
91APP運作200人以上的SaaS產品開發團隊，透過導入Agile的開發方法，用Scrum的方式有節奏推進交付，並大規模的不停地做組織重整，用91APP Way的三個層次來運作產品開發組織。
91APP現在有一個200多人多大產品單位，包含PO、RD、UX/UI、QA等等都在這個單位，也是整個公司佔了一半以上人數的單位，負責91APP的SaaS產品的開發工作。
聽說我們跑的是Agile（敏捷式開發），在台灣，很少聽到有一家軟體產品公司，如此大規模的運作Agile。很多人問我們，這麼大規模的組織運作Agile，要怎麼跑？
這篇文章主要就是嘗試說明這個問題，但其實真實的關鍵已經不是agile，是軟體開發組織運作方法。經過多年的演變，Agile也已經不是原來以為的Agile了，如果硬要說我們現在的開發方法的話，我會說是91APP Way（91APP的軟體開發之道）。
這個故事大概是截至目前為止，最長的一篇文章，足足有將近6,000字。但本來組織發展，就是一個公司能否長期成長的關鍵，千言萬語也無法道盡其中奧妙，所以就用一篇故事的形式，簡化了一些過程，提煉其中的關鍵轉折，串連起來變成起承轉合，或者你也可以把它當作一篇寓言故事，希望能給大家一些啟示。
第零階段：最美好的時光
跟大多數創業公司一樣，我們一開始也只不到20個人，而這個階段，是旅程中最美好的時光。
記得當時ㄧ開始的這群人，除了同事，更像是朋友，中午會一起吃飯，下班還會約唱歌，假日還會約出遊。然後邊玩邊討論工作，邊工作邊玩。
剛開始的這個階段，大家其實會非常有默契。工作目標決定之後，會一起想辦法達成，有麻煩就互相幫忙，有挑戰一起打怪，有經驗一起練功，有問題就快速溝通，有想法就快速討論。
或者更可以說像是革命夥伴。革命是很讓人亢奮的。創業初期雖然辛苦，但創業就是一起追求一個夢想，一起做夢，看起來未來無限可能，所以會莫名的型成一種很High的氛圍，感覺我們什麼都做得到。
通常這個階段，也沒什麼明確的組織，也沒有明確的分工，反正就是一起想辦法，貢獻自己可以做的事，看做什麼可以讓公司往夢想彼岸推進一步。
其實這個階段通常也不喜歡什麼組織分工、設立流程制度，都很點綴，想辦法讓公司可以活下去、找到成長的動能才是最重要的。
第零階段的創業團隊，是最美好的階段，如果你還在這個階段，請好好珍惜。
第一階段：瀑布來了
可是當團隊成長到50人以上，管理的問題就開始來了。
通常一定是公司做對了什麼，產品有了第一批的客戶，營收有了進展，團隊也才因此開始成長。
這時候會開始有新成員加入，有了「新人」，原來的舊人就變「資深」了，資深就厲害了，就會開始對新加入的菜鳥有很多的指點。於是，某一種奇妙的「階層感」就開始發生了。
順理成章，「資深」就變成了「主管」，而有主管就會有部門、有部門就開始分工，有分工就開始要溝通，有溝通就開始分你我。
就我們來說，就開始分成有產品部門、設計部門、工程部門、測試部門等等。然後每一個產品專案，都會需要跨部門討論，落下各單位的工作項目，PM就會畫出「甘特圖」，來追蹤整個專案的進度。
產品規劃完交給設計部門、設計畫完交給工程部門，一棒接一棒，很自然的就變成了知名的「瀑布式開發」的跑法，一個功能專案從開始規劃，到開發、測試後上線，通常至少要跑到3個月以上，然後也常常還超出預期。
第二階段：上帝之手
不過隨著團隊規模再跨大，也不可能是一個團隊，一起跑一個專案，一個瀑布跑到底，老闆是不會接受的。最好是整個產品團隊，能同時跑幾個專案，越多越好。
意思就是說，如果我們有70個人，而同一個時間，通常就會有6~8個專案一起跑，所以就得依據專案需求，想辦法分配人手，把人分別丟進不同的專案裡面。
所以依據不同的專案的特性，指派一個PM、UX、再指派幾個RD、QA，組成一個臨時的專案團隊，然後專案結束就解散，大家各自又被「分配」到其他專案去努力了
而分配大家工作的管理階層，就像是決定大家命運的「上帝之手」。
這種跑法，非常講求「上帝之手」的資源調撥的功力。調撥資源的人要知道每個人的長項、每一個人當下的loading等等的，然後把對的人塞進專案裡面。一沒弄對，有的人就會過載，專案超多，命運坎坷，而有的人就像生在好人家， 涼的很，平常也沒什麼事。
「上帝之手」安排每個人的故事與角色，設法讓整個世界可以正常的運作。
通常這種跑法一開始問題也不大，而調資源的主管層越強，這個跑法可以運作的很好，至少好一陣子。
然後問題就來了。
通常這種跑法所形成的「專案團隊」，「團隊」感是很弱的，甚至也根本不是一個團隊。
因為終歸是一個瀑布型的跑法，每一個專案的時程都拉得很長。所以像是專案團隊內的PM，通常專案啟動後，工程師還要寫一段時間，所以他已經被安排跑去寫另一個專案的規格了。
大家彼此都是生命中的過客，因為專案而短暫交集，專案結束就分開了，很難有什麼「團隊默契」。
第三階段：形成專業領域團隊
而且，隨著公司的發展，產品的複雜度也在變高，於是不同產品線功能之間的 「專業領域知識」，也開始越來越深。因此接下一個專案的人，從理解專案的「專業領域知識」 到真正可以上工的時間，也越來越長。
例如本來做金流的人，好不容易把金流搞懂，下一個專案被安排去做會員機制。所以常常一個專案成員，好不容易把一個產品線的專業領域弄熟了，團隊默契也熱起來了。但專案一結束，團隊就解散，各自去接下一個案子，而且可能還是自己完全陌生的案子。
好像是你好不容易找到打棒球的感覺，就突然調你去打打籃球了。
隨著團隊成長到100人，這種跑法幾乎快要跑不去。大家工作都很不開心。
於是我們開始思考，是不是應該把團隊成員固定下來，讓做金流的這20個人，長期形成一個固定的「專業團隊」（而不是「專案」團隊」），就一直做金流相關的題目。做會員的那20個人也一樣。
也就是依據專業領域，畫分出一個一個的「專業領域團隊」，然後整個團隊固定成員，就一起在這個專業領域，長期發展。
也就是會打棒球的就一直打棒球，會打籃球的就打籃球。固定團隊成員在固定的專案領域裡面長期耕耘，理論上會越做越熟練，團隊默契越好，工作效率就會越好，生產力應該會更提升。
但，我們的軟體工程方法，一直以來還是瀑布式開發。不管怎麼切分人員成團隊，每個團隊裡面，還是瀑布式開發。整體專案從PM把規格寫完，到實際RD開發完成上線，產出工期還是很長，而且常常PM一直在寫案子，但工程師怎麼樣都來不及寫完。
於是，我們開始尋找有沒有更好的軟體工程方法，就在這個時候，我們開始嘗試開始導入「敏捷式開發」（Agile）。
第四階段：敏捷式開發
我們選擇採用的是Agile的思維下的Scrum的方法。
我們依照Scrum Guideline，讓每一個「專業領域團隊」，都設定成為一個Agile Team，也剛好原來的「專業領域團隊」，就是跨功能組織的成員所組成，長期一起合作的固定團隊，內有各種角色：PO、UX、RD、QA的等等，可以End to End的生產並交付產品功能。
我們再依據Scrum Guideline，嘗試設定3週為一個「Sprint」，每一個Sprint，跑Agile的四大會議，從每日的站立會議(Daily Stand)，到Planning meeting、Review meeting、Retrospective meeting。透過每一個 Sprint一個release，不停循環sprint，來推進產品功能交付。
我們再依據Scrum Guideline，嘗試導入新的Scrum Master的角色，但因為一開始摸索Scrum Master在團隊內要怎麼做，實在花了很多的時間（吵了很多的架）。於是我們也從業界，找進了敏捷教練，跟專業的Scrum Master。
但，Scrum Guideline真的寫得很精巧，也就是說，他並不是像一本使用手冊一樣可以一步一步照著做，沒有什麼必然的作法與流程。所以常常是一個Guideline，各自解讀。
導入Scrum之後，我們一天到晚遇到團隊成員之間在爭執，PO應該要做什麼、Scurm Master要做什麼，Planning Meeting要怎麼開才對、Product Backlog要怎麼列、甚至一個Sprint是三週、兩週、還是要改一週？
我們花了非常非常多的時間，在解讀guideline，在辯論「什麼才是正統的Scrum」，甚至還互相批評「你這樣的作法不是Agile」，「你這個會議不是Scrum的開法」。
結果，好一段時間，我們太過於計較跑步的姿勢，而忘記了跑步的速度，甚至就算跑步姿勢一百了，一抬頭才發現跑錯了方向。
我們開始思考，為什麼當初要導入敏捷式開發？
第五階段：團隊的自主管理
我們後來發現，身為主管層的我們，還是用傳統管理的腦袋，來嘗試「管理」Agile團隊的Scrum跑法。即使團隊已經導入的敏捷開發方法，但主管層仍然不是很敏捷。事事都想干涉，一直嘗試想安排每一件事（上帝之手一直收不回來），而忽視了「團隊自主」是敏捷裡面很重要的精神。
於是我們開始嘗試，讓「團隊自主管理」，團隊可以依據自己的狀態，可以摸索出自己Scurm的跑法，無論3周一個sprint、2周一個sprint，或者站立會議的開法、Planning Meeting的開法。每個團隊可以跑出了自己的樣子。而不是讓管理層事事要求所有團隊，有一套「標準」的Scrum跑法。
我們開始不去計較團隊跑步的姿勢，不管姿勢如何，有跑步的速度就是好團隊。
我們也讓團隊有自主的權利，團隊可以安排自己的年度計畫（在公司的年度目標的前提下），可以安排每個Sprint的工作內容，團隊成員也會在Planning meeting，一起討論每個sprint的工作項目，設法一起努力、互相幫忙，讓團隊可以一起達成團隊目標。
團隊有自己自主的權利，相對就有責任。團隊要為自己的決定負責，團隊有團隊的責任感，對自己的責任範圍的產品的成敗負責。
這樣子權責相符的跑法，讓其中幾個團隊，慢慢跑出了很高的生產力，也跑出了速度。就像是回到了當時創業的「第零階段」一樣，團隊成員互相Cover，一起工作、一起為團隊而努力。團隊成員對團隊的認同感強，向心力也強，團隊內會形成很亢奮的工作氛圍。而如果我們有好幾個這樣子的團隊，那就真的太美妙了。
然後，就出現了新的問題。事情終歸沒那麼簡單。
第六階段：團隊的團隊 - One Team
讓團隊自主管理之後，逐漸形成了超強向心力的專業領域團隊，對團隊而言，向心力很好，但對團隊「之間」而言，就形成了很強的「silo」-穀倉效應，也就是「團隊 v.s. 團隊」之間就出現問題了。
- 因為團隊還是在同一個產品平台上工作，於是團隊之間就需要「協作」；
- 團隊開發的功能之間也有很強的相依性，所以團隊之間就需要「溝通」；
- 因為我們也以團隊的表現做為績效的參考，於是團隊之間也隱含了「競爭」。
團隊自主的結果，也讓某些團隊開始跑錯了方向，各團隊各唱各的調，往不同的方向加速奔跑，結果整個大產品，差一點就被五馬分屍了。
於是我們嘗試在團隊之上 ，成立「團隊的團隊」，我們自己把他叫做「One Team」（缺什麼補什麼的概念）。
所謂「團隊的團隊」，意思就是所有One Team的成員，都是原各團隊裡面的主管階層，做為代表，聚集在一起，在所有團隊之上，形成一個團隊的上層團隊。因為當團隊跑出了了跑步的速度，團隊的團隊就負責拉好跑步的方向。
One Team形成之後，我們做了幾個重要的調整：
- 對齊每一個團隊的sprint週期。所有的團隊一律改成兩個禮拜一個Sprint，並且統一Release的時間。
- 拉齊所有團隊的方向。所有團隊的product backlog都會集中到One Team，One Team會有一份大產品的One Product backlog，做團隊開發相依性的「協調」與「溝通」，做完backlog優先順序的調整，再讓One Team的成員回到自己的原團隊去做討論。
對齊Sprint週期，為了所有的團隊的「節奏」一致；拉齊團隊方向，為了所有團隊是演奏的「樂譜」是同一首歌。整個大產品團隊就像一個交響樂團一樣，雖然各團隊因為自己負責的不同，樂譜有所不同，但大家終歸是演出同一首歌，「節奏」一定要一致，「樂譜」合起來要是同一首曲。
而身為主管層的我們，也終於體會到了Agile的奧妙。透過Agile的落實，團隊會形成自主管理的完整有機體，會自己管理，自我負責，每一天有速度的推進工作，交付產品。而主管層就可以有足夠的心思，討論產品策略、拉齊團隊的腳步，整合團隊的產生。
這個時候，大概有8個左右的Agile Team，我們終於能個感覺到，8個團隊一起往同一個大產品目標跑，而且跑出了推進的節奏感。但，總覺得哪裡還是卡卡的～～。
第七階段：組織重整
一直到了這個階段，大概也走過了五年以上。所謂的「團隊」，已經從「專案團隊」變成「專業領域團隊」，開發方法也從「瀑布」，變成了「敏捷」。雖然團隊的跑法已經演變了好幾代，但回頭過來，其實整個大產品的組織架構，卻仍停留在第一階段，依然還是功能性組織。
也就是說，每一個同仁，等於都有兩個老闆，也會有兩個目標。每個同仁在團隊裡面，要為團隊的目標努力；但每個同仁同時也隸屬於某個部，該部的主管也會要求他另外的目標。
而當兩個工作目標內容完全不同時，同仁就等於要用加倍的時間來完成兩個工作。而當兩個老闆的目標衝突的時候，同仁就常在中間兩邊不是人。
這都是「矩陣式組織」(Matrix）標準常遇到的管理挑戰與議題。
但其實跑到這個階段，團隊已經成為主要的生產單位，本來的功能組織的「功能」也變成不事生產。於是我們開始思考，是不是要整個大規模的做組織重整。
我們決定把整個大產品組織，全部打掉重練。我們把原有的功能組織打散，重新把所有的專業領域團隊部門化。也就是負責生產的團隊，直接轉變成為一個「產品線部門」，從虛擬團隊組織變成一個真正有管理實權的部門。
我們等於直接把一個一個的agile team部門化了。
這些團隊(agile team)，原本都是跨個功能組織所組成，所組成的團隊（虛擬團隊）。我們等於把這些團隊，直接轉變一個部門組織，形成一個產品線部門（實體部門）。
而這個部門的主管，則有的是原有的PO升任、也可能是原有的RD的技術主管。而部門的主管，自然就是One Team的成員之一，同時One Team就變成大產品的重要的決策單位，管理整個大產品組織。
專業領域團隊變成產品線部門後，原有團隊內的PO、UX、RD、QA等同仁，在這些新的產品線部門裡面，變成分別的功能性組織。再反過來在產品線部門裡面，跨功能組出2~3個「團隊」(agile team)，每個團隊一樣跨職能（PO、UX、RD、QA）組成，用Scrum的方法，一個一個sprint推進產品功能交付。
我們等於把原有的功能性組織，打散進去三大產品線部門。然後把整個大產品組織的Matrix，也落進去這三大產品線部門裡面。看起來，一樣還是有功能性組織，一樣還是有Matrix的存在，但整個大產品的跑法的層次就出來了。
- One Team - 負責產品的方向，形成大產品的政策。
- 產品線部門 - 負責實際「團隊的管理」，並落實One Team的策略。
- 「團隊」- 主力的生產團隊，有節奏的推進產品功能。
這個時候，我們大約有12支左右的「團隊」，每個團隊大約有7到15個左右的成員。這些團隊，也就是實際跑Agile的Agile Team。這些團隊是依然是主力的生產部隊。而產品線部門有三個大部，每一個部分別管理 3~5個「團隊」，這些產品線部門是大產品裡面，實際負責「組織運作的管理單位」。而One Team就變成大產品主要的策略單位，負責產品的長期發展，訂立大產品的政策。
而無論是產品線部門，還是One Team，最終的目的都是為了讓所有的「團隊」，可以放心的全力衝刺開發工作，用每一個一個的Sprint，有節奏的穩定推進產品。而其他的議題，就由另外兩個層次的組織架構來解決。產品線部門解決管理與資源問題，one team解決策略與政策問題。
很多人問我們，我們怎麼跑大規模的Scrum，怎麼讓整個200人的產品團隊，一起跑Agile。而這幾個「層次」的開展與佈置，就是我們到目前為止體悟出來的方法，也許我們可以把它叫做「91APP Way」（91APP的軟體開發之道）。
91APP的軟體開發之道仍然在持續往前，從20人到200人之後，我們正在努力的從200人到2,000人，並形成跨國性組織運作。也許再過五年後，我們可以再接續講述這個故事的下一章。
原文刊登於：零售的科學 (happylee.blog)
🙏 有興趣請追蹤專題
👏 隨手拍手做功德(合十)
👍 FACEBOOK Me：追蹤我
⬆️ 如果你喜歡這些文章，歡迎分享給更多朋友。
以行動支持創作者！付費即可解鎖
本篇內容共 7161 字、0
則留言，僅發佈於零售的科學你目前無法檢視以下內容，可能因為尚未登入，或沒有該房間的查看權限。
你的見面禮 Premium 閱讀權限
只剩下0 小時 0 分
596會員
93內容數
Hello，大家好，我是 91APP 產品長 李昆謀( Happy Lee )， 因為這十年來，一直在幫零售業做數位轉型，會在這邊分享 OMO、新零售、大數據、電子商務 等等相關的內容，也算是把這些年來的經驗，自己做個整理。歡迎大家追蹤我的專題。
留言0
查看全部
你可能也想看
Google News 追蹤
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
美國總統大選只剩下三天， 我們觀察一整週民調與金融市場的變化（包含賭局）， 到本週五下午3:00前為止， 誰是美國總統幾乎大概可以猜到60-70%的機率， 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Apple 在 WWDC 2024 蘋果開發者大會上所推出了「Apple Intelligence」 AI 智慧系統。以下介紹 Apple Intelligence 的完整資訊。
Apple Vision Pro：VR生活的全新開端
Apple Vision Pro ──蘋果推出的全新 VR 頭戴式裝置──不僅以其前沿技術重新定義了虛擬與擴增現實體驗，更以多元化應用打開了使用者探索新世界的大門。從個人電影院、專業工作到冥想空間，提供了享受生活的嶄新方式。
iPhone 和 Mac 免費配備 ChatGPT：
• 直接從 Siri 存取 ChatGPT 並提出問題
• 詢問有關您的文件的問題
• 使用 ChatGPT 分享照片並取得建議
• 使用 ChatGPT 在文件中建立圖像和文字
尋找相片庫中包含特定人物的照片
你丟過幾張悠遊卡？手錶每天戴不怕丟，包包亂找悠遊卡好麻煩！
本文推薦Apple Watch悠遊錶帶，免運＋現折540元，歡迎挑選所需顏色，讓你不再手忙腳亂，隨手一嗶超方便，享折扣等特惠。6/18截止。
她是一個很特別的人。
談及結婚議題，是她人生目前最大難題，她愛對方可不想結婚但被嚴重逼婚，對有的人來說婚姻是一張紙、一個身分，有與沒有都不這麼重要，愛才是重點；對有的人來說結婚才有未來藍圖，才能以連結的身分「在一起」。
很多問題沒有對錯，感情更是，對我來說只是看事情的角度不一樣，即使換位思考也不
超人氣教養專家，蘿拉 馬可罕博士說：沒有人可以無時無刻保持完全平和，不然我們早就開悟了。每一次你選擇用更多的同理心對待自己與孩子，就是往內在的平靜與喜樂更進一步。
博士有一句說的很好，我不得不筆記起來，她說：你的孩子的確就像是個孩子一樣，還在學習的過程中，他的優先順序與你不同，也沒辦法控管自己的情緒
昨晚看到這條新聞的標題，一時之間以為女性是被91歲的老爺車給撞了，撞成了<重体>。
本來想說日語<重体>大概是重傷吧，結果一查竟然是病篤命危，這是怎麼撞的，日語"橫斷步道"是我們說的斑馬線耶。
雨林另一處，凡妮莎獨自一人正搖搖晃晃的低空飛行前進，原本就蒼白的面容因為失血更加慘淡，而且中箭處隱隱有一些墨綠青色浮現，毒素正在她體內蔓延。
最後一位灰精靈藏身暗處，不是她不想扶持對方趕路，而是體型不對等之下難以協助，反而會拖累彼此，倒不如專心執行警戒任務還比較有幫助。
泥地、巨樹、
在MOA美術館中，館藏約有3500件古美術品，其中包含了64件重要美術品、66件重要文化財以及3件國寶。當然，這麼多的館藏美術品不可能一口氣全部展出，每隔一段時間美術館就會推出不同的策展主題，除了自己的館藏之外，有時也會向其他美術館的商借相關展品，推出有系統地特展，所以每次來這裡都會有不同的驚喜。
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
美國總統大選只剩下三天， 我們觀察一整週民調與金融市場的變化（包含賭局）， 到本週五下午3:00前為止， 誰是美國總統幾乎大概可以猜到60-70%的機率， 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Apple 在 WWDC 2024 蘋果開發者大會上所推出了「Apple Intelligence」 AI 智慧系統。以下介紹 Apple Intelligence 的完整資訊。
Apple Vision Pro：VR生活的全新開端
Apple Vision Pro ──蘋果推出的全新 VR 頭戴式裝置──不僅以其前沿技術重新定義了虛擬與擴增現實體驗，更以多元化應用打開了使用者探索新世界的大門。從個人電影院、專業工作到冥想空間，提供了享受生活的嶄新方式。
iPhone 和 Mac 免費配備 ChatGPT：
• 直接從 Siri 存取 ChatGPT 並提出問題
• 詢問有關您的文件的問題
• 使用 ChatGPT 分享照片並取得建議
• 使用 ChatGPT 在文件中建立圖像和文字
尋找相片庫中包含特定人物的照片
你丟過幾張悠遊卡？手錶每天戴不怕丟，包包亂找悠遊卡好麻煩！
本文推薦Apple Watch悠遊錶帶，免運＋現折540元，歡迎挑選所需顏色，讓你不再手忙腳亂，隨手一嗶超方便，享折扣等特惠。6/18截止。
她是一個很特別的人。
談及結婚議題，是她人生目前最大難題，她愛對方可不想結婚但被嚴重逼婚，對有的人來說婚姻是一張紙、一個身分，有與沒有都不這麼重要，愛才是重點；對有的人來說結婚才有未來藍圖，才能以連結的身分「在一起」。
很多問題沒有對錯，感情更是，對我來說只是看事情的角度不一樣，即使換位思考也不
超人氣教養專家，蘿拉 馬可罕博士說：沒有人可以無時無刻保持完全平和，不然我們早就開悟了。每一次你選擇用更多的同理心對待自己與孩子，就是往內在的平靜與喜樂更進一步。
博士有一句說的很好，我不得不筆記起來，她說：你的孩子的確就像是個孩子一樣，還在學習的過程中，他的優先順序與你不同，也沒辦法控管自己的情緒
昨晚看到這條新聞的標題，一時之間以為女性是被91歲的老爺車給撞了，撞成了<重体>。
本來想說日語<重体>大概是重傷吧，結果一查竟然是病篤命危，這是怎麼撞的，日語"橫斷步道"是我們說的斑馬線耶。
雨林另一處，凡妮莎獨自一人正搖搖晃晃的低空飛行前進，原本就蒼白的面容因為失血更加慘淡，而且中箭處隱隱有一些墨綠青色浮現，毒素正在她體內蔓延。
最後一位灰精靈藏身暗處，不是她不想扶持對方趕路，而是體型不對等之下難以協助，反而會拖累彼此，倒不如專心執行警戒任務還比較有幫助。
泥地、巨樹、
在MOA美術館中，館藏約有3500件古美術品，其中包含了64件重要美術品、66件重要文化財以及3件國寶。當然，這麼多的館藏美術品不可能一口氣全部展出，每隔一段時間美術館就會推出不同的策展主題，除了自己的館藏之外，有時也會向其他美術館的商借相關展品，推出有系統地特展，所以每次來這裡都會有不同的驚喜。