Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

第1章 fluct ― 広告配信の舞台裏の技術者たち

2010年にオンプレで始まったサービスをクラウド移行したり技術的負債を返却していくお話でした。開発チームとしてどう立ち向かったというよりかは一人のスーパーマンが全部解決しちゃいましたみたいな話に見えてあまり再現性は期待できなさそうだと思いました。なんでも挑戦してみる文化みたいに推している部分は逆にガバナンスとかが大丈夫なのかなと不安になるところもありました。アドテクノロジー全体のトレンドへの対応をしていかないといけないという業種特有の動きなども垣間見えて面白かったです。

用語や技術など

Beacon Webサーバーに非同期かつノンブロッキングにデータを送る仕組み。
Apache Hadoop 独自の分散ファイルシステムであるHDFSとその上に格納した大量データに対する処理を実行するためのフレームワーク。
Apache Hive HDFS上のデータに対してSQLに似たクエリによるデータ分析を実行できる仕組み。
InfluxDB 時系列データのためのデータベース
Privacy Sandbox 従来のクロスサイトトラッキングを置き換えるための仕組みでChromiumにある機能。
ITP（Intelligent Tracking Prevention）クロスサイトトラッキングを防ぐためのApple Webkitの組み込みの機能。

ドメイン知識

SSP（Supply Side Platform）広告枠の管理を行う部分。
DSP（Demand Side Platform）広告案件の管理を行う部分。
アドネットワーク複数のメディアおよび複数の広告主と契約することで両者を取り持つ仕組み。
RTB（Real Time Bidding）ユーザーが広告枠のあるウェブサイトを閲覧するたびに、リアルタイムに広告を表示する権利が売買される仕組み。
純広告広告主または代理店が直接メディアの広告枠を買い取って広告を表示させるもの。
CMP（Consent Management Platform）ユーザーがどのような用途で何のデータの扱いに同意したかを管理するもの。
TCF（Transparency & Consent Framework）各広告事業者へのデータ提供を制御する仕組み。

面白いなと思ったこと

2010年に広告配信システムを作るということ S3, EC2のリリースが2006年、GAEのリリースが2008年とまだまだクラウドを活用とすることが一般的でなかった時代。
広告配信の集計方法の変化当初は「サーバーサイドカウント方式」という仕組みで配信した件数ベースで広告の件数をカウントしていたが、クライアント側で実際に表示されていなくても広告が配信されたとカウントされてしまう場合などがあり、正しく集計結果が取得できない。そのため、「クライアント再度カウント方式」という仕組みでクライアント側からビーコンをインプレッションサーバーに投げてそのサーバー上での件数を数えるようになった。
技術的負債は賢くやるだけでなく腕力がないと返済していけない教科書的にいえば技術的負債をきちんと管理して計画的に返済していきましょうということになると思うが、負債が膨らんでしまうとがっとソースコードを書き換えていく腕力がないと返済していけない。本書を読む限りだとfluctの開発チームはバックログに対して個別でアサインされて開発を進めていくような開発手法に見えるのでこのアプローチができるかもしれないが、スクラムで開発している場合に技術的負債の解消をどう盛り込んでいくかは難しい気もする。

参考にできそうだなと思ったこと

カルチャー、開発文化今の会社だと特段開発文化というものがなく開発者としてあるべき指針などがないかもしれない。もちろんボトムアップ的に文化が形成されているが、トップダウン的にこれがあるべき姿などは決まっていない。

第2章 Zucks ― フルサイクル開発者の文化

アドネットワークとDSP事業を手掛けるZucksの文化にフォーカスした内容となっている。他の章とは違い技術的な話などはほとんどない。エンジニアだけで2, 30人ほどの規模ながらドキュメントの文化がなかったり、CTOはいるがエンジニア組織に階層構造がなかったりと不安になるところはあるが、それでも組織が回っている文化などが面白いと思いました。用語としては出ませんでしたが、ティール組織とかが近い気がします。VOYAGE GROUPとして独立した事業は子会社として切り出すのでエンジニア組織の数もある程度サイズの上限があるのと、全員がある程度スキルセットがしっかりしたエンジニアだから成り立っているのかなと思いました。これが50人以上のエンジニア組織だったりするとまた話は変わってくるかなと思います。

用語や技術など

Gauche Schemaの処理系の1つ。

ドメイン知識

面白いなと思ったこと

常に新しいものを学ぶ機会を作って、そういう力をチームとして伸ばしている会社として特定の技術に特化してしまうと新しい技術への挑戦のハードルが上がってしまうのがリスク。そのため理由があれば積極的に新しい技術を採用している。さすがに人数規模のわりに採用している技術の数が多いのはどうなんだろうとは思いつつ方針自体は賛成です。特に言及されていないですが、アーキテクチャとして複数技術を採択できるようになっているのもいいです。
管理画面そのものが一種の業務マニュアルになっているかもしれないこれはプロダクトがある程度完成しているとそうかもしれない。先にプロダクトを触ってみることでひと通りのドメイン知識が身につくと思う。現職では、まだ目に見えるプロダクトができていないが開発は進んでいる段階で入ったので結構ドメイン知識やプロダクトについてのキャッチアップが難しかった。
システムそのものがドキュメント管理画面のUIに丁寧に使い方などのドキュメントが書かれているみたい、社内向けのシステムだからできる荒業だが結構面白いアプローチだと思いました。プロダクトとドキュメントの距離をいかに近づけるかというところでいくとゼロ距離のアプローチです。

参考にできそうだなと思ったこと

新しくジョインしたら初日にリリースする機能ができるたびにデプロイができているということなのですごいです。その上で一連の流れをオンボーディングでできるのは入る側としても初日から外観がわかるので良いと思います。
重要なのは切り戻しできるかどうか破壊的変更をなるべく避けることにより、何かあっても安全に切り戻しできるようにしている。

第3章 VOYAGE MARKETING ― 20年級大規模レガシーシステムとの戦い

VOYAGE MARKETINGでの20年もののレガシーシステムの技術的負債を解消した話。技術的負債を開発者だけで解決するのではなく、必要であれば事業ごと見直したりと事業部も巻き込んで進めていくのはすごいの一言。技術的にどう不要なソースコードを減らすかというところも工夫が随所にあって面白かったです。

用語や技術など

AWS Direct Connect オンプレなどの内部ネットワークとAWSを専用のネットワークで接続するサービス。
Gatling 負荷試験ツール。
インデックスリビルド挿入、削除が繰り返されることで物理的なメモリと論理的な順番がバラバラになるインデックスの断片化が起こり、それを解消する目的でインデックスを再構築すること。
パーティショニングデータベース上の大きなテーブルやインデックスを物理的には複数の領域に分割して管理する仕組み。分け方は色々ある。
動的解析プログラムを実行して欠陥などをチェックする。Valgrindとかも動的解析ツール。
OPCache PHPアクセラレータ機能を提供するもの。PHPアクセラレータとは、バイトコードを共有メモリにキャッシュすることでPHPの処理を高速にする方法である。
PHPStan PHPの静的解析ツール。
git-fo-theseus Gitの履歴を解析してビジュアライズするツール。

ドメイン知識

面白いなと思ったこと

5年後にも数十万のユーザーに安定的に使ってもらっている状況は十分にイメージできたさらっと流されているが、何気にかなり大事なことだと思う。技術的負債に取り組む前にその取り組みを行うことで事業のプラスになるかをしっかり検討している。
インフラはオンプレで全社管轄、アプリケーションは事業部管轄という2000年代くらいまで見られた役割分担を行っていました。 devとopsが分かれていた時代。
価格比較サイトのつくりは複雑になりがちなんですよね。。あまりピンとこないが、そうなんだーという感想。
ライセンスをダウングレードしてクラウド上に移行するオンプレでOracleをEnterpriseライセンスで使用していたが、AWSに移行する際にコスト面がネックになった。ライセンスをダウングレードすることでコスト面の負担を減らすというアプローチは面白かった。
テストがなくても使われていなければ削除しても問題ないどのソースコードが呼ばれていてどれが使用されていないかを目視で判断するのは困難。PHPなどの動的プログラミング言語を使用しているので、動的解析ツール、プログラムキャッシュ、モジュールロードのログ、アクセスログなどを見ることでソースコードが使用されているかどうかが分かる。また事業特性をちゃんと考慮していて1ヶ月あればバッチ処理を含めてほとんど全ての処理が呼ばれる。
事業を葬る - 地道だけど確実に良くなるそもそもプロダクトが複雑になる要因は単純な技術的な話だけでなくビジネス要件によるものが大きく、そちらにちゃんと向き合うのはすごい。
業界では、式年遷宮と呼ばれる手法ですねサブシステムの機能を順番に作り直してモダン化しつつシステム全体を延命するやり方。運用フェーズになるとなかなか新規に作るという機会は少ないがその機会を作り出すという意味でも良いと思った。
いわば「1200を450にする」ためのスキル経営だと事業再生やターンアラウンドという事業フェーズの専門領域があるように、開発においても0から1、1から10だけでなくシステムを再生する領域があるという話が面白かった。

参考にできそうだなと思ったこと

DOT言語に変換してGraphvizで画像出力今回のケースでは役に立っていなかったが、ビジュアライゼーションするのには一旦DOT言語に変換してGraphvizでレンダリングするのは良さそう。PlantUMLとかも似た感じの構成。

第4章 VOYAGE Lighthouse Studio ― 数十万記事のメディアをゼロから立ち上げる

VOYAGE Lighthouse Studioがゲーム攻略サイトの後発として、「神ゲー攻略」を立ち上げて数十万記事を有する規模まで成長させた話でした。技術的にはすごい面白い要素は少なかったですが、後発としてニッチ戦略を取るだったり、不確定な要素があるうちはツーウェイドアの選択を意識して後戻りが聞くようにするプロダクトの成長のさせかたは面白かったです。

用語や技術など

Disqus コメント欄を設置するためのサービス。他にも色々できそう。本例のように静的サイトだとコメントのやり取りができないため、導入されることが多そう。
L7スイッチいわゆるロードバランサー。OSI参照モデルのL7であるアプリケーション層でのスイッチであるため。L4（トランスポート層）ではL4スイッチ。

ドメイン知識

面白いなと思ったこと

Markdownエディタ開発 Markdownには標準のシンタックスがなくて、多くのエディタでGFA（Github Flavored Markdown）っぽいシンタックスを採用している。そのためエディタ上での表示と実際にプロダクトでの見た目の差異が発生していた。Markdownエディタを自作することでプロダクトでの見た目を確認しながら開発できるようになったことに加えて、独自の拡張記法を導入しやくなった。

参考にできそうだなと思ったこと

システムがもたらす制約やコストを極力減らすことシステムがもたらすコストは短期的な視点で見ると小さく見えることであっても長期的にプロダクトを運営することを考えると無視できなくなる。たとえば、毎週1時間掛かる作業も1ヶ月で見ると4時間だが、5年くらいの長期でみると250時間（10日程度）になる。そういったことが積み重なると身動きが取りづらくなり組織としても硬直化してしまう。組織全体としてトイル的な作業の割合をトラッキングしてシステムとして一定水準以下に留めるようにするなどで取り入れることができそう。

第5章サポーターズ ― 事業の成長を止めない手段としてのシステム刷新

サポーターズにおいて、当初受託開発で作られて運用でしのいできたシステムをシステムを刷新した話でした。他の章でも技術負債での戦いが述べられていましたが、サポーターズは事業特性もありシステムを丸ごと刷新するハードルが他に比べて低かったため比較的楽に刷新できた印象です。

用語や技術など

ドメイン知識

面白いなと思ったこと

部屋のドアノブを回すと風呂の底が抜ける表現が面白い。
新規利用者だけが使用する新しいシステムをMVPの状態でリリースしたサポーターズが扱う商材は、就活という「季節もの」の商材なので、1年ごとに利用者が大きく変わる。この特性を生かして20卒の学生には既存のサービスを利用してもらって21卒のユーザーには新規サービスを利用してもらうという選択肢が取れた。
就活支援サービスは、気をつけないと採用する企業側の立場が強くなってしまう BtoBtoCのサービスだと結構あるあるな気がする。実際にお金を払うのは企業なためエンドユーザーに対する価値ということが軽視されがちで企業側の要望が先行してしまう。

参考にできそうだなと思ったこと

実装から距離をとってテストを書くことで独立性を保つ APIを外部から叩いたときの挙動を規定するテストをあえて実装とは別の言語で書くようにすることで、実装の詳細に依存したテストを書けないようにする。
ガーデニング依存ライブラリは週1でバージョンアップしていて、この作業を社内的にガーデニングと呼んでいる。一人に負担が集中しないためにガーデニングガチャという仕組みで毎週の担当者を決めている。

第6章データサイエンス ― エンジニアによるビジネスのための機械学習

Zucksにデータサイエンスを取り組んでいく話。既存のビジネスがある中でどうデータサイエンスを取り入れていくかというのが面白かった。またRTBの文脈では推論に使える時間の制約があり、それが推論モデルや推論処理のアーキテクチャの決定に強く影響を与えているのが面白かった。

用語や技術など

Amazon EMR(Elastic MapReduce)
Amazon SQS(Simple Queue Service)
ロジスティクスシグモイド関数

ドメイン知識

ファーストプライスオークション(1st price sealed-bid Auction) 一番高い入札をした入札者が勝者となり、その入札額を支払う方式のオークション。
セカンドプライスオークション(2nd price sealed-bid Auction) 一番高い入札をした入札者が勝者となるが、支払う入札額は次点の入札額である方式のオークション。対戦略性を持つ。対戦略性とは自分の真の評価値以外の値を入札をしても絶対に得をしない、ということ。

面白いなと思ったこと

データサイエンスの力を活かすためにはまずデータを扱えるように整備をする必要がある
ビジネスモデル自体を変えた元々は手数料を貰うというモデルだったが入札額を最適化することと利益相反が起きてしまうため、お金の貰い方を変える提案を行った。
推論速度が重要 RTBにおける推論には100マイクロ秒ほどしか掛けることができないので、予測の正確性と速度がトレードオフになる。複雑なモデルだと正確性は上がるかもしれないが、現実的な推論速度にならないのでシンプルなモデルが広告のRTBという文脈では適している。
アドサーバーと推論処理は同一プロセスで実行させる切り離した方がメンテナンス性はあがるが、プロセス間通信が発生しそのレイテンシにより推論に使える時間が減ってしまうので現状は同一プロセスで実行している。
自分たちの予測モデルの存在が将来の予測を陳腐化させてしまう予測モデルによる意思決定が未来に影響を与える。つまり、これまでのデータに基づいた予測モデルによってそれ以降集まるデータの傾向が大きく変わってしまう場合がある。機械学習の文脈での技術的負債の1つ。

参考にできそうだなと思ったこと

個人の強みを対外的に分かる形でアウトプットしていたおかげで白羽の矢が立った。社内で誰がどんなスキルセットを持っているかが可視化できると新しいことをやる際に適切な人材配置ができそう。また自身としても興味がある分野は対外的に発信していくのが良い。

いろんなフェーズやいろんな業態のプロダクトについての開発現場の事例がインタビュー形式で載っていて面白かったです。それぞれの事業が始まったときの技術や2020年時点での技術トレンドなどが分かるのも良いです。アドテクやtoCの事例が多く個人的に馴染みの薄い業界の話でドメイン知識としても初めて知ることが多かったです。

hayashi-ay / booklist