「事業をエンジニアリングする技術者たち」の脚注記事がオススメばかりなので紹介したい

# はじめに

最近こちらの本を読みました。

https://www.lambdanote.com/collections/frontpage/products/carta

改訂改題前の「Engineers in VOYAGE」から厚みを増した本作。既存の各章ごとに「その後」が追加されたり、新しい章も加筆されるなど大幅な改訂になっています。前作は「ITエンジニア本大賞2021年」の「技術書部門大賞」を受賞した作品ですので、ご存じの方も多いと思います。

私も改訂版を改めて手に取らせてもらい、前作部分も含めて再読しました。自身の環境変化の影響か、今だからこそ刺さる部分もありました。世間の評価に違わず、エンジニアのみならずソフトウェアに関連する事業に関わる方に、広くお薦めしたい一冊であることは間違いありません。

さて、私が思うこの書籍の魅力は、その解説記事と丁寧な脚注にあると言っても過言ではありません。その解説により、生々しいインタビューの事象が抽象化され、読者が自身の環境に適用しやすくなっています。

今回本書を読むにあたり、脚注記事もそれぞれ注意深く参照してみましたが、いづれも本書の主張を支える示唆深いものでした。
そこで、この記事では脚注で引用されている記事の中から、おすすめなものをテーマごとに大別しご紹介できたらと思います。
これらの記事を読むだけでも、「事業をエンジニアリングする技術者」になるために必要な「何か」が感じ取っていただけるかもしれません。

# 本書で脚注引参照されているおすすめ記事たち

それでは以下のカテゴリに分類して紹介します。

1. 基本思想
1. 対レガシー戦略
1. 事業をエンジニアリングする組織やエンジニアの在り方
1. その他Tool&Tips

## 1. 基本思想

### » Why Software Is Eating the World | Andreessen Horowitz

https://a16z.com/2011/08/20/why-software-is-eating-the-world/

:::note info
2011年にMarc Andreessenによってウォールストリートジャーナルで発表されたこの記事は、まさにDX時代への突入を宣言するもので、事業成長を考える上でテクノロジーの地位と優先度を高めるべきだという警鐘でした。10年経った今でも十分にその内容は色あせません（Skypeの記述はちょっと悲しいものがありますが）。公共組織や事業のリーダーは、テクノロジーの価値を正しく理解し、優先順位付けと対応を最適化していくことが求められることは間違いありません。
:::

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

https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325

:::note info
本作中に登場する「フルサイクル開発」のイメージが非常によく伝わる記事。フルスタックを目指すのではなく、スペシャリストが用意した専門ツールを活用してフルサイクルであろうという姿勢は、開発組織の在り方として大変参考になります。
:::

### » 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ

https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor 

:::note info
技術的負債に対する誤解を解いた記事。本来なされるべき雑な設計や実装を許容または揶揄するための比喩ではなく、当初知り得なかった知識前提がないことで生まれた現実装とその時点で最適と思える最適な機能や設計とのギャップを継続的に埋め続ける必要性を説くためのメタファーだったというイメージでしょうか。リファクタリングの重要性という意味では近いですが、それは決して実装レイヤーでのスキル考慮不足を補うという類とは一線を画す意味があったと受け止めています。
:::

## 2. 対レガシー戦略（具体事例）

### » 「AWSへのマイグレーションのその先に ～リフト＆シフトからのクラウド最適化～」でのfluct事例発表

<script async class="speakerdeck-embed" data-id="35b6eea8785a4b61bf6770fe2e1b991e" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

:::note info
本書1章で紹介されている事例の後続を示した発表資料。今とは違い2010年代中間当時はまだAWSに完全に振り切ってよいかどうかはまだ悩ましい判断もあったと思います。そうした苦悩が読み取れる資料でした。正解が分からない中で何らかの答えを出す、そうした経験を誰しも味わうということを気付ける資料です。
:::

### » 広告配信を支えるバッチ基盤をサーバーレス移行した話（ECS Fargate, Step Functions）@ Serverless Meetup Tokyo #16 - Speaker Deck

<script async class="speakerdeck-embed" data-id="469352f78602486dbee2fd4608893304" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>

:::note info
新しい挑戦の足跡を丁寧に記述してくれている資料です。悲観的に様々なことを考慮しつつも、課題に対して楽観的に向き合う姿勢は見習うべきものがあります。
:::

### » デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。 - CARTA TECH BLOG 

https://techblog.cartaholdings.co.jp/entry/2019/02/19/182539 

:::note info
結論として挙げられている「現状把握から始める」「いま取り組むことを絞る」「建設的先送り」など過去エンタープライズシステムのダウンサイジングでも大前提とされていた考え方と全く一致しました。ビックバンという誘惑に駆られることが多いですが、何かを移行するのに銀の弾丸なしということかと思います。
:::

### » 動的解析を利用し、実働6日でレガシーコードを1/3削った話(Perl編) - CARTA TECH BLOG 

https://techblog.cartaholdings.co.jp/entry/2020/05/07/120000 

:::note info
実行モジュールを洗い出す処理を自作して不要なファイルを特定していった流れが紹介されています。対象の分母を減らすのは問題解決の王道。参考になります。
:::

### » 運用、追加開発しづらいPHPアプリケーションに未来を与える方法 - Speaker Deck 

<script async class="speakerdeck-embed" data-id="3fadb19ed167490c9a17e9506f34a727" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>

:::note info
APMが開発環境改善に大きな意味を持つことは改めて気付きがありました。ブリッジ用のルートを先に整備をすることはレガシー移行では非常に汎用的な手法と言えそうで参考になる方も多いのではないでしょうか？
:::

### » ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話 - CARTA TECH BLOG 

https://techblog.cartaholdings.co.jp/entry/replacement-of-kamigame-system-from-ssg-to-ssr-with-lit-html 

:::note info
大規模メディアにおける性能とSEOを踏まえたアーキテクチャ検討の流れが参考になります。「リプレイス戦略——いきなり移行はせず、新配信システムを、独立したサブシステムとして稼働させる」という並行作戦が移行の王道ですね。
:::

## 3. 事業をエンジニアリングする組織やエンジニアの在り方

### » エンジニアがエンジニアの求人を本気出してつくったことを通して、本当に言いたかったこと｜河村 綾祐 (r-kawamura, clonable-eden)｜note

https://note.com/ryosuke_kawamura/n/nb5fc4d34a7c8 

:::note info
読むと熱量が伝わってきますね。なおnote記事内の「求人票」へのリンクが切れていました。現物を是非ご覧頂きたいたので、[こちら](https://hrmos.co/pages/cartaholdings/jobs/zu-e04)を参照ください。
:::

### » The Zen of Zucks - CARTA TECH BLOG

https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks

:::note info
そもそもこの本執筆の背景にも重なるかもしれませんが、目に見えにくいことを言語化しようという企業文化は本当に素晴らしいなと思います。
:::

### » テレビCMの効果測定とは？ - 100万円からはじめられる運用型テレビCMサービス | テレシー(TELECY) | 100万円からはじめられる運用型テレビCMサービス | テレシー(TELECY) 

https://telecy.tv/column/766/ 

:::note info
今回追加された第7章の「テレシー」では、開発する上でのドメイン理解の大切さが表現されています。同じ広告という業界でありながら、WEB広告とTV広告の違いを痛感されたという記述が印象に残ります。
:::

### » サービスデザイン
https://www.meti.go.jp/press/2020/04/20200420002/20200420002.html

:::note info
「一連の顧客体験を望ましいものにするために、”モノ”と”コト”を統合した”サービス”とデザインすることが求められている」として、ビジネスをサービスとして再定義し、より良いサービスを生み出すためのアプローチを解体しようと試みています。職制を超えて参考になるかと思います。
:::

###  » プロジェクトの「ふりかえり」 -- Retrospectives by Norm Kerth：An Agile Way：オルタナティブ・ブログ

https://blogs.itmedia.co.jp/hiranabe/2005/07/__retrospective_7b58.html

:::note info
直接引用されていたのはNoman kerth のグランドルール「この会では、プロジェクトの全員が置かれた状況下でベストを尽くした、ということを疑ってはならない」という表現でした。非常に大切な考え方です。直接この記事が脚注引用されているわけではないのですが、参考までに記載します。
:::

## 4. その他Tool&Tips

### » GitHub - erikbern/git-of-theseus: Analyze how a Git repo grows over time

https://github.com/erikbern/git-of-theseus 

:::note info
Gitリポジトリ内のコード量の変遷を可視化してくれるツールです。ソースコードの「テセウスの船」というパラドックスから由来される命名はなかなか趣深いですね。
:::

### » セマンティック バージョニング 2.0.0 | Semantic Versioning

https://semver.org/lang/ja/ 

:::note info
「バージョンナンバーは、メジャー.マイナー.パッチ」 とする考え方。今多くのバージョニングの基本と言えるので未知の場合は知っておきたい内容です。
:::

# 最後に（受託開発に関わる技術者にこそ読んで欲しい）

特に2022年現在、DX文脈の浸透と共に事業開発とシステム開発の共生のあるべき形に向けた議論は、アジャイル開発や内製化といったテーマの活性化が示す通り、啓蒙レベルからどう実践するかへと確実に議論が進んでいる印象があります。そうした中で、特にレガシーとの向き合い方と「フルサイクル開発者」という在り方の具体例は、決して色あせることなく多くの示唆を与えてくれるものだと思います。

元々取り扱っている企業がインターネット事業者であることもあり、こうした自社サービス企業に勤めている技術者には特に有用であることは間違いありません。ただ「おすすめの読み方」という章でも記載されていますが、受託開発側の企業に従事する技術者にも是非お薦めしたいです。今後企業が求める技術者の取るべきスタンスへの示唆が多く示されているからです。

例えば本作で「その依頼されているモノが相手が本当に欲しいモノではないかもしれない」という前提でヒアリングするところから始める、という部分があります。顧客担当者の言ったことや他者のやった前工程を100%信じるという前提に縛られてしまっていないか注意したいものです。

これらの記事を読んで、興味が湧いた方は是非書籍を手に取ってみてください。

https://www.lambdanote.com/collections/frontpage/products/carta