フルサイクルエンジニア

Claude Code.icon

Netflix が 2018 年のブログ記事で広めた概念で、1つの機能やサービスについて、設計から開発・テスト・デプロイ・運用・サポートまでのライフサイクル全体を、同じエンジニア（チーム）がオーナーシップを持って担当する働き方を指す。

元ネタ

何と対比される概念か

従来の分業モデルと対比される：

table:_

従来モデル フルサイクル

Dev が作って Ops に投げる 作った人がデプロイ・運用も見る

QA がテストする エンジニア自身がテストの責任を持つ

SRE が本番障害を一次対応 開発者がオンコールに入る

PM が要件定義 → Dev に渡す エンジニアも仕様策定に深く関与

「You build it, you run it」(Werner Vogels, Amazon) の思想を、開発のさらに上流・下流まで広げたもの。

担当範囲のイメージ

code:_

要件定義 → 設計 → 実装 → テスト → デプロイ → 監視 → オンコール → 改善

└──────────── 同じエンジニアが全部見る ────────────┘

なぜこの働き方が出てきたか

マイクロサービス化で「サービスごとに小さいチームが完結して持つ」のが現実的になった

分業によるハンドオフコスト・責任の押し付け合いが目立つようになった

ツール（CI/CD、IaC、観測ツール）の進化で、1人がカバーできる範囲が広がった

似た言葉との違い

フルスタックエンジニア: 技術レイヤー（フロント〜バック〜DB）の広さの話

フルサイクルエンジニア: プロダクトのライフサイクル（企画〜運用）の広さの話

DevOps エンジニア: Dev と Ops の橋渡し（職種寄り）／フルサイクルは "Dev が Ops もやる" 思想寄り

トレードオフ

✅ オーナーシップが効く／意思決定が速い／品質意識が上がる

❌ 認知負荷が高い／属人化／オンコール疲弊／専門性の深掘りがしにくい

Netflix の記事でも「銀の弾丸ではない」と明記されていて、強いツール基盤と文化がないと単なる "全部押し付け" になる、と注意喚起されている。

https://gyazo.com/2b03a94c69d8f40fb8f4a3c3bca1de3a

netflix

frontend, backend, DB, ..みたいに全ての技術スタックを理解し開発できるエンジニア

フルサイクルエンジニアは

ソフトウェアのライフサイクルの全体をカバーして、

設計、開発、テスト、デプロイ、運用、サポートなどの各フェーズに責任を持つ