こんにちは。インキュベーション本部の 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 についてはプロダクトを跨いだ活動も行っていければと考えています。 長くなりましたが、最後までお読みいただきありがとうございました。 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

はじめに こんにちは。コーポレートエンジニアの溝口です。 メドレーでは、今年 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 に限らず業務効率化につながるものはどんどんやっていきたいと考えています。 さいごに メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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/ 最後まで読んでいただきありがとうございました。

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 https://www.medley.jp/jobs/

はじめに はじめまして、メドレー新卒入社 2 年目の森川です。 インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、 AWS 認定資格クラウドプラクティショナー の試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。 先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。 よろしければお付き合いください。 背景と問題 弊社が運営しているプロダクトの一つ ジョブメドレー ではインフラ環境に AWS を利用しています。 監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。 CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。 ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。 原因 調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。 原因 1. 社外サービスからのアクセスでアラートが発生 CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。 これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。 インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。 以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。 インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。 原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生 CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。 しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。 以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です） 対応方法 2 つの原因に対し、それぞれ対応を行いました。 対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする 各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。 そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。 ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。 その実現のため、今回新たに作成したのが Lambda の関数です。 S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。 ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。 そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。 ただし、CloudFront ではステータスコードに 000 が入ることがあります。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。 （S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました） こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。 必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。 ここまでが Lambda の仕事となります。 各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。 対応 2. CloudWatch アラームの検知ルールを調整する 利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。 一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。 以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。 対応を終えて Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。 以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。 システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。 今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。 AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。 さいごに メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。 エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！ ここまでお付き合いいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp