Re: [情報] 徵求對開放政府有興趣的公務員鄉民
※ 引述《Roy3567 (路邊的大白)》之銘言：
: 看到這個話題能延燒好幾天而不墜，許多人跳出來對開放政府及數位治理的概念發表自己的意見，並且有來自中央單位、地方政府，資訊人員及一般承辦人的觀點，老實說我還滿驚訝的。看到眾高手的回應，我想雖然大家口中罵歸罵，但心裡都希望自己的工作是有意義、能看得見實效的，不必浪費精力去做一堆沒有必要的冗事。我想當大家都願意把這當一回事時，就是一個改變的契機了。
: 雖然我仍認為開放政府的理念要完整實現，整個文官組織要進行大幅度的改造，但這種期待顯然不切實際。我在念小學時老師就說過，要改變一個環境，要從大處著眼、小處著手，如果我們必須在這個文官系統內待上數十年，就要從現有公務體系的架構下來思考，一個跟得上時代變遷、可以迅速回應民眾需求的行政組織，需要從哪些地方開始著手改變。
: 這十數年來，各級政府真的花了很多資源委外開發大大小小的資訊系統，自然每個系統的建立都是為了解決某些需求，但原本的需求改變了、新的需求出現了，原有系統不能滿足需求時，公務機關的解法經常是掛上另一層系統去解決問題，所以資訊系統愈來愈多，新版舊版交疊夾雜，每一個系統都會吃掉承辦人員的時間與精力，當要維護、要登打的資料一多，原本期待能批量快速解決問題的資訊系統就會成為冗事的來源。
: 舉個例子，前幾天我奉派參加某個全國性的行政協調會議，會議開始台上興高采烈的宣佈，為了解決跨縣市登錄管理借用器材的需求，某資訊中心已經設計好全國統一的器材管理系統，預計明年1月就可上線使用。這時候有縣市問了，他們先前已經建立了縣市範圍內的器材借用系統，如何整合？長官回答曰：這部份他們也有注意到，所以請已經建制自有系統的縣市每個月底將資料彙整成excel檔案上傳到該系統，就能完成登錄了，「應該很快吧？」
: 不騙你，我看到旁邊的縣市承辦人眼中閃過一絲忿怒的色彩，但瞬間又化為無奈，這就是我們的公務機關在整合系統時最常用的方法，利用彷彿不值錢的公務員人力去進行大量資料的轉換，還自己為這是幫大家解決問題，結果總是製造更多的問題。
: 我認為，現在政府的數位治理盲點並非不夠資訊化，而是資訊碎片化，尤其系統跟系統之間無法介接溝通，或是因為某些崇高目的拒絕使用已經運作好些時日，成效尚堪的原有系統，而重新要求所屬人員適應另一套操作邏輯完全不一樣的新系統，自然會引起相當的反彈，到後來才發現為了轉換系統所耗費的成本，可能比使用原先系統多了許多。譬如說這十年間眾多機關強迫要求所屬人員拋棄MS的office套裝軟體，改用libre
office等自由軟體，但這些檔案轉換的成本實際上是由第一線的人員在承擔，帳面上少了授權費用，但維護費用及使用者的學習、轉換成本卻難以估計。
: 我很認同TonyQ所講的，重點是拆開現有的各個系統，將資料轉化為共同的語言，不要期待一套系統可以解決所有的問題，而能將系統設計成可迅速拆換的模組，可以快速上線，收取第一線人員的回饋後修改成更適宜使用的型式。這當然對資訊人員及第一線使用的承辦人是很大的負擔，但如果機關首長對資訊開發有sense，願意給底下的部門多一些容錯的空間，我想資訊系統可以幫上公務人員更多的忙，而不是製造更多的麻煩。
: 另外要如何讓第一線的業務單位認識到自己需要的資訊系統是什麼，要如何與資訊人員溝通，表達需求，轉換成能看得見、做得到的spec，需要資訊人員花很多時間下來各單位溝通。本人身為某地方政府某個小科室的資訊聯繫窗口，近日就接到一份調查表，要求本科室提報可未來可以數位化的業務，但本科科長認為業務資料都有輸入進電腦，公文也是用電腦發的，該給大眾的申請文件也有放在網站上，他想不出來到底還有什麼行政作業還沒被數位化。
: 這就是心懷數位治理大夢的資訊人員與第一線業務科室的差異所在，業務單位對於行政流程的想法其實很固著，我們之前做得還算過得去的業務，到底要怎麼做才叫作數位化呢？況且，現下各業務單位最頭痛的就是處理人民的陳情與投訴，這部份數位治理又能幫上什麼忙呢？
: 作為一個地方政府裡的「內應」，我真的很希望可以看到更多如TonyQ般的資訊人才來到我們這些第一線的科室，一起來思考、來盤點我們現有的作業流程有哪裡可以更優化、更進步。我想公務人員不是怕多做事，而是怕做不知道意義在哪的冗事。也希望唐政委的開放政府理想能真正由下而上，對整個公務體系帶來正向的改變。
其實說真的，我個人是非常尊敬公務員的，
我自己出身公務員家庭，雖然我沒有走公職路線。
但我覺得許多公職都還是蠻憂國憂民的。
我自己來公部門服務，初衷是因為我不忍看國家各種門面如此......脆弱。
也是因為我看到許多社會局處的同仁不斷加班，
覺得可能的話，這些社會的安全網自己應該要被撐住。
所以我花很多的時間在這塊盡量幫忙。
這裡很多人都提到對資訊與行政這兩端的許多質疑，
我覺得我的經驗算是蠻特別的，就想舉兩個我自己的案例來跟大家分享。
可能這些案例都是很小的東西，但我著實花了一年多在推動這些小事上。
＝＝＝＝＝
在這邊我其實覺得我的經驗也不是很特別，
當然我也可以理解大家對資訊行政這塊的感受。
我最早試著幫單位解決問題，是我 2009 年還在桃園縣政府服務的時候，
我那時候是個社會處的替代役，有感於國保國民年金審查系統實在是太難用。
所以運用資訊技術幫單位略為「改造」了一下，大幅簡化既有流程。
（要另外裝程式才能改造，所以其他人看到系統還是原本的（笑），
這有點像是我們單位另外寫程式界接的意思。）
幫助單位大幅加速審查流程，因為單位也不是很懂，
只是看到東西好像有做出來可以用，也就直接採用了。
大概審查一個案件節省了 90% 的時間。
（帶入自動化判斷跟一次查詢所有需要的資料而不是要跨越層層表單）
但那時候我也只是個死替代役，雖然做了種種事蹟拿到績優役男，
運氣不錯拿到處長嘉勉，但做再多終究就是個替代役。
而且那個老問題：你走了，系統就復原了。
這些我六七年前就都經歷過，也體會過。
其實我都明白體系內對我們這種外人的感受。
只是至少我們在的時候，是有些事情會發生的。
但是也因為當初我們做過那樣的範例，所以後來系統雛形有在督導的要求下，
參考我當初作的概念重新整理過，雖然晚了兩年，但終究有走到當初的那一步。
＝＝＝
現在很多問題，其實是「不知道能做什麼」、「缺乏想像」。
資訊室覺得承辦人不能用太新的東西，承辦人不懂資訊技術，
當然我知道資訊室有時候是被當小叮噹，所以也怒了不想幫忙，
而承辦人覺得資訊室不幫忙，兩邊互卡久了就僵住了。
＝＝＝
以郵遞回執聯為例，那個例子最大的負擔原本是「找到公文歸檔」，
我先讓承辦可以用公文 di 檔下載回執聯 word 檔下載列印出回執聯，
然後上面特地印了系統辨識用的 QRCode。
然後我用資訊技術作 QRCode 「自動辨識」，
有 95% 的辨識率，只剩5% 需要人工歸檔。
那時候討論需求時我很直覺就想到這個解法，
不用人工歸檔，因為這件數一多就會吃掉一整個工讀生人力，
更不用說要 key in 到系統，搞到要額外 key in 系統肯定沒人想弄。
我提出來說，可以掃描後自動上傳跟自動辨識的時候，
台北市社會局的承辦人是愣住嚇傻了跟我說：真的可以這麼神奇嗎？
可以的話我們當然好。
我說：技術的問題交給我，我說可以就可以，行政協調的部分交給你們解決。
我後來花了兩個小時找了開源 lib ，測試了一下辨識率，
然後印出來測測沒問題，兩天就寫好了。
他們則開始去思考怎麼做試行，後來我們在「一個科」科長支持下試辦，
試辦一個月後成效良好業務大幅降低，就在「局長」支持下推展到全局。
（不過最開心的聽說是檔案室，
他們原本有一個人全職在做回執聯歸檔這個業務（因為原本是公文加頁）。
XD）
這是回執聯，不過回執聯這個故事比較特別啦，
當初想到要做這個，只是因為台北市社會局訴願量比較大，
常需要舉證送達，加上承辦人輪替，
大家手上都有一堆陳年回執聯，實在是很恐怖。
他們科綜合覺得有必要解決這個問題，所以才在科長同意下來請我幫忙。
做完這個機制之後回執聯根本不會回承辦人手上，直接存檔，
又有數位系統可以查。
他們承辦人有幾個好處，所以蠻買單的：
1. 少了保管回執聯的負擔
2. 不用手寫回執聯（系統列印）
3. 可以即時查詢跟確認回執聯回來沒
4. 不需要自己做公文加頁
我們把數十人的每日零碎作業，集中成一個人一天不到二十分鐘的業務。
這只是一個很小的業務，但就是我們在挑戰的一個事情。
＝＝＝＝＝
我手上還有另一個行政數位化的實際案子：「志工」業務。
目前是先拿榮譽卡試行。
志願服務榮譽卡在台北市，
本來是要用紙本填寫申請單跟單位基本資料（蓋官防），
然後列印志工志願服務手冊封面跟內頁。
由單位送件到台北市社會局做申請。
這個業務是他們科長覺得志工業務很混亂，系統也多，流程繁複，
所以請我「指導」，然後我跟他們聊一下。
（先說叫我去指導的單位很多，但可以做事情的機會可遇不可求，
我聊過的科長跟承辦應該有超過四十位，只有大概五六位有進展。）
我跟承辦聊了一下，承辦自己主動提出覺得許多「申請」案件，流程很累。
一方面完全沒有系統（只有 excel 檔），
要查有沒有重複申請只能靠 search，非常浪費人力跟時間。
另一方面是規則真的很複雜，志工承辦根本搞不清楚。
最後一個部分是厚厚一疊紙本，審查困難、歸檔困難，處理也困難。
這塊後來討論了一下，我們決定把 excel 檔系統化，
我們為了系統化，第一個撞到的障礙就是申請單要蓋「官防」，
到底還要不要紙本單據蓋章？還是半套式的線上送資料，紙本送申請書？
這塊志願服務推廣中心跟股長都很支持，覺得既然要做線上送件，
跟要求志工團體申請數位帳號了，就不應該再要求官防。
所以在這件事情上達成了減章。
（事後調查發現這對志願團體來說，應該是最有感的需求，
很多單位很難拿到官防，甚至為了這個，
還有些單位限制他們一年只能申請兩次。
不要求一定要有官防之後，目前線上申請案件量大增.....XDDDD
）
另一塊是系統我先寫好一版，內部測試試跑時發現一個有趣問題，
照原本的紙本流程設計的電子檔，事先建申請單，
再逐一填寫申請使用者，變成一案 n 人的模型。
但後來發現一個問題，原本送件是一次送整批（假設十個人申請），
假設其中一個人被退件，照原本紙本邏輯是要十個人全部退件的。
可是這非常不合理，站在志工單位的角度而言，這很糟糕。
後來我們經過討論有了共識，稍微調整了結構，
在線上系統變成一案一人，可批次送出，
先建人再送出，不再採取原本的一案多人的模型。
這樣有個好處，萬一需要退件，我一次退一個人就好，
其他九個人照過，不用退十個人。
這些紙本檔案只要用影印機掃描或用手機翻拍，
我的網站系統支援直接用手機連拍照片上傳送件。
（而且我的網站同時支援桌機、平版、手機，做 RWD ，
從送件到承辦審查，都可以藉由手機跟平版進行，
不過倒是有一點比較可惜，不支援 IE8 以下，只支援到 IE9+ 。XD）
最後我們取消了「兩吋大頭照」（榮譽卡照片）的繳交！
我們直接收電子檔或是請志工團體的承辦，
直接幫志工用手機拍正面看的清楚背景單純的照片即可。
而且志工送件時不需裁切照片，我寫的系統可以簡單裁切，
所以審查員（志願服務推廣中心）這邊也願意支援我們審查時幫忙裁切。
這樣一方面省掉找兩吋照片的麻煩，
另一方面是就可以做到「直接下載數位榮譽卡電子檔」。
這裡還有個插曲，為了做數位榮譽卡電子檔，
我認為應該要有 QRCode ，做卡片的數位防偽，
所以這塊特別請承辦簽文到衛福部申請卡面格式變更，
等了整整兩個月還做了許多的說明，才終於等到核可函。XDDD
當然還有許多具體的問題討論，在此不一一贅述。
然後對應的修改線上申請的辦法，辦系統說明會。
（我去當講師跟志工承辦一個個說明理念，系統操作...etc）
最重要的部分，因為是開放給民間團體申請，易放難收，
所以我們更謹慎一點，我們沒有拿民間單位當白老鼠，
我們十月試推一個月，是請志願服務推廣中心，
試著用「紙本件翻拍」的方式當我們系統的第一批使用者，
確保用真正業務的東西磨了一個月，志推發現的問題全部修正，
之後才丟給民間團體使用。
（eat your own dog food.
這是我們資訊業界常用的術語，自己先用過再叫別人用。）
現在每天大概都有數十案線上送件，
案件審核時間從原本的 4-5 週，簡化到 3 週不到。
而且審查員能夠更專心在內容審查上，
一些基本的條件檢測都由資訊系統做完前置處理跟檢測了。
另外單位因為送件後「即時」看的到申請流程，
事後看得到申請紀錄，這也解決了他們承辦人經常輪替資料不齊的問題。
而且規則系統化了，也更讓承辦人比較不用自己瞎猜跟瞎摸。
（不過說明文件還需要再補齊就是了）
（據說志工業務在團體也是屎缺）
-----
其實還有別的例子，但舉這兩個相對比較大的。
寫這兩個過程是要說，行政流程電子化，
必須要同時滿足幾個條件：
1. 要有真正的問題存在
2. 這個問題必須要能被「簡化」
（如果建系統只是讓大家打更多字或做更多 excel 表，那何必）
3. 流程必須要有調整的空間跟可能性
4. 要試著運作，從運作中得到反饋
5. 不要單純的只是把紙本件轉成線上申請
6. 過度時期可能會需要行政人力配合測試，所以要挑時機點
當然科長的支持也很重要。
既有的系統，我基本上有兩個原則：
1. 強烈反對「砍掉重練」
2. 用「調整」跟「局部模組化」慢慢取代「砍掉重練」。
但是這塊我自己做的比較少，目前只有 2-3 個非常小的表單調整，
倒是檔下了幾次系統砍掉重練。
資訊技術的部分我就略過不談，因為這部分是我的專業，
至於有些人可能會在意的「存檔」跟「備份」，
這塊我們都有設計在流程中交給檔案室做數位存檔。
也在一些如「發冊名單」流程上有設計內部紙本公文簽核留存。
避免系統發生不幸時，造成資料的損毀。
但其實扣掉專業的部分，前述一到六點，
是如果內部沒有真正懂業務，而且真的有興趣減少「冗事」的承辦。
那我有再強的資訊技術，我也不太可能跳過承辦讓他們去做什麼。
對我來說，我是訪談無數人，然後在裡面找到願意合作的人，
再來談合作的方法，這是一種姜太公釣魚式的做法。
畢竟我們都很清楚，公務員如果他不願意動，
就算請長官壓他動，對我也是沒有意義的，
我的需求訪談會亂七八糟，做出來的東西也很難真的進入成果。
我大概前前後後花了一年半的時間，利用自己本業閒暇之餘，
（我有自己正職工作），
去跟各業務單位交流資訊技術，提供他們專業意見。
必要的時候提供一些技術支援。
對我來說，與其去做一個很偉大包山包海的系統，
還不如好好想想「怎麼做一個好的、簡潔的行政流程」，
而且在這樣的過程裡面承辦其實會學到很多系統的概念。
我會幫忙翻譯資訊語言到承辦的流程裡面，
讓他們理解資訊系統可以做什麼，不能做什麼，
哪些需要人，哪些部分會不安全，哪些事情是安全的，
在瞭解這些細節之後，承辦人才能對資訊流程做出相對可靠的判斷。
當然這裡面都需要「信任」。
我相信這裡一定有人聽過我的現場演講，
因為很多長官都會找我去公務單位演講，
但我也直白的說，這種演講通常沒什麼用。
找基層的基層的會說長官才需要上，找長官長官會說基層的才需要上，
最後結束後也沒人敢真的談問題。
我跟唐鳳他們的目標（或許）比較不一樣，我個人待過政委辦公室，
也看過無數政策強硬推行之後中間的各種感受，我都很清楚。
我的感想是唯有讓科長層跟承辦層，這些「中間份子」真的願意買單，
然後同時遊說到局處長級的「長官支持」，
我相信只有這兩個條件滿足的前提，行政數位化才會開始。
而且行政數位化應該在「源頭」，也就是地方或公所，
這種第一線接觸民眾的單位就開始數位化。
我跟很多長官提過這個想法，他們總是跟我說
「公所跟縣府承辦有多少人啊，你為什麼不設定一個高階的培訓，
一次教會大家這是什麼，而要自己一個個去踩點呢？ 」
我自己過去兩年講超過四十場的「開放資料研討」，
辦過「訓練營」也講過無數案例。
我個人的心得是，不真的下去踩點，
一個個業務執行當案例，當說明，
這些訓練都是假的，都是空談。
如同大家靠北國發會說要做但不給指引一樣，
主事的不下去做案例，誰知道要怎麼做？
事實上在最近半年我已經不鼓勵盲目做開放資料了，
應該是業務有資料，然後評估「有幫助時」開放。
而且開放資料「並不是」為了讓人民來攻擊政府，
是要讓他們能夠更接觸到承辦人，更能夠申請業務。
特別是人民服務案件。
開放資料並不能直接等於陽光法案。
而且也不限於資料開放，也可以用開放 api 的格式收各種申請資料，
（另外 api 也不代表不能做身份驗證跟檢核，下略三千字。）
（政府真的需要自己做 app 嗎？
必要的部分是需要，但那堆 50 app 以上合一的蚊子詭異縣市 app？
開放 api 就會有很多人搶著幫你做啦，如果真的 api 是有用的業務的話。）
其實想寫的還有很多很多，關於資訊系統怎麼應用於公務，
關於資訊行政的細節，關於業務跟資訊兩邊的拔河。
我知道這個大環境不好，中央很亂，地方業務很重。
很多東西都人越來越少、繁重業務流動率高又會有交接困難，
業務每個月都越來越多，而且時效又越來越即時，大家壓力越來越大。
要即時的就會一直建系統，但又不互通導致永遠都在填系統就飽了。
每次反應都是「研議」、「等待」、「研議」、「等待」。
不知道何年何月得償所望。
這些我都明白，但是在座的各位如果有機會哪天一起共事，
我希望我是能幫各位真的去想真正業務的問題，
遊說長官，找真正的資源，做該做的事情。
而我們不用在最基本的層次：到底要外包還是自建，長官是不是白癡，
這種其實不是答案、也不是問題的部分，再繼續耗費青春下去。
作為一個資訊專業，半路亂入政府部門的工程師，這是我自己的想法，
對我來說，前面有人噓文說，內應是需要負責的，我不用。
但其實我自己在位置上的時候，我還是會想辦法跟大家一起負責。
而如果跟我合作的人有各種疑慮，我也是很樂意退回到支援者的角色，
對我來說，重點不是我自己做什麼或我成就了什麼。
而是這些一個個的業務，背後的民間申請者（特別是我做的以社福業務多），
他們到底有沒有辦法更簡單、更直接、對大家都省事的作法。
而且以一種大家都覺得「安心」的角度來做。
我相信一定公務上還有很多空間，因為我已經看到了許多......
--
回到前面，有人說「開放政府到底是什麼」。
我認為「是一個每個零組件都有發揮功能的政府。」，
只要大家都有把自己業務做好，而且跨單位溝通無礙。
那這樣的政府，自然就是開放政府了。
目前根本不是要不要揭露各單位資料的問題，
而是許多單位根本就在行政上已經瀕臨失靈與失去功能的問題。
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.105.90
※ 文章網址: https://www.ptt.cc/bbs/PublicServan/M.1480693123.A.ABA.html
※ 編輯: TonyQ (220.133.105.90), 12/02/2016 23:53:19
※ 編輯: TonyQ (220.133.105.90), 12/03/2016 00:12:54
推
12/03 00:17, , 1F
12/03 00:17, 1F
推
12/03 00:31, , 2F
12/03 00:31, 2F
→
12/03 00:32, , 3F
12/03 00:32, 3F
→
12/03 00:32, , 4F
12/03 00:32, 4F
→
12/03 00:33, , 5F
12/03 00:33, 5F
→
12/03 00:33, , 6F
12/03 00:33, 6F
→
12/03 00:33, , 7F
12/03 00:33, 7F
→
12/03 00:35, , 8F
12/03 00:35, 8F
→
12/03 00:36, , 9F
12/03 00:36, 9F
→
12/03 00:36, , 10F
12/03 00:36, 10F
→
12/03 00:36, , 11F
12/03 00:36, 11F
→
12/03 00:37, , 12F
12/03 00:37, 12F
推
12/03 00:38, , 13F
12/03 00:38, 13F
推
12/03 00:39, , 14F
12/03 00:39, 14F
推
12/03 01:01, , 15F
12/03 01:01, 15F
推
12/03 01:02, , 16F
12/03 01:02, 16F
→
12/03 01:02, , 17F
12/03 01:02, 17F
→
12/03 01:02, , 18F
12/03 01:02, 18F
→
12/03 01:02, , 19F
12/03 01:02, 19F
→
12/03 01:02, , 20F
12/03 01:02, 20F
→
12/03 01:03, , 21F
12/03 01:03, 21F
※ 編輯: TonyQ (220.133.105.90), 12/03/2016 01:05:03
推
12/03 01:10, , 22F
12/03 01:10, 22F
→
12/03 01:10, , 23F
12/03 01:10, 23F
→
12/03 01:10, , 24F
12/03 01:10, 24F
→
12/03 01:10, , 25F
12/03 01:10, 25F
→
12/03 01:12, , 26F
12/03 01:12, 26F
→
12/03 01:12, , 27F
12/03 01:12, 27F
→
12/03 01:13, , 28F
12/03 01:13, 28F
推
12/03 01:22, , 29F
12/03 01:22, 29F
噓
12/03 01:27, , 30F
12/03 01:27, 30F
→
12/03 01:28, , 31F
12/03 01:28, 31F
→
12/03 01:29, , 32F
12/03 01:29, 32F
→
12/03 01:29, , 33F
12/03 01:29, 33F
推
12/03 01:33, , 34F
12/03 01:33, 34F
→
12/03 01:33, , 35F
12/03 01:33, 35F
噓
12/03 01:40, , 36F
12/03 01:40, 36F
→
12/03 01:40, , 37F
12/03 01:40, 37F
→
12/03 01:40, , 38F
12/03 01:40, 38F
還有 31 則推文
→
12/03 12:16, , 70F
12/03 12:16, 70F
我覺得現在缺人但有業務的情況會是常態啊 :Q
因為現在的財政情況...(下略)
如果不善用資訊系統來協助資料彙整，
只想靠人力作資料整理，早晚一定會大家一起死的。
推
12/03 12:33, , 71F
12/03 12:33, 71F
→
12/03 12:33, , 72F
12/03 12:33, 72F
其實攤開來看很多題目，其實都是「年久失修」啦....
當初構想不一定壞，所以也造成在推動時很多的困難。
很多人會覺得「這麼多年來都沒變，應該不能變了吧」
但其實這麼多年來真的有力氣去看他的，搞不好一個都沒有....
※ 編輯: TonyQ (220.133.105.90), 12/03/2016 12:55:32
※ 編輯: TonyQ (220.133.105.90), 12/03/2016 12:56:42
推
12/03 13:20, , 73F
12/03 13:20, 73F
推
12/03 13:23, , 74F
12/03 13:23, 74F
推
12/03 15:03, , 75F
12/03 15:03, 75F
推
12/03 16:03, , 76F
12/03 16:03, 76F
推
12/03 16:23, , 77F
12/03 16:23, 77F
→
12/03 17:12, , 78F
12/03 17:12, 78F
推
12/03 17:21, , 79F
12/03 17:21, 79F
推
12/03 20:36, , 80F
12/03 20:36, 80F
→
12/03 20:36, , 81F
12/03 20:36, 81F
→
12/03 20:36, , 82F
12/03 20:36, 82F
→
12/03 20:36, , 83F
12/03 20:36, 83F
推
12/03 23:25, , 84F
12/03 23:25, 84F
→
12/03 23:25, , 85F
12/03 23:25, 85F
→
12/03 23:25, , 86F
12/03 23:25, 86F
→
12/03 23:35, , 87F
12/03 23:35, 87F
推
12/04 00:19, , 88F
12/04 00:19, 88F
推
12/04 04:37, , 89F
12/04 04:37, 89F
推
12/04 10:13, , 90F
12/04 10:13, 90F
推
12/04 15:47, , 91F
12/04 15:47, 91F
→
12/04 15:47, , 92F
12/04 15:47, 92F
→
12/04 16:38, , 93F
12/04 16:38, 93F
(2015/1 ~ 2015/6 蔡玉玲政委辦公室，法律政委。 ）
→
12/04 16:38, , 94F
12/04 16:38, 94F
→
12/04 16:39, , 95F
12/04 16:39, 95F
→
12/04 16:39, , 96F
12/04 16:39, 96F
→
12/04 16:40, , 97F
12/04 16:40, 97F
※ 編輯: TonyQ (220.133.105.90), 12/04/2016 16:41:04
→
12/04 16:41, , 98F
12/04 16:41, 98F
→
12/04 21:06, , 99F
12/04 21:06, 99F
→
12/04 21:06, , 100F
12/04 21:06, 100F
推
12/04 23:09, , 101F
12/04 23:09, 101F
推
12/05 01:00, , 102F
12/05 01:00, 102F
推
12/05 07:58, , 103F
12/05 07:58, 103F
推
12/05 19:43, , 104F
12/05 19:43, 104F
推
12/06 23:19, , 105F
12/06 23:19, 105F
討論串 (同標題文章)