我們如何為登山申請打造一站式服務系統

緣起

自 2019 年 6 月份起，在蘇貞昌院長帶領下，行政院啟動「開放山林」政策，營建署也於 6 月 30 日推出了「臺灣登山申請整合資訊網」作為山林政策的開端，旨在於讓民眾的入山申請更便利。

整合資訊網上線後，許多建議湧入網站。作為近年來少有的跨部會資訊整合網站，整合資訊網算是踏出了第一步。而民眾的意見，則讓各部會同仁明白改善的可能方向。

因此，內政部開放政府聯絡人（以下簡稱「PO」）王俊凱將這個案子於 8 月份「開放政府聯絡人工作推動會議」（簡稱「PO 月會」）中提出，與 PDIS 協作改造登山線上申請流程的使用者體驗。在蘇院長的授權下，PDIS 從系統整合的技術面切入，協助跨部會系統間介接產生的疑難雜症。

經過一個多月的規劃和討論，我們在 9 月 6 日舉辦協作會議，以工作坊的形式和山友一同協力設計規劃新的線上申請流程。最終的成果，便是現在的臺灣登山申請整合資訊網。

以使用者為本，找出痛點

現有的申請流程下，民眾需多費心辨別自己所行走的路線涉及的管理單位，並分別提出申請。對於想要親近山林，但相對沒有經驗的朋友們來說，實在有些困擾。

政府數位服務指引(註 1)的第一條「了解使用者需求」。

定義誰是服務的使用者(含數位弱勢)，透過持續進行使用者研究，設計符合使用者需要的服務。 為設計符合使用者真正需要的(數位)服務，讓使用者樂於使用，須界定使用者(包含多方利害關係人)，確認服務是融入使用者的生活、且為需要而非只是使用者或提供者想要的服務，考慮到數位弱勢需要協助的管道，以及持續與使用者共同探索需求精進服務。

我們在這一案透過多元的方式來收集民眾的意見，從使用者的視角出發，尋找痛點。

大專生互動服務設計師一同參與

自 2017 年起， PDIS 一直與教育部青年發展署的「大專生公部門見習計畫」合作，執行「青年學生體檢政府網站計畫（簡稱 RAY）」。邀請青年透過改善政府數位服務的方式，參與公共事務。 2019 年起，有別與前兩年大規模地針對政府網站的相容性體檢，我們改以邀請人機互動與服務設計專業的大專生們，針對政府網站數位服務流程進行深度的設計改造。

其中一組的 RAY 見習生，便是選擇了登山線上申請流程的改進作為見習內容。他們透過簡單的訪談與調查後，描繪出山友們的 Persona，定義出系統目標使用者的樣態，並設定關鍵任務，尋找符合樣態的受試者，針對現有系統進行易用性測試同時深度訪談。

接著，同學們將訪談中收集到的意見進行歸納整理，納入原型設計中。使用低保真原型(Wireframe)邀請受訪者針對新設計的介面進行測試，並透過運用服務流程設計方法評估其效益。透過多次迭代後，最終 RAY 計畫的同學們產出了系統介面的原型(Mockup)，作為後續系統開發的參考。

圖 2，RAY 計畫產出的系統原型。圖為首頁，點這裡有可以線上互動的 Demo 網頁

跨部會整合資訊系統的挑戰

打造一站式的登山申請服務時，馬上面對到的挑戰便是依照現行法規下，進入山林可能涉及到許多業務單位管轄而帶來的許多子議題。

最顯而易見的挑戰是，在近乎從無到有的情況下，將各申請流程整合後，打造一套新的流程介面。所幸，這部分我們已有 RAY 的見習同學做的 Mockup ，以此為基礎，再納入協作會議收集到的意見後進行微調，便有相當不錯的介面設計稿。

有產品系統分析經驗的朋友一定知道，流程介面整併優化，只是對於多系統整合上的第一關而已。最困難的是整併那些藏在操作介面後，但使用者卻不太容易發掘的系統營運邏輯。

因應環境保護與永續發展，臺灣的一些山林已被劃設為國家公園或自然保護保留區，民眾在進入前須向國家公園處或林務局進行申請，以利於環境承載量管制進而永續發展。

同時，過去臺灣的山地地區被列為管制區域，依據國安法第5條，進入山地管制區前應向機關進行申請。雖然目前管制區域逐步進行解禁，但民眾在進入尚未解禁區域前仍須向警政署（現行的山林管制區域執行機關），進行申請取得入山許可證。

在每個地點都有可能超過一個以上且不完全相同的行政主管部門時，便導致整合的複雜度大大增加。

圖 4，PDIS 在專案期間自行盤點整理後的規則心智圖。圖中規則並不一定是目前線上實際規則，而是盤點整理當下時的規則。

從上圖可以看到在規則面上，申請天數、成員人數（成員身份別）甚至抽籤方式都有相異的地方。

而這些規則的相異處，包含各個管理單位行政作業流程上的考量，就系統設計面來說，能將這些規則盡量統一當然是再好不過。但考量時程壓力下，並沒有充裕時間能讓各行政部門坐下來將規則統一，因此，能夠處理複雜申請規則成為了這次系統設計的重大考量點之一。

所以我們怎麼整合？

最終經過全面性的系統盤點後產生如上圖那樣巨大的樹狀圖，需要解決的事情很多，但資源和時間是有限的，因此首要任務是從眾多的需求中尋找出核心且關鍵的部分來實作，並設定為 11 月 1 日系統上線的目標；這樣的做法也就是業界所說的 MVP 最小可行性產品(minimum viable product)。

我們的策略

我們將一站式服務網站拆分為前端(Frontend)與後端(Backend)兩大部分(註 2)來進行。

為了規劃出最小可行性產品的範圍，我們嘗試模仿一般業界常見的微服務思維來進行。

何謂微服務思維?

如果嘗試將一站式系統想像成由積木堆砌而成的城堡，我們可以很簡單的將城堡分割為許多不同形狀的積木，只要逐一地將所需形狀的積木找出進行拼裝。若特定形狀積木不存在則製作它；而為了避免花時間與金錢製作新積木，在切割城堡時盡可能以現有的積木形狀為優先。同時，回想以前在堆積木的時候，積木通常也都會製作成盡可能通用的形狀(如圓形、方形、三角形等)，也因此若萬不得已要製作新積木時，也盡可能考慮切割成通用的形狀。

在堆積木思維中，其中一個重點是，盡可能避免製作新的積木，因此我們選擇保留既有系統。

在圖的右半部分，是這次一站式服務的主要核心部分也就是新造的積木，前端 Frontend - 「一站式申請User 介面」及後端 Backend - 「一站式申請Server」。

中間則是每一個既有積木與一站式服務串接的部分 - 「使用者代理程式」，可想像成製作一個新舊積木的轉接頭。

在這個架構下，能夠保留既有系統，同時開發一站式整合服務網，讓一站式整合服務網將申請資料回拋到原系統中。

新的系統與代理程式之間採用 RESTful API 進行串接，API 規範採用國家發展委員會基於 OAS3 (OpenAPI Specification 3.0) 頒布的「共通性應用程式介面規範」。

在 08/28 以及 09/06，在唐鳳主持下，與部會及相關廠商就上述提到的雛形召開了共兩次的技術會議進行討。

在 08/28 的第一場技術會議中，PDIS 先向部會及廠商提出如圖 6 的構想。徵詢各廠商意見，以及溝通既有廠商需要配合的事項。

而在 09/06 的第二場技術會議，此時就「使用者代理程式」的技術細節進行討論，大致有兩大方向：由既有廠商自行實作 API 於既有系統，以及另行發包廠商透過 Web 爬蟲技術製作 API。

我們的最小可行性模型

經過 RAY 同學所做的使用者訪談、兩次的技術會議以及第二次技術會議早上的協作會議，總共歷經一個多月的時間，我們產出了如圖 7 的最小可行性模型進行實作。

由警政署、林務局、營建署針對現有山友們會使用到的國家公園入園、警政署入山、林務局保護區與山屋系統實作依照國家發展委員會基於 OAS3 (OpenAPI Specification 3.0) 頒布的「共通性應用程式介面規範」，讓原有系統廠商在允許的情況下盡可能針對遞交申請之 CRUD 以及公開資訊查閱（如乘載量限制、餘額）實作應用程式介面(API)，讓一站式網站使用。

把握政府數位服務指引精神(註 1)

為協助政府內部各機關發展跨域服務整合以及落實使用者為中心的服務設計理念，達成打造智慧政府的願景，自民國 107 年 1 月由國家發展委員會主導下，擬定了「政府數位服務設計準則(草案)」，並於同年 10 月公布政府數位服準則(Beta版)，提供給各機關作為發展數位服務的參考。(註 1)

這次的一站式的登山申請服務也不例外，我們在兼顧整體開發能量的情況下，盡可能地向(註 1)看齊。在整個專案執行的過程中，也不時地回頭檢視是否偏離其精神，作為專案執行過程中調整的依據之一。

國家發展委員會 - 政府數位服務指引

迭代式演進政府部門也可以！

前面提到把握政府數位服務指引，當中第四條：

採用持續精進作業程序 透過快速原型(Rapid Prototyping)、迭代(Iterative)及漸進 (incremental)軟體開發方式，持續精進服務。為因應技術創新、政策挑戰及使用者需求的變化，宜在服務生命週期各階段，考量使用者需求變化、服務整體架構及技術資源成熟度，採用迭代式的開發作業程序，持續納入使用者回饋，快速回應精進服務。

這次一站式整合開發的過程中，我們嘗試依照這樣的精神，透過仿照業界軟體工程的方法，要求承攬的開發廠商進行迭代式修正。

10/01，在 09/09 開發工作啟動後經過不到一個月的時間，我們對仍處開發中的系統進行了第一次的使用者內部測試，邀請了曾參與協作會議的民間夥伴協助測試、指出問題，並將這些問題收集歸納後讓承包廠商進行修改。

時隔半個月，10/16 再次邀請前一次參與測試的民間夥伴，確認是否有改善前一次提出的問題，並同時討論未來或許還能增加那些功能。

透過和部會協調下，讓整合系統上各個子系統（微服務）都分別具有「測試環境」與「正式環境」；11/01 系統上線後，由於有兩套相似系統環境的基礎下，透過如圖 8 的循環，能夠一小步一小步的將系統逐步變得更好。

大事記

最終我們在配合政策時程的需求下，在開發時程只有約莫兩個月的時間推出了第一版的整合系統上線。

下面這張圖的時間軸幫大家整理了這個案子的始末

未來展望

「這不是結束…我們才正要開始」

雖然系統已於在 11 月 1 日公開，但這不是結束，只是開始。

誠如前面所講到的，此案使用迭代式開發，因此系統上線後，仍然會持續彙整意見，納入持續改版考量。

針對那些受限於時程壓力，被排除於最小可行性模型中的事項，在 12 月 13 日的後續精進會議中 PDIS 也整理出來給予部會作為參考。

2019/12/13 臺灣登山申請一站式服務網後續精進事宜會議
- 簡報內容

註 1: 「政府數位服務準則」於 108 年 12 月更名為「政府數位服務指引」。

註 2：如一般業界對網頁服務(Web Service)定義類似，前端 Frontend 即使用者所能操作的網頁介面；後端 Backend 則是在網頁伺服器上使用者看不到的部分。以本案為例，RAY 同學們的設計即為前端的設計稿；而背後那些幫忙將申請單回拋到原系統的部分即為後端。