事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「CLINICS」 の開発・基盤周りを担当しております。 今回は、HTTP のコンテンツ圧縮について調査・対応する機会があったので、本ブログにて紹介したいと思います。 HTTP コンテンツの圧縮とは HTTP コンテンツの圧縮とは、HTTP の通信において Web サーバー側が返すデータを、なんらかの形式で圧縮してクライアントに返すことです。圧縮されたレスポンスをクライアント側は解凍して利用します。 HTTP コンテンツの圧縮によって得られるメリット・デメリットは以下の通りです。 ⤴ メリット 通信の帯域使用量を減らせる それによって通信にかかる時間を削減し、 ページ表示速度を向上 できる ⤵ デメリット 圧縮・解凍コストがかかる ただし、圧縮・解凍コストはほとんどの場合は小さいため、メリットを下回る 大容量ファイルやもともと圧縮されているファイル（画像や動画、PDF ファイルなど）を圧縮するのは、圧縮してもサイズがそれほど小さくならないため非効率である サイズがあまり削減できない割に、圧縮・解凍に CPU リソースを使い、数百 MB を超えるファイルになるとそれぞれ数秒かかることもある HTTP コンテンツを圧縮するためには HTTP コンテンツを圧縮するためには、クライアントが解凍可能な圧縮形式を指定する必要があります。解凍可能な圧縮形式を指定するには、リクエストヘッダに Accept-Encoding ヘッダを指定します。 最近のブラウザでは、HTTP リクエスト時に自動的に Accept-Encoding ヘッダを自動的に付加してアクセスしているので、ブラウザ経由の場合は特に明示的に指定する必要はありません。Chrome, Safari, Edge など、ほとんどのメジャーなブラウザでは Accept-Encoding: gzip, deflate, br が指定されています(※2021-01-23 時点)。 圧縮形式(gzip, deflate, br) 圧縮形式はいくつかありますが、ブラウザを利用する場合は以下のいずれかが選択肢になります。 gzip: LZ77 と 32 ビット CR を用いた圧縮形式 deflate: zlib 構造体と deflate 圧縮アルゴリズムを用いた圧縮形式 br: Brotli アルゴリズムを用いた圧縮形式。gzip に近いが大容量の言語辞書を用いて、頻出するパターンの単語を圧縮して効率化。そのため文章的なテキストでは gzip よりも圧縮率が高い と言われる Brotli は比較的新しい形式で、ほとんどのサーバー、ブラウザで対応しています。 サーバーでの HTTP コンテンツの圧縮方法(gzip) サーバーはクライアントの Accept-Encoding リクエストヘッダを受け取り、その中から 1 つを選択して圧縮処理を行い、 Content-Encoding レスポンスヘッダを付加してクライアントに結果を知らせます。 CLINICS が利用しているそれぞれのアプリケーション・ミドルウェアに絞って、どのように HTTP コンテンツ圧縮を実現しているか解説したいと思います。いくつか圧縮形式はありますが、ここでは gzip 形式での圧縮方法について解説します。 NGINX NGINX の ngx_http_gzip_module を利用することで gzip 圧縮することができます。 nginx.conf の gzip ディレクティブを on にすることで圧縮が有効になります。ただし、タイプを指定しないと Content-Type: text/html のときにしか圧縮されません。他のタイプでも圧縮したいときは gzip_types ディレクティブも合わせて指定する必要があります。 gzip_types に * を指定することで、すべてのコンテンツを圧縮することもできます。 gzip: on; gzip_types: text/css application/javascript application/json また、CloudFront など Proxy を経由してのアクセスの場合はデフォルトでは行われません。Proxy 経由のアクセスかどうかは、リクエストヘッダに Via ヘッダがあるかどうかで判定します。 CloudFront 経由でのアクセスの場合は Via: 1.1 xxxxx.cloudfront.net (CloudFront) のように Via ヘッダが付加されているため、NGINX にて Proxy 経由であると判定します。Proxy 経由であっても何かしらの条件で圧縮したい場合は gzip_proxied ディレクティブを指定する必要があります。 ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html CloudFront CloudFront の Behavior の設定にて設定します。Compress Objects Automatically を有効化することで、gzip 圧縮が有効になります。 上記を有効化すると、CloudFront では以下の条件で圧縮が行われます。 ファイルサイズが 1,000(≒1KB) 〜 10,000,000(≒10MB) バイトの間 よって、オリジンからファイルサイズを判定するための Content-Length ヘッダが付与されていない場合は、サイズ判別できないため圧縮されない 特定の Content-Type のコンテンツを圧縮する テキスト系のコンテンツは圧縮するが、画像や動画、PDF など、もともと圧縮されているものは対象外。詳しくは こちら オリジン側（NGINX や Rails など）から圧縮して返される場合は、 再度圧縮は行わない Content-Encoding ヘッダの有無で判定している ref. https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html Rails Rails はデフォルトでは HTTP コンテンツの圧縮は行いません。Rails でコンテンツ圧縮を行いたい場合は、Rails の Rack Middleware の Rack::Deflater を導入するのが簡単です。しかしながら、Rack::Deflater はすべての Content-Type のコンテンツでも圧縮するので、画像や動画・ PDF など圧縮するべきでないコンテンツまで圧縮してしまいます。NGINX や CloudFront など、Rails 外の他のサービスやミドルウェアに任せるのが良いと思います。 CLINICS での HTTP コンテンツ圧縮のシーケンス 前章で解説したアプリケーション・ミドルウェアは、CLINICS では以下のように連携しています。 AWS 上に Rails アプリケーションをデプロイしており、通常のアクセスはロードバランサーから NGINX を経由して Rails にアクセスし、静的ファイルなどキャッシュコンテンツは CloudFront 経由でアクセスしています。 CLINICS では用途に合わせた圧縮を行っています。3 つのケースを紹介します。 1. NGINX 経由で Rails にアクセスした時 API アクセスなどは上記シーケンスでアクセスしています。ほとんどが text/html や application/json 形式のコンテンツとなり、NGINX にて gzip 圧縮処理を行っています。Rails はアプリケーションの処理のみを行い、圧縮は行わないようにしています。 2. CloudFront 経由で S3 にアクセスした時 画像ファイルや PDF、静的な js、css ファイルなどはサービスのデプロイ時に S3 にアップロードしています。クライアントは CloudFront 経由でアクセスし、S3 から取得して、CloudFront で gzip に圧縮処理を行っています。また、一定期間 CloudFront 上にキャッシュされるので、効率よく圧縮コンテンツを返します。 3. CloudFront→NGINX→Rails 経由で S3 にアクセスした時 静的ファイルの中でもシグネチャをチェックしているものは、このフローでアクセスしています。NGINX でも圧縮設定を ON にしていますが、 Via ヘッダがあるため、NGINX では圧縮しないようになっています。 まとめ HTTP コンテンツの圧縮を適切に行うことで、サービス全体のパフォーマンス向上が見込めます。更に CloudFront を活用することで、アプリケーションやミドルウェアでの圧縮処理をなくし、更なるパフォーマンス向上が見込めます。 今回は HTTP コンテンツの gzip 圧縮についてのみ触れましたが、Brotli 圧縮についても NGINX、CloudFront ともに可能なため、今後取り入れていきたいと考えています。もし HTTP コンテンツの圧縮設定を特に気にしたことがない方は一度確認してみてはいかがでしょうか？ 最後に メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 https://www.medley.jp/jobs/

事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「CLINICS」 の開発・基盤周りを担当しております。 今回は、HTTP のコンテンツ圧縮について調査・対応する機会があったので、本ブログにて紹介したいと思います。 HTTP コンテンツの圧縮とは HTTP コンテンツの圧縮とは、HTTP の通信において Web サーバー側が返すデータを、なんらかの形式で圧縮してクライアントに返すことです。圧縮されたレスポンスをクライアント側は解凍して利用します。 HTTP コンテンツの圧縮によって得られるメリット・デメリットは以下の通りです。 ⤴ メリット 通信の帯域使用量を減らせる それによって通信にかかる時間を削減し、 ページ表示速度を向上 できる ⤵ デメリット 圧縮・解凍コストがかかる ただし、圧縮・解凍コストはほとんどの場合は小さいため、メリットを下回る 大容量ファイルやもともと圧縮されているファイル（画像や動画、PDF ファイルなど）を圧縮するのは、圧縮してもサイズがそれほど小さくならないため非効率である サイズがあまり削減できない割に、圧縮・解凍に CPU リソースを使い、数百 MB を超えるファイルになるとそれぞれ数秒かかることもある HTTP コンテンツを圧縮するためには HTTP コンテンツを圧縮するためには、クライアントが解凍可能な圧縮形式を指定する必要があります。解凍可能な圧縮形式を指定するには、リクエストヘッダに Accept-Encoding ヘッダを指定します。 最近のブラウザでは、HTTP リクエスト時に自動的に Accept-Encoding ヘッダを自動的に付加してアクセスしているので、ブラウザ経由の場合は特に明示的に指定する必要はありません。Chrome, Safari, Edge など、ほとんどのメジャーなブラウザでは Accept-Encoding: gzip, deflate, br が指定されています(※2021-01-23 時点)。 圧縮形式(gzip, deflate, br) 圧縮形式はいくつかありますが、ブラウザを利用する場合は以下のいずれかが選択肢になります。 gzip: LZ77 と 32 ビット CR を用いた圧縮形式 deflate: zlib 構造体と deflate 圧縮アルゴリズムを用いた圧縮形式 br: Brotli アルゴリズムを用いた圧縮形式。gzip に近いが大容量の言語辞書を用いて、頻出するパターンの単語を圧縮して効率化。そのため文章的なテキストでは gzip よりも圧縮率が高い と言われる Brotli は比較的新しい形式で、ほとんどのサーバー、ブラウザで対応しています。 サーバーでの HTTP コンテンツの圧縮方法(gzip) サーバーはクライアントの Accept-Encoding リクエストヘッダを受け取り、その中から 1 つを選択して圧縮処理を行い、 Content-Encoding レスポンスヘッダを付加してクライアントに結果を知らせます。 CLINICS が利用しているそれぞれのアプリケーション・ミドルウェアに絞って、どのように HTTP コンテンツ圧縮を実現しているか解説したいと思います。いくつか圧縮形式はありますが、ここでは gzip 形式での圧縮方法について解説します。 NGINX NGINX の ngx_http_gzip_module を利用することで gzip 圧縮することができます。 nginx.conf の gzip ディレクティブを on にすることで圧縮が有効になります。ただし、タイプを指定しないと Content-Type: text/html のときにしか圧縮されません。他のタイプでも圧縮したいときは gzip_types ディレクティブも合わせて指定する必要があります。 gzip_types に * を指定することで、すべてのコンテンツを圧縮することもできます。 gzip: on; gzip_types: text/css application/javascript application/json また、CloudFront など Proxy を経由してのアクセスの場合はデフォルトでは行われません。Proxy 経由のアクセスかどうかは、リクエストヘッダに Via ヘッダがあるかどうかで判定します。 CloudFront 経由でのアクセスの場合は Via: 1.1 xxxxx.cloudfront.net (CloudFront) のように Via ヘッダが付加されているため、NGINX にて Proxy 経由であると判定します。Proxy 経由であっても何かしらの条件で圧縮したい場合は gzip_proxied ディレクティブを指定する必要があります。 ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html CloudFront CloudFront の Behavior の設定にて設定します。Compress Objects Automatically を有効化することで、gzip 圧縮が有効になります。 上記を有効化すると、CloudFront では以下の条件で圧縮が行われます。 ファイルサイズが 1,000(≒1KB) 〜 10,000,000(≒10MB) バイトの間 よって、オリジンからファイルサイズを判定するための Content-Length ヘッダが付与されていない場合は、サイズ判別できないため圧縮されない 特定の Content-Type のコンテンツを圧縮する テキスト系のコンテンツは圧縮するが、画像や動画、PDF など、もともと圧縮されているものは対象外。詳しくは こちら オリジン側（NGINX や Rails など）から圧縮して返される場合は、 再度圧縮は行わない Content-Encoding ヘッダの有無で判定している ref. https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html Rails Rails はデフォルトでは HTTP コンテンツの圧縮は行いません。Rails でコンテンツ圧縮を行いたい場合は、Rails の Rack Middleware の Rack::Deflater を導入するのが簡単です。しかしながら、Rack::Deflater はすべての Content-Type のコンテンツでも圧縮するので、画像や動画・ PDF など圧縮するべきでないコンテンツまで圧縮してしまいます。NGINX や CloudFront など、Rails 外の他のサービスやミドルウェアに任せるのが良いと思います。 CLINICS での HTTP コンテンツ圧縮のシーケンス 前章で解説したアプリケーション・ミドルウェアは、CLINICS では以下のように連携しています。 AWS 上に Rails アプリケーションをデプロイしており、通常のアクセスはロードバランサーから NGINX を経由して Rails にアクセスし、静的ファイルなどキャッシュコンテンツは CloudFront 経由でアクセスしています。 CLINICS では用途に合わせた圧縮を行っています。3 つのケースを紹介します。 1. NGINX 経由で Rails にアクセスした時 API アクセスなどは上記シーケンスでアクセスしています。ほとんどが text/html や application/json 形式のコンテンツとなり、NGINX にて gzip 圧縮処理を行っています。Rails はアプリケーションの処理のみを行い、圧縮は行わないようにしています。 2. CloudFront 経由で S3 にアクセスした時 画像ファイルや PDF、静的な js、css ファイルなどはサービスのデプロイ時に S3 にアップロードしています。クライアントは CloudFront 経由でアクセスし、S3 から取得して、CloudFront で gzip に圧縮処理を行っています。また、一定期間 CloudFront 上にキャッシュされるので、効率よく圧縮コンテンツを返します。 3. CloudFront→NGINX→Rails 経由で S3 にアクセスした時 静的ファイルの中でもシグネチャをチェックしているものは、このフローでアクセスしています。NGINX でも圧縮設定を ON にしていますが、 Via ヘッダがあるため、NGINX では圧縮しないようになっています。 まとめ HTTP コンテンツの圧縮を適切に行うことで、サービス全体のパフォーマンス向上が見込めます。更に CloudFront を活用することで、アプリケーションやミドルウェアでの圧縮処理をなくし、更なるパフォーマンス向上が見込めます。 今回は HTTP コンテンツの gzip 圧縮についてのみ触れましたが、Brotli 圧縮についても NGINX、CloudFront ともに可能なため、今後取り入れていきたいと考えています。もし HTTP コンテンツの圧縮設定を特に気にしたことがない方は一度確認してみてはいかがでしょうか？ 最後に メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「CLINICS」 の開発・基盤周りを担当しております。 今回は、HTTP のコンテンツ圧縮について調査・対応する機会があったので、本ブログにて紹介したいと思います。 HTTP コンテンツの圧縮とは HTTP コンテンツの圧縮とは、HTTP の通信において Web サーバー側が返すデータを、なんらかの形式で圧縮してクライアントに返すことです。圧縮されたレスポンスをクライアント側は解凍して利用します。 HTTP コンテンツの圧縮によって得られるメリット・デメリットは以下の通りです。 ⤴ メリット 通信の帯域使用量を減らせる それによって通信にかかる時間を削減し、 ページ表示速度を向上 できる ⤵ デメリット 圧縮・解凍コストがかかる ただし、圧縮・解凍コストはほとんどの場合は小さいため、メリットを下回る 大容量ファイルやもともと圧縮されているファイル（画像や動画、PDF ファイルなど）を圧縮するのは、圧縮してもサイズがそれほど小さくならないため非効率である サイズがあまり削減できない割に、圧縮・解凍に CPU リソースを使い、数百 MB を超えるファイルになるとそれぞれ数秒かかることもある HTTP コンテンツを圧縮するためには HTTP コンテンツを圧縮するためには、クライアントが解凍可能な圧縮形式を指定する必要があります。解凍可能な圧縮形式を指定するには、リクエストヘッダに Accept-Encoding ヘッダを指定します。 最近のブラウザでは、HTTP リクエスト時に自動的に Accept-Encoding ヘッダを自動的に付加してアクセスしているので、ブラウザ経由の場合は特に明示的に指定する必要はありません。Chrome, Safari, Edge など、ほとんどのメジャーなブラウザでは Accept-Encoding: gzip, deflate, br が指定されています(※2021-01-23 時点)。 圧縮形式(gzip, deflate, br) 圧縮形式はいくつかありますが、ブラウザを利用する場合は以下のいずれかが選択肢になります。 gzip: LZ77 と 32 ビット CR を用いた圧縮形式 deflate: zlib 構造体と deflate 圧縮アルゴリズムを用いた圧縮形式 br: Brotli アルゴリズムを用いた圧縮形式。gzip に近いが大容量の言語辞書を用いて、頻出するパターンの単語を圧縮して効率化。そのため文章的なテキストでは gzip よりも圧縮率が高い と言われる Brotli は比較的新しい形式で、ほとんどのサーバー、ブラウザで対応しています。 サーバーでの HTTP コンテンツの圧縮方法(gzip) サーバーはクライアントの Accept-Encoding リクエストヘッダを受け取り、その中から 1 つを選択して圧縮処理を行い、 Content-Encoding レスポンスヘッダを付加してクライアントに結果を知らせます。 CLINICS が利用しているそれぞれのアプリケーション・ミドルウェアに絞って、どのように HTTP コンテンツ圧縮を実現しているか解説したいと思います。いくつか圧縮形式はありますが、ここでは gzip 形式での圧縮方法について解説します。 NGINX NGINX の ngx_http_gzip_module を利用することで gzip 圧縮することができます。 nginx.conf の gzip ディレクティブを on にすることで圧縮が有効になります。ただし、タイプを指定しないと Content-Type: text/html のときにしか圧縮されません。他のタイプでも圧縮したいときは gzip_types ディレクティブも合わせて指定する必要があります。 gzip_types に * を指定することで、すべてのコンテンツを圧縮することもできます。 gzip: on; gzip_types: text/css application/javascript application/json また、CloudFront など Proxy を経由してのアクセスの場合はデフォルトでは行われません。Proxy 経由のアクセスかどうかは、リクエストヘッダに Via ヘッダがあるかどうかで判定します。 CloudFront 経由でのアクセスの場合は Via: 1.1 xxxxx.cloudfront.net (CloudFront) のように Via ヘッダが付加されているため、NGINX にて Proxy 経由であると判定します。Proxy 経由であっても何かしらの条件で圧縮したい場合は gzip_proxied ディレクティブを指定する必要があります。 ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html CloudFront CloudFront の Behavior の設定にて設定します。Compress Objects Automatically を有効化することで、gzip 圧縮が有効になります。 上記を有効化すると、CloudFront では以下の条件で圧縮が行われます。 ファイルサイズが 1,000(≒1KB) 〜 10,000,000(≒10MB) バイトの間 よって、オリジンからファイルサイズを判定するための Content-Length ヘッダが付与されていない場合は、サイズ判別できないため圧縮されない 特定の Content-Type のコンテンツを圧縮する テキスト系のコンテンツは圧縮するが、画像や動画、PDF など、もともと圧縮されているものは対象外。詳しくは こちら オリジン側（NGINX や Rails など）から圧縮して返される場合は、 再度圧縮は行わない Content-Encoding ヘッダの有無で判定している ref. https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html Rails Rails はデフォルトでは HTTP コンテンツの圧縮は行いません。Rails でコンテンツ圧縮を行いたい場合は、Rails の Rack Middleware の Rack::Deflater を導入するのが簡単です。しかしながら、Rack::Deflater はすべての Content-Type のコンテンツでも圧縮するので、画像や動画・ PDF など圧縮するべきでないコンテンツまで圧縮してしまいます。NGINX や CloudFront など、Rails 外の他のサービスやミドルウェアに任せるのが良いと思います。 CLINICS での HTTP コンテンツ圧縮のシーケンス 前章で解説したアプリケーション・ミドルウェアは、CLINICS では以下のように連携しています。 AWS 上に Rails アプリケーションをデプロイしており、通常のアクセスはロードバランサーから NGINX を経由して Rails にアクセスし、静的ファイルなどキャッシュコンテンツは CloudFront 経由でアクセスしています。 CLINICS では用途に合わせた圧縮を行っています。3 つのケースを紹介します。 1. NGINX 経由で Rails にアクセスした時 API アクセスなどは上記シーケンスでアクセスしています。ほとんどが text/html や application/json 形式のコンテンツとなり、NGINX にて gzip 圧縮処理を行っています。Rails はアプリケーションの処理のみを行い、圧縮は行わないようにしています。 2. CloudFront 経由で S3 にアクセスした時 画像ファイルや PDF、静的な js、css ファイルなどはサービスのデプロイ時に S3 にアップロードしています。クライアントは CloudFront 経由でアクセスし、S3 から取得して、CloudFront で gzip に圧縮処理を行っています。また、一定期間 CloudFront 上にキャッシュされるので、効率よく圧縮コンテンツを返します。 3. CloudFront→NGINX→Rails 経由で S3 にアクセスした時 静的ファイルの中でもシグネチャをチェックしているものは、このフローでアクセスしています。NGINX でも圧縮設定を ON にしていますが、 Via ヘッダがあるため、NGINX では圧縮しないようになっています。 まとめ HTTP コンテンツの圧縮を適切に行うことで、サービス全体のパフォーマンス向上が見込めます。更に CloudFront を活用することで、アプリケーションやミドルウェアでの圧縮処理をなくし、更なるパフォーマンス向上が見込めます。 今回は HTTP コンテンツの gzip 圧縮についてのみ触れましたが、Brotli 圧縮についても NGINX、CloudFront ともに可能なため、今後取り入れていきたいと考えています。もし HTTP コンテンツの圧縮設定を特に気にしたことがない方は一度確認してみてはいかがでしょうか？ 最後に メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「CLINICS」 の開発・基盤周りを担当しております。 今回は、HTTP のコンテンツ圧縮について調査・対応する機会があったので、本ブログにて紹介したいと思います。 HTTP コンテンツの圧縮とは HTTP コンテンツの圧縮とは、HTTP の通信において Web サーバー側が返すデータを、なんらかの形式で圧縮してクライアントに返すことです。圧縮されたレスポンスをクライアント側は解凍して利用します。 HTTP コンテンツの圧縮によって得られるメリット・デメリットは以下の通りです。 ⤴ メリット 通信の帯域使用量を減らせる それによって通信にかかる時間を削減し、 ページ表示速度を向上 できる ⤵ デメリット 圧縮・解凍コストがかかる ただし、圧縮・解凍コストはほとんどの場合は小さいため、メリットを下回る 大容量ファイルやもともと圧縮されているファイル（画像や動画、PDF ファイルなど）を圧縮するのは、圧縮してもサイズがそれほど小さくならないため非効率である サイズがあまり削減できない割に、圧縮・解凍に CPU リソースを使い、数百 MB を超えるファイルになるとそれぞれ数秒かかることもある HTTP コンテンツを圧縮するためには HTTP コンテンツを圧縮するためには、クライアントが解凍可能な圧縮形式を指定する必要があります。解凍可能な圧縮形式を指定するには、リクエストヘッダに Accept-Encoding ヘッダを指定します。 最近のブラウザでは、HTTP リクエスト時に自動的に Accept-Encoding ヘッダを自動的に付加してアクセスしているので、ブラウザ経由の場合は特に明示的に指定する必要はありません。Chrome, Safari, Edge など、ほとんどのメジャーなブラウザでは Accept-Encoding: gzip, deflate, br が指定されています(※2021-01-23 時点)。 圧縮形式(gzip, deflate, br) 圧縮形式はいくつかありますが、ブラウザを利用する場合は以下のいずれかが選択肢になります。 gzip: LZ77 と 32 ビット CR を用いた圧縮形式 deflate: zlib 構造体と deflate 圧縮アルゴリズムを用いた圧縮形式 br: Brotli アルゴリズムを用いた圧縮形式。gzip に近いが大容量の言語辞書を用いて、頻出するパターンの単語を圧縮して効率化。そのため文章的なテキストでは gzip よりも圧縮率が高い と言われる Brotli は比較的新しい形式で、ほとんどのサーバー、ブラウザで対応しています。 サーバーでの HTTP コンテンツの圧縮方法(gzip) サーバーはクライアントの Accept-Encoding リクエストヘッダを受け取り、その中から 1 つを選択して圧縮処理を行い、 Content-Encoding レスポンスヘッダを付加してクライアントに結果を知らせます。 CLINICS が利用しているそれぞれのアプリケーション・ミドルウェアに絞って、どのように HTTP コンテンツ圧縮を実現しているか解説したいと思います。いくつか圧縮形式はありますが、ここでは gzip 形式での圧縮方法について解説します。 NGINX NGINX の ngx_http_gzip_module を利用することで gzip 圧縮することができます。 nginx.conf の gzip ディレクティブを on にすることで圧縮が有効になります。ただし、タイプを指定しないと Content-Type: text/html のときにしか圧縮されません。他のタイプでも圧縮したいときは gzip_types ディレクティブも合わせて指定する必要があります。 gzip_types に * を指定することで、すべてのコンテンツを圧縮することもできます。 gzip: on; gzip_types: text/css application/javascript application/json また、CloudFront など Proxy を経由してのアクセスの場合はデフォルトでは行われません。Proxy 経由のアクセスかどうかは、リクエストヘッダに Via ヘッダがあるかどうかで判定します。 CloudFront 経由でのアクセスの場合は Via: 1.1 xxxxx.cloudfront.net (CloudFront) のように Via ヘッダが付加されているため、NGINX にて Proxy 経由であると判定します。Proxy 経由であっても何かしらの条件で圧縮したい場合は gzip_proxied ディレクティブを指定する必要があります。 ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html CloudFront CloudFront の Behavior の設定にて設定します。Compress Objects Automatically を有効化することで、gzip 圧縮が有効になります。 上記を有効化すると、CloudFront では以下の条件で圧縮が行われます。 ファイルサイズが 1,000(≒1KB) 〜 10,000,000(≒10MB) バイトの間 よって、オリジンからファイルサイズを判定するための Content-Length ヘッダが付与されていない場合は、サイズ判別できないため圧縮されない 特定の Content-Type のコンテンツを圧縮する テキスト系のコンテンツは圧縮するが、画像や動画、PDF など、もともと圧縮されているものは対象外。詳しくは こちら オリジン側（NGINX や Rails など）から圧縮して返される場合は、 再度圧縮は行わない Content-Encoding ヘッダの有無で判定している ref. https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html Rails Rails はデフォルトでは HTTP コンテンツの圧縮は行いません。Rails でコンテンツ圧縮を行いたい場合は、Rails の Rack Middleware の Rack::Deflater を導入するのが簡単です。しかしながら、Rack::Deflater はすべての Content-Type のコンテンツでも圧縮するので、画像や動画・ PDF など圧縮するべきでないコンテンツまで圧縮してしまいます。NGINX や CloudFront など、Rails 外の他のサービスやミドルウェアに任せるのが良いと思います。 CLINICS での HTTP コンテンツ圧縮のシーケンス 前章で解説したアプリケーション・ミドルウェアは、CLINICS では以下のように連携しています。 AWS 上に Rails アプリケーションをデプロイしており、通常のアクセスはロードバランサーから NGINX を経由して Rails にアクセスし、静的ファイルなどキャッシュコンテンツは CloudFront 経由でアクセスしています。 CLINICS では用途に合わせた圧縮を行っています。3 つのケースを紹介します。 1. NGINX 経由で Rails にアクセスした時 API アクセスなどは上記シーケンスでアクセスしています。ほとんどが text/html や application/json 形式のコンテンツとなり、NGINX にて gzip 圧縮処理を行っています。Rails はアプリケーションの処理のみを行い、圧縮は行わないようにしています。 2. CloudFront 経由で S3 にアクセスした時 画像ファイルや PDF、静的な js、css ファイルなどはサービスのデプロイ時に S3 にアップロードしています。クライアントは CloudFront 経由でアクセスし、S3 から取得して、CloudFront で gzip に圧縮処理を行っています。また、一定期間 CloudFront 上にキャッシュされるので、効率よく圧縮コンテンツを返します。 3. CloudFront→NGINX→Rails 経由で S3 にアクセスした時 静的ファイルの中でもシグネチャをチェックしているものは、このフローでアクセスしています。NGINX でも圧縮設定を ON にしていますが、 Via ヘッダがあるため、NGINX では圧縮しないようになっています。 まとめ HTTP コンテンツの圧縮を適切に行うことで、サービス全体のパフォーマンス向上が見込めます。更に CloudFront を活用することで、アプリケーションやミドルウェアでの圧縮処理をなくし、更なるパフォーマンス向上が見込めます。 今回は HTTP コンテンツの gzip 圧縮についてのみ触れましたが、Brotli 圧縮についても NGINX、CloudFront ともに可能なため、今後取り入れていきたいと考えています。もし HTTP コンテンツの圧縮設定を特に気にしたことがない方は一度確認してみてはいかがでしょうか？ 最後に メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「CLINICS」 の開発・基盤周りを担当しております。 今回は、HTTP のコンテンツ圧縮について調査・対応する機会があったので、本ブログにて紹介したいと思います。 HTTP コンテンツの圧縮とは HTTP コンテンツの圧縮とは、HTTP の通信において Web サーバー側が返すデータを、なんらかの形式で圧縮してクライアントに返すことです。圧縮されたレスポンスをクライアント側は解凍して利用します。 HTTP コンテンツの圧縮によって得られるメリット・デメリットは以下の通りです。 ⤴ メリット 通信の帯域使用量を減らせる それによって通信にかかる時間を削減し、 ページ表示速度を向上 できる ⤵ デメリット 圧縮・解凍コストがかかる ただし、圧縮・解凍コストはほとんどの場合は小さいため、メリットを下回る 大容量ファイルやもともと圧縮されているファイル（画像や動画、PDF ファイルなど）を圧縮するのは、圧縮してもサイズがそれほど小さくならないため非効率である サイズがあまり削減できない割に、圧縮・解凍に CPU リソースを使い、数百 MB を超えるファイルになるとそれぞれ数秒かかることもある HTTP コンテンツを圧縮するためには HTTP コンテンツを圧縮するためには、クライアントが解凍可能な圧縮形式を指定する必要があります。解凍可能な圧縮形式を指定するには、リクエストヘッダに Accept-Encoding ヘッダを指定します。 最近のブラウザでは、HTTP リクエスト時に自動的に Accept-Encoding ヘッダを自動的に付加してアクセスしているので、ブラウザ経由の場合は特に明示的に指定する必要はありません。Chrome, Safari, Edge など、ほとんどのメジャーなブラウザでは Accept-Encoding: gzip, deflate, br が指定されています(※2021-01-23 時点)。 圧縮形式(gzip, deflate, br) 圧縮形式はいくつかありますが、ブラウザを利用する場合は以下のいずれかが選択肢になります。 gzip: LZ77 と 32 ビット CR を用いた圧縮形式 deflate: zlib 構造体と deflate 圧縮アルゴリズムを用いた圧縮形式 br: Brotli アルゴリズムを用いた圧縮形式。gzip に近いが大容量の言語辞書を用いて、頻出するパターンの単語を圧縮して効率化。そのため文章的なテキストでは gzip よりも圧縮率が高い と言われる Brotli は比較的新しい形式で、ほとんどのサーバー、ブラウザで対応しています。 サーバーでの HTTP コンテンツの圧縮方法(gzip) サーバーはクライアントの Accept-Encoding リクエストヘッダを受け取り、その中から 1 つを選択して圧縮処理を行い、 Content-Encoding レスポンスヘッダを付加してクライアントに結果を知らせます。 CLINICS が利用しているそれぞれのアプリケーション・ミドルウェアに絞って、どのように HTTP コンテンツ圧縮を実現しているか解説したいと思います。いくつか圧縮形式はありますが、ここでは gzip 形式での圧縮方法について解説します。 NGINX NGINX の ngx_http_gzip_module を利用することで gzip 圧縮することができます。 nginx.conf の gzip ディレクティブを on にすることで圧縮が有効になります。ただし、タイプを指定しないと Content-Type: text/html のときにしか圧縮されません。他のタイプでも圧縮したいときは gzip_types ディレクティブも合わせて指定する必要があります。 gzip_types に * を指定することで、すべてのコンテンツを圧縮することもできます。 gzip: on; gzip_types: text/css application/javascript application/json また、CloudFront など Proxy を経由してのアクセスの場合はデフォルトでは行われません。Proxy 経由のアクセスかどうかは、リクエストヘッダに Via ヘッダがあるかどうかで判定します。 CloudFront 経由でのアクセスの場合は Via: 1.1 xxxxx.cloudfront.net (CloudFront) のように Via ヘッダが付加されているため、NGINX にて Proxy 経由であると判定します。Proxy 経由であっても何かしらの条件で圧縮したい場合は gzip_proxied ディレクティブを指定する必要があります。 ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html CloudFront CloudFront の Behavior の設定にて設定します。Compress Objects Automatically を有効化することで、gzip 圧縮が有効になります。 上記を有効化すると、CloudFront では以下の条件で圧縮が行われます。 ファイルサイズが 1,000(≒1KB) 〜 10,000,000(≒10MB) バイトの間 よって、オリジンからファイルサイズを判定するための Content-Length ヘッダが付与されていない場合は、サイズ判別できないため圧縮されない 特定の Content-Type のコンテンツを圧縮する テキスト系のコンテンツは圧縮するが、画像や動画、PDF など、もともと圧縮されているものは対象外。詳しくは こちら オリジン側（NGINX や Rails など）から圧縮して返される場合は、 再度圧縮は行わない Content-Encoding ヘッダの有無で判定している ref. https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html Rails Rails はデフォルトでは HTTP コンテンツの圧縮は行いません。Rails でコンテンツ圧縮を行いたい場合は、Rails の Rack Middleware の Rack::Deflater を導入するのが簡単です。しかしながら、Rack::Deflater はすべての Content-Type のコンテンツでも圧縮するので、画像や動画・ PDF など圧縮するべきでないコンテンツまで圧縮してしまいます。NGINX や CloudFront など、Rails 外の他のサービスやミドルウェアに任せるのが良いと思います。 CLINICS での HTTP コンテンツ圧縮のシーケンス 前章で解説したアプリケーション・ミドルウェアは、CLINICS では以下のように連携しています。 AWS 上に Rails アプリケーションをデプロイしており、通常のアクセスはロードバランサーから NGINX を経由して Rails にアクセスし、静的ファイルなどキャッシュコンテンツは CloudFront 経由でアクセスしています。 CLINICS では用途に合わせた圧縮を行っています。3 つのケースを紹介します。 1. NGINX 経由で Rails にアクセスした時 API アクセスなどは上記シーケンスでアクセスしています。ほとんどが text/html や application/json 形式のコンテンツとなり、NGINX にて gzip 圧縮処理を行っています。Rails はアプリケーションの処理のみを行い、圧縮は行わないようにしています。 2. CloudFront 経由で S3 にアクセスした時 画像ファイルや PDF、静的な js、css ファイルなどはサービスのデプロイ時に S3 にアップロードしています。クライアントは CloudFront 経由でアクセスし、S3 から取得して、CloudFront で gzip に圧縮処理を行っています。また、一定期間 CloudFront 上にキャッシュされるので、効率よく圧縮コンテンツを返します。 3. CloudFront→NGINX→Rails 経由で S3 にアクセスした時 静的ファイルの中でもシグネチャをチェックしているものは、このフローでアクセスしています。NGINX でも圧縮設定を ON にしていますが、 Via ヘッダがあるため、NGINX では圧縮しないようになっています。 まとめ HTTP コンテンツの圧縮を適切に行うことで、サービス全体のパフォーマンス向上が見込めます。更に CloudFront を活用することで、アプリケーションやミドルウェアでの圧縮処理をなくし、更なるパフォーマンス向上が見込めます。 今回は HTTP コンテンツの gzip 圧縮についてのみ触れましたが、Brotli 圧縮についても NGINX、CloudFront ともに可能なため、今後取り入れていきたいと考えています。もし HTTP コンテンツの圧縮設定を特に気にしたことがない方は一度確認してみてはいかがでしょうか？ 最後に メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 https://www.medley.jp/jobs/

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。インキュベーション本部の QA エンジニアの米山です。主に CLINICS アプリの QA を担当しています。メドレーには 2020 年 8 月に入社しました。 今回は入社してまず行ったことの一つ、リグレッションテストの自動化と、そのために導入した Magic Pod というツールについて、経緯や導入してみた結果をご紹介したいと思います。 CLINICS とは 私の所属するチームで開発している CLINICS というプロダクトはアプリでオンライン診療や、クリニック・病院から処方箋を発行してもらうことができ、オンライン上で診察からお薬の受け取りまで完結できるサービスです。 プラットフォームは iOS と Android のネイティブアプリ、それから同様のサービスを Web ブラウザからも利用することが出来ます。 QA／リリース周りの状況 CLINICS の開発組織に QA エンジニアがジョインしたのは昨年（2020 年）ですが、サービス自体は 2016 年にローンチされています。 本組織ではリリース前に行うリグレッションテストについては、開発メンバを中心にチーム全体で行う文化があります。 アプリのリリースは隔週で行っており、その都度開発メンバ自身によってテストが行われていましたが、自動化された UI テストは存在していませんでした。 メドレーでは QA エンジニアがジョインして間もないため、やりたいこと・やるべきことは多岐にわたる中でまず何から着手するべきか検討しました。 QA プロセスの策定・改善から、新機能をリリースまで推進するための QA 活動もあり、並行して幾つか動いている中でテスト自動化をどのタイミングで、どうやってスタートするか悩みました。 バリューから考える メドレーのバリューはこの三つです。これらのバリュー視点で考えてみました。 「凡事徹底」として、リリース前のリグレッションテストをしっかり行うことは当然のこととして考えられます。 「中央突破」の視点ではどうかと考えると、やはりテストプロセスにおいて、特にリリース毎に繰り返し作業となるリグレッションテストを自動化することは王道であり、ベストプラクティスの一つだと考えられます。 そのため自動化は優先度高く進めるべきではあります。 残る一つ「未来志向」については、例えば 1~2 年後やその先を考えて、リグレッションテストが自動化されているべきか否かで言うとやはり Yes です。 また、別の観点として、現在はわずか 2 人の QA エンジニアに対して、複数のプロダクトが存在している状況で、QA エンジニアがアサインされていないプロダクトも多くあります。 私自身も昨年 10 月からアプリ・基盤チームに異動したこともあり、今後についてもまた体制が変わっていくことは十分に考えられました。 そんな状況下では、仮に UI テストを自動化した環境を用意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります（自動テストにおいて、担当が不在になったことでメンテされなくなり形骸化するケースはよくある話です）。 そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運用できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできる Magic Pod は有力な候補となりました。 これらをまとめると、以下のような結論に至りました。 テストの自動化は推進した方が良い ただし、他のメンバでもメンテしやすい環境を選定する ただし QA としてやるべき事が沢山ある中で、テスト自動化だけに専念できる状況ではありません。 そのためなるべく他タスクと並行して小コストで進められる事も重要な要素でした。 自動化された UI テストは全くない事や、他のテストの密度も鑑みると、なるべく早い段階で一定の自動テスト環境は用意したいという想いもありました。 これらの状況も踏まえ、ツールを選定・トライアルしてみた結果、Magic Pod を導入することに決めました。 Magic Pod の紹介 Magic Pod について、サービス自体の詳細は割愛しますが、端的にいうとクラウド環境かつ GUI から UI テストの実装及び実行を行うことができるツールです。 GUI で自動テストが実装できるツールだと、 Autify なども有名です。 Autify はブラウザ向けのツールですが、実装方法は Magic Pod とは少し異なり、操作をレコーディングしてテストシナリオが自動で生成される形が基本です。 一方、Magic Pod は以下のようにアプリの画面をまずキャプチャで取り込み、そこからテストで使いたい項目を選択し、シナリオにドラッグアンドドロップしていくことでテストシナリオを生成することができます。 ログインなど、複数のテストで使う部分は共通化しておきます。 テスト対象が iOS アプリであろうと、Android アプリやブラウザであろうと基本的に同じ I/F からテストの生成・メンテが出来ることは大きな強みの一つです。 また、テストで使用するフィールドの要素を選択可能なことも、状態変化に強いテストとする上での強みとなります。 例えば「調剤薬局名でさがす」というテキストフィールドに対して、そのテキストを使うのか、ID なのか、テキストフィールドなのか xpath なのかといった所です。 そのため、 テキストが頻繁に変わるような場所（例えば日付など）ではテキストを使わない アプリ内部でリファクタリングなどが動いている場合であれば逆に ID は変わる可能性が高いため、テキストで指定する UI テストを作り込む上では当然のことではありますが、上記のような工夫によりテストの成功率を上げることができます。 導入してみて トライアル中は探りながらの部分はあったものの、慣れると実装工数は非常に短期間で実装でき、トータルでも iOS で 2 3 週間（オンボーディング含む）、Android の UI テストについては実質 2 3 日で基本的なテストシナリオの自動化を行う事ができました。 その後、運用しながら落ちやすいテストの改修を行ったり、運用が安定してからは CI にも連携しています。 UI テストの運用においては定期的に実行することは非常に重要なことですが、Magic Pod の場合、Bitrise では UI 上から設定でき、Circle CI に対してもドキュメントを参照しながら比較的容易に設定できます。 実際、昨年 1 クォーター運用してみて、幾つかのクラッシュをリリース前に検知してくれました。 また、私自身、過去には XCTest における UITest( Testing Your Apps in Xcode )や Appium を使って UI テストを運用していたため、以下ではそれら他ツールとの比較も含めて紹介してみたいと思います。 実装コスト 実装コストにも初期構築と、その後のメンテコストで分かれますが、他のツールと比較して、大きく異なるのは初期構築コストだと思います。 Magic Pod については環境構築コストは非常に低コストで行うことができます（基本的な部分は 1 日あれば十分だと思います）。 またテストのレポーティングやキャプチャ機能なども標準で付いていますので、この辺りも自前で頑張る必要はありません。 次にメンテコストですが、例えば XCUITest ではまずビルドを行い、debug して各ボタンなどの要素の ID などを確認し、それらを用いてコーディングしていました。 Magic Pod では一度アプリをアップロードして、スキャンすることで画面の要素を一括で取得でき、その中から操作したい要素を選択することができます。 そのためこちらもコストはだいぶ下がります。ただ、この部分については他のツールや言語でも慣れればそう時間はかからないのでもしかしたら大差ないかもしれません。 あえて言うと debug で ID を確認する手間が楽になる、実装したテストを試して実行するのが容易（ビルド待ちの時間がない）といった辺りでしょうか。 運用コスト UI テストといえば Flaky なテスト（落ちたり落ちなかったりするテスト）に悩まされることは多いですが、運用してみると最初の内はそういったこともありましたが、現状ではほぼ起きていません。 これは Magic Pod に限った話ではありませんが、 クラウド上で実行されることで環境要因で落ちることは稀 落ちた時には自動でリトライされる ビルドも CI 上で実行している 実行はメンバが活動していない時間帯に行っている といった辺りが要因かと思います。 また Magic Pod のようなツールを使っている場合に助かる部分としては、Xcode など、UI テストに必要なツールのアップデートに対するメンテが不要ということも挙げられます。 逆に少し辛い所 ここまで Magic Pod の良い部分を多く書きましたが、逆にこのような GUI でのテストツールを使うことで少しやり辛い点も紹介しておきたいと思います。 1. テストコードのレビュー テストコード（ケース）は Magic Pod 上で管理されているため、PR レビューなどのプロセスを行うことができません。 そのため、ケースの修正に対して、反映させる前にレビューしてもらいたい場合は、テストケースをコピーしてから編集するなど少し工夫が必要になるかと思います。 現状では困ることはありませんが、複数人で同一のプロジェクトに対して運用したい場合は少し煩雑になりそうです。 2. テストコードの管理 自動テストにおいて、テスト結果に影響が出る仕様変更が入るような場合、仕様変更に対するテストコードの修正は開発と並行して用意しておき、プロダクトへの変更がマージされるタイミングで同時にテストコードの修正もマージしたいケースがあります。 Magic Pod では GitHub 上でテストコードを管理していないため、このようなケースへの対応を自動で行うことが難しく、予めテストケースを分けて用意しておき、実装がマージされた後に手動で置き換えるか、マージされた後に影響のあるテストケースを修正するといった手動でのプロセスが必要になります。 現時点で気になったのは上記の 2 点ですが、これらも今後改善されていく可能性は大いにありますし、プロセスの中での工夫次第で対処も可能かと思います。 その他 基本的に UI テストを自動化する上で気をつけるべきことやアンチパターンはどんなツールを使っても同じです。 他のツールでは難しいことが、このツールでは実現出来るということも稀で、時にはプロダクト側で手を入れる必要もあります。 どんなツールであれ、何かしら工夫すれば達成出来ることが多いため、違いが出るのは実装や運用、オンボーディング等のコスト部分が最も大きいのではないかと感じています。 周囲のサポート テスト自動化を行う場合（だけではないですが）、周囲の理解を得ることは大事な部分ですが、チームメンバは皆前向きで興味を持ってくれて進めやすい環境でした。 特に CI 連携の部分では iOS/Android の開発の方にもサポートしていただき大変助かりました。 そして Magic Pod については、数年前から運用している株式会社ノハナの武田さんにも事前に話を伺ったり、オンボーディング中は質問させていただいたりしました（ありがとうございました！）。 また Magic Pod の伊藤様には導入時からトラブルシューティングに多大なサポートをいただいています。 Circle CI に入れ込む際には、ちょっと詰まった点があり伊藤様とメールでやり取りしていたのですが、その日のうちに ドキュメント がアップされたり、 とある環境下で不明なエラーが出ていて相談した際には、ストアから CLINICS アプリをダウンロードして試していただいたり、とにかくいつも迅速かつご丁寧な対応が印象的でした。 まだ QA チームもないような少人数の状況では、こういったトラブルに対して相談でき、共に解決法を探れる方がいるという意味でも非常に心強いです。 今後について アプリの UI テストについて、改善していきたいことはまだまだ沢山あるのですが、現状でも基本的なテストは用意できているため、じっくり腰を据えて改善していきたいと考えています。 また現在はブラウザのテスト自動化を進めています。メドレーの CLINICS 以外のプロダクトの多くは Web ブラウザをプラットフォームとしているため、Web についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ https://www.medley.jp/jobs/ 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。 詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。 ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？ 申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。 我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても 便利 で 合理的 なシステムを目指して開発を行いました。今回 ChatOps の概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。 本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。 最後までお付き合いいただければ幸いです。 ChatOps とは ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です) ChatOps には以下のメリットがあると考えています。 常に立ち上げているツールという共通インターフェースである インタラクティブなコミュニケーションにつながり、スピーディである 共有しやすく、記録に残しやすい 本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。 なぜ ChatOps なのか 稟議申請においては 承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」 申請者「すいません、変更し忘れました。差戻しお願いします」 などのコミュニケーションが度々発生します。 通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。 メドレー内の業務コミュニケーションは Slack 上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。 そこで、 共通インターフェースの Chat を中心にシステム構築する＝ ChatOps を採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。 システム概要 申請 申請者は TeamSpirit 上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。 Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。 承認 申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。 承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。 承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。 後続のアクション 承認後には、 ・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する 後続の担当者へ Slack で通知する (法務押印などの)承認後タスクを作成し担当者に通知する 等、後続のアクションへつながっていく仕組みも用意しました。 システムの裏側 入力インターフェース 入力画面は、TeamSpirit で標準提供されている 稟議オブジェクト を利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。 Slack 通知 Salesforce の標準機能と Apex を用いた Script 処理を使って Slack 通知をしています。 Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。 Slack 通知までの大きな流れは以下です。 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール Apex 内で申請情報や承認者情報の取得 Slack API をコールし、Slack へ投稿 1~4 のプロセスを詳しく見ていきます。 1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更 申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。 申請時のアクションとして、 ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。 2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。 3. Apex 内で申請情報や承認者情報の取得 通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。 String ownerId = p . OwnerId ; //申請者のユーザ名を取得 String applicant = [SELECT Username FROM User WHERE Id = : ownerId ]. Username ; //承認プロセスのレコード取得 String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p . Id ORDER BY CreatedDate DESC limit 1 ]. Id ; //承認者の ID を取得 String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId ]. OriginalActorId ; 4. Slack API をコールし、Slack へ投稿 Apex が取得した情報をもとに、Slack に投稿します。 稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。 また、今回は承認者用にインタラクティブボタンを配置する必要があったので、 Block Kit を利用し、ボタン付きメッセージを作成しました。 { "text" : "hoge" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : "fuga" } }, ... { "type" : "actions" , "elements" : [ { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "承認" }, "value" : "Approve" , "style" : "primary" }, { "type" : "button" , "text" : { "type" : "plain_text" , "text" : "差戻し" }, "value" : "Reject" , "style" : "danger" } ] } ] } TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。 Slack からのアクション Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。 また承認後は、ボタンを「承認」スタンプに置き換えています。 開発を終えて 稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。 承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。 Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。 今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 最後まで読んでいただきありがとうございました。