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

システムリプレイスを乗り越える!成功体験に導く3つの心構え

こんにちは。エンジニアの竹田です。
BUYMAの検索システムやMLOps基盤の開発・運用を担当しております。
こちらはEnigmo Advent Calendar 2024の18日目の記事です 🎄

はじめに

2024年もいよいよ年の瀬ですね!寒さが増すこの季節、みなさまいかがお過ごしでしょうか?

早速ですが本記事の主題のシステムリプレイスについてです。
ここ言うシステムリプレイスとは、老朽化したシステムの刷新、管理目的での移設など、既存システムがあり、それを何かしらの方法で置き換えることを指しています。
例えば、古くなったオンプレミス環境をクラウドに移行したり、データベースをより新しいものに入れ替えるといった作業も含まれます。

サーバサイドから下位のレイヤを担当している方々は、システムリプレイスを行う機会が割と多いのではないでしょうか。
実際に自分もエニグモに入社してからもそうですが、それ以前からも新規システムを構築するよりはシステムリプレイスを行うことが多いと感じています。

  • 今までの実績
    • 各種検索システムのリプレイス
    • MLOpsシステムのkubeflow pipelines→vertex ai pipelinesへのリプレイス
    • アカウント検知システムのリプレイス

どんなシステムでも老朽化が進むため、定期的なリプレイスが必要です。
気が付くとサポート期限間近であったりということは少なくないのではないでしょうか。
ただ、新しいもの作りという訳ではないので、なかなかモチベーションを上げ辛い作業ではないかなと思います。

また、旧システムとインプットやアウトプットは変えない、というのが命題となるので、結果比較に時間を要したりとナーバスになる作業も多いです。

そんな中でも、モチベーションを高く保つために自分が意識していることを紹介したいと思います。

システムリプレイスのモチベーションを高めるために

改善のチャンスと捉える:システムの価値を高める!

何か付加価値を提供できないかを考えます。
システムコストや学習コストの兼ね合いもありますが、思い切って足回りやミドルウェアの置き換えなど検討しても良いと思います。

  • コスト削減
    • 新たなマネージドサービスの利用
    • 多めに見積もって構築されていたリソースの削ぎ落とし
  • システム強化
    • 少し気になっていたコードの修正
    • 構成周りの定義での一工夫
  • マイクロサービス化
    • 機能の一部を切り出して影響を局所化
  • 監視強化
    • 迅速な障害対応、柔軟な運用

学びのチャンスと捉える:自身のスキル底上げ!

少なくとも現状を一切変更しないリプレイスはあまり存在しないと思います。
例えば、旧システムのデータベースを調査中に、想定外のデータ構造や運用上の工夫を発見することもあります。それが新システム設計のヒントになることもしばしばです。
そう考えると、以下の点で新しく学びを得られる機会があります。

  • 各種ライブラリのバージョン最新化
    • 動作差異の確認、理解
  • あまり深く知らない言語の理解
    • どの言語でも固有の特徴がある
  • 旧システムの構成や思想の理解
    • wiki等が残っていれば確認、当時の思想が全く分からないこともある...
    • とにかく旧システムを把握しないことには作業を進めづらい

アウトプットのチャンスと捉える:学びを共有して価値を広げる!

どういった方法でシステムを刷新したか、その意図など、技術ブログなどで外部発信する機会を得られます。
技術ブログの他にも、社内勉強会やカンファレンスでのLT(ライトニングトーク)なども該当するかと思います。
自分もこの点はあまり実践できていないので、自戒の意味も込めて記載しています。

  • 自身の技術棚卸し
    • こういった機会を作ることで、振り返りの機会を設ける
  • 外部向け文章作成の機会
  • 企業ブランディングへの貢献

より気持ちを高めるために

関わったことのなかった方と関わりを持てる可能性がある

過去担当していた方と関わりを持ち、人間関係を広げる機会になる可能性があります。
怯むことなく関わりを持てるようにしましょう。

今どきな言い方をしてみる

slack等でやりとりする際、リプレイスではなく モダナイズ という言葉を使ってみたりしています。
ただし、クラウドの新機能を利用したり、インフラやアプリの構成を大幅に見直すような場合でないと名前負けした感じになるので注意が必要です。

最後に

以上のようなことを意識して取り組んでいるため、比較的楽しくシステムリプレイスを行っていると思っています。
システム規模が大きくなればなるほどリプレイスは大変になるので、立ち止まって特定の機能を切り出せないかを考えたりするのも良いと思います。

みなさんもシステムリプレイスを楽しむ方法を見つけて、エンジニアとしての成長を一緒に楽しんでいきましょう!

明日の記事の担当は同グループの中村さんです。お楽しみに!!


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

hrmos.co

PHPerがRubyistになろうとしてつまづいたところ③SQL

こんにちは!WEBアプリケーションエンジニアの小松です!

この記事は[Enigmo Advent Calendar 2024]の17日目の記事です。  

Railsの場合: 自動的に日付オブジェクトとして認識

RailsActiveRecordのORMを利用する場合だけでなく、rawクエリを用いた場合でもdate型はRubyDateオブジェクトに変換されます。そのため、日付フォーマットの変換を簡単に記述できます。

サンプルコード(Rails

テーブル定義

# migration
create_table :events do |t|
  t.date :event_date
  t.timestamps
end

rawクエリの利用

result = ActiveRecord::Base.connection.execute("SELECT event_date FROM events LIMIT 1")
raw_date = result.first["event_date"] # => #<Date: 2023-12-13>

puts raw_date.strftime('%Y%m%d') # => "20231213"

ポイント

  • event_dateRubyDateオブジェクトとして取得される。
  • .strftimeメソッドを直接利用してフォーマットを変更可能。

Laravelの場合: 明示的な型変換が必要

Laravelでrawクエリを使用した場合、デフォルトではdate型は文字列として取得されます。そのため、フォーマットを変更する際は、明示的にCarbonオブジェクトなどに変換する必要があります。

サンプルコード(Laravel)

テーブル定義

// migration
Schema::create('events', function (Blueprint $table) {
    $table->date('event_date');
    $table->timestamps();
});

rawクエリの利用

use Illuminate\Support\Facades\DB;
use Carbon\Carbon;

$result = DB::select("SELECT event_date FROM events LIMIT 1");
$rawDate = $result[0]->event_date; // => "2023-12-13" (文字列)

$carbonDate = Carbon::parse($rawDate);
echo $carbonDate->format('Ymd'); // => "20231213"

ポイント

  • event_dateは文字列として取得される。
  • PHPCarbonライブラリを利用して明示的に日付オブジェクトに変換する必要がある。

RailsとLaravelの比較表

特徴 Rails Laravel
rawクエリでのdate型の扱い 自動的にDateオブジェクトとして認識される 文字列として取得される
日付フォーマットの変更 .strftime('%Y%m%d')が直接利用可能 Carbon::parse($date)->format('Ymd')が必要
追加の変換処理の必要性 不要 必要
デフォルトの開発者体験 日付操作が非常に簡潔で直感的 明示的な型変換が必要で、柔軟性が高い
適用範囲 ActiveRecordでもrawクエリでも同じ Eloquentとrawクエリで挙動が異なる

開発者の観点からの結論

Railsのメリット

  • 開発効率が高い: 日付型は自動的にDateオブジェクトとして認識され、変換処理を意識する必要がありません。
  • 統一性がある: ActiveRecordでもrawクエリでも同じように扱えます。
  • 時間をかけてハマる前に、まず .to_sqlでクエリを確認 する習慣をつけると、デバッグがスムーズになります!

Laravelのメリット

  • 柔軟性が高い: Carbonを使えば、細かい日付操作やタイムゾーン操作が可能です。
  • 設計の自由度: 明示的な変換により、モデルやユースケースに応じた日付処理を柔軟に適用できます。

Railsは「標準的な処理が簡潔」、Laravelは「柔軟性を重視」といったフレームワークの哲学の違いが、日付型の扱い方にも表れています。どちらを選ぶかはプロジェクトの要件やチームの好みに依存しますが、簡潔さを求める場合はRailsが有利です。