「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ
先日から個人的にフルサイクル開発のことを色々と調べる機会があり、Qiitaに以下の記事を書いたのだが、
この中でほんの少し触れたVOYAGE GROUPの例について、情報源である「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」に書かれているその考えや文化については色々と興味深かったため、もう少し書き留めておきたい。
フルサイクル開発の文化
第2章 「Zucks - フルサイクル開発者の文化」 ではアドネットワークやDSPを提供するZucks社の開発チームの文化について書かれている。 VOYAGE GROUPのフルサイクル開発というのは主にこのZucks社の文化のことを言っている。
Zucks社のフルサイクル開発者
「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。お客さんに届いたものから更にビジネスアイディアが生まれ、また別のサイクルが始まります。
とのことで、開発者のみならずエンジニア全般にフルサイクルを意識して欲しいため、「フルサイクルエンジニア」とも呼んでいるとのこと。
実際にエンジニアに求められる業務範囲のイメージとしては先のQiitaの記事でも書いたが、
全部を作れる必要はないけれど、その代わりビジネス的要件を整理するところから一人でできること。
なおフルスタックである必要がないのは以下のように書かれており、
すでに動いている仕組みについては、その使い方くらいを知っていれば、ビジネスアイディアをお客さんに届けるのに十分でしょう
これだけ読むと小さい改修に限られるイメージをしてしまうが、これは逆に「ビジネス要件の整理から」という上流工程に踏み込む方がフルサイクル開発者としてより重要になるということと理解している。
このことは、Zucks社のエンジニアの求人票 に 「業務を遂行する際、大切にしている1つに、一人のエンジニアが誰かに待たされずに開発を行う点があります。誰かが仕様を決めて、それをただ実装するだけのエンジニアはチームにいません。」 と書いてあることからも見て取れる。
ちなみに、この求人票の経緯について以下のnoteに綴られているので参考まで。
ジョイン初日にリリースする
求人票にも明記されているZucksの文化として、「ジョイン初日に必ず管理画面の機能をリリースする」というものがあるらしい。 かなりインパクトがあるが、これが如何に難しいか。
なぜ難しいか
どんなに軽微なissueをアサインするとしても、ぱっと思いつくだけでも
- オンボーディング、PCセットアップから該当issueにたどり着くまでの時間の早さ
- ツールのアカウント準備やアクセス等で躓くことがない
- そもそも必ず新人が初日クリアできるような適切なissueを整理している
このあたりがクリア出来ていないと絶対に初日では終わらないから。
初日リリースを可能にしている要素
この本の中ではその他にこれを可能にしている要素として以下を挙げている。
- 基本的にmasterブランチしかない
- 広告配信は本番環境でないと分からないことが多いことなども要因と思われる
- エンジニアの権限を分けていない（全員admin権限）
- これは一見「雑」と思われそうだが...
- 切り戻しできるかどうかを重要視
- 小さな変更でも安全に戻せない（破壊的変更）のであれば止める
- DB設計もきれいさより切り戻しが容易であることが優先（カラムを消さないなど）
とは言え
新人にとってはかなり大変な文化なのは間違いない。 広告業界経験者でも初日でそこまでやるのは難しいのに、広告業界が初めての人にとっては「そもそも何を言っているのか分からない」だろうから。
しかもトレーナーになる担当者がつきっきりでもなく「何かあったら聞いてくれ」という放置っぷり。
さらに、issueの内容からして簡単な修正だと思いきや、そのissueの背景などを営業にヒアリングするなどして理解した上で適切な修正方法を取っていないとPRで総ツッコミを受けるとか、レビューしたAさんとBさんで違うこと言ってたりとかして翻弄されるとかあるらしい。
（このトークイベントの中でそんなことを言っていた）
合わない人には全く合わない文化だと思うが、新人が初日でアウトプットを出せる、事業に貢献できる実感が持てるということにはとても価値があると思う。
ドキュメントレス文化
Zucksでは、他社で通常ドキュメント化されるような情報でも、全てGithubのissueだけで管理しているとのこと。
理由は以下。
- 一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続ける作業が発生してしまう
- メンテナンスされないと新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことにもなる
- コードに一番近いところでドキュメント的な情報を管理しようと思ったらissueが最適だった
※ちなみに、まったくないと言っても監査目的等外部に出すために必要なドキュメント等はきちんと作っているとのこと（少し上に貼ったトークイベントの中で言っていた）。
情報が欲しいときはどうするか
- まずGithubのissueを全文検索（全員この癖をつけている）
- 探しても見つからない情報は、人に聞くか、コードを見るか
- 最終的には動いているコードが正義
- 何かドキュメントが見つかってもそれは当時のスナップショットなので基本的に「ドキュメントは更新されていない」前提
気になったこと
- 動いているコードが読みにくい、意図がわかりにくいためにまずリファクタリングから始めて複数人の認識を合わせることから始めるというケースが結構多いらしい
コードレベルでない情報もissueコメントで追う必要がある
- issueをたどって全ての議論を追う必要はどこまであるのか
- issueコメントの議論をたどると結論が変わっているケースもある
- （これはこの文化の辛い側面として触れられてはいる）
全体の俯瞰、アーキテクチャなどを伝えるのは都度ホワイトボードに集まって説明するなどでカバー
- これは面倒くさくないのか... オンボーディングのコストがめっちゃ高い気がする。。
- これがあるのに初日リリース出来ているのには矛盾すら感じる。
このあたりを見ると特に新人向けにはお互いの伝達コストが高い気しかしないので、正直いってあまり納得感はなかった。 とは言え、だいたいどこの現場でも経緯が分からんというケースの方が圧倒的に多い気がするので、それを考えるとこう振り切ることのメリットの方が大きい、ということだと思う。
なお、新人向けにシステムのことを理解してもらう際には、まずは管理画面を一回触ってもらうことで流れと項目が理解できるので、それとセットで動いているコードを説明するなどして全体像理解のスタート地点に立ってもらうとのこと。これは理解できる。
その他印象に残ったところ
SRE部門の解散の背景
（第1章 「fluct - 広告配信の舞台裏の技術者たち」より）
SSPを運用するfluct社で、2019年11月にもともとあったSRE部門を解散し開発部門に統合。その背景としてこんな理由があった。
- だんだん開発チームからSREチームに「依頼」するケースが増えていた
- DevとOpsが分かれていることは悪くないが、本来は同じ目的を共有するチーム間で「依頼」が発生するのは本意ではない
ビジネスと一緒に開発する
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
就活支援サービスを展開するサポーターズ社では「ビジネス側から言われたものをそのまま作ることはしない」姿勢を明言している。
- かつては社内受託のような形で「この画面をこういうふうに作ってください」という、アウトプットが規定された「依頼」が普通だった
- 今はそのような来た場合は「なんで？」と即座に返す
- 「なぜ」を聞いた上で当初の提案よりもコストのかかる実装（理想）を提案することもある
- 今すぐ結果だけ欲しい人にとっては「いまはそれは良いから、すぐにできることだけ話してくれ」と感じる
- 「ちょっとしたお願いを相談しただけなのに、なんでこんな大きな話にされて、いっぱい話さないといけないんだろう」
これは非常に「べき論」を地で行っているが、ビジネスの方が立場の強い会社だと開発側が負けてしまうし、開発側が強い場合はビジネス側が「開発は相談に乗ってくれない」と不満を漏らして二度と相談に来ないという結果を生みやすいので、如何に日々コミュニケーションを濃密に取ってお互いを理解しているかというのが伺えるエピソードだった。
ちなみに、このような相談の場合にケンカにならないために押さえておくべきポイントを言うなら、
- ビジネス側：背景をきちんと伝える、結果を急ぎすぎない（サクッと明日までに大体で良いから見積ほしい（でも上振れしないでねという圧）とか）
- 開発側：温度感を踏まえて聞く、むやみに話を大きくしない（エンジニアは「そもそも〜」で話を振り出しに戻して大きくする人が多い）
以上踏まえてお互いに落とし所を見つけることかなぁ、と自分の肌感覚では思っている。
依存ライブラリは週1で上げる
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
同じくサポーターズ社で、「ガーデニング」と称してフロントエンドやサーバーサイドの依存ライブラリを毎週最新化するという運用を行っているとのこと。
- 最新バージョンへの追随は一度やめると二度と復活できないので、1ヶ月ではなく1週間で実施
- 「ガーデニングガチャ」で当たった人が実施
- 週次で上げるのはマイナーな変更（既存コードの変更がないもの）のみ
- ライブラリを上げる作業自体はコード変更がなければ単純作業なので、ガーデニング作業そのものの大半はchangelogの確認
これは簡単そうにやっているようだが、実はすごいこと。そんなこまめに上げていたことないな...
最初の1,2回なんとか乗り越えれば、後はそれほど苦ではないのかな。
でもメジャーバージョンアップがあるとこのルーティーンとは別タスクでやらないといけないはずだから、そこは同じなのかな。
最後に
2章のことでたくさん書いてしまったため他の章の取り上げ方が雑になってしまったが、 他にもレガシーのシステムといかに付き合っていくか、改修とリプレースの判断はどうやって行うのか、など、外から見ると楽しそうにやっているWeb系企業の現場で直面する決して華やかではない、むしろ泥臭さしかない課題に対する取り組み方などについても臨場感の伝わる記述がされたとても熱量の多い一冊だった。開発現場を経験しているエンジニアならきっとよくうなずく箇所や「いやこれはちょっと...」と賛否両論の独り言になること請け合いなので、是非一度手にとって頂きたい。
