Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sigmaで作る業務アプリ

 Sigmaで作る業務アプリ

Sigma って何?ハンズオンで理解しちゃおう! && 日本の Sigma ユーザーによるLT大会!の登壇資料です
https://sigma.connpass.com/event/404654/

## 資料概要
本資料では、Sigmaを活用した業務アプリの開発事例を紹介します。
パートナー商流の案件管理を目的に、案件情報や進捗状況を一元管理するアプリを構築。

Salesforceの改修、スプレッドシート+GAS、スクラッチ開発などの選択肢を比較し、Sigmaを採用した背景や判断基準を解説します。Snowflake上のデータへのアクセス、Salesforce情報との連携、データのライトバック、スプレッドシートに近い操作性など、Sigmaの特徴を業務アプリにどう活用したかを具体的に説明。
さらに、数万行規模のデータを扱う際の操作性や表示速度、関連情報を含むデータモデルの設計、一括入力を前提とした新規作成・編集機能の実装、将来的なSFA移行を見据えたスコープ設計など、開発時に考慮したポイントも紹介します。Sigmaをデータ分析だけでなく、既存業務の隙間を補完する業務基盤として活用する方法を学べる内容です。

Avatar for kazushiro_honma

kazushiro_honma

September 09, 2026

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 本間 和城 バクラク事業部 BizOps部 業務システムマネジメントグループ マネージャー LayerX略歴 • •

    • バクラク申請‧経費精算のプロダクトマネージャーとして⼊社 その後、事業企画 → データ → CS Ops → BizOpsなどいろいろなことをやる 今はSalesforceを中⼼とした業務システムを使った業務設計やBPR と データ関連の業務に従事 私とSigma • 2026年8⽉中旬からSigmaを触りはじめる。今回テーマにしている業務アプリは1週 間程度で実装。 (8⽉12⽇にはじめまして。8⽉25⽇に仲良くなった。) © LayerX Inc. 2
  2. 会社概要 すべての経済活動を、デジタル化する。 会社名 株式会社LayerX(レイヤーエックス) 代表取締役 代表取締役CEO 福島 良典 代表取締役CTO 松本

    勇気 創業 2018年 8⽉1⽇ 資本⾦ 282.6億円(準備⾦含む) 拠点 東京本社 〒104-0045 東京都中央区築地1-13-1 銀座松⽵スクエア 5階 関⻄⽀社 〒530-0002 ⼤阪府⼤阪市北区曽根崎新地1-13-22 御堂筋フロントタワー 内 中部⽀社 〒466-0064 愛知県名古屋市昭和区鶴舞1-2-32 STATION Ai 内 九州⽀社 〒810-0801 福岡県福岡市博多区中洲3-7-24 WeWorkゲイツ福岡 11F 内 従業員数 646名 (2026年3月末時点) © LayerX Inc. 3
  3. 事業紹介 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して⽇本の社会 課題を解決し、AIの⼒で⼈々の創造⼒がより発揮される未来をつくります。 © LayerX Inc. バクラク事業 Fintech事業 バックオフィス向け AIエージェントサービスを提供

    資産運⽤サービス 「ALTERNA(オルタナ)」を提供 Ai Workforce事業 Security事業 エンタープライズ向け AIプラットフォームを提供 AIエージェントによる ⾃律的なペネトレーションテストを提供 4
  4. 過去の類似の話 「XXの業務をよりスムーズに⾏うために業務システムとしてこういう環境を⽤意したい」 という社内ニーズは多くあった 社内からの要望  既存のお客様との接点をより多⾯的に管理したい! HTMLアプリ + Google Sheets

    スプレッドシートをデータベースとして Google Apps ScriptでHTMLのアプリケーショ ンを実装。 書き込み先:Google Sheets  お客様のオンボーディング活動の案件管理がしたい!  お客様に提⽰する⾒積を簡単に作りたい! © LayerX Inc. 実装⽅法 Chrome Extension  Snowflake  Salesforce Snowflakeに格納されたSalesforceデー タをインプットに、⼀部のデータをアプ リ側からSalesforceへwrite back 参照元:Snowflake | 書き戻し先:Salesforce Chrome Extension  Salesforce Chrome Extensionで実装。 ⼊⼒した内容をSalesforceに書き込む。 ⼊⼒先‧格納先:Salesforce 8
  5. 要件と選択肢 実現したい要件から、最適な実装⽅式を考える 現場の要望に応じて、データの持ち⽅‧参照先‧書き込み先を選択 要求 • 選択肢 Salesforce上に存在する企業情報を元に、パート ナー企業<->紹介企業のステータス管理をしたい • Salesforceとの⼆重メンテや⼆重確認がないよう

    スクラッチ (Vibe) 専⽤アプリとして実装 にしたい • 案件⼀括で登録できるようなUIが欲しい • すでに数万件のデータあり。⼤量のデータでも表 Salesforceを改修 既存の業務基盤に機能追加 ⽰速度を落としたくない スプレッドシート + GAS シートをデータベースにして構築 © LayerX Inc. 9
  6. 選択肢それぞれの所感 選択肢を⽐較して⾒えたこと 既存の選択肢には乗り越えるべき課題がある データ基盤へのwrite backに難あり スクラッチ (Vibe) バックエンド‧データベースを持つアプリケーションをセキュアな場所に置き、Not エンジニアなメンバーが運⽤改善する世界線はちょっとハードルが⾼かった。 DBを持たずにSalesforceへ直接書き込む運⽤も検討したが、断念。

    実装がかなりヘビーだが、⼀括登録などの実装が難しい Salesforceを改修 スプレッドシート + GAS © LayerX Inc. n:nの中間オブジェクトを間に作り、かつn:nの関係性に対してステータスを持つ必 要があるため今のSalesforceのオブジェクト構造を維持しながら追加実装は重かっ た。また、UI上から簡単に⼀括登録という要件も合わず。 ⼤量データでは動作‧運⽤に限界 1万⾏前後で満⾜に動かなかった。、キャッシュをのこしても書き込みをトリ ガーにリフレッシュが必要。 関連情報まで持たせると数⼗万レコード規模に。流⽯に重すぎ。 つまり、どれも要件にFitするものは実現できなそう😢 10
  7. Sigmaとの⽐較 選択肢をとSigmaを⽐較して⾒えたこと Sigmaであればどの課題も解決できそうな⾒込みが⽴つ データ基盤へのwrite backが簡単に。 スクラッチと⽐較して Salesforceを改修 と⽐較して スプレッドシート +

    GAS と⽐較して © LayerX Inc. バリデーションチェックや⼊⼒規則、データ基盤の連携など、⾯倒なこと もSigma内で完結。 データモデルを Sigma上で作成可能。 データ基盤から SQLでデータ出力できるので、 Salesforce上のデータをアプリ から確認できる。 数万行のデータでも難なく動く。 過去の商談・全取引先など、関連するさまざまな ても、ストレスなく操作できる表示速度。 Salesforce情報を呼び出し Sigmaならやりたいことが全部実現できそう 😆 12
  8. 業務アプリを作る際に気をつけたこと スコープ 作るときに気をつけたこと ①スコープの境界 既存の業務システムとどう責務を分けるとユーザー体験が向上するか Salesforce等への移⾏を⾒据えた設計 案件の紹介 スコープを絞る 商談の準備 今回のアプリ実装範囲。商

    談前プロセスに集中して構 築 将来的なSFAへの移⾏やプロセス変更の可能性を考慮し、「商談を 作る⼿前までの管理」にスコープを絞って実装 変化に強い「業務の切れ⽬」の定義 End to Endの⼀気通貫プロセスが理想だが、不確実性が⾼い状況 では「どの業務の切れ⽬をスコープにするか」を正しく⾒極めるこ とが重要 商談化 後続システムと連携 Sigmaのライトバックでサイロ化を防⽌ 後続業務が別システムに分かれても、Sigmaならデータ基盤へ直接 writebackできるため、データのサイロ化を防げる © LayerX Inc. 商談進⾏ 同じデータ基盤を参照する ため、後続システムへの データ受け渡しも容易 14
  9. 業務アプリを作る際に気をつけたこと データモデル 作るときに気をつけたこと ② 作成と編集を切り分ける 「間違って削除した」「間違って編集した」がないような安全設計 ユースケースと設計の懸念 本アプリでは「⼀括⼊⼒」の頻度が⾮常に⾼い。 インプットテーブル1つで新規作成(Create)と編集(Edit)の両⽅ を実現しようとすると、重要なIDや初期値を誤って書き換えたり、削

    除してしまう懸念がある。 安全なデータ更新モデル設計 レコード作成 データベース分割による解決アプローチ 「特定のカラムのみ変更を禁⽌する」「削除させない」という要件 を、物理的にテーブルを切り分けることで安全に解決。 • Enptyインプット: Keyや最⼩限の基本情報のみを安全に書き込み • Linkedテーブル: 定期的に変更されるステータス等を別管理 Enpty インプット(Key情報) 1:1 Linked 可変‧ステータス ステータス変更 © LayerX Inc. 15
  10. 業務アプリを作る際に気をつけたこと 開発環境 作るときに気をつけたこと ③ テストと本番を分ける Staging/Dev環境がない中で、どうテストをするか 本番環境での動作検証における課題 画⾯表⽰と開発トグルの連動 別環境を⽤意しての動作テストが難しいため、本番環境でダミーデー タを使うが、検証後のダミーデータ削除が⾯倒。

    また、本番に近いテストデータを⼊れると、どれがテストデータか判 定しづらい課題がある。 トグルによる安全な解決策 Input DataにダミーデータかどうかのBooleanをもつ。ヘッダーの 「開発」トグルを開発⽤にすることで、すべての操作をダミーデータ として扱う 共通ヘッダーのトグル: • • データが本番⽤か開発⽤かを識別する 「開発⽤」のままデータを書き込むと、⾃動的にテストデータと して書き込まれ、本番切り替え時に⾮表⽰になる © LayerX Inc. 16
  11. まとめ まとめ Sigmaはデータ分析のためだけのツールではなく、業務の切れ⽬を補完する強⼒なソリューション 1. 業務アプリを素早く構築 2. 実装において気をつけたいこと 3. 有効なユースケース データ分析やダッシュボードという

    ユースケースだけでなく、「業務アプ リ」としての利活⽤にも⼗分耐えられ るアプリケーション。 簡単に作れるからこそ、事前の整理と ⽅針定義が重要 Salesforce等の基幹システムを無理にリプ レイスするのではなく、その⼿前の業務を 補完。 現場に運⽤を引き継ぐことも現実的 で、⼿離れが良いのが嬉しい。 ‧スコープ: 業務の境界線を引く ‧データモデル: 作成と編集の分離 ‧テスト⽅法: 安全なデータ分離 システム化の⾕間に落ちていた「ちょっと した不便」や⼿作業プロセスを、Sigmaの ライトバック機能で綺麗に接続します。 まだ本運⽤前だが、困ったことはなく 順調に進みそう 🎉 © LayerX Inc. 18