そーだいなるVOYAGE GROUPの裏側 #SPZ 事業の成長を止めない手段としてのシステム刷新

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第六回の今回は「事業の成長を止めない手段としてのシステム刷新」と題してサポーターズ(以下 SPZ )のみんなとディスカッションしてきました!

f:id:voyagegroup_tech:20201120140132j:plain

 資料の中にSPZの紹介やパネラーの自己紹介もあります。

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。

今回はビジネスサイド代表で参加したpiroさんから、素晴らしい発言が連発でしたね! 特に私はこのセリフには感動しました。

 チームの信頼関係が要所要所で感じられるいい話でした。 ぜひみんなも見てみてください。

感想

 今回はSPZのお話でした。 フルリプレイス、完遂するのはとても難しく、また完遂しても満足できる結果にならないことは珍しくありません。 それほどフルリプレイスは難易度高く、勇気が必要な決断なわけですが、サポーターズも例に漏れず、一度失敗しています。

 その経験を活かした二度目のチャレンジがなぜうまく行ったのか。その理由が余すことなく見えた回だったなと思います。

 よく言われるフルリプレイスのタイミングで捨てる、だけではなくて、チームの信頼関係や文化も合わせて一緒にリビルドしたのは素晴らしいですし、大事な知見ですね。

 そして会のあとにパネラーの @nekoya さんが大事なことをツイートしてたのでそちらも紹介します。

 常に他者に対するリスペクト、サービスに対するパッション、そしてメンバーに対するトラストを感じる、サポーターズのみんなと一緒に働いてみたいなって思ってしまうようなウィットに富んだ回でした。 ぜひみなさんもご覧ください。

次回予告

 ついに次回のそーだいなるVOYAGE GROUPの裏側で 最終回 です! 総集編と題して、本の中でのインタビュワーである @t_wada さんとVOYAGE GROUPのCTOである @makoga さんと3人で各章を振り返っていきます。

 そして最終回は夜から開始で特大版、質問も大募集しますので、みんなも過去の動画を見て、復習しましょう!!!

f:id:Soudai:20201120114544p:plain

voyagegroup.connpass.com

 最終回もサービスサービス♪

techlog.voyagegroup.com

PR枠

 エンジニア本大賞にもノミネートされてるので良かったって思った人はぜひ投票よろしくおねがいします!

そーだいなるVOYAGE GROUPの裏側 #DS エンジニアによるビジネスのための機械学習

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第五回の今回は「エンジニアによるビジネスのための機械学習」と題してデータサイエンスチーム(以下 DS)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201109134244p:plain

当日の紹介資料

 資料の中にDSの紹介やパネラーの自己紹介もあります。

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回は機械学習を専門に扱っていないエンジニアでも楽しめる内容でしたね。

 西林さんとところてんさんのわかりやすい解説は必見です! おすすめポイントである、そーだいさんの「なるほど…(わかってない)」を探してみてください。 今回は七色のなるほどが炸裂しています。

感想

 今回はZucksのDSのお話でした。 特にソフトウェアエンジニアとデータサイエンスの橋渡しについて、参考になるところも多かったのではないでしょうか。 Zucksはサバンナと第二回でも話題になりましたが、DSも例外ではありません。 Zucksの中でデータサイエンスをするというのは機能を選定し、モデルを考え、自分たちで実装して、そして運用する。 フルサイクルエンジニアであるからこそ、データから実装までコントロールできる強さを感じました。

 機械学習エンジニアは共感の嵐、ソフトウェアエンジニアとしても学びの多い回でした。 ぜひ、みなさんも見てください!!

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は サポーターズ です! 「ドアノブを回すと風呂の底が抜ける」そんなパワーワード満載のリプレースを乗り越えたサポーターズ。 事業責任者も巻き込んだパネルディスカッションは盛り上がること間違いなしです!

 みんなも気になるフルリプレースの裏側とその後、赤裸々に切り込んでいきます。

voyagegroup.connpass.com

 見知らぬソースコードに苦戦するサポーターズ。そこに現れたのは…次回「発進!サポーターズ」この次も!サービスサービス♪ 次回のサポーターズ回もよろしくおねがいします!

techlog.voyagegroup.com

そーだいなるVOYAGE GROUPの裏側 #VLS 数十万記事のメディアをゼロから立ち上げる

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第四回の今回は「数十万記事のメディアをゼロから立ち上げる」と題してVOYAGE Lighthouse Studio(以下 VLS)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201027132206p:plain

当日の紹介資料

 資料の中にVLSの紹介やパネラーの自己紹介もあります。

speakerdeck.com

 また当日話題にしたSSGからSSRにリプレイスしていった実際の中身について えびちゃん @co3k がまとめてくれています! SEOの知見やSSRの知見を赤裸々に綴ってくれていますのでこちらもぜひご参照ください。

techlog.voyagegroup.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回は「アウトプットとフィードバック」が裏テーマだったと思います。 人を育てるということ、事業を前に進めること、共通してアウトプットを素早く出して、早く結果を出し、そのフィードバックを受け取った上で改善してまたアウトプットを出す。 このサイクルを如何に早く回すかに勘所があるなと学びました。

 リーンスタートアップやMVP*1と同じような文脈ではあるのですが、実際の赤裸々な体験談と共に聴くと、より実感できる内容でした。 特にプルリクエストに対するコメントの話などは同じく育てる側の人たちにとっても学ぶところが多かったのではないでしょうか。  

感想

 今回は事業を0→1にするために技術で問題を解決していく話でした。 その中で前述したとおり、小さくアウトプットしてフィードバックを早く受け取るのが肝要というのは多くの人にも共感する部分なのではないでしょうか。

 また @makoga さんの意思決定のコツも知見の詰まった素晴らしい話でしたね。 私もCTO時代はこの視点をとても大事にしていたので共感がとてもありました。

 ちなみに意思決定に時間がかかるような決定事項に アーキテクチャの決定 があります。 そう考えるとVLSがSSG*2からSSR*3に移行する決断をするのに時間をかけたのも納得できます。

 今回はこれからの自分のエンジニア人生に大切なことがたくさん詰まった回でした。 ぜひ、みなさんも見てください!!

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は DS*4 です! 機械学習がブームからコモディティ化してきた昨今、如何に実務でデータを活かしているか?という視点で現場の声を聴いていきたいと思います。

 しかも今回は特別ゲストで @tokoroten さんの登場です! 機械学習に興味がある人はもちろんのこと、データサイエンティストじゃなくてもソフトウェアエンジニアなら必見の内容間違いなしですよ。

 私も自分の知らない領域の話を深堀りできるのでとても楽しみな回です!!

voyagegroup.connpass.com

 行き過ぎやりすぎストライク、すでにターキーまで行っちゃってるへっぽこ実験アニメ「VLS」 次回のDS回もよろしくおねがいします!

techlog.voyagegroup.com

*1:Minimum Viable Product: 必要最小限で製品をリリースする

*2:Static Site Generator

*3:Server Side Rendering

*4:データサイエンティスト

ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話

VOYAGE Lighthouse Studio の海老原 (@co3k) です。

ゲーム攻略メディア「神ゲー攻略」の記事は、これまで SSG (Static Site Generator; 静的サイトジェネレータ) を用いて構築、配信されていました。 このたび、従来の SSG を活用した記事配信の仕組みから、 SSR (Server Side Rendering) による仕組みにリプレイスしていくことにしました。

本記事では、そうした新しい記事配信システムの詳細と、移行にまつわる工夫や苦労話などについてご紹介します。

[PR] 本エントリをお読みいただく前に

そもそもリプレイス前の構成ってどんな感じだったの? というか「神ゲー攻略」って何? みたいなのが気になって記事が読み進められないかも〜とご心配の方に耳寄りな情報です。

実は「神ゲー攻略」の事業やシステム構成については『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』の第四章にて、 t-wada さんインタビューのもと、事業背景から技術戦略に至るまで、たっぷりとお話をさせていただいています。

そういった部分も含めてガッツリ理解したいよーという方におかれましては、是非書籍をお買い求めいただければ、この記事を 360° お楽しみいただけると確信しております。

『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』は、私たちのチーム以外にも、 VOYAGE GROUP の大小様々なチームにおける赤裸々な話に触れられる、とても面白い書籍なので、もしまだお読みでない方はこの機会にお手に取られてはいかがでしょうか。

もちろん、本記事は書籍をお持ちでない方でも問題なくお楽しみいただけます!

記事配信システム構成図

まずは全体像を把握していただくために、神ゲー攻略の記事配信システムに関する構成図をババーンとお見せいたします。

f:id:co3k:20201022101026p:plain
神ゲー攻略記事配信システム構成図

図において、青字で解説しているのが旧配信システムに関するものです。

旧配信システムの流れを一言で表現すると、「SSG によって構築された HTML を Amazon S3 に置いて Amazon CloudFront で配信している」です。旧配信システムについては、前述の『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』の第四章で詳しく述べていますので、是非ご一読いただければと思います!

赤字で解説しているものが、本記事においてこれから述べる新配信システムに関するものとなります。

書籍のなかで詳しく説明しているとおりとなりますが、私たちのサービスは検索エンジンからの流入を中心としているため、 SEO (Search Engine Optimization; 検索エンジン最適化) や応答性能などは最大の関心事です。また、事業展開上、旧配信システムにおける簡易なアクセス制御では不足するような事態が出てきていました。新配信システムにおいては、これら要件を満たすための趣向が凝らされています。それぞれについて見ていきましょう。

新配信システムの特徴その 1: lit-html を利用した SSR

旧配信システムは完全なる SSG でしたが、新配信システムは SPA (Single Page Application) に生まれかわっています。これはできるだけ記事のみを無駄なく配信することによるユーザ体験の向上と、転送量等の削減によるコストメリットを狙ってのことです。

さて、 SPA には SEO において懸念があることもよく知られています。

たとえば Google の検索エンジンのボットは JavaScript を解釈しますが、それはレンダリングフェーズにおける話で、クロールフェーズにおいては HTML のみが解釈されます。レンダリングはクロールとは別なキューによって改めて処理されますから、 SPA 技術によって構築されたページがインデックスされるまでには、それぞれの順番待ちの時間が生じることになります。

以下は JavaScript SEO の基本を理解する | Google 検索デベロッパー ガイド | Google Developers 内、「Googlebot が JavaScript を処理する仕組み」 にて紹介されている図となります。この図をご覧いただければどういうことなのか一目瞭然だと思います。

Googlebot が JavaScript を処理してインデックスするまでの図

先述の通り、私たちのサービスは検索エンジンからの流入を中心としており、かつ、競合他社様との競争力も求められることから、こうしたタイムラグは事業的に見て致命傷となりかねません 1

ですから SSR あるいは Dynamic Rendering といった選択肢が検討の俎上に置かれることとなります。しかしながら、

  • Dynamic Rendering はヘッドレスブラウザを用いたレンダリングをおこなう
  • SSR は DOM レンダリングなどをおこなう

という特性から、従来型のウェブアプリケーションに比べ、サーバに求められる性能要件が跳ね上がります。

これらのソリューションはメモリをそれなりに要求しがちです。ウェブサーバ (ないし Dynamic Rendering をおこなうためのリバースプロキシ) のプロセスあたりに要求されるメモリ使用量が大きくなるということは、ひとつのサーバインスタンスで捌けるリクエスト数が少なくなるというトレードオフを覚悟することになります。また、私たちのように Google App Engine を用いる場合は、デフォルトの F1 インスタンスでは不充分で、少なくとも F2 以上のインスタンスクラスでなければたいていの場合まともに動作させられないでしょう。低く見積もって F2 インスタンスを用いるのだとしても、 F1 インスタンスと比べてかかるコストは倍になります。これは PV あたりの運用コストに関わりますし、ひいては収益性に直結します。

幸いなことに、私たちのサイト構成はとてもシンプルです。記事数こそ数十万、月間 PV 数は数億という規模のサービスではあるものの、このシステムで配信されるページは概ね以下の数パターンしかありません。

  • 記事詳細ページ (トップページも含む)
  • 記事一覧ページ
  • その他システムで使うページ (エラー画面など)

これくらいの複雑さのアプリケーションであれば、 React や Vue.js などのメジャーなフレームワークを利用する以外にも、 lit-html が検討候補にあがってくるかと思います。 lit-html は端的に言えば DOM の差分更新をサポートした軽量なテンプレートエンジンです。コンポーネント機構は有しませんが、充分に小さいライブラリなので、ブラウザネイティブの Web Components と組み合わせて利用することができます。

ということで私たちもご多分に漏れず lit-html と Web Components を組み合わせつつ、状態管理を Redux に任せるような形で SPA を実現しています。

さて本題の SSR ですが、 lit-html それ自体は現行バージョンにおいては SSR をサポートしていません。「現行バージョンにおいては」、と書いたのは、次のメジャーリリースである lit-html 2.0 において SSR 可能になるような改良がおこなわれるからです。素晴らしい! ……ですが私たちは未来に生きていないので、どうにかして今すぐに lit-html で SSR したいよーというワガママニーズを満たす必要があります。

さて先ほど lit-html は「軽量なテンプレートエンジン」である、と言いました。 lit-html の解釈するテンプレートは以下のような単純な Tagged Template Literals によって実現されます。

const template = html`<p>Hello, ${name}!</p>`;

現行の lit-html は DOM 実装なしにサーバ上に持っていって動くような代物ではありませんが、 このテンプレート自体を解釈して DOM なしで処理をするような互換実装さえあれば、クライアントとほとんど同様の出力内容をサーバ上で構築することができます。

f:id:co3k:20201023065143p:plain

で、ありがたいことにそのような互換実装が (サードパーティのものですが) あります。 https://github.com/popeindustries/lit-html-server

この実装によってサーバ側での DOM 実装の導入などなしに SSR が実現できる (なぜなら単純な文字列処理に落ちるので) ので、お安く SSR することが可能となります。 もちろん、テンプレート以外にも、たとえばルーティングを router5 のような universal なライブラリによって、クライアント側とサーバ側で共通のルールで処理をさせるなど、クライアント側処理とサーバ側処理の乖離を小さく留めるように工夫しています。

新配信システムの特徴その 2: RDBMS まで来たら負け

新配信システムではなんと RDBMS に記事データを蓄積するようになりました!!!! 五年の時を経てついに普通の Web アプリケーションになった!!!!

例によってフルマネージドなサービスということで、 Google Cloud SQL 上で動かされる MySQL サーバを使っています。

ですが、エンドユーザから参照されるデータの大部分は Google Cloud Datastore から取得するようにしています。 Google Cloud Datastore は高い性能を誇るフルマネージドな NoSQL データベースサービスです。

実は Google Cloud Datastore については、静的な記事ページに動的に埋め込まれるコメント機能のサーバ側実装 2 で既に使い倒しており、その性能は折り紙付きでした。極めて高いスケーラビリティと応答性能、そして強力な可用性は、私たちのような高トラフィックサービスのバックエンドとして据えるにふさわしいものです。

一方で、 Datastore 内のデータをマスタデータとはしていません。マスタデータはあくまで RDBMS に置かれます。これはコメントサーバを実装、運用するなかでの反省から来たものです。

Datastore が Datastore であるために、すなわちその性能要件を維持するため、たとえば RDBMS で可能となる柔軟な条件による結果セットのフィルタリングなどはおこないにくいといった制約が存在します。

たいていの場合、この制約に合わせてアプリケーションを設計、実装することは可能です。しかし、管理画面など、運用上の要求により、柔軟な、時としてアドホックな条件でのデータアクセスが想定されるような場合には、こうした制約がネックとなってきます。コメントサーバにおいては、実際にこれが問題となり、管理上の柔軟性を欠いてしまっている部分があります。

ですので、マスタデータは MySQL 上に、そこから公開用データのみを Datastore 上にそれぞれ格納することで、用等に応じて両データベースを使い分け、双方の利点を享受できるようにしています。

これはパフォーマンス、運用上の柔軟性の獲得といったメリットだけでなく、セキュリティ上の利点ももたらします。

記事のメタデータのなかには編集上のためだけに有用な、公開に差し支えるような情報も含まれます(たとえば、編集担当者のアカウント名など)。このような情報がアプリケーションロジックの問題によって、 API や HTML 出力などを通して誤って公開されてしまうような事態はなんとしても避けねばなりません。あらかじめ公開を意図したフィールドのみに限定したスキーマを持つデータとして射影して格納しておけば、アプリケーションロジックの欠陥によってこれらの情報が誤って公開状態に置かれる可能性を大きく減じられます。

また、 Datastore に至る前には memcached で、さらにその手前では高いキャッシュヒット率 (なんと 90% オーバー) を誇るエッジサーバキャッシュによって、大半のリクエストを処理することができるようにしています。その結果、サイト規模の割に RDBMS への参照がおこなわれることはほとんどありません。そうしたこともあって、エンドユーザのリクエストが RDBMS に来たら「負け」、という思想の元でアプリケーションを組んでいます。

実は、なんと Cloud SQL に関しては一番低いインスタンスタイプで運用されています。チューニングもぜんぜん頑張っていません。にもかかわらず Cloud SQL の CPU 使用率は少ない値を維持し続けており、この工夫が少なくともいまのところはうまくワークしている様子がうかがえます。

f:id:co3k:20201023065202p:plain

新配信システムの特徴その 3: 管理機能は RBAC (ロールベースアクセス制御) による権限管理を実施

攻略サイトで扱う攻略情報のなかには、ゲームのデベロッパ様やパブリッシャ様自身の監修を受けて公開するものも存在します。 そういった情報は、たとえば特定の公開日時までは関係者外秘となるような情報であったりするわけです。

神ゲー攻略の認知度がありがたいことに高まってきたおかげもあり、こうした形態の攻略情報を扱わせていただくことも増えてきましたが、これは旧配信システムで実現するのが(システム的には)難しい要件のひとつでした。旧配信システムは大ざっぱに公開用バケットと非公開用バケット、二種類のバケットに対するデプロイにしか対応しておらず、「特定の関係者のみに公開する情報」や「特定種類の情報しか閲覧できない関係者」などといったきめ細やかなアクセスコントロールは残念ながら実現することはできませんでした。

新配信システムにおいてはこの課題を払拭するために RBAC (ロールベースアクセス制御) による権限管理を実施しています。 これによって、以下の図のように(わかりにくいかもごめんなさい)、個々のロールに対して複雑な権限設定を付与するというのが簡単におこなえるようになっています。

f:id:co3k:20201023065217p:plain

ちなみに、 RBAC の実現にあたっては Casbin というライブラリを用いています。

実装コードの具体的な内容は Casbin 自体の知識がかなり要求されてしまいますので割愛しますが、上の図のようなことをおこなう Negroni の middleware を用意していて、各 API のエンドポイントよりも手前で処理されるようにしています。

リプレイス戦略——いきなり移行はせず、新配信システムを、独立したサブシステムとして稼働させる

さて、こうした機能を備えた新配信システムにリプレイスしていくわけですが、なにぶん大きなアーキテクチャ変更を伴うリプレイスですので、やはりというか何というか一筋縄ではいきません。

旧配信システムはだいぶガタが来ているとはいえ、五年もの歴史があります。安定性や稼働率も抜群ですし、現場で運用するうえでの工夫もたくさん詰まっています。これを一朝一夕でまるごとすげ替えることはできません。いえ、表面上はできるかもしれませんが、配信性能や記事品質など、私たちが大事にしている多くのものをしばらくの間犠牲にすることになるでしょう。

ではどうしたかというと、最初は「リプレイスをしない」という決断をおこないました。

リプレイスは決して簡単な道のりではありませんから、旧配信システムとはまた別な形での記事配信システムとして新配信システムを立ちあげ、新規に構築するタイトルの一部や、新配信システムによって新たにもたらされる管理機能などが有効に働くゲームタイトルの一部などで実験的かつ段階的に導入をおこない、編集部側で運用するにあたっての知見やフィードバックの収集、開発側での技術やシステム運用に関するノウハウの蓄積、そしてもちろんバグの洗い出しと修正や、徐々に増えていく負荷にあたって支障が出てこないかなどを焦らず慎重に進めていきました。

どのくらい慎重かというと、実は 2 年前に書いたエントリ、スキーマ定義言語 Protocol Buffers と protoc-gen-swagger を使って Web API のスキマを埋めようにて触れている「とある派生サービス」というのが、この新配信システムのことだったのです。

な、なんだってーっ(AA 略)。

ということで、新配信システムは、実際に旧配信システムからリプレイスされるまでに、 2 年近く battle-tested な状態に置かれていたということです。これだけの期間があれば、わかりやすいバグは潰れているし、運用側での知見もだいぶ蓄積されています。どこの馬の骨ともつかないシステムに、開発と編集の両方が振り回され、高い品質の記事を安定した配信基盤に載せて素早く出す、という目的が達成できない、……という事態にはならずに済みます。

そうそう、要するにこの戦略は、あたかも一個のサービスの看板を出しておきながら、その実、二種類のシステムを抱えていて、条件に応じて切り替える、というようなモデルなんですが、これが気軽にできてしまうのは、見た目上の違いをほとんど感じさせないように作っているというものあるでしょうが、ゲーム攻略サイトならではの特徴のおかげかもしれません。ゲーム攻略サイトは「検索エンジンからの流入が中心」、「ゲームタイトルごとにユーザが分かれる」という特徴があります。特に後者が重要で、たいていの人は複数のゲームを本当の意味で同時にはプレイしません。従って『AJITO 奪還大作戦』3というゲームをプレイしているときに『Enemy in VOYAGEー船に乗り込む侵入者たち』4というゲームのことを調べたくなったりはあまりしないわけです。それぞれのゲームタイトルごとに攻略サイトが立ち上がっているというような認識をもたれるのがむしろ普通なので、それぞれが別なシステムで動いていたとしても、そもそもそんなに気にならないという土壌が既にあるのだと言えます。

よくある質問 Q1: あれ? ということは、リプレイスはまだ終わっていないってこと?

は、はい……。

旧配信システムから記事などのリソースをインポートして新配信システム上で利用できるようにする仕組みは既に用意しています。 この仕組みを利用して、 100 を超えるゲームタイトルについては、既に旧配信システムから新配信システムに切り替えて記事の配信がおこなわれています。

以下が、実際に記事をインポートしている様子です。

f:id:co3k:20201023123010p:plain

新システムにおいても、 Markdown パーサやそれに付随する CSS や JavaScript のアセット類の一部については、旧システムのものをそのまま移植しています。そのため、記事の内容に踏み込んだ変換処理などは一切おこなっていません。

旧システムは Markdown の表現力を活かしまくってメニューなどを実装しているため (なぜかというとそうするしかなかったからです)、そのあたりを新システムに適合するようにインポートするなど、小さな差異は埋めていく必要がありますが、基本的には新旧システム間でのリソースの互換性を維持するように配慮しているため、このインポート用のコマンドラインツールはもっぱらオートメーションのために機能している具合となります。

また、この切り替えについても一気にはおこなっていません。準備が整ったゲームタイトルから、新配信システムを利用する形に少しずつ移行を進めていっています。 万が一移行に際して致命的な問題が生じたとしても、影響範囲が小さく抑えられるようになっています。

ただ、運用ツールがガラリと変わってしまうため、移行については、システム側での準備だけでなく、運用側での準備が必要不可欠です。 たとえばゲーム内イベントはたくさんのユーザが訪問してくれる大事な機会なわけですが、そのようなチャンスを、私たちの都合によるシステム移行作業で逃してしまっては悔やんでも悔やみきれません。

ということで、ただいま大絶賛リプレイス進行中というわけです! えへん。

え、えへん……

……な、なんだか煮え切らない感じの締めになってしまってすみません。でもこれがありのままの現状なんです。

えっ? こういうありのままの赤裸々な話をするのにうってつけなイベントがあるって本当ですか!?

[PR] 「そーだいなるVOYAGE GROUPの裏側 #VLS 数十万記事のメディアをゼロから立ち上げる」というイベントをやります!

『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』出版イベントである、大好評「そーだいなるVOYAGE GROUPの裏側」の第四弾、 VOYAGE Lighthouse Studio 編が、来る 10/26 (月) の 12:30 より(オンライン)開催されます!

https://voyagegroup.connpass.com/event/192112/

この記事の内容や書籍の第四章の内容であったり、あるいはあまり触れられていなかった部分などについて、どんどん掘り下げていくタイプのイベントとなっています。

特に、本記事においては、旧システムの問題点や、どうして新システムへのリプレイスを決断するに至ったのかについてはあまり触れませんでした。そのあたりが気になる方については、『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』をお読みいただいてももちろんいいのですが、このイベントにおいても、そーだいさん(@soudai1025)にモデレータを務めていただくことで、より深く生々しい苦労話などが明らかにされるはずです。

ということで、興味を持たれた方は是非ご参加いただけると嬉しいです。質問も絶賛受け付け中ですよ!


  1. このあたりのお話はぜひ『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』にてお楽しみください。

  2. 『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』 132 ページ参照

  3. タイトルは架空のものです。同名の何かが万が一実在したら申し訳ございませんが、それは偶然の一致であって実在のものとは無関係です

  4. タイトルは架空のものです。同名の何かが万が一実在したら申し訳ございませんが、それは偶然の一致であって実在のものとは無関係です

そーだいなるVOYAGE GROUPの裏側 #VM 編 レガシーシステムといい感じに付き合うスキル

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第三回の今回は「レガシーシステムといい感じに付き合うスキル」と題してVOYAGE MARKETING(以下 VM)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201017175212p:plain

当日の紹介資料

 資料の中にVMの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。 オススメポイントは人気声優と同姓同名の下りです!*1

speakerdeck.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 3回目ともなるとこなれてきて、いい感じに雑談から入り、配信もできました。 パネルディスカッションも大盛りあがりだったのでぜひ見てください!

 今回は牧場のfluct、サバンナのZucks、に対して農耕と評される、VMの話でした。 チームで問題に取り組み、チームで問題を解決するという文化が終始出ていましたね。

 特にレガシー改善は古いコードのメンテナンスをさせられているという印象が強いですが、そんなことはなくてどんどん新しい仕組みを取り入れたり、置き換えたりしながら前に進んでいて、多くの人に勇気を与える回でした。  

感想

 今回は自分の中では大きく以下の3つのテーマがありました。

  • 歴史あるサービスをメンテナンスするということの楽しさと学び
  • レガシーコードを腕力*2ではなく、組織で取り組む
  • 改善の道に王道なし、プロダクトの成長に近道なし!

 この3つがVMの特徴だと思っていて、皆様にその片鱗をお伝えすることができたのでは無いでしょうか。 特にこのツイートがVMの文化を表してるなぁと感じます。

 VMの文化はチームにフォーカスしているものの、前述の2社と変わらず、事業の成長にエンジニアが向き合ってきた形です。 お互いにサポートしながら 一つのミッションをチームで解決する というミッションベースの文化は多くの企業でも取り入れる要素なのではないでしょうか。

 今回の回も名言が連発なのでぜひTwitterのまとめも御覧ください。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は VLS*3 です! ここまで1を100にする、100を10000にするような事業の話がメインでしたが次回は0を1にする話です。 今までは腕力あり、文化ありですが次回はそこにまさに 技術あり! といった内容になる予定です。

 最小限で最大の効果を発揮する、技術で問題を的確に解決していくVLSの姿に乞うご期待ください。 本の中で語られなかったより深い技術の話を引き出せると思うとオラ、ワクラクしてきたぞ!

voyagegroup.connpass.com

 VMに変わってお仕置きよ! 次回のVLS回もよろしくおねがいします!

techlog.voyagegroup.com

*1:当日誰も触れなかったのでここで触れます

*2:腕力についてはfluct回を参照

*3:VOYAGE Lighthouse Studio

新卒とOJTに配属からの様子を聞いてみた【VOYAGE MARKETING編】

こんにちは!新卒エンジニア採用担当のさとみんです。

VOYAGE GROUPにはこの春9名の新卒エンジニアが入社し、4月末の配属からもうすぐ半年が経とうとしています! 今回は、VOYAGE MARKETINGに配属されたぐりと、ぐりのOJTであるよっぴーのインタビューをお届けします!

※OJTとは?…OJTは、業務を通じて仕事に必要な知識・スキル・マインドなどを新入社員に継続的に指導する存在です。VOYAGE GROUPでは業務の中で1人ひとりのスキルや個性に合わせて学んでいけるよう、OJT制度を取り入れています。

▼3行まとめ

  • やりたいと手を挙げると任せてもらえ、想像以上に働く自由度が高かった
  • わからないことに対して、チームを超えてみんなが教えてくれる
  • 「設計の選択肢を増やす」ことが今後の目標

f:id:satomin35y:20200924184938p:plain

登場人物

ぐり(左):2020年入社の新卒1年目。VOYAGE MARKETINGに配属され、ECナビの技術的負債の返済などを担当。

よっぴー(右):2016年入社の5年目。VOYAGE MARKETING(以降VM)でECナビの技術的負債の返済などを担当し、ぐりのOJTも担当。

ーまずは、入社から配属までを教えて下さい!

ぐり:今年は入社式・研修・配属とすべてオンラインだったのが印象深いですね。配属希望を出すまでは約2週間で、研修ではVOYAGE GROUPや事業の説明、各事業部の方々との交流の時間があり、部署の雰囲気や現場のクルーを知ることができました。

よっぴー:VMでは、ランチ時間に新卒へ向けてエンジニアが普段行っている「昼会」を公開しました。進捗共有の様子や今後の方針について話し合う姿をそのまま見てもらうのが、1番部署の雰囲気が伝わるのかなと思ったので。

ぐり:正直話している内容は全然理解できなかったのですが(笑)、部署の雰囲気や毎日集まる機会があることを知れて部署選びの参考になりました。VM以外だと、ランチをしながら質問する場を設けてくれる部署が多く、各部署への自分のイメージと、実際はどうなのかの差分を埋めるのに役立ちました。

※VOYAGE GROUPでの配属先の決定について…本人の志向性をもとに人事や現場クルー、CTOとの面談を重ね、最も活躍できる部署へ配属が決定します。

ーどんな基準で部署を選んだの?

ぐり:ユーザーに近いところで開発できるかを重視していて、ECナビサポーターズを中心に話を聞きに行きました。「実際開発していてどう感じるか?」などを質問し、自分がやりたいことが本当にできるかを実際に相談したりもしました。色々な部署の話を聞けば聞くほど「どの部署に行っても楽しそうだな」という気持ちで着地したので、配属式ではいい意味でドキドキ感がありました。

ー晴れてVM配属になったその後は?

ぐり:配属翌日、最初は上長の福田さんとVM開発本部のどのチームに入るかを面談で話し合いました。ユーザーに近い部分のアプリケーションを触りたいと相談し、VMの各チームの状況を聞く上で最終的にリノベGというチームを福田さんに薦めていただきました。

よっぴー:リノベGは僕の所属するチームで、20年近く続くサービスであるECナビ

ecnavi.jp

技術的負債の返済が僕らの役割です。サービスも長年続くと、開発面ではシステムが複雑になっていて、誰も仕様を知らなかったり、使われているか分からない、似たような機能が乱立していたりと課題も蓄積されていき、例えば、「新しく機能を追加・変更するぞ!」という場合でも開発工数とは別に仕組みや影響の調査といった工数が増えてしまうケースがありますね。なので、開発の課題部分をきれいにする技術的負債の返済をしていき、ユーザーにより早く価値提供できるようにしていくのが僕らのチームの役割です。

ただ、いきなり「技術的負債の返済をしろ!」と言われてもさすがに難しいので、最初はECナビに慣れてもらうために、内部向けの管理画面の改修など小さめのタスクから任せていて、一通り触った7月頃からリノベGのタスクに着手してもらってます。

ー1番最初の仕事は?

ぐり:「ここが変だよECナビ」という提案企画をまず最初に任されました。ECナビを使って違和感のある箇所を事業部のメンバーに向けてプレゼンする企画で、配属された同期たちと相談しながら提案をまとめました。実際に自分が提案した中からだと、「ナビックの新着情報」のデザイン変更案と、ユーザーのお知らせ欄の見やすさ改善が採用されました。

▼実際のぐりの提案資料一部

f:id:satomin35y:20200924190023p:plain f:id:satomin35y:20200924191513p:plain f:id:satomin35y:20200924191523p:plain

よっぴー:提案が採用されたのすごいよね!

ぐり:この企画を通して、気になったところは自分でどんどん提案できる環境だとわかりました。最近では、「このコードをきれいに直したいな」と思ったところはGitHubのIssueにメモしておいて、タスクが空いた時に直して自分からプルリクエストを出したりもしています。

ー開発周りでの初仕事は?

ぐり:管理画面の開発です。ECナビはポイントサイトで、一定期間を超えたユーザーのポイントは失効していくのですが、失効作業の一部でエンジニアが本番DBを触る作業が残っていて、より安全に作業が進むよう、これを無くすための機能開発を担当しました。その際、今まで学校の課題くらいでしか触れていなかったPHPに本格的に挑戦しました。

よっぴー:管理画面に着手してもらった狙いとしては、まずは小さいタスクから取り組んでもらい、ECナビのプロダクトのコードへ慣れてもらう意図がありました。初めて触るPHPについても、ぐりは周りのクルーにSlackで勉強の仕方などを質問していたよね。

ぐり:はい。実際、おすすめされた『はじめてのPHP』という本で勉強しました。プログラミング自体は他の言語でやっていたので、「PHPだとどう書くのか」という部分を書籍などで補完しました。他にも聞きたいこと・わからないことがあればSlackで質問をすると、全然違うチームの人も含めてみんなが集まって教えてくれるのでありがたいです(笑)

よっぴー:テキストベースで解決が難しいものは、在宅勤務でも適宜通話をつないだり、オンラインで画面共有をして一緒にコードを見ながら進めていきました。リモートながら、ぐりがドライバーで自分がナビゲータとしてペアプロをしながら進めていきました。

ーー最近取り組んでいる仕事は?

ぐり:最近だと、ECナビでの広告掲載の一部を自動化しました。ECナビ上に掲載する案件は、内部向けの管理画面から、運用担当の方がどの広告枠に何を掲載するかを手作業で登録しているのですが、一部の広告枠でこの運用を自動化しました。あとは、運用ミスが起きやすい管理画面の改善や、すでに利用されていない機能を見つけて削除、などもしています。

ーー実装を進める中で大変だったことは?

ぐり:要件の実装においていくつか選択肢があり、適切な選択肢を選んでいくのが難しかったです。メリット・デメリットをそれぞれ自分で出し、チームメンバーに壁打ちをしながらまずは自分主体で進めていきました。

よっぴー:ぐりは質問の際にすぐに答えを求めるのではなく、「こう考えているんですがどうですか?」という聞き方をしてくれたのがいいですね。タスクをこなすにつれて、ぐり自身の考えがブラッシュアップされていて成長を感じています。

ーー配属前と配属後でギャップはあった?

ぐり:配属前は仕事の進め方に関して、チームでやることが決まっていてそれに向けてやっていくイメージだったのですが、実際はやりたいと手を挙げると任せてもらえ、自由度がかなり高い印象を受けました。また、在宅勤務中も毎日昼会でリモートながら顔を合わせていたので、チームに打ち解けるのもそれほど時間がかかりませんでした。

ーーでは最後に、これからやっていきたいことは?

ぐり:リノベチームが技術的負債を頑張って返済していくチームなので、 やはりその部分でチームに貢献できるように頑張っていきたいです。また、ECナビのように長く使われているサービスでは、その歴史とともにうまくいっている設計・うまくいかなくなった設計を身をもって学ぶことができます。それらを学んで、『設計の選択肢を増やす』というのが個人的な目標です。自分の選択肢を増やしてそのタイミングごとにベストな選択が取れるようになりたいです!

よっぴー:自分の手持ちを増やして、リノベGやそれ以外の範囲でももっと幅を広げて動いていけるように一緒に頑張っていこう!

お知らせ

VOYAGE GROUPでは、2022年4月入社のエンジニア新卒採用選考を開始しています! ミチを切り拓く、未来の仲間を募集中。詳細はこちらから!

voyagegroup.com

そーだいなるVOYAGE GROUPの裏側 #Zucks 編 フルサイクル開発者の文化

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第二回の今回は「フルサイクル開発者の文化」と題してZucksのみんなとディスカッションしてきました!

f:id:Soudai:20201009173640p:plain

当日の紹介資料

 資料の中にZucksの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。

speakerdeck.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回はYou Tube Liveがこちらの問題で配信できなかったため、zoomの録画から生成されました。 You Tube Live勢が見れてない、イベント史上最高と評判高い前説もぜひ見てください!

 今回はサバンナと評される、Zucks文化がにじみ出るディスカッションでしたね。 諸事情でリモート参加の人もいましたが、違和感なくディスカッションできたのは技術力の勝利と言ったところでしょうか。 Zucksの章にも出てきた @brtriver さんのCSO*1*2 のおかげです!

 

感想

 今回は本には登場しない三人に来てもらいました。 Zucksの文化は独特と言われることも多いですが、どちらかといえば「大切なことを正面から向き合って解決していった結果」でしたね。 結果的にフルサイクル、ドキュメントが必要にないくらいにissueをはじめ、しっかりとコミュニケーションを取ることは多くのエンジニア、企業にとっても学ぶことが多いのでは無いでしょうか。

 また監査対応に「特別対応を用意しない」というのは本当に大切だなと思いました。 常に本質を見抜き、最善な解決をしていく姿勢に 技術力で問題を解決する ということはこういう姿だと強く感じました。

 要所要所の名言はTwitterのまとめにも出てくるのでぜひ、そちらも見てみてください。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は VM*3 です! 牧場のfluct、サバンナのZucksに対して、農耕と呼ばれるのVMです*4

 腕力だけがレガシーの改善方法じゃない、毎日の積み重ねの先に健全なプロダクションがある。そんなVMの取り組みは「自分は凡庸だ」と感じている人にこそ、聞いて欲しい話です。

 正しいことの繰り返しの中に四季がある、そんなVMの話は私も今からめちゃめちゃ楽しみです。

voyagegroup.connpass.com

 翔べ!voyage!! 次回のVM回もよろしくおねがいします!

techlog.voyagegroup.com

*1:チーフサウンドオフィサ

*2:非公式

*3:VOYAGE MARKETING

*4:そーだい調べ