@makoga さんから「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を送って頂きました。ありがとうございました。
VOYAGE GROUP にある 5 つの事業会社についてそれぞれの事業を支えるシステムの開発、運用、改善といった内容を在籍するエンジニアへのインタビュー形式でまとめられた本です。
事業会社の現場
システムは一度開発して終わりではなく、事業を継続し続ける限りその開発運用をしていくとになります。5 社ではそれぞれ別の事業を営んでおり、それぞれのコンテキストがあります。本書では、システム開発における様々な意思決定（主にシステムの改善）と施策を行ってきたかという話がメインとなっているのですが、具体的な施策だけではなくその背後にあるコンテキストも含めて語られているのが大きいな特徴です。
システム開発は無数の意思決定の上に成り立っており、それぞれの場面でコンテキストに従って判断していくことになります。場合によっては一般的には良いとされる方法とは異なる方法を意識的に採用する、もしくは状況として採用せざるを得ない場面もあるでしょう。こうしたコンテキストは組織や部署、会社によって特有のものであり、外部に語られることはありません。場合によっては、チームメンバーでさえも全容は理解していないこともあるでしょう。
こうしたコンテキストはある時点だけの状態を切り取ったものではなく、ストーリーとしてそこに至った経緯を見ることでより鮮明になってきます。本書では、それを知る現場のエンジニアからインタビューという形でストーリーが語られており、少しづつストーリーを進んでいく（戻っていく）ので、まるでその場で一緒に話を聞いているような感覚で頭の中にコンテキストが形成されていきました。
そして、もう一つ本書通じて感じたのは、インタビュイーである開発現場のエンジニアの方々が圧倒的な当事者意識を持って仕事に取り組まれているということです*1。これはシステムに対してだけでなく、事業に対しても同様です。事業会社で働くなら当たり前のことかもしれませんが、システム、さらにその目的である事業をいかに自分のこととして捉えられるかによって考え方も起こすアクションも変わってきます。1 章の BigQuery 採用の流れや、同じく 1 章そして 2 章にある腕力で改善を一気に進めるところなどまさにそうでしょう。
こうした当事者意識は本人の心持ちだけではなく、それを後押しする環境、文化にも影響を受けます。もし、自分がこうした意識を持とうとしても、すぐにボールを取り上げられる環境や事業サイドの下請けのような立場になっている環境ではそれを継続することは難しくなります。本書で登場する 5 社では現場のエンジニアが当事者意識を持てるような、後押しするような環境になっているのだろうということを感じました。
まさに副題にあるとおり「事業をエンジニアリングする技術者」ですね。
リファクタリングかリライトか
複雑怪奇になったレガシーシステムを改善していく方法を大きく分けると既存のコードベースを改善していくリファクタリングやリアーキテクティングといった手法と１から書き直すリライトといった手法に分けられます。*2 このどちらを取るかというのは現場でも議論になるところです。
本書でも、各社でどちらを採用するかという内容が登場しています。どちらを選ぶべきかというのはまさにコンテキストによるとしか言えないと思うのですが、リファクタリングを採用した会社もリライトを採用した会社も双方の事例があるというのは興味深いところです。
例えば、3 章の VOYAGE MARKETING では 20 年もののレガシーシステムの改善案として双方を検討したところリファクタリングを選択しています。一方、5 章のサポーターズでは他社が実装したシステムを自社で実装し直すリライトを選択しています。どちらもなぜそれを選択したかという点も記されており、現場でレガシーコードの改善を検討している人には参考になる内容でしょう。
レガシーソフトウェア改善ガイドを筆頭にこうしたレガシーシステムをどう改善していくかという内容の書籍はいくつかありますが、こうした書籍にあるのはある意味汎用的な知識です。実際の現場では、こうした知識をベースにそれぞれのコンテキストで判断していくことになるのですが、本書ではまさに現場での意思決定がその理由と共に語られているというのが面白いところでした。
3 章は、それ以外にも、データベースのテーブル数を 1200 から 450 まで減らしたり、システムをスリム化していく流れでコード、機能、事業の削減（葬り）に分けて実施していくという骨太の内容でした。これを 5 年かけて通常業務と並行しながら除々に実施したというのは、大変ではありますが、粘り強く少しづつでも進めることで技術的負債を返却できるという一つの指針を見ることができました。
PHP レガシーシステム改善ガイド
開発現場での改善や意思決定というどちらかというと抽象的な面に触れてきたのですが、実は具体的な改善策についてもしっかり描かれています。特に、PHP ユーザとして見逃せないのは、PHP で作られたレガシーシステムをどのように改善していくかという内容です。VOYAGE GROUP では PHP が多く使われている（た）ようなので、それをどのように改善していったかという話題が度々登場します。いくつか抜粋すると下記のようなものです。
- PHP + Smarty から Slim PHP + React に変更
- require_once を撤廃して use を使うように変更
- PSR-4 準拠のレイアウトに配置し直しとなるので composer オートローダへの変更と思われる
- グローバルな例外ハンドラ導入により、異常系処理の統一
- PHP + Apache から Go へのレプレース
- PHP(CakePHP) から Scala へのリプレース
- PHP OPcache を利用して不要コード（葬りコード）の検知
コードレベルでも細かな解説があるというわけではないですが、長年運用されているシステムを持つ現場では改善のヒントとなるでしょう。
印象に残ったところ
- 1 章 - 配信サーバと管理画面
- 2 章 - フルサイクル開発者、独自の文化
- 3 章 - 「技術的負債はエンジニアリングからも積まれていきますが、多くは事業起因」、ビジネスサイドと現場サイドとの調整
- 4 章 - 初期アーキテクチャとその進化
- 5 章 - 事業特性に応じた施策の選択
- 6 章 - データサイエンスエンジニア
さいごに
他にもまだまだ見所があるのですが、読んでのお楽しみということでこのあたりで。開発現場で仕事をしている人なら何かしら琴線に触れるポイントがあり、誰かに話したくなる本です。また、これから開発を仕事にしたい人にも開発現場のリアルが垣間見える貴重な本です。
最後に触れたいのはインタビュー形式という本書のフォーマットです。現場のストーリーを質問で少しづつ紐解いていくという流れはとても読みやすく、想起しやすいものでした。口伝えで話す伝わり易さとテキストとしての可搬性を合わせ持った良い形だと感じました。もちろんこれは、インタビュアである t_wada さん、そしてインタビュー内容を読みやすい形に編集された鹿野さんの手腕によるものでしょう。良い本をありがとうございました。
本書で語られていた 2020 年のシステムが、さらに今後 2025 年、2030 年と時が経るうちにどのような意思決定が行われ、システムが変化していくのか、そしてどういう結果をもたらすのかというストーリーもいずれ第二弾、第三弾の書籍で読めることを楽しみにしています。
