LinkedInを去るにあたって

• きちんと仕事をすることと、会社の速いスピードが衝突したとき、あなたはどちらを選ぶか？
• 信念を守って妥協するのか、それとも原則に合う仕事を求めて去るのかという問いで、後者を選んだエンジニア Chris Krycho の物語
• クリスは最終的に、自分の原則に合致する仕事を追求するために LinkedIn を去った
• ポッドキャストで語られた内容を整理
• 彼の話は、「イノベーションの必要性」と「プロジェクト健全性の重要性」のあいだにある緊張を強調している

クリス・クライチョのLinkedInでの初日

• クリスは2019年1月末にLinkedInに参加。大企業や健全な小規模企業でよく見られるさまざまなオンボーディングを経験した。
• クリスはコロラドからリモート勤務する予定だったが、最初の2週間はオンボーディングとチームとの時間に充てた。

数百万行のコード

• 前職での経験と比べて、LinkedInのフロントエンドクライアントアプリとバックエンドサービスの規模に大きく驚いた。
• LinkedInのフロントエンドは200万行に達し、これは前職の会社全体のコード量をはるかに上回っていた。

インフラチーム

• クリスの役割はインフラチームにあり、サーバー構築ではなく、エンジニアリング支援や開発者体験の改善に重点を置いていた。
• LinkedInの大規模なデスクトップアプリを、より扱いやすくすることが目標だった。

JavaScriptのモダナイズ

• JavaScriptクラスの導入によるコードのモダナイズ作業に参加。Emberフレームワークを使う中で生じる問題を解決する過程で、多くを学んだ。
• 大規模コードベースでのマイグレーション作業は、可能な限り自動化されるべきであり、手作業で処理するには作業量が大きすぎることを悟った。

TypeScript導入

• フロントエンドで発生するエラーを減らすため、TypeScriptへの移行を決定した。
• TypeScriptは段階的に導入でき、これはLinkedInが必要としていたスケーラビリティを提供した。

遅いマイグレーション計画 vs 'Finger Gun's Plan'

• クリスと彼のチームは、EmberコードをReactへマイグレーションする3〜5年計画を提案したが、別のチームは、全面的な見直しと高速な進行を約束する 'Finger Gun's Plan' を提示した。
• こうしたアプローチの違いは、クリスたちのチームが直面していた問題と、会社のスピードを優先する文化とのあいだの対立を反映していた。

クリスの経験と学び

• 不十分なアラートの問題を認識。
• メモリ使用量の増加とサーバー再起動の連鎖反応により、データセンター全体のサーバーがダウンした。
• システムのリセットと権限調整を通じて問題解決を試みた。
• 失敗は避けられず、ソフトウェアエンジニアリングとは、エンジニアがプロダクトの成果物を生み出す過程を支えるシステムを設計することだ。
• 多層的なレジリエンスを備えたシステムの必要性を強調。

事件に対する反発

• 問題解決の過程で、マネジメントからの信頼不足による不満が生じた。
• 上級エンジニアとの意見の相違やコミュニケーションの問題。
• システムは最良の状態でだけ動作するのではなく、あらゆる状況で支えられるものであるべきだと強調。

増していく圧力

• 技術的負債の解消とレジリエンス向上に取り組んでいたにもかかわらず、経営陣の不満は増していった。
• 複雑な問題に対して単純な解決策を求める経営陣との対立。

組織再編

• 「フィンガーガンズ・チーム」による組織再編と役割の変化。
• 別の役割での新たな経験と学習機会を認識。

反省と自覚

• 過去の経験と現在の状況を通じた自己省察。
• 人間関係の構築とコミュニケーションの重要性を認識。
• 技術的問題と社会的問題が相互につながっていることを理解。

結論と教訓

• クリスは、スピードを最優先の価値とする文化に対して批判的な視点を保ち続けた。
• キャリアと個人の価値観を見つめ直すことで、新たな機会を模索。
• エンジニアリングの卓越性を追求できる役割を探すクリスの旅は続いている。

GN⁺の意見

• クリス・クライチョの経験は、技術的原則とビジネス要件のあいだの対立をよく示している。
• 彼の決断は、個人の価値観と職業上の選択のあいだでバランスを取ることの重要性を強調している。
• LinkedInのような大規模な技術環境における変化管理は複雑であり、これは他の企業にとっても重要な教訓を提供する。
• TypeScriptのような技術導入はコード品質を向上させ、エラー削減に役立つ可能性があるが、大規模コードベースでは段階的なアプローチが必要となる。
• こうした技術的変化を推進する際には、開発者体験と製品リリース速度のあいだのバランスを考慮する必要がある。

[GN⁺]

Hacker Newsの意見

• あるマネージャーとの会話で、「君は理想主義的すぎる、収益を十分に重視していないし、価値観を変えるべきだ」と言われたという。これに対して嫌悪感を示し、自分の価値観を守り抜く意思を明らかにした。この発言はポッドキャストの中で最も興味深い部分であり、投稿者はこれによって重要なフィードバックを意図的に無視しているような印象を受けたという。キャリアを通じて学んだ教訓は、正しいことを知るのが難しいのではなく、正しい解決策について組織全体の合意を得ることこそが本当に難しい問題だということだ。

  • マネージャーとの会話で価値観の衝突を経験した事例
  • 重要なフィードバックを意図的に無視したように見える印象
  • 正しい解決策に対する組織全体の合意が重要だという教訓

• 2019年にfacebook.comをReactで書き直す作業に参加した。LinkedInのコードベースや組織について直接知っているわけではないが、似たようなコードベースや組織構造を持つ会社を見てきた経験がある。私は「フィンガーガン」アプローチを支持していて、うまく実装されれば良い結果をもたらしうる。複数のクライアントが同じ取り組みをしようとする場合、1つを土台にして他のプラットフォームにも展開できる。また、ゼロから始めるなら、クリーンで高速かつ簡潔なやり方で進められる。成功の一般的な要素は、ベテランの少人数チームが新しいシステムを作ることであり、ドメインエキスパートと技術エキスパートが組み合わさった小規模なエンジニアチームから成功が生まれると私は考えている。技術管理で繰り返し起きる大きな問題は、最も経験の浅い人たちが次の大規模システムを構築してしまうことだ。

  • Reactへの書き換え経験の共有
  • 「フィンガーガン」アプローチと少人数のベテランチームの重要性を強調
  • 経験の浅い人たちが大規模システムを構築する問題を指摘

• 大規模な書き換えは、管理可能なコードベースであっても危険であり、残存する問題が完全になくなることはない。数年後に隠れた設定ページを書き直そうとする人がいるだろうか？ コードベースを書き換えるためのフレームワークがあればいいのだが、実際には存在しない。自動化されたコードモッドは一貫性を要求するが、それが守られることは稀だ。時間の経過とともにコードパターンは大きく変化してきたので、まるで木の年輪を見ているようだ。コードを箱に入れて並べ替えるようなものだが、箱レベルでは自動化が行われていない。

  • コードベース書き換えの危険性と残存する問題
  • コード書き換えのためのフレームワークの不在
  • コードレベルの自動化と箱レベルの自動化のあいだの隔たり

• 現在LinkedInで働いており、ポッドキャストで言及されたChrisの役割とフロントエンドWeb開発はemberに関連していると思う。LinkedInのモノリシックな主力Webアプリであるvoyager-webのことを指しているのだろう。LinkedInにはvoyager-web以外にも、数百万行のコードと長いビルド時間を抱えるシステムが多い。たとえば、中間層、オフラインデータスタック、メトリクスシステム、Kafkaなどだ。17分のビルド時間はかなり良いほうで、一時的なインフラ障害なしで17分なら非常に優秀だ。

  • LinkedInでの現在の勤務経験の共有
  • さまざまなシステムとビルド時間についての説明
  • 17分のビルド時間に対する評価

• 数百万行のJavaScriptコードは、過剰な肥大化を意味する。LinkedInのようなサービスを再実装したり、自分自身の連絡先データベースを作ったりしたくなった。問題は、連絡先をどうやって大量に移行するかだ。Microsoft LinkedInの主な問題の1つは、連絡先情報をエクスポートできないことであり、これは連絡先プラットフォームに必須の機能だ。

  • JavaScriptコードの過度な肥大化を指摘
  • 連絡先情報移行の難しさ
  • 連絡先情報のエクスポート機能の重要性

• LinkedInで12年を過ごしたが、いまやかつてのエンジニアリング組織とはほど遠い。Kevin Scottがエンジニアリングを率いていた時代のほうがずっと良かったと評価している。

  • LinkedInでの長期勤務経験
  • 過去のエンジニアリング組織と現在の違い

• これはConwayの法則が働いている状況だ。組織が変わらない限り、同じコードの混乱を再び作り出すことになる。前向きなエンジニアリング施策は上から降りてくる必要があり、非常に高いレベルの支援が必要だ。組織を下から上へ変えるのは不可能であり、組織がコードベースを生み出すのだ。

  • 組織変化なしではコードの混乱が再発する可能性
  • 上層部からの前向きなエンジニアリング施策の必要性

• Chris Krychoが自分の苦労について率直に語りつつも、責任の押し付け合いをしない姿勢に深く感銘を受けた。CoRecursiveは、コードの背後にある複雑な文脈を掘り下げる、私の好きなポッドキャストの1つだ。

  • Chris Krychoの率直な姿勢と責任転嫁の回避
  • CoRecursiveポッドキャストへの肯定的な評価

• EmberからReactへの移行は、以前私が関わっていたクライアントが作った技術に適した事例に見える。彼は「Unhack」という言語を作り、ASTレベルで検索と置換ができるようにした。元のコードでパターンを指定し、それを別のパターンに置き換えるための言語を使っていた。数年前にそのクライアントとの作業をやめたので、いまも存在するかはわからない。

  • EmberからReactへの技術移行事例
  • ASTレベルでの検索と置換を可能にする「Unhack」言語

• LinkedInのコードベースが散らかっているというのは、Webサイトを使ってみれば驚くことではない。気になる投稿をクリックし、その投稿者についてもっと知ろうとしてから戻るボタンを押すと、フィードが再読み込みされて投稿を見失ってしまう。受信メッセージをスクロールしようとするとWebページ全体が重くなり、入力が反映されるまで10〜15秒かかる。なぜ30件もの偽の通知を受け取るのか？ それらは人々からの反応を強制するために作られた偽通知だ。推薦アルゴリズムも完全にひどい。

  • LinkedIn Webサイト利用時の不便さ
  • 偽通知と遅いWebページの反応速度
  • 推薦アルゴリズムの問題点を指摘