<p>イオン株式会社のAI・Data系部署に所属しデータエンジニアをしている星野と申します。2023年8月より部署のデータ基盤をAzure Databricksを中心としたものへ刷新しました。本記事ではこれにより得られた恩恵をみていきます。</p><h2 id="he4538202c6">イオンのデータ</h2><p>まず、イオンのデータについて紹介させてください。</p><p>イオングループはM＆Aで大きくなってきたという背景があります。<a href="https://www.aeon.info/company/group/" target="_blank" rel="noopener noreferrer nofollow"><u>イオングループ事業・企業紹介</u></a>をご覧いただくと、身近な会社もイオングループの一員ということに驚かれるかもしれません。</p><p>データについても、この背景により、現状は各企業がデータ基盤を持っている状態です。ほとんどが小売業を営んでいるため、「商品」や「POS」など扱うデータは似てはいるものの、データ構造・アーキテクチャ・組織文化などは全く異なり多種多様です。</p><h2 id="h0125af4989">所属について</h2><p>次に、私の所属について簡単に述べます。</p><p>前述の背景のもと「各所に点在するイオンのデータを横断的に活用し、価値創出を行う」ことを目的に2021年に発足したのが私の所属する部署です。グループ各社と協力し、点在するデータの収集・活用施策のプロトタイピングや導入支援等を行うR＆D的な役割を担います。</p><p>より具体的には「イオンのデータとデータサイエンスを掛け合わせ、データによる新たな価値創出を行う」ことがミッションであり、商品・POSデータを利用した商品価格の最適化・需要予測や、生成AIによる商品POPの作成などに取り組んでいます。</p><p>データ関連ロールとしては、データサイエンティストとデータエンジニアの2種が存在し、各々の構成と役割は以下です。</p><ul><li>データサイエンティスト（約10名）：データサイエンスの実施、グループ会社への成果物導入支援が責務</li><li>データエンジニア（筆者含め3名）：データ収集、データ整備、データ基盤の改善が責務</li></ul><h2 id="h356ab75f63">データ基盤について</h2><p>本題のデータ基盤をみていきます。</p><p>今までの総括的内容ですが、弊部のデータ基盤の役割は以下であり、主要ユーザーは部署内のデータサイエンティスト・データエンジニアです。</p><ul><li>グループ会社に点在するデータを継続的に収集すること</li><li>データエンジニアリング・データサイエンスの役割を全うすること</li></ul><h3 id="hdfd9efe67f">以前のデータ基盤と課題</h3><p>データ基盤として、発足当初から以下の構成を採用していました。</p><ul><li><a href="https://learn.microsoft.com/ja-jp/azure/storage/blobs/data-lake-storage-introduction" target="_blank" rel="noopener noreferrer nofollow"><u>Azure Data Lake Storage Gen2</u></a>：オブジェクトストレージ</li><li><a href="https://learn.microsoft.com/ja-jp/azure/synapse-analytics/overview-what-is" target="_blank" rel="noopener noreferrer nofollow"><u>Azure Synapse Analytics</u></a>：データエンジニアリング、データサイエンスの前処理</li><li><a href="https://learn.microsoft.com/ja-jp/azure/virtual-machines/overview" target="_blank" rel="noopener noreferrer nofollow"><u>Azure VM</u></a>：データサイエンス（データサイエンティストが1人n台保有）</li></ul><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/f81a575de4884b12af8517b2059650be/fig1.png" alt="" width="731" height="192"></figure><p>いくつかあった課題のうち、Azure VMでの作業の不透明性が一番大きなものでした。すべてが使用者依存であったため、プロジェクトの長期化と拡大によって引き継ぎや複数人進行が必要になるにつれ、この問題が顕在化しました。以下が顕在化した問題の一例です。</p><ul><li>構成管理<ul><li>他の人が再現できない環境</li></ul></li><li>Azure VMでのデータ処理<ul><li>処理がデータ基盤に還元されず、再利用できないデータ</li></ul></li><li>ワークフロー管理 / MLOps<ul><li>手動運用派の場当たり的な運用に起因した再現できない成果物</li></ul></li></ul><p>これらを解決するために、Azure Databricksを導入しました。</p><h3 id="h292a392a37">Azure Databricksを中心としたデータ基盤</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/azure/storage/blobs/data-lake-storage-introduction" target="_blank" rel="noopener noreferrer nofollow"><u>Azure Data Lake Storage Gen2</u></a>：オブジェクトストレージ</li><li><a href="https://learn.microsoft.com/ja-jp/azure/databricks/introduction/" target="_blank" rel="noopener noreferrer nofollow"><u>Azure Databricks</u></a>：データエンジニアリング・データサイエンス</li></ul><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/0a9c8a972ac64d91a70333e969f64528/fig2.png" alt="" width="571" height="202"></figure><p>そしてこれらの問題は以下のように解決しています。</p><ul><li>IaC(Infrastructure as Code)による構成管理。IaCになじみがなく、各種リソースをGUIで作成したとしても構成をJSON出力可能</li><li>データの処理をDatabricksに集約し、部署内でのデータサイロを抑止</li><li>フルマネージドなワークフローオーケストレーションであるDatabricks WorkflowsとマネージドMLflow</li></ul><p>上記に加え、以下の効果も得ています。</p><ul><li><a href="https://learn.microsoft.com/ja-jp/azure/databricks/administration-guide/clusters/policies" target="_blank" rel="noopener noreferrer nofollow"><u>Compute Policy</u></a>によって敷設したガードレールの範囲内であれば、自由にComputeをスケールアップ・スケールアウト可とし、セルフサービス化</li><li><a href="https://learn.microsoft.com/ja-jp/azure/databricks/compute/cluster-config-best-practices" target="_blank" rel="noopener noreferrer nofollow"><u>スポットインスタンス</u></a>と<a href="https://learn.microsoft.com/ja-jp/azure/cost-management-billing/reservations/prepay-databricks-reserved-capacity" target="_blank" rel="noopener noreferrer nofollow"><u>事前購入</u></a>を活用し、金銭コストを抑制</li></ul><p>実開発においても、ノートブックの使用感の良さやAIアシスタント機能によるコードの生成・デバッグ補助機能のおかげで、データエンジニアリング、データサイエンス双方で開発のアジリティ向上を感じています。</p><p>これらの恩恵にあずかれたことから、Databricksへのリプレースは正解だったと考えています。</p><h3 id="he19ef9e808">データコラボレーション</h3><p>データエンジニアリング、データサイエンスの観点に限らず、グループ各社とのデータコラボレーションの観点でもDatabricks導入の恩恵を受けつつあります。</p><p>まず、グループ会社からのデータ収集について、Databricksの導入により、<a href="https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/" target="_blank" rel="noopener noreferrer nofollow"><u>Unity Catalog</u></a>を通じた<a href="https://learn.microsoft.com/ja-jp/azure/databricks/query-federation/" target="_blank" rel="noopener noreferrer nofollow"><u>Lakehouse Federation</u></a>の機能で、グループ会社のデータストアのデータを直接参照できるようになりました。以前は、ファイル転送によるデータ連携を行っていたのですが、さまざまな事前手続きに時間がかかり、実際にデータを受領するのに1、2カ月を要することが珍しくありませんでした。しかし、Lakehouse Federationにより、このリードタイムを削減できるのは大きな恩恵です。</p><p>また、データサイエンス成果物についても、Unity Catalogのアクセスコントロールや<a href="https://learn.microsoft.com/ja-jp/azure/databricks/data-sharing/" target="_blank" rel="noopener noreferrer nofollow"><u>Delta Sharing</u></a>を通して、グループ各社へ直接提供できるようになりました。実際に、グループ各社のユーザーへ特定のノートブックを触る権限を与え、成果物を直接触ってもらっています。従来の、グループ会社へ成果物を定期的にレポーティングという方式に比べ、レポート作成の手間を省けるメリットがあるほか、動くものをユーザーに触ってもらうことでフィードバックが得やすくなる効果も狙っています。</p><p>さらに、実際に利用されているかどうかをアクセスログで確認可能なため、利用されていないようであれば理由をヒアリングするというアクションも取れるようになりました。このように成果物のフィードバックサイクルを回せるようになった効果もあります。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/7d2f46fc7b3644899a440f8e7bb62740/fig3.png" alt="" width="522" height="152"></figure><p>リードタイムの削減、フィードバックサイクルの改善により、仮説検証スピードを高めることができるようになりました。一見地味ですが、価値創出のために仮説検証を繰り返す必要がある我々にとって、確実に効いてくるものなので、やはりDatabricks導入効果は大きいと考えます。</p><h3 id="hfe0f7dc6ed">まとめと今後の展望</h3><p>部署内のデータ基盤をDatabricksにリプレースしたことにより得られた恩恵を紹介しました。データ基盤でお悩みを抱える方の一助となれば幸いです。</p><p>今後の展望として、データエンジニアリング・データサイエンスについては、Databricksの機能リリースはもちろん、周辺技術についても良いものは積極的に取り入れていこうと考えています（この分野、エコシステムの進化がとても速くキャッチアップは大変ではありますが……）。</p><p>また、データコラボレーションについて、紹介したDatabricksの機能を利用した連携を始めたのはごく最近、適用範囲もごく一部で、データ収集・成果物提供の双方とも従前の方法が大半です。データによる価値創出をより早く行うために、データコラボレーションの機能をフル活用していきたいと考えていますが、それにはグループ各社の協力が不可欠です。グループ各社と気持ちよくコラボレーションするための近道はないので、地道に実績を積み重ねていく所存です。</p><p>イオングループユーザーの皆さまへ一日でも早く価値還元ができるよう、引き続き創意工夫してまいりますのでよろしくお願いいたします。</p><p>執筆協力：土沢誉太</p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

イオン株式会社のAI・Data系部署では、2023年8月よりデータ基盤をAzure Databricksを中心としたものへ刷新しました。本記事ではこれにより得られた恩恵をデータエンジニアの星野さんが解説します。

Azure Databricksを中心としたデータ基盤への刷新。データをグループ会社横断で活用し、価値創出を行う施策

<p>ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野と申します。私が所属しているエネチェンジ事業部では、電気とガスの料金シミュレーションサービス「エネチェンジ」を開発しています。この記事では、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。</p><h2 id="h47a2082ce8">リプレース前の技術スタック</h2><p>リプレース前の「エネチェンジ」のフロントエンドは、jQueryがメインで使われていました。たまに、HTML（正確にはRailsのerbテンプレート）に直接scriptタグで記述されていることもあり、ルールが整備されておらず、既存のコードを読み解くのが大変な状況でした。加えて、Vueの2系を一部導入しており、同じページの中にjQueryで制御している部分とVueのコンポーネントで記述されている部分が混在していました。それも、コードを難解にする大きな要因でした。</p><h2 id="h6e4c81a0fd">リプレースに向けた技術選定</h2><p>最初、Vue2を使っていると聞いたときは、Vue3への移行に気持ちが傾きました。しかし、実際のコードを見てみると、そもそもVue2が使われているのはごく一部であり、Vueの資産を活かすことはほとんど考える必要がないと判明しました。そのため、フラットな視点で、今導入するならReactとVue3どちらが良いかを検討することになりました。調査する前から、明らかにReactが良いだろうとは思っていたのですが、技術選定にあたっては自分や周りの人を納得させられるだけの根拠が必要です。</p><p>そこで、ライブラリのダウンロード数や、他社の事例などを調査しました。ReactやVueを拡張したフレームワークであるNext.jsやNuxtも併せて調査しました。2022年4月当時、npm trendsでダウンロード数を比較した結果、React + Next.jsがVue + Nuxtに圧倒的な差をつけて使用されていることが判明しました。</p><p>↓当時の React と Vue の npm trends のグラフ</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5fd95a4d4db14d538f7ab47dae8099ae/image%20(1).png" alt="" width="2048" height="742"></figure><p>↓当時の Next と Nuxt の npm trends のグラフ</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/3fbfbfd1acd24bcc983322789bbc1dc5/image.png" alt="" width="2048" height="744"></figure><p>また、リプレースの事例を調査したところ、Vue→Reactに移行したという記事はたくさん見つかりましたが、その逆は一つも見つかりませんでした。もうこの時点でReactが良さそうに思えましたが、単にReactの方が多く使われているというだけであり、なぜReactまたはVueを使うのかについてはまだ調べられていません。そこで、数多くの技術記事を読み込み、また、自分自身が両方触った経験も踏まえ、それぞれの特徴をまとめました。</p><p>React + Next.jsの特徴</p><ul><li>TypeScriptとの相性が良い</li><li>Vueに比べ、品質の担保や開発者体験に優れている</li><li>Nuxtは覚えることが多いのに対し、Next.jsはシンプルで覚えることが少ない</li></ul><p>Vue + Nuxtの特徴</p><ul><li>マークアップを直感的に書ける。ReactのJSX記法に比べてとっつきやすい</li><li>コンポーネント単位のCSSがデフォルトでサポートされている</li><li>Vue3 + Nuxt3の登場によりTypeScriptのサポートが手厚くなった<ul><li>逆に言えば当時は過渡期で、主要ライブラリのVue3対応が終わらないと手を出しづらかった</li></ul></li></ul><p>このようにまとめることによって、どちらを選ぶべきかの方針が見えてきました。一言で言うと、品質や開発者体験を優先するならReact、新人育成のしやすさを優先するならVueという方針で選ぶと良さそうです。当時の社内ではジュニアレベルのエンジニアを育成するということはあまりなく、品質や開発者体験を優先するという判断で、Reactを選択することになりました。付け加えると、Reactで開発したいエンジニアが増えていることから、採用にも良い影響がありそうというのも一つの理由となっています。</p><h2 id="h64ba7c16c2">どのようにリプレースしたか</h2><h3 id="h80f1e5b496">静的なページはNext.jsで</h3><p>React化を進めるにあたり、まずはLPなどの静的なページから移行を始めることにしました。なぜなら、LPは以前から速度を改善したいという要望があり、リプレースするにはちょうどよかったためです。大きな方針としてはReactを使うことになっていましたが、リプレースするページが決まったところで、さらに詳細な技術選定をする必要が出てきました。そこで、表示速度やSEO面で有利になり、かつ開発者体験も良いNext.jsのSSGを使うことにしました。また、CSSの書き方についてもいろいろ調べたり実際に触ってみたりした結果、使いやすくて利用者も多いEmotionを使うことにしました。詳細な技術スタックは下記のようになりました。</p><ul><li>Next.js</li><li>TypeScript</li><li>Emotion</li><li>Jest</li><li>ESLint</li><li>Prettier</li><li>Storybook</li></ul><p>最初の1ページは、ほぼ私一人で開発を進めていき、基盤作りもかねてリプレースをしました。正直、思っていたよりも大変でした。ページ内のすべての要素をNext.jsで実装し直す必要がありましたし、一部Railsから電力会社のプランなどのデータを引っ張ってきて表示する必要もありました。そのために、Rails側にAPIを実装しなければならないのですが、そのAPIも私が開発しました。また、インフラの構成としてはAWSのCodeBuildでビルドし、それをS3にアップロードするという形をとりました。インフラの構築自体はインフラチームにお任せしましたが、構成を考えるところや、ビルド設定ファイルの作成は私が行いました。CodeBuildを使うのは初めてだったので、ビルドが成功するまで設定をいろいろと変えながら試行錯誤をくり返しました。最初の1ページを完成させるのに大体4カ月ぐらいかかりました。苦労したかいがあり、ページ速度はPageSpeed Insightsのスコアが40点台だったのが、70点台にまで大幅に改善しました。それに自分自身のスキルアップにもつながる貴重な経験でした。</p><p>その後は、他のフロントエンドエンジニアにも協力してもらいながら、さらに各ページのリプレースを進めました。半年ぐらいかけて、ページ数でいうと1000ページ以上のリプレースに成功しました（ページの種類でいうと4種類ほどです）。リプレース後のページは表示速度が改善したとともに、ソースコードも読みやすくなり、保守しやすくなったと思います。</p><h3 id="h08794f3c7e">「マイエネルギー」の開発でReactの導入が進んだ</h3><p>2023年10月にスマートメーターのCルート開放が実施されることが決定し、我々もスマートメーターのデータにアクセスできるようになりました。それに向けて、そのデータを活用するサービス「マイエネルギー」を開発することになりました。新規開発ということで、当然フロントエンドはReactを使用しました。ただ一つ問題があり、それはスケジュールがタイトだということです。</p><p>ENECHANGEは「電力データを活用した機能を日本で一番早くリリースする」という方針を掲げていたので、2023年10月のリリースが決まっていました。また、諸事情により開発に入る前の工程（企画・デザインなど）が遅れていたため、2カ月ちょっとでリリースできる状態まで持っていく必要がありました。そこで、今回はページ全体をリプレースするという方法ではなく、新規要素のみをReactで実装し、共通パーツ（ヘッダーやサイドバーなど）はRails上の既存のものをそのまま使うという方針で進めました。これにより、工数を最小限に抑えることができたと思います。なお、それを実現するには、Rails上でReactのアプリケーションを読み込む必要があります。それの基盤作りも苦労したので少しお話ししたいと思います。</p><p>今までのフロントエンドの構成は、Vueのソースコードがwebpackでビルドされる仕組みになっていました。このwebpackが非常に遅く、開発サーバーの起動やビルドに1分近くかかっていました。この仕組みをそのまま流用すれば楽に開発環境を構築できますが、これだけ遅いと開発スピードに支障をきたしてしまいます。そこで、チームで話し合った結果、Viteを使うことにしました。その結果、一瞬で開発サーバーが起動するようになり、ソースコードの変更も一瞬で反映されるので、かなり開発者体験が良くなりました。なお、Viteで構築したものをRails側で読み込めるようにするのも苦労しました。調べたところ、vite_railsというGemを使うのが一般的らしく、逆にGemを使わずに自力でRailsとViteを連携させた事例は一つも見つかりませんでした。しかし、実際にvite_railsを使ってみたところ、以下のような問題が発覚しました。</p><ul><li>Viteの設定ファイルやpackage.jsonなどがRailsのルートディレクトリに置かれてしまう<ul><li>上記はreactディレクトリに置きたいのに、それができず、ファイルが散らばってしまう</li><li>設定ファイルの場所を変更するオプションもなさそう</li></ul></li><li>そもそも、フロントエンドのためにGemに依存するのはあまりやりたくなかった</li></ul><p>念のため、他のフロントエンドのメンバーにも意見を聞いてみたのですが、やはりvite_railsは使いたくないという意見で一致したので、Gemを使わずに自力でRailsとViteの連携を実装することにしました。</p><p><a href="https://ja.vitejs.dev/guide/backend-integration.html" target="_blank" rel="noopener noreferrer nofollow"><u>https://ja.vitejs.dev/guide/backend-integration.html</u></a> を参考にしながら、実装を進めました。これも試行錯誤のくり返しでしたが、バックエンドエンジニアにも相談しながら、なんとか実装できました。今回、バックエンドの実装が終わる前にフロントエンドの開発が始まりました。そこで、バックエンドのAPIが完成しなくても進められるように、OpenAPI（Swagger）のファイルを作成し、そのAPI定義をもとにフロントエンドとバックエンドの開発を並行して進めました。おかげで、なんとかスケジュール通りにリリースすることができました。</p><h2 id="h28b62bc2c0">今後の課題</h2><p>このように1年半にわたる「React化」の結果、モダンなフロントエンド開発が進んだとはいえ、まだまだレガシーなコードがたくさん残っています。特にVueで書かれた箇所が結構読みにくくて管理コストがかかっているので、その部分を優先的にReact化していきたいなと考えています。</p><p>また、「マイエネルギー」の開発で、フロントエンドとバックエンドの連携に関する課題が見えてきました。APIスキーマをあらかじめ共有することによりうまくいった部分もありますが、時間がなかったこともあって、どのような値を入れてほしいのかについての意思疎通が十分にできていませんでした。結果として、意図したものとは異なる動きになっている箇所が出てしまいました。今後は、APIスキーマの説明をできる限り詳細に書くことや、必要に応じてフロントエンドとバックエンドですり合わせのミーティングを実施するなどの工夫をしていきたいです。</p><h2 id="ha214098e44">まとめ</h2><p>ENECHANGEにおけるフロントエンドのリプレースプロジェクト「React化」について紹介しました。フロントエンドのリプレースは決して簡単なことではありません。既存のレガシーなコードを読み解きながら、最新の技術で実装し直す必要があり、高度なスキルが求められます。だからこそ、リプレースは、エンジニアがスキルアップするチャンスです。私もこのプロジェクトを通して、エンジニアとしてのスキルに磨きがかかった実感があります。また、React化は、開発組織の士気を高めることにもつながったと思います。メンバーからは「新しいコードは読みやすくて修正しやすい」と言ってもらえました。本当にやってよかったなと思いました。</p><p>最近は弊社だけでなく、さまざまな現場でフロントエンドのリプレースを進めていたり、検討していたりすると思います。スキルアップしたいエンジニアのみなさん、チャンスがあれば、ぜひチャレンジしてみてはいかがでしょうか。</p><p>編集：中薗昴</p><p style="text-align: start">提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow"><u>株式会社Haul</u></a></p>

ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野さんが、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。

レガシーなフロントエンドをリプレースするプラクティス。エネチェンジが挑む「React化」

<p>こんにちは、LINEヤフー株式会社の児玉です。現在は出前館に出向し、主にコンシューマ向けアプリケーションのフロントエンド開発を担当しています。</p><p>現在、出前館フロントエンドはWebの画面単位でのリプレイスを進めており、あと少しで完了予定となっています。</p><p>もともとリプレイスした経緯としては、レガシーな技術で保守が難しいコードベースが、だんだんと負債になっているのを感じていたことからです。たとえば、新しく加わったエンジニアにとって理解しにくいコードベースや開発スピードの低下といった問題があったため、モダンな技術を使ってリプレイスすることにしました。しかし、モダンな技術にリプレイスしたからといって負債がゼロになるわけではなく、新たな課題などが見つかります。出前館Webでもリプレイスを進める中で技術的な課題に何度か直面し、アーキテクチャなどの大きな変更も行いました。</p><p>本記事では出前館Webでのリプレイスとリアーキテクトの取り組みについてご紹介したいと思います。</p><h2 id="had005982f7">PHP + jQueryで作られていたWebをリプレイス</h2><p>出前館はPHPのCodeIgniterというフレームワークで開発されていましたが、以前はQAや開発体制が整っていなかったため、以下の問題がありました。</p><ul><li>巨大な1ファイルにロジックが集約されていたため、コードベースの可読性が低く、メンテナンスが難しい状態になっていた。</li><li>本来サーバーサイドにあるべきロジックがフロントエンドに寄せられていたため、WebとAppで同じようなロジックが多数存在していた。そのため修正や改善を行う際にWebとAppの両方を直す必要が多々あり、開発スピードも落ちていた。</li><li>フロントエンドチームにPHPが得意なエンジニアがいない。</li></ul><p>これらの理由から、既存のシステムを引き継ぐのではなく、全面的にリプレイスすることにしたのです。</p><p>新しい技術スタックは、開発コミュニティが大きくエコシステムも充実しているReactを採用しました。また出前館アプリがReact Nativeで開発されているなど、出前館全社としても採用が進んでいる技術です。</p><p>WebのフレームワークはCSR（Client Side Rendering）やSSR（Server Side Rendering）、SSG（Static Site Generation）などのさまざまなレンダリング手法をページ単位で適用できるNext.jsを採用し、Next.jsのAPI Routesを使いBFF（Backend for Frontend）の層を設けることにしました。</p><p>BFFのモデルとして、クライアントごとにBFFを持つこともありますが、出前館ではWebとAppで別々のサーバーを立てて運用するとコストが高くなると考え、WebとAppで1つのBFFを使うことにしました。またWeb/AppとBFF間のプロトコルにGraphQLを採用し、クライアントから柔軟な形でクエリできる構成としました。</p><p>さらにサーバー側はマイクロサービス化を進めていることもあり、BFFは複数のマイクロサービスからデータ取得しそれらを集約してクライアントに返すAggregation Gatewayの役割も担っています。</p><p>ざっくりとした構成は下記の通りです。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/825a0c92763145a0bb850cdf5d0d38f0/image2.png" alt="" width="977" height="518"></figure><h2 id="h2ce2a72a8c">WebとBFFの分離</h2><p>上記で述べたリプレイスでは全画面を一気にリプレイスするのではなく、画面単位でのリプレイスをする戦略をとりました。</p><p> しかし、何画面かのリプレイス後に気付いたのですが、Next.jsのAPI RoutesをBFFとして使っているとWebとBFFは同じサーバーかつ同じコードベースになることから、以下の問題が出てきました。</p><ul><li><strong>コードベースのメンテナンス性の低下</strong>：WebとBFFのコードが混在してわかりにくくなっていた。Webはさらにクライアントとサーバー側に分かれており、実際は3つの異なる役割のコードが存在していた。そのせいもあって、新しくエンジニアが参画するたびにコードベースについて質問され、説明していた。</li><li><strong>サーバーの柔軟性</strong>：Webの負荷は主にSSRで、BFFはWebとAppの両方からのリクエストをさばいているため、Webよりも高負荷になる。1つのサーバーで管理していると柔軟性がなく最適化などが難しい状態だった。</li><li><strong>デプロイの分離</strong>：デプロイやロールバックでWebとBFFの切り離しができなかった。たとえば、デプロイ後にWebで不具合があってロールバックをする際にBFFも一緒にロールバックする必要があった。さらに、場合によってはBFFを呼んでいるAppも戻す必要があった。</li></ul><p>こうした問題を解決するために、Next.jsのAPI RoutesをBFFとして使うのをやめ、WebとBFFのサーバーとコードベースを分けることにしました。</p><p>BFF用のサーバーを別で立てることにより、サーバーの台数調整、デプロイとロールバックの切り離しも柔軟に行えるようなりました。</p><p>また、コードベースもMonorepo化し、パッケージ単位でWebとBFFを切り分けることができたのでわかりやすくなりました。</p><p>ざっくりとした構成は下記の通りです。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b63ec121302d40009d141458a554845e/image3.png" alt="" width="977" height="522"></figure><h2 id="h0313e6d6f3">リプレイス・リアーキテクトの改善点</h2><p>Next.jsのAPI RoutesをBFFとして使うのを途中でやめたように、技術を新しくしたからといって、課題や負債がなくなるわけではありません。実際に、出前館でもリプレイスしていく中で他にも改善したい点はいくつかあります。たとえば次のようなことがあります。</p><ul><li><strong>Webのコンポーネントのディレクトリ構成</strong>：当初はコンポーネントのディレクトリ構成にAtomic Designを採用しており、コンポーネントの責務が明確になるなどのメリットもあったが、そこまで細かくコンポーネントを分けるメリットを感じなかった。</li><li><strong>GraphQL Client選定</strong>：Apollo Clientを採用しているが、SSR時の負荷が高いことや、メモリリークの問題などに直面。</li><li><strong>GraphQL  Server選定</strong>：コミュニティが大きいなどの理由からApollo Serverを採用しているが、他のGraphQL Serverに比べてパフォーマンスが劣る。</li><li><strong>Monorepoの採用</strong>：リリース時のブランチとmainブランチの差分が大きくなりがち。共通パッケージなどはなく、Monorepoを有効活用できていない。</li><li><strong>エラー設計</strong>：エラーの表現やハンドリングの仕方に統一性がない。GraphQLスキーマでエラーを表現する方法やエラーをスローする方法など、チーム全体で共通の理解を事前に確立すべき。</li><li><strong>ログ設計</strong>：ログのフォーマットやログレベルに統一性がない。</li></ul><p>このようにリプレイス途中でも多くの課題が見つかり、今も継続的な改善を実施しています。改善を施してもビジネスや技術の変化や考慮不足から負債は生まれるもので、それとどう向き合うかが大事だと思っています。</p><h2 id="h9be0c3393d">おわりに</h2><p>この記事では、出前館Webにおけるリプレイス・リアーキテクトによる技術負債の解消への試みについてご紹介しました。</p><p>技術やアーキテクチャはより良いプロダクトを作るために、状況に応じて常に変化し続けるもので、最初から完璧なアーキテクチャや技術選定をするのは不可能です。</p><p>重要なのは、問題や負債を蓄積せず、継続的な改善を行うためのチームや仕組みを築くことだと思います。</p><p>出前館では、リリース前には自動でのリグレッションテストを実施したり、GitHub Discussionsやミーティングで新しい取り組みへ前向きに議論する場を設けたりし、継続的な改善を積極的に行っています。</p><p>今後も、より良いプロダクトを作るためにこの姿勢で改善を続けていきます。またどこかで別の改善などをご紹介できればと思います。</p><p>編集：中薗昴</p><p style="text-align: start">提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow"><u>株式会社Haul</u></a></p>

出前館フロントエンドはWebの画面単位でのリプレイスを進めています。その事例について、LINEヤフー株式会社の児玉さんが解説しました。


PHP+jQueryをReact+Next.jsに移行。出前館Webが選択したリプレイス戦略

<p>はじめまして、<a href="https://www.asoview.co.jp/"><u>アソビュー</u></a>でデータ基盤チームに所属している霧生です。</p><p>近年、モダンデータスタックの登場などによりデータ分析基盤は一層盛り上がりを見せています。選択肢も増えてできることが多くなった反面、どう構築していくか迷う場面も多いのではないでしょうか。今回はアソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説しますので、ご参考になれば幸いです。</p><h2 id="h551033d7c6">現在のアソビューのデータ分析基盤</h2><p>アソビューは創業10周年を超えており、当然ながら今までもデータを分析して事業やサービスに役立ててきました。しかし、コードやインフラの継ぎ足しを重ねたことにより秘伝のタレのような状態と化してしまい、多くの課題が生まれています。そこで、アソビューではこの問題を解消するために、昨年から<a href="https://datale.co.jp/"><u>株式会社DATALE</u></a>さんとともにデータ分析基盤の再構築を行いました。</p><p>データ分析基盤を構築するにあたり、「使われる」データ分析基盤にすることを大切に設計・実装していきました。というのもそもそも「データ分析基盤は使われなければ意味がない」からです。ただデータを収集しているだけ、データ分析基盤を作ることだけが目的になってしまっている場合、どれだけ優れたアーキテクチャを組んでも、データからインサイトを得てビジネスに役立てるデータ活用のプロセスが進みません。</p><p>では、どうすればデータの活用が進むのでしょうか。その答えのひとつが弊社も利用しているBIツール、<a href="https://www.tableau.com/ja-jp" target="_blank" rel="noopener noreferrer nofollow">Tableau</a>が提唱しているビジュアル分析のサイクルにあると考えています。</p><p></p><figure><a href="https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm" target="_blank" rel="noopener noreferrer nofollow"><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5a80e285e9884c8894dbfeb628a3f26e/image1.png" alt="" width="489" height="425"></a><figcaption>ビジュアル分析のサイクル。画像は https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm より引用。</figcaption></figure><p>「どこからデータを分析していけばいいかわからない」「分析結果を見てもよくわからない」というユーザーからのフィードバックは「タスク」がないことに起因していることが多いです。</p><p>簡単な例ですが、「売り上げを上げたい」「コストを下げたい」といったタスクに対して、どんなデータを見ればいいか、さらにそのデータをどう見ればいいかなどを考えて、必要十分なデータを取捨選択していくことが重要です。こうして適切なデータを適切に扱うことで、より価値のある活用につながります。また、ビジュアル分析のサイクルはただのプロセスサイクルではないため、分析を行う中でさらに必要なデータが出てくることもあります。柔軟かつ高速にビジュアル分析のサイクルを回すことで、データ分析基盤は使われる・価値のあるものに進化していきます。</p><p>分析者と同じ視点に立ち、高速に新しいデータを連携して分析のプロセスを回す。これがデータ分析基盤を新規に作り上げていく段階では特に重要な観点だと考えています。そこで私たちが導入したのが<a href="https://trocco.io/lp/index.html"><u>trocco</u></a>です。troccoとはETL/データ転送機能を提供する分析基盤構築・運用支援のSaaSです。troccoを提供している<a href="https://primenumber.co.jp/"><u>株式会社primeNumber</u></a>が日本企業ということもあり、日本語での手厚いサポートや日本でよく使われるSaaSからのデータ連携にも多く対応しています。troccoは主にGUIで設定を作成するため、初期の学習コストや設定作業のコストを大幅に削減でき、いち早くデータを提供できます。</p><p>また、データウェアハウスには<a href="https://cloud.google.com/bigquery?hl=ja"><u>BigQuery</u></a>を採用しました。これも構築・提供スピードを重視した技術選定です。GAなどの他のGoogleサービスとの親和性や、よく使われるSaaSとの連携に対応していることを考えて選択しました。</p><p>最終的なアーキテクチャは下記のようになりました。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8ed3924aac5846ada4dbc3991266cc67/image2.png" alt="" width="1537" height="865"></figure><p>troccoにはデータマート生成という機能があり、これを利用して収集したデータを最終的に分析可能な状態に変換してデータマートを構築しています。</p><p>BIツールは先にも出てきたTableauを利用しており、直近では社内のアクティブユーザー数が全社員の4分の1に迫る40人前後、Tableau Cloud上での分析結果のView数は約600view/日と、広く使われる状態を実現できていると感じています。今ではマーケティング施策やモニタリングだけではなく、アプリケーションへのデータの利活用や広告の最適化など、さまざまな用途でデータ分析基盤が使われています。</p><p>これは株式会社DATALEさんのご協力はもちろんですが、分析しているアソビュー社員のデータに対しての感度の高さや意欲など、さまざまな立場とスキルを持ったメンバーが揃い尽力した結果だと思います。データ分析基盤は使われなければ意味がないと冒頭で書きましたが、それはつまりエンジニアだけで作り上げるものではなく、使っている人や状況に応じてアーキテクチャも変わっていくべきということです。現状は前述の構成を使っていますが、運用している中での課題も出てきており、その解決のためには小手先の対応ではなくアーキテクチャレベルの改修が必要になっています。</p><h2 id="h7070e90391">将来的なデータ分析基盤の構想と導入したい技術</h2><p>先に挙げた現状抱えている課題ですが、大きく分けて下記の2つがあります。</p><ul><li>データマートに対してのSQLの実行速度とデータ基盤全体の料金</li><li>データ分析基盤の堅牢性</li></ul><h3 id="h4312134b13">データマートに対してのSQLの実行速度とデータ基盤全体の料金</h3><p>ビジュアル分析のサイクルを高速に回していくには、さまざまなデータについて異なる角度から何度もビジュアル分析を試すデータ探索によって、BIツールから素早く結果を取得できることが重要になります。アソビューではデータ分析基盤の利用が拡大し分析可能なデータが加速度的に増えていった結果、いくつかのテーブルで速度劣化が起きるようになりました。また、うれしい悲鳴ではありますが、データ分析基盤の利用が拡大し利用者が増えたことにより料金も大きく増加しています。</p><p>テーブルの構造変更やBigQueryの機能の利用など、現状のアーキテクチャでも改善できる部分は当然あると考えています。しかし投げるクエリやテーブルの性質、利用しているBIツールとの相性などを鑑みて、アソビューの場合は同時並行で検証を行っていた<a href="https://www.snowflake.com/ja/"><u>Snowflake</u></a>を利用することでこれらの課題に対して一定の効果が期待できると判断しています。</p><p>速度面では、データ探索中にTableauが類似したクエリを多く投げる点や、ライブ接続でViz*を見た場合に同じクエリが投げられる点などから、Snowflakeの強力なキャッシュ機能の恩恵を受けやすいこと。料金面では従量課金の方式がBigQueryではデータのスキャン料であるのに対して、Snowflakeはデータウェアハウスというコンピュートリソースの起動時間であるため、予測が立てやすく利用者が爆発的に増えた場合でも対応しやすい料金体系になっていることが理由です。</p><p><em>*…Tableauで作成した、ビジュアライズされたグラフや表。</em></p><p>また、管理側の目線ではクラウドサービスプロバイダーであるGCPのひとつの機能であるBigQueryよりも、データクラウドとしての機能に特化しているSnowflakeのほうがアクセスコントロールが優れている点もあり、管理と利用の両面でSnowflakeへの移行はメリットが大きいです。</p><p>一部ではすでにSnowflakeの実験利用が始まっています。GAなどBigQueryに依存したデータがあるので、Snowflakeだけでデータ分析基盤を構築することはできないですし、クエリの細かな違い、データの移行やどう活用するかのステップなど多くの課題がありますが、一歩一歩移行を進めていく予定です。</p><h3 id="h11f5f4f8cc">データ分析基盤の堅牢性</h3><p>データ分析基盤の利用者が増えて、データ分析基盤自体の業務への依存度が高まっています。それに伴い、データの鮮度や状態といったデータ分析基盤の可用性や変更に対しての強さ、堅牢性の重要度が日々増しています。</p><p>troccoはGUIからの設定が主であるため導入コストの低さが特徴です。しかし、分析できるデータが増えて規模が大きくなるにつれて、データマートを構築するためのクエリやそれらを取りまとめるワークフローは複雑になっており、管理が煩雑で属人化が激しくなってきています。これをきっかけに、より使われるようになったからこそ堅牢性を上げていきたいと考えています。しかし、堅牢性は構築スピードとトレードオフになってしまうため、バランスをどう取るかに頭を悩ませています。</p><p>現状この問題に対してはdbtを導入することが良いのではないかと考えています。troccoにもdbt連携という機能があるため、どこでどう実行するか、Snowflakeへの移行も含め今後検討していく予定です。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>アソビューにおけるデータ分析基盤のアーキテクチャと、その設計意図に関しての紹介でした。</p><p>技術の更新が激しい界隈ですし、ここには書けていない課題も多くある状況です。お察しの通りアソビューのデータ分析基盤はまだまだ道半ば、なんなら走り始めた段階だと思っています。しかし、データ分析基盤の利用者は日々増えており、データドリブンな文化も浸透してきています。ここを走り切ってデータの利活用が進むことが大きく事業を成長させる重要な要素であることは間違いありません。</p><p>これからも、より「使われる」データ分析基盤になるように改善を続けていきます。1年後には別の姿になっているかもしれません。その時はまたどこかで共有できればと思います。本記事が皆さまの一助になれば幸いです。</p><p>編集：中薗昴</p><p style="text-align: start">提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow"><u>株式会社Haul</u></a></p>

アソビューでデータ基盤チームに所属している霧生さんによる寄稿。アソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説します。

trocco・BigQuery・Tableauを採用。アソビューがデータ分析基盤の再構築に挑んだ理由

<p>株式会社アンドパッドの白土慧と申します。OSSなどではkei-sで活動しています。アンドパッドではリアーキテクティングチームに所属し、チームの立ち上げから携わっています。</p><p>リアーキテクティングチームの活動を簡単に紹介すると、アンドパッドにある大規模なRailsアプリケーションを、コードや構造も含めて、もっと拡張しやすくて、開発者が使いやすく、ミスの防止などもできるようにする活動をしています。今回のRuby/Railsのアップデートも取りまとめているほか、チームのスコープにはマイクロサービスやモジュラーモノリスなどへの移行の検討も含まれます。</p><h3 id="hee53e05de9"><strong>アンドパッドでのRailsの役割</strong></h3><p>アンドパッドにある大規模なRailsアプリケーションをもう少し掘り下げます。</p><p>このアプリケーションは「ANDPAD施工管理」や「ANDPAD黒板」、「ANDPAD検査」などのアプリ向けのAPIサーバーであり、ブラウザレスポンスも返しています。他の製品ではGoも使って開発していますが、アンドパッドではこのRailsアプリケーションが最も歴史があります。それだけに大規模で、モデルだけで20万行はあります。私の開発経験上でも一番の規模です。この中で、コード品質を上げる取り組みとして、例えばRuboCopを使った検査や写真といったデータの持ち方などを整理しています。</p><h2 id="hd26e0f350d"><strong>アンドパッドがRuby/Railsを最新に保つ理由</strong></h2><p>では、本題に入りましょう。</p><p>まず現在のバージョンを申し上げると、Railsは、ほぼ最新の7.0系で、さらに近々アップデート予定です。一方でRubyはつい先週に最新の3.2.2にアップデートしたばかりです（2023年10月執筆時点）。そして、アンドパッドでは「最新に追従すること=&quot;しょっちゅう&quot;アップデートすること」*を方針としています。その理由をこれから紹介します。</p><p>*<a href="https://cruel.org/freeware/cathedral.pdf"> <u>「伽藍とバザール(The Cathedral and the Bazar)」(Eric S. Raymond 著 / 山形 浩生 訳 ©2000 YAMAGATA Hiroo.）</u></a>の見出し、&quot;はやめのリリース、しょっちゅうリリース&quot;からのインスピレーションです。</p><h3 id="ha814922afd"><strong>大きなジャンプの歴史</strong></h3><p>読者の皆さまには、これだけの規模だと影響範囲が広く、アップデートしにくいことを察していただけるのではないかと思います。ご多分に漏れず、アンドパッドでもアップデートが停滞し、過去にはジャンプが発生していました。</p><p>私が入社後に行われたものでは、2022年末から2023年1月にかけてのRubyのバージョンを2.7系から3.0へとアップデートしたことがそれに当たります。そのときは今のリアーキテクティングチームのような専門チームはなく、私のほか数名とSREの有志のチームで行ったため、通常業務とアップデート業務の両方をこなす必要があり、非常に負荷が高い状況になりました。また、本来のアップデート作業以外にも、各製品開発チームすべてが行う動作確認とその確認結果の集約に、とりわけ多くの工数がかかりました。</p><p>このようにジャンプが発生すると、どうしても工数が膨らみ、各製品チームのロードマップやマイルストーンにも影響を与えます。これはRubyに限らず、Railsでも発生し、誰もが苦労をしていました。</p><h3 id="h745d6ec3f1"><strong>アップデートを止めることは「後退する」と同じ意味</strong></h3><p>アップデートはいつかはやらないといけません。放っておいても楽になることはなく、スキップすればするほど、後回しにすればするほど、どんどん作業が膨らむだけです。アンドパッドはこれまでのジャンプでそれを痛感しました。フルタイムRubyコミッターとしてアンドパッドに入社したhsbtからも、「世の中のほうが進んでいるので、止まる=後退すると同義である。前に進んでようやく留まっている」というアドバイスもあり、先ほど挙げた「&quot;しょっちゅう&quot;アップデートする」方針に変更しました。小さくアップデートすれば、影響範囲も限定的になり、工数も抑えられます。</p><h3 id="hbea341950c"><strong>ANDPADユーザーにもいい影響がある</strong></h3><p>&quot;しょっちゅう&quot;アップデートする方針に変更することには、ANDPADユーザーにもメリットがあります。特にRuby3系は3×3構想の通り、レスポンス速度が上がっており、タフな建築・建設現場でのユーザー体験の向上に寄与し、ポジティブな影響を与えられます。話題のYJITもスイッチONで動くことはわかっていますので、これも視野に入れています。もしアップデートが停滞した場合、脆弱性があったとしてもすぐに直せない可能性があり、ANDPADユーザーはもちろん、ビジネスとしてもリスクでしかありません。ANDPADは17万社44万人ものユーザーの毎日の業務を支える大規模SaaSだからこそ、安心して使える環境を用意しなくてはならないため、常に最新にアップデートすることにより、セキュリティも担保しやすくなります。</p><p>関連して、一般的には、アップデートのような内部品質の向上よりも、外部品質（例えば、ビジネスサイドや経営陣からの新機能開発の要求など）の向上が優先されがちです。しかし、アンドパッドが内部品質向上を専門とするリアーキテクティングチームを組んだことそのものが、ビジネスサイド・経営陣の理解がある証拠であり、また内部品質に投資するだけの体力・体制があるとも言えます。</p><h2 id="h35a070217c"><strong>アップデート体制と進め方の工夫</strong></h2><p>では、実際にどのようにアップデートを進めているのか、詳しく紹介します。</p><h3 id="hd94232778f"><strong>リアーキテクティングチームが中心</strong></h3><p>先ほど触れたRuby2.7→3.0へのアップデートでの教訓から、リアーキテクティングチームが進める体制となりました。ただし、他のチームに「アップデートはリアーキテクティングチームの仕事だから、やらなくていいや」と認識されることは本意ではなく、エンジニア全体でやることが理想です。現在はその過渡期にあり、リアーキテクティングチームがその環境整備を進めている段階です。</p><p>リアーキテクティングチーム主導になったことで、チームはアップデートに集中できるようになり、前回のような高い負荷はありません。また、ジャンプではなく、小さなアップデートにフォーカスしたことで、影響範囲を絞り込めて、自動テストでエラー検知がしやすく、安心してアップデートを進められました。そのほかhsbtからアップデートで影響がありそうな変更やYJITの話、注意点のアドバイスをもらえ、見通しがつけやすくなりました。ただ実際hsbtに手を動かしてもらう場面はなく、アップデート作業そのものはチームですべて完結できました。</p><h3 id="hf971e18d0c"><strong>数週間に及ぶmainブランチを使った開発検証でアップデートを検証</strong></h3><p>自動テストでアップデートによる非互換が検知されるとはいえ、エッジケースでの分岐や込み入った実データなど、手で触ってみることで自動テストではカバーできない部分の非互換が見つかることも考えられます。このため引き続き、各製品チームの動作確認が必要であり、工数がかかることが予想されました。また、一定期間だけ特定の開発環境を用意→動作確認→OK→マージと進んでも、その期間に新たに追加された機能の動作確認漏れが発生し、エラーが起きる可能性が高まります。</p><p>そこで社内検証環境の中に、プロダクションと同じmainブランチが動いているものがあり、それを最新のRubyバージョンにして何週間も動かす、ということに取り組みました。日々のプルリクエストなどによる開発の動作確認もその環境で行っているので、何週間にも及ぶ検証の結果、アップデートしても問題がないことがわかりました。この取り組みにより、動作確認の工数が膨らむこともなく、大きなエラーも発生しませんでした。</p><p>これにはRuby2.7→3.0で取り組んだCI/CD環境などの知見がそのまま活きています。詳しくはアンドパッドのテックブログで紹介していますので、ぜひご覧ください。</p><p><a href="https://tech.andpad.co.jp/entry/2023/02/21/100000" target="_blank" rel="noopener noreferrer nofollow">複数チームが開発するモノリシックなサービスにおける、Rubyのバージョンアッププロジェクトの進め方とこのプロジェクトから学んだこと - ANDPAD Tech Blog</a></p><h2 id="h3a22275536"><strong>これからはRuby/Railsアップストリームへのコントリビュートが視野</strong></h2><p>最後に今後の展望です。</p><p>今回のRuby3.2.2のアップデートにより、最新の環境になりました。これでhsbtたちRubyコアチームが毎日開発している最新バージョンを取り込み、実験できるようになりました。Nightly Buildを取り込み、テストを動かせば、すぐに問題箇所がわかり、アップストリームへのフィードバックも即座にできます。アンドパッドだけでなくRubyコミュニティにもメリットをもたらせるようになりました。こういうことができるのがフルタイムRubyコミッターを抱える強みの一つです。また、リアーキテクティングにはRailsチームのメンバーにも関わってもらっているので、Railsでも同様のことができます。</p><p>今後は<a href="https://github.blog/2023-04-06-building-github-with-ruby-and-rails/" target="_blank" rel="noopener noreferrer nofollow">Building GitHub with Ruby and Rails - The GitHub Blog</a>でGitHubが発表したように、アンドパッドはRubyやRailsの改善に積極的に貢献し、ANDPADユーザーの体験向上に還元したいと考えています。</p><p>編集：中薗昴</p><p style="text-align: start">提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow"><u>株式会社Haul</u></a></p><hr><p>著者: 白土 慧 (Shiratsuchi Kei) GitHub:<a href="https://github.com/kei-s"> <u>kei-s<br></u></a></p><p>ソフトウェアエンジニア。好きな言語はRubyとRust。好きな小説家は舞城王太郎。現在はアンドパッドでRailsアプリケーションの大規模リファクタリングに携わっている。過去にはKaigi on Rails 2022「実践 Rails アソシエーションリファクタリング」などで登壇している。</p>

本コラムでは「株式会社アンドパッド社がなぜ最新のRuby/Railsにこだわるのか？」についてリアーキテクティングチームのkei-sさんがご紹介します。

なぜ、アンドパッドは最新のRuby/Railsにこだわるのか？アップデートを止めないための体制と仕組み

<p>DIGGLE株式会社でエンジニアリングマネージャーをしている岡崎と申します。普段はエンジニアチーム全体のマネジメントを担いつつ、開発業務も行っています。DIGGLEは予実管理クラウドサービス「<a href="https://diggle.jp/" target="_blank" rel="noopener noreferrer nofollow">DIGGLE（ディグル）</a>」を提供するスタートアップであり、「<a href="https://rubykaigi.org/2023/" target="_blank" rel="noopener noreferrer nofollow">RubyKaigi 2023</a>」の<a href="https://rubykaigi.org/2023/sponsors/#sponsor-498" target="_blank" rel="noopener noreferrer nofollow">スポンサー</a>を担うなどテクノロジーやそのコミュニティへの投資を積極的に行っています。本記事ではDIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。</p><h2 id="h48ed43c917"><strong>工数の何%を負債解消に充てるかを四半期ごとに経営と合意する</strong></h2><p>技術的負債解消は、エンジニアチーム単体でやり切るにも限界があり、経営陣の理解を得ることが重要です。弊社はCTOが共同創業者であるため、エンジニアの意見が経営陣へダイレクトに届き、経営陣の技術に対する理解度が非常に高いのが特徴となっています。CTOから技術的負債がビジネスに及ぼす影響を経営陣に説明することで、技術的負債解消の重要性を経営陣も理解し、技術的負債解消に対して一定の工数を割くことができる状態になっています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/90021b12fa5c4ad2b95ae2b93b342a63/image4.jpg" alt="" width="1920" height="1290"><figcaption>CTOがProductチームと経営陣のハブとなっている</figcaption></figure><p>実際にどの程度の工数を割くかについては、四半期ごとに、私とCTOで技術的負債解消に割り当てられる工数の目安を相談して決めています（おおよそ20%程度に収まることが多いです）。</p><p>このような仕組みにすることで、技術的負債を会社全体の関心事として捉え対応することが可能となり、「日々の作業が忙しくて技術的負債解消を行うことができない」という状態に陥らないようにしています。</p><p>実際に、技術的負債解消の中で解決した問題を弊社のエンジニアブログで取り上げていますのでご紹介します。</p><p><a href="https://diggle.engineer/entry/fixed-issue-railsapp-caused-by-updating-ruby31-to-ruby32" target="_blank" rel="noopener noreferrer nofollow">Ruby のバージョンを 3.1 系から 3.2 系にアップデートしたら Ruby on Rails アプリの動きが変わったのを解決した話</a></p><p>DIGGLEでは経営陣に技術に対する理解があるためこうした体制を実現できていますが、読者の中には「なかなか経営陣に技術的負債解消の重要性を理解してもらえない」という環境の方もいらっしゃるかもしれません。</p><p>その場合は、臨機応変に可能な限り権限が高い方（CTO、部長、リーダーなど）と技術的負債解消の重要性を共有し、組織やチームで継続的に技術的負債に対応できるように働きかけていくことから始めると良いと思います。</p><p>そして、技術的負債の解消により得た実績（工数が削減した、バグが減少したなど）を収集することで、技術的負債解消がどのような好影響を与えたかを定量的に測れる仕組みを作ることが肝要となります。そうして計測した数値を基に、経営陣と根気強く対話をし、ゆくゆくは会社全体で技術的負債に立ち向かえる環境にしていきましょう。</p><p>参考までに、弊社で計測している数値をご紹介します。弊社では以下の数値などを四半期ごとに計測し、CTOを含む開発チーム全体で状況を共有する仕組みを作っています。</p><ul><li>どの作業にどのくらいの工数が掛かったか（新規機能開発 / 既存機能改善 / 技術的負債解消 など）</li><li>本番環境でどのようなバグが発生したのか（インシデント / デザイン崩れ / 軽微なバグ など）</li><li>上記のバグ対応でどのくらいの工数が掛かったか</li></ul><h2 id="h374361b6fc"><strong>開発作業の終わりにリファクタリングを行う文化</strong></h2><p>弊社のエンジニアチームには、開発作業が終わったタイミングでリファクタリングを行う文化があります。</p><p>これは私が社員3人目として入社した2019年当時から存在しているのですが、開発作業が終わってPull Requestを投げる前に、リファクタリング用のタスクを切って、コードの整理やテストコードのバリエーション追加などの対応を各エンジニアの裁量で行う文化です。</p><p>これにより、常日頃から各エンジニアが個人レベルで意識を持って作業し、「そもそも技術的負債がたまりにくい土壌」が作られています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b13cf930af924a2a8cbdcef3f932f86e/image8.jpg" alt="" width="1417" height="643"></figure><h2 id="hfea3fe6791"><strong>TODOやFIXMEを放置しない仕組み</strong></h2><p>エンジニアの皆さんは共感してくださると思うのですが、ついつい書いておきたくなってしまうTODOやFIXMEは、時間が経って数が多くなってくると以下のような問題が起こります。</p><ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない</li></ul><p>弊社では、これらの解決策として「TODOやFIXMEを書く場合はJIRAにタスクとして挙げ、TODOコメントにはJIRAのリンクを記載する」というルールを作っています。これにより、先ほどの問題点は以下のように解決することができます。</p><ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する<p>→常日頃使っているJIRA上でタスクとして確認することが可能になる</p></li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない<p>→JIRAの本文に背景・内容を記載することで把握ができる</p><p>→バックログリファインメントで新規JIRAタスクを確認する際に、背景・内容が理解できるものになっているかチェックすることができる</p></li></ul><p>上記運用に際して、Pull Requestレビュー時に目視でチェックすることは難しいため、TODOやFIXMEにJIRAリンクを付けていないとエラーになるようにCIを組んでいます。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fa06a9c72c4042138f0afb4a685dce92/image5.png" alt="" width="1207" height="218"></figure><p>参考までにrubocopのソースコードを添付します。</p><pre><code class="language-ruby">class TodoComment &lt; RuboCop::Cop::Base
  include RuboCop::Cop::RangeHelp

  MESSAGE = &apos;Annotation comment, with keyword `%&lt;keyword&gt;s`, should have JIRA TASK (ex: DEV-N).&apos;.freeze

  def on_new_investigation
    processed_source.comments.each_with_index do |comment, index|
      next unless first_comment_line?(processed_source.comments, index) ||
                  inline_comment?(comment)
      annotation = RuboCop::Cop::AnnotationComment.new(comment, keywords)
      next unless annotation.annotation?
      next if jira_task?(annotation)

      register_offense(annotation)
    end
  end

  private

  def register_offense(annotation)
    range = annotation_range(annotation)
    add_offense(range, message: format(MESSAGE, keyword: annotation.keyword))
  end

  def first_comment_line?(comments, index)
    index.zero? || comments[index - 1].loc.line &lt; comments[index].loc.line - 1
  end

  def inline_comment?(comment)
    !comment_line?(comment.loc.expression.source_line)
  end

  def annotation_range(annotation)
    range_between(*annotation.bounds)
  end

  def jira_task?(annotation)
    annotation.comment.text.match?(/DEV-\d+/)
  end

  def keywords
    %w[TODO FIXME]
  end
end</code></pre><h2 id="h92a239a3a7"><strong>ライブラリのアップデートを、SaaSを使って自動で行う</strong></h2><p>弊社プロダクトは主にRuby on RailsとReactで構成しているのですが、gemやnpmなどのアップデートは<a href="https://depfu.com/" target="_blank" rel="noopener noreferrer nofollow">depfu</a>というサービスを使って、自動でPull Requestを作成する仕組みにしています。</p><p>depfuで作成されたPull Requestについては、逐次対応するのは大変なので（後述のセキュリティアップデートは異なります）、3カ月に1回、エンジニアチーム全体で分担してdepfuが作成したPull Requestの確認と、必要に応じた修正をしています。</p><p>セキュリティアップデートについては、即対応が求められるものとなりますので、毎朝Slackに通知を飛ばします。アップデートがある場合は、デイリースクラムで担当者を割り当てて即日中にリリースするような仕組みとなっています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8f995f55d8f143b2b0aec5cd37ef86f6/image7.jpg" alt="" width="565" height="225"><figcaption>Slack上でのセキュリティアップデートの通知キャプチャ</figcaption></figure><h2 id="h447e0f8f3a"><strong>OSのミドルウェアアップデートは週次で自動実行する</strong></h2><p>次にサーバーのOSミドルウェアのアップデートについてですが、弊社ではAWS Fargateを利用し、Docker imageを使ってリリースしていますので、Docker image内でのライブラリアップデートをどのように行っているかについてご説明します。</p><p>各サーバーが利用しているDocker imageに関しては、CIにより週次でライブラリのアップデートを行っており、各エンジニアが意識することなく、日々のデプロイを行うタイミングで最新のライブラリが自動適用されるようになっています（もちろん、試験環境で動作検証を実施してからリリースを行っています）。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/009be8374642472984c853378494c3c4/image2.png" alt="" width="1067" height="674"><figcaption>週次でDocker imageを更新しているGithub Actionの図</figcaption></figure><h2 id="h27325700b4"><strong>バグやSlow Queryを自動検知する</strong></h2><p>弊社では<a href="https://www.bugsnag.com/" target="_blank" rel="noopener noreferrer nofollow">Bugsnag</a>というサービスを使って、バグが起きた際にSlackへ通知を飛ばす仕組みを作っています。バグについては、営業時間内であれば即時、営業時間外であれば次の営業開始時に確認します。そして、この仕組みに相乗りする形で、Slow QueryについてもBugsnag経由でSlackに通知が飛ぶように設定しているので、同じフローで確認ができるようになっています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b3dd7aa7c2884c3abdcd593a2d983e8d/image6.png" alt="" width="814" height="396"></figure><h2 id="h97864f4768"><strong>積極的に自動化やシステム化をする</strong></h2><p>技術的負債解消に限ったことではありませんが、弊社では、前述したように自動化できるものは積極的に自動化しています。そして、自動化できないものについてもスクリプトを組むなど、なるべく人が行わなくて済むような仕組みを構築することを重要視しています。</p><p>自動化・スクリプト化する理由としては、工数削減と、ルール化・仕組み化の抑止の2つが挙げられます。</p><h3 id="h905af46c97"><strong>工数削減</strong></h3><p>こちらは想像しやすいと思いますが、自動化することにより手作業で実施するよりも工数を削減することができます。これにより、エンジニアの対応が必要な技術的負債解消に注力することが可能となります。</p><h3 id="h2e318cd4ca"><strong>ルール化・仕組み化の抑止</strong></h3><p>定常的に何かをチェックしたり、対応したりする必要があるものについて、手作業で対応を行う場合、チェック表であったり、手順書であったりを作成することになると思います。そういった資料を用いつつ、ルールや仕組みを作って運用していくのですが、1つ2つであれば問題ないものも、数が多くなってくると把握が難しく、窮屈に感じるようになってしまいます。</p><p>そのため、弊社では可能なものについては自動化・スクリプト化し、ルールや仕組みをなるべく増やさないように心がけています。</p><p>上記2点の結果として、余分なところに貴重なエンジニアのリソースが割かれてしまうことを抑止できます。効率よく必要な箇所へ工数を注入することができるようになり、それが日々増えていく技術的負債に対する特効薬となります。</p><h2 id="h3bcda3e6b0"><strong>最後に</strong></h2><p>以上、DIGGLEにおける技術的負債解消方法を、いろいろな切り口でご紹介しました。</p><p>技術的負債はエンジニアを苦しめる問題であり、技術的負債が多ければ、それだけエンジニアの職場環境は悪いと言えます。そして逆に言えば、技術的負債の解消はエンジニアの職場環境改善の一助となります。</p><p>この記事が、読んでくださった方の職場環境改善の一助となることを願い、本記事を締めさせていただきます。</p><p></p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

予実管理クラウドサービス「DIGGLE（ディグル）」を提供するスタートアップ企業DIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。

技術的負債の解消のためには、“経営層との合意形成”が不可欠。DIGGLE社に学ぶ開発体制構築の秘訣

<p><a href="https://corp.moneyforward.com/" target="_blank" rel="noopener noreferrer nofollow">株式会社マネーフォワード</a>のCTO室副室長の松本と申します。主にデータエンジニアのチームのマネジメントを担当しています。本記事では執筆時点（2023年8月）のマネーフォワード内のデータ分析における業務やアーキテクチャについて説明します。</p><h2 id="h3e48e533b6">事業紹介</h2><p>より具体的なイメージを持っていただくために、マネーフォワードはどのような事業を行っているかについてまずは説明します。法人向け・個人向け・金融機関向けという3つの事業領域を定義しており、法人向けは事業者の経理や人事労務などの作業効率化のためのバックオフィスSaaSの提供、個人向けは家計簿・資産管理アプリなどのPFMサービス、金融機関向けでは、金融機関の顧客への業務DXサービスやコンサルティングサービスなどを提供しています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5ddcd75d6b1048c2a122b3bd7eae0536/image1.png" alt="" width="1462" height="655"><figcaption>「2023年11月期第2四半期決算説明資料」より抜粋。グラフは2023年11月期第2四半期累計売上高に占める内訳。</figcaption></figure><p>IR資料にもある通り、法人向け領域は売り上げの多くを占めており、特にデータ活用の社内ニーズも高まっている領域です。エンジニアチームも注力領域として日々改善を続けています。そのような背景から、本記事では法人向け領域でのデータ活用を中心に記載しています。</p><h2 id="hed5e2f5a5c">データ分析のワークロード</h2><p>続いてデータ分析におけるワークロードについてです。データ分析のための業務と一口に言ってもさまざまな技術要素や知識が組み合わさって構成されています。生産性や専門性の観点から3つのプロセスに大別し、それぞれに業務プロセスや開発フローを定義し運用しています。</p><h3 id="h2cd7571313">1.データ収集</h3><p>1つ目はデータ収集プロセスです。データ分析に利用されるデータはプロダクトのデータベースだけではなく、利用しているSaaS・広告関連などのツール・行動ログなど多岐にわたります。通常これらのデータは1カ所に集約されていることはないため収集する仕組みを新たに構築する必要があり、収集する際には収集元の仕様やセキュリティ強度を理解した上で設計することが求められます。マネーフォワードのデータ分析環境は利用者が差異を意識せずに分析ができるよう連携先ごとに異なる仕様を吸収するために、スクラッチの仕組みやツールなどを組み合わせて構築しています。</p><h3 id="h14d5d243b1">2.データロード</h3><p>2つ目はデータロードのプロセスです。こちらもユースケースによって同じデータソースに対してもさまざまな処理要求があります。用途によってリアルタイムに近いデータが必要である場合や、日次レポートや月次集計処理などの場合はそれぞれのタイミングに合わせる形でよいケースもあります。全てのデータを一律に処理すると仕組み上はシンプルですが、キャパシティやコストなどの問題を抱えることになるため、データロードにおいても異なった要件に対応できるよう複数の仕組みを用意しています。</p><h3 id="hb3d85062bf">3.データ利用・分析</h3><p>3つ目は実際のデータ利用・分析のユースケースになります。データ収集とデータロードの工程を経て利用可能となったデータを用いて事業KPI管理のためのダッシュボードを構築したり、マーケティング施策の改善などビジネスのためにデータを活用したりすることなどが主な用途ですが、特別定額給付金が家計消費に与える影響に関する研究論文に利用された事例もあります。</p><h2 id="hfd97687f98">アーキテクチャ構成と設計意図</h2><p>上記を実現するためのアーキテクチャについて解説します。データの連携元としては代表的なものとしてRDB・SaaS・行動ログ・広告データの4つがあり、それぞれについて説明します。</p><h3 id="hf8fcd0af10">多数のプロダクトから迅速にデータを集めるために</h3><p>まずRDBとの連携ですが、マネーフォワードでは日々新たなプロダクトが生まれており、それぞれのチームが独立して意思決定を行い構築・運用しています。一方でデータ分析はさまざまな軸で行われるためシームレスに利用可能なことが求められます。それらを実現するために複数あるRDBのデータ変更をキャプチャし、集約した後に各環境へ配布するという方式をとっています。</p><p>直接的にデータロードをすることも可能ですが、一度同じ形式に変換する方式をとることにより、新規プロダクトの仕様差分を抽象化して分析可能なデータのデリバリー速度を向上させています。現状はこの方式に落ち着いているのですが、元々はそれぞれのプロダクトごとにデータ分析のパイプラインや環境が存在しており、開発や管理も煩雑な状態でした。そのため数年かけて集約に取り組みました。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1d7c21c81d024a95aa9eee41c82ae7ab/image2.jpg" alt="" width="1920" height="1112"></figure><p>SaaSとのデータ連携においてボトルネックになりやすいのが仕様変更時の対応です。マネーフォワード内では業務効率化やビジネス成長を目的として各部署でさまざまなSaaSの導入検討や活用が進んでいます。一方でSaaSはそれぞれの仕様があり、安定して分析用途のデータを提供するためにはそれらの仕様変更に追随し続ける必要があります。</p><p>これらに対しては外部のETLツールを積極的に利用することで、社内のエンジニアがSaaSの個別仕様への追随を意識せずに済むようにしています。行動ログ・広告データもSaaSと同じく外部ソースなので、仕様変更を吸収するために外部のツールを利用しています。</p><p>一方で、ツールでは実現できない要件であるケースも多々あります。その場合は独自の実装をするケースがありますが、マネージドサービスと比較して技術面での負債化やメンテナンスコストの増大につながる懸念が大きいため、一定期間で再評価して継続すべきか否かの判断を行っています。</p><h3 id="hdc6685d508">安全管理対策としての環境分離</h3><p>またこれらのデータにはさまざまな情報が含まれています。情報の安全管理のために、各項目に情報レベルを定義・分類し、異なる環境へ格納するようにしています（言い換えると情報レベルごとに環境を分断しています）。各環境は参照できる情報が制限されていたり、エクスポートが制限されていたりとレベルに応じた安全対策がそれぞれなされています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5b2ff1df32ee41cb8a9ca0e5855fd6bd/image4.jpg" alt="" width="1920" height="1262"></figure><p>制約が多い環境は分析体験が悪化するため、分析者は分析の目的によって環境を使い分けています。そして、それぞれの環境に異なったレベルのデータが混入しないように自動で検知するための仕組みを構築し対処しています。</p><h3 id="hf6bbcaf0eb">メタデータの重要性</h3><p>これまでデータそのものの収集に関して説明しましたが、付帯情報（メタデータ）についても同様の課題を抱えています。つまり複数のプロダクトからデータを集約できても、それらのデータが何を意味するのかがわからなければデータとしての価値は低いですし、分析者が分析作業を中断して調査を行うのも合理的ではありません。</p><p>また、先に述べた通りマネーフォワードでは多くのプロダクトを運営しており、それぞれに開発チームが存在しています。つまり、多くの開発チーム・エンジニアが社内にいるということであり、問い合わせ先を確認するのもそれなりの作業量になります。これらの課題に対処するために独自で情報に対してメタデータを登録・更新できる仕組みを構築しています。分析者が一度調べた内容をこの仕組みに登録すれば、他の分析者もそれらの知見を再利用できるようになっています。</p><p>さらに、これらのデータは構成情報のみのため1カ所に集約して管理し、先に述べた各情報レベルの環境へ「配信」するという構成にしています。理由としては将来的には情報レベルのさらなる細分化や、利用技術によって環境を分離する必要が出てくることを想定しているためです（売上集計の業務環境と大規模なモデルを構築する環境では必要な機能・リソースが異なるというようなことを想定しています）。現在は分析者用途ですが将来的にはエンジニアも他プロダクトのメタデータを知りたいというニーズは出てくると考えられるので、エンジニア向けの用途としても想定しています。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>マネーフォワードにおけるデータ分析に関するワークロードとアーキテクチャを紹介しました。最後にこれからデータ分析のアーキテクチャを検討されている方にお伝えしたいことがあります。</p><p>データ分析に関連した業務や職務は細分化し続けています。以前は分析環境といえば専ら分析用データベースがあるという形でしたが、現在ではデータ量が増加し分析手法も多様化して、単一のデータベースでは実現できないユースケースがたくさん出てきています。それらの実現のために多くの機能や複数の環境が求められるように変化してきていると感じています。</p><p>一方で環境の増加はメンテナンスコストや技術的負債の増加を招きます（それらを避けるために機能拡張に消極的になるケースもあります）。これらの最適解を見つけるためには、なるべく多くのステークホルダー・関係者と適切にコミュニケーションをとり、正しい意思決定をし続けることが肝要だと考えています。本記事がみなさまのデータ分析に関する業務の一助となれば幸いです。</p><p></p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

株式会社マネーフォワードのCTO室副室長である松本さんが、同社におけるデータ分析業務の内容やそのアーキテクチャについて解説します。

「コラム」の記事一覧