どう考えてもこの３連休で読んでねっていうタイミングでの発売 & 献本 (小賀 @makogaさんありがとうございました) だったので、感想も覚えてるうちに書いておこうと思います。
この本はなに
書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売 #voyagebook
VOYAGE GROUP techlog にてまえがきがまるっと掲載されているのでそれを読むのがベストだと思いますが、どんな形式の本かといえばVOYAGE GROUPが持つ6つの事業について、そこに関わるエンジニアのインタビューをまとめたものになります。
本書は、そのようなVOYAGE GROUPのさまざまな事業やサービスを牽引するエンジニアに2020年1月から2020年5月にかけて行ったインタビューを1冊の書籍としてまとめたものです。事業をエンジニアリングの視点で考えたり、さらにはエンジニアリングの視点で事業を作り出したりと、「ビジネス」と「エンジニアリング」を両輪にしてITシステムを開発・運用しながら実社会で活躍している技術者や技術者のチームの生の声をお届けします。
僕個人の解釈でいうと、この本では事業でも技術でもなくそこで日々行われる「エンジニアリング」という活動にフォーカスして書かれている本だと感じました。エンジニアリングの本といえば特定の技術やテクニックについて深く解説した技術書が多いですが、この本では「ビジネス」に対して「どうエンジニアリングをしてきたか」という経験をインタビューという形で文章化されています。
えてして技術カンファレンスの発表だと(時間の制約もあって)「最新の上手く言った話」が強調されている気がするのですが、この本では時間の経過の中での「上手く行かなかった話」も多くあり リアルなエンジニアリングの本 としての情報がつまっているように思いました。むしろリアルで生々しいがゆえに感想をどういう切り口で書けばいいのか悩みました。
この本は何ではないか？
この本には多くの技術的なキーワードが含まれていますが、前述の通り「特定の技術を解説した本」ではありません。そういう意味では、エンジニアがこの本を読んだ次の日からコードの質が上がるというものではないです。
また、エンジニアリングのベストプラクティス本でもありません。タイトルに「事業をエンジニアリングする」と書いてありますが、具体的に「これをせよ」という話はでてきません。逆に言えばそれ自体がこの本の一番の価値だと僕は感じたのですが、人によっては「分かりづらい」本に見えてしまうかもしれません。
感想
前述の通り、この本には「特定技術についての知識」や「エンジニアとしてのベストプラクティス」が明示的に書かれているわけではありません。(パッと見)
というより、紹介されている各事業のビジネスモデルや事業課題、歴史がバラバラなので話がまとまりようがないんですよね。例えばfluctとZucksは大きくはネット広告/アドテクのビジネスですが、それぞれSSPとDSPとして立ち位置が異なります。VOYAGE MARKETINGのECナビとVOYAGE Lighthouse Studio（VLS)はどちらもメディア事業ですが、会員制と非会員制という違いがあります。そして、サポーターズは就職活動の支援サービスでこれまでのサービスとはまったく違う事業ドメインだったりします。
また時系列でみるとECナビは1999年、fluctが2010年、サポーターズが2012年、Zucksが2013年、そしてVLSが2015年です。第6章のデータサイエンスは事業単体ではないですが、2015年からとあるので時系列でいえば最も新しい取り組みの部類だと思います。ECナビを除けば残りは５年の間にできたサービスたちですが、たとえばVLSで使っているTravisCI(僕の記憶ではフルマネージドなCIとしては最初期)は2012年のスタートで、fluctなどでは当時使うべくもないんですよね。TravisCIやAWSはじめ5年の間にかなりの技術的変化があった時期だった気がします(当時の記憶として)
ビジネスが異なりそれが生まれた時代(作られてからの時間)も異なるのならば、そこで求められ使われる技術やエンジニアリングのアプローチも変わってくるわけで。例えばZucksでは「ドキュメントを書かない」ことを是としているのに対し、ECナビでは現状把握のための資料が多く生まれている様子でした。また、(当時)約15年ものだったECナビは作り直しをせずに時間をかけて改善した一方で、サポーターズは7年目?の2018年に作り直しの意思決定をしています。
全体をかいつまんで読んでしまうとどこもやり方がバラバラで、「事業をエンジニアリングする」とは何なのかが分からなくなります。そういう意味で、「分かりづらい」本に見えるかもと感じてしまったわけです。
全体からみえてくること
一方で、各事業部のバラバラなアプローチの中にもいくつか共通している部分もあるように見えました。
１つは「既存システムの課題/ボトルネックをきちんと見極めて改善をしている」ことです。VLSのエピソードがとても分かりやすいんですが、ビルド時間の増加=記事公開までのリードタイムの増加というボトルネックが先にあり、そこに対して専用エディタの開発や、サイトジェネレータと記事のビルドの分割を通して解決しています。
fluctの管理画面の話や、サポーターズの運用でカバーの話などもビジネスを含めた顕在化した課題があって、それを解決することを繰り返してる話だと感じました。
エンジニアが勝手に考えた「キレイなシステム」とか「最強のシステム」ではなく、ビジネスと照らし合わせた上で解決すべき課題を定義して改善するという進め方が全体としてあるように感じました。(もちろん課題を前に解決する時間がないとか、解決する技術力がないっていうシナリオもあるし、いつ解決すべきかという別の難しさと戦わないといけないのですが)
そして、もう1つ特徴的だなと思ったのが「エンジニアがリスクヘッジをしている」ということです。ここについてはZucksがとても明確で「重要なのは切り戻しができるかどうか」と節になってるくらいです。またサポーターズの作り直しでも、既存システムで延命するオプションを持っていたエピソードが書かれています。
エンジニアであれば「サービスが止まらないようにする」ことの重要性は理解しているし、日々gitを使って開発している人なら、いつでも戻せることのありがたさはわかっていると思います。ですが、こういったインタビューの場面できちんと意識して話せるということは、それ自体がエンジニアの価値観=文化として根付いているのではないかと思いました。
この本から学べること
ということで、結局この本を読んでわかるのは「銀の弾丸などない」という当たり前のことだと思います。
(もちろん、きれいなコードを書くとかテストを書くといった当然のプラクティスはあると思いますが)
「ビジネスまでの広いスコープの中で課題を見つけ、適切な解決策を考え、解決していく」
言葉にすれば平易なんですが、実際は"言うは易し行うは難し"です。「3,000行のPHPのコードをリファクタリングする」とか「1,200行のテーブルやシステムの構成図を起こし続ける」とか「分析のための基盤を作るところから始める」とか、解決のために相当の泥臭いこともやらなければいけないことがあるわけで。
そして、エンジニアである以上"腕力"も伴っていないといけません。
それをリアルなエピソードとして読むことで、ある意味では嫌な現実を再確認し、またエンジニアという仕事の価値を思いだすことができました。
いい話なんだけど、「いい話だ。」と一言では片付けられない感じのグッと来る感じ。
そんな読後感でした。
余談 : エンジニアという職業について
「エンジニア」という職業と「デベロッパー」「プログラマー」という職業の違いを時々考えるのですが、この本を読んでちょっと思うところがあったので吐き出しておきます。
「エンジニア」という言葉、日本だとわりといろん職業に対して使うのですが、国によっては「工学士」の学位を持つ人と明確に定義されていたりします。つまり「工学 = エンジニアリング」の専門的知識と技術を身につけている(体系的教育を受けた)人のことになるわけですが、Wikipediaによると、工学はこういう説明がなされています。
工学とは数学と自然科学を基礎とし、ときには人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である。
ここの解釈は人それぞれだと思うので特に人に押し付けるつもりはないのですが、自分の場合は「数学や自然科学の知識を基礎として社会を良くする」ことだとざっくり考えています。で、そのアプローチとして「いくつかの評価尺度にもとづいて、計測により現状の課題や解決策の評価をして、それを現実に落とし込んで社会に提供し良くしていく」こと。それがエンジニアリングする者 = エンジニアなのかなと。
何が言いたいかと言うと「社会を良くする」っていうのは「ビジネスとして社会に価値を届ける」ということであって、エンジニアをエンジニアたらしめるものはそこなんじゃないかと。そしてそのための方法が「プログラムを書く」以外の時もあるかもしれなくて、その時にちゃんと必要な解法を実践していくことがエンジニアの価値なのだと思っています。(ソフトウェアエンジニアとかで絞るとまたちょっと意味変わるのかもしれませんが)
まさに今回の感想の部分です。
そういう意味で、今回のこの本のタイトルが「事業をエンジニアリングする」というになっているのは、僕にとってもとてもしっくり来る表現で良いタイトルだと思いました。
まとめ
サクッとまとめるつもりがだいぶ長文になってしまいました。
さいごに、どんな人がこの本を読むと良いのか軽く挙げてみようと思います。(わかりやすい本ではないので難しいのですが)
1つは、これからエンジニアを目指す人。
それは学生かもしれませんし、社会人でこれからエンジニアに転職しようとしてる人かもしれません。いずれにしても「現場のエンジニアが何を意識しながら日々エンジニアリングをしているのか」をこの本から感じ取れると、将来役に立つかもしれません。
2つ目は、若手のエンジニア。(若手と言ってる辺り自分はもうおじさんの部類なんですが)
実装だけではなくて、ビジネスを理解しながらシステムを設計・開発・運用していく本書で言う「フルサイクルエンジニア」がどういうものか今後のキャリアアップの助けになることは間違いありません。
ちなみに、本書の脚注はエンジニアが知っておく知識の宝庫です。本を読んでピンと来なかった人はここに出てくる資料を片っ端から読むと良いのではないでしょうか。(僕も読んでない本がありました)
最後に、中堅以上のエンジニア。
レガシーなシステムの改修とか、胃が痛くなるようなつらみの話って酒の肴として最高ですよね。本書片手にオンライン飲みでもやるともあり上がりそうです。
以上 #voyagebook の感想でした。