Closed hayashi-ay closed 1 year ago
アドネットワークとDSP事業を手掛けるZucksの文化にフォーカスした内容となっている。他の章とは違い技術的な話などはほとんどない。エンジニアだけで2, 30人ほどの規模ながらドキュメントの文化がなかったり、CTOはいるがエンジニア組織に階層構造がなかったりと不安になるところはあるが、それでも組織が回っている文化などが面白いと思いました。用語としては出ませんでしたが、ティール組織とかが近い気がします。VOYAGE GROUPとして独立した事業は子会社として切り出すのでエンジニア組織の数もある程度サイズの上限があるのと、全員がある程度スキルセットがしっかりしたエンジニアだから成り立っているのかなと思いました。これが50人以上のエンジニア組織だったりするとまた話は変わってくるかなと思います。
常に新しいものを学ぶ機会を作って、そういう力をチームとして伸ばしている 会社として特定の技術に特化してしまうと新しい技術への挑戦のハードルが上がってしまうのがリスク。そのため理由があれば積極的に新しい技術を採用している。さすがに人数規模のわりに採用している技術の数が多いのはどうなんだろうとは思いつつ方針自体は賛成です。特に言及されていないですが、アーキテクチャとして複数技術を採択できるようになっているのもいいです。
管理画面そのものが一種の業務マニュアルになっているかもしれない これはプロダクトがある程度完成しているとそうかもしれない。先にプロダクトを触ってみることでひと通りのドメイン知識が身につくと思う。現職では、まだ目に見えるプロダクトができていないが開発は進んでいる段階で入ったので結構ドメイン知識やプロダクトについてのキャッチアップが難しかった。
システムそのものがドキュメント 管理画面のUIに丁寧に使い方などのドキュメントが書かれているみたい、社内向けのシステムだからできる荒業だが結構面白いアプローチだと思いました。プロダクトとドキュメントの距離をいかに近づけるかというところでいくとゼロ距離のアプローチです。
新しくジョインしたら初日にリリースする 機能ができるたびにデプロイができているということなのですごいです。その上で一連の流れをオンボーディングでできるのは入る側としても初日から外観がわかるので良いと思います。
重要なのは切り戻しできるかどうか 破壊的変更をなるべく避けることにより、何かあっても安全に切り戻しできるようにしている。
VOYAGE MARKETINGでの20年もののレガシーシステムの技術的負債を解消した話。技術的負債を開発者だけで解決するのではなく、必要であれば事業ごと見直したりと事業部も巻き込んで進めていくのはすごいの一言。技術的にどう不要なソースコードを減らすかというところも工夫が随所にあって面白かったです。
5年後にも数十万のユーザーに安定的に使ってもらっている状況は十分にイメージできた さらっと流されているが、何気にかなり大事なことだと思う。技術的負債に取り組む前にその取り組みを行うことで事業のプラスになるかをしっかり検討している。
インフラはオンプレで全社管轄、アプリケーションは事業部管轄という2000年代くらいまで見られた役割分担を行っていました。 devとopsが分かれていた時代。
価格比較サイトのつくりは複雑になりがちなんですよね。。 あまりピンとこないが、そうなんだーという感想。
ライセンスをダウングレードしてクラウド上に移行する オンプレでOracleをEnterpriseライセンスで使用していたが、AWSに移行する際にコスト面がネックになった。ライセンスをダウングレードすることでコスト面の負担を減らすというアプローチは面白かった。
テストがなくても使われていなければ削除しても問題ない どのソースコードが呼ばれていてどれが使用されていないかを目視で判断するのは困難。PHPなどの動的プログラミング言語を使用しているので、動的解析ツール、プログラムキャッシュ、モジュールロードのログ、アクセスログなどを見ることでソースコードが使用されているかどうかが分かる。また事業特性をちゃんと考慮していて1ヶ月あればバッチ処理を含めてほとんど全ての処理が呼ばれる。
事業を葬る - 地道だけど確実に良くなる そもそもプロダクトが複雑になる要因は単純な技術的な話だけでなくビジネス要件によるものが大きく、そちらにちゃんと向き合うのはすごい。
業界では、式年遷宮と呼ばれる手法ですね サブシステムの機能を順番に作り直してモダン化しつつシステム全体を延命するやり方。運用フェーズになるとなかなか新規に作るという機会は少ないがその機会を作り出すという意味でも良いと思った。
いわば「1200を450にする」ためのスキル 経営だと事業再生やターンアラウンドという事業フェーズの専門領域があるように、開発においても0から1、1から10だけでなくシステムを再生する領域があるという話が面白かった。
VOYAGE Lighthouse Studioがゲーム攻略サイトの後発として、「神ゲー攻略」を立ち上げて数十万記事を有する規模まで成長させた話でした。技術的にはすごい面白い要素は少なかったですが、後発としてニッチ戦略を取るだったり、不確定な要素があるうちはツーウェイドアの選択を意識して後戻りが聞くようにするプロダクトの成長のさせかたは面白かったです。
サポーターズにおいて、当初受託開発で作られて運用でしのいできたシステムをシステムを刷新した話でした。他の章でも技術負債での戦いが述べられていましたが、サポーターズは事業特性もありシステムを丸ごと刷新するハードルが他に比べて低かったため比較的楽に刷新できた印象です。
部屋のドアノブを回すと風呂の底が抜ける 表現が面白い。
新規利用者だけが使用する新しいシステムをMVPの状態でリリースした サポーターズが扱う商材は、就活という「季節もの」の商材なので、1年ごとに利用者が大きく変わる。この特性を生かして20卒の学生には既存のサービスを利用してもらって21卒のユーザーには新規サービスを利用してもらうという選択肢が取れた。
就活支援サービスは、気をつけないと採用する企業側の立場が強くなってしまう BtoBtoCのサービスだと結構あるあるな気がする。実際にお金を払うのは企業なためエンドユーザーに対する価値ということが軽視されがちで企業側の要望が先行してしまう。
実装から距離をとってテストを書くことで独立性を保つ APIを外部から叩いたときの挙動を規定するテストをあえて実装とは別の言語で書くようにすることで、実装の詳細に依存したテストを書けないようにする。
ガーデニング 依存ライブラリは週1でバージョンアップしていて、この作業を社内的にガーデニングと呼んでいる。一人に負担が集中しないためにガーデニングガチャという仕組みで毎週の担当者を決めている。
Zucksにデータサイエンスを取り組んでいく話。既存のビジネスがある中でどうデータサイエンスを取り入れていくかというのが面白かった。またRTBの文脈では推論に使える時間の制約があり、それが推論モデルや推論処理のアーキテクチャの決定に強く影響を与えているのが面白かった。
ファーストプライスオークション(1st price sealed-bid Auction) 一番高い入札をした入札者が勝者となり、その入札額を支払う方式のオークション。
セカンドプライスオークション(2nd price sealed-bid Auction) 一番高い入札をした入札者が勝者となるが、支払う入札額は次点の入札額である方式のオークション。対戦略性を持つ。対戦略性とは自分の真の評価値以外の値を入札をしても絶対に得をしない、ということ。
データサイエンスの力を活かすためにはまずデータを扱えるように整備をする必要がある
ビジネスモデル自体を変えた 元々は手数料を貰うというモデルだったが入札額を最適化することと利益相反が起きてしまうため、お金の貰い方を変える提案を行った。
推論速度が重要 RTBにおける推論には100マイクロ秒ほどしか掛けることができないので、予測の正確性と速度がトレードオフになる。複雑なモデルだと正確性は上がるかもしれないが、現実的な推論速度にならないのでシンプルなモデルが広告のRTBという文脈では適している。
アドサーバーと推論処理は同一プロセスで実行させる 切り離した方がメンテナンス性はあがるが、プロセス間通信が発生しそのレイテンシにより推論に使える時間が減ってしまうので現状は同一プロセスで実行している。
自分たちの予測モデルの存在が将来の予測を陳腐化させてしまう 予測モデルによる意思決定が未来に影響を与える。つまり、これまでのデータに基づいた予測モデルによってそれ以降集まるデータの傾向が大きく変わってしまう場合がある。機械学習の文脈での技術的負債の1つ。
いろんなフェーズやいろんな業態のプロダクトについての開発現場の事例がインタビュー形式で載っていて面白かったです。それぞれの事業が始まったときの技術や2020年時点での技術トレンドなどが分かるのも良いです。アドテクやtoCの事例が多く個人的に馴染みの薄い業界の話でドメイン知識としても初めて知ることが多かったです。
第1章 fluct ― 広告配信の舞台裏の技術者たち
2010年にオンプレで始まったサービスをクラウド移行したり技術的負債を返却していくお話でした。開発チームとしてどう立ち向かったというよりかは一人のスーパーマンが全部解決しちゃいましたみたいな話に見えてあまり再現性は期待できなさそうだと思いました。なんでも挑戦してみる文化みたいに推している部分は逆にガバナンスとかが大丈夫なのかなと不安になるところもありました。アドテクノロジー全体のトレンドへの対応をしていかないといけないという業種特有の動きなども垣間見えて面白かったです。
用語や技術など
ドメイン知識
面白いなと思ったこと
2010年に広告配信システムを作るということ S3, EC2のリリースが2006年、GAEのリリースが2008年とまだまだクラウドを活用とすることが一般的でなかった時代。
広告配信の集計方法の変化 当初は「サーバーサイドカウント方式」という仕組みで配信した件数ベースで広告の件数をカウントしていたが、クライアント側で実際に表示されていなくても広告が配信されたとカウントされてしまう場合などがあり、正しく集計結果が取得できない。そのため、「クライアント再度カウント方式」という仕組みでクライアント側からビーコンをインプレッションサーバーに投げてそのサーバー上での件数を数えるようになった。
技術的負債は賢くやるだけでなく腕力がないと返済していけない 教科書的にいえば技術的負債をきちんと管理して計画的に返済していきましょうということになると思うが、負債が膨らんでしまうとがっとソースコードを書き換えていく腕力がないと返済していけない。本書を読む限りだとfluctの開発チームはバックログに対して個別でアサインされて開発を進めていくような開発手法に見えるのでこのアプローチができるかもしれないが、スクラムで開発している場合に技術的負債の解消をどう盛り込んでいくかは難しい気もする。
参考にできそうだなと思ったこと