エニグモのAI活用を支える「AIテクノロジーグループ」について紹介します!

はじめに

こんにちは、AIテクノロジーグループの辻埜です。普段はデータサイエンティストとして機械学習を用いたシステムの開発運用や、社内のAI活用推進を担当しています。

近年、テクノロジーの発展に伴いAIの重要性が叫ばれる中で、エニグモが運営するソーシャルショッピングサイト『BUYMA』でも積極的にAIの活用が進められています。この記事では、エニグモにおいてAIやデータをメインで扱っている「AIテクノロジーグループ」についてご紹介します。

まずはじめに「AIテクノロジーグループ」の組織における位置付けとグループ内のチーム構成を簡単にご説明した上で、メインのトピックとして各チームの業務内容や技術スタック/ツールついてご紹介していきます。

AIテクノロジーグループとは

組織図

AIテクノロジーグループは、社内のエンジニア組織であるサービスエンジニアリング本部(以下、SE本部)に属するグループの1つです。AI・データのスペシャリストが集まっており、それらの専門知識・技術をプラットフォーム・組織に提供し、事業価値・企業価値向上へ貢献する役割を担っています。元々データテクノロジーグループという名称でしたが、2025年4月1日より「AIテクノロジーグループ」へと名称を変更しました。

組織図(2025年8月1日時点)

AIテクノロジーグループが所属するSE本部はAIテクノロジーグループ、アプリケーション開発グループ、インフラグループの3つのグループに分かれており、各グループ内でも担当ごとに更に細かくチームを構成しています。 SE本部の開発体制の詳細について知りたい方は以下の記事も併せてご覧ください。

tech.enigmo.co.jp

チーム構成について

AIテクノロジーグループにはデータエンジニア、データサイエンティスト、検索・MLOpsエンジニアなどデータに関わるメンバーが所属しており、以下のような単位でチームを構成しています。

  • データ基盤チーム
  • 機械学習チーム
  • 検索チーム
  • MDDBチーム

システムの構成図と各チームの担当範囲は以下のようになっています。

システム構成と担当範囲

ここからは、それぞれのチームごとの役割と業務内容を順番にご紹介します。

各チームの紹介

データ基盤チーム

役割

データ基盤チームにはデータエンジニアが所属しています。社内の膨大なデータを整理して「データ基盤」を構築・運用し、データ分析がしやすい環境を提供する役割を担っています。

エニグモでは、データアナリストやデータサイエンティストといった分析を専門とする社員だけでなく、ほとんどの社員が自らSQLを駆使してデータを確認したり分析を行うなど、データドリブンな文化が強く根づいています。データ基盤チームはこの強力なデータ活用文化を支えています。

業務内容

データ基盤チームの主要な業務の1つは、データのETL(Extrat: 抽出、Transform: 変換、Load: 書き出し)処理の管理です。エニグモでは、それらのデータ処理のオーケストレーションにCloud Composerを活用しています。環境から収集APIを通じて送られてくる何万、何億というデータを分析しやすい形式に整形し、データベースに集約します。さらに、それらのデータがその先のデータベースやMAツール、社内分析ツールへと連携されるまでの一連の処理すべてをオーケストレーションしています。

効果的な施策を実施するためにはデータのリアルタイム性も欠かせません。データはわずか1時間で各DBからデータ基盤であるBigQueryへ同期され、リアルタイムに近い分析と意思決定を可能にしています。高速なデータ連携を維持するため、全体の健全性の監視も行っています。具体的には、Cloud Composerが適切に稼働しているか、同期に遅延は起きていないか、格納されたデータに問題はないかなどを常に確認しています。

また、データ処理のオーケストレーションだけでなく、ビジネスチームがデータを最大限に活用するための環境の整備も行っています。社内では分析ツールのひとつに「Looker」が使用されており、データ基盤チームは社内からの要望に応じてLookML(Lookerで使用される独自のモデリング言語)でデータの定義を行っています。これにより、社内の誰もが効率的で一貫性のあるデータ分析ができる環境を提供しています。さらに、Lookerの利用コストが著しく増大するのを防ぐため、LookMLの記述においてクエリの効率化やデータ集計の最適化を行うことで、リソース消費の抑制を図っています。

加えて直近の業務としてはオンプレミス環境に存在する一部のデータ処理基盤のクラウド移行プロジェクトも進められています。Terraformによるインフラ部分のコード化、既存のDAGのバージョンアップ修正、現状の構成のリファクタリング、移行に伴う動作確認など、機能面・非機能面ともに移行後に求めらる水準を達成できるよう、入念にプロジェクトを進めています。

以上のように、エニグモのデータ活用を根底から支えているのがデータ基盤チームです。

機械学習チーム

役割

機械学習チームにはデータサイエンティストが所属しています。施策の企画や実施、効果検証、機械学習モデルの開発・運用、社内のAI活用推進などを担当しています。

データ基盤チームの取り組みにより、エニグモには総ユーザー1000万人以上の行動データ、計650万点以上の出品データなど、膨大なデータが蓄積されています。それらのデータから機械学習を活用してインサイトを抽出し、アプリの機能や施策など様々な形でユーザーへ価値を届けるのがデータサイエンティストの役割です。

業務内容

BUYMAでは様々なシーンで機械学習が活用されています。たとえばログイン済みのユーザーがBUYMAを開くと、PERSONALIZED RANKINGという項目が表示されます。これは、各ユーザーの履歴をもとに、ユーザーの好みに沿った商品をレコメンドし、専用のランキングとして表示しています。

PERSONALIZED RANKING

また、データサイエンティストが自発的に提案を行い施策を実施するケースもあります。クーポン施策の実施などがその一例です。施策の企画から分析、実施、効果検証まで一貫して担当します。過去の施策を分析したり機械学習モデルを活用しながら、施策内容や配布タイミング、対象者を定め、様々な関係者と連携をとりながらプロジェクトを進めます。施策実施後には効果検証も行い、後の施策に活かすための知見を探ります。

機械学習の知見を活用し、社内で利用されているサービスの内製化に至ったケースもあります。以下のブログでは、元々社内で使用されていた他社製の類似画像検索システムにおいて、精度を維持しつつコスト削減が実現できた事例をご紹介しています。

tech.enigmo.co.jp

直近では社内のAI活用を推進するため、Difyという生成AIアプリ開発ツールを活用した取り組みも行っています。エンジニアが逐一アプリを構築するのではなく、非エンジニアでもツールを使ってどんどんAIを活用できるような環境を整えるための取り組みを行っています。

以上が機械学習チームの業務内容です。

※混同されがちですが社内の別グループにはデータアナリストのチームも存在します。役割の違いとしては、データアナリストは各事業部が実施した施策をアドホックに分析し、ビジネス上の課題を特定したり、成功要因を把握することに焦点を当てます。一方でデータサイエンティストは機械学習の知識を駆使して、将来の予測やモデルの構築を行うことがメインの役割です。役割の違いはありつつも両者は業務範囲が重なる部分も多いため、毎週合同のデータ勉強会を実施したりミーティングを通じて情報交換などをするなど、密に連携をとりながら業務を進めています。

検索チーム

役割

チーム名から検索システムのみを担当としているチームと思われがちですが、業務内容としては社内のMLOps領域も担っており、検索兼MLOpsエンジニアが所属しています。

BUYMAの検索システムの運用改善、機械学習基盤の開発運用を担うチームです。

業務内容

検索チームの業務内容としては主に3つの柱があります。

1つ目がBUYMAの検索システムの運用改善です。BUYMAでは650万点以上もの商品が出品されています。その膨大な商品の中からユーザーが求めている商品を見つけやすくするためには、高精度な検索システムが欠かせません。検索チームでは検索システムが稼働するKubernetes Engine(GKE)環境の更新や中間DBに用いられているMySQLの管理など、検索システムに関わる一連のシステムのすべての管理を担当しています。
また、直近では検索システムの運用だけではなく、よりよい検索結果を提供するための精度改善の取り組みも行われています。

BUYMAでは複数の検索システムが稼働しています。2024年7月に全検索システムのGoogle Cloud Platformへの移設が完了しており、完全にマイクロサービス化された状態となっています。
BUYMAの検索システムの構成については以下の記事も併せてご覧ください。

tech.enigmo.co.jp

2つ目の柱がMLOpsです。検索チームは元々は検索エンジニアリングの専任チームとしてスタートしましたが、徐々に検索システムから推薦システム、機械学習へと領域が広がり、今ではAIサービスの安定稼働を支えるMLOps部分も担当しています。
具体的にはデータサイエンティストが開発したモデルをデプロイするためのクラウド環境の構築などを行います。構築にあたっては求められる水準のレスポンス速度や可用性を担保するための設計、システムが危険に晒されないためのセキュリティの設計など、考慮すべき事項が数多くあります。また、機械学習システムは一度リリースされたら終わりではなく、必要に応じて何度も修正、テスト、デプロイが繰り返されます。それらの開発と運用のサイクルを円滑にするためのCI/CDの構築も行っています。

3つ目の柱がAIシステムの開発やPoCです。以前までは上記の2つの業務が主でしたが、最近はAIを使ったシステムを比較的容易にデプロイできるようなSaaS系のサービスも増えてきたため、それらを活用してAIを使ったシステムの開発やPoCを担当するようにもなっています。
代表的にはAIを用いた社内ドキュメント検索システムの構築やBUYMAのAI検索機能の改善、テキストデータの分析システムの構築などを行っています。

以上のように、インフラからアプリケーションレイヤーにわたる幅広い知識をフルに生かし、機械学習システムの大黒柱のような役割を担っています。

MDDBチーム

役割

MDDBはMerchandise Databaseの略で、BUYMAに掲載されている膨大な数の商品情報を集約・整理し、提供するための基盤を指します。MDDBチームは、このMDDBの開発と改善、そして社内でMDDBをより活用しやすくするためのAPI開発などを行っています。

業務内容

BUYMAではCtoCプラットフォームの特性上、出品されている商品が同じ商品であっても、出品者が異なればそれぞれ異なる商品IDが付与されるため、システム上では別々の商品であると認識されてしまいます。
そこで、MDDBチームでは社内に蓄積された多種多様な情報を整備し、異なる商品IDを持つ同一商品を紐づけることで、より正確で包括的な商品データベースを構築しています。

一口に「情報の整備」と言っても、乗り越えるべき課題は多岐にわたります。例えば、BUYMAの商品情報の入力方法や記載内容は出品者によってさまざまです。そのため、AIを活用して表記ゆれを吸収し、画像情報や製品情報なども活用しながら、真に同じ商品であるかを識別する仕組みを開発しています。

また、構築されたMDDBの情報をLookerと連携させることで、社内の誰もが簡単にデータにアクセスし、分析できる環境を提供しています。これにより、各部門は「BUYMA上ではどの商品が人気か?」「どんな商品が出品数が多いか?少ないか?」といった商品を軸にした分析や、その分析結果を根拠とした施策の意思決定が可能になります。

さらに、各部門にMDDBを活用した分析環境を提供するだけでなく、MDDBチーム側からもデータ分析における積極的な貢献を行っています。具体的には、MDDBのデータを使ってBUYMA上に出品されている商品の変化を分析し、出品や購入を促進するための示唆に富むデータを提供することで、各部門がより効果的な施策を検討できるよう支援しています。

このように、商品という切り口で施策の意思決定の根拠になるようなデータを収集、整備、分析して提供するのがMDDBチームのミッションです。

技術スタック・ツール

上記でご説明した業務を行うにあたって、AIテクノロジーグループでは主に以下の技術スタック、ツールが使われています。

用途 技術/サービス/ツール名
開発言語 Python, RubyRuby on Rails), PHP
コード管理 GitLab
CI/CD GitLabCI/CD
インフラ Google Cloud, Docker, Google Kubernetes Engine(GKE)
IaC Terraform
バッチ処理 Cloud Run, Vertex AI Pipelines
分散処理 Dataflow
ログ管理 Datadog, Cloud Logging
ワークフロー管理 Apache Airflow / Cloud Composer, Vertex AI Pipelines, Cloud Workflows
データ変換 dbt
データベース BigQuery, MySQL, Cloud Datastore
データ分析 Looker, Redash
検索エンジン Apache Solr
タスク管理 Jira, Redmine
コミュニケーション Slack, Zoom

技術スタックについては上記のサービス群で固定されているわけではなく、新たに有用なサービスが見つかった場合には積極的に利用しています。使用ツールについてもセキュリティに問題のない範囲で各個人で好きなツールを使っていたり、最新のAIエディタ等も申請が通れば会社の予算で利用できるなど、エンジニアがなるべく開発しやすくなるような環境を整えています。

さいごに

先にご紹介した通り、AIテクノロジーグループは昨年度までは「データテクノロジーグループ」という名称でした。しかし、社内でのAI活用が進んでいく中で、グループの担当業務としてもAI検索システムの導入などAIの案件が増えていたことに加え、グループの方針として「BUYMAおよび社内業務へのAI組み込みの提案」という方針を打ち立てており、実態にあった名称とするために2025年4月から「AIテクノロジーグループ」という名称に変更されました。

AIテクノロジーグループは、新たなグループ名となってまだスタートを切ったばかりです。BUYMAがユーザーの皆様にとって魅力的で価値のあるプラットフォームであり続けるために、そして「世界を変える、新しい流れを。」というモットーのもと、日々奮闘しています。

まだまだ課題やチャレンジしたいことがたくさんあります。以下の通り採用も行っておりますので、ご興味のある方はぜひご覧ください。ご応募お待ちしております!

hrmos.co

BUYMAのWebエンジニアインタビュー/20年続く大規模サービスで、裁量を持って開発の全工程に携わる魅力

こんにちは、UXデザイングループの宮川です。今回は、エニグモが運営するソーシャルショッピングサイト「BUYMA」で、購入者向け機能を開発するチームのエンジニア、東野さんにインタビューしました。エニグモに入社したきっかけや普段の業務内容、そしてエニグモで働く魅力について伺います。

これまでのキャリアとエニグモに入社した経緯を教えてください

元々、エンジニアとしてキャリアをスタートさせたわけではなく、建築業界で施工管理の仕事をしていました。そこからエンジニアという職業に興味を持ち、独学で勉強してエンジニアとして転職しました。

前職ではエンジニアが5名ほどの小規模な組織に所属し、Web上の店舗情報を一括管理するSaaSの開発に携わっていました。ここでは、バックエンド、フロントエンド、インフラと、開発のほぼ全ての領域を担当し、ビジネスサイドやCTOと密に連携しながら、要件定義から開発までを一貫して行っていました。

とても貴重な経験をさせていただいていたのですが、その一方で、エンジニア組織が小規模で技術への関心が高いメンバーが少なかったことから、自身の技術的な貢献が評価されにくいという課題も感じていました。

そんな中、エニグモの記事で評価制度やバリューに関する考え方を拝見し、透明性が高く、自分がやりたいことで会社に貢献し、正当に評価してもらえる環境だと感じました。また、技術ブログからは、スペシャリストとして業務に貢献されている方々の姿や、各メンバーの取り組みを知ることができ、その技術レベルの高さに強く惹かれました。技術面においても、大規模なトラフィックを前提としたデータ処理や、本番環境で求められる高い品質を考慮した設計・実装など、私が挑戦したいこととエニグモが求めるものが一致していると感じ、入社を決意しました。

※スペシャリストとして貢献するメンバーの紹介記事
※カンファレンスについての記事
※エンジニア組織やバリューに関する記事 

 

エニグモではどのようなお仕事をされていますか?

入社当初は、開発組織を横断的に支援するチームの1つであるApplication Platformチーム(以下APチーム ) に所属していました。ここでは、技術スタックの最適化、インフラ基盤のモダン化、アーキテクチャ改善、サービスの信頼性向上といった、横断的に共通の技術課題を解決し、開発組織全体の生産性を向上させる活動を行っていました。

その後、社内異動を経て、現在はBUYMAの購入者向け機能を開発する「BUY Domain」の「CVR Squad」に所属しています。

エニグモの開発体制は、BUYMAのDomain(機能)ごとに、BUY(購入者向け機能)、SELL(出品者向け機能)・SERVICE INFRA(決済や配送などのBUYMA根幹を支える機能)(※)といった3つのドメインに分かれています。そして、そのドメインをさらに細分化し、事業的なミッション達成に向けて、システム全体のライフサイクル(設計、開発、テスト、本番化、運用、不具合対応など)にオーナーシップを持つ縦割りのチームのことを「Squad(スクワッド)」と呼んでいます。

私の所属するCVR Squadは「購入者のコンバージョン率(CVR)向上」のミッションを持っており、私はBUYMAの購入フローやクーポン施策に関する開発を担当し、今後開発をリードしていく役割を担っています。

また、DXチームという開発組織を横断的に支援するチームも兼任しており、BUYMAのローカル開発環境やソフトウェア開発のプロセスを自動化するためCI/CDツールの整備を通して、エンジニアがより快適かつ効率的に開発できる環境づくりに取り組んでいます。例えば、AIツールを安全に活用できるよう、BUYMAソースコードから個人情報などの機密情報を分離し、気兼ねなくAIを使用できる開発環境の整備などを行なっています。

※エニグモのエンジニア組織について

 

印象に残っているプロジェクトについて教えてください

現在所属しているCVR Squadでの、トレンドワード機能を改善したプロジェクトが印象に残っています。BUYMAには、ホーム画面のカテゴリータブの下にある、(ブランド名)人気バッグ、(ブランド名)アウトレット商品などの「トレンドワード」タグを押下して検索結果に遷移できる機能があります。

改善前のこの機能では、全年代に一律の「トレンドワード」を表示しており、特定の層にしか響かず、特に若年層への訴求が弱いという課題がありました。そこで、ログインユーザーの年代に合わせて、表示する「トレンドワード」を最適化し、若年層への訴求を強化するために、このプロジェクトが始まりました。

私は主にバックエンド開発の役割で関わりましたが、仕様のキャッチアップも兼ねてWebアプリケーションのフロントエンド(React)も一部担当しました。また、ディレクターやアプリエンジニア(iOS / Android)を交えてビジネス要件を調整しつつ、バックエンドの設計・実装を進め、施策全体の開発計画やリリース計画の調整も行いました。

開発そのものの複雑さは高くなかったのですが、大規模サービスならではの課題が2点ありました。1点目は、複数のレイヤーにキャッシュが組み込まれていることや、アプリ用APIでバージョニングを考慮した設計が必要であるなど、サービスが大規模なため、数々の既存システムの仕様を把握する必要があったことです。 2点目は、私のBUYMAでのはじめてのビジネス系の施策で、アプリ(iOS / Android)、管理画面、Webと開発範囲が広かったため、自身の担当範囲の見極めや、開発フローを把握しながら他チームと連携する必要があったことです。

これらの課題に対し、1点目の既存システムの仕様の把握については、社内の情報共有ツール(esa)やSlackのログを確認したり、ソースコードを直接読み解いたりすることで理解を深めました。2点目の開発の連携については、プロジェクトの初期段階でタスクを洗い出して開発計画を立て、クリティカルパスを把握した上で、開発の順序や他チームへの依頼フローを整理するようにしました。 

結果、大きな手戻りなく各チームが効率的に開発を進めることができ、施策としてもトレンドワード機能を利用するユーザーの数を底上げすることに成功しました。このプロジェクトを通して、幅広い開発スコープを担当させてもらえたことで、ビジネス施策の進め方やシステム仕様への理解が深まり、大きな自信に繋がる印象的なプロジェクトになりました。

 

エニグモグループで働く魅力を教えてください

長年続くサービスだからこそ得られる技術的な知見

BUYMAは20年以上稼働しているエニグモ創業時から続くサービスで、以前は開発言語にPHPが使われていましたが、現在はRubyに技術刷新され、旧来のシステムと新しいシステムが共存する形で運用されています。

そのため、機能的には移行が完了していても、一部でPHP時代の影響が残っている箇所があり、施策内容によっては旧来のシステムへの影響調査と設計が求められます。このような長年稼働している複雑なシステムに対し、実装当時の担当者がいない中で、自ら仮説を立てて状況を整理し、アウトプットを出す必要があります。

難しい挑戦ではありますが、それを乗り越えることで、リアルなビジネス課題を解決するための実践的な知見を得ることができます。

職種の枠を超えて幅広い工程に携われる

システム開発において、ビジネス要件の調整から、既存システムの調査、開発計画の立案、設計、実装、QAまで、全工程に携われることも大きな魅力です。 

もちろん、全てを一人で対応しなければいけないわけではありません。状況に応じて他チームに依頼することや、エンジニアのアサインが難しい場合は自ら開発することもあります。あるいは、開発に専念してレビューのみを他チームに依頼したりと、柔軟な動き方が可能です。 

加えて、エニグモでは安全なリリースに必要なリソースを確保しやすい文化があるため、時間をかけて調査や実装、リリース計画を綿密に立てることができるため、エンジニアとして納得感を持ちながら開発に取り組むことができます。

多職種なメンバーと協業しながら開発できる環境

入社時に配属になったAPチームでは、難易度の高い専門的な技術を扱っており、技術力が高いエンジニアが集まっていたため、当初エンジニア3年目の自分にとってはチャレンジングな環境でした。何でも自分で解決しようとして行き詰まることもありましたが、思い切って相談してみると、皆さん快く手を差し伸べてくださり、自己解決が難しい案件もスムーズに進められるようになりました。

複数のチームを経験したことで組織体制への理解が深まり、他チームのエンジニアやビジネスサイドのメンバーと関わる中で、効率的に業務を進められるようになったと感じています。また、ビジネスサイドやディレクターの方々もエンジニアへの理解が深く、建設的なコミュニケーションが取りやすい環境です。

多様なメンバーと協業する中で、視野が広がり、自身の成長やよりよい開発・提案にもつながっていると実感しています。

 

今後チャレンジしたいことを教えてください

既存システムの技術的課題やソースコードの改善提案などを通して、サービスの安定性と開発者体験の向上にさらに貢献していきたいです。

BUYMAは既存システムの仕様を把握するのが難しく、改善提案を行う際にも、変更することによって起こる多くの影響を考慮する必要があります。しかし、今までの業務で既存システムに触れ、他のエンジニアのコードレビューと合わせて仕様の把握を進める中で、より大きな課題解決を行うための準備が整ってきたと感じており、今後は、より積極的に改善に取り組んでいこうと思っています。

例えば、BUYMAのユーザー情報や取引情報を管理する社内ツールは、多くの部署で利用される必要不可欠なツールですが、技術スタックが古く、機能開発のボトルネックになり、パフォーマンスが最適化されていません。このようなツールの新規開発を主導し、順次リプレースを進めることで、抜本的な改善に貢献していきたいと考えています。

 

エニグモに興味を持ってくださっている方に、メッセージをお願いします

20年以上続く大規模サービスを舞台に、本番環境に根ざしたリアルな課題に向き合うことができます。開発者としての視野を広げ、技術的な意思決定を自らの手で行う経験を積みたい方にとっては、非常にやりがいのある環境だと思います。担当業務は基本的に自身の役割が軸になりますが、施策の初期段階から関わることで設計や技術方針に意見を出し、必要に応じて他の領域に挑戦したりすることも可能です。

私も最初は不安がありましたが、困ったときにはすぐに助けてくれるチームメンバーや、エンジニアの挑戦を後押ししてくれる文化があるので、安心してチャレンジを続けられています。

エニグモで、一緒にエンジニアとしての幅を広げていきましょう!

 

----

株式会社エニグモ すべての求人一覧

hrmos.co

AppSheet初心者向け YouTubeおすすめ動画(見る順番付き)

こんにちは、エニグモ 嘉松です。

データ活用推進室という部署でデータ活用の推進やマーケティング・オートメーションツール(MAツール)を活用した販促支援、CRMなどを担当しています。

この記事は エニグモ Advent Calendar 2024 の 25 日目の記事です。

はじめに

この記事では、AppSheetを学び始めたばかりの私が実際に視聴して役立ったYouTube動画をご紹介します。 効率的にスキルアップできるよう、おすすめの視聴順も一緒にご紹介します。

AppSheetとは

AppSheetとは、プログラミングの知識がなくても簡単にアプリを作成できるGoogle社が提供するノーコード開発プラットフォームです。Googleスプレッドシートなどのデータと連携し、GPS機能やカメラ機能を活用したアプリも開発可能です。営業活動の効率化、在庫管理の最適化、顧客管理の強化など、様々な業務に活用することができ、業務効率化、コスト削減、意思決定のスピードアップを実現できます。現場の作業者など、IT知識がなくてもアプリ開発に挑戦したい方におすすめです。

おすすめ動画(再生リスト)2選

以下におすすめ動画の再生リストを2つ紹介します。

  • 「AppSheetを作ろうの会」
  • 「AppSheet入門シリーズ」

「AppSheetを作ろうの会」

  • チャンネル名
  • 再生リスト
  • 動画本数
    • 22本(2024年12月時点)
  • 内容
    • AppSheetの初心者向けに、アプリ作成の基本から応用までを解説しています。
    • 各動画では、具体的なアプリの作成手順や機能の使い方が丁寧に説明されています。
    • メインで解説を担当する牛乳屋の社長と社員に加えて、Google Cloud Japanの担当者も登場します。
    • 動画の再生時間が30分を超えるものもあり、また動画本数も22本と多いです。
  • おすすめポイント
    • AppSheet初心者の社長の視点で解説されているので、AppSheet初心者には同じ視点で動画を視聴することができます。
    • Google Cloud Japanの担当者の方も登場するので、AppSheetの中の人からの解説も聞ける点が他の動画と比較してユニークです。
    • 現在も動画が追加されているので、定期的にウオッチしていくと最新の動向など把握できます。
    • AppSheet開発の考え方や作ったアプリをどのような業務に活かせるのか?といったAppSheetの開発の説明に留まらない重要な内容に触れているところに価値があると感じます。
  • おすすめ視聴方法
    • 動画の本数も多く、30分を超えるような再生時間が長い動画もあるので、最初から一気に全て視聴するのはタイパという点でおすすめしません。
    • 視聴者のこれまでの経験や担当する役割、確保できる時間との兼ね合いで、動画をピックアップして視聴するのがおすすめです。
    • 視聴する優先度はこの後の「おすすめ視聴順」を参考にしてください。

「AppSheet入門シリーズ」

  • チャンネル名
  • 再生リスト
  • 動画本数
    • 10本(2024年12月時点)
  • 内容
    • AppSheet専門フリーランスエンジニアの方が解説している動画です。
    • 初心者向けにプログラミングの知識がなくても理解しやすい構成になっています。
    • 各動画がコンパクトにまとめられており、効率的に必要な知識を得ることができます。
  • おすすめポイント
    • 開発の手順について実践的に解説されているので、いち早くAppSheetでアプリ開発を進めるには最適な再生リストです。
    • 実際の操作画面を見ながら学べるため、手順が分かりやすく、初心者でもスムーズにアプリ開発に取り組めます。
    • 動画のクオリティーも高いと感じました。

おすすめ視聴順

「おすすめ視聴順」の選定ポイント

  • 最初はAppSheetの特性を理解できる動画をおすすめ!
    • 具体的には、AppSheetでどのようなことができるのか、また、AppSheetがどのような場合に適していて、どのような場合に不向きなのかを理解できる動画を最初に視聴することをおすすめします。なぜなら、どのようなケースでAppSheetを使うべきか、逆にどのようなケースではAppSheetを使わない方が良いのかを判断できることは、その後のアプリ開発において非常に重要だからです。AppSheetに向いていないことをAppSheetで行おうとすると、開発者もAppSheetも不幸になってしまうため、何事も適材適所が大切です。
  • 次に実際に手を動かしながら開発手順、開発方法を学べる動画をおすすめ!!
    • 次の段階としては、実際に動画を視聴しながら、開発を進めていく段階です。この段階では思ったとおりにいかないことも多々でてくると思います。なるべく迷わないように動画のクオリティが高く、丁寧に解説されている動画が良いと思いました。
  • AppSheetの開発の初期段階で知っておいたほうが良い小技的な知識も優先して視聴することをおすすめ!!!
    • 開発が進んだ段階だと後戻り、作り直しになってしまうような知識(たいていは小技的なことが多い)は早めに見る価値は高いので、優先して視聴することをおすすめします。

おすすめ視聴順

視聴順 動画タイトル チャンネル名 視聴時間
1 【AppSheet新シリーズ】新企画始動!第一弾:AppSheetでめっちゃ便利なアプリを大公開! cooker8 by 明治クッカー 約33分
2 【AppSheet第三弾】5分で出退勤アプリをつくる。「ド素人」のにっしー社長の作成過程を全部見せます。 cooker8 by 明治クッカー 約26分
3 AppSheetの絶対ルールをまとめてみた。【AppSheet第5弾】 cooker8 by 明治クッカー 約21分
4 AppSheet入門シリーズ(Part1〜Part6) AppSheetエンジニア岡田 約60分

おすすめ視聴順の詳細

  1. 「AppSheetを作ろうの会」

    1. 【AppSheet新シリーズ】新企画始動!第一弾:AppSheetでめっちゃ便利なアプリを大公開!(視聴時間約33分)
      • 33分と長いが、どんなアプリが作れるのか、アプリをどのように業務に活かせるのかをイメージできる。
      • アプリの作り方は説明していないが、どんなアプリを作れるか、どう業務に活かせるかをイメージできるのでオススメ。
      • 個別のアプリの説明がやや長いので、その部分は飛ばして視聴してもオッケーです。
    2. 【AppSheet第三弾】5分で出退勤アプリをつくる。「ド素人」のにっしー社長の作成過程を全部見せます。(視聴時間約26分)
      • アプリ開発の初心者(未体験)の社長が、最初のアプリを作るまでを紹介している。
      • 超シンプルなアプリの開発を通して、AppSheetの開発の流れを理解できる。
    3. AppSheetの絶対ルールをまとめてみた。【AppSheet第5弾】(視聴時間約21分)
      • スプレットシートからAppSheetを作成する前段階として押さえておいたほうが良いこと、特にAppSheeを作成した後だと容易に変更できないことなどがまとめられている。
      • AppSheetの開発の初期段階で知ってくと後戻りが少ないので、早めに見る価値は高い。
  2. 「AppSheet入門シリーズ」

    1. 「AppSheet入門シリーズ」のPart1からPart6まで通しで視聴する。(視聴時間約60分)
    2. 作りたいアプリによってはPart6の後にPart7とPart8を視聴する。(視聴時間約14分)
    3. 時間のある時にPart9、Part10を視聴する。(視聴時間約20分)

おわりに

この記事では、AppSheetの初学者の私が視聴してためになったYouTuebe動画をおすすめの視聴順と合わせて紹介させていただきました。 これからAppSheetを試してみたい、勉強したいという方の一助となれば幸いです。 他に参考になる動画があればコメントいただければ助かります。

本日の記事は以上になります。

なおエニグモ Advent Calendar 2024もこの記事で最後になります。 最後までお読みいただきありがとうございました。

株式会社エニグモ すべての求人一覧

hrmos.co

Datadog Live Tokyo 2024 Reprise に参加してきました!

こんにちは!Webアプリケーションエンジニアの 川本 です!

この記事は Enigmo Advent Calendar 2024 の 23日目の記事です。

2024年12月18日に開催された Datadog Live Tokyo 2024 Reprise へ参加してきました。

www.datadoghq.com

10月に行われた Datadog Summit Tokyo 2024 にも参加したのですが、イベント内容の充実度とそこから得た学びが多かったことから今回のイベントにも参加を決めました。

Datadog Summit Tokyo 2024 へ参加した際のレポートを 2日目のAdventCalenderに投稿しているので、気になった方はこちらも合わせてご覧ください。

tech.enigmo.co.jp

印象に残ったトピック

今回のイベントを通して以下のトピックが印象に残りました。

ボトルネック特定までの流れ

サイバーエージェント社の赤野さんの講演で紹介されていた、APIパフォーマンス改善を行なった際に APM Trace Queries を使ってボトルネック特定の流れが非常に参考になりました。

APM Trace Queriesは Span の関係に基づいて Trace の検索、集計ができる機能です。
例えば ServiceA から直接呼び出されている ServiceB または ServiceC の Span を含むトレースを検索する場合、トレースクエリ演算子を用いて以下のように表現することができます。

ServiceA => ServiceB | ServiceC 

APM Trace Queries についての詳細

docs.datadoghq.com

ボトルネック特定までの流れは以下にように紹介されておりました。

  1. APM Trace Queries を使って BFF のレイテンシに対して処理時間の割合が大きいマイクロサービスAPIを可視化
  2. APIごとに APM Trace を確認して怪しい Span がないかを探す
  3. Continuous Profiler でボトルネックになっている関数を特定

私もパフォーマンス改善の際に同じような手順で改善を試みたことがあるのですが、APM Trace Queriesについてはここまで活用できていなあったので非常に参考になりました。

また Datadog を使ったボトルネック特定の手順は属人化しないと思うので、手順としてチームに共有することもできるのでとてもいいなと思いました。

オブザーバビリティツールの統一

サービスによっては歴史的経緯やマイクロサービス化等によってオブザーバビリティツールが統一されていない状況があるかと思います。

しかし、このような状況ですとツールの管理者は事情を把握しているので臨機応変に使いわけられるかと思いますが、利用者は最初どれを使えばよいのか混乱を招く可能性があります。

他にもWantedly社の田中さんの講演ではツールを統一することには以下のようなメリットがあると紹介されており非常に参考になりました。

  • 計装ライブラリへの依存が減りパフォーマンス向上
  • 計装ライブラリ同士の競合による不具合の解消
  • サービス利用費用の圧縮

speakerdeck.com

弊社では Datadog が主に使われていますが、完全には統一されておらず他のツールと併用している状況です。私自身も入社当初どのツールを見れば良いのか迷って質問した経験があります。社内の誰でもオブザーバビリティを活用できるようにツールは統一していきたいです。

コスト管理

コスト管理に関する興味深い点として、オブザーバビリティツールが従量課金モデルかユーザー数課金モデルかで大きく違ってくるということです。

従量課金の場合はコスト管理は難しいが、コストコトロールはしやすい。 ユーザー数課金の場合はコスト管理はしやすいが、コストコトロールは難しい。

これらは組織によってツール選定の基準に大きく関わってきそうです。

従量課金のDatadog www.datadoghq.com

ユーザー数課金のNew Relic newrelic.com

エンドポイントごとの担当者(Owner)を可視化

大規模なモノリシックなサービスでエンドポイントが多数ある場合、どのエンドポイントが自分のチームが管理しているのものなのか把握するのが難しいことがあると思います。

リクルート社の小檜山さんの講演で、エンドポイントのOwner一覧をダッシュボードで見れるようにしたという事例が非常に参考になりました。

以下の資料で紹介されております↓ speakerdeck.com

弊社も大規模なRailsモノリスが存在しており、お問い合わせ対応の際にすぐにエンドポイントのOwnerがどこかわからずに混乱するといったことがあります。この事例は弊社でも適用できそうだと感じました。

おわりに

様々な会社のオブザーバビリティ、Datadogの活用事例が聞けてとても勉強になりました。

また Datadog をエンジニア組織に普及することの難しさはどの会社でも語られていましたが、まずは興味を持ってもらう機会を作りだし、ちょっと便利だから使ってみようかなと思ってもらうことが大切なのかなと思いました。

イベント最後に、Datadogのキャップやステッカーをいただきました。
運営の皆様素晴らしいイベントをありがとうございました!

明日の記事の担当は SC本部 の 平澤さんです。お楽しみに。


株式会社エニグモ すべての求人一覧 hrmos.co

ノーコード・ローコード:AppSheetがもたらす開発手法と業務スタイルの変化

こんにちは、GASエンジニア の 佐伯 です。

この記事はEnigmo Advent Calendar 2024の 21 日目の記事です。 この記事ではGoogle製のアプリ開発ツールである、AppSheet について紹介します。

軽く自己紹介になりますが、普段はGAS(Google Apps Script)やBigQueryなどを用いて業務用ツールの開発を行っています。最近はGASとの親和性も高いAppSheetに挑戦しているので、その中で気づいたことをまとめます!

概要

AppSheetの利用を検討している方向けに、AppSheetの基本的な特徴やメリットをまとめる。また、より高度に使いこなしたい場合の拡張性や、筆者が感じる向いている用途、デメリット(弱点)、Microsoft製品との比較についても記載している。

特徴とメリット

データに関する設定を重視した開発ツール

  • 大前提とされるべきAppSheetの特徴として、データ重視の開発ツールである点がある。
  • これはどういう意味かというと、例えば、ある業務に関連した複数のリレーショナルなテーブルがあるとする。これらに対して、各テーブルの主キーやデータ型を定義し、またテーブル間の参照関係を設定すると、それらのテーブルの利用の仕方は、おおよそ決まってくる(予想がつく)。
  • 「予想がつくなら、自動で作ればいいやん」というのが、Google社がAppSheetに込めた主要な思想かな、、と考えている。
  • それゆえ、それらのテーブルに対する CRUD( = Create 生成、Read 読み取り、Update 更新、Delete 削除)操作を行うUIを、ほぼ自動で作成するのが AppSheetのメイン機能となっている。
  • それ以外にも多くの便利なサブ機能があるが、これらはメイン機能に付随し、補完する形で提供される。

UIの作成が非常に早い

  • データソースの設定がなされた時点で、主要なUIは、ほぼ自動で作成される。
  • UIの表示形式も、テーブルやカード、タイル形式だけでなく、ダッシュボード、カレンダー、マップ、フォームなどなど、ある程度のバリエーションが用意されている。
  • データ型に応じた入力補助のUIなども、自動で適用される。選択肢タイプであればドロップダウンが表示されるし、日付型であればカレンダーが表示される。当然、データ型に違反するような入力はできない。
  • あとは、表示順や、並び替えといった、実際に利用するユーザー目線での利便性を向上させれば完了である。
  • ここまで読んで、メイン機能それだけ?!と言われそうであるが、AppSheetを利用することで、UIとデータソースをほぼ完全に分離することができるため、これによるメリットはやはり大きい。
  • 例えば、GASでスプレッドシートをベースにツールを組む場合、UI作成の手間を回避するためにスプレッドシートをUIとして用いることが多いが、この場合、どうしてもユーザーがデータソースを直接編集する形になりがちであり、誤操作やツールの破壊が生じるリスクは大きい。
  • また、本来であれば正規化して複数のテーブルに分離されるべきデータ構造であっても、やはりユーザーの一覧性向上の観点から、一つのシートにまとめて表示させる場合も多く、冗長でもあるし、データの保全性という点でも、よろしくない。
  • AppSheetを利用することで、UIを独立させ、データソースを理想的なリレーショナルDBの構成で、堅牢に安全性高く維持することができる。しかもUIはほぼ自動でできるのだから、活用しない手はない。
  • ちなみに自動で作成されたUIを利用せずに、手動でイチから設定していくことも可能である。

データソースの選択肢が幅広い

名称 説明
AppSheetデータベース 専用のリレーショナルデータベース。
Googleフォーム Googleフォーム入力値をテーブルに使える。
Googleドライブ フォルダーやファイルを指定し、そのコンテンツを解析して半自動でテーブルを作成する。
Microsoft OneDrive または SharePoint にあるエクセルを使える。
Airtable
Cloud Database GCP,AWS,Azureなど、クラウド上にあるデータベース。通常のSQL形式はもちろん、BigQueryも含む。
On-premises Database オンプレデータベース。DreamFactory connection を使って接続する。
  • 特にGoogleドライブは、請求書などの書面からも自動的にデータを再現するとのことであり、使ったことはないが、おもしろそうである。

サブ機能によって処理内容の自由度を上げられる

基本的なCRUD操作以上の処理フローを構築する手段として、AppSheetでは様々なサブ機能が提供されている。

サブ機能 内容
入出力補完 UI上でユーザーが様々なCRUD操作を行う際に、いろいろなバリデーションや加工、警告といった機能を付与できる。
Action ユーザーが実際にCRUD操作を行う際に、実行するであろう画面遷移や処理内容を、ボタン1クリックにまとめて、UI上に配置する機能である。
Automation テーブルに加えられたCRUD操作や、スケジュール設定をトリガーにして、定められた処理を実行する機能である。処理内容の選択肢としては、大きく次の2種がある。
①メール、通知、SMS、Chatなどの通知系
②webhookやGASを実行する外部連携系
Chat app アプリと連動させて、Google Chatにメッセージを送るような使い方ができる。普段から Google Chatを使っているならば、便利と思われる。
  • Action はアプリ内での画面遷移や、他のテーブルへ影響を伝播させるための機能で、処理内容は選択式となるため制約もあるが、比較的簡単な操作で処理フローを構築できる。
  • Automationは、ユーザー操作や時間タイマーをトリガーとする自動化処理を構築するための機能で、先ほどのActionによる内部的な処理はもちろん、web APIなどを通じた外部サービスとの連携や、GASとの連携を図ることができる。GASはGCPとも密接に連携可能であり、この点は、AppSheetの限界を大きく広げてくれる。
  • ただしweb APIについては、AppSheetから直接認証通過できるのは、APIキー方式などの単純なものに限られ、OAuth2といった主流の方式は(今のところ)直接接続はできない。ただしこの点も、GASに処理を任せてしまえば、そちらでOAuth2通過はできるので、あまり問題にはならない。
  • GASをどれだけ使いこなすかが、AppSheetの限界を決めそうであるが、GASとAppSheetを連携させる場合においても細かい注意点はあるので、こちらは別途まとめる予定。

SQLライクの専用関数を利用して、複雑な処理フローも構築できる。

  • 少し複雑な処理フローを構築する場合でも、AppSheetには専用の関数が利用されており、これらを用いることで、かなり複雑なデータ操作も作成できる。
  • これらの関数の使い心地としては、基本的にはスプレッドシート関数に似ていて、テーブルデータを操作する部分についてはSQLの記法も混じっている感覚となる。関数の数は少ないが、よく考えられており、組み合わせ次第で多彩な使い方が可能。

モバイルからの利用をメインで想定しているようだが、パソコンでも問題なく使えるし、便利。

  • AppSheetのエディター画面では、モバイル形式のプレビュー画面がデフォルトで表示されるが、パソコンのブラウザでのプレビューも表示できるし、実際、問題なく利用できる。
  • ただ、基本的にモバイルを想定しているため、パソコン(ブラウザ)で利用すると、画面がちょっとシンプルすぎる印象ではある。ただこの点も、デスクトップモードの改善が進んでおり、かなり利便性を向上させやすい状態になっている。

実質無料

  • 驚くべきことに、無料のGmailユーザーであっても、AppSheetは利用できる。いくつか機能に制限があり、アプリを共有できるのも最大10名までではあるが、それで事足りる場合も多い。
  • ましてや workspaceを利用している組織であれば、使わない手はない。プラン関係なく、Business系プランには AppSheetの Coreプランが付属している。
  • AppSheet有料プランの料金体系は極めて複雑であり、合理的なのだろうとは思うが、ユーザーの理解を拒絶しているといっても差し支えないレベルである。
  • 詳細を無視してざっくり言ってしまうと、「(有料レベルの機能を利用している、または10個以上のGoogleアカウントで利用しているアプリの場合、)そのユーザー数分の AppSheet有料プラン契約が必要」というイメージである。
  • workspaceを利用している組織であれば、そのユーザー数分の AppSheet有料プランは含まれているわけだから、例えば30人の組織であれば、あるアプリを最大30ユーザーで利用できる。しかも、これは組織内のアカウントに限られず、組織外の無料Gmailユーザーを含んでいてもよい。そのアプリの合計ユーザー数が30を超えなければよい、のである。
  • さらに無料、有料を問わずアプリ数の制限はなく、また全アプリの合計ユーザー数分の有料プランが必要なわけでもない。あくまで個々のアプリでユーザー数が判定されるのみで、先ほどの例で行くと、組織内でアプリA、アプリB、アプリC の 3つのアプリを運営しているとしても、それぞれのアプリで30ユーザーまで設定できる。

抜群の拡張性

ここまで AppSheetの主要な特徴に絞って記載してきたが、それ以外にも注目に値する特徴は多い。

  • バーコード、QRコードの読み取りが可能
    商品や資材といった物理的なアイテムを取り扱う業態の場合、これは非常に強力なメリットとなる。コードを読み取ってアプリに値を直接入力したり、コードを読み取ってそのアイテムに該当するデータを瞬時に検索したりすることができる。
  • データだけでなく、画像を始めとした各種ファイルの取り扱いが可能
    画像やファイルを、データに紐付けて保管できる。アプリ内で端末からアップロードすると、Googleドライブ内に作られた専用フォルダに自動で保管される。
  • CSVを介したデータ操作が可能
    他ツールとの連携や一括更新の際に便利。現状のテーブルをそのままCSVで出力し、修正の上で、アップロードして反映させることも可能
  • アプリごとにAPIを利用できる
    これもエンジニアにとっては嬉しいところ。他のシステムやツールから、API を介して直接データ操作することができる。
  • GAS(GCP)連携
    先にも述べた通りで、スタンドアロン型のGASと連携できる。GASはGCPや外部システムとの連携が可能であり、これはつまり、ほぼ何でもありであることを意味する。

デメリット

AppSheetにはデメリット、または使いにくそうな面ももちろんある。以下は、これまでの使用経験の中で感じた主要なデメリットであり、今後の改善に期待している。

  • UI作成の自由度は低い。特に要素配置やメッセージ表示の観点で不自由を感じることが多い。
  • 環境移行の手間が比較的多い。アプリAからBへ丸っと移行はできるが、その際にGitのような移行前後の差分確認ができない。来歴管理については、開発画面で編集保存するたびにバージョンが自動更新されるようになっており、過去のバージョンにロールバックさせる機能が備わっている。
  • スプレッドシートのように他ユーザーの利用状況を確認できない。
  • スプレッドシートのようにアプリ画面で関数や条件付き書式の設定ができない。(開発エディターからは可能)
  • 他ユーザーによる操作の反映がリアルタイムに行われない場合がある。その際は画面再読み込みが必要。

向いている用途

SQL形式のデータ構造に基づく、業務用アプリケーションの作成に向いている。

NoSQLや複雑なデータ構造が必要なアプリケーションや、顧客向けアプリのようなオシャレで複雑なUIデザインが必要な用途には、向いていない。

また業務アプリケーションであっても、複数人で同時にテーブルの同一行を編集するような用途では、衝突により更新が拒否される場面が多くなる可能性があり、工夫が必要である。

今後期待している点

一番は、UIの柔軟性の向上である。表示のデザインや操作性には特に文句はないのだが、項目やボタンの配置の自由度がもっと上がれば、非常に使いやすい画面になると思っている。

またユーザーからの指摘で「なるほど」と思ったのは、スプレッドシートのように「誰がどこで作業しているかを表示してほしい」という意見であった。業務に関する操作を行うのが目的である以上、他メンバーの状況が一目瞭然にわかるということは、進捗の把握や連携の向上といった点で、得られるものは大きいと思う。

Microsoft製サービスとの比較

仕事と言えばエクセル(?)、エクセルといえば Microsoftということで、長く独壇場を維持していた Microsoftも負けてはいない。グループウェアのビッグ2といえば、Google Workspace と Microsoft 365 であり、Microsoft 365 には AppSheet と類似する Power Apps が含まれている。

Power Apps もノーコード・ローコードツールであり、SharePoint に作成したテーブルなどをベースに、Poser Automate の処理フローと連携して作成する業務アプリケーション作成ツールである。

Google AppSheet と比較した際の一番の特徴は、UI制作の自由度の高さである。項目の配置はもちろん、その大きさや配置など、極めて柔軟であり、自由である。VBAのユーザーフォーム(UI)作成の操作感とよく似ていると思う。

ただ自由度が高いということは、それだけ手間がかかるということであり、実際、同じような画面を作る工数は、AppSheet と比べると Power Apps のほうが大きくなると感じている。

Google AppSheetのようにスッパリ割り切るのがよいか、それとも、Microsoft Power Appsで納得いくまでこだわれる方がよいか、、このあたりはまさに悩みどころかもしれない。

終わりに

近年のノーコード・ローコードツールの発達は目覚ましく、AppSheetがその代表例の一つであることは間違いない。いろいろとツールを調べたり使ってみたりする中で思うようになったのは「拡張性の高いノーコード・ローコードツールを、エンジニアが使うことが重要」という点だ。

プログラミングスキルに乏しい状態でノーコード・ローコードツールを使っても、さほど便利なアプリは作れない。あくまで標準的に準備されている環境の中だけで構築することになるからである。

しかし、エンジニアが拡張性に優れたノーコード・ローコードツールを使うことで、

  • (生産性の低くなりがちな)UIや簡単な処理フローの構築をツールに頼って高速化しつつ、
  • ツール内では対応しきれないような複雑な処理フローについては、連動可能なプログラミング環境内で実装することで、その業務特有の複雑なプロセスにも対応できる。

という、両者のいいとこどりが可能となる。

また、操作性がよいゆえに、ノーコード・ローコードツールの開発者は、かつてのVBAのように今後ジリジリと増えていくと思われる。こういったツールでは開発手法がより規格化されやすいので、同じ機能を実装した場合の開発者による差も生じにくい。

それゆえ、できるだけこういったツールを用いることで、開発/保守業務の属人化を極小化し、ひいては業務の継続性・安定性を高めることになると考えている。

明日の記事の担当は RDチーム の 廣島 さんです。お楽しみに。


株式会社エニグモ すべての求人一覧 hrmos.co

BigQuery上のデータへのアクセス制御

こんにちは、データエンジニアの中村です。

新卒で入社してから、気づけば2年が経とうとしています。時間の流れは本当に早いものですね。

今回は、私がこれまで取り組んできたデータ基盤におけるアクセス制御に関する技術と取り組みについてお話ししようと思います。

昨日に引き続きデータ基盤関連の記事になりますが、ぜひ最後までご覧ください!

この記事はEnigmo Advent Calendar 202420日目の記事です。

目次

背景

弊社のデータ基盤はBigQueryを利用しており、社内の個人ユーザーやサービスアカウント経由での各種サービスからアクセスがあります。

データの種類によってはユーザー・グループ毎にカラムレベルでアクセスを制御したいケースが発生することがありました。

以前は、通常のviewと特定のグループに見せたくないカラムをexceptしたviewの二つを作成し管理していました。

図1: アクセス制御方法(旧)

シンプルな構成で直感的に理解しやすいのでこのままでも良さそうでしたが、特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要があるので、要望が多いと対応が大変になってしまいます。

その課題を解決するために、BigQueryのポリシータグという機能を利用してアクセス制御を行おうと考えました。

ポリシータグとは

ポリシータグは、BigQuery上のテーブルで、列レベルでのアクセス制御を可能にするタグ機能のことです。

以下はBigQuery上で実際にポリシータグを設定した時の画像です。アクセス制御したいカラムに対して、作成したポリシータグを紐づけることでカラム単位でのアクセス制御が可能となります。

図2: ポリシータグ

ポリシータグの利用イメージ

イメージを以下に示しました。

図3: ポリシータグによるアクセス制御方法

ざっくり言うと

ポリシータグを作成ポリシータグに対して権限周りの設定をゴニョゴニョアクセス制御したい列に対してポリシータグを設定アクセス制御したい列の見え方がユーザーによって変わる

といった具合です。

ここで重要なのが、「同じテーブルを見ているのにユーザーによって見え方が変わる」ということです。

これまでは閲覧権限のないカラムをexceptしたviewを作って権限管理していましたが、ポリシータグによって1つのテーブルでそれぞれの閲覧権限に応じて閲覧可能なカラムのみ見せられるようになりました。

図4: アクセス制御方法(新)

現時点ではまだ移行途中ですが、最終的には図1から図4へ完全移行を考えております。

それでは、どのようにして見え方を変えているのかを説明していこうと思います。

ポリシータグによるアクセス制御の仕組み

ポリシータグの挙動を理解する上で重要なのが以下のロールです。

1. roles/datacatalog.categoryFineGrainedReader (きめ細かい読み取り)
2. roles/bigquerydatapolicy.maskedReader (マスクされたデータの読み取り)

名前からある程度想像がつきますね。

1は「ポリシータグが付与されていても、データをそのまま見れる」ロールで、2は「ポリシータグが付与されている場合、データをマスクされた状態で閲覧できる」ロールです。

この二つのロールを利用してアクセス制御を行います。

ポリシータグを作成図3①して、ポリシータグをテーブルへ設定図3⑤するだけだと、どちらのグループも権限エラーでクエリすらできません。

まずは閲覧可能グループの場合ですが、1のロールを付与したIAMポリシーをポリシータグへbinding図3②します。そうすると、閲覧可能グループがクエリしてもポリシータグが付与されているカラムはそのままの状態で閲覧できる状態になります。

次に、閲覧不可グループの場合ですが、2のロールを付与したIAMポリシーをポリシータグへではなくデータポリシーにbinding図3④します。

データポリシーというのはポリシータグに紐づいているデータのマスキングルールを決定するリソースであり、それに対してポリシーbindingを行います。マスキングルールは複数あるので、ケースに応じて適切なルールを選ぶと良いでしょう。

ここまで行うと、閲覧不可グループがポリシータグを設定した列を含むクエリを実行した場合、ポリシータグを設定した列がマスキングルールに従った状態で返ってくる状態になります。


まとめると以下のような挙動になります。

図5: ポリシータグの挙動

③の状態になってしまうと、そもそもクエリが実行できなくなってしまうので、そうならないように全てのグループ・ユーザーが①or②の状態になることが理想です。

使ってみた感想

約1年半利用しましたが、正直なところ当初の課題であった「特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要がある」というケースがあまり発生しなくなったので、利用前後でそこまで恩恵を感じておりません。

ですが、アクセス制御方法を移行することによって将来的に以下のメリットがあると思いました。

  • 組織が拡大してさらに細かいアクセス制御が必要になった場合、ポリシータグの方が対応が容易
  • セキュリティポリシーの一元管理が可能になり、管理コストが削減される

デメリットももちろんあり、以下のような状況に陥りました。

  • テーブルへのポリシータグ付与をAirflowで行なっており、そこで利用しているAPIタイムアウトになり連携処理が失敗・遅延してしまい後続処理へ影響が出てしまった。
  • 新規で作成したSAが図5③の状況になり、各所からこれまで以上に権限付与依頼が届くようになった。

APIタイムアウトの件は、暫定でリトライ回数を増やして対応しました。

権限付与依頼の増加は、デメリットというよりメリット寄りかもしれません。というのも新規ユーザーがデータ基盤にアクセスする場合はどのような権限を持つべきかを考えるべきだと考えているので、その状態が作れていることはプラスであると思います。 (あまりに多くなってきたらもっと良いやり方がないか考えます。。)

まとめ

現段階では総じてポリシータグによるアクセス制御への移行は個人的に微差でプラス寄りな気がします。

最終的に移行してよかったと思えるように日々運用方法は改善していこうと思います。

最後に

最後までご覧いただきありがとうございました!

明日は佐伯さんよりAppSheetに関する記事をお届けします。お楽しみに!


株式会社エニグモ すべての求人一覧

hrmos.co

Lookerで大幅にコスト削減できた話

こんにちは、データエンジニアの中村です。

弊社ではBIツールとしてGoogle Cloudから提供されているLookerを利用しています。

Lookerの利用者も徐々に増えており、日々データ活用が進んでいることは嬉しいですが、それと比例して気になるのはダッシュボードの表示速度やクエリコスト等のパフォーマンスです。

最近AggregateAwarenessという機能を利用してパフォーマンスを改善することができたので、その機能を利用するに至った背景と、その改善効果を紹介したいと思います。

AggregateAwarenessの詳細な使い方は説明しないので、その点はご了承ください。

この記事はEnigmo Advent Calendar 2024 の19日目の記事です。

目次

背景

弊社のデータ基盤はBigQueryを採用しており、LookerからBigQueryへのクエリでどのくらいのコストが発生しているかをモニタリングしています。

今年の8月ごろからクエリコストが増加していることが判明し、原因調査から始めました。

Lookerのコスト推移

原因はアクセス量の多いダッシュボードにスキャン量の大きいLookを追加したことによるものでした。

対策としては、Lookに対応した軽量のデータマートを用意してあげることでコストを抑えるといった方法があると思いますが、パネル毎にデータマートを用意するのは大変ですし、メンテナンスコストも高くなります。

かといって、DWH層を一から整備していくのは時間がかかりそうです。

そこで、両者のメリットを兼ね備えた方法としてAggregateAwarenessという機能に辿り着きました。

AggregateAwarenessとは

AggregateAwarenessとは、データマートに相当する、事前に集計されたテーブルを自動で作成し、クエリの際にそのテーブルを自動で認識してくれる機能です。

ざっくりとした手順を以下に記載しますが、本題ではないので詳細は割愛します。利用方法はクラスメソッドさんのこちらの記事が参考になりました。

①AggregateAwarenessを適用したいLookが参照しているExplore画面を表示
↓
②Explore画面より、AggregateAwareness用に自動生成されたLookMLをコピー
↓
③コピーしたLookMLを、対象のexploreが定義されているmodelファイルのexploreブロックへコピペ
↓
④Exploreからクエリを実行すると、BigQueryにLookMLで指定した条件で集計されたテーブルが作成される
↓
⑤次回以降は④で作成された集計テーブルへクエリしに行ってくれるので、クエリパフォーマンスが向上する

この方法だと、テーブルの作成をLooker側で行なってくれるので、工数をかけずにマートの作成が行えてよかったです。

また、パネルが不要になったら、コピペしたLookMLと自動で作成されたテーブルを削除すればクリーニングが済むので、後片付けが楽そうだと感じました。

紹介はここまでにして、AggregateAwarenessを利用した結果の方を説明していこうと思います。

利用した結果

AggregateAwareness適用後のコスト推移

グラフを見ると一目瞭然ですが、適用前後で大幅にコストを削減することができています。

修正した日付が11月14日なので、11/10の週から減少傾向になり、11/17の週から一気に削減効果が現れていますね。

クエリ一回あたりのコストも連動して減少しているので、クエリ回数が減ったことによる効果ではなさそうです。

コスト 期間①※1 期間②※2 減少率
クエリ全体のコスト(円) (省略) (省略) 71.8%
クエリ1回あたりのコスト(円/クエリ) 13.75 3.53 74.3%

※1期間①: 10/14~11/13(修正日前日から直近1ヶ月)
※2期間②: 11/14~12/15(修正日当日から1ヶ月後まで)

具体的な数値だと、適用前後1ヶ月で全体のクエリコストを約71%、クエリ一回あたりのコストを約74%削減できました!

また、今回の対応を行うきっかけとなったパネル以外にもAggregateAwarenessを適用したことで、コスト増加前の期間よりも改善されていました。

コスト 期間③※3 期間②※2 減少率
クエリ全体のコスト(円) (省略) (省略) 34.0%
クエリ1回あたりのコスト(円/クエリ) 7.17 3.53 50.8%

※3期間③: 7/1~7/31(コスト増加前)

平常時と比較しても約50%のコスト削減効果を得られたので、年間を通してかなり効きそうですね。


なお、クエリパフォーマンスも改善されており、平常時の平均実行時間はは4秒程度だったものが、適用後は3秒程度まで減少していました。

クエリの平均実行時間の推移

コスト削減と同時にユーザビリティを向上させることもできました!

メリデメ

AggregateAwarenessを使用してみて、以下のメリットがあると感じました。

メリット

  • 簡単にデータマートを作成でき、削除する際もクリーニングが簡単
  • クエリのパフォーマンスが課題になっている場合、改善効果が大きい

ただし、上記のメリットはあくまで短期的な視点で見た時のものであり、中・長期的な視点で考えると以下のようなデメリットもあると感じました。

デメリット

  • パフォーマンスが低下するたびに対応が必要で、イタチごっごになってしまう。(スケーラビリティの低下)
  • AggregateAwarenessの利用が膨大になると、メンテナンスコストが増加しそう。(このLookMLってどのLookに対応してるんだっけ?とかが起こる)

これらのメリデメを加味してバランスよく利用していけばかなり有用な機能だと思いました。

メリットが大きすぎるので、個人的にはどんどん利用していきたいです。

まとめ

  • AggregateAwarenessを利用することで、Lookerのコストを約70%削減することができました。

  • 平均クエリ実行時間も減少し、ユーザビリティの向上も同時に行えました。

  • 「まだ利用していない&パフォーマンスを改善したい」場合は利用をお勧め!

最後に

最後までご覧いただきありがとうございました!

明日の記事の担当は、本日と同じくデータエンジニアの中村です。お楽しみに!


株式会社エニグモ すべての求人一覧

hrmos.co