[ノーコード] Zapier × Slack × asanaでタスク管理とユーザーコミュニケーションを効率化する

こんにちは。

マネーフォワードビジネスカンパニー所属の下村です。
ビジネスサイドエンジニアとして、日々業務自動化や、効率化を推進してます。
(以前はCIO室に所属していましたが、ビジネスサイドの業務をテクノロジーで効率化したい!と思い異動しました。)

本日は、社員からの問い合わせや作業依頼についての対応を効率化してみた記事を書いてみます。

この記事の要約

  1. Slackとasanaを併用するうえで、両者のメリットを最大限活かしつつ、デメリットを消せる運用を自動化してみた。
  2. 依頼者とのコミュニケーションはSlackに統一。
  3. 対応者はタスク管理はasana、依頼者とのコミュニケーションをSlackで行いつつ、スレッドでのやり取りをasanaタスクのコメントに記録するようにした。
  4. 上記方法の実現にZapierを使ってノーコードで実現した。

なぜやったか

下記のような課題があったため、Slackやasanaの良いところを最大限、活かしつつタスク管理したいなーと思ったためです。

  • 依頼者とのコミュニケーションはSlackで行うのが便利なのでSlackで行いがち。
  • ただ、Slackはタスクの優先度付けやToDo管理には向いていない…。
    • 「あれ?あの質問内容どのスレッドでやりとりしてたっけ…」となりがち。
  • そこでasanaでタスク管理をしようとするが、下記のような問題点が起きがち。
    • Slackの投稿内容をasanaに転記するの漏れがち。
    • asanaのタスクだけを見ても何やってたか忘れてしまい、Slackのスレッドの内容を再確認して時間を無駄にしがち。

続きを読む

DogStatsDを使った独自メトリクスのDatadog取り込み検証をローカル環境で実施する

クラウド勤怠とクラウド給与で一人プロダクトSREをしているVTRyoです。いつの間にかプロダクトを兼任していて人手が足りません、助けてください

Datadogに独自メトリクスを取り込むために最初はStaging環境などで検証しようとしたのですが、動くかわからないもののためにエンジニアのコードレビュー時間を取っても勿体ないです。

ローカルでDogStatsDを検証する方法があったので紹介します。

前提

Datadog側が提供している既存のメトリクスでは取得できない、アプリケーション独自のメトリクスを集計する必要がありました。
プロダクト固有の問題に寄り添ったSLIを設定するためには、もはや必須の条件です。

独自のメトリクスをDatadogに送信する方法はいくつかあります。

  • カスタムAgentチェック
  • DogStatsD
  • PowerShell
  • DatadogのHTTP API

今回はDogStatsDを利用します。
アプリケーション側で制御できることや、Datadog Agentに付属するメトリクス集計サービスであることによる導入コストの低さが理由です。

続きを読む

アプリケーションロジックを見直してマネーフォワードMEのとあるAPIを約50%高速化しました

マネーフォワード ME のサーバサイドエンジニアの taka.naoga です。
ME が提供するとある機能のアプリケーションロジックを見直すことで、エンドポイント単位でパフォーマンスを改善した話を紹介しようと思います。

改善した機能紹介

はじめに、改善の対象となった機能について概要をご紹介します。

画像赤枠で囲われているアプリホーム画面の「お知らせ」機能です。

ここに表示されているお知らせは、ユーザの属性ごとに任意のセグメントを設定することで、リクエストしたユーザに合わせたキャンペーンや関連サービスの紹介などをすることができます。
社内からアクセスできる管理用のwebアプリケーションを使ってマーケティングチームなどが設定、運営をしています。

設定できるユーザ属性には、年齢や性別といったプロフィール情報から、「証券口座を連携しているユーザ」のようにユーザの連携口座に基づいたものなど多岐にわたります。

改善したアプリケーションロジックは、リクエストしたユーザがどのセグメントに属するかを判定し、表示するお知らせを抽出する部分です。

単語の定義

ここで改めてこの記事内の単語を整理しておきます。

ユーザ属性 … リクエストユーザの情報に応じた判定を行う個別の抽出条件。開発者が管理用webアプリケーションへ実装しマーケティングチームに機能として提供する。
例: 性別・年齢・プレミアムユーザかの判定・連携口座情報 など

セグメント … キャンペーンなどをパーソナライズするため、マーケティングチーム等が管理用webアプリケーションから設定するもの。複数のユーザ属性を組み合わせることによって1つのセグメントを設定する。
セグメント has_many ユーザ属性” の関係。
例: 「関東在住 20代男性」「プレミアムユーザで資産系口座を連携しているユーザ」など

お知らせ … アプリホーム画面で表示されているキャンペーンなどの実際の情報。上記のセグメントと紐つけパーソナライズを実現する。
お知らせ has_one セグメント” の関係。

進め方

改善のきっかけ

たびたびマーケティングチームから、こんな「セグメント」が設定できるように、とある「ユーザ属性」を追加して欲しい といった依頼が来ます。

判定するユーザ属性の追加は、内部のコード的にはパターン化されており、比較的工数をかけずに対応できていましたが、ひとつ大きな問題を抱えていました。

それは判定するユーザ属性の追加ごとに、セグメント判定のためのクエリ長が伸びパフォーマンスがどんどん悪化すること でした。

前述したように追加コスト自体はそれほど大きくなかったため、この問題は認識されながらも年単位で放置されていました。
ですが、あるときマーケティングチームからユーザ属性の追加依頼が数件来たタイミングで、このまま放っておけないと改善へのメス入れに立ち上がったという流れです。

問題の認識

まず、ユーザ属性の判定を追加するごとにクエリ長が伸びる原因をコードレベルで理解しました。
サーバサイドの処理はざっくり以下のようでした。

  1. すべてのお知らせに対して設定されている全てのセグメントを走査し、リクエストユーザにマッチするセグメントを抽出する
  2. 1で抽出したセグメントに対応するお知らせを取得する
  3. お知らせには「公開期間」が指定できるので、公開期間中のもののみ選択し、レスポンスする

1の処理では、設定可能なユーザ属性ひとつひとつに対して条件判定を行っています。肝は「セグメントに対して設定されたユーザ属性」ではなく「設定可能なユーザ属性」に対して処理が走っていることです。判定するユーザ属性の追加ごとにクエリ長が伸びるのはこのためです。

導入しているDatadogのAPMから、ワーストケースだとこのセグメント抽出周りで1リクエストでデータベースへ40クエリほど投げていることも確認しました。

改善案

上記のフローを以下の様に組み替えます。

  1. 公開期間中のお知らせから、それらが持つセグメントのリストを取得
  2. そのセグメントがそれぞれ持っている複数のユーザ属性を個別に判定する
  3. 2の結果、セグメント対象と判定されたお知らせをレスポンスする

組み替えたメリットとして2つを想定していました。

  • 公開期間中のお知らせを対象に判定を行うので、そもそも公開期間のお知らせが存在しない場合はセグメント抽出関連の処理が走らないようになる
  • 公開期間中のお知らせを対象に、かつそのセグメント判定に必要な条件判定のみ行うようにすることで、クエリ長が伸びる根本原因が解消される

ここまで整理したところで、サーバサイドチーム内で共有と方針のレビューを行いました。
プロダクトマネージャにも現状の課題と工数感を共有し、作業を進めるための準備を行います。

どちらからもGOサインをもらえたので、あとは方針に従って再実装するだけです。

リリース後…

ひと通り実装が完了し、いざリリースです。Datadog の APM ではエンドポイント単位でのレスポンスタイムを見ることができるのでそちらを確認すると…

以下画像のように 大きな改善を得ることができました!
リリース前後1週間でp99の平均値で比較すると 1.49s -> 0.80s と、46% の改善です。

また、アプリのホーム画面で必ず叩かれるAPIのレスポンスタイムを改善したこともあり、全エンドポイント共通でのレスポンスタイムにもトレンドの変化が見て取れます。

そのほか、発行されるクエリを改善したこともあり対象DBのCPU使用率もわずかながら改善していました。

(リリース後予想以上の改善に調子に乗っている様子)

まとめ

いかがでしたでしょうか。一口にパフォーマンスチューニングと言っても、意外とアプリケーションレイヤでロジックを見直すだけで今回のように成果が得られるケースもあるという紹介でした。
実際に取り組んでみて、数値に基づいた定量で成果を理解することができるのがパフォーマンスチューニングの良いところだなと思いました。

またチーム内でも「パフォーマンス改善に対してより前向きに取り組んでいきたい」という声が上がっていてポジティブな変化が生まれています。

ここまで読んで頂いたみなさんが、業務・個人問わず開発しているアプリケーションのロジックを見直すきっかけになったら幸いです。

続きを読む

OSS Forwardするエンジニアにインタビュー!なぜOSS開発文化が育っていないマネーフォワードで活動をおこなうのか?

企画概要

今回は最近マネーフォワードが公開したOSS開発の消費税計算GemJctを主導したTaKOBKiさんに、なぜ社内ライブラリをOSSで公開しようと考えたのか、を根掘り葉掘り聞いてみたいと思い、インタビュー企画を実施しました。

jct

OSSとは?

オープンソースソフトウェア(英: Open Source Software、略称: OSS)とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である[1]。

wikipedia参照

それでは早速インタビューしていきたいと思います!
聞き手は技術広報の luccafort です。

プロフィール: 株式会社マネーフォワード CTO室付 前田 喬之(TaKO8Ki

luccafort: まずは自己紹介からお願いします

TaKO8Ki:2019年11月からマネーフォワードの京都開発拠点にインターンとしてジョインしました。
『マネーフォワード クラウド会計Plus』(以下、会計Plus)のスクラムチームに入って、開発をしていました。
経歴を全て話すと長いのですが、『会計Plus』のパフォーマンス改善をおこなったり、現在も本番環境で動いているマイクロサービスの設計と開発をしていました。

続きを読む

AsanaのタスクをGoogleスプレッドシートに連携して不具合管理をしてみた:その2

みなさんこんにちは!HRソリューション本部でQAエンジニアをしている筑後です。
私は2021年9月にマネーフォワードに入社し、品質の可視化に取り組んでいます。

前回は、チームごとに異なるツールを使って不具合の管理をしている現状と、AsanaのAPIリクエストが想定通りになっているかのテスト方法を書きました。

今回はいよいよGoogleスプレッドシートに出力します。

目次

  • まずはGAS全体を大公開!
  • GASの中身の説明
    • 定数を用意する
    • 出力先のGoogleスプレッドシートを取得する
    • URLを取得する
    • タスクを取得する
    • Googleスプレッドシートに出力できた!
  • トリガーを追加する
  • さいごに

続きを読む

AsanaのタスクをGoogleスプレッドシートに連携して不具合管理をしてみた:その1

みなさんこんにちは!HRソリューション本部でQAエンジニアをしている筑後です。
私は2021年9月にマネーフォワードに入社し、品質の可視化に取り組んでいます。

突然ですが、みなさんはITS(Issue Tracking System)、BTS(Bug Tracking System)はどのようなツールを使っていますか?昨今は本当に色々なツールが各社から出ていたり、APIの連携ができたりと、組織や開発プランに合ったツールを検討できますよね。

HRソリューション本部では、チームによって異なるツールを利用しています。その中でも、「Asana」で管理しているタスクをGoogleスプレッドシートに連携したお話をします。

Tipsは「Access Tokenを取得する」から始まります!

目次

  • たかがツール、されどツールの昔話
  • 管理ツールは統一されないものである
  • 今回やりたいこと
  • Access Tokenを取得する
  • API ExplorerでAPIリクエストをテストする

続きを読む

全国の”一人プロダクトSRE”にTipsを届けたいので、SRE NEXT 2022 ONLINEに登壇します

こんにちは。プロダクトSREのVTRyoです。

SRE NEXT 2022 ONLINEのProposalが採択され、VTRyoが登壇することになりました。

SRE NEXTとは

信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスであり、同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されているものです。

セッション概要


マネーフォワードのSREは大きく分けて3種類のSRE組織に分かれており今回のセッションは、Product SREsによる登壇です。

  • Platform SRE
  • Enabling SRE
  • Product SREs

組織について詳しい部分は以下のブログを参照してください!

参加方法

無料ですが、チケット手に入れる必要があります。(個人スポンサープランもあり)

https://www.eventbrite.com/e/sre-next-2022-tickets-293885488407

日時

2021年5月14日(土)16:00-16:30 @ TrackA

※Online開催です

続きを読む

Create JSON Web Tokens with signatures by ECDSA_SHA algorithms signed by AWS KMS keys with python

Hello, this is Daiki Tanaka. I’m a member of CTO Office, AI Forward Division.
This page describes things to keep in mind when you create JSON Web Tokens (JWT) with signatures using ECDSA_SHA algorithms with AWS KMS keys. Sample codes here are all writen in python 3.8.

JSON Web Token

JSON Web Token (JWT) is a standard that defines a method for signing and encrypting JSON data.

As a practical use case, let’s consider a request from a client to an API server.

The followings are the steps needed when requesting to the API server with JWT. Here, we assume the API user has already created a public/private key pair.
1. Send the public key to the API server administrator in advance.
2. When the cluent makes a request, the private key is used to sign the request and create a JWT.
3. Set the created JWT in the header and make a request to the API.
4. The API server receives the request and verifies the validity of the signature using the public key.
5. If the signature is valid, the request is processed and the response is returned to the client from the API.

続きを読む

Go Conference 2022 Spring Onlineにメンバーが2名登壇、スポンサー協賛もおこないます!

4月23日(土) 10時からいよいよ Go Conference 2022 Spring が開催されます。
今回も日本中のGophersとお話できることを楽しみにしております。

まだ申し込みをしていないかたは、ぜひ以下のページよりお申し込みください。
Go Conference 2022 Spring (Online)

続きを読む

Android 13で導入されるNotification runtime permissionについて調べてみた

こんにちは。Androidエンジニアの宮本です。
マネーフォワード クラウド確定申告アプリの開発を担当しています。

マネーフォワードでは、毎月末に各部署のAndroidエンジニアが集まって開催している社内勉強会があります。
この社内勉強会では、毎回Android開発に関するテーマを1つ決めて深堀り、発表・ディスカッションを行っています。

本記事では2022年3月の社内勉強会で私が発表した、「Android 13で導入されるNotification runtime permission」について紹介します。

はじめに

2022年2月にAndroidの次期メジャーバージョン「Android 13」が発表されました。
本記事を執筆している2022年4月6日時点では、開発者向けプレビュー版の第2弾にあたる「Developer Preview 2」がリリースされています。

ドキュメントにはAndroid 13における変更点がまとめられています。
今回はこれらの変更点の内、通知機能を利用する際にユーザーへ要求する必要があるRuntime permissionについて解説します。

Runtime permissionとは、例えばカメラや位置情報、連絡先情報など、ユーザーの個人情報を含む可能性のある特別な機能・データにアクセスするために必要な権限のことです。
Android 13からは新たにアプリから通知を送信するために必要な権限が追加され、ユーザーからはこの権限の許可を得る必要があります。

本記事ではNotification runtime permissionのドキュメント通知機能の実装を体系的に学べるcodelabのアプリを題材に動作確認したことをまとめています。

今後のアップデートで内容に変更が入る可能性がありますのでご注意ください。

続きを読む