I read 『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』, so I’ll introduce the insights I gained from the book.

Background: Want to Learn About Other Companies' Engineering Organizations / 背景 他社のエンジニア組織について知りたい

I read this VOYAGE GROUP engineering book that I was curious about because it was available on Kindle Unlimited 📚

Below are quotes and notes from sections that left an impression.

Chapter 1: fluct ― Technologists Behind Ad Delivery / 第1章 fluct ― 広告配信の舞台裏の技術者たち

【Supplementary Explanation】Difference Between Refactoring and Rebuilding / 【補足解説】リファクタリングと作り直しの違い

テストを書いて保護しながら機能を追加したい、でもテストが書けないから、まずはテストが書けるようにしよう、それもエンドツーエンドで同じログが出るか見るようなテストができる状態にしてやろうというのは、まさにレガシーコード改善とリファクタリングの手法です。

English translation: We want to add functionality while writing tests for protection, but since we can’t write tests, let’s first make it possible to write tests. Making it possible to do end-to-end tests that check if the same logs are output is exactly the technique for legacy code improvement and refactoring.

💡 I want to reference this when improving legacy code.

Chapter 2: Zucks ― Full-Cycle Developer Culture / 第2章 Zucks ― フルサイクル開発者の文化

Zucks Engineering Culture / Zucksのエンジニア文化

自分たちの文化をまずは言葉にするところから始めようと思い、それを伝えることに重点をおいた求人票を書いた

English translation: I thought we should start by putting our culture into words, and wrote a job posting that focused on communicating that.

💡 Write culture in job postings.

面白かったのは、この「CTOが求人票を書く」という作業そのものを通して、「これがZucksのエンジニアなんだよなあ」と改めて感じさせられたところです。チームの全員にチェックしてもらったんですが、「こう書いたほうがZucksの実体が伝わる」とか、「こっちのほうがうちにあっている」といったコメントをたくさんもらえたんです。自分の中で完成形に近い状態にしてから見てもらったんですが、もっと雑に書いた状態でチェックしてもらったほうがよかったかもしれないな、と思いました。

English translation: What was interesting was that through this “CTO writing job posting” work itself, I was reminded once again that “this is what Zucks engineers are like.” I had everyone on the team check it, and I received many comments like “writing it this way conveys Zucks’ reality better” or “this way fits us better.” I had them review it when it was nearly complete, but I think it might have been better to have them check it when it was more roughly written.

💡 I want to reference this since I’m in the middle of creating job postings.

フルサイクルでは、全部を作れる必要はないけれど、その代わりビジネス的な要件を整理するところからできる必要がある

English translation: In full-cycle, you don’t need to be able to build everything, but instead you need to be able to organize business requirements from the start.

フルスタックと言うと、一人でプロダクトやサービスをすべて作れることに主眼がおかれると思います。一方、フルサイクルでは、全部を作れる必要はないけれど、その代わりビジネス的な要件を整理するところからできる必要があります。

English translation: When we say full-stack, I think the focus is on being able to create all products and services by oneself. On the other hand, with full-cycle, you don’t need to be able to build everything, but instead you need to be able to organize business requirements from the start.

💡 Full-stack and full-cycle require different skills.

サーバーとクライアントとバックエンドで構成されるシステムがあって、そのシステムを使ったビジネスを各分野のエンジニアのチームと一緒に回していこうと思うと、もしかしたらフロントにフラグを追加するだけで実現できる機能であっても、最初から3人のエンジニアに相談が必要になるでしょう。 Zucksでは、それを機能要件の絞り込み、つまりどこに改修が必要になるかを考える段階から一人のエンジニアでやれてしまう、ということです。

English translation: If there’s a system composed of server, client, and backend, and you want to run a business using that system together with teams of engineers from each field, even for features that might be achievable just by adding a flag to the frontend, you’d need to consult with three engineers from the start. At Zucks, one engineer can handle everything from the stage of narrowing down functional requirements—that is, thinking about where modifications are needed.

💡 Example of full-cycle developers in action.

【Supplementary Explanation】What is a Full-Cycle Developer / 【補足解説】フルサイクル開発者とは

【補足解説】フルサイクル開発者とは「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それをすべて一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。

（中略）

フルサイクル開発者については、Netflixのブログを翻訳した記事がVOYAGE GROUPの技術ブログ（“VOYAGE GROUP techlog”）に掲載されています。ビジネスの一番最初から運用して観測するというフィードバックサイクルを回せるのが「フルサイクル」のイメージであることがよくわかる解説になっています。

• Netflixにおけるフルサイクル開発者–開発したものが運用する https://techlog.voyagegroup.com/entry/2019/02/04/171325

English translation: 【Supplementary Explanation】A full-cycle developer views “from business idea to customer delivery” as one cycle, and the image is to make it possible for a single technologist to handle all of that.

(omitted)

Regarding full-cycle developers, an article translating Netflix’s blog is published on VOYAGE GROUP’s technical blog (“VOYAGE GROUP techlog”). It’s an explanation that clearly shows that the “full-cycle” image is being able to run a feedback cycle of operating and observing from the very beginning of business.

💡 The article translating Netflix’s blog was very helpful. Thank you.

フルサイクル開発者の仕事はコードを書くことだけでなく、ビジネスなんです

English translation: The job of a full-cycle developer is not just writing code, it’s business.

💡 The engineer I’m looking for is close to this.

フルサイクルで全員がシステムの全体をさわることが前提と言っておきながら、言語を絞らずにサブシステムごとにバラバラなのは、一見すると矛盾した方針かもしれません。実際にそれで問題ないのかという質問を受けることも多いんですが、「普段から新しいものにさわってキャッチアップする力をメンバーがつけているから問題ない」と答えています。逆に、技術を絞って全員が同じものを使っている状況だと、必要があって新しい仕組みを導入したくなったとき、それをチーム全体に受け入れさせるのが大変になってしまうでしょう。だから、常に新しいものを学ぶ機会を作って、そういう力をチームとして伸ばしているんだ、と。新しいものを覚えるのが億劫になってしまうよりは、それが当たり前になっているチームのほうがいいですよね。新しいものを取り入れるのを一回止めてしまうと、重い腰が上がらなくなってしまい、新しいものに対して悲観的になってしまう、そちらのほうがリスクだろうと思います。

English translation: While saying that the premise is that everyone in full-cycle touches the entire system, not narrowing down languages and having different ones for each subsystem might seem like a contradictory policy at first glance. I often get asked if that’s really okay, but I answer that “it’s fine because members usually develop the ability to touch new things and catch up.” Conversely, if we narrow down technology and everyone uses the same thing, when we want to introduce a new system when needed, it would be difficult to get the whole team to accept it. So we constantly create opportunities to learn new things and develop that ability as a team. It’s better to have a team where that’s normal rather than where learning new things becomes troublesome. If you stop adopting new things once, it becomes hard to get motivated again and you become pessimistic about new things, which I think is more of a risk.

💡 I want to create this kind of tech culture.

System with No Documentation Whatsoever / ドキュメントがまったく存在しないシステム

一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続けるという作業が発生してしまいます。さもないと、新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことになるでしょう。

English translation: Once you write documentation, you have the task of continuously maintaining that documentation. Otherwise, when new people join, they’ll end up referencing old documentation thinking it’s valid information.

💡 Disadvantages of writing documentation.

Chapter 5: Supporters ― System Renewal as a Means Not to Stop Business Growth / 第5章 サポーターズ ― 事業の成長を止めない手段としてのシステム刷新

Redefined Not Just Systems but Organizations Too / システムだけじゃなくて組織も再定義した

最終的には、ISO 52184の性別表記の定義に従う形になりました。

English translation: In the end, we followed the ISO 52184 definition for gender notation.

💡 Will reference this.

"Everyone Can Do It If They Try" System / 「全員、やればできる」体制

ね：ちなみに、サーバーのAPI受け入れテスト的なものは、ScalaではなくNode.jsで書いています。最初にサーバーをScalaとGoのどちらで書くか検討していた段階で、「あとで方針転換があっても使いまわせるように、テストを別言語で書いておこう」と考えたからです。か：和田さんが以前、「実装から距離をとってテストを書くことで独立性を保つ」という話をしていましたが、その点にもつながっていますね。ね： APIを外部から叩いたときの挙動を規定するテストを、あえて実装とは別の言語で書くようにすることで、実装に入り込んだテストを書けないようにする、という話ですね。―確かに、書籍『Clean Architecture』6の読書会でそのような話をしました。

English translation: Ne: By the way, we write server API acceptance tests in Node.js rather than Scala. When we were initially considering whether to write the server in Scala or Go, we thought “let’s write tests in a different language so they can be reused even if we change direction later.” Ka: Wada-san previously talked about “maintaining independence by writing tests at a distance from implementation,” which connects to this point. Ne: The idea is to write tests that define the behavior when APIs are called from outside in a different language from the implementation, so you can’t write tests that get too deep into the implementation. —Indeed, I made such a discussion at the Clean Architecture book reading session.

💡 Technique of writing tests in a different language from implementation.

【Supplementary Explanation】Maintaining Independence by Writing Tests at a Distance from Implementation / 【補足解説】実装から距離をとってテストを書くことで独立性を保つ

こうしておけば、フロントエンド側でAPIに対する望ましい挙動を定義する際に、それをテストを書くことで規定できるとも考えています。仮に将来、フロントエンドとサーバーサイドにチームが完全に分かれても、フロントエンドの開発者が「こういうAPIが欲しい」と思ったときは「それに通らないテスト」を自分でNode.jsで書き、サーバーサイドの開発者がそれを通す実装を提供する、という感じにできます。

English translation: By doing this, when defining desired API behavior on the frontend side, we think we can specify it by writing tests. Even if teams are completely split between frontend and server-side in the future, when frontend developers think “I want this kind of API,” they can write “tests that don’t pass” themselves in Node.js, and server-side developers can provide implementations that make them pass.

💡 If you write test code in Node.js, frontend engineers can also write it.

Impressions After Reading / 読了後の所感

There were things written that seemed helpful for building our own engineering organization, and highlighting and note-taking was productive. Also, gritty realistic stories were written, giving glimpses into other companies’ technical workplaces, making it enjoyable to read.

That’s all from the Gemba.