この記事は、 みらい翻訳 Advent Calendar 2020 4日目の記事です。
はじめに
こんにちは。株式会社みらい翻訳 プラットフォーム部の@m-chikaです。
みらい翻訳には今年からジョインし、エンジニアリングマネージャーとして機械翻訳サービスMiraiTranslatorの開発に携わってます。
Advent Calendarには初めて参加します。
この記事について
ある日、社内ミーティングの資料で以下の一文が目に入ってきました。
「今日から皆さん、フルサイクルエンジニアです」
今後、開発チームのフルサイクル化を目指しますということでした。フルサイクルエンジニアという言葉に初めて触れた瞬間です。
お、これは何だろう？
フルスタックエンジニアと似てるけど、間違えたという感じじゃなさそう。
プロみたいに、宣言すればなれるのかな？
それともどこかになれるサイトでもあるのだろうか。
...というのは冗談ですが、もう少しちゃんと知る必要があると思ったので、
今回はフルサイクルエンジニアについて調べたこと、思ったことなどを書きます。
フルサイクルエンジニア（フルサイクル開発者）とは
フルサイクルエンジニアという言葉は、2018年5月に書かれた Full Cycle Developers at Netflix — Operate What You Buildという記事にある "full cycle developer" に由来しています。
訳としてはフルサイクル「開発者」が正しいですが、「エンジニア」とした方が語呂が良いと思うのでここでは「フルサイクルエンジニア」と記載します。
この記事は、VOYAGE GROUP techlog のエントリ Netflixにおけるフルサイクル開発者―開発したものが運用する で翻訳が公開されているので、本記事でもこの翻訳記事の訳文を一部引用させていただきます。
Netflixにおけるフルサイクルとは、開発チームが運用とサポートを含めたサービスライフサイクルの一連のタスクをすべてを担い、開発を回すことを意味します。
"開発したものが運用する"というアプローチでは、システムを開発するチームが運用とサポートにも責任を持つことでdevopsの原則を実践する。責任を外部化するのではなく開発チームに与えることで、ダイレクトなフィードバックループと共通のインセンティブを持つことができるのだ。
devopsの原則を取り入れたソフトウェア開発ライフサイクル
出典：Netflixにおけるフルサイクル開発者―開発したものが運用するより
devopsは開発チームと運用チームの連携を深めることでソフトウェアのビジネス価値を顧客に迅速に届けるという概念ですが、これを同じチームでやった方が話が早いじゃん、ということです。
更に、フルサイクルの開発チームは各ライフサイクルで発生する作業を自動化することによりスケールします。
フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する。開発者の視点で問題を評価し、「このシステムを動かすために必要なものをどう自動化できるか？」「どのようなセルフサービスツールがあればパートナーが開発者の手を借りずに自分の疑問に答えることができるだろうか」と問う。人間中心よりもシステム中心に考え、手動で行われていたものを自動化することによって、チームはスケールする。
背景
Netflixでフルサイクルエンジニアが生まれた背景には、開発チームと運用チームが分かれた組織におけるチーム間のコミュニケーションコスト増大という、「ごくありふれた問題」がありました。
開発チームと運用チーム間でのコミュニケーションや知識の移転はロスが多く、デバッグやパートナーからの質問に回答するためには余計な往復を必要とした。また、運用チームがデプロイされる変更点についての直接的な知識を持っていないため、デプロイ時の問題の検知と解決にはより多くの時間がかかった。コードの完成からデプロイまでの時間は今よりずっと長く、リリースは日ではなく週単位で行われた。アラート/監視の欠如や性能問題やレイテンシーの増加といった問題で実際に苦しむのは運用チームで、開発チームはそれを運用チームから間接的に伝えられるだけだった。
こんな経験ありませんか？
自分の経験として思い起こすと、以下のような現象が挙げられます。
思い当たるフシのある人もいるんじゃないでしょうか。
- 開発チームにデプロイするノウハウがないので運用チームにデプロイ依頼してスケジュール調整
- ほんの少しの文言修正でもデプロイ待ちで数日かかったりして迅速にデプロイできない
- デプロイは運用チームがやるが、デプロイ時に問題が出たら開発チームでないと調査が難しい
- アラートが飛んでくる原因の多くはプロダクトのコードにあるにも関わらず、アラートを受け取って苦しんでいるのは運用チーム
また、運用チームと同様に横断チームとしてQAチームが存在する場合も同様の問題がよく生じます。
- QAチームが各開発チームのQAを一手に引き受けるため、開発チーム間でスケジュールの取り合いになる
- QAチームは全開発チームの作る機能に精通していないため、QAケースを作る前に仕様理解にかかる時間が大きい
- QAチームがいるために本当は開発チームで検出すべき問題がQAフェーズまで発覚せず、手戻りやスケジュール影響が大きい
...リアルにイメージし過ぎて胃が痛くなってきました。。
よくある解決策
このような問題を解決するためによく取るアプローチとしては、一部のデプロイやQAを開発チームでできるようにするために権限を渡したり、手順を自動化するなどして開発チームに提供するといったことが考えられますが、Netflixの事例では
例えば、開発チームがデプロイをしたりパイプラインの破損をデバッグできたとしても、多くの場合彼らはリリースの専門家である運用チームの指示に従うことが多かった。また運用チームにとっては、日々の仕事を行うモチベーションはあっても、他チームから自身への依存をなくすための自動化を優先させるのは難しかった。
一部の業務を開発チームにもできるようにする（でも通常はやらない）だけでは運用チームへの依存は完全には無くならなかったということです。
自分の経験した現場を想像しても、開発業務そのものですら忙しいときにはリリースやQAといった作業を積極的にやるという選択は難しいと思います。
「余裕があればやります」とは言いつつも、そんな余裕ができる日は永遠にやってこないという...
これを根本的に解決するために、Netflixでは開発チームが設計・開発・運用をすべて行う責任を持つというアプローチを取る必要があったとのことです。
よくある疑問に自分で答えてみる
フルスタックエンジニアと何が違うんだっけ？
おそらくみなさん最初に思い浮かぶのはこれでしょう。
よくあるフルスタックエンジニアのイメージはというと、
- 要件定義/設計/実装まで一気通貫でできます！
- フロント/バックエンド/インフラ、何でもできるぜ！
- イケてるアプリケーションをイチから作れます！コンテナでビルドしてクラウド環境にデプロイまで！
こんな感じでしょうか（薄い）。
フルスタックエンジニアもフルサイクルエンジニアとかなり似ています。
いや、ほぼフルサイクルのような定義を記載しているサイトすら見かけます。
おそらく、「フルスタック」という単語が、人によって何を指すのか解釈が分かれやすいからだと思います。
それでも、自分なりの理解で両者の定義の違いを区別するのであれば、こんなところでしょうか。
| 観点 | フルスタックエンジニア | フルサイクルエンジニア |
|---|---|---|
| 領域の分け方 | 技術の専門領域（フロント/バックエンド/インフラ等) | ソフトウェアライフサイクルのプロセス（(要件定義 ※1)/設計/実装/テスト/デプロイ/運用/サポート） |
| "フル"を満たす主体 | 個人 | 個人 or チーム ※2 |
※1 Netflixの例では要件定義という言葉はソフトウェアライフサイクルに含まれていません。ビジネス側やプロダクトマネージャで必要十分な要件を決められる体制であれば特に含める必要はないので、そもそも馴染まないのかもしれません。
ただ、プロダクトマネージャが不在で 要望：営業 → 開発：要件定義 という状況はよくあると思っていて、この場合ビジネス側では 欲しいもの と 必要なもの の区別が難しいことが多いため、要件定義もエンジニアが担う必要があります。
※2 フルスタックは基本的にエンジニア個人の能力の範囲について言及されます。
フルサイクルについても当然個人の守備範囲は広くなりますので、**フルサイクルを担うには結局フルスタックでないと回せないんじゃない？**という疑問もあります。
これについては、以下２つの例が参考になると思っています。
VOYAGE GROUPの例
VOYAGE GROUPでは、フルサイクルを重視しているとのことです。
「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」には以下のようなことが書かれています。
フルスタックというと、一人でプロダクトやサービスをすべて作れることに主眼がおかれていると思います。一方、フルサイクルでは、全部を作れる必要はないければ、その代わりビジネス的要件を整理するところから一人でできること
つまり、
- 結局フロントもバックエンドもインフラもある程度触れる必要はある
- が、フルスタックというほど全領域に長けている必要はない（フルスタックに求める水準...）
- どちらかというとビジネス要件を含めた上流工程からリリースまでを守備範囲としてこなせることの方が重要
Netflixの例
Netflixの場合も
フルサイクル開発者はソフトウェアライフサイクルの全ての分野において知識があり効果的であることが期待される。
このようにフルスタックに求められることと近いことが書かれていますが、一方で
驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。
少なくとも記事の事例にではチームという単位で語られています。これは必ずしも個人でフルサイクルを担う必要はなく、重要なのはチームでフルサイクルを回せることであると理解しています。
業務量が増えますよね？
増えますね。。
開発チームでソフトウェアライフサイクルのすべてを担うということは、今まで専門外と捉えていたQA,デプロイ,サポートなども行うということなので、業務としてカバーする領域が広がり、例えば常にコーディングに100％集中するといったことは必然的に難しくなりますので、単に今のチームで業務領域を増やすだけでは開発スピードが上がるどころか落ちる一方になり、ブラック企業認定は確実です。
そうならないためにはソフトウェアライフサイクルで発生するそれぞれの業務の効率化、自動化が必須になります。
各チームでフルサイクルを回すために共通で発生するビルド・デプロイ、テスト（QA含む）、保守運用作業、インフラ構築といった作業は、それまで専門に携わっていたチームやエンジニアを中心にツール化したり、スキル底上げのための十分なトレーニングを整備する必要があります。
Netflixほどの規模の組織でも大変だったと思いますので、他の企業がこれをやるのに相当な努力が必要なのは間違いないでしょう。。
マイクロサービスとフルサイクル開発の関係は？
マイクロサービスアーキテクチャの文脈でフルサイクル開発が語られることもあります。
なぜなのか最初はイマイチわかっておりませんでしたが、こちらの講演を観てスッキリしました。
BIT VALLEY 2020「フリマアプリ「メルカリ」AIチームのサービスライフサイクルと、メルカリにおけるフルサイクルエンジニア」
マイクロサービスチームにすると
マイクロサービスアーキテクチャで分かれた機能ごとにチーム編成をすることで、各開発チームが責任を持つ機能は小さくなり、他の機能との依存関係を気にせず開発を進めることができるようになります。
ただ、SREやQAといった横断チームは相変わらず全開発チームの担当をしなくてはならないため、スケールしません。(資料22ページ目)
そこで
各開発チームでSREやQAなどもすべて行うようにすれば、デプロイやQAを待たずにフルサイクルを回すことができるようになります。(資料24ページ目)
ただ、既存サービスをマイクロサービス化するにはプロダクトの作り直しが必要になるケースが多いです。
またマイクロサービスごとにチーム編成をすることは組織の再編成を伴うため、どの企業でもできるわけではありません。
営業もカスタマーサポートも全部エンジニアがやらなければいけないの？
まず、営業まではさすがにソフトウェアライフサイクルには含んでいません。営業には顧客との関係づくりやセールスの戦略などソフトウェア開発とは別の要素が非常に大きく、数人のスタートアップでもない限り、通常はエンジニアに求められることはないでしょう。
カスタマーサポートについては、カスタマーサポート業務の内容・規模や対象顧客によって考えが分かれると思いますが、顧客窓口（受付、回答役）は各エンジニア・各チームそれぞれが兼務するのではなく、専門のサポート担当を置く方が窓口の一本化とサポート品質の均一化という面で優れていると思います。
チームメンバ全員がフルサイクルエンジニアでないといけないの？
人には向き不向きがあります。専門特化型の人もいれば、なんでも屋型の人もいるので、全員がなんでも屋を目指すというのは難しいです。むしろそんな人ばかりのチームというのはさすがに偏りすぎていると思います。。
実際、Netflixでもこのように言っています。
フルサイクルモデルにおいては、ツールによって拡大されたより広い分野でのオーナーシップや有効性に対して優先順位付けがなされる。仕事の幅広さは多様なテクノロジーへの興味や適性を求めることになる。あるエンジニアは狭い分野での世界的な専門家になることを好むし、そのような専門家が必要とされる分野もある。このような専門家にとっては、広い分野でそれなりのスキルを求められることは居心地の悪いことであるし、時には虚しいと感じるかもしれない。Netflixでも、幅のあるスキルではなく特定の分野での深い専門性を好む人々も存在するし、私たちもそのような働き方をサポートしている。そして別の人たちはより幅広い職務を楽しみながら働いている。
全員がフルサイクルでなくても、 チームでフルサイクルを回せること が大きな目的であれば、問題ありません。
まとめ
どうでしょう。これでフルサイクルエンジニアになれたでしょうか（笑）
個人的には、どこまでがフルサイクルの範囲なんだっけ？というのが一番の疑問だったのですが、この記事で触れた例だけでも企業ごとにやや異なるのが分かりました。
ハッキリと定義しにくいのが何とも言えませんが、フルサイクル化で目指すのは 如何にソフトウェアのビジネス価値を顧客に迅速に届けるか ということなので、これを達成するための実践の仕方は違って当然なのだと理解しました。
自分の理解のためにまとめようと色々書いたので伝わりやすいかどうかはわかりませんが、参考になれば幸いです。
次は明後日12/6に@shhshnが書いてくれるようです。