この記事はBASE アドベントカレンダー 2022の8日目の記事です。
はじめに
BASE BANK Section Dev Group Manager/ BASEカード Engineering Program Managerの松雪(@applepine1125)です。
普段はBASEカードのEPMとして開発をリードしながら、BASE BANKがもつプロダクト開発チームそれぞれがガンガンアウトプットを出していけるように様々なサポートを行っています。
最近は、まだ日本であまり馴染みのないEngineering Program Managerについて色々とアウトプットしているので、特にマネジメント視点からアジリティの高いチーム作っていきたいぞ!という方は是非読んでいただけると幸いです。
プロダクトのデリバリー、クオリティに責任を持つEngineering Program Managerという役割
オーナーシップを持ち自己組織化するチームに必要な Engineering Program Managerという役割
今回は、BASE BANKでも掲げているフルサイクルエンジニア(Full Cycle Developer)というスタンスについて、定義だけでなく実際の仕事の中で見出した姿をお伝えします。
フルサイクルエンジニア(Full Cycle Developer)とは
2018年にNetflixが記事で公開し、日本でもCARTA Holdingsさんが訳してくださったことによりさらに広まりつつある概念です。
Full Cycle Developers at Netflix — Operate What You Build
Netflixにおけるフルサイクル開発者―開発したものが運用する 上記記事の日本語訳
詳細な内容については上記記事に任せますが、要はこれまでソフトウェアライフサイクルの各段階を分業、専門化していた状態から、よりスピーディにプロダクトアウトプットし続けるために一連の段階を価値提供に関わるエンジニア、チームが責任を持ち、実行できるようにしようというスタンスです。
https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
別にNetflixが提唱して初めてそういった働き方、関わり方が生まれたわけではなく、これまでも自律性の高いチームだったり、良くも悪くもカオスなチームに所属するメンバーは似たような働きをしていたのではないでしょうか。
プロダクトや事業を前にすすめるために、創るべきプロダクトについて考え、実装し、インフラや安定したリリースのためのCI/CDフローを構築し、効果測定のための分析基盤まで整備し開発のサイクルを回し続ける。
webアプリケーションエンジニアが担ってきたこの責務にNetflixがFull Cycle Developersという名前付けを行うことで、プロダクトアウトプットのサイクル全体をより能動的に効率よく回そうとする流れができつつあるのは喜ばしいことです。
フルサイクルエンジニアはフルスタックエンジニアなのか?
フルサイクルエンジニアを志向する上で、よく話に上がるのがフルスタックエンジニアとの比較ではないでしょうか。
果たしてフルサイクルエンジニアを志向することはフルスタックエンジニアになることなのでしょうか?
個人的な意見ですが、結果的にフルスタックエンジニアになっていくことはあるものの、必須ではないと思っています。
フルサイクルエンジニアは “Operate what you build” (開発したものが運用する)というアプローチで、開発だけでなくテストや運用、様々なものを効率化します。
ここで重要なのは、個人ではなくチームで一連のサイクルをスピーディに回すことに取り組んでいることです。
全員が全技術領域において圧倒的なアウトプットができれば理想ですが、現実世界ではメンバーによってスキルや興味関心のある領域が異なるのは当たり前です。
そういった中で、CI/CDやテストなどの技術的なツールだけでなく、各メンバーの得意領域における知見やスキルもチームのツールの一つとして活用することで、チームとしてより良いアウトプットを生むことができます。
とはいえ、チーム内で技術的に完全に分業してしまうとこれまでのような専門化した分業体制をチーム内で再現することになるため、各メンバーが少なくとも各技術領域にチャレンジすることは求めるべきだと思っています。
プロダクトのために、自分の強みを活かしつつもその時々ですべきことを行っていくことで、いわゆるT字型のようなスキルセットをもったエンジニアになっていくことはあるでしょう。
フルサイクルエンジニアは専門性が身につかないのか?
広いプロダクトライフサイクル、技術領域に関わることで、器用貧乏になることを恐れている方を時々見かけます。
チームや会社の状況により、仕方なくいろいろな領域に関わらざるを得なくなった結果、自身の強みとなる領域を見つけられずもがくこともあるでしょう。
フルサイクルエンジニアの場合、より良いプロダクトアウトプットのために自ら様々な領域にチャレンジしていきます。
上でも書いたように、自身の強みをチームのツールの一つとして活かしながら、プロダクトのために実行できる領域を広げていけるように成長戦略を立てていくことで、技術的にも十分専門性を育てることができます。
とはいえ、チームとして分業体制がうまく構築され、いわゆる深いI型のスキルを持ったエンジニアに技術的な専門性で劣ると感じることもあるでしょう。
しかし様々なスキルをプロダクトのためにどう使いこなすか、それによってメンバーと共に成果を出し続けられることも十二分に専門性の高いスキルだと思っています。
個ではなくチームのアウトプットを最大化する
事業やプロダクトは常に成長圧力に晒されます。プロダクトの要求も複雑かつ柔軟に変化していきます。
自らの手だけで全領域実行できるようになったとしても、いつか個人の物理的なアウトプット量の限界にぶつかります。
素早い市場の変化、柔軟な要求の変化に追従し、リードしていくためにはチームで課題に取り組まなければなりません。
Some developers view design+development, and sometimes testing, as the primary way that they create value. This leads to the anti-pattern of viewing operations as a distraction, favoring short term fixes to operational and support issues so that they can get back to their “real job”. But the “real job” of full cycle developers is to use their software development expertise to solve problems across the full life cycle
Netflixのブログでもこう言っているように、専門性を発揮しつつもあくまでチームとしてライフサイクル全体の問題を解決することにフォーカスする必要があります。
そのなかで各個人に求められることは、少なくともすべてのライフサイクルの段階にオーナーシップを持つことです。
現実にはインフラ構築はSREの方に実行いただいたり、カスタマーサポートの方にユーザーのサポートをしていただいたりすることもあるでしょう。
そういった場合でもライフサイクル全体をより良くするためにステークホルダーとどうコラボレーションしたり、場合によってはチームの責務として巻き取れるか主体的に検討し実行することにより、個人だけではなくチームを強化することができます。
By combining all of these ideas together, we arrived at a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support.
個人的にNetflixのブログ内のこの一節が好きです。個人ではなくチームなのです。
NetflixのエントリのタイトルもFull Cycle DeveloperではなくFull Cycle Developer"s"であることにお気づきでしょうか。
developerが複数形であることに(勝手に)意味を感じ取っています。
プロダクト開発は基本的にチームで行います。チームがよりよい価値提供を目指して一丸となり、そのために個々人がチームに対しどういった貢献をするのか。そこをうまく組み立てることができれば、各々の強みを最大限に生かした、プロダクトへの様々な関わり方を生み出すことができます。
フルサイクルエンジニアとして働く意義、意味を創る
ここまで主にメンバーの立場でフルサイクルエンジニアについてお話してきました。
ただプロダクトのためにやるべきことをやれ!では人は動きません。そこでマネジメントの腕の見せ所です。
チームとしてフルサイクルエンジニアとして取り組むことがインセンティブとなるように目標や評価を設計する必要があります。
個人が直接プロダクトに価値を与えていくだけでなく、解決すべき問題を見つけるための視点の時間軸を切り替えられるように、チームが余裕を持てるような投資も行っていく必要があります。
例えば、短期的に目の前のプロジェクトをなんとしてもスケジュール通りに終わらせることだけをひたすら求められた場合を考えてみましょう。
当然目の前のタスクに集中し、プロジェクトを完遂させるために払った技術的負債を返済する余裕もなく、ツールやスキルだけではどうにもならなくなります。
すると、短期的な視点で任された自分の仕事だけをこなすことに躍起になり、保守的な見積もりや越境を回避することによるディスコミュニケーションが多く発生するようになり、PMやビジネスサイドとエンジニアとの間で信頼関係が構築できずチームとして破綻していきます。
チームやメンバーは燃え尽きのリスクに晒され、プロダクトアウトプットのライフサイクルが破壊されてしまうのです。
とはいえ、長期的な視点で技術的な投資ばかりしていては事業は前にすすめることができません。
あくまでプロダクトアウトプットのためにどういった投資ができるか考え、それを実行したことで日々の開発がどのように効率化したか常に振り返り続ける必要があります。
直接事業を進めるための仕事と長期的な投資のバランスを取るためには、マネジメントをする人間が両方の視点を持ってうまく優先順位付けを行い、メンバーの成長をサポートし生き生きと働けるような環境づくりをする責任があります。
BASE BANKでのフルサイクルエンジニア像
色々と偉そうなことを書いてきましたが、我々BASE BANKチームもまだまだ発展途上の段階です。日々改善を積み重ねています。
BASE BANKチームはショップオーナーさんのキャッシュフローの課題解決を行うために2018年に誕生し、そこからYELL BANK、やBASEカードなどのプロダクトを生み出してきました。
新規事業立ち上げ、グロースを担うチームとして、最初から意識していたことはとにかく早くリリースし、素早く改善のサイクルを回し続けることです。
これを大前提として今に至るまで組織設計や技術選定、文化の醸成を行い続けています。
現在BASE BANKは全体で15名ほどのチームです。
そのうちエンジニアは10名で、下記組織図のようにDev Group内でBASE BANK管掌の3プロダクトごとにチームを分けています。(他にもチームはあるがBASE BANKに関係する組織構造だけ抜粋)
プロダクトの意思決定に関わるメンバーを組織構造的にも近い位置に置き、よりスピーディにコミュニケーションを取り意思決定を進められるように組織設計をしています。
https://speakerdeck.com/base/basebank?slide=29
なぜやるのか考え、フィードバックループを通じて学び続ける
エンジニアとして解くべき本質的な課題を発見し、フォーカスしてもらうために、なぜ今のような組織構造や開発プロセス、文化になっているのかについて深く腹落ちしてもらい、その上でチームの一員として何をすべきかを一緒に考え、アウトプットしています。
そして個人やチームがアウトプットの結果何を得られたか、何を改善すべきかを振り返りつづけられるようにサポートすることで、学びを積み重ね、発見する課題とそのアウトプットの質を高めていけるようにしています。
エンジニアチームのいわゆるレトロスペクティブのようなスプリントごとの振り返りだけでなく、様々なタイミング、粒度での振り返りやそこから生まれたネクストアクションの実行、そしてまた振り返り・・・といった積み重ねが、エンジニアに限らずBASE BANKチーム全体で当たり前のように行われています。
チーム全体でとにかく学び続ける。 これを徹底しています。
背中を任せ合う。コラボレーション
BASE BANKのメンバーは、皆がプロダクトのライフサイクルすべてを完璧に回せる超人というわけではありません。
各々の強みを最大限に活かしながら、個ではなくチーム全体で高い生産性を維持、向上させ続け、まさに"個ではなくチームのアウトプットを最大化する"の項で書いたことを体現してくれています。
日々の開発のサイクルは各チームが主体的にまわしつつ、チームを横断しレビューや技術的なサポートと通じて背中を任せ合っています。
背中を任せ合うのはエンジニアに閉じた話ではなく、product group(事業企画やマーケティングを担うチーム)やdesign group(デザイナーが所属するチーム)とも密に連携しあい、よりスピーディに仕事をすすめるにはどうコラボレーションしていけばよいか?を日々の振り返りを通じてアップデートし続けています。
https://applepine1125.hatenablog.jp/entry/20220818/1660750909
個人的に昔書いた"みんなでアジャイル"の書評の中でもふれましたが、アジリティの高いチームであり続けるための原則の一つとして早期から頻繁にコラボレーションするのがアジャイルというものが掲げられています。
変化に対し、チームとして柔軟に適応し続けるためには互いに密にサポートしあうのは当然の流れなのです。
越境
"フルサイクルエンジニアは専門性が身につかないのか?"の項で、T字型のスキルについて触れました。
フルサイクルエンジニアとして高いアウトプットを行い続けるためにはプロダクトに必要なことのために越境し続ける必要があります。
技術的なスキルに限った話だけではありません。必要なステークホルダーへのコミュニケーションなどチームの越境や、これまで持ったことのなかった範囲の責任を持ちチャレンジする越境など、様々な越境の形があります。
BASE BANKのメンバーは自分が関わるプロダクトにまつわる領域に高い興味関心をもち、積極的に越境しコミュニケーションを取り、主体的に仕事を前に進めてくれています。
その背景にはプロダクトやユーザーへの高い理解や、相互の信頼があるのかなと思っています。
とはいえ闇雲に越境し続けるとコンフォートゾーンを一気に突き抜けパニックゾーンにまで到達してしまい、越境から得た学びを積み重ねることができずに消耗してしまうこともあるでしょう。
そうならないためにも、自分がマネージャとしてOKRや日々のコミュニケーションを通してプロダクトの方向性とメンバーの志向をすり合わせ、チャレンジしてもらう範囲を着実に広げています。
信用、信頼
ここまで書いてきた学びのサイクル、背中を任せ合うこと、越境、すべての根底には互いへの強い信頼関係があります。
より柔軟にコミュニケーションを取り、学びを積み重ねながらスピーディにプロダクトや事業を前にすすめるためには、技術や経験だけではなく互いの信用、信頼が何より重要と考えています。
"フルサイクルエンジニアとして働く意義、意味を創る"の項でも書いたように、互いの信頼関係が構築できないと、越境することもなく、保守的になりプロダクトアウトプットのサイクルは鈍化していきます。成長もできません。
互いに信頼関係を構築するには手放しで任せ合うのではなく、日々の仕事を通じて互いに腹を割って議論し、成果を出し続ける必要があります。
腹を割ったコミュニケーションができるようになると、意思疎通がスムーズになるだけでなく、相手の理解も深まり、結果的に深い信頼関係を築く事ができます。
また社会人として至極当たり前の話ですが、約束を守り、成果を出し続けることで、信頼を積み重ねることができます。
これができるようになると、よくあるビジネスサイドとエンジニアサイドでやりたいことが食い違い衝突するようなこともなく、状況に応じて仕事の優先順位を適切にコントロールできるようになります。
チームとして仕事をする上で互いに深く理解し合い、頼り合える関係の構築を何より大事にしています。
おわりに
様々なツールが充実しエンジニア自身で実行できる範囲が広がる中、プロダクトのために越境し実行し続けるとフルサイクルエンジニアになっていくというのは自然な流れなのかなと思っています。
我々自身もまだよりよいチームづくりの途中です。今後事業やチームメンバーが増える中で様々な課題にぶつかることでしょう。
それでも互いに信頼関係を構築しあい、背中を預け合いながら、プロダクトのために何ができるか考え続ける姿勢さえ忘れなければ、どんな課題もこのチームであれば乗り越えていけるのではないかと思っています。
当然さらなる成長のためにより多くのメンバーの力も必要です。BASEやBASE BANKの事業、我々の働き方など少しでもご興味があれば気軽にお話しましょう!
明日は@gatchan0807 @yuripi の記事が公開予定です、ぜひご覧ください!
