• 大家可以繼續聊天,但是我們一向準時開始(笑)。

  • 大家如果手上有手機或者是電腦或者是其他可以連網的設備,可以連到sli.do,輸入今天的日期是226,如果等一下麥克風被特定單一人,像我霸佔住的時候,大家還可以在線上……希望是具名留言,但是如果比較敏感想要講的話,也可以開匿名瀏覽器匿名留言,在這上面留言的,我們在逐條討論之前會回來處理,處理的原則就是在上面發言,等同按麥克風發言。

  • 因為還有一位蕭顧問還沒有來,所以我先把議程上的主席致詞講一下。

  • 大家好,我是唐鳳,今天很高興來跟大家一起討論這一個設計準則,GDS(政府數位服務)是全球新興趨勢,當然說新興也好幾年了,其實各位現在多多少少在自己的工作上都有來推動,所謂用民眾的角度來進行思考,不完全用機關的角度來進行思考,這樣當然可以讓服務更好。

  • 我們有一些不敢說「best practice」,有一些「better practice」,是全世界看起來都覺得是比較好的一些做法,所以我們集結大家想法的方式,去做成一個叫做「數位服務設計準則」。

  • 國發會從去年9月,開始推動政府「一站式數位服務」,主要的目的是要讓機關之前個別提供服務,紙本要跑四個地方、現在要填四個網站的情況有所改善,我們希望集結機關一起構思,讓使用者的感覺上是一件事的,就是一個流程可以做完,這件事當然是需要做數位服務再造的工作。

  • 我們參考了一些新興國家的經驗,他們都很重視探索民眾對政府服務的期待,藉由政府服務的設計,以及發展規範,讓政府部門有這樣的動力能夠持續不斷精進。

  • 當然,如果只靠政府來做這一種想像式的政策制定,通常都不會有什麼好結果。我們現在的做法,是用開放的方式來集結大家的意見,這一次特別是在國發會「Join」平台上,也公開徵集民眾的意見,讓這一個草案的規劃更為周全。非常感謝主辦單位,很辛苦地不但把面對面會議的逐字稿提供到「Join」上,也把線上的意見帶回來,變成接下來原則性及逐條討論的提綱。

  • 總之,今天希望藉助在座專家的能力,來集思廣義、一起審視這個準則。

  • 我等一下在簡報和提綱討論之後,也會帶逐條討論,大家可以盡情給一些修正的意見,讓我們接上國際發展數位服務轉型的趨勢。

  • 我剛才問了一下,並不是每一位老師都認識每一位老師,所以是不是可以快速自我介紹一下?

  • 如果有特別關心這一個數位服務準則某些部分的話,也可以在自我介紹的時候順便帶到一些,請從我左邊開始。

  • 政委午安,我是台北市政府資訊局副局長,我姓高,我在政府機關資訊服務待了二十幾年,希望大家多多指教,謝謝。

  • (蕭景燈入座)

  • 剛好,時間抓得真的是太棒了(笑)

  • 各位好,我是台中市政府顧問蕭景燈,謝謝。

  • 大家好,我是時代力量智庫副執行長彭盛韶,之前其實在資訊局服務,謝謝大家。

  • 大家好,我是臺灣科技大學資工系副教授鄧惟中,我同時也在消基會擔任副董事長。

  • 各位好,我叫陳運成,是服務設計師,近期主要幫政府部門進行數位轉型,擔任顧問或專案負責進行創新模式的發展,謝謝各位。

  • 大家好,我是林書漾,我是互動設計背景,現在在PDIS做設計相關工作。

  • 大家好,我是薛雅婷,現在在唐政委辦公室協助相關會議紀錄,謝謝。

  • 各位先進好,我是國發會楊耿瑜,我是承辦科科長,請多多指教,謝謝。

  • 各位先進大家好,我是國發會藍建智,我是本案的承辦人,請多多指教。

  • 各位好,我是國發會資管處潘國才處長,今天很高興有機會請到大家來。

  • 剛剛政委已經跟大家報告過了,我們從去年開始推這個計畫的時候,已經徵詢過非常多的意見,但是各項的意見從來都不嫌多,因此我們今天還是希望能夠聽聽大家給我們寶貴的指教,謝謝。

  • 大家好,我是國發會陳怡君,非常希望大家今天能夠多給我們意見,謝謝。

  • 大家好,我是朱斌妤,政大特聘教授兼任政大電子治理研究中心主任,謝謝。

  • 大家好,我是台科大林久翔,我過去做的研究是人因工程與使用者介面與經驗的設計。

  • 政委,各位與會專家學者大家好,我是陳俊杉,我在台大教書,也在台大智活擔任副主任兼執行長。

  • 我們中心致力於服務設計創新與使用者經驗研究,我們做了十年,一直跟企業、政府及NGO單位做實際案例,深化與落實以使用者為中心的設計創新,很高興有此機會來參與本次的討論,謝謝。

  • 各位午安,敝姓黃,我叫黃仲菁,我目前是台大智活博士後研究員,目前也在台大共同教育中心、清華大學資訊系統研究所兼任教授,資訊系統相關開發的課程,謝謝。

  • 主席,我是資策會科法所顧振豪,資策會科法所長期以來一直針對數位政府及數位轉換相對應的法制問題有作一些研析,今天也透過這個機會希望可以跟大家進行交流,謝謝。

  • 大家好,我是資策會蕭榮興,主要是負責這一次計畫的執行。

  • 很感謝各位專家委員與先進,今天有這樣的機會,藉由這樣的機會可以持續蒐集大家的意見,然後再聽聽大家的想法,謝謝。

  • 主席、各位專家大家好, 我是資策會蕭聿廷,目前是擔任專案經理。

  • 各位好,我是資策會劉蕙,是專案的工程師,謝謝。

  • 各位好,我是鄭來宇,我是資策會負責設計準則的團隊成員之一,謝謝。

  • 謝謝大家。

  • 我想一開始就請執行團隊先跟我們作基本的簡報,包含手上這一份怎麼來的及去那裡。

  • 大家等一下的發言基本上都會做成逐字紀錄,但是不會馬上公開,會先跟他們確認之後再公開。

  • 大家好,我們歷經各國文獻的整理,也透過問卷的方式來蒐集專家的意見之後,還有辦理了兩次的專家諮詢工作會議。在最近的這一個月,我們也透過「Join」平台公開蒐集民眾的意見,今天的會議是希望能夠在完整的資訊蒐集後提出建議與看法,就教於專家委員的一些想法。另外,我們後面會準備四個根據「Join」平台的提綱內容,再請教各個專家委員的後續一些意見,以下我們先就這整個研究歷程與準則的精神來跟各位專家委員來報告。

  • 各位委員大家好,接下來跟大家來進行今天準則的設計內容說明。

  • 這次會議的主要目的是源自於106年行政院提出的DIGI⁺方案,其中打造這次優質數位政府這一塊是由國發會主責,因此國發會也提出服務型智慧政府的推動計畫。

  • 而這個推動計畫主要有兩個主軸,其中有一個主軸是發展「一站式整合」服務,國發會在這一塊已經陸續結集相關機關共同構思。

  • 在機關間討論發現其實還是需要共同準則來作為討論的基礎,因此為了發展政府數位服務創新服務模式,為了提升國際上的排名,以及最重要的是民眾滿意度,因此我們要擬訂政府數位服務設計準則草案來引領整個政府在進行轉型的參考依據。

  • 我們從各國推動的政策來看,首先我們從英國來看,各國推動的整體狀況可以發現英國的做法是屬於全面性戰略的做法,是從制定數位策略當中協調了各個角色的參與,包括使用者、領導者、利害關係人的角色納入。

  • 在制度面有共通的方法,像是擬定了不同的標準與準則,讓機關在推動時可以參考。同時,也提供一些共通平台及一些元件。

  • 在帶動數位轉型的文化上,透過建立了二十五個示範的服務,以及在內部同時也利用數位學院來帶動整個公務人員數位的能力。

  • 美國數位推動起先是為了挽救健保網站癱瘓的問題,後續也把這樣子的經驗累積成play book(教戰手冊),供部會在推行數位服務時可以作參考。此外,也有擬訂設計系統上UI/UX相關參考的guideline。

  • 澳洲的推動其實是起步比較晚,是參考了英國跟美國,在2016年才開始慢慢更新。但在整體推動的策略上,布局也是相當地快,短短一年間整個布局也很全面性,可以看出跟UK一樣,在整體策略的規劃上,有一個很全面的規劃方式。

  • 同時,也有提出數位服務標準,也參考美國建立的部分,就是建立採購框架等等,也有做小型的示範,像myGov,及健康、高齡、照護改革等等。

  • 從各國推動的經驗來看,我們可以發現不論是在整個名次上的排名或者獲得民眾的肯定,還有在節省成本上都可以看到帶來很好的效應。

  • 從上述各國推動的經驗來觀察,我們可以發現一些共通點,像他們都有制定一些準則或者是標準規範,來給各個機關有所參考的依循,以便可以提供更好的數位服務。

  • 同時,也有透過統一入口簡化平台來發展整合式的服務體驗,並且以循序漸進的方式,以小場域的試驗,最後帶動整體國家機關數位服務的發展。

  • 我們也跟國發會就剛剛各國推動的經驗來進行討論,認為準則的定位應該是在DIGI⁺方案之下很重要的參考文獻,未來也會協助國發會來進行配套措施的研擬。我們也會盤點現有規範的連結,以提供部會在推動相關計畫時,有一個參考的依據。並且,我們也會依據實作的經驗來作滾動修正我們的準則。

  • 聚焦在準則的規劃上盤點出相關的規劃文件,有這六份來參考。經過我們的分析與整理,其實可以分為兩大類,最主要是服務的設計建置與維運,因此我們優先參考上面這一部分的內容。另外一類是偏整體網站UI、UX的內容,是在下半部。

  • 配合這整個推動的計畫,所以我們優先參考相關的準則內容是屬於上半部。

  • 這是到目前為止整個準則研擬的程序,我們根據盤點研析這些文件之後,我們其實有初擬了一個草案的內容,然後經過問卷的設計調查、工作會議的進行、「Join」平台徵集的民眾建議,今天這場是屬於專家諮詢會議的部分,我們後續會將內容來進行公告試行。

  • 我們截取了各國在數位服務設計準則或規範的相關內容,斟酌我們臺灣的狀況,我們提出的建議有十大重點,像是從瞭解需求、使用者研究、建立團隊開始,到後面鼓勵數位服務及績效衡量。

  • 我們也規劃了這整個準則的結構,我們目的是要描述這整個準則的精神,因此我們制定的結構除了定義的「What」之外,也把相關的內容羅列出為何需要這個準則,以及希望這一個準則可以達到的結果;細部的做法我們也會在後續配套措施的部分擬訂說明。

  • 有關於團隊在內部討論的過程,我們是用不同人員的角度來作商討,利用服務設計的手法來討論準則的概念收斂及文字的修正。

  • 這個是外部專家會議的情況,經由外部專家來收斂我們的共識。

  • 這是我們剛提到採用的方法,最後將準則收斂成13條的內容,後續會報告13條的內容。之後我們會經過三個部會的實作,以驗證並且修正這準則。除此之外,我們也會研擬相關的配套措施及搭配的工具,來協助這一個部會實作有工具參考。

  • 我們收斂了13個準則規劃成四個構面:第一個構面是探索需求與規劃方向,我們有羅列了三條,主要是瞭解使用者需求、建構跨領域合作機制、規劃多元管道;第二個構面,我們建議除了作業程序能夠確保外,並且所需要的資源範圍、評估工具的內容也應該要包含在內;第三個,建構服務的部分,我們考量資安的部分,並且以open為優先的方式將資料開放,還要做測試、部署及擬訂離線的計畫。

  • 在服務上線之後我們也要注意到易用性、鼓勵數位使用、績效評估,要回歸到整個使用者為主。

  • 第一個構面之下的三個準則,在這上面我們建議機關應該就重要的內容、呈現的精神及需要注意的事項,我們在每一個準則下都有羅列,這是屬於重點式的提示。

  • 第一條是要確認使用者的需求,是透過使用者的研究來作確認,一般的使用者之外,也要注意到數位弱勢的部分。

  • 在跨領域合作機制這一塊要有一個領導者,另外在合作機制裡面的人員需要有跨領域的專業。

  • 在規劃多元的管道,同時也要包含非數位的部分,並且要注意到管道間切換的銜接性。

  • 接下來這個構面的評估方法,我們也有三個準則:第一,機關有別於傳統的瀑布式之外,我們同樣要把持續開發的精神及考慮到使用者需求變化,及將其回饋持續納入的內容。第二,機關要注意到資源涵蓋的面向要包含維運的部分,還要列舉使用資源的範圍,同時也要考量公私協力的部分。

  • 第六個準則的精神是,提醒機關留意評估的項目除了工具與系統外,還要評估到基礎設施的部分,評估的方式要考量到穩定性、限制性及相容性的相關問題。

  • 在建構服務與因應風險的構面,我們主要有四點:

  • 這一點的準則是,考量到資安的部分要確定服務是安全的,並且考量到資安也要兼顧到服務便利性的議題。

  • 開放的議題要列舉開放的內容有哪些外,並且也要達到激勵民間能夠創新為目的。第九條這一塊是希望能夠考量到自動化測試與部署,涵蓋的面向是除了測試外,也包含UI/UX的測試,並且也要考量到使用者的使用環境。

  • 在離線因應計畫的部分,我們要考量到包含定期的演練及可能計畫性或突發性離線的部分。

  • 在上線之後的構面及準則有三點:要顧慮到易用性的部分,使用者同時也要包含數位弱勢使用者易用性。

  • 我們希望提升民眾的數位能力,讓民眾能夠更使用這個數位服務,使機關能夠建構比非數位好用的一個方式,讓民眾去使用,不太需要再去作推廣。

  • 在績效評估方面,我們希望能夠提升整個服務品質,以使用者的滿意度為主要的目標,同時鼓勵機關能夠訂定KPI,以資料來進行整個服務的驅動。

  • 我們把剛剛講的十三條內容放到「Join」平台的徵集意見,經過三十天期間,我們獲得了九則的回應及兩個關注,還有四個粉絲團推廣效益。

  • 這是「Join」平台上的結果,我們簡單摘要,包含有民眾認為準則的定位跟名稱有需要再作確認,共通平台的主管單位應該是機關內最高的單位,民眾也建議源碼應該要開放檢視,對外透過一個獎勵機制來檢視,推動當然還是由機關內部推動,並且民眾建也有議應該要有示範的單位來讓機關觀摩。

  • 因此依據「Join」平台回應,我們提出四個主要的提綱:

  • 第一,本準則文件名稱建議修改為「政府數位服務準則」。其實源自於民眾建議的整理有提到英國「Digital by Default」跟「GDS Design Principles」認為我們應該重新檢視這一些文件,並且作一個規劃上的定位。

  • 剛剛前面也有提到,我們看了這一些文件、盤點這些文件,主要涵蓋兩大內容,第一個是涵蓋服務設計、開發與維運的相關內容,而這樣的文件名稱都是「Digital Service」。另外一類是比較偏UI/UX的參考,我們這一份準則主要的目的是要配合國家的DIGI⁺的方案,我們要落實的是指設計、建置及維運這一塊,應該採用的是屬於前面那類文件的內容。

  • 我們定位是提供各個機關在做數位服務推動的參考手冊,所以我們的名稱建議修改為「政府數位服務準則」比較適合。

  • 第二,有關於公開源碼管理與公私協力檢視,建議由主管機關統一環境,運用公私協力平台向民間徵詢修改建議。

  • 民眾在「Join」平台有給意見,認為應該由主管機關來作規劃共通平台放置源碼的地方,並且讓民間也有機會來檢視,並且增設獎勵的機制。

  • 我們建議由主管機關統一開放源碼做法,配套措施會有相關的建議及做法的擬訂。

  • 第三,第三個提綱是擇定示範單位、建立推動典範,完善數位服務推動。根據民眾的建議,也認為應該要有一個示範的單位讓機關無須摸索。

  • 我們參考了各國的做法,其實各國也是有一些優先示範的項目來滾動修正,因此我們已經擇定了戶籍、商工登記、社會福利等一站式數位服務來規劃,我們後續也會根據這個來修正準則。

  • 第四個提綱建議數位服務主辦機關規劃獎勵機制,這個也是由「Join」平台的民眾建議,應該要有獎勵的機制,我們這個做法也會提出在後續的相關配套措施當中。

  • 我的報告到此,請各位委員討論。

  • 很謝謝團隊的簡報,我們這樣子進行好了,「Join」平台的朋友們已經提出四個要討論的事情,而這四個我聽起來其實跟逐條比較沒有關係,比較是這整個東西的定位、接下來配套措施要注意哪一些方面。

  • 我們解決技術問題的同時,直接討論「提綱一」(書面第26頁)好了,我們進行的方式是會把「提綱一」走一遍,看大家有沒有什麼想法,尤其是對於團隊的擬答有沒有什麼想法。

  • 大家如果ok的話,就先把這四個走完,大家對於這整個原則整體性的東西,我們再看大家想討論的,再一個個討論,大家等於統問統答提出,如果全部走完之後還有時間的話,就會進逐條,逐條分出「why」的部分跟「how」的部分,「why」跟「how」會一起看一次。

  • 我們先看第一個,我們本來是叫做「政府服務設計準則」,但是其實涵蓋了設計建置與維運的整個生命週期。在英文的「design」,是可以擴大到整個週期,但是中文我們看到「設計」,很多人會往前面想,不會想到後面的維運。

  • 如果「設計」這兩個字拿掉的話,是不是比較有全生命週期的感覺?我不知道大家有沒有什麼想法?請任意舉手或者是不舉手發言。

  • 我先表達一下,第一個討論提綱,我覺得改得蠻好的,我同意,沒有什麼不好。

  • 照例,要問有沒有人有反對的意見?或者是有沒有別的想法?也就是字樣上?

  • 準則的項目當中,有推廣,前面有十一項主要是在設計的部分,後面兩項是要推廣的部分,少了剛剛主席提到維運這一塊。

  • 好,非常感謝。

  • 從這個團隊提供的來講,這邊講的是「自動化測試與部署」,到這裡都還可以說是功能上線,您剛剛的意思是我們從準則10開始,我看起來是維運、監控、定期演練等等,這一些都是已經在上線之後操作時要考慮的事情,我不知道我的理解有沒有錯誤?

  • 我這邊看到準則10,是找出可能想要服務的風險、進行監控等等。

  • 是寫擬訂營運計畫?

  • 您覺得這個意思是只把計畫寫出來?

  • 對,好像不一定,就語意來講是這樣。

  • 我補充一下,從準則二就可以看得到,定義服務生命週期是包含設計建置、維運,這整套是生命週期,在生命週期的過程中,都需要包含了瞭解使用者需求等程序,又或者是準則6,必須評估生命週期各階段使用到的工具系統等等,也就是生命週期在準則2這邊下一個定義,在過程當中的每一個階段推動的做法,可能都會需要用到準則裡面的各項來實作,這是我們當時在討論準則的想法。

  • 不過我也同意,純粹維運階段的考量,其實是在準則6、10都有帶到,等於是他要做這一些事,但具體怎麼做,因為這一個準則目前是「why」的部分,小字是「how」的部分,但是「what」也就是到底有哪一些要做,這個在配套措施,對不對?

  • 所以我們今天等於是在審一本書的大綱,但是書的內容還沒有寫的情況。可以這樣說嗎?

  • 關於維運的部分第5條也有提到,也就是整個生命週期,也是蠻原則性的。

  • 對,就是各項資源永續經營,這個大部分的意思並不是資本門撒下去東西做完就結束了,而是要確保大家還會活著,像這些都是有維運階段的機制。

  • 看大家有沒有什麼要指導的?我們回到提綱。請說。

  • 我也附議可以就design先拿掉。

  • 這個是題外話,其實我上次座談會的時候有提出來,我想更瞭解一下這個主責的位階,因為現在的英文名稱是叫principle,位階在前面投影片裡面第51頁當中,感覺上我們說這個是要變成像行政命令或者是相關的什麼東西,最後是否會作為機關單位在做計畫審議的標準,甚至會變成像我們講電子化政府計畫經費分配的審查原則。

  • 如果我們只是提出一個大家參考,而大家沒有落實作為的這個結論,是不是有其效益?或者這個只是推動的過程中,等於協作計畫當中先作試驗完之後再做?我想說是不是在推動的過程中,是不是可以更清楚知道這個準則的位階。

  • 現在老師的意思是,因為我們現在把它叫做「準則」。假設我們現在「設計」拿掉了,現在把它叫做「服務準則」,老師的意思是,對於底下的這一堆規範跟原則有無一定的拘束力,因為我們目前政府的網站、驗收、專案驗收等等,很多是看後面的這一些東西,也就是說,後面這個東西並不會因為準則內容而有調整,又或者是這個準則是不是可以更進一步變成要做哪一些事、不做哪一些事上的政策指引。

  • 我先講怡君跟我討論時,我的基本想法。然後如果要補充的話,也可以請補充。

  • 我對這個理解很接近院才剛頒布的叫做「行政院所屬各機關因應平台經濟發展法規調適參考原則」,也就是平台經濟的參考原則。而這個原則其實有一種是原則的原則的概念,並不是針對Uber或者是Airbnb逐案處理,而是所有看起來像平台經濟的東西,我們責成各部會在考慮的時候,一定要考慮什麼、一定不要考慮什麼,然後考慮的過程中,至少要問哪一些人等等的東西,因著這個原則又可以再去每個部會生成不同民宿、腳踏車或什麼東西的別的原則,等於是用來規範怎麼產生原則的原則。

  • 怡君當時是說叫「準則」看起來比「原則」厲害一點(笑)(怡君登愣XD),大概是這樣;底下還是叫「指引」或是「原則」。

  • 以我的理解,對這一些細體字的,就會開始逐漸有規範性,不是馬上有規範性,而是透過那三個案例累積的過程,來發現這個東西的配套措施真的是work,這個一work,我們就會開始改底下,像「共同性應用程式介面規範」先前就已經被我們改了,本來只是往open data portal交換的規則,現在變成是任何機關對機關交換的規則都寫在裡面,像這個就是具體升級的例子。

  • 我們的概念是這樣訂出來之後,底下就一個個檢視,然後一個個升級,底下的當然會有拘束力。

  • 不好意思,我可能有參與國際相關的評比,他們對這一些東西可能會有一定的要求,當他們談law、plan、project、regulation的定義不一樣,所以我會有疑惑,如果我看到這樣的準則,我要拿去對到國際標準的時候,我不知道是定義在regulation,我相信它不是law或者是行政命令或者是什麼之類的,或者是扣一個policy,我不是很清楚,如果對應到英文的話,我想資管處如何定義這個東西?

  • 我想是這樣子,像我剛剛講的平台經濟,同時是兩件事,首先本身是一個院核定的函,等於各個部會只要是行政院底下可以按照這個函來作為準則,也就是依據,這時候是regulation,也就是「院授發協字第1072000064函」,但是這個東西當然只管到行政院所屬,在別的部門或者是別的四院是沒有拘束力。

  • 雖然如此,但它同時也是參考原則,即使在沒有拘束力的地方,也就是行政院外面,還是可以給其他各院、公部門之外的第三部門及私部門來作為參考,因此同時有一個原則是對外的參考,以及對內有regulation,有這兩種拘束力。前面對外的部分,確實是不理也不會怎麼樣。

  • 這樣ok嗎?請說。

  • 行政院規定有一個準則、指引、原則,請問做這個來講,準則的約束力來講,是參考性的規定,或者是這十三項必須要依循的要求,強度是在什麼位階?

  • 以我的理解是,這個東西比較是抽象的,本身其實並沒有可以拿來賞罰的東西,這個東西會在配套原則裡面逐漸制定。

  • 但是配套原則同樣也不是針對特定的部會或特定的地方政府,所以即使在配套原則寫出來的情況下,還是要落實到底下這幾個東西,而這幾個東西裡面就可以有你剛剛所講的約束力,因此我可以說這是一份產出有約束力文件的模板,這樣可以嗎?

  • (點頭)謝謝。

  • 我有兩個問題:

  • 第一,這樣子草案的對象,首先閱讀的人是機關的人,或者是機關的領導者?在這一份報告裡面後半段第2頁,機關已經有一個做決策的領導者,所以其實是機關內部的人員。

  • 這一份資料我不確定非設計背景或服務設計背景的人是否有辦法操練?因為像上面寫到希望未來會有發布後滾動的經驗來作調整,不確定作業人員是不是可以很順利理解上面的文字。

  • 另外一點,因為當時在閱讀這一份文件,這邊並沒有提到杜拜的案例,杜拜2013年的時候提出草案的概念,2015年就順利立法了,但他們原本在2000年的時候叫做電子政府,2013年改成智慧政府,像剛剛的結構當中有提到要不要把design加進去或不要加進去,究竟是一個研究的流程或是作業手冊,又或者應考量到讓民眾有感,把價值(智慧)的部分放進去。

  • 杜拜的經驗是把它融合在一起,從e政府直接跳到智慧城市、智慧平台,它或許是一個參考的經驗。

  • 他們放入Smart Dsitrict Guideline,因為大家不一定這麼順利瞭解設計的流程是什麼,就導入roadmap、blueprint讓大家參考,而不是用準則的方法,讓裡面的文字又可以有更多作業人員自我詮釋的空間,而導致後面的經驗蒐集變得沒有那麼容易,謝謝。

  • 謝謝。我先確認一下有沒有理解錯誤。

  • 我們這個準則,像剛剛所講的一本書的大綱,你問說這個對象是給誰看的;第二個是如果這一個對象是部門的領導者,而本身沒有設計背景的話,又如何看得懂?

  • 第二個問題,我們是不是能夠有一個更精細的,有點像杜拜式的藍圖,而這個藍圖是照圖施工就不會出錯,並不是這裡面大部分的字,可能每個人看了還是有不同的想法,是不是有一個更精細的版本。

  • 是這樣嗎?

  • 對,設計裡面很多的方法論是幫助大家對焦在方法上的操練,所以收集回饋比較容易。

  • 主要是因為金字塔圖裡面寫到依部會推動的經驗,持續修正這一件事,經驗怎麼蒐集,因為以我在看的話,真的是需要服務設計背景的人才能看準則上面寫的Iterative Inclusive的那一些概念,系統設計或是工業設計背景也未必看得懂,這是我對未來蒐集上會更困難的想法。

  • 我想第二個問題比較簡單,因為這個理論上應該是研究團隊的下一步,我先講我理解的部分,在準則收斂之後就會填肉(配套措施)了,就會比較有親近性,即使不是學服務設計的人都可以看得懂,再拿這個去做實際案例,再拿做實際案例的這個經驗,一方面feedback到有拘束力的原則,二方面回來改這個準則,這個是我的理解,有可能錯了,補充一下。

  • 這邊也作一個補充,陳委員剛剛提到在經驗上的回饋,我們認為會是一個由執行團隊、國發會及機關來創造數位服務或一站式服務的共創過程,我們會逐步協助部會,就是跨越到設計的這一個橋梁,共同一起走過這個過程。一開始初期我們自己來執行這個經驗的轉換,用來作修正準則,至於長期運作上的回饋機制,我們如何做到未來部會自行運轉、動起來的機制,我們會再思考如何協助國發會一起建立這一個機制。

  • 我在這邊跟各位報告一下我們最原始的想法,其實剛剛各位提出來的意見跟我們的想法都差不多。我們訂出這樣的準則,其實我們看到裡面的一些文字或者是條文(13條),並不是純粹操作性的,比較像綱要性或者是原則性的東西。

  • 所以,我們當初的想法是先訂一些原則性的條文出來,投影片上還列出很多不管是指引或者是規範,這其實更具有操作性的文字。

  • 像有一些先進所講的,以目前看的準則,部會有沒有可能照著這個準則去做,我們也沒有那麼樂觀地認為像法令文件頒布下去之後,而部會就完全遵照這個去做,因此服務設計的這一件事對於部會來講,以我們目前的理解還是陌生的,很多部會還不知道服務設計是怎麼回事跟如何做。

  • 因此,我們原來的構想是這個文件做下去之後,包含各項指引規範都訂下去之後,我們等於會跟部會去談一些範例,以落實這一些工作,用手把手的方式,先讓部會產生出幾個服務,而根據這樣的規則、指引來做出幾個服務之後,我們才會去做比較大一點規模推廣的工作,這是所有工作裡面最剛開始起步的起手式,後續的一些工作陸續還有一段時間才有可能(落實),並不是訂完之後,部會就會去做服務設計。

  • 有回答到嗎?

  • 有回答到,謝謝。

  • 我也很認同現在討論的這一個議題,也就是「設計」是不是要拿掉,我想我是認同的,因為國外就是叫做「Digital Service Principle」,其實我們在國內,關於設計會覺得是整個生命週期最前端,因此拿掉之後,我是認同的。

  • 你說這一份文件,要叫「準則」或「原則」等等,這是很不錯的一步,也就是很重要的,雖然是很小一步,但是是很重要的,有這個依據以後,當然看看將來各機關如何運用這個草案或這個準則案。

  • 這裡面有一個重點,我覺得重點不是服務設計,我現在理解的是國發會、資策會也有投入等等,比較重點應該是在數位服務,並不是服務設計,因為非數位類的政府服務,本來過去一直都在做,服務設計的方法、內容等等,我相信這是另外一塊。

  • 現在的重點應該是當政府要把數位加進來原本的或新創的服務內容,需要有甚麼樣的因應,因此如果看這十幾條,其實很多部分是數位相關的,而非服務設計本身,重點是在數位。

  • 因此我比較會建議的是,我們在這邊討論的思考方式是,數位化跟一般服務設計有什麼差異?重大的差異是,過去會出現很多數位落差的問題,民眾不見得理解政府所採用各種在數位化上所推動的各種服務或工具,而產生相當大的落差。

  • 因此我看了這一些準則,我比較建議的是,許多的文字描述要不斷地強調是數位,而不是服務,因為當我們要把一般的服務轉到數位上的時候,會有相當大的難度,這裡面的問題牽涉很多。

  • 因此即便是第一條,就是瞭解使用者的需求,對任何設計這都要做的第一步,但這邊的重點應該還是數位服務的使用者需求。

  • 也就是服務內容與需求在數位化上會產生什麼問題,我們去瞭解它,縮小因數位化而造成不易用不會用的問題,而不是僅僅這個服務要考慮到它的需求,像我要報戶口,這本身是服務的工作內容,這應不是在草案的範圍內,而是現在要用網路或者用手機(行動載具)來報戶口,這一件事使用者的需求是什麼?因為準則的標題都是一樣的,其實準則都很像,但如果看英國那一份或國外的那一份,其實那個精神是數位服務,因此我們有提供這樣的意見,謝謝。

  • 我們可能要用粗體字或畫底線或怎麼樣,名稱本身是不用改,當然數位服務包含現有服務的數位化或者是有數位才有新服務的這兩個部分,但是老師剛剛提醒在我們的文字當中,要特別聚焦在這兩個部分,而不要讓人想到現有,而且不需要數位化服務的部分。

  • 看看老師有沒有對於這個金字塔相關的指導?

  • 這是開放性問題,如果是數位服務草案的話,目前不管是地方機關或者是主管機關,我們對數位服務的需要是迫切的嗎?因為現在在開放政府元年之後,很多資料都上網了,很多資料並不是民眾真的找不到,而是民眾不知道怎麼找。

  • 當然以這個案子為例,我覺得非常認同,其實應該定位為數位服務,數位服務的體驗或完整性可以做到周全或考量到其原則。這就回到我們對於這樣的需求是有急迫性的嗎?因為以民眾來說,可能現在的狀況是很多人在網路上就可以找得到,但操作情境是什麼與過程是什麼相對不明確。

  • 聽到兩個問題:

  • 一個是如何發現真實需求,這個是準則1;第二個是後設meta的問題:很多事情紙本臨櫃及見面已經很方便了,我們為什麼要來做數位服務。

  • 不過,這個不是我可以回答的問題,要看地方政府或者是其他老師們,有沒有覺得數位服務是否真的有這個需求?

  • 或者是大家覺得,能數位化的服務都差不多了,如果見面跟紙本還存在的話,是不是有需要繼續建置數位服務?

  • 我想回應這個問題,並不是把所有的服務都只提供數位化服務而已,我們覺得提供多元的管道,才能更便利。

  • 做數位服務準則的過程中,我們看到的是,臺灣現在希望推動的是數位政府的轉型,而最開始的起步就像林老師所講的,這份準則只是數位政府轉型或數位服務轉型的一小步,但改變的是公務機關同仁的觀念,我們會希望這份準則扮演的是這樣的角色。

  • 但是不管是進一步的規範、指引或者是其他細部一些指導的時候,我們會希望同時有不同單位的資源去推動,像我們在前一場焦點座談的時候有提到人才議題,人才的部分有包含公務機關及私領域部門的人才,公私部門都要有同樣的觀念,才可以公私協力同時推進。

  • 其實電子化政府推動了這麼多年,剛剛談到很多服務已經電腦化了,不管是業務流程或者是網路上申辦,其實都有。

  • 但是我們看到其他國家談到數位政府或者是數位服務的時候,並不是以政府業務的角度來談一個服務,所以我們希望能夠開始去思考業務跟服務是分開來的。

  • 過去的思維是,從我業務單位的角度去出發,我業務單位的流程就是這樣,但是對民眾來講是要跑很多單位,我們一直希望能夠慢慢改善這樣的狀況,因此我們大概會抓到四個點:

  • 首先,我們在推動數位服務轉型的時候,不是從業務流程來思考才談使用者需求,我們希望是從「服務」的概念來談。

  • 第二,有關於開發的方法,我們在過去政府機關開發的時候,就是要寫計畫、做標案,然後這個標案還是比較傳統的開發方式,並不是技術的傳統,而是流程的傳統,因此會涉及到招標方式、驗收方式等等,因此在這一個準則當中,我們其實會希望精進這個作業程序,但並不是馬上、立即可以改善,而是涉及到採購與驗收的方式,都必須同步來做一些調整。

  • 接著,是有關於公私協力的部分,過去是政府機關編訂預算,我們希望例如在推動智慧城市、社福照護的時候,是不是可以跟社區的關係建立起來提供服務,因此希望引進公私協力的概念,來維持服務的永續經營。

  • 第四,我們希望各機關有開放的思維,並不只是資料開放,包含了開放源碼的環境等等,開始希望建立這樣的環境,並不是單一的,我覺得這整套是整體環境建立的概念,包含其他配套措施的訂定及案例形成之後,這樣的環境會更扎實,公私協力才可以往這個方向精進,這個是我們看數位服務準則時引進的精神,也希望各位學者可以再給我們一些指導與建議。

  • 快速綜整一下。簡單來講,這個準則的「why」,最上面的是文化工作,是想要扭轉以前是公部門規劃、業務單位執行、人民被執行的感覺。現在是希望能夠用使用者的需求出發,用共創的方式來做,而做的過程是協力與開放的,因此這一個文化工作其實才是重點,比較不是有什麼迫切一定要解決的技術問題,要現在來弄一個準則解決這些技術問題。

  • 我回應陳高分的部分。我還沒有進政府服務前,覺得政府的網站做得不到位,但是進來之後就懂了,目前我在地方政府,更強烈的感受,地方政府的資源很少,我們做的事是把業務上網,若稱做數位服務,是高估了政府現在的狀況,依照英美國家對數位服務的定義,我可以說我們在台中市做,沒有可以稱得上是英美等級的數位服務,譬如市民生了孩子要跑五、六個局處去辦理業務,業務分散在線上跟線下,目前很多部分都還需要整合。

  • 老師剛剛講有一個很好的point,雖然剛剛說準則「以數位為主」,但是這個提醒也是有必要的。也就是說,如果是實體的話,機關就是長在四個不同的地方,硬要變成合署辦公室,實在沒有那麼容易,但是數位的時候比較容易整合,這也是另外一個動機。

  • 還有沒有要分享的?

  • 我echo一下蕭老師的發言。

  • 身為一個有寫過程式又當過設計師的人,我覺得數位服務跟服務設計的確是兩個很不一樣的觀念,我非常不贊成把兩個觀念放在同一個籃子裡面講完,我覺得這樣不太好。

  • 運成講得很對,服務設計有存在的必要,但可能是推動上先從文化上改變,我進來政府做一年多以來,我也覺得主要是文化上的問題,先有一個行動是好的。

  • 我看到這一份的時候,我想到的是歐巴馬在2009年做開放政府行動的文字,先有文字之後,六個月之後各部會有比較細節的操作規範,我會希望這個是開始;另外,我也反過來想問國發會,如果沒有真的達到開始的話,國發會有沒有什麼plan B?

  • 這個是兩個point,如果我們還叫數位服務設計,我們是把數位服務或服務設計這兩個不互相蘊含的概念混淆,所以就是把「設計」拿掉。第二,如果這個準則沒有取得院函或國發會函的拘束力位階的話,國發會有什麼打算?有沒有什麼對應方式?或者沒有plan B,我們就變成通過的東西?

  • 有院函當然是最好,如果沒有院函的話,其實也有其他的方式,例如像用計畫的形式,有院函能夠爭取到,等於有更大的尚方寶劍來申請計畫,但並不見得每個計畫都一定要有院函才可以推動,也許我們可以嘗試以計畫的形式來推動這一件事。

  • 我所謂的計畫是爭取科技計畫或某個計畫來試行一些服務設計,在設計的過程中,就看如何落實。

  • 處長的意思是,有一些部會本來就有數位服務的相關計畫,有沒有院函都是要做的,這個準則可以埋進去,然後要求用那個方法做。

  • 當然如果最後希望每一個部會,尤其新的數位服務相關計畫都要用這個方式做,免不了還是要用院函。

  • 這可以分成兩個stage來做,希望有回答到。

  • 我聽得出來處長的意思,如果將來是計畫,部會要來爭取計畫或什麼之類的,會看到評分表裡面可能會講這一些東西。

  • 是的,這也沒有什麼不能在逐字稿裡公開的,大家大概都有預料到。

  • 我回應一下剛剛陳高分說的部分,因為在考量民間資源的部分,第5項原則有提到公私協力,因為公私協力這個字在很多部會的計畫裡都廣泛運用,我覺得「協力」這一塊有相關的文件,可能要多著墨一點,看起來會有很多狀況,像一般性的委外,讓民間做就說是「協力」。

  • 起碼我的觀念裡面,政府跟民間單位的協力應該會有一個邊界,而共同打造一個東西,並不是踩線過去,其實民間一直都苦於被政府踩線,而導致一些營運維持不下去的狀況。

  • 因此我覺得如果公私協力的精神還要再帶進來的話,有可能在附加的文件裡面要有多一些拘束的文字,讓政府在開發這一些數位服務可以多考量一點那一條邊界在哪裡。

  • 雖然我知道國發會有很多配套,像大家繳一些資安的報告及讓APP退場,但也許在一些原則上,可能還需要著墨一下。

  • 我想APP的部分,這其實是DIGI⁺大會有提過的案子,我們逐條的時候再來討論。

  • 跟特定準則有關的部分,我們會有逐條處理的時間,並不是不處理的意思。

  • 因此「提綱一」是名稱跟金字塔,大家還ok嗎?

  • 剛剛講到文化的這一件事,我非常認同蕭顧問所講的,其實大部分包含地方政府及中央都是在提供服務,也就是把資源做整合,反而做跨部會溝通是目前比較欠缺的,就是溝通的基礎建設還在建構中。

  • 以前還沒有設計管理概念的時候,因為設計畢竟是跨學科的應用與科學,有辦法幫助到原本的傳統管理的架構,而產生另外一種共創的文化,共同打開來溝通的文化。

  • 剛剛也看到逐條的準則裡面,在價值的部分,也就是組織文化怎麼從原本這個是我的業務,而開始導入我的服務對象、並不是我的業務之單向概念的這樣子的價值……我忽然不知道這怎麼描述比較好。草案的確有提到以使用者為中心、與數位弱勢這一塊,重點是我們透過這次的案子出去,有沒有辦法讓機關在看到這一份草案時,其實是更多關於組織文化上的價值陳述,不只限定於使用者為中心,以及inclusive這樣通用的概念,可能還會有其他的價值主張。

  • 至於準則1到14,對我們來講這就是設計流程。現在叫做數位服務的研發流程,我完全認同,以現在的概況來說,先把流程顧好,而怎麼樣再帶一些文化進去,讓機關是可以感受到的,我覺得可以再討論一下。

  • 這部分是不是請團隊在接下來做配套措施的時候,儘量多一些價值主張跟價值論述,這個東西讓看到的人不但是覺得可以照表抄課,而且覺得被感召或者是感動之類的,要求當然比較高,但我覺得真的有幫助的時候,用正確的圖片可能比文字更有用,在感召方面。

  • 看團隊有沒有要回應的?如果沒有的話,我們這一條就過去了。

  • 我們進入到「提綱二」,這一次提綱都會整體回應在「Join」上,對網友留言的具體回應。

  • 「提綱二」提到:有關公開源碼的管理與公私協力檢視,建議後續由主管機關建立統一環境,運用既有公私協力平台向民間徵詢修改建議。

  • 團隊的建議是會在有血有肉的配套裡面去提出建議做法,我基本上這樣看起來是參採的意思,但有參採,但是具體怎麼做裡面會寫。看大家對於這一點有沒有任何想法、期待或預期碰到的困難,或者是任何想要分享的?

  • 既然開放源碼了,也不是只是擺在那邊,所以有人提建議要偶爾回應一下,這好像是良知良能等級的東西,也就是團隊放在接下來的配套措施裡面,這個就是參採就過去了。

  • 接著討論「提綱三」,有一個標竿學習或有幾個標竿學習的示範單位,讓其他單位有模仿的對象,尤其是在一開始推動的時候,那個配套方案還沒有很具體東西的時候,不被看到的,像剛有提到很像自行摸索的感覺,因此及早建立典範可能是滿重要的。

  • 團隊的回應是戶籍、商工登記及社會福利這三個其實在之前的交談座談上已經有選定當作新的設計規範的試辦方式,是不是請團隊補充一下?

  • 我們在參與設計的過程中,在一開始的時候,我們希望跟部會一起參與與討論,包含像經濟部、衛福部、內政部,我們都有跟相關的主管機關來作溝通。

  • 後續會擇定目前一站式服務所要推動的主題,對於民眾服務有感覺的一些服務來進行調整、現況設計,這整個的過程中,我們會收斂到特定的問題,然後透過在準則裡面所談到的一些精神來檢視跟推動,也會嘗試到底適合用什麼樣的手法來解決這個問題。

  • 在這樣的過程中,我們希望能夠回應到在準則上的修正或檢討,又或者是在配套措施的設計上能夠更完善,以上是我們的說明,謝謝。

  • 我覺得「提綱三」非常好,尤其服務設計是比較抽象的,我們要讓它有好的範例出現,像管理學都會學範例,這是非常好的動作,我對這個提綱沒有問題。

  • 但我對「提綱三」的建議有一點小建議,這三個服務目前都已經在執行,就是已經有預算在開始做一站式的服務,資訊系統也都開始在做了,因此原則上這三個服務,如果不重新開始按照這個準則重新做的話,其實沒有辦法來檢視我們的準則。這三個一站式服務都是由主辦單位根據過去的經驗來做設計,其實並不是這個準則所強調的以使用者為中心的設計。如果第一步都沒有的話,我不知道要滾動修正什麼。

  • 因此,我建議前面文字都ok,也就是「我國已擇定戶籍、商工登記、社會福利等業務試辦一站式數位服務」沒有問題,但是後續「要讓主辦單位根據此準則來進行服務設計、開發與維運,再看這一準則有哪一些窒礙難行或不足之處再滾動修正」。準則是在討論「服務設計、開發與維運」,要做就需從頭做,不能省略以使用者為中心的服務設計,因為準則就像剛剛台中市蕭顧問講的,其實離目前政府的服務有一段距離,我們必須承認這一件事,但我覺得我們有機會做,而且要做的話,在這個時候就要有一個比較正確的策略來做,我建議這個「提綱三」的建議要改成這樣,以上參考。

  • 謝謝。剛才的順序是小彭、老師及這一位。

  • 我的第一個問題其實也類似,一站式數位服務,其實國發會也規劃滿久了,看起來是已經啟動了,因此後續再擇定一些其他的方案是從頭開始的,不然會難調整。

  • 另外一塊是不是要考慮這一個部分跟某些地方政府合作?因為這次的準則,不管是要擇定跨機關的協調或者是前期規劃設計的中間過程持續修正,至後面的一些回饋,這部分其實對公部門的採購是很新的東西。

  • 這樣新的典範進來之後,勢必成本是會增加的,在舊有的預算當中很難就新的典範去執行,即使中央單位決定可以做,到地方政府下放的時候,其實都會有很大的門檻,甚至要擴編這個預算的話,議會絕對不可能過,特別是一個系統要擴編預算。

  • 因此我會覺得如果有機會的話,中央就這樣的準則,帶一個地方政府可以一起做,也會幫忙到地方政府的經驗累積。

  • 謝謝,我們統問統答。

  • 事實上戶政已經一站式服務,在之前都已經存在了,有商工登記及數位服務都是類似的,如何對應這十三個準則的實現,我覺得這個確實與之前提出的問題上有一些差距。

  • 所謂第一個釐清,也就是推動準則的目的是要做什麼?是為了驗證這個準則的可行性?或本身只是想要藉這樣的示範案例,對這樣的準則有感、發生新改變?如果是前者的話,或許前面三個像戶政、商工登記及社會福利,對於這十三個準則當中,已經有缺、少哪一個部分,我們提出這樣的建議、規劃,主要的目的是在做解釋的動作。

  • 如果從頭開始的計畫,我們需要的時間可能就變得比較長,那部分或許下一個階段重新開始在新案例、新典範建立,可能會比較好一點。

  • 我有一個小疑問,因為剛剛很多先進針對位階有做很多討論,準則是guideline的guideline,如果現在要做一個示範系統的話,是不是要先把底下參考文獻的施行細則或作業原則也要先做出來,然後再丟到這個平台,然後再回去談,因為感覺上這個建議好像中間完全把參考守則這一段忽略掉,因此我不太清楚是要先做參考手冊,然後再做示範系統,是不是要把這個過程提出來,這個比較具體一點。

  • 我們先有準則(1),然後用共創的精神把配套措施弄出來(2),接下來才導入各部會服務的相關計畫(3),然後再滾動修正(4),滾動修正可能是來改一大堆有拘束力的東西(4.5)。

  • 因此您剛剛問是不是先有配套再導入,當然先有配套,但是適用性不可能強到一體適用,可能是先導到那幾個來用用看。

  • 剛剛有幾個我覺得非常好的問題,我綜整一下:

  • 第一,以我的理解,我不確定戶政現在是哪一個案例,因為戶政非常大,裡面有非常多的系統,商工跟社福在焦點座談當中都有提出具體的建議,因此是要重新開機或是要檢視缺漏的部分,這可能是團隊要先回答的問題。

  • 第二,是不是就主辦單位的導入要引入地方政府,如果要的話,要如何確認議會的支持及窒礙難行之處,這個克服是不是要放到文字當中?

  • 針對先進的意見,承辦單位在這邊回覆。

  • 我們上面寫的戶籍、商工登記、社會福利來試辦,文字確實寫得不夠精細,誠如各位老師所說的,這三個業務已經在很多年以來,都已經陸續在推動線上申辦或是各機關介接的服務了。

  • 但是我們發現這三個部會推動的內容,對於真正便民的部分,有一些gap需要再努力,因此陸續在這幾年都有提出四年的中程計畫,每一年度都必須針對某些特定的業務。

  • 舉個例子來講,社會福利跟十一個縣市政府來合辦簡易福利申辦的業務來進行數位服務的設計與改造,因此我們就會針對他們預計要做的新工作項目,跟這一些部會一起來試辦先前所設計的社會服務設計準則,從陪伴的角度共同瞭解我們現在所規劃的這十三條準則是否有缺漏。

  • 後續需要跟各機關就試辦過程中來瞭解並作修正,也就是準則是否夠完備,或者是在評估的過程中是不是有要考慮的細節,我們必須要考慮進來,因此必須透過試辦的工作項目執行完畢之後,然後再回過頭來檢視,並讓整個準則更豐沛。

  • 至於,剛剛有專家所提到與地方政府合作的部分,我再舉社會福利的例子來講好了,這個業務其實一直都跟地方政府有非常密切地合作關係,去年度也都跟十一個縣市政府在資訊系統上重新改造,讓整個申辦業務更精進、更好的一些措施。

  • 今年度還會從這樣的角度再去擴大執行,因此地方政府在今年度也是我們要合作的對象之一。

  • 以上簡要補充說明,謝謝。

  • 大家看「戶籍、商工登記、社會福等業務」會想得很大,但實際上是少數領域新規劃的部分,所以既有的還是跑,但是現有的一站式還是做,但是有一些新的部分可以導入的,舊的部分來導入,而不是整個業務來導入,我想這一個中文字的字樣,沒有人會這樣解釋,所以字眼還是要修正(笑),所以新規劃的部分還是要強調出來。

  • 第二,這三個部分跟地方政府的介接是用部會現有的計畫,所以應該不會用到地方政府的預算,自然不需要跟議會爭取,至少在試辦的部分。

  • 我覺得部分解釋清楚就好了,但是我提一下針對這個議題,提綱叫做「擇定試辦單位」,我覺得建立典範是對的,但是「擇定試辦單位」會跟準則2 against,因為要跨單位,擇定單位可能是擇定主辦單位,然後另外的單位是協同。

  • 如果選一件示範,可能是A單位佔80%的工作,另外再加三個單位,每個是7%,我覺得這個相對一定很簡單來做,我們是不是有機會選一個,也就是每一個單位都是出20%力量的那樣典範,我想那對於示範性會更強,但是示範性有時是為了找答案、有時是為了看到問題,但這個要看原來的設計,我只是提出這個想法。

  • 看題目是不是也可以把「單位」拿掉,就是變成「典範」就好了。

  • 很好啊!基本上老師的意思是,因為三個領域,不一定是2+2+2+2+2或者是7+1+1+1的情況,我自己覺得兩種都要有,才能驗證不同搭配的情況。

  • 字樣上老師的提醒是,講「單位」總是有單一主責的感覺,因此不管是擇定示範的服務、議題或別的,都比「單位」二字好,我大概也可以同意。

  • 我另外的問題是,因為我們這邊寫「單位」,但是準則裡面都寫「機關」,以商工登記來說是很大的跨機關,包含了經濟部、財政部、勞動部,甚至有國貿,就是為了英文名字。

  • 因此以這樣的單位來看我們的準則,我覺得它其實是很好的測試case,但這裡面後面可能想要提的是,因為準則裡面都寫機關,並沒有挑明哪一個機關,因此以這樣來說的話,這個是測試準則上最有趣的地方。

  • 但是以準則第13條是寫「機關宜採用合宜之衡量指標評估服務績效」,政府單位最有趣的是,跨機關的績效到底是哪一個單位,而這個準則當中,國發會如果在做輔導的時候,這部分其實會相對困難,這也可以拿回來做回饋,有一點像國發會做「Join」平台的時候,那一個是主責單位。

  • 我反而覺得這三個案子其實我覺得還不錯,至於要不要找一個新的案子,找一個新的案子,也許這一個準則還有下面的條例都很清楚的時候,如果還有「電子化政府計畫」的話——我們改名字了——我覺得還可以從那時做一些新的場域。

  • 我們逐條時會回來看。不過,「評估服務績效」,這個績效講得很明顯是服務的績效,並不是機關的績效。

  • 在管考原則當中,今年有一些新發明,像「跨部會KPI」,或是「Join」平台的「多主責處理原則」等等,大概都是在現有榖倉效應底下,試著找一些跨機關的方法去做,我想在運行準則13的時候也必然會碰到這個情況,謝謝老師的提醒。

  • 這個提綱裡面有提到要「滾動檢討準則內容」,這一點我比較有疑義,「準則」從文字上來看就是「準則」,而且既然是準則,所有的數位服務的項目應該多少都要依循,而且是參考。

  • 有一些準則彼此之間真正執行下去的時候,本身還有衝突,必須要做一些決策與選擇。

  • 因此找出一個示範的項目或者單位來做這一件事,回過頭來修改準則,我比較不理解,因為這個準則已經經過滿縝密的規劃,也參考國內外相關的原則與準則等等,目前看不太出來有這樣的需要,但是這邊卻有這樣的說法。

  • 我覺得比較不需要在準則上去修正滾動,因為我們並沒有強制規範在實務上要怎麼做、包含什麼項目,並沒有的。

  • 應該是要去檢討評估示範項目依循準則執行後本身的一些問題,針對示範項目的成效進行使用性等等的滾動改善,而非修改準則,這是我提出來比較有疑義的部分。

  • 剛剛也有提到要選擇示範單位,因為我們挑示範單位也很奇怪,我看歐美是講「示範項目」,所以事實上我們的準則內容也有提到「示範項目」,這常是跨部會的服務。

  • 謝謝。「項目」是可以用的字嗎?還是要用「專案」?好,「項目」是可以的。

  • 剛才老師講的是,滾動修正的標的至少應該是「準則及其配套措施」或「及其相關原則」之類的,不然大家一看就是改準則,那我們配套原則要重寫嗎?

  • 因此,我們要回來修正準則時,至少要涵括準則後面的範圍,應該要是修正準則及其配套,或是準則及其相關原則之類的,這個交給團隊去斟酌。

  • 我想要補充一下有關地方政府這一塊,因為我曾經是區公所第一線的人員,我同意有一些是系統可能是中央跟地方互相連接共同使用系統,這一塊如果要分析使用者回饋經驗的話,可能是公務員的經驗,其實是實際使用系統的人,如果今天讓民眾有感、一般大眾有感的系統,那個系統就有可能注入在地方政府所動的系統上。

  • 我剛剛想提的建議是地方政府非常有限資源的部分,其實真的滿難落實的,如果這一次的試辦有一個是跟地方政府比較密切合作的話,其實也變成以後其他地方政府有一個依據,然後拿這個來作典範。

  • 因為剛剛聽起來是,中央與地方互相連接的這中間,不是地方對外的那個層次,因此我覺得這可能是要區分一下。

  • 我想社福裡面當然要讓地方公務員能夠受到幫助,這個我想很重要,但是有提到不對外嗎?社福應該是民眾有在用的。

  • 可不可以看哪一位要回答?

  • 這個部分我想將來不管是蕭老師提的在選案時主導權的比例,或在座也有台北市、台中市的資訊局或顧問在這邊,如果有興趣的話,也非常歡迎可以參與我們的示範(笑)。

  • 歡迎加盟的意思(笑)。

  • 要取得良好體驗,不只是地方公務人員,目前感覺上商工登記同樣也會有一些地方需要商工登記的朋友,還是會碰到民眾,但是量測的方法是從中央這邊去量或者是培力地方政府去量,假設錢不是問題的話,也要看地方政府執行的能量,這可能是沒有辦法在這個level去處理的;但如果可以執行能量的話,我們也樂觀其成。

  • 第三題就這樣了?好,那繼續。

  • 第四題是常常都會出現的,我就不免俗唸一下。做得好當然敘獎絕對不是問題了,但是畢竟是新的東西,也就是做得不好,是不是也敘獎呢?或者是不是讓機關內部也有一個推動的動力,是誰可以回答的呢?

  • 我想在政府機關都滿重視國發會有一個「政府服務品質獎」,我不知道是不是改名字為「政府服務獎」,雖然改名字了,但是本質、出發點還是基於鼓勵政府機關在做服務的創新。

  • 當然那個獎項最終的方式是評核那個服務有沒有創新或者是對民眾的感受怎麼樣。

  • 現在大家來討論的是這一個服務最前端,一開始是設計的過程,但是我們會去看看在評核的過程中,有沒有辦法把這一個項目也加到例子當中,雖然品質獎裡面看到的服務最後的結果、民眾的感受、對於公務員等等的改進,但我們也希望在評核的這個過程中,看他有沒有運用我們的這個方式來達到最終的目標,也就是有一些激勵可以在此呈現。

  • 處長的意思是目前是:一個是整體服務類,一個是專案規劃類,專案規劃類感覺比較像。但是專案規劃類目前的這一個評核構面,目前看起來還比較沒有把我們這些東西埋進去,只有把開放參與與創新性這兩個,而且只有10%,看起來非常少,處長的意思是調整佔比或乾脆把這調和式的直接埋進去,或者再加數位服務類?

  • 目前沒有放進去是,因為在討論的階段過程中,在品質獎裡面還沒有成形,因此比較難講說這個東西希望能夠佔幾分,因為會問我們這個東西在哪裡,因此有一些時間上的落差。

  • 我們希望很快有運用之後,我們希望趕快跟領獎機關、單位,其實就是國發會的社發處,我們再跟他說看看要佔比多少跟用多少的指標。

  • 如果3月中旬有一個版本出來的話,決審就可以拿去用;如果沒有的話,可能就要明年再聯絡了。

  • 應該是明年。

  • 對,那就應該是。

  • 這樣也不用擔心時程,因為反正明年1月再辦一次就好了,所以這樣子聽起來是2019年的政府服務獎,這是很有機會放進去的,看大家對這一題有沒有什麼想法?有沒有什麼可以激勵大家來加盟的措施?

  • 因為服務是比較抽象,但又很縝密的過程。我們先不管有前台、後台是否一起運作,但關於服務這一件事,是會有其急迫性。

  • 像我現在是受災戶,我需要很快申請社會福利,所以其實在地方政府,很多第一線人員被打擊是因為不知道這麼多的規則跟程序,急迫性是必須要被優先考量,有別於中央政府處理事情的方法。

  • 因此在服務的評比,地方政府可以協助我們去理解如何滿足這些有急迫性的民眾對於服務的需求的相關洞見,而不只是效率或其他的指標。

  • 所以你剛剛的意思是,如果運用這一些東西,能夠讓第一線人員可以更有時效性地提供服務,本身就是自己的獎勵,不用特別敘獎,是這個意思嗎?

  • 其實第一線的人,可以幫我們蒐集到很多相關的資訊,或許可以幫助我們得到更多更有效的資訊。

  • 所以這個機關內部推動的意思是,不只是機關內部的決策者或者是管理者,也包含第一線人員。

  • 你的意思是,第一線人員要放在機關內部推動有主動權的人裡面,是不是?

  • 另外,「政府服務獎」是不是可以放在回應裡?

  • 現在還太早了?

  • 我認為至少兩年,因為評估比賽的標準至少要前一年。

  • 是,今年好像1月15日才剛辦。

  • 老師的意思是評選的標準要前一年訂定。

  • 等於今年年底公布,可能有一點太趕,因為這是憑今年的計畫,明年頒獎。

  • 所以老師的意思是2019年的計畫,但是實際上拿的獎是2020年的「政府服務獎」。

  • 到這個程度,可以放在回應裡面嗎?還是也太早?

  • 因為我當過好幾次委員,這個作業規範其實滿縝密的,而且牽涉到資管處與別單位的協調。

  • 另外,要做這個評分,criteria能不能放進去,另外一個單位通常都是還去做了研究計畫,然後再看criteria的百分比大概要多少,我個人會比較保守,是不是可以一下子就把這個東西嵌入,我覺得保守估計是兩年。

  • 我建議暫時不明確寫「政府服務獎」,因為我們是說後續提出執行做法,因此在今年、明年,其實可以在適當的時機有適當的方法,像之前在開放資料的時候,曾行文給各單位,請各單位對於推動資料開放有關的人員敘獎,這個對於推動的同仁來講也是滿實質上的一些回饋,我想再適當思考一些配套措施。

  • 好,所以這樣聽起來是可行方向。先不要寫具體的獎項到回應的建議裡面,基本上就是按照這一個字樣來寫,最多加上由機關內部推動時也可以適度考慮,像第一線人員這一類的,參與的部分大家應該是沒有什麼問題。

  • 「並不只是民眾的建議,也包含第一線人員的建議」,我覺得這個很重要。

  • 至於特別獎項的部分,就留給有力氣來看逐字稿的朋友作為彩蛋,就不寫在裡面。

  • 其實我們還是有一些時間,所以在我們進逐條之前,大家有沒有別的整體性詢問,或想要提出來的任何分享或看法?

  • 抱歉,各位先進,因為我過去擔任過聯合服務中心主任,也推動過類似資訊服務的計畫,因此有一些經驗可以跟大家分享。

  • 這個案子本身的數位服務範圍很高,包含網站、WIFI、Open Source等很多項目,但是真正讓民眾有感的是申辦項目,事實上和民眾直接相關的項目,不外乎申請、陳請、訴願、國賠、消保、勞工申訴及採購申訴,如何透過我們的努力讓民眾享受到便利 才是重點。

  • 而便利推動的幾個方向是,服務通路整合、服務資料整合、服務流程整合、服務進入整合。

  • 在準則中我看到數位與非數位的部分,事實上非數位管道也就是實體通路可能對一般民眾可能更重要、更直接,如何讓各項申辦項目都能作到跨區、跨縣市申辦,也能在單一櫃台完成各項申辦服務,這不僅需要完整資訊系統的支援,如何建立友善的UI讓沒有經過很深的訓練的櫃員也可以受理及處理民眾各項申辦項目,絕對是值得我們努力達到的目標。

  • 再者,有關於資訊整合的部分,政府講了很多年的跨機關免書證謄本,但事實上卻沒有真正的落實,而現在跨機關間的資訊流通仍很欠缺,例如一個學生在同一縣市從甲學校轉到乙學校,資料是不是可以直接過來?我跟各位報告,很多學校至今仍必須是要靠紙本交換,同縣市如此, 更遑論是跨縣市政府間的資料暢流。 。

  • 而在介面設計上,我們應想辦法做一致性的體驗,對民眾會有很大的方便,並不是到甲機關是這樣的方式,到乙機關換別的方式。

  • 我真的不希望準則訂出來之後,只是一份文件,希望可以真正改變現在民眾所遇到不愉快或不方便的經驗。

  • 我班門弄斧,實在很不好意思,但講到這邊,我實在忍不住做這樣的意見陳述。

  • 謝謝,非常有幫助。

  • 這段不用綜整,其實每一句話都是重點,但是我還是試著綜整一下。

  • 其實民眾最有感也就是目前一定會做的事,像申請、申訴這一些東西,目前就是有一些卡住或者是讓人不舒服的地方,如何讓這一些東西解除掉或者是簡化,可能比我們再把網站弄成漂亮的,讓民眾更有感,因為就是有這樣的需求,存取這樣的服務。

  • 像流程、通路資料或金流方面都給了很具體的指教,我們一開始挑的這些個案必須要是接地氣的個案,這跟小彭剛剛講的,不要「只是讓櫃員的UX變好,但是民眾的感覺並沒有變好」——其實這樣也是有貢獻——但並沒有那麼有貢獻(笑)。我想這個是非常重要的,謝謝。

  • 看其他的老師有沒有想回應或提出的?

  • (與會者皆無意見)

  • 我提一些想法讓大家參考一下,也就是我們今天對於要做數位服務準則、配套措施、示範案例,大概都有一定的共識,這是我自己的覺得,大家也覺得非常該做。

  • 接下來就是要做多快及如何落實的問題,該做但如果沒有做的話,就流於空談,我想台北市的高副局長應該是有這種焦慮感。

  • 我提一個建議給主席參考一下,如果仔細看目前我們follow的國外案例,最具體的是英國與美國,澳洲是跟著走。你看這兩個單位,其實都有不小的核心組織,我知道政府改造有一定的困難度,但我覺得既然要動起來,政府的組織要有in-house設計師來協助完成服務設計。我覺得這個滿重要的,也才有機會擺脫過去服務往往都沒有以使用者為中心來設計,這個是第一個綜合建議。

  • 第二,我們目前比較欠缺的是東亞文化,剛剛大家都提到文化的問題,西方在做事的方式其實跟東方不太一樣,我們參考的方式是英國與美國的做法,我們當然可以嘗試內化是不是有機會可以達到一些效果,這個是一個方式。再者,我們應該看一下新加坡怎麼做,跟大家分享一下,新加坡在這幾個政府當中是做得非常好的,跟設計最有名的公司IDEO等都是一起完成非常具體的案例。

  • 這個團隊有沒有要回應的?東亞,不管是新加坡、日本或者是其他的。

  • 新加坡目前也是我們在研究的範圍,因為有承諾這部分會持續給一些資料,所以我們會納入。

  • 像IDEO的合作,資策會過去來講,我們有發展服務體驗工程的創新服務設計方法,曾有一些研究方法的經驗累積,另外也曾經跟德國Fraunhofer IAO合作,我們也會考慮用一些過去相關的研究成果進來,看看是不是多一些自己的案例,或是日、新加坡等東亞這邊的案例來補充與加強,以上說明,謝謝。

  • 各位好,我稍微補充一下有關於數位服務可能的影響與邊際效應,其實數位服務跟存估最大的不同是數位服務可以產生很大的資料,在第13點的準則有提到的是,可以透過資料服務來衡量績效,目前的敘述是以各個機關訂定績效指標的角度去蒐集數據分析的服務成效。

  • 以目前實務上商業界做事的方法與這樣的敘述上稍微有一點不同,舉一個例子來講,在網站或是數位APP的資料或使用過程中,都已經預先埋好可以偵測的指標或相關的方式,可以去監控整個使用的流程。

  • 而這個流程的本身可能會帶來新的洞見與意義,並不是在一開始就可以被預見,因此可以訂定KPI,然後再衡量數位資料是不是唯一的方法?

  • 因此,我建議是不是準則當中,有一些政府的聲音是否有「我們允許不允許類似這樣的狀況來申請使用者蒐集情境的資料?」我們可以說很中性,也就是匿名,要同意之後再蒐集。

  • 或者是我們可以更積極一點,也就是鼓勵或者是開放,因為現在的描述當中,比較像只有主管機關決定KPI之後才可以申請,對於目前商業界的使用角度來講比較不太一樣。

  • 我的建議是:是不是加中性或是我們非常保守,一定要匿名、積極一點來開放鼓勵,因為對於設計團隊、研究團隊來講,這個相對來講有相當程度的助益。

  • 現在一般型的部分,我們政府的態度是什麼?我相信在這部分可以加一點著墨,也就是中性、開放及保守的態度。

  • 我們到準則13的時候一併討論。

  • 這個是滿重要,但是也滿有爭議的話題,所以這比較不是綜合性的部分,我們先把綜合性的前提先收一輪,但是有記起來。

  • 看大家有沒有別的想法?

  • 我回應一下剛剛陳副主任的想法,我也贊同政府間要有一個in house的設計團隊,會比較容易推動這一些事,像有採購法的時候,很多資訊公司是從外包來的,因為沒有in house的資訊團隊來做這一件事,所以我們會需要很多時候要等採購法的流程,必須要跟外部的資訊公司介接。

  • 然後要有可能合作經驗的廠商,而那一些廠商可能是跟政府有長久合作關係之後,知道如何跟政府合作。

  • 因此在設計這一塊,我特別想要補充的是,國際上各國政府有設計團隊的政府,他們的設計會著重在公共服務設計,不是服務設計而已,這邊可能是我們要特別加強的地方,當我們成立這個團隊的時候,不只是看有服務設計的專家,或是各種設計領域的專家,更重要的是他們有跟「公部門合作過的經驗」。

  • 我們團隊的兩個設計師有特別跟英國GDS的設計團隊接洽,他們現在有一個國際上公部門設計師連線的線上群組,如果資策會需要的話,我們也可以提供一些名單,就是可能作為研究的參考。

  • 我覺得很有趣的是,因為設計師很喜歡互相面對面認識聯絡感情,我們不管去哪一個地方出差或者是有人要來臺灣出差的時候,我們就會稍微見面聊天一下,像18F跟後來要成立的一間公司叫做「Nava(https://www.navapbc.com/)」,他們都有跟我們聯絡過,還有很多其他不同國家,除了英國美國、一些其他的歐盟國家也有一些聯繫。

  • 起步的時候當然要做很多研究,然後去參考別人曾經打拼過的經驗,所以我覺得研究當然可以參考亞洲這一塊,才不會漏掉,也有很多公共服務設計,也就是civic service design的principle,這個也正在撰寫中,給大家參考。

  • 不好意思,逐項的部分我已經用紙本寫好了。

  • 我唯一一個比較遺憾的建議是,也就是未來是不是可以納入「運用資料以利決策」,因為這個東西的感覺,也就是這個位階都已經既定的服務,也就是怎麼樣能夠把這一些資料,真的是到比較上位的決策,也就是相關準則的精神放進去,其實以前座談會有提,也就是未來是不是有考慮真正機關單位在做決策時,實際上可以把data driven、evidence driven的想法放進去,謝謝。

  • 我稍微回應一下設計師的說明,其實一開始在做區域性,像臺灣、日本、韓國、新加坡、泰國的公共服務設計,所以他們自己在做,他們並不用civic,而是用public,然後有一些事情是在進行,給大家參考,如果有機會的話,也可以promote這樣子區域性的設計,謝謝。

  • 我補充一下其他可能可以研究的資源,像Global Service Design Network,在世界各地有很多據點,每一年也會發布相關的報告,所以做跨文化的比較,我記得2013年、2014年都有過,如果需要聯絡窗口,也可以跟我說。

  • 另外一點,芬蘭在公共服務設計的專案上一直都有開放資料,包括產、官、學、研合作,包含地方及中央的資料,其實都很多。

  • 芬蘭導入公民科技也很久了,所以或許也有一些參考的依據,謝謝。

  • 我補充一下在data driven的這一件事,我在其他的場合,如國發會的會議都講過,現在網站上服務與剛剛朱老師期待的data driven是對立的狀況,也就是業務導向,如果也用一個近似的英文來稱呼的話是「owner driven」,也就是這個業務誰own,那個人就從頭導到尾。

  • 像前面有提到user driven、service driven,然後再加data driven,都要去翻轉現有owner driven的思維才做得到,因此我們需要把更高層的價值或者是上位meta講清楚。

  • 建構數位服務也好,或是將來的一站式服務也好,並不是處理技術層面而已,可以看做是將過去流程、思維的大幅調整,owner driven的做法要先換掉,過去操作的方式要轉個180度、90度,用這樣上位思考來溝通會更精準一點,有了這個指導出來,執行端就知道要朝user driven規劃,從業務導向轉到data centric之後可以做data driven。

  • 大家有沒有要一起提出?我綜整一下,從後面到前面回覆。

  • 剛剛蕭老師提了一個很好的想法,尤其在配套措施的部分,我們這邊都是寫一堆要做什麼,很少寫不要做什麼。或者是特別說「機關宜」怎麼樣,但是幾乎沒有寫「機關不宜」怎麼樣,但是有些概念是有一個「之前」跟「之後」:本來是這樣子,但有些時候這其實不是好主意。

  • 這個說明可能不要太強烈,但還是滿有幫助的,就是給他一個名字,不管是叫owner driven或是叫做業務導向之類的,儘量用一個中性的名詞,然後說試著從這個範示轉到新的範示,不是說舊的就立刻丟掉,而是希望新的可以給出創新的做法。

  • 我自己聽起來,也就是在前言的部分,因為目前這是非常正能量,也就是做了很多東西會很棒的東西,但是前面可以加一點負能量,現在面臨怎麼樣的挑戰,而這個挑戰,我們給他一些名字,請研究團隊參考,我覺得這個是非常好的想法。

  • 同樣的道理,目前在「循證決策」普及之前的狀況,這要講什麼呢(笑)?我們可能也沒有發明一個很中立的字樣來講,但是我們確實可以在前面的部分,可以用比較概念式的陳述:推動數位的設計之後,想要達到好比像使用者服務的資料,作為設計或作為整個機關提供服務的願景等等。

  • 因為目前是要做這一些,是當下的,但比較沒有一個過去式,本來沒有要做什麼,以及我們未來這個做完之後還可以做什麼,比較缺少的是過去、未來這兩塊,我想這是很適合在前言的部分,不是在配套措施,因此必須在準則層級處理。

  • 如果大家覺得ok的話,這一頁差不多就是這樣子。

  • 至於設計網絡,大家請互相換名片,盡可能互相認識大家。我們去看不管是美國或者是英國,不只是公部門裡面的核心團隊,等於是in house的廠商,大到一個程度就像在美國還是會被批評說18F搶民間廠商的生意,所謂踩線就像小彭剛剛講的,大到一個程度的時候一定會發生的,我們這邊法人們也多多少少會被這樣講。

  • 我們的意思是,看美國的例子,很多是第一批在18F的人或是在USDS的人慢慢到外面成立社會企業(「社會企業」即解決社會問題的企業),他們有一個網絡可以更有效跟內部沒有非常大的in house團隊去作接合,我想這個模式很可能是政治上唯一可行的模式,所以這部分有賴於大家互相network起來,這個是非常實際的狀況。

  • 我非常同意要有組織上的awareness,其實英國GDS原則裡面,有一個很重要的是,每一個這種新服務,部長都要從頭跟到尾——我如果沒有記錯的話——不知道是為什麼沒有進到我們的準則來。可能是在德爾菲法裡面,大家沒有覺得這個很重要,所以到最後就篩掉了(笑)。

  • 但是我覺得部長層級從頭跟到尾——至少前幾個案子——我覺得這個滿重要的,即使不寫到準則裡面,我們執行上這必須要提到相應的位階,也就是剛剛所說尚方寶劍的意思,我想大家多多少少都有體認到這一件事,我會儘量幫忙。

  • 尤其從第一線的角度來看,我想民眾有感的這一套流程,我們可以請團隊稍微綜整一下,然後在配套措施的那個層級,儘量地把怎麼樣是第一線公務員有感、怎麼樣是民眾有感的部分,如何落實到十幾條的配套措施當中,盡可能把剛剛老師提到這些部分放進去。

  • 因為尤其一開始挑的那三個案子都會同時碰到這兩個部分,因此如何讓大家知道如何不是在完全犧牲第一線的公務員的肝去換取民眾覺得比較方便,像跨區申辦,就是第一次申辦護照要做人別確認的時候,就有一片聲音說讓基層人員爆肝,但事實上並不是,我們是靠機器對機器的方式去介接,這個在配套措施當中,儘量不要讓人覺得是犧牲民眾的感覺去換第一線承辦的生活方便,或者是犧牲第一線承辦的生活品質去換民眾有感,我們是透過數位的方式同時兼顧到這兩個需求,這可能也要落在文字裡面。

  • 統問的部分,不知道團隊有沒有別的要回應的?

  • (與會者皆無意見)

  • 我們也到表定的結束時間,但是其實場地還可以再用一個小時,所以如果需要先走的人可以先走,我們還是回來把準則都過一遍。

  • 前言的部分,剛剛講到過去的部分跟未來的部分,這個應該就是這樣子,如果大家對於前言有什麼想法也很歡迎現在提出來,如果沒有的話,我們就進入到「準則1:了解使用者需求」。

  • 粗體字都是「why」,就是為何要做這一件事,接下來細體字是為何要做這一件事的基本大綱,為何要做這一件事是為了要設計服務使用者需要的服務;大家都ok嗎?如果有任何的字樣、字眼或標的符號等等的修正都提出來,沒有的話,就過去了。

  • 要怎麼做呢?是「讓使用者樂於使用」,為了要做這一件事,我們要先界定他們是誰,確定是融入生活、且是需要的服務,並不只是想要的服務,而且考慮到數位弱勢需要協助的管道才能使用,這些都考慮到之後,還要持續共同探索,因為現在覺得樂於使用,而且覺得過了兩、三年,隨著所有的服務都一直在水漲船高,他們會覺得公務體系的服務不太好用,而且其實沒有變過,但這個其實是要一直精進的。

  • 我幫朱老師轉達一下,她有提到我們說有持續進行使用者的研究,朱老師提到「研究」所指為何?研究的範疇跟深度是不是可以在配套措施裡面再加以說明?

  • 接著我們有提到「確認服務是融入使用者的生活」,而且是「需要而非只是想要」。朱老師提到「生活」是很片面的形容,可能是工作,是不是要修正成「生活與工作」,這個是第一個建議。

  • 第二,「且為需要而非只是想要」,這一句話中文聽起來有一點奇怪。接著,政府很多服務是regulation的部分,都不是人民所想要的,因此建議把這一句話拿掉。以上幾點建議。

  • 我想「須界定」是一定要做研究,但是怎麼做是在配套措施,請團隊參採就好了,沒有什麼好在準則這邊改的。

  • 「服務是融入使用者的生活」,我想本來的意思是並不是下班的時間再來用政府的服務,意思是這個是日常流程的一部分,是daily use的意思,好比像日常……「融入使用者的日常」好像也怪怪的,也就是不用特別去用非常高的成本去取用這個服務,而是在日常生活裡面取用這個服務,現在只是措詞上如何把這個概念傳遞出來。

  • 其實不要也沒有關係,因為「為設計符合使用者真正需要的服務,讓使用者樂於使用,須界定對象且為需要而想要」,這一句話拿掉好像也可以涵蓋了。

  • 所以老師的意思是連上面這一句都拿掉?

  • 因為前面那一句話是寫「為設計符合使用者真正需要的(數位)服務」,讓「使用者樂於使用……」到對象,其實這一段話如果拿掉的話,也可以變成「且為需要而非只是想要」,其實也很完整。

  • 我確認一下您的意思,您的意思是「為設計符合使用者真正需要的(數位)服務,讓使用者樂於使用,機關須界定使用者對象,並考慮到數位弱勢需要協助的管道」?

  • 「且為需要而非只是想要」,這樣就很完整了。

  • 確實,同意。

  • 看大家覺得?

  • 關於使用者的部分,這個是比較一般的說明,但是事實上在應用這一些數位系統服務裡面,其實會包含其他的stakeholders,例如機關本身就會有這樣的情況。

  • 或者像社福有中間代辦的地區服務人員,或者使用者可以再稍微廣義解釋,像機關的承辦人員,像這樣的說明或是將來的細節上要額外說明,不然就是會只落到民眾那一關,而忽略到真正在執行業務的事。

  • 所以老師的具體建議是,機關須界定使用者對象,包含公部門承辦等等利益關係人,不管放括弧裡面或者是括弧外面,如果這樣的話,我們就把多方利益關係人的精神,想辦法變成「對象」這兩個字的註解……但是這邊沒有政府。

  • 這部分我想請團隊參採,這個我想滿重要的,但是要不要放括弧,團隊可以自己決定。

  • 「確認服務是融入使用者的生活」這一句話要不要留?

  • 不好意思,這個草案準則是讓機關去瞭解服務的研究發展至調整驗證的過程,瞭解使用者需求是個體上的研究,所以是不是也可以考慮總體上的研究?像社會福利的參採,像對於很多重要議題,比如低收入戶補助等等,在網路上已經有很多懶人包及指南,其實也有透過輿論蒐集的方法來改變內容。

  • 機關不一定要從頭瞭解使用者的需求是什麼,也可以瞭解這個市場上有什麼可以研究的資料,以幫助他們去發展服務的研究。

  • 第二,剛剛有講到這個是準則中的準則,因此像剛剛有講到使用者範圍的擴大,各位先進也有提到可能會引用到最後像數位治理或資料治理的概念,所以會變成有很多範圍不一定是在使用跟非使用的關係。

  • 像IoT的技術引進之後,街道燈具結合感測器可以蒐集資料,也可以根據行走的人產生不一樣的樣態,這不是一個使用與被使用的關係,但也確實提供了服務,只是行走的人並不一定是使用服務的那一個人,而單純是被服務的人。所以這部分比較開放,但在學術理論研究的部分,可以之後再討論一下。

  • 後面這個我沒有聽懂,你的意思是這一個服務是所謂的「用的人不覺得自己是使用者,但無論如何會被影響到」,是這個意思嗎?

  • 其實會引介到,使用者的使用跟被使用的關係,在智慧生活導入之後如何進行共創,有時並不是使用者,而是變成幫忙蒐集資料的人時候,他們還叫做使用者嗎?這樣轉譯過來的字,大家是不是會有所曲解?

  • 目前比較新的論述是行動者,當然民眾更難理解「行動者」的概念:也就是研究對象不必一定要是人,即使一個智慧物件也可以擔任行動者的角色,也因此會與人產生相互影響概念,但這會變的太複雜,因此如何在本次個案當中,還能保有廣義上詮釋的範圍,畢竟今天討論的是是準則中的準則。

  • 沒有關係,配套措施都可以寫進去。「行動者」是英文的「agent」?

  • 我想這裡很簡單,就是「機關須界定使用者」,如果不要花很多字,就是打一個左括弧,像公務人員承辦等行動者,也就是各類行動者之類的及利益關係人,我想這裡的重點只是把行動者跟利益關係人這兩個主要的詞帶到準則裡面,但我們在這個準則裡面,其實不需要多做定義,這是在配套的部分做到的。

  • 剛才其實這兩個意見是非常像的,這裡的使用者對象,大家很容易用早期電子化政府的方法,只把最後填表的那一個人當作使用者去忽略整個服務流程有非常多的別的行動者、別的利益關係人,也都是各自agent,這一個部分不管是用附註或是括弧帶入,感覺上都是在接下來做配套時有意義的。看大家覺得怎麼樣?

  • 不過如果現在把括弧放進去的話,確實「融入使用者的生活」,這一句話就更格格不入。

  • 我不是很確定要怎麼樣改寫,目的確認這一個服務到最後真的會被使用,是這個意思嗎?可以回答一下嗎?

  • 其實我們在研究的過程中,也曾經跟國發會有探討這一個問題。

  • 因為一個是服務需求者、一個是服務提供者,但這兩個角色中,通常直覺是最後使用的人,但是我們在定義的過程中,像機器對機器間,一樣也是服務提供者與服務需求者,就像您談到新的科技進來之後,也必須要納入這個準則當中來滿足其需求。只是我們在討論的過程中,如果要包含這麼多樣態可能會太過於發散,或者是太多了,因此我們想先解決人的問題,我們後來也在觀察學習過程中,看到需要先便官再便民,因此還有一個中介者的角色,我們必須把暫時先以這兩個角色當作數位服務解決的重點。

  • 因此如果再到所謂本身是機器對機器的服務機制,或者是擴大到物件概念的話,怎麼樣去界定這裡面的話,我們會持續思考,但我們還是建議先處理人的問題,做數位服務,先滿足人的需求,等先解決這部份問題之後,再看如何處理這個物件的問題,也就是我們在過程當中討論的一些重點。

  • 我有一個具體的建議,看大家覺得怎麼樣,「機關須界定使用者對象」,其實這在中文是雙重名詞,本來就有一點拗口,我建議這裡寫「機關需界定服務對象」。

  • 如果服務對象,這邊就可以變成行動者、利益關係人,但是接下來下一句就不刪掉了,我們剛剛說刪掉,是因為有衝突之嫌,但界定了服務對象,包含便官及其他行動者的部分,只要再回來確認服務有融入使用者的生活,這樣的意思就比較明白,就是在界定的時候,每一個agent都要界定,但是做完之後,要確認最後一里有帶到,意義會變成這樣,這樣邏輯上是不是比較說得通?

  • 而且也可以解決使用者的對象是歧異性的問題,我們等於提一個大的概念,也就是叫做「服務對象」,接下來再說「還是要融入使用者的生活」或這個生活要改成作業流程、日常流程或什麼都可以,但是這個範圍就縮小,變成是使用者,而且是人類的使用者,還沒有給AI公民權之前,暫時先考慮一下人類。

  • 我覺得服務對象反而是最終的民眾,但使用者是中間過程任何一個人,應該要對調。

  • 那很好。那第一句就「使用者」,就沒有對象了,這樣也可以,因為我只是要把兩個名詞刪掉一個,所以這樣也是可以。

  • 然後「確定服務是融入服務對象的生活」,表示是需要這個服務,而不是想要這個服務,這樣邏輯也很順。

  • 剛剛朱老師是針對第二句,也就是「且為需要而非只是想要」這一句是不是要刪掉有提出看法。

  • 朱老師的意思是這幾個字是在詮釋「真正需要」,老師的意思是既然寫了「真正需要」,底下思路就有重複之嫌,因為這是在詮釋「真正」兩個字,如果大家覺得看「真正」二字就可以理解意思的話,「需要而非只是想要」就不需要。

  • 但是如果大家覺得看「真正」二字,沒有辦法望文生義理解不是只是想要的話,可能還有保留的需要,也就是詞是怎麼調整的問題,看團隊有沒有什麼想法。

  • 我們補充一下,我們當初會留下這這個精神,第一個原因是因為英國的規範裡面有提到這一句,其實目的是希望類似做負面表列,並不是所有提出的服務就一定要提供給使用者,我們必須要檢討這樣的服務是不是使用者真正需要的服務,因此我們會留下這一句,以免大家透過這個準則在看提供服務時,會過度無限上綱要求機關應該要提供服務,這個是當初提出來覺得要做一個收斂的目的。

  • 對,這個跟小彭講的踩線有一點像,也就是民間的私部門開發者,常常是解決一些想要的需求,但公部門作為臺灣最大的NPO,當然是解決需要的需求為主,因此這一個部分是講說自我設限的意思,所以如果是這樣的話,我覺得意思有逸脫「真正」兩個字上會說的意思。

  • 我想這一個部分,我個人的看法是,其實朱老師的想法從民眾的角度,會覺得並不需要這一個服務,像報稅,我根本不想報,我不需要報,我也不想報,但這都是政府法規所規定的,因此是從這一個角度來看。

  • 但是我們今天在做數位服務原則的時候,政府需要讓民眾報稅的時候,讓民眾報稅的過程中,讓民眾使用的服務可以切合民眾所必要的,而不只是政府覺得提供給你更好的,因此我們當時在做這一個準則的時候,其實是有需要的,也就是協助機關來盤點跟釐清真正民眾需要的步驟。

  • 等一下,你這樣說,是改變了「想要」這裡的主詞,你的意思是,這裡的主詞是「且為服務對象真的需要」,而不是「服務提供者自己想要」,是這樣嗎?

  • 對,當時在看是這樣。

  • 可是這個文意會有所轉變。團隊理解的是這樣嗎?因為我剛剛一直理解的是,是這些服務對象真的有需要,並不是服務對象想到要叫政府做,政府就要做,但剛才怡君的意思是……

  • 也包括「不是政府自己想要做就去做?」

  • 對,其實兩種都是。

  • 是這樣嗎?

  • 所以是「民眾覺得想要」跟「政府自己想要」都有。

  • 這樣的話,那就完全逸脫「真正」二字的範圍。我會建議就寫清楚,也就是「且為需要,而非只是服務對象或機關片面……」之類的,也就是把兩個主詞都寫得出來,這樣大家才想得到,不然任何人一看就腦補其中一個主詞,絕對不會想到另外一個。

  • 因此我會覺得,「而非只是服務接收者或是提供者片面的想法」之類的,這樣是不是比較好?

  • 如果大家ok的話,這一部分我們可能展開成兩個主詞。

  • 接著是「數位弱勢」的部分,還有剛剛提到「共同探索需求」並不是跟使用者,也跟媒體、研究者,但是我想剛剛會強調使用者的原因,是已經有跟各界諮詢,但是就缺使用者,是這樣嗎?這裡是強調的意思,或者是可以併舉?

  • 我再補充說明,因為閱讀這個文件當然是機關的承辦人,因為我們想要避免過去用機關承辦人員的想法覺得民眾需要什麼,因此把「使用者」點出來是希望可以改變這樣的思維。

  • 所以簡單來講,就是要他放棄比較本位主要的意思,按照本來的本位主義,本來就會考量到立法委員或是媒體的想法,因此就不用在這邊寫的意思,是這樣的意思嗎?

  • 可以接受嗎?

  • 我舉的例子比較像社群或網路上的輿論。

  • 就是一般大眾。

  • 一般大眾的想法是?也就是共同探索要不要包含,其實沒有用到服務的人,我聽起來的意思是,不是服務的使用者,也不是利益關係人,但就是對公共事務有需求,也應該要加入共同探索。

  • 應該是要符合利益關係人。

  • 如果前面已經把使用者用「(......)」定義成多方利益關係人的話,這樣的使用者也包含多方利益關係人,然後就解決了?

  • 我們就這樣處理,第一條有沒有想要討論的?

  • (與會者沒有意見)

  • 那我們就逐條審查。

  • 「準則2:建立跨領域合作機制」,這邊的why是強調要有機制,而這個機制裡面要有各個領域的專業,除此之外還要有一個擔當的決策者,而這個決策者叫做「管理者」,需要有適當的技能。

  • 大家還ok嗎?如果還可以的話,就往下走。

  • 怎麼做呢?為達到的目標是持續設計、建置、維運及精進服務,這四個加起來叫做「生命週期」,而且除了「生命週期」之外,還要能夠快速地決策,因為這樣的關係,所以需要一個領導者來帶領。

  • 在這個帶領的過程中有三個要求,一個是要跨領域及跨單位,第二個是多種技能,第三個是要確實做到建立這個機制。大家有沒有什麼想法?

  • 還是代替朱老師的發言。

  • 這邊有提到「機關宜有一個作決策的領導者」,也許大家可以討論到是「宜有」或者是「應有」,跨機關很難有一個做決策的領導者,這個是他的第一個看法。

  • 第二,如果是「應有」可能很難,但是「宜有」又沒有拘束力,因此「應有」或「宜有」大家可以提出來討論。

  • 這其實整篇裡面都有同樣用詞的選擇,因為我們在規範裡面寫「應」的話,如果不完成的話,大概就拿不到錢了,因此「應」(效力)是滿強的。

  • 這整個準則裡面,沒有一個字提到「應」,只有「因應」的時候有提到「應」,但是沒有提到「應」,所以表示你們是有意地在淡化「應」這個字,可以講一下動機嗎?

  • 其實我們在一開始的確會用到「應」這個字,也是透過專家意見徵詢之後,我們後來針對文件的定位來作討論,因為比較是準則的概念,也就是作為機關的一個參考的項目,因此我們才會把原來有「應」的部分改成「宜」。

  • 根據剛才朱老師所給的意見,我建議不要談「機關」,重點是這一個服務本身能夠有作決策的領導者來帶領,因為跨機關的問題,所以沒有辦法在原來的機關本身找到一個可以來帶領的領導者,我們通常就會往上再尋求跨機關機制的合作。

  • 是不是把這樣的精神帶入,避免這邊所談的單一機關決策的領導者,因為可能不容易在實務上,也就是目前的公務體系裡面運作,這是我以上的建議。

  • 簡單來講,如果是跨機關的情況下,有機關就不會有一個,有一個的話,可能就不能寫機關了(笑),就是「機關」跟「一個」只能存在一個。

  • 剛剛具體的建議是把「機關」拿掉,看大家怎麼想?

  • 這樣的話,主詞就是「服務」或者是「服務本身」或者是「服務流程」之類的?

  • 應該直接把「機關」拿掉就可以了。

  • 這樣的話,「宜」就是隨便誰在看準則就是他的意思(笑),就是沒有人的意思。

  • 所以「宜」有一個作決策的領導者來帶領,要做到三件事,文意是通的,看大家有沒有什麼想法?

  • 我只是負責作文法檢查而已,任何實質內容就要靠大家,如果大家都ok的話,那就過去了。

  • 所以基本上「應」是在下位的位階別的文件會出現,但這裡不出現,這裡的「宜」唸成「應」,接下來因為一個跟機關的實務上無法共存,所以就把機關拿掉,隨便誰在看準則,就是它了。

  • 「準則3:規劃多元服務管道」的「why」是確保使用者可以依其需要,包含數位服務及其他管道,而且先有數位服務再用其他管道,或者是先用其他管道再用數位服務,中間都可以順利轉換,而不會重複或者是混淆,這個是動機。

  • 怎麼做?做法就是要透過不同載具與管道,為了要達成這一件事,機關宜留意順利轉換時的銜接或一致,尤其是在非數位與數位,也就是數位跟非數位中間要留意,但是數位跟非數位中間更要留意。

  • 機關宜考量非數位管道,有事沒事就可以數位化一下,可以引入一些新的數位技術。

  • 朱老師是針對最後一句覺得語句未完,因此建議這一句是不是可以考量一下文句上如何讓它更精進。

  • 簡單來講,在多元服務管道間順利轉換這是一件事,但非數位管道亦可數位化,感覺上就沒有講完,只是說可以這樣做,但沒有講說為何要這樣做,或者是到底達成「why」裡面的哪一點,也就是說有一點孤兒的情況,沒有連到上面的動機。

  • 如果要特別講機器人的話,可能要在配套措施裡面講一下到底為何機器人是非數位管道的數位化,意思是不是這樣子?

  • 我想echo一下政委,特別是科技提供,現在是三個例子,或許科技會有重大的變化,所以直接列這三個,我建議還不如不要列。

  • 所以老師的建議是「機關亦宜考量,將非數位管道數位化之可能性或適切性……」或隨便什麼,然後後面的括弧就不寫了;意思是這樣?主詞是「非現有數位管道」,動詞是「非數位化」,也就是考量要不做這一件事,但是後面怎麼做,我們就不舉例子了,看大家有沒有什麼想法?

  • 我提供一個名詞或概念給大家參考,因為最近兩、三年業界談論digital twins:實體有什麼、數位就有什麼,實體有一顆心臟,數位就有一顆心臟,先把數位版本的心臟摸熟,再來動刀,那就很容易了。

  • 其實政府服務也差不多是這樣子,不管是業務本身、還是業務服務管道都在做數位化,看是不是有一個比較聰明的寫法,也就是把digital twins的概念寫進來,這是相當上位,寫進來之後,我們在執行的時候,就會同時提醒自己,政府虛擬的digital twins的時候,不管什麼業務,一本戶口名簿就有一個digital twins的戶口名簿,一個土地的權狀就有一個digital的部分,甚至有一個identity都有這樣的對應,我自己覺得是一套講法,然後適用到所有的地方。

  • 簡單來講,這邊的主詞不是「非數位管道」,而是「既有的」非數位管道,是現在已經有的。

  • 這邊不只是數位化,不管叫做「同步數位化」或者是……我們不能直接翻成「孿生數位化」(笑)

  • 要找出某個詞,並不是為數位化而數位化,而是把現有的用一個類似一比一的方式,來進行併行、同步或者之類的數位化。

  • 看團隊覺得,有沒有逸脫你們本來想要寫的概念?

  • 我覺得這樣比較中性一點,因為虛擬跟實體其實都是必要存在的,雖然我們希望是數位化。我覺得這樣子可能是涵蓋更大的面向。

  • OK。所以要講同步還是對照,這個就……請。

  • 初步在看這一條的時候,我的理解並不太一樣,我以為這一條是在講excercise accessibility,我們要朝著數位化,這個大概是大勢所趨,但是在過程中有提到一句話,也就是「留意在多元服務管道之間順利轉換」,也就是數位的過程中,不能太驟然、突然,很多民眾都沒有這個accessibility的時候,臨櫃都不見了,沒有電腦工具,那就完蛋了。

  • 這是我的理解,為何要規劃多元服務管道,就是讓轉換可以有銜接性,就是在考慮的過程中要考慮不同的載具與管道,而不是要一直保留臨櫃,最後會怎麼樣,沒有人可以預測,因為數位的方式非常便利,或許臨櫃慢慢就被淘汰了,並非需要永遠保留多元管道。

  • 因此我覺得用詞與語句之間,或許可以先把轉換的過程先拉到前面來,讓語句更明確。

  • 因為一開始是包括電腦、行動裝置與電話臨櫃,所有的東西都要保留住,一直要保留多元管道,這可能對政府與機關是cost,我們一直要維持人力,我覺得這反而不是很好的現象,這是我的意見。

  • 所以這邊的具體建議是,我們寫在前面的都是動機語句,所以如果第一句話是寫這個感覺,就是好像臨櫃永遠存在的意思。

  • 但我們如果好比像為了使用者在多元服務管道間順利轉換,機關「宜留意服務管道間銜接或一致性,尤其是非數位與數位間的轉換,讓使用者透過不同載具管道來取得服務,包含臨櫃等等」,也就是一、二大點對調,然後中間加一些銜接,這樣第一句就變成動機語句,然後第二句就變成轉銜過程中必然的情況。

  • 這樣比較不會搞錯,團隊覺得可以嗎?

  • 第三個部分,剛剛講的是機關也「宜考量」將「既有的」非數位管道同步進行數位化的可能性或必要性等等。

  • 我蠻同意的,這一條感覺是在講accessibility,不是在聊是不是要數位化的過程,所以後面那一句其實有一點怪怪的,乾脆拿掉算了,就是「機關宜考量非數位……」,這個好像……

  • ……對,我說是孤兒語句,因為沒有接到前面的動機。

  • 因為這樣的關係,如果還要存在的話,好比移到準則11之類的,因為現有東西數位化的這一件事,比較是在準則11去處理的。

  • 對,或者是12。

  • 對,或者是準則12處理的。

  • 但是無論如何,這個滿前面的,感覺是及早起規劃階段的事,為何要一下子就考量到準則時程期的東西,因為是生命週期的規劃,因此這個到後面去檢討,理路上是比較說得通的,因此先往準則11或者是12移,這一條就只留下動機,也就是在多元服務管道設立轉換,機關宜留意一致性,讓使用者有不同載具的管道,這樣可以嗎?

  • 我剛剛在看準則2與準則3的過程,準則2寫的「跨領域合作機制」其實就是在建立跨領域的團隊,但在實務層面上有這樣的團隊,但不一定能進行有效的討論或好的討論。我不知道在國外的準則上會不會有增加溝通這部分準則的補述或是另立一個準則。

  • 或許我們比較需要這部分的補述,國外公民素養的培力相對比較深,我不確定;但是增加參與式、互動性的討論活動,的確會幫助到跨領域團隊的溝通與討論,因為過程中還必須準備可閱讀的資訊幫助資訊平衡等等。

  • 這裡特別講的是最早期的時候,並不是建置,而是規劃。

  • 這個機制本身不是跨領域、單位合作,也包含了溝通。

  • 我們一般來講合作會包含溝通的意思,很少有不溝通而合作的情況。

  • 是不是有效的溝通,有時沒有有效的溝通,反而實務上會產生很多的問題與傷害。

  • 簡單來講,跨領域的溝通跟跨單位的合作,如果我們一定要把溝通埋進去的話,應該是要放在某一個有框定的主詞裡面,不然跨單位的合作非溝通不可,大概不會有不溝通的情況。

  • 如果你覺得溝通很重要的話,我現在看起來主要能夠埋的地方是跨領域溝通及跨單位合作,如果有必要的話。

  • 不然的話,其實跨領域合作也有蘊含溝通在裡面;看團隊覺得?

  • 我補充一下,主席這樣建議,我們可以接受。

  • 另外我們也在準備準則可以用來操作的checklist,目前裡面也已經有放進去,也就是在這一條準則下面未來會有checklist。

  • 好啊!我們就跨領域溝通,我覺得這樣子比較清楚。

  • 如果只說「跨單位溝通」,這真的有點太下位一點,比較難放在這邊。

  • 我想提另外一個想法,是「跨領域、跨單位溝通及合作」。

  • 那就是四個了,2×2的概念(笑)。

  • 因為我怕這樣切,我怕大家會覺得跨領域溝通,但只有跨單位合作。

  • 好啊!那就「跨領域、跨單位溝通及合作」。中文很難放大括弧及中括弧,就要靠大家在腦裡建立語意樹(笑)。

  • 如果團隊覺得OK,我也可以,大概的意思就是這樣子,不會有錯誤。只是說不要有排除性,這應該是最沒有排除性的狀況。

  • 謝謝這邊的意見,我們就把「溝通」放進去。

  • 接下來是「準則4」。

  • 「準則4:透過快速原型、迭代及漸進軟體開發方式,持續精進服務」,本來有寫英文的,我這裡暫時把英文拿掉。

  • 接下來要做什麼呢?目的是要因應技術創新、政策挑戰及民眾需求,一共有三件事;為了回應這三件事,我們要問的是機關是不是還需要,接下來在各階段都要做三件事,就是考量使用者需求變化、服務整體架構及技術資源的成熟度,而且要採用適當的開發作業程序,所謂適當的意思是,要能夠讓使用者的回饋可以快速被回應,這是主要的論點,大家有沒有什麼新的想法?

  • 如果大家覺得「機關」二字沒有一定要留,我是傾向可以刪掉。

  • 這個算是一個精神,前面有提到其實這一些準則,更重要的是文化與價值。一開始團隊準備的簡報裡面有提到美國做Lean Startup,我認為這個是它的精神,也就是fail fast、fail often、fail cheap,這個是政府內部最缺的文化,我們的公務員真的不敢犯錯,如果回到剛剛提綱講的敘獎,是不是能夠敘一個犯最多錯的?

  • 「Iterate最多次」獎(笑)。

  • 鼓勵犯錯的精神我覺得這個可以寫在前言,寫在準則4就只談論到操作層次,這個精神如果不寫的話,閱讀準則時沒有這樣的理解,遇到要修改精進服務時會猶豫,現有執行業務的普遍原則是都不犯錯,為了怕犯錯會要想太多細節花太多時間,也就是不會有額外的時間與資源去iterate,也就是如何把這樣的文化透過準則說明傳遞出去。

  • 所以老師的具體建議是去修改適當或是修正「適當的」這三字,想辦法採用不怕犯錯、大膽、快速迭代、最小可行的,反正高興就好,把適當的改成某個文化上有啟發性的用詞,比較能夠撐得起來為何我們要持續納入使用者的回饋,不然還是第一版就要完美,這樣的話,持續納入使用者回饋,前面還是瀑布,那就沒有什麼意義。

  • 因此看老師們,有沒有對什麼字眼的想法?

  • 這一條大概是在實務操作最難的,因為做軟體開發的都知道,迭代才會work,應政委剛剛講的,我們如果真的要改,真的是採用迭代為keyword。

  • 我滿同意蕭顧問有關於fail early, fail fast的看法,但是最重要的還是要成功,所以不能拿一個都一直犯錯的服務當示範。要找及早犯錯、很快犯錯,但最後成功的案例,這樣才有示範的作用。

  • OK,不然只能當教學案例(笑)。

  • 我想「迭代式」的確是一個專有名詞,我們現在是放在第二個。而我的感覺其實是「快速原型、迭代及漸近」,這其實是有互相重疊的概念,最後還是落在持續精進,也就是往成功走,而不是為了迭代而迭代。就像我們的準則可以迭代二十次,但今天還是要收斂的。

  • 如果大家不反對的話,我們確實同意迭代式比快速原型或漸近更能體現Lean的文化,即使看不懂的承辦,去Google看一下,也知道是什麼意思,如果老師有更好的建議也可以,這總比「大膽、不怕失敗的」要好一點。

  • 「最小可行」的話,還不錯。

  • 不過如果要最小可行的話,要放在哪裡?因為「迭代」就蘊含了「第一代是最小可行」。

  • 「迭代」的概念其實是比較大的,這邊寫迭代,就蘊含最小可行。

  • 我想回應先前有提到類似的狀況,目前採購法或者是以規格導向的專業進行,這個迭代是什麼樣的形式,提供給團隊參考,後續施行細則……因為不太是這個階段能夠講的事情,但是真的會因迭代在規格上的修正,在採購或將來驗收上會造成一些麻煩,請團隊……

  • 理解。不過,國發會跟工程會今年有一些新發明,好比說小額採購從10萬變成100萬。

  • 另外一個新發明現在已經送到立法院,採購法裡面用最有利標不用寫理由,以前要寫理由之類的。

  • 我想這些新發明多少都有一些幫助,反正我們就做做看,但應該不是這個準則範圍可以處理的。

  • 如果大家還ok的話,準則4就這樣子。

  • 因為現在已經5點19分了,場地到6點,我提一個動議,我們休息10分,我們休息到5點30分,然後再進行30分鐘,儘量把準則走完。

  • (中場休息)

  • 最後半小時,我們繼續進行。

  • 服務要開始建置了,「why」是說要發展數位服務的完整性,所以要確保各種資源,包含人力、設備、經費及技術,然後這裡特別講的確保是往內的,往外還包含中間的相關資源,這個是「why」。

  • 要達成這個,為了提供各項資源,宜確保所需資源是充裕的,如何達到充裕是可以涵蓋公私協力的合作機制,引進民間機構及公民團體的資源,來達到服務的永續經營。朱老師對這一條有沒有什麼意見?

  • 我們就回來看小彭的意見,公私協力的合作機制也許需要講得更清楚一點,這邊有一些關鍵字,像co-creation放進去,或者是用排除的方式,並不是委外或不是機關想做什麼就做什麼,然後就重疊到民間已經提供的商業服務等等。

  • 小彭有沒有要額外再加?或者就是這樣子?

  • 不好意思,我不太知道字要怎麼加,但是起碼在之前操作過北市府的一些案例,其實公務員是本於職權能夠達到的部分,民間也做不到這一些事,像協調場域出來開協調會,但再來導入的解決方式,其實都是讓民間來進行,我們也不會要再去委外開發一個民間想要實證的事。

  • 我想說的是,那個協力的感覺真的是確定不去踩到一些線,有一些是民間引入之後可以自成一個經濟體的模式,而不讓這個經濟沒有辦法抽象,我也不知道用什麼樣的文字來表達這一件事。

  • 但是我覺得公務員很容易不小心因為長官認為很好的亮點,我們就去開發了一個民間原本……

  • ……就是想要而不需要的東西。

  • 本可維運,於是就掛了的東西,不只是APP,很有可能是別的部分也出現這一件事。

  • 其實「APP」已經快要不紅了,所以APP反而沒有這個問題。

  • 我相信會有下一個。

  • 是,未來會有更多的關鍵字。只要有關鍵字就有關鍵字廣告。(笑)

  • 我們現在要做的事是兩個,按照小彭的講法,公私協力的合作或者是我們一般叫做「協作」,跟前面所講的跨領域、跨單位的「合作」到底有什麼不一樣?

  • 小彭提到的是把我要做的部分做好,把你要做的部分開出來,然後不加以限制,對不對?

  • 所以這裡講的「引進」,特別是這個動詞,希望能夠改成或者是加註成某個讓人看到之後,不會想到開標案或者是委外的動詞,所以這裡是落在「引進」二字上。

  • 我不知道大家有沒有什麼想法或者是意見?

  • 而且對政府自己本身那一條線的釐清,可能也得說明一下,不然就像剛剛所說的,那樣正面一直去push,沒有負面的部分來講的話,那就會擴張。

  • 對,所以簡單來講就是說,可涵蓋公私協力合作機制,確保……你的意思是「確保民間機構及公民團體」在這個機制裡面,「有開發的空間」或者是「有營運的空間」,而這裡的重點倒不只是引入資源,而是確保他們的空間。

  • 而且政府也要約束自己。

  • 當然,我們確保別人的空間,也就是約束自己不要佔空間的意思,我這邊儘量用正能量的方法陳述(笑);但是大概的意思是這樣。

  • 「可涵蓋公私協力合作機制,確保民間機構及公民團體有充足的共同創造空間,或有共同創造的資源」等等,反正這整個目的是確保外面的人有空間跟資源,而不是好像都是委外,對不對?聽起來意思是這樣?

  • 我不知道這邊會不會太抽象。老師有沒有什麼想法?我是覺得真的滿抽象(笑)。

  • 這一條就我自己的理解,其實是考量政府在開發一個新服務的時候,其實資源並沒有完整地思考。

  • 至於公私的界限,什麼需要公、私協力、什麼應該委外,好像沒有在這邊去描述,因此感覺兩件事要放進來一個準則有一點困難。

  • 簡單來講,回到動機,動機只是說不要覺得資本門進了一次,然後後面就可以放著爛掉了,意思是這樣。

  • 但是動機裡面有特別納入民間相關資源,所以動機其實已經是雙重動機,並不是說納入民間相關資源只是為了確保完整性,這個「並」是「併行」。

  • 所以它的意思是:這個完整性有兩個部分,一個是對內有充足的資源,另外一個for some reason,這個完整性還包含了外部要提供資源。

  • 你剛剛講的是一魚兩吃,這個在動機裡面就已經長這樣了,我不知道團隊這邊的考量是什麼,有沒有可以補充的?

  • 你們覺得內外都要對這一個服務有投入資源,是這一條的準則動機嗎?

  • 我們在與國發會溝通的過程中有注意到除了原來所認知的資源之外,在公私協力的合作機制當中,也有資源可以引進來,針對服務可能是設計或者是改進的方向。

  • 當初在準則5希望聚焦在談資源的層面。雖然有些資源來自公私協力的,而且其主要的精神是在於共同創造,我們是在想說是不是在準則的其他要點裡面,找比較像建議合作機制的要點來處理,也就是在公私協力合作上可以共創,點出明確分工的精神。

  • 不幸的是,別的準則裡面也沒有(笑)。

  • 唯一比較接近的是,在跨領域合作機制裡面,這裡面可以試著談一下合作的一些原則。

  • 我補充剛剛想到的例子,像台北市政府之前在思考府內規費統整時,的確也同時思考民間的資源有很多行動支付的業者要介接,所以後來處理的是,把府內規費release API出來讓外面的業者介接。

  • 以前政府的思維考量是,把前端的部分全部做完,然後做了一個非常難用的東西,但是現在也開始在思考民間有存在這樣的能量時,就畫清了一個理性的界限,做到統整府內各管道之後,然後再讓民間資源可以承接上來。

  • 所以某種程度的確也是在一開始思考資源時,就開始在思考這一件事,而且去釐清那一條界限在哪裡。

  • 不好意思,我讓這一個問題還是……

  • ……沒問題。這樣聽起來是民間相關資源,包含民間人力、民間設備、民間經費及民間技術,但是這裡「納入」的意思,按照你的講法是,也確實是在一開始就要把「納入」二字放進來,並不是做完之後再想說開一個API,而是一開始就要想這兩個中間怎麼樣搭配或是怎麼樣結合。

  • 按照小彭的講法,是要做整體資源的盤點,並不是先公後民,是不是?

  • 我想這一條的解讀上來講,我們會定位在宜確保所需資源充裕,但是只到這邊的時候,過去機關會思考我的預算要怎麼樣編,都會著重在自己的編列預算而已。

  • 我們這邊寫「可涵蓋」的意思是你的充裕裡面是,你的思考方向還可以包含到你去思考公私協力合作機制的可行性,然後引進民間機構與公民團體的資源。

  • 我們在做check list或key question的時候,我們有提醒給機關參考,也就是在看這一條的時候,也就是這樣子來解讀的。

  • 我在地方政府服務兩年的經驗是,前述說到盤點資源,而最主要的資源是錢,但錢大多數時候是不夠的,系統開發第二年以後編有限維護費用,不足以作持續更新,這是我們委外服務經常遇到的vendor lock-in問題,這樣經常導致服務品質降下來,連逃都逃不掉。

  • 我目前在台中的策略是儘量選擇開源軟體,其實也沒有太多辦法可以想,選擇開源讓系統未來的改善有更多人可以參與承接,技術上來解決vendor lock-in的問題。

  • 如果有更好的guideline在這一個地方,我覺得在確保資源這一條要同時提醒避免vendor lock-in,也屬於在公私合作的這一個層次裡面,開源的思維把公私協力擴大到不只是採購、促參的範疇,否則還是會掉回來資源不夠的問題。

  • 這個確實,範圍是在準則5裡面,我現在覺得不應該移到別的準則了(笑)。

  • 我們這邊有兩件事,一個是可涵蓋公私協力,「合作」是不是要拿掉?因為前面「合作」有一個很明確的定義,也就是「跨領域」、「跨機關」,我們這邊講的事情好像跟那個合作不完全一樣,這個是我的一個問題,就是這個合作機制跟前面講的「跨領域」、「跨機關」的合作機制是不是同一個回事?

  • 如果是的話,也許就留著,如果不是的話,是不是公私協力機制是另外一回事?

  • 好,那我們就留著。

  • 第二個,這裡的「引進」,剛才想要講的意思比較是「運用」或是「援用」。即使不寫「共創」,我們可能也不是單向它在外面、我們讓它進來,可能是一個夥伴關係。

  • 如果是夥伴關係的話,這邊可能不寫「引進資源」,因為大家看到引進資源,大概都是想民間促參、投資這一些東西。

  • 所以一個很取巧的方法,是寫成好比像「建立夥伴關係」之類的,雖然很白話,但至少不會變成是促參,對不對?

  • 我具體的建議是,我們把「夥伴關係」這四字用來取代「資源」二字,或者是至少要併列。

  • 另外一個剛才蕭老師的意見是,達到服務永續經營,這個「永續經營」,我們可以加一個註腳,什麼叫做「永續」?也就是不要被特定的廠商綁定(笑)。

  • 會看到「永續」兩個字,腦裡就浮起「不被特定廠商綁住」,可能只有我們這些做自由軟體的。是不是要更明確形諸文字,我覺得是看團隊這邊的想法,我們希望永續經營是不被綁定,這個精神絕對沒有問題。

  • 如果不特別說明,「永續經營」就是一直編經費的意思,回到問題源頭是資源永遠不夠,所以把避免vendor lock-in寫進去,我覺得滿好的。

  • 我們的目的是要達到服務的永續,大家聽到「經營」二字,心理想的是每一年都有經常門預算(笑),這個經營是不是一定程度上,可以改成說達到服務的永續?

  • 然後我不知道避免vendor lock-in如何寫成中文(笑);「達到服務永續,開啟更多未來合作夥伴的可能性,或者是開啟更多廠商的合作空間……」之類的,反正意思是這樣。

  • 如果大方向大家不反對的話,雖然這個是有一點意識形態,但我們會一直push這個東西。

  • 這個是這個準則的價值。

  • 我們要寫到多強力?如果特別說「不要被特別廠商綁定」,很可能這個準則沒有辦法一下子落實成原則,因為現狀就是有被廠商綁定,所以我們只能講是「朝向儘量服務永續」,然後「儘量開啟多方合作的可能性」等等,這個才會變成比較能夠落實。

  • 老師剛剛講不被廠商綁定的這個想法,其實我們放在準則6,而準則6裡面其實就是要用哪一些工具的這一件事,我們有列一個婉轉式的寫法,也就是「避免受限於契約而阻礙服務的精進」。

  • 這樣寫沒有人看得懂(笑)。

  • 這個是我們當時在討論的時候,我們配合老師剛剛的想法,然後我們轉換成這樣子,因為我們不能在準則上寫說不被廠商綁定,所以我們轉了一個寫法。

  • 我們有「不特定於廠商」的專有名詞嗎?像我們說open document是一個vendor-neutral的技術?

  • 沒有特別翻。

  • 老師這邊講的是vendor neutral,但是這邊的服務永續經營,如何把它轉換成vendor neutral,還是請團隊再想一想。

  • 我們最小可行方案,就是把「經營」兩個字想辦法改掉,或者是變成同義字,也許「達到服務的永續」,這樣就可以了。

  • 多一點的可行方案,是「永續」後面,再加開啟更多合作的夥伴、可能性等等,字樣就麻煩團隊幫忙。

  • 不好意思,因為現在討論的是公共服務,所以公共服務在政府發展的目標上,是不是也會考慮到國外發展公共服務上,於社會資源的壟斷跟浪費上有一些積極作為。

  • 因為廠商是不可能把技術公開的,而公部門有沒有可能做到這一個部分,也就是……

  • ……這個在「open by default」(準則8)。

  • 因為看到「準則5」的「why」的描述是把資料盤點出來,就是確定是足夠完整可以推這個服務上線,或許也可以參照剛剛所講的公共服務發展目標之一,謝謝。

  • 所以簡單來講,你覺得完整性這邊,可能還包含達到公共利益等等的這一些部分。

  • 不過,我想這部分應該接近不證自明,因為我們在做的是政府服務,所以一定是為了公益,而不是特定廠商的利益。如果有的話,那是個案。

  • 就是看人怎麼詮釋。

  • 我同意啊!公益性是非常重要,但如果要特別講公益性的話,那個是前言層級的東西,不是到我們東西都已經規劃到一半都要做的「準則5」來寫的。

  • 前言包含公共利益或者是社會問題之類的,那個就請團隊再參酌,大概沒有辦法放到「準則5」。

  • 大家看對於「準則5」有沒有意見?沒有的話就往下走。

  • (與會者皆無意見)

  • 「準則6:評估採用工具與系統」,目標是要符合各階段的需求,做法是為了提高效率與持續精進,機關要在各個階段,選用適當的工具系統與基礎設施。

  • 這裡很有意思的是,我看到的版本是「選用」與「宜包含」中間沒有逗點或之類的,我不是很確定這個文意,意思應該是適當的這一些東西,然後「宜包含」,是不是?這一些東西「宜包含」以下的這四個考量,是不是這個意思?可能要有一個逗點之類的。

  • 「評估其風險與限制而避免受限於契約而阻礙精進,評估選用穩定性高的開源工具與系統,考量支援常用的系統環境」,目的同樣是永續支援、

  • 看大家有沒有什麼想法?這是滿連貫的,這四個確實我們終於看到唯一負面的字,就是「避免」,所以修到非常弱,但畢竟是整個準則裡面極少數負面的字,看大家有沒有什麼想法?

  • 我自己的想法是覺得這個後面的「避免」真的太抽象了,大概沒有人知道是vendor neutral的意思,這可能要在配套方案或者是check list裡面展開成更有約束力的文字,但在這邊是比較正能量。

  • 看大家有沒有意見?

  • (與會者皆無意見)

  • 「準則7:健全資安及隱私」,這邊講的是保護資訊安全、個人隱私,但是又不犧牲服務便利性,等於承認中間本來就有一些緊張關係,才會用「兼顧」二字。

  • 所以為了要兼顧這兩個比較緊張的東西,所以機關要定期進行風險評估跟資訊系統檢查是採取適當的防護措施,讓使用者可以安心,看大家有沒有什麼想法,這一點我覺得是比較標準的,比較看不出目前沒有做哪一些東西,但我不知道大家的想法是什麼。

  • 如果是有這個意圖的話,前面的健全資安及隱私,其實是一個面向而已,第二個面向其實沒有出現。

  • 我的意思是,是要把平衡的議題顯現出來,否則像兼顧服務便利性,其實可以整個拿掉的,如果需要有平衡,搞不好一個主標題就要再稍微處理。

  • 所以具體建議是,準則7是兼顧資安隱私與便利性之類的,大家如果不反對的話……因為如果不這樣子寫的話,其實內文不用這樣寫。

  • 如果大家ok的話,這裡就不是健全,因為我們說「健全資安」是沒有問題的,但是「健全隱私」就開始有一點怪,如果說這個動詞是特別這三者要兼顧,這個也可以避免機關常常把廠商跟隱私混淆的問題,等於是我們三個併舉,並不是說前兩個是一個方向,後面是一個方向,這個是三個方向要兼顧,如果這樣可以的話,我們就用三個並列的方法處理,就是「兼顧資安隱私及便利性」。

  • 看大家有沒有意見?

  • (與會者皆無意見)

  • 「準則8:以開放為優先」,目的是要降低提供服務總成本,做法是引進民間創新的能量,符合開放標準及重複使用。

  • 具體的做法是要透過開放資料與開放源碼來激勵民間創新優化服務,接下來還要採用符合開放標準且通過測試,可重複使用的共通平台及元件,這樣就可以快速精進服務,因此節省服務開發時間與總成本。

  • 這邊用「開放源碼」,前面用「開源」,是有什麼動機嗎?或者我們全部都用「開放源碼」。

  • 我記得這邊有講開源,大家看到「開源」就知道是開放源碼的意思,我具體建議是不是就展開成「開放源碼」,就是選用「穩定性高之開放源碼工具系統」,不然爭取到多一點的預算也叫做「開源」(笑),也就是充分的資源(笑)。

  • 看大家有沒有什麼想法?我看前幾場逐字稿裡面有激烈討論這一段,所以這個好像已經預先收斂過了,我覺得還算滿不錯的,也就是把資料、源碼、標準及共通性的四個,其實只有部份互相重疊的東西,都放在同一個準則裡面。

  • 如果大家都ok的話,就繼續往下走。

  • 「準則9:測試與部署服務」。

  • 那現在服務已經要上線了,所以要提供與實際運作一致的環境測試,不是在空想的虛擬狀況裡面測試,而且這個測試儘量不要手動測試,要作CI,也就是持續整合、持續發布。

  • 而這一個部分的重點是:縮短測試與部屬的時程,進行end to end的測試,還有易用性測試。這個「等」的意思是還有更多的測試要做。

  • 接下來要確保各種常見的東西都可以有存取服務,但是講到「瀏覽器」,好像是well base的服務。但是anyway我不是特別在意這一點,只是說我們這個涵蓋的範圍包含不是well base的也在裡面。

  • 我不知道你要用什麼,通常我們會說user agent,但在這邊就已經過於抽象,因此通常留載具系統,可能就可以了;或者「及環境」等等,如果講瀏覽器的話,等於是綁定well base,然後還有迭代的服務,這部分跟剛剛的迭代是一樣的原則,看大家有沒有什麼想法?這個講的大概是軟體工程。

  • 因為這個特別是在講軟體的部分。

  • 看一下sli.do。

  • 鄧老師跟另外三位朋友想說,「準則9」的標題比較沒有特色。確實,我們沒有辦法想像不測試,或者不在一個跟現實生活類似的環境去進行模擬,我們就上線,這是很難想像的。

  • 因此建議把自動化、縮短時程、更新服務、持續測試直接加到主題當中,不然這個主題好像沒有講,而具體建議是「持續測試服務與快速部署更新」。

  • 這裡講的是把「持續」、「快速」加入,也就是把「服務」替換成「更新」,大家有沒有什麼想法?

  • 我想就是放在自動化前面,「持續」是要做的第二件事,要測試也要持續,最後要自動化。

  • 我自己覺得「持續」放前面是沒有什麼問題,至於接下來「快速」跟「更新」,是要用「快速」或「更新」,又或者是「自動化」,看大家有什麼想法?

  • 唯一的問題是「自動化」的字,「自動化」很好,但是全部都自動化,就有一點太強烈一點。

  • 「測試」不代表只是軟體功能的測試,也有包含易用性,不過後面還有一個易用性,就是要測人、也要測服務,因此自動化有一點太強烈,可以思考看看,如果不是那麼critical,看看是不是要拿掉?

  • 如果是手動的話,沒有辦法快速部署,對不對?如果要把「自動化」拿掉的話,要把「快速」拿掉。

  • 測試要比較多的選項。

  • 所以你的想法是,我們可以自動化來部署,但是我們部署前的測試,不一定要全自動化,是不是這個意思?就是自動化的scope只到部署而已,看大家有沒有什麼意見?

  • 如果全部測試都要自動化,是滿強烈的,而且我們前面已經講了「宜縮短」,所以這邊其實有盡可能縮短的意思。

  • 如果大家不反對的話,我們可能是說「並以自動化的部署方式迭代地進行服務」,我想「部署」一定要自動化,人拿一個光碟去部署,可能說不過去,所以「自動化」就把它縮限範圍了。

  • 因為前面已經有全面測試了,我們就把前面刪掉,就是自動化部署,因為我們要儘量縮短時程,因此裡面自動化的部分要儘量多,但不表示是全面的自動化。

  • 「持續測試」大家有沒有什麼意見?如果我們把標題改成「持續測試與快速部署服務」,我覺得「更新」好像就不用了;好,我們就「持續測試與快速部署服務」。

  • 看大家有沒有意見?