雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
如果你對數位趨勢的議題很感興趣、你不是工程師但喜歡四處找數位工具提升自己的工作效率，或是因為接觸了 Ragic、Zapier 等服務，對「不用寫程式，就能做出 XXXX 應用」的軟體有些好奇的話，「No Code」是一個你可以認識、探究一下的新名詞。
不用寫程式，就可以透過特定工具做到傳統需要寫程式才能做到的事情，例如建立表單系統、ERP，因為這個「No Code」工具已經幫你把底層的程式寫好了。這個詞目前沒有很嚴謹一致的定義，所以大家想像中 No Code 工具的範圍可能不大一樣。不過比較沒爭議的是，Ragic 就是一種 No Code 工具。
和 No Code 類似的另一個名詞是「Low Code」（低代碼工具）——就是只要寫少量的程式，就可以達到傳統要寫一堆程式才能做到的事情。
（我們針對 No Code 概念的詳細說明可另外參考這篇）
最近， Ragic 的 Jeff 受邀到一個 podcast （線上廣播）節目——三創育成基金會的《星箭廣播》當來賓，就是以「 No Code」這個議題為主題。50 分鐘的節目裡，聊到了「趨勢觀察者口中的 No Code 新趨勢是什麼」、「No Code 到底是不是一個趨勢」、「No Code 的定義要畫在哪裡」、「工程師對 No Code 的矛盾情感」、 「No Code 到底對一般人生活 / 工作產生了什麼影響」，裡面也提到了許多 Ragic 的經驗。你可以直接點下面的播放器收聽：
或者另外點擊節目收聽連結：請點這裡。想看文字版的，我們下面提供了完整的開場後的逐字稿，這裡逐字稿的分段目錄跟《星箭廣播》的章節目錄是一組的，有需要的話可以搭配著聽 / 看。
Titan: 今天很高興邀請到一位來賓，他是我們國內新創公司 Ragic 的創辦人，他自己本身也是工程師——郭家甫 Jeff 。Ragic 是一個讓使用者可以不用寫程式，也可以在類似 Excel 這樣的介面去建立資料庫軟體的一個線上工具。Jeff 你好，我們先請你跟我們的觀眾自我介紹。
Jeff: 哈囉大家好，我是 Ragic 的 Jeff ，我們是做企業雲端資料庫的一間公司。
Titan: 就...就這麼短？
Jeff:對對 ^__^
Titan: 我們之所以要邀請 Jeff 來上我們的節目，是因為他的背景和他們的公司，跟我們今天要聊的主題「 No Code」——不用寫程式也可以達到一些我們要做的軟體功能，這樣產品的概念有高度相關，所以我們邀請他上節目聊 No Code 這個主題。他們的 Ragic 這個產品就是有 No Code 的概念在裡面。
為什麼我們今天想要跟大家聊這個議題，其實是因為我們不約而同在今年年初在不同的地方都看到在討論 No Code 這個主題的文章，甚至 Maxine 本身自己已經寫過介紹 No Code 工具的網站，（網站名字）就叫做「NoCode」，No 和 Code 中間沒有空格。（註：可點此查看網站）大家可以去我們 StarRocket Medium 看這篇文章，或者如果你有訂閱我們的科技創業週報，第 191 期的週報也有介紹這篇文章。
我一開始注意到 No Code，是因為今年 1 月多的時候看到一篇文章，是 High Growth Handbook 這本書的作者，叫做 Eliad Gil 寫的。 High Growth Handbook 這本書的副標題叫做 Scaling Startups from 10 to 10,000 People ，就是說一家公司從十個人成長到一萬人的時候，這個過程應該怎麼應對。
這個人（ Eliad Gil ）他的背景是，他以前有在 Google 工作過，後來變成連續創業家，他創辦的公司後來被 Twitter 收購，剛好他就經歷了 Twitter 從 90 個人成長到 1500 人的過程。我讀的那篇文章的標題叫做 Interesting Markets: 2019 Edition ，就是 2019 年他覺得有趣的市場。
其中一個吸引我注意的是他講「 devsumer 」的這一段。 devsumer 其實就是「 developer」加上「 consumer 」——以前我們可能聽眾有聽過的一個詞叫做「 prosumer 」，就是「 professional 」跟「 consumer 」（的結合）。這個詞其實是滿老的詞，應該是 1980 年的詞，「專業的消費者」，或早期有一個比較艱澀的說法叫做「生產消費合一者」。這個詞已經太久了。（當時）他只是在講說，有一種人，他是會消費他自己生產出來的東西，然後是專業的。
今天的話，這個概念比較像是：有一群人，因為自己的喜好或是因為自己的背景，他對一般消費的事物比一般人更了解，所以比如說一台電腦（買）回來，他可以自己組裝，按照他自己的喜好去組裝 PC 。另外一個，我自己個人的理解是，現在有很多電子產品，一般消費者在市面上可以買到的東西，基本上就是專業級的。一些 YouTube 用來剪接五分鐘短片的工具例如 Final Cut Pro ，跟一般業界導演拍片時用來剪接的工具，很有可能跟本是一樣的，我們也可以拿來講這就是「 prosumer」。
回到 Eliad Gil 那篇文章講到的 devsumer ，他在講的是，如果今天你是一個不會寫程式的人，你也在一家不是科技公司的公司工作的話，以前如果這家公司想要提升員工的生產力，比如說建置一個 ERP 系統或是會計系統，他就必須找導入顧問公司、找ERP公司來協助他們導入；要開一系列的教育課程，去教育他們的員工去使用這些工具，或者這些公司就必須有一個部門去協助開發這些產品。
可是 devsumer 這個東西或是這個市場的產品，可以讓本來根本不會寫程式的人，可以用他們的方式，打造出符合他們需求，例如業務需求的 CRM 工具、或是企業內部要做 ERP 系統的，他們很有可能都可以在不懂程式的狀況下，先打造出一個大概可以用的產品。
這是 Eliad Gil 觀察到的趨勢。這件事情會讓本來不是科技公司的公司，或是所謂的中小企業，本來需要大量仰賴外部的人，或是有一筆專門的支出找顧問公司幫他們協助導入，現在可以比較有能力去 access 到本來需要寫程式才能做到的事情。
他在文章中間有提到一些案例，比如說把 SQL 資料庫或者 Excel 報表變成一個應用程式平台，比方說 Airtable 或者是Retool 這種工具。
他也有提到 Notion 或 Coda 這種新型態的文件產品，或者更簡單講， Zapier 跟 IFTTT 這種串接 API 的工具，尤其是 IFTTT ，大家可能已經聽我們星箭廣播講過 N 遍了，它就是讓使用者用圖形化的介面，去串接不同的 API。
這兩股力量結合在一起，熟悉操作電腦或網路的工作者——就是我們這一代，可能也許 50 歲或 40 歲以下，成長過程中已經很熟悉使用電腦了，加上這種新型態軟體出現之後，Eliad Gil 就認為中小企業跟員工個人可以取得過去沒有的程式化的能力，達到（過去沒有的）成果。他在文章最後有估計，他覺得這個市場——因為文章就是講說他認為 2019 有趣的市場，他以投資人的角度來看，市場估計規模有 50 億美元那麼大。
他舉例說， Airtable 的估值——當時是一月底， Airtable 有經過一輪募資，估值超過十億美元，就是大家俗稱的獨角獸。當然我們在講市場規模的時候，不能把新創公司估值加一加告訴你說，市場規模就這麼大不是這樣，但我想 Eliad Gil 就是要跟大家說，業界是滿嚴肅在看待 Airtable 這樣的公司。
Maxine: 剛剛 Titan 分享的這篇文章比較是以公司、市場來看待的，我自己第一次接觸到 No Code 的話，就像 Titan 一開始講的，是我 2018 年底寫過一篇文章介紹一個就叫做「NoCode」的網站，這個網站還滿實用的，它就像是一個導覽或是一個工具箱的概念。它上面會依照你的需求是什麼，比如說你想要做數據分析、你想要製作一個 app ，或你想找繪圖軟體，或最簡單製作表單問卷功能，依照這些屬性來分類，把網上可以用的資源整理起來。
創造這個網站的人叫做 Sam Dickie ，他自己本身就不是工程師。他其實有一個完全專業的領域，是環境科學，可是因為他自己很喜歡自己手作某些東西，像是 3D 列印，所以他也喜歡做一些小型的專案。他其實有分享過建立「NoCode」這個網站的目的，希望很多像他這樣不是資工背景出來，不會寫程式的人，但也想要手作或實際做一些東西出來的人，有一個地方，可以協助他實現某些想法的地方，或找到這樣的資源。
這個網站跟 Sam Dickie 的故事，算是我首次比較淺層接觸到 No Code 這個概念。後來又在今年 2019 年初，Product Hunt 的創辦人 Ryan Hoover 在 Medium 上發表的一篇文章，那篇文章的標題其實很明白就直接寫了：「The Rise of No Code」，他把 No Code 這件事情當成一個趨勢來看待。
大致上，那篇文章概念就比較呼應我剛剛前面講的 Nocode 這個網站的概念，他是比較以個體消費者、沒有技術背景的一般人，透過 No Code 這樣的工具，有種被賦能 empower 的感覺感覺，每個人都可以當 Maker 這樣。當然，那篇文章也有提到一點可能是工程師吧、或是某些（族群）對於No Code 現象的質疑：一間科技公司也好、或者是明明有龐大的技術資源或是技術能力團隊的公司，為什麼在技術決策上，有時候會去選擇一些 No Code 的方案？
當然他那篇文章是很簡短地講到，可能企業考量到可以快速搭建某些東西，方便後續的維護。我想這一塊可能是我們今天邀請 Jeff 跟我們聊他作為一個工程師、或以經營一家 No Code 這樣服務的公司，可以提供我們多一點的想法。
Titan: 我跟 Maxine ，我們各自讀到的文章，可能是比較以「投資人角度」，或「個人使用者」的角度來看待 No Code 這件事情。那我們今天要請 Jeff 跟我們分享「工程師的角度」，尤其是他的公司就是以 No Code 為主打，以他的角度解釋一下怎麼看待 No Code 。
Jeff: OK。剛剛 Maxine 有提到的一點說，很多新創公司決定用 No Code 來提高內部組織效率，第一個提到的就是開發起來會比較快，不用找資訊人員。大家很常忽略最大的好處（其實）是「維護成本比較低」。
（只要）有 code 寫出來，你需要的維護成本往往遠高於你的想像，因為你 code 寫出來之後，一定會想要改，不可能寫出來百分之百 perfect 不會改，維護成本往往是意想不到的高。你可能花一小時寫的 code ，可能之後維護的時間是三四個小時，這種事情是常常有的。
如果是有這樣 No Code 的工具，就不會需要重新找開發人員來開發、或花比原本意想不到的成本來維護這個東西，所以我覺得「維護成本」比較是沒有系統開發經驗的人比較沒有想到的好處。
Titan: 能不能請 Jeff 先聊聊什麼是你心目中的 No Code？對 No Code 的趨勢有什麼觀察嗎？
Jeff: 剛剛聽 Titan 跟 Maxine 講，我覺得對於技術人員跟非技術人員（來說），對 No Code 、Low Code 這部分的看法是完全兩件事情。
本身我是開發人員，No Code 對我個人來說是「工程師的浪漫」：我一開始接觸了很多資料庫系統開發，所以我想說，漸漸發現資料庫系統其實要做的事情還蠻重複的，大部分都要資料庫讀、寫、刪除、修改，固定要做的事情其實非常多，要寫的程式也很像。身為工程師最討厭的就是重複的 code ，就想說能不能做出工具，用很快的方式完成原本一樣要達成的效果。
這是我自己一開始踏入這領域的一個想法。可是其實「把程式碼越來越高階」的想法——所謂低階就是 assembly （組合語言），寫一些越來越貼近機器講的話的話就是低階；所謂高階，就是越來越接近人類講的話。
程式語言的發展，一直以來都是從低階往高階發展，從一開始的 assembly 到 C、C++ 到Java，甚至比較圖像式的語言，這個趨勢其實幾十年來一直存在的。你程式語言越低階，可以控制到的東西越多；程式語言越高階，能夠控制的東西就越少，可是越低階就越難開發，越高階就越容易開發。
對開發人員來說，有一個情感上的特色：多半程式人員都覺得，以前的人寫 assembly 寫 machine code 可以控制到那麼低階的東西，好厲害！以前的人，是拿一張卡片在上面打洞，變成程式去發射火箭，那樣子感覺是「真正的工程師」該做的事情。在圖形介面上拖拉，比較像小朋友在寫程式。
所以對工程人員來說，寫程式的人常常會覺得低階的比較厲害，高階的像玩具一樣不那麼厲害，變成 No Code、Low Code 這些工具比較常使用的人，往往是非技術人員。而在原本一般來說要來開發這些程式的人，反而沒有那麼喜歡 No Code、Low Code 的一些工具。這是我們一開始在推Ragic 的工具比較沒有想到的事情。
我們原本是想說，這種東西，開發人員一定超愛的！我們可以節省他多少時間，一下子就可以把它做出來。後來發現，開發人員有他的尊嚴，覺得這不是把我原本辛辛苦苦寫的東西變得好像兒戲嗎？就開始展現他們的東西可以做到多細（No Code 不行），就會有這樣子的掙扎。
可是對於非開發人員，就完全不是這樣。非開發人員原本就不會寫程式，所以今天你給了他這樣的工具，可以做 CRM 、訂單管理，他覺得非常開心啊！可以幫他打開整個的門：原來我自己就可以把我的對於產業的知識，灌注到資訊系統中！我可以做出各種很神奇的東西！對於他，是非常開心、非常興奮的事情。（這個工具）開發人員和非開發人員的看法是非常不一樣的。
所以說，其實 No Code、Low Code 這些工具，其實對於非技術人員、原本不會寫程式的人來說，是非常有吸引力的，因為他們可能其實懂的是其他東西，他們可能對於房地產、對於營造業、對於晶圓製造非常熟，他們只是不會寫程式而已，可是對於系統該有的邏輯，他們都非常清楚。當這樣的工具給了他們一個魔法棒，突然變成會寫程式、能夠變出資訊系統之後，他們反而變成最熱情擁抱 No Code、Low Code 技術的人。
Maxine: Jeff 說的對我而言很有感，因為我今年二月就是嘗試著去寫 Python。其實 Jeff 剛剛講的，你本身對這個領域技術了解的位置在哪裡，對工程師來講的話，其實 No Code 沒有那麼強大吸引力，（沒有）開啟一扇門的感覺；但是對沒有技術的人來說，我突然覺得我可以寫一串程式碼的時候，會覺得自己很厲害。
Titan: 對於我來說，我覺得我們找 Jeff 來應該是滿對的，因為我沒有想到工程師不是很喜歡、或者說對於 No Code 這個概念這件事情是有矛盾心理在裡面的。的確他就是有效率、節省時間，但是掌控度又不在自己手上，對工程師就是比較不能接受，或覺得比較奇怪的事情。
Jeff: 對，這件事我原本我就會做啦！而且我原本會做到百分之百，它（No Code 工具）讓我只能做 80% 。雖然它也讓我原本要花 100 的時間變成只要 20 ，可是（工程師）他就覺得我剩下那 20 要怎麼辦呢？開始掙扎，而且覺得缺少展現他工程師才華的地方。
Titan: 補充解釋一下，剛才有聽到 Jeff 在講 No Code 跟 Low Code ，其實跟字面上有點像。No Code 就是不用寫程式，Low Code 就是你在使用這個工具時，你還是要會寫一些程式才行（但只需要寫少量的程式）。
回到剛剛 Jeff 講的，我們發現一般人像我跟 Maxine ，我們對 No Code 這件事情跟工程師看法似乎有一些不太一樣的地方，我們想請 Jeff 再深入去談對這件事情的想法。
Jeff: 一開始在談的時候我們會發現，突然開始討論 No Code、Low Code 大家就會很高興，覺得過去的各種東西好像都是 No Code。
比如說，我過去不會架網站，現在有 website builder 讓我們可以架網站了，這是不是一種 No Code？原本我要寫程式才能做一個購物車、購物網站，現在我讓不會寫程式的人也可以勾勾勾設定之後，就變成一個購物網站，這樣是不是一種 No Code 的方式？
（但這樣討論下來）絕大多數的雲端服務都變成 No Code 了。我開始覺得，界線必須畫在某個地方。這就回到一開始討論雲端運算、 big data 的時候，所有程式都是 cloud computing 只要在伺服器上、只要有資料就是 big data 資料，這樣界線會不知道切在哪裡。
所以我仔細想了一下，我自己分類了一下——這是我自己的分類不是官方的分類，我大概把它分成三類：
第一個是原本有一個趨勢叫做「 Bring your own device 」，BYOD，後來（這趨勢）漸漸變成「BYOA」， Bring your own application，大家把個人常用習慣的帶到工作上來用。
比如我習慣用 Google Drive 管理我的檔案，我拿到辦公室跟大家分享我的檔案；或我習慣用 Evernote、OneNote、Notion 來做 Note taking （做筆記），我把這樣的工具拿到辦公室跟大家使用，我認為這就比較是個人的 Bring your own application 的方式來做到由非資訊部門幫部門導入一些生產力工具的一件事情。
再往進一步走，是我們剛剛講到 website builder 或是 e-commerse 的購物車工具，這就不只是個人，是整間公司整個團隊要一起維護的。像是 Wix、Shopify 甚至 Zapier、 IFTTT 這些整合工具，這是一整間公司或一個團隊要一起使用的。
最後，再進一步，才是我心目中的 No Code 。前面兩種做的事情都有一個特色，就是雖然是說你不用寫程式，可是你能夠做的事情是很有限制性的。比如說， website builder 你就只能做網站、購物車就只能做電子商務的東西，你拿一個 Dropbox 就只能管理檔案，你拿 Evernote 就只能做筆記，其實產品設計就是只能做某件事情。
再進一步說，我們其實有另一種工具，例如 form builder、Google Form 或是 Survey Monkey、Typeform，他們這種東西能夠做的應用可以稍微可以再廣一點，可以搜集各種資料。再進一步說，可能是一種 database builder ，可以涵蓋的範圍就更廣了。比如說 CRM、ERP 系統、 HR 系統，或是公司內的 KM （知識庫）系統這種資料庫系統，都有可能藉由一些 database builder 的工具來做出來，我就認為這個比較接近我心目中 No Code 的方式，因為一般人或許可以藉著這個工具，做到傳統來說一定要由資料庫系統開發人員做的事情。
Maxine: 我這邊提一個問題好了。看起來這三個分類， Jeff 心目中的 No Code 工具好像都跟「資料」比較有關係？
Jeff: 對對對。
Maxine: 因為我剛看像您說 form builder ，像 Typeform ，對我這種非技術的人，對我來說，他們就是「做表單」。我可能沒想過他們就可以搜集資料、可以做更進一步運用，對我來說他們就像 Evernote 做筆記、 Typefotm 做表單，這樣而已。
Jeff: 對，嚴格說來他也是一種「應用」，只是，一個 form 就是資料庫應用裡面最基本的「輸入資料」或「維護資料」的元素，他可以長成的東西的可能性就會多很多了。
Maxine: 這果然就是工程師與非工程師看到的世界就不一樣！
Titan: 不知道Maxine 有沒有聽過一個其實也是今年才有的一個新創公司，強調的就是用 Google Sheet 可以做成一個 iOS 或者 Android app 叫做 Glide 也是微軟工程師的創業。還有一個叫做 Sheet2Site ，就是用 Sheet 可以做成一個 Site ——大家可能沒想過 Excel 表單可以做成一個網站，他的概念有點不是那麼直覺。我們看到表單覺得可以做問卷調查，但其實用表單可以做出一個訂單系統或部落格，都是有可能的。
我們聽完 Jeff 剛才解釋他把應用層級分成三種，只有所謂的 form builder 或是 database builder 比較是他所謂的 No Code ，我們可以發現他的看法跟我們一開始聊的......有非常大的落差（囧），像我們講的 IFTTT ，對他來講可能就沒有在這個範圍裡。我想這是我們的聽眾，不管是工程師或是對這個領域沒有那麼熟的人來說，可以多了解一下真正工程師的看法，跟我們在網路上讀到的趨勢文章的看法、出發點是不一樣的。
剛剛 Jeff 有提到程式語言的發展從組合語言到後來的 Fortran 或者是 C 語言、現在更高階一點的像是 Python 這種的，或是還有那種圖象化像 MIT 做的那種 Scratch ...
Jeff: 對啊，越往高階，大家都是希望走到一個程度就是，你不需要去學語言。只是到目前為止，大部分情況都還是：有一個語言可以跟電腦溝通，還是比較方便一點。
＊＊＊＊＊
Titan: 那想請問的是， No Code 這件事情，個人在組織裡...像 Eliad Gil 有講到，非科技業的員工可以因為 devsumer 的產品或是 No Code 類型的工具，讓他對組織有一些影響。我想問 Jeff 這樣的問題；另外是像 No Code 這樣的產品，對工程師有什麼影響？
正面反面可能都有，那我們想請 Jeff 先從可能比較正面的影響來講。
Jeff: 正面影響，除了一開始有稍微提到維護成本低很多之外，有很大一個好處在於說，通常透過這個方式做出來的應用，會比較實用。這個東西是由 End User 自己做出來，解決他們每天實際遇到的問題，這個東西是他會很想要用，而且是真正能解決他的問題的。
因為傳統來說，通常 IT 部門在推資訊系統的時候，都滿痛苦的。例如要導 ERP ，要導 CRM ，這種東西通常底下行政部門都會一片哀嚎，覺得原本好好的為什麼要做新的事情，要學新的東西，而且上線以後通常還是會哀嚎很久說，為什麼要帶來那麼多麻煩。原本他們可能覺得很簡單的事情，要變成用很複雜的方式去做。
其實這是有它的原因。導套裝軟體 Package software 這種東西，通常是很龐大、對一般的使用者而言很痛苦的。一套系統例如 SAP ，幾萬間公司都是用像這樣的軟體，同一套東西，要去給石油業、要去給晶圓業、要去給補習班用，都要用同一套，這個功能絕對是包羅萬象、什麼都有，而你用到的只會是其中一點點的部分，變成為了要去解決你的一小部分的問題，你要去學很龐大的軟體，要去維護很龐大的軟體，過程其實是非常痛苦的。
而且就算這個軟體很龐大，通常也還是沒辦法涵蓋你的需求，通常只能夠涵蓋非常核心、每間公司都還比較類似的部分才會涵蓋，所以用起來都滿痛苦的。
Titan: 聽眾可能看不到我們的表情，但是我跟 Maxine 都在點頭。
Jeff: 對，因為其實我們以前也做過 ERP 導入，使用者真的會用到哭。從另一個方向，你不用套裝軟體，你有另外一個方式就，是我們找 SI 、外包廠商、系統整合商來做一個好了。像我們政府標案，都是這種東西客製化的，你說什麼，我們就做什麼，這種東西......其實還是很痛苦。
因為第一個，我們提出需求的最好狀況是，（由）最終端使用者（來提）。終端使用者一開始就要很完整描述，要什麼東西做成資訊系統。如果有做過，就會發現，這是是非常困難的東西，你常常會說我要做這樣、那樣，等工程師說，好！我這樣把它做出來之後，你會發現不對，這不是我要的，我意思是另外一個。這樣就會改來改去，專案會延宕做不出來，工程師會生氣說，你當初不是要這樣嗎？其實我不是這個意思。這會造成我們一般客製化專案很痛苦的原因，而且這已經是比較好的狀況了。
比較糟糕的情況是：公司高層說，他們（ 軟體公司）業務說我們可以做什麼東西，可以做出怎樣的報表，聽起來很棒，那我們就來做吧！但這是高層要用的東西，對基層沒有明顯好處的東西，變成讓他們日常工作，更麻煩。這種情況原本已經是很困難，要開發出這樣資訊系統的情況，如果不是 bottom up ，而是 top down 的方式從高層來的話，對實際上要使用系統的人造成的痛苦就會更多。
那我們透過 No Code 或 Low Code 或是我們叫做公民開發，讓實際使用者可以設計出自己的系統的時候，他們一定會設計出可以解決平常最嚴重問題的工具，沒有人會拿石頭砸自己的腳。我自己設計的話，我一定會調出我平常工作最順的方式，所以會確保這個工具比較實用，比較不會好高騖遠，一定是最基本解決他們平常每個行政人員、每個客服人員、業務人員，或是在做 Marketing 的人平常會碰到的問題，這是第一個很明顯很正面的部分，做出來的東西真的會比較實用。
再來就是維護調整。因為系統很少有做出來上線之後就是一百分的，一個真正好的系統往往是慢慢調出來的，所以一個系統上線一個月之後，我們自己實際使用的人就會知道，哪裡不太順？我們可以哪邊的欄位加一下、哪邊加一張表單，會讓整個流程更順，不用再找到開發人員來寫 code ，我們自己就可以來修改這個東西，既會減少維護的成本，也會縮短改善的時間，很快的系統就會漸漸進入方便好用的狀態。這是我觀察到 No Code 或 Low Code 在公司應用上很實際會看到的好處。
Maxine: 但如果我們今天回頭講...因為今天 Jeff 講的是使用者，想要使用這樣工具的人，他等於自己有很大的彈性對自己客製化的狀況。可是以一個企業組織來看，如果每個人、每個部門都可以自己決定的話，會不會對老闆或管理部門會有疑慮？
Jeff: 會，絕對會，以 No Code 或 Bring your own application 來說，其實碰到公司第一個問的問題就是：資訊安全怎麼辦？你們又不是資訊安全的專業的人員，你們做出來的東西真的安全嗎？這些都是公司這麼珍貴的資產，我放在你們這些外行人做出來的系統裡面，是不是有真的符合我們的安全規範，跟我們用的套裝軟體或是請專業的程式人員開發出來的（相比），資料是不是真的有安全性？這是公司一定會問的問題。
不過這個問題其實是比較可以解決的。 No code 設定上其實可以做很多考量，很多這都比較是可以解決的。大家最常問的反而相對比較好解決。
第二個常常碰到的是政治問題。資訊系統絕對不只有資料在裡面，牽扯到流程和人的問題，最常見的資訊的政治問題，就是資訊部門很難看、被打臉，資訊部門說這個 CRM 系統很難做啦，這個至少要兩年、要多少預算，結果我們的 Sales 部門覺得兩年後才有哦，那用別的東西、用 Ragic ，一個月兜一個系統，覺得欸、不錯，上線吧！問一下資訊部門行不行？我們要用系統。
這時候他們就很難看了，給老闆看，會覺得你們專業資訊部門，有那麼多資源，說要兩年才能做出來，要多少錢；可是人家 Sales 部門自己很快就做出來了，而且他們覺得很好用，怎麼辦？這時候資訊部門就會很反抗，會想辦法刁難。
這時候資訊部門也滿無辜的，他們是啞巴吃黃蓮，有苦說不出。看起來類似、功能也類似，不代表他們做的工是白費的。資訊部門用 code 寫出來的東西，掌控度、精細度，還是優於 No Code 的部分，只是對公司而言，你為了最後 10%、20% 的掌控度，要花十倍時間成本來完成這件事情，這就是公司高層自己會有考量。
尤其是高層又不是很清楚技術或需求細節的話，就會覺得資訊部門很難看，就會產生一些政治問題，造成 No Code 在推的時候遇到資訊部門的刁難。
一開始推產品的時候，（我們）覺得資訊部門是我們的好朋友，因為我們會讓他們效率變得超高啊！但結果反而有點相反，我們主要使用者其實反而是從一般使用單位、行政部門、會計、財務等等，他們反而會覺得找到一個救星的感覺。
Titan: 對工程師呢？工程師會覺得影響工作嗎？我前面講到 Eliad Gil 講的，他有講到，比較淺層的工程師可以做的事情可能被取代了，這會對工程師的工作造成影響嗎？
Jeff: 我覺得不會耶！開發人員實在全世界來說都太缺了，每間公司想要找到工程師都有它的難度，大家都在搶人。現階段能夠取代掉的仍然只有資料庫系統的開發，如果能夠取代也只是一小部分的人。而且我實際觀察，有些人導入 Ragic 之後，還會找一個人來管理 Ragic ，做更多應用，只是差別是用他更熟悉的工具去涵蓋更多組織的資訊需求。
因為其實組織的資訊需求實在是做不完。全球前五百大公司有多少資源去做企業電子化？還是做不完！台灣最大的台積電，每天還是有多少人不斷在開發維護他們各式各樣的資訊系統。我們只希望有更好的工具，把看似海樣做不完的事情，更有一點希望，讓我們的每間組織能夠更加真正電子化一點。因為現在大多數組織電子化程度仍然非常低，非常多資料仍然在 Excel 、在紙上面這樣。
Titan: 不知道大家記不記得我跟 Maxine 在講未來地圖那一集說到，雖然新科技會取代一些工作，但他也會創造工作。剛 Jeff 也有講，用 No Code 產品的公司後來反而會專門請一兩個人來使用 NoCode 工具做現在的應用，不管是維護或是開發，而不一定是「我們不用再找人來開發了」這樣。
另外Jeff 剛剛有講到 IT 人員在面對 No Code的「威脅」，可能 IT 部門的工程師常常要面臨各方外行人的挑戰，不知道對工程師或 IT 部門來說，會不會有一種恐懼，這個東西都可以做到七八成我要的功能了，難道就不用工程師了嗎？或者非 IT 部門的人會有這種想法說，我們不用工程師了吧？大多數我都可以搞定，其他部分就交給 No Code 工具的廠商就好了。你覺得這種狀態是有可能的嗎？
Jeff: 其實像 No Code 只是把寫程式這部分拿掉了，在程式以外，在建構企業的電子化、建立資料庫系統時需要的一些能力（來說），寫程式只是裡面的一小部分而已。寫程式以外，我們看到這樣的工具，什麼樣的使用者比較適合把這樣的資訊系統做得好呢？通常是他的邏輯能力比較好的，基本的資訊能力也是有的，有辦法把「非結構」的問題變成「結構化」的、變成表單和一筆一筆的資料，有能力解決非結構問題的人。通常有這種能力的人，可以把這件事情做得比較好。
另外還有一個很重要的能力，是溝通能力。他能夠去召集不同部門，討論清楚彙整成大家都能接受的版本把它做成資料庫系統。這其實也是傳統資訊部門要做的事情，他需要開會研究大家的需求、了解各部門真正要做的事情是什麼、最後才是回到辦公室去把它寫成程式。
討論需求、彙整需求、解決非結構性的問題，其實本來就是他們工作很重要的一部分，只是在 No Code 的未來，這件事情不一定需要會寫程式的人才能做。你如果溝通能力更好、更能夠解決非結構性問題、更能夠讓大家取得共識，知道資訊系統和組織的資料要怎麼管理，那你可能更適合做這件事情。
（不過）傳統的資訊能力在這裡還是有相當重要的角色：一般來說，比較有資訊背景的人設計出來的資料還是比較好維護。我舉個最簡單的例子。我們常看到客戶用我們的工具，有人會把一月的資料變成一個 table，二月的資料變成一個 table，或者是台灣的客戶做成一個資料表、中國的客戶做成一個資料表。
但以資訊人員來說，就會覺得你們這些資料表的欄位基本上大同小異，是不是你們可以把他們彙整成同一張？你會發現，這樣好像比較有道理，有時候資訊人員跟非資訊人員有一些小差異，資訊人員設計出來的資料架構，一張表單可以化簡為繁、涵蓋這麼多張表單的需求，就會讓資料比較好維護、不會有不必要的複雜。資訊人員有資訊背景還是有這方面的好處。
另外，處理資料的時候還是需要注意一些資訊安全的問題，通常資訊人員會稍微比較有一些資訊安全的敏感度，會知道哪些東西要隱藏，密碼不能放在表單裡，有一些基本概念，或者他們對個資的隱私、資訊系統常面對到的法律問題，基本觀念會比較具備。
總而言之， No Code 就是把寫程式的部分拿掉，可是剩下來就資訊系統開發，其實還有非常多部分的能力是要累積的，未來就是看誰最具有這部分的能力來做，而不一定是程式設計師。程式設計師有他的優勢，只是未來可能會變成另外一種職缺。
Titan: 剛剛我們聊的大概都是一般工作者，企業組織的部分。我們接著想要聊的部分是， No Code 這樣的工具對我們一般人的生活、乃至於社會的影響。
大家可能有一些經驗，就是你的親朋好友要結婚宴客，現在可能有些人會收到喜帖之外其他形式的通知，比如有人在 Facebook 直接成立一個 Event page ，邀請大家參加婚禮；另外也很常見的是你會收到一個 Google 表單的網址，看你那天能不能去、要不要攜伴，幾個人，甚至會問你要不要停車位，其實以前可能都是喜帖或電話聯繫，或可能就沒辦法確切知道多少人要來參加婚禮。我想有了這樣的工具靈感，或大家可能不管是學校或工作場合學到了這樣的工具，你可能會發現日常生活也可以套用這種東西。
想問 Jeff 你覺得 No Code 這樣的工具真的可以在某種程度讓技術更民主化一點嗎？或說對我們社會上的影響，你同意這種說法嗎？還是你會覺得這種東西講歸講，但實際上還是會有障礙？
Jeff: 不會，其實我覺得剛才講的很多障礙都是針對企業。對個人來說，這些工具能夠帶來的好處都滿明顯的，對個人來說，他能帶來的好處不少，而且比較沒有剛剛提到的後遺症。
Titan: 剛有聽到你講到、我們自己也一直提到「未來」這個詞。我們知道台灣現在教育的狀況，我們想要讓義務教育的課程也涵蓋寫程式，我們認為這是對於培養未來人才很重要的一件事，教育部就把這件事納入義務教育要學的東西。但有人質疑說，讓我的小孩多了功課、多了學業負擔、未來做的工作不一定跟工程師有關；另外也有人會覺得，對家長是負擔、家裡的小孩能不能學好這個科目沒有把握，是不是增加一個麻煩？
另一邊看法是，程式教育重點不一定是學寫程式，而是透過程式教育教會小朋友邏輯概念，知道運算的基本原則...
Maxine: 我這邊有一個比較直白的提問，就是：我第一次接觸 No Code 概念的時候，我比較把重點放在：「No Code 已經可以取代掉寫程式」。 同時我又接觸到「全民寫程式」這個概念，那時我是想說：「有 No Code 啦！為什麼還要那麼小就提倡寫程式的概念？這兩個概念是不是有點矛盾或衝突？」
Jeff: 從小寫程式有一個比較大的好處是，對於電腦怎麼運作，程式怎麼運作，比較有基本的概念。我自己有兩個小孩，我有給他們買寫程式的機器人「dash & dot」，他可以用類似 Scratch 的方式來讓機器人移動。
我的小孩一個才五歲、一個才七歲，教他們寫程式還是會遇到瓶頸啦，我還沒有特別看到什麼成果。我的確同意說，如果能透過寫程式，讓他們對於邏輯性能夠訓練出來，是很好的，但不太確定他們是不是能做到這一點。
不過，透過寫程式的經驗，至少對於程式能做什麼、什麼是程式容易做的、什麼是程式不容易做的，會有一點概念的話，對於工作會很有幫助，例如你未來擔任 PM ，在跟工程師溝通的時候，會比較知道自己要求的事情，是不是天馬行空、根本做不到的，或者這對工程師來說是非常困難、還是非常簡單的。
因為對非技術人員來說，常常很困擾的是：我不知道這個要求是他花十秒還是十天才做得到的。當你稍微寫過一些程式，你至少會有一些概念，不會瞎子摸象。職場上會有比較立即明顯的優勢是在這邊。
Titan: 再請問 Jeff 一下，我們很喜歡看趨勢的文章，一開始我們講的也是兩個在科技領域打滾很久的人寫的文章，讓我們想到這個主題。不免俗想問你的觀察：像 No Code 這樣的趨勢，他後面催生的應用，哪部分比較有機會有取得比較爆發性的成長？我們常常會喊說今年 IOT （物聯網）會很紅、或是雲端對企業的生產力有很大的升級，或是你剛剛講的電子化。那 No Code 這個趨勢你覺得會有這方面的影響，或讓哪個領域的產品冒出來嗎？
Jeff: 我覺得......雖然我自己公司也算是 No Code 的領域，我還是覺得這個領域一定會有一些產品出來，真正解決問題、變成很流行、變成大公司的產品，但能夠成功的重點，還是在於他有沒有解決企業或消費者的問題，而不在於它是不是 No Code。 No Code 我覺得他只是一個結果，只是解決問題的方式。
到頭來，還是要看這個產品到底解決了什麼非常多公司會有的問題。它們一定是透過解決這些問題，成長為非常茁壯的產品，而 No Code 是一個結果。透過 No Code 的方式，產品有 No Code 的特性，突破了過去需要透過開發人員才能夠做某件事情的一個困境，讓一般人也可以更快達到我們要的事情。
No Code 會是一個產品的特性，而不是最後的結果，我們不是為了 No Code 而 No Code ，是為了解決某種商務上某些問題。因為實際上我們做出來的東西，仍然是各式各樣的資料庫系統，去管理資料、或是其他應用，No Code 是過程，不是結果。
Titan: 我必須說 Jeff 的答案跟我預料的......並不相同。但剛剛聽他回答的過程中，讓我有一個靈感。剛剛問問題的時候，有提到 IOT 這件事情，產業界或是商業趨勢的人已經喊了很多年，但各位觀察你的親朋好友，真正使用 IOT 的多不多？我覺得 Jeff 的答案某一部份可以解釋這個現象：它是不是真的有解決大家的需求？才可以變成這個產品普遍的特性。
例如智慧型手機解決了很多以前發現自己沒有這個需要的，所以現在變得很普遍，大家都想要用這種隨身型的電腦，可以用來溝通、拍照，大家應該很有感，用 LINE。可是 IOT 就是我們想把他當成趨勢來喊、來催生，但市場或者終端使用者並不覺得有解決到他們這樣的問題，所以大家常討論說，這個東西什麼時候要起飛呀？好像沒有真正很明確的分界點，有點像以前智慧型手機在 iPhone 之前以定義來說也有很多智慧型手機，但從某個時間點Android 也加入進來之後，智慧型手機這個產品的類別就這樣爆發出來。是不是我們可以從 Jeff 的回答看 IOT 的趨勢？我覺得說不定可以。
Jeff: 趨勢都缺「殺手級應用」。趨勢在有能夠落實的殺手級應用之前，就只是個趨勢。等到有能夠真正解決問題的應用，它就真的是能夠產生商業價值的地方。
Titan: 今天跟大家聊 No Code，先跟大家解釋，我們覺得是趨勢的這個東西，延伸出我們想要討論的主題。
後來我們跟 Jeff ，從工程師還有 Ragic 從新創公司產業的角度來看，他跟我們解釋了自己的三層的分類，讓我們知道我們原本對No Code 的解釋，對工程師來說不是那麼容易接受；另外就是，在企業和個人組織對 No Code 趨勢會帶來可能的影響是什麼。
最後我們還有跟大家聊到 No Code 這個東西，一開始我們原本會用到趨勢這個詞，但後來覺得比較像是當我們發現這些好用的工具之後，它有一個共通點，就是有 No Code 的元素在裡面，好比 Maxine 在最前面講到的，他之前介紹的 NoCode 網站。為什麼會有 NoCode這個網站，上面列出來的產品並不是為了我們要產出 No Code 的產品而開發出來的，只是為了要解決某一個問題，剛好這些結果被建置 NoCode 這個網站的人察覺，這些工具，我其實不用寫程式我就可以使用，把這些工具放在我的網站，把他列出來，對這些跟我有相同需求、但不會寫程式的人來說，是有幫助的，所以最終還是要回到是不是能解決這個問題，最後還是要回到 Jeff 所說的：所有趨勢都缺殺手級應用，這才是比較關鍵的部分。
