大家好，很感謝今天過來，我們一樣準時開始。跟其他我在院裡主持的會議一樣，都會做逐字紀錄，在編修10個工作天之後再上網公開，首先非常感謝大家為這個案子爆肝了兩個月，在場很多朋友持續爆肝相當久，我們也看到非常多的網友批評指教，但是比較不一樣的是，他們的批評指教不只是在網路上，而是跟我們有一個協力的關係，也很具體指出接下來可以怎麼樣精進，所以我覺得這還是共創很好的例子。

接下來的議程，我想我們會請葉寧參事實質主持。如果在技術上或者是流程改造上有什麼我可以協助的地方，也可以就像之前一樣，政委自帶廠商，我可以出一些主意，但在行政的事務上，以及很重要後續的追蹤上，我想皓婷有做一個簡報，先請皓婷先。

主持還是政委，今天會議有幾個目的，第一個目的是院長跟秘書長的會議都有提過民眾意見的回復，可能要整理一下，也要做一部分的處理，也要看有沒有哪一些問題是沒有辦法處理的，比如是跨部會或是有一些資源的問題需要協調、解決，這個可能要做一些盤點。

其實不管是網友或像天池山莊，又或是同仁有提出很多的意見，其實也是代表大家對於系統是希望它能夠好好用，所以這一些問題跟解決我們到最後也會跟秘書長報告，各單位都是非常主動的情況下解決了，今天第一個議程先拜託營建署來作彙整，請營建署跟我們作簡單目前問題反映的概況報告。

我們大概不會進到非常仔細地討論，麻煩營建署，如果您覺得有一些問題是今天會議可以討論或是解決的，不外乎有幾種，一種是跨單位的協調，或是需要院裡面一些指示之後可以做的，這個是一種。

另外一種是像政委剛剛提到的，也就是如果技術上的問題，可以進一步討論之後，讓大家對齊之後可以解決的，就可以提出來。

跟民眾反映問題有相關的，接下來有兩個報告案，是由政委辦公室PDIS小組提出報告，一個部分是皓婷設計師會跟各位談一下。因為我們期待一站式服務是可以永續經營的，換句話說，不會過了六個月之後就沒有辦法運作。

比較複雜的是，會牽涉到後面有三至四個，甚至是更多個各個單位的管理或者是申請系統的加盟，所以在這兩個方面都必須要注意到，之前爆肝的結果是很快讓系統上線可用，但當系統上線可用的時候，民眾的期待會逐漸提高，他們之前很習慣上警政署、國家公園、林務局的系統，但是並沒有把三個放在一起，既然放在一起就要真正能夠一站式服務，也就是使用者的經驗觀點來看這樣的一站式服務有無更進一步優化的可能。

另外，我們也請秉倫研究員在過去一個多月之間與大家一起工作，從技術在後續的維運上如何長期營運下去。今天當然也特別邀請國發會資管處的同仁一起來，這樣系統的改善是比較罕見的，真的是四個的申請系統合而為一，資管處負責所有政府網站的品質及精進，我們也請資管處的同仁來看有沒有可以更加精進的地方，所以整個議程的情形就是這樣，先請營建署來做概況報告，有任何的問題就提出來，然後由PDIS來做報告。

報告是口頭或是我們有簡報檔？

簡報。

剛才所說的罕見，那個是過去的狀況，以我所知，上個禮拜國發會才頒布「 政府數位服務指引 」以及 配套措施建議 ，也就是瞭解需求、跨領域的合作、多元服務管考及持續精進，未來應該就會變成常態了，各位就是這個常態之前的一個標竿。我們就開始報告。

主席、各位與會的長官、廠商大家好，我是資拓宏宇公司，一站式服務網委外的建置廠商。

本系統在11月1日正式上線，目前針對包括民眾申請與各管處反映的建議與問題進行報告。 11月1日正式上線後，統計到12月5日透過一站式服務網申請總共有329筆，針對申請的路線進行排序，前三名是玉山線、能高越嶺、雪山主峰線，這是民眾目前使用的申請狀況。

一站式服務網也有設置客服信箱，統計到11月25日，總共有27封的信件，將內容進行分類，包括功能建議、使用者操作，與其他系統介接的部分，大致有這幾類的問題。

針對相關的問題，屬於資料面的設定，我們已進行補正或修正。跟系統介接的部分，我們與其他介接的廠商也都有確認問題並排除。

在功能建議的部分，在本建置案可以處理的部分，我們已直接處理，比如在申請成功的時候，一站式網站上會有一個序號，如果民眾沒有自己紀錄下來，這個序號之後會查不到，所以針對這個部分，我們後來在一站式申請成功以後，會主動發出一封email來作通知。

基本上透過查詢，須要有序號與身分證字號，我們後來也增加另一種查詢方式，也就是可以用個人電話、入園日期、身分證字號進行查詢，所以如果個人忘記申請序號，也可以透過一些他自己知道的資訊來查詢。

另外，我們也新增了一個草稿儲存的功能，所以臨時要做一些修正，也可以很方便進行。

原本我們的建置範圍是轉介到現有的付費系統，但是實務在運作的過程，民眾申請之後，有可能人員異動、取消或者是退費，本計畫原本沒有規劃退費的功能，但是為了民眾方便的使用，所以在林務局山屋取消的部分，我們也開發退費的功能。

另外，這個階段不容易處理的，我們就會建議在後續的案件再來作規劃，比如像申請能高越嶺步道，要跨到奇萊南峰的部分，目前一站式網站只會對林務局來申請，並沒有對太魯閣國家公園來申請，以上作簡短的報告，謝謝。

謝謝。

非常感謝，我想技術上那個查詢的問題，其實就把很多民怨解決了，我現在看到也有單號跟其他的資訊，對不對？建議前面都加一個「以單號查詢」、「以其他資訊查詢」，因為標題是申請進度查詢，那個「以」什麼來查詢就是以標的來查詢，其他都沒有什麼問題，謝謝。

營建署或是警政署，又或者是警政署的同仁，有沒有要補充的？

林務局這邊第一次發言，針對資拓剛剛有提到退費的事情，其實我們現在有反映到我們異動退費，但是是人員要異動，所以沒有辦法讓民眾更改，就是只能讓你退，但因為以前我們的功能項目是允許讓你的人員作更換動作，像刪減，本來只能住五個，後來只去三個，要刪減掉，但是沒有辦法，必須要五個都退掉，等於要重來的意思。

謝謝。您之前有碰過這樣的討論或者是網友的要求嗎？

稍微回應一下，人員異動在一站式服務網是比較複雜的作業，必須同時面對，林務局、營建署、警政署及各個系統，一站式服務網於申請時，同時對這幾個機關一起都發送申請資料，所以如果要異動的話，除非法規允許以及這幾家廠商也都提供單筆的人員異動API，一站式服務網才可能完成單筆人員異動，不然以目前一站式服務網的精神，如果使用者申請完成後，如果要異動，就是一起取消，然後再一起申請。

單筆人員異動申請與一般的申請的是整批退整批重送是一樣的，只是使用者回報狀況比較麻煩的是，因為山屋系統會有所謂抽籤的問題，通常會發生這個登山的人抽籤已經抽中了，而且甚至已經繳費了，但是不希望他的取消會造成他的抽籤要重新去抽的問題，這一部分一站式服務網目前的做法都是由客服用手動的方式幫單筆個案的使用者來做異動的處理，目前異動的處理，會把一站式服務網的單子跟山屋的會員連結，做好這個連結的時候，這個使用者就可以透過山屋系統中人員異動的功能來完成這一件事。

未來如果要做這一種單筆人員異動功能，如果法規面或者是系統面都已完整後，一站式服務網，也是樂意去開發調整，以上發言。

我們確認兩件事：

第一，假設沒有抽籤的這一件事，如果異動就是撤掉重送，這個並不需要額外後面的API，也就是純前端的工作，目前當然還沒有這樣子的前端功能來做這一件事，需要在後台操作。

第二個，因為有抽籤的這一件事，所以目前除非在那邊已經有會員的資格，不然這邊不可能幫他延續他再次申請時本來會員的連結，會變成是這邊要先取得會員資格，而且讓你知道他那邊會員的代號，你才可以幫忙做這樣的連結，是不是這樣的意思？

沒有錯。這個連結的部分，資拓建議在山屋系統仍是採目前手動機制，因為山屋系統是比較特別的系統，是一個會員制的系統，是要有會員。一站式服務網目前手動機制的處理方式是，透過客服問答的方式來確認申請人的身分，當一站式服務網客服確定這個申請人的身分以後，一站式服務網就會通知山屋系統把這一筆單號跟會員做綁定的動作，之後使用者就可以在山屋系統做後續的異動設定。

要怎麼確認他的身分？

目前的做法是類似銀行客服一樣，就是問一些申請的資料，然後做一些身分的比對。

所以概念上不一定是要人類來做，像銀行確認的話，像線上開戶等等，很多是透過機器的方式來取得這一些資料，雖然現在是用人工，我聽起來並沒有高度對話性的部分，好像非是人來做不可。

是的，但是這一件事就變成這個使用者也是必須在山屋有會員，比如我們要後續來做自動化處理。

這樣瞭解了。這邊聽起來還算合理？

針對山屋人員異動的部分說明一下，抽籤前其實人員可以無限制異動，只要是同一筆訂單。抽籤前可以無限制的，像增加或者是減少人，因為還沒有抽籤，抽中之後會有繳款的問題，只要一旦一繳款了，就只有兩個人次的異動機會，因為這個是為了防止旅行社先抽了，然後再大量換人，所以為了防止這一件事，因此只要一中籤繳完費，最多只有兩個人可以異動，可是問題會出在兩個人異動，可能是取消了兩個人，這時候就造成有退費的問題，這也是一開始會議最早就有提到，也就是退費的問題，像刷卡的刷退其實是比較複雜的動作。

但是其實我們這邊API都已經準備好了，所以資拓是透過API，也就是不管是抽籤前無限次的異動，或是中籤後繳完費，最多兩個人次的異動，其實API是準備好的，所以資拓應該沒有這個問題才對。

第二，我們是透過單號，所以我們認得到這一筆訂單，只要資拓把單號給我們，我們就可以把這一筆訂單來做人員的異動，這個API也是準備好的，所以這個應該也不會有問題才對。

第三，我們面臨到的問題是，現在是透過人工告知我們，由我們的手去做人員的異動，這個對我們公司來說，這個是非常沒有保障的一件事，如果遇到冒名的，責任是不是我們的手去改了這個訂單，會有問題。現在有六件客服，行政院我印象中有兩件，要我們去幫這個訂單來做人員的異動，其實我們做的是很緊張的，因為如果是冒名，變成是我們的手去改的，所以我們建議趕快把洞補起來。

變成機器對機器。

對，不然我們是有責任的疑慮，以上是這三點，我認為這個應該不會有問題才對，因為我們的API是準備好的，應該不會有資拓說的問題，所以是要把它補起來。

感謝。我確認一下我聽到的，一個是因為目前單號的資料結構，目前是手動拋轉，也就是你們那邊的單號，是這邊跟使用者確認之後，知道在這邊相應於什麼單號，然後再打電話跟你們說，然後再請你們修改？

單號是自動的。我們現在訂單整筆，然後傳過來。

但是在修改的？

變成人工確認單，由我們的人修改。

所以打電話的人到底是你們或者是資拓？

資拓。

資拓確認是一個人類，他告訴你一件事，然後再提。其實對雙方都有責任，並不是只有對你有責任而已，有一點像我們做政府開放資料，無涉個資，一蒐集就發布，主要是不要公務員用手來做任何事，因為這樣你不知道是人的操作疏失，或是資料蒐集時那一台機器的疏失，如果機器對機器的話，很明確是那一台機器的疏失，我想這是比較清楚的。

第二個，我聽到的是，你們這邊抽籤後的API也是已經準備好的，只是可能這邊的前端或者是介接的程式還沒有能夠運用而已，這樣也牽涉到這邊提到的法規跟流程確認的問題。

這邊也是覺得這樣子嗎？也就是解決法規流程問題的話，這邊API是可以用的？

這個事情分兩段說明：

第一，如果只是要自動化解決訂單跟會員綁定，這一個部分其實是可行，也就是藝凡有一個API，讓一站式服務網送單號與會員編號配對，後續的異動就可以使用原山屋系統功能進行，這個是第一個方案。

第二個方案是比較遠期的方案，例如申請單上有兩名成員要異動，理論上也要通知警政署，甚至通知國家公園等等，在法規沒有限制問題，且這幾家廠商系統也都有提供異動API的話，資拓可以把異動的功能來做補強的動作。

所以如果現在改掉撤掉重送，等於是不是會有問題？因為等於是要重新審核一次。

現在的機制是撤掉重送。

OK，這樣我瞭解了，也就是短程跟你剛剛講的中程不相違背的，短程可以先做，並沒有你本身做了，但是中程反而不能做的情況，中程的部分，我想就列到後面的事項來處理。

是不是可以先問一個問題，也就是單號跟會員，可能有一單多人的情形，所以單號可能不只對到一個人？

抽籤的會員是一個會員？

一個會員可以申請多個訂單。

所以不會有一個單、五個人，然後中間有兩個人不去，其他三個人要去的情形？

會。應該是說在我們原有會員的機制下，一個會員可以有很多個訂單，但是一站式過來沒有會員，所以只有單號，可以有多筆訂單，但不知道是不是同一個人申請，這個對我來講不重要。

對不起，剛剛沒有非常完全瞭解。

第一，剛剛有所謂單號跟會員的問題，我聽起來的意思是，如本來申請的時候有帶會員，這個問題是不是就沒有了？或者是還是有？

一站式本來就沒有會員了。

但葉寧問是如果一開始就給你會員的資料，會不會比較好？

我一開始也是這麼認為，也就是我們把三個山屋的會員做成單籤，然後給資拓使用，基本上是AD進來。

這個我有聽懂。

回歸到會議的行政面要請教林務局的同仁。像剛剛聽到法規流程部分，我聽起來沒有很多法規的問題，但是需要一定的授權，如果有會議紀錄，也有提供一些授權，比如請藝凡提供API，請資拓加上去，長期來講做什麼樣的改善，會不會下一次系統維運或者是重新再處理的時候，就可以比較容易來處理？

我的意思是，行政院的會議紀錄可不可以幫你們做一些事？

可以。

比較確切的文字，可以會後提供給我們辦公室的玉琪嗎？

另外，如果會員可以解決這個問題的話，似乎我聽起來並不是不可以，在一站式申請的話，如果要退費的話，你必須退……

這個等一下秉倫應該會有相關的討論。不過我想我們至少不要用人工做可能增加風險、麻煩、而且還沒有credit的事情，我們儘量不要有這個形狀的東西。

即使資拓的角度，專門對山屋有一個更改的專門案件，這是相對容易的，不用改大的資料結構，我覺得我們叫做「低垂的果實」先解決掉，大家再看能不能類推適用，如果可以的話，我們後續再討論。

資拓提到的問題，我不知道有沒有什麼討論或者是解法？也就是有關於能高越嶺、奇萊南峰，涉及到林務局的申請及國家公園的申請，很多的意見反映是不是同時間可以連結到入園證的申請，然後拿到入園證。南二段是用專案的方式來處理掉，或者是怎麼樣？我的意思是是否不只是能高越嶺到奇萊南峰的情形，這是不是有什麼通案方向？

主席、各位長官，玉管處發言，南二段的話，嘉明湖營地自108年8月1日起原6個營位中之4個營位，由林務局提供給進入玉山國家公園生態保護區路線民眾山友申請，民眾在申請南二段的時候，如果申請嘉明湖營位，我們就會依申請先後順序安排營位給民眾，再透過林務局的繳費系統繳費，繳費之後就會核准入園。

我懂意思，這是另外一個解決方式，也就是把南二段的窗口移到玉管處，把嘉明湖避難山屋的營地釋放出來讓玉管處分配，但是另外一個情形是他們申請天池山屋，如果往下走能高安東軍的時候，就會進到太魯閣國家公園，可是申請天池山屋的時候，我的意思是自然不會有太魯閣國家公園入園證的申請，是這個意思嗎？

如果按照玉管處的解決方式，也就是本來有營位釋出來給太魯閣國家公園運用，像這樣的路線可以單一窗口的申請，比如移到太魯閣國家公園的意思嗎？

從系統面來講，為何這一條路線沒有辦法在一站式服務網完成的，原因跟南二段類似，因為走這一條路線有一部分的途經點是在太魯閣國家公園，另一部分是在林務局，一站式服務網的角度來看，走的是一條路線，所以很容易帶出今天要完成的路線，比如從天池山莊的登山口，一路走到奇萊，從奇萊南出去等等，看起來是很順的，但是以這樣的路線，我們以API丟回去給太魯閣國家公園系統，而這個系統就會錯誤，因為太魯閣國家公園系統並不知道林務局的途經點，就會自動否決這個申請單。

所以其實如果這一件事的短期解決方案，就很像跟南二段類似，太魯閣國家公園系統的途經點要納入能高越嶺道的這一些林務局管轄途經點，把這些都途經點都新增以後，一站式服務網送出來的路線，太魯閣國家公園系統就能接受，完成這一段路線的申請，這是短期解決方案，但是就變成系統面的資料點要做增修的動作，以上發言。

等一下秉倫報告會提到這一件事，我們等一下再來處理，看起來這個其實就像我剛開始所說的，原來是三站服務或者是六站服務的時候，民眾沒有這個需求，就會覺得既然要拆單那就拆單，先申請到嘉明湖，再從嘉明湖申請入園，我們放在一起的時候，期待值會提高，會覺得怎麼動作沒有一次完成，這個是我們今天要解決的問題，這個等一下會再來報告。

有沒有要在這個階段提出來的？也就是圖景點的一致化，等一下會討論。

如果沒有的話，是不是請皓婷。

謝謝政委，謝謝各位夥伴在這一、兩個月超過，協助我們整合、優化的經驗，還有整合一站式的服務網。其實我的報告也是在這兩個月內跟各位夥伴合作，發現了很多其實我們在實作使用者經驗，發現很多要整合、優化的部分，其實不管是資拓、林務局、營建署或者是警政署，其實都有接過跟我的聯繫，大家都知道脈絡大概怎麼樣，我們也有跟各管處詢問使用者的經驗跟建議，以管處的經驗、使用者的經驗為平衡，得出了一些建議的方向。

當然有幾個議題，我先盤點一下今天可能會講到的議題，第一個包含剛剛講到的節點、路線名稱的統合，還有一站式填寫欄位減少、登山角色統合、申請日期整合、山屋分配規則，及聲明整併。

其實這幾個議題，有一些比較單純、有一些比較複雜，所以議題單純的部分，我們就會有一個大致上的建議方向，建議你們可以參考自己實作的經驗，也參考我們的建議方向。

第一個，我們想要講的是議題比較單純的部分，希望接下來的一站式廠商可以跟進，為何是廠商跟進？也是因為目前實作上有看到其實路線的名稱跟節點會影響到很多一站式使用者的經驗，以一個簡單的例子來講，像奇萊南峰營地跟南峰岔路口營地，其實兩個講的是一個地方，但是實際上可能因為常年使用的關係，大家用不同的名稱來統合，但是如果要搜尋的話，是要從這兩個東西搜尋到同一個地點，當然秉倫會就使用者經驗、系統後面的邏輯，再就這個議題來深究，所以我不把時間花在這邊，等一下一起交給秉倫。

同樣剛剛討論到的南二段，還有天池，不管是跨林務局或者是國家公園路線的問題，都會一併在秉倫的簡報當中作細部的討論。

另外兩個議題比較單純，我們有一些建議的做法，其實在前兩個月，相信各部會也有跟我們一起合作，有做了一站式填寫欄位的減少，其實在第一階段的時候，我們有做全面盤點的表格，這個表格當然也會附給各部會作參考，這上面都有大家回覆回來這個欄位是不是必填及原因，這個是交給你們來做參考。

其實我們今天想要講到的是現況更新，其實跟大家在這一個部分的合作上，其實聽到很多部會有回應給我們，其實有些欄位真的是常年以來累積下來的一些填寫作業，實際上把它刪掉，並不會造成太多作業的負擔，反而其實是幫助部會們在審核資料上減輕負擔，甚至其實我們的方向是希望可以優化使用者的經驗，所以這個是現況的更新，目前第一階段刪除了將近20個欄位，這裡面當然也有再來回討論之後希望保留的欄位，例如申請人的生日。

需要大家注意的是，因為有一些欄位，資拓在打申請單的時候，可能會遭遇到一阻礙，所以需要各部會更新API，其實這一些欄位如果要刪除的話，也就是各部會的廠商要更新，這一些在系統上也不需要再填寫了，但是這些需要更新API的，現在目前如果刪掉的話，申請單就會不通過，因此這部分再跟資拓協力，確認一下不同的資訊。這是一站式欄位盤點的現況。

我稱這個東西為第一階段的盤點，因為其實使用者經驗是不斷演化的過程，搞不好可能過了一段時間之後，又會發現某一些欄位又不需要再填寫，或是某一些欄位因為某一些需求再增加，所以這是不斷演化的過程，也希望大家可以持續跟進。

當然，我們還有第三個部分是登山角色的統合，其實我在送出去的回饋單當中有問到一個實際上因為林務局那邊有一個協作員的身分，國家公園目前在系統上並沒有這樣的東西，這個議題其實相對而言是比較複雜的，對於一站式整合系統來講，大家希望可以統合各身分，不管身分別或者是資格，隨便舉一個簡單的例子，像申請人跟留守人需要年滿多少歲，我們會看到有的系統是規定18歲、有的是規定20歲，這個可以想系統在建立的時候，大家不曉得互相的規定，既然現在有一個統合的系統之後，是不是可以用一個簡單的方式來統整這一些規則，讓一站式接下來的演化，也可以比較順暢。

至於協作員的角色，這一個部分因為比較複雜，所以並沒有列在上面，但是也可以建議你們在之後有做統合時可以考慮進去，並且研議一下。

當然接下來有幾個議題是需要更多的後續跟進是比較複雜的，我們會建議成立各單位的聯繫窗口，由營建署召集、定期開會追蹤，接下來是這四個議題需要這樣做。

第一個是申請日期的整合，我們在一站式上線的時候，就遇到了有很多不同的申請日期，當然之前因為登山解禁的關係，我們已經把它改成是前5日，但實際上經由我們之前的一些盤點，也有發現某一些國家公園目前的網站上，其實還沒有更新這樣的資訊。

其實這個最重要的部分是，我們要注意的是，因為有一些單攻路線可以前一天，甚至是前三天來申請，我們不希望犧牲掉這一些方便性，但至少在最大值，也就是到底是兩個月前可以申請，或是一個月前可以申請，這部分希望各部會可以有一個研議的動作，然後來討論怎麼樣才是對整合的經驗最友善的，包含要考慮到不管是營建署或是林務局，甚至是警政署那邊的限制，再來研議出一個統合的日期。這個連結也會附給你，這個是之前辦公室所做的整理，這個也提供給你們參考。

另外一個是，我們其實常年以來都知道非常複雜的議題，也就是山屋分配的規則，目前大致上兩個，一個是先搶先贏，另外一個是抽籤，這個是大致上來說，因為抽籤不管是林務局的三個山屋或者玉管處轄下的山屋，就算他們都是抽籤，但是他們抽籤的方式也不一樣，在後補抽籤或是之後後續的動作都不太一樣，所以我們會希望這個比較複雜的議題，可以先讓各部會自己想好自己覺得適合的方式，然後再跟大家一起來作協調，找出最好的統合方法，所以我們也希望可以建立各單位的聯繫窗口、定期開會追蹤這個議題。

在使用者的經驗上，一開始上線遇到困難，也就是聲明整併的部分，一站式是拿目前各個單位不同的聲明頁面來做，但是實際上比較適合的方式，我在這邊說整併，應該是要有一個統一的聲明，可能包含各部會你們覺得應該要包含的資訊在裡面。

其實我也非常希望能夠平衡法規跟使用者經驗前提之下，因為聲明當然是不可避免的東西，但是實際上我們也不希望使用者因為要申請這個東西，然後要苦讀三至五頁又臭又長，且沒有辦法很好理解的聲明。

我在這邊也有附上一些不同的參考資料，不管是在紐西蘭國家公園或者是英國登山系統，他們都有一個很好參考，你們可以看看他們是怎麼樣把他們的資訊分類，然後怎麼樣簡化。

這個附件有一點小，我會再附上去給你，這個是我們參考了其他國家做法之後，也給了所謂的原型，可以給你們參考，也就是分類是怎麼樣的方式，資訊上可以怎麼樣做不一樣的統合。

這一份簡報會後也會再請玉琪都寄給大家，如果有任何的問題，隨時可以跟我聯絡，以上報告。

最後這一張是排版的參考，不是內容參考，內容當然是各位專業，只是怎麼樣排起來比較容易看而已，比較是視覺溝通的部分。

另外，我剛才有聽到的是，不管是奇萊南峰或者是南峰叉路口等等，這其實也是剛才所講的，尤其系統裡面沒有，或者是有，但是裡面的一個名字，這都要做一些整合後續工作。

最後我剛剛聽到填寫欄位減少，初步短期比較簡單的是，從API不填這一些欄位的話，並不會退單，也就是變成選填，這個是最容易改的部分，未來在自己的介面裡面，是不是也要把這個東西變成選填或者是不顯示，那個是比較中期的部分，以上是我的理解，看各個機關跟廠商的朋友們，有沒有覺得這個方向有什麼哪一些可以精進及調整的部分，這個是諮詢性的建議裡面，我們要寫到會議紀錄裡才變成大家都可以用的東西，現在很歡迎大家提供一些意見。

我是國家公園廠商，剛剛報告完之後，我以一個登山者的角色想問，申請日期的調整有包含外國人嗎？就我所知，只有玉山會提前幾個月，但是其他跟外國人的申請好像沒有特別提前，我想問這邊會不會做相關的整合？謝謝。

謝謝。外國人的部分，看有哪一位朋友知道，是不是可以先回答？

我們有外籍人士可以提前申請的措施，因為外國人要提前規劃行程，所以我們讓外國人可以提前四個月就申請，以上報告。

目前像雪壩、太魯閣從今年開始也有這樣的措施，也就是外國人可以提前四個月申請。

林務局也是。

所以大家是希望先訂得到，再來訂機票，意思是這樣子。剛剛的問題，未來一站式服務網，因為目前以我的理解沒有英文介面，雖然版面設計很好，資拓設計出來，用Google翻譯出來是看得懂，但是並沒有是外國人、所以要護照等等的程序，第一個問題是未來有沒有給外國人的介面。

第二個是我們現在討論這一些申請日數的整合，如果先不考慮外國人的情況，具體有哪一些還需要再調整的，我聽起來您的問題也有這樣的意思，是不是這樣？

其實主要是針對外國人的部分，因為我覺得明年是觀光據的登山旅遊年，會吸引一批外國人進來，在行政整合上，應該要讓外國人可以更親近臺灣的山林，謝謝。

感謝。所以這樣聽起來的意思是，從您的角度來看，給外籍人士的一站式的，當然至少要有英文的，也就是適用外籍人士規則的一站式服務網，這個比較像後續開發的建議，是不是這樣？

對。

並不是要針對外籍人士來針對天數的調整？

應該是說是否變成林務局、警政署、國家公園的相關單位，針對外國人的申請日期是要做一個統一的，而不是不一樣的時間，我不確定現在是不是都已經統一了，所以想瞭解之後的狀況。

就是現況的釐清，瞭解。

提到日期的部分，我要先感謝警政署，因為在這個過程中，警政署的申請日期反而是30天，國家公園也好，或者是林務局的山屋也好，這個抽籤日期是大於30天之前的，在一站式申請只要一個單位不合規定就沒法申請，所以在11月1日很臨時的狀況下，請警政署的同仁幫忙，所以已經改了45天，要感謝警政署非常有效率。

回到這個問題看起來一樣，如果國家公園跟林務局的規則是四個月的話，當然也會建議警政署的入山申請，也就是按照這樣的規則來辦理，換句話說，不會因為只因為入山申請時不符合規則，然後就退件。

整體來講，像剛剛皓婷所提的報告，也就是所謂使用者經驗，我們看到的觀察建議，如果各個網站的管理規則放在一起的時候，需要儘量的統一或者是簡化，大概有幾個是我們看到的，節點的問題等一下會再看，欄位減少應該是一個趨勢，皓婷的建議是自主逐一檢討，把欄位儘量減少，填需要填的欄位，甚至有一些API的話，就繼續做，接著也是身分資格的問題，在不同的系統可以統一起來。

像日期需要做一些協調，山屋的分配規則，先到先贏不用講，抽籤的規則也有一些不太一致的地方，或者剛剛提到各自有各自網站的聲明，可是到一站式的時候，可能要必須整合成單一的聲明，而且是符合使用者經驗比較易讀的聲明，雖然大家看到可能還是都點接受，完全沒有細看，我們還是提供比較好的服務。

整體來講，這一個部分如果大家沒有補充的話，我們還是會把剛剛皓婷所說的，短期或者是長期的修正參考，中間有提到一個具體的建議方式，這個當然會跟先前11月15日秘書長會議決議有關，那邊已經建議登山網站的問題，如果有需要跨部會協商，提到教育部的工作小組，可是我們會覺得教育部工作小組，那是政策面，正式的名稱是「登山解禁政策跨部會工作小組」，現在的問題不需要到教育部或請示秘書長那邊就可以解決，大部分都是警政署、林務局、國家公園的同仁談定，大概就可以了。

我們建議的方式是建一個協調聯繫的機制，當然營建署還是最大宗的，營建署能夠仿照今天的方式來開會，像三個月或者是幾個月開會一次，把大家所提到的問題進行追蹤、協調，能夠統一的就統一，光是大家的規則統一，不管是國家公園的三個管處統一，加上目前林務局、警政署的規則統一之後，整個使用者經驗就會改善非常多，這是需要長期去做的，所以如果大家不反對，我們還是會把這個做成決議，也就是請大家有一個協調聯繫的機制，來開會並且追蹤檢討，也解決新發生的問題。不知道大家有沒有什麼意見或者是需要補充的？

剛剛有提到申請時間，也希望警政署配合提前外國人申請四個月，但是現在進入生態保護區，其實先核准入園，然後才會請他們做入山申請，如果提前到四個月申請，其實我們提前四個月申請，主要是要保留外國人的名額，我們有一定的限額，像目前一站式的，申請了入園之後，入山申請就馬上核准，但是我們入園還沒有核准，這樣民眾會誤解已經可以入山了，實際上山屋還要抽籤、名額還要分配，所以這一個部分，可能建議，如果進入生態保護區，是不是先不要送入山，我們核准之後再送入山。

不過你們核准還是有可能是在實際發生前，像三個半月之類的，如果是外國人的話。

其實這個問題好像沒有這麼大，像入山申請的部分，並不是下決議請警政署入山申請就外國人的部分要提前四個月，這個也要看警政署是否容許，但是希望他們儘量朝向一致。

但是拿到入山申請，不等於拿到入園申請，這個是大家可以理解的，因為現在是三個獨立的狀況之下，沒有人認為拿到入山證就可以登玉山，一定要拿到玉管處的同意才行。

我不知道原來一定要入園或者是自然保護區的許可才能申請入山，有沒有什麼先天上一定覺得非如此不可？避免混淆我相信現在國家公園或者是警政署的網站都很清楚標明，甚至國家公園很貼心入園拿到以後點一下就幫忙送入山申請。

現在一站式的服務更清楚，如果入山的條件不符合ㄝ就會被打回來，原來希望管控的目的更清楚，也就是假設符合入園資格，但是不符合入山資格，雖然這個情形很難想像，如果這樣的話，這個單子就退掉了，所以不會是拿到入園之後，然後才需要入山的情形。

在現在這個機制底下，只要警政署不同意，入園也拿不到。

或者拿到的單還是會退掉，也就是還是會失敗。

很明顯會得到一個訊息，也就是警政署基於某一個理由不能入山的話，在這個系統的話，是更明顯的。

但是這個跟本來的操作習慣不一樣，我聽起來意思只是說，如果有一些比較習慣操作習慣的朋友，他們在一站式上可能會有一些誤解，也就是流程上混淆。

我在山友社團看到本來對系統越熟的朋友，覺得新系統越混淆，因為他們很習慣舊的介面了，這個是為什麼我們報稅軟體還要保留本來的Windows，原因是一樣的。

但是對於新手來講，也就是之前沒有對舊系統的朋友來講，一站式腦裡沒有預設的流程，反而覺得比較順，這個確實任何新的系統都會碰到這樣的情況。

一站式的情況之下，是更清楚知道所有都要拿到才不會被退，簡單來講是這樣子。

再看其他朋友有沒有想要提出來的一些點？

有關由本署定期召開會議，就前面所提及建議再行改善，這個我們會來進行，但是申請規則跟聲明整併的部分，涉及到各個單位行政規則的修正，需要一些時間，短期內沒有辦法解決的部分，將納入明年度的標案來進行，以上說明。

像剛剛有問，明年本來就打算把英文的部分納進去嗎？所以包含外國人的登山規則等等，也是在標案的範疇裡面？

是。

今天我們幾乎沒有押時間，只是希望大家把現在看到的問題記下來，能夠接著繼續去改。

就是短期內標案可以解決就解決？

當然。我們只是覺得好像不用提到秘書長指定的大政策工作小組，這個是小問題。

我們跟林務局談好就可以了。

那個比較政策層面的問題，這個比較是技術層面。

假設三個月開一次，我們儘量不要半年開一次，因為這樣三個月一次的平台裡面就不會有我們的報告案，這樣看起來也不會奇怪，因此儘量跟著大會議，或者是會前會的形式，也就是要開上面政策檢討會之前一陣子，也許這邊就找一個會，當然因為我們現在不確定那個政策會的週期。

如果各單位協調之後，還是需要資源，像需要增加部會預算，就可以跟秘書長提了。

謝謝。看接下來還有沒有其他的朋友要提哪一些想法？

對不起，我們說明一下英文網站的問題，依照之前的合約精神，資拓會做英文網站，而且目前英文網站已經都完成翻譯放在資拓的測試環境下，預計下個禮拜會找一個時間部署，所以在今年就可以看到英文版的網站。

比較不一樣的地方是，一站式系統把外國人的申請規則等等，全部納入英文版的網站處理，技術上的做法是，中文版打中文的API，英文版直接打英文版的API，這樣就會變成國內申請跟國外申請的規則不同，是以API的方式區分。

前幾天署裡面也有開會，也有提到這個部分，如果是僅懂中文的外國人，在中文網站申請，對於這樣的案例如何處理？

這一件事就會變成有兩個狀況，一個是外國人申請中文版網站，以及本國人申請英文版的網站，其實第一個是如果外國人看得懂中文，用中文來申請，以目前的狀況來講就是會follow國內的機制，除非我們在申請人那邊，有一些系統會勾本國人、外國人來做區分。

另外一個是，本國人想要用外國的方式來申請，但是他說是用英文網站，也就是提前到四個月前申請，但是其實申請，基本上都會有審核的機制，所以就算他其實是本國人用外國人的方式申請，基本上在審核的部分，是會打回票，以上發言。

不過剛才講的其實是本國人，但是不會中文的這個情況，這個情況當然也是存在的，比較小眾，但是是存在的，以及外國人不會英文的情況，這個就很多了，並不是所有的國家都是有這一種語言，當然後面那一個，我們可能是用機器翻譯，也就是確保那個東西機器翻譯是翻得動的。

我覺得以我對網站的經驗，機器翻譯雖然目前只有看本國人中文的版本，機器翻譯一翻起來還ok，並不是完全不會懂，所以如果只會西班牙語，就到英文的網站，然後用自動翻譯，把它變成西班牙語，以我的理解，這個也是資拓……不是馬上要做西班牙語網站，或者其實是有的？

我們今年只會做中文版跟英文版的，但是有一個東西可能其他各機關要配合，整個網站系統英文版是沒有問題的，但是各個系統會送回來狀態字串，現在大部分仍是回傳中文，因此英文版的網站會有一個問題是，如果在英文網站申請失敗的話，系統的錯誤訊息會是中文的，這一個部分可能需要跟廠商大概提醒一下，也就是以後在做錯誤回傳的時候，除了中文的說明以外，也要再提供英文的說明，這樣英文版的網站，在錯誤上的處理，就可以用英文來做顯示，希望各個單位可以配合，謝謝。

我想這一個應該不是瞬間改，但是你只是變成中英併陳的話，沒有改不動的道理，這個就比較不能靠機器翻譯，錯誤翻譯必須要很精確，像要補什麼件之類的，我想這個翻譯的責任還是要在各系統裡面，沒有辦法讓一站式來猜大家的錯誤代碼，自己變成一個翻譯來，這個似乎並不是妙，這個是要請大家幫忙的部分。

接著是國外的申請者不會英文，我不知道你們目前即將上線英文網站，是不是加一個自動翻譯的小元件在上面，如果真的看不懂英文的話，至少有一個看起來滿熟悉下拉式語言的選項，整個網站就翻成英文，這個有很多廠商，沒有很多，像是三個，有比較多是google，是直接改到你們的介面裡面。

如果這一版上去還來不及的話，是不是有辦法在後續的維護裡面加上去？

很抱歉，至少我個人目前沒有用過這樣的小元件，但是資拓是樂意研究看看，如果可行的話，我們會盡力配合，把自動翻譯的功能放在今年度的網站系統當中。

感謝，因為我們也沒有要指定特定廠商，但是提供全網站翻譯就那幾家，就麻煩你們看一下，這樣就可以解決外籍人士不會英文的狀態。

至於本國人說不會中文的情況，是不是足夠我們在中文網站也要加這一種翻譯元件，或者是我們推定如果是這個情況，自己本來就會去用網頁翻譯工具，這個倒是我們還沒有做過使用者的研究，還沒有很確定怎麼樣對他們比較好的，也請你們稍微徵詢一下，這個沒有定見，並不是要怎麼處理。

聽起來有錯的話請修正，一站式網站會做中文跟英文的，長期來看的話，中文網站也要能夠給外國人用，英文網站也要給本國人用，雙語國家的目標就是這樣。因為區分本國人跟外國人的身分之後，可能申請的日期是不同的，也就是把這個問題記下來，附帶的，包含系統，將來勢必可能都需要提供一定的英文服務，比如國家公園做得還不錯，也請記下來之後，請大家長期繼續來改善的。

雙語環境的部分，非常感謝提出，我們大概先處理到這樣，看其他的方面有沒有要提出來？

因為剛剛講到中、英文，我這邊補充一個比較不像後續的精進，比較像之前跟資拓有討論到，因為手機版的部分，我知道你們一直用Responsive Web Design在做開發，也因為這個禮拜根本沒有跟你們見到面，沒有更新最近的近況，也想跟大家討論一下，因為手機版目前在使用者來說，很多人都會使用手機，不曉得大家對於這個部分的更新及看法怎麼樣。

有關於手機版的網站，其實一站式服務網是base on在RWD的方式來做，大部分的網頁不會有太嚴重的破版的問題，比較會有問題的兩個網頁，第一個網頁是月曆的申請畫面。

概況表。

很難用低解析度來完成動作，另外一個是步道申請，也就是步道的路線選擇，我們會對這兩個網頁額外做手機版的優化。

在月曆的部分，我們有跟PDIS小組討論過，我們會用類似輪盤的方式來做日期的選擇或者是內容的查閱，Carousel元件都已研究完成，我們會配合辦理，在今年度的登山網站當中會把Carousel放在手機版上面，路線就是類似一般手機在做導航軟體，常用的方式就是點選的方式做路線選擇，這兩個都會做手機版的優化。

其他申請頁面，因為皆根據RWD，但是我們會手機的實際來看一下，至少不能跑版，又或是跑版太嚴重，以上說明。

感謝，這真的是非常佛心，因為大的表格的手機排版，並沒有一定的解決方案，我們如果去看線上訂房網站，每一家的做法都不一樣，並不是要做到100分，只是讓大家用手機版的方式，不能無法操作，我們先求有，我們Open API的目的就是看不順眼的人可以自己改介面，但要知道怎麼用才可以知道怎麼用，山友社群的朋友們有很多朋友提出意見，就會說請你來說你的標準回答。

看大家在其他的方面有沒有想要提出討論的？

就請秉倫。

我這邊就系統和技術面來報今天的建議。

這一份簡報的初衷是增加大家之後的靈活度跟便利性，增加一站式服務可靠性，避免單點失效。前兩週警政署的API突突然失靈，所以會讓所有的路線沒有辦法申請，會基於這兩個方向來做簡報。

第一個建議的是，可能一站式之後，幫路線的資料庫設計方式來做一些調整。現行的做法是，會有一些樣板路線，樣板路線會註記這個路線會涉及什麼管轄單位，如果民眾選擇什麼樣板路線，就用樣板路線所記的管轄單位做送出的動作。簡報上的節點就是剛剛講到的途徑點的概念。我舉一個比較實際的案例，也是林務局提供給我的路線，這個路線是奇萊群峰經屯原登山口，在這個路線底下我們可能會要申請警政署的入山，第二個部分還要再就屬於太魯閣國家公園部分來做拆單，我在簡報上綠色底的部分就屬於太魯閣的國家範圍。

像圖的上半部，也就是我在國家公園看到的路線，像林務局提供給路線我看到的是卡東營地，而國家公園系統上則是卡東木屋，就像剛剛皓婷提的，我們對於路線名稱要做一致性的統合。

接著比較複雜的是所謂南峰岔路口營地，因為國家公園系統上有看到奇萊南峰的登山口，這個變成登山口宿營地，如果使用者是用這樣的單來做申請的時候，系統最好可以做到的是可以幫他辨識，進行拆單的動作，也就是這邊先拆成先上宿營地，然後再上登山口，也就是把國家公園的部分擷出來然後再做申請的動作，接著是送天池山莊。

如果要做到像一步步剛剛那樣將節點挑出來看的方式，將管理單位從樣板單位的路線註記到節點，這樣就可以比較程式化的方式，從民眾提出來的路線，來計算哪一些點要轉送哪一些單位來做申請。

既然有像剛剛那樣拆單的動作，針對申請單資料結構，我這邊會建議的是，一站式的申請單要有類似這樣的觀念，一站式的申請單可能會有各個單位的申請單，假設民眾申請，比如大縱走之類的，甚至可能會有橫跨同一國家公園兩條路線，這個申請單就會有兩張國家公園申請單的狀況，所以會建議申請單的處理方式要調成這樣。

如果要調成這樣後，一站式查詢畫面建議也一起調動，（如簡報之示意圖）同時也要讓民眾很清楚知道在一站式是填了一張單，然後一站式協助拆成哪一些單送到哪一個單位去，這個是我畫的 Prototyping 示意圖。

途中上半部就是像剛剛有提到送警政署、太魯閣及天池山莊，下面就會看到相應有四個頁籤一站式填的資料，以及額外分別對應到太魯閣、警政署入山的申請資料。

上面會有一些概覽，也就是 Summarize 各個申請的狀態，這邊有一個「等待轉送」的部分，我後面會再解釋後面的東西是什麼。之前有蒐集到的資訊是，民眾會把一站式的單號拿去管處詢問，管處反而會對不到申請單，我會期待的是，如果有這樣的東西呈現給使用者，他們會知道在一站式申請單，其實是拆了很多單到各系統裡面去，民眾也可以在這個畫面上找到各系統的單號是哪一些。

同時如果有這樣的概念之後，管處對於被一站式拆出來的申請單有哪一些奇怪或者是看不懂，有疑慮之後，也可以藉由這樣的方式回來一站式看這個使用者申請的完整歷程，到底要怎麼樣走，釐清為何在某個管處只有申請某個部分的狀況。

雖然剛剛說我們講了比較好假設的部分，我們假設可以做拆單，但還是會面臨一個問題，每個管處欄位還沒有到一致的狀況，這一些欄位可以分成兩種，一種是相較固定，像國家公園、警政署、林務局山屋的這些系統，他們欄位是相對比較不變動，一站式系統在設計的時候可以先設計好直接撰寫在程式碼中。

但是現在這個比較大的問題是自然保護區的狀況，像林務局就有反映從後台更動保護區的申請表，一站式沒有辦法即時反映的狀況，這邊會有一個狀況是，假設今天林務局調動的欄位，一站式還是沒有辦法做很好的自動響應，像欄位是從A變成B欄位，那他可能會有一些 mapping (對應)關係，比如只是填的格式改動了，但是自然保護區給API的資訊可能是不一樣的欄位，但一站式也沒有辦法透過程式化知道這個欄位原本是要對到之前的什麼欄位，因此自然保護區的廠商要幫忙想一個比較完整、比較好理解，如何 render (繪製)動態表單的API結構。

另外一個建議一站式收單與轉發機制，這個跟剛剛前面簡報有提到所謂「等待轉送」是有一點關係，先講一下現行的做法，現行的做法是如果一站式收到單之後，會回拋給各系統來檢查，檢查都成功之後，然後開始發送，然後才會回一個申請單號給民眾，但是這樣會有一個問題，像剛剛前面提到的避免單點失效，先前有小段時間警政署的部分API壞掉了，整個申請就沒有辦法做了；另外剛剛也提到現行制度有所謂日期不統一的狀況，像警政署45天前，國家公園是可以到兩個月甚至是120天的狀況，這樣民眾也沒有辦法送單，所以會建議改成這樣的狀況，我們在做一站式收單的話，我們只要日期符合其中一個管處的規則，然後就會收下來產生單號。

我們在合乎規定的時間內，像時間到了，比如民眾兩個月之內申請，到了倒數45天就轉送警政署的單，甚至在這個機制底下，如果發現有單點失敗的狀況，可以設計一定次數的重送，如果假設可能在三天之內可以重送成功之後就不會衍生其他問題，如果一直重送失敗，一站式也要有機制，也就是批次把部分管處失敗的單匯出，然後透過人工的方式轉送申請單，也就是讓管處來作處理。

接著是申請單的同步機制，剛剛有提到遇到山屋要退部分人的狀況。現行的狀況是，要減少成員或者是修改成員的資料，民眾透過電話請管處異動，異動完的結果不會回到一站式，兩邊的資料不會一致，會有越來越重的落差，來回涉及的廠商不只有一間。

第一步是在一站式這邊建立 webhook，也就是在各管處的系統進行異動時，管處的系統也有機會回饋回來給一站式系統，在這一步做完之後，再建置讓一站式的資料改變的時候，再 sync 到各管處系統。

我這邊提異動 webhook，目前只會有每個管處的變動可以回來（一站式），但 A 管處變動不會到 B 管處去，如果異動的話，可以同步回一站式整理之後，我們下一步想要怎麼樣把一站式的資料Sync到各系統去，以上報告。

其實後面的這半部是很基本的概念，本來類似像直通轉換變成儲存轉發的概念，這個當然涉及到我們所謂的營運邏輯改變，所以這個當然並不是要年底之前資拓要做完，絕對不是這個時程。

但是只是說因為這邊也要開明年的案子，提供這一個方向，不是非得這樣子做不可，但是確實我們目前看到的是隨著時間過去，維護的成本開始增加，這個提出一個未來比較有效的減少維護成本，大家在每一個地方，像改欄位或者是改狀態有所異動，像玉管處的同仁有一部分過、有一部分沒有過，可以儘量減少使用者的認知成本，不需要用後台同仁的時間成本來補，這個是雙方都節省時間的設計，並不是這個是唯一的設計，這個是唯一的參考。

看大家對於這樣的方向有沒有什麼想法？這個是未來，也就是明年的事情，在此強調並不是今年要做的事，為了減少大家後續維護的成本，這個也許是一個方向。

我是保護區的廠商，我有幾個系統面的問題。

第一，我們在這兩個月的合作過程當中，其實有遇到每一個API內容同步的問題，因為第一次開會的時候，其實在保護區這邊，也算是一個各林管處的小平台，因為各林管處有自己的需求規劃，所以會指定自己的管理內容。

我們在一站式介接的部分，大概會分成兩個層面，一個是內容變動的部分，也就是申請的日期會從5天調整為10天，申請的成員會從10人調整成15人，內容不變，但是結構會變動。

接著是申請的時候，各林管處需要民眾申請資料的部分，可能會調整，也就是剛剛有提到的動態調整欄位的部分，這個是第二個部分。

第三個部分，未來各林管處因為自身的需求，有一些林管處需要解說員的角色，這個改動就會更大於我們需要跟平台，需要提供的人員，還要再擴增角色，這個是另外一個層面的改動。

目前來說，這個三個層面的改動在介接層面時都會有一些問題，林務局在測試的時候，也回覆過相關的問題也提供給一站式廠商。

雖然變動有三個層面，剛剛有提到要再思考如何更動，更動的幅度不會太大，第一個內容改動的部分。

因為一站式廠商這邊，其實是有介接我們的API讀取內容，每一天要跟民眾講說那個區域目前申請人數的狀況怎麼樣，很明顯的是有即時讀取API的內容，即使讀取的項目並不是全面，有可能是讀取部分的資訊，我們想要問的是，因為之前有討論過，沒有太大的結論，像API的內容改變的話，這個東西應該要怎麼樣處理這一件事？後續兩個層面改動，我們之後再討論看看。

謝謝。

我先釐清一下，秉倫剛才講的，以我聽起來是包含結構跟內容變動，這兩個都包含在內；您希望我們先聚焦在內容變動的部分，當然ok。

我想這裡面有兩個部分，一個是給使用者看到的部分，好比像你要提示什麼文字等等，這一個部分在你們的小平台上，只要在後台一改，立刻就生效，或是你們會有上板的工作，然後每天固定幾點生效？

直接生效。

比如5點30分加一個，從5點31分之後的申請就新的？

對。

這裡就出現API同步的問題，像從一站式的角度來看，當然可以約定時間去讀你的我們叫做「資料綱要」，也就是OpenAPI的Schema的部分，像每送一個申請單之前都要變化一次的話，這邊需要的彈性就比較大，而且也會對每一次的申請造成負擔，所以通常API同步的規則、樣式是雙方約API同步的時間點，好比像每一天凌晨，這邊才生效，這邊很明確說是隔天開始都用新的Schema來顯示。

但是這邊有營運規則的需求，真的非常需要當天改了就當天生效的話，當然我們也尊重你們，但是這樣子就需要用這邊改了之後要通知他一下，這邊來進行讀取，無論如何不能用polling的方式，這邊要顯示一筆單，然後就回到你們這邊問一下資料綱要，這個是不可能的。

從你們的角度來看，你們跟不同的系統管理員來說要改，但是要零點才會生或者是零點、十二點才會生效，這個會不會有困難？又或者是維護會比較好？這可能對你們是比較簡單的。

我簡單回答一下，其實我們申請調整的項目重要性，其實是各管處的需求，但是並沒有這麼即時性的需求，跟民眾的錢什麼都沒有太大的，都是一些資訊上的問題，我們覺得定期更新其實就是可以的。

但是之前在討論結果，平台那邊是說有追蹤的機制，就是希望在哪裡登記，但是我們這邊沒有辦法控管各管處什麼時候調整，如果要我這邊通知平台，我就是寫一個機器人。

你寫出來也會變成定期更新，不如定期更新就好了。

我們覺得意思是一樣的，這個部分我們覺得並沒有這麼強烈的需求改說要馬上呈現，就是一週或是一個月要更新一次資訊。

只要不是每一次申請都更新，不會影響使用者的體驗，要一天一次，甚至要一小時一次，其實技術上都不困難。

但這邊我剛剛釐清的只是並沒有很強烈影響到使用者權益是30分改41分就一定要套用的強度，如果這樣的話，我也會建議為了省所有人的麻煩，這邊是定期抓新的描述檔，在那個描述檔，本來就會有欄位的說明等等，這個是OpenAPI現成的東西，透過描述檔的方式，把字響應的部分來解決，看秉倫覺得怎麼樣？

我目前看API的狀況資料，並沒有非常好的動態random，兩邊可能要再協調一下，也就是API回應的Schema如何描述新的欄位會比較好一點，這邊還沒有到OpenAPI的標準來描述。

當然，未來還有中英文，所以會變成好比像API改了之後，那邊要確認他們回來的資料綱要裡面，有一個英文版的資料綱要，然後描述的欄位是英文的，以及有一個中文的資料綱要，描述是中文的，說不定本國人、外國人也要兩個endpoint等等事情，這個是未來，並不是現在。

按照秉倫所講的，比較充分運用JSON的Schema，也就是OpenAPI的一個附帶資料標準，先看能不能應用，然後再劃出來，不行的話，再約定一些external documents的欄位，也可以多用。

甚至external documents documentation裡面放markdown也是可以想像的事，這一些不是做不到，而是兩邊要有所約定，我覺得這個方向比起給delta來講，對兩邊的開發成本其實比較低一點，所以我也會建議隨便什麼方法，大家省一點時間就是比較好的方法。

這個題目先這樣，看其他有沒有要提出來的？

另外的問題其實也跟資料內容修改的問題有關，因為我們目前來說，前兩個月，我們上的保護區其實是所有的保護區，但是事實上來說，並不是所有的保護區都跟登山有關的，我們還有跟澎湖、台北市相關的區域，或者是一些其他的區域是能夠業管，但是並不是所有都跟登山有關。

我不太清楚保護區這邊在一站式平台的角色，是要把所有的保護區上到平台裡面來提供民眾申請，或者是這邊是有一定的規劃，只是把部分的區域放在平台的範圍當中？因各個區域的管理方式，並不是一定都能套用登山的方式來管理。

你剛剛舉一個很具體的例子是哪個保護區希望可以明列？

淡水紅樹林。

玄武岩。

玄武岩很難講是登山的。看這邊有什麼想像？

目前這個平台主要是針對登山的部分，如果保留區部分跟登山無涉，在系統上也沒有問題的話，建議就把這個部分切開來。

這個問題當時談過，這個網站的特色是自然保護區的系統本身一定要維持住，而這個網站的名字是叫做「登山一站式服務」，所以當然結論上跟你所說的一樣，如果不牽涉到入山入園的部分就免列，這個是符合原來的邏輯，原來的邏輯是登山會碰到自然保護區，不需要再跑到自然保護的系統再申請一次，但是一開始有提到有一些專門作研究，或者是看玄武岩的就不一定要，將來大家定期的會議如果碰到的時候就討論，這個大概都沒有問題。

而且我想我們後來是做響應表單，你就在所提供的選項裡面直接把它拿掉，這邊應該就不會劃出來了，理論上是這樣子才對，所以好比像玄武岩的海拔是30公尺左右，你不認為它是一座山，你就不要把它列進來，更新你的資料檔之後，理論上就不會畫出來才對。

看有沒有其他想要討論的？

不好意思，剛剛是區域選擇的問題，我們還有進入申請的項目問題，因為登山基本上所面對的應該是民眾申請，因為進入保護保留區會有不同的申請項目，像原住民進入的活動，或者是研究區域的活動。

像這一些東西，基本上民眾來說，申請自然保護區、自然保留區，又或者是環境教育為目的，又或者是人員出入，自然保護區並沒有民眾環境教育的選項，只有人員出入的選項，目前是以人員出入來取代民眾環境教育的項目來提供選擇。

我們在這邊想要提出的是，既然保護區是可以做區分，進入選項是不是可以只限定只讓一般民眾的申請項目進入，就在一站式平台提供就好了，其他的選項就不需要在一站式平台上申請。

像研究的需要，像有一些區域，是希望民眾提供一些計畫報告，或者是相關單位申請的證書，這樣子就會牽涉到附件的問題，如果只有民眾的環境教育需要，其實只有人數的限制，所以我們想說在申請項目當中也可以做相關的調整。

所以你的意思是，你希望把你的API調到完全不需要附件嗎？你的目的是這個？

不是，因為不同的申請項目，申請人規則其實不太一樣，因為有一些是要抽籤，有一些不需要抽籤，我們希望能夠從一站式的申請來這邊的理由都是相同的，我覺得會對於管理的單位來說會比較有好處。

OK，所以簡單來講是原住民族祭儀跟學術研究，你不希望他們走一站式，簡單來講是這樣，雖然他們或許會經過山區，或者事實上也會有行程的安排等等，但你覺得這個定性上就不是一站式登山的使用者，是不是？我聽起來是這個意思，看這邊的想法。

我覺得這樣比較單純，如果林務局的廠商認為這樣也ok的話，申請的原因把它鎖住在登山。

至於其他可能因為學術研究或是原住民祭儀等等的話，就維持在原來的系統當中。

不過這樣的話就需要一個提示，假設真的是原住民族需要這個祭儀，看到這個網站也填了，發現沒有得選，至少要有一個東西告訴我說現在要做一件事，然後就回到那個網站去，您的目的是不是這樣？

是。

假設屏科大研究黑熊，他們也會進到玉山國家公園，可是在保護區那邊申請，大分那邊的山屋要如何登記？是不是比如學術研究的時候就要拆單了。

就不在一站式申請。

這是不是不給學術研究使用？目前是不是可以？

資拓回應一下，這個問題跟動態表單也有一些關係，像原住民申請或者學術研究，又或者是一般出入登山等等，這個選項在不同的保護旅遊區，其實項目也不太一樣，也沒有固定的欄位，所以我們先給申請單一個固定的值，其他表單沒有預設的東西，再跑出來。

所以我這邊應該要講的是，如果像這樣的申請程序，從一站式系統申請送到自然保護留區系統，這個本來可能就是以登山的名義來做申請的話，是不是另外一則，其實應該是那個API那邊，當收到這個API的時候，就知道是用一站式進來的，也就是自然保護留區系統應該自動把不必要的欄位就已經過濾掉了，一站式系統這邊相對就非常單純完成這個登山的自然保護留區的申請，以上說明。

不過以目前的情況，你會切換成學術需要的附件嗎？在一站式？

我們現在對於每一個自然保護旅遊區表單的欄位都有再調查過，所以相關必填寫欄位，其實在一站式服務網都會出現。

所以實務上，我不知道你們有沒有統計或者是現在可以看一下我們上線以來，是不是有人真的因為學術研究使用過這個建議？

學術研究，我們有資料、紀錄，會議上臨時沒有辦法調出來看，但是我們可以看另外一個紀錄，就是自然保護旅遊區的申請狀況，我們會發現，這一些學術研究或者是這一些研究人員，看起來其實本來就沒有選擇使用一站式服務網來做申請。

我們要確認這一件事，因為如果已經用成習慣了，你拿掉功能，永遠都是很悲慘的一件事，但是如果都沒有人在用，拿掉就比較沒有成本，很高興我們有這個機會先檢討這樣的一件事。

在投影出來之前，我的基本想法是，因為我們之前並沒有跟學術社群、原住民族祭儀社群公開承諾說給他們用的，但是我們也沒有說不是，我們唯一判斷是有沒有人真的來用，如果真的有人來用，我們就要理解到……您要說明嗎？

自然保護旅遊區，目前看起來最多人申請的是插天山，我們可以分析一下是哪一些類型使用者，用什麼名義來做申請的動作。

其他像挖子尾、紅樹林跟九九峰，這一些人使用一站式來做申請的次數，本來就很低。

好，我想就麻煩資拓這邊來分析一下，包含插天山、一葉蘭、挖子尾，這幾個是不是有使用原住民族祭儀或者是學術那一個部分的API，如果已經有使用者，而且已經告訴他的朋友可以使用，我們要把這一個部分拿掉，就需要很充足的正當性才可以拿掉。

如果都沒有人用或者是一個人用，你打電話給他就好了，這個是比較簡單的做法，所以我們在這邊先不決定這一件事，先看一下使用者認定這一個系統的功能有沒有包含這一塊，如果看大家覺得沒有包含這一塊的話，我們就認為可以按照自然保護區的需求，直接在資料描述欄位裡面把其他的需求拿掉，所以我們還是先分析一下。

國家公園是open的，如果要透過一站式的話，我們也ok，至於自然保護區的部分，就按照林務局的需求來處理。

OK。因為我們服務網是叫登山申請，所以登山10公尺確實沒有什麼正當性，但是學術跟原住民族祭儀，實際上是在登山，並不是沒有在登山，這個也要看一下使用者的期待如何，說不定未來會有各族語的網站需求因為國家語言發展法通過了，不過這個是以後再說的事情。

看其他有沒有要提出的？

不好意思，我講一下跟上面議題比較沒有關係的，還有會講到維運的問題；先拿這塊出來講一下，像資拓今年有做維運的客服信箱，相信到明年初的時候，有一段時間因為還不知道是誰來接；這一段空窗期是不是會有人來收客服信箱跟這時候的維運方式？

另外，今年一定會出的就是我們的API文件；想知道API文件到明年會不會有任何的精進方式，可以繼續來做處理？因為我們當然很希望大家透過API文件來做更好的加值應用。

最後，目前我們知道資拓是用營建署的主機，透過營建署的郵件伺服器來發信；當初我們想要做mail攔截這一塊，就是透過將原系統的信件攔截處理，然後全部改成從一站式這邊來寄信；也就是原本希望寄信的窗口是全部從同一間廠商來寄，這個需求目前看起來比較低，現在還是會從原系統來寄信。

國家公園這一塊，目前看起來是營建署的網域，所以實際上使用者不會因為是登山書寄，或者是營建署寄覺得不一樣；因此我想說今年雖然有拜託登山書這個功能，要不要開啟是另外一個議題。

另外一個還是講一下是關於附件的部分，像檔案上傳是上傳到一站式這邊，他們會有一些資料保留的議題，可能會有一些資料刪除考量或者是維護上面等等的問題；我們今年還沒有想要管這一塊，未來如果需要做整體方面考量，也就是配合資訊單位一些資安政策的話，可能在精進的會議就會需要一起討論這一些問題。

謝謝。一個個來，目前是客服的部分，因為走客服信箱的網域是營建署，不管廠商是誰，營建署都會收到信，接下來只是你們要給誰這一封信，看目前的規劃是什麼？

因為後續廠商維運的部分，沒有包含這個部分，在新的廠商承接之前，已經拜託資拓宏宇同意協助處理，我們儘量縮短招標時間，其他的部分就請他們來做。

非常感謝。

第二個部分是，我們現在API文件有任何的方式從網站上發現有API文件？或者是未來的規劃怎麼樣？

這個部分資拓說明一下，依照合約我們在結案時會交API的文件，目前的文件是用Word來寫，目前的格式亦follow API格式，另外也還是會把API spec與描述文件交付到營建署這邊。

至於這一份文件要如何做發布的動作，可能是看營建署這邊如何思考這一個問題。

不過這個倒不是任意思考，因為國發會有共通性應用程式規範，還是有依照規範的想法來做，那個規範其實已經有一個很明確的案例，叫做「交通部PTX」的案例，那個案例其實是放在HTML裡面有一個link，關聯是API，也就是「APIs.JSON」的方式，其實任何的瀏覽器可以讀HTML都可以發現這邊有API的說明文件。

以我的理解，國發會其實本來就有 schema.gov.tw 跟 www.gov.tw 的服務，未來也可以有API的部分。

你們跟社群互動是要放在github或者是下一個廠商都再說，我的意思是，不能完全不讓國發會的網站偵測工具知道你們有API的這一件事，是不是盡可能按照公共性應用城市規範第6頁的描述跟發現方式直接把API的文件掛在網站上，大家可以省力氣，不會只有交通部的案例可以用，也有內政部的案例可以看。這個技術上應該並不困難才對。

國發會有沒有要補充？

資拓會配合辦理。

國發會有沒有要補充？

好，謝謝。之前有說讓email的通知方是不是可以儘量用同一個網域的事情，當時是因為沒有代收轉發的規劃，幾乎要靠email的方式；營建署看未來代收轉發把拆單的狀況隨時讓使用者知道，email是一個人發或者是很多人發就沒有太大的差別，無論如何都可以連回一站式的查詢介面知道被拆成什麼單就知道對使用者是透明的；所以當時才會有email攔截的事，這個比較是跟使用者互動邏輯上的取捨，也解決讓使用者拆到四個單位，這個也是email可以知道的事情；這個是未來是否要看起來都是hike.taiwan在運行，email的發送方都是規格化會有幫助，看你們怎麼想，我覺得都可行。

具體的建議是，秉倫的圖片再show一次。如果下一個階段改善的時候，可以像秉倫這個建議的方式，像單一郵件的攔截跟發送的功能就比較沒有這麼重要了。

說不定還有誤導之嫌。我再講清楚一點，第一個，按照秉倫的建議，本來把拆單的這一件事就告訴有拆單這一件事發生的話，當然合理期待，也就是既然拆成這三個單，當然會分別通知我，這個是沒有問題的事。

或者是如果營建覺得下一個階段的方向是盡可能假裝這個是一個網站而已，就不要知道後面有別的網站了，這樣當然email放在同一個網域是有必要的，這建議把拆單的這一件事讓大家知悉，我自己本人覺得這兩個都很可行，都ok，所以是看你們覺得。

我們補充一下這邊想要建議拆單透明化系統的另外一個理由，因為剛剛說拆單機制，我們建路線資料庫、節點資料庫幫我們算出來，因為基本上工程師不一定是爬山的山友，所以不一定可以建出完全百分之百對的資料庫，所以拆單透明或許有一個機會讓他們回饋拆單是拆錯或者是比較不好的東西，因此才會想說讓拆單的這一件事可以讓民眾看得到。

我們來說明一下，我想個人的觀察，從11月1日上先以來到現在，一則是這個email代送服務做完以後，其他的廠商也要配合，所以目前的狀況就會變成在一站式申請完以後，像警政署或者林務局，又或者是國家公園一樣，還是直接透過原有機制來收送email，其實這一email代送功能，個人會覺得對於使用者而言，可能某方面會覺得一站式服務網真的有一些便利，真的幫他代送了這一些單位，而且這一些單位真的有資訊做處理的動作。

所以這個是時程的關係，因此這一項工作雖然還沒有做的很完整的程度，但是會覺得目前這樣各自系統發送email的呈現方式好像對於使用者也不是不好的體驗，以上說明。

就是尚可接受，聽起來是這個意思。

我們也沒有必要一定要在這裡做出決定，但是我們要理解到這兩個是連動的，這樣就好了，如果拆單透明化，未來這個方向，email就各自送各自的，如果拆單透明化不是好的方向，email就要攔截，並且從這邊收。

最後是附件上傳，不過這個跟資安、個資保護都有關聯，不管是拆單都有這個問題，如果要代收轉發的話，資料都要存一份，不管是不是要上傳附件，除非上傳特種的醫療等個資，但是上傳的時候好像沒有要上傳這個東西……嗎？所以個資保護層級，無論如何都是相同的，我只是要講這一件事。

個資法只分兩級，一個是醫療等特種個資，一個是識別到一般當事人的部分，就算沒有附件，第二個部分也跑不掉，這個部分是相同的。

所以剛才聽起來的意思是要保留多久、資料保存的資安要求，我覺得附件是不是上傳都有類似的要求，而且現在以我的理解，硬碟的成本滿低的，所以我也不會覺得有一份附件是放在一站式裡面造成很大公務營運的負擔。

只是他當然要很明確告訴使用者是個資隱私、資安保護等等是如何，當目的消失，也就是真的爬山了，我們就可以刪掉，至少在一站式這邊，因為蒐集的目的已經完成了 。

後端有個子資料保存及合理的需求，這個是資料保存的policy，一站式是到這一件事申請完成，而且登山已經發生了，之後像申請是登山的最後一天，也就是12月29日一過了之後，我到12月30日就沒有留這一些附件的必要了，按照個資法使用目的的精神，當時就不必要保存了，在此之前保存是合乎目的，也不會有人從個資法挑戰你，我想就往這個想方法。

看大家有沒有要提出來的？

我再提一下有關於資料結構的東西。剛剛有提到這兩個設計，也就是我們用這樣的方式紀錄，也許可以從歷來申請的路線再找出一些熱門的路線給使用者。

剛才這邊。

我要問的問題也跟這個有關，因為林務局各管處在審核資料，其實很重要的一個因素是，他們審核民眾的申請路線，但是現在申請路線，好像是由林務局這邊提供給平台來做節點的拆分，跟我們這邊的系統其實是沒有做關聯性的資料交流。

我會問這個問題是因為各管處在審核資料的時候，會看民眾進入的路程，但是因為現在路程是由林務局這邊提供給平台來做拆解，平台那邊是用串接的方式再送過來，如果這個路程林管處的管理員沒有問題，審核通過是沒有問題。

但是當這個管處裡面有幾個節點是關閉的，目前沒有機制是到平台這邊通知，只有說送出來之後通過，然後我們審核不通過，只能走這樣的流程。

像有一些路徑，比如羅東林管處明年有一些區域是關閉的，雖然是只有一個部分的區域關閉，但是在我們的系統上只有看到資訊，在API裡面大概會把資訊放在裡面，但是如果以這一種路徑的結構方式，好像沒有機制回饋到這裡面，所以我想要問一下這種節點路徑的管理方式。

你剛剛提到的是節點，而不是路線，這個關閉是好幾個節點，你要繞道而行之類的。

實際上我不太清楚，但是就是子區域不讓他進去。

但是你們那邊關閉的時候是用純文字發布而已，或者是在你們的資料結構裡面會反映到他關閉的這一件事？

基本上我們的選項裡面就會把它關閉，然後在公告裡面也會這個區域不提供申請。

但是在你們的資料結構裡面關閉的狀態，所對應到的是一個節點，也就是一個區域的描述，或者是一整條路線？又或者是都有？路線不能申請、節點也會關閉？

節點是文字性的描述，但是會把路線寫在附註裡面。

這樣子我有聽懂。看秉倫要不要補充？

我要補充一下，目前我理解的狀況是一個子區域可能會有二至三個節點，其實或許如果真的關閉資訊，也許一站式可以做一些檢查機制，也就是在申請的路線當中，不可以有比如像某個子區域，像A至C點，我們在檢查申請單的時候，如果裡面有A至C的點，就直接在檢查當中說不通，就不會有送到林務局去，然後有再被打槍的問題。

我們來說明一下，這個應該算是許願池，我們這一期主要的重點在於申請的動作，但是有一個部分是，在申請當中，不只林務局，像國家管理公園也很多，像是山屋營地的狀況不好，比如缺水等等的狀況，這一些會影響到登山的人要不要用山屋來登山，但是這一方面的資訊，因為是動態資訊，目前沒有所謂的回饋機制。

因此現在都只能先讓他申請，申請完以後到了後端，也就是說申請不符回來，原因是某一個營地出了問題。

所以將來有一個機制，將各個系統可以把這一些狀態回饋回來給一站式服務網，這樣對於使用者的查詢跟決定路線申請會有相當大的幫助。

這個跟欄位調整是不一樣的議題，如果一個議題要關閉，在此之前常常會知道要關閉，這個是預告的作用。這個預告就變成一站式的角度來看，在這一段時間申請的時候，就不讓他申請，而不是從今天開始就不讓他申請，雖然會收到今天關閉的訊息，因此這樣看起來節點到管理單位的部分，這個圖上的左側，至少要有多加一個set，也就是從這個管理單位來看，未來幾號到幾號，而且這個還有多個，這個會關閉，然後他的說明會如何，也就是這三個欄位附加的表格要掛上去，才可以在這邊反映未來申請這一個地區的時候，才可以有比較讓人看得懂的錯誤訊息，讓人家看說為何需要調整，並不是單純說不行而已。

現在是說給出的API裡面，有這一種屬於預告式的，未來幾號到幾號的節點會關閉的這種描述，也就是公告結構化。

關閉的資訊並不是公開的資訊，像部分的區域停止申請日期有哪一些，子區域可能不能被選擇，也就是選項是被關閉，資訊會寫在附註的下面，但是其實是網站用的，並不是給一站式平台。

還沒有到結構化。

沒有真正結構化的項目。像到時要配合雙方資訊交流的話，應該是我們這邊也要調整，一站式那邊應該也要給我們一個標準，也就是應該要怎麼樣來調整這一件事。

另外，其實我們並沒有節點的概念，我們是一個區域，為了館處的管理方便，所以只有一個路線，也就是以區域來選擇。

對，我剛剛聽懂了。

怎麼樣從區域的概念跟一站式節點的概念來串在一起，管理方面不會我們做出來的東西不符合一站式的需求。

這個我理解。像剛剛提到奇萊南峰跟南峰岔路是要在同一個會議上做確認的工作，一個是你們目前是未結構化，是給人看，並不是給機器看的預告資料，在這樣的情況之下，一站式除了目前做法之外，也沒有別的可以做的，因為沒有別的結構性可以運用，除非是寫自然語言的機器，但是這個超過標案的金額。

第二個，但是在未來也許把圖景點的部分同步化，或者對應到不同的系統，像區域跟路線不同路線的時候，要做總的盤點，就可以當作未來非結構化訊息的參考，而且因為在當時，大家都已經約定了，所以只要用這一些欄位名稱結構化，未來當然就可以藉此而調整，所以順序應該是這樣，以我的理解。

感謝大家的貢獻。

我想要回到剛剛email的討論，我滿贊同政委所說的，我們在一站式申請的時候，其實我們要保障的服務期間其實一直要到下山為止，我想要補充說明一下，當然這個呈現申請資料的方向很好，代收email的部分，我會覺得不是非A即B，並不是兩個極端的方向，應該是可以並存的方向。

我舉一個可能會發生狀況的部分，像假設申請一個單，也許警政署的入山就下來了，某些原因山屋沒有抽籤到，這個申請會被拒絕，所以email是分開來送的話，我拿到警政署的入山許可了可以去，但是後來才發現沒有辦法去，如果我們有這樣的email的代收機制，經過更多的設計及思考之後，也許可以避免使用者會有這樣的疑惑。

她的意思是這個設計空間很大，並不是一個維度而已，兩端的綁住當然是兩個極端值是如此，但是很可能可以設計出更新維度的狀態，讓使用者一方面可以更清楚，二方面也不會造成系統管理上的麻煩，非常感謝皓婷的提醒。

看大家有沒有要提出來討論？

接下就麻煩營建署在協調會議當中，把剛剛所提出來的這一些意見看能不能定期跟各個機關的窗口來做對齊的動作，如果有任何需要行政支援的話就跟我們說，如果需要秘書長裁什麼的話，就提到那邊的會議。謝謝。