LINEヤフーを退職していた
前言
投稿主は台湾出身です。
2024年の12月末が僕のLINEでの最後の出社日で、有休消化は2025年の1月末までだった。**この記事は今の僕の感想と体験を主としており、現状とは異なる部分があるかもしれない。**すべての見解は僕の立場、僕の経験から出たものであり、実際の状況とは異なる可能性がある。
なぜ日本なのか？
僕は別のブログで、日本語を学ぶ動機や、そこまでどう歩んできたかについて書いたことがある。興味があればこちらを参照してほしい。
大学の頃に日本で暮らしたいという思いが芽生えたが、当時は経済状況がよくなく、ワーキングホリデーを支えるだけの貯金がなかったし、成績も交換留学に行けるほど優秀ではなかった。
留年に加えて兵役が必要だったため、僕は簡単には海外に出られなかった。2018年9月に召集令状を受け取ってから、僕は4か月の兵役についた。
当時は日本で働くこと、ましてや日本でソフトウェアエンジニアをすることまでは考えていなかった。Denny が、ワーキングホリデーで日本に来るよりも、正社員として固定の週休2日と使える有休がある仕事を探したほうがいいと僕に言った。そう言われると確かに筋が通っていたので、僕は兵役が終わったら日本の仕事を探すことにした。
また、LINEを選んだ理由はいくつかある。
- 世界各国の開発者と一緒に働ける
- 比較的大きな組織のもとで働くことに挑戦したかった
- 固定の始業・終業時間がない
- 伝統的な日系企業（JTC）の雰囲気がない
日本での面接準備
僕は日本語がとても好きだったので、日本に来る前に「日語八百屋」というニュースレターを運営していた。5、60号ほど書いたが、今はすでに休刊している。この期間にN3とN2も受け、兵役中にN1に合格した。多くの人のように日本に来てから日本語を学び始めたのとは、かなり違う順序だったと感じている。
僕は日本に来る前から数年の開発経験を積んでおり、普段から技術記事も書いていた。当時の条件としては、それが多少なりともLINEの面接にたどり着く切符になったはずだ。およそ2018〜2019年ごろ、LINE福岡は台湾で大々的に採用をしていて、ちょうどDennyがそこで働いていたので、4か月の兵役が終わったあとに彼にリファラルをお願いした。
ここで少し脱線すると、AIの発展はすでにソフトウェア開発の面接ルールを書き換えつつあると思うので、当時の面接経験は今とはまったく合わないかもしれない。この記事は参考程度に読んでほしい。
給与水準について言うと、明記された最低年収は600万日本円だった。当時の為替はまだ0.3だったので、180万台湾ドルということになる。あの時点の条件としてはかなり良かった。また、Backend 関連の職種なら、1000万日本円以上を交渉できる可能性もあった。
なぜ福岡なのか？
僕が初めて九州を知ったのは『坂道のアポロン』というアニメがきっかけだった。その後、2018年に福岡へ2回旅行し、ここの雰囲気がとても好きだと感じた。加えて、LINE福岡は福岡にあった。
さらに詳しい感想は、当時の福岡一年目の振り返りを参照してほしい。
5年後には僕はすでに福岡で家を買っており、より責任を持ってこう言える。福岡は本当に素晴らしい。僕がこれまで会った、昔東京に住んでいた日本人の同僚のほとんどが、福岡を絶賛していた。東京にはより多くの資源、より多くの仕事の機会、より多くの人、より高い物価、より便利な交通がある。これも事実だ。
短い通勤生活
僕が福岡に来たのは2019年7月で、ちょうどパンデミックの前年だった。そのため、最初の半年ほどは地下鉄で通勤してオフィスに通っていた。ここで働く利点のひとつは、始業・終業の固定打刻がないことだ。
2020年2月ごろにパンデミックが起き、会社は無期限のリモートワークを発表したのを覚えている。日本は実質的に2、3年ほど鎖国状態で、観光客を受け入れるようになったのはその後だった。だから、この時期に日本に来られたのは、かなり幸運だったとも言える。
（2021年末に台湾へ戻ったとき、飛行機の中に10人もいなかった景色の写真を載せておく）
僕がLINEでやったこと
ここでは、僕がLINEでやった少し面白いことをいくつかまとめる。もちろん日々の仕事、つまりチケット作成、Bug修正、Feature開発などもたくさん含まれていたが、その中でも特に面白かったものをいくつか挙げる。
LINEの基盤インフラはプライベートクラウドで、Verda と呼ばれている。AWSのようなものだと考えればよく、機能面ではAWSほど豊富ではないが、基本的なコンポーネントはひと通り揃っていて、完全なWebサービスを構築できる。例えば以下のようなものだ。
- Computing
- Load Balancer
- Lambda function
- K8S
- Storage と CDN
- Database
特に気に入っていたサービスが2つあるので、簡単に触れておく。
- Cloudflare Imagesのような解決策: Webやアプリ主体のサービスでは、マルチメディアの操作が避けられない。crop、resize、.webp への変換、blur などが典型だ。これらをアプリケーション側で直接処理すると、規模が大きくなるにつれてボトルネックになりがちだが、LINEはちょうど巨大なプラットフォームだった。このツールは本当に素晴らしく、バックエンドエンジニアの仕事をそのまま減らしてくれた。
- Central Dogma：分散型の設定ファイル解決策だ。設定ファイルを更新したあとにマシンを再起動したり再デプロイしたりしたくない、しかも高可用でありたい、という課題を解決するためのものだ。Central Dogmaのバックエンドではgitのような操作でバージョン管理ができ、その変更をpub/subでサーバーに知らせることもできる。一見素朴だが、非常に使いやすい。
LINEの技術選定についてはこれ以上は多く語らない。大まかにはApacheファミリーのフルコースだ。Kafka、HBase、Cassandra、Airflowなどが、各サービスの特性に応じて使い分けられていた。
Slackbot
最初のプロジェクトでは、デプロイの仕組みがバックエンドの更新タグに基づいていた。当時は社内にPaaSのようなツールもあり、内部GitHubと接続してワンクリックでデプロイできたので、僕はRelease管理用のSlackbotを書いた。Slackから直接デプロイを起動できるようにして、元々のデプロイ手順をSlackの1コマンドまで簡略化した。
当時はまだ Hubot の時代だったが、ある事情で（何だったかは忘れた）Hubotが使えなくなった。そこで僕は、TypeScriptに対応した Slackbot を自分で書いた。SlackのメッセージはJSONの集合で組み立てられるので、jsxのような記法で記述するのは実に直感的だった。この部分は、元同僚の Kai の slack-blockx を参考にした。
要するに、元々はいくつもシステムをまたがっていたreleaseフローを、ひとつのSlackコマンドにまとめたわけだ。
@hubot release beta my-org my-repo main v1.2.0
裏側では、版号の検証、タグ作成、release作成までやってくれる。最後に今回のcommit diffをchangelogとしてチャンネルに貼り返す。もうひとつのポイントは、コマンド自体がプラグイン式の設計になっていることだ。各コマンドはひとつのオブジェクトで、誰が使えるか、どのチャンネルで使えるかまで宣言的なオブジェクトとして切り出し、dispatch前にまとめて弾く。
const deploy: Command = {
name: 'deploy',
command: /deploy (alpha|beta) ([^ ]+) ([^ ]+) ([^ ]+)/,
isAuthedUser: isMember, // 只有 member 能觸發
enableChannels: channelIsValid, // 只在特定頻道生效
action: async (matches, message, client) => { /* ... */ },
};このフレームワークも意図的にモジュール化していて、各コマンドを独立したファイルに分け、大きな関数の中に if else を詰め込まないようにしていた。それに、僕はかなりtestabilityにこだわっていた。Slackbotで最も面倒なのは、テストのたびに本当にSlackへ接続してメッセージを送らなければならず、フィードバックが遅いことだ。だから僕はSlackとの通信部分をひとつのclassにまとめ、コマンドのロジックはSlack SDKに一切触れないようにした。さらにterminal adapterまで作り、ローカルではterminalから直接コマンドを打ってテストできるようにしたので、開発中にSlackを開く必要すらなかった。
今振り返ると少し懐かしい。当時と同じアーキテクチャ、同じコードなら、AIなら1日で片付けられるだろうし、むしろコードでAI Agentを縛るべきではなく、何をしたいのかを直接伝えるべきなのかもしれない。
デプロイ環境の改善
当時、ひとつのサービスで複数の機能が同時に開発されていた。メンバーはプロジェクトごとに分かれていたが、同じcodebaseを共有していたため、同時にQAをすると簡単に衝突してしまった。しかも手元にある環境は固定数しかなかったので、僕と別の同僚で nginx のcookie判定を使い、どのbranchへ流すかを振り分けて対応環境へ誘導した。その頃、僕は一緒に仕事をしていた台湾人同僚から Ansible をかなり学んだ。本当に何度も根気強く手取り足取り教えてくれて感謝している。
ただ、Cookieによる切り替えは手続きが煩雑で直感的でもなかった。後になって別の同僚が大なたを振るい、Envoy と Docker を組み合わせて GitHub と統合し、push すれば deployment が自動更新され、domain も動的に割り当てられるようにした。VercelのようなPaaSではごく自然なことだが、Private Cloudでこれを統合するのは実際かなり難しい。
Landing Page SSR
ある金融サービスでカスタマイズされたLanding Pageを公開する必要があったが、当時の社内ツールはほとんど画像しか置けなかった。日本のサービスには、ページ全体が画像で、スマホ専用のWebページというものが多い。同じプロジェクトの他チームはすでにNext.jsを導入していたが、僕たちはまだ純粋なSPAとNode.jsサーバーのままで、アーキテクチャ上の制約から静的ファイルしか置けず、サーバーとして動かすことができなかった。そこで僕はSSRの導入を進め始めた。
今思えば、Vercelもなく、しかもある程度の規模がある組織でSSRを推進するのは本当に大変だ。まずマシンを確保するだけでもSREにリソースを要請しなければならない。当時の僕はプロジェクトを推進する力がまだ足りず、前の上司（Engineering Manager）が非常に多く助けてくれた。僕はアーキテクチャ図、計画、目的をきちんと文書化してSREとコミュニケーションを取り、ようやく本番環境のマシンを確保できた。開発環境とQA環境は自力で何とかするしかなく、Ansibleを必死に読んで対応した。
あれは僕にとって最も忙しく、そして最も学びの多い1年だった。このSSRの仕組みは後の他機能にも引き継がれた。最初の開発は同じく手間がかかるが、コンポーネントが増えるにつれて節約できる時間も増えていき、企画側がずっと強調していたSEO露出にも、実際に目に見える成果があった。
Sentry 自動化
このプロダクトはFinTechで、しかもリソースが十分にあったので、僕たちは性能調整にかなりの時間をかけていた。ちょうどその頃、SentryがCore Web Vitalsを導入し、バックエンドでWebの性能評価指標を確認できるようになった。そこで僕はSentryのAPIを統合して自動通知機能を作り、毎日その結果をSlackに共有するようにした。
社内ツールのK8S化
僕たちの開発には自動化したいフローが山ほどあった。LINEには標準的な開発フローがあったが、それでもサービスやチームの性質に応じて変化する。たとえば以下のようなものだ。
- 今週のDaily会議の進行役は誰か
- PRがMergedされたらJIRAの状態を自動更新する
- Slackbot
ここで問題になるのは、社内ツールを更新するたびにその開発者に依存しなければならず、本当に改善したいときに手を付けにくいことだ。当時、社内プラットフォームでK8Sクラスタを立てられたので、ある同僚が先陣を切って、社内ツールはすべてK8Sに統合できるプラットフォームを作ってくれた。開発者はcommitするだけでよく、デプロイはすべてCIに任せる形になった。
LINE証券
僕は主に、つみたてNISAのフロントエンドTech Leadと、クレカ投資からNISAへつなぐ部分を担当していた。フロントエンドチームには人員異動があり、日本人2人とフランス人1人が加わった。みな非常に実力のあるメンバーで、僕をかなり助けてくれた。そのフランス人同僚は個性がかなりはっきりしていて、ゲームと日本のアニメが好きで、いつも話題に事欠かなかった。
入ったばかりの頃、チームの大半は僕よりずっと若い新卒だったが、それでも驚くほど実力が高く、オープンソースに積極的に貢献している強者も多かった。毎週、互いに技術交流する時間もあった。
金融サービスなのに、ReactやKotlin（バックエンド）のような新しい技術を積極的に採用していた。みんな本当に技術が好きで、単に金融業界の仕事としてやっているのではないことがよく伝わってきた。
ただ、このサービスは最後まで走り切ることはできなかった。LINE証券の証券業務は2024年8月にまとめて野村證券へ移管され、そこで一区切りとなった。僕が関わったものが終わってしまうのを見るのは、やはり複雑な気持ちだった。
Impression-basedなfeedのランキング機構
LINEの後半ではバックエンドに移る機会があり、feedの表示順を決める仕組みを担当した。ユーザーがfeed内で実際にどのコンテンツを見たかを記録する必要があった。単純に聞こえるが、そのサービスのMAUは数千万人規模だったので、規模が大きくなると、素朴なやり方はどれもバックエンドを圧迫する地雷になる。このfeedはserver-driven UIで、画面はAppに固定で書かれているのではなく、バックエンドがJSON contractを返し、clientがそれに従って描画する。その代償として、各impressionを必ずバックエンドへ戻さなければならなかった。
最も直感的なのは「ユーザーが1件見るごとにAPIを叩く」方法だが、この規模ではimpressionだけでバックエンドが壊れる。そこで僕たちはclient側から直接Kafka eventを送る形に変え、書き込み経路とサービス経路を完全に分離した。重複排除とソートはRedisのSorted Setに任せ、scoreには時刻を使い、24時間のTTLを付けて、期限切れデータは自然に落ちるようにした。残念ながらこの設計は最終的に本番には載らず、僕が退職した時点ではまだテスト段階だった。
ハッカソン
会社ではほぼ毎年ハッカソンが開催されていて、僕も何回か参加した。その中からいくつか紹介する。
二酸化炭素監視
詳しくは、同じプロジェクトにいた当時のオランダ人同僚と一緒にやったこの案件を参照してほしい。
主に二酸化炭素センサーでCO2濃度を測り、ESP32を使ってWi-Fi経由でMQTTに接続し、サーバー側でデータを受け取ってからGrafanaで表示する仕組みだ。
詳しい原理はこの記事を見てほしい。
IoTポモドーロタイマー
まあ……これもIoTだ。SwiftのBLE APIがかなり使いやすいことに気づいたので、物理的なポモドーロタイマーのプロトタイプを作ってみた。Bluetoothで接続し、PCから開始・一時停止を操作でき、統計機能もつけた。自分ではかなり良い機能だと思っているが、いかんせん業務時間は1日半しかなかったので、その先までは進めなかった。
Bluetooth会議表示器
MacOSでは内蔵のカレンダーイベントを監視できることに気づいた。僕がとても気に入って使っている小さなツール MeetingBar は、この考え方に基づいている。（すぐにダウンロードすれば、開発に集中しすぎて会議を忘れることがなくなる）
つまり僕も、そのイベントをBluetoothで配信し、ディスプレイに表示させるアプリを書けるということだ。同じ考え方は無限に広げられる。監視したいものを配信できさえすればいい。
主管A と主管B
ここでは、僕の成長に大きく役立ってくれた2人の上司について少し書きたい。
LINEで出会った主管Aは日本人で、フロントエンド部門全体の責任者だった。とてもコミュニケーションがうまく、チームを率いるのが上手で、いろいろなタイプの開発者とうまく付き合える人だと思う。本人はいつも「技術ではみんなに及ばない」と謙虚に言っていたが、実際には常にさまざまな技術動向を把握していて、皆の開発進捗もきちんと見ていた。
もう少し深く話してみると、主管はもうほとんど心配事がない人だと分かった😂。すでに2児の父で、妻はカフェを経営していて、貯金は底なし、仕事は友達を作るために来ているようなものだ。
主管Aは僕のキャリア成長にとても大きく関わってくれた。お互いにTwitterをフォローし合っていて、主管も僕の近況をさりげなく気にかけてくれた。同僚にSNSアカウントを教えるべきかどうかは人それぞれだが、僕は気が合うなら聞くようにしている。同じ会社で一緒に働けるのも縁だからだ。
入社当初、この環境は僕のこれまでの仕事経験とかなり違っていた。僕はチームの中で技術的な細部をかなり気にする方だったが、当時の僕は表現の仕方が下手で、同僚の提案にいちいちケチをつけてしまい、かなり強引で協力しづらい人だと思われていた。
その後、同僚から非常に重いネガティブ評価を受けた。僕の振る舞いがチームの士気に深刻な悪影響を与えるという内容で、彼は僕の行動を見て pissed off だとまで書いた。主管Aも、職場では影響力を発揮することのほうが重要であり、僕のやり方はプロジェクトを前に進めるどころか、むしろ妨げになっていると、かなり真剣に指摘してくれた。
最初にその意見を聞いたとき、僕はまったく納得できなかった。なぜみんなはコード品質をそんなに重視しないのか、なぜ僕がネガティブ評価を受けるのか、とよく思っていた。
その後、主管Aが一歩ずつ僕を導いてくれたおかげで、今の僕がある。主管A自身もかなり本を読む人で、『人を動かす』、中国語では『卡内基溝通與人際關係』と訳される本を勧めてくれた。僕の意識が変わったのは、この本のおかげだと言っていい。技術以外のことを初めて認識したのがその時だった。それ以来、在職中は技術書だけでなく、マネジメント関連の本もたくさん読んだ。
もう一人の主管BはEngineering Managerで、同じプロジェクトの上司だった。この主管Bもチームビルディングがとても上手な人で、短い一年間の協働だったが、プロジェクト上で往復の多いコミュニケーションや調整、さらには他部署からリソースを取りに行くような事柄まで、彼がかなり助けてくれた。
僕は主管Bとも仲がよかった。以前の文章を日本語に翻訳していると話したら、彼は即座に原稿を見て修正してくれた。さらに、プロジェクトの問題を解決したあとには、主管Bが僕に禰豆子のフィギュアまで買ってくれた。
僕自身は、賞品で人を励ますやり方はあまり好きではない。とはいえ、個人のモチベーションを効果的に高める方法ではあるのだろう。
その後、たまに主管Bと彼の娘さんと一緒にスプラトゥーン2を遊ぶようになったし、僕が机を買い替えたいと言ったときには、車でホームセンターまで木材を買いに連れて行ってくれた。
その後、プロジェクトの変化があって、主管同士の違いがあそこまで大きいのだと初めて分かった。
今思うと、僕のキャリアで出会った主管の多くは本当に優秀で、僕に大きな成長と刺激を与えてくれた。職場で出会った主管たちには、本当に感謝している。
いくつか楽しかったこと
Happy Friday
当時は毎月最終金曜日に Happy Friday があり、会社が軽いお菓子と飲み物を用意して、みんなでCafe Spaceに集まって雑談できた。パンデミックが始まってからは開催されなくなったが、僕にとってとても懐かしい時間だ。
毎週1回、午後に全体会議があり、注意事項を共有したあと、残りの時間は通常こう使われていた。
- 新しく入った同僚の自己紹介
- 技術Talkの発表募集。テーマは自由
他のプロジェクトで起きていた問題や、その解決策を聞けるし、同僚と交流する機会にもなった。さらに金曜日にはフロントエンドチームの共有会もあった。
韓国出張
2019年末に会社は UIT Global Workshop を開催し、日本、タイ、台湾、韓国などからフロントエンドエンジニアを集めて、韓国のNAVERにある Connect One でイベントを行った。
Connect One は韓国の春川市にあり、NAVERが社員向けに特別に作った研修センターだ。さまざまなオフィススペース、会議室、大講堂があり、寮までかなり豪華だった。
イベントの主な議題は、実際に製品開発へ適用した技術事例の共有だった。残りの時間は主に食事と交流で、各国のエンジニアと知り合う場になっていた。
LINE Developer Day 2019
続いて別のカンファレンスがあり、会社の費用で東京へ出張して LINE Developer Day 2019 に参加した。当時の参加記録はこの2本に書いてある。感想（上）、感想（中）：Slack が Armeria で search サービスを再構築。
このカンファレンスで僕が最も得たものは次の2つだ。
- LINEにはオープンソースのマイクロサービスフレームワーク Armeria があり、しかもSlackでも使われていること
- BERTの実世界での応用
なぜ退職したのか
退職理由はひとつの出来事ではなく、いくつもの線が少しずつ収束して同じ結論になった、という感じだ。
最も根本的なのは、大企業で働くと枠組みの外に出るのが難しいということだ。上に行ける可能性は確かにあるが、当時の僕は認識が足りず、ゲームのルールをまだ十分に理解していなかった。同時に、自分のキャリアはすでに停滞とボトルネックにぶつかっていると感じていた。さらに、続けて関わった2つのサービスが終了し、結果だけ見れば実績がないのと同じだった。
上司も理由のひとつだった。その後に出会った上司たちはみなNPCのようで、僕の問題に対する助言はたいてい一般論にとどまり、チームを本当に気にかけているとも思えなかった。1on1も、日々の業務をこなすためのものに近かった。この点はバックエンドに移ってからさらに明確になり、僕はそのうちのひとりの上司とたびたび意見の相違や摩擦を起こした。
最後のプロジェクトに回されたとき、その製品の性質自体が比較的業務寄りで、数週間かけてようやく小さな機能ひとつを作るような感覚がよくあった。この期間で面白かったのはバックエンド開発に参加できたことだ。Backendに移ってから、大規模トラフィックで気をつけるべきことをたくさん学び、推薦システムの設計も担当した。ただ残念ながら、それはまだテスト段階で本番には上がらないまま、僕は退職した。そしてこの最後のプロジェクトは、広告impressionを増やすことを目的にする場面が多く、やればやるほど僕は迷いを深めていった。
さらに僕が気になっていたのは、昇進Drivenの下にあるあのロジックだ。
僕は価値のないことが、さもimpactがあるように包装されている場面をたくさん見た。たとえば社内で標準規約の統一が進められ、みんなで使える設定ファイルのRepositoryが作られたことがあったが、流行が過ぎるとそのまま放置された。その設定ファイルは長年メンテナンスされず、各プロジェクトにうまく適用できなかったので、結局は各プロジェクトで個別に設定することになった。
ただ、後になって僕は腑に落ちた。たとえ何かに価値がなかったとしても、なぜ価値がないのかをきちんと説明できる力が必要なのだ。そして、多くのものは包装次第で60点から100点になる。つまり、もし自分があるものを100点だと思うなら、見せ方を200点にしないと見てもらえないということでもある。
組織が大きくなると、多くの指標はそもそも数値化できない。上司は数字と資料を見るしかない。そして代理指標が目標になった瞬間、それはもはや良い代理指標ではない。もちろん、決められたゲームルールの中でゲームをうまく遊べなかったのは完全に僕自身の問題だ。僕はルールそのものを変えることもできず、与えられたルールの中で成果も出せなかった。
最後の引き金はAIだった。2024年はちょうどLLMが百花繚乱の年で、大企業ではAIを導入しようとすると、どうしてもコンプライアンス、安全性、データ保管といった問題に向き合わざるを得ず、state-of-the-artのモデルをそんなに簡単には使えなかった。
僕はAIがここ数年の潮流になると考えているし、ソフトウェア開発も大きく変わるだろうと思っている。だから、もっと自由なやり方で探求したいと思った。ずいぶん悩んだ末、それでも退職する決意をした。未知のものに向き合う必要があったので、僕にとっては非常に難しい決断だったが、今振り返ると、この決断をしてよかったと思っている。
後悔していること
僕の人間関係は育った環境の影響を強く受けている。僕は自分から人に近づくのが得意ではなく、社交も苦手で、むしろ一人でいるほうが好きだ。
その結果、協働していたチーム以外の人脈を積極的に広げられなかった。非エンジニア部門であれ、別プロジェクトの開発者であれ、その重要性を以前の僕は理解していなかった。
パンデミック後にオフィスがリモート前提になり、こちらから交わりを作る機会はなかなか生まれなかった。それは僕にとって残念だった。退職時にひとりで去ることになり、設備をすべて返却したときのあの空虚感は、やはりかなりつらかった。
細かい話はいくらでもあるが、ここではいくつかだけ挙げておく。
- ある同僚はオーストラリアから来ていたのだが、本人も最初にそう言っていたのに、僕はイギリス出身だと勘違いしていた
- ある同僚はフランス人だったので、「それなら箸は使えるの？」と聞いてしまった。後で思い返すとかなり失礼だったと思う。僕が「彼はアジア人ではないのだから、当然箸は使えないはずだ」と勝手に決めつけていたからだ
特に心に残っている別の出来事がある。以前、同僚同士で衝突が起きたとき、僕は沈黙を選んだ。僕としては事件自体はそこまで重大ではないと思っていたが、その考えは当事者に伝わらなかった。
後になって考えると、彼が向き合っていた感情的なプレッシャーは相当大きかったのだろう。僕自身も、不快な場面に対してはいつもそうだ。しかし、さらに上を目指すなら、不快な対話を避けることはできない。むしろ、多くの場合、向き合うことになるのは不快な対話そのものだ。この件はずいぶん前のことだが、ずっと僕の心に残っている。
その後、最も長く一緒に仕事をした同僚たちと食事に行った。彼らには本当に感謝している。
学んだこと
僕は会社で、確かに前例のない成長機会を得た。大規模トラフィックに対して適切なアーキテクチャをどう設計するか、ゼロからサーバーを構築すること、各国の開発者と交流すること、他部署のチームとコミュニケーションすること、チームを率いていくつもの機能を完成させること。これらはどれも得難い経験だったし、あれだけのトラフィックと規模があって初めて、以前ならまったく考えもしなかったことを目にできるのだ。
- 技術は武器だが、すべてではない。特にプロジェクトの過程では、LINEでは多くのフローが標準化されていた。しかしそれは、上司や上層部が裏で調整してくれた結果にすぎず、自分の手柄ではない可能性が高い。
- 影響力を発揮したいなら、人に関わる多くのことに向き合わなければならない。僕はLINEで、フロー、ドキュメント、ソフトウェア開発のやり方をたくさん学んだが、「人」についてはまだまだ学ぶことが多い。
あとがき
以前は日本で働く話をすると、日本の給料は高くない、税金が多い、日系企業の文化がどうだ、といった反対意見がよく出た。どの会社にも不完全なところはあり、LINEにも当然あった。それでも僕は、みんなに機会があれば、こういう規模の会社で働いてみることを勧めたい。
僕は日本がとても好きだ。もちろん台湾自体も、快適に暮らせる場所だ。仕事環境だけを見れば、日本はまだ多くの人に軽く見られていて、シリコンバレーのほうが良い選択だと思われるかもしれない。この点は僕も同意する。だけど僕は日本にいたいのだ。
欧米やインド出身の同僚と何度も話したことがある。スターバックスにノートPCを置いたままトイレに行っても戻ってきたら盗まれていないこと、あるいはスマホをぶら下げたまま道を歩いても奪われないことは、欧米ではなかなか起こらない。先進国の中で、日本は高い社会秩序と比較的安い物価を保っている。
親切でいること、自分にできる範囲で人を助けること。ありきたりに聞こえるが、僕は技術をゲートキーピングの手段にして、どんどん傲慢になっていく人をたくさん見てきた。技術の敷居は遅かれ早かれAIによって平準化される。そのとき最後まで残るのは、手を差し出せる人であって、一番大きな顔をしている人ではない。
だから僕は、基礎がしっかりしたエンジニアのほうが好きでもある。この文章では彼について触れなかったので、ここで補足しておく。彼について特に印象に残っていることが3つある。
1つ目は、前述の二酸化炭素監視ハッカソンでのことだ。僕はCO2センサーを1つ買ったが、ArduinoのSDKが付いていて、そのまま使おうと思っていた。ところが彼は、せっかくのハッカソンなのだから何かを学ぶべきで、既製のライブラリだけを使うなら普段のAPI呼び出しと変わらないではないか、と言った。僕はもっともだと思い、一緒にそのセンサーのdatasheetを読み、protocolに従って通信をゼロから実装した。
2つ目は、彼がmultipart/form-data のテストを書いていて詰まり、どうやってフォームリクエストを模擬するのか僕に聞いてきたことだ。彼はフォームが少し特殊なHTTPリクエストだということは知っていたが、libraryをいくら触っても組み立てられなかった。僕が見てみると、form boundary の設定が間違っていただけで、そこを直したら通った。
3つ目は、お互いに好きなYouTubeチャンネルの話をしたとき、彼が Ben Eater を勧めてくれたことだ。コンピュータの仕組みを掘り下げるのが好きな人にとっては、まさに宝の山だ。ネットワークがどう動くかを説明するために、彼は伝送線上の信号から始めて（オシロスコープも使いながら）、application layer まで話してくれる。さらに、ブレッドボードだけでゼロからシンプルな8-bit CPUを作ったこともある。
AIが進化し続ける時代にあって、こういう能力はますます珍しくなっていると感じる。しかし、どんな時代であっても、これはかけがえのない特質だと思う。
最後に、日本での暮らしの写真をいくつか載せて締めくくる。この文章が読者に少しでも何かを残せたらうれしい。福岡に遊びに来ることがあれば、ぜひ僕とコーヒーでも飲もう。
関連記事
- 籠と槍 これは、僕が子どものころにとても好きだった本の一つ――『五つの修練』の物語だ。子どものころはもちろん、組織だのチームだのなんてまったく分からなかった。ただ中の物語が好きだっただけだ。まさか大人になってから、この『五つの修練』の物語の内容がチームを中心にしたものだと気づくとは思わなかった。
- 15. 感謝に満ちた人生 幼い頃の家は裕福ではなく、生活も順調ではなかった。経済的な支援がない中では、選べる道はとても狭くなる。しかしそんな環境の中でも、僕はそれでも…
- 14. 1000人の熱心なファン（1000 True Fans） これはクリエイター（アーティスト、作家、音楽家、創作者など）向けの経営戦略だ。クリエイターは世界的なスーパースターになったり、何百万人ものフォロワーを抱えたりする必要はなく、自分を熱心に支えてくれる人たちの集まりさえあれば、安定して生活を支え、創作を続けられるという考えである。
- 13. 不確実性を受け入れる 『ブラック・スワン』の著者ナシームはかつて、いかにも起こりえなさそうなことが、予想もしない時に起こり、その大半は予測できないにもかかわらず甚大な衝撃をもたらす、という概念を提起した。2020年のCOVID-19はその最たる例であり、感染拡大の影響で人々の生活や働き方は完全に変わり、踏ん張れずに閉店・倒産する店も少なくなかった。状況が好転し始めたのは2023年になってからだ。