はじめに

話題となっていた書籍である Engineers in VOYAGE を読み終えたので、その簡単な書評を書く。

書評

結論から述べると、本書籍で多く触れられるWeb技術に関わる技術者だけでなく、普段は上流工程から技術やプロジェクトマネジメントに携わっているエンタープライズな技術者にも本書籍を読んで欲しいとおもった。なぜかと言うと、通常であれば隠蔽されていて見えないエンジニアの考えや努力が、生々しく記載されており、エンタープライズ領域でも有用である知見が多く記載されているからだ。

レガシーシステムとの戦い

たとえば、Voyage Marketing社におけるECナビでの、経済産業省の述べる2025年の崖への戦いの知見が1つの例だ。1200を超えるテーブルを持つオンプレシステムに対して、いかに泥臭く改善を進めたか、書籍で説明されている。具体的な取り組みとしては、オンプレからクラウドへの移行、テーブル数を450まで削減の方法が言及されている。単に技術的な機能面だけはなく、事業ごと葬る、といったようにビジネスサイドとも合意を得て力強く進められていることがわかる。

このような経験・スキルは中で体験しているエンジニアでないと獲得しがたいものである。もちろん、書籍から得られる知見は表面上に限るかもしれないが、その内容について少しでも触れることができるという意味で、大変貴重な書籍である。

今後、2025年の壁が本格的にやってくる。レガシーシステムと向き合わないといけない、SIerのエンジニアも多くいるはずだ。そのような方にとって、本書籍の3章は非常に勇気づけられる内容になるだろう。

開発経緯をIssueに残す

なお、自身の置かれる文脈から3章について上記で取り上げたが、3章以外も素晴らしい内容が多い。たとえば、Zucksにおける開発アプローチは大変興味深く、ドキュメントがほとんどない代わりに、GitHub Issueに歴史的議論経緯などを積み重ねるスタイルで、「そういう開発方法もあるのか」と大変参考になった。

開発あるあるかもしれないが、現在のアーキテクチャやテーブル設計などの最終的な構成を起こした図はあったとしても、なぜそこに至ったかという理由が残っていないケースがある。この場合、将来に変更を加えようとした場合に、これまでの背景が分かっていないため、影響範囲を把握しにくくなるという課題がある。したがって、背景・変更理由を残すのは重要であり、Issueにトピック1つずつ残すやり方は、大変興味深く読ませていただいた。

ビジネスとの距離と近づける

5章では、サポーターズというサービスについて言及されている。

その中の取り組みで大変面白いのが、オフィスでビジネスサイドと技術サイドのメンバーが同席できる場所を用意するというアプローチだ。もともとは、オフィスが徒歩20分程度離れていたが、その時間がゼロになる。また、ビジネス要件を理解するためにヒアリングだけでなく、マネージャーミーティングに参加するなど、解像度を高めるための具体的な行動な紹介されている。

終わりに

冒頭で述べたように、エンタープライズ文脈の技術者にとっても、非常に学ぶことの多い書籍であると思う。ぜひ、手にとって見てほしい。