Safie Engineers' Blog!

Safieのエンジニアが書くブログです

プロダクトマネージャー孤独問題に向き合ってみた

この記事はSafie Engineers' Blog! Advent Calendar 20日目の記事です

自己紹介と本日のテーマ

はじめまして、セーフィー株式会社でSafieの映像サービスを支えるSaaSプラットフォーム プロダクト群のPdMをマネジメントしているマネージャーの光田です。

本日はPdM組織のマネジメントについて、発生した課題と解決のために取り組んでみた施策についてお話しさせていただきます。

  • 自己紹介と本日のテーマ
  • 前提
  • 発生した問題
  • どうやって解決したか
  • まとめ
続きを読む

QCDグループで使っている自動テストツール(MagicPod編)

この記事はSafie Engineers' Blog! Advent Calendar 19日目の記事です

こんにちは。2023年3月にセーフィーにジョインした入社一年目のQCDグループの森重です。

入社してからはカメラの対応機種拡大やマイページ、モバイルアプリと様々な領域・プロダクトにQAとして携わっていて、テスト設計や手動テストの実行だけでなく自動テストにも取り組んでいます。

この記事ではQCDグループで取り組んでいる自動化、特にMagicPodに焦点を当てて、QCDグループがMagicPodでどんなテストを自動化しているかをお話できればと思います。

MagicPodについて

そもそもMagicPodとはなんぞや?という方もいると思うので、簡単にツールについて説明します。

MagicPodは有償のテスト自動化ツールでWeb・モバイルに対応したE2Eテスト自動化ツールとなっています。

他の自動テストツールと比べて優れていると思うのは、自動テストの実行回数に制限がない点、メンテナンス性を確保し易い点です。

実行回数に制限がないので、毎日自動テストを実行したいプロダクトに向いているツールと言えます。

自動テストの目的

次にQCDグループで自動化に取り組んでいる目的ですが、これはテスト実行回数増加と広範囲化でバグの早期検出とバグ検出件数増加のためです。

MagicPodに決まったテストを毎日実行させることでエラーを早期検出し、今までリスクベースで切り捨てていたテストもやってもらうことで、カバーできる範囲を増やすようにしています。

自動テストのスコープ

対象のテストは、ずばりリグレッションテストになります。

テスト対象の変更が少なくメンテナンス性の確保が比較的容易なことが大きな理由です。逆にE2Eテストで自動化しないほうが良いのは頻繁に変更が入る新規機能だったり、変更が入りやすい画面を対象としているテストケースです。

実際の画面をお見せするとこんな感じです。失敗しているテストケースもありますが、定期実行して毎日結果をモニタリングしています。

メンテナンスはチームで毎日持ち回りで担当していて、日々やっているという感じです。

新機能:ヘルススコア

少し話はそれてしまいますが、先日のMagicPodのメジャーバージョンアップで追加されたアナリティクスで自動テストのヘルススコアを算出してくれます。参考までにマイページのヘルススコアを紹介しておきます。

マイページ

マイページではヘルススコア89です。このプロジェクトはQCDグループの中では後発で自動化を勧めており、パイロットプロジェクトでの運用経験からメンテナンス性を重視したテストケース作成をしています。

特にMagicPodの機能の中でも共有ステップ・変数は様々なテストケースの中の手順を一つの共有ステップで集約することで、テストケースのメンテナンス性・可読性が狙えるため積極的に活用しています。

メリット/課題

一通りテスト対象や運用については書き終わりましたのでMagicPodを自動テストに取り入れたことで感じているメリットと使い続ける上での課題についてもここに書いておきます。

MagicPodを導入したことで感じたメリット

  • 早期バグ検出に役立つ

  • テスト環境を広げたことによるバグ検出ができた

メリットですが、こちらはMagicPodを導入した当初の狙い通り、バグ検出関連の恩恵が大きいです。

MagicPodを使い続ける上での課題

  • テストケースの作成
    テストケースの属人化
  • テストケースの管理・メンテナンス
    共有テストケースの活用不足、メンテ工数増
    自動テストの実行結果をTesrailに自動でインプットできていない
  • テスト分析
    データ分析用の基盤の立ち上げができていないのでスピード感を持った分析が困難
  • 教育
    教育資料がなく、ジョインされた方も自己流で学ぶ必要がある

一方課題ですが、MagicPod利用上のルールやそのデータを活用できていないことが多く挙げられています。今後の改善活動として取り組んでいく予定です。

最後に

以上、QCDグループで使っているMagicPodについて紹介させていただきました。

当初狙っていた効果は一定得られているものの、まだまだ課題が残っていますので、継続して改善が必要そうです。

MagicPodにとどまらずテスト自動化について今後もテックブログで発信していきますので、よろしくお願いします。

Gradio: Pythonで簡単にAIをWebアプリ化

この記事はSafie Engineers' Blog! Advent Calendar16日目の記事です。

はじめに

セーフィー株式会社 開発本部 第3開発部 AIVisionグループで画像認識AIの開発エンジニアをしている土井 慎也です。

セーフィーには2023年1月に入社し、もうすぐ1年が経とうとしています。

今年を思い返せば、生成系AIを中心とした、AI界隈の発展がすごい1年でした。

毎日のようにいろんな技術が発表されて、使えそうなものはすぐにOSSに実装されていて、技術進歩の速度がものすごく速く感じました。

さて、今回はそんなAI界隈で使われているWEB UIツールのGradioについて軽く紹介したいと思います。

Gradioとは

Gradioは、機械学習モデルを簡単にデモするためのPythonライブラリです。Gradioを使用すると、モデルの入力と出力に対応するインターフェースを簡単に作成でき、モデルを試すためのWeb UIを生成できます。これにより、モデルの挙動を迅速に確認したり、他の人と共有したりすることが可能になります。

stable diffusionで有名なWEB UIの一つである、stable-diffusion-webuiもGradioを使用しています。

AI用のGithubともいえるHuggingFaceとの親和性も高く、HuggingFaceで公開されているものを簡単に試すことができたり、逆に公開することもできます。

また、機械学習モデルに関係なくても、Gradioには色々なインターフェイスが用意されているので、簡易的なWeb UIが簡単に実装できます。

Gradioは日々アップデートで変化しているため、今回はあまり深くは解説せず、基本的な紹介といたします。

Hello World!

python3.8以上が実行可能な環境を用意します。

Gradioのインストール

pip install gradio

コード実装

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="text", outputs="text")

demo.launch()
  • fn: 実行する関数
  • inputs: 入力のコンポーネントの種類(list型で複数指定可能)
  • outputs: 出力のコンポーネントの種類(list型で複数指定可能)
  • demo.launch(): 実行

こんな感じに、少ないコードで、簡単にWeb UIを作成することができます。 HTMLやCSS、jsなどを意識する必要はありません!

実行結果

https://gradio-hello-world.hf.space

認証機能

Gradioには認証機能があります。

demo.launch(auth=auth_function)とすることで、認証機能を有効にすることができます。

認証機能のベースはFastAPIのOAuth2PasswordRequestFormを使用しているようです。

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

# 認証機能
def auth(user_name, password):
    # 例: ユーザー名とパスワード(反転)が一致したら認証OK
    # 実際にはDBと連携して認証するなどの処理が必要
    if user_name == password[::-1] :
        return True
    else:
        return False

demo = gr.Interface(fn=greet, inputs="text", outputs="text")

# 認証機能を有効にする
demo.launch(auth=auth)

ログイン画面イメージ

リアクティブインターフェース

gr.Interfaceでlive = Trueを指定すると、入力値を変更するたびに、リアルタイムで出力が更新されます。

import gradio as gr

def calculator(num1, operation, num2):
    if operation == "add":
        return num1 + num2
    elif operation == "subtract":
        return num1 - num2
    elif operation == "multiply":
        return num1 * num2
    elif operation == "divide":
        return num1 / num2

demo = gr.Interface(
    calculator,
    [
        "number",
        gr.Radio(["add", "subtract", "multiply", "divide"]),
        "number"
    ],
    "number",
    live=True,
)
demo.launch()

https://gradio-calculator-live.hf.space

ブロック構造とイベントリスナー

Blocksを使用すると、より細かくレイアウトを指定することができます。

また、イベントリスナーを使用することで、ボタンをクリックしたときの処理を指定することができます。

Hello World!をBlocksを使用して書き換えると、以下のようになります。

import gradio as gr


def greet(name):
    return "Hello " + name + "!"

# Block
with gr.Blocks() as demo:
    name = gr.Textbox(label="Name")
    output = gr.Textbox(label="Output Box")
    greet_btn = gr.Button("Greet")
    # イベントリスナー
    greet_btn.click(fn=greet, inputs=name, outputs=output, api_name="greet")

demo.launch()

https://gradio-hello-blocks.hf.space

詳しいBlocksとイベントリスナーについて

www.gradio.app

詳しいレイアウトの方法について

www.gradio.app

コンポーネントの種類

コンポーネントで用意されているもので一般的なものだと、text, number, checkbox, radio, dropdown, file, button, slider, などがあり、そのほかには、画像や音声、動画、グラフ、チャットなどの様々なンポーネントが用意してあります。

コンポーネントの種類

gradio.app

また、Gradioのメジャーアップデートでカスタムコンポーネントも最近追加されたので、今後ユーザーによって多くのカスタムコンポーネントが実装されていき、より種類が豊富になっていくと思います。

カスタムコンポーネントの作成方法

www.gradio.app

実装例

最近発表され、話題になっている動画生成AI、MagicAnimateのWebUIになります。

ソースコード

huggingface.co

画面

zcxu-eric-magicanimate.hf.space

その他ドキュメント

www.gradio.app

www.gradio.app

まとめ

Gradioが用意しているコンポーネントで事足りる場合、それらを組み合わせることで、AIに関わらずPythonで作られたソフトウェアは簡単にWeb UIを作成することができます。

フロントエンドの知識がなくても、簡単かつ迅速にWeb UIを作成することができるので、Pythonで開発したものをすぐにWebアプリ化したいAIエンジニアなどにとっては、非常に便利なツールだと思います。

セーフィーでも、Gradioを使用して社内向けに気軽にAIを試せるデモ環境を迅速に用意し、PoCやその他検証などに活用できないかを現在検証しています。

Safieのサービスを国際化対応した話(モバイルアプリ編)

この記事は Safie Advent Calendar 15日目の記事です。

はじめに

こんにちは。開発本部モバイルグループの池田です。

私は普段、モバイルグループのマネジメントおよび Safie Viewer for Mobile の PdM としてお仕事をしていますが、今年はそれに加えて国際化対応の開発PMとしても活動してきました。

今年の初めに海外展開のための組織が立ち上がり、そこの社内募集に手を上げて、兼務でお手伝いすることとなったためです。セーフィーではこのように、社内でも新しい試みにチャレンジしやすい制度が整っています。

実は、2023年中にセーフィーはグローバル進出のためのビジネス立ち上げ準備と開発を進めており、Safie Viewer モバイルアプリは英語・ベトナム語・タイ語への対応をリリースしています。また時差対応もほぼ完了し、以前はいくつか問題のあった日本以外のタイムゾーンでも、正しく快適に使えるようにアップデートされています。

エキゾチックSafie!!

今回は、主にモバイルアプリの開発に着目して、セーフィーのグローバル対応について書いてみたいと思います。(Web フロントエンドやサーバー、デバイスについても近々きっと書いてくれる人がいると思います!)

  • はじめに
  • 国際化(Internationalization)と地域化(Localization)
  • 言語について
  • 翻訳について
  • 翻訳について・2
  • 翻訳課題:ベトナム語意外と横長問題
  • 翻訳課題:テキストデザインとFigmaのローカライズ
  • 時間について
  • おわりに
続きを読む

テスト管理ツールはじめました

この記事はSafie Engineers' Blog! Advent Calendar 14日目の記事です。

こんにちは、あるいはこんばんは
第1開発部QCDグループ 小山と申します。

ブログ書きますよからもう1年、 さすがに筆を走らせないと追い込まれてしまうので…
今年もいろいろありましたが、ブログのネタにできる変化としてはテスト管理ツールの運用を始めたことでしょうか。

こちら導入時の動機、想定していたメリット・デメリットや、運用開始後上手くいった・いかなかった点について記載していければと思います。

テスト管理ツールを導入したいと考えている方にとって少しでも役立てれば幸いです。

1. 使ってみたいと思った不純な動機

Googleスプレッドシートでの進捗管理がめんどくさくて仕方がない…
これが私の大きな原動力でした。

というのも、弊社はスプレッドシートで作成されたテストケースを用いて定期リリースに向けたテストを実施しているのですが、
光栄なことに複数のプロダクトの担当を任せていただいていたため、
予定したテストの終了確認と日々の進捗確認が非常に手間でした。

少し細かい内容ですが、
テスト項目数が多いため縦に長く、且つ環境ごとに実施するため横にも広がり…
うっかり1項目を飛ばしてしまった場合、探すのが大変という状況でした。
(〆作業を行う為のスプレッドシートとのにらめっこが嫌で嫌でしかたがなかった)
※ちゃんとリグレッションテストを改善しろよというごもっともなツッコミは無しでお願いしますmm

また何度も使うテストケースなので、コピーして過去に入力した結果欄を消すのも、めんどくさくて嫌でした。 (メンテナンス工数をうまく捻出できず秘伝の継ぎ足しタレ状態に)

2. 導入前に享受できると思ったメリット・デメリットについて

紆余曲折あり、無料ツールでの失敗から始まり有料ツールのトライアル利用を経て、
まずは1年使用できることがグループ内で合意でき、上長の承認もいただけました。

ここでは、
こんなことが出来るようになるだろうなという導入前に想定していたメリットをつらつらと…

導入前想定メリット

  • テスト管理工数の削減(1PJの定期リリース1回に際し,15分×10営業日程度を想定)
  • テストケースの資産化、再利用ができるためテスト準備の工数削減になる
  • テスト状況の可視化、レポート作成工数の削減
  • 自動テストツールとの連携による、テスト実施内容の可視化
  • PJごとにばらつきがちなテスト粒度が、同じツールを使用することで均一化
  • 管理ツール導入により何か全体的に改善されるのではないかという漠然とした期待

導入前想定デメリット

  • テストケースの移行コスト(プロダクトによっては1か月弱かかる可能性も)
  • 一度導入するとやめることが難しい、エクスポートしてから加工するなどスプレッドシートでは無かった新たなコストがかかってしまう恐れ
  • テストケースレビュー方法の再検討(アカウント数に上限があるツールだったため)

上記を想定しメリットで納得いただけるよう準備したつもりでしたが、いまいち上手くいかず…
自戒の意味も込めて、メリットに関する反応を主観的に振り返りたいと思います。

3. 上長からの反応(主観的な振り返り)

反応〇

  • テスト管理工数の削減
  • 再利用によるテスト準備工数の削減

反応△

  • テストケースの資産化
  • テスト状況の可視化、レポート作成工数の削減
     ※自動テストとの連携、ばらつきについては承認時には明記せず口頭での説明
     ※その他デメリットについては理解はいただけたと感じています

上長の立場を鑑みた際、
年額の費用が発生するため、想定通り社員工数の削減が強めな説得材料になりました。
導入前に予想していたよりも、テストケースの資産化は刺さらずという結果は、
説明が下手だった可能性が一因にあったと反省しています。

最終的にはQCDグループが今後も将来拡大していく旨、及び、
現場の負担が軽減されるならという理由で承認いただけました。

おまけ:グループ内で出た「スプレッドシートでいいじゃん」をあらためて振り返ると
テスト管理ツールを導入したいですと希望した際、
きっと他メンバーから上がるであろう伝家の宝刀「スプレッドシートでいいじゃん」に対しての振り返りです。
当時はうまく返答できませんでしたが、今返す言葉を考えるとしたら以下になると思っています。

  • テストを資産として残し”やすい”
    (保管場所が統一される)
  • フォーマットがある程度決まっているため、テストの実施体制を整え”やすい”
    (個人による差分が出来くい)
  • テスト管理体制を工数を多く使用することなく構築し”やすい”
    (計算式の修正から解放される)

ただ、ツールの学習コストや移行コスト、テスト設計の自由度まで鑑みてしまうと、どちらに分があるのかは導入後の現時点でも明言は出来ない状態です。
明言はできないものの、推進派一意見としては、
管理ツールを使うことにより将来的に実現したいことを考える機会が得られ、
次のステップを見据えることが出来たのでよかったと思っています。

4. 運用開始直後の振り返り

ここからは、導入してどのように使っているか、活用できているか、上手くいっていない運用など、
軽く紹介できればと思っています。

導入したテスト管理ツール:Testrailhttps://www.techmatrix.co.jp/product/testrail/
いつも細やかなサポート対応ありがとうございます。

1. テストにまつわる工数の削減(上手くいっている)

他メンバーの協力を得てテストを行う案件が多い中、日々の進捗や成果物確認については楽になったと思っています。

プロダクトにより大小はありますが、
1PJの定期リリースに際し、【10分~20分×テスト期間の営業日】は削減が出来ているかと。

例:1クリックでステータス毎のテストケースの抽出ができる(すごく便利)
※「Pass」ステータスとなっているテストを抽出した結果

また、マスターテストケースを作れるプロジェクト形式を選択すれば、
テストの資産化(再利用または不具合流出時の過去結果の参照など)は上手くいくと思います。

<運用一例>
マスターテストケース(v1.0)からv1.1ベースラインを切り出す
⇒テスト終了後、マスターテストケース(v1.0)にv1.1エンハンス個所を反映させる
 ⇒次ver開発時にマスターテストケース(v1.1)からv1.2ベースラインを切り出し
  ⇒v1.1実施内容も実施時のまま保管することが出来る

ベースライン切り出し時に、
どのテストケースを対象とするか、及び、フィルター後も動的に更新するかなどを選択でき、
スプレッドシートでのセル削除や非表示、項目数計算式の修正等からも無縁の状態となりました。

SubVersionを利用している環境下でも同様のことが出来ますが、
「v△△時の○○というテスト結果を探す」という状況ではテスト管理ツールの方が検索性は向上していると思います。

例:次テストケース作成時における参照元の選択

例:更新したMasterテストケースから実施するテストのフィルタリング
※動的なフィルタリングができるのでテスト更新時にももれなく対応できました。

2. テストケースの資産化(どちらかというと上手くいっていない)

テストケースの再利用という点はうまく運用できていますが、
たとえば過去の結果を振り返るといったような、資産化による価値はまだ享受できていません。ここは今後の課題。

3. テスト状況の可視化、レポート作成工数の削減(どちらかというと上手くいっていない)

テスト終了時のレポートは、標準テンプレートを利用すればクリックのみで作成・提出することは可能です。
ただ、プロジェクトごとに欲している内容は異なっているため、上手くいっているところと活用できていないところ両方あるのが実情です。
とはいえ、直近で行われたTestRailのバージョンアップにより、
TestRailとBTS連携を行っていれば信頼度曲線をすぐに出力することが出来るため、
今後プロダクトが成熟したときに活用できるのではないかと考えています。

4. BTSとの連携(どちらかというと上手くいった)

結果入力時に欠陥にBTSのキーを入力することで、
別ページではなくテストケース上で詳細内容を確認できるようになっているため、
作業効率は上がったと考えています。

しかしながら、
テスト内容をもとにBTS側にチケットを発行できる機能もあるのですが、
フォーマット等調整中のため上手く実運用で使用できておらず、今後の課題となっています。

5. 管理ツール内の情報(実施結果等)を共有する場合(上手くいっていない点)

現在QCDグループでは、
テスト実施前にテスト観点やテスト範囲・対象の認識合わせを行ったうえで、
テストケースの作成を行い、実施しています。

テスト観点等については従来通りスプレッドシートを使用することが多いため、レビュー自体に影響はないのですが、
テストケースの展開はアクティブアカウントしか閲覧できないため、
アカウント数を最小で運用しようとすると課題になってしまいます。

現状は、非アクティブユーザーとアクティブユーザーを切り替えることで、
プロジェクト側のステークホルダーにはテストケースを共有しています。
もし費用面で制限がないのであれば、
各プロダクトの企画及び開発リーダーの2名+αとして人数に余裕のあるプラン選択にすることをお勧めします。

来年度は効果測定を実施しつつアカウントを増やし、
運用面でどのような変化が起き、開発側の反応はどうだったのかは別の機会にお伝えできたらと考えています。

6. 入力工数の活用(上手くいっていない点、課題)

Testrailでは各項目実施時に工数を記録できる機能がありますが、現状はまだ活用できていません。
将来的にはテスト計画時の見積もりに活用したいと考えてはいます。

7. 自動化ツールとの連携が出来ていない(上手くいっていない点、課題)

例えば、現在モバイルプロジェクトでは毎日夜間にスモークテスト(荒めの全体動作確認)を実行しています。
理想像としては、どのrevison番号で実行してどういう結果だったかを、自動的にテスト管理ツール側に出力できるようにしたいのですが、 技術力と知見が足りず悪戦苦闘中です。

5. まとめ

導入してからの上手くいっている点、どちらかというと上手くいっている点、及び課題を簡単ではありますがまとめてみました。

正直、TestRailというツールの機能がリッチすぎて触れていない・活用できていない点が多くあり、
恥を忍んでブログを記載しています(´;ω;`)

運用ルールも、まだプロダクトごとに差分があるような導入の初期状態ですが…
テスト管理ツールを導入してみた結論及び感想としては、
テスト管理に関する工数削減など、テストマネージャーといわれる職域の方の効率化の面で貢献してくれる可能性は十分にあると思います。

しかしながら、ある程度テストプロセスが成熟しているプロダクトでは、
導入時のコストを鑑みると、テスト管理ツールはあまりメリットがないように導入直後は感じてしまうかもしれません。(グループへの提案時にそう感じた)

そうではなく、これから開発プロセスやテストに関して固めていくんだというフェーズのプロダクトでしたら、
上手くはまると思いますので、無料のテスト管理ツールを一度触って自身の組織に提案してみるのはどうでしょうか。

提案することで、
言語化する能力や説明力、上長が求めているもの、優先度を理解できるなど、
思わぬ副産物も得ることが出来ました。

また来年、
課題に進展があった場合か新しいネタが手に入ったら、皆様にお伝えしたいなと思っています。

SlackでTableau Vizを自動配信:データへの関心を高めるための実践ガイド

はじめに

この記事は Safie Engineers' Blog! Advent Calendar 2023 13日目の記事です。

こんにちは。データ分析基盤グループでデータアナリストをしているワンです。

データ分析基盤グループに関しては、下記の記事で詳しい情報が掲載されています。この分野にご関心がある方は、ぜひご一読ください。

engineers.safie.link

データを活用したビジネス改善とビジネスサイドとの連携強化の観点から、私たちデータ分析基盤グループはチームにおける主要KPIのモニタリングとアクションへの結び付けを促進する文化を築くことを目指しています。

セーフィーでは、データの可視化ツールとしてTableauを採用しておりますが、その利用率とデータ活用文化を向上させるために、

  • 適切なタイミングで
  • 適切な人々に
  • 適切なコンテンツを

提供することを重視しています。

Tableauで構築したVizをチームメンバーが日常的に使用するSlackに自動連携させることで、データへの迅速なアクセスが可能となり、より効率的な意思決定が行えるようになり、全体としてビジネスの成果向上を期待できます。

それを実現するために、GASでTableau VizをSlackに自動配信する仕組みを実装してみました。

この記事では、Google Apps Script (GAS)を使用して、Tableau VizをSlackに自動連携する方法を紹介します。

準備

  • Tableauで配信したいVizを用意します。
  • Tableauのアカウントが必要です。
  • Slackでボットを作成し、トークンを取得します。

手順

Tableau Vizのサブスクライブ

連携したいTableau Vizを選択し、サブスクライブ機能を使って、Gmailに定期配信します。

TableauのログインとVizの選択

  • Tableau Cloud にログインします。
  • Vizの選択
    • 配信したいTableau Vizを開き、配信したいものを選びます。

サブスクリプション機能の設定

  • サブスクリプション機能のアクセス
    • ビューのツールバーで、[Watch (視聴)] > [サブスクリプション] を選択します。
  • サブスクリプションの詳細設定

    • 配信するメールアドレスを選びます。Tableau登録時に使用したユーザーのメールアドレスに配信したいVizを送信します。個人メールアドレスよりは、管理面や効率的に情報伝達を考えてチームグループのメールアドレスに配信するように設定します。
  • 配信する頻度とスケジュールを選択します。今回は毎日朝08:55で指定しています。

  • サブスクリプションの確認
    • すべての詳細を確認した後、[サブスクリプション] ボタンをクリックしてサブスクリプションを完了します。

Slack Botの作成とトークンの取得

Slackボットの作成、設定、トークンの取得、インストールを手順に従って完了します。

Appの作成

  • Slackの公式サイトにログインした状態で、アプリケーションページ へ移動します。
  • [Create New App] をクリックし、[From Scratch] を選択します。
  • アプリに名前と対象のSlackワークスペースを指定し、[Create App] をクリックしてアプリを作成します。

Bot機能の追加とOAuthの設定

  • 先に作成したApp のページに移動します。このページ内で、Basic Information / Building Apps for Slack / Add features and functionality で、[Bots] を選択します。
  • App Homeのページに移動します。こちらで [Review Scopes to Add] を選択します。
  • OAuth & Permissions のページに移動します。少しスクロールして、[Scope] 下の [Bot Token Scopes]で、必要なスコープを追加します。
    • chat:write
    • files:write
    • users:read
    • users:read.email
  • OAuth & Permissions のページで、[Redirect URLs] を追加します。
    • https:///auth/add_oauth_token を追加します。 * にはワークスペースのURLが入ります。

Bot Tokenの確認

  • OAuth & Permissions のページで、OAuth Tokens for Your Workspaceの下で、[Bot User OAuth Token]をコピーします。

APPのインストール

  • [Settings] から [Basic Information] を選び、TableauInsightBot AppをSlack ワークスペースにインストールします。

投稿させるSlack Botをチャンネルに招待する

作成したBotを該当チャンネルに招待します。

  • [Intergrations]をクリックし、[Add apps]で先ほど作成したBotを該当チャンネルに招待します。例えば仮に #daily_notification_tableauのチャンネルに招待しました。

Google Apps Scriptの設定

GASの新規作成

  • Google Apps Script からProjectを新規作成します。

GASの編集

  • 作成したGASファイルに、下記コードをコピペします。例は毎日配信のスクリプトです。
function Tableau2Slack() {
  // スクリプトプロパティからトークンを取得
  var scriptProperties = PropertiesService.getScriptProperties();
  var SLACK_TOKEN = scriptProperties.getProperty('SLACK_TOKEN');

  // 今日の実行日付を取得し、東京タイムゾーンにフォーマットする
  var currentDate = new Date();
  var formattedCurrentDate = Utilities.formatDate(currentDate, 'Asia/Tokyo', 'yyyy-MM-dd\'T\'HH:mm:ss');

  // スクリプトプロパティから前回の実行日付を取得し、フォーマットする
  var lastExecutionDate = scriptProperties.getProperty('lastExecutionDate');
  var formattedLastExecutionDate = lastExecutionDate ? new Date(lastExecutionDate) : null;

  // 今日の実行日付が前回の実行日付と同じ場合は、関数を終了する
  if (formattedLastExecutionDate && formattedCurrentDate === formattedLastExecutionDate) {
    console.log("本日はすでに実行済みです。");
    return;
  }

  console.log("Last execution date: " + lastExecutionDate); // 前回の実行日付をコンソールに出力する

  // Tableauからの自動メール取得(条件に一致する最新のメールを一件取得)
  var Threads = GmailApp.search('from:"[メールアドレス]" subject:"[メールタイトル]"', 0, 1);
  var messages = Threads[0].getMessages();
  var message = messages[messages.length-1];

  // 自動メールから画像と日付を取得
  var attachments = message.getAttachments();
  var date = new Date();
  date.setDate(date.getDate() - 1); // 現在の日付から1日前の日付を取得
  var time = Utilities.formatDate(date, 'Asia/Tokyo', 'yyyy年M月d日');

  // Slack API Bot設定
  var data = {
    'token': SLACK_TOKEN,
    'file': attachments[0],
    'filename': '[ファイル名]',
    'channels': '[配信するチャンネル名]',
    'title': time + '[Tableau Viz名]',
    'initial_comment': '[コメント]'
  };
  var option = {
    'method': 'POST',
    'payload': data
  };
  UrlFetchApp.fetch('https://slack.com/api/files.upload', option);

  // スクリプトプロパティに今日の実行日付を保存する(日付と時刻を含む形式)
  scriptProperties.setProperty('lastExecutionDate', formattedCurrentDate);
};
  • コードの下記の情報は適切な値に置き換える必要があります。

    • [メールアドレス]
    • [メールタイトル] 
    • [ファイル名]
    • [Tableau Viz名]
    • [配信するチャンネル名]
    • [コメント]

SLACK_TOKENをプロパティに設定する

  • プロジェクトのプロパティ設定

    • GASメニューバーから歯車アイコンの[プロジェクトの設定]をクリックします。
    • [プロジェクトの設定]画面の一番下に[スクリプト プロパティ]があります。
  • SLACK_TOKENの追加

    • [プロパティ]フィールドにSLACK_TOKENと入力します。 [値]フィールドにSlackのトークン値を入力します。このトークンはSlack APIから取得したものを使用します。
    • 入力した情報を確認し、「保存」ボタンをクリックします。
    • 今回はスクリプト内でこのプロパティを使用しているので、 PropertiesService.getScriptProperties().getProperty('SLACK_TOKEN') を使用してアクセスします。

GASトリガーの設定

この手順に従って、GASで定期的にスクリプトを実行するトリガーを設定することができます。これにより、例えば毎日特定の時刻にデータを処理したり、定期的なTableauのVizを送信したりする自動化が可能になります。

  • GASのメニューバーから時計マークのアイコン[トリガー]を選択します。これにより、[現在のプロジェクトのトリガー]画面が開きます。

  • 右下にある「トリガーを追加」ボタンをクリックします。

  • この画面でトリガーを設定します。

    • 実行する関数を選択します。
      • 今回の場合はTableau2Slack
    • 実行するデプロイメントを選択します。
    • イベントのソースとして時間主導型を選択します。
    • 頻度の設定
      • [日単位] [週単位]など、スクリプトの実行頻度を選択します。
      • さらに詳細な時間設定(毎日の特定の時間帯、週の特定の日など)を行います。
    • 設定が完了したら、[保存] ボタンをクリックしてトリガーを保存します。

まとめ

この記事では、GASを活用してTableau VizをSlackに自動連携する方法を紹介しました。SlackへのTableau Vizの自動連携が、私たちの業務スタイルに新たな風を吹き込んでいると感じています。

Tableauには既にサブスクリプション機能が備わっており、定期的にメールでのViz配信が可能です。しかし、これらはメールボックスに届くため、日々の業務の中で見落とされがちです。

Slackに連携されるTableau Vizは、日々のコミュニケーションの流れの中で自然に目に触れることが多く、必要な情報をすぐに手に入れられます。これにより、ただのオンライン上にある数字やグラフではなく、「話す」データを共有して、よりダイナミックな議論が生まれ、具体的な行動につながりやすくなります。

たとえば、KPIを示すTableau VizがSlackに投稿されると、そのスレッド内での議論で、その数値をめぐって即座に議論が始まり、必要なアクションが迅速に決定されます。これは、メールで配信されるデータではなかなか起こり得ないことだと思います。

Slackの使い勝手の良さから、データへのアクセスがより手軽で直感的になり、データ利用やTableau利用のハードルが大きく下がることが期待できます。

会議が変わると組織が変わる!? ~開発本部会のやり方変えてみた話~

「この記事はSafie Engineers' Blog! Advent Calendar 8日目の記事です」

自己紹介と本日のテーマ

セーフィー株式会社 開発本部 エンジニアリングオフィスの武田 智一です。 セーフィーには2023年1月に入社して、エンジニアに対する組織開発全般をおこなっています。エンジニアオフィス(組織開発)って何やっているの?というのはまた別の機会でお話しするとして、 今回はセーフィーのエンジニア全員が参加する

「開発本部会のやり方変えてみた」

のお話しをさせてもらえればと思います。

  • 自己紹介と本日のテーマ
  • 全体会議の課題
  • 会議体の再定義
    • 1. なぜやるのかを言語化
    • 2. どうやって体感するか、の定義
    • 3. アジェンダの再設定
  • 改善ステップ(ストーリー作り)
    • 改善ステップ
  • 結果
  • まとめと今後の予定
続きを読む

QA組織を作ろう ~未経験者がQAチームを作るまで~

はじめに

こんにちは!Safie QAグループ(QCDグループ)のグループリーダーの山谷です。前回はテストの業務についてのテックブログを公開しましたが、今回はなりたちについてのお話になります。

私自身はSafieに入社するまではQAエンジニアどころかテストエンジニアとしてもキャリアがない状態で入社してます。 もし同じ状況でQAエンジニアチームを作る人達の何かの参考になれば嬉しいなと思い、ブログを書くことにしました。

  • テスト体制を作ろう
  • テスト担当者を作ろう
    • ■改善活動その1 ~顧客対応を巻き取る~
    • ■改善活動その2 ~バグチケットを溜める~
  • テストチームを作ろう
  • まとめ
続きを読む

ChatGPTの助けを借りて、FastAPIで画像ビューアーを作ってみた

この記事は Safie Engineers' Blog! Advent Calendar 2023 4日目の記事です。

  • はじめに
  • システム概要
    • システム構成
      • Stable Diffusion
      • ChatGPT
      • FastAPI
      • Poetry
  • 実装
    • プロジェクトの作成
    • ファイル一覧API
      • API作成
      • URLのパスでディレクトリを指定できるように修正
      • ファイルのダウンロード対応
    • ファイル一覧ページ
    • 画像のメタデータ取得
    • 画像一覧ページ
      • 画像のメタデータの表示
  • まとめ
続きを読む

tblsのViewPoint機能を用いたGithub Actions上でのDBドキュメントの自動生成

この記事はSafie Engineers' Blog! Advent Calendar 2日目の記事です。

セーフィー株式会社でテックリードをやっております鈴木敦志です。

セーフィーはクラウドカメラのSaaSを提供しており、現在22万台程度のデバイスに対してカメラ映像をクラウドから視聴する機能を提供しています。 それに加えエンタープライズ向けの権限管理機能や社内向けの販売管理ツールなど複数のサービスを運営しており、各サービスでMySQLのDBを共有しているためDBのテーブル数が肥大化し構造がわかりにくくなり、新機能開発の妨げとなっていました。

本稿ではデータベースのドキュメンテーションツールである tbls を導入し、DBスキーマ管理ツール skeema、ドキュメント生成ツール mkdocs、Github Actionsなどと組み合わせてスキーマ管理からドキュメント生成までをやっていきます。

  • 現在の問題点
  • ドキュメント記述方法の検討 - tbls
  • ドキュメント生成手順
    • skeema によるDBスキーマの適用
    • tbls によるドキュメント生成
    • mkdocsによるHTML生成
    • ドキュメント配信
  • tblsのViewPoints機能によるドキュメントの改善
  • 今後の課題
    • .tbls.yml のエディタ補完
続きを読む

© Safie Inc.