読書メモ『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』 株式会社VOYAGE GROUP監修
『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』 を読んだので、書籍から得た知見をご紹介します。
背景 他社のエンジニア組織について知りたい
気になっていた VOYAGE GROUP のエンジニア本が Kindle Unlimited 読み放題にあったので読みました 📚
以下、印象に残った箇所の引用とメモです。
第1章 fluct ― 広告配信の舞台裏の技術者たち
【補足解説】リファクタリングと作り直しの違い
テストを書いて保護しながら機能を追加したい、でもテストが書けないから、まずはテストが書けるようにしよう、それもエンドツーエンドで同じログが出るか見るようなテストができる状態にしてやろうというのは、まさにレガシーコード改善とリファクタリングの手法です。
📝 レガシーコード改善するときに参考にしたい。
第2章 Zucks ― フルサイクル開発者の文化
Zucksのエンジニア文化
自分たちの文化をまずは言葉にするところから始めようと思い、それを伝えることに重点をおいた求人票を書いた
📝 求人票に文化を書く
面白かったのは、この「CTOが求人票を書く」という作業そのものを通して、「これがZucksのエンジニアなんだよなあ」と改めて感じさせられたところです。チームの全員にチェックしてもらったんですが、「こう書いたほうがZucksの実体が伝わる」とか、「こっちのほうがうちにあっている」といったコメントをたくさんもらえたんです。自分の中で完成形に近い状態にしてから見てもらったんですが、もっと雑に書いた状態でチェックしてもらったほうがよかったかもしれないな、と思いました。
📝 ちょうど求人票を作成中だったので参考にしたい。
フルサイクルでは、全部を作れる必要はないけれど、その代わりビジネス的な要件を整理するところからできる必要がある
フルスタックと言うと、一人でプロダクトやサービスをすべて作れることに主眼がおかれると思います。一方、フルサイクルでは、全部を作れる必要はないけれど、その代わりビジネス的な要件を整理するところからできる必要があります。
📝 フルスタックとフルサイクルは、求められるスキルが違う。
サーバーとクライアントとバックエンドで構成されるシステムがあって、そのシステムを使ったビジネスを各分野のエンジニアのチームと一緒に回していこうと思うと、もしかしたらフロントにフラグを追加するだけで実現できる機能であっても、最初から3人のエンジニアに相談が必要になるでしょう。 Zucksでは、それを機能要件の絞り込み、つまりどこに改修が必要になるかを考える段階から一人のエンジニアでやれてしまう、ということです。
📝 フルサイクル開発者が活躍する事例
【補足解説】フルサイクル開発者とは
【補足解説】フルサイクル開発者とは「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それをすべて一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。
（中略）
フルサイクル開発者については、Netflixのブログを翻訳した記事がVOYAGE GROUPの技術ブログ（“VOYAGE GROUP techlog”）に掲載されています。ビジネスの一番最初から運用して観測するというフィードバックサイクルを回せるのが「フルサイクル」のイメージであることがよくわかる解説になっています。
- Netflixにおけるフルサイクル開発者–開発したものが運用する https://techlog.voyagegroup.com/entry/2019/02/04/171325
📝 Netflix社のブログを翻訳した記事はとても参考になりました。ありがとうございます。
フルサイクル開発者の仕事はコードを書くことだけでなく、ビジネスなんです
📝 自分が求めるエンジニアはこれに近い。
フルサイクルで全員がシステムの全体をさわることが前提と言っておきながら、言語を絞らずにサブシステムごとにバラバラなのは、一見すると矛盾した方針かもしれません。実際にそれで問題ないのかという質問を受けることも多いんですが、「普段から新しいものにさわってキャッチアップする力をメンバーがつけているから問題ない」と答えています。逆に、技術を絞って全員が同じものを使っている状況だと、必要があって新しい仕組みを導入したくなったとき、それをチーム全体に受け入れさせるのが大変になってしまうでしょう。だから、常に新しいものを学ぶ機会を作って、そういう力をチームとして伸ばしているんだ、と。新しいものを覚えるのが億劫になってしまうよりは、それが当たり前になっているチームのほうがいいですよね。新しいものを取り入れるのを一回止めてしまうと、重い腰が上がらなくなってしまい、新しいものに対して悲観的になってしまう、そちらのほうがリスクだろうと思います。
📝 こういうテックカルチャーにしていきたい。
ドキュメントがまったく存在しないシステム
一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続けるという作業が発生してしまいます。さもないと、新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことになるでしょう。
📝 ドキュメントを書くことのデメリット
第5章 サポーターズ ― 事業の成長を止めない手段としてのシステム刷新
システムだけじゃなくて組織も再定義した
最終的には、ISO 52184の性別表記の定義に従う形になりました。
📝 参考にする。
「全員、やればできる」体制
ね：ちなみに、サーバーのAPI受け入れテスト的なものは、ScalaではなくNode.jsで書いています。最初にサーバーをScalaとGoのどちらで書くか検討していた段階で、「あとで方針転換があっても使いまわせるように、テストを別言語で書いておこう」と考えたからです。か：和田さんが以前、「実装から距離をとってテストを書くことで独立性を保つ」という話をしていましたが、その点にもつながっていますね。ね： APIを外部から叩いたときの挙動を規定するテストを、あえて実装とは別の言語で書くようにすることで、実装に入り込んだテストを書けないようにする、という話ですね。―確かに、書籍『Clean Architecture』6の読書会でそのような話をしました。
📝 実装と別の言語でテストを書く手法。
【補足解説】実装から距離をとってテストを書くことで独立性を保つ
こうしておけば、フロントエンド側でAPIに対する望ましい挙動を定義する際に、それをテストを書くことで規定できるとも考えています。仮に将来、フロントエンドとサーバーサイドにチームが完全に分かれても、フロントエンドの開発者が「こういうAPIが欲しい」と思ったときは「それに通らないテスト」を自分でNode.jsで書き、サーバーサイドの開発者がそれを通す実装を提供する、という感じにできます。
📝 Node.jsでテストコードを書いておけばフロントエンドエンジニアも書ける。
読了後の所感
自社のエンジニア組織づくりに参考になりそうなことが書かれていて、ハイライトとメモが捗りました。また、泥臭いリアルな話も書かれていて、他社の技術現場の光景が垣間見れ、楽しく読ませていただきました。
以上、エンジニア組織を作っていく上で良いところは真似していきたい、現場からお送りしました。
