読後レビュー｜『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』

ども、いろいろ本を読み直し中の Nash です。

この記事は下記の本の書評になります。

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

では、みていきます。

この本はどんな本？

この本は、1990 年に創業し 20 年で 100 以上の事業・サービスを手掛けてきた VOYAGE GROUP 社の過去・現在のプロジェクトに参画してきた各エンジニアへのインタビュー集として構成されている本です。

そのため、よくある技術書本とはまったく違う趣になります。簡単に言えば「Web エンジニアリングにおけるプロジェクト X」みたいな感じです。

2021 年の技術者本の大賞

またこの本は翔泳社にて行われている毎年恒例の IT エンジニア本大賞にて見事、技術書部門大賞となった本です。

ベスト 10 の本はもちろんですが特に大賞になった本は名著なので出来る限り読むようにしています。

この本から得られること

自分がこの本を読んだことで得られたことは下記の通りです。

• 他のインターネット事業会社のプロジェクトの進め方などを現場感を持って知れる
• 大きくなってしまった技術的負債に対してどのように立ち向かっていくべきかのナレッジやヒントをたくさん知れる

この本は誰が書いたの？

この本は一人の著者によって書かれたような本ではなく共同編集かつ内容もインタビュー集なので複数の編者・監修者によって手がけられているようです。

編者としては和田卓人さんが携わってます。過去にも『SQL アンチパターン』『テスト駆動開発』などの名書に携わっていて、「テスト書いてないとかお前それ　@t_wada の前でも同じ事言えんの？」 のネットミームでも有名ですしエンジニア界隈では知らない人はいないくらいの有名人ですね。

監修者としては VOYAGE GROUP 社が携わっています。1999 年に創業して今までに様々なインターネット事業に携わってきたこの会社が社内のエンジニアへのインタビューという形でこの本は構成されています。

他にも、協力者としてラムダノート CEO の鹿野さんがすべてのインタビューに同席しかつ編集にも力を入れているようです。

この本はだれが読むべき？

この本は下記ような人が読むのが良いかと思いました。

• 大きな技術的な負債を抱えたシステムにどう立ち向かうかを知りたい人
• プロジェクト X が大好きなエンジニア
• アフター DX としての開発現場の肌感を知りたい人
• エンジニアだけでなく非エンジニアでも問題なし

各理由は下記の書評の項目を読んでもらえればと思います。

だれが読んだの

この本を読んた自分の簡単な自己紹介です。

メガバンクを顧客にした SIer で金融系 SE として活動したのち Web 系へ転職。 自社サービス・受託システムの両方で開発・マネジメントを経験した後、エンジニアリングを中心にしたフリーランスとして活動しています。

書評

では、自分が読んだ結果の評論を書いていきます。

自分が知らないアドテク事業について現場感をもって読み進められる

自分は過去にアドテク事業の経験をしたことがないですが、この本を通じて様々なインタビューを通して、アドテク事業特有の制約・特徴などを現場感を感じながら理解することができました。

例えば「配信サーバー周りだと一日に数億行のログファイルが発生するような超ハイトラフィックな分野である」ことなどですね。

アドテク系を中心に様々な切り口でプロジェクトを見ていける

各章ごとにインタビューする相手が異なり、それぞれが担当するシステムも異なります。インタビューを通じて、それぞれのエンジニアがどのような課題にどのようなアプローチで立ち向かってきたのかを知ることができます。

ただ、少し残念に思ったのは全体的に広告・アドテクの事業に関するトピックが多かった点で。各章ごとに別ドメインにすると一貫性はなくなりますが、その分だけよりバラエティに富んでいたのではないかなーと少し感じました。

腕力と技術的負債

過去に自分も様々な会社・プロジェクトに携わってきましたが、技術的負債を溜め込んでそのまま解決しきれないシステムに悩むチームをよく見かけてきました。

こういうケースにおける銀の弾丸はないとは思っていますが、解決の一つの手段・アイデアなどがこの本で語られていたのが個人的には学びがありました。下記の内容です。

技術的負債は、賢くやるだけではなく、腕力がないと返済していけない。 … 腕力って、いったい何でしょうね。

関係ないところに手を出す力、放っておかない力、というのがまずあると思います。

重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、 カッとなる力、放っておかない力が必要です。 … 率直に言うと、技術的負債を返済できる企業とできない企業があるのは、この腕力の有無 によるという面も否定できません。 (p32 第 1 章)

ここでは「技術的負債と腕力」について語られていて「技術的負債をするためには腕力が必要」というような内容です。ただ、では腕力を得るためにはどうすればいいのか？が個人的にはまだ答えが出ていないです。

過去にも腕力のあるエンジニアに何度か遭遇してきましたが、そもそも自分とは特性が違うんじゃないかと思うことが多いので、能力や資質に近いものかと思っています。

能力として考えると後天的に鍛えられて、おそらく必要な要素として下記のようなものかなーと思ってます。

• ソフト：やりきる力（GLID）
• ハード：コードリーディングスキル
• ハード：コード改善能力

こう列挙するとわかりますが、ソフトとハードの両方において獲得するのが難しいスキルが並んでいることもあるため「腕力のあるエンジニア」は稀有なのではないかなーと思ってます。

本番で試せられる文化の裏側

よく巷で言われるようになった文化の一つとしてチャンレジ文化が挙げられると思います。一昔では物事を進めるときのスタンダードは PDCA サイクルでしたが、今ではできるだけはやくトライをしその結果から学び再度イテレーションを回すのが是となっているかと思います。

VOYAGE GROUP においてはこのチャレンジ文化の１つとして本番環境で物事トライすることが是となる文化があるようです。

昨今では、このように本番環境でチャレンジできる環境作りの大事さを問われることが多いが、そういうチャレンジを担保するための仕組みについて言及されていることはあんまり見たことがなく、ここで初めて知れたので学びでした。

常 に「安全に元に戻せる仕組み」を用意したうえでリリースしている

… 本番環境じゃないとわからないことがすごく多いから、本番環境で安全にトライすることを基本戦略にしている 、という感じですね。 … データベースの設計にしても、きれいさより切り戻しが容易であることを優 先しているので、「本当にその方針でいいのか?」と。 「カラムを消さない」というのが典型的です。 (p70 第 2 章)

本番環境で試せられる文化を作るためにもその裏側には安全性を担保する仕組み・思想が必要という話でした。

意図的に技術を集中しないという選択

自分がスタートアップ系の企業を中心にフリーランスとして活動していることもあり、技術を投資的に考えている節があります。

• 自分が今後どの技術を学ぶべきか。
• 企業がどの技術を選択しているか。

基本的に企業が技術選定をする場合は一般的に技術・言語は散らばらせずに集中することが多いです。選択と集中の理論のためで、スタートアップのは場合はその傾向はなおさら強いです。

インタビューの中であえて技術を集中しない話について書かれていて新しい視点を得たのでまとめます。

逆に、技術を絞って全員が同じものを使っている状況だと、必要があって新しい仕 組みを導入したくなったとき、それをチーム全体に受け入れさせるのが大変になって しまうでしょう。

だから、常に新しいものを学ぶ機会を作って、そういう力をチーム として伸ばしているんだ、と。 (p62 第 2 章)

つまり、選択と集中ではなくて柔軟性に重きをおいた選定戦略と考えられます。

ただ、これを実現するためには既存・新規メンバーの技術力がかなりのラインを超えていないといけないことが予想されます。逆に言えば、この文化がうまく機能すれば強いエンジニアの新規参入・定着が期待できそうです。なぜなら、強いエンジニアからすると自分の一存で好きにやりたい技術を導入しやすいからです。

技術的負債の返済タイプ

レガシー化した大規模システムにおいて技術的負債をどう返済していくか？についてのナレッジを得たので抜粋します。

いらないテーブルとコード を削除し、システムの全体ボリュームを必要十 分にする、という作戦です。完全にチーム内の 用語なんですが、「葬り」と呼んでいます。 … 「葬り」には「事業葬り」と「機能葬り」と「コード葬り」の 3 段階 があります。 P95

葬りに対して段階ごとに命名をすることで、それぞれを認識可能になった点は大きいです。

それぞれの特徴とトレードオフなどは下記の通りでした。

• 事業葬り：ハイコストハイリターン ⇒ 関係者への説得などのコストも大きいがその分のリターンも大きい。
• 機能葬り：ミドルコストミドルリターン ⇒ 機能単位なので関係者への調整もしやすくコードも機能単位で削れる。
• コード葬り：ローコストローリターン ⇒ コード単位の調整なので全体から見たときのインパクトも小さい。

技術的負債を返済するときの手段として手元にアイデアを得られたのは個人的には有意義でした。

Web 系のエンジニアリングが、SE 的な仕事になる未来

現在、Web に関わるシステムは作られたばかりで比較的年齢が若いためレガシー化も巨大化もしていません。ですが、今後はそれらがレガシー化していくと見られています。俗に言う 2025 年問題として語られてます。

こういうシステムへの対処として泥臭い戦いをしなければいけないのですが、その時の仕事の進め方は下記のように語られています。

「作った人がすでにいない大きめ のシステムを解きほぐし、スプレッドシートで把握の度合いを高めていく」というスキルは、誤解を恐れずに言えば、SIer のスキルなんですよね p111

自分も同じことを感じながらこの本を読んでいて、この説明を見て「やっぱりか」という感想でした。過去に自分はメガバンクを相手に SIer で SE をしていたため、その時の仕事内容に通じるところをものすごく感じます。

少なくとも 2021 年の現代エンジニアリングにおいて理想論としては、このようなシステムへの対処としてはマイクロサービス化するのがグローバルスタンダードでしょう。

ただ、すべての Web 企業がそのようにうまく切り替えられるわけもないので、おそらく今後はどんどんシステムがレガシー化・マンモス化して SIer 業界によくあるような腐ってしまったシステムのようになってしまうんだろうなーという未来が簡単に予測できます。

負債やバグが溜まりすぎるとユーザーがバグ技を使い始める

これは個人的には一番おもしろかったストーリーでした。

こんな挙動になるから、それで運用することで新しい取り組みに対応しよう」みたいな感じです。

実装を見ると「その挙動は実はバグなんだけどな」というものもあったり。 データベースを見て業務がわからないのも当然だなあ、と。(Page 155).

システムがレガシー・マンモス化するとバグが仕様になって、バグを直すこともできなくなる恐怖ですね。。。

テストコードは別の言語で書く

バックエンドが Scala で書かれているのにテストコードは TypeScript/Node 書かれている、とのことでその理由の学びと納得感がすごいあったので抜粋します。

和田さんが以前、「実装から距離をとってテストを書くことで独立性を保つ」という話をしていましたが、その点にもつながっていますね。

API を外部から叩いたときの挙動を規定するテストを、あえて実装とは別の言語で書くようにすることで、実装に入り込んだテストを書けないようにする、という話 ですね。(Page 171 第 4 章).

確かに同一言語で書くと理想論よりも面倒臭さなどから密結合な書き方などをしがちです。そして一度汚くなると割れ窓理論の力学が作用してしまいます。

その点、言語を別にすれば面倒くさいからと密結合な書き方は発生しないですね。密結合にするほうがむしろ大変になるくらいですから。

独立性の高いテストコードを作るための「仕組み」としてすごいアイデアでした。

ほかの本と比較

この本は VOYAGE GROUP 社に所属するエンジニアへの過去・現在のプロジェクトへどうやって立ち向かってきたかのインタビュー集です。そのためこの本の内容としてあまり他の本と比較することができないタイプの本かと思います。

そのため、気になる人は他の本との比較したりする必要がなくそのまま読み始めてよいかと思います。

おわりに

各章ごとにストーリがわかれているため自分は夜寝る前に１つの章ごと読んでいました。

もともと読みやすい文体なこともあり、毎日 1 章ごと読めば 1 週間もかからずに簡単に読み切れます。

もし気になったのなら、この機会に一読してもらうのが良いかと思います。

この本はだれが読むべき？

この本は下記ような人が読むのが良いかと思いました。

• 大きな技術的な負債を抱えたシステムにどう立ち向かうかを知りたい人
• プロジェクト X が大好きなエンジニア
• アフター DX としての開発現場の肌感を知りたい人
• エンジニアだけでなく非エンジニアでも問題なし

この本から得られること

• 他のインターネット事業会社のプロジェクトの進め方などを現場感を持って知れる
• 大きくなってしまった技術的負債に対してどのように立ち向かっていくべきかのナレッジやヒントをたくさん知れる

---