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

本の概要はこちらから

https://amzn.asia/d/iWgILdz

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

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

前回の記事

「第2章 フルサイクル開発者の文化」より

広告配信システムのうち、DSP（Demand Side Platform）と呼ばれるWEB広告の出稿側で利用される仕組みを提供するサービスの開発のお話。

フルクラウドでの挑戦

当時（2012年）はクラウドコンピューティングがだいぶ一般的になり、日本でもAWSが大々的に使用されはじめた頃。
クラウドにおける監視の知見がなかった。例えば、オンプレならあらかじめ把握できている監視対象のIPアドレスも、クラウドではインスタンスを捨てて立ち上げるたびに変わるため、Xymon（OSSの監視ツール）の設定ファイルにIPアドレス一覧を取得して更新するなどの対応が必要だった。

なぜオンプレにしなかった？

多少コストがかかっても、スケーラビリティのある環境にしたかった。過去に営業チームが拡大してリクエストが増えてるのに、サーバーの調達が6週間後みたいなことがあった反省から。仮にオンプレを使うとしても、必ずパブリッククラウドとのハイブリットにしたはず。

fluct（SSP）とはビジネスがまったく違うアドネットワーク

SSPとDSPでは似ている部分もあるが、要求のズレがあった。例えば「広告が全然配信できない」という事態はSSPでもアドネットワークでも問題となるが、SSPでは「絶対に許されない」一方、アドネットワークではある程度許容されている。
サービスとして目指すことが違うため、システムとして力点の置き方も違ってくる。

アラート

アラートはSlackチャンネルに自動的にあがってくるので、それを誰かが見て気づいたらGitHubのissueをおこして議論が始める…というのを各人が自発的にやっていた。とりあえず調査して原因を探ってみて対策案を考えてから共有してくれる、くらいまでは勝手に進めてくれていた。
CTOとしては指示しなくても勝手にやってくれるので、助かっていた。

MEMO：担当を決めず「誰かがやる」という状態でも回るくらい、サービスを自分事としてとらえているチームだったのだろう。主体的に動くことで本人の経験にもなっている

Zucksのエンジニア文化を求人票に載せる

自分たちの文化をまずは言葉にするところからはじめた。通常の求人票のような文言に加えて「エンジニア組織について」と「仕事の進め方」を軸に、自社の文化を紹介するつもりで書いた。
CTO自身が求人票を書くという作業を通して、「これがうちのエンジニアなんだよなあ」と改めて感じさせられた。

全員がフルサイクル開発者であること

技術者はコードを書くだけが仕事ではない、と考えている。その意味で、「フルスタック開発者」という言い方はしていない。
「フルスタック」というと、一人でプロダクトやサービスをすべて作れることに主眼が起これると思うが、「フルサイクル」では、全部を作れる必要はない。その代わりビジネス的な要件を整理するところからできる必要がある。

参考：「Netflixにおけるフルサイクル開発者―開発したものが運用する」

MEMO：「ビジネス的な要件」とは具体的に何だろう？担当範囲を超えて、プロジェクトを前に進めるために必要な情報取集・判断を行うことだろうか

使用言語はサブシステムごとにバラバラだった

使用言語を絞らなくても「普段から新しいものにさわってキャッチアップする力をメンバーがつけているから問題ない」状態だった。逆に、技術を絞って全員同一のものを使っている状態だと、必要があって新しい仕組みを導入したときに、チーム全体に受け入れさせるのが大変になってしまう。
だから、常に新しいものを学ぶ機会を作って、キャッチアップする力をチームとして伸ばしている。

ドキュメントがまったく存在しないシステムだった

エンジニアがやらないといけないのは、フルサイクルの流れを回すこと。一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続けるという作業が発生してしまう。それを避けるために、すべてGitHubのissueだけで管理していた。「同じようなことが過去にもあったはず」と思ったら、まずはissueを全文検索する癖が全員についている。
また、みんなが「ドキュメントは更新されていない」という前提で動いている文化がある。ある時点で何かを整理した記録はあるかもしれないけど、あくまでも動いているものが正義 = 「動いているものが読みやすいコードである」前提。

MEMO：更新されていないドキュメント…耳が痛い。ベストプラクティスは組織によるだろうが、コード自体を読みやすくして一部ドキュメントの役割を持たせることは心掛けたい

はっきりした担当範囲がなく、全員である程度全体を把握していた

ドキュメントがないという事実を全員が認識していたため、「自分しか分からないことを作らない」ようみんなが動いていた。ドキュメントがないと大変な場合もあるけど、その緊張感によってシステム全体に対する全員の理解が進んでいた面もあった。

新入社員にはまず管理画面をさわってもらう

管理画面が最初に手をつけてもらう部分として、一番わかりやすい。管理画面にはフォームがあり、そこで何かしらの項目を登録する。それが何のための項目かわからないと登録もできないので、そこがシステムの全体像を掘っていくスタート地点になる。

MEMO：「管理画面から触ってもらう」はすぐに真似できそうなプラクティス

チームの文化はスケールできるのか

「互いに補い合いつつすべてがうまく回る文化」という仕組みを作り上げてきた。できるだけこの思想でやっていこうとしているが、スケールするたびに「そろそろ限界かな…」と感じることもある。でも変えてしまうとなかなか戻せないだろうから、いま動けている状態を大事にしている。
「個々のメンバーができることを増やすことでチームを強くしたい」、それに共感して自分が強くなれるメンバーを増やしたい。そのためにあのような求人票を書いた。

感想

二章では、チームとしてどうプロセスを回していくか、そのために必要な文化とは何か、そして文化を保ったままチームをスケールする挑戦について描かれていた。
多くの企業でミッション・ビジョン・バリューなどが公表されているが、チームとしての文化もまた、自分たちの言葉で再解釈し解像度をあげることで恒常性を持たせられるのかもしれない。