「事業をエンジニアリングする技術者たち（1章）」 の読書メモ

本の概要はこちらから

https://amzn.asia/d/iWgILdz

この本に期待していたこと

具体的な事例を通して、事業にインパクトを与えるようなエンジニアリングのカルチャーや手法を学んで真似したい。
事業をエンジニアリングするとはどういう意味か、フルサイクル開発者とはどんなエンジニアか、のヒントを得たい。

「第１章 fluct 広告配信の舞台裏の技術者たち」より

2010年頃、広告配信システムのうち、SSP（Supply Side Platform）と呼ばれるWEB広告の掲載側で利用される仕組みを提供するサービスの開発のお話。

開発スタイルの変化

最初はWBSを基準に機能をすべて埋めてローンチした。進め方は2週間に1回リリースする小さなウォーターフォールのような方式だった。
手動のデプロイだったものからMakefileで半自動化、その後Jenkinsを導入し、デプロイ頻度があがっていった。

とりあえず使ってみる文化

makeやJenkinsなどの導入は上が決めたことではなく、「とりあえず使ってみて」うまく行った結果、徐々に活用する人が増えていった。
データ処理に使用していたのはオンプレのHadoopだったが、これもAmazon ERMやGoogle BigQueryを試しに使ってみて、処理の早かったBigQueryへ移行していった。

• MEMO：検討するよりも、試してみる方が早い。自分の経験にもなる。

DevOps

インフラを見ていたSER部門を、開発本部と統合した。DevとOpsが分かれているのが悪というわけではなく、同じ目的を共有するチームの間で「依頼」が発生するのが本意ではなかった。開発でインフラを自然と使えたり、ペアで一緒にインフラを作れた方がよいと考えた。

• MEMO：DevOpsはフルサイクル開発者への一歩

SRE（Site/Service Reliability Engineering サイト/サービス信頼性エンジニアリング）に対する考え方

障害に対する恐れが大きくなると、デプロイが怖くなる。デプロイを減らすと、さらに恐怖が増して事業の成長スピードが落ちる。細かく早くリリースし、それに適応して経験を積むことで、チームもプロダクトも成長できる。

オブザーバビリティ

問題が起きた時、それに気づけるようにしないとデプロイが不安になる。デプロイ頻度を上げるだけでなく、問題にいち早く気づけないと意味がない。
サーバー側のメトリクスだけでなく、アプリケーションに関するメトリクスも取得する。
また、障害が起きたときは「このメトリクスが取れていればよかったのでは？」と振り返る（ポストモーテム：検死）

技術的負債との戦い

リリースから時間が経ち、システムの複雑性が増していった。システムのどこを変えると何が起きるのか、だんだん見えなくなっていった。それに伴い、既存システムに対する影響範囲を調査する時間が増えていった。もっと読みやすく、早くしやすく、書きやすいコードに変えていく必要がでてきた。

リファクタリング類語

リファクタリングは、ソフトウェア自体の挙動を変えずに、理解・修正しやすいよう内部構造を変化させること。
リアーキテクティングは、リファクタリングの一種だが、リファクタリングよりもスコープが広く、サービス全体の構造改善やモジュールの責務整理などを指す。
リプレースは挙動も含め、ソフトウェアそのもの全体を書き換える行為。

実際のリファクタリング

IDEや静的解析ツールによるコード探索がしやすくなるよう、PHPのrequire_onceを撤廃してuseにしたり、PSR-4準拠のレイアウトに変更した。
HTML + jQueryだったフロントをReact + JSONによる画面に書き換えた。
長らくメンテナンスされていないOSSの使用をやめ、テストしやすいライブラリやミドルウェアに変更した。

リファクタする腕力

「時間が無限にあればやりたいが、今は緊急の対応を進めないといけないからできない、暫定的な実装」を繰り返さない、許さない。まずは例外処理の統一化から手をつけた。重要だけど緊急ではないから誰も手をつけないところ、をゴリゴリ巻き取っていく力、放置しない力が必要。また、何か技術的負債の返済ができそうな時に、それをやってもいい！と思える環境もあると良い。

• MEMO:プロダクトの成長スピードを鈍化させないためにも、クリーンなコードを保つ必要があるのでは

感想

まだ一章しか読んでいないのに、なんて中身の濃いインタビュー本なんだろう。事業やチームのために必要なことは重要なことだ。面倒なことでも放置せずに取り組もう。