我先簡單報告一下，非常謝謝政委幫我們作協作，也有清楚的方向，我們有研擬一些相對的做法跟時程，看是否妥適，有什麼樣的建議，詳細的內容就等檢報完再說，謝謝。

我是財政資訊中心梁瑞芬，針對上次的協作會議，整個討論的成果丶議題牽涉到很多對象，擬成立一個工作小組，針對這七項建議研討及規劃，整個規劃跟運作的時程就如下列的期程，像7月會成立工作小組，8月至11月進行整個需求的研討、規劃及開發，12月會進行第一次的系統驗證，1至2月會針對系統驗證再提出一些精進修改，3月份會進行第二次驗證，整個成員有包含使用者代表、Mac專家、賦稅署、國稅局及本中心。

接著是針對協作會議所提出的問題、建議及改進的方式，我們擬訂一些具體規劃及時程報告。

有關於「（一）提供白話說明」及「（三）申報網站登入畫面，只留畫面上最重要的訊息」，這一個部分我們規劃在106年8月份，會邀請使用者代表、賦稅署、國稅局共同研議相關的內容及說明。

（二）由部落客宣導，我們會透過工作小組運作，於106年7月起請五區國稅局服務科針對系統改善進程與網路部落客互動，會規劃邀請部落客參與兩次驗證作業。這一項作業會納入經常性的辦理事項，每一年4月份會加強這一部分的宣導。

（四）進行參與式工作坊，規劃106年8月份依工作小組時程，適時邀請部落客、首報族等二十人，藉由開放式的研討，蒐集有效、可行建議，作為系統改善參考，納入106年規劃綜合所得稅辦理。

有關於報稅流程的部分，目前反應到的問題是不知道要準備什麼東西、元件安裝跟介面老舊的問題，增加提示簡單的流程進度及流程引導機制，並提示完成百分比，這一個部分會規劃在106年8月份邀集使用者代表、賦稅署及五區國稅局，共同研議修改及相關說明。106年綜合所得稅結算申報時會上線。

就是明年？

對。

解決方式是有各個平台安全元件、認證標章取得、參考大廠設計、不需要讓使用者進行安全性設定更改，這個部分我們規劃在106年7月起會邀請賦稅署去國稅局研商，納入108年開發標案需求規劃書中。

這個部分沒有？我們等一下再討論。

對。

第四期的部分，在107年綜合所得稅結算申報上線，這個部分會納入工作坊的研討議題來作規劃參考。

有關於易用性的部分，也就是讓用戶感覺放心、要有使用者測試、美感與設計感、整合所有環境元件一次安裝，短期一樣在106年8月份會邀請使用者代表、賦稅署及五區國稅局，溝通研議修正內容及相關說明修改，在106年度綜稅結算申報時上線，長期於108年開發標案需求規劃書中，訂定相關需求，進行全面整體規劃設計。

我作一個補充，108年並不是要驗證，而是現在就要開始規劃，把需求規格訂出來，9月份就要準備RFP招標程序，107年開發，108年上線。

只是花一年跟花兩年看到的差別而已？

對，沒錯。

接著是簡化報稅查詢碼的部分，我們是戶政、申報資料及健保卡資訊作為核發查詢碼之身分辨識，申報的時候會配合戶號跟出生日期申報，這個納入工作坊討論議題，大家認為ok的時候……這只是初步的構想，這個是針對大家討論之後作為規劃設計的參考。

這個是免讀卡機的部分？

對。

第三個是以限定操作次數為前提的設計，這一個部分是規劃在106年8月份要請使用者代表賦稅署去國稅局共同研議相關的修改內容，應該是明年度進行106年結算申報時上線。

問題五是有關於滿意度的部分，因有前、中、後三層滿意度調查，並且清楚說明滿意度調查的目的，目前先將滿意度的部分移到申報完成時再詢問。第二個部分是在108年開發標案中會納入使用者介面、使用者經驗八項基本原則，民眾申報完成後，調查其對事前網頁引導、事中的像申報介面及事後的完成查詢來進行滿意度調查及回饋後續改善。第三點是系統開發期間邀請工作坊成員進行研討，在系統雛形建置完成之後，納入專家及使用者建議，來提高滿意度。

有關於遙測的部分，是每一年申報一次，並不是經常性改版，我們認為這一項作業在檢討階段中就可以蒐集民眾的建議跟問題來回饋，這個部分我們建議在討論的階段再來蒐集資訊。

第三個是RFP包含使用者介面、使用者經驗的規格，已經納入108年開發標案需求規格書規劃。

108年開發，是以108年報的所得稅，也就是2020年？

申報107年。

是在107年所得年度，也就是108年5月就申報。

表示開發標案是從你開標、招標及得標，開發期是多久？

108年的規劃是9月開始準備標案，進行標案的程序，預計12月以前標定，明年一整年的時間開發，明年是107年，開發完之後，108年就開始做大量測試及上線前準備。

開發一年、測試三、四個月，然後上線。

這個標案不僅是綜所稅申報而已，包括所有的國稅網路申報，例如營所稅、遺產稅、贈與稅及營業稅等等，所有的國稅申報都在這一個標案中，所以是很大的系統。

意思是每一個稅種的線上報稅程序，都會納入相同的這一些原則？也就是完整的原則？

對。

這跟去年第五階段電子化政府所提，所有的稅務都要在線上辦理的那部分，的關聯是什麼？

第五階段？喔！5EG。

有關聯嗎？

沒有關聯。

所以這個是前端使用者看得到的部分？

補充說明，剛剛政委提到所有的報稅軟體是不是都按照這樣的原則來做問題，因各稅適用對象不太一樣，像營業稅是營業人，營所稅是營利事業，各稅範圍及其使用者本身的特性不太一樣，例如營業人本身是有專業的或委託會計專業代理人報稅，可能就不會認為我們講得不夠白話，因為他們就是經常接觸稅務法令解釋，對稅務法令或專有名詞已有一定程度的熟悉，所以我們會根據使用者不同而做不同的考量修正。

例如遺產稅、贈與稅網路申報軟體使用者可能多屬一般民眾，對於稅法可能不瞭解，對於慣用的專用名詞也不是很清楚，我們盡量朝淺顯易懂的方向來改進，對於營業稅及營所稅等，尤其很多是委託專業代理人，如記帳士或者是會計師，他們都是專業人士，反而需要一個比較精準的法律說明，才比較好follow。

……理解，不同使用者客群，你會對記帳士作類似的工作坊來作需求？或者是他們之前都沒有表示過不滿，所以就專注在（笑）……

……因為群組比較特定，跟我們的互動也很不錯，所以沒有聽到抱怨。

好啊！我只是確認。

平常國稅局在服務的時候，納稅人隨時有反映聲音，只要是合理的，都會儘量改進。實務上透過每年檢討機制，不斷在改進當中，其實每一年都有精進。

OK，請繼續。

問題六，介面老舊複雜的部分，協作會議建議的解決方式是不要以書面的邏輯來設計介面，可以分為簡單版及完整版，辦理介面設計競賽、新舊介面進行。並使用最新軟體工具建教合作，這個部分會規劃到106年8月份會邀請使用者代表、賦稅署及國稅局，共同研議相關內容及說明，在106年度綜合所得稅結算申報上線。

問題七，持續協作的團隊，建議的方式是找產官學合作、找專家研訂UI、UX規格及公開徵求民眾協作，規劃106年7月邀集賦稅署及五區國稅局研議討論納入108年開發標案需求規格書中，預計107年總和所得稅結算申報上線使用，接著是納入工作坊研討議題，供規劃設計參考，以上報告。

這樣聽起來我們有兩個不同的時程，一個是以現有的規劃，在明年就可以改善的，好比像這一些（如簡報記載），這邊寫106年綜合所得稅結算申報上線的介面複雜先改，是以目前的維護合約來進行？

對。

凡是這邊覺得超出這一個部分的話，我們就列在新的RfP裡面，原則上這樣？

對，沒錯。

想問比較簡單的點：在整個案子當中有納入協作精神在裡面，有提到了請使用者代表及外界的專家學者來討論協作，我們注意到這一次政府跟外界合作看起來是比較密切的。那麼這些民間朋友會不會得到相對的報酬，比如車馬費這一類的？

車馬費是有的。至於額外的報酬，政府有一些限制；車馬費或出席費一定是會有的。

簡報第5頁我比較聽不懂的，按照我們剛才確認的邏輯是，維護合約裡面目前沒有辦法cover這一些，必須要在新開的標案當中才可以cover這一些，是有碰到實際的困難嗎？或者廠商可以協助解釋嗎？

這個我們要去盤點，原則上是可以立即改的，我們一定優先處理，但有些是會牽扯到整個基本及整體性規劃的東西會比較晚一點，因此提出來的需求，原則上是106年，但還有層次的差別，如果牽涉到比較大的東西，我們原則上會納到107年。

你們有已知比較大的問題嗎？

主要是這一個。

分三個部分：第一個是採用的技術不要彈出不安全警告的技術，像Java廠商已經不建議使用，明年放棄維護，要他提出不安全警告，那個幾乎是不可能的事情。

意思是我們在明年的時候，只要不用Java就好了，「1」就自動完成了，這一件事技術上有什麼困難嗎？

不使用Java的替代方案是什麼？

目前是朝向Web方向去作研析，但在整體架構上來講，因為我們後段的機器可不可以承載這麼長時間的連結，這個是我們要考量的地方，這個必須要整體性判斷，也就是現在的設備是不是可以支援前端程式改寫，等我們談完之後才會比較清楚知道有無達到這一個需求，比較保守來講是我們可以先往後納，可以做的就先做。

意思是你們本來規劃的Web版是給iPad或者是Android的版本，本來測試的時候只有好比像千分之三的人來報稅，並沒有一半的使用者突然用手機報稅的量，是這個意思嗎？

可以這麼說。

你們現在測試的量是多少？

壓測是很容易的事，今年度有壓測過嗎？

不到一萬個。

你們事前有測試過嗎？

你們壓測的量是多少？

我們一般是壓測3倍到7倍，以實際申報3到7倍。

是分布在三十天，所以是用一天壓一千人？

不是，是一次。

意思是可以同時三萬到七萬人來報稅？

理論上是。

事實上有做這一個壓測嗎？

在行動版的合約裡面是沒有要求壓測作業，但是我們實際上有做，所以像剛剛中心長官說的，大概是在五萬上下，我們以這樣的量去壓測，因為長期觀察市場使用的狀況，使用者大概是一萬上下而已，假設沒有做任何改變的時候，很難瞬間飆高，以市場使用者的狀況，也就是以五萬上下的量壓測。

我們知道目前用手機的是千分之三到千分之五，也就是最多只會變兩百倍的量，所以意思是你們現在可以承載兩到三倍的量沒有問題，以目前後端的資源，大概需要再多一百倍的量就可以接受，意思是這樣。

所以如果這一個規模，以目前壓測的結果乘一百倍，所有的人跑來報稅也沒有問題，是這樣嗎？如果我算數有錯誤，請和我說。

這上面還有身分認證元件的設計考量，這不是單一方面關貿配合就可以解決。

但你們的Web版是已經在身分認證之後的，我是在另外一個畫面取得完身分認證查詢碼才輸入，所以理論上這邊的壓力，是從取得查詢碼開始算。

也就是你這邊如承載一百倍的流量，如果有一百倍流量的話……不一定一百倍，因為明年Windows的離線版還在，所以不可能全部的人丟掉Windows離線版，然後去用Web版。

假設是一半的人來用，你們這邊就是要承載上百倍，如果有上百倍流量沒有問題就不會問題，可以這樣說嗎？那這個是工程問題（笑）。

我自己的想法是，如果明年還留著Java Applet，別的版本做得再好，這些跳出來的安全性警告或者是事前安裝還是跑不掉，那大家今年最不舒服的那一點沒有解決掉，其他的部分都很好，但還是要花三十分鐘安裝。

裝完之後會有很舒服的過程，但是已前面經花了三十分鐘，這樣我們做其他的意義好像滿小的（笑），我不知道是不是可以這樣解釋？

我們在今年的時候有朝這一個方向去做，如果可行真的會下去做，如果真的大改是牽涉到兩個合約，第一個是行動版的合約，第二個是目前3G的合約，因為Java是在目前3G的合約上，我們把Java Applet拿掉，把行動版加進Mac跟Linux需求的話，人月數可能會不足的狀況。

你們本來Java Applet的維護約在今年省下來的人月，不能透過合約變更，或者是不變更合約、只是書面變更工作項目的情況下，轉移到Mac版嗎？

目前就現有的Web版來做，承載容量的部分，我們研究一下，我覺得是有空間的。

我們來談到的是108年年度，也就是把目前Java拿掉，未來要走的方向是Pure Web，或者是用做一個跨平台的離線版？

為什麼考慮離線版？因為Pure Web連線上去，一個人差不多三十分鐘左右，connection會非常大，所以這個是我們擔心未來會不會因為connection太大，造成民眾等待時間過久。

現在遠端很多機房的概念，變成我們要研究這一件事，到底用離線版的效益比較大，或者是用線上版，但如果要的話，scale來承載同一個時間爆量的connection，做2P就簡單了，因為連線了，一個人連很久，一萬個人要connection，可能會比較久，這個是我們目前研究的部分。

不過剛剛政委談的是，我們以現有的手機版方式來應用，未來明年我們把Java版拿掉，讓我們的承載可不可以負擔的量。

使用者認證我想暫時不改要用讀卡機，我們是用查詢碼的方法來做，我倒覺得可以找關貿來談一下，是不是把後面的scale做大一點，目前的量看能不能承載。額外的費用因為指示，我們是不是可以用預備金來解決，這也是一個解決方法，因此在現有的架構下把後面那個的提高，我覺得是有可能性的，我們再跟關貿洽談這一件事。

關貿，我們這樣的意見應該是ok吧？

我們配合中心研擬方向，再作細節的討論。

這個部分有三個部分：

第一，一個人力的調度，你們本來正在維護Java的工程師，如果調過來專門做Web，當然會有一段時間需要學習、轉銜之類的。另外一個是硬體資源上的，你們的Web的寫法，其實我有稍微看一下，理論上同時連線的人數不太是問題，因為大部分的運算量其實非常小，只是要有一個連結在那邊，並不是伺服器幫使用者作運算，都只是做加減乘除的事情，所以重點是在之前的壓測，看那個瓶頸在哪裡，看是否能克服，把動態式的後端機器變多的方式來調節，或者是比較好的網頁伺服器有比較好的連線量，但是不用每一個進程來處理，這個是技術上可以處理的方法，現在只是在本來維護Java的版本，Mac跟Linux來做而已。

另外一個是錢的部分，剛剛您已經說了。

如果有做這三個調整的話，我們可不可以把問題三的部分提前到明年上線？

剛剛討論起來的共識，初步目前看起來，大部分可以在106年申報，也就是明年申報可以有所改善，剛政委提到民眾關切的點卻是放在108年的合約處理。

先不管合約，其實對於技術團隊先不看合約的問題，因為合約的問題，中心會處理。我們現在先看技術面的部分，我們希望是不是可以再給中心一個禮拜的時間，請你們去測試，我希望可以提出現在版本，我們實際上去測它承載的量可以負荷到什麼程度，假設接下來有兩百萬人同時上線的話，可負載否? 你們認為問題出在哪裡、提出建議解法，我相信中心這邊會評估合約怎麼樣去做適當的調適去處理這一個問題，我們會希望可以在明年度報稅的時候，這一個部分就可以有所改善。

長期的部分，包含後台重新開發等等，我們可以放到新合約去處理，到108年的時候正式上線，讓它更穩定、讓使用者滿意，但有些要解決的點，我希望明年可以先解決。

但是目前沒有看到你們提出來真正技術的問題在哪裡，以及跟你們建議的解法是什麼，可是我目前看到的是，你們提出來的都是合約的問題，我覺得就算合約處理好了、經費也編了例如需要一千萬就編了一千萬，但是這樣的一千萬是不是真正解決問題或者我們只需要五百萬或者是二千萬才能解? 我不知道是不是可以給一個禮拜或者是兩個禮拜時間，真正測試找出現在的問題是什麼，然後提出你們的建議解法。

應該是說你們之前私下做壓測的時候，最後如果承載不了，那是什麼原因？

如果本來就有做這個分析的話，其實也不需要一個禮拜，我們現在就可以馬上解決這一個問題；當然如果你們需要額外時間才取得的話，也請直接說。

其實壓測相關數據，我要再回去諮詢一下，畢竟是我們私底下測的，有一些東西我們要再檢視，像這樣的測法，如果以後是要作正式大量的時候，這樣的測試方法有沒有需要調整的地方。

至於其他承載量問題的話，我想瓶頸的部分還是要回去找原因，畢竟這個跟連線數、點擊方式及動態設計都會有關係。

所以可以給一個大致的分析，很容易，因為在業界好比像你本來只派十台後端的機器，後來壓測的時候，發現當連線到多少人的時候，有一、兩台機器就會開始出現回應大於十秒之類的狀況，這都有標準的工具跟方法，只是仿效而已。

時間的部分，可能至少給我們兩週的時間，現在同仁都還在忙下稅後的事情。

無論如何Web版還是可以作為使用者代表賦稅署、工作坊的一個開頭，因為我們辦工作坊不可能給大家一些A4紙都是手畫的畫面，我們還是要有一個實際的流程給大家參考。之前民間辦的工作坊都是Windows版和Java Applet的Mac版為主，但我還沒有看到提案人用Web版。

因為其實很多人不知道有Web版，絕大部分的人不知道有Web版，所以還沒有看到以Web版流程為主的設計。

如果接下來以Web版當作明年主要方向的話，這一些工作坊就可以直接拿Web的流程來當作精進的方向。

而且Web有一個好處，即使關貿完全不改程式，設計師只是調整字體大小、流程、動畫，這一些在技術上是可以脫鉤的，也就是前端的開發，完全在技術上是獨立於關貿的後端作業，也不會影響到他們的壓力測試，也就是把CSS、字形換掉跟你們的壓力測試是沒有關係，這樣才有可能由致翔來說的由民間來看介面上如何規劃並優化，也不會卡到關貿的時程。

提出一個問題，明年方向如果導向以這一個版為主，原來Mac或者是Linux的使用者，明年是不是直接就不提供？

對，Java版就不再存在了。

原本我們也有想到這一件事。

我們今天有逐字稿，所以過了十個工作天後公開，基本上大家都會知道。

如果要讓部落客或者是民眾知道有一個講法，很簡單就是因為「資安考量」，Oracle都不建議使用Java Applet了，未來如果有資安的問題，他們也不會修補。當然財資中心是絕對不可能幫Oracle補漏洞，所以不使用這個。

這有點Windows XP或者是IE8，微軟都不支援了，一旦有漏洞，除非是Wannacry那種等級，否則都不修了，這個是一樣的考量。這樣應該大家可以接受？

OK，這個是幅度不小的變動，替代性的軟體要講得很清楚，第二個是要先讓民眾知道，免得明年要報稅的時候，已將MAC環境設定好的民眾一下無所適從。我怕會有這一個issue，因此要早一點讓民眾知道。

目前Mac的瀏覽器只剩下Safari可以了，到最新的這一版macOS Sierra，用Chrome或別的瀏覽器，其實也報不了稅，這是今年的狀況。

也有可能到明年Safari也不支援新版的Java Applet了，所以本來就需要告訴大家這一件事。

不好意思，我想請教一下，可以看到簡報第7頁，我們的解決方法（三），有提到RFP包含使用者介面UI、UX的規格，要納入108年的規格書的規劃。剛剛主任有提到108年的標案，現在可能已經在準備了，現在有辦法包含我們的需求嗎？這個部分我們打算怎麼做？RFP規格應該不是太大的問題，而是我們應該要納入什麼？

這個我們有一些討論，是不是可以說明一下？

像上次UI、UX，網路上有提一些建議、標準及原則，我們會follow，我們會訂在裡面。

我來回應一下，初步討論是這樣子，在108年合約，其實我們目前已經在討論，UI、UX有一些基本原則，上次有幾個教授來給予這些寶貴的資訊，所以這一個基本要求我們會納入，但這一些原則本質上是抽象的，所以我們接下來會在RFP要求，在開始規劃的時候就真的讓使用者一起進來設計。

設計完之後的雛形，我們找UI、UX專家跟使用者及我一起來檢視是否符合基本的原則，使用者有時不買這樣的帳，有時理論跟使用者不一樣，這個是第二級檢視，因此我們RFP會要求把這樣的程序包在裡面，一定要做到。

真正上線的時候，再做一次問卷調查，是不是可以達到需求，如果不滿意再修，這個是RFP會再要求的事。

但是最近有一個工作坊，也就是7至9月會討論比較細的，106年會討論，這一些已經接近要做的這些規格，也會納到裡面去，大概是整個討論的過程這樣子。

這樣討論出來的東西，某些在Web能做就先做，接下來的年度再精進，也就是有一個程序的關係？

對。

把Web版精進之後，這個不錯或者哪一些地方可以改，就可以在回饋的地方改，並不是各做各的，一邊做壞，然後另外一邊從頭做？

是。

會參考原來的系統的情況，目前系統的原始碼等資料也會交給未來的承商參考，基本上是不會整個重新來過，因為架構上是長期累積下來的東西，像一期、二期到現在，所以未來應該也會在這樣的基礎下，而且中心的經費其實也不是很足夠。

說到經費，我跟政委簡單報告一下，其實這一些費用都是額度預算，這個案子沒有在第五階段電子化裡面，所以年預算比較吃虧，因為公務預算的額度逐年減少10%，經費比較難。

若在5EG裡，也許會好一點。

我想錢不是優先考量的問題，我們先談，如果有困難，怡君也在這邊，應該可以幫一些忙，我們很多錢從這邊來支持的。

我們有前端的錢跟後端的錢。像後端的錢，是提到機房裡面需要有額外的機器，甚至不是固定的機器，而是報稅季看實際進來的流量，然後再租給他，不管是「財政雲端服務網」或者「綠能雲端資料中心」，那些還有經費嗎？

設備是先由關貿提供，未來擬定合約的時候，若需要額外的設備，就會變成我們要再調整一下合約，然後再extra補充費用給他們。

所以這整個是包含硬體、機房都是由這邊出，所以要用額外硬體資源的時候，你們這邊就要有一個額外的授權？

費用。這一個案子比較特殊，這一個案子是從系統設計到客服，都是委給他們做的。

好的。可以問一下，你們後端機房現在放在哪裡？

中華電信。

是某個機房？

中正紀念堂那邊的……數據中心。

是租用電腦，或者是直接買機器放在那邊？

整個機器都是為了電子報稅購買的，空間設置在中華電信機房。

後端有幾台，可以問嗎？

你知道嗎？

這個沒有辦法（笑）。

北部的AP server有六部，中部有四部AP server，上面還要架網路設備組。接下來有兩個報稅的DB server，另外一個是我們真正報稅的所得資料server，那個擺在我們這邊，這個是資安的考慮。主要大致是這樣，所以設備量不是那麼大。

所以未來如果需要做使用者體驗有關connection的問題，可能還要額外增加設備。現在設備是跑Unix系統，是嗎？

有人知道嗎？如果不知道就說不知道，沒關係。

不知道。

有一些AP server，跑什麼不重要，但是機器數量是固定的，也就是雲端自動延伸，你們本來沒有寫進去，可以這樣說嗎？

你們是固定數量AP server做負載平衡，現在變成一百個AP server的話，你們程式也要調整，還是不用調？

要調。

也就是說，之前壓測是以目前AP server的數量。如果無法負擔，那中心這邊要想辦法提供運算資源。

像之前別的案子——EMIC——也就是雨下很大的時候，大家要看防救災系統，路、水、電的目前民生資訊，那個有固定數量，但防救災跟報稅很像，一年裡面不會用到，某一個月份會很多人出來用，所以有固定的伺服器數量，後來發現到一個極限，像梅姬颱風可能三倍左右的話，硬體沒有辦法負載，但是要為了梅姬颱風的三倍買一大堆的伺服器在那邊是不經濟的，所以我們現在正在輔導他們跑到中華電信現在有一個可以做自動雲端延伸——HGR——的服務。

HGR是hicloud government region，是他們用目前賣給民間hicloud的方案，變成是在GSN，等於是政府內部網路裡面有一個專用區，但是在那一個區裡面可以做到負載高過某個量，自動開伺服器給你，只要把某個範本壓出來，就會自動開非常多台機器給你。

好處是我們在那邊可以做壓測，可以做到全國納稅義務人都來用的水準，然後HGR會告訴我們說到那個水準，在不調整程式的前提下會用多少機器的server，最多也是用一個月，不會超過一個月，就看因中心能不能負擔費用，如果不能的話，就要改程式，但幾乎一定是可以，因為是非常有彈性的，所以其實到晚上沒有人報稅，所以機器就縮回來了，是按照實際分鐘數計費，因此你們如果是用Java寫的話，要調整成這一個架構，如果你們是做多區負載平衡，所以理論上調整這一個架構，應該是不會做不到的情形。

如果真的有需要，我可以幫忙看程式（笑）。

你們設備好像要搬回去嗎？

這個沒有。

設備放哪裡都不是問題，政委給的建議是給財政中心參考，報稅不是一年內十二個月都在報，不管是營業稅、綜所稅都是區間，如何因應區間大量需求來考慮硬體設備的提供，現在作法就算是整體委外，概念仍比較像是財政資訊中心花錢去買設備的概念，只是這部分是透過關貿買的設備，且量不太夠。

如果今天投入大量的資源去投入硬體設備，可是一年只用一次的時候，兩年後、三年後，硬體設備會追不上軟體開發的速度，我們又得再花錢買設備。

所以其實剛剛政委建議的是，我們接下來的這一個報稅程式應該符合雲端資源調整的架構去做調整，當然程式必須作必要的調整，才能真正彈性做資源運用，在硬體的部分，我們不要做固定的投資、購買，而是用租賃的方式，去應付短期大量的需求，才能真正解決我們現在面臨到你們週期性業務的財政中心的問題，不管是合約或者調整，我相信財政中心可以作這樣的規劃。

包含108年的標案，也應該考量到AP調整的需求，一併要考量進來。

既然在108年的規劃案要做之前，我想這兩個禮拜的測試就非常重要，所以財政中心必須要深入跟團隊規劃測試，用什麼測試方法，我們才可以找到該解決的問題，接下來才能討論解決方案。

我們新的開發標案的原則就是用這種按分鐘的這種真正雲端、方法來規劃，但是我們理解明年，尤其是關貿改程式的幅度有限，好比用按日租賃或者其他的規劃方法，只要最後承載到那個流量，然後價錢不要太不合理，我覺得我們是可以接受。

如果最後出來太不合理的話，像剛剛災防雲，我真的有幫他們去調參數，有些是可以用技術方法解決的，我們就試試看。

OK。

謝謝。

所以Java Applet這邊大概就這樣子了，至於要如何說服大家，資安上Java Applet就不使用了（笑），這個是你們會幫忙有個說帖嗎？

這是我們負責的業務，說帖當然由我們準備，而說帖如何讓使用者比較能夠接受，請大家幫我們看一下。

要寫成「網友的聲音我們聽到了」，那個框架還是很重要。

就是對民眾的說帖，請團隊幫我們檢視一下。

聽了網友聲音最多的是我們的開放政府聯絡人（指財政部PO，金亨），我看他的回覆已經可以避開網友的地雷，每一個負能量都轉化成能量，我覺得已經有高手了（笑），PO群組可以一起幫忙看，但這個無論如何還是以你們的名義發。

我們是不是也可以大概兩個星期之後來看一下這樣一份說帖，如果接下來工作坊就要邀集大家以Web作為基礎精進，這一個說帖勢必要一起發，不然這一個東西一出來，大家都會問為什麼Java不改。

所以我們從對外溝通的角度來看，這兩個訊息一定要一起給，是不是一樣可以兩個星期之後，我們重新來看一下我們怎麼樣對外告訴大家說我們現在既要把Java改成漂亮的Web版了，也不會字元編碼的問題，因為已經是Web了，以及測試出來後，需要什麼樣的硬體、AP修改，但是介面的部分，我們現在可以開始用工作坊的方式，來看大家都沒有看過的Web介面，看有沒有什麼地方可以做得更好或更漂亮，大概是兩個禮拜之後來做這一件事。

大家有沒有別的什麼想法？

關於工作坊的內容，除了問題三之外，是不是都可以納入工作坊研議的部分？有一些有寫到，有一些沒有寫到。

你說像問題四也可以？

對，這個部分從問題再確認，也就是跟使用者及相關利害關係人再確認一次問題，然後再進行之後的設計及驗證，可能會比較精確、踏實一點。

其實我看起來沒有寫到的只有問題四而已，所以具體建議是把易用性的部分加到……

……對。

問題四跟問題五，問題五也加進去。這包含遙測，還是其實你們這個版本沒有要加遙測？

這一個版本沒有。

問題四有加進去。

問題五的部分是只有問題五-1有加到工作坊，問題五-3其實意思是標案需求規格，那個是接續工作坊的。

對，那是接續的。工作坊的結果，再來談使用者需求確定的時候，會在明年，在明年初談所謂的需求確定。

確定不在工作坊的，除了Java Applet之外，是在問題五-2（遙測）。有沒有不要的理由？我沒有說一定要或不要，只是如果說不要，也要經過評估。

我說明一下，遙測的功能，當時在5月19日的會議，他們說必須要像類似微軟蒐集的相關功能，因為報稅是每一年只有做一次，其實時間滿短，之前在開發階段時，我們就已經有邀集專家來做，一年一年就可以一直累積下去，也就是要開一個遙測功能去蒐集，這樣很像重疊。

我們記得協作工作坊的意思，是可以知道2％的使用者在第一個畫面會點錯再回來，然後再到第三個，可以看到實際的使用模式。

但是這個就可以叫做大數據了，因為人滿多的（笑），不是普通量的數據，也就是使用者平均的每一個畫面，看這一些字花幾毫秒，或者是看完之後沒有辦法知道做什麼，因此按求助，也就是每一個畫面最可能知道去哪裡，這個是遙測可以給你的訊息。

您剛剛的意思是其實在測試階段，已經有邀請專家做非常類似的事情，所以其實不需要靠遙測就可以做到，意思是這樣？

大概是這個意思。

另外一個考量，所得稅申報期間是5月份，原則上是5月1日到31日，通常會前三、四天開放下載所得資料，今年是4月28日開始提供下載服務，其間並不長，民眾只有這一段時間才看得到軟體，才能操作，也才會有剛剛政委講的，在哪一個畫面停很久，或者是有什麼意見，那時要改版，怕影響整個系統的穩定性，動輒發生問題，所以我們比較不建議。

當然這個數據蒐集起來，明年再跑，沒有要你們馬上改的意思，而是蒐集數據這一件事的本身，之前靠比較類似像使用者觀察或者是一些別的方式就可以做得到，不一定要靠遙測做，我聽起來的意思是這樣。

遙測一樣是蒐集這一些數據，我們開工作坊討論的群組，也是做相同的事情，如果在前面就已經先做，因為我們在滿意度調查的時候，會有相關的建議跟資訊蒐集，要做到這麼精進的遙測？投資報酬率是不是有不符的成本，遙測是不是靠其他的方式來解決掉就好了。

我沒有反對，我只是要把大家具體理由放到逐字稿裡面，當初提建議的人，我才可以貼連結給他。

我補充一下，工作坊中收到的會是針對報稅服務在規劃期間的意見，而滿意度調查與遙測屬於系統上線後蒐集到的意見，這三種方式收到的內容和意義不太一樣。

滿意度調查蒐集到的意見，比較聚焦在報稅流程完成後的整體的主觀意見，但遙測蒐集到的回饋是真實且客觀的數據，回饋的資料是細節的，有些細節資料比較不會反應在滿意度調查中，所以我認為這三種方式收到的回饋內容與意義不太一樣，再拉回來談是否進行遙測，開放大家一起討論。

其實滿意度會收到的特別是太不滿意高過某個程度才會寫給你，只是在某個畫面，大家等了一段時間，但沒有到太不滿意的程度，那個畫面比較早，所以就慢慢忘了，就比較難從滿意度調查拿到那個資訊，剛剛芳睿的意思是這樣。

如果我們要放遙測在之前的離線版或者是Java，技術上是非常困難的，在Web版是非常容易的，加一個Piwik這一類的軟體，其實一行JavaScript就做完了。

現在是有兩個問題：一個是使用者願意不願意被遙測，這個也許一開始要打一個勾之類的；第二個是後端需要分析，這個需要成本，而後面這一個成本其實比較大。

所以，可以完全理解如果明年版本，好比像我們只蒐集，而不分析，或者是明年先不分析，我們到108年再來討論要不要蒐集，我都可以接受，我只是說還是有其價值，並不是完全沒有價值的東西。這樣ok嗎？

（點頭）

還有沒有要討論的？

所以以剛才討論的內容，Web版比較容易做到，以今年或者是以往的申報情行統計，Web版使用者相對少很多，且比例差距很大，我們是不是等到明年？假設我們真的改了，而Web的使用者量有明顯增加，屆時再來討論是不是蒐集遙測的資訊，甚至做分析。

所以明年不蒐集？

對。

其實明年的策略，要就是把Windows離線版放在最上面，Web說測試版是下面，但是Linux或者是Mac還是只能用這一個版本。

我們如果測一測發現真的沒有問題，壓力測試也過了，甚至把線上版放上面，如果還在用老舊的Windows可以用離線版。可以保證使用者會幫我們做壓測，因為會大量的人用線上的，在那樣的情況下，數據絕對可以拿得到，現在只是說遙測的功能，我們拿到那麼多的數據之後，我們未必知道如何分析，所以我可以接受在明年先不加遙測功能，但先知道有這一個量，即使沒有特別加遙測功能，每一個Web是單獨的網址，如果靠Log分析可以做遙測工作，可以知道停留的時間，最基礎的還是可以做，大概是這樣子。

所以這一個工作坊的細部規劃，包含誰可以參加、在哪一些地方辦多少場，以及實際收到的意見有沒有比較公開的方式，讓大家知道像這一種幾乎是逐點回應，哪一個有採、哪一個沒有採，你們正在規劃嗎？

正在規劃。剛剛政委提的我們會仔細規劃。

對，有公開出來的話，看到有意見的朋友就會給回應了，而且這些朋友不會收錢，因為是他們自己要來回應，並不是我們找他們的，所以經費有限的情況下，這個不失為我們叫做「眾包」的方法，這個也是可以想的。

至少今天這一份簡報跟討論的過程，應該沒有什麼不能公開的吧！

是。

如果不能公開的部分，像機房位置的部分之類的，大家都會收到可以編輯共筆的頁面，可以再回去編輯逐字稿。我這邊沒有什麼（問題），不知道大家（有沒有要討論的）？

工作坊的形式可以問一下嗎？要繼續規劃下去，是完全沒有任何想法，是有打算給別的廠商來帶工作坊或者是希望內部就可以處理？比如金亨有經驗可以處理。

工作坊不是一、兩年，可能會一直做下去，運作的方式是國稅局賦稅署，原則上是以5月19日協作的專家、部落客及一些意見領袖，看能不能透過他幫我們找一些使用者我們希望可以把程序公開，不會給外面的使用者隨便上來，也就是要上來的話，必須要類似專人，這樣好聯絡，像第一次接洽是不是留email，我們可以知道有誰、並知道多少人及對象是誰來測試，我們可以蒐集到他們的意見，大概這樣子，才可以找到使用者，不然他們都在外面，怎麼會找到他們。

就是有一個公測的伺服器，那個就是即使不是報稅期也可以試著報稅？

對。

是真的資料嗎？

這個要後面再來討論，這個還是有個資的問題。

是啊！但如果不是真的資料也可以，我的意思是就是這個Web介面，開放大家在6月份以後還可以用，好比像使用者代表框定了二十人，只讓這二十人事前先用，在工作坊來討論；或者是會希望每一個人都有受邀請，又可以邀請他的親朋好友去測，負責收攏他們的意見回來。

類似這個意思，開會不可能找把使用者都找來，是找那個領頭，我們的構想是這樣。

他不一定是自己家裡報稅的那個人，我們在協作工作坊的狀況，可以給他邀請碼的概念，就是這二十個人再邀請二十個親朋好友（去測），不是讓全台灣的人又回來測，這樣主計不一定負荷得了，至少讓確定會來的人再發邀請碼出去，那幾個人不能來，但可以事前先玩，這樣的想法可以怎麼帶過來，這個是具體的建議，可以廣泛蒐集不同族群的意見。

之後工作坊會不會由PDIS小組用幾次協作工作坊的形式協助？

當然，很好，非常歡迎。

財政中心先規劃，可以先請金亨幫忙處理，金亨有需要可以找PDIS，也就是書漾、芳睿來看看有沒有什麼需要協助的。

需求驗證也滿重要的，其實到今年底之前，雖然我們是叫做「做工作坊來確認現在的系統Web版或者是其他的版本有什麼問題」，這個部分驗證很重要，但是工作坊這三個字，我們彼此瞭解會稍微有落差，如果要幫忙的話，很願意跟金亨聯絡（笑）。

金亨是我們重要的開放政府聯絡人（笑）。

財政中心規劃到一定的程度，可以找他們討論。

好，要不然針對工作坊的進行方式，我們先作比較具體的規劃，規劃完之後就找PDIS幾個先進談一談，未來實作工作坊時，請PDIS視情況一起join。

好啊！財資的那一個場地非常適合，如何運用那一個場地，我們也累積了一些經驗，有任何幫上忙的地方就可以直接講。

我報告一下，雖然我參加很多次工作坊，但我覺得它是一個滿專業的技術，其實很重要的是顧問引導跟最後的收納及歸類，我參加這麼多次，還沒有辦法把握這一塊。

下次你（指金亨）來帶（笑）。

我們希望可以漸漸培養PO做這一件事，可以協助金亨。

我們跟PDIS會密切聯繫，有需要的話，還是要用專業的能量。

我當然呼應芳睿的說法，我們整個目的希望政府比較快速收攏意見的方法，各個部會的朋友們能夠慢慢培力出來。

剛好這一個案子滿熟悉的，所以在這個過程中，我覺得並不是完全什麼都是由芳睿或PDIS朋友全部自己做，很願意把自己做的how to跟事前的這一些briefing一起帶著大家來做，但是實際在工作坊的時候，當然很希望大家接觸到的桌長或者是主持人（財政部同仁），你們在常規的業務中……因為剛剛已經講到這一個可能包含使用者需求、測試，都是每一年會發生的事情，我們也不會永遠在這邊，至少讓大家可以轉移過來，大家就可以做，這樣好不好？

謝謝。

我想再接著補充一點關於為什麼期待這麼做，因為政府有最多的專業知識與人力，也希望這樣的專業資源能夠累積在部會裡面，所以仰賴外部專家學者、使用者、廠商的部分，建議採用協作的方式。政府的組織一直存在且能夠累積能力，外部合作對象則是非常有機會變動，雖有各自的專業面向，但沒有部會裡全面的專業知識與人力，如果在做後續規劃的時候並沒有讓部會內的人力主持，會有知識上的落差，產出的公共服務也會有缺陷。以這次報稅的議題來說，可以由財政部同仁為核心，再與外部人員配合，使更多「知識與能力」(knowledge & know-how)可以累積在部會裡，讓公共服務的規劃有一個系統性的脈絡，如果財政部在協作上面需要幫忙，PDIS小組也樂意協助。

以後別的部會要做類似的事情，就放財政資訊中心的錄影帶，就說這樣做就對了，如果有什麼不懂就來找金亨。

程序上我有幾個想要提的：因為今天會議上後續方向有一些修正，可能這份簡報會有簡單調整，拜託金亨連同逐字稿一起在join上面發布，會後一起處理。另外，這一個案子滿有指標性，是不是也可以比照之前的案例，製作政策履歷。

我們無論如何兩個禮拜之後又要回來，壓測跟主機的配置，還有中心這邊的對外說明為什麼Java不要用，因此邀請大家來開工作坊，這個要對一次。

不知道承辦單位是不是需要我們出一個會議紀錄？或者是用逐字稿就可以？公務程序上有沒有我可以協助的部分？

我想會議紀錄倒不是非常需要。

如果有需要，再跟我們講。

列一下，才不會漏掉。

其實部長、次長也滿關心這一件事。

所以大家的意見希望還是提供會議紀錄。

就是重點摘要。

做比較會聚焦，不然怕會漏掉或失焦。

大概就這樣，謝謝大家。