こんにちは！CTOのsuzukenです。
CARTAの開発スタイルは「フルサイクル開発」として説明しています。 これについてまとめておきます。
「フルサイクル開発」とは
「フルサイクル開発」という言葉は、2018年に公開されたNetflixのブログ記事にある「Full Cycle Developers(フルサイクル開発者)」に由来しています。
Full Cycle Developers at Netflix — Operate What You Build
要約すると、以下のように示されています。
「開発したものが運用する」のがフルサイクル開発者。責任を外部化せず、直接のフィードバックループを開発チームに内在させる。ソフトウェア開発者が設計実装のみならず、サポート、デプロイなどのイテレーションをすべて自分でこなしている。
運用のペインは開発者自ら解消する。
- ソフトウェア開発者はツールのちからにより、ライフサイクルを最適化させられている。
- ライフサイクルを最適化することにより、サイロを解消し、学習とフィードバックを最適化して、価値のデリバリー速度を高めるのがフルサイクル開発である。
当初この記事がでたとき、fluct（CARTAの事業子会社の一つ）の有村さんが日本語訳をしてCARTA TECH BLOGに投稿してくれました。
Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG
これが社外にCARTA（当時VOYAGE GROUP）はフルサイクル開発を志向していると認識されるきっかけとなったように思います。
この記事を多くのCARTAエンジニアが見た当初、
「ああ、自分たちの仕事を表しているなあ」
と感じたのでした。
CARTAもフルサイクル開発の実践者である
CARTAに浸透しているフルサイクル開発の在り方は、Netflixの「Full Cycle Developers」を参考にしつつ、独自のエッセンスを加えたものです。
世界的企業であるNetflixとCARTAが同じプラクティスを実践しても、どこまで行っても同じものにはなりません。CARTAもフルサイクル開発の実践者であると言えるでしょう。
フルサイクル開発者は、コードを書くこと(開発)だけでなく顧客への価値提供が仕事です。CARTAでは論理的に考え、あるべき仕組みを作れることがエンジニアの振る舞いとして求められています。
たとえば、次の役割を担います。
- ビジネス的な要件を整理する。営業から依頼されているものは、実は本当に顧客が求めているものではないかもしれない。「なぜ」を明らかにし、どう進めるかを判断する。
- テストをし、自らリリースする。自分のパッチは自分の手でリリースする。モニタリング基盤を通じてプロダクトKPIへの影響を確認する。
- そしてつくったソフトウェア・プロダクトを自ら運用し、改善しつづける。
フロントエンド、バックエンド、クラウド等、役割に囚われず、また場所や範囲を問わずに自ら手をいれて変えられることを善しとしています。
経験値の最大化を重視する
CARTAの開発の現場では複数のプログラミング言語や環境のあるプロダクトがほとんど です(TypeScript, Go, PHP, Kotlin, Pythonなど）。
ただし全てに習熟している必要はありません。チームでお互いに高めあい、支援しあいながら開発を進めています。
言語が複数あることが採用難易度をあげ、オンボーディングや育成上の問題にならないのか
と聞かれることもあります。
私たちは、「基礎のあるエンジニアなら、新しい技術を学ぶことは問題にならない」と考えています。むしろ新たな仕組みを学ぶことは楽しく、刺激的なことであり、技術選定の審美眼を養う上で欠かせない営みだと考えています。
新たなビジネス的要望のため、未知の言語や仕組みに関する学習は主要な仕事の一部です。こうした環境に身をおいていると、新しいものを学ぶことが日常になり、チーム及び個人としてのキャッチアップする力が向上していきます。
新しいものを覚えるのが億劫になってしまうより、それが当たり前になっているチームのほうがいい
「事業を開発する技術者たち」 第2章Zucks p.62 より
フルサイクル開発者は経験値の最大化を重視します。わたしたちの事業においては経験を増やすことが事業の成功にとって重要です。
なぜなら環境は変化し、技術は進歩するものであり、顧客の求めるものも常に要望のレベルが高くなるからです。事業モデルとしても変化に追随し、それにともなってプロダクトもなめらかに変わり続ける。これがCARTAにおける理想的なプロダクト開発です。
戻れる決断、戻れない決断
プロダクトを開発していると、多くの場面で決断する必要があります。
- 「この決済機能はいまつくるべきか」
- 「リファクタリングを先にしておくべきか、あとにすべきか」
- 「どのように新しい配信モジュールを日本向けに追加すべきか」
さまざまな問いを立て、決定し続けるのが開発の現場です。
プロダクト開発において重要なのは、「戻れる決断」を素早く重ね、小さく速く失敗し、成功に近づくことです。例えばデータを消してしまっては元に戻せないかもしれませんが、データを別の場所に移せば状態をもとに戻すことができます。「元に戻せる」のは強力な選択肢で、意思決定を速やかにするメリットがあります。個人や組織において小さく挑戦し、失敗から学ぶことを重視すれば経験を最大化できます。
Amazonでは「戻れる決断」のことをTwo-way doors(双方向に行き来できるドア)と呼んでいます。
参考:Elements of Amazon’s Day 1 Culture | AWS Executive Insights
Amazon で高品質で高速な意思決定を支援するために使用しているもう 1 つのツールは、一方向と双方向と呼ばれるメンタルモデルです。一方向の意思決定は、重大でしばしば取り返しのつかない結果をもたらす決定です。フルフィルメントまたはデータセンターの構築は、多くの設備投資、計画、リソースを必要とする決定であるため、注意深い分析が必要となります。一方、双方向の意思決定は、限定的で可逆的な結果をもたらすものです。サイトの詳細ページまたはモバイルアプリで機能の A/B テストを実施することは、可逆的な決定において基本的だがエレガントな例です。
では、逆に「戻れない決断」とはなんでしょうか？
元に戻すコストが高いものは「戻れない決断」と考えるとよいでしょう。
例えばデータベースの選定やモノリス or マイクロサービスの選定、採用が含まれます。もちろん長い時間軸で考えれば元に戻れますが、より慎重に意思決定をするのが合理的です。
一度決めた技術選定は、開発チームの文化にも影響を与えます。早い段階であれば元に戻すコストは低いですが、時間が経つにつれて戻すことが難しくなっていきます。
人の採用などは「戻れない決断」になりやすいです。一度雇用すると元に戻すコストは高くつきます。「戻れる決断」か「戻れない決断」かは環境、チーム、国における法律などによって変わってきます。
1つ言えることは、その意思決定について「元に戻せる」環境をつくることができれば、より早く意思決定ができるということです。「元に戻せる」なら、挑戦とそれに伴う失敗もしやすくなります。
「元に戻せる」環境が優れたフルサイクル開発を実現する素地になる
フルサイクル開発者を支える技術として、クラウド、ビルド・デプロイに関するツールやサービス、エディタによるコーディング補助などがあります。
また、CARTAで実施しているプラクティスには以下のものがあります。
- リリースおよび修復の高速化
- リバート可能なリリース、カナリアリリースで戻すことのコストを下げる
- オブザーバビリティへの投資: 何かあったらすぐ気づけるようにする
多くの場合はクラウドに標準で搭載されたり、ベンダーがサービスとして提供されているものを活用しています。たとえばNewRelic / Datadog / SplunkなどのAPMツールをつかえば監視が容易になります。これらは事業部によっては専任のチームが提供することもあります。
GitHub Actionはほぼすべてのチームがワークフローの自動化のために採用しています。自前でこれらを用意するのはとても手間がかかります。
優れたフルサイクルを実現するチームは高速に実験を積み重ね、多くの経験を得られるようにする。これを支えるのが「元に戻せる」環境づくりです。
状況判断力を向上させるには、何度もループを回す必要がある。
図: OODAループ (https://ja.wikipedia.org/wiki/OODA%E3%83%AB%E3%83%BC%E3%83%97 )
OODAは、「観察・指向・決定・行動」の4つのフェーズからなる意思決定フレームワークです。
図は意思決定のメカニズムを示しています。左から観察、状況判断、意志決定、行動と並んでいます。経過観察をしたり、行動からフィードバックを得てさらに観察を重ねる等の構造がループとして書かれています。
この図において重要なのは状況判断です。状況判断は「今何をすべきか」を分析し、過去の傾向と照らし合わせ、新しい情報を組み合わせることで判断を組み上げます。経験のない人には状況判断ができません。状況判断力を増やすには、何度もループを回す必要があります。
行動を増やすには状況判断力を高める必要があります。熟練したエンジニアは観察から行動までが短時間で実現できます。熟練したエンジニアはそれに至るまでに数多くの経験を積んでいます。
経験を積むには「元に戻せる」環境によって支援された早い意思決定を積み重ね、実際に自分で考えた機能を多く作るとよいでしょう。
ここまでみてきたように、フルサイクル開発はツール及び環境に支援され、意思決定を早め、試行と失敗の回数を増やすことで経験の最大化を重視しています。全員がフルサイクル開発者であるチームは、新しく入ったチームメンバーの経験獲得を支援します。チームとして安全な挑戦が行えるようになっていると、そのチームでは人の成長速度が上がります。
組織を越えて知見を共有することで、共に創る
CARTAにはフルサイクル開発者によって構成されたチームが複数あります。事業の数だけ、自律し、プロダクトにオーナーシップを持ち、事業を開発する技術者たちがいます。
社内では毎日、多くのツールやサービスをつかった実験が繰り返されています。モニタリングツール、テストツール、エディタの機能、デプロイのプラクティスに至るまで、各チームが自律的に実験を繰り返しています。
これらの実験と多くの失敗は、以下の環境を通じて個人や事業部を越えて共有されます。
- Slackやオフィスでの雑談の場で
- 社内勉強会（dev_urandom day, Tech Garden..等）
- 社内ブログ
- GitHub
- 技術力評価会
社内における制度や雑談を通じて、個々人や事業部の挑戦と学び（実験）について参照できます。社内のエンジニアは過去すべての実験の情報を検索し、学ぶことができます。
他のプロダクト開発チームから知識を移し、それを足場に新たな挑戦をスタートすることができます。
事業によってフェーズも異なります。20年もののメディア事業もあれば、まだ立ち上げて1年ほどの初期フェーズにあるプロダクトもあります。
事業フェーズが異なれば、プロダクトのサイズ・複雑性もまた異なります。まだPMF(Product Market Fit)が済んでいないサービスもあれば、安定して収益をあげているサービスもあります。
先に実験をし、経験を積んだ事業やチームから、新しいサービスを開発するメンバーに経験が伝達される。こうして開発組織のフルサイクル開発者は、状況判断のための知識を異なるチームから得ることができます。
まとめ: 実行に価値がある
いくら考えても、ある程度まで考えたら、あとはやってみなければわかりません。
考えて、考えて、手を動かせないのでは結局経験も増えず、新たな観察も生まれず、何も進みません。方法はいろいろあれど、ある程度考えたならやってみるしかない。「投資しない」という判断はあり得えますが、「何にも投資しない」という判断はありません。別の機能やコンポーネントを改善したり、事業展開より先回りしてリアーキテクチャする等、なにをすべきかの判断は常になされるべきです。
一番よくないのは、考えて、何もしないことです。
チームで行動していると、他者の振る舞いを見て個人としては「それはうまい打ち手ではないなあ」と思うこともあるでしょう。けれど、やると決めたならやる。やってみれば自分も経験を得て、次の状況判断では次のレベルで見ることが可能になっているでしょう。
決めたらやる。それによって、あなただけではなく、チーム全体が経験を最大化できることにつながります。
