隱藏在朗神球棒的秘密:「木棒職人」久保田眼中的鈴木一朗

隱藏在朗神球棒的秘密:「木棒職人」久保田眼中的鈴木一朗
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

不論是在日本職棒或大聯盟,打者隨著自己年齡和經驗的增長,調整球棒尺寸或重量似乎是必然發生的,但職棒生涯超過四分之一世紀的鈴木一朗卻是最大的例外。

文:張尤金

1959年,中學剛畢業、16歲的久保田五十一,為了找一個離家近、可以通勤上下班的工作,他去應徵位於岐阜縣西部養老郡養老町的「美津濃養老工場」(現名Mizuno TECHNICS)擔任工人,沒想到這一待就是55年。

說到美津濃公司,這是出身岐阜縣大垣的水野利八1906年在大阪創立的,之後發展成為日本最大的體育用品及運動服裝製造商。雖然二次大戰期間美津濃工廠一度轉為生產戰爭用品,但戰後隨即重回運動老本行,並致力於研發與技術的提升。

1959年入社的久保田,一開始就被分配到木棒的生產線,六年後(1965年)養老工場開始生產職棒選手使用的木棒,並逐漸贏得日本職棒打者的信賴。1985、1986連續兩年贏得太平洋聯盟打擊三冠王的落合博滿,以及同期間連續贏得中央聯盟打擊三冠王的Randy Bass,他們都是使用美津濃養老工場出品的球棒。

更精確地說,推升美津濃球棒在美日職棒聲名大噪的頂級球星,包括鈴木一朗、松井秀喜、Mike Piazza等,這些VIP客戶的球棒都是出自久保田之手。全盛時期美日職棒每年大約有180名球員、12,000到13,000支球棒,都是由久保田和兩名助理手工打造的。

在久保田的大牌球星客戶中最讓你意想不到的,或許就是大聯盟安打王Pete Rose了,活躍於1960至1980年代中期的Rose,早就是美津濃球棒的愛好者。雖然近年來Rose曾經因為一朗的美日職棒通算安打紀錄而多次提出質疑,但事實上他們的球棒可是系出同門,都是由久保田親手製作;而且兩人對球棒的要求,套一句廣告台詞就叫做「追求完美,近乎苛求」。久保田回憶說:「Rose與一朗的打擊型態或許不同,但他們兩個人對於球棒的挑剔態度卻是有志一同。」

不過Rose與一朗對於球棒的要求方向大不相同,久保田進一步補充,他說Rose一直到1986年退休為止,對於球棒的規格一直在改變,不斷反覆要求將球棒做得略長或改得更短。

然而一朗正好相反。自從一朗在歐力士的第一年秋天告訴久保田「棒頭重了一點」,要求將棒頭前15公分的直徑減少0.05公分以來,他的球棒規格從此沒有再改變過。

命運的安排

久保田的名字叫做「五十一」,這個名字的由來是因為父親在51歲才生下他,故以此命名。至於讓他在美日職棒界名聲達到頂峰的球星鈴木一朗,最具代表性的球衣背號也是「51」號,久保田認為「這就是命運的安排」。

一朗與久保田的第一次相遇是在1992年,當時同樣效力歐力士的「賢拜」小川博文帶著一朗來拜訪他。當久保田問一朗「慣用什麼球棒」時,一朗的回答著實讓他嚇了一跳。

因為一朗使用的是巨人明星二壘手篠塚和典的球棒規格,這種球棒的棒頭比較細,適合廣角打法使用,但因為擊球面積小,打擊難度更高,通常要有高度球棒控制能力(bat control;バットコントロール)的打者才能駕馭。這也就是為什麼當久保田看到菜鳥一朗竟然使用這種球棒時,他會如此訝異的原因了。

說到棒頭粗細,打者難免有種迷思,認為棒頭較粗的球棒能增加擊球面積,提高安打的機率或降低揮空的次數。但一朗可不這麼認為,過去他在受訪時就表達高度自我要求與極為嚴謹的態度:

「很多人都以為粗棒才好打,但球棒粗只是容易碰到球而已。」

與其用粗棒打到不該打的地方而出局,我寧願用細棒揮棒落空。」

「想正中球心就用細棒打擊。」

不過話說回來,細棒倒不是一朗讓久保田最驚訝的一件事。

超過四分之一世紀的堅持

不論是在日本職棒或大聯盟,打者隨著自己年齡和經驗的增長,調整球棒尺寸或重量似乎是必然發生的,但職棒生涯超過四分之一世紀的鈴木一朗卻是最大的例外。

打從歐力士第一年的秋天以來,一朗的球棒規格(包含長度、棒頭直徑、握把直徑)就從來沒有改變過。換言之,一朗必須透過持續不斷的訓練來維持球技與體能,才有能力在超過四分之一世紀的職棒生涯使用相同規格的球棒。

至於球棒材質,一朗用的是北海道特產的青梻木(アオダモ),又稱「日本樺木」。青梻木砍伐後通常只能作為木棒使用,但樹木終歸是天然生長的植物,即便是優質的青梻木材,每100根最後能做成一朗球棒的只有個位數,而久保田每年大約要提供一朗80到90支球棒。

題外話,一朗在2016年春訓熱身賽被發現他所使用的球棒由原木色改為黑色,不再使用原本的日本樺木球棒。原因在於日本樺木被過度砍伐,幾乎消失殆盡,不得已只好換球棒。

事實上,2001年一朗渡海挑戰大聯盟之後,考量美國天候與日本不同,而且多數大聯盟打者都用白樺木球棒,於是他決定放棄過去日職時期慣用的日本樺木球棒,改拿白樺木球棒,而且因此還打出單季242支安打的大聯盟史上菜鳥最多安打紀錄。不過2015年為了找回打擊手感,他決定換回熟悉的日本樺木球棒。

有圖為證,這是一朗從2001年以來所使用的球棒:

1
Photo Credit: Keith Allison CC BY-SA 2.0

2015年移籍馬林魚之後改用原木色球棒:

1
Photo Credit: Arturo Pardavila III on Flickr CC BY 2.0

但2016年之後又改回黑色木棒:

鈴木一朗
Photo Credit: Reuters/達志影像

一個有趣的數據:一朗一年平均消耗80到90支木棒,相較於日本職棒選手平均每年使用大約120支球棒,更凸顯一朗出類拔萃的打擊能力。畢竟在棒球比賽中,打者因為沒有確實掌握擊球點而將球棒打斷的情況屢見不鮮;相形之下,一朗對於擊球點的精準掌握能力,足以將斷棒的機率壓低,這是他精簡使用球棒的一大主因。

大師級的木棒職人

還記得這一幕嗎?

1

2014年球季結束後,一朗受訪時提到自己曾經在比賽中甩棒,結果馬上後悔,賽後寫信向製作球棒的師傅道歉,甚至還當場自己掌嘴。

一朗的父親宣之篤信天地萬物皆有靈,棒球手套和球棒亦如是,所以他教育一朗,對於球具必須抱以尊敬和感恩的心情。就像下面這一幕,一朗不會把自己的球棒置放在公用的球棒架上,相反地,他會將球棒與手套恭敬而工整地擺放在球員休息區,彷彿它們都有自己的座位一般:

1

久保田是美津濃公司唯一賦予「大師」封號的「木棒職人」,日本厚生勞動省還在2003年推選他為「現代名工」。不管是對自己的工作、每位客戶、乃至於每支球棒,他都有同樣尊敬的心情:

「我只會製作球棒,但我擁有幸運的人生,因為我的客戶是如此地不可思議。」

「球棒不只是一種產品,它更是影響球員能不能有所成就的基礎工具。」

有趣的是,你知道這位木棒職人在2014年以後的退休人生是怎麼過的?71歲的久保田竟然賣起蕎麥麵來了。

根據媒體報導,2009年開始,久保田將無法製成球棒的廢棄木材做成擀麵棍,在擀麵棍上市半年後,有消費者反映粗細不一,這項客訴再次點燃久保田的「職人魂」,前後大概又磨了1,000支擀麵棍,他甚至在試擀過程中學到了手打麵的訣竅與樂趣,於是和友人在滋賀縣合開了一間蕎麥麵店。

「職人魂」上身,持之以恆,就有可能成為「大師」!

更多張尤金在運動視界的文章

本文經運動視界授權刊登,原文發表於此

責任編輯:游家權
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡