# 取经台湾： SmartGov “政府开窍” 会议 （上） 本篇内容作者林小草，联系邮箱，原载在 演讲ppt下载请戳左下角「阅读原文」 SmartGov（政府開竅系列研討會）是由 "Code for Tomorrow" 這個組織舉辦的活動，旨在分享在公部門改善作業流程、分享資源、彙集相關資訊等種種經驗。 然後⋯⋯我最近有下標障礙，廢話不多說，先來一下議程表。 XD | 時間 | 主題 | 講者 | 講者服務單位 | | ----- | ------------------------------------- | -------------------- | ------------ | | 13:00 | 報到 | | | | 13:30 | 主辦、合辦單位致詞 |

徐子涵

吳肇銘

| | | 13:40 | 如何讓政府變聰明 How Can Governments be Smart | 李鴻源 | 國立台灣大學 | | 14:10 | 跨區服務免奔波 | 吳肇銘 | 新北市政府研考會 | | 14:30 | 英國政府數位服務策略 (GDS) 及設計準則 | 蔡明哲 | HPX | | 14:50 | 從資料看交通安全 | 柯維然 | 新竹市警察局 | | 15:10 | 政府防疫物資公私協力新模式 | 王開弘 | 衛福部疾管署 | | 15:30 | 中場休息 | | | | 15:50 | 病後人生 | 羅佩琪 | 病後人生一站式服務網 | | 16:10 | 公共服務如何導入通用設計 | 余虹儀 | IxDA台灣互動設計協會 | | 16:30 | 大學選課模擬系統 | 謝宜峯 | 國立臺灣科技大學 | | 16:50 | 讓公共服務變聰明的《資料科學計畫》 | 蔣居裕 | DSP 資料科學計畫 | | 17:10 | 政府與公民共創價值的小撇步 | 汪建均 | | | 17:30 | Wrap-up | | | 活動辦在消防局，是一個相當奇妙的地點。你知道的，近幾年我參加 open source 的集會活動都在中研院啊⋯⋯ 一樓的告示牌寫「謝絕選舉宣傳」，我實在是很好奇有哪個候選人會這麼熱血跑來這個場子⋯⋯如果有來我應該會印象大加分耶！XD 行政院研考會的吳肇銘主委一開場就很直白的說：「今天的主題是政府開竅，但是政府一直拿翹。」在這場活動中，就是以各種不同的角度來改善公家機關，講者有身在公務體系的人（例如吳肇銘自己本身在新北市政府、疾管署的王開弘也來分享採購經驗），也有一般民眾（例如在國宅裡導入通用設計的余虹儀、因為翻讀社會福利申請資料感到不便而主動整理的羅佩琪）。 徐子涵 (schee) 提到，在 twitter 上為了要推廣這個活動，曾以英文發佈活動訊息，有新加坡的政府部門對這個活動非常感興趣，顯見政府開竅是各地皆然的需要。 因為只有一下午的時間，但是有十個議題要分享，時間有限，所以開場的這兩位都沒有說太多，很快地把第一場的講者李鴻源教授請上台。 **#01，李鴻源教授，「如何讓政府變聰明」** （講者背景：國立臺灣大學土木工程學系水利組教授。曾任台灣省政府水利處處長、台北縣副縣長、行政院公共工程委員會主任委員與內政部部長。） 全世界的政府都面臨到我們過去不熟悉的狀況，全球的氣候變遷、政府組織的改變⋯⋯使得政府不再能夠以過去的運作模式運行。 過去政府機構的運作方式都只想要防弊，「防到公務人員都沒有想像力。有想像力的公務員是非常危險的。」而台灣因為不能夠清楚定位自己在華人世界的位置，因此定義出來的政策也很難準確。 基於台灣的地理特性（多高山、地震頻仍），水利界很難定義「兩百年防洪頻率」，在他處兩百年發生一次的災情，在台灣一年可能就發生兩次。水庫都滿了，找不到地方再蓋新的水庫，清淤也有困難；地層下陷問題嚴重，例如在屏東佳冬鄉，在離開海岸線五公里處仍只能抽出鹹水，只好種植耐鹽作物（例如黑珍珠），我們不能單單只是告訴漁民「你不要再抽地下水了」，而是要提供他替代方案。 雲林每年下陷八公分，高鐵到未來一定會斷掉，雲林彰化的地盤下陷狀況是以封井計畫來減緩下陷的速度（目前是每年三公分）。這樣的封井計畫，最大的困難是在於政府的跨部會協調合作，每個部會都有每個部會的主觀意識，要如何讓政府各個組織之間能協調合作，是最大的挑戰。 李鴻源教授舉了谷關、南投縣隆華國小等案例，這些不斷重建、再毀壞的建築物與公共道路，修復後總是讓人期待它是可以長治久安的繼續使用的，但卻又一再遇到百年、千年才會遇到的災害（賀伯颱風、921 集集大地震）。 台北目前人口密集程度之大，「新北市的雲林人，比雲林縣的雲林人還要多。」房價並不是最大的問題，而是以目前的人口密集度，如果再次發生 921 這樣的六級地震大災難，估計會倒掉四千多戶房子，會造成多大的損害？因此應該考慮的不是如何打房，而是要思考怎麼讓各地區人口與就業機會能均衡發展，減少可能的災害對國家帶來的震盪。 政府往往沒有意識到有些現象正在形成，例如，目前台灣有大量的新住民移入，但是卻沒有對應的政府機構來專職處理這樣的議題。 「台灣有三件事永遠不能談：油價、電價、水價。」沒有替代能源，就永遠無法討論核四存廢議題。瑞典在 2005 年提出了新的能源政策，目前替代能源就已發展得非常好；但是在台灣，沒有企業發展替代能源，政治上也不能妥善討論這方面的議題。 李鴻源提到在他過去還在政府機關服務時，曾經參與與大埔事件有關的會議。「我是新來的，我不清楚大埔問題，但我想問：台灣需要多少科學園區？現場一片靜默，沒有一個人能算出來為什麼我們需要這麼多的科學園區，那我們憑什麼去圈人家的地？」全世界都有智庫在為政府規劃中長期的發展計畫，照理說應該要廣為收集資料、進行分析，才來制定政策與預算，但台灣只有選舉時才有人提一時的方案與願景。 李鴻源教授先前根據水利署、農委會等部會統計的易淹水、坡地災害及土石流區域，畫出了以下這張圖，再根據這樣的圖來規劃國土政策。可以看到台北有很多很貴的地段都是在高危險區，「那些拉住滑坡的地錨都是有壽命的，我們一天到晚算命，但你怎麼知道你開車經過的地方地錨壽命到了沒？」 透過大專院校（台大、中央、成大）收集大量的資料，整合出了 7,835 個村里的防災地圖。有了這樣的資料數據，現在只要中央氣象局說新莊地區降雨 200 毫米以上，就算閉上眼也能知道哪些村里會發生怎樣的淹水狀況、應該如何因應。 這樣龐大的資料庫未來也能推衍出公共建設的合理性：怎樣才不會蓋出蚊子館？怎樣的發包水準不會有政風問題？目前有些部會或公所因為不熟悉工程，沒有判斷標案的能力，常被廠商牽著鼻子走，因而影響了工程品質與價格合理性（例如：有的廠商完全沒有相關的修繕經驗，卻以最低標得標，因而使得同一個地方怎麼修都修不好），如果能夠跨部會收集足夠的資料、進而作出正確的分析與決策，就能達到防弊興利的目的。 理想上，應該由各地大專院校協力收集資料，付由中央各部會、內政部、地方政府與災害防護科技中心運用。整合多方資源，才能研擬出合適的對策、也能具有好的執行力。 「我們的政府被我們的民主制度綁架了。」政府忙著解決昨天的問題，沒有時間心力去面對未來的問題。李教授認為應該以值得信賴的科學來搜集資料，進而定義明確的政策。 **#02，新北市政府研考會主委吳肇銘，「政府開竅：新北市跨區服務免奔波」** （講者背景：現為新北市政府研考會主委，曾獲2013年度「100 MVP經理人」（經理人月刊）、「傑出資訊人才獎」（資訊月），是公部門首位同時獲得資訊界與管理界最高榮耀的雙榜得獎人。） 我們期待能讓公家機關能以市民為主體，「從作文的角度來說非常容易，從做事的角度來說非常不容易。作文的比做事的多，有想法的比有做法的多。」政府應該以「平台」的角度來服務民眾，不是讓公務人員一個人去嘗試串連多個機關，而是要整合連結各個機構的資源來共同為民眾服務。 這樣講很抽象，舉個例來看：過去我們都是以單一資源的概念來思考，這台筆記型電腦就是裝這台電腦上的東西、那支手機的內容就是那支手機的內容⋯⋯應該像 Apple 的 iTunes 一樣，讓不同的設備可以同享相同的 App、音樂等等種種資源。 以前戶政事務所會要求民眾回戶籍所在地處理所要申請的服務，但是現在已經數位化了，透過雲端服務的整合，到每一區都能接受服務。第一個遇到的問題就是「規定不行」，開會時發現是新北市的自治條例，那麼就著手來修法；各機構各謀其政地覺得「關你什麼事啊」，就只好往上尋求市長的支持；面對底層執行時的抗拒，「做錯算誰的？」、「人手不足啊！」，就從少量的服務先著手，慢慢開始做。 初期必須先統一規範，例如以前各個區公所對業務要求的證件不一，表單上只要貼一張照片，可能有的區為了保險收了三張、五張照片；如果只發內部公文通知內部啟動新服務時，基層人員可能會基於抗拒而告知民眾「這個服務你還是不要跨區做比較保險」，因而刻意做一些裝潢，在門口擺個「任意門」，讓民眾明顯知道有新政策，進而 push 基層公務人員協助辦理。 公所最常做的業務以社會福利申請案件居多，而需要社會福利的人往往是比較弱勢或是不便移動的，例如：孕婦要申請好孕專車、老人與身心障礙人士要申請相關補助等等。能夠整合提供服務，就能解決大部分需求者的問題。 整合服務技術上其實不困難，但是基於「防弊」的心情，要取得各機構的資料就要面對「你把資料拿去，如果被濫用怎麼辦」的質疑。但以申請社會福利為例，如果不做整合，以身心障礙者申請「房屋租金」及「購屋貸款利息補貼」為例，在舊制下要奔走至少四個機構（公所、稅捐處、地政事務所、戶政事務所）。 「『聰明』，就是讓民眾的需求得到滿足。」 **#03，蔡明哲 (Richard)，「英國政府數位服務策略 (GDS) 及設計準則：以使用者為中心的政府數位服務設計」** （講者背景：現為悠識數位首席體驗架構師 (Chief Experience Architect)、HPX 社群創辦人。） 英國政府數位服務 GDS (Government Digital Service)，是一個「帶領政府數位轉型」的政府部門，不過它不太像典型的政府部門，其中的成員大部分來自民間。轉型不是買軟硬體，不是把磁碟裡的資料放上雲端就叫轉型。 過去英國的弱勢族群申請社會福利時，會很困惑於應該如何申請：政府可能提供了 A 補助，又告知因為取得 A 補助、必須取消 B 補助，那麼應該怎樣申請為宜？就能為民眾面對的現實困境。 2010 年 10 月，Martha Lane Fox 提出 "Revolution not evolution."——政府應該要革命性的變革，而不是慢慢地演化。 為了提供民眾「高品質使用者經驗」，GDS 的溝通策略是 "open"，讓民眾可以參與，而不是一群人關在辦公室裡把東西生出來。過去有很多服務都是政府機構悶著頭想，使得有些網站服務做到後來就變成「雲端蚊子館」。「在商業團隊裡溝通的過程，我們都覺得『公公婆婆』很多了；在政府機關，最難的不是技術也不是營運，而是不易取得共識、不知道怎麼做出正確的決策。」「什麼是世界上最遠的距離？老闆用自己的經驗想像使用者需求。」 在發展過程中，GDS 不停地在每一季演化網站，可以從下圖看出演化過程，一直到 2013 年 08 月才出現穩定的版本。 在新版本中，GDS 拿掉了花花綠綠的 icon，這也是他們的研究成果之一：根據使用者研究發現，icon 無助於使用者記憶、觀看網頁內容，因此改為調整字體與排版來達成網頁呈現的目的。 GDS 的辦公環境很像民營企業，採開放式空間，而非一般死氣沉沉的公務機構的小隔間；但在發想過程中，仍大量地使用紙筆，不倚賴科技。 目前 GDS 訂出 26 條設計方針，也有相對的實作建議約 240 篇文章。套句 g0v 常說的，「不要問為何沒有人做這個，先承認你就是『沒有人』」，因此 HPX 成立了 HPX-Gov，研讀前面提到 guideline，預計要翻譯該份文件。 **#04，柯維然 (odie)，「從資料看交通安全」** （講者背景：新竹的菜鳥巡官，服務年資約兩年，寫 python、參與 python 社群。） 為了減少交通事故發生率，要收集交通事故資料，來作為未來的分析依據。目前的事故資料來源有： 1警政署的交通事故統計 2.衛生機關的死傷統計 3.交通機關的流量、道路幾何資料等等 4.監理機關的機動車輛持有數 5.保險資料 在事故發生時，基本上要填的表單有七種，填到員警一定記得住當事人的名字XD： 1.受理交通事故登記表 2.道路交通事故談話記錄表 3.交通事故調查筆路 4.現場照片記錄表 5.酒精測試觀察記錄表 6.肇因研判表 7.對方當事人資料表 下面這張圖是員警反映很難用的內政部警政署的「道路交通事故資訊 E 化系統」，我其實還滿好奇難用的點在哪裡？web 表單很難填？ 總之這個系統可以轉出資料來，不過是奇怪格式的 raw data。（用 @ 當分隔符號，不曉得為什麼不做成 CSV？） 有了基本資料，就可以把資料放到 GIS 上，清楚標示出容易肇事的路口，以作為日後改善的依據。 柯維然設計的視覺化交通事故分析平台，使用 Google Map API 來標示車禍事件、提供視覺化的分析依據，上頭的交通事故類型有三種： A1：事故後24小時內死亡 A2：事故後24小時後死亡或受傷 A3：財損 這場講者的語速很快，所以就簡單摘要一下： 1 住宅竊案比較容易出現在過年期間發生，如果抓到一個慣竊，接下來的竊案發生率會明顯下降。 2 以新竹而言，凌晨五點左右是車禍案件比較容易造成傷亡的時候，年輕的用路人常是肇事者。 3\. 「有人才，沒位置」，目前雖然有交通工程的專業，也收集了大量數據、有分析能力，但是沒辦法做更多的事或得到肯定。但是沒有鼓勵的時候，就是用很多的熱情來支持自己。「不一定有結果，但一定要有堅持。」 **#05，衛福部疾管署王開弘，「政府防疫物資公私協力新模式」** （講者背景：前職是在做防疫物資的管理。） 在 SARS 期間，負責管理 N95 口罩、外科口罩（即民生口罩）、防護衣等物資，由於在當時市場上供需失衡，因此為解決疫情尖峰期間的供需問題，大約會釋出 400 萬片的民生口罩來降低民眾的恐慌。 由於防疫物資有保存年限，因此難以預先大量購入儲備；過去又有「如果儲備量公開，會不會被搶著索取」的疑慮，因此資料也沒有透明公開的前例。 衛福部一度以「虛擬庫存」的概念，簽訂「開口合約」，以特定的單價請廠商供應。但是等到疫情發生，簽了八家廠商，仍然每家都宣稱無貨可供應。後來想到「大水庫流通模式」，在既有預算下，成立電子平台。改成與業者簽約，先將防疫物資由廠商庫存管理，再由醫療院所統一由衛福部的平台下單取得。 在現有的政府採購法之下，「公務員為民興利的概念尚未被認可，可能無端背上圖利廠商罪名。」公部門如何與民營機構之間合作，還待多方調適。 活動總共有十場演講，後面還有五場～不過因為這篇已經寫太長了，所以另外五場就請看明天的报道。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://blog.opendatachina.org/blogs/qu-jing-tai-wan-smartgov-zheng-fu-kai-qiao-hui-yi-shang.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.