困難を「一般解」で解く

困難を「一般解」で解く 2025-03-05 技術参謀たちの戦略図〜リーダーシップという選択肢と彼らが選んだ企業の魅力〜藤原俊一郎 @fujiwara

自己紹介 @fujiwara (X, GitHub, Bluesky) さくらインターネットクラウド事業本部(2025/02〜) 面白法人カヤック(〜2025/01) ISUCON 優勝4回
/ 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll

Staff Engineerの４類型 Tech Lead チームを導く Architect 設計で方向性を示す Solver 困難な問題を解決する Right
hand 経営陣と技術陣をつなぐ

Staff Engineerの４類型 Tech Lead Architect Solver Right hand 自分はどれか強いていえば、Solver (もちろん全員被る領域はある)

Solver = 困難な問題を解決する、火消し困難な問題とは例えば… パフォーマンスチューニング障害対応セキュリティインシデント対応コンポーネントの適切な使い方をするこれが実は意外と難しい運用における諸問題
(ログ、監視、アラート、デプロイ、etc) エンジニアリングや運用における困難 = 要因が単純ではない、複合的

やってきたこと現場で出会った困難な問題を解決する単にその場で解決するだけではなく、レバレッジの効く形で解決するのがベターレバレッジの効く形とは… そのプロジェクト/プロダクトに閉じていない解決法を見つけるそれを実装 / 導入 / 啓蒙する
→ 他のプロジェクト/プロダクトにも効く(みんなうれしい)

実例1: ログをAmazon Redshiftに取り込む 2015年ごろ fluent-plugin-redshift を使っていて運用が辛かった (最初に入れた Lobi というプロダクトで自分が…) fujiwara/Rin
( 26) で置き換え → 他のタイトルやログ基盤にも導入　　　

実例2: オートスケール環境でのスケーラブルなデプロイ 2014年ごろ (Lobiで) EC2でオートスケールがしたかったが、rsyncベースのデプロイでは困難 fujiwara/stretcher ( 249)を開発 → 他タイトルにも適用できた。コスト削減効果大

実例3: ECS / Lambda のデプロイそろそろコンテナ/FaaSを本格導入したかった2017年ごろ Amazon ECS: そもそもデファクトなデプロイツールがなかった kayac/ecspresso
( 892)を開発大変世間の皆様のお役に立っているようです AWS Lambda: apex/apex を使っていたが… 2019年にEoL → fujiwara/lambroll ( 385)を開発 ecspresso 同様の使い勝手になるように便利にしていった

ECS → Lambda でスケール速度改善+コスト削減 2024年アクセスのスパイクが鋭い+予測困難なマイクロサービス ECS ではオートスケールが追いつかない fujiwara/ridge (
63) を使って Lambda に置き換えアプリのコードは変更なしスパイク耐性が大幅にアップ(突然10倍きても平気) コストも大幅に削減デプロイフローの変更は最小限 ecspresso / lambroll が同じ思想で作られているので同じように使える

Staff Engineer の役割広い範囲に技術で影響力を及ぼせるのが Staff Engineer Solver = 困難な問題がある現場でその問題を解く可能であれば
「一般解で解く」ある現場で解いた問題は、他でも簡単に解けるようになる解法が OSS なら社内だけではなく、世間でも解けるようになるジュニアエンジニア = 自分の困難を解決できるシニアエンジニア = チームの困難を解決できる Staff Engineer = 会社/業界の困難を解決できる

「最強のSREイネイブラー」by Songmu https://junkyard.song.mu/slides/fujiwara-tech-conference/#27

困難を「一般解」で解く

困難を「一般解」で解く

FUJIWARA Shunichiro

More Decks by FUJIWARA Shunichiro

Other Decks in Technology

Featured

Transcript