はじめにlink
事業をエンジニアリングする技術者たちの献本をいただいた。自分の感じたことを書評として残しておく。
書籍の概要link
VOYAGE GROUPのグループ会社それぞれの仕事内容、チームの特徴、技術スタックやプロジェクトの進め方、考え方などが章ごとにまとめられている。
2020年に発行された「Engineers in VOYAGE」の改題改訂版。VOYAGE GROUPとサイバー・コミュニケーションズが経営統合しCARTA HOLDINGSに変わったため、題も変更になり内容も追記されている。
それぞれの章に2年たって現状ではどうなったかが追加されている。
各サービスの担当者がインタビュー形式で語っていく内容がまとめられている。
インタビュアーはテストで有名な和田卓人（@t_wada）さん。
技術的なバックグラウンドも豊富で、受け答えや引き出し方にも安定感がある読みやすい書籍。
感想link
幅広い範囲で知らない知識が深堀りされていくので、ざっくりweb関連の知識を広げるのにはよかった
本全体を通して受けた印象としては、少人数で機動的に動ける事を大事にして考えられているように感じた。 各グループ会社も規模的に数十人程度でやっているから、そこでパフォームしやすい構成を取っているのだろうか。
かといって妥協した選択はあまり見られないので、全体的にスタートアップ的な規模にちょうどよい選択がされていると感じた。
1~2章link
ここはいわゆるアドテクの会社の話。
技術的な内容はもちろんだが、ここではフルスタックではなくフルサイクルエンジニアというのが大事にされているという所が一番印象に残った。
アイデアからユーザーに届くまでのサイクルを考えられるのがフルサイクル。 フルスタックでは全部自分でやれるというニュアンスが出てしまうが、得意の濃淡はあってよくて全部自分で作れる必要はないからフルサイクルと呼ぶという話だった。
自分はフルサイクルでやりたくて、その手段としてフルスタックにふるまえる技術（フロントエンド, Node.js,…）を身に着けているんだと認識した。
また、その文脈でDevOpsでチームは分かれていないという話も語られていた。 一つのチームでやれてたほうがいいというのは自分も同意で、作っているものは一緒なのだから作るために「依頼」を発生させるのは本意ではないという所に共感した。
3章link
ECサービスのレガシー脱却プロジェクトの話。
コードや使わない機能を削るって胆力がいるけど、やらないと末端から死んでいくので非常に重要な仕事だと思う。
途中にDBのリレーションを可視化したものが出てくるが、あの規模になるまで1つのDBでも動いてしまったというのは中々すさまじい。 どうしてもスクラップアンドビルドをしたくなってしまいそうな規模だが、リターンも大きいがリスクもかなり巨大なのでビジネスとして本当に行うべきなのかは十分検討しないといけない。
個人としてはエンジニアの立場から見がちなので、エンジニアがレガシーにやる気を失わない程度に作り直していけるかは重要な指標だと考えている。 やり方としてはかなりバランスがいい進め方だなと感じた。
4章link
ゲーム攻略サイトを静的サイトジェネレータで作る話。
個人的に一番領域が近くて理解しやすく面白く読めた。
「可読性 > パフォーマンス」で進めているという表現があったが自分の優先度は逆かもしれない。 競技プログラミング的なコードはさすがに極端だが、パフォーマンス優位に考えてからロジックを決める事が多い。
N+1問題的なのを想像したけどさすがにちょっと極端かも。
Array.filter().map() 的なのがあったらfor分でやったほうがよくない？的な感じ（これはこれでちょっと例が悪い）
静的サイトジェネレーターからSSRに移行しているとさらっと書かれていた。これは最近の傾向から見ると逆の方向に見えるが、自分は割と納得のいく選択に感じた。
少人数で負荷をさばくための静的サイトジェネレータ採用というのは納得感があり、ゲーム攻略サイトは結果整合性でも問題になりにくいからチームと技術の選択が合っている。エンジニアのパワーが増加した今ならSSR系の技術の方が柔軟性があがり機動的に動けるようになったよね、という話と受け取った。
5章link
サポーターズという人事領域サービスの話
社内受託にならない事に気を割いているのが伝わった。自分もここは大切にしているので共感した。
めんどくさいと思われそうだけどただ作るじゃなくて、ユーザーにいいものを届けるのが大事。 だからこの機能が欲しいを受け取るだけじゃなくて、届けたいコアの価値を理解してそれに対するコストを見積もるのはエンジニア側が妥協してはならない役割だと考えている。
実装から距離をとるためにScalaのe2eテストをNode.jsで書いてるという話が出てきて、自分はやったことなかったのでコスパが気になった。 実装言語が変わっても使いまわせるし、とは書いてあったが実際にそれが起きる可能性は低そうだから、強制的に別言語にすることでどちらの領域も理解していじれるようにするという文化の方を大事にしているのかもしれない。
1週ごとにライブラリバージョンアップをしているらしいが中々大変そうだが、一度止まると二度と出来なくなるというのは同意した。 ライブラリバージョンアップをガーデニングと呼び、ガーデニングガチャで毎週担当を決めるという仕組みはよさそうだと思った。
6~7章link
会社は違うがざっくりと機械学習系の話。
データサイエンスの章は分野が違うこともあり正確に理解できていない所はあるが、モデルに大してテストをどう書いたらいいか全然思いつかないのでやるなら発想の転換が求められそう。
広告に対する知識がないと章全体をちゃんと理解するのが難しいかも。オークションの方式とか聞いたことはあったのでなんとか言っていることは理解できたくらい。
Webの方ではモデルの精度よりマイクロ秒レベル返せる速度が必要という話は確かに見極めが難しそう。そういう判断のチューニングが機械学習エンジニアの重要な仕事なんだろう。
推論の速度が重要なので別プロセスに分離するデメリットがでかいからScalaの内部で推論モデルを呼んでると書いてあってなるほどなぁという感じだった。APIに分けるのが正解な箇所ではない。
TVCMの効果測定モデルでは放映時刻から減衰していく残存価値をモデルに組み込むという所が確かにと思ってちょっと深堀りしたい興味がわいた。
8章link
新しく追加された章。経営統合に伴うシステム統合の話。
ここは自分も情シスに所属していたこともあり、全体的に他人事に感じなくて大変だったんだろうなというのが身近に感じた。 社員マスタまわりを触るのは非常に大変というのは身をもって知っていて、数年かかっても終われるんだろうかという印象を最初に持ってしまうレベル。
文化の違う複数の組織を統合するのはシステムそのものが問題になることはあまりなくて、文化からくる考え方の違いによるシステムの使い方/捉え方の違いをまとめていくのが一番難しいというのがよく伝わる章だった。
社内向けに腹落ち感をもってもらってシステムを統合するべきなのは確かだが、色々な制約があった上で移行前より不便になってしまう事はどうしてもある。 そこでの不満噴出は自分も経験あるし、ユーザーとしての不満の気持ちもよくわかるが、終わってみないとああしたらよかったというのが出しにくくて難しい所だと思う。
振り返りの話に書かれていた「次やるとしたらこうやる」という風に意見を出してくのが重要というのは自分の肌感にもあっててよかった。
「置かれた状況下で全員がベストを尽くしたことを疑ってはならない」は非常に重要な考えだと自分も思っていて、この考えを持っているだけで変なマサカリはなくなって心理的安全性の高い組織になるんじゃないかと思っている。