【感想】『Engineers in VOYAGE』：現場のエンジニアの航海記録 #voyagebook
事業をエンジニアリングする技術者たち
インターネット領域の事業開発企業として、Webメディアでもよく名前を聞くVOYAGE GROUP。ビジネスとエンジニアリングの両輪で活動しているエンジニアの生の声を届け、もっと知ってもらおう…ということで始まったインタビュー企画が『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』という本になったもの。ネット上でも反響が大きかったですね。インタビュアーはTDDでも有名なあのt_wadaさんの和田卓人さんです。
- 事業をエンジニアリングする技術者たち
- 第1章 fluct - 広告配信の舞台裏の技術者たち
- 第2章 Zucks - フルサイクル開発者の文化
- 第3章 VOYAGE MARKETING - 20年級大規模レガシーシステムとの戦い
- 第4章 VOYAGE Lighthouse Studio - 数十万記事のメディアをゼロから立ち上げる
- 第5章 サポーターズ - 事業の成長を止めない手段としてのシステム刷新
- 第6章 データサイエンス - エンジニアによるビジネスのための機械学習
- まとめ：VOYAGEする事業会社のエンジニアの今を知ることができる本
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち
- 作者:株式会社VOYAGE GROUP 監修
- 発売日: 2020/08/26
- メディア: Kindle版
発売を記念した同社ブログの記事がこちら。 techlog.voyagegroup.com
第1章 fluct - 広告配信の舞台裏の技術者たち
最初は傘下のfluct社、ウェブサイトを見たときに毎回動的に変わる広告を決定して表示するアドテクノロジーの裏にあるWebサービスを運営しているエンジニアたちの話。すずけんさん、あじよしさん、グループの取締役CTOの古賀さんが登場します。
★キャリア関係でも人に焦点を当てた話は割と見ますが、こういうアドテクノロジー関連の話というのは(自分の観測範囲では)あまり見かけないので、そういう意味でもコラムでの仕組みの解説なども含め興味深かったです。
★始まったのが2010年、まだクラウドもこれからという時代。AWSとGCPが主に登場しますが、徐々に各種クラウドサービスも充実してきて、クラウドやビッグデータ小史としても楽しめます。CloudWatch, BigQuery, Hadoop なども登場します。
★ある処理をAmazon EMRに処理させたら遅くてだめでBigQueryにしたら超絶速かったなんて四方山話も出てきます。第6章にも出てきますね。
★全てクラウドにしたらこんなに安くなった！的な話はよく見かけますが、このfluctは最初は完全オンプレミスからスタート、徐々にクラウドも入ってくるけど本体のサーバーの一部は高くつくのでずっとオンプレのままだそうで、へえと思いました。ものすごく性能の高いサーバーなのでしょうか。
★開発も最初はウォーターフォールで小さいサイクルの繰り返しから始まっていた、なんてあたりもリアルな泥臭さがあって面白い。
★技術の変遷に伴い様々なチャレンジが登場しますが「とりあえずやってみる」という文化が社内に既に浸透していたからできたというのがあって、やっぱり根底にこれは必要なのだなと思います。
★インフラと開発は最初から分けない方針があり、変遷あって最終的にはSRE部門も開発本部という集団にまとまったとのことですが、あーまさにDevOpsの考えを地で行っているなと。
★技術的負債の話もかなりリアルです。RDBのあるテーブルのカラムに設定情報用になんでも入るJSON形式のカラムがあって、フリーダムに使っていたら後々問題になった...という話、まさにt_wadaさんの本『SQLアンチパターン』を体現しています。これは分かります…XMLでもプレーンテキストでもなんでも、本来は予備用の使わない予定のカラムをなんかに使いだすとヤバいのぢゃ…
- 作者:Bill Karwin
- 発売日: 2013/01/26
- メディア: 大型本
★よく様々な言語の開発で「管理画面」というワードが出てきて、比較的業務システム寄りの世界に生息している僕にはいまいち分からなかったのですが本書でだいぶイメージが湧きました。広告のオーナーによって見たい情報が微妙に違い、それぞれの要求に応えられるよう管理画面を拡張してカスタマイズしていったらどんどん大変なことになってしまった...ということがあるのですね。
★PHPのおそらく5＋テンプレートエンジンのSmarty →PHP7.2＋軽量フレームワークのSlim＋フロントにReact というスタイルになったという話もなるほどなーと思います。Smartyは小さめの開発で自分は今も使ってます(笑
★負債の返却のやり方で以下の分類が登場します。
- 作り直し、リプレース: まるごとやりなおし
- リファクタリング: ファウラー本のあのリファクタリング。クラスやメソッドなど比較的小さいスコープで実施
- リアーキテクティング: リファクタリングに含まれるが、モジュールやサービス自体など、スコープがより大きめ
★別部分の負債返済でPHPで書いていたところをGoで書き直し、まずテストが書けるようにして保護しながら直して行く…というくだりは、本書にもありますがまさに『リファクタリング』『レガシーコード改善ガイド』の世界を体現していますね。
- 作者:ＭａｒｔｉｎＦｏｗｌｅｒ
- 発売日: 2019/12/06
- メディア: Kindle版
- 作者:マイケル・C・フェザーズ
- 発売日: 2016/01/15
- メディア: Kindle版
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 発売日: 2019/09/19
- メディア: 単行本（ソフトカバー）
★技術的負債の返却に必要であろう力に「腕力」というワードが出てきます。ニュアンスはなんとなく分かるんですが曖昧な言葉でもあります。
インタビュアーのt_wadaさんによると、負債の返却と直接関係ないところでも放っておかず、カッとなって全部まきとって人がやりたがらないところでも全部バーっとやっちゃう力。もうひとつは修正箇所のボリュームがあって単純作業ぽくてもめげずにやり抜く力…のような意味で使われています。
なんとなく分かるのですが、このエンジニアの腕力はこれぐらいだ…なんてふうに定量化するのは難しい能力値でもあるなあと思いました。
★まぬけなコードを書かない人(他人に読めるコードを書く、責任感がある人、任せられる人)は技術的負債を生み出しにくい…という話は納得です。
ここ数年で技術的負債はあらかた返却し最近は攻めに回っているとのことで、いやはや大したものです。広告配信の裏にも様々なドラマがあるのだなあと思いました。
イベントで同fluct社が登場する回もブログ記事になっています。
第2章 Zucks - フルサイクル開発者の文化
今度は1章のFluctとまた別の広告配信基盤Zucksの話。河村さん、前田さん、CTOの古賀さんが登場します。
★こちらは2012年開始、今度は最初からクラウド前提で最初からAWSを活用したという対比が面白い。
★こちらもインフラと開発はチームを分けずに行っているそうです。あとから問題発生時のログを収集できるなど、たとえば夜中に何かが起きても即時対応が不要な仕組みを作り上げているのが素晴らしい。
★2012年開発開始、2013年7月がリリースで最初は最低限、サービス開発界隈でよく聞く MVP: Minimul Value Product のワードが登場します。リリースは7/1の0時、その日だけが最初で最後の徹夜作業だったというのが印象に残ります。
★内部的なシステム内のコードネーム群がモビルスーツだったり、SHがShellでなく人の名前だったりdeliveryの略のdlvが使われたりしたのがずっと続いているなんていうこぼれ話もあって、あ～こういうのはどこの現場でもあるんだなあと思いました。プログラミングの格言の「名前重要」というやつですね。
★CTO自らが求人票を書いたり、エンジニア文化にはかなり力を入れてています。「フルスタック」は最初から最後までサービスを1人で作れる、フロントもバックエンドも全ての技術要素を知っているぐらいの意味で使われますが、ここでは「フルサイクル開発者」。
ビジネスアイデアが生まれてから顧客に届くまでが1サイクルで、これを1人でやりきれる、全ての技術要素を知り尽くしている必要はない…とのこと。こういう分類もあるのですね。
★守備範囲が広く、使っているプログラム言語の幅も広いそうですが、普段からキャッチアップできる能力をメンバーが持っているので問題ないとのこと。技術を固定化していると新しいものを導入したときに入れるのが大変になり、悲観的になってしまう方をリスクと捉えている…という思想にはなるほどと思ました。
規模の大きい会社はたいていこれが苦手なので、やはり少数精鋭の規模の小さい集団でないと実現しづらいのかなあと思います。
★大きい特徴として、メンテナンスに掛かる手間をマイナスと考えてドキュメントを残していないそうです。情報はGitHubのIssueに残っている過程の情報、Slackで既存メンバーからの情報伝達、コードが丁寧に書いてあればコメントに残る情報…と、ドキュメントがなくても回る体制でやっているとのこと。
僕もチケット駆動開発はやったことはありますが、ほとんどのプロジェクトはちゃんと清書されて改版され続けている設計書を使うのがほとんどです。SIer的でもありますが、このへんはプロジェクトの特徴やメンバ数やメンバの力にもよるのかなあと。
★新しく入社した人はその日のうちに簡単でも機能の改修をしてその日のうちにリリースまで行うという文化も良いですね。
★メンバーが十数人クラス、マネージャーも配置せず明示的なルールも少ない中でうまく回っている一方、この先人数的にスケールさせていくとそろそろ限界を感じてもいるとのこと。やはり少数精鋭のチームは強くても人間はオートスケールするわけには行かないようです。
懐かしのケント・ベック氏のエクストリーム・プログラミング(XP)の本が出てきて、幾つかのプラクティスが組み合わさってうまく回るという話が出てきます。様々な要素の一部分一部分が有機的に組合わって何か結果を生み出す、だから様々なことを試し続ける...というのもアジャイル的な進め方では大事なのかなと思いました。
- 作者:ＫｅｎｔＢｅｃｋ,ＣｙｎｔｈｉａＡｎｄｒｅｓ
- 発売日: 2017/07/14
- メディア: Kindle版
アドテクノロジーに縁がないこともあり1章のfluctとZucksの違いなどは正直よく分からなかったのですが(笑)、エンジニア文化の話関連が参考になった2章でした。
イベントで同Zucks社が登場する回がブログでも記事になっています。
第3章 VOYAGE MARKETING - 20年級大規模レガシーシステムとの戦い
今度はVOYAGE MARKETINGが運営している「ECナビ」という歴史ある老舗システムをいかに新しくしていくかの話。福田剛広さん、吉田祐一さんが登場します。
★エンプラ世界でもおじさんやエライ人達を震撼させているパワーワード「2025年の壁」がここでも登場！ うーんなじみ深い話です。なんとECナビは1999年スタートの20年もの、あのmixiと同じぐらい歴史があるというのが震えます。2015年頃からレガシーシステム改善の動きが始まります。
★最初のシステムの辛い状態がよくわかる。うーん自分が過去見てきたシステムでも全体設計やテーブル設計はレビューしてある程度きちんとしてしているものが多かったのでまだましというか、こういうのは急拡大を続けてきたシステムの方がもっと大変なのだろうなあと想像します。テーブル数1200というのがもはやパワーワード。
★最初は淡々と情報を集めて現状を把握していった、鉛の弾丸を撃っていったというのがまずはそうだよなあと共感します。リバースエンジニアリングしたらテーブル関連図が巨大なお花畑になって、あまり役に立たなかったというのもお察しします...
★そこから立体的に分析を進め、作戦としては少しづつ改善する「コツコツ改善」を3-5年かけてやっていく手法をとったとのこと。自分は業務システムだと過去全部作り直しの決定で進んだプロジェクトに参加したこともありますが、現在動いている重要サービスで大規模になるとやはりビッグリライトでなくこちらになるのかなあと。
★突破策の１つ目はインフラの全クラウド化、これを機にIaC(Infrastructure as Code)を徹底。テーブル1200を移行するのではなく300ぐらいに減らしてからAWSに移行したとのことで、OracleのEnterprizeライセンスのDBを安いものに変えてからAmazon RDSに変えてうまくいったという、興味深い話が載っています。
★突破策２つめがアプリのダイエットで、不要なテーブルと機能をなくしていく話。「問題の分母を減らす」「葬り」という面白い表現を使っています。
葬りにも３種類あって、コード葬り＜機能葬り＜事業葬り の順に規模が小＜大。
- コード葬り：普段の開発と並行して不要コードを消していく。Perlで、サーバーで実行されているファイルの情報をログで収集、使われていないファイルを突き止めて機械的に消す「葬り無双」という手法が紹介。
- 機能葬り：関係者と相談したりして機能自体を消していく。大変だったのはテーブルが密結合のものを解きほぐしていくところで、さすがにここではE-R図があったとのこと。
- 事業葬り：経営指標を基にしたデータを会議で提示して、事業自体をなくす
★うまくレガシーと戦えたコツは、技術的負債のデメリットや対応に時間を使う価値があることををエンジニア以外の人々も認識していたこと、完璧な計画にこだわりすぎずに柔軟に対応して進めてきたことのように読めます。ネットでもよく聞く「いい感じに」という表現がここでも出てきます。こういう話になるとやはり、結局のところはバランス感覚が大事なのだなあと感じます。
★テーブル数が1200から450まで減り、今後は300台を目指しながらサブシステムごとに刷新を続けて新しくしていくとのこと。自分的にはデブサミで聞いたのが記憶に残っている「式年遷宮」(しきねんせんぐう)のワードが出てきます。
★最後にレガシーシステムと付き合っていくスキルの話題があり、「誤解を恐れずに言えばSIerのスキル」だという話があってなるほどなあと思いました。確かに0を1にする力とは別種のスキルですね。もしも自分がこういう状況の中にいたら、それなりに力を発揮を発揮できそうだなあとチョット思いました。わははは。
テーブル総数1200からお花畑に葬り無双、強烈なパワーワードの多いこの3章は開発者からするとかなり身近な話題で、共感できる内容でした。
イベントで同VOYAGE MARKETING(VM)社が登場する回がブログ記事でも紹介されています。
第4章 VOYAGE Lighthouse Studio - 数十万記事のメディアをゼロから立ち上げる
今度は2015年開始の「神ゲー攻略」というWebメディア、コンテンツをビジネスにしている領域の話。蛯原さん、野崎さんが登場します。
★今は業界内TOPにも入っている「神ゲー攻略」も最初はゼロから、試行錯誤からスタートしたとのことで様々な苦労が偲ばれます。コラムにSEOはサイト側の対応は重要だが、本当のところは検索エンジン側でないと分からないことも書いてあってなるほどなあと思います。
★ゼロスタートで最初は静的サイトジェネレーターを自作したとのこと。記事を書いてGitHubに投稿するとクラウド上のCI/CDサービスであるTravis CIが動いてビルドしてHTMLを生成、AWSのS3に実体の静的HTMLを載せるとサーバーも不要で低コスト。さらにその手前にはAmazon CloudFrontがあり、ユーザに近い場所からキャッシュがデリバリーされてより速くページが見られると。なるほどコンテンツがメインのシステムでは、こういうアプローチもあるのですね。
★試行錯誤の時期はSEOを試すために機械的に大量生成した記事を載せていたこともあったとのことで、そんなこともやるんだ……となります。そこから進歩して、人を雇ってよいコンテンツ、中身で勝負するようになったとそうです。
★静的サイトジェネレーターを作ったは良いがコミット(push)のたびにビルドが走り時間がかかるようになり、その場では画面のプレビューもできない。次のアプローチは……今度はMarkdownエディタを自作。
Node.js中心にHTMLを作るビルドは当時よく使われたgulp、デスクトップでWeb技術が使えるようになるElectronを使って実現したとのこと。自分たちで作ってしまうというアプローチがすごい。
★コラムでCMS(Contents Management System)の解説があり、WordPressも使ってない身としては勉強になります。出来上がったコンテンツをWeb APIで吐くだけで配信時のUIは使う側で決められるものを Headless CMS というんですね。
静的サイトジェネレーター経由だと最初からHTML本体が出来上がっているのでパフォーマンスも良く、セキュリティ問題も(動的ページよりは)生じにくいというのも納得です。
★Markdownエディタもその後独自記法が進化してレーダーチャートなどコンテンツ特有のものも書けるようになり、まさにDSL(Domain Specific Language)になっていったというのも面白いですね。
★やがて記事が人気になってアクセスが14倍になった日も普通に温泉に行っていたとのことで、Amazon CloudFrontだからスケールも気にしなくてよいわけですね。こういうケースでクラウド任せにできるのは強いですね。
★コンテンツも伸びた後、1日50回もビルドするようになって問題になったのは静的サイトジェネレーターのビルド時間がかかること。これにはコード部分と記事を分けて処理をすることで解決したそうです。
こういうコンテンツだと記事にコメントが書けるというのは想像がつきますが、意外にも神ゲー攻略には最初はコメント機能がなかったとのことで、ここでAWS以外にGoogle Cloud Platformが登場します。GAE(Google App Engine)を使い、コメント数一覧とコメント本体を返すだけのAPIサーバーを別に立てたとのこと。
オートスケールしてくれるのでGAEを選んだということで、ここはAWSだけで完結させるならAPI Gateway + Lambda関数などでもいけるのでは?という気もしましたが、いろいろ事情がきっとあるのでしょうか。
★既にGitHubにプッシュされた記事数も15万(!)で限界、現在はアーキテクチャ見直しの段階まで来ており、今度はブラウザ上で記事を書いてMySQLに格納する構造に変えている途中だそうです。最初からRDBに格納する手法もありますが、静的サイトジェネレーターを使ったからこそここまで来れたというのもあるのでしょう。
続けるうえで大事にしてきたこととして、最初からPaaSのような高いものを使わずにシステムのランニングコストを減らす、作りすぎない。自分たちの意思決定が間違っていることも想定して進み、だからこそ撤退したり新しい仕組みに作り直したりしやすくなっている...という話が最後に載っています。
こうしたことを考えながら来たからこそ、柔軟にやり方を変えながら進んでいけるのですね。物事の解法は一つではないのだなあと改めて思います。自分には縁の遠い領域の話でしたが、勉強になる章でした。
『神ゲー攻略』サイト。本章を読んだ後でアーキテクチャ構成図を思い浮かべたりしながらサイトの方を見ると、この記事の後ろにこんな仕組みが……となって楽しいです。
また本章で語られている記事配信システムの構成周りのもっと深い話やイベントについても別途ブログ記事になっています。 techlog.voyagegroup.com
第5章 サポーターズ - 事業の成長を止めない手段としてのシステム刷新
5章は学生向けの就活支援サービス『サポーターズ』を巡る話。ねこやさん、かぬーさんが登場します。
★こうしたサービスはBtoBとBtoCの両方の特徴を併せ持つというのは言われてみると納得しますね。BtoBだったら顧客の要件を聞いて古いブラウザに対応したり、制限をかけてブラウザを固定したり。一方BtoCは利用者の比率によって変えていくとのことで、『サポーターズ』は徐々にモバイルデバイスの比率が高まったそうです。
★最初は2012年頃に外注で作ってもらったシステムで、問題が多々あれど最初は様子を見ながら使っていたとのこと。
正規化が不十分でDBの複数テーブルに項目が重複している、登録した年代によってデータが不正、レコードがユニークのはずが複数行返ってくる、varchar(1)とかで入れる値の範囲が決まってるのに違う値が入っている、その値を読み取るプログラムのロジック側の判定もまちまち....というあたり、まずい雰囲気がよく伝わってきます。(笑
エンタープライズ開発でもまともなプロジェクトなら時間がかかってもまずレビューで弾いてこういう問題は防ぐので、スピード優先で開発したり十分な受け入れテストなく発進するとこうなってしまうのかなあと思ったりします。
このケースでは運用サイドが強くて、内部のバグを利用してうまく使い続けていたというのも面白いですね。
★自分たちの業務として向き合っているシステムに、自分たちがエンジニアとして誇りを持てない状況だった...というのも共感します。やはり自分たちで作ってこそナンボですからね。
★DBを見ればどんな業務の組み立てをしているのかイメージできる…という話があり、RDBをよく使う身としてはこういうのも納得します。
★そんな問題の多かったサポーターズの再建は、まずはヒアリングから。使うビジネス側の人とオフィスが離れていたとのことで週一で来てもらい、話をよく聞いて小さく作り直すスモールスタートから。既存のシステムを使いつつ、2021年卒向けだけに MVP: Minimum Value Product で小さなシステムを再起動したそうです。
★ユーザーの入力項目も減らし、世の中の変化に合わせて性別も必須でなくしたなどというあたりはなるほどなあと思います。
システムの仕様を一度決めて作ったらもう変更禁止ではなく、これからも変えながら拡張して育てていけるものであることはビジネス側の人にも何度も説明したとのことで、確かにアジャイル的なアプローチに変えると最初はそういう反応が来るだろうなあと思います。
また、以前はビジネス側から新要件を依頼されたら調べて可能ならその通り実現して終了だったのが、今は必ず開発サイドからなぜそうしたいのか理由を聞くように変わったとのこと。開発者の立場であればもっとよい方法を考えつくこともあるからですね。まさにビジネスとエンジニアリングが一緒になった瞬間だなあと思います。
★新システムは技術的にはサーバーはなんとScalaで仕事はあくまでAPIサーバー。フロントエンドはTypeScriptでReact+Redux、Pythonもちょっとしたことに活用、インフラはすべてAWS上。
サーバーの受け入れテストはNode.jsのJavaScriptでやっており、実装から距離を置くことで独立性を保っているとのこと。こういう複数言語の使い方もあるのだなあと思います。
★エンジニアは現状6人体制、情報はドキュメントでなくGitHubのissueにまとめることが多いとのことでここは今風。依存ライブラリのバージョンアップを毎週頑張っているとのことで、「ガーデニング」と呼んでいるそうです。
★学生さんのモバイルアクセスはiOSが多くAndroidは少ないとのことで、これからはiOS版アプリを開発予定とのこと。サーバーはAPIを返すだけにしているアーキテクチャだからこうした拡張もできるわけですね。
ようやく事業の成長スピードにシステムが追いつける状態になった…というサポーターズ。5章は自分の領域と違うものの割と身近で想像しやすい内容で、事業とエンジニアリングの調和が成長に結びつくのだなと感じました。
第6章 データサイエンス - エンジニアによるビジネスのための機械学習
最後はMachine Learningの話。2章に出てきたZucksに機械学習による意思決定を取り入れつつ、あくまで軸足はエンジニアとして活動している西林孝さんが登場します。
★現状データサイエンスをやってる部署もなし、西林さんも別部署から異動、個人で学習したりブログ発信していたのがきっかけだそうです。こうした活動がチャンスに繋がるのはよく聞く話ですね。
テクノロジーに強い人を引っ張ってくるのではなく、事業を理解した上で技術を適用する力がある人を投入するそうで、このへんは事業会社らしいなと。
- 作者:C.M. ビショップ
- 発売日: 2012/04/05
- メディア: 単行本（ソフトカバー）
- 作者:C.M. ビショップ
- 発売日: 2012/02/29
- メディア: 単行本
★よくデータサイエンティスト略してDSと呼ばれたりしますが、インタビュイーの西林さんは肩書は「データサイエンスエンジニア」だそうです。偉い人にもっと偉そうな肩書を望まれたこともあるそうで、このへんちょっと面白いです。こういうエンジニアの肩書っていろいろありますね。
★技術的には最初は大量データがAmazon S3にデータがあるだけ。まだ Amazon Athena でSQLが発行できるようになる前の時代で、Amazon EMR も試したりしたとのことですが、その頃Google BigQueryが話題になりGCP導入。配信ログをBigQuery側に流してそこからSQLを発行して中身を見られるような仕組みをまずは整えたとのことです。確かにクラウドエンジニア寄りの仕事ですね。
データサイエンスとエンジニアの間のスキルにまだまだ距離があるという話は、2010年代に生まれた新しい職業であることもあってまだまだ過渡期なのだなあと思います。
★広告配信ではもう機械学習を取り入れるのが当たり前になっているそうです。クリック率を予測しても嬉しくないケースがあるのが分かった、人間が頑張っている所に予測モデルを中途半端に使っても実は結果は改善しない、機械学習でロジックをいれたら利益が減少するパターンもあった...などの試行錯誤の話を読むと、機械学習も単にやればいいわけではなく奥が深いなあと思います。
★データサイエンスの面白さはやはり、モデルを作るのが面白いとのこと。作ったモデルが間違っていることもあり、仮説を立てて予測器をいろいろ作ったりして自分たちの状況にマッチするモデルを作れたときが嬉しいそうです。
ある予測モデルを使い出すとそれによって未来の得られるデータが変わってしまうこともあり、この問題が論文にもなっているという話を聞くとこの世界も本当に奥が深いなあと思います。
★データサイエンスを学んだだけだと限界があり、エンジニアリングスキルもあったほうが実務では役立つという話もあり、このへんの話は学生さんにも役立ちそうですね。
★自社のアルゴリズムはまだまだ発展途上であることもご本人が最後に語っており、最終的な意思決定は人間が考え続ける必要があるという話が最後にあります。よくAIが人間の仕事を奪う～云々は単純な文脈で出てきますが、機械学習はそんな単純な訳ではなく広く奥深い世界なのだなと改めて思います。
6章はなかなかアカデミックな内容も入っていて専門的なところは難しいのですが、事業における機械学習の活用の実際の雰囲気が知れる内容でした。
西林さんはこの記事の方ですね。
公式ブログでも関連記事があります。
まとめ：VOYAGEする事業会社のエンジニアの今を知ることができる本
自分にも刺さるところが多く、勇気や活力をもらえる非常にエキサイティングな本でした。印象に残るところというと、すぐやってみるエンジニア文化や当事者意識、よりよくしていくことへの会社からの理解、技術的負債の返済における短期決戦と長期作戦の2パターン、技術だけでも駄目でビジネスだけでも駄目で事業とエンジニアリングのうまい調和、柔軟に考え方や作戦を変えてうまくやっていく力、様々な技術的解法による問題解決……などでしょうか。
ネットの感想では生々しい、ここまで公開していいのかという反響が多かったそうですが、実地のITエンジニアからするとうん実際はこんなものだよねという感じです。こういう泥臭いところも良いです。
脚注も各章についていますが技術用語はけっこうバンバン出てきます。とはいえ雰囲気でもある程度分かるので、現場の空気感に満ちたインタビューは様々な立場の人が読んでそれぞれ面白いと思います。
自分のような開発の現場にいるエンジニアにとってもそれぞれ刺さるところがあるでしょうし、エンジニア志望の学生さんにも参考になるでしょう。ビジネス側の立場の方や人事・採用担当の方にも理解が深まると思います。
僕は事業会社でなくSIerと思われてるであろうITベンダー、しかしその中でもザ・SIer的というわけでもない中間帯域でゆらゆらとエンジニアリングをしていますが、共感できるところも多かったです。
1章と2章はアドテクには縁は遠いけど進め方や文化が分かる章。3章のレガシーシステムとの戦いがめっさわかりみNo.1の章(笑)。4章の神ゲー攻略と5章のサポーターズが、領域的には違うけど仕組みが想像できるので共感できる章。6章の機械学習がMLには触ってないけど奥深さが改めて分かった章という感じでした。
現場のエンジニアリングの情報を伝えるコンテンツというと、これまで個人やキャリアを焦点に当てたインタビューなどはよく見かけますが、こうした事業に焦点を当てた本というのは、本書冒頭にあるようにGAFA＋Mのようなレベルを除くとあまりないように思います。そういう意味でも面白い本でした。いろんな会社や様々な事業がこういう話を公開していくと楽しくなりそうですね。
本書に頻出する3テーマである 生々しさ/技術的負債との向き合い方/事業のエンジニアリング や、各所の感想リンクをまとめた記事。 techlog.voyagegroup.com
技育祭を祝っての若手エンジニアの成長の記事も面白かったですね。CTOの小賀昌法さんの来歴を拝見するとフリーランス、その前がヤフー、その前の90年代に意外にもお堅くNECネッツエスアイが出てきてへえ〜となりました。 techlog.voyagegroup.com
