今天謝謝大家來這邊討論整合平台精進措施的會議，今天如果大家來過會前會的話，都會知道我們會做逐字紀錄，但是這個逐字紀錄充分編輯之後才做，今天感謝景森政委辦公室來跟我們當共同的主持，整個山岳整合平台，其實是五大主軸的一個部分，其他的主軸目前正在如火如荼進行中，這個總盤整還是景森政委在負責，今天就技術可行性的部分來做很明確的對齊工作，也很感謝葉寧參事幫忙處理之前會前焦點的會議，先請葉參事跟我們分享一下討論的進度。

大家都參加過前面兩次會議，知道9月6日要開協作會議，登山申請平台是五大政策主軸中「資訊開放、簡化申請」最重要的項目，協作會議目的希望蒐集山友的意見，或者是跟他們一起想想看有沒有更好的方法，但是像我前幾天也跟各位講過，對於行政部門來講，我們確定要改這個系統，因為我們已經收到非常多不同的抱怨，讓系統變得更好的這一件事，不管是民眾的意見提到什麼程度，盡我們的能力在最短的時間做到最好，特別大家參加過院長主持的會議，院長非常強調他並不是用月或者是年來計算工作時間，而是用天來計算工作時間，我們會希望儘量在政策目標下，能夠盤點清楚我們現在的問題以及我們可以改善的方向，以及我們也有多少資源可以用。

前兩次會議碰到一些事情，不好意思，個人主持能力不足，所以麻煩政委來主持。第一個，我們要確定以我們最短的時間之內，讓民眾有感的資訊系統改善，改善內容大概是到什麼程度，如果是在這樣的內容之下，可不可能在最短的時間之內完成，比如廠商希望有四個月，如果再加上公文期程，像我上次聽得沒有錯的話，營建署提到要兩個月加四個月，等於是六個月，我們覺得不太可能，如果各位開過院長會議，都希望一、兩個月可以完成。

我們剛剛說跑公文要兩個月，系統要改四個月，很難符合期望，我們就不用談要不要跟院長要錢的問題，所以第二個當然要搞清楚在那樣的情況之下，我們要花多少的時間來做完這一件事，然後需要什麼資源，這個是大概的情況。

話說回來，第一個部分如果沒有先對齊的話，各個系統的掌有的機關，到底要改到什麼程度，可能沒有一個清楚的概念，當然也無從去估算那個時程跟可以做到什麼程度，還有要花多少的資源，今天的會議其實是請政委能夠親自主持，希望這幾個部分可以對齊，希望在會議之後付諸行動。

其實不是主持能力的問題。因為我們通常跟廠商朋友們討論的時候，我們也知道大家都會想要把實際的功能，做成一個比較穩定可控的版本，但是因為我之前是敏捷開發的教練，我的工作就是協助大家還沒有做好的版本，就先上線看看，讓一部份的使用者測試。

上線之後，就會有一些朋友們說來參加協作會議、參加登山諮詢會議，拿到先期測試者的資格，拿到這個資格之後就會碰到各種各樣的問題，但是覺得因為是選民，也就是被選中的人民，所以這個時候就不會罵你，就會坐下來把系統改得更好，像在報稅軟體案、健保卡虛擬案、故宮票務案都是用同樣敏捷的方式來規劃這一件事，所以簡單來講，我們以前在做風險控管的時候，都是覺得說不要被罵，只要一、兩個人被抓出什麼問題，這個是困難跟風險。

但是如果採用敏捷開發的話，是不是直接說closed beta，某些人先用用看？「我們知道一定很爛，但是你的關心會變成我們的助力」。我想這樣子的做法對於大家實際業務上的付大也可以比較減輕，增加的大概是政治上的負擔，政治上的負擔反正我吸收，有問題都是唐鳳的問題——我是說資訊上，不是別的——，在這樣的情況下，大家工作的空間會多一些，以上是這一次主持的想法。

剛剛葉寧其實很明確講了兩件事，也就是紅底的這兩件事，第一個是我們的後端無論如何就是要做整合，不管我們在協作會議，也就是前端這邊，大家繞著發想、腦力激蕩，做了多少了不起的規劃，這個跟後端的關係沒有什麼，後端就是要整合，沒有什麼好講的，這個是第一件事。

第二，誠然2020年3、4月可以做出比較完整的版本，但其實我們的拘束力結構，就是院長打算在10月有一個對外的公開宣示，說全國最大登山平台上線之類的，這個時候我們必須已經有一些東西讓大家可以用，用了再建議更多的，這個非常好，我們也瞭解到大家需要時間實作，但是並不能說我們什麼都沒有，就問大家說這個要不要、好不好等等。

按照院長在上次會議的發言，就是說「早餐店不應該去問人家要不要荷包蛋，而是要問一顆蛋或者是兩顆蛋」，因此在2019年10月要把第一顆荷包蛋做好，這個是政治架構。看宗諭要不要補充？

差不多講完了。

承襲上次會前會的脈絡，假設2019年10月就要把這個整合做到一個程度，大家會實際上碰到的，包含行政上跟技術上的挑戰，是不是可以先有一個對齊。

行政上，我先講一個實際上跟院長及部長們提到的概念，我們中央的機關，也就是各部會，只要部長同意，任何100萬以下的招標都可以比照10萬以下的招標，也就是沒有工程會或者是其他還要敘明理由等等，只要部長或者是主委簽了，95萬就可以當作9萬的採購來辦理，這個意思是可以省去一個月的行政程序，這個是第一件事。

但是接下來當然有兩個問題：

第一個是我們去做各位現在手上維護的平台，API的整合讓它能夠做一個讀寫的介面，第一個是95萬是否足夠？第二個一個月內可以爭取到，對每一條線95萬，這樣子有沒有可能在2019年10月就把這樣的東西上線，不管API長什麼樣子？這個是時程跟金額上要詢問的問題。這是第一件事。

第二，假設大家覺得現在正在維護的網站，沒有辦法用這樣子很像急行軍之類的方法來改造（Plan A），那就是考慮第二個狀態（Plan B），也就是有沒有可能大家現在既有的網站，對於我們在國發會特定的機房過來的一些IP，保留現有的路徑，就不要再去改版了，接下來一年只要從這個IP過來的，本來現在是長什麼樣子就是什麼，可以加一些新功能，但是這一些IP過來的，就會看到舊版的網站。

看到的時候不要有一些測試是不是人類的這一種captcha東西，這一些機器人，這個是代操，也就是代使用者操作你們的網站，這個要如何跟前端整合，這個API會要求新的廠商，如果plan A走通的話，我們會要求把這一段，不但是開放原始嗎、API及文件，以後是可以合併進去的，而且也會希望在機器人代操作的設定上，同樣也跟剛剛要求在90萬之內、一個月之內完成。

所以大概對於每一個我們後端要接的網站會要請各位做這樣的評估，也請我們的公務同仁評估一下，假定跟錢、時程，廠商們覺得沒有問題或者是有問題找到備案的話，在行政程序上有沒有什麼我們沒有考慮到的，讓我們知道。看葉寧有沒有要補充的。

剛剛政委提示的，我們可能要一個系統的時間點，我的理解是國家公園應該是一個系統或者是三個系統：林務局的部分有山屋，我不確定這個算是三個系統；另外一個是林務局的自然保護區；警政署是一個系統。

體育署是要不要把即時資訊整合進來，跟申請是沒有連結的，那個我會建議最後處理，是不是以這樣的方法，我們還是從營建署開始，然後林務局、警政署，我們逐一就剛剛政委所提示的部分來做盤點。

不好意思，營建署看是公務同仁發言或者是誰發言？因為有行政面，也有資訊技術面。

我想營建署這邊，是不是請廠商就技術跟經費面來就唐政委提到的部分先說明一下，後續行政需要處理再補充。

各位委員大家早，我是營建署廠商天眼李勇慶。請問IP接進來是接data base？

不是，如果database願意有一個view分享出來的話，我們只要看那一個view，如果view不分享出來，甚至只要保障網站介面不要改，我們就砍站、寫機器人，這樣什麼都不用改，其實你只要答應不改就可以了，這是最低的要求，這個是plan B；如果你願意寫API，當然資料庫開一個view或者是寫一層都是可以的。

因為民眾山友的需求很多，所以廠商會異動，因此開database的view給你，這個也沒有問題，包含table schema部分出來，這個理所當然，這個也都ok，可是剛剛唐政委提到我們的山屋管理處，因為山友討論之後會做一些政策的調整。

像今年度我們在調整的時候，山屋管理處有一致性，我們開view給你之後又變了，結構又不太一樣，我一沒有跟你講，你一介接，機器人抓資料一定是錯誤的。

所以如果是plan A我們來做的話，當然是我們最快，如果改欄位，我們加上去，前端整合網帶走，這個就沒有問題，但是時間上我還是真的有疑慮，因為坦白來說，我們廠商到這個年底，我們還是有一些公部門的案子，也是在執行當中，這樣會形成排擠效應，本身像我們是這邊是PFT PMI的證照，我們也知道這時的風險我們必須要去考量。

技術上坦白來說，之前已經講過了，技術上我們都沒有問題，但在於時程上這是我們最大的疑慮。今天唐政委有提到，因為院長說兩顆荷包蛋，至少10月底生一個茶葉蛋出來，我覺得這是今天會議上最重要的結論。

我綜整一下我聽到的，Plan A是可行，但是你們同時有別人的客人點早餐，所以其實年底是比較忙的，團隊要去煎蘿蔔糕之類的。

但是到了明年，如果比較緩過氣來，經費也充裕的話，對於Plan A好好做出來，這個也是支持的。也許Plan B的情況，也許我們在這個系統裡面，請您提供兩件事，一個是從這個IP網段來的，就不要改介面，甚至你給我們一個特別的path，這個路徑是只有這個IP可以來，就是一直運行舊版程式，你知道我的意思嗎？這個並不是一定的，而是等你有空的時候，你再把它弄回來。

這個一定可以做，因為這個是不做什麼，不是讓你做什麼。Plan B只是不要對那個路徑更版，這個是第一件事。

我聽得懂。

第二件事，我們這邊會請現在的這一個暫時廠商，就是快速煎蛋的廠商，把這個東西進可能整理成API的文件，自己省掉一道API的公序，用PMP或者是最好的方法來確保它的完整性、資安、API管理等等，我們之後就放到Plan B來進行，我們切成先後兩個來做，這個很清楚。

看公務同仁有沒有要補充的？

不好意思，我有一個疑問，前端頁面的設計要怎麼來做處理？因為這部分確實我們資訊是比較沒那麼充足的。

前端會對這一台綜整的機器作業，由它來連結這一些後端。

這個前端會長成什麼樣子，這是大家可以一起討論的，這是協作會議的標的。

但是它的功能怎麼樣，這是我們目前現在各位的後端所能夠做的功能，理論上在你們本來的網站上可以做到，在這個整合的地方就應該要可以做到，概念就是這樣。

所以前端的整合網是找另外一個廠商來做？

當然如果有人很想做前端整合網，因為95萬之內就免評比，如果在場有人很有意願做的話，這也是可以討論的。

目前如果以營建署還要再處理前端，還有包括剛剛所講的後端，這可能還是會超過100萬。

那是兩個100萬，前端100萬，然後這一條線再100萬。

可能還是超過100萬，有一些公開評選程序。

不會，這是兩個標啊，真的啦！

這是兩個標，不是開玩笑的，因為它的工項不一樣，互相也沒有依存關係，你先寫哪一個、然後再寫哪一個絕無差別，工程會不能找你麻煩。

因為我們要會到主計、政風。

是，這個沒有問題，我們寫意見書給你。

另外一個疑問，之前整合平台其實已經有用過100萬以下的限制性招標了，所以同一個年度又另外起一個案子做這樣的事情，也是會擔心後續審計部來查，變成逃避採購法的可能。

所以你的偏好是由別的⋯⋯但是審計部是整個查，這根本沒有差別。

哪一個得標廠商不管，會覺得同一個案子，為何會拆成兩個90萬的案子在做處理，他們會有這樣的疑問。

我們這邊可以先做兩個處理：

第一，也許我們先新上線的這個，我們叫做「一站式服務網」，跟現行「整合平台」有一個最大的不同，整合平台基本上是我們所說的出口網站——反正是進去之後又出去的網站——這個大家都非常清楚。

「一站式服務」是一進去不用點開任何網頁了，在這個網站辦好，所以第一個招標工項的大標題不一樣。

第二個是我們把網址弄到不一樣，我們在封閉測試的時候，也就是剛剛所講的一些先行者們，願意山屋還沒有完全蓋好就來爬了，我們給他一個網址，而且網域也不會在你的署底下，所以標題不一樣、工項不一樣、網址也不一樣，這樣子如果審計部還有一些疑慮的話，那沒有關係，我們也是可以寫一些意見書出來。

因為政委在很難得，有問題就問。

對，我也可以用廠商身分回答，所謂「政委自帶廠商」（笑）。

不管是科長的問題，像署裡面的同仁有問題，包括PDIS同仁有問題，因為政委在，就儘量確認一下。

如果各位覺得有需要，對你們工作有幫助的話，我們是可以考慮這一場會議直接給你們書面紀錄，讓你們比較容易做。

第三，如果經過這樣的會議，大家都確認沒有問題的話，就不要再等了，像你們覺得一定要跟主計室好好談一談，麻煩趕快跟他們談一下，像按照政委的說法，主計室是不是就ok了？我們不要等到下一次的會議再確定，我們希望時間上儘量趕上，有需要再問就儘量提。

不好意思，我是林務局山屋的廠商，因為我們現在三個山屋都有會員制，所以同一個領隊帶領的隊伍，其實在重複報名的時候，其基本個資是不用重複填寫，是把每一次的隊員填上去就可以了。

我現在聽起來的感覺是，整合網應該會把整個隊伍每一次都會拋給我們，我當成一個訂單，我先說明一下現在的做法，是會員註冊好、登入，然後開始key隊員，然後產生一筆訂單，然後進入到虛擬帳號，看用虛擬帳號繳費或者是用線上刷卡來繳費，要先抽籤後繳費，繳費完會有修改的機會，也就是人是可以臨時不去，是可以取消，然後會造成退費的問題，也就是刷退的問題，然後會產生床位證給他，他就帶著這個床位證去山上，整個流程是這樣做。

我必須要開另外一個通道，讓整合網可以拋隊員過來，跟現行的會員制是併存的，是這個意思嗎？我想確認一下。

先回答一下，這個流程跟我們之前做報稅軟體還滿像的，只是報稅軟體不用抽籤而已，大家都得繳稅。

基本上這個狀態就看是Plan A或者是B，其實Plan A的情況，你可以想成你的使用者沒有辦法操作瀏覽器，必須要是像類似google這一些，也就是純粹用機器對機器的方法來進行溝通，這樣子通常最簡單的方法是你把自己的架構，我不知道你用什麼技術，像如果是「ASP.NET」，就可以生出本來服務的web API出來，現在也已經可以生OAS 3的規格。

早期一點的話，可能用的是swagger或者是Apiary，你等於是提供一個現行功能機器可讀的文件，轉成新版OAS3而已，重點是結構化的文件工作。

這看你網站的設計，如果你的網站設計已經是前後分離設計，你在前面是已經用了React、Vue、Angular這些東西的話，你本來就有一個接到前端的那一些地方，只是你可以隨便改，而且沒有文件說明而已，這樣在Plan A裡面，只要生出API文件，現在國發會全部都用OAS 3了，也沒有什麼別的選擇，雖然我自己比較喜歡另外一個API Blueprint，但總之大家都用OAS 3了，假設本來網站就有RESTful的能力的話。

第二個方法是，你本來前後端都寫在一起，本來沒有前端的程式庫，而是後端每個頁面重新畫一張HTML出來，那如果走Plan A出來，就要畫結構化資料出來。這個有兩個方法：一個是在HTML裡面嵌像JSON-LD的這種東西，反正是有機器可讀的部分跟人可讀的部分，這個是常見的。

另外一個是給我一個endpoint，像我們逐字稿的網站，大家都知道當政委之後，開了快1,000張場合，還有跟4,000多人，講了20萬句話，裡面每一場會議，我們處理所有的從一開始我們去討論救災的網站，救災的網站我們在進行討論的時候，其實我們也是從跟廠商的對話開始，在這個對話的過程中，每一個人都可以看到每個人到底講了什麼東西之類的。

在這個過程中，我們有一個給前端看的部分，網站架構其實並沒有API可言，就是把這一場對話畫成HTML，然後給使用者，把它顯示出來；但當時還有雲辦的時候，是在雲辦開的，當然大家都一定程度匿名化，我們知道誰是NEC，誰是中華電信，沒有姓名。

但如果現在要做一個像剛剛Plan A的東西，在 網址 後面加一個「.an」，忽然間包含可輸入部分、可輸出部分等等，總之就會給你一個XML檔。

所以要看你目前網站的架構，如果可以有一個XML或者JSON額外的endpoint，這個是一個做法，你生HTML可以嵌結構化資料進去，這是一種做法，或者你的前端本來就是用前端框架，把你的API寫好文件，也是一種做法，Plan A目前大概三種。

當然有很多其他比較尖端的，像GraphQL，但是這個我們就不講了。這樣有大概說明了嗎？

我是聽懂了，但是變成像繳費跟刷卡刷退，也是要透過API再幫整合網跑一次？

當然，本來就會跟臺銀，就是透過它的API，就是瀏覽器忽然彈出視窗或內嵌，然後回一個訊息碼給你，一定是長這樣？

是。

這邊也是一樣。我們從web API的角度來看，你到這個情況下，然後給我一個payment required，這也是一個status code，然後你給我一個location，然後一個call back，或者一個web的網址，反正這一些OAS 3都有，所以如果是API的導向設計，這個節奏，OAS 3是可以描繪的，Swagger還不一定有辦法。看展銘要不要補充一下？

不好意思，我補充會員制的部分，因為你們目前有會員制，如果要簡單的做法，我訂單給你的時候，你就用個資去查詢這個會員是否有存在；如果不存在，就產生一個新的會員編號給他，諸如此類的，如果要並存就是這個解法，如果沒有的話，就是把會員制拿掉。

在這個網站過來的話，可以有兩個選擇，一個是立即幫他變成會員，一個是產生另外一個會員，也就是中間的轉銜期，就有點像Plan B，有另外一個伺服器來幫你預先註冊會員的功能，這個完全是看你自己寫，還是別人寫，如果別人寫，勢必要走到Plan B的解決方案來做，如果是你自己寫，當然有所選擇。

理論上目前會議節奏還在營建署這端，但因為林務局同仁問的問題是大家的問題。

這個問題是所有廠商都會需要面對的。營建署的廠商有沒有什麼問題？沒有的話，就正式進入林務局這邊，像公務同仁在採購上有沒有問題，或者行政作業上有沒有什麼問題，還有廠商在資訊技術上有沒有什麼問題。

林務局報告，這邊是公務單位的同仁，我們的廠商今天都來了，他們現在還在思考政委所激蕩出來的話題，我們先說明採購100萬以內的部分，我們會在行政的作業上儘量促成，所以我們的經費也會自己去尋找，所以這個行政作業不用擔心，唯一的部分是我們要去理解會請廠商帶回去評估10月1日會做到什麼樣的程度，還有也想要知道是10月1日⋯⋯

我們現在看起來是10月15日，你們抓10月15日，當然10月1日前端必須要開始測，也就是前端雖然大家都橋接上了，但是那個使用者體驗，像我們所說的拉皮必須要真的接上才可以，所以這個工項當然趕一點，一個禮拜也做完了，所以大家要有10月初有一個雛形版本的想法，但是如果真的讓Alpha tester可以用的話，大概是10月中左右。

大家好，我是保護區的維護廠商，我有一些問題需要釐清的是，因為我們的保護區系統其實是由林務局這邊所統籌，但是管理人其實是各個林務單位，還有一些地方政府保護區的管理單位，所以後台的管理人其實是滿多個，以至於我們在表單設計上來說的話，會依據各個不同的單位，他們去調整申請的內容。

OK。

為了因應這一種方式，我們在申請的頁面時，會從後台去把那一些管理人的設定成一個可以生成頁面的設定檔，想要問的是，如果以採API的方式，這個問題可能會比較慢，需要API對接的廠商去理解生成的申請設定檔，而且是必須要把必填的欄位來填滿。

如果是Plan B的話，我們沒有辦法控制各個林管區申請的需求，因為他們可能會依據他們的業務需求來調整他們的欄位或者是調整金額的東西，所以以Plan B的話，我們沒有辦法保證網站的架構是相同的。

不過我想先釐清一下，我聽到的是，大家可以客製化在不同的區需要填什麼欄位才可以進入，但是他的控制權是多到可以改變一個同名欄位的資料結構，還是其實只是不同欄位，有一點像抽換的方式來進行，這兩個是很不一樣的，同名欄位資料結構是可以修改的，或者是enum，我這邊1、2、3，他那邊4、5、6的話，當然我們在API的設計上會碰到一些挑戰。

基本上我們申請的區域是有法規固定要填欄位，像申請的區域、申請進入及離開的時間，還有活動範圍，但是還有部分像行程或者是申請目的，或者是災難的處理方式，這一種東西是額外的欄位，我們提供的彈性其實是給各個保護區給申請的人提供哪一些東西，所以像那一些欄位會封裝成一個結構化的資料放在同一個欄位裡面，在底層資料庫裡面會放在一個欄位，也就是申請縫的欄位裡面，基本上我們的頁面設計是只要有欄位都是使用者必填的，這是基礎的設定。

所以遇到這樣的問題，如果以API提供給外部廠商去存取的話，就需要他們去解析我們的申請設定檔的項目內容，才能對應給我們需要的資料，這個是我們對於API方案的要求。

不好意思，我先確定我有沒有聽懂，所以這個是類似資料建模的發現，當他發現你這個欄位有所更動的時候，並不會回溯到前面的申請，而是從你改了這個欄位變成多一個欄位要必填的時候那一刻開始，以後要填的人要填，前面的人在資料庫裡面是空的？

對，

如果本來必填，後來發現沒有意義想拿掉，但是舊的沒有消失，等於新的不填、是隱藏起來，所以在資料模式上是不斷累加，只是有一些會藏起來而已。

這樣當然是滿容易處理，因為這樣聽起來像欄位名稱是地方保護區會有一個單一的代碼，所以自己加的欄位可能是它的代碼01-F01、F02，無論如何是累加，不會利用那個欄位編號，這樣的話，其實不管是走Plan A或者是Plan B，這個是非常容易處理，只要保證剛剛講的是不會回溯適用，不會一個現在叫做「行程目的」的東西，你用這個編號，然後莫名其妙改一個名字等等，這一種API inconsistency的情況不要發生。

這樣的話，其實只要保持繼續同樣的做法，我想外部API廠商當然可以來解析你的模型，因為對他來講，就是要使用者填一些欄位，這個當然是ok的。

另外一個問題，他們在申請保護區的時候，需要提供一些外部的附加檔案，這一種外部的附加檔案是由廠商來提供或者是我這邊也要去建一個API跟廠商對接來取得相關的資料？

對你們來講，怎麼樣比較簡單？

對我們來講，對方提供申請的資料輸入的資料結構裡面，有帶使用者上傳的連結，我這邊就可以處理了。

所以我舉一個例子，像現在是一個外部廠商，然後他給你的，你不希望他丟blog給你，而是希望丟一個網址給你，這個是上傳的類似欄位，只是檔案暫時放在這裡而已，但是一收到之後，會自己放一個附本來這裡，因為你的資料庫要存。

但是這個檔名是一致的，像我們用uuid或者是什麼東西，對你來講，其實有另外一份放在中介的廠商，這個事情你並不是真的很在意，技術上也沒有什麼需要修改的地方，而且這樣子還有另外一個好處，就是你這邊也有一份，真的發生什麼事情，還可以看你的log，是這個意思嗎？

對。

好，我們就這樣處理。

第三個問題是，因為到目前為止只有討論到申請的部分，但是整個保護區的申請流程是連續性的流程，關於審查的部分跟民眾抽籤的部分都沒有討論到，我想問的是，當民眾申請完之後，在各地的林管處說這個使用者要修改等，或者不允許進入的時候，這些資訊也是在新的平台嗎？

請問目前是用拉取回來看自己的狀態，或者是會用推送的狀態會主動告訴他？

基本上我們的申請程序有五個階段，除非有一些地方申請是需要抽籤的，會發送他的狀態怎麼樣，然後再請使用者依據連結回來看申請的狀態，或是審查人自動發信跟民眾講說缺少了什麼，然後再請民眾到系統上去修改申請的狀態。

所以走的是SMTP，並不是走簡訊或者是LINE？

沒有。

如果是純SMTP的話，非常好，因為中間這個機器也可以是SMTP server，先寄給我們，我們收到再寄給使用者。

從我的角度來看，你們改越少行越好，當年有留一個email，也許我給你的，其實就會是長成好比像mail叫做「 [email protected] 」，這個隨時都可以用，是這樣子。

但是這在中間這一台裡面轉成UUID，這邊看到的其實會變成一個完全一樣的，好比像「hike+7F76FC98-B535-4B90-86C7-0F2AC8A52F2E@…」，這邊就uuid，然後後面一定是「….gov.tw」，所以來你這邊申請的是，透過新系統的人是長成左下角這樣子，所有的程式都不要改，照樣寄信，我們當然就得來剖析這個信了，所以後面@是這樣的話，信的格式就可以改。

這個地方倒是沒有什麼太大的問題，想要詢問的問題是，審查的部分，像林管處可能對使用者要求需要補件或什麼，如果倒回原本的申請畫面？

補件也是透過email嗎？

不是，是到申請流程有一個key，然後再用這個key跑一次。

我怎麼知道要補件？

會用mail跟他講。

所以還是email，因此我們中間還是會知道，當你需要它做什麼事的時候，中間這邊一定會知道。

但是審查的操作介面是在新的系統上嗎？

你是說補件的介面嗎？而不是審查員的介面？

簡單來講，就把這個當作無障礙設計，明眼人能夠用的，盲人也可以用，你用的東西是flash，盲人真的很難使用，必須做出簡單版，讓盲人也可以使用，機器是一種盲人，所以你的補件這一件事，如果它是在介面，如果我們走Plan B，你這個介面不要動就是了，我們自然會有另外一個虛擬補件介面來操作你的實際補件介面。

第二，如果要走Plan A的話，你的補件介面，就生出一個相應於在網站上能夠操作的API，也是用OAS 3來描述就好了，所以大概是這個意思。

我想提出的是，我們這邊不只是要做一個申請API，還有一個審查的部分。

基本上使用者在你這邊有做的操作都做，應該是說沒有任何的遺漏，不要說有哪一些東西忽然間又跑回你們家再操作，不如一開始點開四個視窗，就像現在的整合網一樣。

最後一個是查詢的問題，因為我們在系統上還是有一些比如使用者要申請舊的申請紀錄或者是一些抽籤的申請紀錄，這些應該是這個是做固定上的介面，並不是像剛剛申請介面這麼大的彈性或者是結構化的東西。

有可能我們最後要做的是Plan A跟Plan B一起處理，他可能會花掉更多的時間，到最後還要轉共同的系統。

應該要這樣講，如果你的查詢介面相當老舊，然後你要走Plan A，就把那個database轉出來就是了，不要畫那一頁，有什麼資料就吐什麼資料，這是最簡單的。

如果這都要做Plan B的話，很命苦的中介廠商就要爬HTML資料，然後想辦法還原成結構化，可是即使是這樣子，應該也可以做得到。

但如果我們10月中這個系統還不完全能夠上線的話，當然我們未來可以再把這個做得更豐富，但是我想從爬山者的角度來看，我以前爬過哪一些，這個系統還是會需要的，因此我建議規劃的時候就規劃在裡面，但是確實上線節奏是可以放在稍微比較後面一點，大概是這樣子。

所以我們10月的目的是讓使用者可以申請？

可以申請、查詢，發生事情了，可以通知他，抽籤中或不中，就是可以完成一個流程。

最後一個問題是，除了一般的民眾使用外，還有一些不是管理者的權責機關，比如像各地的消防隊。

他們用慣了，不要打擾他們，後台的部分，你打擾他們，我們不能做一些便民的事情，讓大家省一小時，讓不幸的公務同仁多花一個小時，這樣的改革絕對不會成功，所以大家用慣介面就用那個介面，現在只是說山友並沒有覺得點開四個頁籤是大家習慣的頁籤，事實上他們用的非常不習慣，因此這樣的情況下，我們把他們的生活弄得好一點。

但是如果要讓管理人員等等，讓他們的生活好一點的話，這可能不是我們跟山友的協作會議可以解決的，可能要重新調查一下他們那一些利害關係人，自然也沒有10月上線的問題。

沒有問題了，以上。

謝謝。

我再請教一個問題，如果山友還是維持希望回來我們原本的山屋系統來申請，我們也要同時維持現行的會員嗎？

當然啊！如果有人就是要下載windows的報稅軟體，報到一半還會有一個娃娃跳出來說「感謝你對國家的貢獻」，他看慣了標楷體，你不能阻止他。

會不會有民眾說在這邊山屋申請，在整個整合網查詢？

就不用提供服務，非常簡單。如果在你這邊申請的話，email的連結都是你們家的，如果裡面有內嵌網址或者是QR code，當然都是到你們本來的平台，我們系統是這樣設計的。

我們攔截住本來要寄給使用者的信，然後我們不發那一封信，把它扣起來，我們發那一封信，那一封信的網址是新的。

也就是預先提出來，會不會未來有山友是在山屋申請，會不會在哪裡整合？

我們一收到什麼也好，上面logo是你們的網址、文案，這邊自然會有我們的網址、logo跟文案，看起來是兩個完全不同的網站，只是剛好可以做同一件事，跟你兩個方法都可以報稅是一樣的道理。

林務局這邊有沒有其他的問題？

可以了。

目前為止，營建署的系統是傾向Plan B，但是林務局我沒有聽得很清楚。

可能是一部分、一部分，這個你們要想一下。

剛剛林務局的同仁有提到經費的部分是沒有問題的，當然營建署的部分等一下也要說明一下，這個等一下都要再確認，或者現在要講，也沒有問題。

我們這邊應該也是A的部分。

因為要自己做？

是。

時間不能改喔！

你們要自己做就自己做。

B是？

B是別人做。

有沒有一種形狀是「現行廠商」做B？

當然可以啊！如果你們公司很大，另外派一組人做Plan B，這個我們都不會反對，自己砍自己的站，當然這樣資安攻擊表面更小一點，這個是很棒的事情。

只是從採購的角度來看，因為這是指定廠商了，所以我們要知道的只是他們的指定廠商上，要填你們的名字或是要填別人的名字，我們只是要知道這一件事，至於你們自己砍自己的站，說真的從公務同仁的角度來看，是沒有什麼差別。

採購方面沒有辦法替你們解決內部的問題，署裡面這樣子會不會明明是同樣的廠商，但是他不做A、要做B，也講得通，因為這個是有政策目標希望早日回應民眾需求，這個方法是不是最簡便的方法？

標題、網址、方式不同，像上次的以mountain.taiwan.gov.tw作另一個網站，如果你們可以克服這個問題，找同一個廠商來做也可以。

如果可以解決掉主計跟政風的疑慮，當然是希望同一個廠商來作處理。

但是他們的能量要負擔得了，就是李老師講的。

就是本來那一組人去煎蘿蔔糕的話，你們有沒有什麼別的組員可以做？

是哪裡出問題。

我們都同意，這個是你們可以自己決定。

像經費的部分，我們營建署也會自己籌措。其實上次報的已經超過100萬，我們有想好方案了，不過這個我們可以自己處理。

感謝。

你們是說後端的嗎？

前端等一下再討論。

這裡是警政署的廠商，我們在這邊第一次發言。這個系統相關的問題，其實前面兩家廠商已經幫我們解惑了非常多，有的問題在我們這邊也都有，像署裡面外網的部分，那是三層式的結構，所以如果要開發API等等的作業，是需要有一些相對應的時間。

我們現在也很清楚、瞭解到這個有一個任務時間性的要求，其實對我們來講，如果在所謂的Plan A這一段的話，當然是可以做比較完整的規劃，但如果要在10月完成的話，在Plan B，我們在既有對外的網站，然後在機器人認證的這一段，還有跟以後開發機器人廠商這一個部分，把一些資安標準、定義資料來我們網站截取一些相關的標準，能夠把它定義好的話，我想這個部分在Plan B這一段是我們比較有機會在10月完成的。

謝謝。

有沒有技術上的問題需要詢問？

其實我們有的問題，前面幾家廠商都提出了。技術不是問題，時間才是問題。

行政的部分，警政署的先進們？

報告一下，在警政署的部分來講，因為剛剛在技術上，其實在配合上、時程上，如果採Plan B處理，我們是沒有問題。

經費的部分？

經費我們可以處理。

好。所以剛剛處理三個後端系統，還有別的嗎？語言的部分是另外的嗎？後端系統先確認大家手上都已經沒有問題了，沒有一些額外別的系統嗎？

我也跟政委請教一下，如果採用Plan B的話，會有一個主導的廠商會出來，會從網站這邊截取資料的方式，來做他的定義嗎？

當然。

對於署這邊來講，網站除了機器人相關的要求以外，可能到時還會有一些資安上的考量，因為對外一般民眾服務的網頁是不會改變的，但是針對這個內部整合平台，我們等於會有一些IP或是資安的要求，會變成要更看機器人廠商這一段如何配合。

當然，其實臺灣的Plan B產業，也就是搶票機器人，那是非常蓬勃的，不管從車票到演唱會門票，都有許多寫機器人的經驗，所以專業度應該不成問題，這就是黑帽轉白的概念。所以大家在專業度的溝通上，應該不成問題才對。

如果後端都確定的話，我們會做成會議紀錄，我想會後大家也可以給做會議紀錄的朋友們一些指點，怎麼寫、怎麼樣的文句，才能讓大家對於政風、主計及長官等等都能在最短的時間內爭取到剛剛的那一個工項及資源，然後大家一起去做採購的動作，所以這個是後端的部分要麻煩大家幫忙的。

我再補一句話，原則上我們會做會議紀錄，但是大家知道主要是處理行政程序，會議紀錄一定會說請參照逐字稿，剛剛政委回答個別的技術問題沒辦法都記載在紀錄裡，否則做會議紀錄的同仁會很頭大，如果覺得技術面的問題有哪一些一定要寫進會議紀錄才好做，要提前告訴我們，不然我們會從行政面的角度來寫，這個是提醒大家的。

如果有需要加進來的文字，不管會後或者是什麼，請儘快提供給我們，我們儘快融入，方便大家作業。

我請教一下，如果是走Plan B的話，四個系統有頁面申請的非必填或者是附件是否要上傳，這個整合的廠商？

那就是前端了。應該這樣講，Plan B的每一條線，可以是一家不同的廠商，這是併聯，並不是串聯的概念，所以要一個月做完，並不是同一組人簽這個後端的Plan B，又簽那個後端的Plan B，這要三、四個月才做完，所以要一個月做完，勢必要同時讓三組不同的人，幫各位三個不同的後端來建立一個API的介面，如果願意認領半組去，那是非常好的，但是總之我要講的是，林務局或者是這邊也好，大家用90萬招標的對象，很可能到最後三個都不一樣，所以這個是實際上的狀況。

老師想要問的是，假設大家都如期如質完成，到底是誰把這三個長得完全不一樣的API或者是四個不一樣的API來統合前端可以做的事情，這個是前端廠商的工作。

所以是三加一？

四加一。

所以最後會用到等於五個90萬？

不好意思，我可能沒有講清楚，我再講一次，Plan A是自己改，但四個廠商一樣要寫API出來，也就是申請的介面。

但是Plan B是別人幫我寫，我爬梳四個網頁如何帶，就是用這個方式。但我現在怕的是，他們聽起來並不是這個意思，整合網的廠商有沒有需要管裡面的欄位？或者這是等一下的議題要討論？

我們現行的整合網就不去動它了，現行的就長現在這樣子，也許很多朋友很喜歡看試算表跟打勾的介面，及有些人很喜歡標楷體，每個人有美學上的堅持。

我們現在做的是新的網站，這個是不同使用者不體驗，而且10月上線的時候，真的只讓一部分的人使用，而且說不定可以抽籤——開玩笑的——所以在這個過程中，我們必須要讓舊的整合網可以持續網站營運，所以勢必營運團隊一定是不同的人，這個是很明確的。

像剛剛老師提醒的，並不是四個後端要想，而是全新的前端要想，如何想成人類可以理解整合式的流程，這是完全不同的技術專業，所以我們才會請不同的人來做，因為能夠做API建置的廠商，碰巧又非常懂前端的服務、互動設計，這是非常難能可貴的一件事，我們不做這一種想法，而且有這樣能力的人，90萬大概也請不起，這樣的情況，我們儘量把工項去做細的切分。

這一個部分？

這個議程過了的話，我們就往前端走了。

前端仍然是90萬的話，還是從這邊發包，是這個意思嗎？

我們應該講清楚，如果這樣的話，其實營建署負擔的經費，是一個後端加一個前端。

對。在場有人想要當前端嗎？在我們去問別的廠商以前？

如果沒有人要做的話，我們會找別人了。這個前端的目的非常簡單，後端我們瞭解會不斷迭代、抽換，不但是欄位會抽換，接下來逐步上線的API個數也可能會抽換，要在這一些抽換的情況下，做出一個最小可行的方案來，這個最小可行方案是大家用了之後，會覺得某些地方變順了，但很多地方還是沒有的感覺。

我們就是要這一種感覺，因為這樣子大家才會像你看維基百科，如果沒有錯字就不會編輯，按錯字才會編輯，是一樣的道理，所以這個廠商是不斷被人按編輯，然後幫忙做出一個像先期規劃案那樣子，你給大家看一個樣品屋，大家對著樣品屋覺得這個勉強，但是有很多想法，這個廠商可能要產生類似建議書的東西，像正規程序比較多錢招標，也就是未來的廠商，知道怎麼樣做才對，那樣做的時候，樣品屋自然可以拆掉了，這個事情會講得非常清楚，也就是在做測試。

事實上去年報稅是這樣子，如果想要試用新的報稅介面，要先借一臺蘋果電腦是一樣的事情，因為我們把蘋果電腦使用者，界定成樣品屋的使用者，都沒有問題了，我們今年才讓windows使用者使用，未來是這樣的結構，不會請營建署說要用90萬要把樣品屋一路蓋到大樓，沒有這樣的事情，先跟大家說明。

在場沒有人認領，政委只能做概括性的說明，營建署需要進一步的。是不是可以問一個問題，後端跟前端有沒有時間上的差距？

可以一起做。可以一起做的原因是，所有現有的流程，其實在各位的後端網頁上都有了，所以最壞的情況，是可以做一個綠野仙蹤法，就是做前端模擬的流程，看到之後有一個人類，看到有這個流程來，就幫忙你們開這幾個頁籤，然後填一些東西過去，很多人工智慧網站到最後都發現是工人智慧，在後面是這樣子做到的，所以開發本身一定不會出問題，而是等到各位後端介接都做完的時候，這個需要跑來跑去的這一位朋友就消失了，就變成一支程式而已。

署這邊也是會希望整合部分由我們來協助。

太好了，所以你們要一次接兩個？要想清楚喔！

入園系統本來是一組人，整合網是一組人，因為發現整合網並不會這麼單純讓我下台，所以又找另外一組工程師，這個是兩組在work。

他們沒有要去煎蘿蔔糕？（笑）

不會煎蛋餅。

這樣更好，也就是一開始破冰跟彼此培養信任等等的狀態，如果確認兩個都可以做的話，我們這一次的會議紀錄比較好寫，也就是要確認就是了。

這樣很好。像前端的問題，現在要問也是可以，會後包含展銘跟秉倫都有的聯絡方式，甚至用email問政委都可以，到這個階段，有沒有就前端的部分需要知道的？

我再提一個問題，像整合網拋過來的資料，我發現是我的會員，我是不是應該讓他在單獨山屋這邊可以查到這一筆？

都可以，你決定。我們在意的是使用者不用離開新的整合網，但是如果哪一天願意來逛舊的，也發現自己的紀錄在上面或者不在上面，說真的，不在我們使用者體驗的範圍裡面，就是這樣。

不好意思，我再問一下執行面相關的問題，因為現在系統是在林務局在自己的機房裡面，他們有自己資安等級的規範，像現在的系統是讀不到任何IP的狀態，他們可能有經過一些防火牆的處理。

我想要問一下，系統開發在配合的時候，到底會有一些權益上的衝突，也就是到底要聽林務局還是聽新廠商的問題，因為其實只要牽涉到資安，大家都會戰得很緊，所以我覺得會有一些問題。

這個確實是這樣，尤其我們《資通安全法》通過了。

但是有兩個常用的解決方案，一個是根本不要看IP，因為IP只是一種講法而已，其實你要的是它的身分，這個資安，大家都完全可以相信，一點問題都沒有的，就叫做「client certificate」，這是從IP機房的虛擬瀏覽器來找你的時候，我就先認證我是正規的，你就我們驗證這個「client certificate」，確保這個密鑰不會跑到別人，這個是正牌的瀏覽器。

這個透過資安檢測的話，可能透過shared secret的方法或者是透過傳統的SSL的方法，我們想辦法請GCA給我們一些憑證，我們比那個指紋，對的就是他，只要是那個指紋就等於永遠那個特權，這個特權是可以看到不確認是人類，而且也不用去管介面會不會修改的特權，這個是一個解決方案。

另外一個解決方案也是我們很常用的，如果我們不是client certificate，而是一個公共領域，不是有這個特權的機器人才可以造訪，而是任何人都可以造訪，這樣子也是一個很好的解決方法。因為你們是抽籤，並不是排隊，對不對？

（點頭）

所以就算我的機房離你比較遠，光速要走比較久一點，然後差幾個millisecond去、排到後面去，但是這並不是高頻交易，沒有一秒幾十萬上下，最後都還是要抽籤，所以這樣子開成API的話，並沒有剝奪到現有的權限，這又少寫幾行程式碼。這個是你可以自己決定。

前端也好了，所以就雙語的部分？

我們先講一下，跟政委報告一下，雙語的部分，我的理解是，林務局跟營建署的系統都是ok的，不ok你們要講一下，有稍微帶到警政署所面臨的問題，我們就一起處理這一個問題。

警政署以我的理解，目前是有雙語的介面，只是英文的介面是一個word檔。

當然Word檔也是一種介面，傳真也是一種API，這個我們都是同意的。但目前的情況是，如果只看得懂英文的話，我就必須要使用上個世紀的API，如果會中文的話，就可以用這個世紀的API。這是我的理解，不曉得警政署的同仁有沒有要補充的？

針對雙語的部分，我們可能是針對流程申請的表單，會用中英文雙語，雙語並陳的方式，讓操作者同時間可以看到中文跟英文的說明，我們會用這個方式來做網頁的改版。

什麼時候可以完成？

目前正在評估這個申請網頁的時程，如果時程是訂在10月底的話，我們目前看起來會想辦法把這個部分是不是可以儘快完成？

你講的是這個介面，已經有部份是雙語了，這個很好，警政署的名字是英文，但是其他的部分全部都要加上雙語，是這個意思嗎？

比如像往下申請的時候，會有填入國人的身分證字號，或者是外國人的護照號碼，如果要配合整合網的作業，就是下面機器人那一段，我們會把它取消掉，也就是我們會有一個專屬的網頁是給機器人使用，所以機器人認證會拿掉，在開始申請進去的時候，我們有一張表單，會用中英文併陳的方式來提供。

其實我要提醒一個，喜歡這個舊的介面的外國朋友，不是從機器人進去，而是從舊網頁進去，理論上對你們來講，他看到這個網頁及下一個網頁也有英文，這應該是同樣工作的程度，不應該是我們這個新平台來的才有英文的說明可以看，你知道我的意思嗎？

因為對你來講，如果把新的機器人用的那個改成雙語的，你同樣的工作，也可以把這個改成雙語，而且大家還可以順便學一點英文，這個有什麼困難嗎？不管是政治上或者是技術上。

跟長官報告一下，因為本案在六年前或者是七年前開發完成以後到現在，因為在行政單位這邊並沒有提出整個網站的英文改版，所以如果以整個網站，其實全部把它變成英文版的話，像警政署其實有滿多的網站完成雙英文，甚至還有手機版的部分，這一段可能就要看單位規劃整個網站英文改版的作業，再由到時的廠商來配合。

所以我聽起來的意思是，只有入山許可證申辦作業的這個頁籤，底下的網站在雙語的工作上可以如期完成，「進度查詢與取消作業」、「可申辦人數查詢」及「網路核發單位一覽表」這部分不在這次雙語的規劃裡面，是這個意思嗎？

目前評估，入山許可證申辦作業這一段是沒有問題的。

我有一個詢問，因為其實「申辦」都已經寫了英文進去了，所以我覺得「查詢、取消」是申辦流程的一部分，其實不應該說可以用英文申辦，但是取消就要懂中文，這好像有一點奇怪。

像比如在入山許可申辦作業這一段，您點進去看頁籤，也就是剛剛那個表格，本身就已經有提供英文，中英併陳。

現在只是說「網路核發單位一覽表」沒有英文？

對。

我們在講兩件事，我講的這個頁籤是「進入查詢與取消」。

這裡面有兩個部分，一個部分是包含到所有的地址轉址，還有資料庫英文這一段建議的作業，因為畢竟我們如果沒有按照國家的英文路名，然後透過一些翻譯軟體或者是沒有做過一些證明的話，因為那牽扯到位置正確性的問題。

這個我理解。不過你們本來也有一些錯字，也不見得翻譯軟體就比較差。

不好意思，這個是我校稿的問題。

但是就地址來講，你們有一個很確定的，像TGOS的團隊，給你一個一定沒問題的，這是比較容易的，對不對？

可是，我剛剛講的是進度查詢取消，這個好像沒有關係。

這裡面可能有一些資料填的是英文的資料。

意思是，你們不想處理查詢取消時的英文資料，但是你們要處理申辦時的英文資料？

目前評估是針對申辦這一段。

按照《羅伯特議事規則》，如果主席要持反對立場發言，好像要把這個議案主持權交給旁邊的葉寧。（笑）

對不起，我滿反對這個講法。

因為查詢跟取消，從申辦者角度來看，並不是可以跳過申辦，就可以直接跑去查詢取消的事。我必須要先有申辦，才有查詢取消，這個是前後的邏輯關係。

從使用者流程的角度，而不是網頁的角度，這是一件事的前後方面，不可能切分開來。

所以，我覺得前兩個頁籤是同一個使用者體驗，如果你要把它英文化的話，這兩個必須要同時辦理。後兩個你講的地址什麼的，我也都同意，不用在10月上線。

入山跟進度中英併陳。

不管是機器人或者是人類看，這兩個頁籤都要有相應的英文翻譯。

我們就這樣處理。

不好意思，警政署這邊的廠商，我再詢問一下，所以你們入山許可證申請的頁面，現在已經有中英並陳了，他的下拉式選單，比如⋯⋯

表單頁面本身就已經有中英併陳。

你們未來會把下拉式選單的選項，也會做英文翻譯嗎？

警政署業務單位發言，下拉式選單針對那一些路段跟登山路段，我們會請國際組來協助翻譯，因為這個都還沒有制式統一的英文翻譯，我們會儘量朝向山友常用的說法、順便對照林務局、營建署網站上針對這幾個登山步道、林道的翻譯情形，我們會一併參考，報告完畢。

我想補充的是，大家不要覺得10月中上線一大堆外國人會來用，並不是這樣子的。我們還要特別拜託一些在臺灣對爬山有興趣的外國朋友，也有一些朋友們來社創中心找我，說他們很願意來免費幫忙測試我們英文的流程，對外國朋友來說是好用的，也就是完全看不懂中文的情況下，也可以完成像入山申請等等的事情。

所以一開始會來用這個介面，而且用英文操作的，是我們的夥伴——不是伙計，也不是廠商，因為沒有領錢。

所以第一個，不用擔心他用了很不高興之後，馬上就投稿到爆料或者是什麼東西，變成政治上的風險。

第二，除了你是錯的，基本上是會帶著禮物，意思是也會告訴你什麼是對的，其實在網路上就是這樣，如果一開始說是拋磚引玉，然後我提一個不太好的答案，還真的不太好，這樣專家都會來糾正你，所以一開始是這個形狀。

所以大家不要覺得英文網頁馬上要給所有的外國人使用，甚至放在某一個路徑裡面，只用新的這個平台可以連得到，也就是這一些都沒有問題，這個都是可以做的。

在這個前提底下，我想你們的國際組，對品質的要求，我很尊重，但是什麼時候10月1日翻完，就先用那個版本，是這個意思。

感謝警政署的同仁，為什麼三番兩次提這個問題，還是說明一下，因為我們當然知道整個山岳觀光是交通部大家一直非常努力在做的，交通部方面有很多推銷臺灣山岳觀光計畫的時候，如果沒有雙語的介面，大概很難跟大家講。

但是如剛剛所說的，像政委所提示的，將來並不會把個別的網站先打掉去作新網站，不會11月上線就直接打掉，也不會，有一個新的網站，在那個狀況上線的時候，固然是有一定的容錯空間，但完全沒有雙語的話，我們很難解釋，推展山岳觀光，也歡迎外國人透過登山來認識臺灣，但是很抱歉，我們沒有辦法提供英文介面，會有一點難處理，所以這個是特別拜託警政署同仁幫忙的原因。

非常非常感謝透過警政署、大家的幫忙，現在看起來應該是可以的，但也不要大家壓力太大，覺得在10月15日的時候，全天下只留下新的系統可以用，所以一定要是完美的。

沒有這個問題。甚至本來的導流是可以說英文的使用者跑到那個word檔，在首頁導流，我都不會怪你，如果有人想要嘗鮮，想要用一下英文的申請，可以說這一些外國朋友們看要不要試試看，如果不滿意再跟我們講，其實只是這樣子的拘束程度而已，我們絕對不會把本來可以走的那個精美word檔路徑拿掉。

我再提醒一下，林務局自然保護區可能也會有英文版的東西嗎？

基本上在設計的時候，沒有考慮到任何英文相關的資訊，但是在設計上來說的話，自然保護區的申請系統，條目其實並不是非常多，而是一些網站上會有的按鈕、頁籤的相關內容，這一些問題並不大，因為可以採中英文的對照檔的方式去取代，比較大的問題是，像相關林務局的法規或者是提供給民眾相關的法規參考，或是流程圖的東西，基本上是沒有英文版的內容在上面。

再來，很大的一塊區域是，我們各個保護區的管理單位，自己發布公告，我們也沒有硬性規定一定要寫英文的公告，但是其實保護區在申請上來說，公告的內容其實算這個網站申請滿重要的項目，因為如果地方不能申請進去，其實通常都是寫在我們的公告上面。

像這個部分我們沒有辦法硬性去處理，唯一能做的是，用機器翻譯的方式，把公告的內容來做翻譯。接著是需要林務局配合，把一些區域正規的語言名稱跟一些相關法規內容提供給我們，我們這邊英文版網站，大概可以處理完畢。

感謝。我想我覺得還行，英文自動翻譯並沒有特別糟糕，除了1至6的大小寫有一點不一致，區域申請狀況，好像這個位置是壞掉的，除了這個之外，剛剛我稍微看了一下，大概都沒有什麼太大的問題，所以其實你們有一個簡單的方法，就是直接掛一個右下角的自動翻譯。

我們都說了是拋磚引玉，而且不這樣做，其實外國的朋友跟我剛剛開google翻譯，跟我做的事情是一樣的，你沒有比現行情況差的話，大家自然會給你一些批評指教，我想直接掛google翻譯就可以了，而且我看一下PHP的前端並沒有用一些圖片的按鈕或什麼之類的東西，直接掛上去就可以。

如果這個按鈕是一張圖，就是google翻譯，其實他們已經有能力去做文字識別，然後再翻、再貼回去，但不知道為什麼沒有上線。（笑）

總之，只要一開始的設計網頁架構是對的，掛google翻譯應該是一、兩天的工作。

主要我們提供民眾一些入山申證相關的內容要提供。

瞭解。

一個事情，我覺得我們在日期上，大家似乎有一點不太一樣的說法，是不是稍微確認一下，我們現在大概有幾個時間點，因為每個網站完成的日期不一樣，也就是全國登山日的活動是10月6日，依照早上教科文處的那一封信，第一個是院長要出席，這個是第一件事。第二，院內撇開系統的部分，在制度面，如何申請、管理，也是指示要在10月6日前要完成盤點，以利讓院長出席那一場會議的時候宣布。我的意思是，一個是我們網站完成的時間，一個具體建議，是不是訂在10月7日禮拜一？因為10月6日是禮拜天，如果10月7日來得及，是不是就禮拜一？讓院長出席登山日活動時，有一個說法是隔天上線。

第二，因為現在新版的前台網站，只是介接這幾個後台，但如果另外一邊制度面有做修改，時間怎麼搭配，因為有一點平行線⋯⋯

應該這樣講，如果使用者體驗裡面的接觸點沒有修改，而只是每一個接觸點裡面需要及給出的資料有所修改，像剛剛所謂欄位的例子，前端是不用做任何修改就可以了，就是所謂的API discovery。

但是如果動線有所修改的話，前端就要改很大，所以這是為什麼我們希望機器人讀的時候，動線都不要改的原因在此。

所以其實未來的修改還是要用正規的工法做，現在的做法是一個hack，也就是樣品屋，大家可以用，但是等到修改規則等等做完之後，我們還是要有後端的規則修改，實際回應到前端的能力，也就是有一天大家都走回Plan A。

目前的Plan B就真的是打樣品屋而已，但這一些都無所謂，因為大家保證未來一年不要去動Plan B的endpoint，這個應該是大家都做得到。

大家都很關心時程的問題，理想的狀況下，子維的建議很好，也就是如果院長宣布的時候是第二天，很有號召力，但因為這有物理定律的問題，辦不到就辦不到，但時間可能沒有辦法壓太久。

我的意思是，像各位有處理山屋改建的問題，也會要求NCC跟山屋建基地台，如果可以宣布在10月1日或某個特定日期山屋會有全新的風貌，對院長來講也可以在10月6日講，這個要先講清楚。所以這個系統，我們要能跟院長講說比如在10月6日的時候可以用，或者10月15日會有新的網站，大家都可以用。

我們可以多講一點，院長可以說第一批提出具體建議的勇者們，已經在幫大家進行易用性測試了，這個測試將會維持一個月，一個之後會跟大家見面等等，這都可以講的，大家不需要做到在10月6日當天運作起來一點問題都沒有，只是說10月6日可以運作，就是這樣。

所以我的意思是，現在要不要就⋯⋯

我現在要確認一件事，如果理解沒有錯，政委原先提的是10月15日？

10月1日後端寫完，接下來是前端整合的時間。

採購的日期我就不壓，因為各個單位有不同的情形，如果要求各位什麼時候要完成採購程序，這個是不合理的，但是就用工作完成的。

像剛剛講的第一個日期後端完成是10月1日，我們現在幾個單位，有問題要趕快講？

如果你們覺得已經全部牽出來請外面的團隊做，現在就說「可以」就好了，因為反正不是你們。

政委講得沒有錯，這個問題要回答的只有李老師而已，因為對各位來講，我的理解不錯的話，其實政委要求都是你們不要做什麼事情，所以理論上這個應該比較沒有問題。

其實我們同時在做的是，前端也在進行開發，我不知道要用什麼整合起來可以上線運作？

應該這樣講，如果只是要讓少數的外國朋友可以測試，中間運用一些工人智慧，我們現在沒有公共行政替代役了，但大家知道我在講什麼，透過一些工人智慧來進行手動整合，這都是做得到的，說不定實務上在做易用性測試，還真的得這樣做，所以這個時候的上線與否是脫鉤的，10月1日，我們要求前端的，只有前端看起來美輪美奐，但是不一定真的要用後端的API。

到了10月6日，如果真的不行，我們就說我們先開放10個人測試，測試測試者跟後面的總機要開始申請，我們就幫你打開頁籤，這一些都是可以安排的，事實上是必要安排的，所以前端在10月1日準備的只是一個殼，這是大家在用的時候覺得很順，但實務上這一些殼到底哪一些接到後端的API，這個是看運氣。

但到10月15日的時候，我會希望接得上的、接不上的，到底API有哪一些API需要修改、調整等等，這一批意見就要給後端，後端如果真的需要調整，不管是採取Plan A自己改，Plan B第三方廠商沒有寫好的部分，10月15日請前端給出這樣子一份意見，這樣後端在調整，我們就比較不趕了，因為這個時候就大概可以做出包含簡訊、email的流程，都可以做得出來，就像葉寧剛剛所說的大家都可以來用，是11月1日。

甚至到最後大家都可以來是12月1日，我們看那一個月的測試期裡面，大家覺得怎麼樣，不過不可以晚於12月1日。

不能隨便什麼時候。

今年的隨便什麼時候？

以我的理解方式，10月1日前後端基本上有一個殼，10月6日院長要能宣布明天開始進行一些有限度的封測，並不是全國的人都可以用，10月15日測的結果會丟回來，我當然是希望11月1日是全世界的人都可以用，我的理解是這樣。

對，但是這裡有兩個風險。第一個是大家覺得API接回來有問題，兩個禮拜修好，這個是理所當然。

但是如果大家覺得前端介面很醜，或是前端介面用起來就是一直讓人看了不想去爬山等等，等於完全是主觀性的意見，要兩個禮拜修正完畢，這也不容易。

所以，我比較不敢保證這個新的前端一定可以兩個禮拜修完的原因在此。

但我們現在討論的是，也就是前後端介接的中間這幾條線，我也是希望如果10月1日都做完，10月15日第一次封測結果出來的話，11月1日就把兩邊都修正完畢。

我只是想一個場景，對於蘇院長來講，10月6日如果被問到，之前網站做得很爛要怎麼處理，院長就可以說：「我們做完了，明天就開始進行測試。」？

「已經拜託各機關幫忙，以最快的速度做完。」

特別是行政的同仁，要特別理解這一件事，我們會儘量把這一個部分寫在紀錄裡面，讓你們可以跟長官報告。

即使是指定採購，你還是得找一個結案的時程及結案到底要做到什麼，這個是葉寧給一個非常明確的時間，以後端橋接的工項來講，就直接寫10月1日完成開發、11月1日要完成驗收。

前端的案子還要另外討論，因為前端的案子，不是只是接後段的工項完成，還要調整到大家真的用得起來的地步。

如果有任何的問題，都可以提問。

我再提問一個問題，因為現在是會員制，因為領隊通常很多是旅行社，以天池山莊，我看過有400多隊在抽不到10隊的機率，如果整合網，比如是一個領隊帶10個隊員，因為領隊是旅行社，所以隊員不需要註冊的，如果未來在整合網這邊，可能會有11個人輪流當領隊，因為我們這邊報名一定要有領隊，也就是11個人當領隊，然後用11筆訂單過來，那就會增加原本的中籤機率。因為天池是非常熱門的。

那用你們本來的網站？

我有領隊，會攔會員，會員一定是領隊，領隊不能重複註冊。

所以你的意思是，可是這個情形一樣發生，如果要做同樣的事情，就把10個人註冊成會員。

不會，因為通常是旅行社會註冊，那個隊員不會註冊。

但不是不能註冊？

可以。

不會做這一件事，但是在整合網，像旅行社用其11個隊員來輪流送訂單，我這邊是吃的。

但就像剛剛講的，旅行社現在寫一個小外掛，只要有人來報名，我就趕快來註冊成為領隊，你們的系統？

因為中籤之後只能改兩次，不能增加人，只能減少人，而且只能讓他減兩次，所以我們這邊是有限制的。

我聽懂了。我想我們先這樣處理，你們先以你們目前的邏輯，把API做出來，然後我們在前端的設計上，我們來看一下有沒有可能你們這邊類似的限制、類似的篩檢，或者是類似的東西，我們在未來——不是10月1日——中間的這一層也用類似的方法，在介面上一樣的方式，也是會照顧到他們的公平性，問題是10月1日到11月1日是絕對不會發生，這個是封閉測試，所以等到公開以前，我們爭取一些時間，爭取前端有一些修改來照顧到公平性。

這個是功能性端對端測試，另外一個是體驗，包含來爬山跟來亂的使用者，所以Q＆A的部分，我們本來就沒有辦法在那一個月裡面把所有的這一種刻意測試的這些朋友們都約來，之後正規上線的時候，必定還是要配一些你剛剛所說的極端案例情況。

我想那個時候，您的角色可能就會是類似前端的諮詢或顧問，或者自己就來打打看等等的狀況，也就是在前端怎麼樣作弊會造成後端最大的困擾，這個時候我想我們會有另外一些方法來調整前端的介面到比較不會發生這一件事，但我想這個大家不用把它想在11月1日要做到的事情，你知道我的意思嗎？

我充分理解。

但是有一天會要做的。

這個是一個問題，像嘉明湖，禮拜六或者是連續假日，是非常熱門的。

這個我完全同意。其實對於抽籤的公平性等等，其實就算是你現在的系統，我們在訪談的時候，也有聽到非常多各種各樣的意見，我想這跟買樂透沒有中，是一樣的道理。

我想我們先比較瞭解大家的感受之後，再來看那個介面怎麼樣畫、呈現，甚至配色是什麼，這一些可能都滿重要的，因為目前這一些質化的資料還沒有回來，所以等質化的資料回來之後，協作會議之後我們再回來盤點這個，但是很謝謝，這個是非常重要的一點。

其實以我們的經驗，那天協作會議一定會提到這個問題，這個是必然會討論到的，但是不管怎麼樣，在10月1日的時候，那個問題不會發生。

請大家把握時間。

林務局一直提到像會員制跟控管領隊，我們稱之為卡控，熱門時間要2,000多隊抽12隊出來，但是我問的是，前台是把申請的業務一直到申請完成，可以查得到跟下載許可證，但是像這一種卡控的整合網要去調查嗎？

你說的調查是什麼意思？

我要照顧到像剛剛所提到的，有三個管處、三個系統，這三個林管處的需求，我要care到這個嗎？

是跟你要資料？

我把案件塞回去給他，不管是API或者怎麼樣，這個領隊有沒有照顧機制的時候，其實原系統還在，自動就會chek這個結構給我說這個身分是有疑慮，所以前端⋯⋯

瞭解，那就是例外處理。

說違反林務局的規則？

對，他出什麼，你就是什麼。

所以在前端不用管它？

他這邊只是確認你的格式跟他的格式還是有一點不同，所以會變成僧多粥少的情況，這個從技術上來講，我說自己是2020年出生，他這邊跟你說其實今年沒有人是2020年出生的，你就直接顯示給他就好了，這個不需要特別想商業邏輯。

還有5分鐘要處理體育署，他們有登山的網站，像相關的資訊可以像「ai.taiwan.gov.tw」。

這個是什麼？

因為配合後來整個登山政策的處理，我們有一個登山教育的區塊，原先我們自己本身就有一個愛運動的平台，將有一些活動跟縣市政府的活動進行一些相關的整合，讓民眾比較容易去查詢這一些資訊。

「愛運動」嗎？

「i運動」。

登山是其中一個？

對，是登山教育。有一些影片跟懶人包，目前是在建置這一些資訊。

但是這裡看起來，你們自己放的資訊，並沒有非常多種格式，這個也是你們的？

對，因為我們這邊有負責山岳嚮導受證這一塊，我們有把專業人力放進來。

你的意思是希望未來前端整合平台，也串接你們系統的意思嗎？

如果有些東西是在你們那邊，既然是叫整合平台，也可以看到你們的東西。

這個我大概瞭解。目前的有連回去嗎？

沒有。

沒有的原因是，同樣的資訊別的地方也有，或者當初沒有想到？

這個本來打算是做登山教育資訊這一塊，是後來因為營建署這邊做了整合平台，因此想說把它一起做網站的連結，民眾如果有需要的話，或許也可以使用。

互相加連結，這個是1秒鐘的事情。

當時是這樣的想法。

所以體育署將來是登山活動的教育主管機關，你們有打算把登山的活動分開來，變成一個獨立的網站嗎？或者是沒有，繼續這樣放上去？

目前初步來講，以整體現行的經費規模上，我們沒有去獨立再去做登山的網站，所以我們現在是在我們的活動平台的網站上，因為這個平台也可以查詢一些資訊。

這邊是想找人才、服務，其他都不是服務，而是一些資訊，對不對？因為我們是一站式服務，因為一站式服務跟資訊是兩回事，因此我們的研議是一站式服務平台先做好，資訊的部分，我看本來整合資訊網的做法，也是所有的資訊部分用外聯的方法來做，我想先這樣，因為你內嵌顯示資訊跟外聯顯示資訊是一樣的道理。

可能要展開，不可以直接連「i運動」？

就是這一頁，等到入山申請證上線了，也麻煩這個連結改到新的連結。

好。

大家都ok嗎？

會議紀錄會講清楚，各位現在做的，像政委所講的，不代表做了Plan B之後，其他的長期改善就不做了。

Plan B是短期的。未來該做的後續開發、資安檢測，當然一個不缺。

只是說，如果沒有先讓大家看得到的東西，民眾大概不會有興趣來參加重新設計。

各位系統的改善，並不是說10月、11月上線後就結束，然後就沒有這一件事了。

謝謝大家，我們先這樣處理，謝謝。