はじめまして。メドレーでデザイナーをしているおおのです。わたしはメドレーには昨年（2020 年）の 6 月に入社し、現在老人ホーム・介護施設の検索サイト「 介護のほんね 」を担当しています。 介護のほんねは昨年リニューアルを行いました。今回は、そのリニューアルプロジェクトの中で自分が取り組んだこと（主にサイトトップのリニューアルについて）についてお話しようと思います。 目次 介護のほんねとは リニューアルの背景 プロジェクトについて プロジェクトとの関わりについて サイトトップの制作 プロジェクトを終えて 介護のほんねとは 介護のほんねは、納得できる老人ホーム・介護施設探しができる検索サイトです。介護のほんねには、全国にある多くの施設が掲載されています。予算やエリアなどお好みの条件で施設を検索したり、気になった施設へ見学予約や資料請求などお問い合わせができます。また社内の入居相談員による施設に関する資料送付や条件にあった施設紹介、施設見学の日程調整などのサポートにも対応しています。 リニューアルの背景 介護のほんねは 2014 年にローンチされました。しかし、長い間の運用の中で古いデザインと新しいデザインが入り混じっている部分があったり、SEO の観点での強化が必要だったり、今後の成長に向けて手直しする部分が積もり始めていました。また、2019 年に「医療につよい老人ホーム検索サイト」にコンセプトを変更しましたが、より多くの方にご利用いただくためにも、医療につよいというコンセプトからさらに一歩進み、様々な状況のお客様に向き合い、お客様が介護に対して前向きに、そして後悔のない選択ができるよう寄り添うことのできるサービスにしていきたいという思いから今回のリニューアルが始まりました。 プロジェクトについて リニューアルプロジェクトは昨年 5 月頃から始まり、外部のデザイン制作会社と連携して進められました。制作会社の方には、デザイン業務の支援をお願いしつつ、週 1〜2 回の定例で進捗報告や業務内容の確認を行っていました。 プロジェクトとの関わりについて 自分が入社したのが昨年 6 月後半だったので、デザインや開発も部分的に進んでいる状況でした。介護領域の勉強や、担当サービス、競合調査、リニューアルプロジェクトや介護のほんねのこれまでの歩みについてなどのキャッチアップと並行してリニューアルのデザインのことも考えていました。 そこで次のようなことを意識して動きました。 プロジェクトに対して 社内のメンバーといつでもコミュニケーションがとれることを活かし、外注先とも相談して自分自身も手を動かしながらデザインをブラッシュアップすること 社内に対して サービスに対するメンバーの思いを確認しつつ、これまでのサービスの歩みを尊重して動くこと 社内のデザイナーの先輩など頼れる人には頼ること サイトトップの制作 プロジェクトにジョイン後、主にサービスの顔であるサイトトップについて、アイデア出しやデザインをしました。 サイトトップにどのようなコンテンツを掲載するのか、また、お客様が介護に対して前向きに、そして後悔のない選択ができるよう寄り添いたいというサービスの思いをどのように表現すればよいか考えていきました。 掲載するコンテンツに関しては、サイトトップを誰に向けて作るのかという部分を介護施設探しが初めての人に設定し、このサイトでは施設が探せることを伝えてサービスのコア機能を全面に出しつつ、介護のほんねでの施設探しの魅力ポイントや、介護や施設探しに関するコラムや Q&A などお役立ち情報も掲載するようにしました。 ▼ リニューアル前のサイトトップ また、当時のサイトトップは上に貼ったキャプチャの通りで、落ち着いた青を基調としたクリーンで誠実そうな印象がありました。これまで築き上げてきたプロダクトのイメージや印象は、リニューアル後も受け継いで残していきたいなと思いました。 それをふまえた上で、サイトトップの新しいキャッチコピーやキービジュアルをどういうものにするのかプロジェクトのメンバーとアイデアを出しながら考えました。しかし、「どのアイデアも間違ってないけどもっといいのがありそうだな」という気持ちが拭えず、なかなか決まりませんでした。 そこで、改めて原点に帰って情報を整理するために次のことに取り組みました。 ユーザーを知る 介護のほんねが提供する価値を整理する 信頼できる情報から納得できる介護サービスと出会えることをキャッチコピーに落とす 介護のほんねの世界観を視覚的に伝えられるようなメインビジュアルの選定 ユーザーを知る まずはじめに介護のほんねのユーザーデータを 1 件 1 件見ていきました。そこにはお客様の情報や施設を探している理由など様々な情報がまとまっています。それらのデータを見ていくと、おおよそ 4 つのパターンにわけられることがわかりました。 ① 退院後の施設を探したい 転倒など何かしらの理由で入院している家族の退院期限が迫っており、退院後に在宅での介護ではなく施設にいれる必要があるケース ② 施設を移動しないといけなくなった 介護度があがったことで施設の受け入れ可能範囲から外れた場合や、施設の中でトラブルがあるなどの事情により施設を移る必要があるケース ③ 今後に備えて早めに動きたい 今すぐ介護施設に入れる必要があるわけではないものの、親が高齢でひとり暮らしをしていて不安なためまだ自分で動けるうちに施設にいれておきたいケース ④ 在宅介護では限界がきてしまった 自分自身も高齢になってきたため、仕事や家事に加えて介護の両立が難しくなってきた方が施設を探しているケース このようなお客様のデータを見ていると、事情が事情だけになるべく急いで施設を探しているものの、離れても家族が幸せに暮らせるように慎重に施設を探したい、という思いが伝わってきました。 ▼ ユーザーの大まかなパターン 介護のほんねが提供する価値を整理する 次に、ユーザーの方に対して介護のほんねができることはどういうことかを整理しました。 介護のほんねは「老人ホーム・介護施設の検索サイト」ということからもわかるように、施設を探すことができ、プロの入居相談員が施設探しから実際の入居までサポートするサービスです。また介護のほんねとしては、お客様が介護に対して前向きに、そして後悔のない施設探しができるよう寄り添いたいという思いがあります。そこで、介護のほんねの価値を機能的なものと情緒的なものにわけて整理してみました。 機能的価値＝すぐに納得できる施設が見つかること 情緒的価値＝家族のために、いろんな思いをもって施設探しをしているユーザーに寄り添うこと ユーザーデータから見えてきた「事情が事情だけになるべく急いで施設を探しているものの離れても幸せに暮らせるように慎重に施設を探したい」、そのようなユーザーに介護のほんねは寄り添って、後悔することなく納得できる施設がすぐに見つかるようにサポートしていくことを伝えたいなと思いました。 納得できる介護サービスと出会えることをキャッチコピーに落とす ユーザーやサービスの提供価値について整理をしたところで、新しいコンセプトをサイトトップのキャッチコピーにどう落とし込むのかを考えました。 そもそもサイトトップのキャッチコピーですので、前提として「サービス概要、コンセプトが端的に伝わること」は大事にしたいと思いました。サービス概要は、繰り返しになりますが老人ホーム・介護施設の検索サイトです。そして端的にサービス価値を伝えるためにも、先程述べたサービスの機能的価値である「すぐに納得できる施設がみつかること」をキャッチコピーに盛り込もうと考えました。 色々アイデアを出した結果、「老人ホームが見つかる」というサービスのコア機能に加え、介護のほんねならではの「すぐに」見つかるということや、後悔のない納得いく施設選びができるというエッセンスを入れて、最終的に「納得できる老人ホームがすぐ見つかる」というコピーになりました。 介護のほんねの世界観を視覚的に伝えられるようなメインビジュアルの選定 キャッチコピーはサービスの機能やできることをわかりやすく伝えるものにしたため、キービジュアルは先程述べたサービスの情緒的価値のエッセンスをいれたいと思いました。それを踏まえ、いろんな思いを持った相談者の方に寄り添い、ご家族が施設に入居されてから始まる新しい生活を前向きに捉えられるようなビジュアルにしようと思いました。 キービジュアルの選定にあたり、チーム内で意見を集めながら、色々アイデアが出ました。入居後のイメージやサービス概要が伝わりやすい老人ホームの屋内風景の写真、入居後の楽しい生活が期待できそうな施設のスタッフと入居者の笑顔の写真や、サービスの寄り添うスタンスを抽象的に伝える手を握り合うような写真など、たくさんの写真をあてはめて検討を繰り返しました。 ▼ イメージ選定 車椅子が写りこんでいると、自立度が高い状態で施設を探している方（※介護の必要がない元気な方向けの施設もあり、元気なうちから施設に入られる方もいらっしゃいます）にとって自分が使っていいサービスではないのかとマイナスなイメージにならないか？ 施設スタッフと入居者が笑顔で写っている人が写ったモデル風の綺麗な写真だと素材感が出すぎて嘘っぽくならないか？ 手を包みこむなどモチーフが抽象的すぎるとかえって何も伝わらないのではないか？ 写真を選ぶ中でチーム内でも相談しながら、小さな違和感をひとつずつつぶしていきました。そして、最終的に下のようなキービジュアルになりました。 ▼ リニューアル前とリニューアル後 これからの新しい生活がポジティブなものに捉えられるような、スタッフと笑顔で生活する入居者が写っており、背景に程よく雑多感が残る素材感を抑えた写真を選びました。写真に写っているのは入居者と入居者に寄り添うスタッフですが、介護のほんねも同じように、施設探しをしている方に寄り添う姿勢がこの写真から間接的に伝われば嬉しいなと思っています。 プロジェクトを終えて プロジェクトは一段落しましたが、スタートラインにたったところなので、まだまだ追加したい機能や磨き込みたい部分も山積みだなと感じています。 今回、自分のデザインに納得感をだすためにサービスや介護の知識、チームのメンバーが考えていることへの理解を深めながら並行してリニューアルのデザインを手掛けたことは、とてもやりがいのあるものでした。 また、リニューアルをきっかけに改めてサービスの価値や目指したい世界を整理できたのはとても良かったです。これからも介護のほんねの目指したい姿を見据えながら、より多くの方につかってもらえるようなサービスにしていきたいと思っています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 https://www.medley.jp/jobs/

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。 私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。 CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。 この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。 「CLINICS の QA」とは？ さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。 入社前にも、何度も なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ QA エンジニアにどんな役割を期待しているのか？ といった点を開発チームの上長と話し合いました。 なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？ 私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。 現場の思いとして、以下の点が挙げられていました。 プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい QA エンジニアにどんな役割を期待しているのか？ 描いている組織体制像としては以下のようなお話でした。 QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。 「QA エンジニア」「テストエンジニア」「SET/SWET」 ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。 一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『 テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。 私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。 CLINICS のありたい「QA」の姿 上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。 （現状行っている）テストの改善 プロセス改善 知識の底上げ それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。 「テストの改善」 現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。 そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。 私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。 「プロセス改善」 こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。 種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。 それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。 また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「 SaPID 」という改善手法を参考にしています。 SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。 誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。 コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として 自分と身の周りに役に立つ状況をつくる 世間に認知されるプロダクトをつくる というような定義をつくることができました。 「知識の底上げ」 CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。 普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。 まずは教科書的な内容を CLINICS チームの Confluence に書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。 『 ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』 『 はじめて学ぶソフトウェアのテスト技法 』 『 ソフトウェアテスト技法練習帳 知識を経験に変える 40 問 』 一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。 （再）「CLINICS の QA」とは？ 冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。 テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。 最初の問いに戻ります。 「CLINICS の QA」とは何か？ 品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。 「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。 品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。 最後までお読みいただきありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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 にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！ 最後までお読みいただきありがとうございました。 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

事業本部 プロダクト開発室のエンジニアの中畑です。 オンライン診療・服薬指導・クラウド診療支援システム 「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/