日記はScrapboxに移動しました。

フルサイクルエンジニアリングのすすめ:『事業をエンジニアリングする技術者たち―フルサイクル開発者がつくるCARTAの現場』

本書カバー(画像は版元のWebページより)

事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場』(版元のWebページ)をいただきました。ありがとうございます。本記事では、副題となっている「フルサイクル」という言葉に着目して、本書について簡単に紹介します。

本書の位置付け

本書は、2020年に刊行された『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』の「改題改訂版」として刊行されたものです。

まず「改訂」の方から。前著の刊行から2年が経過し、「事業」運営母体も大きく変わりました。それを受けて、各章の最後にこの2年のアップデートが付記され、さらには新規事業と経営基盤システムの統合を扱う2章分が追加されました。

「改題」の方はというと、サブタイトルが新たに追加されています。前述の運営母体の変更による内容とともに、「フルサイクル開発者」という言葉が明記されていることに、一瞥して気づかれることでしょう。

フルサイクル開発者とは何か?

「フルサイクル開発者」という言葉は、前著においても幾度も言及されていました。今回の「改題改訂版」では副題にまで取り上げられていることもあり、本書のコンセプトをひとことで示す重要な概念としての位置付けに格上げされたようです。

そのフルサイクル開発者について、本書では以下のように解説されています。

「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。

(中略)

ビジネスの一番最初から運用して観測するというフィードバックサイクルを回せるのが「フルサイクル」のイメージ(後略)。

本書p.61

元々はNetflixのブログから取り入れた概念であったそうです。「Netflixにおけるフルサイクル開発者―開発したものが運用する – CARTA TECH BLOG」として訳出されています。この記事では、フルサイクル開発者とは「ソフトウェア開発ライフサイクル」を通じた職務を持つエンジニアであり、以下の役割が期待されています。

フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する。開発者の視点で問題を評価し、「このシステムを動かすために必要なものをどう自動化できるか?」「どのようなセルフサービスツールがあればパートナーが開発者の手を借りずに自分の疑問に答えることができるだろうか」と問う。人間中心よりもシステム中心に考え、手動で行われていたものを自動化することによって、チームはスケールする。

Netflixにおけるフルサイクル開発者―開発したものが運用する – CARTA TECH BLOG

ここでいわれるような「ライフサイクルのあらゆる分野」にエンジニアリングを適用し、問題解決できる人々のことを「フルサイクル開発者」と呼ぶのでしょう。

ソフトウェアエンジニアリングの対象

ところで、本書が主題とするソフトウェアエンジニアリングについて、『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』では、以下のように述べてます。

本書が共有する重要な見識に、ソフトウェアエンジニアリングとは「時間で積分したプログラミング」とみなせる、というものがある。自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクルを通じて持続可能(sustainable)なものとするためにコードに導入できるのは、どんなプラクティスだろうか。

本書では、コードを設計し、コードのアーキテクチャーを定め、コードを書いていく際に、ソフトウェア組織が留意すべきと我々が感じる 3 つの根本的原則に重点が置かれている。

時間と変化

コードがその存続期間にわたりどのように適応していかなければならないか

スケールと発展

進化するにつれて組織がどのように適応していかなければならないか

トレードオフとコスト

「時間と変化」、「スケールと発展」から得られる教訓に基づき、組織がどのように決定を行うべきか

『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』p.x

ここでは「サイクル」という言葉の含意がより広く捉えられているように思われます。すなわち、「自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクル」とはつまり、開発サイクルを超えた「事業ライフサイクル」というべきより広い概念ですし、サイクルに応じた組織のスケールについても言及されています。

「フルサイクル開発者」という言葉の可能性をより広げるためには、その「サイクル」の円周をさらに広げて、「事業ライフサイクル」として捉えると良いのではないでしょうか。事実、本書における「サイクル」とは、最近ローンチされた新規事業から、長いものでは20年に及ぶ事業まで様々な来歴を持つプロダクトという時間的スケールにおいて語られているのであり、それは日々の活動としての開発サイクルを包含した、よりスケールの大きな営みの連鎖の謂なのですから。

このようにソフトウェアエンジニアリングの定義とその対象を捉え直した時、本書が広告配信、EC関連サービス、メディア、人材採用等の、一見すると取り止めもなく思えるほどの幅広いサービスにわたり、それぞれの事業を支えてきたエンジニアたちの奮闘ぶりを余すところなく伝えてくれることの、本当のありがたみがわかるというものでしょう。

ソフトウェアエンジニアリングの3軸

本書における語り手たちが勤務するCARTA HOLDINGSと前身であるVOYAGE GROUPは、長きにわたって「技術力評価会」を運営してきたことで有名です。それがどのようなものであったかは、同社をCTOとして率いてきた元CTOの小賀さんによる「5分でわかる技術力評価会」をご覧ください。

ところで、筆者が取締役CTOとして勤めているGMOペパボ株式会社においても、長い間エンジニア評価制度というものを運用してきました。元々はエンジニアのための制度だったのですが、数年前から同じ枠組みを全職種に展開するに至り、全社的な制度として運用しています。そこでは、「能力」(エンジニアであれば技術力といわれるようなこと)を、以下の3軸によって定義しています。

GMOペパボ会社紹介資料」p.28より

「フルスタックエンジニア」という言葉が広く用いられるようになって久しいようです。「フルスタック」という時の水準に対する認識次第では、もちろん望ましいエンジニア像です。一方で、スタックの深さというのは、それ自体ではこれまで述べてきたソフトウェアエンジニアリングという観点からは、複数ある軸のひとつであるという位置付けになるでしょう。すなわち、いかに時間の経過(ライフサイクル!)をその対象とし得るのかという問題です。また、上図では「影響を広げる力」として、他者に対するインパクトもまた重視しています。

フルサイクルエンジニアリングの担い手たちへ

本書のいう「フルサイクル開発者」とはすなわち、ここでいう「作り上げる力」のみならず、「先を見通す力」によって「時間で積分した」(前掲書)価値を実現し、「影響を広げる力」によって事業全体を通じて影響力を行使するような気概を持つエンジニアのことをいうのではないでしょうか。そして、実際に本書に登場するのは、きれいごとばかりではない事業運営の中で、時には「つらい」と落ち込んだり、かと思えば「アンガー駆動」で勢いづいたりする、等身大のエンジニアたちです。その奮闘ぶりは、読者を心底から勇気づけてくれるでしょう。

また、前述のNetflixによる記事(の翻訳)にあるように「フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する」のであり、また、ソフトウェアエンジニアリングの対象が、「時間と変化」「スケールと発展」という必然に向き合うべき組織もライフサイクルにおける重要なファクターなのであれば、マネジメントという営みもまた、フルサイクルエンジニアリングの射程に入ってくるでしょう。そのあたりについては『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』がいまや古典の風格をもって語るところです。

また、そのような意味で捉えたとき、エンジニアリングとは何も職種としてのエンジニアのみが担うべきことではもはやありません。本書の帯に再録された@tokorotenさんのツイートにある通り「アフターDXの働き方がここにある。非エンジニア必見(中略)企業のDX担当者には必携の一冊」であり、いまや誰もがフルサイクルエンジニアリングの担い手である自覚を持ってことにあたるべきであるということになるのではないでしょうか。

そのような人々に向けて、本書は改題改訂版としてあらためて我々の前に再登場してきたのでしょう。フルサイクルエンジニアリングを担うすべての人々に、ご一読されることをおすすめします。

Leave a Reply

Your email address will not be published.