前言

你好！我是數據科學家塔蘭丘拉。

「數據科學家第一年究竟在做什麼，會遇到什麼困難，什麼才是最有成長的部分？」
這個問題對於正在追求這個職業的人來說，無疑是非常關心的。然而，當真正去尋找時，發現大多是“閃亮的成功案例”或是“僅僅技術的討論”，而能夠切身實感到實作經驗的文章卻意外地少。

因此，這次我將分享作為一名新進數據科學家工作了一年的經驗，實際上「哪些學習有效」、「哪些是繞了遠路」、「想更早知道的事情」，並儘量從實務的角度整理出來。
我希望這篇文章著重於現場的可觸感內容，而不是華麗的敘述。

這篇文章特別適合以下這些人：

• 準備成為數據科學家的學生或社會人士
• 想從無經驗或不同領域轉職為數據科學家，並希望提前了解現場真實情況的人
• 雖然學習過技術，但對於如何進行工作尚無法想像的人
• 想了解第一年“成長者的行動方式”的人

在數據科學和AI工程師中取得成果所需要的不僅僅是「技術能力」，溝通及推進工作的綜合能力也是必不可少的，這在我一年中深有體會。

在本文中，我將整理出我在這一年中特別認為重要的幾個重點，依次為：

• 溝通：減少認知偏差，最小化重工的方法
• 技術能力：在實務中有效的「雖然不起眼但強大的」技術
• 工作的推進方式：面對不確定任務的推進框架
• 副業的推介：在本業中難以獲得的學習和成長加速的理由

以上內容並不是“這麼做就是正解”的談話，而是我在失敗中學到的目前最佳經驗。
如果能幫助到處於相似處境的人減少繞遠路的機會，那我會非常高興。

此外，我也在X平台上發佈有關數據科學和生成AI的相關資訊。
我每天都在Qiita上發佈一些無法寫完的小知識和學習，如果有興趣，希望能夠關注我，這將是我不斷努力的動力。

那麼，首先簡單介紹一下我第一年的工作內容。

第一年的工作

本章將作為前提，簡單分享一下「第一年我在做什麼工作」。
接下來要寫的「溝通」、「技術能力」、「工作的推進方式」的學習，都是基於這些業務內容的體驗談，因此先確定這一點會讓閱讀更流暢。

我在第一年主負責的工作是利用生成AI進行應用開發。
不僅僅是傳統的「分析報告撰寫」或「模型建構」，我有機會深度參與到當前現場日益增多的「將生成AI融入產品」類型的開發中。

說極端一點，最近「數據科學家」的角色不僅限於「建模人員」，
而越來越多的場景需要一個以生成AI為前提，快速創建和改善產品的人（當然這視公司和團隊而異，但我的體感確實是這樣的）。

在實際工作中，我不僅是處理生成AI（LLM），還負責：

• 創造用戶輸入並返回結果的前端體驗
• 負責API、數據處理、驗證、提示管理等後端工作
• 並查看質量、速度和成本的平衡實施到運營改善中

整體上負責的工作接近全棧工作。
這段經歷與後面提到的「溝通」和「工作的推進方式」的學習直接相關。

此外，我在第一年便開始挑戰副業。
在副業中，我建立了一個利用生成AI自動製作社交媒體報告的系統。

最初，我完全獨自承擔設計、開發和運營的工作。
需要整理需求，實現系統，並持續運行，因此我在某種意義上，對於「工作的全貌」有了迅速的鍛鍊。

最近我們增加了兩位成員，目前三人合作推進開發。
經歷了獨自進行的階段和團隊合作的階段，我更深刻地感受到溝通的重要性。

溝通

那麼，接下來我將寫一下關於“溝通”的學習。

「數據科學家和工程師最重要的終究是溝通。」這句話在學生時代聽過很多次，但在一年的工作後，我深刻體會到這是事實。

老實說，在入職之前我認為「只要技術力足夠，就能取得成果」。
當然，技術力是重要的。然而，在實際工作中，這與溝通能力同樣重要，甚至在某些情況下可能更直接影響成果。

這個原因很簡單，由於生成AI的普及，技術的“底層提升”正在進行，實施本身的速度比以前要快得多。
但另一方面，往往成為工作瓶頸的不是技術本身而是溝通能力。

換句話說，溝通能力高的人工作效率更快。這種差距，直觀上感覺就像是「天壤之別」。

在這一章中，我將其中特別重要的溝通總結為三個模式來介紹。

1. 在解釋前提的基礎上，提出問題或議題
2. 在結構性整理後發言
3. 在被詢問進度前，隨時分享進展

在解釋前提的基礎上，提出問題或議題

在向上司或其他部門請教時，如果直接問「這怎麼做？」對方首先需要了解情況。
結果可能導致：

• 問題偏差
• 回答偏差
• 需要額外的詢問
• 更多時間浪費

因此我開始注意使用“前提→論點→所需判斷”的順序去提問。

• 前提：我正在做什麼，目的是什麼
• 情況：目前是什麼狀況，什麼是問題
• 論點：我在哪裡迷茫（如果有選擇則列出）
• 諮詢：希望對方處理什麼或告訴我什麼

例（形象化）
「我的目標是◯◯，目前已經做到△△，但是卡在□□。選擇有A和B，我偏好A，但風險是〜。您認為需要選擇哪個進行？」

這樣能大幅減少對方的認知負擔，提升回答的質量和速度。
更重要的是，可以逐漸建立信任，對方會覺得「這個人會整理情況後帶過來」。

在後續的討論中加入「前面的回顧」也會讓溝通變得非常順暢。

在結構性整理後發言

在會議或諮詢的場合中，邊整理思路邊開始發言，往往會在途中迷失。
這樣會導致「到底想表達什麼？」的情況，使討論中斷。我也經歷過這種情況多次。

這裡有效的方法是：結論→理由→具體（如有需求，接下來的行動）。
這類似於PREP方法，但在工作中這個順序確實強而有力。

推薦的發言順序

• 結論：我認為應該這樣 / 提出這個建議
• 理由：因為〜（判斷的依據是什麼）
• 具體：數據/例子/前提條件
• 接下來：下一步要做什麼（若需諮詢則為“希望決定的事項”）

此外，因為數據科學領域的論點易於散開，發言前如果可以說一句

• 「有兩個論點」
• 「我要決定的是A或B」
• 「結論是〜」

這樣的“標籤化”可以避免聽者迷路，非常推薦。

結果不僅會讓會議理解的速度變快，
而且「這個人發言很有條理」→「重要的問題會聚集」→「更能被賦予責任」
好循環比較容易出現。

在被詢問進度前，隨時分享進展

在第一年特別有效的就是這一點。我覺得每個人都應該這麼做。
進度分享不僅是「報告」，而是為了減少返工和不安的行為，這樣理解後，壓力減少了。

上司問「進度怎麼樣？」時，很多情況下是因為想解決：

• 可能延遲的不安
• 不知道哪裡卡住的不安
• 何時可以看到成果的不安

因此，提前短暫且定期主動發佈進度，工作會變得驚人地順利。

總結

到目前為止所寫的三點，並非是關於天賦的話，而是任何人都能重現的模式。

• 前提→論點→判斷請求進行諮詢
• 結論→理由→具體地闡述
• 在被詢問前，短暫地共享進展

隨著生成AI的推進，實施速度加快的同時，工作中的差異往往集中在「認知對齊」上。
因此，若在第一年就鍛鍊好溝通作為“技能”，成長的方向將會改變。

接下來的章節將寫出在實務中有效的「技術能力」。

技術能力

接下來，我將寫下在第一年學到的「技術能力」。

在學生時代的我專注於新AI算法的理解以及生成AI的實作本身（如提示、RAG、LLM應用等）。
當然，這些都很重要。然而，進入實務後，我強烈感受到實際中被評價的“技術能力”內容與預想中的差異之大。

第一年的數據科學家/AI工程師基本上是 player（參與者）。
也就是說「設計、製作、運行、修正、改進」的人。
因為不論是分析還是開發，都是動手推進事情，這樣的角色使得技術能力更傾向於“短時間內迅速製作可運行的東西，並穩定運行的能力”。

在本章中，我將總結在第一年中特別重要的技術能力，分為三點。

1. 掌握前端、後端和基礎設施的全棧技術
2. 精心考量實施設計，在評審中運行PDCA
3. 能夠對實施區域做到“全行”邏輯性解釋

掌握前端、後端和基礎設施的全棧技術

隨著生成AI的崛起，生成AI應用的需求急劇增加。
在許多情況下，首先需要的往往是能夠把生成AI“產品化”的非工程師，而不是僅僅能夠使用LLM的人。

在實務中，處理生成AI的部分往往不會單獨存在，通常的情況如下：

• 前端：用戶輸入並返回結果的體驗設計
• 後端：API、驗證、數據庫、提示管理、日誌、錯誤處理
• 基礎設施：部署、環境變數、監控、擴展、成本管理

這意味著機器學習算法或生成AI更可能成為應用內部運作的組件之一。
在這種情況下，能夠理解自己範圍以外的領域、並順利平滑地促進團隊間的協作的人，會比僅僅完成自己任務的人更為強大。

當然，並非每個人都必須成為全棧工程師。
但在第一年的時間裡，至少要理解：

• 自己的實踐「連接在哪裡、運行在哪裡、可能壞在哪裡」
• 當出現故障時「需要查看哪裡才能進行排查」

這樣理解後，開發的速度和質量都會有大幅的變化。我目前也正在努力學習關於基礎設施的知識！

精心考量實施設計，在評審中運行PDCA

第一年中，經常會出現的情況是：先寫出來 → 寫完大量代碼後再進行評審（我也有過這樣的經歷）。
但這會在後期帶來困擾。
「這裡是不是從根本上就需要變更設計？」這樣的意見出現時，返工的量會非常大，讓人難受。

因此，我開始意識到評審應該在“實施後”而是“設計階段”時進行。

例如：

• 對於責任分配的分割（哪一層承擔什麼）
• 資料結構和I/O的設置
• 對未來的擴展（功能新增、模型替換、提示更動）的耐受性
• 在運營中可能會發生的阻塞點

在編寫代碼之前，我會稍微整理並分享這些內容。
等到設計固化後再進行編碼，不僅能提升實施速度，評審的提出意見也會變得更深入，而不是僅僅是“表面”。

這與溝通也是相似的，但作為技術能力，我認為“能夠通過良好的設計和良好的代碼寫作進行PDCA”是第一年中區別的關鍵點。

能夠對實施區域做到“全行”邏輯性解釋

在生成AI及Cline、GitHub Copilot等代碼生成普及的當下，出現一個問題的比例反而增加。

「這為什麼這樣寫？」

即便不是自己手動編寫的代碼，即使是AI生成的，評審時也會被問及。
若不能回答，會出現以下的狀況之一。

• 無法判定是否需修改，代碼變成“黑箱”
• 當出現事故時無法追溯原因，導致運行失敗

因此，我強烈意識到在提交之前，至少要能用自己的話解釋：

• 為什麼選擇這樣的實施（目的）
• 有哪些選擇，為何排除它們（比較）
• 有哪些前提和約束（條件）
• 哪裡可能發生故障，如何檢測（運營）

做到這一點後，利用AI提高的實施速度，將能花更多時間在“設計、判斷、評審應對”上。
並且當能夠掌握這些後，逐漸會感受到，自己已經從純粹的實施參與者（player）向一個被賦予責任的角色靠近了。

副業的推介

接下來我將寫一下「副業的推介」。
雖然聽起來有點自以為是，但我在第一年便以AI工程師的身份從事副業工作。

副業的公司是一家社交媒體運營代行企業，最初幾乎都是獨自負責AI開發的工作。
具體來說，不僅僅是實施，還包括

• 整理應該製作什麼（提案）
• 需求定義和設計
• 實施和檢驗
• 維護運營（改善、故障處理、運營流程整備）

誠實地說，第一年的數據科學家/AI工程師能夠在這種程度上擁有自由裁量權並「製作和運作產品」的機會並不多。
因此，這段經歷非常寶貴，最終也實現了與本業之間的相互促進效果，這效果遠超預期。

推薦副業的理由（優點）

副業的好處不僅僅是「收入增加」。
在第一年中實際體驗到的特別有四點。

1. 本業與副業的學習循環（成長加速）

可以將本業中學到的知識應用於副業。
在副業中遇到的困難，能以本業的見解得到解決。
這樣的往返運動使得學習的鞏固力度大大提升。

實際上能感受到「學到的東西不再只是自我認知」，而是能迅速變為可用的技能。

2. 自主權大，從提案到全部經歷

副業中因為是小型AI團隊，自主權極大。
在實務中成長最快的並不是「作業」，而是

• 決定做什麼
• 確定範圍的界限
• 思考為誰提供什麼價值

我覺得副業很容易讓人強制性地體驗到這一部分。

3. 能夠在第一年踏入在本業中3到5年後可能經歷的事

在本業中由於角色分配和評審體系的完善，經歷往往以階段性為主。
而副業良好或不良的對於「全部由自己」負責的情況時有發生。

這種“超越自我”的經歷，最終提高了我在本業的視野。
（思考「我現在所做的任務對整體有何影響」這一習慣的養成是很重要的）

4. 收入增加（精神上的餘裕）

這是一個現實的好處。
收入增加後，學習上投資（書籍、工具、雲端費用）也能變得更容易，並且有了精神上的餘裕。

缺點（真實的困難之處）

當然缺點也是存在的。
以我為例，除了本業的定時工作外，還需要每月增加約100小時的工作。

這相當辛苦。
睡眠、運動、人際關係的崩壞都會影響到本業，因此無法在所有人身上無條件推薦。

不過儘管如此，我感受到的收益仍然壓倒性的大。

副業尋找方式和開始方式因人而異，如果有興趣的話，可以隨時與我咨詢。
視時間而定，若有機會，我的副業開發中還能有少量人參與的可能性。

• 具備很強的動力
• 能長期共同努力
• 能實踐上述第一年的學習

這樣的朋友我非常歡迎！

最後

謝謝您讀到最後。
在本文中，我總結了作為新進數據科學家一年來的學習，儘量以實務的感覺傳達出來。

回顧第一年，我強烈認為，取得成果所需的不僅是「技術能力」，
還需要通過良好的溝通來減少認知偏差，擁有推進工作的“模式”。
並且像副業這樣能夠從提案到運營全過程經歷的環境，成為了加速成長的重要契機。

今後我也會持續提高溝通能力和技術能力，繼續發展副業，實現更大價值的工作。
透過這些累積，我期待在五年後實現自己的夢想和目標。

此外，我也在X平台上發佈有關數據科學和生成AI的學習和試行錯誤。
如果本文對您有所參考，請務必關注我，這將是我繼續努力的動力。

未來我也會持續在Qiita上分享從實務中獲得的學習。
如果有什麼可以參考的，請按讚和收藏！
謝謝您。

原文出處：https://qiita.com/tarantula426/items/193f9df4db110f1bb817