LINE Fukuoka（現 LY Corporation）で5年間働いた感想
はじめに
2024年の12月末が僕のLINEでの最終出社日であり、有給消化を経て2025年1月末での退職となった。本記事はあくまで僕自身の現在の実感や体験に基づくものであり、僕の立場や経歴から見た視点で書かれているため、現況とは異なる可能性がある。
なぜ日本だったのか？
僕が日本語を学び始めた動機や、これまでの歩みについては別のブログで触れたことがあるので、興味があれば参照してほしい：
大学時代に日本で暮らしてみたいという思いが芽生えたものの、当時は経済的に余裕がなく、ワーキングホリデーの費用を賄えるほどの貯金もなければ、交換留学に行けるほど学業成績が優秀だったわけでもなかった。
大学の留年に加え、兵役の義務もあったため、気軽に海外へ出ることはできなかった。2018年9月に召集令状を受け取り、4ヶ月間の兵役に従事することになった。
当時は日本で働くこと、ましてや日本でソフトウェアエンジニアになることなど考えてもいなかった。そんな時、Dennyから「ワーホリで日本に行くくらいなら、正社員の仕事を探したほうがいい。完全週休2日で有休も使えるぞ」と言われた。確かにその通りだと思い、僕は兵役を終えたら日本での職探しを始めようと決意した。
また、LINEを選んだのにはいくつか理由がある：
- 世界各国の開発者と一緒に仕事ができる
- 規模の大きな組織で働くことに挑戦したかった
- 固定の就業時間（コアタイム）がない
- 伝統的な日本企業（JTC）の雰囲気がない
日本での面接の準備
日本語が好きだったこともあり、日本に来る前、僕は「日語八百屋」というニュースレターを運営していた。だいたい50〜60号ほど配信しただろうか（現在は休刊している）。その期間中にN3とN2を受験し、兵役中にN1にも合格した。日本に来てから日本語を学び始める人が多いのと比べると、この順序は少し珍しい体験だったかもしれない。
日本に来る前にすでに数年の開発経験を積んでおり、普段から技術記事も執筆していた。当時の状況からすれば、これが多少なりともLINEの面接への切符を手に入れる助けになったと思う。2018〜2019年頃、LINE Fukuokaは台湾で大規模な採用を行っており、ちょうどDennyが社内にいたため、兵役を終えた後に彼にリファラル（社内推薦）をお願いした。
今やAIがソフトウェア開発の面接ルールを書き換えつつあり、当時の面接体験は現在とは大きくかけ離れている部分が多い。以下は当時の時代背景として読んでもらえれば幸いだ。
給与水準に関しては、提示された最低年俸は600万円だった（当時の為替レートはまだ1元＝0.3円台だったので、台湾元にして180万元相当！）。当時の条件としてはかなり魅力的だった。また、Backend関連のポジションであれば、1000万円以上で交渉できるチャンスもあった。
なぜ福岡だったのか？
僕が九州を初めて知ったきっかけは『坂道のアポロン』というアニメだった。その後、2018年に福岡を2度旅行で訪れ、街の雰囲気がとても気に入った。そして何より、LINE Fukuokaが福岡にあったからだ。
より詳しい所感については、福岡に来て1年が経った頃に書いた記事を参考にしてほしい。
あれから5年が経ち、僕はすでに福岡で家を購入した。今ならより責任を持って言えるが、福岡は本当に素晴らしい街だ。僕が出会った、かつて東京に住んでいた日本人同僚のほぼ全員が、福岡を絶賛している。
つかの間の通勤生活
僕が福岡に来たのは2019年7月で、ちょうどパンデミックが勃発する1年前だった。そのため、最初の半年ほどは地下鉄でオフィスへ通勤していた。ここで働くメリットの一つは、決まった出退勤の打刻がないことだった。
2020年2月頃に感染が拡大し、会社が無期限のリモートワークを発表したのを今でも覚えている。日本はその後、実質的な鎖国状態が2〜3年続き、ようやく観光客の受け入れを再開した。
（2021年末に台湾へ一時帰国した際、機内に10人も乗っていなかった風景を載せておく）
コロナ禍の期間
日本が2020年に水際対策を発表してから2023年4月に解除されるまでの間、まるで時間が圧縮されていたかのように感じる。今振り返ると、仕事をして、退勤して、オンライン飲み会をして、たまに散歩に出かけるだけの日常だったが、この期間があったからこそ、他の分野を探求する時間ができた。エレキギターを習ったり、IoTで遊んだり、YouTubeチャンネルを始めたり（とっくに放置してしまっているが）、ゲームに熱中したりもした。
また、コロナ禍の影響もあって、高度人材ビザも永住権の申請も、非常に短期間で取得することができた。
僕がLINEでやったこと
ここで、僕自身がLINEで手掛けた比較的興味深い仕事についてまとめておきたい。もちろん、日常的な業務（チケット消化、バグ修正、機能開発など）も数多く含まれるが、その中から面白かったものをいくつかピックアップして紹介する。
LINEのインフラ基盤には、Verdaと呼ばれるプライベートクラウドが使われている。AWSのようなものと想像してもらえばいい。機能面ではAWSほど豊富ではないが、基本的にはWebサービスを一通り構築するのに十分なコンポーネントが揃っている。例えば：
- Computing
- Load Balancer
- Lambda function
- K8S
- Storage と CDN
- Database
僕が特に気に入っていたサービスが2つあるので、簡単に紹介したい：
- Cloudflare Imagesに似たソリューション：Webやアプリを中心としたサービスではマルチメディアの操作が不可欠だ。クロップ、リサイズ、.webpへの変換、ブラー加工などが一般的だが、これらをアプリケーション側で直接処理すると、規模が大きくなった途端にボトルネックにぶつかりやすい。LINEはまさにその大規模プラットフォームだった。このツールは本当に素晴らしく、バックエンドエンジニアの手間を直接省いてくれた。
- Central Dogma：分散型の設定ファイル管理ソリューションだ。設定の更新時にマシンの再起動や再デプロイを行わずに済むようにすること、そして高可用性を実現することを主眼に置いている。Central Dogmaの管理画面にはGitに似た操作体系があり、バージョン管理が可能で、変更をPub/Sub方式でサーバーに通知することもできる。一見素朴だが、非常に重宝した。
LINEにおける細かな技術選定についてはここでは深く触れないが、大まかにはいわゆるApacheファミリーのフルコースだ。Kafka、HBase、Cassandra、Airflowなど、各サービスの特性に合わせて異なる技術選定がなされていた。
Slackbot
僕が携わった最初のプロジェクトでは、バックエンドでタグを更新してデプロイする仕組みをとっていた。当時社内にはPaaSに似たツールが提供されており、社内GitHubと連携してワンクリックでデプロイできた。そこで僕はリリース管理用のSlackbotを作成し、Slackから直接デプロイをトリガーできるようにした。これにより、従来の複数のデプロイ手順をSlackのコマンド一発に集約した。
当時はまだHubotの全盛期だったが、とある事情（具体的に何だったかは忘れてしまった）でHubotが使えなかったため、TypeScriptに対応した独自のSlackbotを自作した。Slackのメッセージ構築は一連のJSONなので、JSXに似た構文で記述すると非常に直感的になる。この部分は元同僚のKaiが作ったslack-blockxを参考にした。
基本的にこのBotがやっていることは、複数のシステムを行き来していた従来のリリースフローを、Slackのコマンド1行に集約することだ：
@hubot release beta my-org my-repo main v1.2.0
内部的にはバージョンの検証、タグの作成、リリースの作成を自動で行い、最終的に今回のコミット差分をチェンジログとしてチャンネルに投稿してくれる。また、コマンド自体もプラグイン形式で設計されており、各コマンドが一つのオブジェクトになっている。「誰が使えるか、どのチャンネルで使えるか」まで宣言的なオブジェクトとして定義し、ディスパッチの前に一括で弾く仕組みにした：
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との通信部分をクラスの1層に集約し、コマンドのロジックがSlack SDKに一切触れないようにした。さらにはターミナル用のアダプターを作り、ローカルのターミナルから直接コマンドを叩いてテストできるようにしたため、開発中にSlackを開く必要すらなくなった。
今振り返ると実に懐かしい。同じアーキテクチャやコードなら、AIに任せればおそらく1日もかからず完成してしまうだろう。今となってはコードでAIエージェントを制約するのではなく、何をすべきかを直接指示する時代かもしれない。
デプロイ環境の改善
当時、僕たちのサービスでは複数の機能が同時に開発されており、メンバーはプロジェクトごとに割り振られていた。しかし同じコードベースを共有していたため、同じタイミングでのQAテストでコンフリクトが頻繁に起きていた。手元にある検証環境の数も限られていたため、僕ともう一人の同僚でnginxのCookieを使ってどのブランチにルーティングすべきかを判定し、対応する環境へ振り分ける仕組みを作った。その時期、一緒に作業していた台湾人の同僚からAnsibleをたくさん学んだ。根気強く手取り足取り教えてくれた彼にはとても感謝している。
とはいえ、Cookieの切り替えは手間がかかり直感的ではなかった。その後、別の同僚が大胆なメスを入れ、EnvoyとDockerを組み合わせてGitHubと連携させ、pushするだけでデプロイが自動更新され、ドメインも動的に割り当てられる仕組みを構築した。VercelのようなPaaSなら当たり前の機能だが、プライベートクラウドの中でこれを統合するのは決して簡単なことではない。
ランディングページのSSR
ある金融サービスでカスタマイズ可能なランディングページをローンチすることになったが、当時の社内ツールはほぼ画像しか配置できない仕様だった（日本のサービスには、スマートフォン専用の1枚画像のようなWebページが多々ある）。同じプロジェクト内の他チームはすでにNext.jsを導入していたが、僕たちのチームは純粋なSPAにNode.jsサーバーという構成で、アーキテクチャ上の制約から静的ファイルをホスティングするだけでサーバーとして実行することができず、そこで僕はSSRの導入を推進し始めた。
今考えると、Vercelもなく、ある程度の規模を持つ組織の中でSSRを推進するのは並大抵のことではなかった。マシンを確保するだけでもSREと交渉してリソースをもらう必要があった。当時の僕にはまだプロジェクトを推進する力が不足していたが、当時の上司（エンジニアリングマネージャー）が非常に大きな助け舟を出してくれた。アーキテクチャ図や計画、目的を明確に書き起こしてSREと交渉し、ようやく本番環境のマシンを確保できた。開発環境やQA環境については、Ansibleを必死に独学しながら自力でなんとか構築した。
あれは僕にとって最も忙しく、そして最も多くのことを学んだ1年だった。このSSRの仕組みは後に他の機能にも流用された。開発当初は同じように手間がかかったが、コンポーネントが増えるにつれて節約できる時間も増えていき、企画サイドが重視していたSEOの露出効果に対しても確かな成果をもたらした。
Sentryの自動化
このプロダクトはFinTech領域であり、リソースが潤沢だったこともあって、パフォーマンスチューニングには多くの時間を費やした。ちょうどその頃SentryがCore Web Vitalsに対応し、ダッシュボード上で現在のWebページの各パフォーマンス評価指標が確認できるようになった。そこで僕はSentryのAPIを統合して自動通知機能を作成し、毎日の結果をSlackに共有するようにした。
社内ツールのK8S化
開発の中には自動化したい細かなプロセスが無数に存在する。LINEには標準的な開発プロセスが存在するものの、サービスやチームの性質によって変化する。例えば：
- 今週のDailyミーティングのファシリテーターは誰か
- PRがマージされた後、JIRAのステータスを自動更新する
- Slackbot
ここで生じる問題は、社内ツールをデプロイするたびにその開発者個人に依存してしまい、他人が改善を手助けしようにも手を出しにくいという点だった。当時、社内プラットフォーム上でK8Sクラスタをプロビジョニングできるようになったため、ある同僚が率先してみんなのために基盤を作り、社内ツールであれば何でもK8Sに統合できるようにしてくれた。開発者はcommitするだけで、デプロイはすべてCIが面倒を見てくれるようになった。
LINE証券
僕は主につみたてNISAのフロントエンドTech Leadと、クレカ積立（クレジットカード投資）とNISAの連携部分を担当した。フロントエンドチームで人員の異動があり、日本人2名とフランス人1名が加わった。いずれも実力派のメンバーで、僕を大いに助けてくれた。そのフランス人の同僚は非常に個性豊かで、ゲームと日本のアニメが大好きで、いつも話題が尽きなかった。
チームに加わった当初、メンバーの多くは僕よりずっと若い新卒ばかりだったが、その実力は驚くほど高く、オープンソースに貢献している猛者も大勢いた。毎週定期的に技術的な意見交換会も行われていた。
金融サービスであるにもかかわらず、ReactやKotlin（バックエンド）といった新しい技術を積極的に採用していた。単に金融業界の仕事としてこなしているのではなく、みんなが本当に技術を愛していることが伝わってきた。
例えば、ReactがRecoilをリリースしたばかりの頃、チームはすぐにプロジェクトへの導入を決めた。先進的すぎないかと懸念する声もあったが、最終的には導入に踏み切った。同じやり方を他のチームで取ろうとしても、全く違った結果になっていたと思う。
また、バックエンドのAPIがまだ用意されていない段階でもフロントエンドが繋ぎ込みを進められるよう、mswのようなモックを容易にするライブラリを導入したり、UIの安定性を高めるためにプロジェクトの初期段階からCypressを導入してE2EテストをCIに統合したりしていた。
ただ、このサービスは最後まで生き残ることはできなかった。LINE証券の証券業務は2024年8月に野村證券へ一括移管され、事実上の幕引きとなった。自分が関わったプロダクトがクローズされるのを見るのは、やはり複雑な気持ちになるものだ。
Impression based なフィードの並び替え機構
LINE在籍の後期、僕はバックエンドへ異動する機会を得て、フィードの露出・並び替え機構を担当した。ユーザーがフィード内で実際にどのコンテンツを目にしたのかを記録する仕組みだ。一見シンプルに聞こえるが、そのサービスのMAUは数千万人規模にのぼる。トラフィックの規模が跳ね上がると、どんな安易な実装もバックエンドを圧迫する地雷へと変わる。このフィードはServer-Driven UIを採用しており、画面のレイアウトはアプリ内にハードコードされているのではなく、バックエンドが吐き出すJSONコントラクトに従ってクライアントが描画する設計だった。その代償として、露出（インプレッション）が発生するたびにバックエンドへデータをフィードバックする必要があった。
最も直感的なアプローチは「ユーザーが1件見るたびにAPIを叩く」ことだが、このトラフィック規模では、露出のトラフィックだけでバックエンドが容易にパンクしてしまう。
そこで僕たちはクライアントから直接Kafkaイベントを発行する方式に改め、書き込み経路とサービス提供経路を完全に分離した。重複排除と並び替えはRedisのSorted Setに委ね、スコアには時間の新旧を用い、24時間のTTLを設定して期限切れのデータが自然に消去されるようにした。
ただ残念なことに、この設計が日の目を見ることはなかった——僕が退職した時点では、まだ検証段階のままだった。
ハッカソン
社内ではほぼ毎年ハッカソンが開催されており、僕も何度か参加した。そのうちのいくつかを紹介したい。
二酸化炭素（CO2）濃度のモニタリング
詳細は以下の記事を参照してほしい。当時同じプロジェクトにいたオランダ人の同僚と一緒に制作したプロジェクトだ。
主にCO2センサーを使って室内のCO2濃度を計測し、ESP32からWi-Fi経由でMQTTにデータを送信、サーバー側でそれを受け取ってGrafanaと連携して可視化するというものだ。
詳細な仕組みはこちらの記事にまとめている：
ついでに、一緒にこのプロジェクトをやったオランダ人の同僚の話をしておきたい。
僕が購入したこのセンサーには、そのまま使えるArduinoのSDKが用意されていた。僕は当初、それを使って手早く作ろうと考えていた。しかし彼は、「せっかくのハッカソンなんだから何か新しいことを学ばなきゃ。出来合いのパッケージを全部使うなら、普段やってること（APIを叩くこと）と変わらないじゃないか」と言った。もっともな意見だと思い、僕たちはセンサーのデータシートをめくりながら、プロトコルに従って通信処理をゼロから実装した。
もう一つの出来事は、彼がフォーム送信（multipart/form-data）のテストコードを書く際に手が止まり、どうやってフォームリクエストをモックすればいいかと僕に聞きに来た時のことだ。彼はフォームが少し特殊なHTTPリクエストに過ぎないことは理解していたが、ライブラリを使ってあれこれ試してもうまく組み立てられずにいた。僕が見てみるとform boundaryが正しく設定されていないことが判明し、修正したらすぐに動いた。
3つ目は、お互いのお気に入りのYouTubeチャンネルについて話した時のことだ。彼は僕にBen Eaterを勧めてくれた。コンピューターの原理を深く掘り下げるのが好きな人にとって、あのチャンネルはまさに宝の山だ。ネットワークの仕組みを説明するために、彼は伝送線路上の電気信号（オシロスコープまで持ち出して）から語り始め、アプリケーション層に至るまで解説し尽くす。ブレッドボードを使ってゼロからシンプルな8ビットCPUを作り上げたことさえある。
AIが進化し続ける現代において、こうした泥臭い探求力を持つ人はますます少なくなっていると感じる。しかし、どんな時代であっても、それはかけがえのない価値ある資質だと思う。
IoTポモドーロタイマー
これも……IoTだ。SwiftのBLE APIが意外と扱いやすいことに気づき、物理的なポモドーロタイマーのプロトタイプを作ってみた。BluetoothでPCと接続し、PC側から開始や一時停止を操作して、ついでに統計も取るというものだ。個人的には素晴らしい機能だと思ったが（自画自賛だが）、ハッカソンの開発期間は1日半しかなかったため、それ以上作り込むことはしなかった。
Bluetooth 会議ディスプレイ
macOSでは、標準のカレンダーイベントを監視できることに気づいた。僕がお気に入りで使っているツールの一つであるMeetingBarもまさにこのコンセプトだ（ぜひインストールしてみてほしい。開発に没頭して会議をすっぽかすことがなくなる）。
つまり、専用のアプリを書いてそのイベントをBluetooth経由で配信し、ディスプレイ側に表示させることも可能だということだ。同じコンセプトはいくらでも拡張可能で、監視したい情報を外へ配信する術さえあれば何でもできる。
上司Aと上司B
ここで少し紙幅を割いて、僕の成長に大きく貢献してくれた2人の上司について触れておきたい。
LINEで最初に出会った上司Aは日本人で、フロントエンド部門全体のマネージャーだった。彼はコミュニケーションとチームの牽引が非常に巧みで、タイプが異なる様々な開発者との付き合い方を心得ていた。「技術面ではみんなに敵わない」と謙遜することが多かったが、実際にはあらゆる技術のトレンドを常に把握しており、メンバー全員の開発の進捗もしっかりと見守っていた。
深く話してみると、その上司はすでに人生における心配事がほとんどない状態だった😂。すでに2人の子どもの父親で、奥さんはカフェを経営しており、貯金は底が見えないほどあり、仕事はもはや「友達を作りに来ている」ようなものだった。
上司Aは僕のキャリアの成長を大いに助けてくれた。お互いのTwitterをフォローし合っており、上司も僕の近況を（控えめなやり方で）気にかけてくれていた。同僚にSNSのアカウントを教えるべきかどうかは人それぞれだが、僕自身の判断としては、ある程度仲良くなれたら聞くようにしている。同じ会社で一緒に働くのも何かの縁だからだ。
入社した当初、ここの環境は僕の過去の勤務経験とは大きく異なっていた。僕はチーム内でも比較的技術的な細部にこだわる方だったが、当時の僕の伝え方は決して上手とは言えず、同僚の提案にあれこれケチをつけてしまい、非常に高圧的で協調性に欠けると受け取られることが多かった。
その後、同僚から非常に厳しいネガティブフィードバックを受けた。僕のそうした態度はチームの士気を著しく下げるという指摘で、僕の振る舞いによって「pissed off（激怒した）」とストレートに書かれていた。上司Aからも厳重に注意された。「職場でより重要なのは影響力を発揮することだ。君のやり方はプロジェクトの前進にとって無益であるばかりか、むしろ進行を阻害している」と。
最初のうちはその意見を素直に受け入れられず、「なぜみんなコードの品質にそれほど頓着しないのか」と不満に思い、ネガティブ評価に納得がいかなかった。
しかし、上司Aが辛抱強く導いてくれたおかげで、今の僕がある。上司A自身もかなりの読書家で、僕に『人を動かす』（カーネギー著）を読むよう勧めてくれた。当時の僕のマインドセットが変わったのは、まさにこの本のおかげだったと言っていい。技術以外の領域に初めて意識が向いた瞬間だった。その一件以来、僕は在籍中に技術書だけでなく、マネジメントに関する本もたくさん読むようになった。
もう一人の上司Bはエンジニアリングマネージャーで、同じプロジェクト内のマネージャーだった。この上司Bもチームビルディングに非常に長けた人物だった。一緒に仕事をしたのはわずか1年ほどだったが、上司Bがいてくれたからこそ、プロジェクトで発生する調整やコミュニケーション、さらには他部署へのリソース要請といった泥臭いタスクを一手に引き受けてくれた。
上司Bとはとても親密な関係だった。僕が過去の記事を日本語に翻訳していると話したら、二つ返事で校正を手伝ってくれた。また、プロジェクトの課題を解決した際には、上司Bがわざわざ禰豆子のフィギュアを買ってプレゼントしてくれたことすらあった。
その後も、たまに上司Bやその娘さんと一緒にスプラトゥーン2で遊んだり、僕がデスクを買い替えたいと言った時には車を出してホームセンターまで木材を買いに連れて行ってくれたりもした。
後にプロジェクトが変わり、マネージャーによってこれほどまでに差があるのかと痛感することになった。例えばチームに対する関心の高さや、マネージャーが盾となって外からの雑音を防いでくれているかどうかだ。あるプロジェクトでは、マネージャーがミーティングの時くらいしか姿を見せず、それ以外の時間はSlackでメンションしても音沙汰がないか、始業時に質問した内容の返信が終業間際になってようやく返ってくるような有様だった。
チームにとって上司の存在は極めて重要だ。チームの手本となるべき存在であるだけでなく、上司の仕事に対する姿勢がチーム全体の仕事の進め方に直結するからだ。上司がスケジュールを気にせず、品質にも無頓着であれば、それは部下に対して「納期も品質も気にしなくていい」と言っているようなものだ。
今思い返せば、僕がキャリアの中で出会ってきた上司は優秀な人たちばかりだった。だからこそ、そうしたギャップに直面した時の落胆は大きかったが、現実の世界のシビアさを知る良い薬にもなった。
楽しかった思い出
Happy Friday
当時は毎月最終金曜日に「Happy Friday」が開催されていた。会社が軽食や飲み物を用意し、みんなでカフェスペースに集まって談笑できた。コロナ禍が始まってからは開催されなくなってしまったが、今でもとても懐かしく思い出す時間だ。
また、週に1回、午後に全社ミーティングがあり、連絡事項のアナウンスが終わった後の時間は通常以下のように使われていた：
- 新入社員の自己紹介
- 誰でも登壇できる技術LT（テーマは自由）
他のプロジェクトが直面している課題やその解決策を知ることができ、同僚と交流する絶好の機会だった。さらに金曜日にはフロントエンドチーム内での知見共有会も開かれていた。
韓国出張
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も形骸化し、単なるルーチンワークをこなしているだけに感じられた。この傾向はバックエンドに転向してからより顕著になり、あるマネージャーとは意見の相違や摩擦が頻繁に生じるようになった。
最後にアサインされたプロジェクトは、プロダクトの性質自体がかなりビジネス寄り（営業寄り）であり、数週間かけて小さな機能を一つ作るだけ、という感覚に陥ることが多かった。その期間で面白かったのはバックエンド開発に携われたことで、バックエンドに移ってからは大規模トラフィックを扱う際の注意点を多く学び、レコメンドシステムの設計も担当できた。ただ残念なことに、それはテスト段階のままで本番リリースを迎える前に僕は退職してしまった。そしてその最後のプロジェクトでは、広告のインプレッション数を増やすことばかりが目標とされることが多く、作れば作るほど自分の進む道に迷いが生じていった。
さらに僕が違和感を覚えたのは、「プロモーション（昇進）駆動」の裏にあるロジックだ。「代理指標が目標となった瞬間、それはもはや良い代理指標ではなくなる」という法則の通りだ。
本質的な価値を持たないものが、さも大きなインパクトがあるかのように体裁よくパッケージングされている場面を何度も目にした。例えば社内でかつて「標準コーディング規約の統一」が推進され、全社共通の設定ファイル用のリポジトリが作られたことがあった。しかしブームが過ぎ去るとそのまま放置され、設定ファイルはメンテナンスされずに陳腐化し、各プロジェクトに適合できなくなった結果、最終的にはどのプロジェクトも独自に設定を抱え込むことになった。
だが、後になって僕は悟った。たとえ何かに本質的な価値がなかったとしても、それがなぜ価値を持たないのかを論理的に説明できる能力が必要なのだ。そして、世の中の多くのものはパッケージング次第で60点から100点に見せかけることができる。ということは、自分が100点だと思うものがあるのなら、それを200点に見えるくらいに包み込んで初めて、周囲に認知してもらえるということなのだ。
組織が巨大化すると、多くの指標は定量的には測れなくなり、上層部は数字やプレゼン資料だけを見るようになる。もちろん、決められたゲームのルールの中でうまく立ち回れなかったのは、完全に僕自身の責任だ。僕はゲームのルールを変えることもできなければ、既存のルールの中で上位に食い込むこともできなかった。
そして決定打となったのがAIだった。2024年はまさにLLMモデルが百花繚乱の進化を遂げた1年だった。大企業においてAIを導入しようとすると、コンプライアンス、セキュリティ、データ保持といった様々なハードルに直面せざるを得ず、最先端（state-of-the-art）のモデルを手軽に使い倒すことが難しい。
AIは今後数年間の大きな潮流となり、ソフトウェア開発のあり方を激変させると僕は考えている。だからこそ、もっと自由な環境でそれを探求したかった。長い間悩み抜いた末、僕は退職を決意した。先行きが見えない数々の不確実性と向き合わなければならないため、この決断を下すのは僕にとって非常に困難なことだったが、今振り返ってみても、この選択をして本当に良かったと心から思っている。
後悔していること
僕の対人関係のあり方は、自らの育った環境に強く影響されている。僕は自分から積極的に人に近づくタイプではなく、社交も得意ではない。むしろ一人でいることを好む人間だ。
その結果、協業しているチームの枠を超えて積極的に人脈を広げようとしなかった。非エンジニアの部門であれ、他のプロジェクトの開発者であれ、当時の僕はそうした広がりの重要性を理解していなかった。
パンデミック以降はフルリモートになり、自発的に接点を作る機会がさらに減ってしまったのは、僕にとって悔やまれる点だ。その結果として、退職の日はどこか寂しい去り際となり、すべての機材を返却した時のあの虚無感は、今でも胸に苦く残っている。
他にも、数え上げればきりがないほどの反省がある：
- オーストラリア出身の同僚がいた。彼は最初にそう自己紹介してくれていたのに、僕は彼をイギリス出身だと勘違いし続けていた
- フランス人の同僚に対して「もう箸は使えるようになった？」と聞いてしまったこと。後から振り返ると、非常に失礼な聞き方だったと思う。「アジア人ではないから箸が使えないのが当たり前」という無意識の決めつけが根底にあったからだ
とりわけ心に引っかかっている出来事がもう一つある。以前、同僚同士で衝突が起きた際、僕は沈黙を選んでしまった。僕から見ればその出来事自体はそれほど深刻なものには見えなかったのだが、僕のその見解を当事者に伝えることはしなかった。
後になって、彼が抱えていた精神的プレッシャーは相当なものだったのだろうと思い至った。気まずい場面に直面した時、僕はいつもそうやってやり過ごしてきた。しかし、キャリアの中で上を目指し続けるのであれば、居心地の悪い対話を避けて通ることはできない。むしろ対峙しなければならない場面のほとんどは、そうした不快な対話の連続なのだ。ずいぶん前の出来事だが、今でもずっと心に残り続けている。
退職後、最も長く一緒に仕事をした同僚たちと食事に行くことができた。彼らには本当に感謝している。
学んだこと
会社では間違いなく、これまでにない成長の機会を得ることができた。大規模トラフィックに直面した際にいかに適切なアーキテクチャを設計するか、サーバーをゼロから構築すること、世界各国から集まった開発者との交流、他部署とのコミュニケーション、チームをリードして複数の機能をやり遂げたことなど、どれもかけがえのない経験だった。これほどのトラフィックと規模を持つ環境でなければ、かつての僕では想像すら及ばなかった景色を見ることができなかったはずだ。
- 技術は武器だが、すべてではない。特にプロジェクトの進行においては、LINEのプロセスの多くが標準化されていた。しかし、それは上司やマネジメント層が裏で調整してくれていたからこそ成り立っていた結果に過ぎず、決して自分一人の功績ではない。
- 影響力を発揮したいのなら、「人」にまつわる数々の課題に向き合わなければならない。僕はLINEでプロセスやドキュメンテーション、ソフトウェア開発の手法を多く学んだが、「人」に関してはまだまだ学ぶべきことが山積みだ。
このあたりについては、職涯回首（キャリアの振り返り）でさらに詳しく述べている。
おわりに
日本で働くことについて語られる時、給与が高くない、税金が重い、独特の企業文化がある、といったネガティブな意見が聞かれることも少なくない。どんな会社にも不完全な部分はあるし、当然LINEにもそれはあった。それでも僕は、機会があればぜひ一度、これほどの規模を持つ会社で働いてみることをお勧めしたい。
僕自身、日本という国が大好きだ。もちろん、台湾自体も非常に心地よく暮らせる場所であり、純粋に労働環境の面だけで見れば、日本など眼中に置かずシリコンバレーを目指すべきだという意見も多いだろうし、それには僕も同意する。それでも、僕は日本にいたかったのだ。
欧米やインド出身の多くの同僚たちと話したことがあるが、スタバでPCを置いたままトイレに行き、戻ってきてもPCが盗まれていないこと、あるいはスマートフォンを首からぶら下げて夜道を歩いていても強盗に遭わないこと——こうした日常は欧米ではなかなかあり得ない。先進国でありながら、日本は極めて高い社会秩序と、相対的に手頃な物価を保ち続けている。
退職を経て僕が心に刻んだのは、「常に優しさを忘れず、自分の手の届く範囲でできる限り人に手を差し伸べる」ということだ。
ありふれた綺麗事のように聞こえるかもしれない。しかし僕は、技術を自らの特権（ゲートキーピング）のように扱い、登りつめるほどに傲慢になっていく人間をあまりにも多く見てきた。技術の壁はいずれAIによって平坦にならされる。その時になっても生き残れるのは、誰かに快く手を差し伸べられる人間であり、最も偉そうにふんぞり返っている人間ではないはずだ。かつて深夜に見知らぬ人にドアをノックされて途方に暮れていた時、わざわざ駆けつけて心配してくれた台湾人のテックマネージャーには、今でも心から感謝している。
最後に、日本での暮らしの写真をいくつか載せて筆を置くことにする。この記事が読者の皆さんに何かしらの気付きやヒントを与えられたら幸いだ。もし福岡に遊びに来ることがあれば、ぜひコーヒーでも一杯飲みに行こう！
関連記事
- 籠と槍 これは子供の頃に大好きでよく読んでいた本の一つ、『学習する組織（五項修煉）』の物語からの一節だ。子供の頃はもちろん組織やチームのことなど理解しておらず、ただ中の物語が好きだっただけだった。大人になってから、『学習する組織』の物語の内容がまさにチームを巡るものだったと気づくとは思ってもみなかった。
- 15. 感謝に満ちた人生 子供の頃は家が裕福ではなく、生活も決して順風満帆ではなかった。経済的な支援がない状況では、選択肢は極めて狭くなる。しかしそんな環境にあっても、僕は…
- 14. 1000人の真のファン（1000 True Fans） このアイデアは、クリエイター（アーティスト、作家、ミュージシャンなど）に向けた運営戦略だ。クリエイターは世界的なスーパースターになったり、何百万ものフォロワーを持ったりする必要はなく、自分を熱心に応援してくれる少数のファンさえいれば、安定して生計を立て、創作を続けられるという考え方である。
- 13. 不確実性を受け入れる 『ブラック・スワン』の著者であるナシーム・タレブはかつて、ある概念を提唱した――一見すると絶対にあり得ないような出来事が思いがけないタイミングで発生し、その大半は予測不可能であるにもかかわらず、極めて甚大なインパクトをもたらすというものだ。2020年のCOVID-19はその典型例であり、パンデミックの影響によって人々の生活や働き方は一変した。持ちこたえられずに倒産や破産に追い込まれる店舗も相次ぎ、状況が好転し始めたのは2023年になってからのことだった。