0. はじめに
こんにちは。都内でエンジニアをしている、@gkzvoiceです。
今日は『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んで印象に残ったことなどを書いていきます。
>VOYAGE GROUPは、(略) 強くしなやかなエンジニアリング文化を備え自分たちで問題を解決しながら日々前進している企業だと思います。その意味では、「あれらの企業はそもそも特別すぎるから」という先入観から離れ、より現実的で模倣可能なエンジニアリング文化を本書から読み取ってもらえるはずです。
— GakujiTamaki@July Tech Festa運営スタッフ (@gkzvoice) August 7, 2020
本読書メモをお読みになっていただく前に
-
本記事は表題のとおり、
「書評記事」と言えるほど考察まで踏み込んだ内容になっていない- 理由としては、私はいわゆるオンプレミス上で動く社内システムを開発するエンジニアであり、VOYAGE GROUP社が手がける開発案件と同程度のミッションクリティカルな開発案件に携わったことがないために、現場の方のひとつひとつの行動の取捨選択の背景まで考えを巡らせることが難しいと感じたためです。
- とはいえ、そのようなミッションクリティカルな開発案件に携わったことがないからこそ、**
本書から学んだこと、疑問に感じたことをスナップショットとして大切に文字に残すことで、再度「考察」にチャレンジできるようにするべきではないか？と考え、読書メモ**として、アウトプットすることとしました。
-
本記事では第1章だけ取り扱うこととし、記事の公開を優先することにした
- 表題に掲げたとおり、本書は自分にとって学びがてんこ盛りの一冊でした。
- そのため、一行一行、自分のなかで咀嚼して、ときには以前読んだところまで戻ることもありました。
- 一方で、本を読んでそのとき感じた気持ちをできるだけ早く共有したいとも思い、本記事では第1章だけ取り扱うこととし、記事の公開を優先することにしました。
1.本書の目次
- 第1章 fluct：広告配信の舞台裏の技術者たち
- 第2章 Zucks：フルサイクル開発者の文化
- 第3章 VOYAGE MARKETING：20年級大規模レガシーシステムとの戦い
- 第4章 VOYAGE Lighthouse Studio：数十万記事のメディアをゼロから立ち上げる
- 第5章 サポーターズ：事業の成長を止めない手段としてのシステム刷新
- 第6章 データサイエンス：エンジニアによるビジネスのための機械学習
2. 本書のおすすめポイント
2-1.読者を選ばない
- 本書では対象読者として、以下の方々を取り上げている
- インターネット上で事業を営んでいる企業に属しているエンジニア
- 受託開発を行っているエンジニアの方々
- ビジネスを営んでいる方々
2-2.本書は読者を選ばないと考えた3つの理由
-
- 取り上げるシステムが千差万別
-
- スマートな理論の解説にとどまらず、**
泥臭くて普通の書籍では埋もれてしまう「腕力、調整力、洞察力」**まで取り上げられている
- これらは本書の「おすすめの読み方」でも記載されている。
- スマートな理論の解説にとどまらず、**
-
- 【私の考え】業界用語の説明や技術の変遷に関する解説から事例までページが割かれていること
- 例）「第1章 fluct：広告配信の舞台裏の技術者たち」のアドテクノロジーの解説
- 例）「オンプレミスv.s.クラウド」の技術選択の議論の焦点をVOYAGE GROUP社の事例で解説
3.印象に残ったこと
3-1.技術選定をしない技術選定
「このチームには採用という明確なプロセスもない」というのが正確かもしれません。「とりあえずこんなの作ったから使ってみて」とか「とりあえずログをあげておいたから使ってみて」と言えば、誰かが応じてくれるんです。 BigQuery にしても、誰かに「検証のためにまずは GCP のアカウントが欲しい」とお願いしてから始まるのではなく、「やってみたら便利だった」と言って、そのうちみんなが「じゃあ使うか」となった感じです。そういうノリがあるチームです。
-
権限周りやコスト管理の面でも、「とりあえずやってみる」の気持ちを押し殺さないような取り組みがされている印象を受けた。
-
ただし、**
「とりあえずやってみる」＝「開発者個人によるゲリラ的なアプローチ」**は”イケイケドンドン”な感じでもなかった。- たとえば、左記に引用した、BigQueryは、本番採用と判断するまでに要した期間は3年程度とのこと。
なぜ印象に残ったのか
- このようなアグレッシブさと冷静さといった、一見相反する要素が共存している。
相反する要素が共存している要因を考えてみた
- **
「とりあえずやってみる」＝「開発者個人によるゲリラ的なアプローチ」**をする役割の方と、その取り組みを踏まえて判断する役割の方が別々にいる。 - ただし、両者は異なる目標に向かっているわけではなく、同じ目標に向かい、そしてお互いがお互いの取り組みを理解し、尊敬している。
- ”ディベート”のようにロールで業務設計されているのかも。
3-2.技術的負債の返済に必要なことは腕力
※前提として、本書では、技術的負債の返済に必要なこととして言わずもがなですが、技術力も挙げています。
- 技術的負債の返済に必要な腕力とは
関係ないところに手を出す力、放っておかない力、というのがまずあると思います。重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、カッとなる力、放っておかない力が必要です。そのうえで、それを短期間で仕留める力ももちろん必要になります。率直に言うと、技術的負債を返済できる企業とできない企業があるのは、この腕力の有無によるという面も否定できません。
- その腕力はVOYAGE GROUP社で身につけたと話題になり、その身につけ方/育成方法について
育て方でいうと、手順を教えるわけではなく、まずカルチャーを教える、という面はあります。それも、カルチャーを教えるというよりは、雰囲気で知ってもらうことを意識しています。そうしてカルチャーを知ってもらえれば、それをもとにスキルが身についていく、という方向性です。そのため、できることを増やしていってスキルを身につけてほしいという方向ではなく、カルチャーの中でいい仕事をしてほしいという方向でメッセージを出しているつもりです。
なぜ印象に残ったのか
- 技術的負債≒「技術的な観点を差し置いても、ビジネスサイドの観点から改修したくてもできないコード、設計」を片付けるには、技術力とは別のものが必要そうだと感じることがあった。
- そして、技術的負債を片付けるうえで技術力以外に必要なことである、**
腕力**は、VOYAGE GROUP社の
何か返済できそうな負債に気づいたときに、それを「やっていい」と思える環境
が育んだというお話はスゴイなと感じた。（マネできるのか！？）
深堀りしたいこと
- **
腕力**を発揮すること（重要だけど緊急ではないと思われがちなところに対して、一気に片付けていく取り組み）は、ときには必要であり、奨励されるべきであると理解してもらうカルチャーを根付かせた方法
さいごに
- 第2章以降の読書メモは未定です。
- 読書メモを公開できるほど考えを整理できるか分からず。。