MEDLEY Developer Portal

SREエンジニア／医療プラットフォーム本部 | 株式会社メドレー

SREエンジニア／医療プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

CLINICSの信頼性を守るDatadog 導入・活用事例(株式会社メドレー)

※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

注釈

*1: CLINICSでのDatadog活用事例については、こちらの記事を参照ください。

株式会社メドレーのDatadogのレビューです。導入に至った背景や導入検討時の悩み、実際に導入してから感じたDatadogのメリットと課題感を導入効果とともにレビューしていただきました。

findy-tools.io

*2: 具体的なデータは、全てダミーデータを使用しています。

*3: AI推進グループは、「AIで『医師』と『エンジニア』の生産性を最大化する」というミッションのもとで、プロダクトへのAI機能導入と開発者の生産性向上に取り組む組織です。詳しく知りたい方は、以下を参照ください。

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

www.youtube.com

「ゼロ距離医療」実現へ。医師とエンジニアの生産性最大化にAIで挑戦｜メドレー公式note

皆さん、こんにちは！株式会社メドレーでDevRelをしている重田です。メドレーの開発組織で働く社員を「入社エントリーブログ」の形式でご紹介します🎉 今月ご紹介するのはAI推進グループエンジニアの大塚さんです。ぜひご一読いただき、メドレーに興味を持っていただけたら嬉しいです！まず初めに自己紹介をお願いします大塚と申します。現在は医療プラットフォーム本部の医科診療所プロダクト開発室 AI推進グループでマネジャーを務めており、主にクラウド診療支援システム「CLINICS」に携わっています。 AI推進グループとは？ AI推進グループは、「AI で ”医師”と”エンジニア”

note.com

Workday Rising 2025 参加レポート - 海外カンファレンスに参加しました！

Tue, 24 Feb 2026 00:00:00 GMT

はじめまして！コーポレートIT室の種田と申します。コーポレートIT室では全従業員が利用するデバイス、ネットワークインフラ、 SaaS といった IT 全般を統括しています。

メドレーでは自社開発のプロダクト、M&Aで取得したプロダクト、またローカルおよびグローバルのプロダクトを、会社や国を越えて統一的に管理・運用することを目指す「Global One」という思想を掲げています。プロセスやシステムにおいても、この思想に基づき、個別最適に陥ることなく、グローバルに共通して適用できる標準的なIT基盤を構築することが求められています。

コーポレートITでシステムを選定するときも、「グローバルで標準的に活用できること」が観点のひとつとなっています。Google Workspace、Slack、Confluence、ServiceNow、GitHubといった、各領域でデファクトスタンダードとなっているものを導入・活用しています。

メドレーの人事基幹システムは、2022年からグローバル共通で「Workday」を利用しています。私はコーポレートITとしてWorkdayの導入プロジェクトに参加し、現在は運用や新規機能の導入検討などを担当しています。昨年の9/15-18に、サンフランシスコで開催されたWorkdayの年次カンファレンス「Workday Rising 2025」に初めて参加してきました。開催から少し日数が経過していますが、当日の熱気あふれる会場の様子や海外カンファレンス初参加の感想をお届けします。

会場の様子

会場はサンフランシスコ Moscone Centerです。合計で500以上のセッションがありました。会場移動とインプットの繰り返しでかなりタフな4日間を過ごしました（最終日が終わった後、ばっちり風邪を引きました）事前に参加セッションの計画を立てていたのですが、期間中に発表された新機能に関する追加セッションも多くありました。Workdayの機能ごとのブースや協賛企業のブースも多く、4日間ではとても回りきれません！ほとんどのセッションは後から動画が公開されるので、日程後半は会場でしか体験できないハンズオンセッションやブースを中心に参加していました。

おもしろかったセッション・ブース

Keynote: The Workday Platform: Transforming Work with Agentic AI

AI関連企業の買収やAIを中心とした新機能の発表など、初めて聞くことばかりでとてもわくわくしました。WorkdayでのAIエージェント開発・管理・実行やWorkday外のさまざまなデータとの連携を加速させる動きを感じました。発表された新機能の中で、Workdayのデータをゼロデータコピーで外部システムと連携できる「Workday Data Cloud」が個人的にとても気になりました。セッションの中でも、Workdayは人事基幹システムから「エンタープライズAIプラットフォーム」へ位置づけを変化していくと話されていました。

Equipping You to Manage Workday Learning: A Hands-On Lab

Workdayの学習管理システム(LMS)である「Workday Learning」の研修コンテンツ作成をハンズオンで学べるセッションがありました。ひとり1台パソコンが準備されており、ガイドに沿って手を動かしていきます。（意外と簡単に実装できそうでした！）Workday Learningのハンズオンは日本では開催されないため、良い経験になりました。

Workdayブース

Workdayを開発しているエンジニアの方がブースにいたので、新機能のデモだけではなく、細かな質問にも対応してもらえるのがとてもよかったです！（ただし、私は英語ができないので他の方が質問しているのを聞いて理解するにとどまりました…もっと話せるようになりたい）

協賛企業ブース

協賛企業ブースには、日本ではあまり知られていないHRTechサービスのブースが多かったです。ここでもAI関連のサービスが多かった印象です。気になったサービスがいくつかあったのでご紹介します！

TechWolf

TechWolf | The intelligence to act with confidence

TechWolf is the foundational data layer for workforce transformation in large enterprises. For the first time ever, you can use accurate skill data to hire smarter, improve learning, fix internal mobility and plan your workforce with confidence.

www.techwolf.ai

Workdayのスキル管理システムとGoogle Workspace / Slack / Jira / Confluenceを連携することで、自分のスキルプロファイルを生成してくれるSaaSがありました。日々の業務でアウトプットしたデータから自分のスキルを提案されると、自身で気づいていない意外なスキルを発見できる可能性もあって良さそうです！

eduMe

Training that's built for your frontline

eduMe is the AI-first frontline training platform that slots invisibly into your existing tools - helping you get better training to your frontline, faster.

www.edume.com

TikTokのような短時間の動画で隙間時間に学べる、デスクレスワーカーをターゲットとした研修プラットフォームです。コンテンツもPDFなどの資料からAIが自動生成してくれるため、管理者側にもメリットがあって良いと思いました。

まとめ

全体を通しての感想

グローバルシステムの年次カンファレンスへの参加は私にとって初めての経験でした。規模・セッション数ともに桁違いですし、自分が興味があることを開発エンジニアに直接聞くことができるのも年次カンファレンスならではの貴重な機会でした。また、日本のWorkdayユーザー企業様とも交流する機会が多くありました。ユースケースやお悩みごとなど情報交換をたくさんすることができました。

（おまけ）最終日前日にはサンフランシスコ・ジャイアンツの本拠地であるオラクル・パークを貸し切ったパーティが開催されました。グラウンドやベンチにも入ることができたのがうれしかったです！サンフランシスコに到着した日にドジャース戦を見に行っていたので、大谷選手と同じ場所に立てた…！と思ってしまいました。

Workdayの今後の活用について

セッションでは、AIエージェントを含むアプリ開発やエージェントのセキュアな管理、外部とのデータ連携といった、エンジニア向けのトピックが多かったことが印象的でした。 AIエージェントとのやりとりで業務が進められていく世界観も提示されていました。Workdayでの各種申請・承認がAIエージェントとのやりとりだけで完結できると、従業員にとってうれしい未来だなと思っています。今後のアップデートも継続してキャッチアップし、便利な機能は積極的に展開していきたいです。また、Workdayのタレントマネジメント分野ではAIを使った機能拡充が多く予定されています。従業員のタレント情報（スキル、職歴、興味など）のWorkdayへの集約を進め、新機能を活用できる状態に整えていきたいと考えています。

おわりに

Workday Risingへの参加を通して、日本開催のイベントでは得られない多くのインプットを得ることができました。参加する機会をいただけたことを本当に感謝しています。また、このインプットを無駄にせず、今後のメドレーの人事戦略にシステムを通じて貢献していきたいと思ってます。

現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。

株式会社メドレー

株式会社メドレーです。| HRMOS

「医療ヘルスケアの未来をつくる」というミッションのもと、様々な医療課題を解決するためのデジタル活用を推進する【株式会社メドレー】の公式noteです。https://www.medley.jp/

※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

メドレー公式note｜note

note.com

ジョブメドレーアカデミーにおけるLLM活用事例 — Dify導入・解説自動生成・動画翻訳の実装

Fri, 30 Jan 2026 08:00:47 GMT

医療業界の視点から解説！AWSの国内クロスリージョン推論がもたらす恩恵

Tue, 16 Dec 2025 06:18:16 GMT

はじめに

この記事は Medley（メドレー） Advent Calendar 2025 16日目の記事です。

こんにちは。医療プラットフォーム本部病院プロダクト統括部開発戦略室の竹本です。re:Invent 2025 が閉幕し、今年も残すところあと僅かとなりました。

今回は Amazon Bedrock に関する記事を書いてみたいと思います。

Bedrockで国内限定のクロスリージョン推論が可能に！

少し前のAWSアップデートですが、 2025年9月29日に Amazon Bedrock で Claude Sonnet 4.5 が利用可能になると同時に、Claude Sonnet 4.5で日本国内に限定したクロスリージョン推論機能の提供が開始されました。この機能の特徴については、以下の Amazon Web Services ブログの記事に詳細が記載されています。

Amazon Web Services ブログ | Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に！日本国内クロスリージョン推論のご紹介

この機能を利用すると、生成 AI の推論リクエストを日本国内の東京・大阪リージョンのみに限定して分散ルーティングさせることができます。また記事の中で日本国内クロスリージョン推論を選択すべきケースのひとつとして医療業界の例が挙げられており、弊社もその例外ではありません。

しかし金融や医療の業界でも積極的にパブリッククラウドが活用されている近年において、なぜ国内にリクエストを閉じなければならないのかピンと来ない方もいらっしゃるかもしれません。

そこで医療系IT企業の視点から、このアップデートが持つ意義について徹底的に解説したいと思います。

本記事に関する免責事項

本記事の中で AWSをはじめ各社が公開しているサービスの情報や各省が公開しているガイドラインの内容について言及していますが、それぞれ 2025年12月時点の情報をもとに執筆しております。いずれも内容が改訂される可能性がありますので、最新の情報につきましては各機関より正式に公開されている情報をもとにご判断いただくようお願いいたします。

きっかけ

まず、本記事を書くことになったきっかけからお伝えします。

私が所属する開発戦略室では当時、一部のシステムで Amazon Bedrock で Claude 3.5 Sonnet のモデル ( anthropic.claude-3-5-sonnet-20240620-v1:0 ) が利用されていました。
2025年12月時点では Claude 3.5 Sonnet は既に Anthropic社としてはEOSを迎えてしまったモデルであり (1) 、Amazon Bedrock ではレガシーモデルと呼ばれる扱いとして 2026年3月1日までに別のモデルへ移行することが促されています。(2)

そこで、冒頭に記載した日本国内に閉じたクロスリージョン推論機能の利用が果たして必須となるか否かをこの機会に明らかにすることにしました。

(1) 参考： Anthropic | Claude docs - モデルの廃止予定
(2) 参考： AWS | Amazon Bedrock - モデルのライフサイクル

クロスリージョン推論の基本情報

まずはクロスリージョン推論についておさらいをします。

クロスリージョン推論とは、リージョンごとの混雑状況に応じてAWSが基盤モデルを利用可能なリージョンのエンドポイントへ自動的に推論リクエストをルーティングしてくれる機能です。リージョン単位で基盤モデルを呼び出す従来の方式と比較すると、リクエスト数のクォータ (上限) が広がりスロットリングエラーの発生を回避しやすくなります。

Amazon Bedrock モデル推論 b.実践編【Amazon Bedrock Series #02b】より引用

Claude Sonnetでは、Claude 3.5 Sonnet以降のモデルはすべてクロスリージョン推論が実行される推論プロファイルのみ提供されています。

ところが、クロスリージョン推論はユーザーが利用するリージョンを選択することはできません。 利用する推論プロファイルごとに既定のいずれかのリージョンへ送信される仕様であり、冒頭のアップデートが発表されるまではいずれも日本国外にあるリージョンが含まれておりました。(3)

詳細は次章で解説しますが、医療情報システムでは日本国外にある情報機器を使えないことが原則です。では果たして医療情報システムは海外の優れた最新AIを利用することが困難なのでしょうか。

(3) 参考情報：AWS | Amazon Bedrock - 推論プロファイルでサポートされているリージョンとモデル

3省2ガイドラインの存在

医療情報を取り扱うシステムにおいて、避けて通れないのがいわゆる 3省2ガイドラインです。3省2ガイドラインとは、厚生労働省・総務省・経済産業省が策定した、医療情報を安全に取り扱うための2つの指針の総称です。

病院等の医療機関だけでなく、弊社のように医療情報を扱うシステムを提供する事業者もまたこれらのガイドラインに記載された安全管理措置やセキュリティに対する対策を講じることが求められます。

そしてこのガイドラインに含まれる項目のひとつに、情報を格納する情報機器は日本国内法の適用が及ぶ場所に設置すること が求められています。

厚生労働省 | 医療情報システムの安全管理に関するガイドライン第 6.0 版企画管理編 ─ 7章より抜粋

では、いかなる場合も日本国外のサービスを利用できないのでしょうか。
この疑問点を考える上で、ポイントが大きく分けると 2 点あります。

1. 送信された推論リクエストは、Amazon Bedrock内で情報機器に情報が格納・保存されるのか
2. もし Amazon Bedrock で情報が保存されないならば日本国外にリクエストして良いのか

1. Amazon Bedrock は “情報を格納“ するのか

結論として、Amazon Bedrock では入出力するデータが保存・記録されないことが公式ドキュメントに明記されており (4) 、クロスリージョン推論であってもこの方針は変わりません。

(4) 参考：AWS | Amazon Bedrock - データ保護

▼ 該当箇所を抜粋

プロンプトおよび AI のレスポンスを保存またはログに記録することはありません。

この点については、Amazon Bedrockを既に利用されている方によく知られていることかと思います。

2 . それなら国外サーバーを利用してもよいのか

では医療情報を取り扱うシステムにおいて、グローバルクロスリージョン推論のように日本国外のサーバーに対してリクエストを送信してもよいのでしょうか。
これについては、厚生労働省が公開している別の資料の中に手がかりがありました。

厚生労働省 | 「医療情報システムの安全管理に関するガイドライン第 6.0 版」に関するＱ＆Ａ ─ P.45 より抜粋

この資料によると、以下の条件に該当する場合には国内法の適用を受けていないサーバーを利用可能であると記載されています。

▼ 該当箇所を抜粋

医療情報が保存されないことが、契約等において担保されている場合は国内法の適用を受けていないサーバを利用可能

AWSドキュメント = 契約…？

ここでまた新たな疑問が生まれます。
AWSドキュメントに明記されていることはこれに該当するのでしょうか。

結論として、「契約等において担保されている」に相当するとまでは言えない でしょう。

なぜなら AWSドキュメントは、個別具体的な当事者間の合意内容をもとに作成した契約書とは性質が大きく異なるからです。AWSドキュメントはサービスアップデートの中で AWS社によって内容が一方的に変更されることもあり、サービスユーザーである我々はこれを受け入れる or 利用を停止するのいずれかしか選択肢がありません。

したがって、グローバルクロスリージョン推論の利用は明確に禁止されているとまでは言えないものの、医療情報システムのサービス提供者としては日本国内に限定したクロスリージョン推論を採用する方が無難であると考えられます。

今回の結論

以上のことから冒頭のサービスアップデートは、多くの推論リクエストを処理可能になる・ガイドラインを確実に準拠できる・最新のモデルを利用できると多くのメリットを含む内容でした。

入出力トークン数が大きい AIワークロードの場合、料金が 10% 上乗せになってしまう点は痛手になりますが、プロダクトの付加価値とコンプライアンス要件の両立を可能にする選択肢が生まれたことは大きな一歩となりました。

多くのイノベーションが安全性とトレードオフの関係になっている中で、国内の厳格な安全基準を守りつつ最高水準のベンチマークを誇る高性能モデルを安定したインフラで利用できるようになる。
そんな選択肢を提供してくれた事こそ、医療業界にもたらす一番の恩恵と言えるでしょう。

最後に

本記事では、医療業界における日本国内に閉じたクロスリージョン推論の有用性について解説させていただきました。

私が所属する医療プラットフォーム本部では、医師の偏在や医療従事者の人材不足が引き起こす長時間労働という課題に対し生成 AI のテクノロジーを用いた業務効率化によって、医療従事者の負担を軽減する試みに取り組んでいます。

メドレー、病院向け電子カルテ「MALL」で医療文書作成をAIで支援する新機能のパイロット版を提供開始

このような取り組みの陰には、厳格なルールの中で技術選定を行うエンジニアの苦労と「医療ヘルスケアの未来をつくる」弊社ならではのやりがいがあることを、より多くの人に知ってもらえればと願っております。

本記事がどなたかの参考になれば幸いです。

次回予告

Medley（メドレー） Advent Calendar 2025 もいよいよ後半戦！
次回 17 日目の担当は QA エンジニアの @daishu さんです！🎉 明日も是非お楽しみに〜！！

We’re hiring!

メドレーでは、「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！

株式会社メドレー

株式会社メドレーです。| HRMOS

プロダクトマネージャーカンファレンス 2025 | pmconf 2025

※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

pmconf 2025 参加レポート - ゴールドスポンサーとして協賛しました！

Fri, 12 Dec 2025 00:00:00 GMT

こんにちは。人材プラットフォーム本部でプロダクトマネージャーをやっている渥美です。メドレーは2025年12月4日に開催された「pmconf 2025」に、ゴールドスポンサーとして協賛しました。

プロダクトマネージャー⼀⼈ひとりの成⻑と挑戦が、新たな未来を⽣み出す。pmconfは、それを信じています。 pmconf 2025は、プロダクトマネージャーの成⻑意欲と挑戦への熱量がぶつかり合う場へと進化します。登壇者は、より良い未来を切り拓く挑戦のリアルを語る。参加者は、切磋琢磨の渦に⾶び込み、挑戦のエネルギーを⾼める。スポンサーは、この挑戦の場を⽀え、熱狂を共に創り上げる。そして、ここで⽣まれる熱量が、未来を動かす原動⼒となる。

2025.pmconf.jp

会場の様子

年に一度開催される日本最大のPMイベント「pmconf」は、2016年に始まり今年で10回目。東京会場では2つのホールと5つのルームに分かれて約30本ものトークセッションや、OST、PMフィッシュボウルなどの実践セッションが行われました。

弊社ブースの様子

ブースでは、プロダクトマネージャーとしての強みを4つのタイプに診断する「PMタイプ診断」を行い、参加していただいた方にはノベルティをお渡ししました。

新しいロゴのステッカーも初お披露目です！

医療にちなんで、総合診療医・臨床研究医・外科医・看護師長の4つのタイプに診断。

開場時間からたくさんの方にお越しいただき、メドレーのプロダクトにも多くの関心をいただきました。

実践型セッションの様子

トークセッションと同じく盛り上がりを見せたのは、OST（Open Space Technology）。セッション開始時に話したいテーマを紙に書き出し、一緒に議論する仲間に呼びかけます。参加者はそのテーマを選んで、セッションに加わります。

皆さん真剣に議論されていて熱気がすごかったです！弊社のwatanabeも参加。

PMフィッシュボウルでは、「そもそもプロダクトマネージャーって必要？」という核心的なテーマのもと、白熱した議論が行われました。自社でもプロダクト横断でやってみると面白いかも？

戦利品

狙っていたスタンプラリーのパーカーは間に合わなかったけど、ロゴ入りタンブラーをゲットできました。 RevenueCatさんの靴下は来場したときから一目惚れだったので当たって嬉しかったです！（猫ちゃんモチーフで全てがかわいかった）

最後に

初めてのブース参加でしたが、とても楽しかったです。次回はもっとセッションや交流を楽しみたいと思います。

（開場後まだ元気な私。すぐに軟弱な足腰が悲鳴をあげ、マツキヨで湿布を買いました）

メドレーはこれからも、医療ヘルスケアの未来を作るために、様々なプロダクト・サービスを開発し提供していきます。

現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。

株式会社メドレー求人一覧

我が家のNATゲートウェイを覗いてみた

Thu, 04 Dec 2025 06:18:15 GMT

はじめに

この記事は Medley（メドレー） Advent Calendar 2025 4日目の記事です。

医療プラットフォーム本部プラットフォーム開発室 SRE グループの山田です。医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。

本記事では、VPCフローログ/Amazon Athena/ネットワークACLを用いてNATゲートウェイへの通信内容を調査する方法について紹介します。タイトルにもありますが、かなり力技になりますので本番環境で実施は控えてください。

背景

CLINICSには外部サービスと連携して機能を提供するAPIが多く存在します。また、システム間通信にもNATゲートウェイを経由して通信することがあるため、サービスの成長に伴いECS Taskのスケールアウトによって、NATゲートウェイを経由する通信量は着実に増えていきます。

日常の運用では問題が見えにくくても、万が一NATゲートウェイで障害が発生してしまった場合、その影響は広範囲に及び、サービスの復旧に時間を要する可能性があります。

特に懸念される障害シナリオの一つが、トラフィック集中による「ポート割り当てエラーの増加」です。これにより、NATゲートウェイへの新規接続が失敗し、通信が遮断される可能性があります。

参考：Amazon VPC の NATゲートウェイで発生する「エラーポートアロケーション」エラーを解決するにはどうすればよいですか？

こうしたリスクを未然に防ぐためには、「NATゲートウェイの冗長化」や、「NATゲートウェイ経由の通信が必須か」を見直し、可能な通信はVPCエンドポイントへ移行させるといったアーキテクチャの最適化が求められます。

CLINICSでは、この課題への第一歩として、現状のNATゲートウェイの利用実態を詳細に把握する調査を実施しました。具体的には、NATゲートウェイを介して通信しているシステムと通信先のサービスを洗い出すことに取り組みました。

次章からは、この調査で得られた具体的な知見と、それに基づきどのようにインフラアーキテクチャの改善を進めたのかを紹介します。

調査方法

ここからは、NATゲートウェイ経由でのトラフィックを調査し、CLINICSが通信している外部のサービスを特定する方法について紹介します。大枠、以下のような流れで調査を進めていきました。

VPCフローログを有効化
Athena からVPCフローログを解析
通信先のAWSサービスを特定
通信先のAWS以外のサービスを特定

VPCフローログを有効化

VPCフローログはVPC内部の通信内容をキャプチャする機能です。もちろん、「VPC内部の通信」にはNATゲートウェイの通信も含まれます。

ログはAmazon CloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehoseへ保存することができますが、本記事ではS3へ保存する想定で解説していきます。

ログレコードの形式

VPCフローログのフォーマットはデフォルト設定でもある程度調査が可能ですが、調査をする上で追加で以下のフィールドを追加しました。

tcp-flags: TCP接続の状態（SYN、ACK、FINなど）を確認するために使用します。NATゲートウェイはアイドルタイムアウト時にRSTパケットを送信するため、調査目的で追加しました
pkt-srcaddr: NAT変換前の元の送信元IPアドレス。NATゲートウェイ経由の通信では、送信元を特定するために変換前のIPを追跡するために使用します
pkt-dstaddr: NAT変換前の元の送信先IPアドレス。実際に通信しようとしている外部サービスのIPを特定するために使用します
pkt-src-aws-service: 送信元IPがAWSサービスのIP範囲に該当する場合、そのサービス名が記録されます
pkt-dst-aws-service: 送信先IPがAWSサービスのIP範囲に該当する場合、そのサービス名が記録されます。EC2やS3など、どのAWSサービスと通信しているかを判別できます
traffic-path: トラフィックがどの経路を通っているかを確認できます。NATゲートウェイ経由かどうかの判定に役立ちます

参考: フローログレコード

フローログに追加できる情報はかなり種類があり定期的に更新されるので、設定するときは用途に合わせたフォーマットになるようドキュメントを一読することをお勧めします。また、既存のフローログのフォーマットを変更することはできないので注意が必要です。

VPCフローログを分析するための基盤を作成

VPCフローログを有効化したので、S3にVPC内のトラフィックに関する情報が保存されるようになりました。次に、これらのログを集計して通信内容に関するより詳細な情報を取得できるようにするためにAthenaテーブルを用意します。

Athena テーブル作成

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
  flowlog_version INT,
  account_id STRING,
  interface_id STRING,
  srcaddr STRING,
  dstaddr STRING,
  srcport INT,
  dstport INT,
  protocol INT,
  packets BIGINT,
  bytes BIGINT,
  start_time BIGINT,
  end_time BIGINT,
  traffic_action STRING,
  log_status STRING,
  tcp_flags INT,
  pkt_srcaddr STRING,
  pkt_dstaddr STRING,
  pkt_src_aws_service STRING,
  pkt_dst_aws_service STRING,
  traffic_path INT
)
PARTITIONED BY (dt STRING)
ROW FORMAT DELIMITED
  FIELDS TERMINATED BY ' '
LOCATION 's3://bucket-name/AWSLogs/XXXXXXXXXXXX/vpcflowlogs/region'
TBLPROPERTIES (
  "skip.header.line.count" = "1"
);

作成したテーブルに対してパーティションを追加して、データを取り込ませたら準備完了です。

ALTER TABLE vpc_flow_logs
ADD PARTITION (dt='20YY-MM-DD')
LOCATION 's3://bucket-name/AWSLogs/XXXXXXXXXXXX/vpcflowlogs/region/20YY/MM/DD/';

通信対象の特定

実際にクエリを実行してNATゲートウェイを介してどこと通信しているかを調査します。

下記のクエリでは、特定の日付でNATゲートウェイを介した通信回数を通信元と通信先のIPで集計しています。

SELECT pkt_srcaddr, srcaddr, dstaddr, pkt_dstaddr, dstport, pkt_dst_aws_service, COUNT(1) AS c
FROM vpc_flow_logs
WHERE srcaddr LIKE 'x.x.%' -- VPC CIDR
  AND dstaddr IN ('y.y.y.y', 'z.z.z.z') -- NAT Gateway IP
  AND dt = '20YY-MM-DD'
GROUP BY pkt_srcaddr, srcaddr, dstaddr, pkt_dstaddr, dstport, pkt_dst_aws_service
ORDER BY c DESC;

すると以下のような結果が返ってきます。（もちろんダミーデータです。）

#	pkt_srcaddr	srcaddr	dstaddr	pkt_dstaddr	dstport	pkt_dst_aws_service	c
1	x.x.a.a	x.x.a.a	y.y.y.y	a.a.a.a	443	EC2	1600
2	x.x.b.b	x.x.b.b	z.z.z.z	b.b.b.b	443	AMAZON	1500
3	x.x.c.c	x.x.c.c	y.y.y.y	c.c.c.c	443	-	700
4	x.x.d.d	x.x.d.d	y.y.y.y	d.d.d.d	443	-	400

通信先のAWSサービスを特定

通信先がAWSサービスの場合は、pkt_dst_aws_service を確認することで対象を特定することができます。

フローログに記載されるpkt-src-aws-serviceとpkt-dst-aws-serviceはEC2のように具体的なAWSサービスが記載されていることもあれば、AMAZONのようにどのエンドポイントと通信しているかわからない場合もあります。そのような場合は、AWS Route53 リゾルバーのクエリログ記録を確認することで特定できたりします。

参考: リゾルバーでのクエリのログ記録

また、EC2ダッシュボードから確認できるネットワークインターフェース一覧からパブリックIPで検索することで通信先のリソースを特定することも可能です。

通信先のAWS以外のサービスを特定

基本的にIPアドレスからどのサービスなのかを完全に特定することはできません。

逆引きDNS（PTRレコード）が設定されている場合はdigを使ったりwhoisでIP所有者の特定はできるかもしれませんが、外部サービスがIPアドレスの範囲を公開していなければどのサービスかを絞り込むのは難しいです。

では、AWS以外のサービスをどのように特定すれば良いでしょうか？

A. 「特定のIPアドレスへの通信を遮断すれば、システムアラートからどのサービスとの通信が確立できなかったか確認できるのでは？」

以下のような仕組みを考えてみました。

CLINICS APIが外部サービス（IPがx.x.x.x）へリクエストを送信する
特定のIPアドレスへの通信を遮断する
外部サービスへのリクエストがタイムアウトすることでアラートが発報される

筋が良くはないかもしれませんがやってみました。冒頭にも記載しましたが、本番環境での実施は控えてください。

特定のIPアドレスへの通信を遮断する方法

特定のIPアドレスへの通信を遮断する手段として「ネットワークアクセスコントロールリスト（ネットワークACL）」があります。ネットワークACLはサブネットレベルで特定のトラフィックを許可/拒否することができる仕組みです。

参考：ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する

実際にネットワークACLを作成してみます。先ほど実行したクエリ結果をもとにブロックしたいIPアドレスをアウトバウンドルールを設定していきます。

作成したネットワークACLをプライベートサブネットに関連付ければ、NATゲートウェイを介した通信が遮断されるようになります。

全てのIPアドレスをしらみつぶしに検証していくとキリがないので、トラフィックが特に多いものに絞って調査を進めました。

調査結果

上述した方法を用いて、NATゲートウェイを介して通信する外部サービスの特定ができました。特にトラフィック量が多く、NATゲートウェイを経由しなくても良いサービスは以下のようになりました。

Amazon Kinesis
Datadog

NATゲートウェイを通らないアーキテクチャへ変更

ここからは、NATゲートウェイ経由で通信していたトラフィックをVPCエンドポイントへ逃していきます。 NATゲートウェイとVPCエンドポイントどちらを採用するかを検討する場合、損益分岐点を計算する必要がありますが本記事では割愛します。

Amazon Kinesis

Amazon Kinesis はインターフェイスVPCエンドポイントがサポートされているため、VPCエンドポイントを作成して向き先を変えてあげます。

参考: AWS のサービスと統合する AWS PrivateLink

Datadog

DatadogはPrivateLinkを提供しているため、これを採用します。

参考: AWS PrivateLink を介して Datadog に接続する

後になって知りましたが、DatadogさんはIPアドレスの範囲を公開されていたんですね。以下から確認できました。

curl -X GET "https://ip-ranges.datadoghq.com/" -H "Accept: application/json"

参考: IP 範囲

効果検証

VPCエンドポイントやPrivateLinkへの移行が完了した後、実際にNATゲートウェイを経由するトラフィック量が削減されたかを確認しました。

NATゲートウェイ経由のトラフィック削減

VPCエンドポイントやPrivateLinkへの移行後、NATゲートウェイを経由するトラフィック量が大幅に削減されました。

VPCエンドポイントへトラフィックが流れた後のNATゲートウェイの送信先へのバイト数の変化

具体的には、移行前と比較して以下のような結果が得られました。

送信パケット数の削減: NATゲートウェイを経由するパケット数が約50%削減
データ量の削減: NATゲートウェイを経由するデータ量が約82%削減

まとめ

本記事では、VPCフローログとAmazon Athenaを用いてNATゲートウェイを経由する通信内容を分析し、ネットワークACLを活用した力技で通信先のサービスを特定する方法を紹介しました。

調査の結果、NATゲートウェイを経由する主な通信先としてAmazon KinesisとDatadogが特定できました。これらをVPCエンドポイントやPrivateLinkに移行することで、NATゲートウェイを経由するトラフィック量を削減することができました。

NATゲートウェイのポート割り当てエラーなどのリスクを事前に回避するためには、定期的に通信内容を見直し、可能な限りVPCエンドポイントやPrivateLinkを活用したアーキテクチャに最適化していくことが重要です。ただし、VPCエンドポイントやPrivateLinkを導入することでかえってインフラコストが増加する可能性もあるため、アーキテクチャの最適化によるリスク低減とインフラコストのバランスを慎重に検討する必要があります。本記事が、同様の課題に取り組む方々の参考になれば幸いです。

We’re hiring!

株式会社メドレーエンジニアの求人一覧

株式会社メドレーエンジニアの求人一覧です。| HRMOS

Flutterエンジニア／人材プラットフォーム本部 | 株式会社メドレー

※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

FlutterKaigi 2025 参加レポート - Bronzeスポンサーとして協賛しました！

Tue, 18 Nov 2025 01:00:00 GMT

こんにちは、人材プラットフォーム本部CTO室の奥澤です。株式会社メドレーの人材プラットフォーム本部では現在、Flutterを用いて複数のモバイルアプリを開発しています。Flutterに興味を持つメンバーが増え、注目度も高まっています

2025年11月13日、日本最大級のカンファレンス「FlutterKaigi 2025」が開催されました。FlutterKaigiは有志により開催され、メドレーからも複数のメンバーが参加しています。メドレーでは、Bronzeスポンサーとして協賛しており、技術カンファレンスへ継続的に協賛を通じて、技術コミュニティの支援を行っています。

本記事では、FlutterKaigi 2025への参加レポートを報告します。

会場の様子

FlutterKaigi 2025は、大手町プレイスホール＆カンファレンスで開催されました。会場に着くと、巨大なDashちゃんに迎えられました。FlutterKaigiを盛り上げるぞという気持ちが高まります。また、写真では小さいですが、このボードにはBronzeスポンサーとしてメドレーの社名も出ています。

会場の2階には、メッセージボードも設置されていました。遠方から参加された方のコメントも多数残されていました。見知らぬ参加者同士でコミュニケーションできるのは良いですね。

また会場では、スポンサーブースをまわってスタンプを集めるスタンプラリーが開催されていました。自分も各社のブースをまわり、技術、プロダクト、開発体制などの話を聞かせていただきました。いくつかのブースではかなり長い時間にわたって情報交換させていただき、とても有益な時間になりました。スタンプを集めて引けるクジでは当たりを引き、Dashちゃんのぬいぐるみをいただきました。宝物にします。

セッションの紹介

印象に残ったセッションを紹介します。

Flutterにしてよかった？出前館アプリを2年運用して気づいたこと全部話します

出前館には複数のモバイルアプリがあり、2年前にそのすべてをFlutterに統一したとのこと。それからの2年間で遭遇した技術面・運用面での課題とその課題をどう解消したのかを発表されていました。

まず、2年前まではReact NativeのCode Pushを利用してアプリを配信していたが、Flutterへの移行に伴い2週間のリリーストレインで運用するようになった、という話がありました。モバイルアプリにおけるリリーストレインの事例自体は多いと思いますが、フレームワークの移行に伴ってリリースフローも変更したという話は興味深く聞きました。「ユーザーに素早く価値を提供すること」を起点にリリースフローを再定義されていた点は素晴らしいなと感じました。

次に、Flutter Webを活用して開発中のフィードバックを受けるようにした、という話も良かったです。Flutterで開発しているモバイルアプリを、開発中のフィードバックを得るために社内に向けてWeb版で提供するようにした、とのことです。開発中のアプリをモバイル端末で動かしてもらってフィードバックを受ける、というのは実は心理的な障壁が高く、Web版を動かしてもらってフィードバックを受ける方が心理的障壁が低くフィードバックが集まりやすい…という点は驚きでした。Flutterを使って開発しているからこそ実現できた活用事例でした。

顧客価値を実現するFlutter：KPI・SLOから考えるキャリア支援アプリのUIUX設計

顧客価値を実現するためにFlutterをどう活用しているか？について実践してきた内容を発表されていました。提供したい顧客価値を定義し、重要指標を特定し、Flutterを用いて重要指標をどうやって改善するか、という事例の話でした。例えば以下のような事例です。

入力内容の即時ローカル保存によってフォーム入力における離脱率の指標を改善した
UIを楽観的更新することによって体感レイテンシの指標を改善した

発表されていた内容は、顧客価値を実現するためにモバイルアプリエンジニアから提案できるものだと思います。こういった取り組みについては、他社の具体的な事例を知る機会はなかなかないため、ありがたい発表でした。

アクセシビリティ、まだ完璧じゃないけど ── “今から”できること

アクセシビリティは重要な品質特性のひとつですが、モバイルアプリにおけるアクセシビリティへの取り組みはまだまだ発展途上にあると思います。しかしながら、カンファレンスでのアクセシビリティに関するセッションも増えつつあり、本セッションもそのひとつです。本セッションでは、Flutterにおけるアクセシビリティの基本や遭遇したトラブルについて発表されていました。

まず、Flutterにおけるアクセシビリティ対応ではSemantics Widgetを利用することが重要である、という説明がありました。その上で、Semantics Widgetの基本的な使い方の説明がありました。またこれまで遭遇したトラブルとしていくつかの事例が共有され、例えば標準WidgetではなくGestureDetectorを使用して実装した場合にスクリーンリーダーが適切に読み上げできない事例などが共有されました。

Flutterにおけるアクセシビリティの実装を再確認できたと共に、どのような場合に適切な読み上げができなくなってしまうのかを認識できました。非常に実用的な、有益なセッションでした。

最後に

メドレーの人材プラットフォーム本部では、Flutterエンジニアを積極採用中です。Flutterを活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！

Flutterエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

GitHub - honojs/cli: CLI for Humans and AI with Hono

Ruby World Conference 2025 参加レポート - ゴールドスポンサーとして協賛しました！

Wed, 12 Nov 2025 00:00:00 GMT

はじめまして！人材プラットフォーム本部のプラットフォームチームで、プラットフォームエンジニアリングとしてジョブメドレープラットフォームを開発している安藤雄飛と申します。（←プラットフォーム×4がお気に入りの自己紹介）

さて今回は、2025年11月6日と7日に島根県松江市の「くにびきメッセ」で開催されたRuby World Conference 2025に、当社メドレーはGoldスポンサーとして参加しました。また、メドレーの歯科診療所事業部長であり、Omotesando.rbのオーガナイザーやRuby関連執筆で活動されている牧さんの講演を聴講しましたので、そのカンファレンスの熱気をお届けします。

カンファレンスのサマリ

Rubyコミュニティの懐の深さ: 30年続くRubyのOSSコミュニティは、産学官連携や地域、国際文化交流まで有機的に発展しており、その間口の広さと懐の深さが際立っていました。
エコシステムの進化と拡充: Rubyで爆速リリースされたプロダクトが急成長し、次のフェーズに進むにあたり、Rubyエコシステムとメソドロジーがさらなる拡充と進化を遂げていること。
オープンな知識共有: Rubyのオープンなマインドに共感した「つよいRubyist」たちが、成功事例だけでなく、課題や失敗、挑戦を共有することで、コミュニティ全体の一体感と共有資産を生み出していること。

Ruby World Conference 2025会場

会場となった「くにびきメッセ」はJR松江駅から徒歩圏内ながらも、澄んだ少し冷たい風を感じながら大橋川を渡っているうちに、どこか神聖な雰囲気に包まれます。メドレーの松江エンジニアリングオフィス「Tech Studio MATSUE」も、このすぐ先にあります。

オープニングセレモニーでは、Rubyの父Matz（まつもとゆきひろ氏）をはじめ、島根県知事、松江市長の挨拶があり、Rubyが地域に深く根付いた文化であることが伝わってきました。

2日間にわたる27の講演・プログラムは、Rubyが様々な分野で活用されていることを示していました。主な活用事例は以下の3点です。

アフリカ東部を中心とした銀行口座を持たない14億人に向けて、金融排除問題をオフラインのフィーチャーフォンとRubyで解決したBernard Banta氏（アフリカRubyコミュニティ議長）の基調講演をはじめ、東日本大震災から首都圏のガスインフラを守った防災システムや事業継続（BCP）マネジメントシステム、政府案件として複雑な台湾語をRubyで解析するなどの 「喫緊の社会イシューをRubyで解決」 した事例
PicoRubyによるマイコンやIoT・ビジュアルアートのファンダムや、ruby.wasmを活用した学生向けプログラミングゲームやメタプログラミングRuby問題集、社内のDXやキャリアチェンジにRubyを活用した人材育成、そしてPythonが優勢なAI/機械学習分野におけるRubyの導入事例や機能移植へのモチベートなど 「Rubyの更なる可能性」 を示唆する講演
ビジネスのスケールに伴うシステムと開発組織の拡大、そしてそれに付随する社会的インパクトに対応するための品質とアジリティの両立に 「Rubyのエコシステムとコミュニティを活用したリアーキ戦略」 の紹介

どの講演も自社サービスや担当システムへの愛とRuby愛に溢れるものばかりでした。

歯科医療DXを支えるRuby職人の魂

Day1のトリを務めたメドレー歯科診療所事業部長、牧さんの 「歯科医療DXを支えるRuby - クラウド歯科業務支援システム『DENTIS』の開発事例」 の講演の様子がこちらです。

メドレーのミッション 「医療ヘルスケアの未来をつくる」 と、松江の拠点、そして「MEDLEY AI CLOUD」による未来の医療体験の紹介の後、牧部長が牽引するクラウド歯科業務支援システム 「DENTIS」 のデモが披露されました。

単なるサービス紹介に留まらず、歯科医療というドメインの持つ難しさが会場に伝わりました。そして牧さんは、その複雑さを以下の3点にまとめました。

医療会計の難しさ
保険診療の難しさ
歯科特有の情報処理

具体的な事例を用いたエッジケースや計算ツリーの複雑さの説明では、指数的なカバレッジの増加や、2年に1度見直しが入る診療報酬の改定と、その施行までの期間のタイトさ（本当に開発者にとっては驚くほど短期間です）がとても印象的でした。

そして、保険点数と医療費（月の算定エラーやアラートを含む）のメインロジックをActive Recordのコールバックからinteractor gemにリプレースすることと、予約システムデータ連携と電子カルテ・レセコンエンジン部を分離し、独立してスケールできるようなアーキテクチャに進化させ、この複雑なドメインをモデリングするための技術的挑戦を惜しみなく語り、Ruby職人の魂を感じさせました。

最後に、牧さんはこのシステムの「医療・ヘルスケアの未来を作る仲間」を募集していますと締めくくりました。会場にはたくさんのRubyistと学生さんもいましたが、私は、はたしてここまで複雑な事業ドメインを抱えるシステムに対してどれだけのエンジニアがチャレンジしようと思ってくれるのかと一縷の不安がありました。

ところが、質疑応答では、はじめに「大変やりがいのあるシステムだと思います。」と好意的な前置きをした上で「歯科診療のドメイン知識の取得が鍵になると思いますが、どのように解決されていますか？」と質問がありました。

牧さんは、「元々社内に数名の医療ドメインエキスパートがいることや専門家がジョインしていること、エンジニアも厚労省のPDFを読み込んだり勉強会などを通じてキャッチアップしていることにより、社内で情報のインデックス化が進んでいる。」との回答でした。

まとめと、未来を作る仲間へ

Rubyが入門のし易さや、開発者体験の良さといった スタートアップ事業における迅速性のみならず、ビジネス環境の変革に合わせた柔軟性や、システムや組織のスケールの適応性も兼ね備えている事を再認識した機会でした。特にRubyの 高い生産性 で開発フェーズを圧縮し、結果としてテストに時間を費やせるようになり、金融や防災、医療といった ミッションクリティカルなシステムでも品質を高められる という技術的判断に大きく納得させられました。

さらに、このRubyの発展と進化を支えているのが、このRubyコミュニティです。冒頭申し上げましたとおり、OSSコミュニティとして技術者同士のみならず、産学官、地域・国際文化交流がとても自然な形で融合しており、あらゆる形でコミュニティに参加するギバー達の貢献がエコシステムやナレッジとして、Rubyそのものとそれを使っている多様な企業や機関を通じて人々の幸せに還流されていく様子は、まさにOSSコミュニティの理想形ではないでしょうか。

以上、Ruby World Conference 2025のレポートでした！メドレーでは今後もRubyを含めて様々なOSSコミュニティへの協賛、オーガナイズ、登壇、コントリビュートなどを通じてOSSの発展に寄与してまいります。

そして、私たちと一緒に 「医療・ヘルスケアの未来をつくる仲間」 を大募集しています！メドレーの事業や、OSSを通じた医療DXと医療人材不足解消への挑戦に興味を持たれたエンジニアの方は、ぜひこちらメドレー採用資料もご覧になってください。

左から安藤、登壇された牧さん、Tech Studio MATSUEの三原さん（積極的にご質問されてました）

レセプションで松江の太鼓「鼕（どう）」を体験するMatz氏とBernard Banta氏

レセプション後の流れで自然と2次会にお集まり頂いた、牧さんと親交の深い色々な会社の #rubyfriends の皆さんと記念撮影

メドレー松江エンジニアリングオフィス「Tech Studio MATSUE」の皆さんと一緒に

We’re hiring!

現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。カジュアル面談も実施しています！

株式会社メドレー求人一覧

Hono Conference 2025 参加レポート - Silver Sponsor として協賛しました！

Mon, 10 Nov 2025 05:16:29 GMT

はじめに

こんにちは、人材プラットフォーム本部プロダクト開発部グループマネージャの松田です。ジョブメドレーアカデミーというオンライン動画研修・勤怠シフト管理の開発を行っています。

2025年10月18日(土)、Hono Conference 2025に参加してきました。Honoは、Cloudflare Workersなどのエッジ環境で注目を集める超高速・軽量Webフレームワークであり、私たちメドレーでも新規プロダクトの技術スタックとして採用しています。

今回、メドレーはSilver Sponsorとして本カンファレンスに協賛しました。私たちはHonoコミュニティの発展を支援するとともに、自社のエンジニアの城間（@shiromie）も登壇し、HonoとAIを組み合わせた開発ワークフローについて発表しました。本記事では、カンファレンスの熱気ある会場の様子と、Honoはもちろん、AIやBunなど、私たちが普段の業務で使用しているテーマを中心に、印象に残ったセッションを技術的な考察と共にご紹介します。

会場の様子

Hono Conference 2025は、docomo R&D OPEN LAB ODAIBAで開催されました。

カンファレンスは、Honoの作者@yusukebeさんによるオープニングセッションから始まりました。

スライドには「週200万 / 月800万」というnpmダウンロード数が映し出され、このフレームワークがいかに注目されているかが分かります。この後のブース巡りや各セッションで、Honoを支えるエコシステムや活用事例を見ていきたいと思います。

今回のイベントでは、多くのノベルティがありました。Cloudflareのオレンジ色の靴下は特に印象的でした。また、Vercelのロゴが入ったステッカーと、クッキーをいただきました。ステッカーも充実しており、Denoのかわいい恐竜のステッカーや、JSP（JavaServer Pages）のロゴがありました。特に、チームとして普段利用しているBunのステッカー（まんじゅう）も頂けて大満足でした。

セッションのハイライト

私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。

Blazing Fast Full Stack Apps with Hono and JSX

TwitchやYouTubeで人気のCJ氏(@CodingGarden)による発表です。ハイライトは、HonoがAPIフレームワークから、柔軟なフルスタックフレームワークへと進化した点です。

これまではAPI構築がメインでしたが、今回の発表では、Honoが標準でサポートするJSX、CSS in JSのように使えるHono CSS、ReactのSuspenseのように非同期データを扱えるストリーミング機能、そしてuseStateやuseEffectまで備えた軽量なクライアントコンポーネント（JSX DOM）機能がデモされました。

現在HonoをAPIサーバとして利用しているため、今回紹介されたHonoxは、今後の選択肢の一つとして非常に魅力的だと感じました。

CJ氏は人気のテックポッドキャスト『Syntax.fm』のホストとしても知られており、その語り口はさすがで、発表自体もとても丁寧で分かりやすかったです。

Interesting memory leak with Hono on Bun

Bun社に所属するSosuke Suzuki氏（@sosukesuzuki）のセッションです。私たちのチームでもHono on Bunの組み合わせを採用しているため、メモリリークというテーマはとても楽しみにしていました。

ハイライトは、Honoのストリーミングヘルパーと、BunのGC（ガベージコレクション）の特性が組み合わさった点でした。

まず、Honoの処理において、レスポンスとストリームが互いを参照し合う「循環参照」が発生します。Bunが採用するJavaScriptCore（JSC）のGCは、本来これを検知して解放できるはずでした。

しかし、レスポンスからストリームへの参照が『ストロングリファレンス』という特殊な参照として実装されていました。これはGCのルートのように扱われるため、GCは「両方とも到達可能である」と判断してしまいます。その結果、どちらも解放されずにメモリリークを引き起こしていた、という内容でした。

Bunを普段から利用するので、こうしたウィークポイントを具体的に知れたのはとても参考になりました。このセッションを受け、Bun自体のバージョンアップを積極的に追随し、修正を確実に取り込んでいく重要性を再認識しました。

@scalar/hono-api-referenceとMastraでシステム仕様書を自動更新するAIワークフロー構築してみた

続いて、弊社メドレーのエンジニアの城間（@shiromie）による登壇セッションです。このセッションでは、私たちが普段の開発で直面しているドキュメントの陳腐化という課題に対し、HonoとAIを組み合わせてどう解決したかを発表しました。

業務の合間を縫って構築したこのワークフローは、RAG（Bedrock + OpenSearch）とClaudeを活用したものです。特に、AIがハルシネーションを起こさず、事実に基づいた仕様書を書くようチューニングする点が、今回の取り組みにおける技術的なハイライトでした。

この取り組みは、まさに「AIが自動で成果物を作成し、人間がレビューするだけ」という理想を体現しています。具体的には、GitHub ActionsがAPI仕様書（llms.txt）の差分を検知すると、RAGが既存ドキュメントの関連箇所を特定し、Claudeが更新内容を判断してプルリクエストを自動作成します。開発者はそのPRをレビューするだけでドキュメントの鮮度が保たれます。

この取り組みは、AIを使った開発をより一層加速させる発表でした。

Closing - Hono CLI 登場

Hono ConfのClosingで終わったかと思いきや、そこでHono CLIが世界最速で発表され、まさかの発表に会場は熱狂に包まれました。コンセプトは「CLI for Human and AI」で、Hono自身もAIフレンドリーを意識した進化を遂げていることがわかりますし、ここにいるエンジニア全員が求めていたものでは？と感じました。

AIと開発者のための主要機能

1. AIエージェントの自律性向上 (AI Friendly)

AIエージェントがHonoをより深く理解し、扱えるようになります。

hono search
- AIがドキュメントを自律的に検索し、Markdown形式の仕様を正確に把握します。
hono request
- サーバーを一切起動せず（app.request()を直接実行）、型安全なリクエストをテスト実行できます。

2. 革命的な開発体験 (Developer Experience)

開発者のワークフローを根本から変える機能が導入されました。

hono serve --use <middleware>
- 個人的に衝撃的だった機能の一つです。
- コードを一行も変更せず、コマンドラインから直接ミドルウェアを注入（例：--use logger）できます。

3. 劇的な本番性能の最適化 (Performance)

hono optimize
- アプリのルート情報を事前コンパイルする PreparedRegExpRouter を生成。
- これにより、ルーターの初期化速度が16倍以上高速化し、バンドルサイズも大幅に削減されます。

Hono CLIを利用することで、開発速度が劇的に加速し、より速くプロダクトの価値を提供できるようになるだろうと感じました。

CLI for Humans and AI with Hono. Contribute to honojs/cli development by creating an account on GitHub.

エンジニア／人材プラットフォーム本部 | 株式会社メドレー

終わりに

2025年10月18日に開催された「Hono Conference 2025」に参加してきました。Honoに関わる企業・人々が一堂に集まるとても学びの多かったカンファレンスでした。技術的な側面では、Honoが単なる「高速なAPIフレームワーク」から、JSXによるフルスタック開発、そしてHono CLIによる「AIエージェント開発基盤」へと、そのエコシステムを急速に拡大させていることを実感しました。特に、私たちが実践している「Hono × AI」の取り組みと、コミュニティのAIに対する大きな流れが一致していたことは、大きな自信となりましたし、これからのHonoの進化が楽しみです。素晴らしい場を創り上げた主催者・スタッフ・登壇者・協賛企業の皆様に深く感謝いたします。

メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティへの貢献を続けています。

メドレーではエンジニアを積極採用中です！

メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。Honoが好きな方はもちろん、バックエンド、フロントエンド、インフラ、モバイルなど、ご自身の専門性を活かして医療ヘルスケア領域の課題解決に取り組みたいという、幅広いエンジニアの方を募集しています。ぜひカジュアル面談にお越しください！

エンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

テックリード・シニアエンジニア／人材プラットフォーム本部 | 株式会社メドレー

テックリード・シニアエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

新規事業プロダクトエンジニア／人材プラットフォーム本部 | 株式会社メドレー

新規事業プロダクトエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり

Designship 2025 参加レポート - ゴールドスポンサーとして協賛しました！

Wed, 22 Oct 2025 00:00:00 GMT

こんにちは。人材プラットフォーム本部でデザイナーをしている米田です。

メドレーは 2025年10月11日〜12日に開催された「Designship 2025」に、ゴールドスポンサーとして協賛しました🎉

会場の様子

「Designship」はオフラインとオンラインのハイブリッド形式で開催され、メインステージとオープンステージの2会場構成。
2日間にわたり、約80本ものデザインセッションが絶え間なく行われました。圧巻のボリュームと豪華な登壇者陣でした！

当日の雰囲気をショート動画風にまとめてみました。

弊社ブースの様子

弊社ブースは会場入口付近に設置され、多くの方にお立ち寄りいただきました。アンケートで、皆さんが日頃感じる医療課題についてお伺いしたところ、「待ち時間が長い」という声が圧倒的でした。

この課題を解決する一つの取り組みとして、私たちはオンライン診療・服薬指導を通じて「通院の待ち時間」をなくすことを目指した 「総合医療アプリ CLINICS」 を提供しています。
👉 CLINICS公式サイトはこちら

また、弊社のイベント情報やテックブログをお届けするメーリングリストに登録いただいた方には、その場でノベルティをお渡ししました。

他社ブースの様子

フラー株式会社様の「夢を書いていく」ブースでは、他の来場者の夢を拝見できる素敵な展示がありました。「犬・猫を飼いたい」という方がパッと見ただけでも3人いらっしゃいました。素敵ですね。🐶🐱

自分でも書いてみました。

ファインディ株式会社様ではなんとゲームができました！
ゲームの出来が良すぎて任天堂のイベントにきてしまったような気持ち。
クリアポーチもステッカーもとても可愛いです。

弊社のセッションの様子

オープンステージでは、弊社から2名が登壇しました。

医療プラットフォーム本部の前田（写真左） がプロダクト群統合とブランドリニューアルの取り組みを、
人材プラットフォーム本部の小山（写真右） がアクセシビリティ向上への取り組みを紹介しました。

他社のセッションの様子

株式会社スタメン様「組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり」

Designship2025でお話ししたセッション資料です。 https://design-ship.jp/2025/

作品を盛れない僕が掲げたポートフォリオ不要宣言｜宇野雄 / note inc. CDO

組織カルチャーという難しいテーマに対し、デザインの力で課題解決を試みる お話が印象的でした。
人数増加によるカルチャーの希薄化を課題と捉え、LT会でのアイデア共有や、うちわ・ペンライトなどを使った施策まで展開。
「課題を見つけ、ユーザーを理解し、解決策を実行していく」、これはまさにデザイナーの仕事そのものですね。
自分の組織もデザインしていく意識を持たねば…と気が引き締まりました。

note株式会社様「作品を盛れない僕が掲げたポートフォリオ不要宣言」

これはDesignship 2025の発表資料です。当日はゆったりと見てもらうために、メモや撮影などしなくていいよう、記録として残しています。 -------👇ここから発表内容👇------- まず最初に問いから入ります──「ポートフォリオって、そもそも何でしょう？」会場の皆さんの多くは、この言葉をご存じで、実際に作ったことがあると思います。出典：デジタル大辞泉語源を辿ると、もともとは書類や紙を入れる折りたたみのケースのこと。そこから意味が広がっていきました。投資の世界での「ポートフォリオ」は資産の一覧や配分を指しますよね。今日ここで使う意味は、最後の「作品集／

note.com

ポートフォリオといえば、ついつい見栄えをどれだけよくするかなどを考えてしまいますが、こちらは「ポートフォリオをなくしてしまおう」という発想。
ポートフォリオの提出を任意にし、その代わり、実際の業務に取り組んでもらい、評価をしていく形に変えたそう。
私も面接時に人のポートフォリオを拝見する機会がありました。知りたいのは「どういう考えを持って課題解決をしていく方か、どこにこだわりや美意識があるのか、無理せずお互いが合う性格・価値観か」などだったなあと、なぜポートフォリオを見るのかを、今一度考えさせられました。

おわりに

メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。

最後に改めて、Designshipの運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！

現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。
カジュアル面談も実施しています！

株式会社メドレー求人一覧

データ分析AIエージェントの実践 - Slack × Devin × Context Engineering

Thu, 16 Oct 2025 10:00:54 GMT

はじめに

こんにちは、医療プラットフォーム本部データ戦略グループの安東です。

以前、私たちは「データ戦略グループにおけるcontext engineeringの取り組み」という記事で、LLMに適切なコンテキストを提供することで分析精度を向上させるContext Engineeringの実践について紹介しました。

本記事は、その取り組みをさらに一歩進め、ビジネスユーザーが日常的に使える分析AIエージェントとして社内リリースした事例を紹介します。

組織拡大に伴うデータ分析ニーズ増加とアナリスト不足という課題に対し、私たちはContext Engineeringの知見を活かし、Devinを分析AIエージェントとして活用した分析基盤を構築しました。

本記事では、Slackをインターフェースとした分析AIエージェントのアーキテクチャと、データ戦略グループの具体的な取り組みについて解説します。

分析AIエージェントの全体フロー

分析AIエージェント全体の流れを以下の図で示します。

分析は、次の5つのステップで実行されます。

① Slackで自然言語で質問
ビジネスユーザー（PdM、Marketing、Sales、CSなど）が、Slackで自然言語により分析を依頼します。

分析依頼の専用フォームを用いることで、分析の目的、対象プロダクト、希望スピードなどを構造化して入力できます。

② AIエージェントが質問を解釈し、分析設計とツール使用
Devinが中心となり、以下のツールを活用しながら分析を設計・実行します。

MCP Toolbox for Databases: データベースへのアクセス
Confluence: 社内ドキュメントの参照
pandas: データ分析とグラフ作成
Playbook/Knowledge: 分析設計とドメイン知識の参照

③ 分析に必要なKnowledge参照
GitHubに格納されたKnowledgeリポジトリから、必要な情報を取得します。

ビジネスメタデータ: プロダクト固有のビジネスロジックやKPI定義
テクニカルメタデータ: データモデルの構造や分析手法

④ データの取得
データウェアハウスから分析に必要なデータを取得します。

データはdbtで変換されたmartモデルを中心に、分析パスに応じて最適なレイヤーにアクセスします。

⑤ Slackで分析結果回答
Slackのスレッドに、以下の形式で分析結果を返却します。

分析の結果・要約
Markdown形式のレポート
CSV形式のデータ
グラフ（PNG、HTML）
実行したSQLクエリ

この一連の流れにより、ビジネスユーザーはSlack内で数分で分析結果を得られます。

データ戦略グループの取り組み

データ戦略グループとして、この分析フローを実現するためにどのような工夫を行っているのか、具体的に解説します。

① Slackインターフェース：ユーザー体験の最適化

なぜSlackなのか

ビジネスユーザーにとって、データ分析の障壁は、「そもそも分析を依頼すること自体が難しい」という点にあります。

SQLエディタを開く、分析の設計をする、アナリストに分析依頼することは、多くのビジネスユーザーにとって日常的な行動ではありません。

一方、Slackは多くの組織で既に日常的に使われているツールです。メッセージを送る感覚で分析を依頼できれば、認知負荷を最小化できます。

私たちはこの点に着目し、Slackを分析AIエージェントのインターフェースとして選択しました。

フォーム設計による「プロンプトの最適化」

しかし、Slackで自由フォーマットで依頼を受けると、AIエージェントが意図を正しく汲み取れず分析品質がブレてしまいます。

そこで、構造化フォームを用いることで、分析に必要な情報を確実に収集し、AIエージェントへの入力を最適化する設計としました。

従来アプローチ: 自由記述 → AIエージェントが意図を推測 → 品質がブレる
改善アプローチ: 構造化フォーム → 必要情報を確実に収集 → 品質が安定

分析フォームは試行錯誤中ですが、分析設計において重要な情報を必須にしています

この設計により、ユーザーは「どんな分析をしてほしいか」を構造的に伝えられるようになり、AIエージェントは迷わず適切な分析パスを選択できます。

Devin Macroの活用

フォーム送信時には、Macroを用いてPlaybookパスを自動選択し、依頼内容を構造化した形でDevinに渡します。

これにより、以下のようなワークフローが実現されます。

ユーザーがSlackフォームで依頼を送信
MacroがPlaybookの該当セクションを特定
構造化された依頼 + Playbookパスの情報がDevinに送信
DevinがKnowledge Repositoryを参照しながら分析を実行

工夫のポイントは、自由度と制約のバランスです。

フォームによる構造化は「制約」ですが、その制約がユーザーに適切な依頼方法を示す効果も持ちます。

② AIエージェント実行：Devinの活用

Devinは、AIエージェントとして分析タスクを自律的に実行します。

Slackから受け取った構造化された依頼に基づき、以下のプロセスで分析を進めます。

自律的な分析タスクの実行

Devinは、単に質問に答えるだけでなく、以下のような複雑なタスクを自律的に遂行します。

タスクの理解とプランニング: 依頼内容を解釈し、必要な分析ステップを計画
ツールの選択と使用: MCPや分析パッケージなど、適切なツールを選択
データアクセス: MCP Serverを通じてデータウェアハウスに接続
分析の実行: SQLクエリの作成、データ加工、グラフ作成

Knowledge Repositoryとの連携

Devinは、分析実行時にGitHubのKnowledge Repositoryを常に参照し、以下の情報に基づいて適切な判断を行います。

Playbook: 分析の作法、コスト最適化、品質ゲート
Product Knowledge: プロダクト固有のビジネスロジックとKPI定義

この連携により、Devinは単なる汎用的なAIエージェントではなく、組織固有の分析ノウハウを持つ専門的なデータアナリストとして機能します。

③ Context Engineeringの実践

Prompt Engineeringが「どう尋ねるか」に焦点を当てるのに対し、Context Engineeringは「どんな知識を与えるか」に焦点を当てます。

Knowledge Repositoryの利点は、再現性、保守性、チーム管理のしやすさです。

プロンプトに知識を埋め込むのではなく、外部化された知識リポジトリとして管理することで、チーム全体で知識を共有し、継続的に改善できます。

私たちのContext Engineeringへの取り組みの詳細は、以前の記事「データ戦略グループにおけるcontext engineeringの取り組み」でも紹介しています。

GitHubをSSOTとした知識管理

私たちは、GitHubリポジトリをSingle Source of Truth（SSOT）として、分析AIエージェントが参照する全ての知識を一元管理しています。

knowledge-repository/
├── agent/
│   ├── playbook/
│   │   ├── playbook-main.md      # メインフロー
│   │   ├── playbook-paths.md     # 分析依頼に応じた分析パス
│   │   ├── playbook-cost.md      # BigQueryコストの最適化
│   │   └── playbook-quality.md   # 分析における品質と禁止事項
│   └── configurations/
└── product_knowledge/
    ├── product_a_knowledge.md    # Product Aのドメイン知識
    ├── product_b_knowledge.md    # Product Bのドメイン知識
    ├── product_c_knowledge.md    # Product Cのドメイン知識
    ...etc

この構造化により、AIエージェントは必要な知識を的確に参照でき、チームメンバーは知識の追加と更新を容易に行えます。

Playbookの設計思想

Playbookは、データアナリストの思考プロセスを再現することを目的に設計されています。

責務の分割

単一のPlaybookファイルではなく、目的別に分割することで保守性を高めています。

playbook-main.md: 分析の基本フロー
1. 分析の目的を明確化
2. データ品質をチェック
3. BigQueryコストを見積もり
4. アウトプットから逆算して分析パスを選択
playbook-paths.md: 3つの分析パスの定義
- Fast: 既存のmartモデルのみを使用、低コスト
- Standard: 中間テーブルを参照、バランス型
- Deep: 複数のレイヤーのデータを参照、高精度・高コスト
playbook-cost.md: コスト最適化戦略
- クエリ実行前のドライラン
- パーティションとクラスタリングの活用
- 全量スキャンの回避
playbook-quality.md: 品質ゲートと禁止事項
- 集計前のデータ件数確認
- NULL値の扱いの明示
- 結果の妥当性チェック

この分割により、各Playbookは独立して更新でき、特定の目的（例: コスト削減）に特化した改善が容易になります。

Product Knowledgeの役割

各プロダクトには、固有のビジネスロジックやドメイン知識があります。これらを product_knowledge/ 配下にMarkdownファイルとして整理しています。

例えば、 product_a_knowledge.md には以下のような情報が含まれます。

プロダクトの概要とビジネスモデル
重要なKPI定義
よくある分析パターン（リテンション分析、コホート分析など）
データの特性や注意点

AIエージェントは、依頼フォームで指定されたプロダクトに応じて、該当するProduct Knowledgeを参照し、適切な分析を行います。

④ データ基盤：AIに最適化されたデータ設計

分析AIエージェントが効率的に動作するためには、AIが理解しやすいデータ構造が不可欠です。私たちは、dbtを用いてデータウェアハウスのモデリングを行い、階層的なデータ構造を構築しています。

3層のデータ構造

データウェアハウスは、以下の3層で構成されています。

staging（加工処理データ）: 各種データソースを加工処理したデータ
intermediate（中間層）: データクレンジングや結合を行った中間テーブル
mart（分析用データマート）: ビジネスロジックを適用し、分析に最適化されたテーブル

この階層化により、スピードとコストのトレードオフを明示的に管理できます。

実際の動作と効果

Slackで分析を依頼すると、以下のような流れで結果が返ってきます。

ユーザーがフォームで依頼を送信（所要時間: 1分）
DevinがKnowledge Repositoryを参照しながら分析を実行（Fast: 5分、Standard: 30分）
分析結果がSlackスレッドで返却（グラフや数値サマリ付き）

社内リリースからまだ日が浅く、現在も試行錯誤を続けています。

ビジネスユーザーからのフィードバックをもとに、Playbookの改善やProduct Knowledgeの拡充を継続的に行いながら、より多くの分析ニーズに対応できるよう取り組んでいます。

AIエージェントと人間アナリストの役割分担

分析AIエージェントは、全ての分析業務を代替するものではありません。分析の複雑性と工数に応じて、適切な役割分担が重要です。

分析業務は、その複雑性に応じて3つの領域に分類できます。

BIツール: 定型レポートやダッシュボードでの即座な確認
AIエージェント: 本記事で紹介した領域。アドホックな集計や探索的分析を自律的に実行
データアナリスト + AI: 曖昧な要件の明確化やシミュレーション、戦略的な意思決定支援

現在、AIエージェントは②の領域を中心に活用されており、定型的で構造化された分析を効率化することで、人間アナリストが戦略的な分析に集中できる環境を作っています。

今後の展望

現在の分析AIエージェントは、一部プロダクトに対応していますが、今後は以下のような拡張を計画しています。

データソースの拡充: セールスやマーケティングデータへの対応
横断的な分析: プロダクトデータとセールスデータの統合分析
より高度な分析手法: 機械学習モデルの適用や予測分析

本記事では、Slack、Devin、Context Engineeringを組み合わせた分析AIエージェントのアーキテクチャと設計思想を紹介しました。

データ分析AIエージェントの開発に取り組む方々の参考になれば幸いです。

We’re hiring!

メドレーの医療プラットフォーム本部のデータ戦略グループでは、AI 時代の新しいデータ分析にチャレンジしたいデータエンジニアを募集しています。医療ヘルスケア領域でのAI×データ活用にご興味をお持ちの方は、ぜひお気軽にお声がけください！

データエンジニア／医療プラットフォーム本部の募集詳細はこちら

運用されつづけるブランドをつくるために — MEDLEY AI CLOUD リブランディング「苦悩と葛藤の 8 ヶ月」の舞台裏 —

Fri, 26 Sep 2025 00:59:17 GMT

こんにちは。株式会社メドレー医療プラットフォーム本部デザイン室長の前田です。

こちらの記事は「MEDLEY Summer Tech Blog Relay」の 23 日目の記事です。

はじめに

9 月 1 日、メドレーは新ブランド「MEDLEY AI CLOUD」をニュースリリースで発表しました。

これまで個別に展開してきた医療機関向けの業務支援システムを「MEDLEY AI CLOUD」として統合的にブランディングし、各プロダクトロゴも刷新しました。

この記事では 「なぜこのプロジェクトを立ち上げたのか」、「どんな課題があったのか」、「どんな未来を描いているのか」 についてお話しします。

なぜリブランディングをすることにしたのか

メドレーの医療プラットフォームは 10 年前、医療事典 MEDLEY からスタートしました。その後、CLINICS、Pharms（現在、MEDIXS に統合）、DENTIS などのプロダクトを開発・提供し、MALL、MINET、Lalune、@link、MEDIXS などメドレーにジョインするプロダクトも増えてきました。プロダクトによっては 20 年以上提供し続けてきた歴史があります。

私たちの強みは、病院・診療所・薬局向けの基幹システムから患者アプリまでを一気通貫で提供していること。
しかし、プロダクトが増えるにつれ 「統一感のなさ」や「ブランドのつながりが見えないこと」 が課題として浮かび上がってきました。

医療プラットフォームのプロダクト群

組織づくりから始まった

2024 年初め、メドレーの医療プラットフォームに在籍するデザイナーはわずか 5 名。プロダクト開発業務だけで手一杯で、ブランド構築を考える余裕は微塵もありませんでした。

デザイン人材不足の課題を解消するために、デザイン組織の立ち上げと採用の強化 から取り組みはじめました。

「デザイナー」という幅広い募集要項で採用をかけていたため、私たちが求めるスキルや役割が十分に伝わらず、なかなか採用決定に至らない状況が続いていました。

そこで、役割を「プロダクトデザイナー」と「コミュニケーションデザイナー」に分けて募集したところ、採用が一気に進展。結果として、2024 年末には 11 名体制となり、デザイナー同士で協力しあえる組織基盤を整えることができました。（2025 年 9 月時点では 14 名）

デザイン組織の変遷

ブランド構築プロジェクト始動

組織体制が整ってきた 2025 年初め、いよいよブランド構築プロジェクトを開始します。最初のステップは医療プラットフォームの各プロダクトとして核となる「ブランド DNA」の設計から着手しました。

ブランドの軸を定めるため、指針を立てて、わかりやすく言語化することで、関係者の意識統一を図るのが目的です。

正直、私自身この規模のリブランディングを一気に対応していくことが初めての試みだったこともあり、どのように設計していくべきか悩みました。いろんなブランドの本を読み漁ったのですが、その中でも「ニューヨークのアートディレクターがいま、日本のビジネスリーダーに伝えたいこと」が今回のプロジェクトを進めていくうえで参考になりました。

ブランド DNA を設計し、経営層やプロダクト責任者と議論を重ね、ブラッシュアップしていきました。

それと平行して、各プロダクトの LP に活用するデザインシステムの検討も進めました。見た目の統一感だけでなく「顧客に安心と信頼を届けるブランド体験」を実現するフロントエンド設計も同時に目指しました。

ブランド DNA 検討中の資料

ロゴ刷新は予定外だった

当初、ロゴの刷新は計画していませんでした。
ちょうど同時期に CLINICS アプリのリブランディングが進んでおり、デザイナーのリソースを集中させる判断をしていたからです。

しかし、ブランド DNA を定義し、各プロダクトのサービスサイトをリニューアルしていく中で、それだけではブランドの一体感や方向性を十分に示せないのではないかという課題が浮かび上がってきました。

加えて、各プロダクトで AI 機能の搭載が検討され始めたことを背景に、今後の医療プラットフォームの魅力を「医療 SaaS + AI」という形で明確に示すため、統合ブランド「MEDLEY AI CLOUD」を立ち上げる決断を下します。

こうして最終的に、「統合されたブランド体験を象徴するためにはロゴ刷新が欠かせない」と判断しました。そこで全プロダクトのロゴ刷新を含む、大規模なリブランディングへと舵を切ったのです。

AI 活用の業務イメージをどう伝えるか

ロゴ刷新の方針が固まり、各プロダクトで共通して使えるデザインシステムの検討も整いました。あとは「実装あるのみ！」と意気込んでいた、その矢先です。

新たな課題が立ちはだかりました。
ーー「医療 SaaS + AI」という魅力を、どう伝えるのか？

当時、AI 機能を搭載したプロダクトはまだ開発途中。
実際の医療現場でどう役立つのか、どのようにして効率化につながるのか。
その具体的なイメージを示す手段が不足しているのでは…。
そんな不安が広がっていったのです。

自ら AI 活用で業務効率化を体感してみる

そんな不安を打ち消すきっかけになったのが、「AI 活用のイメージを動画で見せてしまおう」というアイデアでした。

ちょうどその頃、社内では生成 AI 利用のガイドラインが整備され、各部門でもそれに沿った AI 活用が推進されていました。その流れも相まって、私自身も AI を取り入れた動画制作に挑戦することにしたのです。

ナレーションや BGM に AI を駆使し、構成や演出については自ら試行錯誤を重ねました。その結果、短期間でムービーを完成させることができました。

「AI による効率化を語るなら、まず自分が体験してみよう」

その思いから取り組んだ動画は、ブランドやプロダクトの未来像を端的に伝える欠かせない要素となりました。

BRAND PROMISE MOVIE - MEDLEY AI CLOUD

MEDLEY AI CLOUDは、AIを活用して医療機関の業務効率化を実現し、患者・生活者により良い体験を届ける、株式会社メドレーが提供する次世代医療プラットフォームです。

medley-cloud.com

運用されつづけるデザインシステムをどう構築するか

Developer ブログらしく、同時並行して進めてるデザインシステム構築についても少し触れておきます。デザインシステムは「作ったら終わり」ではなく、継続的に運用される仕組みがなければ意味がありません。

マルチ CMS 環境という課題

各プロダクトの LP は、WordPress や外部の CMS、Headless CMS など、バラバラな環境で運用されています。そこで、同じ環境でデザインシステムを構築し、どのサイトからでも共通で利用できる状態を目指すことにしました。

この課題を解消するために社内のエンジニアともすり合わせをして、以下を実施することにしました。

・CMS の一本化：Headless CMS へ統一
・モノレポ化：共通デザインシステムを集中管理
・コンポーネント呼び出し：各プロダクトから共通の UI コンポーネントを利用可能に

この仕組みにより、UI やブランドトーンを一貫させつつ、各 LP への高速な展開ができると思っています。

現段階では、 MEDLEY AI CLOUD のみで実装されていますが、今後は各プロダクト LP へも順次展開していく予定です。この取り組みの詳細は、また別の機会に説明できればと思っております。

これから

ロゴは無事に完成し、各プロダクト LP への反映も進んでいます（ロゴ制作についても別の機会に説明できればと思います）。
けれども、ブランド構築プロジェクトはまだ始まったばかり。ロゴ刷新はあくまで出発点であり、これからはブランド体験の一貫性をさらに高め、医療現場や患者とのさまざまな接点にブランドを浸透させていくフェーズが本格化します。

私たちが提供する MEDLEY AI CLOUD の各プロダクトの使命は、「医療現場の業務効率化と、より良い患者体験を支援する」ことにあります。プロジェクトを進める中で、私自身も AI ツールの活用が推進力になることを強く実感しました。

全プロダクトで共通する 5 つのブランド・プロミス

より良い患者体験
AI 活用
安心・安全
オープン連携
リーズナブル

これらを軸に、病院・診療所・薬局・歯科といった領域をつなぎ、患者・生活者と直結する「ひとつながりの医療プラットフォーム」を実現していきます。中長期的には、社会インフラの一翼を担うプラットフォームとなることを目指しています。

さいごに

MEDLEY AI CLOUD ブランドの浸透や各プロダクトの開発を進めるうえで、これからもデザイナーの力は欠かせません。

このブランド構築プロジェクトは、私たち自身の想いや未来への取り組みを社内外に届けるため、外部に頼らず、社内メンバーだけでつくり上げてきました。

今後はブランド認知のさらなる拡大と事業成長を見据え、デザイナーをはじめ、多様な専門性を持つ仲間を必要としています。

少しでも興味を持っていただけたら、ぜひ MEDLEY AI CLOUD サイト内の採用一覧をご覧ください。

私たちと共に、未来の医療体験を一緒につくっていきましょう。

MEDLEY AI CLOUD

medley-cloud.com

iOSDC Japan 2025 参加レポート - ゴールドスポンサーとして協賛しました！

Fri, 26 Sep 2025 00:00:00 GMT

こんにちは！株式会社メドレーでDevRelを担当している重田です。

株式会社メドレーは、2025年9月19日(金)〜21日(日)に開催された iOSDC Japan 2025に、ゴールドスポンサーとして協賛しました。昨年同様、今年はセッション登壇とブース出展の両方を実施しました。記念すべきiOSDC Japan 10周年を、コミュニティの一員として迎えられたことを大変嬉しく思います！

メドレーでは複数のモバイルアプリを開発しており、コミュニティとのつながりを通じて開発力とプロダクト価値の向上を目指しています。その活動の一環として、弊社は2017年からiOSDC Japanに協賛しており、今年で9回目となりました。

本記事では、3日間にわたるイベントの様子と共に、メドレーの取り組み、そして印象に残ったセッションやブースについてレポートします。 2024年の参加レポートもぜひご覧ください → https://developer.medley.jp/entry/2024/09/10/205504/

会場の様子

iOSDC Japan 2025は、有明セントラルタワー&カンファレンスにて開催されました。今年は3日間にわたり、のべ1,500名ものiOSエンジニアが有明に集結し、技術への熱気に満ち溢れた空間となりました。スポンサーブースエリアも連日多くの参加者で賑わい、カジュアルな雰囲気で技術交流を楽しむ姿がそこかしこで見受けられました。

常に、軽食とフリードリンクが用意されており、ブース運営にとって大変ありがたいサービスでした！

フリードリンク（お水）には開催年度のデザインが施され、手に取るのが楽しかったです。

15時以降になると、アルコール類も提供があり驚きました。

セッションの様子

メドレーからは、医療PF所属の吉田が登壇しました。ご聴講いただいた皆さま、ありがとうございました！

止められない医療アプリ、そっと Swift 6 へ

2025年9月21日（日）に開催のiOSDC Japan 2025の登壇資料です。イベントURL：https://iosdc.jp/2025/ 発表者情報：医療プラットフォーム本部　エンジニア　吉田将吾

Learn CPU architecture with Assembly

エンジニアに聞いた面白かったセッション

弊社エンジニアが気になった・聴講して面白かったセッションをご紹介します！

アセンブリで学ぶCPUアーキテクチャ by akkey

iOSDC Japan 2025 https://fortee.jp/iosdc-japan-2025/proposal/4316d7ee-b3a0-4623-997a-df8843a9a709

Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム

私たちが日々用いている Swift などのプログラミング言語は、LLVM を経由してアセンブリに変換され、最終的に機械語として実行されます。アセンブリは普段あまり意識しない領域ですが、開発の基盤を支える重要な要素です。本セッションはそのアセンブリに焦点を当て、アセンブリとは何か、具体的な読み方、スタックトレースを用いた実例まで、とっつきにくい内容を非常にわかりやすく解説していました。日常の開発で直接触れる機会は多くないかもしれませんが、技術的な好奇心を強く刺激する発表でした。

Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム by giginet

https://fortee.jp/iosdc-japan-2025/proposal/c740120d-d52f-4100-986b-a24e8f0d3b87

プログラマのための作曲入門 iOSDC Japan 2025 2025/09/21 13:55〜 Track A 音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。 ……と思われている方も多いようです。しかしながら、それは大きな誤解なのです。なぜ…

iOS アプリ開発では、普段あまり意識せずにビルドを行っていますが、今年の初めに Apple がビルドエンジンである「Swift Build」のオープンソース化を発表しました。本セッションでは、既存のビルドシステムの説明から、Swift Build で何が変わるかを丁寧に説明していました。 CLINICS アプリでも Swift Package Manager を使ったマルチモジュール構成を採用しています。Xcode Project と Package.swift 双方がどのようにビルドされ、最終的にアプリとしてパッケージ化されるのか理解が深まり、非常に有意義な発表でした。

プログラマのための作曲入門 by CHEEBOW

プログラマのための作曲入門

「Chatwork」アプリにおけるSVVS実装戦略 | ドクセル

iOSDC というと、iOS に関するセッションだけだと思われがちですが、iOS から離れた技術領域のセッションも採択されることがあります。本セッションは、実際にアーティストへ楽曲提供している iOS エンジニアの CHEEBOW さんによる、作曲に関するお話でした。コード進行の実例を交え、作曲をわかりやすく解説しており、作曲未経験の人にも理解しやすい内容でした。作曲とソフトウェア開発は一見まったく異なる領域に思えますが、コード進行にも定番がいくつもあり、ソフトウェア開発でいう「デザインパターン」に相当するものだ、という表現が印象的でした。

「Chatwork」アプリにおけるSVVS実装戦略

iOSDC2025の登壇資料です。ビジネスチャット「Chatwork」を提供する株式会社kubell（旧Chatwork株式会社...

www.docswell.com

SVVSというアーキテクチャでプロダクトを実装していく上で直面した課題とその課題を解決する方法が話されていました。セッションの前半で、ログインのライフサイクルを管理するためにLoginContextを導入した話は興味深く聞きました。ライフサイクル管理のための考え方として、他にも応用が効く考え方であると感じました。

ブース出展の様子

約50社のブースが出展されており、連日とても賑わっていました。本記事では、私たちのブースと特に印象に残ったブースをいくつかご紹介します！

弊社ブースの様子

私たちは医療×iOSに関する3択3問クイズにチャレンジいただき、正解数に応じてノベルティを配布していました！日替わりで問題を変更し、全日楽しんでいただけるよう工夫しました。 👇実際に出題した問題を一部ご紹介。最後には解説付きで正誤を確認！

全問正解の方には、今回初めて登場したノベルティ「ポータブル防災7点セット」をプレゼント！いざという時に役立つグッズをご用意しました🏃‍♀️

お越しいただいた皆様、ありがとうございました🙌✨

その他のブースの様子

KINTOテクノロジーズ株式会社

AI広報るぴあちゃんとじゃんけんで勝つとトミカがもらえる楽しいブースでした🚙 トミカ欲しさに何度かチャレンジしたものの、るぴあちゃんが強くてゲットならず・・・（写真に写っている弊社エンジニアは勝ってトミカをゲットしていました👏）

本田技研工業株式会社

最新の車載システムとiOSの連携について、デモを交えながら詳しく説明されていました。普段触れることのない分野の技術に触れられ、とても興味深かったです。（なんといってもバイクがカッコよかったです!!!）

株式会社Luup

新しいモビリティサービスをiOSエンジニアの視点から解説されており、地図や位置情報と密接に関わる開発の面白さを感じることができました。タップ数をクリアしたらロックが外れトートバッグをゲットできる仕掛けになっていました。

まとめ

DevRelとしてメドレーの事業やプロダクトをコミュニティに発信することを目的として参加した今回のiOSDC。スポンサーセッションやブース出展を通して、多くのiOSエンジニアの皆さんと直接お話しする機会をいただき、非常に有意義な3日間となりました。ブースに立ち寄ってくださった皆様、ありがとうございました！今後もメドレーは技術コミュニティへの貢献、そして弊社をより多くの方々に知っていただくためにイベントへの協賛を継続していきます。またカンファレンスでお会いしましょう！

We’re hiring!

メドレーではiOSエンジニアをはじめ、「医療ヘルスケアの未来をつくる」というミッションに共感し、ともに切磋琢磨する仲間を大募集中です。

少しでもご興味のある方はまずはカジュアル面談でお話しましょう！

株式会社メドレー

株式会社メドレーです。| HRMOS

テックリード候補バックエンド／CLINICS | 株式会社メドレー

※カジュアル面談をご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

ライブラリ更新リスクを分離する週2回リリース戦略〜開発とQAの実践〜

Thu, 25 Sep 2025 05:36:28 GMT

はじめに

この記事はメドレー夏のブログリレー 2025 22 日目の記事です。

メドレー医科診療所プロダクト開発室 AI推進グループの桶谷です。

AI推進グループでは、「AIで “医師” と “エンジニア” の生産性を最大化する」というミッションを掲げ、医師の皆様に向けたAIソリューション（「ゼロ距離医療」の実現）と、社内エンジニアの生産性向上（「CLINICS 10x」）の両輪で様々な施策に取り組んでいます。取り組みの全体像はこちらの記事で詳しく紹介しています。興味のある方はぜひお読みください。

その中でも「CLINICS 10x」では、従来の10倍の速度で機能リリースを実現するための様々な取り組みを進めています。 10倍のリリーススピードを実現するには、単に開発を速めるだけでなく、リリースの品質担保、特にQAの効率化とバグの早期検知が極めて重要になります。 CLINICSは多くの医療機関で利用される基幹システムであり、不具合発生時の影響をいかに局所化し、迅速に修正できる体制を築くかが大きな課題でした。

そこで、10xリリースの土台作りとして、まず「ライブラリ更新」のリリース戦略見直しに着手しました。今回はその取り組みの中から、CLINICSを開発しているチームで導入した、ライブラリ更新を分離する新しいブランチ戦略についてご紹介します。

※ ライブラリ更新：本記事ではMinor、Patchレベルの更新を指します

想定読者

リリースプロセスに課題を感じている人
開発チームと連携して品質保証の仕組みを改善したい人

なぜリリース戦略を見直したのか

CLINICS は多くの医療機関で利用されている診療所向けクラウド型電子カルテシステムです。医療機関向け SaaS として提供される一方で、電子カルテ、予約管理、会計、オンライン診療など診療所の基幹業務を一手に担う「基幹システム」として機能しています。日々の診療に直結する業務を支えるため非常に高い安定性と信頼性が求められます。サービスの性質上、ひとつの変更が「受付 → 診療 → 会計」といった一連の業務フロー全体に波及する可能性があるため、品質保証の重要性は非常に高いです。

その品質保証の範囲も単なる UI 動作の確認にとどまらず、業務フローの整合性、データ整合性、権限や監査、請求（算定）ロジック、可用性といった多岐にわたる領域に広がります。しかし、いくらテストを厚くしても、あらゆる組み合わせを事前に網羅するのは現実的に困難であり、検証漏れのリスクを完全に排除することはできません。そのため、リリース設計においては差分を小さく保ち、影響範囲を限定し、原因を切り分けやすくする工夫が不可欠となります。

さらに技術的な背景として、CLINICS は Rails モノリスに複数の SPA を内包し、バックエンド、フロントエンド、一部インフラを単一リポジトリ（モノレポ）で集約的に管理・運用しています。1つのリポジトリに Rails、React、Next.js、Node.js といった技術スタックが同居しており、依存関係は論理的に分離されているものの、ライブラリ更新の頻度は高く、変更の影響範囲も広大になりがちでした。

こうした背景と課題から、まずは機能とライブラリのリリースを分けることで、変更差分と影響を最小化しようと取り組みました。

従来のリリースプロセス

CLINICSでは、master（本番環境相当）/ develop（開発統合）/ release-candidate（次回リリース候補のコードフリーズ） の3ブランチ構成を基本に運用しています。従来は「機能追加」と「ライブラリ更新」を毎週火曜日の定常リリースにまとめて実施していました。具体的には、各 feature ブランチや deps（ライブラリ更新）ブランチを develop に順次マージし、木曜日に develop から release-candidate を作成してコードフリーズ。このrelease-candidate 上で QA を実施し、翌週火曜日に master へまとめてリリースするというフローです。

図を見て分かる通り、Git Flow をベースに開発、リリースを実施しており、全ての変更が毎週火曜日の定常リリースに集約されていました。この方法ではプロダクトの成長とともに、以下の課題が浮き彫りになりました。

不具合発生時の原因切り分けが難しい：不具合が生じても、それが新機能によるものかライブラリ更新によるものか特定に時間がかかる
品質担保コストの増大：ライブラリ更新は予期せぬ副作用を生むことがあり、機能追加と同時に行うことで QA の範囲が広がり、テストや検証に必要なコストが増大していた

リリース時の差分が大きいと、一見些細なライブラリ更新であっても、医療現場の業務フローに予期せぬ不具合を引き起こし、診療や会計といった基幹業務に影響を及ぼすリスクがあります。実際にも、ライブラリ更新と多様なデータ状況など複数の要因が重なれば、一部の医療機関で「会計処理が停止する」といった業務に直結する問題が発生する恐れがありました。こうした事象は、医師やスタッフの負担を増やすだけでなく、患者体験にも直結してしまいます。

さらに昨今では、生成AIを活用した開発の加速によって、リリースごとに扱う差分はますます膨らみ、従来のリリースプロセスのままでは品質とスピードの両立が難しくなってきました。そこで、「CLINICS 10x」の思想に立ち返り、品質を確保しながらもスピードを失わないために、リリース戦略そのものを見直す必要があると判断しました。

新しいリリース戦略で実現したいこと

今回の取り組みで目指したのは、単なるリリース手法の変更ではなく、チーム全体が安心して開発・検証・リリースに取り組める体制を作ることです。そのために、次の3つを軸としました。

ライブラリ更新の安定化
- 不具合発生時に「ライブラリ起因」と即座に判断して対応できるため、機能変更と明確に切り分けてリスク管理が可能となる
- 不具合発生時にライブラリ更新だけを即時に戻せるため、初動対応を安全に行える
機能リリースの明確化
- QAは機能検証に集中でき、テストの粒度と品質が向上する
- リリースノートも「メンテナンス」と「アップデート」に分け、ユーザーに分かりやすく伝えられる
品質とスピードを兼ね備えた体制
- 小さな差分で安全かつ素早くリリースできる体制を確立
- 領域ごとの責任分担と確認項目を明確化し、安心して高速リリースを実行できる運用体制を整備

この取り組みには技術面だけでなく、事業部やQAチームとの合意形成も不可欠です。特に、カスタマーサクセス（CS）/サポートデスクは変更点の把握が不可欠である一方で、ライブラリ更新といった技術的変更が十分に共有されないままリリース差分が大きくなることに不安を抱えていました。そこで、週2回のリリース頻度増は「差分を小さく保ち、リスクを分離・局所化すること」を狙いとしていると説明し、リリースノートを「メンテナンス（ライブラリ）／アップデート（機能）」に分けて整理しました。結果として、関係部署からも「そのほうが安全で把握しやすい」と理解が得られ、スムーズに合意形成へとつなげることができました。

一方で QA チームも、従来はライブラリ更新と機能追加を同時に検証していたため、不具合が発生すると原因切り分けに苦労していました。こうした課題感もあり、「更新と機能を分けた方が効率的に品質を担保できる」という点で意見が一致しました。加えて、開発と QA が一体となって品質を高める文化がすでに定着していたことも後押しし、新しいリリース戦略をスムーズに取り入れることができました。

ライブラリリリースと機能リリースを分ける際のブランチ戦略

今回、新たに「ライブラリ更新専用のブランチ」を追加することで、ライブラリ更新を単体でリリースできるようになり、機能リリースと役割を分担した週2回の安定したリリース体制を実現しました。

曜日	リリース成果物	ブランチ
月曜日	ライブラリ更新	release-candidate-lib
火曜日	機能追加	release-candidate

この仕組みにより、ライブラリ更新と新機能追加という性質の異なる変更が互いに干渉せず、それぞれに適したテストと品質保証を行える体制を確立することができました。

AS-IS / TO-BE の比較

AS-IS（従来のリリースフロー）

TO-BE（新しいリリースフロー）

AS-IS では、機能追加（feature）と依存更新（deps）が develop に同居し、木曜日作成の release-candidate 上でまとめて QA を実施し、翌週火曜日に単一リリースしていました。TO-BE ではフローを2本に分離しました。ライブラリ更新は release-candidate-lib-next に集約し、同時に develop へ Reverse Merge することで、日常開発の中で早期に動作検証を行います。安定化した内容は月曜日に release-candidate-lib にて、ライブラリのみのリリースを実施します。機能追加については従来通り release-candidate を経由し、火曜日に本番リリースを行う形にしました。

新しいブランチ戦略におけるキーポイントとメリット・デメリット

今回の戦略で最大のポイントは、release-candidate-lib-next ブランチの新設です。

Renovate/Dependabot が作成するライブラリ更新 PR を release-candidate-lib-next に集約することで、翌々週にリリースされるライブラリ更新の成果物を対象に、長期回帰テストを継続的に実施できるようになりました。コードフリーズブランチを「ライブラリ用」と「機能用」に分離したこともポイントです。ライブラリ更新は回帰確認中心、機能追加は業務フローやユーザー体験検証中心といった形で、QA のスコープを用途ごとに最適化できるようになりました。加えて、ライブラリ更新を単独でリリースできるため、不具合発生時には原因の切り分けが容易になり、ライブラリのみを安全に Revert する対応も可能です。

こうした仕組みによって、品質保証の効率化と精度向上を実現しつつ、不具合対応の即応性も高めることができました。一方で、運用を進める中でいくつかの課題やトレードオフも明らかになってきました。

Reverse Merge の増加：release-candidate-lib-next → develop への取り込み頻度が上がり、特にコンフリクト発生時の解消コストが高い
ブランチ運用の複雑化：release-candidate-lib-next / release-candidate-lib の追加によって、運用コストや学習コストが増大
CI/テスト負荷の増加：候補ブランチごとに E2E が走るため、ジョブ数が増えて実行環境への負荷が高い(省力化や高速化に向けた改善は別途実施中)

これらの課題は認識しつつも、チーム合意のもと「医療に直結するプロダクトとして品質を優先する」という判断を取りました。その結果、リスクの局所化と原因特定の迅速化を両立し、週2回の安全なリリースを継続できる体制を確立できています。

QA チームによる品質担保の仕組み

ここからは、QA エンジニアの小島 (@Daishu) が、今回の改善における E2E テストを用いた品質担保の設計について紹介します。

E2E テストの実施体制

CLINICS では、QA チームが MagicPod を使って E2E テストを管理しています。

出典: 徹底解剖！医療業務システムのReactコンポーネント設計を基に作成

各ブランチでは、以下の頻度と目的で E2E テストを実行しています：

1. 開発統合 (develop) ブランチ
デイリーで E2E テストを実行し、デグレを検出します。テスト失敗時は原因を分析し、仕様変更による失敗の場合は MagicPod のテストシナリオを更新して対応しています。

2. リリース候補 (release-candidate) ブランチ
ウィークリーで E2E テストと手動テストの両方をフルスイートで実行してリリース可否を判定します。

新しいリリースプロセスへの対応

新体制への移行にあたり、QA チームの懸念や要望を開発チームに共有し、一緒に品質担保の仕組みを設計しました。

① deps マージタイミングの最適化

deps をマージするタイミングを変更したことで、問題の切り分けが改善されました。

	deps マージタイミング	特徴
旧	release-candidate ブランチカット前	• ライブラリ更新が翌週リリースとなる • 不具合検出の猶予がなく、問題切り分けに時間がかかる
新	release-candidate ブランチカット後	• ライブラリ更新のリリースが翌々週となる • 開発環境での検証期間を確保でき、問題の切り分けが容易になる

この変更により、deps 起因の問題を効率的に検出・対応できるようになりました。

② release-candidate-lib ブランチでの E2E テスト追加

前述の release-candidate-lib ブランチに対する E2E テストを追加しました。これにより、ライブラリ更新の品質を単独で検証できるようになりました。

③ MagicPod ブランチ機能による UI バージョン管理

release-candidate-lib は前回リリース済みのコードをベースにしているのに対し、E2E テストは日々更新される最新の develop に合わせてメンテナンスされているため、そのままでは UI の差分でテストが失敗します。この問題は、MagicPod ブランチ機能で解消しています。

# 運用フロー
 1. 木曜日：E2E テスト完了時点で MagicPod branch を作成
    └─ ブランチ名: release-candidate-lib/YYYY-MM-DD
 2. 翌週木曜日：前週に作成した branch を指定して、E2E テスト実行
 3. テスト完了後：branch を削除して、次のサイクルに備える

MagicPod の定期実行機能では branch を指定できない仕様のため、GitHub Actions から API 経由で branch を指定して週次で自動実行しています。

以上、QA チームの視点から、新しいリリース戦略を支える品質担保の仕組みについて紹介しました。開発チームと共に設計したこの体制により、週 2 回のリリースでも効率的な検証と高い品質維持を実現しています。

まとめ

今回リリース戦略の見直しにより、CLINICS 開発チームでは「品質」と「スピード」の両立に向けて土台を築くことができました。不具合発生時の原因切り分けは迅速になり、QA プロセスも効率化されています。今後はさらに、フロントエンドとバックエンドを個別にリリースできる体制や、日中に安心してリリースできる仕組みの整備にも取り組んでいく予定です。これらの改善を通じて、より柔軟に、そして迅速に、ユーザーにとって価値ある改善を届けられる開発体制を目指していきます。

We Are Hiring!

最後まで読んでいただきありがとうございます！

メドレーでは、開発プロセスの改善や自動化に情熱を注げるエンジニアを募集しています。もし私たちの取り組みに少しでも興味を持っていただけましたら、ぜひカジュアルにお話ししましょう！

テックリード候補バックエンド／CLINICS（株式会社メドレー）の求人情報です。 | HRMOS

株式会社メドレーエンジニアの求人一覧です。| HRMOS

「Medley Summer Tech Blog Relay」 23 日目は、医療プラットフォーム本部の前田さんの記事です！

痒い所に手が届く！Step Functions によるトイル削減

Wed, 24 Sep 2025 02:08:24 GMT

はじめに

この記事はメドレー夏のブログリレー 2025 21 日目の記事です。

SREグループは開発組織全体の中でも比較的少人数のチームです。そのため、腰を据えて事業やプロダクトに中長期的な価値を生む時間を作るためにも、トイルの削減に力を入れています。

繰り返し作業や自動化が可能なタスクを効率化する上で、AWS Step Functionsは非常に強力なサービスです。

本記事では、AWS Step Functions を活用し、1000を超えるデータベースのマイグレーション作業を自動化した事例を題材に、Step Functionsの 実践的な活用方法（tips） についてご紹介します。

メンテナンス作業のおおまかなワークフロー

DBのバックアップ（スナップショットを作成）
DBマイグレーションを実施
マイグレ後のDBスキーマチェック
ECS Task（アプリケーション）のデプロイ
完了/失敗通知を飛ばす

更新手順としてはごく一般的なワークフローかと思います。しかし、手順2で大量のデータベースをどのようにして夜間で更新しきるのかが課題となりました。

プロダクトの成長とともにデータベースの数が増えていくという特性上、なるべく変更管理の手間がかからない仕組みを導入しなくてはなりません。

Step Functions を用いたアプローチ

SREチームでは上述した課題に対して Step Functions によるメンテナンスを自動化することにしました。

AWS Step Functions とは？

ここでは、詳細な説明は割愛しますが、AWS Step Functions は複数のAWSリソースやサービスを統合してワークフローを構築するためのサービスです。 lambda で実装するには処理が複雑だったり処理時間が15分以上かかる場合、Step Functionsが選択肢となります。（AWS Step Functions は最大1年実行が可能）

1. Map ステートを活用する

Map ステートは同一ワークフローに異なる入力を与えてタスクを並列実行する（動的並列処理）機能です。 Map ステートに与える入力を増やす/減らすことでワークフローを変更することなく並列実行するタスクをスケールさせることができます。

これにより、大量のDBマイグレーションを同時に実行しメンテナンス時間の短縮をしただけでなく、変更に強いワークフローを構築することができました。

ワークフローの処理内容

各ブランチのマイグレーションタスクがどのDBのマイグレーションを実施するのかリストを作成（画像では3並列なので1 Taskあたり約333DBのマイグレーションを実行するように振り分け）
複数のECS Taskを立ち上げてマイグレーションを実施
DBスキーマをチェックして問題ないか確認

※各ステートごとにlambdaを用意すると管理しづらくマイグレーション処理も15分以上かかるため、メンテナンス作業用のコンテナイメージを別途、用意しています。

2. `.sync` を用いてDBマイグレーション完了まで待機させる

Step Functions では通常サービスを呼び出すと次のステートへ遷移しますが、.syncを用いることでジョブが完了するまで状態遷移を待機させることができます。

"更新対象のDBリストを作成": {
  "Type": "Task",
  "Next": "DBマイグレーションを実行",
  "Resource": "arn:aws:states:::ecs:runTask.sync",
  "Arguments": { /* 省略 */ },
  "Catch": [
    {
      "ErrorEquals": [
        "States.ALL"
      ],
      "Next": "更新処理の失敗を通知"
    }
  ]
},

上記のように記述することで、更新対象のデータベースリストを作成するECS Taskが終了しないと、次のステート「DBマイグレーションを実行」へ遷移しないようになります。

ジョブ完了状態のポーリングは DescribeTasks, ChoiceState, WaitState の組み合わせでも可能ですが、Step Functions は状態遷移回数によってサービス利用料が計算されるため、コスト的に優しくありません。

ただし、すべてのAWSサービスで.syncが利用できるわけではないので注意が必要です。

参考：最適化されたサービスと Step Functions の統合

実装時に意識したこと

1. ビジュアルエディタを活用する

AWS Step Functions のワークフローはJSON形式で定義する宣言型の Amazon States Language (ASL) で記述します。

シンプルなワークフローであればASLで書かれたワークフローを読むのもそこまで苦ではありませんが、分岐が複数あったり複雑なワークフローだと辛くなってきます。そこで、役立つのがビジュアルエディタです。

Step Functions のビジュアルエディタにはデザインモードとコードモードが存在します。デザインモードを活用することで、ワークフローの構造をビジュアルで確認することができます。

デザインモード

ドラッグ＆ドロップでアクションやフローを配置してワークフローの構築ができます。
コードを書く必要がなく直感的に操作することができます。

コードモード

ASLでワークフローを編集することができます。
他のStep Functionsワークフローをコピペして組み込んだりする時には便利です。
ASLの構文エラーはエディタから確認することができるので、間違いに気がつくことはできます。

2. TestState API を使い倒す

ワークフローを構成する各ステートはTestState APIで単体テストが可能です。特に参照系APIの戻り値をテストしたりJSONataのような書き慣れないクエリ構文のチェックに利用します。ただし、処理完了するまで待機する .sync やコールバックが返却されるまでStep Functionsが待機する .waitForTaskToken といったステートはTestState APIをサポートしていないため、その場合は.sync や .waitForTaskToken を外して検証します。

まとめ

本記事では、Step Functions を活用した運用トイル削減の取り組みとそこで得たTipsについて紹介しました。少人数のSREチームにおいて、手作業による運用コストの削減は重要な課題です。

Step Functions を使用することで、以下の成果を得ることができました：

定量的効果: 月6時間、年間72時間の工数削減
定性的効果: ヒューマンエラーの排除と心理的負荷の軽減
組織的効果: より価値の高い業務への時間投入が可能

特に、視覚的なワークフロー管理機能により、チーム全体での理解と保守性が向上したことは、持続可能な運用自動化において重要な要素でした。

今後も、運用業務の中で反復的に実施している作業を見つけ出し、Step Functions をはじめとしたAWSサービスを活用した自動化に取り組んでいきます。これにより、SREとしてのCLINICSの安定性と信頼性をさらに向上させていきたいと考えています。

次回は、医療プラットフォーム本部桶谷さん・小島さんの、「生成AI時代に向けて、開発効率10xを支えるリリース戦略の見直し」です。お楽しみに。

メドレーではエンジニアを積極採用中です！

株式会社メドレーエンジニアの求人一覧

共有と分離 ─ Compose Multiplatform “本番導入” の設計指針

※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

DroidKaigi 2025 参加レポート - Supporter Sponsor として協賛しました！

Thu, 18 Sep 2025 11:00:00 GMT

こんにちは、人材プラットフォーム本部CTO室の奥澤です。2025年9月、株式会社メドレーに入社して人材プラットフォーム本部へ配属されました。メドレーの人材プラットフォーム本部では既に複数のモバイルアプリを開発していますが、モバイルアプリ開発をさらに加速させていくためにジョインしました。

さて、9月に入って8月ほどの暑さはなくなり、夏の終わりを感じています。そして例年、自分にとって暑い夏の終わりと秋の始まりを告げるイベントである、DroidKaigiに今年も参加してきました！DroidKaigiは、日本国内で最大級のAndroidに関するカンファレンスです。

株式会社メドレーは、2025年9月10日から12日にかけて開催された、DroidKaigi 2025にSupporters Sponsorとして協賛しました。メドレーでは2021年からDroidKaigiに協賛しており、今年で5回目の協賛となっています。メドレーでは、DroidKaigiなどの技術カンファレンスへ継続的に協賛し、技術コミュニティを支援しています。

本記事では、DroidKaigi 2025の会場の様子と共に、印象に残ったセッションを紹介します。

会場の様子

DroidKaigi 2025は、ベルサール渋谷ガーデンで開催されました。DroidKaigi 2023から同じ会場で開催されています。今年も元気に会場にやってきました。

地下1階に設けられたコミュニケーションエリアには、協賛している各企業のブースが出展されていました。ブースを周り、各企業の話を聞いて歩くのはカンファレンスの大きな楽しみですね。それぞれの会社 / アプリの取り組みについて学び、さらに中の人に詳しい話を聞くことができるのは良いですね。

今年も気合いを入れてスタンプラリーをコンプリートしました。大量にノベルティもいただいたので、家族へのお土産になりました。全部のノベルティが嬉しいものですが、特に印象に残ったノベルティは、株式会社TVer様のタンブラー（かっこいい）、KINTOテクノロジーズ株式会社様のコースター（かわいい）、株式会社メルカリ様のキーキャップ（さっそく使ってます）でした。

セッションの様子

私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。

共有と分離 ─ Compose Multiplatform “本番導入” の設計指針

Kotlin Multiplatform（KMP）は、ここ数年で盛り上がっているクロスプラットフォーム技術で、ロジックをプラットフォーム間で共通化することができるものです。さらに、Compose Multiplatform（CMP）を用いることで、UIも共通化することができます。KMP / CMP、あるいはクロスプラットフォーム技術において、OSの境界をどう引くか？をいかに設計すれば少人数で生産性高くアプリを開発できるのか、という点に興味を持ちました。

本セッションでは、KMP / CMPとそのエコシステムの現状・限界を見極めながら、その本番導入を進めていった過程とその結果を発表されていました。最終的に約90%のソースコードをOS間で共有することができたそうですが、ネイティブで提供できる高品質な触り心地と、ソースコードの共有によって実装効率の向上を両立できた点は素晴らしいですね。

Kotlin Multiplatform (KMP) は、ネットワーク通信やドメインロジックを Android / iOS で共通化し、Compose Multiplatform (CMP) はそのうえ UI までを共通化します。両者を組み合わせれば、アプリの大部分を単一のコードベースで開発できることが大きな魅力です。ところが実プロダクトへの導入に踏み出すと・使いたいライブラリや SDK が KMP に非対応・OS 固有の API を直接呼びたい・一部の画面をネイティブ UI でリッチに作り込みたいといった理由で、 ”共有できない領域” が必ず現れます。本セッションでは、Android と iOS のエンジニアが共同登壇し、・プラットフォーム間でコードのどこを共有し、どこを分離するのか・開発速度 × ユーザ体験を両立させる設計・実装パターンを具体例とともに紹介します。実際に CMP を採用して半年弱で Android / iOS 両アプリをリリースしたプロダクトを題材に解説します。予定しているトピック：・共有の最前線　CMP + KMP 対応ライブラリの活用でどこまで共通化できるか・分離のテクニック　・Kotlin × Swift の DI 設計　・KMP に非対応の SDK の安全な統合　・CMP + ネイティブ UI のハイブリッド実装・両プラットフォーム視点で見る落とし穴と回避策 CMP 導入で必ずぶつかる ”共有できない領域” を見極め、必要に応じてコードを切り離すための指針をお伝えします。

2025.droidkaigi.jp

スマホ新法って何？１２月施行？アプリビジネスに影響あるの？

2025年12月18日に施行される、「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律」、いわゆるスマホ新法またはスマホ法について、公正取引委員会の方のセッションがありました。スマホ法の趣旨、スマホ法の施行によって何が変わるのか、スマホ法の施行によるアプリデベロッパーへの影響など、わかりやすく説明いただきました。

規制対象となる指定事業者に属していないエンジニアにおいても、スマホ法の施行によって今後どのようなことが起こっていくのか？しっかり理解しておいた方が良さそうだと感じました。セッションに参加したことで興味・理解が深まりました。

スマホ新法って何？１２月施行？アプリビジネスに影響あるの？

今年１２月に施行が予定されている新しい法律、スマホソフトウェア競争促進法（スマホ新法）。この法律がアプリビジネスにどのような影響を与えるのか、エンジニアのみなさまにどんな関係があるのか、公正取引委員会の担当者が解説します。例えば、・OS機能（通信機能等）の利用可能性の向上・新たなアプリストアの登場など決済手段の多様化・ウェブサイト等のアプリ外での商品提供の拡大・ソフトウェアの切替え時におけるデータ移転の円滑化・ユーザーによるブラウザや検索サービスの選択の促進などなど、これから見込まれる「変化」について説明します。

2025.droidkaigi.jp

Surviving Network Failures: Building Resilient Offline-First Flutter Apps

モバイル端末はネットワークが不安定な場所で使われることも多々あります。ネットワークが不安定な状況においてもアプリを使い続けられることは、ユーザーの体験として非常に重要であると考えます。そのためには、「オフラインファースト」でアプリの体験を設計することが必要になり、同時にオフラインファーストな体験を実現するための技術的な戦略も描く必要があります。

このセッションでは、オフラインファーストなアプリの体験を実現するためのUX / 技術的な戦略を提案しています。サンプルコードはFlutter / Dartですが、おおまかな内容はフレームワークによらず参考にできるものでした。セッションの内容については触れませんが、オフラインファーストでアプリの体験 / アーキテクチャを設計するためのガイドラインとなるセッションだったと感じています。

Surviving Network Failures: Building Resilient Offline-First Flutter Apps

What happens when your app loses internet, does it gracefully adapt, or does it leave users frustrated? In a world where connectivity is unpredictable, building offline-first apps isn’t just a feature; it’s a necessity. In this talk, we’ll explore battle-tested strategies to keep your Flutter app running smoothly, even in airplane mode. You’ll learn: Caching Like a Pro – Choosing between SQLite, Hive, Isar, or ObjectBox for local data storage. Syncing Without Breaking Things – Ensuring data consistency with background sync techniques. Handling Conflicts Gracefully – Avoiding data loss when multiple devices update the same record. Background Tasks & Work Managers – Keeping data fresh even when the app isn’t open. By the end of this session, you'll walk away with practical solutions to handle network failures, data synchronization, and seamless user experiences, whether your app is used in the subway, remote villages, or just a bad Wi-Fi zone.

2025.droidkaigi.jp

最後に

2025年9月10日から12日にかけて開催されたDroidKaigi 2025に参加してきました。Androidに関わる企業・人々が一堂に会するお祭りとして、楽しく、そして学びの多いイベントでした。主催者・スタッフ・登壇者・協賛企業など、関係者に感謝しつつ、弊社メドレーでもイベントや技術コミュニティを盛り上げていきたいと改めて思いました。

メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティに貢献しています。

メドレーではエンジニアを積極採用中です！

メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。モバイルアプリ開発の専門性を活かした医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！

Flutterエンジニア／人材プラットフォーム本部 | 株式会社メドレー

Flutterエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS

iOSアプリケーションエンジニア／melmo（総合医療アプリ） | 株式会社メドレー

iOSアプリケーションエンジニア／melmo（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS

Androidアプリケーションエンジニア／melmo（総合医療アプリ） | 株式会社メドレー

Androidアプリケーションエンジニア／melmo（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS

支払基金ってどんなところ？｜社会保険診療報酬支払基金

複雑な歯科電子レセプトを可視化するWebビューアを作ってみた

Thu, 18 Sep 2025 09:43:43 GMT

こちらの記事は「MEDLEY Summer Tech Blog Relay」の18日目の記事です🎉

今週はFY25新卒エンジニアの4人が連続して記事をお届けします！

はじめに

株式会社メドレーに 2025 年 4 月に新卒入社した、平林です。医療プラットフォームの歯科診療所事業部でソフトウェアエンジニアをしており、クラウド歯科業務支援システム「Dentis」を開発しています。

皆さんは病院や歯科医院で診察を受けた後、窓口で料金を支払っていると思います。ご存じの方も多いかもしれませんが、ここで払う料金は医療機関の収入の一部に過ぎません。

残りの診療報酬は患者が加入している保険組合（保険者）から支払われることになっており、医療機関は毎月患者に行った診療をまとめた書類（診療報酬請求書、通称レセプト）を作成して支払基金（国保の場合は国民健康保険団体連合会）に請求します。以下は、社会保険に加入している患者の診療報酬請求の流れです。

www.ssk.or.jp

このレセプトをコンピューターを使って自動で作成してくれるのが、レセプトコンピューター（レセコン）です。

今回は、このレセプトについて学習するために、レセプトビューアを作ってみました。

ソースコードは以下で公開しています。

GitHub - avaice/dental-uke-reader

Contribute to avaice/dental-uke-reader development by creating an account on GitHub.

GitHub - microsoft/markitdown: Python tool for converting files and office documents to Markdown.

電子レセプトについて

レセプトには、紙レセプトと電子レセプトの2種類があります。元々は紙レセプトのみでしたが、現在はそれをデータ化した電子レセプトが主流となっています。

電子レセプトはCSVライクなカンマ区切りのフォーマットとなっており、UKEという拡張子で保存されます。

以下は、一般的な電子レセプトの例です。※データは架空の情報です

UK,2,13,3,1234567,,メドレークリニック,202201,0117,00
IR,2,13,3,1234567,,202201,03-1234-5678,0117
RE,4,3318,202112,歯科　太郎,1,19400808,,,20210609,1,,,29,,123456/8,,,,,,,,,,シカタロウ,
HO,39141320,,２３５７２４４９,2,1279,,,,,,,,
JD,1,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,,
MF,00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
HS,,,101700101500101400101300101200101100102100102200102300102400102500102600102700104800104500104400104300104200104100103100103200103300103400103500103700,5234009,,,,,,,,
SS,12,1,301001610,,,CA062,,CA045,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,57,2,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,,
(...以下省略)
GO,116,155332,99

一見よくわからないデータですが、社会保険診療報酬支払基金のWebページには「オンライン又は光ディスク等による請求に係る記録条件仕様（歯科用）」（以下、仕様書）が公開されているので、それを見ながら読み進めていきます。

電子レセプトの作成｜社会保険診療報酬支払基金

www.ssk.or.jp

1列目には「UK」と書いてあります。これはレコード識別情報です。

レコード識別情報の一覧は、以下のとおりです。

値	レコードの種類	データの一例
UK	受付情報レコード	審査支払機関・医療機関コード・都道府県など
IR	医療機関情報レコード	医療機関コード・連絡先・請求年月など
RE	レセプト共通レコード	患者（被保険者）の名前・性別など
HO	保険者レコード	保険者番号・合計点数など
KO	公費レコード	負担者番号公費負担者番号など
SN	資格確認レコード	負担者種別や受給者番号など
JD	受診日等レコード	日別の受診等区分など
MF	窓口負担額レコード	高額療養費の扱いなど
HS	傷病名部位レコード	傷病名コード・部位の歯式コードなど
SS	歯科診療行為レコード	診療識別・歯科診療行為コードなど
SI	診療行為レコード	医科診療行為コードなど
IY	医薬品レコード	診療で使用した医薬品・院内で処方した医薬品など
TO	特定器材レコード	特定器材コードなど
CO	コメントレコード	診療識別・コメントコードなど
SJ	症状詳記レコード	症状詳記（診療内容が明確でない場合などに記録する）など
GO	診療報酬請求書レコード	総件数など

この値によってこの行がどんな情報を含んでいるのか判別することができます。

今回はUK（受付情報レコード）だけ見てみましょう。仕様書と照らし合わせると、以下の内容であることが分かります。

値	説明	備考
1	審査支払機関	1: 社会保険診療報酬支払基金、2: 国民健康保険団体連合会
13	都道府県コード	総務省が定める都道府県コード(URL) 16: 富山県
3	点数表種別	点数表種別 3: 歯科他にも、1: 医科, 4: 調剤など
1234567	医療機関コード	医療機関コード
(空欄)	予備エリア
メドレークリニック	地方厚生（支）局長に届け出た名称	20文字を超える場合は、決まっている省略名称になる
202201	請求年月	レセプトが請求される年月。例: 2022年1月
0117	施設基準届出コード	2文字区切りで解釈される。01:補管（クラウン・ブリッジ維持管理料）17:歯科初診料
00	マルチボリューム識別情報	フロッピーディスクなど容量の少ない媒体を使用する際、レセプト情報が複数のファイルに分割されている場合に、そのファイルの順番を示す

このような形で各行を読んでいくと、電子レセプトが示している内容が分かります。

レセプトの読み方がなんとなく分かったので、次は実際にこれを読み込むプログラムを作ります。

CSVを読み込んでパースする

電子レセプトはShift-JISで記録されているので、文字コードを指定して読み込みます。

const loadFile = (file) =>
  new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.onload = (e) => {
      const text = e.target?.result;
      if (typeof text !== "string") {
        reject(new Error("Failed to load the file"));
        return;
      }
      resolve(text);
    };
    reader.onerror = () => {
      reject(new Error("Failed to read the file"));
    };
    reader.readAsText(file, "shift-jis");
  });

読み込んだあとは、UKEデータをパースします。

CSVのパースは考慮することが多くエンジニア泣かせで有名ですが、UKEの仕様は非常にシンプルなので簡単にパースできます。

（以下は、一部抜粋です）

符号名称	図形記号	用途
コンマ	`,`	項目の区切りを表現する
引用符	`"`	使用しない
改行コード	`\n`	レコードの区切りを表現する

const csv = await loadFile(file);
const receipts = csv
  .trim()
  .split("\n")
  .map((line) => line.split(","));

項目の説明を表示する

行ごとのレコードと列番号を渡すと説明が返ってくるロジックを作ります。

説明情報は、社会保険診療報酬支払基金のWebページに公開されている「電子レセプトの作成手引き」を参考にします。

「電子レセプトの作成手引き」はPDFで公開されているデータですが、 markitdown を使ってマークダウンに変換し作業スペースに置くことで、CursorやClaude Codeといった開発支援ツールを活用して効率的に実装を進めることができました。

Python tool for converting files and office documents to Markdown. - microsoft/markitdown

export type RecordType = {
  index: number;
  data: string[];
};
export const explain = (record: RecordType) => {
  switch (record.identification) {
    case "UK":
      return explainUK(record);
    case "IR":
      return explainIR(record);
    // ...省略
    default:
      return null;
  }
};

値によって説明が変わる内容もあるので、動的に説明文を作れるようにしました。

const explainUK: (((record: RecordType) => string) | string)[] = [
  "この行が受付情報レコードであることを示します",
  (record) =>
    `審査支払機関を示します。値「${record.data[record.index]}」は「${getShiharaiKikan(record.data[record.index])}」です`,
  // ...省略
];

マスターファイルから情報を取得する

UKEの中にはそのまま解釈できる内容だけでなく、診療行為コードや医薬品コードのような別のデータ（マスターファイル）を参照しないと内容がわからないものがあります。

マスターファイルや仕様は、厚生労働省がWebで公開してくれています。

診療報酬情報提供サービス

shinryohoshu.mhlw.go.jp

マスターファイルは電子レセプトと仕様の違うCSVで、以下のような仕様になっています。

項目間の区切り文字は「,」（カンマ）とする。
各項目の値は、モード（「数字」、「英数」及び「漢字」）に関わらず、引用符「”」（ダブルクォーテーション）を前後に付す。
最大バイトは引用符「“」を除いたバイト数であり、小数部がある値は、小数点及び小数以降の数字を含む。
０バイトの文字列（Null）の場合は、引用符「“」を続けて記録する。

値をダブルクォーテーションで囲むとのことなので、値の中のカンマを許容する仕様である可能性があります。愚直に1文字ずつ処理します。

// const csv = 生のCSVデータ;
const lines = csv.split("\n");
const records: Record<string, string>[] = [];
const shobyomeiMasterHeaders = ["変更区分", "マスター種別", "傷病名コード", /** 以下省略... */];
for (const line of lines) {
  const record: Record<string, string> = {};
  let charIndex = 0;
  let columnIndex = 0;
  let inQuotes = false;
  let buffer = "";
  while (charIndex < line.length) {
    const char = line[charIndex];
    if (char === '"') {
      inQuotes = !inQuotes;
    } else if (char === ',' && !inQuotes) {
      // カンマ区切り、かつ引用符の外
      record[shobyomeiMasterHeaders[columnIndex]] = buffer;
      columnIndex++;
      buffer = "";
    } else {
      // それ以外はバッファに追加
      buffer += char;
    }
    charIndex++;
  }
  if (buffer.length > 0) {
    record[shobyomeiMasterHeaders[columnIndex]] = buffer;
  }
  // データベースへの保存
  await saveToDatabase("shobyomei", record.傷病名コード, [record]);
}

マスターファイルは全部で20MB程度あり、毎回処理していたら時間がかかってしまうので、indexedDBに展開しました。

これで、診療行為コードや医薬品コードを基にマスターの内容を参照できるようになりました。

ここで一つ気をつけなければいけないのは、医薬品コードの情報には有効期限があるということです。

該当するレコードの診療日が、変更年月日〜廃止年月日の間であることを確認する必要があります。例えば2015年のレセプトから情報を得たいのであれば、2015年時点のマスターファイルを参照する必要があります。

そのため、時系列に合った複数バージョンのマスターを保持できる設計にするために、キーに対してデータは配列で持つようにしました。

表としてレンダリングする

UKEのパーサーと情報の取得処理が書けたので、表としてレンダリングします。

type CellPosition = { x: number; y: number };
const UKERenderer = ({ uke }: { uke: string[][] }) => {
  const [activeCell, setActiveCell] = useState<CellPosition | null>(null);
  const handleClickCell = (x: number, y: number) => setActiveCell({ x, y });
  const isActiveCell = (x: number, y: number) =>
    activeCell && activeCell.x === x && activeCell.y === y;
  return uke.map((row, y) => (
    <Row key={`row-${y}`}>
      {row.map((value, x) => (
        <Cell
          key={`cell-${x}`}
          onClick={() => handleClickCell(x, y)}
          active={isActiveCell(x, y)}
          description={explain({ index: x, data: row })}
        >
          {value}
        </Cell>
      ))}
    </Row>
  ));
};

実際に開発したもの

実際に開発したものは、今まで解説したコードをベースに機能や処理を付け加えています。

開発してみて

以前は、テキストエディターを使って目視でマスターファイルの内容を照らし合わせており確認作業が大変でしたが、今回作った電子レセプトビューアによって、正しくレセプトが出力されているかの確認が行いやすくなりました。

また、自分自身も電子レセプトの仕様を学んだことで、業務で行っていることが少しずつ分かるようになってきました！

おわりに

今回は、歯科の電子レセプトを理解するために、電子レセプトビューアを開発しました。

私たちソフトウェアエンジニアは、普段医療に関するシステムの話をあまり目にすることは少ないですが、意外と仕様やデータが一般にも公開されており、手軽に触れてみることができます。

この記事を読んで、医療ITに興味を持ってくださる方がいれば幸いです！

次は、新卒エンジニア4人目の池田さんです！お楽しみに！！

「誰でも使える」ように、ジョブメドレーの求職者向け利用規約を刷新します

Fri, 12 Sep 2025 02:20:57 GMT

この記事は「MEDLEY Summer Tech Blog Relay」 15 日目の記事です。

はじめに

こんにちは！人材プラットフォーム本部プロダクト開発部の小泉(@kzmkt)です。
医療介護従事者向けの求人メディア「ジョブメドレー」開発チームの一員として、主にフロントエンドのエンジニアをしています。

今回、2025年10月の利用規約改定に備えて、利用規約ページを刷新しました。
→ 改定版周知のための利用規約ページはこちら

ジョブメドレーは「誰でも使える」サービスを目指してデザインリニューアルのプロジェクトに取り組んでいます。
→ 「誰でも使える」ように、アクセシビリティ向上に向けて取り組んだこと

この記事では取り組みの背景、具体的な開発プロセスとソフトウェアエンジニアリングについて、プロジェクトメンバーの話も交えて紹介させていただきます。

今回のプロジェクトでは利用規約を読みやすくするために、総合的な観点が必要だったので、法務担当・外部弁護士・デザイン部・開発チームの共同プロジェクトとして進めました。

利用規約を刷新する理由

利用規約刷新の具体的な背景と課題について、事業企画室の小松さんとデザイン部の佐竹さんにお話を伺いました。

事業企画室小松さんのコメント

ジョブメドレーの利用規約は、あらゆるケースを想定した抽象的で抜け漏れのない規定が必要となります。
そうした文章はともすると、冗長で専門的な用語が多用されるため、誰にとっても読みやすいものとはいえません。
また、サービス規模にあわせて最適な状態に改定してきたものの、運営が15年にもなると複雑でわかりやすいとはいえない規約となっていました。

今回の取り組みでは、わかりづらさを解消し、誰にとってもわかりやすい利用規約を目指すため、以下のような対応を実施しました。

冗長な文章を箇条書きや表形式に変更する
条文が適用されたときの具体例を記載する
「〜を承諾するものとします」や「〜に帰属するものとします」など、法律的な言い回しを可能な限り平易なものに変更する
章立ても含めた規約の構成をすべて見直す

デザイン部佐竹さんのコメント

旧デザインの課題

デザインの視点から見た旧デザインの課題は大きく3つあります。

情報構造が不明瞭で、ページ全体の流れをつかみにくい
文字サイズや太さに強弱がなく、重要な情報を見つけづらい
装飾的な補助要素がなく、内容を直感的に理解しにくい

新デザインでの解決策

新デザインでは、読む負担を減らし、内容を把握しやすい表現を意識しました。

適切な余白を設け、テキストをブロック単位で整理
目次を追加し、見出しサイズを最適化することで、章や節の構造を一目で把握しやすく改善
キーワードをフォントウェイトで強調し、重要情報を直感的に理解可能に
イラストを追加し、複雑な内容をサポート。長文の合間に配置することで、読解のストレスを軽減
背景色付きの注釈で補足説明や注意事項を目立たせ、必要な情報をすぐに把握できるように

ジョブメドレーは2009年11月にサービスを開始しました。

サービスが成長していく中で法改正以外でも利用規約を更新し続けており、その時々では最善を尽くしてきたものの、たび重なる改定により、結果として複雑で読みにくい利用規約になってきてしまっていました。
そのため、今回の改定で全面的に見直しを行い、よりわかりやすい構成と内容に改定することにしました。

使用技術と開発プロセス

ここからは分かりやすい利用規約の実現及び「誰でも使える」ジョブメドレーの実現に向けた、アクセシビリティに配慮した開発について紹介します。

ジョブメドレーにはさまざまな開発チームがあり、各チームが並行して機能開発や改善を進めています。多様なチーム構成の中では、チーム間の違いに加えて、企画者・デザイナー・エンジニアなどポジション毎でも、アクセシビリティに関する知見のレベルは様々です。

また、現在は協力会社のサポートを受けながらアクセシビリティに配慮した開発を進めており、今後のアクセシビティ対応の内製化に向けて、ジョブメドレーのエンジニア全員が「誰でも使える」を「誰でも作れる」ようにする必要があります。

今回は以下のプロセスで開発を行いました。

企画・仕様策定
デザイン作成
開発
- デザインコンポーネント開発
- 画面全体の作り込み
- ロジックの実装
- アクセシビリティレビュー
QA
リリース
監視
運用

今回は「デザインコンポーネント開発」および「アクセシビリティレビュー」における取り組みの一部をご紹介します。

どの画面でも変わらないアクセシビリティ品質を提供する開発プロセス

今回の利用規約ページでは、デザインコンポーネントとロジック実装を完全に分けて開発しており、デザインコンポーネント開発段階でアクセシビリティに配慮した実装を行っています。
Storybookを用いてアクセシビリティの品質が担保されたコンポーネントを開発し、それらを組み合わせることで各ページを作成しています。

アクセシビリティ勉強会でStorybookの利用方法を共有

ジョブメドレー開発チームではアクセシビリティ勉強会を実施しており、FigmaのデザインからStorybookを用いたデザインコンポーネント開発を行う際の注意点を紹介しています。
コンポーネント毎にジョブメドレーで目指すアクセシビリティが担保された状態を目標に開発しています。

利用規約ページにおける各項目要素のコンポーネントを作成

今回の利用規約ページでは、各要素に対応したコンポーネントを作成しました。
それぞれのコンポーネントを組み合わせることで、各章や注釈の構造を明確にしています。

ツールやAIによる形式レビューと人による総合的なレビュー

アクセシビリティへの配慮は最終的には人の手と目で確認しなければ、本当に必要な対応ができているかを判断することができません。しかし、開発現場では全てを人の手と目で確認することは必ずしも現実的ではありません。

そこで、段階的なレビュープロセスを実施しています。

初期確認
- AIによる各コンポーネントの実装およびアクセシビリティのレビュー
- 既存の実装と類似している箇所の事前自動チェック
ページ作成時
- ブラウザのアクセシビリティチェックツールによる確認
最終確認
- VoiceOverやPC Talkerを用いた実機での確認
- ジョブメドレー独自のルール、実際の使用感も含めた人によるレビュー

この仕組みによりレビューコストを減らしつつ、より本質的なアクセシビリティの課題に取り組めるようにしています。

AIによるレビュー

ジョブメドレーではAIによるプルリクエストのレビューを行っています。

アクセシビリティ観点だけでなく、開発初期段階におけるレビューとして、既存実装との整合性や単純な実装ミスのチェックはAIに任せています。
この結果、一定の精度をクリアしたものを人間のレビューに回すことになり、負荷を減らしています。

ブラウザのアクセシビリティツールによるチェック

ブラウザ拡張ツールのaxe DevTools®を用いて、ページのアクセシビリティチェックを実施しています。

これにより基本的なアクセシビリティ課題は自動的に検出することができ、一定の品質を担保できるようにしています。

利用規約ページに合わせた人によるレビュー

AIやツールによる自動チェックでは対応しきれない部分について、人によるレビューを行っています。
アクセシビリティに可能な限り配慮しつつ、ジョブメドレー固有のユーザビリティ要件や使用感も担保できる状態を目指してレビューします。
自動化できる部分は事前にAIやツールでチェックしているため、人によるレビューではより本質的で高度な判断が必要な部分に集中することができます。

VoiceOver・PC Talkerを用いた実機確認

実機での読み上げ、タップ操作、キーボード操作の確認を行います。

開発者用の検証ツールと実機では、読み上げや操作に差異が起きる場合があります。
利用者を想定して、実際のPCやスマホ上でも問題のない表現になっているかを改めて確認しています。

サービス体験をより良いものにするために、ウェブサービスは人間だけでなく機械が読みやすい文章にする必要があります。これをマシンリーダビリティと呼び、読み上げツールがより適切なアウトプットを行うことができ、ユーザ体験が向上します。
アクセシビリティに配慮した開発を行う中で読み上げツールに対応した表現になるようにしています。マシンリーダビリティも担保できる形になっています。

アクセシビリティに配慮したウェブサービスを提供することで、人間だけでなく読み上げツールやAIなどの機械にも扱いやすいサービスを作ることができます。

今回の学び

利用規約の刷新を行う中で様々な気づきがありました。

アクセシビリティに配慮できているウェブサービスであるかどうかは、実際に画面がどのようにHTMLとしてマークアップされるかによって決まります。
そのため、コンポーネント作成段階からアクセシビリティに配慮した開発を進めていくことで、実際の画面を作り込むときのチェックが行いやすくなり、実装者とレビュワーのそれぞれが注力すべき箇所がより明確になります。

コンテンツページのアクセシビリティ

静的コンテンツページでの表示はシンプルですが、ただ純粋に文章を羅列するだけではなく、適切なマークアップが必要になります。適したHTML表現を行うことで、アクセシビリティに配慮したセマンティックなWebページを作ることができます。

今回、一般的なページの開発ではあまり見かけないHTMLタグも使用しています。

HTMLタグ	説明
`<small>`: 附随コメント要素	HTML4.1では小さい文字を表現するものでしたが、HTML5ではスタイルの表現とは独立して、著作権表示や法的表記のような、注釈や小さく表示される文を表す仕様に変わっています。
`<address>`: 連絡先要素	個人、団体、組織の連絡先情報を提供していることを示しています。

利用規約の各要素に明確に意味を持たせることを意図して使用しています。

WCAG2.1 AAAへの配慮

ジョブメドレーではWCAG2.1の適合レベルAおよびAAに配慮した、Webサービス作りを行っています。今回の利用規約の刷新において、結果的にWCAG 2.1 AAA（日本語版: WCAG 2.1）にも一部配慮したページになりました。

基準名	達成基準	対応内容
達成基準 2.4.10: セクション見出し	セクション見出しを用いて、コンテンツが整理されている。	各セクションで`<h1>~<h6>`タグを使用して、内容や項目を明確に示す見出しを作成
達成基準 3.1.5: 読解レベル（※達成途中）	固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。	文章全体として、簡潔な文章となっており、前期中等教育レベルでおおよそ読解できる状態

※ 今回の利用規約刷新では、達成基準 3.1.5 読解レベルを目指していますが、まだ完全に平易なものにはなっておらず改善の余地があります。
この達成基準を目指して改善を重ねていければと思います。

まとめ

今回の利用規約刷新では、「多くの人にとって読みやすい」利用規約ページとなるように、これまで以上に、丁寧なアクセシビリティに配慮したページを作成しました。

また、開発チームにもさまざまな知見が溜まりました。
アクセシビリティに配慮した開発に終わりはなく、今後も続いていきます。
ジョブメドレーでは全てのチームがアクセシビリティに配慮したプロダクト作りを行い、これまで以上に「誰でも使える」ジョブメドレーを目指して行きます。

We Are Hiring!

最後まで読んでいただきありがとうございます！

メドレーでは一緒にプロダクト開発をしていただけるエンジニア・デザイナー・ディレクターを募集中です。
少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！

「Medley Summer Tech Blog Relay」 16 日目は、医療プラットフォーム本部の山田さんの記事です！

数字でみるメドレーのAI活用現在地点とこれから

Mon, 08 Sep 2025 00:00:00 GMT

この記事は「MEDLEY Summer Tech Blog Relay」11 日目の記事です。

はじめに

こんにちは、メドレーでAI推進している人材プラットフォーム本部 VPoE の倉林(@terukura)です。

前回の記事「AI for All - 全社でAI活用を推進する取り組み」でお伝えした通り、メドレーでは「AI for All」を合言葉に、全社的なAI活用を推進しています。あれから約4ヶ月が経過し、プロダクト開発チームにおけるAI活用は大きく前進しました。

本記事では、メドレーのプロダクト開発におけるAI活用の現在地を、具体的な数値とともに振り返ってみます。

AI活用に関する発表では、制度としての一人n万円の支援制度、全社Cursor/Claude Max Plan導入、全社でn億円の投資などマクロな数字が注目されがちですが、本記事ではなるべく実際にどのツールをどれくらい使っているのか、具体的な利用状況を公開している例は意外と少ないため、皆様の参考になれば幸いです。

1〜2週間ごとに新しい技術やツールが登場する昨今、最適解はないと感じています。各社の状況や文化に合わせ変化に強い組織を作ることが重要だと考えています。あくまで一つの事例として、メドレーの取り組みをご紹介します。

メドレーのプロダクト開発におけるAI活用の方針

メドレーでは、以下の3つの方針を軸にAI活用を進めています。

1. ツールに縛られない柔軟な選定

特定のAIツールやサービスに固執せず、AI技術やモデルの進化に合わせて最適なツールを選定しています。例えば、コーディング支援ツールだけでも複数のオプションを並行して検証し、用途や開発者の好みに応じて使い分けています。

2. 継続的なモニタリングと改善

導入して終わりではなく、日々の利用状況や生産性向上の効果を定量的にモニタリングし、PDCAサイクルを回しています。月次でROIを評価し、効果が薄いツールは見直しを行います。

3. 開発プロセスへの深い統合

GitHub ActionsでのAIレビュー自動化、監視/アラートへのAI組み込みなど、開発プロセスの各段階にAIを統合しています。これにより、エンジニアが意識せずともAIの恩恵を受けられる環境を構築しています。

現在メドレーで利用・検証中の主なAIツール・サービス

2025年9月時点 で、メドレーでは以下のAIツール・サービスを主に活用しています。

コーディング支援ツール
- Claude Code、Cursor、Devin、Codex、GitHub Copilot、Gemini CLI
AIモデルプロバイダー
- Google Vertex AI、Azure OpenAI、AWS Bedrock、Anthropic API、OpenAI API、BytePlus ModelArk
ワークフロー・自動化
- Dify、n8n
コードレビュー支援
- Claude Code Action、CodeRabbit、GitHub Copilot Review、Devin Review
チャット・汎用AI
- ChatGPT Team、Claude Team 、Gemini
その他のツール
- Langfuse、NotebookLM、Dia、Perplexity、Snyk、Mastra

数値でみる主な利用状況

Claude CodeについてはパワーユーザーはMax Plan、その他の利用者向けにはVertex AI経由で提供
GPT-5の登場により徐々にCodex CLIの利用も増加傾向（TeamPlan/ProPlan）
利用ModelとしてはClaude Sonnetの割合が高い、次点でOpus・GPT（Claude Max Plan ユーザー除く）
Difyについては徐々に全従業員が触れ合うツールになりつつある、Model+Prompot+フローの検証利用としても拡大中
トータルで350-400万円/月　くらいがコスト観点での現在地

生産性への影響、FourKeysの変化などはまた次の機会に詳細を共有させていただければと思っています。

今後の展望

AI駆動開発（AI-Driven Development）への移行

AIが開発の中心となる新しいパラダイムへの移行を目指します。

自然言語での要件定義から実装までの自動化
AIエージェントの本格導入・開発
AIによるUI/UX設計・プロトタイピング
AIによるアーキテクチャ設計の提案・レビュー
CI/CDパイプラインとの深い統合
QA自動化
パフォーマンス最適化の自動実行
インシデント対応・管理の自動化

今回は主にプロダクト開発におけるAI活用の現在地点を利用状況を元に振り返ってみました。 「同じような利用状況の方」、「もっと活用している方」、「まだまだ未活用で活用方法を聞きたい方」 などぜひ詳細など情報交換させていただければと思います。

直近はMEDLEY AI CLOUDの発表や、今回のMEDLEY Summer Tech Blog RelayでのAI関連の記事など AI関連の発信もどしどし行っていますので、ぜひ興味をもっていただければと思います。

明日の「MEDLEY Summer Tech Blog Relay」の記事は、デザイナーの近藤さんです！

We’re hiring!

メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！

カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！

メドレーのエンジニア組織・AI活用についてお話します！

医療エンジニアリング領域盛り上がっています！メドレーについてお話します！

「メドレーのエンジニア組織・AI活用についてお話します！」- 倉林昭和さん

The rise of "context engineering"

データ戦略グループにおけるcontext engineeringの取り組み

Mon, 01 Sep 2025 00:00:00 GMT

この記事はメドレー夏のブログリレー 2025 6 日目の記事です。

はじめに

こんにちは、医療プラットフォーム本部データ戦略グループの安東です。データ戦略グループでは、データ基盤の構築から可視化、分析、ダッシュボード作成まで担い、データ活用を促進することで事業成長と医療ヘルスケアの未来に貢献することをミッションにしています。そのため、日々データを扱う業務をしているのですが、最近チームでこんな議論がありました。

「AI を用いてデータ分析する際にテーブルのメタデータだけでなく、ビジネスロジックや過去の分析知見、議論の文脈まで理解させることが大切だよね。」

皆さんのデータアナリスト組織でも、AI を活用したデータ分析で同じような課題を感じることはないでしょうか。当社もデータ分析の生産性を高めるため、Cursor や ClaudeCode といった AI ツールを積極的に活用しています。

その過程で、データアナリストに新たな価値提供の機会が広がっていると感じており、その鍵となるのが「 context engineering 」と考えています。

context engineering とは、 AI がタスクを達成できるように、適切な知識・ツール・求める出力形式を提供することです。（参考：The rise of “context engineering”）

今回は、「Analytics Knowledge as Code」という形で、分析における context engineering の取り組みについてお話しします。なお、Analytics Knowledge as Code の考えは、AWS Summit で紹介されていた「AI Agent 時代のソフトウェア開発の型〜 Everything as Code で叡智を伝える〜」の内容を参考にしています。

AI によって変わる分析の風景

生成 AI の登場で、SQL の記述、前処理、集計、可視化といったデータ分析作業の多くが効率化できるようになりました。

では、すべての分析業務が AI に置き換えられるでしょうか？

少なくとも現時点では、分析業務にはグラデーションがあり、AI に置き換え可能な領域とそうでない領域に分かれると思います。

下図のように、分析要求の複雑性によって、データ分析における AI と人間の役割が分かれてきています。

単純なデータ抽出やレポート作成は、BI ツールによるセルフサービスで十分です。やや複雑な要件も、AI Agent で対応できつつあります。

しかし、複雑性の高い分析ではステークホルダーと議論しながら曖昧な要件を明確にし、分析の定義、解決する問いのディスカッションを通じて、意思決定を支援することが求められます。

事業部と認識を揃えつつ、丁寧な合意形成も欠かせません。

この領域のデータアナリストには、課題を主体的に定義し、その内容に即した最適な分析アプローチを設計する力が、核心的な価値として求められるようになってきています。

データ分析は過去・現在のコンテキストが重要

ここで重要なのは、企業での分析は一度きりの独立したタスクではないということです。過去の分析結果や現在の議論状況に依存する性質を持っています。

例えば、解約率の分析を行う際には、単に数値の変化を見るだけでは不十分です。

過去の解約要因、顧客セグメントの特性、競合サービスの動向、外部環境の変化といったコンテキストがあってこそ、意味のある洞察が得られます。

一例ですが、メドレーのような医療ヘルスケア領域では、以下のような特殊な文脈が重要になるケースもあります：

診療報酬改定: 制度変更が事業指標に与える影響
季節性: 疾病の流行期や健康診断シーズンなど医療特有のパターン
規制環境: 関連省庁のガイドラインの変更等
業界慣習: 医療における事業者の意思決定プロセスの変化

こうした蓄積された文脈（コンテキスト）があってこそ、質の高い分析が可能になります 。

しかし、モデルは自動的に賢くなっていく一方で、このコンテキストの整備は人間に委ねられています。

リソースは有限なので、求められる品質やビジネス要件を満たして期日までに意思決定を行うためには、AI が効率的に活用できるよう適切なコンテキストを整備することが不可欠です。

Analytics Knowledge as Code：なぜ今、この考え方が重要なのか

そのため、分析ナレッジを「コード化」する Analytics Knowledge as Code の取り組みを始めています。その背景には 3 つの課題があります。

1. 分析による意思決定過程のナレッジ共有の課題

多くの分析組織では、事業部に専属のデータアナリストが配置される体制を取っているケースが多いと思います。この体制では、各事業のデータ構造の知識や成り立ち、過去の分析インサイトが、一人のデータアナリストに集中しがちです。当社でもデータ分析チーム全体として、共通知見を蓄積することに課題があります。

2. AI には人間向けドキュメントだけでは不十分

社内 Wiki や分析ドキュメントは人間が読むことを前提としていますが、AI が効率的に参照・活用するには構造化された情報が必要です。特に重要なのは、コンテキストエンジニアリングにおいて、AI に広範囲を探索させるよりも、探索させる空間を狭くして、その空間内の情報の質を高めるアプローチの方がより期待に沿った応答を返してくれるという点です。そのため、データ分析における AI が参照するナレッジは共通化して、品質の高い状態を管理する価値が高いと考えています。

3. 再利用性と保守性の担保

ナレッジは日々更新されていくため、継続的に更新し、信頼できる状態を担保する必要があります。ソフトウェア開発のように、バージョン管理、レビュープロセス、継続的な改善 を分析ナレッジにも適用することで、組織全体の分析品質を向上させることが必要になります。

コンテキストを「コード」として管理する手法

Analytics Knowledge as Code は、データ分析における知識やノウハウを、ソフトウェア開発のコードと同様に管理・共有する考えです。

管理する方法として、GitHub リポジトリを活用したナレッジ管理により、以下の要素を実現します。

データカタログやプロンプトエンジニアリングでは難しい領域をカバーします。

項目	内容
分析ナレッジの保守	分析結果のテンプレート化による標準化、バージョン管理による変更履歴の追跡
ビジネスロジックの反映	対象の分析がどのようなビジネスモデル、ロジックなのか理解させる
お手本 SQL や分析手法の例示	AI にゼロから判断させずに、参考になる SQL や分析パターンを参照させる
過去分析の知識	過去の分析議論過程や意思決定の内容を参照させる

Analytics Knowledge as Code のイメージ：GitHub リポジトリに分析ナレッジ蓄積

私たちは分析プロジェクトごとに、上図のような構成で、ナレッジを GitHub リポジトリで管理する取り組みを始めています。

これにより次回の分析では、過去のナレッジをベースに、条件の検討や定義のズレによるコミュニケーションエラーを減らすことができています。

今後、メンバーに変更があった際にも、過去の分析上の判断根拠を理解した上で分析に取り組めるようになることを目指しています。

MCP を活用したコンテキスト補完

ナレッジリポジトリと MCP を組み合わせることで、AI が分析時に過去の知見を参照できるようにしています。

この取り組みにおいて重要なのは、「人間が決めて、AI が分析を実行する」という以下のような役割分担です

項目	内容
問題定義	データアナリストがステークホルダーと協力して課題を明確化
分析実行	AI が SQL 生成、前処理、基本統計の処理、可視化といった分析ワークフローの実施
結果解釈	データアナリストが主導し、AI が集計結果から解釈を支援
意思決定	最終的な判断は必ず人間が行う

このような役割分担を実現するために、AI が効率的に動作するための意思決定過程の言語化と構造化された文脈の共有が不可欠になります。

そのため、私たちは以下の要素も体系的に管理することを目指しています：

項目	内容
ドメイン知識	医療業界特有の制約や業界慣習
ステークホルダー情報	各事業部のビジネス戦略、ロードマップ、意思決定軸
過去のプロジェクトの意思決定履歴	会議の議事録や議論の文脈
データ定義と品質ルール	テーブル構造やデータの具体的な使い方

これにより、データアナリストが持つドメイン知識を組織の資産として活用し、より質の高い分析を効率的に行えるようになることを想定しています。

AI とデータアナリストの役割分担

AI はデータ集計やクロス集計といった処理を得意とし、膨大な情報を効率的に整理することができます。

一方で、「何を解くべきか」という問いを立てたり、仮説検証の結果をどう意思決定につなげるかといった部分は、人間だからこそ担える役割です。

単純な集計や事象確認は AI に任せることでスピードと効率を得られますが、複雑なテーマでは過去の分析や議論、外部環境を踏まえて設計し、ステークホルダーと議論しながら最適な進め方を探る必要があります。

ときには分析にかけるコストと成果を比較し、データ分析以外の手段を選ぶ判断も求められます。

つまり、AI は「効率的に分析を実行する力」、データアナリストは「問いを設定し意思決定へ橋渡しする力」を発揮することで、それぞれが補い合いながら最大の価値を生み出していくと考えます。

AI × 人間のベストな協働を目指して

Analytics Knowledge as Code は、こうした新時代のデータアナリストに求められる能力を組織レベルで実現するための取り組みです。

LLM のモデルは今後も性能が向上していきますが、コンテキストの整備は組織が担う必要があります。

AI エディタや GitHub Copilot などのツールにより、従来はエンジニアの専門領域だったコードやリポジトリの管理の障壁は大幅に下がっていると感じています。

「なぜそれが必要なのか」「どう組織の価値に繋がるのか」 を理解し、積極的に取り組む姿勢があれば、どのようなデータ分析組織でも始められると思います。

AI が正しく・早くデータ分析を遂行するための context engineering の整備が、これからのデータ組織に求められる役割の一つと言えるでしょう。

メドレーでは今後も、医療・ヘルスケア領域における課題解決に向けて、こうした AI × データ分析の発展に取り組んでいきます。

同じような取り組みを検討されている組織の方々と、ぜひ知見を共有できればと思います。

We’re hiring!

メドレーの医療プラットフォーム本部のデータ戦略グループでは、AI 時代の新しいデータ分析にチャレンジしたいデータアナリスト・データエンジニアを募集しています。Analytics Knowledge as Code の実践や、医療ヘルスケア領域でのデータ活用にご興味をお持ちの方は、ぜひお気軽にお声がけください！

参考

Header image from Dex Horthy on Twitter. Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. Most of the time when an agent is not performing reliably the underlying cause is that the

blog.langchain.com

pages.awscloud.com

Medley Summer Tech Blog Relay 7 日目は、人材プラットフォーム本部の山邉さんの記事です！

メドレー新卒エンジニア研修2025

Fri, 29 Aug 2025 03:15:50 GMT

はじめに

こんにちは。医療プラットフォーム本部プラットフォーム開発室の島谷です。メドレーでは 2019 年から新卒エンジニアの採用を続けており、毎年新卒向けエンジニア研修を実施しています。本記事では、2025 年に実施した新卒研修の設計思想とプログラムの全体像をご紹介します。メドレーで働くことに関心のある学生の方はもちろん、私たちの開発文化に興味のあるエンジニアの方にも、メドレーという会社の雰囲気が伝わる内容になれば幸いです。

新卒研修の目的

私たちが大切にしているのは、単なるスキルの習得にとどまらず、「課題にどう向き合うか」「どのように学び、成長していくか」といった姿勢やマインドセットを身につけてもらうことです。

新卒研修のミッションは、エンジニアとして必要な基礎技術と、問題解決に欠かせない考え方を習得し、配属後に高い成果を発揮するための土台を築くことにあります。研修では「技術的な基礎力」と「問題解決力」を重点的に養い、配属後すぐに開発を進められる状態を目指します。

もっとも、研修期間だけで一人前のエンジニアになることは難しく、だからこそ長いキャリアを通じて自ら成長し続ける姿勢が欠かせません。そうした背景があるからこそ、私たちはスキル以上に「成長し続けるための姿勢やマインドセット」を大切にしています。

研修の全体像

今年の新卒研修は、大きく 4 つのステップで構成されています。まず社会人として必要なビジネススキルとマインドを身に付け、技術的な基礎を作り、そのうえで実務としての開発を体験し、最後に成果発表会で振り返りを行い今後の成長へつなげる。学びを段階的に深めていく一連の流れを設計しています。

期間と研修全体の流れ

HC 研修、外部研修

人事部が実施する内製の HC（Human Capital）研修と、外部研修を実施しました。HC 研修では、社会人に必要な基本動作（報連相や PDCA）やマインド（ニーズを理解しニーズに応える）の基本を習得してもらい、外部研修では、より体験的な演習を通じて社会人としての自覚を持つきっかけとしました。

基礎研修

エンジニアに求められる横断的な基礎知識の習得、深く学び続ける姿勢の醸成、チームで成果を出すためのコミュニケーション能力の向上を目的としています。フロントエンド（TypeScript/React）、バックエンド（Ruby on Rails）、インフラやミドルウェア（データベース、AWS）など幅広い領域を実践形式で扱いました。

加えて、CTO・VPoE による事業説明や、メドレーでエンジニアとして働くうえでの心構えを学ぶセッションも実施。QA チームやデザインチームからは、それぞれの取り組みを共有してもらい、組織全体での開発の在り方についても学んでもらいました。今年は新たな取り組みとして、AI 活用に関する講義も行っています。

VPoE 山﨑さんによる講義の様子

事業部 OJT、開発 OJT

事業部 OJT では、複数の事業部でビジネスの理解を深め、現場業務を体験します。現場社員とのコミュニケーションを通じて、エンジニアへの期待やその期待の裏側にある状況の一端を理解し、顧客志向を育みます。

開発 OJT では基礎研修で身につけた知識やスキルを実際の開発現場で活かすフェーズです。既存プロダクトの開発チームに加わり、実務としての開発を体験します。

成果発表会

研修の集大成として、これまでの学びや開発 OJT での取り組みを整理し発表してもらいました。

メンター制度

研修を支える仕組みとして、今年も一人ひとりにメンターをつける「メンター制度」を実施しました。研修本体での学びを補い、成長をより加速させることを目的としています。

研修期間中は毎日、日報を書いてもらっています。その日取り組んだことや学んだことを弊社の行動原則（Our Essentials）に基づき整理し、読み手を意識した文章にまとめることがルールです。日報はメンターが必ず目を通し、毎日フィードバックを行いました。やりとりの内容は、技術的な疑問点への対応だけでなく、課題への向き合い方や物事の捉え方といった長期的な成長につながる視点を与えることを意識してもらっています。短期的な知識の提供ではなく、将来にわたって役立つ考え方を養うことを重視しました。

さらに、週次では 1on1 を実施し、振り返りの場を設けました。目標や課題を言語化し、メドレーの行動規範の観点から自らの振る舞いを点検。翌週に試す具体的な一手へと落とし込むことで、実践的な成長サイクルを回しました。もちろん、真面目な内容だけでなく、砕けた相談も自由にできる場とし、安心して取り組める環境づくりも大切にしています。

日報に対するフィードバックの様子

研修の詳細

HC 研修、外部研修

HC 研修では、社会人に求められるビジネスマナーやキャリアマインド、ロジカルシンキング、コミュニケーション能力などのポータブルスキルを学びました。座学だけでなく、ワークショップを行うことでメドレーグループの他職種の新卒とも交流も行いました。最終日はチーム対抗の寸劇を行うことで、一人ひとりの発言力を高め、一体感を生み出すことができました。

外部研修では、講師が顧客役を演じたり、チームを企業に見立てた競争環境で取り組んだりと、実際の現場に近いハイプレッシャーな状況を体験しました。その中で、適切なコミュニケーションやチームワークの大切さを実感し、成果につなげるプロセスを学ぶことを目指しました。

基礎研修

基礎研修は、実際にプロダクト開発に携わっているメドレーのエンジニアが、教材づくりから講師までを担当します。単なる知識の習得にとどまらず、判断の背景や根拠を言語化し、他者に伝わる形で残すことまで含めて学ぶことを大切にしています。

全体を通して繰り返し伝えられていたことは、「課題を終わらせること自体を目的にしない」ということです。わからない点をそのままにせず、ドキュメント・実装・計測結果を往復しながら自分の言葉で理解し直す。この姿勢を身につけることが、研修を通じて最も大事にしている部分です。

ここでは主要な研修内容を紹介します。

TypeScript/ React

この研修では、フロントエンド開発の基礎として TypeScript と React を扱いました。TypeScript の型システムなどの言語仕様を理解したうえで、React のコンポーネント設計、状態管理、フック　などの基礎を学びます。

演習課題は Pull Request 形式で提出し、背景や選択肢、判断理由を文章にまとめたうえでコードレビューを受ける流れとしました。これにより、単に技術を学ぶだけでなく、技術を深く掘り下げる姿勢や、GitHub を使った開発フロー、レビューを通じたテキストコミュニケーションを実践的に身につけることを狙いとしています。

データベース（DB）

次に、データベースの基礎を幅広く学びました。テーブル設計や ER 図、リレーションの理解に加え、実際にクエリを書く演習として「クエリ 100 本ノック」に挑戦。WHERE や JOIN といった開発や分析で頻出する構文を身につけました。さらに、クエリ実行計画の読み方やインデックス設計など、パフォーマンスチューニングにも取り組みました。長期的な保守性や変更容易性、パフォーマンスを意識しながらデータベースを扱うための基礎を、実践的に学ぶ内容です。

アプリケーション開発実践

フロントエンドとバックエンドをつなげた実践的な開発演習として、Rails on Rails で API を実装し、React で SPA（Single Page Application）を構築する研修を行いました。フードデリバリーサービス（Uber Eats のようなアプリ）を題材に、決められた要件定義から設計、開発、テストまでを一気通貫で経験します。

ここでは、TypeScript/React 研修で身につけた基礎を応用しながら、実際にプロダクトとして動くアプリケーションを作り上げることに挑戦しました。仕様の整理からテスト設計までを通じて、フロントエンドとバックエンドを横断的に理解し、開発に必要な実践力を養うことが目的です。

Docker / AWS

最後に、インフラ領域の基礎として Docker と AWS を扱いました。メドレーでは AWS を中心に利用しているため、実際にアプリケーションを AWS 上にデプロイし、動作させるところまでを体験します。可用性やスケーラビリティを考慮したシステム構築に加え、ログ、監視、アラート設定といった運用面も含めて一通り設定。さらに簡易的に負荷をかけ、スケールアウトやアラートが正しく機能するかを検証しました。単に作るだけでなく、安定的に運用できる状態にすることの重要性を学ぶハンズオンとなっています。

事業部 OJT、開発 OJT

基礎研修を終えたあとは、現場社員から研修を受ける事業部 OJT に取り組みました。事業部によって取り組む内容は異なりますが、市場環境やミッション、今後の方向性を理解することから始まり、Sales や Customer support の業務の一部を体感します。

その後は、既存プロダクトの開発現場に加わり、実際の開発を体験する OJT に取り組みました。ここでは、抽象度の高い課題に対して自ら問題を整理し、解決に向けた手順を考え、周囲と協調しながら前に進める力が求められます。

開発の過程では、リリースに至るまでの一連のプロセスを経験します。わからないことを適切に言語化して周囲に伝え、協力を得ながら課題を乗り越えることも重要なポイントです。

今年の OJT で取り組まれていたタスクをいくつかピックアップしてみます。

デザインシステムの MCP サーバー構築
顧客向け管理画面の UI/UX 改善
電子カルテにおける書類作成機能の改善
患者向け通知機能の UX 改善

タスクを進める中では、先輩エンジニアから様々な観点でフィードバックを受けます。これまで自分になかった視点や考え方に触れることで、新卒メンバーは大きな学びを得ていた様子でした。

成果発表会

研修の締めくくりとして行ったのが成果発表会です。ここでは、研修や OJT を通じて学んだこと、自身の成長・変化を自分の言葉で整理し、周囲に伝える力を養うことを目的としています。単に振り返るだけでなく、学びを言語化して共有することで、個人の経験をチーム全体の資産へと昇華させる場でもあります。

当日は、CTO や VPoE、メンター、配属先のマネージャーなど、研修に関わった多くのメンバーが参加しました。新卒の皆さんは緊張した面持ちでしたが、先輩たちから温かいフィードバックや応援の言葉が寄せられ、会場は和やかな雰囲気に包まれていました。

各 VP の皆様を始め、関わった方々からコメントいただきました

まとめ

研修という限られた期間の中で、一人前のエンジニアとしての力をすべて身につけることは容易ではありません。だからこそ、この期間を通じて「これから成長していくための土台」を築いてもらうことを大切にしてきました。本番はここから始まります。

新卒の皆さんには、これからは仲間として実際の開発現場で活躍しながら、さらに経験を積み重ねていくことを期待しています。私たちのミッションである「医療ヘルスケアの未来をつくる」を実現するために、それぞれが力を発揮し、共に歩んでいけることを心から楽しみにしています。

We’re hiring!

サマーインターン参加者募集中！

メドレーでは、この夏に開催するエンジニア向けサマーインターンの参加者を募集しています。実際のプロダクト開発を体験しながら、エンジニアとしての成長につながる機会を提供します。

「まずは話だけ聞いてみたい」「雰囲気を知りたい」という方に向けて、カジュアル面談も実施しています。少しでも興味をお持ちの方は、お気軽にご応募ください。

募集はこちら

中途採用も積極募集中！

また、エンジニアをはじめとした中途採用も積極的に行っています。ヘルスケアの未来を一緒につくる仲間を幅広く募集していますので、ぜひこちらもご覧ください。

中途採用の募集一覧はこちら

メドレーオフィス（13階）へのアクセスと入館方法のご案内
 [六本木ヒルズ森タワー]メドレーのオフィスを初披露

「最高のパフォーマンスを引き出す！メドレーエンジニアの働く環境を徹底解剖」

Fri, 29 Aug 2025 00:00:00 GMT

この記事はメドレー夏のブログリレー2025 5日目の記事です。

はじめに

こんにちは！メドレーでDevRelをしている重田です。

突然ですが、転職先を探す時に実際に働く環境や雰囲気って気になりますよね？
この記事では、メドレーのエンジニアが普段どんな環境で仕事をしているのかを写真メインでご紹介します！

「メドレーのオフィスで働きたい！」「働くイメージが持てた！」と思っていただけたら嬉しいです🙌

では、早速オフィスツアースタートです📣

🏢 私たちが働くオフィス

私たちのオフィスは日比谷線六本木駅直結の六本木ヒルズ森タワーの12階と13階にあります。詳細は以下記事でご紹介しています🙋‍♀️

🏙️外観

六本木ヒルズ森タワーは54F建て、高さ238メートルの超高層オフィスビルです。上を見上げる高さで、たまに見ると「おお〜〜都会だ！」となり背筋が伸びます。笑

🏥13階

エンジニアの中でも医療プラットフォームのプロダクト開発エンジニアやコーポレートITのメンバーが13階で働いています。

エントランス（受付）

13階のエントランスは清潔感のある白の壁に温かみのある木目調の床です。

憩いスペース

約100席と、広々したスペースです。テーブル席の他、ソファもあるのでゆったりと過ごせます。

カウンターには賞状などが飾られています。

🏥12階

エンジニアの中でも人材プラットフォームのプロダクト開発エンジニアが12階で働いています。

憩いスペース

こちらは今年の春に増設されたスペースです！
ランチだけではなく、1on1やチームミーティングでも大活躍のスペースです。

ボックス席にはディスプレイが付いており、チームミーティングの際に役立ちます。

ゆっくりしたいときはこの席がおすすめです🍵

東京タワーを眺めて仕事ができるのは六本木、そして12階に位置する特権です🗼

憩いスペース入口には弊社プロダクトを体験できるコーナーがあります。

また、自動販売機2台・コーヒー販売機2台・食品自動販売機1台・冷蔵庫が完備されています☕️

小腹が減った時の救世主🙏コンビニに行くのが面倒な時に大活躍です！

持参/購入したお弁当を温められるのも嬉しいポイント💡

🏥共通

会議室

会議室は50室以上あり、来客専用・社内専用の会議室が分かれています。

✨メドレーのカルチャー「クリーンデスクポリシー」に込められた想い

メドレーが大切にしているカルチャーのひとつに「クリーンデスクポリシー」があります。これはデスクの上には仕事道具以外置かない、帰宅時にはモニタ・キーボード・マウス以外は全て片付けるというルールのことです。

「クリーンデスクポリシー」は代表の瀧口が「佐藤可士和の超整理術」という本から影響を受け、創業時から大切にしているカルチャーです。なぜ「クリーンデスクポリシー」が大切なのか、瀧口が社内で共有している資料から引用してご紹介します。

整理整頓には、視点が必要です。複雑なものであれば、それぞれの因果関係を見抜き、何が大切なのかの優先順位をつけることが必要です。「頭で理解しているつもりのこと」と「身体に染み付いて実践できること」には大きな隔たりがあります。実践への近道は、たった一つの象徴的なことを徹底することではないでしょうか。
例えば、この記事「日本電産が赤字会社を速攻で再生できたワケ」の「組織体質を変える一番の早道は」を読んでみてください。整理・整頓・清潔・躾（自主的な）を徹底して、営業回数を増やせば成功すると書いています。
そもそも仕事机は、仕事をするためのものです。クリーンデスクというのは整理整頓ができる組織であることの象徴です。このような背景で、クリーンデスクポリシーは僕にとって、大切にしたい考え方なのです。

実際、社員の机は常に整理されています。

また、過去にも「クリーンデスクポリシー」に触れているのでぜひご覧いただけると嬉しいです！
[六本木ヒルズ森タワー]メドレーのオフィスを初披露

📚スキルアップ支援やライフステージに合わせた柔軟な働き方を実現

この記事では主にエンジニアの制度をご紹介します！

支援制度

社内勉強会支援
社内で勉強会を開催する際の飲食補助が出ます！

書籍購入の補助
会社の費用で購入可！ ※資産管理の観点から電子書籍は除く

資格取得支援
AWS認定試験・Ruby技術認定試験を会社の費用で受験可！ ※一定条件あり

カンファレンス参加費用の補助
RubyKaigi などの外部カンファレンスへ会社の費用で参加可！

制度を利用する際は、以下のようにSlackで申請をしています。

希望PC・モニター・アーロンチェアの貸与
エンジニアの方には希望PCとモニターが貸与されます。基本的にはスペックも自由に選べます🙆‍♀️

湾曲型モニター

また、希望者にはアーロンチェアも用意しています。

働く環境

よくある質問をもとにご紹介します！

Q. 勤務時間は決まっていますか？
A. 開発職では裁量労働制を採用しており、多くの社員は事業部の稼働時間に合わせて10:00～19:00で勤務しています。
一方で、子育て中の社員については、勤務時間中に一時的に離席するなど、個々の状況に応じた柔軟な体制をとっています。

Q. 出社とリモートの頻度はどのぐらいですか？
A. エンジニア/デザイナーの場合は週2出社、週3リモートをベースにしています。
こちらも勤務時間と同様、体調やご家庭の事情など、柔軟に対応できる体制になっています。

Q. キャリアロールはどのようになっていますか？
A. 「スペシャリスト」と「マネジメント」の2つに大別されます。事業責任者のロールも存在しますが、役職ではなく、一つのロールとして位置づけています。

Q. 担当するプロダクトは決まっていますか？
A. エージェントからのご紹介時・スカウトをお送りする際などにプロダクトを限定している場合もありますが、基本的には選考を通じて皆様のご希望や志向、スキルスタックなども合わせてご提案・ご相談しながら決めています。

イベントでも大活躍のオフィス

メドレーでは定期的にイベントを開催したり、オフィスを他社様や外部コミュニティのイベント会場として提供したりしています。

こちらは5月にリンケージ社とヘンリー社と開催したイベント、
HealthTech Meetupの様子です。

Roppongi.rb、Omotesando.rb の会場としても定期的にご利用いただいています🙌

🍀最後に

最後までご覧いただきありがとうございました！
メドレーで働くイメージはつきましたでしょうか!?

直近では、以下のイベントを開催予定です！
少しでもご興味のある方は、ぜひイベントを機にオフィスにいらしてください！ご参加お待ちしております✨

9/4(木)19:30
Omotesando.rb#113

9/5(金)19:00
【有料プランユーザー限定×オフライン】MagicPodユーザーミートアップ

We’re hiring

最後まで読んでいただきありがとうございます！
メドレーでは、一緒に働く仲間を大募集中です👫
少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！

🤝 募集一覧
🗣️ カジュアル面談

Medley Summer Tech Blog Relay 6 日目は、医療プラットフォーム本部の安東(Andō)さんの記事です！
それでは良い週末をお過ごしください！

MEDLEY Summer Tech Blog Relay

Fri, 22 Aug 2025 00:00:00 GMT

こんにちは！メドレーでDevRelをしている重田です。今年も暑い日が続いていますがいかがお過ごしですか？

メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 8/25(月)〜9/26(金)まで毎日異なるメンバーが技術やエンジニアリング、個人開発など幅広いテーマでテックブログを公開していきます！

本記事にて毎日ブログを追記更新していくので、ぜひお楽しみください✨ ※土日祝を除く

ブログリレーカレンダー

🗓️第1週(8/25~8/29)

🗓️第2週(9/1~9/5)

🗓️第3週(9/8~9/12)

🗓️第4週(9/16~9/19)

🗓️第5週(9/22~9/26)

🍉We’re hiring!

メドレーでは、「医療ヘルスケアの未来をつくる」仲間を大募集しています！少しでも興味をお持ちいただけましたら、ぜひ、カジュアル面談にお越しください🙌

メドレーで働く | 株式会社メドレー

メドレーの組織文化や募集要項をご紹介します

Medley Engineer Entrance Book

この度は株式会社メドレーに興味をお寄せいただきありがとうございます。本資料は、メドレーへの転職をご検討いただいている皆様に、当社をより深くご理解いただくために作成いたしました。

medley-inc.notion.site

BigQuery Data Transfer Service を通して学ぶ Google 広告のデータモデル

Thu, 24 Jul 2025 03:02:28 GMT

SRE NEXT 2025 参加レポート

Thu, 17 Jul 2025 01:24:38 GMT

はじめに

こんにちは！医療プラットフォーム本部プラットフォーム開発室 SRE グループの山田です。医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。

メドレーは 7 月 11 日、12 日にTOC 有明（東京都江東区）で開催された SRE NEXT 2025 に LOGO Sponsor として協賛しました！ SRE NEXT は、信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。医療プラットフォーム本部 SRE グループは発足して間もないため、他社のさまざまな挑戦や SRE プラクティスを学ぶべく、私を含め数名のエンジニアが参加し、たくさんの方々と交流させていただきました。本レポートでは、SRE NEXT 2025 の会場や企業ブースの様子、そして発表の内容についてご紹介します。

会場の様子

SRE NEXT 2025 は、オンラインとオフラインのハイブリッド形式で開催されました。 50 を超える企業の協賛のもと、740 名もの SRE エンジニアが現地に参加しました。

広々とした会場

企業ブースも多数出展しており、SRE にまつわるアンケートや SRE プラクティスの紹介など非常に面白かったです。

株式会社タイミー様のブースにお邪魔させていただきました

2 日目の最後には懇親会も催され、様々な SRE エンジニアの方と交流することができました。

懇親会の様子

発表の様子

どのセッションも大変興味深かったのですが、特に印象深かった下記のセッションについてご紹介します。

Day1: SRE 不在の開発チームが障害対応と向き合った 100 日間
Day2: 伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上
Day2: Four Keys から始める信頼性の改善

SRE 不在の開発チームが障害対応と向き合った 100 日間 (Loglass 勝丸真さん)

引用元: speakerdeck.com

カスタマーサクセスチームからのフィードバックをきっかけに、インシデント対応の改善に取り組んだ際の課題と、その解決策が紹介されました。

開発チームが障害対応に直面する中で、エンジニアによって対応品質にばらつきがあり、カスタマーサクセスチームから「障害対応がスムーズに進まない」「全体の体制や連絡手段が曖昧」といったフィードバックを受けるという課題があったとのことです。特に、あるエンジニアは単純な修正作業のみを行う一方で、別のエンジニアは影響範囲の特定やカスタマーサクセスへの回避策伝達まで含めた包括的な対応を実施するなど、対応者によって大きな差が生じていました。

そこで、専任のインシデントコマンダーチームを編成し、全エンジニアによるローテーション制から専門化による品質向上を図るアプローチへ切り替えたことが説明されました。また、障害対応フローの明確化とシンプル化、インシデントレベルの再定義、外部ツール「Warroom」の導入による自動記録・AI 要約機能の活用についても具体的な手法が紹介されました。さらに、プロジェクトの推進においてはプロセス整備だけでなく、ビジネスチームやプロダクトチームとの継続的な対話を重視し、「なぜこの変更が必要なのか」という背景を丁寧に共有することで組織全体の理解を深め、技術的なベストプラクティスとビジネス要求のギャップを埋めていく文化づくりの重要性も解説されていました。

所感

このセッションで特に印象的だったのは、教科書的なベストプラクティスをそのまま適用するのではなく、現場の実情に合わせて大胆な割り切りを行っていた点です。中でも、「全エンジニアがインシデントコマンダーになる」という理想を一旦捨て、あえて属人化を許容して専門チームを作るという判断は、実践が進んでいるからこその現実的な選択だと感じました。

CLINICS SRE でも、理想的なインシデント対応体制を構築しようとする際に、全エンジニアのスキルレベルやモチベーションのばらつきという現実的な課題に直面することがあります。この発表から学んだのは、完璧な体制を目指すよりも、まずは実効性のある仕組みを作り上げることの重要性です。専門チームによる安定した対応基盤があってこそ、その後の全体的なスキル向上や体制の民主化が可能になるのだと理解しました。

また、プロセス整備だけでは解決できない人間関係や組織文化の課題に対し、継続的な対話を通じて理解を深めていく姿勢も非常に参考になりました。CLINICS でも、開発チームや事業部との間で、障害対応時の連携や認識に齟齬が生じることは少なくありません。この発表から学んだ対話を重ねることが重要であるという点は、今後の SRE の取り組みに活かしていきたいと思います。

現場の泥臭い課題に真摯に向き合い、組織として解決策を模索する姿勢は、同じような課題に取り組む SRE チームにとって大きな学びとなる発表でした。

伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上　（ビズリーチ佐々木康徳さん）

引用元: speakerdeck.com

このセッションでは、WAF 運用をプロダクトチームへイネーブリングするにあたり、SECI モデルに基づいて実践された事例が紹介されました。

具体的には、共同化、表出化、連結化、内面化の 4 つのプロセスを通じて、SRE が持つ暗黙知を段階的にプロダクトチームに移転し、チームのオーナーシップを醸成する具体的な方法が示されました。

この取り組みにより、WAF 運用をプロダクトチームへ移管できただけでなく、プロダクト開発チームのオーナーシップ向上やコミュニケーションの効率化といった効果も得られたと説明されていました。

所感

このセッションで、SECI モデルという概念を初めて知りました。私自身、暗黙知から他者への暗黙知のプロセスを飛ばしていきなりドキュメント化（表出化）から始めたり、連結化まで進めずに終わってしまったりと、SECI モデルの観点から見ると不完全な取り組みでイネーブリングに失敗した経験があります。そのため、今回の発表は非常に納得感があり、共感を深く覚えました。

今後、CLINICS SRE でも SECI モデルを意識した開発チームへのイネーブリングを進めていきたいと考えています。

Four Keys から始める信頼性の改善　（DMM 尾崎耕太さん）

引用元: speakerdeck.com

このセッションは、Four Keys (チーム生産性を可視化することを目的とした指標のこと) を軸に DevOps 文化を作り、その結果としてユーザにとって魅力的で信頼されるプロダクトを提供することを目指す戦略を取ることで、信頼性の改善を進めたという事例と導入効果について紹介されました。

信頼性指標である SLI/SLO やエラーバジェットは、機能開発チームにとって理解しにくく、日々の開発サイクルに組み込みにくいという課題がありました。そこで、より開発プロセスに近く、チームがオーナーシップを持ちやすい Four Keys を採用。これを軸に DevOps 文化を醸成することで、段階的に信頼性を獲得するというアプローチをとったと説明されています。

その結果、Four Keys の数値が改善しただけでなく、プロダクト開発チームが自律的に変化に取り組むようになったという大きな効果があったと紹介されていました。

所感

最も印象的だったのは、「指標の改善が目的ではなく、その先の状態が目標」という考え方です。指標を取るのは気づきを得て、アクションに繋げるためのものであるため、「指標を改善すること」にこだわりすぎない方が良いという話には深く共感できました。数値の向上に注力するあまり、なぜその指標を見ているのかという根本的な目的を見失ってしまうことは、実際の現場でもよく起こりがちな問題です。

CLINICS でも SLO 運用を行っていますが、この考え方は非常に参考になりました。SLO の数値を改善することに集中してしまい、そもそもなぜ SLO を設定しているのか、SLO 運用を通じて何を実現したいのかという本質的な目的を見失わないよう気をつけたいと思います。 SLO 運用をした先に SRE チームが何を目指しているのか、サービスの信頼性向上によってどのような価値をユーザーや事業に提供したいのかという意識を、開発チームにもさらに伝えられるようにしたいと感じました。

また、開発チームがオーナーシップを持って変化に取り組んでいることが重要という点も非常に納得できました。具体的な成果よりも、開発チーム自身が主体的に改善活動を推進していることの方が本質的な価値があるという考え方は、持続可能な改善文化を構築する上で欠かせない要素だと思います。

実践面で特に参考になったのは、単純に Four Keys を導入するのではなく、プロダクト開発チームと対話してアクションに繋げられるように Keys を詳細化している点です。開発者が「なぜ悪化したのか」「どの活動が効果的だったのか」を理解できるよう工夫している取り組みは、実際の現場での指標活用を考える上で非常に実用的なアプローチだと感じました。

さいごに

他社のさまざまな挑戦や SRE プラクティスを学べただけでなく、たくさんの方々と交流することができて刺激的な 2 日間でした。

来年も 7 月 10 日、11 日にTOC 有明での開催を予定しているそうです。メドレーは今後も SRE NEXT だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。

運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！

メドレーではエンジニアを積極採用中です！

エンジニアを積極採用中です

メドレーでは、「医療ヘルスケアの未来」を共に創っていく SRE エンジニアを積極的に採用しています。興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。

募集の一覧 https://www.medley.jp/jobs/

※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

高可用性システムにおけるBlue/Greenデプロイメント実装 - 医療システム統合基盤での取り組み

Mon, 30 Jun 2025 01:29:00 GMT

こんにちは。医療プラットフォーム本部の日下（@mkusaka）です。私の所属する統合基盤チームでは、医療プラットフォームの複数のシステムを支えるサービス群を運用しています。

これまではユーザーへの影響を最小限に抑えるため、リリース作業を深夜や早朝に限定していましたが、その結果として運用チームへの負担増やリリースタイミングの制約といった課題が生じていました。

こうした課題を解決し、日中でも安全かつ段階的にリリースを行うため、統合基盤に Blue/Green デプロイメントを導入しました。今回はその詳細を紹介します。

統合基盤コンポーネントの紹介

統合基盤チームでは、患者と医療機関の双方に使われる医療システムの根幹を支える重要な基盤の開発・運用を行っています。管理するコンポーネントは、「医療機関向け」と「患者向け」の 2 つに分類できます。

「医療機関向け」機能は、Pharms、Dentis、CLINICS などの各サービス間でコミュニケーションのハブとして機能し、イベントの配信を行います。

一方、「患者向け」機能としては、総合医療アプリ CLINICSから送られたリクエストを適切なサービスに振り分けるゲートウェイの役割を担っています。

このようなアーキテクチャを採用した背景には、医療プラットフォームが複数のプロダクト（Pharms、Dentis、CLINICS など）を統合的に運用する必要があるという背景があります。

医療機関向けには、いずれか一方のシステムの状態に他方が引きずられない構成とすることで、各医療機関の業務システムの可用性を最大限高めるという狙いがあります。

一方、患者向けには、複数の医療機関向けシステムに対して共通のアプリからアクセスできるようにするため、患者情報の一元管理や統一された認証基盤の整備が不可欠です。これにより、患者にとってシームレスな体験を実現し、より効率的で質の高い医療サービスの提供を目指しています。

つまり、統合基盤が管理するこれらのコンポーネントに障害が発生すると、サービス間にまたがる業務だけでなく、患者向けのサービス提供にも影響が及ぶため、高い可用性が求められています。

Blue/Green デプロイメント導入の目的

統合基盤の各サービスは、AWS ECS（Elastic Container Service）上で運用されています。これまでは、運用のシンプルさからローリングデプロイを採用していました。しかしこの手法では、デプロイが開始されると新バージョンが一斉に展開されてしまうため、問題発生時の影響範囲が広く、迅速なロールバックも難しいという課題がありました。

こうした課題への対策として、Blue/Green デプロイメントを導入することを決定しました。 Blue/Green デプロイメントとは、新旧 2 つの環境（Blue と Green）を用意し、新バージョンを片方に展開した後、徐々にトラフィックを移行していく方法です。これにより、致命的な問題やパフォーマンスの劣化を早期に発見し、迅速なロールバックが可能になります。

Blue/Green デプロイメントの要件と独自実装の選択

システムを Blue/Green デプロイする際に、大きく分けて 2 つの考慮事項がありました。 1 つ目は 2 つの明確な検証フェーズを設けることです。

致命的なエラー検出フェーズ：新環境に約 10%のトラフィックを流し、システムの安定性を確認。
負荷時のパフォーマンス検証フェーズ：新環境に約 50%のトラフィックを流し、負荷によるパフォーマンスの劣化を確認。

これら 2 つのフェーズを明確に設け、十分な検証時間を取ることで、より高い自信をもってリリース作業を進めることが可能になると考えました。

2 つ目は非同期処理を担当する Worker サービスを新旧の環境それぞれで用意することです。 Worker サービスでは、ジョブが SQS（Simple Queue Service）キューに投入されてから実際に処理されるまでタイムラグがあります。その間に新しい環境へ切り替えが行われると、旧環境のジョブが新環境の Worker によって処理され、データの不整合が起きる可能性があります。このリスクを防ぐため、Blue と Green の環境それぞれに独立した SQS キューを用意し、それぞれのジョブが確実に自環境の Worker で処理を完了する形式を取ることとしました。

ECS には CodeDeploy を利用した標準的な Blue/Green の段階的デプロイ戦略として、Canary デプロイ（一部のトラフィックで検証後、一気に切り替え）や Linear デプロイ（一定割合ずつ徐々に適用）が提供されています。しかし、私たちが求めるようなトラフィック調整にはこれらの手法が十分に適しておらず、また SQS を分離するための Blue 環境/Green 環境どちらかを判定するような仕組みが整備されていないようだったので、内製化することとしました。

採用した構成

自前の Blue/Green デプロイを実現するため、以下の構成を採用しました。

ALB（Application Load Balancer）の weighted target groups を利用して、トラフィックを柔軟に調整しています。
ECS 環境は Blue/Green のそれぞれが並行稼働し、SQS は各環境ごとに独立したキューを設けます。

新バージョンは Green 環境として起動し、初期状態では Blue 環境（現行バージョン）がすべてのトラフィックを処理します。その後、Green 環境へのトラフィックを 10%、50%と段階的に増やしながら、各段階でメトリクスの監視を行います。 10%の段階で致命的なエラーがないことを確認し、50%の段階で負荷時のパフォーマンスに問題ないと判断されたら、最終的にすべてのトラフィックを Green 環境へ切り替えます（100%）。

また、各種ステップは承認操作やロールバックも含めて CI 上で完結するように整備を行うことで、デプロイの複雑性も抑えています。

実装サンプル

Terraform と AWS CLI を組み合わせて実装しています。

ALB の weighted routing 設定（Terraform）

resource "aws_lb_listener_rule" "weighted_routing" {
  listener_arn = aws_lb_listener.https.arn

  action {
    type = "forward"
    forward {
      target_group {
        arn    = aws_lb_target_group.app_blue.arn
        weight = 100  # 初期状態では Blue が 100%
      }
      target_group {
        arn    = aws_lb_target_group.app_green.arn
        weight = 0    # Green は 0%
      }
    }
  }

  # AWS CLI で weight を動的に調整するため、Terraform での変更を無視
  lifecycle {
    ignore_changes = [action]
  }
}

トラフィック配分の変更（AWS CLI）

デプロイ時のトラフィック配分は、AWS CLI を使用して動的に変更します。実際の運用では、Green の weight を指定すると Blue が自動的に 100 - Green になるように調整しています：

# Green の weight を指定して Blue/Green の配分を設定
# 例：GREEN_WEIGHT=10 の場合、Blue=90、Green=10 に自動計算
set-weight:
	@aws elbv2 modify-rule \
	  --rule-arn $(LISTENER_RULE_ARN) \
	  --actions '[{
	    "Type": "forward",
	    "ForwardConfig": {
	      "TargetGroups": [
	        {
	          "TargetGroupArn": "$(BLUE_TG_ARN)",
	          "Weight": '$$((100 - $(GREEN_WEIGHT)))'
	        },
	        {
	          "TargetGroupArn": "$(GREEN_TG_ARN)",
	          "Weight": '$(GREEN_WEIGHT)'
	        }
	      ]
	    }
	  }]'

デプロイフロー

実際のデプロイでは、以下のような手順で段階的にトラフィックを移行します：

# 1. Green 環境へのデプロイ
make app-green.deploy TAG=$(NEW_VERSION)

# 2. トラフィックを段階的に移行
make set-weight GREEN_WEIGHT=10   # 10% を Green へ
make set-weight GREEN_WEIGHT=50   # 50% を Green へ
make set-weight GREEN_WEIGHT=100  # 100% を Green へ（切り替え完了）

# 3. 問題が発生した場合のロールバック
make set-weight GREEN_WEIGHT=0    # すべてのトラフィックを Blue へ戻す

この実装により、段階的なリリースと問題発生時の迅速なロールバックが可能になっています。

導入後の効果

Blue/Green デプロイメント導入後、深夜のリリース作業がなくなり、運用チームの負担が大幅に軽減されました。また日中であってもリスクを最小限に抑えたリリースが実現でき、問題が発生した場合にも迅速にロールバックできるようになったため、システムの安定性を犠牲にすることなくリリースを行えるようになりました。

まとめ

今回は、医療システム統合基盤における Blue/Green デプロイメントの導入事例を紹介しました。

医療システムには高い可用性が求められる中、従来のローリングデプロイでは段階的なリリースや迅速なロールバックが困難で、深夜作業が必須となっていました。

Blue/Green デプロイメントの導入により、以下を実現しました：

ALB の weighted target groups を活用した段階的トラフィック移行（10%→50%→100%）により品質を確認しながらのリリース進行
Worker サービス用の SQS キューを環境ごとに分離し、データ不整合を防止
深夜作業を廃止し、日中でも安全にリリース作業を実施可能に

今後も医療システムに求められる高可用性を維持しながら、開発効率の向上を目指し、継続的な改善を進めていきます。

We’re hiring

統合基盤チームでは、医療システムの根幹を支える重要な基盤の開発・運用を行っています。

今回紹介したような Blue/Green デプロイメントの実装をはじめ、高可用性が求められるシステムにおいて、技術的な課題に向き合いながら医療現場と患者体験の向上に貢献できる環境があります。

医療の未来をエンジニアリングで支えることに興味がある方のご応募をお待ちしています。

RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal

TSKaigi 2025 参加レポート：新卒2年目エンジニアが感じたTypeScriptの最前線

Thu, 29 May 2025 06:19:14 GMT

はじめに

こんにちは！人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「ジョブメドレーアカデミー」の新規プロダクト開発に携わっています。

先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。

惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！

会場の熱気と「型にとらわれない」エンジニアたちの交流

今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。

場内の様子

スポンサーボード

2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。

参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。

OST のテーマ

懇親会の様子

TypeScript ケーキ

また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。

特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。

公式ノベルティ（一部）

スタンプラリー

印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性

どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。

Day1: AI Coding Agent Enablement in TypeScript

引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck

概要

このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。

コンテキスト注入: ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。
機械的検査とフィードバック: LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。

また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。

最後に、「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。

Day2: TS 特化 Cline プログラミング

引用元: tskaigi.mizchi.workers.dev

概要

このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。

書きすぎない（再現性ある範囲で詠唱破棄）
執拗に出力例を例示する
両立条件の矛盾を避ける
規模感に合わせて厳しくする

また特に強調されていたのは、テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。

その他にも、次のような実践的なプロンプトの一例が紹介されていました。

コメントによる自己記述: 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ
In Source Testing: 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する
types.ts にドメイン型を集約: 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす
TS + 関数型ドメインモデリング: 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする
ファイル配置規則の明記: モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす
詳細指示を docs/*.md に分割: 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる
カバレッジに基づくテストの自動生成: vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる
機械的なマイグレーション: lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる
URL を読む能力: URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする

一方で、うまくいかないプロンプト のパターンもいくつか示唆されました。

型だけで設計しようとする: ほぼ確実に無視され、抽象的な設計能力は期待できない
非同期例外処理が下手: 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる
環境構築が下手: ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある
モジュールインターフェースが発散: 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する
「ある」のがよくない（チェーホフの銃の法則）: 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる
デバッグログを食いすぎる: 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである

結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。

感想

これらのセッションを通して、私が携わる新規プロダクト開発において、実践できている部分 と 改善の余地がある部分 が明確になりました。実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「ドキュメントドリブン」に倣い、ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。

具体的なイメージ

さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。

一方で、改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。

さいごに

TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。

過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！

はじめにこんにちは！人材プラットフォーム本部プロダクト開発室第一開発グループ所属の山下です。メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイトジョブメドレーの開発を担当しています。メドレーは 4 月 1...

pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal

こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら...

JSConf JP 2024にプレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。今回、メドレーは 2024/11/23 に九段坂上...

DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され...

TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！

メドレーではエンジニアを積極採用中です！

メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！

fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d

※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

Webでユーザビリティの高い手書きアプリケーションを実装するためのTips

Tue, 27 May 2025 00:00:00 GMT

はじめに

こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡(@yuya333_)と村上(@yuporonM)です。吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。

私たちは、医科診療所向けの電子カルテであるCLINICS カルテを開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。

主訴・所見の手書き

シェーマの手書き

本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。

ライブラリ選定

手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。

fabric
konva

メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。

konva では線が荒くなってしまうことがある
- https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない
konva では線を描くたびに再レンダリングが発生してしまう
- mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる

また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。

React+fabric.jsで作る手書きアプリ

zenn.dev

手書き機能で工夫したポイント 4 選

工夫 1. 手を画面につけながらペンで手書きできるようにした

画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。

画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、radiusXプロパティを使用して、radiusX がある値より大きいときには、isDrawingModeが false になるようにしました。

canvas.on("mouse:down:before", (e) => {
  if ("TouchEvent" in window && e.e instanceof TouchEvent) {
    const touch = e.e.touches.item(0);
    if (!touch) {
      return;
    }

    // 接触面積がペンや指よりも大きいときに線を書けなくする
    if (touch.radiusX > 35) {
      canvas.isDrawingMode = false;
    }
  }
});

// 画面から手を離す度にisDrawingModeをリセット
canvas.on("mouse:up:before", () => {
  canvas.isDrawingMode = true;
});

工夫 2. 消しゴムで線を消すときのラグを解消した

消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。

このラグは PC では発生せず、iPad でのみ発生していました。

この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。

原因 1. Retina ディスプレイによるピクセル密度の違い

iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。

原因 2. ピクセル密度に依存した消しゴム機能特有の処理

消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。

// https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40
export const erase = (
  destination: CanvasRenderingContext2D, // メインキャンバス
  source: CanvasRenderingContext2D, // 消しゴムの軌跡が描かれたキャンバス
  erasingEffect?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス
) => {
  // メインキャンバスから、消しゴムの軌跡部分を消去
  drawImage(destination, source, "destination-out");

  if (erasingEffect) {
    // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護
    drawImage(source, erasingEffect, "source-in");
  } else {
    // 消しゴムの軌跡を描いたキャンバスを初期化
    source.save();
    source.resetTransform();
    source.clearRect(0, 0, source.canvas.width, source.canvas.height);
    source.restore();
  }
};

これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。解決策として Canvas の初期化時に enableRetinaScaling オプションをfalseに設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。

const canvas = new fabric.Canvas(canvasElement, {
  enableRetinaScaling: false,
});

この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。

工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした

iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。

SSE(Server-Sent Events)
WebSocket
Firebase Realtime Database

Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。

以下が、Realtime Database で変更の監視及び通知を行う実装です。

import { initializeApp } from "firebase/app";
import { getDatabase, off, onValue, ref, set } from "firebase/database";

const app = initializeApp(
  {
    /* 省略’*/
  },
  "firebaseapp"
);

const db = () => {
  return getDatabase(app);
};

const PATH = "medicalRecordChiefComplaintImages";

// refを生成
const medicalRecordChiefComplaintImagesRef = (medicalRecordId: string) => {
  return ref(db(), `/${PATH}/${medicalRecordId}`);
};

// 主訴所見の手書き画像が更新されたことを通知する
export const updateMedicalRecordChiefComplaintImageIds = async ({
  medicalRecordId,
}: {
  medicalRecordId: string;
}) => {
  await set(medicalRecordChiefComplaintImagesRef(medicalRecordId), Date.now());
};

// 主訴所見の手書き画像の変更を監視する
export const watchMedicalRecordChiefComplaintImages = ({
  medicalRecordId,
  refreshMedicalRecordChiefComplaintImages,
}: {
  medicalRecordId: string;
  refreshMedicalRecordChiefComplaintImages: () => void;
}) => {
  onValue(medicalRecordChiefComplaintImagesRef(medicalRecordId), () => {
    // Realtime Databaseが更新されたときに実行する処理
    refreshMedicalRecordChiefComplaintImages();
  });
};

// 主訴所見の手書き画像の変更の監視を解除する
export const unwatchMedicalRecordChiefComplaintImages = ({
  medicalRecordId,
}: {
  medicalRecordId: string;
}) => {
  off(medicalRecordChiefComplaintImagesRef(medicalRecordId));
};

フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。

export const useMedicalChiefComplaintImagesWatchQuery = ({
  medicalRecordId,
  initialChiefComplaintImages,
}: UseMedicalChiefComplaintImagesWatchQueryProps) => {
  const medicalChiefComplaintImagesQuery = useQuery({
    queryKey: medicalChiefComplaintImageKey.list(medicalRecordId),
    queryFn: () => query.get(request.get(medicalRecordId)),
  });

  useEffect(() => {
    watchMedicalRecordChiefComplaintImages({
      medicalRecordId: medicalRecordId,
      // Realtime Databaseの更新時にrefetchする
      refreshMedicalRecordChiefComplaintImages:
        medicalChiefComplaintImagesQuery.refetch,
    });

    return () => unwatchMedicalRecordChiefComplaintImages({ medicalRecordId });
  }, [medicalRecordId, medicalChiefComplaintImagesQuery.refetch]);

  return medicalChiefComplaintImagesQuery;
};

最後に、iPad で手書き画像を更新したタイミングでupdateMedicalRecordChiefComplaintImageIdsを呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。

工夫 4. 手書きツールバーを自由に配置できるようにした

手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。

動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。

ライブラリの不具合

上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！

I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes.

まとめ

本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。実装にあたり、以下の 4 つを工夫しました。

手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました
消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました
リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました
柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました

また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。

We’re hiring

メドレーでは一緒に働く仲間を大募集しています！カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！

募集の一覧

メドレーの人材プラットフォーム事業についてお話しします！

医療エンジニアリング領域盛り上がっています！メドレーについてお話します！

「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林昭和さん

「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永諒介さん

メドレーの開発チームについて知りたい方！ぜひお話ししましょう！

医療プラットフォーム本部におけるSREグループの立ち上げ

Wed, 30 Apr 2025 00:00:00 GMT

はじめに

こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。

このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。

この記事では、以下の内容についてお話しします。

医療プラットフォームにおける SRE チーム立ち上げの経緯
医療プラットフォームの中核である CLINICS について
医療プラットフォーム SRE チームの組織体制と役割
医療プラットフォーム SRE チームとしての展望

医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。

なぜ、医療プラットフォームで SRE チーム立ち上げたのか？

医療プラットフォームの中核を担う CLINICS

医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。

その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。

また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。

CLINICS に求められる非機能要件

CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。

例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。

その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。

しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム）などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。

CLINICS を含む医療プラットフォームの成長に伴う技術課題

私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。

システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。

長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される
トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む
ライブラリ対応の優先度が下がり、 EOL 対応に追われている
アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない

また、これらの課題は、Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。

CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。

医療プラットフォーム SRE チームの発足

信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。

まずは、医療プラットフォームの中でも中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。

2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。

CLINICS の信頼性向上を目指した SRE の取り組み

ここからは CLINICS に対して現在行っている取り組みを説明します。

SRE チームの役割とミッション

CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。

前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。

目標 1: トイル排除と中長期課題へのシフト

課題:

日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする

主な取り組み:

既存インフラリソースの Terraform import を実施: 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。
定常的に発生する運用業務の自動化: CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。

目標 2: 改善文化の浸透

課題:

ポストモーテム文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。

主な取り組み:

ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。
アラート改善を定常的に回す仕組みの策定: 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。

目標 3: SLO による信頼性可視化

課題:

CLINICS の関係者が納得できる信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する

主な取り組み:

重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。
SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。

SRE チームにおけるその他の取り組み

上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。

事業成長を見越したキャパシティプランニング
システムのモニタリングによる事前の課題発見
障害対応プロセスの改善
インフラコストの削減
DB 等のパフォーマンス問題の改善
ライブラリ対応やセキュリティ対応の効率化
アーキテクチャとリリースフローの改善…など

SRE チームの取り組みの成果が実を結び始める

これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。

信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的としたSidekiq Proの導入など、信頼性向上にも取り組んでいます。

このように私たちの取り組みが徐々に成果を上げ始めています。開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。

医療プラットフォーム SRE チームとしての展望

ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。

医療プラットフォーム全体への SRE ノウハウ展開

CLINICS での知見を活かし、今後、Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。

CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。

プロダクトの拡充に対して柔軟に対応できる仕組みづくり

医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。

新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。

SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。

事業運営に関わる全関係者が納得する SRE 文化の醸成

SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。

SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。

まとめ：医療ヘルスケアの未来を支える SRE

医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。

SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。

何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？

興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。

メドレーのAI活用戦略：「AI for All」

Fri, 25 Apr 2025 02:26:55 GMT

メドレーの AI 活用戦略

こんにちは！メドレー株式会社人材プラットフォーム本部 VPoE の倉林(@terukura)です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。

昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。

メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。

AI for All

1. AI 活用による業務オペレーションの効率化：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。

2. AI 活用によるエンジニアリング生産性向上：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。

3. AI 活用によるプロダクト価値提供：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。

またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。

安心・安全な AI 活用のためのガイドライン整備：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。

AI Enabling：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。

今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。

プロダクト開発・エンジニアリングの変化

特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。

開発スタイルの変化

AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。

メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。

活用している AI ツール

メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。

コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf

元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。

これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。

思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM

対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。

UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。

自律型開発エージェント: Devin

Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。

検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。

AI 開発プラットフォーム: Dify

Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。

AI ツール活用の今後の基本方針

これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。

その際、私たちが特に重視している点は以下の 2 つです：

単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと
FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること

まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。

推進・検証中の領域

以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。

AI×QA

AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減
エッジケースの自動検出機能による人間が見落としがちなバグの早期発見

AI× データマネージメント

大規模データセットからのインサイト抽出と意思決定支援
データクレンジングと前処理の自動化によるデータ品質向上

「AI ファースト」の開発フロー

AI が理解しやすいコード構造とドキュメント体系の標準化
ナレッジやルールを AI が理解しやすい形で蓄積・管理

MCP の利用ルールとガードレールの整備

安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計
ドメイン知識を組み込んだ自社 MCP の開発と展開

AI 活用時代のエンジニア採用・人材要件

AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準
技術的深さと AI との協業スキルを評価する新たな人材ペルソナ

AI 関連費用対効果・費用モニタリング

各種ツールのコスト・モデルのコストなど様々なコスト管理
生産性モニタリング

医療 ×AI の可能性

医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。

患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。

メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！

We’re hiring

メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！

カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！

募集の一覧

メドレーのエンジニア組織・AI活用についてお話します！

医療エンジニアリング領域盛り上がっています！メドレーについてお話します！

「メドレーのエンジニア組織・AI活用についてお話します！」- 倉林昭和さん

https://increments.connpass.com/event/351891/

RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！

Wed, 23 Apr 2025 06:00:00 GMT

はじめに

こんにちは！人材プラットフォーム本部プロダクト開発室第一開発グループ所属の山下です。メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイトジョブメドレーの開発を担当しています。

メドレーは 4 月 16 日から 18 日に愛媛県松山市の愛媛県県民文化会館にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。今回は会場・ブースと発表の様子をご紹介します。

会場の様子

当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。

重厚で堅牢な印象を与える外観

100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！

広々として開放感のある場内

参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。

弊社ブースの様子

弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。

みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。また、弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。

オリジナルデザインの絆創膏も衛生キットも大人気でした！

医療DXの課題アンケートで特に回答が多かったのが 「待ち時間が長い」 という課題でした。メドレーの提供するオンライン診療・服薬指導アプリ「CLINICS」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。

また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（CLINICS、MALL、Pharms、Dentis）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。

メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で

発表の様子

どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。

Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi
Day1: Introducing Type Guard to Steep - Takeshi KOMIYA
Day2: Making TCPSocket.new “Happy”! Misaki Shioi
Day3: Matz Keynote

Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi

Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。

引用元: speakerdeck.com

概要

文字コードの進化

文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。

Reline の事例から見えた課題

Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。

Ruby における Unicode サポート

Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、\X（書記素クラスタ）や \p{Property}（Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。

感想

文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。

Day1: Introducing Type Guard to Steep

Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。

引用元 drive.google.com

概要

これまでの Steep と型ガードの課題

Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用されるpresent?メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。

Union Type に対する型ガードの強化

この課題に対応するため、Steep 1.10 以降で UnionType（例: String | nil）への型ガードが強化されました。設定記述によりpresent?のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。

また、より直感的な型ガード宣言のため、新しいアノテーション構文 a{guard: self is AdminUser} が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。

今後の展望

将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例: UserAdmin & Publish）も関連して検討されており、より高度で精密な型チェックが実現します。

感想

Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。

Day2: Making TCPSocket.new “Happy” !

Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特にTCPSocket.newへの Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。

引用元: speakerdeck.com

概要

TCPSocket.new を “Happy” にする試み

TCPSocket.newへの Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行してSocket.tcpにHEv2を実装した経験を活かし、より低レイヤーのTCPSocket.newへの改善に挑みました。

課題

先行実装したSocket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとにTCPSocket.new(C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。

プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。

感想

HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。Socket.tcpの再実装からTCPSocket.newへの実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。

Day3: Matz Keynote

RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。

AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。

一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。

そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。

また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。

さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。

昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！

さいごに

Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。
運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！

来年は北海道・函館での開催を予定しているそうです。メドレーにははこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！

After RubyKaigi 2025 を開催します！

メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社との合同開催によるアフターイベントを 5 月 14 日に行います。
RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！

メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。

メドレーではエンジニアを積極採用中です！

メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。
Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！

募集の一覧 https://www.medley.jp/jobs/
※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

Docker DesktopからOrbStackへ移行してみた

Tue, 25 Mar 2025 06:11:00 GMT

はじめに

こんにちは。人材プラットフォーム本部第一開発グループの坂井(@Hiroshi_mars)です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。

今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。

対象プロダクト: ジョブメドレーのサイトページや社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。
期間: 2~3 週間

OrbStack とは

公式

OrbStack とは

OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用)

OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。と書かれています。 Docker Desktop の代替として注目されています。

OrbStack の特徴

Docker Desktop より高速で軽量
既存の Docker コマンドや docker-compose 系のコマンドも利用可能
Docker Desktop からの移行が容易

CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。

OrbStack へ移行した理由

大きく二点あります。

OrbStack へ移行した理由その 1

【OrbStack と Docker Desktop の商用利用の料金差】

OrbStack の料金はこちら
Docker Desktop の料金はこちら

今まで Docker Desktop のDocker Teamのプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。

Docker Desktop のプランをDocker TeamからDocker Businessに上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。

「プランのランクを一つ上に上げる」のも可能ではありましたが、OrbStack へ移行した理由その 2に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。

この判断はメドレーの行動原則である(Our Essentials)の中の**『日々の倹約と大胆な投資の両立』**に適っています。無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。

OrbStack へ移行した理由その 2

【OrbStack へ移行が容易】

ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。

他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad

また、社内の別プロダクトで既に移行した実績がありました。社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。

そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。

移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。

OrbStack への移行手順

1. OrbStack をインストール

インストール方法は 2 種類あります。

Homebrew を使ったインストール

brew install orbstack

2.公式サイトから dmg 形式のファイルをダウンロードする

2. OrbStack の起動

インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。

Docker を選択すると上記のようなトップ画面が出ます。

3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する

2 種類方法があります。

トップ画面に表示されている”Migrate from Docker Desktop”をクリックする
上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます

＊2 のメニューについての画面

migrate した後、下記のようなポップアップが出ることがあります。

内容はモザイクをつけていますが、下記のようなログが出力される場合があります。

container /~: create container: [Docker] No such image: ...

これは、一部のコンテナやイメージの移行に失敗していることを示しています。

今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。

4. Docker コンテキスト情報の確認と変更

migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。

次のコマンドでコンテキストを確認します。

docker context ls

出力例:

$ docker context ls
NAME         DESCRIPTION                               DOCKER ENDPOINT                                         ERROR
default      Current DOCKER_HOST based configuration   unix:///hogehoge
orbstack *   OrbStack                                  unix:///hogehoge

”*“が今利用しているコンテキストになります

“Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。

docker context use orbstack

出力例:

% docker context use orbstack
orbstack
Current context is now "orbstack"

5. Docker コンテナの立ち上げ

Docker コンテナを起動して、正常に移行できたことを確認します。完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。

コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。

ハマりポイントや苦労した点

少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。

Docker Network 周りのエラー

Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。

Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。そのため、次のコマンドで Docker Network を確認します。

docker network ls

不要なネットワークが存在していた場合、次のコマンドで削除します。

docker network rm Hogehoge

マルチビルド周りのエラー

先ほど記載したDocker_Network 周りのエラーと似たようなエラーになります。

Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。

エラー内容

error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename) that container to be able to reuse that name.

次のコマンドで、新たにマルチビルドを作成して利用できます。

docker buildx rm multibuild
docker buildx create --name multibuild_new_type
docker buildx use multibuild_new_type

コンテナとローカルのファイル差分が更新されない問題

通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。

こちらの問題は、原因追及にかなり苦労しました。

調査の結果、以前から利用していた docker-sync が OrbStack への移行後に正常に動作していないことがわかりました。

docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。

原因の切り分けには苦労しましたが、次の手順で特定できました。

先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた
ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した
docker-sync を使用しない環境で検証して問題の解消を確認した

そのため、OrbStack への移行を機に docker-sync の利用をやめることでコンテナとローカルのファイル差分が更新されない問題を解決しました。

移行後の OrbStack の使用感

Docker Desktop より UI などがシンプルであり、操作が容易です。
migrates するだけで OrbStack に移行できる手軽さがよかったです。
商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。

まとめ

OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。

もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。

We’re hiring

メドレーでは一緒に働く仲間を大募集しています！カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！

募集の一覧 https://www.medley.jp/jobs/

医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx

メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

テックブログを継続運営するためのメドレーの取り組み

Wed, 26 Feb 2025 08:00:00 GMT

こんにちは、Jobley でエンジニアをしている新居です。

メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。

この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。

メドレーのテックブログのトップページ

テックブログ運営にまつわる課題

テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。

過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。

具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。

もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。

それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。

テックブログを継続運営するための取り組み

ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。

メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。

具体的にどのように運営しているのか、以下の順に紹介していきます。

運営委員会のメンバー構成
運営委員会の活動
執筆推進の流れ
運営委員会の KPI
大切にしていること

運営委員会のメンバー構成

まずはメンバー構成についてです。

リーダー（必須）

テックブログや運営体制のビジョンを示すのが主な役目
**会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い

コーディネーター（必須）

記事執筆推進や定例のファシリテーション、議事録の共有が主な役目
記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント
メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している

アドバイザー（任意）

記事ネタの提案や運営体制の改善などが主な役目
採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い
メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている

現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。

この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。

特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。

チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。

運営委員会の活動

続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。

定例

隔週で開催
アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有
ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない）
例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める

振り返り

年 1 回で実施
今年度を振り返り、次年度の継続アクション・改善アクションを決める
直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた

執筆推進

以下で詳細に説明

執筆推進の流れ

続いて、執筆推進の流れを詳しく紹介します。

全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。

時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。

記事執筆の流れ

では、Step 1 から順に説明していきます。

Step 1

1. 記事案の選定と決定

担当: 運営委員会
定例で記事案を決定する
後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく
記事案のカテゴリ
- 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする）
  - 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。
- インタビュー記事
  - 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました
- イベント参加記事
  - 例: pmconf 2024 にゴールドスポンサーとして協賛しました！
- etc

2. 記事案の頭出し

担当: コーディネーター
執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う
定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する

3. 執筆の事前依頼

担当: コーディネーター
突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく

4. 執筆の正式依頼

担当: コーディネーター
執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する

Step 2

5. スケジュールの作成

担当: コーディネーター
執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する
締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする

6. 執筆環境の構築

担当: コーディネーター
GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する
執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする

7. 記事構成案の作成

担当: 執筆者
さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート）

8. 執筆

担当: 執筆者
作成した記事構成案をベースにして執筆する

Step 3

9. 運営レビュー

担当: 運営委員会、その他関係者（執筆者の上長など）
誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う
後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく

10. 最終レビュー

担当: 広報チーム、CTO
広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう
ここで記事を公開可能な状態に仕上げる

11. 公開

担当: コーディネーター、執筆者、広報チーム
記事を公開し、社内外に共有する
- メドレーの公式 X アカウントでも発信しているので、フォローよろしくお願いします

運営委員会の KPI

続いて、運営委員会で設定している KPI についてです。

KPI はシンプルに、ひと月に最低 1 記事以上を公開すること
まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから

大切にしていること

最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。

テックブログをやる目的を明確にする

何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする
メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている
目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる

執筆は業務であることを明確にする

記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする
通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである
しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる
メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある
例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり

おわりに

メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。

リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。

会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。

今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。

We’re hiring

メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。

プロダクトマネージャーカンファレンス / pmconf

アドベントカレンダー2024を振り返ってみた

Wed, 22 Jan 2025 02:54:30 GMT

こんにちは！メドレー DevRel の重田です。
2024 年 12 月に実施したアドベントカレンダー（以下、アドカレ）について、「実施の目的〜実施してどうだったのか」を振り返ろうと思います。

▼Medley（メドレー） Advent Calendar 2024
https://qiita.com/advent-calendar/2024/medley

なぜアドカレを実施したのか

メドレーは採用・広報・テックブログ運営の各チームで連携して日々発信しています。

▼株式会社メドレー note
https://note.com/medley

▼テックブログ MEDLEY Developer Portal
https://developer.medley.jp/entries/

その中でアドカレを実施した理由は大きく二つです。

社外に向けてメドレーエンジニア組織の情報発信量を増やすため
事業部を超えたエンジニア同士の知見/情報交換の機会を増やすため

そして何より、アドベントカレンダーという年末行事をみんなでワイワイ楽しみたい気持ちで実施しました 🎅

こうした目的があり、テーマは絞らず社員一人一人のカラーが出るようにしました。
（個人的にはカジュアルに楽しんで参加してもらいたい、テーマを絞ることでハードルを上げたくなかったという思いもありました）

どうやって運営をしたのか

▼ はじめに決めたこと

実施の目的
この取り組みの背景を明確にし、その目的をしっかりと定義することで、全員が共通認識を持って取り組めるようにしました。

執筆ガイドラインの作成
社外に向けて発信する記事であるため、記載ルールを明確に設定しました。ガイドラインがあることで、レビュー時の手戻りを最小限に抑え、スムーズに運営することを目指しました。

執筆場所（Qiita、Zenn、はてなブログなど）
執筆する媒体については、基本的に各自にお任せしました。各媒体での個人アカウントを用いて記事を作成し、その後、企業アカウントに紐付けることで管理を統一しています。

執筆〜公開までのタスクをドキュメント化
執筆から公開に至るまでのタスクを具体的にドキュメント化しました。これにより、全員が同じフローに沿って円滑に作業を進めることができました。

▼ 気をつけたこと

メドレーでは今回のアドカレをはじめ、社外へ情報発信をする際はしっかりとレビューをする体制を敷いています。
アドカレについては、公開前に必ずエンジニア視点での技術レビューと広報視点でのレビューのダブルチェックを実施していました。また、公開後は CTO・テックブログ運営チームで最終チェックをしていました。
今回のアドカレはカジュアルに楽しんで参加してもらう取り組みなので自由に執筆してもらいましたが、上場企業としてダブルチェックは欠かせません…！

社内の反応

スタート時は不安もありましたが、各方面から協力があり無事に枠を埋めることができました 🙌

「ブログ書こう！」と積極的に呼びかけてくれる場面もあり、メドレー社員の温かさにほっこりしていました…感謝です！

また、以下のようにポジティブな反応をもらうことができました ✨

最終的には目的であった、

社外に向けてメドレーエンジニア組織の情報発信量を増やすため
事業部を超えたエンジニア同士の知見/情報交換の機会を増やすため

のどちらも実現できたと考えています。

最後に

人気があった記事や個人的に面白かったブログをいくつかピックアップします。
他にも素敵なブログがたくさんあるのでぜひご一読いただけると嬉しいです🙌✨

耳コピアプリの個人開発記録：ドキュメントドリブンで描くプロダクト設計 _@nayucolony
https://zenn.dev/medley/articles/personal-project-with-document-driven

トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ _@yujittttttt https://developer.medley.jp/entry/2024/12/03/100122

私と地域 Ruby コミュニティとメドレーの関わり _@Kirika_K2
https://developer.medley.jp/entry/2024/12/12/180014

エンジニアがユーザーヒアリングやってみた _@eriririri
https://qiita.com/eriririri/items/738274113dbc93e10d82

ルビと格闘した話 _@rio-song
https://qiita.com/rio-song/items/94879fc82ce90253c5b4

EM やテックリードにチャレンジすることになったら考えたい「時間」のこと _@ymzkmct
https://ymzkmct.hatenablog.com/entry/2024/12/22/100000

1,000 人を超える規模の組織で、全社生成 AI 推進プラットフォームとして Dify を導入し始めた話 _@terukura
https://zenn.dev/medley/articles/54ad12a3557656

We’re hiring

メドレーでは一緒に働く仲間を大募集しています！
カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております！

募集の一覧
https://www.medley.jp/jobs/

医療エンジニアリング領域盛り上がっています！メドレーについてお話します！
https://pitta.me/matches/BtcyDvCvUZtx

メドレーの開発チームについて知りたい方！ぜひお話ししましょう！
https://pitta.me/matches/sNeEHMdSLZpB

株式会社メドレーのデザインについてお話します！
https://pitta.me/matches/vshCmTBHhzCQ

pmconf 2024にゴールドスポンサーとして協賛しました！

Thu, 09 Jan 2025 02:57:53 GMT

こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がられています。

表題のとおり、メドレーは 2024/12/5-6 の 2 日間にわたって開催された『pmconf 2024』にゴールドスポンサーとして協賛させていただきました。pmconf は 2016 年から開催されており、Product Manager 向けのカンファレンスとしては国内最大（2024 年 6 月時点）の規模を誇ります。プロダクトマネジメントに携わる人たちが共に学び・切磋琢磨する場として数々の発見・挑戦・苦悩が共有され、今年も大変刺激的な 2 日間となりました。

今回は Day 1 (オンライン配信)の舞台裏＋ Day 2 (会場現地)の様子を、参加したメンバーの感想とあわせて皆さんにお伝えします！

Day 1（オンライン配信）

1 日目は YouTube Live でのオンライン開催。今年のテーマ “QUEST.” に沿って、日々の探究から生まれた濃密な経験や知見が 5 トラック・ 40 セッションに渡って展開されました。

メドレーからは私が登壇し、入社直後にぶつかった壁と、それを乗り越える過程で発見した『新任 PdM に求められる行動様式』について皆様にシェアする…つもりだったのですが…なんと当日全く声が出ないという想定外の事態に…。急遽 CLINICS の Product Manager 田所にプレゼンをお願いする展開となりました。

(突然の代打登壇を抜群の安定感で進める田所と、恐縮そうな顔をしつつ本番中に手元で台本を update している私)

ご視聴くださった皆様、本当にありがとうございます！そして突然の変更にも関わらず臨機応変に対応してくださった運営メンバーの皆様にも、この場を借りて御礼申し上げます。

なお Day 1 は前述のとおり 5 トラック構成なので「どれかを選ぶとその他は選べない」という Product Manager らしい意思決定が求められるのですが、後日 YouTube にアーカイブ動画がアップされるので安心して選んだセッションに集中することができます。今年のアーカイブもすでにアップされていますので、ぜひご視聴ください。

ちなみにメドレーが提供している患者向け総合医療アプリ「CLINICS(クリニクス)」を利用すると、例えば会議の合間にオンライン診療・オンライン服薬指導を受けられるのはもちろんのこと、その処方薬を薬局から Uber Eats が即日配送してくれるという多忙な皆さまに最適なサービスがスタートしました。おかげで私も速やかに処方薬を服用することができ、重症化する前に声を取り戻せました。宣伝のために身体を張ったことにしておきます。心からオススメです。

メドレー、患者向け総合医療アプリ「CLINICS」で処方薬の当日配達を開始〜Uber Eats との連携で、オンライン診療・服薬指導後に全国の Pharms 導入薬局を通じた即時配送が可能に〜 | 株式会社メドレー

Day 2 （ベルサール羽田空港）

2 日目はオンサイト開催。会場は空港ターミナル直結のベルサール羽田空港でした。定員 300 名をゆうに超える申込みがあり早期にキャンセル待ちになっていましたが、それだけに参加されていた皆さんの熱量は想像以上でした。

メドレーからは人材プラットフォーム・医療プラットフォームそれぞれの PdM に採用・広報チームも加わり、メイン会場の展示ブースを中心に多くの皆様と交流させていただきました。

会場ではパネルディスカッションに始まり、ワークショップ形式の Open Space Technology (OST) 、ブースを巡るスタンプラリーなど多数のイベントが展開され、至るところでエネルギッシュなやり取りを見ることができました。ワークショップ時間以外メドレーブースも終始盛況で、事業やプロダクトについて様々な角度から質問をいただきました（メンバー一同、脳にたくさん汗をかく 1 日でした）。

医療 UX の「ここなんとかならない？」

iOSDC 2024 や DroidKaigi 2024 同様、メドレーブースでは展開しているプロダクト群の紹介に加え、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。

pmconf 2024 での結果はこちら！

待ち時間が長い！問診票を毎回書いたり、同じことを聞かれるのが面倒！病院探しに時間がかかる・オンラインで予約したい！ …という項目に票が集まる結果となりました。

これらの課題は私たちメドレーが患者向けに提供している総合医療アプリ「CLINICS」で解決・解消を目指しているもので、すでに提供済みのオンライン予約・事前問診・キャッシュレス決済等のお話をさせていただくと「こんなに機能あるんですね」「めちゃくちゃ便利！」という反応をいただくことが多かったです。嬉しい反面、価値を届けきるためのアクションをもっと積み重ねていかなくては…と痛感する時間でもありました。

終わりに

メドレーはこれからも、医療ヘルスケアの未来をつくるために、様々なプロダクト・サービスを構想し、開発し、提供していきます。

最後に改めて、pmconf 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした！そして、刺激的な 2 日間をありがとうございました！

メドレーでは一緒に働く仲間を募集しています

この記事やブースなどでメドレーに興味を持ってくださった皆さま、ぜひご連絡をお待ちしております。カジュアル面談などのアレンジも可能ですので、お気軽にお問い合わせください！

RubyKaigi 2024 に Ruby Sponsor として協賛しました！ - MEDLEY Developers Portal

私と地域Rubyコミュニティとメドレーの関わり

Thu, 12 Dec 2024 09:00:14 GMT

こちらの記事は Medley（メドレー） Advent Calendar 2024 の12日目の記事です。

はじめに

はじめまして。医療プラットフォーム事業部　プロダクト開発室　Dentis開発グループでグループマネジャーをしている牧（X: @Kirika_K2）と申します。

メドレーには2019年に入社し、以来、歯科医院向けのクラウドサービスDentisの立ち上げ、プロダクト開発に携わっています。
Dentisは医療機関の予約・受付・問診・カルテの記録・会計業務・保険請求業務までをトータルでサポートするクラウドシステムで、主にRuby on RailsとReactで作られています。日々歯科医療ドメインでお客様の声に向き合いながら、医療DXを推進しています。
着実に成長しているプロダクトですので、もしご興味ありましたら、カジュアル面談等受け付けておりますので、お声がけください。（宣伝終）

普段はプロダクト開発に従事していますが、プライベートでは地域Rubyコミュニティの表参道.rbを主催しておりまして、メドレーでも地域Rubyコミュニティ支援という形で、表参道.rbのスポンサー企業として、協力してもらっています。
今回のAdvent Calendarでは、一地域Rubyコミュニティオーガナイザーの立場から見たメドレーの地域Rubyコミュニティとの関わりについて書こうと思います。

表参道.rbと私の関わり

表参道.rbは2015年頃から始まった、表参道周辺のエンジニアが集まってRubyの周辺技術に関する情報交換をする地域Rubyコミュニティです。
毎月第１木曜日に開催しており、毎月1人10分程度のトークセッションを6〜７本と交流会を行っています。

一部例外があり、開催日が祝日等と重なる場合は、1週間ずらして第2木曜日に開催しています。
ちょうど今月の第1木曜日は島根県松江市で、RubyWorld Conference 2025が開催されており、表参道.rbに普段来てもらっている多くの方も松江に集合しているので、第2木曜日の開催になります。（つまり今日です！）

毎月第2週は、後ほどお話する六本木.rbが定期開催されており、合同開催という形での開催しています。
どちらも楽しいコミュニティですので、是非遊びに来てください。

表参道.rb
https://omotesandorb.connpass.com/

六本木.rb
https://roppongirb.connpass.com/

私は、2018年頃から運営に関わり始め、その後メドレーに入社し、職場が六本木に変わった後も続けていました。

コロナ禍によるオンライン開催移行、そしてオフライン開催の復活

2020年にコロナ禍になり、オフラインでの開催ができなくなり半年ほど開催を見送っていたこともありましたが、オンライン開催に移行して開催してきました。
ちょうどコロナ禍で混乱していた頃、コミュニティを活動休止にするか、オンライン開催に移行するか悩みましたが、一度中止にしてしまうと再開するきっかけを失ってしまう可能性もあったため、これまで通りの頻度で開催することに決めました。
またオンラインに移行するにあたって、もくもく会など、これまでと異なる形式での開催も考えましたが、いくつかのコミュニティがオンラインに移行している中、トークセッションがあるコミュニティは貴重、という意見をいただき、これまで通りの形式で進めていくことにしました。

オンライン開催の時は人の集まりが良くない時もあり、5名ぐらいで開催することもありましたが、毎回誰かが発表ネタを持ち込んでくれ、また発表が少なかった日は、少人数で余った時間をディスカッションに充てることができたので、これはこれで面白みがありました。
また普段遠方で表参道.rbに参加できないような方にも参加していただいていたので、今も表参道.rbが続いているのは、当時少人数でも途切れないようにコミュニティを支えてくださった方々のお陰です。とてもありがたいことですね。
御存知のとおり、コロナ禍は長く続くことになり、オンラインでの開催は2020年11月から2023年6月まで行われました。

RubyKaigiがオフライン開催に戻り、2023年の松本での開催から東京に戻った後、表参道.rbもオフラインに戻すことを考え始めました。
その際に必要になるのが開催する会場です。当時はまだオフラインで会場を提供していただける場所は多くなく、まず最初に相談したのは自分の勤務先であるメドレーでした。
メドレーでは過去にRubyコミュニティのために会場提供をしたことはありませんでしたが、私が地域Rubyコミュニティの主催を継続していたこともあり、活動を後押ししていただけ、快く会場提供と懇親会の予算をつけてもらえました。

表参道.rb #87 では弊社が会場提供させていただいております!#omotesandorb #ruby https://t.co/PDmvLeqLPN #omotesandorb
— メドレーディベロッパー公式 (@medley_dev) June 16, 2023

ありがたいことに、この回の表参道.rbに参加してくださった方の中から、「自分の会社でも会場提供したい」という申し出を受け、現在の表参道.rbは10社ぐらいの企業から会場スポンサードをしていただき、毎回開催会場を変えながら、継続しています。

そして、今年2024年8月に表参道.rbはめでたく100回目の開催を迎えました。
本当に様々な人に支えられて開催できた100回開催だな、と思います。

表参道rb 100回〜〜！！👏👏👏👏👏#omotesandorb #roppongirb pic.twitter.com/1qe2aJWMcZ
— あっきー🍺ツクリンクEM (@kuronekopunk) August 1, 2024

六本木.rbの復活とメドレーとの関わり

ちょうど今年のはじめぐらいの頃に、表参道.rbに参加されていたryoskさん(X: @ryosk7)から六本木.rbを再始動させたいという話があり、会場を探しているという話がありました。
六本木.rbは六本木周辺の企業で働くエンジニアが集まるRubyコミュニティで、コロナ前までは時々開催されていたようですが、こちらもコロナで休止していたコミュニティでした。
メドレーは六本木の企業ということもあり、表参道.rb同様に六本木.rbも支援してもらいたいということで会社に相談したところ、こちらも会場提供と懇親会予算をつけてもらえることになりました。

この時メドレーはRubyKaigi 2024のRubyスポンサーとして協賛しており、最終日の基調講演前のスポンサーセッション枠をもらったタイミングだったため、どうせなら、盛大に宣伝してもらおうということで、弊社VPoEの山崎にも地域.rb支援の件について紹介してもらいました。

ただいま発表がありましたが、
Roppongi.rb が復活します！！！🎉

六本木周辺の企業さんのお力を借りてオフライン開催をします。
6月13日はメドレーさんのオフィスをお借りします。

これからconnpassの方も展開します！
よろしくお願いします🙌#rubykaigi https://t.co/zo2t6KGPrj
— ryosk7🦎 (@ryosk7) May 17, 2024

それ以来、六本木.rbはメドレーを含む4社で月1回の定期開催しています。

メドレーさんのオフィスに着きました！
今日はこちらでRoppongi.rbを行います。#roppongirb pic.twitter.com/UioFP3FEyY
— ryosk7🦎 (@ryosk7) June 13, 2024

地域Rubyコミュニティ支援に伴う、ポジティブな効果

このような活動を続けてきて、会社にどのような変化があったかについて触れたいと思います。
まず1つ目は「普段の仕事で会わない社内の人たちと社外のイベントで顔を合わせるようになった」ことです。

2022年RubyKaigiの様子、この年はコロナ休止からのリブートということもあり、ブース出展もなかったので、自分しか参加してなかった

2023年RubyKaigiの様子、会場の様子を見てきて欲しいと言われた若手エンジニアと。実はこの時写真を撮ってもらった人が、その後新卒としてメドレーに入るというミラクルが起きました

2024年RubyKaigiの様子、スポンサーブースにて

社内でRubyのイベントを告知するようになってから、参加してくれる人も増えました。

先日のKaigi on Railsでも、業務とは関係なく来たと言う人達で集まる一幕もあり、変化を感じた部分でもありました。

もう一つは、やはり社外への認知で、今年のRubyKaigi 2024ではRubyスポンサーでブースを出していたのですが、「表参道.rbで会社に行ったことがあります」と教えてくださる人が数名いらっしゃったり、今年入社された方が「表参道.rbに参加したことがあります」と教えてくださったり、少なからずポジティブな側面があるなぁ、と感じることがありました。こういった声が定期的に聞けるのはスポンサードしている側としてはとても嬉しいです。

地域Rubyコミュニティのオーガナイザーから見た、メドレーと地域Rubyコミュニティとの関わり

さて、ここまではメドレーと地域Rubyコミュニティとの関わりについてお話してきました。
ここからは私の所感について書きます。ここから先は私がオーガナイザーとして普段コミュニティ活動について考えていることですので、特段会社から何か言われているということではありません。誤解なきようお願いします（笑

会社から見ると「地域.rbのスポンサードをしました！」、地域Rubyコミュニティのオーガナイザーから見ると「地域.rbを開催しました！」という話で終わるのですが、地域Rubyコミュニティのオーガナイザーをしつつ、会社として地域.rbの支援をする、という立場でみると、少し違った見え方になります。

企業がこういったスポンサードを行う際には、一定の費用対効果を考える必要があるからです。
私もスポンサードする側の立場から、そういった事情を抜きにすれば、「知名度向上のために積極的に行うべき」「採用面にも少なからずポジティブに働いている」と主張することはできますし、実際そういった側面はあると思います。しかし、それがどの程度プラスに働いているのかを正しく計測する方法がないため、基本的にはコミュニティはボランティアに近い形で支援してもらうことになります。
そういったものは、長く続くとは限りませんし、普段ご支援いただいている会社の窓口担当の方や、決済責任者が変わるだけで状況は変わります。

これについては、オーガナイザーとしては仕方ないものと考えており、コミュニティを持続可能なものにするために、最大限努力をする必要があると考えています。

以前表参道.rb 100回のときに、「表参道.rb 100回に寄せて」というタイトルで、「コミュニティが継続していくためにはどうすればよいか」というお話をさせていただきました。その中で、コミュニティが継続するための3要素「主催者のやる気・スポンサード企業・参加者」の3つを挙げ、コミュニティが長く続くためにどうするべきか、というお話をさせていただきました。

「表参道.rb 100回に寄せて」

メドレーも現在は地域Rubyコミュニティを無償で応援している立場ではありますが、これが未来永劫続くかは分かりません。が、可能な限り長期間支援できるように、一地域Rubyコミュニティのオーガナイザーとして、そして会社の中の人として、努力したいと思っています。

まとめ

地域Rubyコミュニティのオーガナイザーから見た、メドレーと地域Rubyコミュニティとの関わりについて書かせていただきました。
メドレーでは、表参道.rbと六本木.rbの地域Rubyコミュニティの支援をしており、定期的にメドレーでも開催しております。

もし、ご興味ありましたら是非遊びに来てください。

表参道.rb
https://omotesandorb.connpass.com/

六本木.rb
https://roppongirb.connpass.com/

JSConf JP 2024にプレミアムスポンサーとして協賛しました！

Fri, 06 Dec 2024 09:31:34 GMT

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。

今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「JSConf JP 2024」にプレミアムスポンサーとして協賛させていただきました。

JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。

会場の様子

会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。

当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。セッション数が多くとても充実したイベントになりました。

会場入り口

メドレーブースの様子

メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨

特に多かった「医療体験あるある」は以下 2 つ。

① キャッシュレス決済がしたい
⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い
⇨ 現金を引き落としに一度コンビニに行くことがあった

② 待ち時間が長い（ほぼ同率１位）
⇨ 予約したはずなのに待ち時間が発生している
⇨ いつも混んでいるので病院に行くのが疲れる

実際に CLINICS アプリの画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。

多くの方にお越しいただきました 🙌

自身が開発しているプロダクトに込める思いは人一倍 👀✨

メドレー登壇

当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。

高橋のセッションの様子

次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！

登壇した髙橋より一言

セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。

コンポーネントの分割粒度をチーム全体でどのように統一していますか？

発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。

状態管理ライブラリはどのように使い分けていますか？

非同期状態管理は Tanstack Query、フォーム状態管理は React Hook Form、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。

👇 登壇資料はこちら

德永のセッションの様子

登壇した徳永より一言

Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。

👇 登壇資料はこちら

終わりに

メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！

最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！

ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨

メドレーでは一緒に働く仲間を募集しています。

ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！

当日会場でお時間いただいた皆様、ありがとうございました！

メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Centerは欲張りなんだ。

Tue, 03 Dec 2024 01:01:22 GMT

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。

Who are you?

メドレーで主にSRE活動を行っている人材プラットフォーム本部第四開発グループの玉井です。

最初に簡単にFAQ形式で自己紹介させていただこうと思います。

（昨日は何を食べましたか） ：麺系ファストフードでは一番好きな小諸そば。
（好きな本は何ですか） ：柳井正さんの自伝書『一勝九敗』は心に残っています。
（遊びに行くならどこに行きますか） ：アウトドアが好きなのでキャンプなど。

今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。

セキュリティと管理コストの天秤

メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。

一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。

AssumeRole概要図

それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。

AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。

AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。

セキュアな環境を維持したまま、管理コストもなるべく下げたい。

そこで導入を決めたのが IAM Identity Center でした。

IAM Identity Centerの導入検討

結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。

IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。

IAM Identity Centerとは

元は AWS Single Sign-On （AWS SSO） というサービス名でした。これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。

IAM Identity Center概要図

IAM Identity Centerを導入した決め手

SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。

つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。

では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。

そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。

まさに最強で無敵のIAM Identity Centerです。

IAM Identity Centerの導入

ここではIAM Identity Centerの導入の流れを簡単に説明いたします。一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。

IAM Identity Center全体図

SSOユーザの作成

SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。最低限必要なのは名前とメールアドレスのみです。作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。

SSOユーザ作成画面

SSOグループの作成

SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。

SSOグループ作成画面

許可セットの作成

許可セットは、IAMロールの素になるものです。ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。

プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。

許可セット作成画面

プロビジョニング

“SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。

プロビジョニング概要図

SSOアクセスポータル画面

SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！

AWSアクセスポータル画面

一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。

AWSアクセスポータルアクセスキー確認画面

導入後に対応したこと

これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。

~/.aws/configの修正

ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。

[default]
sso_session = my-sso
sso_account_id = 999999999999
sso_role_name = xxxxxxxxxxxx

[sso-session my-sso]
sso_start_url = https://xxxxxxxxxxxx.awsapps.com/start
sso_registration_scopes = sso:account:access

sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。

[tools]
awscli = "latest"

この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。

ターミナルでsso login

ブラウザで認証

開発環境へのアクセスキーの渡し方

開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。

この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。

これもmiseで定義することで、全開発メンバーにもれなく対応できました。

# 一部抜粋
if ! $(aws2-wrap --profile "$profile" --export); then
    aws sso login --profile="$profile"
    eval "$(aws2-wrap --profile "$profile" --export)"
fi

# 一部抜粋
from dotenv import set_key

def update_env_file(env_file, key_value_pairs):
    try:
        for key in key_value_pairs:
            value = key_value_pairs[key]
            set_key(env_file, key, value, quote_mode='never')
    except Exception as e:
        print(e)

Terraform, Packerの対応

最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。

Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、“ログイン時にSSOセッションの存在有無の確認” → “なければSSOログイン” をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。

# 一部抜粋
function get_caller_identity () {
	set +eu

  for i in {1..3} ; do
    command "aws sts get-caller-identity --profile $1"

    if [[ $? = 0 ]]; then
      break
    else
      echo "Not logged in"
      command "aws sso login --profile $1"
    fi
  done

	set -eu
}

最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。

[profile packer]
credential_process = aws --profile default configure export-credentials --format process
region = ap-northeast-1
output = json

対応して良かったこと

管理者目線で良かったこと

管理者目線では、AWSのユーザ管理が大分楽になりました。

これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。

IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。

また、与えている権限の管理も楽になりました。

IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。

利用者目線で良かったこと

利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました。

対応して困ったこと

12時間の壁

SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。

深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。

個人的にはセッション時間の上限の時間もう少し上げて欲しいです。

利用できないサードパーティーツールの存在

AWSにアクセスするためのサードパーティーツールは様々ありますが、AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。

SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。

最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。

まとめ

これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。

もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。

そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！

We’re hiring!

メドレーでは各種エンジニアを絶賛募集中です！

カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！

日本 CTO 協会 DX Criteria WG 所属の ahomu さんをお招きして Web フロントエンド版 DX Criteria 勉強会を開催しました

Fri, 29 Nov 2024 00:45:50 GMT

はじめに

皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。

11/15(金)にも社内勉強会を開催したのですが、題材をWeb フロントエンド版 DX Criteriaについてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤歩(@ahomu)さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。

今回の勉強会開催の背景

今年 4 月に Web フロントエンド版 DX Criteria が発表されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。

作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。

勉強会について

講演の様子

今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。

真剣に講演を聞くメンバー

社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。

歴史を踏まえた昨今のフロントエンドの技術的な変遷
現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係
開発持続性を実現するための、開発環境について
Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説
Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説
アセスメント後に、どのような整理をして改善していけばよいかの指針について

佳境に入った講演の様子

上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。

参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。

改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。

多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました!

ahomu さんと記念撮影

さいごに

メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。

自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。

JSConf JP 2024に協賛し、医療業務システムのReactコンポーネント設計を紹介します

Mon, 11 Nov 2024 06:54:08 GMT

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。

メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。

今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。

JSConf JP 2024 とは

JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。

国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。

公式サイト： https://jsconf.jp/2024/

スポンサーワークショップでは React コンポーネント設計について発表します

16:00 からトラック D にて、クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。

徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP

【ワークショップタイトル】

徹底解剖！医療業務システムの React コンポーネント設計

【ワークショップ詳細】

医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。加えて、長期利用を見据えた保守性の維持も重要です。これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。

本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。具体的には次の内容を予定しています：

コンポーネントレイヤーと分割粒度
独立性の高い複合コンポーネント設計とデザインパターン
代表的なフロントエンドロジックの分類とそれぞれの実装手法
クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用
開発速度と品質を両立するためのテスト戦略

発表予定内容の一部：コンポーネント分割粒度の紹介

ブースでメドレーのエンジニアとお話しましょう

トラック D がある 2F の Communication Area にブースを出展します。

ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。

休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。

おわりに

最後までお読み頂きありがとうございました。

当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！

患者向け薬局検索機能のパフォーマンスを OpenSearch 導入により改善した話

Thu, 31 Oct 2024 14:36:00 GMT

こんにちは。かかりつけ薬局支援システム「Pharms」の開発を担当している熊本です。先日、総合医療アプリ「CLINICS」の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。

医療プラットフォームのプロダクト紹介と構成

まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。

患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。

CLINICS の薬局検索機能

CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。

薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！

他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。

この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。

潜在課題の表層化

先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。

データ量と検索トラフィックが増加してきた
データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた
検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた

潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。

患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴かなと改めて感じました。

しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。

課題の対応に向けて

上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。

ここに関しては、プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできたことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。

対応

パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。

OpenSearch の導入

設計・実装

OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。

まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。

index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。

検証

実装後はデグレチェックと負荷耐久性の観点で検証を行いました。医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。

負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、AWSのトラブルシューティングなどを参考にして基準を十分にクリアできるかどうかの観点で行いました。

リリース

諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。

二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。

モニタリング強化

これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。

インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。

結果

結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。

パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。

まとめ

今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。

Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。

メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。

DroidKaigi 2024にゴールドスポンサーとして協賛しました！

Tue, 15 Oct 2024 03:04:19 GMT

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！

さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「DroidKaigi 2024」にゴールドスポンサーとして協賛させていただきました。

DroidKaigi は、今年で 10 年目を迎える Android カンファレンスです。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。

そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。

今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！

会場の様子

DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。

軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！

また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！

DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！私も参加し、様々な企業の方とお話しすることができました。

また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細はこちら）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！

多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。

メドレーブースの様子

メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。

DroidKaigi 2024 での最終結果はこちら！

1 位　待ち時間が長い！

2 位　何科に通えば良いかわからない！

3 位　病院探しに時間がかかる・オンラインで予約したい

iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。

メドレーでは、これらの課題を解決するべく、様々なプロダクト・サービスを展開しています。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「CLINICS」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。

待ち時間が長い！

CLINICS アプリを使ってオンラインで診療を受けることができます
CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます

何科に通えば良いかわからない！

CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します

病院探しに時間がかかる・オンラインで予約したい

CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます

また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。

CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。

セッションやブース

DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。

セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト

SwiftUI、Jetpack Compose、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、宣言的 UI という観点から見ると確かに同じ思想をしているなと感じることができました。

(詳細ページはこちら)

セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！

アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。

(詳細ページはこちら)

セッション：Android View から Jetpack Compose へ〜Jetpack Compose 移行のすゝめ〜

タイトルの通り、Jetpack Compose 移行に関するお話で、具体的な移行の事例も交えながら説明されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。

(詳細ページはこちら)

ブース：株式会社ゆめみ

DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。

Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。）

私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！みなさんは分かりましたか？

終わりに

メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。

最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！

メドレーでは一緒に働く仲間を募集しています。

ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！

引用元：LeanとDevOpsのために E2E テストができること

シンプルで低コストな動画配信の実現：Cloudflare Stream 導入事例

Mon, 30 Sep 2024 01:24:47 GMT

こんにちは。ジョブメドレーアカデミーの開発を担当している德永です。今回は、私たちのオンライン動画研修サービスで Cloudflare Stream を導入した経緯と、そのメリット・デメリットについて詳しくお話しします。

背景

ジョブメドレーアカデミーは、Web / モバイルアプリで提供している介護・障がい福祉・在宅医療事業者向けのオンライン動画研修サービスです。直近では複数の業種への提供を開始し、多くの職員の方々に利用していただけるプロダクトに成長しています。

要件に合った動画配信プラットフォームを探す

ジョブメドレーアカデミーでは、外部の動画配信プラットフォームに研修動画をアップロードして、発行される配信用の URL をプロダクト内で利用し、サービス提供を行っています。これは動画配信基盤をメンテナンスするコストを削減し、動画配信の安定性を確保出来ることを目的としています。

もともと利用していた動画配信プラットフォームは、非常に機能が豊富で様々なユースケース・プロダクトに利用することが可能でした。しかし、豊富な機能が提供されていてもジョブメドレーアカデミーで必要とされているのは主に動画の配信のみであり、その他の機能はほとんど必要ありませんでした。

また、プロダクトの急成長に伴って動画配信費用の増大 / 定期的な動画配信容量の見積もりやそれに伴う商談といった、サービス利用の上で発生するコスト面に課題を感じていました。

そこで、動画配信プラットフォームの移行を検討することにしました。移行先の動画配信プラットフォームを選定する際、私たちが重視したのは以下のポイントです。

シンプルな運用：専任のインフラエンジニアがいなくても簡単に運用できること
コスト効率：使った分だけの料金が発生し、予算管理がしやすいこと
機能面：高度な機能は不要で、動画配信に必要な最低限の機能があること

これらの要件を満たすサービスを検討した結果、私たちは Cloudflare Stream を採用することにしました。

競合サービスとの比較

ジョブメドレーアカデミーでは、Cloudflare Stream 導入前にいくつかの動画配信プラットフォームを検討しました。その中でも、特に比較検討したのが ULIZA と AWS Media Services でした。

ULIZA

ULIZA は日本企業が提供する動画配信プラットフォームで、日本語でのサポートが充実している点が魅力でした。また、動画の編集、配信、分析など、多岐にわたる機能を提供しており、Web サービス上で CMS 機能も利用できるため、多くのユースケースに対応できる柔軟性があります。

しかし、ジョブメドレーアカデミーでは、動画配信の基本的な機能のみが必要であり、ULIZA のようなリッチな機能は必ずしも必要ではありませんでした。また、料金体系も Cloudflare Stream と比較して高額であったため、コスト面での懸念がありました。

AWS Media Services

AWS Media Services は、AWS 上で動画配信インフラを構築できるサービスです。柔軟性が高く、プロダクトの要件に合わせてカスタマイズできる点が魅力ですが、インフラ構築や運用には開発工数・保守運用コストを要するため、トータルでのコストが高くなる可能性があります。

ジョブメドレーアカデミーでは、前述の通りインフラ専任のエンジニアがいないため、運用負荷の低いサーバーレスな動画配信プラットフォームが求められていました。そのため、AWS Media Services は採用を見送ることになりました。

Cloudflare Stream を採用した理由

Cloudflare Stream の採用を決定した理由には、いくつかの要素があります。

シンプルな料金体系

Cloudflare Stream は、動画の配信時間と保存時間に基づくシンプルな従量課金制です。

配信費用： 1,000 分あたり 1 ドル
保存費用： 1,000 分あたり 5 ドル

Pricing | Cloudflare Stream docs

他の動画配信プラットフォームと比べてかなり明瞭な料金体系となっており、予算管理を行いやすいのが特徴です。課金形態が少し異なるため比較しづらいのですが、ジョブメドレーアカデミーのケースでは競合サービスと比較しても安価な料金での利用が可能でした。

ジョブメドレーアカデミーでは、7,500 本以上の動画を提供しており、月額で約 390 ドルの保存費用 + 再生時間による配信費用が発生しています。この料金体系のおかげで、今後のコストを明確に予測でき、予算に応じた運用が可能になりました。

実際の課金時の画面

高品質な動画を安定して提供

Cloudflare Stream では、ユーザーが高画質・低画質どちらで視聴しても料金が変わらないという特長があります。特に、私たちのような研修サービスでは、動画内のテキストや細かい部分の可読性が重要となってくる場合もあります。以前利用していたサービスでは、データ転送量によって料金が変動したため、高画質の動画を提供する際にコスト面での懸念がありましたが、Cloudflare Stream ではその心配がなく、安定した高画質の動画配信が可能になりました。

移行コストの低さ

ジョブメドレーアカデミーでは前述の通り、もともとは別の動画配信プラットフォームを利用していました。そちらから移行する作業も簡単に実現可能です。

プロダクト上で問題なく動画が視聴できるかの確認は、Web 上で設定や管理が完結するため、動画をアップロードしただけで配信用の URL なども発行され、インフラ専任のエンジニアがいなくても問題なく検証に進むことが可能でした。

実際の動画ファイル移行についても、アクセス可能な URL から自動で取り込む機能を API として提供しているため、既存の動画プラットフォームで期限付きのリンクを発行し、Cloudflare Stream API 経由で動画配信の URL を渡すだけでアップロードすることが可能です。

開発者体験の良さ

開発者体験という面でも、 Cloudflare Stream の魅力は非常に大きかったです。また、Go、TypeScript、Python 向けの SDK が提供されており、API を使った開発が非常にスムーズに進みました。

さらに、専用プレイヤーの提供もあるため、動画の視聴環境を迅速に構築できました。API ドキュメントも非常に充実しており、SDK が未対応の言語でも容易に実装が可能です。

Example なども充実した API ドキュメント

実際に導入しての所感

Cloudflare Stream を実際に運用してみて感じたメリットと、触ってみるまで判明しなかった課題についていくつかご紹介します。

コスト面での満足度 ⭕

期待していた通り、シンプルな料金体系で予算管理が非常に容易でした。また、記載されている料金以外の追加課金が発生せず、コスト面での不安は感じていません。

安定性 ⭕

導入してから今まで、Cloudflare Stream の安定性に課題感はありません。障害情報は Cloudflare Status で確認できるため、運用の際の不安要素も少なく済んでいます。

運用面での評価 💭

以前利用していたサービスでは、利用帯域幅の監視やプラン変更の手続き・次回契約のための想定帯域幅算出に工数がかかっていましたが、Cloudflare Stream ではそれが不要になり、運用工数を削減できました。

一方、CMS 機能が最小限に抑えられている点は導入において課題になりやすい点です。例えば、動画のディレクトリ管理ができないため、ID ベースでの管理を自前で設計する必要があります。また、検索機能なども最低限しか提供されていないため、基本的に私達のサービスでは、 Cloudflare Stream 上にアップロードされた動画の meta フィールドに API 経由でアクセスし、動画の種別管理（テスト用の動画 / 本番用の動画など）を行っています。

その他にも、 Cloudflare 側で提供されているアラートの粒度が粗いのは課題としてありました。配信容量と異なり保存容量は月単位で事前購入する課金形態です。そのため、ユーザーの利用状況に合わせて残容量が減ってきたら容量を購入する必要があります。完全にサービス提供側でアップロードする動画を管理できる場合は問題にならないのですが、ジョブメドレーアカデミーではユーザーが動画をアップロードするユースケースも存在するため、容量の監視が必要です。

Cloudflare が提供している機能として容量の上限が近づくとメールが届くのですが、割合での通知のため、総利用容量が増えた場合は「残り数%ではあるが、容量の実数（nGB アップロード可能か）を見ると当分問題ない範囲である」ということが多々あり、実際に容量を購入しないと不足してしまうタイミングがいつかわかりません。Cloudflare Stream 側で残容量を取得する API が提供されているため、動画アップロード時にこの API を利用して容量確認を行い、残容量が少なくなった場合に Slack 通知を行うように開発を行いました。

実際に送信されるメール通知。3,322 分あれば直近は充分なのだが、毎日通知が来る

また、Web ダッシュボード上でのファイル管理が限定的であるため、他の動画配信プラットフォーム（ULIZA などのリッチな機能を持つ動画配信プラットフォーム）に比べて管理の手間がかかる部分もあります。

実際のダッシュボード画面

実際の動画詳細画面

機能面での評価 💭

基本的には期待していた通り、動画配信の実装をシンプルに実現することができました。しかし、一部のケースにおいて HLS / MPEG-DASH を使った動画配信への対応に工数がかかりました。

HLS / MPEG-DASH での配信はアダプティブ・ビットレート・ストリーミングが基本となり、視聴者のネットワーク環境によって動的に配信される画質が決まります。この機能はネットワーク環境に最適な画質が自動で選択されるため、動画を視聴する職員の方々にとってより良い視聴体験を提供することに繋がりました。

一方、この機能を利用すると一部の動画プレイヤーでは視聴端末のネットワーク環境に適した最高画質でのみ配信され、画質がプレイヤー上で選択出来ないという問題がありました。ジョブメドレーアカデミーの動作環境の中では、iOS Safari x Stream Player や React Native の Expo Player が該当します。

ジョブメドレーアカデミーでは、私用スマホを利用して動画研修を受講される職員の方が Wi-Fi 環境を用意できず、データ通信量を節約するために画質を下げて視聴するというケースがあります。自動的に最高画質での配信が行われてしまう場合、意図せずデータ通信量が増大してしまうことで一部の職員の方にとって不利益が生じる可能性があります。

以前まで利用していた動画配信プラットフォーム上では、mp4 ファイルで複数画質の動画が提供されていたため、ダウンロードする mp4 ファイルの画質を選択することで視聴する職員の方が画質を制御することが出来ました。一方、 Cloudflare Stream では mp4 ファイルでの配信自体は設定により可能ですが、配信される mp4 の画質は常に最高画質での配信に固定されるため、今回の画質を選択したいというケースには利用できませんでした。

また、 mp4 を利用すると動画配信が発生した段階で動画全体の再生時間が課金対象になります。例えば 30 分の動画を 1 分だけ視聴して配信画面を閉じた場合、 HLS / MPEG-DASH だと 1 分が配信費用の課金対象として計上されるのに対し、 mp4 での配信だと 30 分が配信費用の課金対象として計上されてしまいます。利用状況によってはコストがかさむ可能性があるため、注意が必要です。

この配信する画質についての課題は、 Cloudflare Stream で提供されている動画配信時に画質を制御するオプション（clientBandwidthHint）を利用することで解決することが出来ました。このオプションは最終手段であるという旨がドキュメント内に記載されていますが、今回のケースでの利用は妥当だということを Cloudflare Stream の開発者である Zaid Saleem 氏に X 上で確認済みです。

Makes sense. Have you already tried clientBandwidthHint feature of Stream? pic.twitter.com/6KAf94MNuR
— Zaid Saleem (@zaid) May 17, 2024

結果的に画質を選択する機能を提供することが出来ました。が、Cloudflare Stream が提供する配信方法の仕様上仕方ないところではありつつ、他の動画配信プラットフォームで提供している mp4 の特定の解像度を配信する方法と比較すると、直感的ではなく開発工数がかかってしまいました。

clientBandwidthHint と解像度の対応表（ジョブメドレーアカデミーのフルHD動画で検証したデータ）

clientBandwidthHint	画質
0.1	240p
0.2	360p
0.3	480p
0.4	480p
0.5	720p
0.6	720p
0.7	720p
0.8	720p
0.9	720p
1.0	1080p

Cloudflare Stream の採用を検討している方へ

Cloudflare Stream を導入するメリットは大きいですが、サービスの特性上、すべてのケースに適しているわけではありません。以下のポイントを踏まえて検討することをお勧めします。

Cloudflare Stream が向いているケース

シンプルで予測可能な料金体系を希望している
高品質な動画を安定して提供したい
開発リソースや運用リソースが限られている
開発者向けのサポートやドキュメントが充実している環境を求めている

特に、Cloudflare 内の他サービス（Workers や Pages など）を利用している場合、Stream との組み合わせでコスト削減や運用の効率化が期待できます。

Cloudflare Stream が向いていないケース

一方で、以下のようなケースでは他のサービスを検討することも選択肢に入れるべきです。

動画サイズが 30GB を超えるような動画が必要な場合

Cloudflare Stream では、1 動画あたり最大 30GB のアップロード制限があります。長時間の高解像度動画を扱う場合は、この制限に注意が必要です。

By default, a video upload can be at most 30 GB.
Is there a limit to the amount of videos I can upload? | Frequently asked questions about Cloudflare Stream

高度な分析機能が必要な場合

Cloudflare Stream の分析機能はミニマムなものであるため、視聴履歴や詳細な視聴データの分析は外部ツールで行う必要がある場合があります。

実際の分析画面 - 基本的に課金単位の再生時間に注目した、分析機能のみ提供されている

動画管理機能が求められる場合

前述の通り、 Cloudflare Stream は他サービスと比べ、CMS 機能は非常に限られています。動画のディレクトリ管理やタグ付けなど、細かい管理が必要な場合には、自前で管理システムを構築するか、他のサービスを選ぶ方が効率的です。

おわりに

Cloudflare Stream のシンプルな料金体系と高品質な動画提供は大きな魅力です。一方で、CMS 機能や高度な分析機能を求める場合には、他のサービスも視野に入れる必要があります。

動画配信プラットフォームの選定は、プロダクトの特性やチームの状況に応じて異なりますが、この記事がその一助になれば幸いです。今後もユーザー体験の向上とプロダクトの成長に向けて、最適な技術選定を続けていきたいと思います。

2024 年 9 月時点の情報をもとに執筆しました。サービス内容や仕様は変更される可能性がありますので、最新情報は公式の情報をご参照ください。

iOSDC Japan 2024にプラチナスポンサーとして協賛しました！

Tue, 10 Sep 2024 11:55:04 GMT

こんにちは。人材プラットフォーム本部で EngineeringManager をしている倉林です。2024 年 4 月にメドレーにジョインし、少しづつエンジニアの組織作りに携わり始めています。

メドレーは 2024/8/22 〜 8/24 の 3 日間に早稲田大学西早稲田キャンパスにて開催された「iOSDC Japan 2024」にプラチナスポンサーとして協賛させていただきました。 iOSDC は、iOS 関連技術をコアのテーマとしたソフトウェア技術者のためのカンファレンスで、各所からアプリエンジニアが集う大規模なイベントです。毎年、多くのアプリエンジニアが集まり、最新の技術やトレンドを共有する活気あるイベントとして知られています。

2016 年から開催され、今年で 9 回目。メドレーはなんと今年で 8 年連続のスポンサー参加となり、今年も採用担当・広報・ネイティブアプリエンジニアが参加し、多くのエンジニアや関係者の方々との交流を深めることができました。

会場の様子

会場は早稲田大学西早稲田キャンパス。今年はオンライン・オフラインのハイブリッド開催で、オフライン 1100 名、オンライン 400 名の合計約 1500 名以上の参加者で賑わいました。

登壇や LT などもたくさんあり、通常セッションが 50 セッション、LT がルーキーズ LT 含めて 30 本以上で内容も幅広く、様々なインプットを得ることができました。

まさに「アプリエンジニアのお祭り」という雰囲気でした！

会場は各ブースをスタンプラリー方式で巡る形式だったこともあり、どのブース・空間も終始賑やかで、スポンサー・一般参加者・エンジニア・人事関係なく交流が行われていました。大学での開催ということもあるのか学生も多く参加しているのが印象的でした。

スポンサーブーススタンプラリー、フリードリンクや軽食、お昼時にはキッチンカー、朝ドーナツや夕方からはアルコール類の提供、ネイルやボディペイントなどのアートブースなど楽しむための様々な工夫がされていて、まさにコミュニケーションの場となる空間作りがされたカンファレンスだったと感じました。運営の方々の準備と当日のスムーズな対応に感謝です。（スタンプを 1 列揃えて BINGO するとたこ焼き、2 列揃えるとクレープ、全部集めると iOSDC ノベルティと交換）

メドレーブースの様子

メドレーブースでは、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。特に課題として多かったは以下の３つ

待ち時間が長い
1. 圧倒的一位でした、特に子供がいる家庭は子供を連れて薬局へも行かなくてはいけないのが辛いとの回答が多数
キャッシュレス決済がしたい
1. 大分増えてはきたけど。。。との声でした！
オンラインで予約したい
1. 電話で予約するのが面倒という方が圧倒的に多かった
2. 予約とはちょっと違うけど病院の口コミを見たい　という声も多かったです

それぞれの課題についてメドレーのプロダクト・サービスを通じて解決できていること・これから解決していくことなどをご紹介させていただきました。

iOS のイベントということもあり、実施に CLINICS アプリの画面をお見せしながら説明させていただき以下のような感想もいただきました。

オンライン診療が受けれて、薬が Uber Eats で届く。もうそこまで体験が到達しているとな思わなかった
病院検索の UI が体感が早く心地よい・どうやって実装しているのか
オンライン診療で話した内容を電子カルテに書き込んだりできないのか？など新しい機能提案

などなど。

メドレーはアプリを展開している印象があまりなかったので、参考になったなどの声も頂きました。

各アプリの技術スタックは以下の画像の通りで、React Native や Flutter などのクロスプラットフォーム技術で開発しているものもあれば Swift, Kotlin などネイティブ言語で開発しているものもあり提供したい価値やアプリ特性によって様々な技術スタックを選定しています。

CLINICS では全画面の実装が SwiftUI 、SPM を用いたマルチモジュール構成だったりと新しい技術を積極的に導入しています。

セッションやブース

個人的に気になったセッション及び、弊社メドレーの吉田による登壇について少し紹介させていただければと思います。

Ditto SDK 紹介: インターネットなしで快適なデータ同期

アプリ内に SDK の処理を入れておくと、P2P で端末同士がローカルでやり取りしてデータを同期できます、というサービスの紹介。 Flutter や RN にも対応していて「ローカルの端末同士で P2P をいい感じにやる部分」と「ローカルのデータを吸い上げて適宜配信する中央サーバー」といった印象で、需要ありそうだと感じました。

Swift 6 の Typed throws と Swift におけるエラーハンドリングの全体像を学ぶ

Swift 6 の新機能の 1 つである Typed throws についての紹介。安易に使うべきではないとしながら、どういう場面では効果的かなど、実践的な内容も聞くことができました。普段使っている Optional がエラーハンドリングにおいてどの位置づけかを含め、エラーハンドリングの全体像の概観を理解することができました。

座談会「Strict Concurrency と Swift 6 が開く新時代: 私たちはどう生きるか？」

超満員の人気セッションで、Swift 6 対応の盛り上がりを感じました。 CLINICS アプリでも Swift 6 対応を進めているのですが、どこまでを MainActor のスコープとするか、どのレベルでのリファクタリングを同時にやっていくかが議論になっていたので、大変参考になりました。座談会という形式も普段のトークとは異なり新鮮でした。

bitkey さんブース：bitlink をさがして！

個人的に一番面白かったのは Bitkey さんのブースです。iBeacon になる自社製品(bitlink)を携帯して歩いている社員の方がいるので、iOS アプリを自作してその人を見つけられれば、景品を渡す、という企画でした。メドレーメンバーも結構早めにアプリ作って探しましたが、3 番目だったとのこと。残念！

Forkwell さんブース

会場で配布していた資料に、イチ推し求人としてメドレーの求人情報を掲載していただいていました！いつもお世話になっております！

メドレー登壇

医療アプリ開発における安全性と生産性のバランスについて医療プラットフォーム本部患者プロダクト開発グループの吉田 (@shzero5) が登壇させていただきました。

医療アプリの開発においては、患者の安全と利便性の向上が最重要課題となります。一方で、医療制度の変更への迅速な対応や新規機能の実装など、高い生産性も求められます。この 2 つの要件は相反するものですが、その両立は避けられない課題だと感じています。

今回の登壇では、メドレーのオンライン診療サービスを含む総合医療アプリ「CLINICS」の開発を通じて、いかにして安全性と生産性の両立に取り組んでいるかをご紹介しました。

診療報酬改定などの制度変更に柔軟に対応できる体制
SPM マルチモジュール、トランクベース開発など生産性向上の工夫
MagicPod を活用した自動テスト環境での効率的な品質確保
法律・ガイドライン・制度対応や社内他部門との連携を含む総合的なアプローチ

医療アプリの開発は技術的側面のみならず、適切な規制対応や組織間調整など様々な課題に直面します。今回の登壇では、そうした課題への具体的な取り組みをご紹介しつつ、品質と速度の両立に向けた実践的な知見をお話ししました。

質問もいくつかいただきました。

トランクベース開発とのことだが、ブランチ作成からマージまでの間隔は？
- 大きな機能開発でも、ブランチ作成からコードレビューを通してマージまで、1 日かからない程度の粒度に分割しています
MagicPod の導入をチームで進めているが、自動化するテストシナリオの選択基準は？
- MagicPod で自動化できるテストシナリオは全て自動化しているが、ビデオ通話など、どうしても自動テストしづらい部分は課題として残っています
iOS、Android、Web で越境して実装してるとのことだが、コードレビューはどうしているのか
- 個々で強みのプラットフォームがあるので、知見のある人がレビューすることが多いです

発表後にブースに来ていただいて面白かったとコメント頂いたり、改めて医療領域に興味をもっていただけたりしました。医療 × テクノロジーの最前線で得られた学びを、皆様の開発にも活かしていただければ幸いです。

終わりに

メドレーはこれからもアプリを通じて様々な医療体験にインパクト与えるようにプロダクト・サービスを開発していきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！

最後に、改めて iOSDC Japan 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年 10 周年の開催も楽しみにしています！

メドレーでは一緒に働く仲間を募集しています。

ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ https://www.medley.jp/jobs/

また DroidKaigi 2024にもスポンサードしてブースなど予定していますので、興味のある方はぜひ会場にて会話させていただけると嬉しいです。

E2Eテストの信頼性と向き合ってMagicPodのヘルススコアが100に達した話

Fri, 30 Aug 2024 05:47:08 GMT

こんにちは、医療プラットフォーム本部プロダクト開発室 QA グループ所属の小島大周 (@Daishu) です。2022 年 4 月に QA エンジニアとしてメドレーに入社しました。主に “クラウド診療支援システム CLINICS” のプロダクト開発における QA と、E2E テスト自動化を担当しています。

今回は、MagicPod という自動テストツールに半年間向き合い、テスト内容と結果の信頼性を高める改善を行った話をさせていただきます。

※ 自動テストツール全般に共通する話なので、自動テストに携わっている方々にご覧いただけると大変嬉しいです。

MagicPod

弊社は E2E テストの自動化に対して MagicPod というツールを採用しています。MagicPod の詳細は割愛しますが、導入時の話は「UIテストの自動化に MagicPod を導入した話」にありますので、ぜひご覧ください。

活用状況と背景

私が所属する医療プラットフォーム本部では、医療機関に向けて予約や問診、診察 (電子カルテ)、会計等の機能を提供する “クラウド診療支援システム CLINICS” と、患者向けにオンライン診療をはじめ、総合的な医療体験を提供する “オンライン診療・服薬指導アプリ CLINICS” を展開しています。

私は画像左側の医療機関向けのプロダクトにおいて社内で **周辺領域¹ ** と呼ぶ機能群を中心としたQA・テスト自動化を担当しています。MagicPod は導入して4年目になりますが、半年前までこの周辺領域の機能に関しては、MagicPod を十分活用しきれておらず、以下のような状況でした。

MagicPod の自動テスト実行頻度が週 1 回のみ
自動化したリグレッションテストが 3 件しかない (20件が推奨値)
テスト結果が不安定で、自動テストの修正にかかる調査コストが大きい

また、MagicPod には “ヘルススコア機能” がありますが、当時のヘルススコアは 30 点と低い数字でした。これは端的に言うと「自動テストの信頼性が低い」という状態です。一方で、画像右側の CLINICS アプリ (患者向け) は MagicPod を十分活用できており、既にヘルススコアも 100 点に達していました。それゆえに、CLINICS (医療機関向け) の自動テストの改善が望まれていました。

当時の CLINICS (医療機関向け) のヘルススコア

MagicPod ヘルススコア機能

自動テストの改善について話す前に、MagicPod が提供しているヘルススコア機能について説明します。ヘルススコア機能とは、自動テストの活用度合いや成功率などを 100 点満点でスコアリングしたもので、2023 年 12 月にリリースされました。

ざっくりとした採点基準の内訳と配点は下記となっています。

注目すべきは、「テストから信頼性のあるフィードバックを早いサイクルで得られているか」を重視している点です。これは、手動テストの工数削減や、自動テストでの不具合検出数のような費用対効果を意識した指標ではなく、開発生産性への貢献を意識した指標となっています。スコアが低いということは「テストに信頼性がなく必要なフィードバックが得られていない」ことを意味しており、自動テストが開発生産性に貢献できていない状態となります。

私個人も、テストカバレッジが十分ある自動テストが統合ブランチでパスしているなら「開発ブランチで不具合を潰してマージされている」と考えますし、自動テストでは「統合ブランチが stable であることを保証する」ことが、「不具合を見つけた件数」と並んで重要と捉えています。ヘルススコア機能がリリースされたことで、こういった活動も定量的に測定できるので重宝しています。

主に3つの改善を実施しました

本題である E2E 自動テストの改善について話していきます。約半年前から本腰をいれて自動テストの信頼性向上に取り組みました。

① デイリー実行で不安定なテストを解消した

早いサイクルでフィードバックを得るには、自動テストのデイリー実行は必須です。そもそも、ウィークリー実行にしていた理由は、テスト結果が不安定なケース (以下、Flaky test) が多数あり、不具合かどうか調査するコストが大きかったからです。実際、調査してもほとんどが Flaky test で自動テスト側の不備で終わることが多く、ここに時間を割くなら開発機能の QA に使いたいという考えが当時ありました。とはいえ、Flaky test と一口に言っても突き詰めると何かしらの原因があり、発生パターンは限定的です。テスト結果を信頼できるものにするためにも、デイリー実行で Flaky test と向き合いました。

まず、デイリー実行すれば Flaky test となるパターンに遭遇できます。次に「なぜ Flaky test として失敗するのか？」を 1 件ずつ追求していくことで、見つけた “穴” を確実に塞いでいきます。そして、この活動を毎日繰り返すことで、堅牢で精度の高い自動テストを構築できました。これは信頼性のあるフィードバックを得る上でも重要な要素でした。今は「自動テストはデイリー実行で育てるもの」という考えで、日々の自動テストの結果と向き合うことができています。

② テストケースの二重メンテナンスを止めた

テストカバレッジが十分でないと、毎日自動テストを動かしても「統合ブランチが stable である」と言い切ることはできません。信頼性を高める上で、テスト対象とする機能の充実化は必須要件でした。しかし、当時のリグレッションテストの自動化フローは、手動テスト用のケースをスプレッドシートで作成した上で自動化する流れとなっており、テストケースを二重メンテナンスする形となっていました。このように本来の必要以上の工数がかかってしまうことからテストカバレッジを素早く上げづらい状況がありました。

手動テスト用のケースは、自動化後に触る機会がほとんどないにも関わらず、仕様変更などで自動テストに手を加えるたびにメンテナンスコストが発生します。もちろん、仕様キャッチアップ等の特定シーンで役立つ事はありますが、常にではありません。こういった運用コストの課題もあり、テストケースの二重メンテナンスはしない方針 に切り替えました。

現在は下記フローで MagicPod のテスト実装のみ行なっています。

リグレッションテストの自動化手順

この方針により、約半年で CLINICS の周辺領域に含まれる機能のテストカバレッジを 100% まで拡充できました。一方で、手動テスト用のケースがないことで「テストケースを使った仕様キャッチアップができない、そもそもどんな自動テストがあるのか外から見えづらい」とった課題が生まれましたが、MagicPod がテスト実行時に取得するキャプチャを用いた仕様書や、機能一覧と自動化したテストケースをマッピングした資料を用意することで対応しています。この取り組みについては、別途またご紹介できればと思います。

MagicPod のテスト概要欄の記載例

③ 先行して共有ステップを作成した

この改善が最も成果に結びつきました。共有ステップとは MagicPod の標準機能で、テストステップを汎用的なステップ (関数化) として流用できるものです。一般的に、複数のテストで同一のステップがある場合、共有ステップを作成されると思いますが、私は現時点で同一ステップがなくても、先行投資的に共有ステップを作成する方針で実装を進めました。これにより、早い段階で共有ステップを拡充できました。

現在は、共有ステップをパズルのように組み上げる、実際のコーディングに近い実装スタイルを確立できました。実装スピードは格段に上がり、再発防止等で確認項目を追加する場合は 10 分ほど、ゼロから大きめの E2E テストを実装する場合でも 1-2 時間ほどで作成できます。

実装スピードの向上はテストカバレッジを上げる上でも役立ちましたが、他のテストで動作保証できた共有ステップを使い回すことで「デイリー実行で自動テストを育てる前から安定したテストを作りやすい」という点も大きかったです。

共有ステップ例：Mailtrapに届いたメールの本文から正規表現に一致するテキストを取得

改善した結果どうなったか

一番の成果は、前日にマージされた Pull Request の不具合検出が毎朝行えるようになり、冒頭紹介した「テストから信頼性のあるフィードバックを早いサイクルで得られる」点が達成できたことです。また、テストカバレッジも十分あるので「統合ブランチが stable である」ことが保証でき、機能開発や QA しやすい状況づくり (=開発生産性) にもコミットできていると思います。

障害発生時には、MagicPod で再発防止策の自動テストを作るという手段を QA エンジニアだけで完結できるようになりました。これまで QA 側で対応できることは手動のリグレッションテストを追加する方法が多かったですが、自動テストで再発を抑止するという解決手段を QA エンジニアが持てることは運用コスト的にも大きいです。

これらの改善を通して、開発エンジニアの方々からの自動テストに対する信頼感が高まってきた、と感じることも増えてきました。

障害の再発防止として自動テストを作成した際

また先日にはMagicPod 社のミートアップイベントに登壇する機会もいただきました。登壇時に利用したスライドは下記です。共有ステップの Tips や安定した Xpath ロケータを取得する方法などを紹介しているので、既に MagicPod を利用されている方はぜひご覧ください。

今後やりたいこと

上述した改善により、CLINICS (医療機関向け) の周辺領域における MagicPod のヘルススコアは 30 点から 100 点まで上げることができました。現在は、自動テストの新規追加や変更を加えた際にスコアが変動しないか注視しながら改善を継続しており、デイリー実行する自動テストの安定稼働と拡張の両立ができています。

今後もこのプロセスを崩さず、CLINICS の基幹領域² に対してもテストカバレッジを広げていきたいと考えています。まずは、基幹領域の中でE2Eで確認すべき機能の洗い出し、次に洗い出した機能の自動化タスクを個人にアサインできる体制づくりを検討しています。そのためにも、オンボーディングやレビュー体制、コーディングルール等の仕組みづくりもセットで考えていきます。

また、CLINICS に携わる開発の方々は実装しながらテストコードを書く素晴らしい文化がありますが、MagicPod の自動テストと一部重複して確認している箇所があります。テスト対象は重複しつつも、テスト粒度の方針を定めて自動テスト全体の最適化にも取り組んでいく予定です。

おわりに

私が所属する医療プラットフォームの QA チームはいわゆる完全内製型で少数体制です。しかし、MagicPod の実装の容易さ、メンテナンスコストの低さにより少数でも複数のプロダクトを広範囲でカバーできています。組織体制にも大きく貢献できる MagicPod は素晴らしいツールです。この場をお借りして改めて感謝申し上げたいと思います。いつもありがとうございます。

メドレーは、現在 QA エンジニアを募集しています。医療分野における高い品質目標と、いち早くお客様に価値提供するという課題の両立に対して、QA エンジニアだからできる解決策の打ち手を一緒に考えてコミットしていける方と是非お会いしたいです。

周辺領域とは、主に CLINICS の予約や問診、資格確認といった医療機関と患者との接点となるシステムを指す。社内での呼称。 ↩
基幹領域とは、主に CLINICS の受付・診察・会計といった業務において、電子カルテとレセコン(レセプトコンピュータの略。医療機関から健康保険組合などの支払い機関に対し、診療報酬を請求するために、レセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを行うシステムを指す。社内での呼称。 ↩

Next.js と Server-side Rendering をプロダクト環境で3年運用してきた知見と率直な所感

Tue, 23 Jul 2024 08:00:00 GMT

こんにちは、医療プラットフォーム本部・プロダクト開発室・第1開発グループ所属の加藤です。オンライン診療・オンライン服薬指導アプリ「CLINICS」の開発を担当しています。

今回は CLINICS で採用している Next.js と Server-side Rendering (SSR) についてお話ししたいと思います。

Next.js は昨今注目を集めている React ベースの Web フレームワークです。これから Web フロントエンドの開発を始めるにあたって採用を検討している方も多いのではないでしょうか。

Next.js といえば React コンポーネントをサーバー上で実行して HTML を返す SSR に対応しているのが大きな特徴です。 SSR には様々なメリットがある一方で、採用にあたって自分たちのプロダクトに SSR は不要なのではないかといった懸念や Node.js の実行環境の運用コストを気にする声もよく耳にします。

この記事ではメドレーでの Next.js, SSR の採用事例を紹介しつつ、採用にあたって一般に懸念される点を実際に採用してみた上での所感も交えてお話しできればと思っています。

メドレーの医療プラットフォーム事業と CLINICS アプリについて

まずはメドレーの医療プラットフォーム事業と CLINICS アプリについて簡単に紹介させてください。

メドレーの医療プラットフォーム事業は、2016年にオンライン診療システムとしてリリースされた「CLINICS」を原点としています。当時は医療機関の方が操作する業務システム部分と患者さん向けの iOS/Android アプリとその Web 版が存在するという構成でした。

その後 CLINICS には電子カルテなどの様々な機能が追加され、現在ではオンライン診療に留まらず医療機関の様々な業務を支援するクラウド診療支援システムへと発展しています。また、2020年にリリースされたかかりつけ薬局支援システム「Pharms」や2022年にリリースされたクラウド歯科支援システム「Dentis」もプロダクトのラインナップに加わり、より多くの医療機関の業務を支援するプラットフォームとしてサービスの規模を拡大しています。

医療機関向けの業務システムは医科・歯科・調剤薬局とそれぞれの業務特性に合わせてプロダクトが分かれている一方で、患者さん向けの機能はすべて CLINICS アプリに集約されています。業務システムの機能拡充に伴って CLINICS アプリの機能も拡充されており、現在ではオンライン服薬指導機能や処方箋の事前送信機能など様々な機能が追加されています。

今回お話しするのはこの CLINICS アプリの Web 版 (以下、CLINICS) のフロントエンド開発についてです。

Next.js 採用のモチベーション

CLINICS アプリはリリース以後続々と機能が拡張されてきたのですが、こうした開発を支えるため 2021年に大規模なリニューアルを実施しました。特に Web 版はリニューアルのタイミングでフルスクラッチで実装し直す選択をしています。

リニューアル以前のトップページ

現在のトップページ

リニューアル以前の CLINICS はログインの前後で実装が分かれており、この点がフルスクラッチでの実装を選択する大きなモチベーションとなりました。 CLINICS は開発当初から Ruby on Rails で開発されているのですが、患者さん向けのページは Rails のテンプレートエンジンを用いて実装されている部分と SPA として実装されている部分が混在していました。医療機関の検索や詳細などの検索エンジンからの流入を確保したいページではテンプレートエンジンを用いて HTML を直接レスポンスする、ログインページや予約ページなどの操作性を重視したページでは SPA として実装されている、といった具合です。

こうしたテンプレートエンジンと SPA の併用構成では、ログインの前後で一貫したユーザー体験を提供するのは困難だと感じていました。例えば、同じ機能がログイン前と後とで2つ存在する箇所もあり、ユーザーから見るとログインを挟んで UI が変わってしまい、あまり良いユーザー体験とは言えない状態でした。もちろんこういった課題はログイン前後の両方のページの UI を丁寧に設計することで解決が可能ではありますが、異なる技術スタックで同じような機能を実装しつつ UI の一貫性を保つのは容易ではありません。そういった背景からリニューアルではログイン前後での実装を一本化する方針を立てていました。

実装を一本化する上で SSR に対応している Next.js は非常に魅力的な選択肢でした。 SSR には初期表示のパフォーマンス向上などのメリットもあるのですが、採用にあたっては SEO 面でのメリットを重視していました。近年では Google のクローラーが JavaScript を実行してくれるのですが、直接 HTML をレスポンスできるのであればその方がより確実だと判断しました。これが Next.js を採用するに至った最大の理由です。

ちなみに、この当時は App Router がリリースされる前だったため、Pages Router で開発を開始しました。以降の内容も基本的に Pages Router を前提としてお話ししていきますが、App Router や他のフレームワークを使用している場合でも SSR についての考え方は共通している部分が多いので少しでも参考にしていただけたら幸いです。

Server-side Rendering の仕組み

Server-side Rendering (SSR) とは、Next.js や Remix などの React ベースのフレームワークが持つ機能のひとつです。 SSR という用語は昨今の React に関する話題の中ではよく耳にする言葉ですが、実は React の公式ドキュメントに SSR とは何かという記述は存在していません。それでは React 本体にはサーバー環境向けの機能が存在しないのかというとそうではなく、React はコンポーネントから HTML を生成するための API を提供しています。 Next.js や Remix はこうした API を利用してサーバー環境で HTML を生成しつつブラウザ環境では従来の SPA のような振る舞いを実現する機能を提供しており、こうした機能には SSR という名前が付けられています。例えば、Next.js の Pages Router では getServerSideProps を使用してリクエスト毎に HTML を生成する機能を SSR と呼んでいます。各フレームワークによってサーバー側でのデータ取得の方法は異なりますが、React コンポーネントから HTML を生成する仕組みは共通しています。

サーバー上で HTML を生成すると言うとテンプレートエンジンなどを用いる場合と変わらないように感じられるかもしれませんが、SSR にはハイドレーションという仕組みが存在するのが大きな特徴です。生成された HTML はクライアントにレスポンスされてブラウザ上で表示されるのですが、この時点ではイベントハンドラーが DOM にアタッチされておらず、ユーザーの操作に対して反応することができない状態です。そこで React はブラウザ上で再度コンポーネントをレンダリングしてイベントハンドラーを DOM にアタッチします。この処理はハイドレーションと呼ばれています。

ハイドレーションが行われるとアプリケーションはユーザー操作に反応することができるようになります。アプリケーションによってはいわゆる Client-side Rendering (CSR) と呼ばれる useEffect によるデータの取得と追加の描画が行われる場合もあります。さらに、ハイドレーションが行われた状態からページ遷移が行われる場合には history API が使用されます。

一連の流れをシーケンス図にすると以下のようになります。

このように SSR を使用しているアプリケーションでもハイドレーションが行われた後は従来の SPA と同様に振る舞います。そのため、Context API や Redux などの状態管理ライブラリを使用してページを跨いで状態を共有することも可能です。こういった特徴から考えると、SSR はこれまでの React と対立するものではなく、むしろその機能を一層強化するものと言えるでしょう。

CLINICS での活用事例の紹介

ここからは実際にどういった形で Next.js と SSR を利用しているのか、CLINICS の活用事例を紹介していきます。

CLINICS のシステム構成は以下のようになっています。 (実際にはもう少し複雑な構成を取っているのですが、今回の説明では簡略化しています)

CLINICS の Next.js サーバーは固有のデータベースを持っておらず、必要なデータはすべてバックエンドの API から取得しています。 SSR の際には Next.js サーバーから、CSR の際にはブラウザから API にリクエストが送信されます。

セッション情報については API サーバー側で管理しており、Next.js サーバー側にはセッション情報を共有しない方針を取っています。 SEO 面でのメリットを重視していたため、SSR するのはログイン不要で閲覧可能なページのみで十分だろうと判断しました。そのため、SSR をする際にはログイン不要で取得できる情報のみを表示し、ログインが必要な情報を表示する際には CSR を使用しています。 SSR を使用しているページでも部分的に CSR を組み合わせて使用しており、ページによっては SSR を用いずに全体が CSR で実装されているケースもあります。感覚的には従来の SPA をベースとして部分的に SSR を組み合わせていると言っても良いかもしれません。

採用して良かったと感じている点

ここからは実際に Next.js を使ってみた所感を交えてお話ししていこうと思います。

まずは、Next.js を採用して良かったと感じている点についてです。

全体的な開発体験

フルスクラッチで実装し直す上で Next.js は良い選択だったと感じています。 Next.js というと SSR のイメージが強いかもしれませんが、SSR を抜きにしても SPA の開発に必要な要素は一通り備わっています。 Webpack やトランスパイラなどのビルドツールの設定がデフォルトで含まれており、React のプロジェクトを新規に立ち上げる際には非常に便利なフレームワークだと感じています。 CLINICS では CSS 関連で追加のライブラリを使用しているのを除けば、ほとんどの実装を Next.js と React の標準機能だけで開発しています。

SEO 面での扱いやすさ

こちらは Next.js を採用するにあたって重視していた点なのですが、やはり SSR でサーバーから直接レスポンスを返せるという点で SEO 面では扱いやすいと感じています。 title タグや meta タグなどももちろんですが、HTTP ステータスコードも制御できるため、クローラーに意図を伝える伝統的な方法がそのまま使える点は非常に便利です。 SEO とは直接関係ありませんが、SNS でリンクがシェアされる際の OGP 用の meta タグを動的に生成したいといったケースへの対応も容易です。

とはいえ、近年は Google のクローラーも JavaScript を実行してくれるので SPA が必ずしも SEO 的に不利というわけではありません。クローラーが JavaScript を理解する能力は年々向上しているので、適切に設計された SPA であれば SEO 的に問題ないというケースも多いようです。こうしたクローラーの進歩や実装上のテクニックも踏まえると SSR の SEO 面でのメリットはあくまでその扱いやすさという観点で考えると良いかもしれません。

パフォーマンスの向上

SSR を取り入れるにあたってパフォーマンス面について特に意識していたわけではないのですが、実際に SSR を使ってみて FCP (First Contentful Paint) や LCP (Largest Contentful Paint) といった初期表示の速度を表す指標の改善に効果があるなと感じています。 CSR では JS でのデータ取得が完了して始めて LCP 要素が表示されるケースが多いため、JS ファイルのダウンロードや実行の分だけ FCP や LCP が遅延しやすい傾向にあります。 SSR ではこうした JS のダウンロードや実行の時間が減る分、初期表示のパフォーマンス改善が期待できます。体感的にもローディングインジケーターの表示を挟まずにコンテンツが表示されるため、ユーザーにとってはより快適な体験となるのではないかと感じています。

また、SSR 以外にも Next.js は画像の最適化やコードスプリッティングなどのパフォーマンス向上に役立つ機能を多く提供しているため、安定したパフォーマンスの Web アプリケーションを開発する上では非常に心強い存在です。

セッション管理についての反省点

Next.js そのものについて不便に感じている点はあまりないのですが、SSR を取り入れるにあたってセッション管理についてはよく考えておくべきだったと反省している部分もあります。

従来の SPA であればセッション管理は API サーバーが管理するというのが一般的ですが、SSR を採用する場合では Next.js サーバーと API サーバーが存在するという構成になるケースが多いかと思います。この場合、Next.js サーバーと API サーバーのどちらでセッションを管理するのか、セッション情報を共有するのか、共有するのであればどのような方法で共有するのかといった点で複数の選択肢が考えられます。 CLINICS では前述の通り API サーバーでセッションを管理して Next.js サーバーとの間でセッション情報を共有しない構成を採用しています。

こうした構成の都合で Next.js サーバーでセッション情報を扱うことができないため、ログイン済みのユーザー固有の情報は SSR することができず、CSR で取得して描画する必要があります。このようにして SSR と CSR を組み合わせた場合、CSR で取得したデータを描画する際にレイアウトシフトが発生しやすくなります。また、ログイン済みのユーザーに対しては検索結果をカスタマイズしたり並び替えたりといった要件への対応も難しくなってしまいます。こういった面で SSR と CSR を組み合わせざるを得ない現状の認証構成には課題があると感じています。

こうした課題を解消するためにも、今後はセッション情報を Next.js サーバーと共有する構成へと変更し、CSR している部分を SSR する形に変更していきたいと考えています。

このように SSR を活用する場合には従来の SPA よりもセッション管理の選択肢が増えるため、セッション管理については特に慎重に考える必要があると感じています。 SSR を今は必要としていないというケースでも、将来的な導入に備えてセッション管理について少し考えを巡らせておくと良いかもしれません。

Next.js の採用を検討している方へ

最後に、これから Next.js を採用しようとしている方が気になっているのではないかと思われるポイントについてお話ししていこうと思います。

Next.js を採用するにあたって最も気になるポイントはやはり Node.js の実行環境の運用コストではないでしょうか。 Next.js では一部の例外を除けば SSR を使用するか否かに関わらず実行には Node.js サーバーが必要となります。 SSR は必要としていないが Next.js の様々な恩恵を受けたいという開発者にとっては Node.js サーバーの運用コストが気になるところかと思います。

CLINICS では AWS ECS/Fargate で Next.js サーバーを運用しているのですが、Node.js の実行環境を運用するコストは確かに発生しているものの、現状ではそれほど大きな負担には感じていません。 API サーバーが別で存在する構成では Next.js サーバーが担うのはルーティングに従って API サーバーからデータを取得して SSR するといった比較的シンプルな役割になります。そのため、データベースを扱うような本格的なバックエンドに比べると運用の手間は低く抑えられている印象です。

どうしても Node.js の実行環境を持たずに運用したいという場合には Static Exports というビルド時に HTML を含む静的アセットを出力する機能の利用も検討してみると良いかもしれません。ただし、機能面でいくつかの制約があるので、採用を検討する際にはよく確認しておくことをお勧めします。どちらかと言えば Static Exports は静的なサイトを構築するのに向いている機能であり、動的なコンテンツを扱うようなアプリケーションにはあまり向いていないというのが正直な感想です。従来の SPA に多く見られるようなビルド済みの JavaScript, CSS などの静的アセットを S3 などのストレージに配置して HTML はバックエンドのサーバーから配信するといった構成が想定されていない点も注意が必要かと思います。

また、Next.js の採用にあたって App Router に追従すべきかというのも悩ましいポイントです。 App Router は Next.js 13 で導入された新しいルーティングシステムで、Server Components/Actions などの React の新機能もサポートしている点が魅力ですが、リリースから日が浅くまだしばらくは様子を見たいと考えている方も多いのではないでしょうか。

現状 CLINICS ではまだ App Router への移行は考えておらず実際の使用感などをお話しすることはできないのですが、ドキュメントを読む限りでは Pages Router の扱いにくい部分がうまく改善されている印象はあります。ただ、Pages Router のルーティング機能と完全な互換性がない点が移行を考える上で最大のネックだと感じています。こういった移行のコストや Next.js 自体が App Router への移行を推奨していることを踏まえると、今から新規に開発を始めるのであれば App Router で開発を始めてしまった方が無難な選択かもしれません。

総じて、Node.js サーバーの運用コストが許容できるか、App Router や Server Components/Actions に魅力を感じるかといった点が Next.js の採用を検討する上でのポイントになるのではないでしょうか。

まとめ

CLINICS では Next.js を採用しており、SSR と CSR を併用する形で比較的ライトに SSR を取り入れてフロントエンドの開発を進めています。当初は SEO 面でのメリットを重視していましたが、実際に使ってみるとパフォーマンスの向上や開発体験の向上など様々なメリットを感じています。セッション管理については課題を抱えている部分もありますが、今後はそういった部分を改善しより一層 SSR の恩恵を受けられるようにしていきたいと考えています。

Next.js の他にも Remix と React Router の統合が発表されるなど、さらに SSR を活用しやすい環境が整いつつあるという点でも、SSR の今後は非常に楽しみな部分が多いと感じています。

大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫

Tue, 02 Jul 2024 09:56:22 GMT

はじめに

こんにちは。CLINICS カルテの QA 担当をしております QA エンジニアのかみむらです。
医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン¹の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。

QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。
この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。

プロジェクトの状況とふりかえりの進め方

まずレセコン開発プロジェクトのチーム体制についてご説明します。メンバーは、初期から現在まで総勢20〜25名前後（内訳：ディレクター3〜5名、カスタマーサクセス2〜4名、エンジニア10数名、QA エンジニア1〜2名）で取り組んでいます。
※開発詳細については、Tech Studio MATSUE オフィスのご紹介からご覧いただけます！

元々医療プラットフォーム本部では四半期に一度、個々のプロジェクトの垣根なくプロダクトチーム全体でのふりかえりを KPT（ Keep / Problem / Try ）で行うという習慣があります。そこで、レセコン開発のプロジェクトも時期を合わせてふりかえりを行うようにすればメンバーの気持ちと時間の調整がしやすいのではないか？と考え、プロジェクトマネージャーに相談しながら各四半期の終わり頃に開催することとしました。

当プロジェクトには専任メンバーもいますが、多くのメンバーは他のプロジェクトとの兼務のためふりかえりへの時間の使い方と開催形式には気をつかいました。
特に開発メンバーの半数近くが別拠点（松江オフィス）に勤務していることもあり、東京オフィスメンバーとのコミュニケーションのため完全オンライン形式にする必要がありました（同じ拠点同士は対面で集まり、拠点間のみオンライン接続するというやり方もありますが、経験上個々の発言が拾いにくい等負の側面があることをわかっていたため、全員オンラインでの参加としました）。

具体的には次のように進めています。

”今期の課題感” についてプロジェクトマネージャーとすり合わせ、その課題に合いそうなふりかえり手法を選定する（参加者の対象をどこまで広げるか、数名ずつのグループに分ける場合はどういう基準で分けるか等も相談）
候補に挙げた手法とタイムテーブルを Confluence に書き起こし、前日までに Slack で事前周知
Google Meet でオンライン開催する
ふりかえり結果の要約 / 抜粋 / アクションプランを Confluence に追記し、参加者に Slack で報告

毎回以下の形式を守って執り行いました。

完全オンライン形式で開催
参加者の事前準備はほぼ無し
ふりかえりイベント当日にかける時間は1時間だけ

一般的には四半期という長期間を対象とするふりかえりの場合、半日くらいかけて開催してもおかしくないと思うのですが、対象者全員が空いている時間帯を確保するのもなかなか難しく「1時間以内でやり切り最大の効果をあげること」を自分に課していました。

具体例① 「象、死んだ魚、嘔吐」

開催時期：初期（2022年6月）
参加メンバー：12名

まだ「ふりかえりをこうしていこう！」とも決めていなかった頃の、最初に行ったふりかえりは「象、死んだ魚、嘔吐」という手法を採用しました。
Airbnb 創業者が考案したコミュニケーション改善の手法で、以下の3要素から構成されています。

「象」…存在しないかのように扱われるが、誰もが知っている事実。
「死んだ魚」…過去に起こったこと（悪臭と腐敗）を乗り越えて、将来への期待を設定する。
「嘔吐」…普段は言わないこと、言うのを控えていることなどをぶっちゃけて話す。

最初期のためチーム全体としても遠慮し合うような雰囲気がまだうっすらとあり、松江と東京の物理的な距離感も相まって「もう全員でぶっちゃけて話そうよ！」という思いでこの手法を選びました（個人的にも気になっていた手法でした）。少し前に行ったプロダクトチーム全体のふりかえりから、現在のチームは「良い面も悪い面もコミュニケーションのあり方がキーポイントになっていそう」という推測が出ていたことも背景にありました。

「象」「死んだ魚」「嘔吐」それぞれでボードを使用

「四半期毎の開催」と述べましたが、実はこの最初のチーム全員のふりかえりまではプロジェクト開始から半年経過しています。そのためレセコン開発プロジェクト全体としては初回のふりかえりということもあり、「そもそも何のためにふりかえりを行うのか」「このプロジェクトの目的（共通目標）は何か」という部分は特に丁寧に対話する時間をとりました。
ツールは Jamboard を使用し、心理的安全性を高めるためクローズドな状態にして「本当に何でも言える」環境をつくることに腐心しました。
結果、1時間のうち集中して話ができたのは30分程度ですが、かなりいろんなぶっちゃけ話ができたと思います。もちろんこのふりかえりだけが要因ではないですが、その後のプロジェクトメンバー内のコミュニケーションは徐々に滑らかになっていってるな、チームビルディングという意味でも効果があったかなと感じました。

具体例② 「ポジティブふりかえりマッピング」

開催時期：初回リリース後（2023年3月）
参加メンバー：25名

初回リリース後の運用期間を経て次の大型リリースの準備を進めていく中で、関わる人数やロールも一段と増えた時期でした。これまではふりかえりに参加していなかったカスタマーサクセス等のメンバーも招待し、次の期へのキックオフを兼ねて明るい雰囲気で未来へつながっていくお話をしたく、ポジティブふりかえりマッピングを使うことにしました。
この手法は、はじめに「どんな道をたどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」という声明を発表し、「あなたは⚪︎⚪︎プロジェクトにいましたね。どういう点が素晴らしかったですか？」と質問を続けるという作法で進みます。メンバーが次々と素晴らしい点を挙げていくので、みんなが嬉しく和やかな雰囲気になります。

当時のConfluence

参加メンバーも大人数になってきたので、5名ずつのグループをあらかじめつくっておき、グループ毎の Jamboard へ意見を記載してもらいました。持ち時間は10分です。時間短縮のためブレイクアウトルームはつくらず、25名全員がメインルームに参加したままの状態で各自ふせんをつくっていきます。
キックオフとして有用な場になるよう、この回のグループ編成は以下の点に配慮しました。

同じグループ内でなるべく職種が偏らないように
年齢（経験年数）も偏らないように
とはいえまったく業務上の接点もないということがないように

次に各グループ毎に挙がった内容が近いふせんを寄せたり、ペンで囲んだりといったグルーピングを5分で行います。
最後に各グループの結果を全員で見ていき要約する時間を15分とります。
メンバーからは「プロジェクトの推進における各自の機動力、組織力が素晴らしい」「効率化のための仕組みが効いて次期稼働可能な状態までもっていけた」等の意見が挙がりました。
素晴らしい点をお互いに見つけて言語化することによって労いや協力の気持ちが思い出され、ふりかえりとしてもキックオフとしても良いイベントになったかなと思います。

とあるグループの最終形態

具体例③ 「温度計」

開催時期：成長期（2023年12月）
参加メンバー：19名

自社レセコンが稼働する医療機関数の更なる増加と診療報酬改定²に向けて、持続的なプロダクト開発とオペレーション改善のための話し合いを行いたい時期でした。
このふりかえりでは、以下の3点を重要課題と位置づけました。

良いところを伸ばす
問題を解消する
関係の質を高める

この3点の目的にマッチする「温度計」という手法は、チームメンバーが「チームに起きていること」「チームに望むこと」を報告し合います。現在位置から今後に視点を向けることを意識するため、以下の3ステップで進めました。

感謝・興奮
気づき・興味
提案・希望・願望

「温度計」という名の通り、中央に温度計のイラストを配置します。本来は縦長の用紙下部に低温（よくないこと）、上部にいくほど高温（興奮や願望）のふせんを貼る、というルールになっていますが、オンライン画面上ではスクロールが必要な状況を避けたかったため、各ステップのふせんの色を変えることにより（青→黄色→ピンク）温度感を表現することにしました。

「感謝・興奮」は全員で1つのボードを使用し、ありがとうの気持ちが溢れました

「大変だけど楽しい期だった」「チーム感があった」「インフラチームのおかげで開発・不具合対応に集中できた」等の意見があがり、初期から比べると本当に良いチームになっているなと感じました。
またこの頃から「⚪︎⚪︎に関する勉強会 / 品評会をしてみたい」という意見も徐々に増えてきており、一部実現したものもありますが未だにやれていないジャンルもあり、熱が冷めないうちに何らかの形で達成することが今後の課題です。

まとめ

ここまで、実際に行ったふりかえり事例を3つご紹介しました。
最後に、どのふりかえりでも共通して行っていたことを踏まえてまとめます。

ふりかえりをする意義を再認識し、場をつくる
前回のふりかえりをふりかえる
他のメンバーが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う

以下に詳しくご説明します。

ふりかえりをする意義を再認識し、場をつくる

メンバー全員が「ふりかえり」に慣れているわけではなく、経験が少ないメンバーもいることから、「なぜふりかえりをするのか？」という意義については毎回冒頭で触れて、気持ちをつくっていくということをしていました。毎回別の言葉で、「たいへんな時ほど立ち止まって周りをみることが、これからも一緒に走っていく仲間として大切」のようなお話をしました。
会の前半は説明のため私が1人で話している時間も長めで、オンラインでは参加者の反応がわかりづらくちょっとした無音の時間が続いてしまいがちです。特別にアイスブレイクの時間をとっていないこともあり自然に場を盛り上げていくために、参加メンバーには「環境的にミュート解除しても問題ない人はなるべく声出してください〜」「スタンプくださーい」等と促してわいわいしてもらいました。

前回のふりかえりをふりかえる

四半期毎にふりかえりをする、というリズムもできたので、毎回冒頭で「前回はこういうふりかえりをしましたね」という「ふりかえりのふりかえり」をするようにしています。
あまり時間もとれないのでさらっと触れる程度ですが、今から行うふりかえりの気持ちをつくる上でも重要なパートかなと思っています。

誰かが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う

「ドット投票」もふりかえりの手法の1つですが、あらかじめマークとなるアイコンを準備しておき、それを各自コピーして共感した他の人のふせんの近くに貼ってもらいました。
これによりみんなの関心がある課題が明確になって時間も短縮でき、取り上げる議題に集中できます。

ドット投票の例

ふりかえり手法の選定について

さて、私がなぜ毎回課題感に合わせて最適な（と思われる）ふりかえり手法を使うことができたのか、それはふりかえり＆ Miro エバンジェリストであるびばさんの『ふりかえりチートシート』にかなりお世話になっているためです。
このシートには各ふりかえり手法がどの目的（解消したい課題）に適しているか詳細にマッピングされているので、「今回のふりかえりで解決 / 達成したいこと」を2〜3つ選定し、その中から合いそうな手法をピックアップして詳しく調べてから1時間でやり切れる形式に落とし込んでいきました。
また、課題によっては1つの手法に収めず、複数の手法を組み合わせて使うことも多いです。前述の「ドット投票」もそうですが、軽量な手法である「感謝」（自分が感謝すべき人たちのことを考え、精一杯の誠意を込めて「ありがとう」と言う）は他の手法と組み合わせてアイスブレイク的に使ったりもしました。

このように、毎回異なるふりかえり手法を取り入れることのできる柔軟な組織で一緒に働いてみたい！と思った方はお気軽にカジュアル面談をお申し込みください。
良いふりかえり事例を持っている、あるいはふりかえりの仕方に悩んでいる等とにかく語りたい方も一度お話ししてみましょう！
最後までお読みいただき、ありがとうございました。

Reference&Thanks（ふりかえりの参考図書）

レセプトコンピュータ。レセプト（診療報酬明細書）を作成するためのコンピュータ。
https://clinics-cloud.com/column/64 ↩
通常2年毎に行われる、医療行為に対する点数の見直し。
https://clinics-cloud.com/column/406 ↩

RubyKaigi 2024 に Ruby Sponsor として協賛しました！

Fri, 24 May 2024 09:29:14 GMT

こんにちは。人材プラットフォーム本部プロダクト開発室第五開発グループ所属の寺内です。新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである介護のほんねの開発を担当しています。

メドレーは 5 月 15 日から 17 日に沖縄県那覇市の那覇文化芸術劇場なはーとにて開催された RubyKaigi 2024に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。

エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。

会場の様子

会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン

建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。なんと今年の来場者数は約 1400 人だったそうです！

RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。

2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！

弊社ブースの様子

メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました

アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。

特に回答が多かったのが 「待ち時間が」長い という課題でした。メドレーの提供するオンライン診療・服薬指導アプリ「CLINICS」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました

また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（CLINICS、MALL、Pharms、Dentis）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています

メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で

発表の様子

3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。

Keynote
DAY1 rubykaigiB 「Long journey of Ruby standard library」
DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」
Matz Keynote

Keynote

今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！紹介されていたものは GitHub にてソースコードが公開されています。

引用元:drive.google.com

DAY1 rubykaigiB 「Long journey of Ruby standard library」

Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。

引用元:speakerdeck.com

組み込みクラスと標準ライブラリの違い

組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。

歴史と傾向

Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。

default gems と bundled gems という概念の導入

default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。

影響

default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。これを解決するために、Ruby3.3 では警告機能が実装されました。require "csv"などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。

感想

引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。

DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」

Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。

引用元:slides.com

RBS とは？ & 既存の RBS 作成手法

RBSとは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。既存の RBS 作成手法としては以下の 3 つが紹介されていました。

静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。
動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。
型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。

RBS Goose の仕組み

RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。

hoge.rb に対して静的構文解析などで hoge.rbs を作成
LLM の入力に使う prompt を組み立て
1. この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる
2. お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティングという手法を採用している
LLM に prompt を渡す
RBS を出力

実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。

LLM を使った開発の Tips

開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、VCRのような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。

感想

性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。去年の Keynoteで ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！

Matz Keynote

今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要があるというメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずであるというメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と

スポンサー LT の様子

メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます

あそこまで大きな会場だと思ってなかった…！by 山﨑

LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/

私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！

さいごに

RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。

メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。ご興味を持っていただいた方からのご連絡をお待ちしております。

TSKaigi 2024のスポンサーLTでTypeScriptコード改善の取り組みについて紹介しました

Mon, 13 May 2024 14:41:06 GMT

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。

メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。

エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。今回はスポンサー LT とブースの様子をご紹介します。

スポンサー LT

スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。

発表では、クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。

詳細は次の発表資料にまとめていますので、是非ご覧ください。

ブースの様子

ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。

また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。

メドレーが提供するオンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！機会があれば是非ご活用ください。

さいごに

TSKaigi に協賛した様子をお届けしました。

LT セッションやブースにお越しくださった皆様、ありがとうございました！そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！

メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。ご興味がある方からのご連絡をお待ちしております。

FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました

Fri, 05 Apr 2024 14:41:06 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。

この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。

それでは、ご覧ください!

自己紹介

飯田さん

研修後はジョブメドレーで顧客向けの機能開発を担当。その後シゴトークでインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。

飯田さん

岡田さん

研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。

岡田さん

徳永さん

研修後はジョブメドレーアカデミーに配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。

徳永さん

古川さん

研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。

古川さん

村上さん

研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。

村上さん

吉岡さん

研修後は患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。

吉岡さん

ファーストキャリアとしてメドレーを選んだ理由について

── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。

飯田: 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があったことが理由になっています。

岡田: 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発しているんだなというのが具体的に分かって一貫性を感じられたのが大きいです。

他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。

徳永: 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチするなと感じたのが大きいです。

それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。

── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか?

徳永: エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。

古川: 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。

会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っているのを感じて、最終的にはこの部分に惹かれて入社を決めました。

あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。

岡田: 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。

村上: 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで自分が興味を持って取り組めそうなのは医療業界だなと思ったのが最初のきっかけでした。

メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。

吉岡: 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。

またさきほどの話にも出ていましたが、医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしているのも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。

現在のチーム内での役割について

── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。

飯田: 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。

チームメンバーとの関わりという点では、エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていくことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。

岡田: シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。

また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども裁量を持ってやらせてもらっています。

徳永: ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています。

開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。

またニュースリリースにもなりましたが、社内で初めての生成 AI を使った機能の開発は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です。

古川: Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。

自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています。

村上: CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。

現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリードさせてもらっています。

リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。

吉岡: 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。

大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。

── お二人で組んで仕事をすることもあるんですか?

村上: はい、とても多いです。進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。

吉岡: プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。

入社してメドレーの文化を強く意識した出来事

── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。

飯田: 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。

開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがあると思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。

岡田: 開発にあたって PM が施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。

そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。

徳永: メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でもメドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすいです。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。

また、とても良いなと思ったのが、部署や職種に関わらずConfluenceの情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。

古川: 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に議論に発展してより良いものを作っていけるというのは本当に素晴らしいと感じています。

実際に自分がリードしていた施策の中でもエンジニア・デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。

村上: 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。

いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、医療業務のキャッチアップはかなりしやすい環境だと思います。

もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。

特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。

吉岡: 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。

あとはミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無いのも、仕事がしやすいと思っています。

もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。

これからメドレーに入社する方へのメッセージ

── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。

飯田: そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります。

岡田: 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良いです。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。

徳永: 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良いと思います。

古川: 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、遠慮せずにがんがんと物事進めることができる人には最高なんじゃないかと考えています。

自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。

村上: メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚きです。

また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。

吉岡: メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それをいかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っているので、そういう思考でプロダクト開発ができているのはすごく勉強になります。

── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。

さいごに

それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。

メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう!

新卒配属2ヶ月目でChatGPTを活用した新規機能開発プロジェクトにアサインされた話

Fri, 29 Mar 2024 08:00:00 GMT

はじめに

自己紹介

はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。

私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「ジョブメドレー」のフロントエンドとバックエンドの開発を担当しています。

学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。

エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。

メドレーに入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「技術はあくまで手段であり、顧客への価値提供を目的にしている」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。

大学近くのビーチの夕焼け

入社から初プロジェクトまで

さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。

入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。

その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。

プロジェクトで解決する課題と解決策

まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、ニュースリリースも公開していますので、合わせてご覧ください。

ユーザーの抱える課題

これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。

フォーム形式の求人作成機能のイメージ

社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。

そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。

ユーザー目線の解決策

顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。

さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。

質問形式の求人作成補助機能のイメージ

ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、顧客への価値提供のために新しい技術を導入する考えが現れた意思決定だと思います。

技術スタック

今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。

ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。

文章生成機能の構成イメージ

プロジェクトへの関わり

今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。

プロジェクト初期

私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。

ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。

プロジェクト中盤以降

プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。

そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。

プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。

ChatGPT による提案機能のイメージ

さいごに

プロジェクトを振り返って

新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。

チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。

個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。

またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。

このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。

複数プロダクト横断したプロジェクトをどうやって成功させたのかメンバーに聞いてみました

Thu, 29 Feb 2024 14:22:09 GMT

はじめに

みなさん、こんにちは。エンジニアの古川です。

今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。

メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。

対談メンバー紹介

── はじめに、皆さんの自己紹介をお願いします。

江藤: 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。

経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。

これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。

このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。

江藤さん

── 江藤さんがプロジェクトの中心となって推進したんですね。

江藤: 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。

小田: 自分の所属も江藤さんと同じになります。経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。

入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。

小田さん

有馬: 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。

経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。

有馬さん

酒井: 入社は 2019 年 8 月なので、 5 年目となります。デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。

このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。

酒井さん

小島: 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである米山さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。

同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。

小島さん

同時予約の機能や解決した課題

── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。

江藤: 機能としては、CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能になっています。この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。

患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。

オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。

同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリットだと思ってます。

同時予約機能のリリース前後でのフローの違い

もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、オンライン診療後に発行された処方箋の流入が増加します。

調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。

── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。

開発プロジェクトについて

── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。

江藤: 開発側で言うと４つのドメインになってます。

調剤、患者、医科、そして 患者統合基盤です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。

ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。

いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。

── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。

江藤: そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。

またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。

現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出すのが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。

── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか?

江藤: はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。

Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。

横断プロジェクトで工夫をしたポイント

── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。

江藤: 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。

例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。

こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。

そこで本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。

これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。

── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。

酒井: はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。

メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところです。患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。

江藤: 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。

── 技術面で気をつけたポイントはどんなものがあったんでしょうか。

有馬: 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば診療所も薬局も患者にとっても価値のある機能となるかがポイントです。

ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。

── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。

有馬: 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。

酒井: 今回は、特にプロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になるので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。

江藤: 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、メドレーのエンジニアのとても良い部分だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。

同時予約 Pj 開発の実際

── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。

小田: 先に Pharms 側の機能を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。

一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできたかなと思ってます。

── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか?

江藤: 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。

酒井: 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。

── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。

チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか?

小島: 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。

後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。

メドレーのプロダクト開発の文化として QA エンジニアも要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行えるので、とても働きやすいですね。

── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか?

酒井: Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。

色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプルで処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。

話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。

横断プロジェクトならではのエンジニアリング

── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか?

小田: 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。

有馬: シーケンスの整合性や難しくなりすぎないように設計することには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。

江藤: 細かいプロダクト間の調整が必要になるのでちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。

工夫したことでいうと、UX 調査を徹底したところでしょうか。

今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。

小田: エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。

酒井: CLINICS で気にしてた部分はどちらかというとリスクとコストの部分、いかに最小化して価値を最大化するかが一番重要かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。

例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。

あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。

これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。

小島: QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。

ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。

工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。

QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。

例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。

そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。

アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。

幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。

同時予約 Pj を終えて

── では最後にこのプロジェクトの総括をしていだければ。

江藤: 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。

医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々あるんです。

なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。

次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。

── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう?

有馬: 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。

── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。

さいごに

同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。

このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう!

稼働中の Amazon Aurora PostgreSQL を暗号化した話

Fri, 22 Dec 2023 07:39:11 GMT

はじめに

こんにちは。プロダクト開発室第二開発グループ所属の古川です。

私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。

大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。好きなコーヒー豆の種類はインドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。

さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora（以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。

私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。

AWS のサービス全体は大体知っている
論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない
非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解

上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。

暗号化を実施する Aurora とその周辺アプリケーションについて

影響範囲と暗号化をする Aurora DB クラスターについて

今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。

実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。

Aurora DB クラスターの周辺について

複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。

また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。

実施方法の検討

実施方法の検討をする上で以下の観点を意識しました。

暗号化を実施する時間帯
暗号化するためにかかる時間
移行までの準備と労力・アプリケーションコードへの依存

暗号化を実施する時間帯

前提としてライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。

Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。

暗号化するためにかかる時間

暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要で、その時間も安定稼働までに確保しなければなりません。

以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。

移行までの準備と労力・アプリケーションコードへの依存

基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。そのためできるだけ変更箇所は少ないもの、特にできればアプリケーションコードの変更が極力ない方法というのを検証時点で決めておきました。

上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。

スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ）
AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ）
pg_dump & pg_restore を使用する方法（方法 3 ）

スナップショットを用いて新規暗号化済みクラスターを作成する方法

こちらの方法は Web 上で「 Aurora 暗号化後から」などと検索すると良くヒットする方法です。すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。

準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。

スナップショットの取得時間：3 分
暗号化済み新クラスターの作成：約 30 分
アプリケーションから接続する DB ホストの切り替え：数秒程度
AWS Fargate の再起動：3 分強

AWS DMS を用いて継続的論理レプリケーションを使用する方法

こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更〜レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。

移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。

また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。

pg_dump & pg_restore を使用する方法

こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。

結論からいうとこちらの方法を実際に採用しました。理由は主に以下になりますが、暗号化するクラスターのデータサイズが 5GiB 以下だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。

検証時にライターインスタンスの停止時間は 8 分程度だったこと
- pg_dump & pg_restore ： 4 分弱
- アプリケーションから接続する DB ホストの切り替え：数秒程度
- AWS Fargate サービスの再起動： 3 分強
移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと
検証時に開発環境で実行した後も不具合は確認されなかったこと

またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。

それぞれの検証結果をまとめると以下のようになります。今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。

項目	方法 1	方法 2	方法 3
暗号化するためにかかる時間	40 分弱	2 〜 5 分程度	5 〜 8 分程度
移行までの準備と労力	小	大	小
アプリケーションコードへの依存	なし	あり	なし

実施内容

行った作業内容は以下の通りで、それぞれ説明していきます。移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。

API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する
暗号化された Aurora DB 新クラスターを Terraform で構築する
旧クラスターを読み取り専用に変更する
移行スクリプトを実行する（実行時間： 3 分強）
DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒）
AWS Fargate サービスを再起動する（実行時間： 3 分強）

1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する

AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。

2. 暗号化された Aurora DB 新クラスターを Terraform で構築する

移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンスを見ればすぐに構築可能です）。

余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。

3. 旧クラスターを読み取り専用に変更する

旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。

4. 移行スクリプトを実行する（実行時間： 3 分強）

移行するためのスクリプトを実行します。実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。

$ pg_dump -h <旧クラスターのホスト名> -p <ポート番号> -U <ユーザー名> -d <データベース名> | \
    pg_restore -h <新クラスターのホスト名> -U <ユーザ名> -d <データベース名>

5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒）

移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。

6. AWS Fargate サービスを再起動する（実行時間： 3 分強）

ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。

$ aws ecs update-service --profile <プロファイル> \
    --cluster <クラスター名> \
    --service <サービス名> \
    --force-new-deployment

本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。

ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨

さいごに

まとめ

今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。

今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。

また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。

私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。少しでも私の経験が誰かの役に立てばうれしいなと思います。

このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？

toB 向け E ラーニングシステムに ChatGPT を導入して業務効率化を達成した事例について語ってもらいました

Thu, 30 Nov 2023 12:10:50 GMT

はじめに

エンジニアの山田です。

弊社のニュースリリースにあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「研修作成アシスタント」をリリースしています。この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。

今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。

インタビュイー紹介

岸田さん

SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。

徳永さん

2022 年メドレーに新卒入社。入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。

左: 岸田さん右: 徳永さん

ジョブメドレーアカデミーのサービス概要

── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか?

岸田: アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。

研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。

── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか?

岸田: 大前提として、提供している研修によって施設で働く人のスキルアップに役立たせる、という目的があります。それ以外では BtoB のサービスなので介護施設の事業効率化という点も重要視しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。

生成 AI を活用した研修作成アシスタントについて

機能の概要について

── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。

岸田: 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。

プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分なんです。

今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。

メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ）
一つひとつ動画を選んでオリジナルな研修を作成する機能

この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当するセミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズだったんです。

今回提供した「研修作成アシスタント」機能では、大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案してくれます。管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。

これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。

そもそもこの機能を開発した理由

── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。

岸田: アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業でした。

徳永: 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もあるので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。

── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。

徳永: こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、プロダクトが便利になるなという予感がありました。

アカデミーのサービス特性と ChatGPT の相性の良さ

── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか?

徳永: この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。

あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。

── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか?

徳永: 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと生成 AI が使われていないと事業としても不利になっていくタイミングが来るんじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。

── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。

岸田: そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。

こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。

徳永: 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。

研修作成アシスタントができるまで

── 最初はどんな感じで企画など進行したんでしょう?

徳永: 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。

岸田: 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました。

── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。

徳永: アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。

── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか?

岸田: 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。

ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するためにGoogle の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入したんです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。

これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。

── なるほど 3 段構えくらいで機能を実現しているんですね。

徳永: とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。

今回のプロジェクトでの経験で学んだこと

── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか?

徳永: 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました。

元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。

── では今回のプロジェクトに適任だったんですね!

岸田: あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画のメタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点でした。

今後のアカデミーの技術的な方向性

── これから解決していきたいアカデミーの技術的な課題のようなものってありますか?

岸田: 今回初めてプロダクトに生成 AI を導入しましたが、プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたいです。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。

徳永: ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造をもっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたいなとは考えています。

── ありがとうございました!

さいごに

元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。

また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。

こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう!

歯科医院の業務効率を高める Dentis のサブカルテ機能開発について聞く

Mon, 30 Oct 2023 15:37:32 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました!

対談メンバー紹介

Dentis 開発メンバーの紹介

新居: よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。

前田: CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。

前田さん

大岡: ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。

大岡さん

宮内: 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。

Dentis について

Dentis 誕生まで

新居: ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか?

前田: 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを取得するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。

詳しくはこちらの記事を参照ください。

新居: なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で作り直していますよね。再開してからは 1 から開発したんですか?

前田: はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。

宮内: 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。Next.js を導入したりなどですね。

大岡: 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。

新居: そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、特許も取得できる UI ができたわけですね。

Dentis のアーキテクチャについて

新居: 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。

宮内: サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。

新居: オーソドックスな構成になっているんですね。何か使いづらいなどはないですか?

大岡: 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。

新居: フロントエンドの状態管理はどのようにしているんですか?

大岡: Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。

サブカルテ機能の開発

サブカルテ機能とは

新居: では今回のメインの話であるサブカルテ機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。

前田: 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。

普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。

宮内: 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。

新居: アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。

前田: はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。

大岡: 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。

前田: Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。

サブカルテ機能の開発背景

新居: そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。

前田: Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。

技術的に難しかった部分

新居: 技術的に困難なところなどはありましたか?

大岡: 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。

どれかに対応させると、どれかが上手く表示できないなどがあったので。

宮内: 画像の表示ライブラリを途中で変更したりしましたよね。

大岡: 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。Fabric.js を使うように変更しました。

サブカルテ機能を作ったことによるプロダクトへの良い効果

新居: ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。

前田: 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。

大岡: 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。

前田: サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。

サブカルテ機能追加による反響

新居: 医院からはサブカルテの追加により何か反響はあったんでしょうか。

前田: ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。

宮内: ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。

Dentis チームにマッチするメンバー

新居: ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。

前田: 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑）

宮内: どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。

新居: なかなかハードルが高そうな経験ですね（笑）本日はありがとうございました!

さいごに

Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。

Dentis の開発に興味を持った方はぜひご連絡お待ちしております。

医療 PF 患者アプリチームのデータドリブンな改善

Fri, 29 Sep 2023 14:38:27 GMT

はじめに

みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴としてエンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっているという点が挙げられます。

今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。

自己紹介

吉岡さん

医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。

吉岡さん

メドレーに入社した理由

メドレーに入社するまでの経歴

山田: よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか?

吉岡: 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。

山田: 物理学を専攻していたということですが、授業でプログラミングをしていたんですか?

吉岡: いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり時間ができたので「何か始めてみよう」ということでプログラミングを始めたというのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。

山田: そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。

吉岡: はい、プログラミングしておらず入社もしていなかったかもしれないです(笑)

なぜメドレーに入社しようと思ったのか

山田: そんな吉岡さんは、どうしてメドレーに入社を決めたんですか?

吉岡: まず最初にメドレーの「医療ヘルスケアの未来をつくる」というミッションに共感したというのが大きい要因です。またプロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチをするという姿勢がとても良いと感じたのも理由になります。

山田: 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか?

吉岡: プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。

山田: 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑)

吉岡: そうなりますね(笑) ただ、iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。

取り組んでいる業務について

山田: それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。

吉岡: はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。

チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。

エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。

チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。

お薬手帳改善プロジェクト

お薬手帳とは、どんな機能か

山田: ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。

吉岡: 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、その機能をアプリ化して便利にしたものになります。

例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。

また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。

山田: なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。

吉岡: 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。

既存の「服用アラーム」の課題

山田: 「服用アラーム」はもともとそれ程には使われていない機能だったんですか?

吉岡: もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景をPdM が事前に分析などした結果として以下のような課題が浮き彫りになってきました。

そもそも「服用アラーム」機能を知らなかった
知っていても「服用アラーム」機能の使い方が分からない
「服用アラーム」機能を設定していても通知が届かない場合があった

そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。

服用アラーム設定の UI 改善
服用アラームの通知が届かない問題の解消
お薬登録から服用アラームの登録導線の改善

こうして、課題から実装方針までをまず決めていきました。

服用アラーム設定の UI 改善

山田: 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。

吉岡: まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました。UI 上でユーザーに少し混乱を招いてしまっていました。

そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。

山田: ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。

服用アラームの通知が届かない問題の解消

吉岡: はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、PdM と仮説を立てて検証していきました。

山田: なるほど。どのような仮説だったんですか?

吉岡: そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、Push 通知の許諾を促すための改善を行ないました。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、「服用アラーム」の通知が届かないという問い合わせが減少しました。

山田: かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか?

吉岡: はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。

服用アラームの登録導線の改善

吉岡: ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かったからです。

山田: かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか?

吉岡: 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。

良く考えると当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。

登録導線改善前の UI

山田: 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか?

吉岡: 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。

ですので、導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。

登録導線改善後の UI

山田: 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか?

吉岡: こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。

お薬手帳改善プロジェクトで苦労した部分

山田: お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか?

吉岡: 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変ではありました。

山田: これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。

吉岡: もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。

その他にネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。

お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ

山田: 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか?

吉岡: エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつくんだということが、実感できたという点は大きいです。

また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならないので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。

山田: ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか?

吉岡: ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。

目指すエンジニア像

山田: ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。

吉岡: まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの課題解決能力の高さを身に付けていきたいと思っています。

技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。

山田: どのようにそうした能力を高めていこうと考えているんですか?

吉岡: まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。

その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。

チームで一緒に働いていきたいエンジニア像

山田: 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか?

吉岡: そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニアの方と一緒に働きたいです。

色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。

山田: とても大事な意識ですね。本日はありがとうございました!

最後に

新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。

メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。

ジョブメドレー SRE Unit の業務を円滑に行う取り組みについて

Thu, 31 Aug 2023 07:43:52 GMT

はじめに

こんにちは。人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。

毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？

今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。

投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。

この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。

さて、現在私は SRE Unit リーダの立場で主にジョブメドレーの安定稼働に向けた取り組みに日々取り組んでいます。今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。

SRE Unit が取り組んでいる課題

SRE Unit の業務は

運用/メンテナンス
障害対応
アカウント管理
環境整備

と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。

この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。

特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。

バージョン追従対応とは？

まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。

これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。

EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。

バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。

また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。

「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。

そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。

作業の内容

この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。

前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。

新旧バージョンの変更履歴を把握
変更によるアプリケーション影響の把握
アプリケーションの動作チェック
負荷チェック
移行計画の策定
移行作業の実施

取り組み 1.予測/計画

これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。

AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。

さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。

この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。

対象リソースのリストアップ

まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。

ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。

ex.)

AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。

また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。

優先度の決定

リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。

最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。

これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。

後はこれらの優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。

効果

2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。

特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。

途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。

取り組み 2.突発作業の削減

先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。

社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。

PrivateGem サーバの構築

ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。

そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。

このサーバは RubyGems 向けの Proxy/キャッシュサーバという位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。

キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。

動作環境の Docker イメージ化

とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリの兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。

動作環境としては

プログラム開始時に EC2 起動
コードのダウンロード
ライブラリのインストール
プログラム実行
プログラム終了後に EC2 停止

という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。

具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。

そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。

これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。

また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。

効果

双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。

最後に

今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。

我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。

もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？

Tech Studio MATSUE オフィスのご紹介

Mon, 31 Jul 2023 03:05:55 GMT

はじめに

みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループグループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。

2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。

記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。

松江オフィスでやっていること

松江オフィスではレセコン新規開発プロジェクトとして、CLINICS カルテに内包されるレセコン部分の開発を Ruby on Rails で行っています。

医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。

レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。

電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。

これらの問題を解決すべく、Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。

アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。

松江オフィスで利用してる技術

サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。

新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。

現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。

松江オフィスの雰囲気・文化

松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。

松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきましたトレイルヘッズ様の HP にてご確認いただくことが可能です。

開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。

東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。

現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。

松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。

レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。

以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。

松江オフィスでこんな人と働きたい

以下に当てはまる方、大募集中です。

プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる
Our Essentials に共感できる
医療業界に革新を起こす壮大なミッションにチャレンジしてみたい

下記のリンクからご応募お待ちしています。

中途採用はこちら
2024 年度新卒採用はこちら

おわりに

簡単ですが、松江オフィスの紹介をさせていただきました。

今後も松江オフィスのメンバー一丸となってレセコンの開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

メドレーの開発組織をリードするグループマネージャについて語ってもらいました

Fri, 30 Jun 2023 03:26:07 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。

今回のインタビューは前回の CTO へのインタビューに続いて、メドレーの開発組織についてご紹介していきたいと思います。

メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。

インタビュイー紹介

今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。

平山さん

医療 PF 第一本部プロダクト開発室第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。

岡村さん

医療 PF 第一本部プロダクト開発室第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。

左から岡村さん、平山さん、筆者

前職までの経歴とメドレー入社の理由について

二人の経験について

新居: 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。

平山: メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。

顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。

新居: ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。

岡村: 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。

2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。

その後にメドレーにジョインするという経歴です。

岡村さん

メドレー入社の経緯について

新居: ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ?

平山: 私は 3 年半ですね。

岡村: 私は 4 年経ちました。

新居: もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか?

平山: 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。

転職に際しては、自分が身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。

平山さん

岡村: 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。

会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。

新居: 岡村さんは次の会社の事業領域は、意識していたんでしょうか?

岡村: 医療領域を名指しで考えていたわけではないです。しかし、いわゆる昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良いという考えでした。これは前職でも考えていたことだったので、引き続き志向していました。

メドレー入社後にどのような仕事をしていたのか

新居: ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。

平山: 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。

そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要があるという点は特徴的だと思います。

岡村: 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。

新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携しながら、このプロダクトを作っている開発チームを率いています。

GM としてのミッションと就任してから変わったこと・変わらないこと

新居: 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。

平山: ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「プロダクトを前進させる」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。

「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。

エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。

岡村: レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。

GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。

担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つかと思うので、そういう意識でメンバーのマネジメントをしています。

エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。

新居: お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。

平山: 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。

岡村: 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。

GM で苦労したポイント・どう克服していたか

新居: ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。

平山: 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑）

新居: 平山さんに口下手な印象は全然ありませんが（笑）

平山: 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。

大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます。

新居: ピープルマネジメント面では何かありましたか。

平山: 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。

新居: ありがとうございます。では岡村さんはいかがでしょう。

岡村: 平山さんに全く同感ですね（笑）

冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。

他には、メンバーのキャリア形成をどうするかという点が難しいと思います。メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたいのですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。

新居: なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。

岡村: 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。

また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、チームで一緒にプロジェクトを進める人という認識を持ってもらえたんじゃないかなと考えています。

もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。

GM を担う上で、役に立った経験・知識

新居: ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。

平山: そうですね、一番役に立っているなと感じているのは前職で経験した「様々なステークホルダーとの主体性を持った折衝経験」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。

岡村: 私が役に立っていると感じる経験は、「一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。

こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。

エンジニアのピープルマネジメントで意識していること

新居: 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。

平山: 自分達が作るプロダクトへの興味関心・解像度を高め、何を作るのか。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。

この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。

新居: 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。

平山: 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。

大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。

一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。

新居: そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。

平山: きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないようにメンバーから上がってきた疑問などに対する壁打ちなどは気軽にできるようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。

新居: ありがとうございます。岡村さんはどんな意識をしていますか。

岡村: やっぱり平山さんに全く同感ですね（笑）

付け加えると、ソフト面ですがメンバーであるエンジニアが楽しめる環境作りというところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。

また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。

そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。

GM という役割の醍醐味とは

新居: それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。

岡村: 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。メンバーと一緒に遠くに行くために組織作りなどをしていけるのが醍醐味だと感じています。

平山: メンバーの個人スキルを高めつつ「チーム」に還元してもらうための仕組みを作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。

チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。

メドレーで GM やリードエンジニアのロールに向いている方

新居: 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。

平山: 基本的に物事を前に進めるための解像度を高く描ける人かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。

やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。

岡村: 困難な状況であっても何とかして前に進めることができる人でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。

もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。

新居: なるほど。本日は色々なお話をしていただきまして、ありがとうございました!

さいごに

メドレーの GM 二人に仕事について聞いていきました。

前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。

このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。

新体制になったメドレー開発組織について CTO 2 人に語ってもらいました

Thu, 27 Apr 2023 17:22:45 GMT

はじめに

みなさん、こんにちは。技術広報・エンジニアの平木です。

既に 2 月に発表されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。

インタビュイー紹介

稲本さん

執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。

田中さん

執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。

左から田中さん、稲本さん

CTO を 2 名体制にして開発組織の体制をアップデートした理由

平木: さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。

田中: 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。

ただ、時間が経つに連れ段々と開発チームも各 PF 自体の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。

稲本: 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。

平木: これからの組織の変化を見据えた動きだということですね。

新しい開発体制になって変わっていく部分・変わらない部分

平木: 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。

稲本: 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。

それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。

平木: なるほど。田中さんは何かありますか。

田中: 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。

平木: 将来の課題に対して技術・組織なども先手を打っていくイメージですね。

新体制での開発組織のミッション

平木: それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。

田中: 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。

その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。

プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。

事業とプロダクト開発の関係性

平木: さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。

田中: ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。

平木: 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。

田中: そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。

解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。

稲本: ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。

稲本さん

平木: 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。

田中: メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。

平木: なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。

田中: 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。

平木: 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。

稲本: 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。

Our Essentials(以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。

プロダクトと技術の関係について

平木: もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。

田中: 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。

稲本: 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。

田中: ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。

平木: 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか?

田中: そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。

田中さん

平木: 改めてここで現在の開発体制について伺っていければと思います。

田中: 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。

平木: そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか?

稲本: もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。

田中: メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。

もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。

開発組織の雰囲気やメンバーの働き方について

平木: 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか?

稲本: 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。

自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。

コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。

田中: チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。

平木: 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか?

稲本: これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。

やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。

田中: 自分のバリューを最大化できるように働いていこうというのが基本になっています。

平木: 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか?

田中: 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。

平木: 評価のお話が出てきましたが、どういった観点で評価されますか?

稲本: ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。

立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。

田中: 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。

平木: ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。

田中: メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。

稲本: 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。

さいごに

新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。

2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。

そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います!

Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。1

Tanstack Query を活用したフロントエンドアーキテクチャの紹介 ~ 持続可能な開発を目指して ~

Fri, 31 Mar 2023 10:40:59 GMT

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。普段の業務では、医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。

CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。

この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。

Tanstack Query について
Tanstack Query を活用したフロントエンドアーキテクチャ
- Resource Operation の実装
- ViewModel の実装
Tanstack Query 導入の背景とアーキテクチャの狙い
まとめ
さいごに

Tanstack Query について

類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。²

私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。導入背景の詳細は、後のセクションで詳しく紹介します。

Tanstack Query を活用したフロントエンドアーキテクチャ

それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。始めに、アーキテクチャの全体像を示した次の図をご覧ください。

まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。

Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。役割を大きく分類すると次の 2 つが挙げられます。

非同期状態管理に関連する実装の集約
Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換

全体像を把握するために、左右のレイヤーにも注目してください。

右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、committee-rails を使ったレスポンス検証と、openapi-generator を使った API クライアントコードの自動生成に活用しています。

左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル³のみを参照する設計としています。

Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。

続いて、上記の運用のための実装詳細を紹介します。

Resource Operation の実装

ディレクトリ構成

Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。

ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。

src/resourceOperations
├── resourceTagName      # 例： todo
│   ├── cache.ts
│   ├── mutations.ts
│   └── queries.ts
└── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合）
    └── resourceTagName  # 例： organization（リソースグループ配下のリソース）
        ├── cache.ts
        ├── mutations.ts
        └── queries.ts

ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。

ディレクトリごとに次の 3 つのファイルを定義しています。

ファイル	役割
cache.ts	Query Key の定義、キャッシュ操作のためのカスタムフックの定義
queries.ts	useQuery をラップしたカスタムフックの定義、API Request/Response の整形
mutations.ts	useMutation をラップしたカスタムフックの定義、API Request の整形

cache.ts

cache.ts は次のように実装しています。

// ① Query Key
// queries.ts がある場合に必要に応じて宣言
export const todoKeys = {
  all: ["todo"] as const,
  list: () => [...todoKeys.all, "list"] as const,
  paginateList: (page?: number) => [...todoKeys.list(), { page }] as const,
  detail: (id: string) => [...todoKeys.all, "detail", id] as const,
};

// ② キャッシュ操作のためのカスタムフック
// mutations.ts がある場合に必要に応じて宣言
export function useTodoCache() {
  const queryClient = useQueryClient();

  return useMemo(
    () => ({
      invalidateList: () => queryClient.invalidateQueries(todoKeys.list()),
      invalidateDetail: (id: string) =>
        queryClient.invalidateQueries(todoKeys.detail(id)),
    }),
    [queryClient]
  );
}

① Query Key は、useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。

② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では楽観的更新をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。

queries.ts

queries.ts は次のように実装しています。

import { type Todo } from "@/viewModels/todo";
import { todoApi, type GetTodoDetailRequest } from "@/api/generated";

// ③ queryFn
export const query = {
  getTodoList: async (): Promise<Todo[]> => {
    const { data } = await todoApi.getTodoList();

    return data.todoList;
  },
  getTodoDetail: async (request: GetTodoDetailRequest): Promise<Todo> => {
    const { data } = await todoApi.getTodoDetail(request);

    return data.todo;
  },
};

// ④ Request Selector
export const request = {
  getTodoDetail: (id: string | undefined): GetTodoDetailRequest => {
    if (id === undefined) {
      // `enabled: false` となる条件の引数が与えられた場合例外とすることで、
      // queryFn 内の型の整合性を保つ
      throw new InvalidRequestParameterError(
        "Required parameter id was undefined when calling request.getTodoDetail."
      );
    }
    return {
      id,
    };
  },
};

③ queryFn は、API へのリクエストを責務とした関数群です。ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示しています。このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。省略していますが、レスポンスに応じたエラーの throw もここで行います。

④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で型ガードをしなくて良い設計としています。

これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。

// ⑤ Base Query
// API Response を整形せずに返す
export type UseTodoDetailQueryProps<QueryResult> = {
  id: string | undefined;
  select?: (data: Todo) => QueryResult;
};

export function useTodoDetailQuery<QueryResult = Todo>(
  props: UseTodoDetailQueryProps<QueryResult>
) {
  return useQuery({
    queryKey: todoKeys.detail(props.id),
    queryFn: () => {
      return query.getTodoDetail(request.getTodoDetail(props.id));
    },
    enabled: !!props.id,
    select: props.select,
    useErrorBoundary: true,
  });
}

import { selectTodoForm } from "@/viewModels/todo/todoForm";

// ⑥ Selector Query
// API Response を View で参照したいフォーマットに整形して返す
export function useInitialTodoFormQuery() {
  // Base Query に select オプションを与える
  return useTodoDetailQuery({
    select: selectTodoForm, // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述）
  });
}

useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。4

加えて、この手法では Selector にドメインロジックが凝集されるため、Selector を重点的にテストすることで品質を担保しやすいメリットがあります。

Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。

mutations.ts

mutations.ts は次のように実装しています。

import { type TodoForm } from "@/viewModels/todo/todoForm";
import { todoApi, type PostTodoRequest } "@/api/generated";

// ⑦ mutationFn
export const mutation = {
  createTodo: (request: PostTodoRequest) => {
    return todoApi.postTodo(request);
  },
};

// ⑧ Request Selector
// ViewModel から API Request へ変換する
export const request = {
  createTodo: (todoForm: TodoForm): PostTodoRequest => {
    return {
      PostTodoRequest: {
        todo: {
          title: todoForm.title,
          description: todoForm.description,
          status: todoForm.status,
          favorite: todoForm.favorite === "true" ? true : false,
        },
      },
    };
  },
};

// ⑨ Custom Mutation
export function useCreateTodoMutation() {
  const { invalidateList } = useTodoCache();

  return useMutation({
    mutationFn: (todoForm: TodoForm) => {
      return mutation.createTodo(request.createTodo(todoForm));
    },
    onSuccess: () => {
      return invalidateList();
    },
  });
}

基本的な構成は queries.ts と同じです。

mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。

Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。

Resource Operation レイヤーに関する実装の紹介は以上です。

ViewModel の実装

ViewModel とは、View(React Component) で扱うデータのスキーマと型です。

Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。

全体の理解を深めるため、ViewModel の実装も紹介します。

ディレクトリ構成

ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。

src/viewModels
└── todo
    ├── todo.ts                # サーバステート
    ├── todoForm.test.ts       # フロントエンドに閉じたスキーマのテスト
    ├── todoForm.ts            # フロントエンドに閉じたスキーマ
    └── todoSearchCondition.ts # フロントエンドに閉じた型

ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。

サーバステート
フロントエンドに閉じたスキーマ
フロントエンドに閉じた型

サーバステート

サーバステートは、 API Response として期待するデータのスキーマ及び型です。前述の queries.ts 内の ③ queryFn で使用します。

zod を使って次のように実装しています。

// src/viewModels/todo/todo.ts

// enum は View で <option value={todoStatus.enum.ready} /> のように使用する
export const todoStatus = z.enum(["ready", "doing", "done"]);

// ⑩ サーバステートのスキーマ
// 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する
export const todo = z.object({
  id: z.string(),
  title: z.string(),
  description: z.string().nullable(),
  status: todoStatus,
  favorite: z.boolean(),
});

// ⑪ サーバステートの型
// ③ queryFn の戻り値の型として使用する
export type Todo = z.infer<typeof todo>;

⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。

開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。

// src/resourceOperations/todo/queries.ts
import { todo, type Todo } from "@/viewModels/todo";

export const query = {
  getTodoList: async (): Promise<Todo[]> => {
    const { data } = await todoApi.getTodoList();

    // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する
    // 検証が済んだら parse 処理を外す
    return data.todoList.map((x) => todo.parse(x));
  },
};

例外として、外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証しています。例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。

フロントエンドに閉じたスキーマ

フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。こちらも zod を使って定義しています。

// src/viewModels/todo/todoForm.ts

import { type Todo, todo } from "./todo";

// フロントエンドに閉じたスキーマ
// フォームのスキーマは react-hook-form と連携して使用する（省略）
export const todoForm = z.object({
  title: z
    .string()
    .min(1, "入力してください")
    .max(200, "200字以内で入力してください"),
  description: z.string().max(500, "500字以内で入力してください"),
  status: todo.shape.status,
  favorite: z.union([z.literal("true"), z.literal("false")]),
});

export type TodoForm = z.infer<typeof todoForm>;

// ⑫ ViewModel Selector
// サーバステートからフロントエンドに閉じたスキーマへ変換する
// 前述の queries.ts 内 ⑥ Selector Query で使用する
export function selectTodoForm(todo: Todo): TodoForm {
  return {
    title: todo.title,
    description: todo.description ?? "",
    status: todo.status,
    favorite: todo.favorite ? "true" : "false",
  };
}

フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の空文字への変換や時間データのフォーマットのような、サーバステートと View で使う値の差分吸収はこのセレクタ内で行います。

このように、ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現しています。ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。

フロントエンドに閉じた型

依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。

// src/viewModels/todo/todoSearchParams.ts

export type TodoSearchCondition = {
  sort?: "created_at_asc" | "created_at_desc";
};

ViewModel に関する実装の紹介は以上です。

Tanstack Query 導入の背景とアーキテクチャの狙い

背景：コード品質の課題

Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。

開発体験の課題

非同期処理のためのミニマムな基盤フックを独自に実装していた 5ことにより、開発体験の観点で次のような課題がありました。

新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある
テストが実装されていなかったため変更時に品質確認の負担が大きい

学習容易性の課題

上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。

基盤フックにドキュメントがなく、新規メンバーの学習コストが高い
様々な実装手法が混在することで、実装時に迷いが生じている

可読性の課題

CLINICS は開発開始から約 7 年以上が経過しています。その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。

これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。

画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い
コードレビュー時のレビュワーの負担が大きい

テスト容易性の課題

多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。

テストが実装しづらい
テストカバレッジが低い

CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けることが重要です。

前の章で紹介したアーキテクチャは持続可能な開発を目指して設計しました。具体的には、開発体験・学習容易性・可読性・テスト容易性を向上することを狙いとしています。

狙い 1：Tanstack Query の導入による開発体験の向上

背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。

Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。

極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい
実装に困ったときにドキュメントを読めば解決する環境にしたい

CLINICS では技術的な背景 6から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。

Tanstack Query を採用したことで、非同期処理のためのコードの記述量が大幅に削減されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。

狙い 2：シンプルなレイヤー分割による学習容易性の向上

CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。実装の進め方はプロジェクトによって最適な形式を選択しています。

バックエンドからフロントエンドまで一気通貫で実装
技術領域に分けて分業

このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。

前の章で紹介したアーキテクチャは、レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にすることを意識しています。

加えて、実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できるほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。

レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。

フロントエンドアーキテクチャの話: Resource Set の紹介

ほかにも CLINICS では学習容易性の向上の取り組みとして、新しいライブラリやアーキテクチャを導入した際は勉強会を開催してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。

狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上

アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。

CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、シンプルでテストしやすいコードベースを作っていくことがとりわけ重要だと考えています。

この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。

まとめ

Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。

Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。
レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。
useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。
データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。

この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。

さいごに

CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。

Redux から Tanstack Query への移行

UI ライブラリの Mithril から React への移行⁷
デザインシステムの構築とプロダクトへの反映

このような取り組みに興味がある方は次のリンクから是非ご連絡ください。

Overview | TanStack Query Docs ↩
Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩
この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩
Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩
Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩
CLINICS では一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩
2023 年 3 月現在、 CLINICS のフロントエンドの約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

ジョブメドレー開発チームにおける 2 年目の成長と活躍

Tue, 28 Feb 2023 06:15:36 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトのジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。

インタビュイー紹介

堀内さん

2021 年入社。人材プラットフォーム本部プロダクト開発室第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。

堀内さん

メドレーに入社した理由

新居: まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？

堀内: 以前のインタビュー（21 年新卒入社エンジニアと座談会で振り返る新卒研修）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ビジネス側と開発側の距離が近い部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。

新居: 入社前の印象と実際働きだしてからで、ズレなどはありましたか？

堀内: そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。

新居: 何人くらいの社員と会ったのですか？

堀内: 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。

新卒研修の開発 OJT ではどんなことをやっていたか？

新居: 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？

堀内: まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。

その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。

技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。

また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感できてとても良い経験になりました。

今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。

新居: 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。

ちなみに開発 OJT の中で大変だったこととかはありますか？

堀内: そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。

大変だった分、システムの全体像を理解するのに大いに役立ったので、今思い返すと良い経験だったなあと思います。

色々な経験を積めた求人カード改修プロジェクト

新居: では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？

求人カード改修プロジェクトとは？

堀内: それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。

検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。

もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡

新居: なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。

プロジェクトのはじまり

新居: 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。

堀内: チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。

プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。

仕様についてメンバー間で徹底議論

堀内: 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました。

新居: 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。

堀内: はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。

その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。

使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。

デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。

技術面について

新居: UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？

堀内: 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡

担当したプロジェクトのリード

新居: 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？

堀内: まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。

新居: なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？

堀内: スケジュールの共有方法については、視覚的に分かりやすいように、FigJam を使って、ガントチャートのような形式で、ボードを作成しました。

メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、第三者が見ても進捗状況が直ぐに分かるような状態にしておくよう努めました。

スケジュールボード

スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。

現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。

新居: 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。

堀内: また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。

結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。

A/B テストの導入（効果検証の仕組み化）

新居: オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？

堀内: 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。

統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。

A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡

今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。

新居: とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？

堀内: A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡

実装や設計面における悩み

新居: 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？

堀内: はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。

新居: なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？

堀内: そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。

その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡

新居: なるべく手戻りが発生しないようにする為に、設計段階で身近にいるエンジニアを巻き込んで進めていったのですね。直ぐに相談できる相手がいるのは心強いですね。

学びになった点

新居: 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？

堀内: 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。

技術的な面で言うと、保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できたところだと思っています。

プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。

新卒研修・開発実践のリードとの違い

新居: 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。

堀内: プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。

また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。

ジョブメドレーの開発におけるやりがい

新居: ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？

堀内: やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡

勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡

リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、PDCA サイクルを回していっている開発スタイルに楽しさを感じています。

これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。

ジョブメドレー開発チームにおける 1 日の流れ

新居: 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。

堀内: まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。

現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。

お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くすることができる貴重な場となっています｡

18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。

さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す「技術共有会」を行っています。

技術共有会の雰囲気

ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。

新居: なるほど。質問や相談はしやすい感じですか？

堀内: はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。

新居: ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？

堀内: あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。

プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。

この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。

直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。

1on1 ミーティングの意義としては、そういった仕事の他、プライベートのことも含めて、何でも相談ができる場としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。

ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？

新居: 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？

堀内: 今の環境で働いてて良かったなあと思うことは、人間関係が良好であることです｡もちろん馴れ合いの中での業務というわけではなく､各々がしっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめるという､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。

このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。

自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。

さいごに

ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう!

Pharms 開発チームが取り組んでいるチームビルディング "TGIF" とは？

Tue, 31 Jan 2023 02:20:34 GMT

はじめに

みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。

インタビュイー紹介

新居さん

2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。

小田さん

2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。

兒玉さん

2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。

新倉さん

2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。

古川さん

2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。

Pharms というプロダクトについて

山田: まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか?

新居: 一言で言うと、薬局の業務効率化支援システムです。CLINICS オンライン診療で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。

新居さん

山田: ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトのジョブメドレーでは、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか?

小田: CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。

小田さん

山田: やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。

Pharms 開発チームの TGIF という試みについて

TGIF を始める前の課題感

山田: それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか?

小田: 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。

山田: 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか?

小田: 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために雑多に何でも話せるコミュニケーションの場を作ろうというのが、きっかけでした。

新居: もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。

山田: そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか?

新居: クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。

山田: チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。

新居: はい。チームの状況が変わって行く中で、もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。

TGIF の実際

山田: では、具体的に TGIF でどのような事を話し合われるんでしょうか?

新居: まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。

小田: その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。

KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。

新居: 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。

その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。

山田: 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか?

小田: KPT の内容を踏まえて、基本的には Our Essentials(以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。

固くなりすぎない会を目指して

山田: なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか?

小田: TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。

お菓子を囲んでの TGIF

山田: 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。

TGIF 運用の秘訣

山田: 他に TGIF を運用する上での工夫などはありますか?

新倉: 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。

新倉さん

古川: 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。

古川さん

兒玉: ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。

兒玉さん

新居: ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」という事を意識しています。

こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。

小田: また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。

山田: へえー!何でテディベアなんですか?

新居: プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。

テディベアのリマインダーにコメントが付いている様子

山田: なるほど、それでテディベアが出てくるんですね。

小田: TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。

新倉: これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。

TGIF の利点とこれからについて

山田: ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。

小田: やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。

新居: 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。

新倉: 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。

新居: 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。

古川: 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。

兒玉: 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。

山田: みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。

新居: 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。

小田: 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。

新倉: 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。

Pharms 開発チームでは、どんな人と一緒に働きたいと考えている?

山田: ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか?

小田: いつもチーム内で話をしているのが「顧客ファースト」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。

新居: メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。

山田: TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました!

さいごに

Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。

こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう!

Slack × AppSheet × GAS を利用した ChatOps なアプリ開発〜テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図る〜

Fri, 23 Dec 2022 06:38:18 GMT

はじめに

こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。

コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。

今回は、こうした課題解決の一例として、「呼び鈴アプリ」の開発について背景と実装のご紹介をし、最後にコーポレート IT チームの業務内容や理念についてご紹介したいと思います。

呼び鈴アプリの開発背景

弊社では、チャットツールである「Slack」と「Google Workspace」や「TeamSpirit」等を連携して、来客者受付システムや稟議ワークフローシステム、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。

今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、通称：呼び鈴アプリ をご紹介しようと思います。

呼び鈴アプリ導入前の困りごと

IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。

■ 従業員側の困りごと

・誰に話しかけたらよいかわからない

IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。

・時間調整に手間がかかる

PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。

■ コーポレート部門の困りごと

・依頼者が見つけづらい

座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。

・個人情報が見えると困る

従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。

・従業員の氏名確認に手間がかかる

全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。

・周りの業務状況に配慮が必要

依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。

・依頼者への対応が属人化しがち

コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。

上記の課題を解決するために、従業員の方向けにコーポレート部門の担当者を呼び出すアプリを作りました！

どういったアプリか

呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じたコーポレート部門の担当者を呼び出すことができるアプリです。

コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。

ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。

アプリの利用イメージ

まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。

呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。

画面イメージ

利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。

導入後の効果

呼び鈴アプリの導入によって、

従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、自身が都合の良いタイミングでカウンターの呼び鈴アプリに来れば良く、利便性が向上した。
Slack 通知に依頼者氏名が表示されるので、氏名を確認する必要がなくなった。
コーポレート部門の担当者が依頼者の席を探して尋ねなくてよくなった。

というように困りごとが改善されました。

また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。

呼び鈴アプリの構成

呼び鈴アプリの開発にあたっては

1. 先述の課題を解決すること

2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること

3. なるべくランニングコストをかけないこと

という要件から、AppSheet と Google App Script（以降 GAS）で実装することを決めました。

機能検証期間を含めて 1 週間程度で実装できています。

AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。

AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。

サービス連携図

UI を AppSheet で、Slack への通知を GAS で実装しています。

画面構成

画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。

呼び鈴アプリの実装

呼び鈴アプリをどのように実装しているか解説していきます。

AppSheet の設定

AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。

1. Data の設定

Tables と Slices について、それぞれ設定します。

Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。

1-1. Tables の設定

今回 Table は以下の 5 つを用意しました。

テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。

テーブル名	利用用途
Client	依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル
Doorbell	依頼内容一覧画面に表示するテーブル
DoorbellDetails	依頼詳細一覧画面に表示するテーブル
CallHistory	呼出履歴を保存するテーブル
UserList	依頼者選択画面に表示するテーブル

依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。

・ DoorbellDetails

依頼詳細一覧画面に表示したい内容を一覧で記載します。

分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。

対応説明に関しては、任意で入力していただければ大丈夫です。

SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。

3 行目以降のデータは、 2 行目を参考に設定してください。

スプレッドシートへのデータ入力例

行番号	A 列	B 列	C 列	D 列	E 列
1	分類 ID	対応 ID	対応名	対応説明	SlackChannel
2	receipt	1	入社にあたって貸与物を受け取りたい		（通知先チャンネルの Webhook URL を設定）

Table での設定例

分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。

・ CallHistory

呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。

スプレッドシートへのデータ入力例

行番号	A 列	B 列	C 列	D 列	E 列	F 列	G 列
1	CH_id	CH_分類 ID	CH_対応 ID	CH_対応名	CH_SlackChannel	CH_呼び出し日時	CH_依頼者

Table での設定例

1-2. Slices の設定

次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。

貸与物受け取りに関する Slice の場合、以下のように設定します。

設定項目名	設定値
Slice name	貸与物受け取り
Source table	DoorbellDetails
Row filter condition	`[分類 ID]="receipt"`

2. App の設定

Views について、それぞれ設定します。

2-1. Views の設定

依頼詳細一覧画面について詳しく説明します。

・依頼詳細一覧画面

依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。

設定項目名	設定値
View name	貸与物受け取り画面
For this data	貸与物受け取り
View type	deck
Position	ref
Primary header	_RowNumber
Secondary header	対応名
Event Actions(Row Selected)	SaveAndMoveToClientForm（Actions の設定後、設定可能になります）

3. Actions の設定

各ボタンを押したときの動作を定義します。

実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。

Action 名	利用用途
MoveToClientForm	依頼者選択画面に遷移する
SaveCallHistory	CallHistory にデータを保存する
SaveAndMoveToClientForm	CallHistory に保存後、依頼者選択画面に遷移する

・ MoveToClientForm

依頼者選択画面に遷移する Action です。

設定項目名	設定値
Action name	MoveToClientForm
For a record of this table	DoorbellDetails
Do this	App: go to another view within this app
Target	”#view=依頼者選択”

・ SaveCallHistory

「CallHistory」テーブルにデータを保存する Action です。

選択された氏名については「Client」テーブルからデータを取得しています。

また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。

設定項目名	設定値
Action name	SaveCallHistory
For a record of this table	DoorbellDetails
Do this	Data: add a new row to another table using values from this row
Set these columns	CH_id = UNIQUEID()
	CH_分類 ID = [分類 ID]
	CH_対応 ID = [対応 ID]
	CH_対応名 = [対応名]
	CH_SlackChannel = [SlackChannel]
	CH_呼び出し日次 = TODAY() & ” ” & TIMENOW()
	CH_依頼者 = Client[ご自身の氏名]
Display name	呼び出し
Only if this condition is true	ISNOTBLANK([SlackChannel])
Needs confirmation?	True
Confirmation Message	CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”)

・ SaveAndMoveToClientForm

呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。

設定項目名	設定値
Action name	SaveAndMoveToClientForm
For a record of this table	DoorbellDetails
Do this	Grouped: execute a sequence of actions
Actions	SaveCallHistory
	MoveToClientForm

スプレッドシートの設定

AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。

GAS の記述

先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。

App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」のシートが更新されたときだけ、Slack に通知するように GAS を記述します。

function onChange(e) {
  // イベントが"EDIT"の場合のみ実行。
  if (e.changeType === "EDIT") {
    const ar = e.source.getActiveRange();
    const sheet = e.source.getActiveSheet();

    // CallHistory シートが更新された場合のみ Slack に通知する
    if (e.source.getSheetName() == "CallHistory") {
      const inquiry = sheet.getRange(ar.getRow(), 4).getValue();
      const slackWebHook = sheet.getRange(ar.getRow(), 5).getValue();
      const clientName = sheet.getRange(ar.getRow(), 7).getValue();

      notifyToSlack(
        slackWebHook,
        "コーポカウンター呼び鈴",
        ":notification_bell:", // お好きな Slack の絵文字を設定して下さい。
        `<!here>
        ${clientName}さんが${inquiry}で呼び出ししています。`
      );
    }
  }
}

function notifyToSlack(url, username, icon, message) {
  const jsonData = {
    username: username,
    icon_emoji: icon,
    text: message,
  };
  const payload = JSON.stringify(jsonData);

  const options = {
    method: "post",
    contentType: "application/json",
    payload: payload,
  };

  UrlFetchApp.fetch(url, options);
}

トリガーの設定

スプレッドシートに呼出履歴が登録（行追加）されたら、onChange() を実行するように設定します。

問題なく動作すると、Slack に以下のようなメッセージが通知されます。

実装する上で難しかったこと

AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。

1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと

AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。

→ 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。

2. ボタンの配置と表示が変更できないこと

基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。

→ テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。

ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。

ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。

以上、呼び鈴アプリの開発についてお話しました。

ここからは、コーポレート IT についてご紹介していきます。

コーポレート IT について

コーポレートデザイン部は、「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。

一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。

そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。

コーポレート IT の役割

コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。

そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。

逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。

各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。

業務内容紹介

コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。

端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用
オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで）
社外来客用受付システムの改修/運用
呼び鈴アプリの企画/開発/運用
従業員向けの情報セキュリティ研修
人事基幹システムの導入支援/各システムとの連携機能構築 etc

また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。

業務を行う上で常に意識していること・大事にしていること

コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。

1. システム選定/技術選定の考え方

システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。

2. ユーザー IT サポートの考え方

老子が言っている『授人以魚不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。

「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。

3. ルールを作らず、仕組み/仕掛けで解決する

ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。

例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。

さいごに

コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。

そのため、未来志向で #革新と改善を主導できる方を絶賛募集しております。

メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？

NestJS を使ってジョブメドレーアカデミーのバックエンド開発をどのように行なっているのか

Wed, 30 Nov 2022 01:40:06 GMT

はじめに

みなさん、こんにちは。エンジニアの山田です。今回はジョブメドレーアカデミー（以下、アカデミー）の開発の皆さんに集まってもらい、TypeScript と NestJS を使ったバックエンド開発をどのように行なっているのかをインタビューしました。

以前、アカデミーがリニューアルした際にチームメンバーにインタビューした note もあるので、未読の方はぜひそちらもご覧いただければと思います。

インタビュイー紹介

岸田さん

SES 会社で業務システム開発、バングラデシュに支社があるオフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。

熊本さん

2019 年メドレーに新卒入社。半年の研修を経てジョブメドレーの開発に携わる。現在はアカデミーの開発に携わる。大学では機械学習を用いた自動車の自動運転の研究をしていた。

牧野さん

2021 年 11 月にメドレー入社。不動産業界の SaaS を開発している会社でのマネージャー・エンジニアを経験。現在はアカデミーの開発に携わる。

徳永さん

2022 年メドレーに新卒入社。 OJT 期間中からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。

アカデミーのアーキテクチャ

山田: 早速ですが、現在のアカデミーのアーキテクチャについて話を伺いたいと思います。全体の構成としては現在どんな形になっているんでしょうか。

岸田: 以前話をしたところから大幅に変わったところはないですが、大まかにはこんな感じになっています。

山田: ありがとうございます、分かりやすいですね。

(手前)岸田さん・(奥)牧野さん

山田: Web フロントエンドに関しては Next.js とグローバルの状態管理として Apollo Client を使っていると伺っています。バックエンドは色々あると思うのですが、DB に関しては PostgreSQL を使っているんですよね?

岸田: はい、ORM としては Prisma を使っています。

山田: こうした開発環境はどのように決まったんでしょうか?特に、開発言語を全て TypeScript で統一する、という意思決定が先にあってバックエンド側のフレームワークは NestJS にしようとなったのか、逆に NestJS を使おうとして TypeScript になったのかをお聞きできれば。

岸田: 細かいところまでは記憶にないのですが、TypeScript を使って型で開発をしたいというのが一番大きい理由でした。

山田: まずは TypeScript からだったんですね。そこから Web フレームワークとしては Express など他の物もあったと思いますが、NestJS を採用した理由は何だったのでしょうか?

岸田: そうですね、色々選択肢はあったと思うんですが、現実的にサービスを運用するとなると Express と NestJS のどちらかかな、という感じになっていました。

どちらも実開発での経験を持っているメンバーはいなかったんですが、Web 開発で良く使われる Web フレームワークは、基本的な機能やコンセプトについては共通する部分が多いことに加えて、アカデミーも特殊な仕様があるプロダクトではないので、どちらを選んだとしてもメンバーが困ることはないだろうと考えました。

その上で細かい使い勝手などを検討したり GraphQL との親和性の高さや Express という枯れた技術をベースにしていて、フレームワーク自体の信頼感もあるので NestJS に決めたという感じでした。

熊本: 絞り込んだ段階で各メンバーが NestJS を試験的に触り、使用感を見てみましたが、大きく問題になる点もなかったので全員一致で決まった感じですね。

岸田: 前述のように Express をベースにしているので何か困ったら最悪 Express にすれば良いなというのもありました。

牧野: ここまで実際大きな問題というのは無かったです。

山田: 今は GraphQL を使って API を作っていると思いますが、REST で作るという選択肢は最初から無かったんですか?

岸田: はい、GraphQL を使えるメンバーが揃っているという状況であえて REST にするメリットは無いなという事で考えていませんでした。外部公開する API があるとか、パフォーマンスがすごく重要な重い API 呼び出しというのがあったら別だったでしょうけども。

山田: そもそもの話になってしまうんですが、弊社のプロダクト開発でよく使われている Ruby on Rails を使う選択肢は無かったんでしょうか?

岸田: 選択肢としてはあるにはあったんですが、プロダクトのフェイズとして現在既に成長をしているサービスであることや、メンバーのスキルセットとして Rails に慣れたメンバーがそこまで多くなかったことを考えると、いかに技術的負債を少なく保ちつつ、機能開発をしていけるかという点が重要になるので、現在の技術構成にしました。

これが既存サービスのリニューアルではなくて、新規で一から全部作っていかないといけないという状況であれば Rails を使うかもしれませんが、やっぱり型があってある程度開発効率が高くなるというのは魅力的だったので、これからどんどんと機能開発をするには今の構成が良いと判断しました。

(手前)徳永さん・(奥)熊本さん

山田: DB に関して PostgreSQL ですが、MySQL などにするということは考えなかったですか?

熊本: そうですね、リニューアル前のアカデミーが使っていたということがあり、大きく変えるメリットはあまり無かったのが大きいです。

岸田: あとこれは自分の感覚なのですが、PostgreSQL の方がスマートに処理できることが多いという印象があるというのもありました。

山田: 元々サービスで使っていたというのは、やっぱり大きいですね。ORM は Prisma ですよね。例えば他に TypeORM などの選択肢もあったと思いますが、こちらはどういった経緯で使うことになりましたか?

熊本: 色々と触ってみた結果、Prisma が自分たちの使い方にマッチしてたのが大きかったです。がっつりと SQL を自動生成するなどの手厚い機能は、自分達の使い方では必要もなかったですし。キャッチアップのためにペアプロなどもしましたが、メンバーも使いやすいということが確認できました。

山田: 今ペアプロの話が出ましたが、どのような目的でやっていたんでしょうか。

熊本: 初期の頃はメンバー間の知識などに偏りもあったので、そういったものを実際にコードを触りながら埋めていくという目的でした。実際に、GraphQL を使ったことがなかったメンバーも早く慣れてくれました。

山田: なるほど。ある種学習も兼ねていたんですね。最終的に現在このアーキテクチャの使い勝手としては感想としてどうでしょうか?

岸田: 言葉は違うかもしれないですが「普通に使い勝手が良い」という感じです。

もちろんメンバーが習熟してきたので、色々とコード的に改善しようという部分はあったりもしますが、今のところ本当に困った問題というのは無いので、非常に良い選択だったかと思います。

NestJS のテストコードについて

山田: テストコードは基本書いているんですよね?

熊本: はい、バックエンドは基本的に Jest で全部書いています。フロントエンドに関しては今まさに E2E テストをどのように実施していくかを試行錯誤しているところですね。

山田: NestJS でテストコード書くのに何か困ったこととかありましたか?

岸田: 困っているというわけではないですが、Rails でほぼ必ず使われている Factorybot に相当する機能が欲しいですね…。

山田: 確かに Node.js だとそういったライブラリを見かけないですね…。

岸田: 皆さんあんまり困ってないのかな?ということで今は簡易的なものを自作して使っています。

山田: OSS で作ったら需要があるかもしれませんね。

現状の NestJS での開発の課題感

山田: ここまで NestJS での開発について聞いてきましたが、プロダクト開発での課題は何かあったりしますか?

岸田: 先ほども少し話をしたメンバーの習熟度が高くなったことによるコード改善の他には、NestJS というか Node.js が Rails に比べると定番ライブラリが少なめなのがあります。

例えば、Sidekiq のようなライブラリって便利だと思うんですが、相当するライブラリでデファクトスタンダードというようなものが Node.js だと少ない気がしています。ライブラリが一杯あるのですが、デファクトまでいかないというものが多いという感想です。

山田: 確かに Node.js だと同じ目的のライブラリが複数あって機能がちょっとずつ違うという感じがありますね。

牧野: あとは機能開発にリソースを取っているので、細かい部分でのライブラリのアップデートが遅れ気味というのが課題感としてあります。

今のところはとてつもなく遅れているというわけではないのですが、積り積っていくとこういった部分が負債になっていくので、対応したいと思っています。

岸田: こういったものも含めてプロダクト開発を円滑に回すために、自分も含めた各メンバーのスキルを広げて深くしていかないといけないなというのもありますね。

チームへのオンボーディングについて

山田: さて、話が変わって現在アカデミーで一番最後にジョインしたのが徳永さんだと思いますが、オンボーディングなどはどのような感じだったんでしょうか。学生時代に NestJS はがっつり触っていたんでしたっけ?

徳永: いえ、学生時代はチュートリアルをしたくらいで、深く使っていたということはなかったです。ですので、最初は全然プロダクトのコードが分からないというレベルで、ほとんど未経験でした。

山田: なるほど。ほぼ未経験で新卒研修を経て、アカデミーの開発チームにジョインして困った部分などはありましたか?

徳永: TypeScript を使っているというのは凄く自分にとって良くて、言語でつまづくということはほとんどありませんでした。

やはり公式ドキュメントがすごく充実していますし、コミュニティの質の高い情報も多いので。プロダクトに関しては過去の Pull Request や Issue 上のやり取りなどで、どういう意図で実装されたものなのかを参照できたのが大きかったです。一方でバックエンドのデザインパターンなどは経験が少なく苦労した部分がありました。その部分はドキュメントで学習したり、周りのメンバーに直接質問しながらキャッチアップしていきました。

山田: 今年は入社後研修も TypeScript で書く割合が Ruby よりも多かったので、それがもし逆だったら、もっと苦労していたかもしれないですね。

徳永: そうですね、その可能性は十分にあり得ます。

山田: あとアカデミーチームは火水木に勉強会を開催していますよね。ジョブメドレーの開発チームでも噂になっています。

岸田: これは全員で集まる勉強会というわけではなく、月によって各自テーマを決めて火水木 1 時間ずつスキルアップのために時間を確保し、学んだことなどをアウトプットしていくという形式です。アウトプットしたものは、お互いに確認して知識を深めていこうというものですね。

山田: それは素敵な取り組みですね。あとは Figma で開発ドキュメントをまとめているのが印象的ですよね。

牧野: 最初は岸田さんが率先して、開発した部分のドキュメントなんかを書いていたんですが、最近はチームで共有するようなものもほとんど Figma でまとめるようになっています。

熊本: もちろん永続化しないといけないドキュメントは README なりコンフルエンスなりに書いていくのですが、ちょっとしたものを気軽に Figma にまとめられるのはすごく良いです。

岸田: 他の人がやっていることなんかも絶対に目につくので、そういった意味でもドキュメントが散らばらなくて今は良く機能していると思っています。

現状の課題感とアカデミーの開発に向く人

山田: 最後になりますが、アカデミーに来てほしい人材はどういった方でしょうか?

徳永: このプロダクトにわくわくできる方に来てほしいと思います。福祉業界に明るい方なんかは大歓迎です!

山田: なるほど。プロダクトのビジネス面の理解をして楽しんで開発できる方ですね。技術的な部分では何かありますか?

岸田: 今まで TypeScript と NestJS を中心に話していましたが、実はこれらができる人というのは必須条件ではありません。どの言語でもフレームワークでもちゃんと Web 開発が分かっている方であればという感じです。

他には情報感度が高い人が良いと思います。言語化が難しいのですが、開発環境や言語、ライブラリなどできちんと最新の情報が取捨選択できる方がいると、チームがより活性化すると考えています。

バックエンドでいうとベース部分などもきちんと手を入れることができて、なおかつ人に教えるのが好きな方が入ってもらえると、チームへの知識伝播などもより上手くいくと考えています。

あるとより良いなという所だと、現在アプリは React Native で作られているんですが、React Native でのアプリ開発に強い方だと嬉しいですね。ユーザーに一番使われているのはアプリなので、さらにそのユーザビリティなどを高めるためには、アプリ開発に強い方に入ってもらえるとありがたいです。

山田: よりアカデミーというプロダクトをドライブさせてくれる方にぜひ来てほしいところですね。本日はありがとうございました!

おわりに

メドレーの開発チームの中でも野心的なアーキテクチャで開発をしているアカデミーチームについてお伝えしました。

サービスを伸ばすために、適切に言語やフレームワークを選択していき、柔軟性を持って開発していってるんだなというのが伝わってきたインタビューでした。少しでも興味が出た方はぜひ、下のリンクからお話できればと思います!

S3 Object Lambda を使って処方箋プレビューに透かしを入れる

Fri, 28 Oct 2022 06:38:18 GMT

こんにちは。医療プラットフォーム本部プロダクト開発室エンジニアの中畑です。主にオンライン診療・服薬指導アプリ CLINICS の開発を担当しています。

今回は CLINICS アプリ内で扱う処方箋プレビューに透かし(watermark)を入れた話を紹介したいと思います。なぜ実施したのか、実装方法、パフォーマンスチューニングの 3 本立てでお送りしたいと思います。

課題と解決方針

まず、なぜ処方箋プレビューに透かしを入れることにしたのか。

CLINICS では診察後に患者が希望すると、かかりつけ薬局支援システム Pharms を導入している調剤薬局にてオンライン服薬指導を受けることができます。その際に医療機関から処方箋の画像ファイルや PDF をアップロードし、患者は CLINICS アプリを通じて、オンライン服薬指導を受けたい調剤薬局に処方箋データを送る必要があります。

患者はオンライン服薬指導を予約する前に医療機関からアップロードされた処方箋画像をプレビューできます。この処方箋プレビューは原本とは扱いが異なるため、患者がアプリ内でそれぞれを明確に区別できるような対応を入れる必要があり、その手段として処方箋プレビューに透かしを入れることにしたというのが理由となります。

実現・実装方法

まずは画像に透かしを入れる方法を考え、それからシステム上でどのタイミングで透かしを入れるか検討しました。前提条件ですが、処方箋プレビュー画像は以下のような形で保存されています。

フォーマット: JPEG, PNG, GIF, PDF(画像以外もある)
保存場所: S3

画像に透かしを入れる方法

透かしは技術的には 2 枚の画像をアルファブレンド¹を使って合成した画像となります。

アルファブレンドの実現方法は言語やライブラリによっていろいろありますが、今回は処方箋を扱うシステムが Go を利用しているので、Go の以下の標準ライブラリを使って実装しました。また、画像には向き(orientation)の情報が保持されているのですが、向きを意識しないと合成時におかしくなることがあります。端末やツールによって取り扱いが異なる部分が多いので、それを解消してくれる disintegration/imaging パッケージを利用しました。

image パッケージ: ベースライブラリ
ximage パッケージ: 描画処理
disintegration/imaging パッケージ: 読み込み時に向きを補正

詳細は省きますが、以下のようなコードで合成できます

func Watermark(srcFile string) {
	// 元画像
	imgb, _ := os.Open(srcFile)
	var img image.Image
	img, _ = imaging.Decode(imgb, imaging.AutoOrientation(true))
	defer imgb.Close()

	// 上に重ねる透かし画像
	wmb, _ := os.Open("watermark.png")
	watermark, _, _ := image.Decode(wmb)
	defer wmb.Close()

	// 透かしを配置する場所 (画像サイズによって異なるため、実際は計算が必要)
	watermarkRect := image.Rectangle{image.Point{100, 100}, image.Point{200, 300}}

	// 合成処理（ここではバイリニア補間で実施）
	b := img.Bounds()
	m := image.NewNRGBA(b)
	draw.Draw(m, b, img, image.ZP, draw.Src)
	draw.BiLinear.Scale(m, watermarkRect, watermark, watermark.Bounds(), draw.Over, nil)

	// 合成画像の出力（JPEG 出力。他のエンコーダーを利用すれば他の画像形式も可）
	imgw, _ := os.Create("/tmp/dest.jpg")
	jpeg.Encode(imgw, m, &jpeg.Options{Quality: jpeg.DefaultQuality})
	defer imgw.Close()
}

PDF に透かしを入れる方法

また、今回の要件には PDF ファイルにも透かしを入れる必要がありました。PDF にはレイヤーという概念があり、元の PDF に対して透かしを入れるレイヤーを追加すれば実現できます。Go には PDF を標準で扱えるパッケージがなかったので、今回は pdfcpu を利用しました。

透かしのレイヤーを追加する関数が用意されており、以下のコードだけで実現できて大変便利です。²

wm, _ := api.ImageWatermark("watermark.jpg", "sc:.8 rel, rot:0", onTop, update, pdfcpu.POINTS)
api.AddWatermarksFile("src.pdf", "dest.pdf", nil, wm, nil)

S3 画像に透かしを入れる方法

AWS を利用していると S3 に各種ファイルを保存することも多いと思います。基本的には S3 画像を読み込んで透かし処理をすれば実現できますが、AWS には S3 のレスポンスを加工するマネージメントサービスがいくつかあり、今回は S3 Object Lambda を利用しました。

S3 Object Lambda を利用することで S3 からファイルを取得する際に Lambda による処理を実行したうえで返却することができます。これを利用して、元の画像に Lambda で透かしを入れて返却することができます。

処方箋プレビューに透かしを入れる前の構成は以下のようなイメージです。

アプリサーバーにて処方箋プレビューの S3 presigned URL（署名付き URL）を発行
クライアントに返す
クライアントは受け取った URL にアクセス。処方箋プレビューが表示される

これに S3 Object Lambda を利用して透かしを入れると以下のようになります。

アプリサーバーにて処方箋プレビューの S3 Object Lambda Access Point の presigned URL（署名付き URL）を発行
クライアントは受け取った URL にアクセス
S3 Object Lambda Access Point は透かし処理を行う Lambda 関数を実行。その際に S3 Access Point の署名付き URL を発行し、リクエストパラメータに設定
Lambda Function は受け取った URL にアクセスし処方箋プレビューの元画像を取得して透かしを入れて返却
透かし入りの処方箋プレビューが表示される

新たに S3 Object Lambda Access Point, Lambda Function, S3 Access Point を用意する必要があって少しややこしいですが簡単に説明すると以下のような役割のものとなります。

icon	title	description
	S3 Access Point	S3 Bucket に対する alias。S3 Object Lambda は必ずこれを経由して S3 にアクセスする必要がある
	Lambda Function	S3 のファイルに対してなんらかの処理を実施する関数
	S3 Object Lambda Access Point	S3 Access Point に対して Lambda 関数を実行するためのアクセスポイント

透かし処理を実際呼び出す際は、アプリケーション側からは S3 の presigned URL から S3 Object Lambda Access Point の presigned URL に切り替えるだけなので、透かしありなしの切り替えも簡単です。

S3 presigned URL:

https://[bucket-name].s3.ap-northeast-1.amazonaws.com/prescription.jpg?[signature]

↓ S3 Object Lambda Access Point presigned URL:

https://[s3-object-lambda-access-point]-[account-id].s3-object-lambda.ap-northeast-1.amazonaws.com/prescription.jpg?[signature]

S3 Object Lambda を利用することで以下のようなメリットがあります。

追加のインフラ構築が不要
- 既存サーバーのリソース追加や、新たに透かし処理用のサーバーを用意する必要がない。既存のアプリサーバーへの影響を軽微にできる
- Lambda が自動的にスケールを実施してくれるので負荷対策が容易
- 利用した分だけの課金となる（S3 Get + Lambda + S3 Object Lambda の利用料）
透かしを入れた処方箋プレビュー画像を事前に用意する必要がない
- 事前に用意するとリリース前に保持した画像に対しても処理する必要が出てくる
- (ただし、今回は特定のユーザーのみのアクセスなので不特定多数のアクセスが見込まれる場合は事前生成したほうがよいかもしれません)

もちろん画像だけではなく、テキストデータなど他のものにも利用できるので、S3 に保管した機密情報等をフィルタリングして返したい用途などにもマッチします。

AWS 公式ドキュメントに詳細な解説と様々なユースケースのチュートリアルがありますので、興味がある方は是非御覧ください。

S3 Object Lambda を使用したオブジェクトの変換

パフォーマンス・チューニング

ここまでで、処方箋プレビューに透かしを入れる処理自体は完成しました。ここで気になってくるのがパフォーマンスについてです。今までは S3 の画像を表示するだけでしたが透かし処理に S3 Object Lambda を使うことになったため、速度と料金が気になるところです。

様々なチューニングポイントがありますが、今回は Lambda のメモリ設定に焦点を絞ってお話したいと思います。

Lambda の CPU パフォーマンス

Lambda はメモリ設定しかできませんが、メモリ量に比例して CPU 性能が向上する仕組みとなっています。公式ドキュメント上では 1769MB あたり 1vCPU であるとされていて、MAX の 10240MB で 6vCPU 使えるとしています。実際に Lambda の vCPU の設定を調べたブログ (SENTIA tech blog) では以下のようになっていたそうです。

Memory	vCPUs
128 - 3008 MB	2
3009 - 5307 MB	3
5308 - 7076 MB	4
7077 - 8845 MB	5
8846 - 10240 MB	6

ただし、メモリをいくら増やしたところで関数自体がマルチスレッド・マルチプロセス化されていない場合はパフォーマンス向上が見込めないということにもなります。適切に並列処理が実装されていれば、vCPU が増える境目で大きな性能向上が期待できます。

Lambda の料金

東京リージョン(ap-northeast-1)において、2022 年 10 月現在は以下のような料金となります。³

無料枠: 1 ヶ月あたり 100 万リクエスト、40 万 GB-秒(仮に 1 GB で動かしたとして 40 万秒使える)
- 128 MB だと 320 万秒、 10240 MB だと 4 万秒
有料枠: 100 万リクエストあたり 0.20 USD, GB-秒あたり 0.00001666667 USD
- 1 億リクエストあたり 20 USD
- 128MB で 1 万秒使うと 0.02083 USD
- 1024MB で 1 万秒使うと 0.16666 USD
上記は x86(amd64) の値段、arm だと 2 割引
- arm は CPU パフォーマンスも 2 割向上すると言われているので、可能であれば arm を選択すると更にコスパ向上が期待できる

このように見てみると、サーバーやコンテナを利用した場合はどんなに最小構成でも冗長化を考えると数十ドルはかかるので、特に頻繁に実行されない機能は Lambda によるサーバーレス化を検討すると良さそうです。

また、時間あたりで料金がかかるということは、API などネットワークアクセスで時間を使った場合も料金がかかることに注意が必要です。外部 API のパフォーマンスに依存してしまうので、なるべく Lambda は CPU を使った処理が支配的になるとコスパよく利用することができます。

ベンチマーク

Lambda のパフォーマンス計測には、AWS Lambda Power Tuning を利用しました。AWS Lambda Power Tuning は Step Functions と Lambda を使って Lambda の速度とコストを計測できるツールです。

Step Functions と Lambda をデプロイした上で、Step Functions の state machine に計測したい Lambda の ARN, memory 設定, 実行回数, payload を入力することでベンチマーク結果を取得できます。実行すると最終結果に URL が出力され、その URL をブラウザで表示することで、グラフで結果とスコアボードで結果が可視化されます。また 2 つの結果を比較して表示することもできますので改善後に比較することも容易です。⁴

AWS Lambda Power Tuning の導入

リポジトリのドキュメントに従い導入していきます。

今回は AWS Serverless Application Repository(SAR) を使って導入しました。AWS Serverless Application Repository(SAR) とはその名の通り、サーバーレスアプリケーションを管理するリポジトリですが、組織内に限らず公開することも可能で、他の人も再利用可能になっています。また、導入する際は公開ページの Deploy ボタンをポチるだけで自身の AWS アカウント上にデプロイされ、 CloudFormation の Stack として管理されます。削除も CloudFormation の Stack を削除するだけで実施できます。

AWS Lambda Power Tuning はこちらから自身のアカウントにデプロイできます。また、AWS や個人だけでなく Datadog や New Relic など他のパブリッシャーもサーバーレスアプリケーションを公開しているので、他にも使いたいものがないか探してみるとよいかもしれません。

AWS Lambda Power Tuning の実行

デプロイが完了すると、AWS Step Functions 上に state machine があるので、state machine にパラメータを入力することで計測ができます。リポジトリのドキュメントにいくつかやり方が記載されています。ここでは実行パラメータを定義した json ファイルを用意してスクリプトから実行する方法を紹介します。

まずは、AWS Lambda Power Tuning リポジトリを git clone し、scripts/sample-execution-input.json を編集します。

{
  "lambdaARN": "arn:aws:lambda:ap-northeast-1:123456789012:function:lambda-performance-tuning",
  "powerValues": [128, 256, 512, 832, 1024, 1536, 1769, 1770, 2048, 3008],
  "num": 100,
  "payload": {
    "body": "{\"id\": \"123\",\"name\":\"performance\"}",
    "path": "/api/performance",
    "httpMethod": "GET",
    "isBase64Encoded": false,
    "multiValueHeaders": { "Accept": ["application/json"] }
  },
  "parallelInvocation": false
}

入力値の詳細は以下の通りです。⁵

lambdaARN: Lambda Function の ARN
powerValues: 計測したい Lambda のメモリを指定
num: メモリごとの Lambda 実行回数
payload: Lambda Function にわたす Event JSON の内容
parallelInvocation: ベンチマークを並列実行する

次に、 scripts/execute.sh を実行すると、ベンチマークが開始され、最後に結果 URL が出力されます。デプロイ時の設定によって、CloudFormation の Stack Name が違う場合もありますので、必要に応じて書き換えてください。

$ sh ./scripts/execute.sh
-n Execution started...
-n .
:
-n .
SUCCEEDED
Execution output:
{"power":128,"cost":8.4E-9,"duration":3.6706666666666674,"stateMachine":{"executionCost":4.0E-4,"lambdaCost":1.0178708203125003E-4,"visualization":"https://lambda-power-tuning.show/#gAAAAQACQAMABAAG6QbqBgAIwAs=;NOxqQP9GmkDFII5AbxKBQLErfECGXW1AWDmGQNNNjkBpSo1ARf1nQA==;l08QMn1jtDJ9YzQz1pCSM5dPkDNjd9gzb9AbNPzmGzR9YzQ05vRTNA=="}}

計測方法は以上、簡単ですね 👌

AWS Lambda Power Tuning の結果確認

計測結果を確認します。関数によって傾向は異なりますが、ここでは 2 種類のパターンを紹介します。

DB や API アクセスなど外部処理が支配的なケース(Network-intensive)

Lambda 内の処理が外部処理で占めている場合は、以下のようなグラフになります。赤色の実行時間がどのメモリ設定でも 4ms 前後と大きな変化がなく、青色のコストだけが右肩上がりになっています。この場合は、Lambda の最低メモリである 128MB が最適ということになります。

CPU 実行時間が支配的なケース(CPU-intensive)

Lambda 内の処理が内部処理で占めている場合は、以下のようなグラフになります。透かし処理は画像合成処理に多くの CPU を利用するので、こちらのパターンとなりました。メモリが少ないと速度が出ておらず、メモリを増やすに連れて速度も改善しており、コストの増加も緩やかです。ただし、今回はプログラムがマルチスレッド・マルチプロセス対応はしていないため、コア数が増える 1770MB 以降は大きな速度改善は見られず、コストが上がる結果となっています。よって、このケースではコストだけを考えたら低メモリが有利ですが、速度も考えたら 1024MB ~ 1770MB あたりにすることを検討すると良さそうです。

まとめ

処方箋プレビューに透かしを入れることになった背景、実現方法を紹介いたしました。

透かし処理はアルファブレンド処理を実施することで実現でき、PDF については透かし用のレイヤーを重ねることで実現できます。
S3 Object Lambda を利用することで、追加のサーバー構築をすることなく、S3 のファイルに対してフィルタリングをかけることができます。
Lambda のパフォーマンス・チューニングについては、AWS Lambda Power Tuning を利用して可視化できます。外部 API などネットワーク依存(Network-intensive)ではなく、CPU 処理が中心(CPU-intensive)になると、コスパよく利用することができます。

S3 のファイルに対してなんらかの処理を実施したいと考えてる方は、一度 S3 Object Lambda の利用を検討してみてはいかがでしょうか？

また、Lambda のチューニングポイントは色々ありますが、AWS Summit Online で紹介された以下のセッションがおすすめなので、もっと深くチューニングしたい方は是非ご覧ください！

AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった〜

さいごに

メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。医療という分野においては、機微な情報を扱ったり診療という大事な業務を止めないよう、可用性、パフォーマンス、セキュリティともに高いサービスレベルを求められます。興味がある方は是非ご連絡ください。

元画像に直接文字や図形などを描画することももちろん可能ですが、透かしを画像データとしてデザイン、管理したいこともあり、今回はアルファブレンドを選択した。アルファブレンド - wikipedia ↩
pdfcpu API document: watermark example ↩
ただし最初の 60 億 GB 秒/月。昨今は円安なのでドル建てで利用しているインフラコストも上がっており、USD 表記だとコストが変わらないようにみえるので要注意。AWS Lambda 料金 ↩
この UI は AWS Lambda Power Tuning UI というツールで別途提供されており、 lambda-power-tuning.show ドメインでアクセスできるので、自前で用意する必要はない。URL は https://lambda-power-tuning.show/#AAEAAgADAAQ=;xKDwRUqaakU5+RtFcXLqRA==;UqkHOPJCBDjA6AM46DAEOA==;AAEAAgADAAQ=;aYP6RdyeeUUQKiVFuC76RA==;ZDoNOJy3DDiJrQs4zhENOA==;100;50 のような形式でデータが URL のパスパラメータにエンコードされている。 ↩
この他にも strategy など様々なパラメータがある: aws-lambda-power-tuning: README-INPUT-OUTPUT.md ↩

クラウド診療支援システム「CLINICS」の患者タッチポイントを強化する PRM プロジェクトはどう作り上げたのか

Fri, 30 Sep 2022 13:23:26 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。クラウド診療支援システム CLINICS が 8 月から大幅にアップデートして、より患者と医療機関が密接に繋がるようになりました。

今回のアップデートで中心になっている機能領域として PRM(Patient Relationship Management) というものがあります。この PRM が一体どういったものなのか、プロジェクトはどのように進んでいったのかを関係者にインタビューしていきました。

メドレーで大規模なプロジェクト開発をどのように行なっているかの一端をお見せできればと考えています!

インタビュイー紹介

宍戸さん

医療プラットフォーム第一本部プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の開発責任者。前職は株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2017 年メドレー入社。

酒井さん

医療プラットフォーム第一本部プロダクト開発室第二グループに所属。クラウド診療支援システム CLINICS の UI/UX 全般を担当。本プロジェクトのリード。前職は受託開発会社で様々なサイトやシステムのデザインに従事。2019 年メドレー入社。

田中さん

医療プラットフォーム CTO。医療プラットフォームの開発統括をしながら、自身は患者統合基盤の開発を担当。前職までは SIer や IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとして従事。2016 年メドレー入社。

来田さん

前職まではクリニックで精神科医として従事。CLINCS オンライン診療の立ち上げ時から関わる。現在は CLINICS のディレクションを中心として事業部と開発の架け橋となっている。

PRM とはどういうものなのか?

新居 : では今回中心となった PRM とはいったい何なのかというところから解説していただいて良いですか? 一般的にはそこまで知られてない言葉なのではないかと思うのですが…。

宍戸: 元々 CRM(Customer Relationship Management)というマーケティングなどの文脈の用語があります。これは「自社サービスや商品を使っている顧客」と「サービスや商品を提供している企業」との関係性を管理することを指しますが、それをもとに適切なアクションをおこなうことで最終的には利益向上を目指すものと考えられます。PRM は CRM と同様に医療機関と患者さんの関係性を管理することで必要なサービスを提供するためのもの、と考えています。

CLINICS で基幹システムである電子カルテなどではなく、オンライン診療・予約・問診など患者接点となる機能をターゲットにしてそれらを強化・改善していったのが、CLINICS の今回の PRM プロジェクトになります。

CLINICS 開発責任者宍戸さん

新居 : 確かに CRM は最近良く聞く言葉でしたが、PRM は患者と医療サービスを使う医療機関との関係を深めるためのものなんですね。

PRM プロジェクトの始まり

CLINICS に感じていた課題とは

新居 : このプロジェクトは半年ほどかけていると聞きましたが、「PRM をやっていこう」となったのが半年前からだったんでしょうか?

宍戸 : 元々 CLINICS はオンライン診療のシステムとして 2016 年からサービスを提供してきました。2018 年からは CLINICS カルテとして電子カルテシステムも提供を開始しましたが、そのタイミング以降はオンライン診療部分に関してはそこまで大きくアップデートはしてこなかったんです。

現在はクラウド診療支援システムとして販売していますが、これまでは電子カルテなど基幹部分の強化がメインになっていたからです。しかし、数年開発・運用してきた中で、本来医療機関の診察のメインである対面診療の予約については課題が積み残されていたり、昨今の状況から来るオンライン診療のニーズなどを始めとして、患者接点を強化していく必要があるということになり、今回取り組むことになりました。

酒井 : PRM というと本当にここ最近の潮流なのですが、CLINICS はもともと「患者とつながる」をコンセプトとしており、今回の機能強化などもこのコンセプトに基づき実施しています。その上で、患者とのタッチポイントで抜けていた部分や強化したほうが良い部分をより作り込んでいったという形です。

例えば、CLINICS は元々オンライン診療のシステムとして始まっており、対面診療予約に関して使いづらさを感じるケースがあったため、対面診療予約をより行いやすくするよう改修を行うなどです。

CLINICS デザイナー酒井さん

新居 : 元々あったものをさらに患者とのタッチポイントを強化するために、改修・改善していったんですね。

プロジェクトの背景

どのくらいの規模のプロジェクトだったのか

新居 : 半年のプロジェクトということですが、規模としてはどの位の大きさだったんでしょうか?

酒井 : 私が経験したプロジェクトの中でも関わる部署など考えると一番大きかったと思います。開発はもちろんですが、CLINICS チームのセールス・カスタマーサクセス・マーケティング、広報もなのでほぼ CLINICS の全部署と関わっていました。

田中 : 他にも、サービスとしては患者統合基盤・患者向けアプリ・ Dentis が関係しています。

宍戸 : QA チームにもしっかり入ってもらって QA を行なったりしてもらったので、本当に医療プラットフォームのほぼ全てのチームと関わって開発していった感じです。最終的にプロダクトの見せ方や売り方なども含めて調整していったので事業部とも密接に関わって作り上げていきました。

新しい PRM 機能をどうやって、プロダクトに融合させたのか

新居 : そこまで大きい規模のプロジェクトだということで、PRM の各種機能をどうやって上手くプロダクトに落としこむのか、実際にはどのようにみなさん推進されていったんでしょう。

宍戸 : プロジェクトの推進という意味では、最初は来田さんや( Dentis の運営を行なっている)プロダクト戦略室の平山さんとスモールスタートで意見を出し合いながらモックを作っていき、まずはビジュアル面から機能のイメージなどを刷り合わせていくのに、酒井さんに手を動かしてもらいながら進めていました。

その過程でこのプロジェクトにおける重要な意思決定がありました。CLINICS ではログイン不要のシンプルな予約機能を以前より提供していました。この機能は患者アプリとは元々違うドメインで運営していたものでしたが、今回のタイミングでこの両者のアプリケーションを患者アプリと同じドメインに統合して運営していこうという決定をしました。

患者アプリは CLINICS チームとは別チームで運営しているという背景もあり、チーム間の連携が格段に増え、考えなければいけない事柄も多くなります。プロジェクトとして関係者が多くなってきたので、今までの考え方を 1 度リセットしてプロジェクトの進め方を新しく模索する必要がありました。

この点がかなり自分の中では大変でした。来田さんも大変だったと思います。こうした全体像を描いたり、全体スケジュールを決めたりというところでは、田中さんにアドバイスをもらいながらプロジェクトを進めていきました。

プロジェクトを推進するために必要だったこと

難しい意思決定をどのようにしていた?

新居 : 途中から一気にプロジェクトがスケールアップしたということなんですね。今回のプロジェクトは色々な部署も関わるし、たくさんの機能や改修が入っています。開発側と事業部側との意識合わせが、かなり必要だったんではないかと思うのですが、その辺はいかがだったでしょうか。

来田 : 例えば、今まで CLINICS では対面診療予約の際に患者のクレジットカード登録を必須としていたのですが、今回の改修でクレジットカード登録を不要に変更できるように対応を行いました。この対応は、CLINICS オンライン診療の初期から念願の機能だったりします。自分は事業部長である田中大介さんと今年の年明けくらいから話をして、メンバーに「よし、このプロジェクトをやっていこう」という話を持っていくようにしていました。やっぱり、大変なプロジェクトだというのはあったのでスタートを切れる状態に徐々にしていった感じです。

プロジェクトが佳境に入ってからは自分は各部署との調整がメインの業務でした。開発側と事業側とか CLINICS と Dentis だとかそういった立場の違いから来る要求の違いを納得できる仕様に落とし込む作業です。やっぱり、それぞれの立場でベストを尽くそうとみんな考えているんですが、全部を取り入れることはできないので。私が調整するときにはそれぞれ反対の立場の人たちの考えをきちんと伝えるようにということをしながら、仕様を決めていくことを念頭に置いていました。

具体的な調整の例としては、開発する機能とセールスする際のプランの刷り合わせだったりですね。「機能としてはこうしたほうが使いやすいよね」というだけだと、セールス側としては「どこをウリにして売っていくのかというのが見えてこない」という話になったんですね。これはどちらの言い分も一理あるものなんですが、こういうところを時間をかけて双方納得行くように決めていきました。

CLINICS ディレクター・医師来田さん

酒井 : この例でやったことは、まず現在のプランと機能を全部書き出して、組み合わせを整理するということでした。これをベースにして話を刷り合わせていったんですが、文字ベースだと人間分かった気になるんですが、実はそこまでピンと来ない。ですので、LP のモックを作ってこれを見た顧客が導入したくなるようなウリになっているのかをすぐに判断できる状態にしました。

宍戸 : こうしてちゃんと機能を解いていって細かい部分も含めて、時には CLINICS のコンセプトに立ち返って事業部・開発双方で時間をかけて認識を合わせることができたのは、大変でしたが良かったですね。

リリースまでのプロセスで顧客の声を反映

新居 : やはりここまでのプロジェクトだと最初の段階でちゃんとリリースまでを見据えた意識合わせをチーム内で行なっていたんですね。開発が進行していって、リリースするまではどのようにプロジェクトは進んでいったんでしょう。

宍戸 : リリースをする直前も、単純に仕様や機能について文書で説明しても理解するのは難しいので、酒井さんにディレクションをしてもらいながら、開発環境を使って QA チームやカスタマーサポートチームと一緒に認識合わせやリリースに向けた準備を行なっていきました。

来田 : あとは関係が構築できている顧客に実際機能を見てもらって反応を伺うということもしていきました。色々な使い方をしている顧客 10 件くらいにモックをベースにヒアリングをかけていきました。価格や導入時期なども含めた話を聞いていって、そこをすぐにプロジェクトにフィードバックする体制を構築していました。

酒井 : 実際に顧客の声をこうして聞けるというのは本当にプロダクトにとってありがたいことでした。特にこういう使い勝手などに直接関わる部分では、こうしたフィードバックの有無で完成度が違ってきます。機能の正式リリース前から機能評価に協力していただける医療機関がいるのは、カスタマーサポートの皆さんが顧客と良好な関係を築けているおかげだと思っています。こういった点はメドレーの強みだと思います。

プロジェクトで大切にしたこと

新居 : 開発段階からユーザーの声を吸い上げていけるのは、本当に良いですね。プロダクトの改善スピードなんかも段違いに早くなりそうです。他に大切にしていた部分などありますか?

酒井 : 今回の機能開発においては、プロジェクトの責任者として、開発以外のメンバーともしっかりコミュニケーションし合意形成を図ることを意識してプロジェクトを推進しました。

先ほどの話にも出ましたが 1 つの機能を実装するとなっても、実際の医療現場での使い勝手や、メドレーでのサポート、売り方など色々な視点で考えないといけないプロジェクトでした。そのため、そういったところをカスタマーサクセスのメンバー含む 10 人ほどと毎週 1 つ 1 つ納得がいくように詰めていくという作業をしていったりしました。来田さんのように現役の医師の意見、顧客の意見なども取り入れられますし、カスタマーサポートには医療事務経験者の方もいらっしゃるので、多方面の視点を総合的に取り入れられるコミュニケーションを心がけていました。

手段はテキストや Figma でのデザイン、実際の実装を見せるなど適切な手段を選んでコミュニケーションコストを低くするようにして進行していました。実際の機能実装にあたってはエンジニアも自身で考えて細かいボールを拾ったりしながら、実装していってもらいました。この辺りはこのプロジェクトだからというよりも、メドレーの開発のベースになっている部分なので良いですよね。

メンバーのイメージ合わせがプロジェクト成功の鍵

新居 : 先ほどもお話がありましたが、プロジェクト途中の意思決定で関わるプロダクトが多くなったのでスイッチングが大変だったということでしたが、実際にそのタイミングになったときに全体のシステム設計なんかも変わったりしたんでしょうか。

田中 : 私はプロジェクトの途中から入ったんですが、そのタイミングで、宍戸さんや来田さんがちょうどシステム設計を考え直していたり、プロジェクト計画の引き直しをしているところでした。そこでまずは全体像を把握したいと考えてドキュメントなどを見せてもらったんです。各機能の細かい要件は分かったのですが、このプロジェクト全体としての各システムの責務や依存関係などがいまいち分かりづらく、メンバー間の認識も若干ズレが発生しているように感じました。なのでまずは**メンバーの認識を合わせ、各チームが何をするべきかを明確化するために、各システムの責務など全体感の整理整頓をして「見える化」**することから始めました。

このプロジェクトに限らずですが、プロジェクトとして抽象度の高い段階でのドキュメントは、文章のみの記載だと実は関係者にしっかりと伝わっていなかったということが多々あります。各自が頭の中でイメージした図に差異が発生している状態です。自分はそういう際に良く言っているのが**「大枠で良いので、まずは整理結果を図にしてみんなのイメージを合わせる**」ということです。こうして認識を合わせることで各チームが進めやすくなり後戻りリスクも軽減されるので、この段階でしっかりとイメージをすりあわせる事がとても重要だと考えています。

医療プラットフォーム CTO 田中さん

新居 : たしかにテキストで仕様なんかを書きながら説明しても、実は認識に齟齬があった…という経験があります。その後はどのようなプロセスでプロジェクト推進したんですか?

田中 : その後は各プロダクトにて実装予定の機能で、プロダクト間で共通化できそうな機能を共通サービスとして切り出すかどうかをみんなと考えていきました。結果として大きな機能では「ビデオ通話」部分を共通化するという意思決定をしました。他にも「問診票の提供」機能が候補としてあがっていましたが、共通化せずに各プロダクトの責務としてそれぞれ実装するという結論となりました。同じような機能に見えても、医科と歯科という業務ドメイン毎のコンテキスト差異を十分に検討した上での判断でした。その差異がプロダクト機能としての強みとなり、安易な共通化はプロダクト成長の足枷となるリスクも存在するためです。この判断も先ほどの全体の依存関係などが整理されたからこそ、意思決定できるものでした。

酒井 : 機能実装時に実感しましたが、やはり医科と歯科では細かい部分の要件などが異なる部分が多かったので、この段階で共通化の判断ができたのは大変助かりました。

PRM プロジェクトの大きな成果

新居 : 最後になりますが、このプロジェクトが終わっての成果はどのように考えていますか?

宍戸 : 冒頭に話した CLINICS の課題に関してはある程度、解決ができたと思います。医療機関の業務に沿った形でプロダクトが進化できた点はよかったと思います。特に問診周りなどは発熱外来などニーズの多様化に即して使い勝手が良くなったと思っています。

酒井 : 他にもビデオ通話部分など「オンライン診療」を提供するプロダクトとして「対面診療」だけではなく、もっと有用なプロダクトにできたかと思っています。

来田 : まだリリースしたばかりですが、初月の販売実績も期待していたよりも良く、そうした意味でもマーケットフィットした機能を出せたなという手応えが実感としてもありますね。

田中 : 予約やオンライン診療もドメインを統一した結果、会員登録数が増えていますので、そうした点も成果と言えます。

酒井 : あとは直接の成果というわけではないのですが、今回のプロジェクトの副産物として

CLINICS の機能を整理整頓していった結果、改めて「一気通貫で医療機関の業務をサポートできる」というトータルでの機能提供と各機能のシームレスな連携は CLINICS の強みだ、というのが再確認できたのは大きいです。

新居 : これからのさらなる CLINICS の発展に期待できますね!本日は長い時間お話ありがとうございました!

おわりに

メドレーとしてもかなり大規模なプロジェクトだった今回の PRM プロジェクトでしたが、みなさんのお話を聞いて各部署・各プロダクトで綿密に連携しながらプロジェクトを成功させようとしている様子が感じられるインタビューでした。

特にプロジェクト進行の話は非常に参考になりました。皆さんのご参考になる部分があれば幸いです。

こうしたプロジェクトで自分の力を発揮したい!と思った方はぜひお気軽に下記からご応募ください。

22 年度新卒研修に取り入れた QA 講座について QA エンジニアに語ってもらいました

Wed, 31 Aug 2022 13:35:42 GMT

はじめに

みなさん、こんにちは。エンジニアの山田です。

今年も新卒入社で 6 人のメンバーがエンジニアとして入社しており、現在も絶賛新卒研修中となっています。毎年、新卒研修はプロセスやコンテンツを見直しているのですが、今年度は初めて Quality Assurance(以下 QA)についての講座を取り入れるようにしました。

今回は講師をお願いした QA エンジニアお二人にどのようなことを念頭に講義を実施したのかをインタビューしてみました。

今年から QA 講座を新卒研修のカリキュラムとして取り入れた理由について

インタビュー本編をお届けする前に、今回 QA 講座を新卒研修に取り入れた理由について研修企画担当の 1 人としてご説明します。

QA 講座を新卒研修のカリキュラムに取り入れたいと思ったきっかけは、昨年の「開発実践研修」でアプリケーション開発の一環としてテスト設計も含めて実施していましたが、メンターとしてレビューをしている際「せっかくメドレーには QA のスペシャリストがいるんだから、今回のレビューにも加わってもらえば良かった…」と感じたことでした。

今年はメンターではなく、新卒研修の企画・運営を主に担当することになり、昨年よりもさらに研修の質を上げるためにはどうするかを考えた時、上記のきっかけもあり QA エンジニアの皆さんには「開発実践研修」のテスト設計レビューを含め、座学による講義もお願いしたいと思うようになりました。

講義をお願いしたいと思った理由として大きく 3 つあります。

1. QA の経験不足を補う

全体的な傾向として弊社の新卒エンジニアは、インターンや学校の活動などで開発経験は相応にあるのですが、テスト設計をはじめとする QA を特に力を入れてやった経験が浅いという事実があります。その上でこれから先メドレーでプロダクト開発をする上では、テストや QA などについて自走して考え実施することができるようにしたかったため。

2. QA に対する認識を揃え、意識を高める

「QA とは何ぞや?」という話を専門性を持った QA エンジニアから新卒エンジニアに伝えてもらいプロダクトの QA に対して意識を高めてもらいたかったため。

3. 社内勉強会の内容がとても為になると感じた

弊社では、TechLunch という社内勉強会を開催していますが、その中で今回インタビューした QA エンジニアお二人の発表内容が大変良かったので、その内容をぜひ新卒エンジニアにも伝えてほしいと感じたため。

このような理由により、今年度からは QA 講座を研修の一部として開くことになりました。

さて、前置きが長くなりましたがそんな QA 講座を担当してくださった QA エンジニアのお二人へのインタビューをご覧ください。

インタビュイー紹介

上村さん

医療プラットフォーム第一本部プロダクト開発室第一開発グループに所属。クラウド診療支援システム CLINICS の医療機関側システム（カルテ、オンライン診療など）の品質向上活動を担当。

米山さん

医療プラットフォーム第一本部プロダクト開発室第一開発グループに所属。オンライン診療・服薬指導アプリ CLINICS のアプリ・ Web ・基盤を扱う開発チームで QA プロセス全般を担当。

左から上村さん・米山さん・筆者

QA 講座を担当した QA エンジニアのインタビュー

チームの雰囲気

山田: 早速ですが、お二人とも医療プラットフォームで QA を担当されていますが、所属しているチームの雰囲気はどんな感じなんでしょうか?

上村: チームというよりもメドレーのエンジニア・デザイナーの皆さんに共通している話かもしれませんが、セルフマネジメントできている方がとても多いと感じます。そういった方達なので視野を広く持っていて、開発の時にメンバー間で落ちそうなボールを自分でさっと拾って担当したりを自然にやっていますね。後は CLINICS の特に電子カルテは開発に必要なドメイン知識が広範囲で、私も入社して 2 年強経ちますが、未だに分かっていない部分などが出てくることもあり、そんな時でも気軽に周囲のメンバーに聞ける雰囲気なのが良いです。

山田: 現在は QA エンジニアとして、仕様策定のフェイズから関わっていることが多いんでしょうか?

上村: 関わり方はプロジェクトや時期により違っています。メインで担当するプロジェクトは最初から入って仕様レビューから関わる場合もありますし、複数のプロジェクトが平行している時は要所でアドバイス的な形を取る場合もあります。現在は開発中の大きいプロジェクトでの活動に振り切っているフェイズになっているところです。

山田: 米山さんのチームの雰囲気などはいかがですか?

米山: 上村さんとは違うチームに所属していますが、似た印象を持っています。一言で言うと「大人が集まっている」チームだと思います。ミーティングなどでも本質を捉えた議論が多く、皆さん人格者で仕事ができる方々だと感じています。今所属してるのが患者さんが使うアプリの開発チームで、Android / iOS / Web と 3 プラットフォームのプロダクト開発をしているのですが、1 人のエンジニアが 3 プラットフォーム全てを実装したりするのはこのチームの特徴の一つかもしれません。他社さんと比較すると珍しい体制ではないかと思います。

山田: なるほど。リソース効率を考えた結果のチーム運営なんですね。

研修のオファーの打診がされた時に考えたこと

山田: 今回お二人に QA 講座の担当をオファーさせていただいた訳ですが、オファーを受けた時にどのような思いでしたか?

上村: 「ついにこの時が来たか…!」と思いました w

山田: QA の啓蒙をされている上村さんとしては、やはり講師のオファーを待ち望んでいたわけなんですね。

上村: はい、私が入社したのが一昨年の 4 月だったので当時の新卒研修カリキュラムはもう決まっていたと思うのですが、もしその時にオファーが突然あっても大丈夫でした。去年はオファーが無かったので「まだ早いのかな」と少し残念だったのですが、今年オファーがあって良かったです。

米山: メドレーは元々プロダクト品質に対する意識が高いと感じているので、お話をもらった時に違和感はなかったです。こういった意識の高さは、経験豊富なメンバー達が作ってきた開発文化が社内に浸透しているからだと思います。ですので、入社時にこうした研修を通して目線を合わせるという意味で良い取り組みだと考えています。

QA 研修コンテンツの準備

山田: 今回の研修コンテンツを作る上で、工夫されていた点や意識されたポイントなどは、どのようなものがありましたか?

上村: 準備段階で私のほうで素案を作ってから、直属の上司で研修の責任者でもある田中(医療 PF CTO)に相談したところ、「品質というのがプロダクトに取ってどれだけ重要なのかを教えてほしい」というオーダーを頂きました。

その後に米山さんと、どのように講義を分けるかを話し合い、私は QA の重要性や **QA とは?**をテーマにテスト技法の演習を通して、まずは「品質」という観点がいかにプロダクトを作る上で大事なのかという大枠を話すことになりました。一方で米山さんはより実務に即した観点から、メドレーでの具体的な取り組みや自動テスト、開発プロセスとの関わり方などを話すことになりました。

こんな形で役割分担はスムーズに決まりましたので、まずは研修目的を新卒のスキルレベルから考えて設定しました。研修全体では田中から「メドレーのエンジニアに求めること」の講座があり、内容としてはマインドセットなど抽象度が高めの内容になります。その後に具体的な「開発基礎研修」が続くので、ちょうどその中間的な抽象度になるように今回の講座は作るように意識しました。

私が考えるカリキュラムで大事にしているのは、講義中にも手を動かしたり、自分でも考えてもらいながら参加してもらう所なので、そこも意識しています。

山田: ちょうど良い抽象度で QA の重要性を全般的に分かるようにまとめていったんですね。米山さんは、どんな点が挙げられますか?

米山: 来年以降でも使えるようなコンテンツにしたいと考えていました。前職でも非 QA エンジニア向けの研修があったのですが、講義の感想で「もっと現場での実際の話なども聞いてみたかった」というような意見があるのを見ていたので、私のコンテンツでは抽象度が高い話だけではなく、実際のプロジェクトでの事例なども盛り込むようにしました。

また、 テスト自動化 なども人によって考え方も様々だったりするので、テストピラミッドの話なども含めて現実的な考え方や活用方法などを講座には入れています。

QA 研修講座について紹介

山田: そのように工夫をして作っていただいた講座ですが、それぞれどのような内容だったのか教えていただけますか?

上村: 一般的に知られる障害の事例として例えば「チャレンジャー号爆発事故」などを挙げて、まず**「品質」がプロダクトに与える影響について知ってもらう**ようにしました。事業ドメインなどが違う事例をいくつか挙げています。

後半では、具体的にどのように「品質を上げること」ができるかという部分にスポットを当てて紹介をしています。

上村の発表スライド

米山: 私は具体的なメドレーでの品質向上のためにやっている取り組み（ Magic Pod 導入の話など）や、品質とテストに対する考え方などをお話しました。またメドレーのメンバーの良い取り組み事例としてホットフィックスでも、きちんとテストコードを追加してリリースしている部分などを、どう考えてこの対応をしたのだろうかというような事も講義内容に入れています。

講座についての手応え

山田: お話を聞いていると、すごくバランスが取れた講座に仕上がってる印象を持ちました。講義をした手応えとしては、どんなものがありましたか?

米山: 今回の講義はオンライン形式だったこともあり、少し一方通行で終わってしまったかもしれないなと思いました。もう少しカジュアルに質疑応答も含めてインタラクティブに新卒メンバーと交流できたら、もっと良かったかなと思います。(編注: 今年はコロナ対策として、オンラインで研修を行ないました)

上村: 途中少し問いかけのタイミングなどもつくったんですけどもね。

山田: 研修の時期的に新卒メンバーの緊張なんかもあったんでしょうね。話は変わりますが、今回 1 講座をお二人に担当していただきましたが、新卒研修全体へのお二人の印象などはどんなものでしょうか?

上村: 羨ましいなと思っちゃいますね w 自分が IT 業界で働き始めた時は特に「即 OJT」という感じでしたので、コンテンツがとても充実していて、実業務に入る時にハードルが低くなると思います。

米山: 規模がとても大きい企業で充実した研修というのは分かるのですが、現在のメドレーの規模でここまで充実した研修をしているのは凄いなと感じます。去年までに入社した新卒メンバーも配属後にすごく活躍しているのを見ているので、充実した研修が活きているのではないでしょうか。

自分が QA エンジニアのキャリアを始めた時にも、複数の研修を受けたのですが、今でもちゃんと記憶に残っている研修というのがあるので、講師側としてはそういった研修にできるようにしていきたいですね。

来年に向けて

山田: これからの話もちょうど出てきたところなので、来年の QA 講座はどのようにバージョンアップしていきたいというアイディアはありますか?

上村: 今回のように 90 分も良いのですが、できれば 1 日ワークショップをやってみたいなと考えていました。それだけ時間があれば他にもやりたいことが盛り込めるなと思います。それだけの時間が確保できるかが課題なのですが…。あとは来年はできれば対面で実施できれば良いなと思います。

米山: 新卒メンバーは私達の研修の後に「開発実践研修」で実際にプロダクトを作るフェイズがあるので、来年はその開発実践研修の内容とリンクさせて、すぐに活用できるような実践的な話もできたらと考えています。

上村: 確かに何かアプリを触ってもらって、テスト観点はどういったものがあるかなんかを考えてもらうなども良いですね。

具体的なテスト技法とか考え方なんかは検索すれば出てくるものですが、実際にそれらをどう使うか、いつ使うかという点が難しいところなので、きちんと伝えていきたいです。

米山: あとは中長期的な目標としては、こうした研修をしていくことによって社内で QA エンジニアを志望する方が出てくるような講座ができれば良いなという願望があります w

山田: なるほど、社内スカウトができるように充実した研修にするということですね w

本日はありがとうございました。

おわりに

今年初めての試みである QA 新卒講座をどのように作っていったのかを、お送りしました。

メドレーでは QA エンジニアだけが品質に責任を持つというわけではなく、開発に携わる全員が責任を持っていくというスタイルでプロダクト開発をしているため、そうした姿勢を新卒メンバーに伝える上でも今回の講座はとても有用だったと考えています。

このような開発スタイルで日々プロダクトを作っているメンバーに興味が出て話を聞きたい! という方はぜひカジュアルにお話できればと思います。

21 年新卒入社エンジニアと座談会で振り返る新卒研修

Fri, 22 Jul 2022 12:48:13 GMT

はじめに

みなさん、こんにちは。エンジニアの新居です。

今回は 2021 年新卒入社のエンジニア 5 人に対し、新卒研修を終えてからこれまでにプロダクト開発業務を進めている中で、どのように新卒研修が活きているのかを振り返ってもらおうという座談会の様子をお送りしようと思います。

今までブログでお伝えしてきた新卒研修はメンター側の立場で書かれていましたが、当時メンティーだった 2021 年新卒メンバーの紹介をしながら、初めての試みとしてメンティー側はどのようなことを当時考えていたのかをお伝えできればと思います。

2021 年新卒入社メンバー紹介

(左から)筆者 / 内田さん / 高橋さん / 堀内さん / 佐々岡さん / 寺内さん

高橋さん

医療プラットフォーム第一本部プロダクト開発室第二開発グループ所属。CLINICS の開発を担当。現在は周辺領域拡張プロジェクトに携わる。

佐々岡さん

人材プラットフォーム本部プロダクト開発室第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。

寺内さん

人材プラットフォーム本部プロダクト開発室第三開発グループ所属。介護のほんねの開発を担当。定常開発や新機能開発に携わる。

堀内さん

内田さん

医療プラットフォーム第一本部プロダクト開発室第四開発グループ所属。CLINICS の開発を担当。現在は CLINICS カルテの基幹システムの開発に携わる。

チームの雰囲気について

メドレー入社後 1 年が経ち、5 人の皆さんはどのような雰囲気のチームで働いているかを話してもらいました。

高橋: CLINICS の中でもうちのチームは出社頻度が高めで対面でコミュニケーションを取る機会が多いですね。新規機能を中心に開発しているので、細かな調整がしやすくスピード感を持って開発できています。

内田: 自分は別のチームなんですが、夕会をスタンディングでやっているのを見てカッコいいなと思っていて羨しいです w

佐々岡: ジョブメドレーチームの雰囲気としては結構リモートで開発している方の割合が多めです。家庭持ちの方とかは家で実装していたりすることが多いです。デザイナーとエンジニアはすごく近い距離で仕事をしています。その中で自分は、主に求職者の応募体験を良くするための改善などを行なっています。

寺内: 介護のほんねは、プロダクト開発チームがコンパクトなので他のみんなと違い明確に担当が分かれているということはないです。自分は社内ツールの業務改善系の開発を担当することが多いです。

社内ツールの非効率な部分を改善したり、定常業務で必要になるシステム改善や修正を主に手がけています。サーバーサイドの開発が主で、必要に応じてフロントエンドの開発も行なっています。チームの雰囲気は、締めるところは締める雰囲気です。MTG なども少なめなので、実装や考えることに時間を使っていける環境です。

佐々岡: 寺内はチームのプロダクト責任者が直接メンタリングしてくれるのが良いなーと思っています。

寺内: そうですね。直属の上司にレビューを含め、メンタリングなどもしていただいているので、ありがたいです。

堀内: 自分も佐々岡と一緒でジョブメドレーの開発を担当しています。自分が思うチームの雰囲気ですが、「温和なチーム」と感じています。心理的安全性が高いチームですね。

自分が今担当しているのは求職者側の UI/UX 改善であったり、ページのパフォーマンス改善などです。開発の特徴としては、開発案件を進めるときにすぐにプロダクトマネージャやリードエンジニアといった方々と会話して進めていける部分でしょうか。

ジョブメドレー自体、サービスとしては 10 年選手です。ですから、業務フローが大変成熟したものになっています。 洗練された企画・開発フローを実際に体感しながら開発できる、という環境がとても勉強になりますね。

またこのフローはドキュメントドリブンという考え方で作られた資料に基いていますので、後から蓄積された知見をキャッチアップすることも容易ですし、リモートの人と出社している人との間で齟齬が起きることなく仕事が進められています。

内田: CLINICS 電子カルテの基盤チームで開発しています。基盤チームでは本当にこれぞカルテという部分を扱っているので、レセプトに関係する部分なども担当しています。

チームの特徴としては、チーム構成としてデザイナーやディレクターといった職種の方達がいるんですが、彼らと一緒に会話をしながら、開発を進めていくということでしょうか。

職種で分けずに全員で認識を揃えながらの開発ができています。あとはメドレーのデザイナーは多かれ少なかれ全員そうだと思うのですが、特に今のチームのデザイナーは自分でフロントエンドの React.js のコードを書いているので、手戻りなども無くすごく仕事がやりやすい環境です。こうした環境で自分が要件から考えて実装していくという開発をできているのが、とてもやりがいがあります。

それぞれ配属されているチームが違うこともあり、チームの雰囲気などはやはり色々と違うようです。しかし、共通してチームで動きながら職種に囚われずに要件定義から関わって開発をしているというところは、全員が感じているようですね。

今までのプログラミング経験

次の話題として、21 年入社メンバーの入社前のプログラミング経験について聞いてみました。みなさんどんな形でプログラミングに関わってきたんでしょうか?

高橋: プログラミングを始めたのは高校 1 年生の頃からです。中学生のころからコンピュータに触れはじめて漠然とプログラミングの勉強がしたいという思いから、情報系学科に入学してゲームプログラミングから始めたのが最初です。

大学時代は、実践型のプロジェクト学習に力を入れている公立はこだて未来大学で様々な開発経験を積みました。学部 3 年生の 1 年間は、4 大学合同でチーム開発をするという講義の中で iOS アプリケーションの開発を経験しました。

学部 4 年生からは、都内にある SIer 企業の社内システムを開発する学内プロジェクトに参加しました。他にもエンジニアとして働けるサマーインターンにも参加しました。

内田: 自分達と同世代だと中学生のときくらいに、例えば PSP を始めとしたゲーム機だとか、家のパソコンを触っていくことをきっかけにして、プログラミングに興味を持つという人が多い印象です。この 5 人の共通の思い出として、やっぱりこの辺の話題が出てきたりします。

佐々岡: 自分がプログラミングを始めたのは、情報系の大学に入ってからでした。始めてからは Ruby on Rails での開発や Python の Django での開発をアルバイトで経験を積んでいきました。サークルでも PHP を使った Web アプリケーションを作ったりと、のめり込んでいました。

堀内: 自分は大学では情報系学科ではなく、経済学部を専攻しました。高校のときは理系コースで「理系の大学に行くんだ」と頑張っていたんですが、どちらかというと文系科目の方が好きだったので、数学の知識も使いつつ文系である経済学を選んだ形です。

プログラミングの原体験は Web になります。もうサービスは無くなってしまったんですが、中学生のときに Yahoo!ジオシティーズというホームページを簡単に作れるというサービスに夢中になった時期がありました。

このサービスはエディタにテキストを入れると HTML が生成されるというシステムだったんで、そこでこういった感じで Web が出来るんだなと思い面白いなと思ったのがきっかけです。そこから色を変えたいから CSS を勉強する、クジ引きアプリ作りたいから JavaScript を勉強するみたいな感じで、のめり込んでいきました。

中高くらいにスマホが出てきたんですが、当時カスタムされた OS が流通していて、そういうのも面白いと触っていました。同時期にブログを運営していたのでその時に PHP での開発をしていきました。一通り Web プログラミングが出来るようになってからは、個人事業主として開発や保守を受託することが多く、その時のお仕事で、フロント / バックエンド / インフラ満遍なく貴重な経験をさせて頂けたと思います。

内田: 僕は小学校 3~4 年生くらいに最初にプログラミングに触れました。当時、宇宙がすごく好きでちょうど JAXA が小学生向けのプロジェクトやっていてそれがロボットの開発をするというものだったんです。そのロボットの制御をするためにプログラミングが必要になって触り始めたのが最初です。

中学生で Web プログラミングに触れまして。ちょうど YouTube が盛り上るくらいのタイミングだったんで、今でいう YouTuber っぽい活動していてその宣伝のためのホームページを作るためにサイトを作ったりしていました。

でも、そこからはあんまりプログラミングに触れていなくて、大学 2 年生くらいになって部活でアプリ開発をやり始めて、それがスケールアップして起業もしました。

その会社は儲からなくて閉じたんですが、そこからある程度プログラミング経験が積めたなと思ったので、医療系を含む、色々な企業でインターンとしてプログラミングをしていました。そこからメドレーに入社しました。

寺内: 僕も佐々岡と一緒で大学に入ってからでした。高校のときは遺伝子に興味があったんですが、Web 広告でプログラマーについて知ってこっちの方がより面白そうだと思って情報系学科に入ることにしました。

サークルで知りあった人にインターンをおすすめされたので、1 年生の後半あたりからずっとインターンとしてプログラミングをしていました。その中にメドレーもありました。

話を聞くと皆さん大分早い段階からプログラミングに興味を持ち出していますね。大学でインターンを有効活用してスキルアップしてきた人も多いです。最近あまり言わないですが、デジタルネイティブという印象です。

メドレーに入社を決めた理由

そうした経験を積んできた 5 人はどんな理由でメドレーの入社を決めたのかが気になるので、聞いてみました。

高橋: 就活の軸として、社会的な課題を解決するプロダクトの開発に携わりたいという思いがありました。

この軸は、大学時代までに個人開発やプロジェクトを通して開発してきた成果物が、思うような価値を生み出せなかったという悔しさが原体験としてあったためです。そこから課題解決が好きだったこともあり、エンジニアリングを通して大きな社会課題を解決したいという考えを持つようになりました。

最終的には、インターンシップや就活を通して社員の方々から話を伺った中で「医療ヘルスケアの未来をつくる」というメドレーのミッションに強く惹かれ入社を決めました。

佐々岡: 生活のインフラに直結する分野の社会課題を解決するという所が良かったので、メドレーに入社しました。もう一つの理由としてはメドレーの「ドキュメントドリブン」という文化に心惹かれたからです。

色々社内の知見などをきちんとドキュメント化しているので、そういったドキュメントを参考にしていれば、自分の成長スピードも早くなるのではと思いました。

内田: 他の人と同じで、医療という大きいドメインでの課題解決をしているという点はもちろんなんですが、働いているエンジニアの方々が少数精鋭でレベルが高いなと感じたのも大きいです。

そんな中で、新卒入社のエンジニアの人数もそこまで多くはないので、入社したらそんな方達と一緒に仕事ができるようになるなと感じたからです。

堀内: 就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。将来的には経営をしたいと考えているので、ビジネス側と開発側の距離が近いことも考えて総合的にメドレーが良さそうだと考えて入社しました。

寺内: 私はメドレーの夏のインターンシップに参加したのですが、医療・ヘルスケアドメインの課題の多さと、それに正面から向き合うメドレーという会社が非常にエキサイティングだと感じたのが、きっかけです。

そこから自分の医療の原体験というのを考えたときに、高校の時に親族が難病かもしれないという疑いが出てきたという出来事がありました。結局は大丈夫だったのですが、その時に医療情報などの探しにくさなどを実感したことを思い起しました。メドレーはそうした問題に取り組んでいる会社だというのが一番の理由でした。もちろん優秀な方が働いているというのもあります。

メドレーが「医療」という分野での事業をしているということに共感して入社している方が多いですね。共通して自分が作ったものが、社会にインパクトを生み出せるか?ということを意識しているメンバーが多いと思いました。

2021 年度新卒研修の感想

ここからは、新卒研修を受けた感想を 1 年越しに聞いてみたいと思います。特にチームとして開発をしていった「開発実践研修」について中心に聞いてみました。当時は大変なこともあったと思いますが、経験を積んだ今はどのような感想を持っているのでしょうか。

研修で良かったこと

佐々岡: 開発実践研修で良かったのはまず、要件定義からリリースまで一気通貫にできたので自分のその時点での不足している部分というのが可視化されたことでした。

また開発するツールはそのまま社内で使い続けていくものだったので、レビュアーの方にも親身になってレビューしていただけたり、そういった所が良かった所です。

開発実践では React.js を使って開発をしていたんですが、配属されてからも業務として使って活きている部分です。メドレーで開発業務をするということが、どういうものかをこの研修を通じて勉強できました。おかげで、配属された後も違和感なく実務ができるようになりました。

高橋: エンジニアとしてこれからプロとして開発をしていく上で自信が付いたのが良かったです。

学生のときは作って終わりというプロダクトが多かったのですが、社会人になって初めて作ったプロダクトが今も毎日稼動しているということで、エンジニアとしての自信に繋がりました。

この経験のおかげで、現在の業務でも自分が違和感などを感じたりしたときには、「間違ってるかな」などと臆せずにズバズバと言えるようになっています。

現在のプロジェクトは要件の固まりきっていない新機能を開発しているフェーズなので、日々の業務に活かせている実感があります。

堀内: 今に繋がってるなと思っているのはチームがちゃんと目標を持っているときと、そこがあやふやだったときのチームのパフォーマンスの出方が全然違うというのを体験できた点です。

開発中は自分はチームリードとして、チームビルディングを中心に行っていたのですが、ちゃんと目標をイメージできる形にする・そのイメージをチームで認識が揃うまでしっかりと擦り合せる、という 2 点に注意していました。

最初の目的をちゃんと話しあって固めた後は、朝会などでちゃんとメンバーの作業について共有していくようにしたら、上手くチームが回り始めました。最初にイメージを固めたら、MTG を小まめにしなくてもちゃんと作業が進んでいきました。

寺内: 「開発実践研修」の前に受講した外部研修の「ビジネススタンス研修」が良かったです。研修の序盤に受けられて社会人としてのスタンスが学べたのが良かったです。ここで習ったことが、開発実践研修でチームで話し合う場でもきちんと応用できましたし、もちろん業務をしている今でもちゃんと活きていると実感しています。研修の全メニューが良かったと感じているのは言うまでもないかもしれませんが w

研修で大変だったこと

佐々岡: 最初の段階での要件定義のときに課題設定が想定と違ってきたことが一番大変でした。

研修企画側から予め提示されていた課題と自分達が考えた要件定義とのズレを、 Miro を使ってのミーティングを繰り返して修正するまでに、時間がかかってしまいました。そうしたミーティングなどで課題の解決方法などを構造化して考えたりしていき、ようやく修正できました。

この経験で最初の課題設定も正しいかどうかを鵜呑みにせずに、ちゃんと自分達で調べて納得するような形にしないといけないということを学べました。

高橋: やはり要件定義フェイズでした。当初の予定より大分伸びてしまいました。これは着地点が不明確なまま、議論が進んでしまっていたのが原因でした。

対応として全員でちゃんとコンセンサスを取りながら、着地点を明確にして要件定義をやり直した結果立て直すことができました。要件定義をしっかりやるというのはこの研修が初めてに近い状態だったので、大変でした。

当時フワフワとした状態で進めてしまったところが反省点だったので、不明な部分などは自分の中で全部つぶした上で開発するということが大事なんだということが学べました。

内田: 要件定義していた最初の 1 週間は本当に進みが悪くて大変でした。1 週間経ってようやく**「自分達がオーナーシップを取らないと開発が進まない」ということを実感**したので、そこから勢いが付いた感じです。それまではどこか自分事として捉えられてなかったんだと思います。

寺内: 最初のほうではメンバーの向き不向きとか性格などがやはり分からなかったので、お互いの期待値調整が大変だったなと思います。

最初の時点で目的に対する姿勢も、メンバーごとに温度感が違いました。そこで、全員でお互いの得意・不得意などや期待することを、擦り合せる時間を作ってようやく役割分担もできました。

これで、ようやくスタートラインに立ってゴールもそこに至る道筋も明確になりました。自分は今のチームでも上司や同僚に自分の情報を開示しつつ、期待値を把握して仕事をすることによって目指すべき場所が認識できるようになり、仕事が円滑に進むようになった実感があります。

研修については、皆さんそろっての初の共同作業ということもあり、苦労も達成感も感じていますね。現在の業務にも、きちんと活きているというのは嬉しい限りです。要件定義から自分達でオーナーシップを持って目的を持ってチームで開発をするという、実践的な研修を心がけていたので、ちゃんとそこを経験してもらっているようです。

今後について

最後にメンバーそれぞれの皆さんにこれから目指すエンジニア像を聞いてみました。

佐々岡: 今後はビジネス側の知見・現場の課題感・プロダクトのあるべき姿という 3 つの視点をきちんと身につけていけるエンジニアになっていきたいと思っています。

現時点ではまだまだという自覚があるので、これから色々な先輩方の背中を追いかけつつ、成長していきたいと思います。

高橋: 今はプロダクトマネージャやリーダーがプロダクトの根本的な基本要件を考えて、そこから詳細要件を自分達が考えて実装しているのですが、行く行くはそうした基本要件から自分で考えて、周りと連携しつつ実装していけるようになりたいです。

ここまで出来るようになると、自分が社会にインパクトを与えるプロダクトを作ったと胸を張って言えるんじゃないかなと思っています。

堀内: 将来的には経営者の道を目指そうと思っています。ただ、プロダクト開発をしっかり理解し、一定の技術力を身につけていない状態では、人も付いてこないと思うんです。

ですので、説得力を持てるくらい技術力を身につけていきたいと思います。まだ出来てないと自覚しているのですが、自分が勉強させて頂いている部分を、早くチームの方達に恩返しできるようにしてきたいです。

内田: 元々課題解決するプロダクトを作りたいという思いで入社しましたが、実現するためには 3 つやることがあると思っています。 1 つは「解決のために最適解を選択できること」です。これは幅広い技術を身につけたエンジニアになることかなと思っています。

2 つ目は「ちゃんとドメイン知識を習得すること」です。最適解を選ぶのにも業務知識が無いままだと絶対に良い選択をできないと考えています。

最後は「自分の考えをきちんと推し進められるビジネススキル」です。色々と関わる人にちゃんとコミュニケーションを取って、自分が良いと思うものを広められればと考えています。メドレーは自分が凄いと思ったエンジニアの方達がたくさんいらっしゃるので、行く行くは自分もそう思われる位になれたら…と思います。

寺内: なりたいエンジニア像については、既にみんなに言いたいことを言われているんですが w 直近の目標は、マネージャから見ても「一人前である」と思われる実力を身につけたエンジニアになることです。また、内側に目を向けられるエンジニアになることも目標です。新機能や定常業務の開発だけではなく、部署内の開発以外の人達が気持ち良く働けるようになる開発をしていけば、顧客などにも良い影響が出て、結果として事業の成長になるのではないかと考えています。

ですので、部署の皆さんにも喜んでもらえるような一人前のエンジニアになっていきたいですね。

現在は技術や仕事の仕方などを吸収しながらぐんぐんと成長している皆さんですが、最終的な目標はプロダクトに貢献できるようにという背景を感じます。ちゃんとビジネス面も分かったエンジニアにという考え方を持っていてメドレーでエンジニアに求められる部分を意識しているなと思いました。

おわりに

21 年入社エンジニアの座談会はいかがでしたでしょうか。

メドレーの新卒研修を受けた側の感想を公開するのは初めての試みでしたが、自分もインタビューをしていて改めて当時メンバーの皆さんが苦悩していた部分や、現在に活きている部分などを聞けて勉強になりました。

今年も既に 22 年新卒入社のエンジニアメンバーが研修をしている真っ最中ですが、こうした経験などを後輩に伝えてもらうと、より良い組織になっていくのではないかと思っています。

最後に一緒に医療の未来を作っていく仲間を募集しているので、この記事を読んでメドレーに興味が湧いた方はぜひ、話をしましょう!

CLINICSアプリのリニューアルの裏側（Android編）

Thu, 30 Jun 2022 02:53:07 GMT

はじめまして。医療プラットフォーム本部プロダクト開発室エンジニアの小形（@ogaclejapan）です。普段は、オンライン診療・服薬指導アプリ「CLINICS」の開発を担当しています。近々、転職の入社エントリーも会社の公式 noteに公開されますので、ぜひ読んでみてください。

さて、昨年 12 月に CLINICS アプリはUI のフルリニューアルを行いました。少し経ちましたが、「CLINICS アプリのリニューアルの裏側(iOS 編)」に続く、Android 編ということで裏話を書いていきます。

コミットグラフから振り返るアプリ開発史

リニューアルを終えた直近のコミットグラフから CLINICS の Android 版アプリの歴史を振り返ると、大きく 4 つの時代を超えてきました。

立ち上げ期：2016/7 -
閑散期：2018/4 -
再始動期：2020/5 -
リニューアル期： 2021/5 - 2021/12

1. 立ち上げ期

記念すべき PR#1 は、2016 年 7 月でした。すでにコミットグラフの表示期間外なのであまり詳しく追えていませんが、1〜2 名がメインで関わりつつ、他のエンジニアの方のコミットもちらほらとありました。私のようにネイティブアプリ開発を中心に経験してきた人は、まだ社内に少ないですが、フロントエンドからバックエンドまで幅広くできる人がとても多いのも納得です。

実装は SmartUI と名がつけられた~~アンチパターンの~~ように、ネットワーク通信から画面の表示制御まで単一のファイル内にすべて書かれていました。アプリ経験者不在の中で開発を続けてきたことに尊敬の念を抱きつつも、リニューアル開発で全面的にコードを書き直すまで色々なツラみがありました…。R.I.P. FatActivity 🛐

2. 閑散期

2018 年から約 2 年ほど開発がほぼ止まっていました。もともとオンライン診察機能のために開発された経緯があり、この期間は電子カルテのシステム開発にリソースを注力していたようです。

3. 再始動期

2020 年 5 月から再びアプリ開発は活発になり、オンライン服薬指導機能を提供する調剤薬局窓口支援システム「Pharms」と連携する開発などが 1〜2 名で行われていました。

2020 年度通期の決算説明資料を読んでみると、患者（≒ アプリ）を中心にプロダクトラインナップを増やしていく医療 PF 事業投資の図が初登場していました。この事業計画に沿って、Pharms 連携やお薬手帳機能など患者向けアプリを強化する動きが加速し、2016 年から引き継がれてきた UI デザインや拡張性をゼロベースで見直すべく、翌年のリニューアル開発へ繋がっていきます。

余談ですが、今年の 2 月に歯科業務支援システム「Dentis」をリリースして、4 月からアプリとの連携も試験的に開始しています。リニューアル開発が完了していたからこそ、新規プロダクトへの連携にもスムーズに対応できました。

4. リニューアル期

リニューアル開発は、2021 年 5 月下旬頃から本格的に実装を開始し、同年 12 月に無事リリースすることができました。当初、Android アプリ開発メンバーの頭数が足りておらず、私と協力会社の社外エンジニアのみで進めていく状況でしたが、6 月途中からアプリ開発経験のある社内エンジニアが 1 名異動してきてくれたおかげでピーク時を乗り切れました。

リニューアル後のアプリ内モジュール構成と技術スタックはこんな感じです。今年の 3 月に刷新された公式のアプリアーキテクチャガイドに近く、最低限データアクセス部分を分離したレイヤー構成としました。モノクロではない色付きの技術スタックが今回新たに導入したものになります。

次章からリニューアル開発で取り組んだことについて、詳しく書いていきます。

リニューアル開発で取り組んだこと

リニューアル開発のアプリをリードしていく役割で意識的に取り組んだことは次の 3 つです。

未来像を描く
PoC を作成する
期間と機能の折り合いをつける

未来像を描く

当たり前のことですが、リニューアル開発が最終的な自分たちのゴールではありません。この点を意識しながら、最初に iOS アプリをリードしたエンジニアの世嘉良さんとメドレーに合ったアプリ開発のあるべき姿を一緒に描きました。

ざっくりとした図ですが、202X 未来像をメンバーと共有できたのは良かったと思っています。事業的な観点や技術的な視点から自分たちがこの先に向かいたい方向性が明確になりました。私が入社したときからすでに Web、iOS、Android の 3 つのプラットフォームを横断するチーム体制だったこともあり、今後も横断しながら効率的に取り組める開発スタイルを目指しています。

最終的には、未来と現在を結ぶ通過点として今回のリニューアルを据え、期間や体制面などから実現可能な範囲を話し合って決めました。当時、私は入社 2 ヶ月目でコードの理解がまだ浅かったので、認識ズレのギャップを埋めることにもこの図が役立ちました。

PoC を作成する

開発するメンバー間の経験差が気になるときや実現性に不安が残るときは、PoC（Proof of Concept）モデルとして 1 つ以上の主要な実装パターンを事前に検証しておくと不確実性を低減できます。今回は自分がリードする立場であり、Android 開発経験が豊富なメンバーが揃ってガンガンと進めていける感じではなかったので、入念に事前準備してリニューアル開発に臨みました。

PoC で検証できた実装方針は、メンバーにも既存 1 画面の書き換えを試してもらい、実際に PR をレビューして本番環境へ投入しています。 5 年前のコードベースが多く残るアプリをどのように移行させるか検証は少し大変でしたが、この事前準備の甲斐あって、リニューアル開発の期間中は技術的な要素でハマることなくタスクに集中できました。

期間と機能の折り合いをつける

PoC モデルを作成して技術的な実現性への不安を解消できましたが、リニューアル開発を進めていく期間と仕様面で、まだいくつかの不安要素は残っている状況でした。

私自身、入社 2 ヶ月目で既存の業務ロジックは一部しか把握できてない
⇒ 　業務の仕様を理解しながら新しい画面へ書き換えていくので時間かかるかも…🧑‍💻
要素しか決まっていない画面が多数あり、画面デザインが並行して進んでいた
⇒ 　どのタイミングで要素を取得するべきなのか、デザイン次第で変わりそう…🎨
協力会社から一緒に手伝ってくれる社外エンジニアの実力値が未知数だった
⇒ 　軽く感覚は掴んでもらったものの、良しなにタスクを進められるだろうか…🧗‍♀️

いくら経験を積んだエンジニアでも不確実性を多く含むタスクの工数は正確に見積もれません。そこで、リニューアルに関するアプリの開発定例で「もし想定する期間に間に合わなかったときにどうするか？」という議題を提起しました。当たり前の話になっちゃいますが、うまくいかないときに取る行動を全員が共通認識しておくことは大切だと思っています。結論の候補は次のどちらかになるのではないでしょうか。

リリース日を延ばして計画したリニューアルのタスクはすべてやりきる
一部機能を落としてリリース日はずらさない

今回のリニューアル開発では、後者にあたるリリース日を死守する結論になりました。ただし、一部の機能を落とすのではなく、既存の旧画面をスタイル調整してでも機能は出したいという要望があり、この点を設計やスケジュールのタスク優先度に折り込みました。

12 月に無事リリースできた Android アプリの裏側には、事業サイドとのこのような合意がありました。実際、予定外のことも起きて一部の機能はリニューアル後に回しましたが、取る行動を決めておいたことで終盤あたふたすることなく、安定したものをリリースできました。

これから

ここまでお読みいただきありがとうございました。同じような立場でこれからリニューアル開発を進めていく方のヒントになったら幸いです。コードは 1 行も載せていませんが、Android アプリ開発者なら図の構成でなんとなく想像が付くと思い、今回は進め方にフォーカスしてみました。

さて、患者アプリはリニューアルが無事完了し、モダンな技術スタックで効率良く開発できる状態になりましたが、まだまだ技術的な視点で取り組みたいことはたくさんあります。

Kotlin Multiplatform／Kotlin Multiplatform Mobile の活用[^1]
⇒ 　 iOS、Android（可能なら Web も）のロジック統合など生産性を上げる
宣言的 UI への移行（iOS はすでに SwiftUI）
⇒ 　 UI アーキテクチャ構成やコンポーネント化など UI の共通感覚を高める

一方、患者アプリのビジネス視点では、オンライン診療を主軸とした予約・フォローアップの体験向上が 1 つの役目になります。私自身は、「オンライン診療の実施に当たっての基本理念[^2]」に沿った成長路線がより良い患者体験につながると考えています。

Ⅳ オンライン診療の実施に当たっての基本理念

① 患者の日常生活の情報も得ることにより、医療の質のさらなる向上に結び付けていくこと
② 医療を必要とする患者に対して、医療に対するアクセシビリティ（アクセスの容易性）を確保し、よりよい医療を得られる機会を増やすこと
③ 患者が治療に能動的に参画することにより、治療の効果を最大化すること

この基本理念の 3 項目をアプリが満たすべき姿としたのが次の 2 つの状態です。

医療を身近に行動できる状態（基本理念の ① と ③ に該当）
⇒ 　「探す」「知る」「伝える」といった行動手順の簡素化
必要とする人が適切に使えている状態（基本理念の ② に該当）
⇒ 　アクセシビリティへの配慮、分かりやすい UI（≒ ユニバーサルデザイン）

このような領域に興味のあるエンジニアやデザイナーさんがおりましたら、ぜひお近くのメドレーへ。医療ヘルスケアの未来を一緒につくりませんか？

最後までお読みいただきありがとうございました。

[^1] Flutter や React Native といった選択肢もありますが、現時点では外部 SDK 含めた既存コードとの親和性や時間的な制約から段階的に移行できる技術を重視しています
[^2] 厚生労働省が公開する「オンライン診察の適切な実施に関する指針 10 ページ目」より抜粋

Showcase Gig さん主催の QA エンジニア向けイベントに弊社米山が登壇しました

Tue, 31 May 2022 11:38:23 GMT

はじめに

こんにちは。技術広報・エンジニアの平木です。最近使っている Emacs を Spacemacs から Doom Emacs に変更したところ気分も新たにテキスト活動が捗るようになりました。

さて、2022/05/11 に行なわれた「QA Night 〜組織内で QA エンジニアがバリューを発揮し、キャリアアップするには〜」という QA エンジニア向けイベントで弊社 QA エンジニア米山がパネリストとして登壇しましたので、その様子をイベントレポートとしてお届けしたいと思います。

QA Night とは

こちらのイベントは Showcase Gig さんが主催しているイベントである Geek Gig というエンジニアリングについての定期イベントがありまして、そのシリーズの 1 つとして運営されたものです。

今回は Showcase Gig さんも弊社もテスト自動化ツールの MagicPod を使っているというご縁からお声がけいただきイベント開催の運びとなりました。

イベントについて

今回のイベントは、パネルディスカッションとして 2 社の QA についてそれぞれ語る形式になりました。

モデレーターを Showcase Gig ソフトウェアエンジニアで VP of Technology である菊池さんが行ない、パネリストとして Showcase Gig QA エンジニア横田さんと、弊社 QA エンジニア米山とでざっくばらんにイベントが進行していきました。

QA エンジニアの方だけではなく、モデレーターにエンジニアの方が入ったことによりバランスが良いパネルディスカッションになっているという感想でした。

こちらのイベントは connpass で公開後、あれよあれよと 140 人まで申し込みがあり、注目度の高さが伺えました。

当日のイベントの様子は下記からご覧いただけますので、ご興味のある方はぜひ。

パネルディスカッション

パネルディスカッションは大まかに以下のようなセクションに分かれて実施されました。

パネリスト・モデレーター自己紹介
各社の開発/QA プロセスの理想と現実
QA エンジニアがいなかったらどうなる?
QA エンジニアのキャリア

これらのセクションに合わせて、パネリストそれぞれの立場で回答をしていきましたが、途中で視聴されている方の質問などは、モデレーターの菊池さんがほぼリアルタイムで拾っていきながらの進行だったので、イベントの一体感が非常に感じられて面白かったです。

自己紹介

横田さんも米山も現職に至るまでの経歴がかなり似ていました。第三者検証会社で様々な業態の会社を顧客として、様々な経験を積み重ねてから、事業会社での QA エンジニアとして特定のプロダクトの品質を高める仕事をしていらっしゃるという点です。

第三者検証会社で様々なニーズに対応したことが、プロダクトへの貢献に活きていそうだと感じました。

各社の開発/QA プロセスの理想と現実

QA を含めた開発体制については、両社で違いがもちろんありますが大きい違いでいうと、現在のメドレーではプロダクト開発チームの一員として QA エンジニアが所属しています。他方、Showcase Gig さんでは複数の開発チームを横断して QA チームが存在しているという部分でしょうか。

メドレーの現在の開発体制では、チーム内で開発メンバーと密接にやり取りをしながら品質を高めていくというプロセスが取られており、別の開発チームのヘルプなども、もちろんありますがアドバイザー的な感じで、実際にはそのチーム内で品質を高めるように動いています。

一方で Showcase Gig さんでは横断チームとして各プロダクトを俯瞰して見れるような体制にしている印象でした。それぞれの開発チームとは要所でシンクアップすることにより会社全体での QA プロセスを統一しながら各チームに展開できるのが良さそうだなと感じました。

理想と現実について

そんな両社ですが、共通する部分として事業領域の難しさがありました。メドレーは医療領域という難しさ、Showcase Gig さんではオンラインとオフラインの両立をしなければならない部分が特に難しいとのこと。

そこから話は QA の理想と現実に移っていきます。メドレーではプロダクトのより上流部分である仕様策定部分からバグを潰せるようにしていくのを目指しつつも、ガチガチな方法や体制にならないように日々 QA を行なっています。また E2E テストの失敗が非常事態だとメンバーが焦るくらいに成功率を高めていきたいという理想がありますが、どうしてもマニュアルでのテストが必要になってくるプロダクトなので、E2E テストだけに頼らないように試行錯誤しています。

Showcase Gig さんでは品質は担保しつつ、今以上にリリース頻度を上げるためにどうしたら良いかという点を開発チームと協業で改善しようとされているそうです。MagicPod を使った E2E テストだけでリリースまでできるようにするのが理想ではありますが、その前にプロセスの制定など前段階の準備を着々としているそうです。

QA エンジニアがいなかったらどうなる?

QA エンジニアのイベントで中々出てこないような設問もあり大変面白かったのですが、それがこの「QA エンジニアがいなかったらどうなる?」という設問でした。

興味深かったのはお二人とも同じような返答だったことです。両社とも「リリースは通常通り行なわれるだろうが、リリース後の不具合対応などが増えるかもしれない」ということでした。またこれも共通して「QA エンジニアがいなくても品質保証がされることが理想」というお話でした。

実際に QA エンジニアはいなくてもきちんと高い品質のプロダクトを世に出していける仕組みや体制が理想というのは、関係者に品質についての意識が根差していけるようにするという意気込みのように聞こえ感銘を受けました。

QA エンジニアのキャリア

また普段お二人はどのような意識配分で日々の仕事をされているかというのを円グラフで表わす試みが良かったです。普段どのような事に時間や意識を割いているかというのが分かると自分の仕事の比率と比べてみちゃいますね。

ここから、皆さんが気になる QA エンジニアのキャリアについてお二人が話をされました。

米山は 15 年の QA 経験を持っていますが、その中でアジャイルやテスト自動化などのトレンドには「自分でもできるかな」と思いながら導入をしていったとのことでした。そうしながら、自分の中のプライオリティはあくまでも事業・プロダクトという部分だったので、ここにコミットができる立ち位置での仕事をずっと続けてきたと言います。

先のキャリアとしては、ポジションに捕われず事業価値を高めるように動いていき、どのような状況のチームでも品質を高めるための推進ができるようにしていきたいということでした。

一方の横田さんも今までの経験を踏まえ QA のポジションを高めていけるような動きをしていきたいということでした。テストなどに興味を持つ人の裾野を広げていきたいという意欲を感じました。個人としては UI/UX なども含めて品質を高めるということができればとのことでした。

お二人とも、「自分のキャリア」に留まらず周囲の人間にも、良い影響を与えていきたいということをおっしゃっているのが非常に印象的でした。

最後に

紹介した以外にも現場に即した QA についてや、品質についての考え方の一端が分かるようなイベントでした。自分はエンジニアという立場で視聴していましたが、そうした人間にも大変に示唆に富むお話が多く、あっという間に 1 時間が経過しました。QA エンジニアの方はもちろん、その他プロダクトを作るということに関わる方はぜひ、アーカイブを視聴してみてください!

メドレーエンジニア・デザイナーブログをリニューアルしました

Fri, 01 Apr 2022 07:04:16 GMT

はじめに

皆さん、こんにちは。エンジニア・技術広報の平木です。

以前からご覧になっていただいていた方にはお分かりかと思いますが、3/18 に今ご覧いただいているエンジニア・デザイナーブログを「Developer Portal」という名称に変更して 2017 年以来 5 年ぶりにリニューアルをしました。今回はリニューアルについて、目指すところと若干の技術的な側面をお伝えできればと思います。

ブログトップ新旧比較

旧

新

エンジニア・デザイナーブログリニューアルの背景

まずは、 なぜリニューアルしたか? という背景についてです。弊社のエンジニア・デザイナーブログの変遷と共にお話していきたいと思います。

エンジニア・デザイナーブログの変遷

第 1 期(2016/04 ~ 2017/07)

Developer Blog は 2016/04 月に会社公式ブログにエンジニア向けの記事を掲載し始めたころから、しばらくは他の会社情報とともに掲載をしていました。記事内容はエンジニアが登壇したイベント情報や、今も続いている TechLunch(全社横断のエンジニア・デザイナー向け社内勉強会) の発表レポートなどがメインとなっていました。

この頃は開発組織の人数もそこまで多くなかったのですが、メドレーの開発組織を社内の様々な部署の雰囲気と共にお伝えしようという目的がメインでした。まずは、メドレーの開発組織としてのプレゼンスを高め、プロダクトを内製で日々開発をしていることを、外部の皆さんに知ってもらおうという目的が一番大きかったように思います。

このような形で 2017 年中頃までは会社公式ブログでの更新をしていましたが、開発組織が拡大するにつれ、組織として出来ることも増えてきました。それに伴い、これまでのように「開発組織の存在のアピール」や「組織の取り組み」に加えて、純粋に技術的な側面をもっと打ち出していき「医療 x IT」というテーマにメドレーはどのように向きあっているかを知ってもらおうという機運が高まってきました。

第 2 期(2017/07 ~ 2022/03)

こうした運びで新しく Medley Developer Blog を 2017/07 月に立ち上げることになりました。会社公式ブログから完全に独立したテックブログということで、目論見通りにそれまで以上に技術的な投稿もできるようになりました。編集方式もこの時から現在までエンジニア・デザイナーが主体となっています。

更新頻度も不定期だったものを月 1~2 回と増やし、コンスタントにメドレーの開発に関する話題を取り扱うようにしました。運営をしていた 5 年の間にいくつかの記事は、おかげさまではてなブックマークなどで話題になることもあり、第 1 期よりもさらに皆さんに読んでいただけるようなブログになりました。

この間にメドレーも様々なエンジニア・デザイナーイベントにスポンサードさせていただいたりもして、ブログと合わせて一定のプレゼンスを得ることができてきたのではないかと思っています。特に「医療ヘルスケア業界」という馴染みが無い方にはハードルが高いと思われることが多い業界でのプロダクト開発に、一般的なインターネットテクノロジーを駆使しているという点を、色々な側面からお伝えできるようになったことは大きいと感じています。

現在(2022/03 ~)

そんなブログでしたが、開設から 5 年経ち以下のような課題が出てきました。

会社がまだ上場前に作られたデザインだったため、現在のコーポレートサイトなどのトーンとズレが出てきている
会社や組織規模が大きくなり、希薄になりがちな内部で働いている個人にもフォーカスが当てられるようなコンテンツが欲しい
採用的な側面として、メドレーに興味を持った方へ提供できる情報がバラバラになっている

以上の課題を解決するために、ブログのリニューアルをすることになりました。

特に今年から全社的な方針として、メドレーのソフト面での話題にフォーカスしたコンテンツを作っていくということで、改めて公式noteの更新に注力していることもあり、エンジニア・デザイナーブログもこの動きと連動する必要がありました。

以上の理由から、コンテンツとしては従来通りの ブログ記事 、様々なメディアでメンバーが露出している インタビュー記事 、イベントなどで使われた 発表スライド を全て見られるような総合的なサイトにしていくこととなりました。

インタビューはこれまでもメンバーが様々なメディアに出ていたり、スライドも以前から Speaker Deck を更新していたのですが、まとまった形での提供ができていませんでした。

今回のリニューアルで、これらの要素をまとめて皆さんにお届けできるようになったため、「Medley Developer Blog」から「Medley Developer Portal」と名称変更をしました。

これからも、メドレーの開発組織をより外部の皆さんに知ってもらうために、運営ができればと考えていますので、よろしくお願いします。

エンジニア・デザイナーブログリニューアルの技術面について

さて、ここまでリニューアルの背景をお伝えしましたが、ここからは今回使った技術面について軽く触れていこうと思います。

使用技術について

旧ブログは「はてなブログ」での運用をしていました。リニューアルにあたって上記の課題を解決するためには、独自にブログを開発したほうがよいと考えました。新ブログは以下の技術を使って開発しました。

Gatsby
- Emotion
- TypeScript
Netlify

Gatsby に決めた理由は大きくは以下でした。

既に弊社内で Gatsby の導入実績があるため、社内のメンバーがいざとなったら触れる
ブログ + α のサイトを作るのに十分な柔軟性がある
公式やコミュニティプラグインが充実しており、開発が省力化できる

Gatsby は精力的にアップデートが行なわれており、早いサイクルで進化するのも魅力の 1 つでした。

Gatsby 製サイトをどのように公開するかは、悩んだのですが、結果的に事例も多くありデプロイの簡易さや機能の豊富さを考えて Netlify にしました。

はてなブログからの記事移行について

最初から旧ブログでのコンテンツは新ブログに移行することがマストだったので、まずはどのように移行ができるかということを考慮することから始めました。はてなブログは通常のエクスポートだと Movable Type 方式になるので、なんとか Markdown に変換するか…などと考えていました。

しかし、blogsyncというはてなブログの CLI クライアントを通すとローカルに Markdown ファイルとしてブログエントリを同期することが可能だったため、

blogsync で全ての旧ブログコンテンツをローカルに同期(ダウンロード)
ローカルに Markdown ファイルとしてダウンロードできたブログコンテンツを Gatsby 製の新ブログにコピー
gatsby-source-filesystem でコピーした Markdown ファイルを読み込みブログとして表示

という手順で既存のブログ記事を全て移行することができました。

また、ドメインについては独自ドメインをそのまま新ブログにも移行することとしたため、はてなブログと同じ URL 形式でブログが読み込めるようにルーティングをしました。

苦労した部分

今回の開発で苦労した部分をダイジェストで書いていきます。自分のニーズに合わせて調べてみても、特に深い部分に関して、あまり情報が出てこないというパターンが多かったように思います。

バージョン固有の情報や、プラグインの情報が少なかった

開発当初は Gatsby v4 が出たばかりだったので、何かに困って検索しても公式以外の情報は以前のバージョンで使えないことが多かったです。

またプラグイン関係の情報も調べる内容によっては中々目的の情報が出てこなかったりしました。gatsby-plugin-image 周りで顕著な印象だったので、画像周りの表示に泣かされることがありました。

他にも Markdown 表示は gatsby-plugin-mdx を使用していますが、従来の gatsby-transformer-remark と情報が混在している印象がありましたので混乱することも。

ページネーションでベストなプラグインが見つからなかった

公式ガイドを参考にページネーションを自前で作っていたのですが、GraphQLから持ってきたデータを表示するだけではあまりユーザビリティが良くなかったため、プラグインなど探したのですがこれといったものが見つからなかったです。

公式ガイド参考に作ると延々記事が増えたらページネーションの数も増えていってしまい微妙な感じでした…。自前で制御も考えましたが、最終的にはmui/paginationコンポーネントを組み合わせることで対応しました。

OGP 画像自動生成に関して情報が少ない

OGP 画像は自動生成にしたいと思いましたが、案外ニーズが無いのか情報が少なかった印象です。最終的にこちらのブログを発見し、kentaro-m/catchy-imageを使って生成するようにしました。

これからやりたいこと

機能の拡充以外だと、今まではできなかったtextlintでの校正などをして、編集時の負荷軽減などをやっていきたいと考えています。

さいごに

以上、 Developer Portal のリニューアルについて書かせていただきました。引き続き、情報発信などをしていきメドレー開発組織について、皆さんに知っていただければと思います。

最後になりますが、医療ヘルスケアのプロダクト開発に(このようなブログ製作も)関わっていきたい!という方はぜひ下記よりご応募お待ちしております!

Model–view–presenter - Wikipedia

CLINICS アプリのリニューアルの裏側 (iOS 編)

Tue, 15 Feb 2022 09:00:02 GMT

こんにちは、医療プラットフォーム本部/プロダクト開発室/第一開発グループ所属の世嘉良です。メドレーには 2018 年の頭に入社しており、今年で 4 年目になります。当初はサーバーサイドを中心に開発を担当していたのですが、最近は患者エンゲージメントチームという患者様に提供するサービスを開発するチームで主に iOS の仕事を担当することが多いです。

さて去年の 12 月になりますが、 CLINICS アプリは UI のフルリニューアルを行いました。今回はリニューアルの裏話 (iOS について) をしていきたいと思います。

これまでの CLINICS アプリについて

本題を書く前に、CLINICS アプリの歴史を紹介します。ファーストコミットを見てみると、アプリの開発は 2016 年 2 月ごろからスタートし、ファーストリリースが行われたのが 2016 年 5 月でした。

当初、担当していたエンジニアは iOS の経験が豊富な方はおらず、全員で試行錯誤しながら開発を進めていたようです。しばらくの間は機能の追加などが行われていましたが、CLINICS カルテの開発に注力するために大きな開発はストップし、Pharms との連携が開始される 2020 年 5 月頃まで機能や設計に関する見直しがほとんど行われてきませんでした。

iOS に詳しいエンジニアがいなかったにも関わらず、かなりのスピード感でリリースしていることはさすがの開発力という一言に尽きるのですが、Pharms との連携やお薬手帳といった機能が追加されたり、今後の開発を見据えた際に既存機能や設計の見直しを行いたいと思うようになってきました。

改善したい部分はたくさんあったのですが、対応工数を踏まえ今回のリニューアルでは以下の 2 点の改善に注力することにしました。

Storyboard による View の管理
View とロジックの分離

この 2 点についてそれぞれ詳しく説明します。

1. Storyboard による View の管理

従来の開発では Storyboard を利用して View を作成していました。 Storyboard を使うとレイアウトや画面遷移を簡単に実装することができますが、開発を続けているうちに以下のような問題が目立つようになってきました。

Storyboard が巨大化していき、複数人開発を行う際に支障がでる
レイアウトに追加・変更が行われた場合に AutoLayout の再設定に時間がかかる
コンポーネント自体にサイズが設定されていることがあり、コンポーネントを再利用できないことがある

課題

こちらは実際にあった Storyboard のキャプチャですが、複数の画面が 1 つの Storyboard 内に詰め込まれた状態となっていました。 Storyboard は Xcode のバージョンにより微妙な差分が発生してしまったり、AutoLayout の調整が必要になる場合があります。

こちらは古い Storyboard の画面を開いた後の差分なのですが、この変更がシステムによって加えられた変更なのか、他人の改修による変更なのかを後から見た時にわかりづらいという問題がありました。

仮に問題が発生した場合は修正を試みるのですが、独自の XML によって表現されているため、iOS の経験が浅い僕にとっては修正が非常に難しかったです。

また、複数人で並行して開発する際にもコンフリクトが起きやすくなってしまい解消に時間がかかるという問題となっていました。

さらに従来の CLINICS アプリは DLS を利用してレイアウトを作成していたのですが、コンポーネントに直接サイズが設定されているものがあり、ある画面では微妙にサイズを調整したい…といった要件に対応できず、せっかくのコンポーネントを再利用できないケースがありました。

解決案

課題に対する解決案は色々と考えられますが、弊社の開発スタイルやエンジニアのスキルを考慮し以下のような方針を立てました。

Storyboard と各画面の実装は 1 : 1 の関係とする
画面遷移の責務も Storyboard から切り離す
コンポーネントにアトミックデザインを適用する

Storyboard の分割は以下のようなステップで行っていました。

Refactor to Storyboard を使って巨大な Storyboard を分割する
SwiftGen を利用し画面生成のコードを自動作成する
2 で生成したものを利用して画面遷移を行う
既存の Segue を削除する

まず最初に Xcode 7 から利用可能となった「Refactor to Storyboard」を使って画面を分割するところから始めます。

この機能を利用すると選択した View が新しい Storyboard に切り出され、元の Storyboard には切り出した Storyboard へのリファレンスや Segue 等の接続が保持された状態になります。

次に各画面間の遷移を Segue を使わずに行うようにします。 Segue は便利なのですが、Identifier が単なる文字列であったり、Storyboard を分割してもリファレンスは保持しておく必要がある点が微妙に感じてしまい利用しないことにしました。

Segue を使わずに画面遷移を行う必要があるため、画面生成と画面遷移の方法を自前で実装する必要があります。今回は画面生成の処理を SwiftGen を利用して自動生成可能にし、VIPER というアーキテクチャの Router を参考にして画面遷移を Storyboard から切り離すことにしました。

※ SwiftGen の利用方法は SwiftGen#interface-builder を参照ください。

Router の実装は以下の通りです。実装されたプロトコルを遷移元の VC に継承し、画面遷移のコードを呼び出すだけで画面遷移を行うことができます。

protocol ClinicWireframe: AnyObject {
    var viewController: UIViewController { get }
    func presentClinic(clinicId: String)
    func pushClinic(clinicId: String)
}

extension ClinicWireframe {
    func presentClinic(clinicId: String) {
        let vc = StoryboardScene.Clinic.initialScene.instantiate {
            ClinicViewController(coder: $0, isHeaderEnabled: true)
        }
        let presenter = ClinicPresenter(view: vc)
        presenter.setClinicId(clinicId: clinicId)
        vc.inject(presenter: presenter)
        vc.modalPresentationStyle = .pageSheet
        let nc = UINavigationController(rootViewController: vc)
        viewController.present(nc, animated: true)
    }

    func pushClinic(clinicId: String) {
        let vc = StoryboardScene.Clinic.initialScene.instantiate {
            ClinicViewController(coder: $0, isHeaderEnabled: false)
        }
        let presenter = ClinicPresenter(view: vc)
        presenter.setClinicId(clinicId: clinicId)
        vc.inject(presenter: presenter)
        viewController.navigationController?.pushViewController(vc, animated: true)
}

最後にコンポーネントの調整についてですが、CLINICS アプリではアトミックデザインを簡略化し、以下のような基準でコンポーネントを実装しています。

Block: UI の最小単位 (他の PJT にも持ち込めそうなレベルまで分解されたもの)
Partial: CLINICS の PJT 固有のコンポーネント
Layout: ヘルプ用のモーダルやエラー画面など他の画面から呼び出されることで初めて意味をなす画面など
Page: 各 ViewController とそれに紐づく Storyboard

この管理方法自体は弊社の別プロダクトの開発を担当しているエンジニアによって考案されたものです。弊社ではサーバー・フロント分け隔てなく開発を任されることも多く、厳密なアトミックデザインだとコンポーネントの分類に困ることが多かったためこのような管理方法をとっているそうです。今回のリニューアルに際して CLINICS アプリでもこれを参考にすることにしました。

これまで DLS として管理されていたコンポーネントは Block で実装しなおし、Width / Height といったサイズの設定を行わないようにしました。

このようにコンポーネントの実装レベルを明確にしたことで、実装に一定の指針が生まれ使い回しの効くコンポーネントを作成しやすくなりました。

2. View とロジックの分離

スピード開発が求められた背景を考えると仕方のないことではあるのですが、従来の CLINICS アプリでは ViewController にロジックが記述されており、俗にいう Fat ViewController の状態になってしまっていました。

Fat ViewController の問題点については既にさまざまな方が取り上げていますが、以下の部分が問題と感じています。

UI とロジックが分離されていないため、テストを書くことが難しい
可読性が低くなりがち
ロジックが切り出されていないため似たような実装が点在する場合がある

課題

こちらは実際にあった ViewController の一部です。

このコードに関しては以下の部分が問題と感じていました。

通信処理の呼び出しが ViewController の責務になっていること
通信結果を整形するロジックが ViewController の責務になっていること
画面描画のための State 管理が ViewController の責務になっていること

解決案

UI とロジックを分離するための手法はさまざまなものがありますが、弊社のアプリには以下のような特徴があります。

iOS 以外にも複数のプラットフォームをサポートしているためフロントエンドで保持するデータや複雑なロジック自体は少ない (サーバー側でなるべく担保している)
実装時や QA 時に感じた違和感について細かくディレクターと打ち合わせし、その結果次第では仕様を変更することがある

これらを考慮すると、プロジェクトの期間的に初期の導入コストが低く、データフローがシンプルなものに留めたいというように考えがまとまってきました。

これらを考慮し、CLINICS アプリでは MVP というアーキテクチャを採用することにしました。より詳細には MVP の Passive View 方式を採用しており、以下のような形で実装しています。

View は基本的にすべての入力イベントに対応した Presenter の処理を呼び出す
Presenter は入力に応じて通信処理などの外部要因となる処理を呼び出し、結果を整形する
プレゼンテーションロジックの結果を描画するように View に指示を出す
View は Presenter の指示によってのみ描画処理を行い、自身を起点とした描画処理は行わない

既に Router は導入してるため、複雑な処理フローを実装したい場合は Interactor を導入するだけで VIPER アーキテクチャへと発展させることが簡単にできる点も魅力でした。

CLINICS アプリでの ViewController / Presenter の実装を簡単にまとめたものは以下のようになっています。

final class ClinicViewController: UIViewController {
    private lazy var presenter: ClinicPresenterInput = {
        fatalError(“Failed to inject presenter”)
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        presenter?.refresh()
    }

    func inject(presenter: ClinicPresenterInput) {
        self.presenter = presenter
    }

    // タップされた際に呼び出す
    func onTapServiceCell(_ service: ServiceEntity, isTelemedicine: Bool) {
        presenter?.didTapServiceButton(service, isTelemedicine: isTelemedicine)
    }
}

// MARK: - ClinicPresenterOutput

extension ClinicViewController: ClinicPresenterOutput {
    func reloadData(clinic: ClinicEntity?)
    {
        clinicViewStore.clinic = clinic
    }

    func openCreateAppointmentView(clinic: ClinicEntity, service: ServiceEntity, isTelemedicine: Bool)
        // 予約へ進む
    }

    func showErrorAlert(_ error: Error) {
        // エラー表示を行う
    }
}

protocol ClinicPresenterInput: AnyObject {
    func refresh()
    func didTapServiceButton(_ service: ServiceEntity, isTelemedicine: Bool)
}

protocol ClinicPresenterOutput: AnyObject {
    func reloadData(clinic: ClinicEntity?)
    func openCreateAppointmentView(clinic: ClinicEntity, service: ServiceEntity, isTelemedicine: Bool)
    func showErrorAlert(_ error: Error)
}

final class ClinicPresenter {
    private let clinicRepository: ClinicRepository
    private var clinic: ClinicEntity?
    private var cancellables: Set<AnyCancellable> = .init()

    init(view: ClinicPresenterOutput, container: DIContainer) {
        self.view = view
        clinicRepository = container.resolve()
    }

    private func reloadView() {
        view?.reloadData(clinic: clinic)
    }
}

// MARK: - PresenterInput

extension ClinicPresenter: ClinicPresenterInput {
    func refresh() {
        guard let clinicId = clinicId else { return }
        clinicRepository.getClinic(clinicId: clinicId)
        	.sink(
            receiveCompletion: { [weak self] completion in
                    guard let self = self else { return }
                    guard case let .failure(error) = completion else { return }
                    self.view?.showErrorAlert(error)
                }
            },
            receiveValue: { [weak self] response in
                guard let self = self else { return }
                self.clinic = response.data
                self.reloadView()
            }
        )
        .store(in: &cancellables)
    }

    func didTapServiceButton(_ service: ClinicsServiceEntity, isTelemedicine: Bool) {
        guard let clinic = clinic else { return }
        view?.openCreateAppointmentView(clinic: clinic, service: service, isTelemedicine: isTelemedicine)
    }
}

ViewController と Presenter は以下のように Router の内部で DI するようにしています。

protocol ClinicWireframe: AnyObject {
    var viewController: UIViewController { get }
    func pushClinic(clinicId: String)
}

extension ClinicWireframe {
    func pushClinic(clinicId: String) {
        let vc = StoryboardScene.Clinic.initialScene.instantiate {
            ClinicViewController(coder: $0, isHeaderEnabled: false)
        }
        let presenter = ClinicPresenter(view: vc, container: DIContainer())
        presenter.setClinicId(clinicId: clinicId)
        vc.inject(presenter: presenter)
       viewController.navigationController?.pushViewController(vc, animated: true)
    }
}

これによって、もともと ViewController にあった処理は以下のように分離されました。

また、View と Presenter はインターフェースを介してしかお互いを知らないため、実装の交換が簡単にできるようになりました。 Presenter を交換することで 1 つの View で別々の処理を表現することが可能となったり、View をテストコードを交換することで Presenter の入出力値をテストすることができるようになっています。

まとめ

CLINICS アプリは歴史のあるプロジェクトですが、今回のプロジェクトを通して UI だけでなく裏側の実装も刷新しています。巨大な Storyboard を分解したことでメンテナビリティが向上し、MVP (+ Router) の導入によって View とロジックの交換が簡単になり、テストなどの実装を取り入れやすくなりました。

さいごに

ブログの本編には書けなかったのですが、今回リニューアルされた画面に関しては SwiftUI を利用してフルスクラッチで実装していたり、 Asset の管理方法についても大きな見直しを行いました。

またアーキテクチャの選定にあたり、「iOS アプリ設計パターン入門」が大変参考になりました。iOS の開発を行う方はぜひ一読してほしいと思います。

約半年ほどかかった大きなプロジェクトでしたが、患者エンゲージメントチームのメンバー全員で取り組み無事にリリースまで漕ぎ着けることができました。まだまだ手探りな部分もありますが、今後も患者さんにとってより安心して使えるサービスとなるように開発を続けていければと思っています。

長くなりましたが、最後までお読みいただきありがとうございました。

医療ヘルスケアベンチャーで開発チームと Sync した知財部門を立ち上げた話

Fri, 03 Dec 2021 09:05:44 GMT

はじめに

こんにちは、メドレーのコーポレート本部法務コンプライアンス部で、知的財産関連の業務を担当している鬼鞍です。

1 年ほど前に本ブログで「特許とはなにか」というテーマで当社における特許啓蒙活動を紹介させて頂いたのですが、思っていた以上に反響があり、「面白い」とか「わかりやすい」という嬉しいコメントも頂戴しました。

私がメドレーに入社して最初のミッションが知財部門の立ち上げだったので、次はぜひ**「ベンチャーでの知財部門の立ち上げ方」**的なテーマでブログ発信したいと思っていたのですが、当初はまだ具体的な社内事例が少なかったため、実績ができた段階で改めて本ブログで発表したいと思っていました。

それから１年以上が経過して実際に特許も取得するなど知財活動としての実績が蓄積されてきたため、これを機会にベンチャーで知財部門を立ち上げる際にやるべきことについて、実例に触れながら具体的にまとめてみました。

かなり長いコンテンツになってしまいましたが、フェーズごとの知財活動計画であったり、知財ロードマップの作り方など、なかなか表に出てこない知財部門立ち上げストーリーの具体的事例を惜しみなく書かせていただいておりますので、ぜひご一読いただき、お役に立てれば幸いです。

知財は開発チームとの信頼関係の構築がまず第一

先ほどは知財部門を立ち上げストーリの中で、知財活動計画とか、知財ロードマップであるとか少し格好つけたような文字が羅列していましたが、実は私が知財専任として初めに配置されて最初にやったことはそんな大それたことではありませんでした。

最初になにをやったかというと、エンジニアの方とランチに行く、あるいは飲みに行く、ということでした。当時はまだ Covid-19 が蔓延する前だったので気軽にそういうことができました。入社して最初の 1 ヶ月くらいは週 2 回くらいのペースで誰かとランチか飲みにいくということをしていたと思います。

飲みに行く、というとふざけているとか思われるかもしれませんが、知財部門の立ち上げストーリーを語る上で、このプロセスは無視できないほど重要だと考えています。先に断っておくと私は酒好きでもなければ、家でも一切飲みません。

当たり前のことなのですが、知財というのはプロダクトを生み出す開発組織があって初めて価値を発揮するものです。知財はあくまで事業や開発をサポートするところであって、それ単体で存在意義を発揮することはほぼありません。特に特許活動については開発チームとの連携が非常に重要です。

一緒にご飯を食べることが信頼関係を構築する上で最良の方法、とまでは言いませんが、少なくともご飯を食べない人はいないわけで、時間を無駄にしている感もなければ、オフィスの外で会えば仕事以外のことを話題にし易いので互いの趣味嗜好を知ることができます。みなさんもそうだと思いますが、通常、仲の悪い人とは一緒に食事はしないと思います。

特に、この後にもご紹介する社内のアイデアを発掘するという発明発掘活動は、話しやすいカジュアルな雰囲気で雑談のような感じでブレストするというのが非常に重要で、このときに相手がどんな人間かを互いに知っているか、知らないかでは大きな差がでてきます。

また更に、この後にご紹介する知財計画立案や知財ロードマップを作成することも当然重要なのですが、結局仕事というのは人と人との間を思考がやりとりされて実現化されていくものなので、人間関係・信頼関係が全ての基礎であり、実は一番大切にするべきものだと思います。

これは何も知財に限ったことではなく、部門を跨いで仕事をする上で信頼関係は非常に重要ですし、知財の観点で見ても円滑なコミュニケーションが結果的にいい発明やアイデアを生み出すための土壌づくりに貢献するものだと考えています。

知財活動計画は、事業の成長フェーズに合わせて設定する

知財部門の設立にあたって、エンジニアとのコミュニケーションと並行して進めたのが、知財活動計画の立案でした。知財活動とは、知財サイクルをうまく事業サイクルにインストールしてサイクルを循環させることであり、更にはこのサイクルが循環するための運用基盤を構築することを指します。また、ここでいう知財サイクルとは、例えば、社内に埋もれたアイデアを発掘し（創発）→ それを知財権化し（保護）→ 権利化した知財を活用し（活用）→ 活用した知財で得られた利益や結果を創発支援に適用できる形に変換する、というものです。

このような知財サイクルを、何の計画や戦略もなしに事業サイクルへインストールしようとするとうまくいきません。なぜなら、事業というのは日々成長し変化していくもので、事業の成長に応じて知財活動の目的や課題も変化するからです。

例えば、子会社が増えて事業規模が拡大すると、その子会社の事業領域で既に多くの特許出願がされている場合には、発明発掘活動よりもまずは法的リスクを回避することを最優先にして、他社の特許調査をしっかりやってからプロダクトをリリースする仕組みを作ろう、ということになります。あるいは、事業の成長に伴いプロダクトが成熟してきた場面では、似たようなプロダクトが乱立する結果、尖った機能や最先端技術で差別化をするようになるため、こうした場合には先行した特許取得が重要な目的になってきます。

このように、事業の成長フェーズに応じた知財活動の計画を立案するべく、まずはメドレーのミッションおよびそのミッションを実現するためのプロダクトの性質を把握する必要がありました。

メドレーは「医療ヘルスケアの未来をつくる」というミッションを掲げ、インターネットテクノロジーによる医療のあり方の変革を目指す企業です。

このミッションと向き合いつつ、事業プラットフォームの成長フェーズごとに知財活動の方向性・目的を３段階にわけて設定し、成長フェーズごとに知財活動計画を立案しました。

例えば、プラットフォームの創設期においては新規ユーザ獲得が重要となり、使い勝手のいいシンプルな機能に開発の方向性が向いているため、独自性のある技術を特許化するというよりも、まずは守りを固めるべく知財権侵害のリスクを最小限にして法的安定性の確保に軸足を置いた知財活動を推進します。

このような計画は、知財の観点で一方的にできるものではありません。

知財活動の計画に際しては、開発チームを統括するマネージャにプロダクト開発の方向性をヒアリングして特許取得の判断基準を検討したり、経営層に将来の事業の方向性についてヒアリングをして長期志向で目標設定したりして、ブラッシュアップしていきました。

そういった検討や議論を重ねていくうちに自然と、その企業風土や事業ミッションにあった知財活動計画というものができあがってくるのだと思います。

知財活動ロードマップで現在位置を把握しつつ定期的に軌道修正する

長期的な方向性を可視化したら次はそれをどう実行するかという実行計画が必要になってきました。

そもそも自分たちは今何ができていて、何ができていないのか。またどのようなことを今後やっていかなければならないのかが不明確だよね、という話になり、それを具体的に俯瞰するための知財ロードマッピングというものを作成しました。

縦軸に知的財産の種類、横軸に時間軸であるフェーズを設定して、知財活動の内容に過不足ないかをチェックできるようにしました。

定期的に内容を見直してメドレーの事業規模にあった形に修正しながら自分達の現在位置を把握し、今後の方向性を見定めるためのツールとして有効でした。

このようなロードマップがあれば、知財担当者の立場からすると、実績が可視化されるため知財活動を推進していく上での達成感もありますし、逆に知財担当者を評価する立場からしても、明確な評価基準がない中で、知財担当者の評価をする際に役に立ちます。

以上のように、何もないところから他部門と関わりながら知財活動計画を立案し、ロードマップを達成していくのは、知財部門を立ち上げるという業務の面白さの１つでもあります。

初期段階から長期視点で知財素人でも回せる業務運用作りをする

1 人法務や 1 人知財担当という状況は、遅かれ早かれ属人化という問題が必ずやってきます。

属人化は組織運営上、健全ではありません。

そのため、知財に関する知識がない人間でも、誰でもその業務を回すことができるような状態をつくるために、知財部門立ち上げの初期段階から、自分が担当している業務でルーチン化できるものは全て仕組み化してドキュメントに落とし込むようにしていました。

例えば「怪しい特許を見つけた場合の動き方」、「発明報奨金の決定プロセス」、「他社特許調査及び発明発掘のハイブリッド調査の進め方」などなど、ありとあらゆるプロセス業務を全てフロー図や概念図を作成し、誰か見てもわかる業務ということに留意しています。

現状はまだ引き継ぎや新たな知財部員の登用という話がないので、わかりやすい効果を発揮しているわけではないのですが、他部門からの問い合わせがあった際は資料だけ渡せば理解してもらえるので、コミュニケーションの効率化には貢献していると思います。

どのような特許を取得すべきなのか

企業としてどのような特許を取得していくべきか、ということは「知財を最大限に活用する」という知財の出口から考えていく上で、重要な事項になります。

そしてどのような特許を取得するかは、事業領域や事業ミッションに沿って設定されるべきです。

メドレーは、オープンプラットフォームによる医療のあり方の変革を目指している企業なので、開発チームから上がってきたアイデアについては、プラットフォーム事業を適切に運営していく上で必要な技術かどうか、という観点で特許化するかどうかを判断しています。

例えば、最近特許を取得した**医療データの管理方法（特許第 6921177 号）**というものがあります。これは、アプリ端末から入力された患者データと、医療機関の各業務システムから入力された患者データという 2 つの類似したデータをシームレスに管理するために、両方のデータを 2 つのデータベース上で統合管理することにより、データ管理の責任分担の明確化及び厳格な情報管理を可能にするというものです。

仕組みとしてはとてもシンプルなのですが、患者の持つ端末と、医科・歯科・調剤等の各業務システムをシームレスに連携させる仕組みが、医療プラットフォームを適切に運営していく上で必要な技術だと判断したため、特許化しました。

また、上記事例のように実際にプロダクトに実装されている技術を特許化したものだけでなく、実際にプロダクトに実装するかわからないけれども将来を見据えた先見的な特許として、**ブロックチェーンを用いた電子処方箋の管理方法（特許第 6936763 号）**という特許を取得しています。

これは、ブロックチェーンを用いたアクセス権の管理機能として全体的に秘密状態を保ちながら電子処方箋を管理するためのアクセス制御に関する仕組みで、ブロックチェーンデータベース上において処方箋データと患者データとを紐づけて、医師端末からの患者レコードへの一時的なアクセス権限を付与し、会計終了時に患者端末の操作に応じて医師端末へのアクセス権限を剥奪するというものです。

このような特許を取得した背景には、マーケットを独占して権利主張をするためというよりも、メドレーが考える未来のプロダクトビジョンであったり、開発部門の先見的な創作活動を対外的に発信したい、という思いがあります。

メドレーは、顧客利用率の高いプロダクト、機能拡張性の高いプロダクトの開発を推進しているため、**独創的で最新技術を取り入れた尖った機能を目指すというよりはユーザにとって使いやすいシンプルさが多く取り入れられています。**また、それだけではなく、前述したブロックチェーンと電子処方箋との組み合わせ技術の先見的な特許取得のように、10 年先を見据えた未来のプロダクトのあり方についても日々追求しています。

特許を身近に感じてもらうためのユニークな話も取り入れて社内に啓蒙する

いい特許を生み出すためには地道な社内の啓蒙活動も重要です。

メドレーでは、開発チーム間の技術格差の是正や、技術情報の共有による活性化を目的として、エンジニアが日々の業務で扱っている技術や取り組みについて共有するテックランチという勉強会が定期的に開催されています。

先日そのテックランチで、社内のエンジニアの方達に少しでも特許を身近に感じてもらおうと、「特許の頭体操」というコーナーを設けて、実際に頭を使って体験してもらいました。

下の例では、おたまとスプーンとの違いを考えようというお題を通して、ある物の特徴を把握する際に、「違い」から「もの」を観察すると、その物の特徴が浮き出てくる、というメッセージが含まれています。

おたまもスプーンも対象物をすくい上げるという機能においては共通しているのですが、おたまの先端のお皿部分とスプーンの先端のお皿部分とは、その形状が異なります。スプーンのお皿部分は楕円形ですが、おたまのお皿部分は円形になっています。

つまり、おたまの特徴は、特許的にいうと「その先端にあるお皿部分が円形の開口を有した半球状で、対象物をすくうための所定の深さを有している」ということになります。

この辺はちょっと固苦しい表現が続いたせいもあり、「難しい…」というコメントをもらいました。馴染みのない人にとってはただただ面倒な作業だと思います。

しかし、ここで言いたかったのは、これはあくまで構造物についての話であって、ソフトウェアの特徴を把握するということはそんなに難しいことではないのだよ、ということでした。

ソフトウェアの場合は、ちょっとした機能を追加すれば、それが従来のソフトとは異なるものとなり、比較的簡単に特許になってしまうケースが少なくありません。

つまり、エンジニアの方は日々新しい機能を実装すべく開発業務を行っているわけなので、知財の観点から言うと、極端なことを言えば日々発明をしているということになります。当然特許になるかどうかは別の話になりますが、日々の開発業務で自分が発明をしていることに気づいていない、という状況が多分にあるということです。

さらに、知財担当がこれに気づかなければ、日の目を見ることない埋蔵知財が量産されるということになってしまいます。

では、どのようにしてエンジニアの方が自ら発明をしていることに気づいていないものを発掘し、社内の知的財産として認定していくのか、というのが次の話になります。

面白いアイデアは雑談から生まれる

日々の開発業務の延長で生まれてくる機能や技術を特許化するという活動が基本であることは間違いないのですが、実際にプロダクトに実装するかどうか不確定要素を多く含むアイデアを特許化するという活動は、エンジニアの開発成果物を知的財産として見える化することで、エンジニアの成果が報われる土壌を作るという意味においては大切な活動になってきます。

ただ、どの企業知財部でも発明発掘業務はされていると思いますし、「アイデアは雑談から生まれる」ということは既に周知の事実かもしれません。また、知財活動として特段新しいことをしているわけではないのですが、実際にそれを実行する際の心構えであったり、具体的に気をつけていることについて、事例を通してご紹介したいと思います。

私は、エンジニアの方というのは、アイデアの卵をもっているという前提に立ってエンジニアの方とコミュニケーションをとるようにしています。

そうすると、「実はアイデアありますよね、なんで言ってくれないんですか〜。」という具合にカジュアルな会話をスタートすることができ、スムーズにブレストを進めることができたりします。大したことではないのですが、意外とこういう心がけが円滑なコミュニケーションを生み出すきっかけになっているかもしれません。

一方で、エンジニアの方は暇ではありません。

日々の開発では、既存機能の修正や新規機能の開発などの案件に追われるため、頭の中にあるアイデアの卵も埋もれてしまいがちです。

以上のことを踏まえ、エンジニアからアイデアを出してもらうためのブレスト MTG では主に以下の点に気をつけています。

エンジニアの方の負担にならないように短時間に設定すること（長くて 30 分）
カジュアルに話しやすい雑談ベースの雰囲気にすること
そのために少人数で行うこと
出てきたアイデアを楽しむこと

実際に下図に示すような雑談ベースの会話から、「診療方式を患者と医療機関との間の距離に応じて、対面診療かオンライン診療かを自動的に切り替える」というアイデアが生まれ、実際に特許出願につながりました。

この時にエンジニアの方々からは「とても面白い！」とか「またやりたい！」という前向きなコメントをもらえて、カジュアルベースの雑談効果を実感しました。

このようなブレストを通して一番大きな気づきというのは、エンジニアの皆さん、本当によくプロダクトについて考えているということ。

エンジニアの方々の創意工夫が全て知的財産「権」になるわけではないのですが、知的財産であることには違いありません。

これからは、そういったエンジニアの方の頭の中に埋もれがちな創意・工夫というものが報われるような土壌作りを、知的財産というツールを使って構築していきたいと考えています。

このブログも「特許を対外的にどう見せるか」という実験の１つ

ここまでご紹介してきた内容は、知財計画を立てて、立てた計画に沿って知財業務を運用し、運用していく中でアイデア発掘して知財化する、という話にとどまってましたが、実際に取得した知財権をどのように活用して企業価値の向上につなげるのか、ということがこれからの知財部門にとっての重要なミッションになると考えています。

従来は、特許権の独占排他権という性質を使って参入障壁として活用したり、模倣の抑止に活用されるのが常識だったと思いますが、メドレーではこれまでにない新たな活用方法を模索しています。

実はこのブログもそうなのですが、特許を対外的にどうみせるか、ということの１つの実験です。

どういうことかというと、ここまでご紹介してきた知財活動自体も人の知的活動によって生み出された知的財産であり、このようにブログで発信しなければ単なる埋蔵知財になってしまいます。

例えば、特許取得についてもただ特許を取ったという事実を公表するのではなく、どうしてそのような特許を取得してどのように活用しているのか、またそこに関連したメンバーは誰でどのような検討があったのか、というストーリーメイキングをすると、特許というものを中心とした１つのドラマが浮き上がってきます。

今回は知財活動のご紹介という趣旨で、特許を中心とした内容になっているため、特許に関心がない人にはあまりささらないコンテンツになっているかもしれませんが、例えば特許と広報との掛け算でストーリーメイキングをすれば特許に関心がある人だけでなく、広報に関心がある人にも情報がリーチすることになります。

これは特許というものが、人材・業務ノウハウ・広報・採用活動等と同列に知的財産であるがゆえになせるものです。これからは、知的財産＝特許、商標という視点ではなく、知財＝目に見えない創造的な活動という捉え方をした上で、企業価値に貢献していく必要があります。

知財部門が、採用、IR、広報、開発、社内 IT といった企業内にある多数の部門とコラボレーションすることでこれまで見たことのない新しい知財活用の形を模索し、知財を最大活用することによって企業価値を向上させていきたいと考えています。

さいごに

ここまで、知財活動の一部をご紹介させていただきましたが、これが知財活動の進め方として正解というわけではなく、企業風土や事業領域によって、知財活動のあり方は異なります。そして、そこを考えながら知財活動を推進していくことが仕事の面白さであり醍醐味とも言えます。新しい知財部のあり方や、新しい知的財産の活用方法を検証しながらも、建設的かつ柔軟に日々の業務を進め、メドレーの事業をしっかりとバックアップしていきたいと考えています。少しでも当社の知財活動が参考になれば幸いです。最後までお付き合い頂きありがとうございました！

サービスのダウンタイムなく RDS を Aurora に移行した話

Mon, 08 Nov 2021 09:01:20 GMT

こんにちは、人材プラットフォーム本部プロダクト開発室第一開発グループ所属の森川です。医療介護求人サイト「ジョブメドレー」の開発チームの一員として、現在はインフラタスクをメインに取り組んでいます。

今年（2021 年）の 6 月の話ではありますが、ジョブメドレーの連携サービスにて使用しているデータベースを、通常の RDS（Amazon RDS for MySQL）から Aurora（Amazon Aurora）に移行しました。

タイトルは自分でも大きく出たなと思ってはいるのですが、サービスの特性に助けられたところはありつつも、ダウンタイムなく移行することができました。今回はそのいきさつについてお話させていただこうと思います。

本稿では Amazon RDS for MySQL を「通常の RDS」、Amazon Aurora を「Aurora」と表記させていただきます。

ジョブメドレーの連携サービスについて

ジョブメドレーは医療介護従事経験者が運営する就職・復職・転職のための求人サイトです。このジョブメドレーの連携サービスとして医療・介護・福祉・歯科従事者向けの情報サービスを他社と共同運営しています（以降、本サービス）。

本サービスはアプリケーションシステムのバックエンドの開発フレームワークとして Ruby on Rails（以降、Rails）を使用し、弊社で開発・運用を行っています。表示コンテンツは他社から共有していただくものを表示する形となっています。

発端

今年の 1 月末に AWS から以下のようなメールが届きました（内容を一部抜粋しています）。

Amazon RDS は、MySQL メジャーバージョン 5.6 の廃止 (EOL) プロセスを開始しています。

お客様は古いバージョンで実行されている RDS MySQL インスタンスを１つ以上お持ちであるように見受けられます。

Amazon RDS for MySQL 5.6 は、UTC 協定世界時間の 2021 年 8 月 3 日に廃止されます。

公式のお知らせはこちらです。

EOL 通知はドキッとします。できれば見たくないものです。

この対象となっていたのが、本サービスで使用している RDS の MySQL v5.6.39（当時）でした。

対応方針として以下を考えました。

通常の RDS のまま MySQL のバージョンを 5.7 に上げる
通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる
MySQL のバージョンを 8 まで上げる

MySQL 8 系へのバージョンアップは対応範囲が大きくなりすぎるため今回は断念しました。5.6 の EOL 期限が迫っているため時間の余裕はあまりありません。また、もし 8 系に上げるとしても、5.7 へのバージョンアップは挟む必要がありそうです。

ジョブメドレー本体のシステムにおいても、性能やメンテナンス性の向上の観点から、通常の RDS から Aurora への移行を計画しております。その足がかりとして、関連アプリケーションの中でも比較的システム規模の小さいものから、先行して移行作業をしておきたいという要望がありました。

これらを加味して、今回のミッションは「通常の RDS から Aurora への変更も行いつつ、MySQL のバージョンを 5.7 に上げる」となりました。

検証

インフラ構成に変更を加える際には言うまでもなく検証が必要です。インフラ関連タスクに取り組むにあたって大きなウェイトを占めるのが検討・検証なのではないかと個人的には考えています。

Aurora への乗り換え検証のために、新たに DB インスタンスを用意しました。既存相当のスペックの通常 RDS とそれよりも少しスペックの落とした Aurora です。正確な比較を行う場合であれば、両 DB インスタンスのスペックは揃えるべきかとは思いますが、現行の RDS がオーバースペックであることも課題のひとつであったため、検証段階から Aurora のスペックを落として検証を行っています。よって検証結果による成否判断としては「著しい悪化が見られないか」という観点になっています。

既存相当の RDS のスペックはdb.m4.large 、Aurora のスペックは暫定的にdb.t3.mediumを選択しました。また、データベースに流し込むデータは本番相当のものを個人情報などはマスクした上で用意しています。

検証の項目は以下の 4 点です。

レスポンスタイム検証
SQL ごとの速度検証
実行計画の検証
フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証

レスポンスタイム検証

まずは、レスポンスタイムの影響について確認しました。

本サービスにおける主要なページの URL を選出します。それぞれのページに対して数回のリクエストを行い「低負荷状態」でのレスポンスタイムを比較しました。Aurora の方が一桁ミリ秒程度遅いという結果となりました。

次にApache Benchを用いて短時間に並列でのリクエストを行い「高負荷状態」を再現して比較を行いました。本サービスはスパイクで負荷が高まるような性質ではないため、普段のアクセス頻度を元に「高負荷状態」がどの程度かを想定して定義しています。結果として、一部のページにて 1 秒ほど遅くなっていることが分かりました。スペックを上げることで解決ができるのかを調査するため、インスタンスサイズをdb.t3.mediumからdb.t3.largeに変更して改めて試しました。しかし Aurora の方が遅いという結果に変化は見られませんでした。アプリケーション側の調査を進めると、データベースの問題ではなくアプリケーション側の問題であることが分かり、別途対応ということになりました。

以上より、Aurora への移行によるレスポンスタイムへの影響としては、多少の性能の低下は見られたものの許容範囲内であり、大きな問題は見られないことが分かりました。

SQL ごとの速度検証

こちらはレスポンスタイムの検証に近しい検証ではありますが、生の SQL の速度の調査も行いました。アプリケーションを通して実行される SQL の中でも実行される頻度の高いものを選出し、アプリケーションを介さずクライアントツールから実行しています。

こちらも大きな問題は見られませんでした。

実行計画の検証

この検証でもアプリケーションの中で実行される頻度が高いクエリを選出し調査を行いました。使用したのはお馴染みのEXPLAINステートメントです。

実行計画に差分は見られなかったため問題はありませんでした。

フェイルオーバー後に元 writer に対する接続が継続される問題への対応検証

Rails アプリケーションへの Aurora 導入において、必ずと言ってよいほど障壁となるのがこの問題かと思います。

Aurora のフェイルオーバーと Rails への影響

Aurora の特徴や通常の RDS との差分については様々なサイト・記事で詳しくまとまっている情報ですので本稿での詳解は割愛しますが、Aurora のフェイルオーバーについてのみ概要を説明させていただきます。

マルチ AZ での Aurora DB クラスターのプライマリ DB インスタンス（writer と呼ばれる）において障害が発生した場合、フェイルオーバー（待機システムへの切り替え）が自動で実行されます。プライマリ DB インスタンスのリードレプリカ（reader と呼ばれる）を配置していた場合は、それが次のプライマリへと昇格し、エンドポイントも切り替わってくれます。

次に Rails の ActiveRecord のコネクションプールについてです。ActiveRecord はデータベースへの接続情報を保持し、そのコネクションを再利用することで接続時のオーバーヘッドを解消し、高速化を図る仕組みを保有しています。本サービスにおいて MySQL のクライアントとして使用しているmysql2では、コネクションがアクティブであることをmysql_pingが判定してくれるようです。しかし残念なことに Aurora 側でのフェイルオーバーの発生までは検知することができないようです。

したがって、フェイルオーバーが発生すると、プライマリから降格した元 writer 現 reader である DB インスタンスに対してコネクションが張り続けられてしまうため、書き込みのリクエストに対してはエラーとなってしまう状態になります。

対応策

対応策としては以下を考えました。

Aurora 用のクライアント Gem を使用する
Mysql2::Error が発生した場合、サーバーエラーにしつつコネクションを切断して再接続を促す
一定回数リクエストを処理するごとに再接続させる

今回採用したのは上記の 3 の「一定回数リクエストを処理するごとに再接続させる」対応です。

当初は対応策 1 の Gem の使用を検討しておりましたが、トランザクション中にフェイルオーバーが発生した際の挙動が本サービスには適合しないことが分かりました。またいくつかの対応策を複合して実装するという方法も考えられました。

今回においては、実装工数や、サービスの規模から考えうる必要十分の最小値を検討した結果、この判断としています。

再接続の度に発生するオーバーヘッドによる速度影響についても低負荷・高負荷の状態で検証を行いましたが、数値的には軽微であり、少々の遅延は許容することになりました。

この対応は、Aurora への移行の前、つまり通常の RDS で稼働している状態であってもリリースして問題ないものだったため、事前に実装・リリースを行うことができました。

料金

「現行の RDS がオーバースペックであることも課題のひとつ」と上記しておりましたが、その是正による料金の合理化についても副次的効果として期待していました。

Aurora の料金形態には、通常の RDS と同じ「DB インスタンス時間従量課金」「ストレージ時間従量課金」に加え、「I/O リクエスト数従量課金」という項目が追加されているため、比較を行う際は注意が必要です。

移行前後の条件は以下の通りです。

通常の RDS（移行前）
- オンデマンド
- RDS で稼働しているのは本番環境のみ
- db.m4.large
- ストレージ 100GB
Aurora（移行後）
- オンデマンド
- 本番環境だけでなく検証環境も Aurora で稼働させる
- 本番環境 db.t3.medium, 検証環境 db.t3.small
- ストレージ 100GB（両環境とも）

移行前の通常の RDS では本番環境のみで月々 4 万円以上かかっていたコストですが、移行後は本番環境に加え検証環境においても Aurora を使用するようにしても合計 3 万円以下という計算となりました。月々 1 万円、年額 12 万円の節約になります。さらにはオンデマンドからリザーブドへ変更することも今後検討ができるため、コストカットの余地がまだ残されているのも嬉しいところです。

リリースに向けた準備

リリース作業のキモとなるデータベースの切り替えは、「リードレプリカからの昇格」という方法を採ることとしました。MySQL のバージョンアップについては、プライマリが通常の RDS から Aurora に切り替わった後に、Aurora インスタンスの MySQL バージョンを上げるための変更を実行します。

これらの作業をデータの不整合を発生させることなく完遂させるためには、データベースへの書き込み動作をすべて停止させる必要がありました。

これを実現するためには、データベースへの書き込み処理が発生するケースをすべて洗い出さなければいけません。調査をしたところ、本サービスでは「社内管理画面」と「バッチ処理」でのみ書き込み処理が実行されていることが分かりました。

つまり、一般ユーザからの書き込み処理は本サービスでは保有していないため、書き込みが行われるタイミングを把握・調整することが可能でした。したがって、一般ユーザが見ることのできるページをメンテナンスモードに切り替えるなどの「サービスのダウンタイム」を発生させることなく Aurora への移行と MySQL のバージョンアップを行える、ということになります。

リリース時に影響が生じる周辺情報の洗い出しも一通り済んだところで、次に「手順書」の作成に取り掛かりました。必要な全ての操作について順序に沿って詳細にまとめます。その中には、各段階にて万が一障害が発生した場合の切り戻し手順についても記載しています。

手順書を元に、検証環境にて同様の手順を実行し、予行演習を行いました。これによって、本番での作業を鮮明にイメージすることができます。また大抵の場合、手順書の不備やブラッシュアップできるところが見つかります。予行演習は本番作業を滞りなく実行するための最も重要なファクターのひとつかと思います。

実際に使用した手順書（一部抜粋）

リリース作業

リリースで行った作業の要点をまとめると以下となります。

本番用データベースのリードレプリカを Aurora で作成
データベースへの書き込みを停止
- 社内管理画面の操作を停止いただくよう社内へのアナウンス
- バッチ処理の実行をすべて停止
レプリカ Aurora をプライマリへ昇格
データベースのコネクション更新のためサーバ 1 台ずつアプリケーションの再起動
バッチ処理の再開
動作確認

大きめのリリース作業はアクセスの多い時間帯を避けて行われることもあるかと思いますが、今回はサービスのダウンタイムなく作業を行えるケースであるため午前中からの作業開始となりました。また作業を行う自分の隣には先輩社員が構えており、ダブルチェックをしていだきました。

手順書の作成と予行演習の甲斐もあって、本番リリースを問題なく進めることができました。

まとめ

サービスの特性に助けられたところは大きいですが、サービス停止などのダウンタイムを発生させることなく通常の RDS から Aurora への移行を完了させることができました。

スティーブ・ジョブズは数分のプレゼン発表のために数百時間の準備をしていたといいます。プレゼンで言うところのシナリオの作成とリハーサルの実行もそうですが、サービス特性の理解や検証を綿密に行うことも本番を成功させるためには欠かせません。準備を怠らないエンジニアでありたい、と執筆しながら改めて感じているところです。

さいごに

メドレーでは「医療ヘルスケアの未来をつくる」というミッション実現のため、日々開発・運営を行っています。エンジニア・デザイナーをはじめ多くのポジションでメンバーを募集しております。もし少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話しさせていただければと思います。

最後までお読みいただき、ありがとうございました。

2021 年度新卒エンジニア研修について

Tue, 12 Oct 2021 09:01:47 GMT

こんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。今年の新卒エンジニア研修において、メンターを担当しました。

メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。

例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。

新卒研修の概要

今年の新卒研修の最終ゴールは、「メドレーのエンジニアとして、Our Essentials(※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること」として掲げました。

※) メドレーの行動原則

メドレーの新卒エンジニア研修では、技術を身につけることだけではなく、ビジネスパーソンとしての基礎を身につけ、メドレーが大切にしている価値観を理解し、体現する意識をもって、顧客への価値提供について自分の言葉で話せるようになることまでを目指してもらいます。

研修は昨年同様、大きく分けて、4 つのフェーズに区切って行いました。

また、全研修期間を通じて、各新卒にはメンターを一人ずつ付けました。メンターは、一週間に 1~2 回のペースで新卒と 1on1 ミーティングを実施し、フィジカルとメンタルの両面を気遣い、個別にフォローを行いました。

新卒研修の内容

フェーズ 1：社会人&メドレー基礎研修

リスク研修

インサイダー取引防止研修
コンプライアンス研修
情報セキュリティ研修

ビジネス研修

ビジネスマナー研修
ビジネススキル研修
ビジネススタンス研修（外部研修）

フェーズ 1 では、成果を出し、価値を発揮するために必要なビジネスパーソンとしての基本的な仕事の型を身につけることをゴールとしました。

リスク研修では、メドレー社員として、社会人として、身の周りで起こりうるリスクについて考え、いかにそれらのリスクと向き合うかを講義形式で学んでもらいました。

ビジネス研修では、社会人としての最低限のマナーを学び、論理的思考力、コミュニケーション力など、エンジニア職に限らない課題解決力へつながるポータブルな知識を、座学とワークショップを通じて定着してもらうことを図りました。

また、社会人の基準で仕事と向き合い、適切な報連相によって周囲と協働していくことの重要性についても学んでもらいました。

新卒からの声

質の高い、多量のインプット・アウトプットができた

伝わるメールの書き方、名刺の渡し方など、社会人に必須のマナーやスキルを認識できた

ワークを通じて、言葉では理解していても行動するとできないことを洗い出せた

フェーズ 2：エンジニア基礎研修

開発基礎 1

メドレーエンジニアとして求めること
事業（ジョブメドレー・ CLINICS ・介護のほんね）の概要説明
開発基礎研修（Ruby on Rails チュートリアル）
開発実践（要件定義〜リリースまで）

開発基礎 2

技術書の輪読会
ドキュメンテーションスキル研修
プレゼンテーションスキル研修
中間レポート作成
中間報告会

フェーズ 2 では、新卒研修後に開発業務に入ってもらえるよう、エンジニアとしての基礎を身につけることをゴールとしました。

メドレーエンジニアとして求めること

開発に関わるこのフェーズにおいても、要件定義を含む汎用的な技術的スキルは勿論のこと、メドレーエンジニアが共通して持つべき価値観などを共有するため、フェーズ 2 初日は「メドレーエンジニアとして求めること」と題して、エンジニアの執行役員田中が講義を行いました。

講義では、「エンジニアとは、エンジニアの価値とは、プロエンジニアとはなんでしょうか？」という問いから始まり、講義の終わりにはもう一度同じ問いかけをして締めくくり、新卒がメドレーの求めるエンジニア像について自身の言葉で話せるように考えてもらいました。

メドレーが求めるエンジニア像については、CTO 平山のメドレー平山の中央突破: THE エンジニアにも書かれていますので、よろしければ、あわせてご覧ください。

さらに、メドレーが展開する各事業および関連するプロダクトの概要説明をプロダクトマネージャーが行い、メドレーで開発する意義をあらためて認識してもらいました。

開発基礎研修

2 日目より、Ruby on Rails チュートリアル（以下、「Rails チュートリアル」）を教材とした、開発基礎研修に移りました。

メドレーのプロダクトは Rails で作られているものが多く、Web アプリケーションを開発するための基礎を身につけるためにも、Rails チュートリアルの内容を実施してもらいました。

単純に、Rails チュートリアルの内容に沿って、ダラダラと写経するのではなく、随時、学んだことは Confluence にまとめ、GitHub 上で Pull Request を作成する形で、ソースコードを共有してもらいました。

学んだことを自分の言葉に置き換えてアウトプットすることで反復学習を促し、Pull Request を作成してもらうことで GitHub の使い方に慣れてもらうことを図りました。

また、デイリーで朝会と夕会を実施しました。朝会は仕事のリズムを整えるための顔合わせ、夕会は新卒から質問・成果を共有してメンターがそれに対してフィードバックをする場としてそれぞれ実施しました。

研修前に既に Rails チュートリアルを一周していた新卒もいましたが、二周目を実施して新たな気付きを得たり、AWS を用いてクラウド上に環境構築し、作成した Web アプリケーションをデプロイするまでを実践してもらうなど、インフラに関しても理解を深めてもらうことができました。

新卒からの声

システムのパフォーマンスを上げるための工夫を知ることができた

バグ発生〜原因特定〜修正、というデバッグのスピードが、研修序盤から飛躍的に上がった

プロダクトで利用している AWS の各種サービスの概要を理解できたことに加え、サービス間の繋がりやネットワークの流れに関しても理解を深めることができた

開発実践

開発基礎研修にて Web アプリケーション開発の基礎を学んだ後は、「メドレー/グループ会社で使う来訪者受付システム」を開発題材として、開発実践研修を行いました。

開発業務全体の流れを把握することで、チームで開発（課題解決）することを経験し、今後の仕事に役立たせることを目的としました。

本研修で達成すべきこととして掲げていたものは主に、次の通りです。

プロジェクト管理能力を身につけること
開発する対象を体系的に整理できる能力を養うこと
システム設計に関する基礎的な物事を理解すること
チーム開発を理解すること
品質を理解すること

既に決まりきった仕様書に沿って開発するのではなく、新卒自身が現状の問題把握や課題整理を行って、ユーザーへ価値提供するために何を作るべきかを考えることから始まり、リリース後の運用方法やランニングコストのことまで考え提案してもらいました。

開発実践研修は約 1 ヶ月の期間をかけて行いました。大まかな流れとしては、次の通りです。

要件定義（ヒアリング・現状把握・課題整理・要求分析・機能/非機能要件の洗い出し・ UI 草案）
プロジェクト計画（役割分担・ WBS/ガントチャート作成）
設計（画面設計・機能設計・データモデリング・方式設計・インフラ設計）
開発（実装・コードレビュー）
QA（テスト設計・テスト）
成果発表（成果物を関係者へプレゼン・リリース）

方式設計の一部として、開発に使用する言語などの選定も新卒自身が行いました。

今回作成した社員向け管理画面と来訪者向け画面はいずれも SPA（一部、PWA）のアーキテクチャを採用し、主なライブラリ/フレームワークに関して、フロントエンドはTypeScript, React, Next.js, Chakra UI, Ionic Framework、バックエンドは Ruby on Rails（API モード）をそれぞれ利用することとなりました。

選定理由としては主に、次の通りです。

TypeScript, React（両画面共通）
- ロジックからテンプレートまでの全てのコードを静的型付けで書くことができ、堅牢性に優れているため
Next.js, Chakra UI（社員向け管理画面）
- ゼロコンフィグでビルドやレンダリングを最適化できるため
- アクセシビリティに優れたリッチな UI を素早く構築できるため
Ionic Framework（来訪者向け画面）
- iPad 上で、ネイティブアプリのような UI/UX を提供するため
Ruby on Rails API モード
- フロントエンドとバックエンドを分離して疎結合にするため
- 短期間で構築するため
- 社内でもよく使われておりメンテナンスしやすいため

インフラは AWS を採用し、EC2, S3, RDS, CloudFront, Route53, CloudWatch などのサービスを利用しました。

結果的に、本研修プログラムの成果物としてリリースされたシステムは「Medley Entrance」という名前で、社内ツールとして現在、毎日稼働しており、ユーザーとしてメドレー/グループ社員だけではなく、来訪者の方々にも使っていただいています。

Medley Entrance（上：社員向け管理画面、下：来訪者向け画面）

チームで課題解決に臨み、価値提供までの実績を残せたことは自信につながり、開発実践研修のやりがいとして、感じてもらえたのではないでしょうか。

要件定義などの期間中、想定よりもスムーズに進められなかった時も他責にせず、各々がリーダーシップを発揮し、建設的に進めていく新卒の様子をメンターの一人として傍で見させてもらいました。

この 1 ヶ月間の開発実践研修を通じて、技術力はさることながら、課題解決に対する十分な熱意と主体性を新卒から感じられ、とても頼もしい印象として残りました。

新卒からの声

開発の中での方針を意識して設計/実装することができた(シンプルにする)

QA とはそもそも何かというリサーチから入り、有識者の考え方を軸に方針を決めてから始められた

各々が最適なパフォーマンスを発揮できる環境づくりを意識して、高速な意思決定が可能な体制を整えることができた

要件が決まりきっていない中で設計するのは難しかった

開発タスクが集中していた時に、プロジェクト全体の現状を把握できていなかった

文章を作るスキルが足りていない

技術書の輪読会

フェーズ 2 の開発基礎 2 の輪読会では、『Web を支える技術 -HTTP、URI、HTML、そして REST』を題材書籍として、7 日間に渡って毎日、次の手順で実施しました。

参加者が同じパートをあらかじめ読んでおき、書籍から学んだこと、ネットなどで調べても解消しきれなかった疑問点などをまとめる
その内容をもとに、夕方のミーティング時において、各自が発表してディスカッションを行う
ディスカッションした内容は議事録にまとめる

輪読会は他者からの学びを共有してもらうことで、自分にはなかった視点・気付きを獲得し、その書籍への理解をより深められる効果があります。

本研修プログラムにおける輪読会の目的としては、Web サービスを開発していく上で必要となる知識へ触れることにより、今後獲得していくべき知識のベースラインを理解すること でしたが、輪読会ならではのメリット・楽しさを新卒に実感してもらえたことも、副次的な効果としてあったと思います。

新卒からの声

Web の基本的な知識を「なぜ登場したのか」を理解しながら網羅的に学ぶことができた

文書でまとめた後に、口で説明することが学んだ内容の定着に良いと感じた

これまでなんとなく実装していたことの仕組みを学ぶことで、知識として定着することができた

中間報告会

フェーズ 2：エンジニア基礎研修最後の研修プログラムである中間報告会に向けて、ドキュメンテーションスキル研修、プレゼンテーションスキル研修を実施しました。

上記スキルが必要となる背景は、次の通りです。

エンジニアリングを通じた課題解決とはプログラムを書くだけでは解決しない場面もある
背景、目的を正しくステークホルダーへ共有しながらチームとして取り組んでいくことになる
伝えたいことを文章として整理し、他者へ分かりやすく伝えていくことが求められる

また、メドレーの行動原則 Our Essentials を構成する要素として、「ドキュメントドリブン」「全てを明確に」という項目が含まれており、これらを実現するためにも、とても重要なスキルとしてメドレーは考えています。

新卒研修が終わった後も、エンジニアとして技術的なスキルを身につける機会は日常的に多くありますが、上記のようなスキルをまとめて習得する機会は少ないため、このような研修を社会人のはじめから受けておくことで、その後の伸びしろが違ってくるのではないかと思います。

研修が終わった後は、各自で報告会用の資料を作成し、研修講師からの添削を受けました。

中間報告会は各部署の開発マネージャーを発表相手として、当日は程よい緊張感をもって、良い雰囲気で報告会を終えられました。

フェーズ 3：事業部 OJT

事業部研修

取締役豊田からの講義
CLINICS 事業部研修
ジョブメドレー事業部研修

開発 OJT

システム全体像説明
環境構築
各プロダクトの開発チームでの OJT

フェーズ 3 では、顧客の課題と、顧客への価値提供のための各チームの連携を体感し、メドレーの顧客提供価値を自分の言葉で話せるようになることをゴールとしました。

フェーズ 3 のはじめに、取締役豊田による日本の医療の課題とメドレーの取り組みに関する講義を受講してもらいました。

持続可能な医療体制を構築していくためにメドレーが成すべきことなどの話を聞いた後に、新卒からの質問の受け答えによって理解を深め、メドレーの社会的意義をあらためて認識してもらい、エンジニアとしてだけではなく、メドレー社員としての自覚を強めてもらいました。

事業部研修

開発 OJT で手を動かす前に、自分たちが何のために開発するのかを具体的にイメージできるよう、次のように、各現場に参加してもらいました。

見込顧客への架電業務見学
商談前の社内ミーティング参加
商談現場同席
定例会議参加

事業部のスタッフが、顧客の課題に対して、どのような対応をしていて、どのようにプロダクトを説明しているのか、事業部の各チームが、どのように連携して最終的に顧客に価値を届けるのかの全体観を知ってもらうことを狙いとしていました。

開発チームのエンジニアは業務上、プロダクトのエンドユーザーである顧客の声などを商談のタイミングから聞ける機会はなかなか無いので、研修を通じて話を聞けたことは、今後の開発モチベーションにも影響する良い機会だったと思います。

新卒からの声

ユーザー、顧客、事業部が抱える課題を確認できたことで、開発以外にも目を向けるきっかけになり良かった

各部署が KPI として定めている数字を知ることができ、開発に降りてきている施策の影響箇所がどの部分かを理解できた上で、開発に取り組むことができるようになった

各部署のミーディングに参加することで、各部署がどのような考えで何を目指しているのかを理解でき、メドレー全体として目指している方向性が掴めた

開発 OJT

事業部研修に続く開発 OJT では、ジョブメドレー、CLINICS、介護のほんねの開発チームに分かれて、研修を実施しました。

OJT 配属先では、メンターとは別に、トレーナーを付けて業務の進め方などをサポートしました。トレーナーは配属先の先輩エンジニアが担当しました。

OJT の流れとしては、初日に、プロダクトがどのように動いているのか、システム全体像を把握することから始まり、各自、ドキュメントに沿って、PC にローカル開発環境をセットアップしました。

その後は、他の先輩エンジニアと同様に、GitHub Issue で管理されている課題を解消することを日々の目標としてこなしてもらいました。ただし、単に Issue に書かれている課題をクリアしようとするのではなく、そもそも、なぜそれをやるのか、Issue の背景や起票者の意図を十分に理解した上で、プロダクトのあるべき姿に導くことを意識してもらいました。

Issue に書かれている内容の理解が不十分だったり、解決方針がうまく定まらない場合は随時、ミーティングの時間を設けて、Issue 起票者やトレーナーと認識合わせを行い、認識の相違から生まれるミスコミュニケーションを極力減らすよう、取り組みました。

技術的な質問に関しても、定期的に質問タイムを設けたり、複雑になりそうな実装や、つまずきポイントとなりそうな箇所に関しては、画面共有を用いてレビューを行い、疑問点に関してもその場で確認して、解消してもらいました。

緊急事態宣言期間中だったため、会社全体で原則、在宅勤務の体制となっており、対面でのコミュニケーションが希薄になりがちでしたが、朝会、夕会を含め、たとえ新卒から質問が無くても質問タイムでのミーティングは定期的に実施するなど、できるだけ頻繁に顔合わせして、新卒本人の声と顔を確認するよう心がけました。

Issue へのアサインから始まって、実装 -> レビュー依頼 -> QA -> リリース -> Issue 起票者への報告まで、一連の開発フローを経験してもらい、チーム内での開発業務に慣れてもらうことができました。

フェーズ 4：最終報告

新卒研修最後のプログラムとして、メドレー役員陣に向けた最終報告会を実施しました。

最終報告会の目的としては、次の通りです。

学んだことの知識を深化させる
自らの得手・不得手を捉え、将来の成長計画を立てる
体系的に整理・文書化して他者へ伝えるスキルを向上させる
役員陣に向けてプレゼンすることで、本配属に向けた決意表明として区切りを付ける

役員陣への発表であることに加え、一人あたりの発表時間にも制限が設けられており、当日の緊張はかなりのものだったと思います。

前日に発表会場を下見して、リハーサルを入念に行うなど、当日の発表会を成功させるため、メドレーのエンジニアとしての自覚を持って、発表準備に取り組んでいました。

技術志向とプロダクト志向の両輪を目指すエンジニア募集中

メドレーの研修では、技術的な講義や実践だけで終わるのではなく、ビジネスパーソンとして必要な基礎も身につけ、なぜ開発するのかを追究し、プロダクトを通じた課題解決を実体験してもらうことを重視しています。

メドレーでは、医療ヘルスケア分野の課題解決に挑みたいエンジニアを募集しています。

新卒の学生に限らず、中途採用も行っているので、エンジニアの方で少しでも興味を持っていただけたら、是非、面談でお話ししましょう。

最後までお読みいただき、誠にありがとうございました。

P.S.

昨年、一昨年の新卒研修の様子はこちらより、それぞれご覧いただけます。

新卒エンジニアが 2 年目でプロジェクトリーダーを経験して得た学び

Wed, 01 Sep 2021 09:03:51 GMT

はじめまして。メドレーのエンジニア熊本です。新卒で入社し今年で 3 年目になりまして、2019 年度エンジニア新卒の研修を終えてから早 2 年が経とうとしています。

そんな私ですが去年の 11 月頃から先月までの間、とあるプロジェクトのリーダーを任せてもらっていたので、そのお話をさせていただきます。

はじめに

私は新卒研修を終えてから医療介護求人サイトジョブメドレーのチームで開発をしていましたが、そのジョブメドレーを支える社内管理システムのリニューアルプロジェクトに初期から携わっていました。

こちらのプロジェクトにつきましては、弊社デザイナーの酒井がデザイナーがデザインツールを使わずに、React を使ってデザインした話を、弊社エンジニアの山田がGraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話を以前ブログにしていますので、よろしければあわせてご覧ください。

その社内管理システムをどのような流れでリニューアルし、その中で自分の役割がどう変化しどう対応したのかなどについて、次の章からお話ししていきます。

プロジェクトについて

リニューアルの背景やシステムの概要については上に紹介した記事でも説明しているため割愛しますが、求職者や求人を掲載する顧客に関する業務を行っているシステムをおよそ 1 年半かけて刷新するという大きなプロジェクトでした。

システムの中でも求職者関連を「Phase1」、顧客関連を「Phase2」として分割し、リニューアルを進めました。

プロジェクト内での自分の役割の変遷

Phase1 の最初期は先輩方がアーキテクチャの設計やスケジューリングをしていました。当時まだ新卒 1 年目で未熟な私でしたが、権限管理のテーブル設計をするタスクをアサインしてもらいました。ここでは詳細を省きますが、初めてのテーブル設計で右も左も分からない状態から責任感を持って何とか形にすることができ、（もちろんリニューアル中に多少の見直しはありましたが）大きな達成感を得たことを覚えています。

各種設計、技術選定、開発の進め方などが大方固まり本格的に開発が始まるわけですが、Phase1 の際は先輩社員がプロジェクトリーダーとして引っ張っていただき、自分は開発メンバーの一員として API の作成などに奮闘していました。

GraphQLといった技術やスケジュールが厳密に引かれたプロジェクトでの開発など初めて経験することも多々ありましたが、先輩方にサポートをいただいたり、同期と切磋琢磨しながら取り組めたおかげで、Phase1 を乗り切ることができました。

さて、ここからが本題になりますが、Phase2 になるとプロジェクトメンバーの入れ替えや私自身の目標設定も重なり、プロジェクトリーダーを任せてもらうことになります。まずはプロジェクトリーダーに任命されてから、どういった仕事をしていたのかご紹介します。

プロジェクトリーダーの仕事

プロジェクトリーダーとして期待されていたことは以下の通りです。

プロジェクト管理
システム設計
開発
チームマネジメント

これを更に細分化し、私の実業務と照らし合わせながら並べてみると、多少粒度にばらつきがあるかもしれませんが以下のようなことが挙げられます。

要件定義・画面設計（ディレクターとデザイナー主導で進めつつ、エンジニアも実データや既存ロジックを踏まえた観点を持ち合わせて参加しました）
開発方針の検討
開発タスクへの落とし込み
技術調査・選定
API 設計
工数算出・スケジューリング
実装・レビュー
QA（Quality Assurance）テスト
リリースマネジメント

Phase2 は段階的にリリースを行ったため、その度に 1 から 9 までを繰り返していたような流れになります。また、上記に加え、定例ミーティングでの報告や開発メンバーのタスクマネジメントも随時行っていました。

もちろん苦労したことは多く、全部を挙げようとするとキリがないのですが、その中でもいくつかに絞った上で紹介したいと思います。

苦労と工夫

1. 「そもそも何をやればいいのか」

まず最初に苦労したことは「そもそも何をやればいいのかわからない」ということでした。初めから先ほど挙げたような動きをイメージできていたわけではなく、記事や本を読み漁ったり先輩との 1on1 で質問攻めにしたりと基本的な知識を叩き込むわけですが、実際にとった最初の動きとしては「できる部分を見つけてやっていく」ということだったと思います。自分がリーダーに任命された時点でのプロジェクトの状況としては要件定義や画面設計が進んでいる最中でしたが、これらがまとまるのを待つのではなく「全部決まらないとやれないこと」と「現時点でやれること」を切り分けて動きました。こうしたところから少しずつリズムを作り、最終的に先ほど列挙したような一通りのことがイメージ・実行できるようになったのだと思います。

2. 工数見積もり

一般的に工数見積もりに関する記事は世の中に多く存在しますが、私の場合は工数見積もりの方法がわからなかったというよりも、「どういう思想で見積もったのか、どういう選択肢があるのか」を曖昧にしていたことが当初の問題でした。

初めて見積もった時は単に開発タスクを積み上げた工数を報告して満足してしまいましたが、様々な方のフィードバックを受けプロダクト価値を高めるためにどういう動きができるのかを考える必要があったことを痛感しました。単純に工数を積み上げる場合や事業的な都合を踏まえてミニマムで開発する場合など、いくつかの選択肢をそれぞれの軸で考える必要があったことを学びました（この時期は夜な夜な夢の中で工数見積もりをしていたのも今ではいい思い出です）。

3. 意思決定

これはいつになっても正解が存在する類のものではないのですが、特に意思決定には苦労しました。意思決定といっても開発方針から技術選定まで様々な粒度のものがありますが、特に最初から苦労したのは技術的な決定でした。

それまで先輩に頼ることの多かった私がプロジェクトリーダーになった直後から何もかもできるようになるわけではないことは明々白々ですが、「自分が決めないと」と焦ってしまっていた時期もあったと思います。

そこで一度立ち止まって意識したことは、「何ができて何ができないのかを他者に明示する」ことでした。はっきりと自分に足りていないことを他者に伝えることで、周りもサポートしやすくなると思いますし、自分自身なにがやれることなのか明確になるので単純なことですが効果的であったと思います。他にも開発メンバーの提案で、インセプションデッキを取り入れてみたことも効果的でした。

また、意思決定とは文脈が少し変わってきますが、モブプロやペアプロを実施してチーム力を高め属人化をなくしつつ開発効率を向上させる取り組みも、時間が経てば経つほど効果を実感できて良かったと思います。このようにアジャイル開発の手法からチームにフィットする手法をいくつか取り入れることもできました。

プロジェクトを通して成長したこと

これまで小出しで色々とお話しさせていただきましたが、自分が特に成長したと感じていることをまとめさせていただきます。

一通りの経験を通して得られたリード力

「API 設計だけ」ではなく一通り全てを任せていただいたことはとても大きな経験になりました。初めて個人ではなくチーム・プロジェクト全体として効率が良くなる動きを考える経験もできたと思います。

技術力

もちろん実装を通じて得た技術は数えきれないほどありますが、その中でも特に責任を持って他者のコードをレビューしたり、自分が書くコードの影響範囲やスコープを意識し続けたことが大きな糧になっている気がします。

リスク管理力

スケジュール遅延のリスク、方向性がずれてしまうリスク、技術的なリスク、様々ありますがこれらのリスクヘッジを考える力がプロジェクトリーダーには必要です。

リスク管理において「先読みが大切」とよく言われますが、私の場合はある先輩社員から「常に 2 週間先を見据えておけ」という具体的な日数のアドバイスをいただきました。具体的にすることであらゆることが想像しやすくなりましたし、それを 1 年以上毎日意識し実行し続けたことが、プロジェクトをやり切ることができた要因にもなっていると思います。もちろんこの言葉は家宝にしようと思っています。

価値に対する視野

何よりも「プロダクトのユーザーに価値を提供すること」の意味を理解しました。ここまでに書いてきたようなスケジュール管理やリスク管理などは、あくまでプロジェクトを遂行する上で必要な仕事の一つでしかないはずです。プロジェクトを通してシステムを使っている社員、更にはその先の顧客・求職者へ如何に価値を提供できるか考えるべきですが、一時期は「どうやるのか・なにをやるのか」というプロジェクト自体を完遂させることしか考えられていない時期もありました。

視野が狭くなっていたことに周りからの指摘で気づくことができ、それ以降は「そもそも本当にこの機能はいるのか」などユーザーの立場からの観点も徐々に身に付けることができました。これがきっかけとなり、周りとも頻繁に「なぜやるのか」を議論できるようになったと思います。新卒 1 年目で口酸っぱく言われていた「目的意識」をようやく腹落ちさせ体現することができました。

最後に

最後となりますが、プロジェクトリーダーについて語ってきた私ですが、入社するまでは Web 開発未経験でして、メドレーでの成長を非常に実感しています。そんなメドレーではエンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集していますので、少しでもご興味をお持ちいただけた方は、是非お気軽にお話しさせていただければと思います！

ここまでお付き合いいただき、ありがとうございました。

オンライン診察機能に画面共有を実装した話

Fri, 30 Jul 2021 08:35:08 GMT

事業本部プロダクト開発室エンジニアの日下です。

オンライン診療・服薬指導・クラウド診療支援システム「CLINICS」の、患者・医療機関に向けたアプリケーションの機能開発、開発基盤、インフラ周りを担当しております。

今回 CLINICS が提供するオンライン診療機能に「画面共有機能」を追加しましたので、その背景・技術的な話をまとめます。

画面共有機能実装の背景

CLINICS とオンライン診療

普段皆さんが病院にかかるとき、多くの場合は病院に行き、医師の診察を対面で受け、会計をして帰るといった流れになるかと思います。

CLINICS のオンライン診療はこの流れをインターネットを通して提供するサービスです。

※ オンライン診療は、一度、初診等で対面診療を受けた際に医師が可能と判断した場合、次回以降の診察において可能になります。また、現在は新型コロナウイルス感染症対策時限措置として、初診からオンライン診療を受けることが可能となっています。

CLINICS を利用した場合、事前に予約した時間にスマホまたは PC で待機をする、医師の診察をビデオチャットで受け、会計はクレジットカードで行われるという流れとなっています。

クラウド診療支援システムとしての CLINICS は 2016 年に「オンライン診療のためのシステム」としてローンチされ、2018 年にはクラウド型電子カルテ機能を、2019 年には予約管理システム機能を、2020 年にはかかりつけ薬局支援システム Pharms との連携機能も追加し、患者向けアプリからオンライン服薬指導をシームレスに受けることができるようになりました。

プロダクト開発室ではこれらオンライン診療機能・電子カルテ機能・予約管理機能・連携機能の改善を日々行っています。

画面共有機能の需要の高まり、実装の決定

このように CLINICS の改善を日々行なっている中、昨年から始まった新型コロナウイルス感染症（COVID-19）の流行に伴った需要の増加により、オンライン診療の件数が急増しました。

CLINICS も数多くの医療機関にご利用いただく中で、オンライン診療に関わるさまざまなご要望をいただくようになりました。その中でも特に多かったものが、今回紹介する画面共有機能です。

対面での診察の際に医師が検査結果などを患者に見せながら説明するように、オンラインで診察する場合でも資料をリアルタイムで共有しながら説明ができるようになれば、今まで以上にオンラインでも質の高い診察を行えるようになります。

こういったユースケース、要望などを検討した結果、CLINICS を利用するすべての医療機関及び患者にとって大きな恩恵が見込まれたため、オンライン診察（ビデオチャット）中に医師の PC 画面をリアルタイムで患者に共有する機能として実装をすることにしました。

画面共有機能の実装

画面共有をする医師側向けのコードでどういった実装方法があるのか、大まかな流れをまとめます。

※ 以下に記載しているコードは説明のための疑似コードですので、このままでは動作しないことにご注意ください。また、医師側の実装例を掲載しているため、患者側（画面共有を受ける側）の実装は別途必要になります。

オンライン診察開始までの処理

オンライン診察を開始するには医師側のマイクとカメラで取得した情報を患者側に送付する必要があります。ここではそこまでの実装の流れを見ていきます。

カメラ・マイクのストリームの取得

オンライン診察開始時点で医師側のマイク・カメラの情報を共有するため、まずはそれらのストリームを取得する必要があります。こういったメディアコンテンツのストリームを司るインターフェイスとして MediaStream が定義されています。

マイク・カメラの MediaStream は、例えば MediaDevices.getUserMedia() を利用して取得できます。

const userMediaStream: MediaStream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});

SkyWay 経由でオンライン診察を始める

WebRTC で P2P のビデオチャットを利用するためには、初期の接続のための処理及び接続の維持などの処理を行う必要があります。弊社ではこのあたりの処理を WebRTC SaaS の SkyWay 及びその SDK を利用することで簡略化しています。

オンライン診察開始時には、先程取得した医師側のマイク・カメラの MediaStream を SkyWay の SDK に渡すことで、一対一でのリアルタイムビデオチャットを実現できます。

import Peer, { MediaConnection } from "skyway-js";

const peer = new Peer({ key: "your-api-key" });

// 事前に患者と共有しておいた peer id に対して call メソッドと MediaStream を渡すことで診察を開始できる。
const mediaConnection: MediaConnection = peer.call(
  "shared-peer-id",
  userMediaStream
);

// 注: 患者側は送付された処理をハンドリングする機能を実装する必要がある

ここまでがオンライン診察を開始するまでの処理です。

※ 詳細は SkyWay 公式のチュートリアルなどを参照ください。

画面共有の処理

ここまでで患者に対して医師側のカメラ・マイクで取得された映像・音声が表示されている状態のため、これを切り替える処理が必要になります。今回は現在接続に利用している MediaStream を、画面共有用の MediaStream に入れ替えることで実現しました。

画面の MediaStream の取得

まずは共有する画面の MediaStream を取得する必要があります。これは MediaDevices.getDisplayMedia() を使うことで実現できます。

const displayStream: MediaStream = await navigator.mediaDevices.getDisplayMedia(
  { video: true }
);

画面共有用の MediaStream を作る

getDisplayMedia() から共有する画面の MediaStream を取得できるものの、そのまま利用するとマイクの音声が入りません。

これは getDisplayMedia() から取れる MediaStream にマイクの音声が含まれていないことが原因なので、必要な画像・音声の組み合わせを持った画面共有用の MediaStream を作成することで対処ができます。

MediaStreamTrack を組みあわせて画面共有用の MediaStream を作る

画面共有用の MediaStream を作成する前にまず、MediaStreamTrack と MediaStream の関係を理解する必要があります。

MediaStreamTrack はストリームに含まれる一つのメディアトラックを表現するものです。 kind という読み取り専用プロパティがあり、オーディオトラックであれば "audio" が、ビデオトラックであれば "video" が設定されています。

また、 MediaStream は複数の MediaStreamTrack から成り、オーディオトラック・ビデオトラックを取り出すメソッドがそれぞれ MediaStream.getAudioTracks()・MediaStream.getVideoTracks() として実装されています。

これらを組み合わせることで、マイクと画面の MediaStreamTrack を持つ MediaStream を作ることができ、これを SkyWay の SDK に渡すことで、画面共有を実現できます。

const [displayVideoTrack]: MediaStreamTrack[] = displayStream.getVideoTracks();
// 画面共有の音声はマイクの音声を利用したいので、userMediaStream から audioTrack を取り出しておく
const [userAudioTrack]: MediaStreamTrack[] = userMediaStream.getAudioTracks();

// 画面共有するための MediaStream を作成する(画面の videoTrack、マイクの audioTrack を持つ MediaStream を作る)
const sharingMediaStream: MediaStream = new MediaStream([
  displayVideoTrack,
  userAudioTrack,
]);

MediaStream の入れ替え

最後に画面共有状態への切り替えです。マイク・カメラが共有されている状態からの切り替えにはいくつかの方法が考えられます。

例えば、多重化であれば MediaConnection（ Skyway の SDK の単位で、「接続先 Peer へのメディアチャネル接続」を管理する）の多重化、MediaStream の多重化、MediaStreamTrack の多重化がそれぞれ考えられます。これらの方法はマイク・カメラの切り替え時のチラつき抑制など実装上の選択肢が増えるメリットがある一方で、通信量が多くなってしまう点がデメリットと言えます。

今回は多重化をせずに既存の MediaStream を切り替える実装を紹介します。この方法のメリットは、多重化に比べると通信量が少なく、またすでに MediaStream が一つである前提で作られている場合は、画面共有を受ける側の実装の変更が不要という点です。

この方法は、 SkyWay の SDK であれば MediaConnection の replaceStream というメソッドに対して新しい MediaStream を渡すことで実現ができます。

// 画面共有用の MediaStream を渡すことで、画面共有を開始する
// MediaConnection は先程 `peer.call` した際の返り値として取れているため、それを利用する
mediaConnection.replaceStream(sharingMediaStream);

実装前に懸念していたマイク・カメラの切り替え時のチラつきなども気になるほどはなく、実用に足るような品質を保つことができることを確認しています。

実装の全体概要

以上の流れを実装すると、次のようなコードになります。

import Peer, { MediaConnection } from "skyway-js";

/** 医師側のマイク・カメラを共有してオンライン診察開始するところまで **/
// getUserMedia()でカメラ・マイクのストリームを取得
const userMediaStream: MediaStream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});

// Skyway sdk の初期化処理
const peer = new Peer({ key: "your-api-key" });

// オンライン診察の開始
const mediaConnection: MediaConnection = peer.call("peerId", userMediaStream);

/** 画面共有を開始する処理 **/
// 画面共有する画面の stream を取る
const displayStream: MediaStream = await navigator.mediaDevices.getDisplayMedia(
  { video: true }
);
const [displayVideoTrack]: MediaStreamTrack[] = displayStream.getVideoTracks();

// 画面共有の音声はマイクの音声を利用したいので、userMediaStream から audioTrack を取り出しておく
const [userAudioTrack]: MediaStreamTrack[] = userMediaStream.getAudioTracks();

// 画面共有するための MediaStream を作成する(画面の videoTrack、マイクの audioTrack を持つ MediaStream を作る)
const sharingStream: MediaStream = new MediaStream([
  displayVideoTrack,
  userAudioTrack,
]);

// 画面共有用の MediaStream を渡すことで、画面共有を開始する
mediaConnection.replaceStream(sharingStream);

開発中に遭遇した問題への対応

スリープモード・共有を停止ボタンを押したときの対応

Google Chrome で画面共有の際に表示される「共有を停止」ボタンを押下したり、PC をスリープモードにすると、画面の MediaStreamTrack が途切れてしまいます。

これは該当の MediaStreamTrack に "ended" のイベントリスナを登録しておくことでハンドリングできます。

displayVideoTrack.addEventListener("ended", handleEndedEvent, { once: true });

TypeScript の型の対応

現状 TypeScript の型が getDisplayMedia() に対応していなかったため、今回は実装の参考にしている skyway-conf で利用されている型を流用する形で対応をしました。

declare global {
  interface MediaDevices {
    getDisplayMedia(constraints: MediaStreamConstraints): Promise<MediaStream>;
  }
}

これは根本的には TypeScript の dom.d.ts に型定義が入っていないことが起因していますが、TypeScript4.4 で対応がされるようです。

まとめ

昨今の状況により、オンライン診察のニーズが高まり、画面共有機能の重要性が高まりました。診察中の画面共有機能は以下の api を組み合わせることで実現することができます。

PC 画面の MediaStream は getDisplayMedia() を使うことで取得
MediaStream に含める音声・画像ストリームを変更したい場合は MediaStreamTrack の組み合わせを変えることで作成
接続中の MediaStream の変更は SkyWay の SDK の MediaConnection.replaceStream() を使う

最後に

CLINICS では本稿で紹介した画面共有などの新規機能の導入や日々の改善を通じて、医療機関・患者双方に支持されるプロダクトを目指し開発を行っています。興味を持たれたエンジニアの方がいらっしゃいましたらぜひこちらにご連絡いただければと思います。

「ChatOps 稟議」×「電子契約締結の API 連携」でワークフローの生産性を追求した話

Fri, 16 Jul 2021 08:47:40 GMT

はじめに

はじめまして、コーポレートエンジニアの山下です。

2020 年にSlackを活用した ChatOps 稟議ワークフローを内製で開発したのですが、さらに、2021 年 4 月にこの Slack 稟議と電子契約システムであるクラウドサインを連携させて、電子契約をもっと便利に使い、生産性の向上を実現しましたのでお話しいたします。

まず、当社の稟議システムは2020 年 12 月の当社の記事のおさらいになりますが、稟議の作業が Slack 上で完結する、ChatOps による稟議ワークフローとなっております。本稿については 2021 年 7 月に執筆しておりますので丁度導入から 1 年程経過し、その間大きなトラブルも無く、今も当社の極めて迅速な意思決定の一助になっています。ChatOps による稟議ワークフローについては、直近、2021 年 6 月に LayerX 社がLayerX ワークフローの新機能として発表し、サービスとしても提供され、日経新聞でも取り上げられていることから、今現在のパラダイムとして、先進的で有効な一手法であったと再認識しております。

今回、新型コロナウイルス感染拡大防止に伴うリモートワークの加速という状況もあり、当社で 2021 年 4 月に電子契約システムとしてクラウドサインを導入しました。電子契約に限らず、契約押印作業は稟議の後続作業に当たるため、ただ導入して使用するのみならず、クラウドサインの API を利用して稟議上にあるデータを電子契約に送信させることでシームレスな連携を実現しています。本稿では当社が行ったシームレスな連携手法について詳細をご説明いたします。

TeamSpirit とクラウドサインの API 連携について

実装概要

弊社の稟議システムであるTeamSpiritとクラウドサインとの連携についてお話しします。まず、本稿の開発部分とシステム構成は下記になっております。

処理内容の詳細は後ほど述べますが、概要としては TeamSprit(Apex)からクラウドサインの API をコールし、クラウドサイン上で作成した契約文書へ稟議に記載されている契約書ファイルや先方担当者等の情報を連携する仕組みとなっております。これにより契約担当者はクラウドサインにログイン後、下記の 3 ステップで先方に送信できるようになっています。

記載内容の確認
押印・署名箇所の設定
先方への送信

クラウドサインを使用して契約文書を一から作成する場合のユーザ作業と、当社で採用した API 連携行った場合のユーザ作業を比較したものが下記の表です。作業が半分程度削減されたことが分かります。

作業項番	一から作成する場合	API 連携を利用した当社の場合
1	ログイン	ログイン
2	契約文書の作成(件名、契約文書としての宛名設定等)	なし
3	契約書ファイルのアップロード	なし
4	先方の送信先設定	なし
5	押印欄の設定	押印欄の設定
6	先方への送信	先方への送信

実装

今回の開発で使用したクラウドサイン APIは下記の 5 つの API を使用しました (※以降、クラウドサイン API に倣い、変数を表現する場合は{}で括ります)。

API 種類	使用用途
post /token	アクセストークンの取得
post /document	契約文書の作成
put /documents/{documentID}/attribute	契約文書の作成で設定できない、細かい項目の設定
post /documents/{documentID}/files	ファイルのアップロード
post /documents/{documentID}/participants	先方の送信先設定

全体像で記載したクラウドサインの連携部について、上記の API を織り交ぜて詳細化すると下図のようになります。

実装方法としてはクラウドサイン API のリファレンスを参照し、テスト実行時に出力されるcurlコマンドを参考に同様のレスポンスを得るように Apex で HTTP リクエストを実装しました。アクセストークンの取得を例にとると下記のようになります。

API リファレンスでの curl コマンド例

curl -X 'POST' \
'https://api.cloudsign.jp/token' \
-H 'accept: application/json' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=xxxxxxyyyyyyzzzzzz'

Apex でのリクエスト実装例

HttpRequest req = new HttpRequest();
req.setMethod('POST');
req.setEndpoint('https://api.cloudsign.jp/token');
req.setHeader('accept', 'application/json');
req.setHeader('Content-Type', 'application/x-www-form-urlencoded');
req.setBody('client_id=' + 'xxxxxxyyyyyyzzzzzz');

私自身、Apex もクラウドサイン API もこの案件を担当するまで触ったことがありませんでしたが、リクエストの試行から実装まで 2 週間かからない程度で実装することができました。

ただし、実装や運用にあたっては下記 2 点について注意が必要になります。

Apex からクラウドサインへのファイルのアップロードは単純ではない
アクセストークンの有効期限はクラウドサインでコントロールされる

1. Apex からクラウドサインへのファイルのアップロードは単純ではない

ファイルのアップロードについては今回使用した API の中で、唯一、テスト実行のcurlと Apex のリクエスト実装で差分が生まれます。まず、その差分を確認するために curl コマンド例と Apex のリクエスト実装例で header、body にセットしている値を比較してみます。

API リファレンスでの curl コマンド例

curl -X 'POST' \
'https://api.cloudsign.jp/documents/{document_id}/files' \
-H 'accept: application/json' \
-H 'Authorization: AAAAAABBBBBBCCCCCC' \
-H 'Content-Type: multipart/form-data' \
-F 'name=テスト' \
-F 'uploadfile=@テスト.pdf;type=application/pdf'

Apex でのリクエスト実装例

HttpRequest req = new HttpRequest();
req.setMethod('POST');
     req.setEndpoint('https://api.cloudsign.jp/documents/{document_id}/files');
req.setHeader('accept', 'application/json');
req.setHeader('Authorization', ‘AAAAAABBBBBBCCCCCC’);
req.setHeader('Content-Type', 'multipart/form-data; boundary={boundary}');  // ※1
req.setBodyAsBlob({multipartBody});  // ※2

主な違いは ※1, ※2 とコメントした部分になります。

Apex では HTTP リクエストの値を手で書いていくことになるので、テスト実行例のようにcurlがよしなに処理している部分(-F オプションの部分や Apex で記載している boundary)も実装しなければなりません。これが単純に実装できない理由になります。

boundary については multipart/form-data を送信する際に必要な境界でヘッダーでどの文字列が境界であるかを設定します。curlの-F オプションで定義していた文字列とファイル指定部分は、Apex でファイル(バイナリ)を扱うため、その body に含まれる文字列も含めて Blob 型で扱う必要があります(Content-Transfer-Encoding: base64に API 提供側が対応している場合は例外になります)。そのため、文字列とバイナリデータを結合し一つの Blob にする方法は下記になります。

「バイナリデータ」、「body の開始からバイナリデータまでの文字列」、「バイナリデータ以降から終端までの文字列」の 3 グループに分ける。
3 グループをそれぞれBase64で符号化する。
符号化した「バイナリデータ」と「body の開始からバイナリデータまでの文字列」について、Base64 のデータパディングを示す”=”が含まれないように改行コードで調整する。
「body の開始からバイナリデータまでの文字列」、「バイナリデータ」、「バイナリデータ以降から終端までの文字列」の順で結合する。
結合した Base64 のデータを復号して、一つの Blob とする。

2. アクセストークンの有効期限はクラウドサインでコントロールされる

アクセストークンやその有効期限は token API を発行した際のレスポンスとしてクラウドサインから発行されます。

発行されたレスポンス例

{
     "access_token": "AAAAAABBBBBBCCCCCC",
     "token_type": “xxxx”,
     "expires_in": 3600
}

このレスポンスの内、expires_in の値がトークンの有効期限になります。掲題の通り、有効期限の管理はクラウドサイン側で行われ、有効期限内に再度トークンのリクエストを行った場合、経過した時間だけ expires_in の値が小さくなった結果が返ってきて、access_token などは同じ値が取得されます。有効期限内に token API を再度実行した結果が下記になります。

有効期限切れ前に token API を発行した際のレスポンス例

{
     "access_token": "AAAAAABBBBBBCCCCCC",
     "token_type": “xxxx”,
     "expires_in": 762
}

一方、有効期限後にトークンのリクエストを実行すると、それまでと異なるアクセストークンを取得し、新しい有効期限が設定されます。

有効期限切れ後に token API を発行した際のレスポンス例

{
  "access_token": "XXXXXXYYYYYYZZZZZZ",
  "token_type": "xxxx",
  "expires_in": 3600
}

そのため、API 連携が一度動いた後、有効期限ぎりぎりでもう一度 API 連携が動いてしまった場合、タイミングが悪いと契約文書の作成から最終処理である先方の送信先設定までのプロセス内のどこかから、トークンの有効期限切れが発生する可能性が想定されます。実際に期限切れが発生した場合、発生時以降に発行したその回の API 連携処理が失敗します。

トークンの有効期限切れが発生した際、API リファレンスより HTTP ステータスコードが 401 かつエラー内容が”unauthorized”で応答されることから、当社ではこのエラーを受けた場合にトークンを再取得して処理をリトライするように実装しました。

押印文書作成を例にとると下記のような実装イメージになります。

//クラウドサイン上に押印文書を作成し、作成した文書 ID を取得する
public String getDocumentId(String authToken, String title, String message){

    ・・・中略・・・

    HTTPResponse res = http.send(req);

    if (res.getStatusCode() == 200){
        ・・・正常に終了した際の処理・・・
    }

    //タイミングが悪く token がタイムアウトした場合、トークンを取得し直して、リトライする
    else if (res.getStatusCode() == 401){
        //レスポンスの内容を確認するため、エラーレスポンスの中身を取得する
        Map<String, Object> responseBody = new Map<String, Object>();
        responseBody = (Map<String, Object>)JSON.deserializeUntyped(res.getBody());
        String errorVal = (String)responseBody.get('error');

        //リファレンス上、アクセストークンが無効(有効期限切れ)の場合、'unauthorized’となる
        if (errorVal.equals('unauthorized')){
            //クラウドサインのアクセストークンの再取得
            authToken = getAuthToken();
            //単純再帰で再実行する。
            documentId = getDocumentId(authToken, title, message);
        }
        ・・・中略・・・
    }
    ・・・以下省略・・・
}

実装を終えて

上記を実装した結果、稟議と入力内容が同じ、または、稟議から生成できる内容は全てシステム連携で自動生成するため、押印担当は稟議とクラウドサインの画面を並べて転記するような煩雑な作業を必要としない環境になりました。また、契約書の製本、郵送等の紙媒体であるが故の事務の削減ができるようになる等の、電子契約を導入することのそもそものメリットも併せて享受しています。

当社では 2021 年 4 月後半からクラウドサインを導入しましたが、2021 年 6 月時点ではすでに月間で締結した契約書の「3 割以上」が電子契約を活用しており、押印担当の展望として今後も利用を拡大していく予定です。

コーポレートエンジニア募集中

メドレーのコーポレート部門では、本稿のように、SaaS の導入ひとつとっても検討を尽くし、既存のシステムと有機的に結合させることで「徹底的に合理性を追求した組織基盤や、仕掛けづくり」を行っています。

面白そう！興味がある！と感じた方は、ぜひ当社採用ページからご応募お願いします！

最後までお読みいただきありがとうございました。

Pharms のブランドルーツを辿る

Fri, 25 Jun 2021 09:01:08 GMT

「2020 年 9 月に調剤薬局向けのプロダクトをリリースする」

このプレスリリースが発表されたのは、COVID-19 の感染拡大に端を発する緊急事態宣言が発令されていた 2020 年 4 月半ば。その 1 ヶ月後、私はリモートワーク下でのオンライン MTG になじめない状態のまま、調剤薬局向けプロダクトのブランディングについて役員陣や主要プロジェクトメンバーにプレゼンを行っていた。

今回は当時のプレゼン資料をたどりながらPharmsのブランド設計について説明していこうと思う。

医薬分業のルーツとは

デザイナーとして前田がメドレーに入社してから、オンライン診療や電子カルテなど、主に医療機関向けのプロダクトデザインを担当していたものの、調剤薬局のプロダクトデザインは未知の領域。ブランディングを検討する上で、薬の処方を行う医師と調剤を実施する薬剤師が分担して行う医薬分業のルーツついて調べることからはじめた。

医薬分業は、毒殺を恐れたフリードリヒ 2 世が主治医の処方した薬を、毒が盛られてないか他者にチェックさせたのが始まりとされている。

（参考：公益社団法人日本薬剤師会 HP ｜医薬分業とは）

医療プラットフォームの未来を見据えたブランド定義

次に、調剤に関する法制度や競合などの外部要因、メドレーとしてのブランド力や開発力などの内部要因について簡易な SWOT 分析を行い、調剤薬局のプロジェクトの妥当性を検証。メドレーが取り組む医療プラットフォーム事業(※)に、あらたに調剤薬局プロジェクトが加わることによる他のプロダクトとのバランスも考慮しながらブランドネーミング検討を行っていった。

※) 医療プラットフォーム事業では、患者と医療領域の業務システムを SaaS プロダクトでつなぎ、患者と医療機関双方にとって、テクノロジーの恩恵を受けることのできるプラットフォームづくりを行っている。主要サービスはクラウド診療支援システム「CLINICS」やオンライン診療・服薬指導アプリ「CLINICS」。

メドレーのこれまでの歴史を振り返ると、プロダクト内容を明確かつ端的に表したネーミングが多く、メドレーらしさ = 「中央突破なネーミング」ということを定義し、ネーミングを検討していった。

最終的に調剤薬局を表す「Pharmacies（ファーマシーズ）」と「Pharms（ファームス）」の 2 案に絞込み、それぞれのメリット・デメリットを整理していった。

当時、社内では調剤薬局システム = Pharmacies と呼ばれており、その中央突破なネーミングが最有力候補であった。一方で、ブランドで体現すべきアイデンティティの欠如や、呼びづらさなどが課題として散見された。さらには医療プラットフォーム全体を見据えたブランド構築という観点から考慮すると、バランス面での課題が浮き彫りになり、それら課題をクリアにして誕生したのが Pharms（ファームス）である。

ヴィジュアル・アイデンティティの設計

ブランド名が固まれば、あとはヴィジュアル・アイデンティティを突き詰めていくのみ。視認性や可読性を考慮したフォントフェイスの検証や調剤薬局と想起させるブランドカラーの選定、またシンボルの設計などに取り掛かっていく。

ブランドカラーの選定においては、なんとなく「緑」というイメージがチーム内でもあったが、より精緻化するため、薬の起源や調剤薬局本来の役割を踏まえ詳細に落とし込んでいった。

ロゴにシンボルを含めるか、含めないかも検討のひとつであったが、医療プラットフォーム事業にある CLINICS のロゴがシンボルマーク付きであるため、医療プラットフォームに関連するプロダクト = シンボルを定義するというルールを策定しシンボルも設計。シンボルは薬の構造式に利用される「ハニカム構造」をモチーフとし、ブランドカラーと合わせて詳細に作り込んでいった。

また、Pharms の製品紹介用ランディングページやプロダクトデザインのモックアップを作成し、ロゴとのバランスなども考慮しながら調整を行っていった。

最終的に、患者・調剤薬局・医療機関の 3 者のつながりを三角形で表現しつつ、中心を先述した「ハニカム構造」をモチーフとした形状と、Pharms の頭文字「P」をカプセルと錠剤で表現して、調剤薬局システムとしてシンボルマークに命を吹き込んだ。

まとめ

このような過程を経て、Pharms のブランドが完成したのだが、これらは調剤薬局システムの開発としては氷山の一角でしかない。本丸はプロダクトデザイン。一般的にはロゴとプロダクトデザインは別プロジェクトで進行したり、担当するデザイナーが別だったりすることも多いのではないだろうか。

Pharms はブランド設計、プロダクトデザイン、マーケティング資材といったデザイン領域をすべて私が担当していくことになるのだが、それ故に事業全体を俯瞰し理解しながらデザインや UI デザインに魂を込めて携わることができた。デザイナーキャリアとしてもここまで幅広く携われたことは非常に貴重な経験を得ることができたと自負している。

続いてプロダクトデザイン開発の秘話について語りたいところだが、現在 Pharms 以外の医療プラットフォーム事業に関連する新たなプロダクト開発に注力しているため、その話はまたの機会に。

医療プラットフォーム事業に関連するプロダクトをこれからも創出し成長させていく面白い時期にあり、現在デザイナーを積極採用中です。カジュアルに話を聞きたい、医療領域のデザインに興味があるといったデザイナーの方は、ぜひこちらまでご連絡いただけると幸いです。

メドレーでセキュリティエンジニアとして働くということ

Fri, 28 May 2021 08:50:04 GMT

はじめまして。メドレーでセキュリティエンジニアをしている三浦です。

私はメドレーには今年（2021 年）の 2 月に入社し、このブログを執筆している時点で入社 4 ヶ月目となります。現在、全社的なセキュリティを担当しています。

今回のブログは以下のような構成でお届けします。

自己紹介と、本ブログのテーマについて
前職でのセキュリティエンジニアとしての仕事
メドレーでのセキュリティエンジニアの仕事
セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題
セキュリティエンジニア募集中！

自己紹介と、本ブログのテーマについて

私は前職でセキュリティ専業会社のセキュリティエンジニアとして脆弱性診断やペネトレーションテストのほか、セキュリティ研修の講師、ファイアウォールや Web アプリケーションファイアウォール（WAF）と呼ばれる機器の導入支援などに携わっていました。

このなかでも脆弱性診断の案件に多く関わっていたこともあり、最後には脆弱性診断のサービスオーナーとしてサービスに関わるすべてを取りまとめる立場でした。

今では事業会社のセキュリティエンジニアとして活動しているわけですが、このブログではセキュリティエンジニアとしての活動内容や役割にどのような変化があり、その変化により直面している自分自身の課題や苦労について書いていきます。

前職でのセキュリティエンジニアとしての仕事

先述のとおり前職では脆弱性診断に関わることが多かったため、ここでは脆弱性診断について取り上げます。

脆弱性診断はスポット案件として実施することがほとんどでしたので、案件の流れという観点で仕事内容を整理すると以下のようになります。

営業フォロー（同行や Q&A など）
スケジュールや診断対象などについてお客様にヒアリング a. ここで診断用環境の準備をお願いすることが多い
診断対象の調査、クロール作業
スケジュール感や制限事項についてお客様とすり合わせ
計画書を作成
社内で計画書レビュー、お客様へ送付
診断作業 a. 自動診断ツールの調整 a. 手動診断の実施 a. 出力結果の精査、再現性の確認 a. 速報があれば当日中に整理して送付
診断結果のエビデンス整理
報告書の下書き、リスク度合いの検討
社内で報告書レビュー
お客様へ報告書を納品
報告会の実施

このなかで、特に診断担当者の技術的スキルが問われたのが「手動診断の実施」と「出力結果の精査、再現性の確認」で、全体のうち約 4 割ほど。残りはドキュメント作成、レビュー、ミーティング、業務改善といった定型業務が占めていました。

私は「この 4 割の部分に対して付加価値を提供したい」というエンジニアとしての気負いと、個人的な関心という 2 つの理由から、寝る時間を削っては脆弱性の悪用（Exploit）手法の習得と、知識的な補強としての資格取得に明け暮れる時期がありました。

結局、寝不足が続いたことが原因で肺炎を発症し、入院一歩前まで炎症マーカーが悪化するという自分自身の脆弱性が露呈することになったのですが。ちゃんと夜は寝ましょう。

話がすこし脱線しましたが、脆弱性診断や SI 案件などは年度末にピークを迎えるものの年間を通じて五月雨で受注することも多く、一定の品質を維持しながらも納期を守るために目の前の案件で必死だったというのが今までの仕事のスタイルでした。

目の前の案件をひたすらこなし、組織に対して「報告書を提出して終わり」の関わり方に対して『これで社会の役に立っているのだろうか』という疑問が生まれたことが、メドレーに入社する転機になっています。

メドレーでのセキュリティエンジニアの仕事

さて、セキュリティサービスを提供する側で案件に追われていた私がメドレーでセキュリティエンジニアとして活動することになっているわけですが、具体的に今なにをしているのか？というと、大きくは以下の 6 つが挙げられます。

自社サービスに対する脆弱性診断
脅威情報や脆弱性情報の収集、周知
全社的な業務プロセス上のリスク調査
全社システムの BCP 整備、保守
ISMS 運用
セキュリティ相談

自社サービスに対する脆弱性診断というのは「脆弱性診断の内製化」で、脆弱性診断を外部の業者にお願いするのではなく自社内で実施して開発にフィードバックする形です。

内製による診断であっても、基本的な流れはすでにご紹介した流れで進めていますが、対象サービスをクロールしてから診断対象を確定させるまでの主要なポイントでは、操作手順に漏れがないかなどの観点で開発からのレビューを挟むようにしています。これは内製であるからこそ実現できているアプローチだと思います。

内製で実施している診断対象一覧の例

なお、ここまで脆弱性診断について書いてきましたが、これは現在の業務のほんの一部で、このほかには ISMS の運用（事務局）としての活動のほか、コーポレート IT メンバーと共に事業継続計画（BCP）整備なども並行して進めなければなりません。とにかく関わる範囲が広く、そして、とても地道な活動です。

ですが、会社全体を俯瞰してセキュリティのことを意識して物事を考え続けられる立場というのはセキュリティ会社では経験できないことで、自社にとっての最適解は何か？を探求し続けることの新たな面白さを見いだすことができています。

セキュリティエンジニアとしての活動内容や役割の違いと気づき、課題

ここまでの内容でお気づきの方もいるかと思いますが、現在の業務は ISMS 運用を初めとしてリスクマネジメントの分野も多く、実務的なバックグラウンドのない業務も出てきています。

システム的なセキュリティに関しても「どうやって悪用できるか…好物の BOF*は無いのか..BOF はどこだ…」という攻撃観点の思考回路のみで判断するのではなく、「どのようなソリューションや仕組み、またはルールでリスク低減できるのか、そして、それをなるべく自動で運用できるようにはどうするか」という守る側にとっての実務的な課題を考えなければなりません。

* バッファオーバーフローのこと

このほかに、私が実際に感じているセキュリティエンジニアとしての気づきや考え方の変化を挙げていくと、以下のようなものがあります。

攻撃手法の理解を踏まえ、（社内リソースを鑑みた）現実的に運用しうる対策の仕組みを提案できなければならないことを痛感した
仕組み化やルール化するにも、エンジニアではない従業員の存在を考慮するようになった
脆弱性単体の影響範囲や度合いではなく、システムの利用方法や情報の種類など、社内だからこそ持てる視点を持って評価するようになった
「アップデートしたくてもできない」問題が生じないシステム設計が肝要であることを改めて認識した

これらの変化への対応については、すべてソリューションや自動化に対して私の知見がまだまだ不足しているため、これからは「攻撃者目線」の考え方に加えて「ソリューションと自動化」の知見を補完しながら、メドレーのセキュリティ向上に貢献し続けていきたいと考えています。

セキュリティエンジニア募集中！

最後となりますが、セキュリティエンジニアは関わる業務の幅広さに加え、絶対的な正解が存在しない問題にソリューションを提供することも多い仕事です。

メドレーでの内製による脆弱性診断や全社セキュリティに興味がある方はぜひジョインしてください。いつでもお待ちしています！

介護のほんねリニューアルの話

Tue, 06 Apr 2021 09:00:10 GMT

はじめまして。メドレーでデザイナーをしているおおのです。わたしはメドレーには昨年（2020 年）の 6 月に入社し、現在老人ホーム・介護施設の検索サイト「介護のほんね」を担当しています。

介護のほんねは昨年リニューアルを行いました。今回は、そのリニューアルプロジェクトの中で自分が取り組んだこと（主にサイトトップのリニューアルについて）についてお話しようと思います。

介護のほんねとは

介護のほんねは、納得できる老人ホーム・介護施設探しができる検索サイトです。介護のほんねには、全国にある多くの施設が掲載されています。予算やエリアなどお好みの条件で施設を検索したり、気になった施設へ見学予約や資料請求などお問い合わせができます。また社内の入居相談員による施設に関する資料送付や条件にあった施設紹介、施設見学の日程調整などのサポートにも対応しています。

リニューアルの背景

介護のほんねは 2014 年にローンチされました。しかし、長い間の運用の中で古いデザインと新しいデザインが入り混じっている部分があったり、SEO の観点での強化が必要だったり、今後の成長に向けて手直しする部分が積もり始めていました。また、2019 年に「医療につよい老人ホーム検索サイト」にコンセプトを変更しましたが、より多くの方にご利用いただくためにも、医療につよいというコンセプトからさらに一歩進み、様々な状況のお客様に向き合い、お客様が介護に対して前向きに、そして後悔のない選択ができるよう寄り添うことのできるサービスにしていきたいという思いから今回のリニューアルが始まりました。

プロジェクトについて

リニューアルプロジェクトは昨年 5 月頃から始まり、外部のデザイン制作会社と連携して進められました。制作会社の方には、デザイン業務の支援をお願いしつつ、週 1〜2 回の定例で進捗報告や業務内容の確認を行っていました。

プロジェクトとの関わりについて

自分が入社したのが昨年 6 月後半だったので、デザインや開発も部分的に進んでいる状況でした。介護領域の勉強や、担当サービス、競合調査、リニューアルプロジェクトや介護のほんねのこれまでの歩みについてなどのキャッチアップと並行してリニューアルのデザインのことも考えていました。

そこで次のようなことを意識して動きました。

プロジェクトに対して

社内のメンバーといつでもコミュニケーションがとれることを活かし、外注先とも相談して自分自身も手を動かしながらデザインをブラッシュアップすること

社内に対して

サービスに対するメンバーの思いを確認しつつ、これまでのサービスの歩みを尊重して動くこと
社内のデザイナーの先輩など頼れる人には頼ること

サイトトップの制作

プロジェクトにジョイン後、主にサービスの顔であるサイトトップについて、アイデア出しやデザインをしました。

サイトトップにどのようなコンテンツを掲載するのか、また、お客様が介護に対して前向きに、そして後悔のない選択ができるよう寄り添いたいというサービスの思いをどのように表現すればよいか考えていきました。

掲載するコンテンツに関しては、サイトトップを誰に向けて作るのかという部分を介護施設探しが初めての人に設定し、このサイトでは施設が探せることを伝えてサービスのコア機能を全面に出しつつ、介護のほんねでの施設探しの魅力ポイントや、介護や施設探しに関するコラムや Q&A などお役立ち情報も掲載するようにしました。

▼ リニューアル前のサイトトップ

また、当時のサイトトップは上に貼ったキャプチャの通りで、落ち着いた青を基調としたクリーンで誠実そうな印象がありました。これまで築き上げてきたプロダクトのイメージや印象は、リニューアル後も受け継いで残していきたいなと思いました。

それをふまえた上で、サイトトップの新しいキャッチコピーやキービジュアルをどういうものにするのかプロジェクトのメンバーとアイデアを出しながら考えました。しかし、「どのアイデアも間違ってないけどもっといいのがありそうだな」という気持ちが拭えず、なかなか決まりませんでした。

そこで、改めて原点に帰って情報を整理するために次のことに取り組みました。

ユーザーを知る
介護のほんねが提供する価値を整理する
信頼できる情報から納得できる介護サービスと出会えることをキャッチコピーに落とす
介護のほんねの世界観を視覚的に伝えられるようなメインビジュアルの選定

ユーザーを知る

まずはじめに介護のほんねのユーザーデータを 1 件 1 件見ていきました。そこにはお客様の情報や施設を探している理由など様々な情報がまとまっています。それらのデータを見ていくと、おおよそ 4 つのパターンにわけられることがわかりました。

① 退院後の施設を探したい
転倒など何かしらの理由で入院している家族の退院期限が迫っており、退院後に在宅での介護ではなく施設にいれる必要があるケース

② 施設を移動しないといけなくなった
介護度があがったことで施設の受け入れ可能範囲から外れた場合や、施設の中でトラブルがあるなどの事情により施設を移る必要があるケース

③ 今後に備えて早めに動きたい
今すぐ介護施設に入れる必要があるわけではないものの、親が高齢でひとり暮らしをしていて不安なためまだ自分で動けるうちに施設にいれておきたいケース

④ 在宅介護では限界がきてしまった
自分自身も高齢になってきたため、仕事や家事に加えて介護の両立が難しくなってきた方が施設を探しているケース

このようなお客様のデータを見ていると、事情が事情だけになるべく急いで施設を探しているものの、離れても家族が幸せに暮らせるように慎重に施設を探したい、という思いが伝わってきました。

▼ ユーザーの大まかなパターン

介護のほんねが提供する価値を整理する

次に、ユーザーの方に対して介護のほんねができることはどういうことかを整理しました。

介護のほんねは「老人ホーム・介護施設の検索サイト」ということからもわかるように、施設を探すことができ、プロの入居相談員が施設探しから実際の入居までサポートするサービスです。また介護のほんねとしては、お客様が介護に対して前向きに、そして後悔のない施設探しができるよう寄り添いたいという思いがあります。そこで、介護のほんねの価値を機能的なものと情緒的なものにわけて整理してみました。

機能的価値＝すぐに納得できる施設が見つかること
情緒的価値＝家族のために、いろんな思いをもって施設探しをしているユーザーに寄り添うこと

ユーザーデータから見えてきた「事情が事情だけになるべく急いで施設を探しているものの離れても幸せに暮らせるように慎重に施設を探したい」、そのようなユーザーに介護のほんねは寄り添って、後悔することなく納得できる施設がすぐに見つかるようにサポートしていくことを伝えたいなと思いました。

納得できる介護サービスと出会えることをキャッチコピーに落とす

ユーザーやサービスの提供価値について整理をしたところで、新しいコンセプトをサイトトップのキャッチコピーにどう落とし込むのかを考えました。

そもそもサイトトップのキャッチコピーですので、前提として「サービス概要、コンセプトが端的に伝わること」は大事にしたいと思いました。サービス概要は、繰り返しになりますが老人ホーム・介護施設の検索サイトです。そして端的にサービス価値を伝えるためにも、先程述べたサービスの機能的価値である「すぐに納得できる施設がみつかること」をキャッチコピーに盛り込もうと考えました。

色々アイデアを出した結果、「老人ホームが見つかる」というサービスのコア機能に加え、介護のほんねならではの「すぐに」見つかるということや、後悔のない納得いく施設選びができるというエッセンスを入れて、最終的に「納得できる老人ホームがすぐ見つかる」というコピーになりました。

介護のほんねの世界観を視覚的に伝えられるようなメインビジュアルの選定

キャッチコピーはサービスの機能やできることをわかりやすく伝えるものにしたため、キービジュアルは先程述べたサービスの情緒的価値のエッセンスをいれたいと思いました。それを踏まえ、いろんな思いを持った相談者の方に寄り添い、ご家族が施設に入居されてから始まる新しい生活を前向きに捉えられるようなビジュアルにしようと思いました。

キービジュアルの選定にあたり、チーム内で意見を集めながら、色々アイデアが出ました。入居後のイメージやサービス概要が伝わりやすい老人ホームの屋内風景の写真、入居後の楽しい生活が期待できそうな施設のスタッフと入居者の笑顔の写真や、サービスの寄り添うスタンスを抽象的に伝える手を握り合うような写真など、たくさんの写真をあてはめて検討を繰り返しました。

▼ イメージ選定

車椅子が写りこんでいると、自立度が高い状態で施設を探している方（※介護の必要がない元気な方向けの施設もあり、元気なうちから施設に入られる方もいらっしゃいます）にとって自分が使っていいサービスではないのかとマイナスなイメージにならないか？
施設スタッフと入居者が笑顔で写っている人が写ったモデル風の綺麗な写真だと素材感が出すぎて嘘っぽくならないか？
手を包みこむなどモチーフが抽象的すぎるとかえって何も伝わらないのではないか？

写真を選ぶ中でチーム内でも相談しながら、小さな違和感をひとつずつつぶしていきました。そして、最終的に下のようなキービジュアルになりました。

▼ リニューアル前とリニューアル後

これからの新しい生活がポジティブなものに捉えられるような、スタッフと笑顔で生活する入居者が写っており、背景に程よく雑多感が残る素材感を抑えた写真を選びました。写真に写っているのは入居者と入居者に寄り添うスタッフですが、介護のほんねも同じように、施設探しをしている方に寄り添う姿勢がこの写真から間接的に伝われば嬉しいなと思っています。

プロジェクトを終えて

プロジェクトは一段落しましたが、スタートラインにたったところなので、まだまだ追加したい機能や磨き込みたい部分も山積みだなと感じています。

今回、自分のデザインに納得感をだすためにサービスや介護の知識、チームのメンバーが考えていることへの理解を深めながら並行してリニューアルのデザインを手掛けたことは、とてもやりがいのあるものでした。

また、リニューアルをきっかけに改めてサービスの価値や目指したい世界を整理できたのはとても良かったです。これからも介護のほんねの目指したい姿を見据えながら、より多くの方につかってもらえるようなサービスにしていきたいと思っています。

『ソフトウェアテスト技法ドリル―テスト設計の考え方と実際』
『はじめて学ぶソフトウェアのテスト技法』
『ソフトウェアテスト技法練習帳 ~~知識を経験に変える 40 問~~ 』

開発チームと一体となった QA

Tue, 09 Mar 2021 08:53:56 GMT

みなさんこんにちは、メドレーの 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 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。

一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。

（再）「CLINICS の QA」とは？

冒頭で引用した Magic Pod 導入の記事では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。現在は、CLINICS の Web ページ側のテスト自動化も推進しています。

テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。

最初の問いに戻ります。
「CLINICS の QA」とは何か？

品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。

「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。

品質向上のための手段は、テストの他にも実に多岐に渡ります。長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！　ということが開発チームメンバーの共通認識になるとうれしいです。

最後までお読みいただきありがとうございました。

ref. https://nginx.org/en/docs/http/ngx_http_gzip_module.html

HTTP コンテンツ圧縮でパフォーマンス改善

Mon, 01 Feb 2021 09:00:03 GMT

事業本部プロダクト開発室のエンジニアの中畑です。

オンライン診療・服薬指導・クラウド診療支援システム「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ディレクティブを指定する必要があります。

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 にて解決するために日々邁進しています。医療という分野においては、機微な情報を扱ったり診療を止めないようにするために、パフォーマンス・セキュリティ共に高いサービスレベルが求められます。興味を持った方がいらっしゃいましたら、まずは気軽に面談できればと思いますので、是非ご応募ください！

最後までお読みいただきありがとうございました。

UI テストの自動化に Magic Pod を導入した話

Fri, 15 Jan 2021 09:01:26 GMT

こんにちは。インキュベーション本部の 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 についてはプロダクトを跨いだ活動も行っていければと考えています。

長くなりましたが、最後までお読みいただきありがとうございました。

ChatOps な稟議ワークフローシステムを開発しました

Fri, 25 Dec 2020 09:00:58 GMT

はじめに

こんにちは。コーポレートエンジニアの溝口です。メドレーでは、今年 7 月に稟議ワークフローシステムを導入しました。詳細は「システム概要」の章でご紹介しますが、システムの全体像としては以下のようになっております。

ワークフローシステムと聞かれたら、どんなシステムを思い浮かべますか？申請者がシステムで申請すると、予め定められた承認者へ承認依頼がメールで通知され、申請内容の確認及び承認のためにシステムへログインする、という流れがよくあるワークフローシステムではないかなと思います。

我々はコーポレート部門として「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指しています。故に、メドレーの稟議ワークフローシステムにおいても便利で合理的なシステムを目指して開発を行いました。今回ChatOpsの概念を取り入れることで、一般的なワークフローシステムよりも洗練されたシステムを構築できたかなと思います。本稿ではシステム概要及び、裏側の仕組みをご紹介していきます。最後までお付き合いいただければ幸いです。

ChatOps とは

ChatOps とは「チャットサービス（Chat）をベースとして、システム運用（Ops）を行う」という意味です。ざっくり書くと「システムから Chat へメッセージを飛ばし、次のアクションが同じ Chat 画面で開始できる」というものとなります。(下記フローはあくまで一例です)

ChatOps には以下のメリットがあると考えています。

常に立ち上げているツールという共通インターフェースである
インタラクティブなコミュニケーションにつながり、スピーディである
共有しやすく、記録に残しやすい

本稿では、詳しく説明はしませんが、興味がある方は事例等を解説しているサイトもあるので、是非探してみてください。

なぜ ChatOps なのか

稟議申請においては承認者「これ値引きしてもらって ×× 円になったはずだけど、金額間違ってない？」申請者「すいません、変更し忘れました。差戻しお願いします」などのコミュニケーションが度々発生します。通常のシステムであれば、確認事項がある際はシステム内のコミュニケーション機能を使う、もしくは、Chat に URL や稟議番号を転記して確認のためのコミュニケーションを取ることが想定されます。

メドレー内の業務コミュニケーションはSlack上で殆ど完結しています。 Slack ではない他の場所で会話が発生すると情報が分散しますし、Slack に URL を転記するといった行為や、別システムへのログインなども非効率です。そこで、共通インターフェースの Chat を中心にシステム構築する＝ ChatOpsを採用し、稟議ワークフローを構築してみようと考えました。結果、稟議ワークフローシステムの情報を Slack へ連携し、稟議におけるコミュニケーションは Slack に集約、承認行為も Slack 上で可能、というシステムを構築することができました。

システム概要

申請

申請者はTeamSpirit上で稟議内容を記入し、稟議申請を行います。 TeamSpirit とは、勤怠管理や工数管理、経費精算などを管理できるクラウドサービスです。Salesforce をプラットフォームとして採用しており、アイデア次第でいろいろなカスタマイズが可能です。

Slack から申請できるようにするのが ChatOps のあるべき姿かもしれませんが、過去の申請からコピーしたい、申請種別ごとに入力する項目が異なる等の要件を考慮し、TeamSpirit から申請するように設計しました。申請の導線については、今後もよりよい仕組みに磨き上げていきたいと考えています。

承認

申請者が「稟議申請」ボタンを押下すると、Slack の稟議チャンネルに申請内容及び添付ファイルが自動投稿されます。承認者は申請内容に問題がなければ、投稿に配置されているボタンを利用して承認・差戻しが行えます。

承認者は稟議ワークフローシステムへアクセスすることなく、Slack で承認行為が完結できます。稟議内容において確認事項がある場合には Slack の投稿スレッドで申請者と質疑応答のやり取りができ、承認・差戻しの判断に必要なコミュニケーションが行えます。

後続のアクション

承認後には、・申請者に承認 or 差戻し結果を Slack の DM(ダイレクトメッセージ)で通知する

後続の担当者へ Slack で通知する
(法務押印などの)承認後タスクを作成し担当者に通知する等、後続のアクションへつながっていく仕組みも用意しました。

システムの裏側

入力インターフェース

入力画面は、TeamSpirit で標準提供されている稟議オブジェクトを利用しました。入力項目は標準で用意されているコンポーネントを利用し、メドレー独自で定義しています。承認プロセスを定義すれば、Slack を使わずに TeamSpirit のみでも運用は可能です。

Slack 通知

Salesforce の標準機能とApex を用いた Script 処理を使って Slack 通知をしています。

Apex とは、Salesforce 内で利用するビジネスロジック用のオブジェクト指向のプログラミング言語(ほぼ Java)のことです。

Slack 通知までの大きな流れは以下です。

稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更
プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール
Apex 内で申請情報や承認者情報の取得
Slack API をコールし、Slack へ投稿

1~4 のプロセスを詳しく見ていきます。

1. 稟議申請ボタンを押したタイミングでステータス項目を「未申請」から「申請中」へ変更

申請者が「稟議申請」ボタンを押したタイミングで承認プロセスを走らせます。申請時のアクションとして、ステータス「申請中」とします。ステータスが変わる毎に処理を走らせているので、ステータス定義は一つ肝になります。

2. プロセスビルダーにてステータス項目が「申請中」になったことを検知して Apex をコール

プロセスビルダーを利用することで「稟議レコードを作成または編集したとき」に何らかの処理を実施することが可能です。今回は、ステータスが「申請中」になった場合に Apex をコールする、という処理にしています。

3. Apex 内で申請情報や承認者情報の取得

通知に必要な情報を揃えるため、Apex の処理では稟議オブジェクトの申請情報と合わせて次の承認者情報も取得しています。

String ownerId = p.OwnerId;
//申請者のユーザ名を取得
String applicant = [SELECT Username FROM User WHERE Id = : ownerId].Username;
//承認プロセスのレコード取得
String processInstanceId = [SELECT Id FROM ProcessInstance WHERE TargetObjectId = : p.Id ORDER BY CreatedDate DESC limit 1].Id;
//承認者の ID を取得
String approveId = [SELECT OriginalActorId FROM ProcessInstanceWorkitem WHERE ProcessInstanceId = : processInstanceId].OriginalActorId;

4. Slack API をコールし、Slack へ投稿

Apex が取得した情報をもとに、Slack に投稿します。稟議内容を記載し、申請者・承認者に対してメンションされるようにユーザ名も記載します。また、今回は承認者用にインタラクティブボタンを配置する必要があったので、Block Kitを利用し、ボタン付きメッセージを作成しました。

{
  "text": "hoge",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "fuga"
      }
    },
    ...
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "承認"
          },
          "value": "Approve",
          "style": "primary"
        },
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "差戻し"
          },
          "value": "Reject",
          "style": "danger"
        }
      ]
    }
  ]
}

TeamSpirit(Salesforce)→Slack への投稿は開発において苦労したポイントの一つです。

Slack からのアクション

Slack の投稿に埋め込んでいるボタンがクリックされた際は、Lambda を経由して TeamSpirit(Salesforce)の RestAPI をコールし、承認処理を実行しています。また承認後は、ボタンを「承認」スタンプに置き換えています。

開発を終えて

稟議ワークフローシステムを導入するにあたり、ChatOps の概念を取り入れ Slack に連携する業務システムを構築しました。承認者からは「Slack で承認やコメントができ、社外からでもすぐに対応できるので便利」「Salesforce-Slack 連携は他にも活用できるので是非やっていこう」などのコメントをいただきました。また、承認後にもスレッドにて、「振込お願いします」「物品届きました」等のやりとりも行っており、情報が Slack に集約されていく狙い通りの運用になったかと思っています。

Chat サービスを利用している会社では、今回ご紹介した ChatOps は業務効率化するにあたり、有効な手法になるのではないでしょうか。もちろん、すべて Chat に連携すればよいというものでもなく、しっかり設計や運用検討を行う必要があります。今後は ChatOps に限らず業務効率化につながるものはどんどんやっていきたいと考えています。

さいごに

メドレーのコーポレート部門では「徹底的に合理性を追求した組織基盤や、仕掛けづくりを行っていく」ことを目指して、業務効率改善のための開発を推進しています。面白そう！と感じた方、メドレーでどんどん改善してみたい！と思っていただけた方は、ぜひ弊社採用ページからご応募お願いします！

最後まで読んでいただきありがとうございました。

CloudFront のエラー監視精度を上げた話

Wed, 23 Dec 2020 08:54:28 GMT

はじめに

はじめまして、メドレー新卒入社 2 年目の森川です。

インフラ経験がまだ 4 ヶ月ほどの未熟者ですが、AWS 認定資格クラウドプラクティショナーの試験に合格することができました。上位の資格取得に向けて今後も勉強していきます。

先日私が担当させていただいた CloudFront のアラート改善について、問題の原因と対応方法を本記事で書かせていただきます。

よろしければお付き合いください。

背景と問題

弊社が運営しているプロダクトの一つジョブメドレーではインフラ環境に AWS を利用しています。

監視には CloudWatch や Datadog などを使用しています。サービスの異常を検知するための設定のひとつに、CloudFront のエラーレスポンス増加を検知するためのアラート通知があります。

CloudFront が返すレスポンスのうち、特定の時間範囲の中で 4xx, 5xx 系のエラーを返した割合が閾値を超過したことを検知して、CloudWatch アラームから Lambda を通して Slack に通知を行っています。

ところが、ある頃を境に CloudFront での 4xx 系エラーレスポンスの発生割合が増加し、アラートの通知頻度が想定以上に高くなってしまいました。

原因

調査を行ったところ、刷新した社内システムにて以下 2 つの原因でアラートが発生していることが分かりました。

原因 1. 社外サービスからのアクセスでアラートが発生

CloudFront のログを確認したところ、社外サービス（Slack, Google スプレッドシートなど）からのアクセスに対してステータスコード 403 を返しているレスポンスログが数多く記録されていました。

これらのサービスに弊社の社内管理システムの URL がポストされると、プレビューを表示するためのリクエストが送信されますが、この時のリクエストが社外からのアクセスとして WAF で制限されていました。

インフラ刷新前から現在まで稼働している CloudFront のログも確認したところ、こちらでも同様のエラーレスポンスが発生していることが分かりました。しかし、エラー割合増加のアラートが頻発することは現在でもほとんどありません。

以前はジョブメドレーが持つシステム全体へのアクセスをひとつの CloudFront で処理していたため、アラート通知の割合として計算する際の母数が大きく、社外からのアクセスによるエラーが発生していても、その割合が閾値を超過することが少なかったからだと考えられます。

インフラ構成を刷新したことをきっかけに、これまで目立っていなかった社外からのアクセスという問題が表面化してきたのです。

原因 2. 利用者が少ない時間にエラーレートが高くなりアラートが発生

CloudWatch アラームでは、一定期間内でのレスポンスのうち、4xx, 5xx 系のエラーごとにその割合が閾値を超過したことを検知してアラートを発生させる設定としていました。

しかし、深夜など利用者が少ない時間に一度でもエラーが発生すると、その割合が跳ね上がってしまうことでアラート発生頻度が増加し、誤検知と言える状態になっていました。

以下の画像では、4xx 系エラーの割合が夜間に 100%となっている箇所が確認できます。（表示時間は UTC です）

対応方法

2 つの原因に対し、それぞれ対応を行いました。

対応 1. 特定の社外サービスからのアクセスをエラー検知の対象外とする

各サービスの設定により、プレビュー表示によるアクセスを停止させる選択肢が考えられます。しかし、該当するサービスすべてに設定を行うのは難しく、管理も複雑になりそうです。

そこで、特定の社外サービスからのアクセスを エラー検知の対象外とする 方針で対応を行いました。

ログのすべてを CloudWatch アラームの評価対象としていたために、誤検知と言えるアラートが発生しているのが現状です。したがって、評価させたいログだけに絞り CloudWatch で評価させることができれば解決が図れます。今回であれば、特定のユーザーエージェントや IP アドレスなどを除外して CloudWatch に渡すという処理が求められます。

その実現のため、今回新たに作成したのが Lambda の関数です。

S3 に CloudFront のログが保存されたことをトリガーに Lambda を起動させるように設定しました。

ログごとに記録されているリクエスト元のユーザーエージェントや IP アドレスなどを確認し、除外対象かどうかを判定します。

そうして選別を通過したログを今度はステータスコードの 5 つのクラス（1xx, 2xx, 3xx, 4xx, 5xx 系）ごとに振り分けます。

ただし、CloudFront ではステータスコードに 000 が入ることがあります。

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html

ステータスコード 000 はアラートで検知したところで対応できることが特にないため、検知対象から除外する方針としました。

（S3 のログを直接確認すると 000 なのですが、Athena でログを確認すると 0 で表示されるため、少しハマりました）

こういった意図しない値がステータスコードに含まれていた場合などを検知できるようにするため、5 つのクラス以外の値が含まれていた場合に UNKNOWN_STATUS_CODE なクラスとして分類するようにしました。

必要なものに絞ったログを 6 つのステータスパターンに分け、それぞれの件数を CloudWatch メトリクスへ PUT させます。

ここまでが Lambda の仕事となります。

各ステータスのログの件数を CloudWatch メトリクスで確認できるようになったので、レスポンス全体における 4xx, 5xx 系エラーの割合が算出できます。これを元に閾値を設定し、以前のようなアラートを作成することができました。

対応 2. CloudWatch アラームの検知ルールを調整する

利用者が少ない時間にエラーレートが高くなりアラートが発生する件については、 CloudWatch アラームの検知ルールを調整 することによって対応しました。

一定期間でのエラー数に閾値を定め、超過した際にアラートを通知するように変更しました。つまり、割合ではなく絶対数で判断させるようにしています。

以下の画像の緑色のグラフが新たな検知ルールで参照するものとなります。橙色で示しているのが 4xx 系エラーの割合ですが、これが 100%となっている箇所においても新たな検知ルールには反応していないことが分かります。

対応を終えて

Lambda を用いた集計処理の作成と、アラートの検知ルールの調整を行うことで、CloudFront のエラー監視精度を向上させることができました。

以前は頻繁にアラートがあがっていましたが、対応後はすっかり落ち着きを見せています。

システムの安定稼働を実現するためにも、適切にアラートを検知できるように今後も改善を図っていきたいと思います。

今回の課題に対する解決手段としてはシンプルな対応であったかとは思いますが、私には実りの多い紆余曲折な経験となりました。

AWS の基本的なサービスの連携を学ぶことができたことに加え、新たに作成する AWS のサービスの課金額の試算や、実行計画を定めてからの実装など事前準備を意識して取り組むことができました。恵まれた環境の中、日々学ばせていただいております。

さいごに

メドレーでは「医療ヘルスケアの未来をつくる」というミッションを掲げ、各プロダクトの開発・運営が進められています。

エンジニア・デザイナーをはじめ多くのポジションで新たなメンバーを募集しています。ご興味をお持ちいただけた方は、ぜひお気軽にお話しさせていただければと思います！

ここまでお付き合いいただき、ありがとうございました。

AWS MediaConvert と hls.js で動画配信サービスを構築しました

Fri, 27 Nov 2020 08:00:06 GMT

こんにちは、第一開発グループの矢野です。ジョブメドレー開発エンジニアとして、主にバックエンドを担当しています。

直近では、ジョブメドレーが先月リリースした 「動画選考」 機能の開発プロジェクトに携わっており、動画ファイルのアップロード／配信環境の設計・実装を行っていました。

今回のブログでは、この「動画選考」機能の開発に利用した AWS Elemental MediaConvert サービスと、hls.js という OSS ライブラリについて紹介したいと思います。

ジョブメドレーの「動画選考」機能

はじめに、今回リリースした「動画選考」機能について概要を紹介します。

新型コロナウイルス感染拡大によって、対面での面接に不安を感じたり、公共交通機関の利用が難しくなったりすることにより、満足な転職活動ができなくなっている方もいらっしゃるかと思います。このような課題を解決するために、ジョブメドレーではリアルタイムにオンラインで面接を行う「WEB 面接」と、事業者があらかじめ設定した質問に対して応募者が動画で回答を送る「動画選考」の 2 つの機能を提供開始いたしました。

ref. WEB 面接・動画選考機能のリリースのお知らせ

動画選考（動画面接）は、近年増加傾向にあるオンライン選考の一種です。一般的に、求職者 / 就活生が PC ・スマートフォン等のカメラで、予め用意された設問に応じて動画を撮影し、企業に送ることで選考を行います。

ref. WEB 面接・動画選考とは？実施の流れ、使用ツール、マナー、注意点などを徹底解説！

私たちジョブメドレーの動画選考では、事業所があらかじめ設定した質問に対して、求職者が回答動画を提出することができます。事業所も求職者も、動画で質問・回答を送ることで、書類だけでは伝わらない雰囲気や強みを相手に伝えることができます。

WEB 面接・動画選考機能のリリースのお知らせ

動画配信サービスの設計ポイント

Web アプリでこのような動画配信サービスを開発する場合、「ユーザによる動画アップロード環境」と「ユーザへの動画の配信・再生環境」を提供する必要があります。

ジョブメドレーで扱う動画は一般公開されるものではなく、公開条件も複雑です。

よって今回は、この「動画アップロード／配信環境」を自サービス内に構築する方針をとり、以下のような動画まわりの設計ポイントについて検討・技術選定を行うことにしました。

（もちろん、要件によっては YouTube や、法人向け動画配信プラットフォームを契約した方が手軽な場合もあるかと思います）

動画の録画・撮影
- サポートしたい動画ファイルのフォーマットをどうするか
- Web アプリ内に録画機能を設けるか
動画のアップロード（ストレージ）
- 動画ファイルのバリデーションで「動画ファイルの解析」を行うか
- 動画ファイルのアップロード先（ストレージ）をどこにするか
動画のエンコード
- 動画ファイルのエンコード形式（H.264、HLS 等）をどうするか
- 非同期エンコードの場合、ステータス検知・エラーハンドリングをどうするか
動画の配信（ダウンロード）
- 配信形式（ダウンロード／ストリーミング）をどうするか
- 暗号化をする場合、復号をどのように行うか
- 動画ファイルの公開方法（アクセス制限）をどうするか
動画の再生
- Web ページ上で再生させるのか、その場合の表示・再生制御をどうするか
- ブラウザサポートをどこまでにするか、非対応・エラー時の制御をどうするか

今回は、上記の太字で記載した 「動画のエンコード」に MediaConvert を、「動画の再生」に hls.js をそれぞれ採用しています。

各項の詳細は省きますが、全体を通して大まかに、以下のフローで「動画アップロード → エンコード（変換）→ 配信・再生」を実現することにしました。

ブラウザから Ajax で動画を S3 へアップロードする
MediaConvert が動画を HLS 形式にエンコード（変換）する
ブラウザで hls.js を使い動画を CloudFront からストリーミング形式で受信、再生する

今回はこの「動画アップロード → エンコード（変換）→ 配信・再生」に焦点を絞り、MediaConvert と hls.js をどのように使ったのかを紹介します。

MediaConvert による HLS エンコード

AWS Elemental MediaConvert は、S3 との親和性が高いファイルベースの動画変換サービスです。自前で ffmpeg などを使って動画エンコードサーバを構築・管理することなく、スケーラブルな動画変換処理を手軽にシステムに組み込むことができます。

ref. AWS Elemental MediaConvert

料金は出力する動画の再生時間に応じた従量課金です。AWS コンソールから GUI ベースでエンコード設定を作成したり、ジョブ（エンコード処理）を登録することができます。

また、他 AWS サービス同様に API が提供されており、AWS CLI や各言語の SDK を使ってプログラムからエンコード処理を登録することができ、システム連携も容易です。

# CLI でエンコードジョブを登録する例
$ aws --endpoint-url https://abcd1234.mediaconvert.region-name-1.amazonaws.com --region region-name-1 mediaconvert create-job --cli-input-json file://~/job.json

上記 CLI コマンドで下のようなエンコード設定を記載した JSON を使いジョブを作成すると、S3 上の動画ファイルをサクッとエンコードしてくれます。ジョブはキューイングされ、内部で並列処理されるため、大量のエンコード要求にも簡単に応じることができます。

{
  ...
  "Settings": {
    "Inputs": [
      {
        # 入力元の S3 バケット上の動画ファイル key を指定
        "FileInput": "s3://testcontent/720/example_input_720p.mov"
      }
    ],
    "OutputGroups": [
      {
        "OutputGroupSettings": {
          "FileGroupSettings": {
            # 出力先の S3 バケット key を指定
            "Destination": "s3://testbucket/output"
          }
        },
        # 動画・音声のエンコード設定を指定
        # ここで品質レベル毎に振り分けた複数のファイルを出力したり
        # サムネイル jpg を作成したりすることも可能
        "Outputs": [
          {
            "VideoDescription": { … },
            "AudioDescriptions": { … }
          }
        ]
      }
    ]
  }
}

ref. AWSCLI を使用した AWSElemental MediaConvertCreateJob の例

エンコードが完了したジョブは、cron + SDK などで API を介して定期チェックする他に、CloudWatch Events によるイベント監視 → Lambda で処理するようなこともできます。

ref. AWS Elemental MediaConvert による CloudWatch イベントの使用

なぜ動画を再エンコードするのか

通常、ユーザからアップロードされる動画ファイルは、既に何らかのコーデックで圧縮され .mp4 や .mov などのコンテナフォーマットに変換されていることが殆どです。

しかし Web ページで <video> タグを使いこれら動画ファイルを再生しようとした場合、 「動画フォーマットにブラウザが非対応だと再生できない」 という環境依存問題があります。

ブラウザと動画フォーマットのサポート表

ref. HTML5 video > Browser support

この問題に対応するため、多くの動画配信サービスでは、ユーザの動画を多くの環境で再生可能な MP4 コンテナフォーマット（H.264 + AAC コーデック）などの形式へ「再エンコード」しています。

ジョブメドレーの動画選考では上記目的に加えて、動画閲覧時の回線・端末負荷を抑える 「HTTP ストリーミング形式」 で動画を配信するために、アップロードされた動画を全て HLS 形式 にエンコードしています。

HLS - HTTP Live Streaming 形式

HLS は HTTP Live Streaming の略で、Apple 社の開発した規格です。HTTP ベースのストリーミング通信プロトコルで、細切れにした MP4 動画ファイルを分割ダウンロードさせることで動画のストリーミング配信を実現しています。

HLS 形式にエンコードされた動画は .ts という分割されたメディアファイル群と、 .m3u8 という、メディアファイルの取得先や秒数などを記載したテキストファイルで構成されます。

.m3u8 ファイルの例（マニフェストファイル、プレイリストファイルとも）

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:9.97663,
media-0.ts
#EXTINF:9.97663,
media-1.ts
#EXTINF:7.10710,
media-2.ts
#EXT-X-ENDLIST

ref. RFC 8216: HTTP Live Streaming

HLS は他のストリーミング形式と比較して、ライブ配信 / VOD どちらにも対応可能なこと、対応ブラウザが多いこと、専用の配信サーバを使わずに配信可能なことなどから、近年の動画配信サービスで広く利用されています。

Web エンジニアの視点から見ても、 HTTP ベースなためキャッシュや HTTPS 暗号化など、既存 Web 技術と掛け合わせることが想像しやすく、扱いやすい印象でした。

MediaConvert の HLS エンコードジョブ設定

実際にプログラムから API 経由で HLS エンコードジョブを登録する際の設定 JSON は、以下のように GUI でジョブテンプレートを作成して確認することができます。

この「 JSON を表示」で、前述した CLI コマンド mediaconvert create-job --cli-input-json に渡せる JSON が表示されます。実装の際にはこちらを参考にしながら、ユーザーガイドを参照して利用したい機能にあわせた設定を追加していくことをおすすめします。

注意点・つまづいたポイント

利用前に IAM で MediaConvert 用ロールの設定が必要です
- ステップ 3. IAM 権限の設定
AWS コンソールの Service Quotas > AWS サービス > AWS Elemental MediaConvert から確認できますが、エンコード並行処理の同時実行数上限は 20 になっています
- AWS ルートアカウント 1 つにつき 1 サービスが割当てられるので、これを増やしたい場合は申請が必要です
エンコードジョブをキューイングする「キュー」を作成して、ジョブの登録時に選べるのですが、上記した「並行処理の同時実行数上限」はこの「キュー」毎に均等に振り分けられます
- 例えば「本番キュー」と「検証キュー」の 2 つのキューを作成した場合、それぞれの並行処理の同時実行数上限は 10 ずつになるので注意してください
マニフェスト期間形式（Manifest duration format）に整数（INTEGER）を指定していると、iOS Safari で「動画の実際の再生時間と、再生プレイヤーのシークバーに表示される合計時間にズレが生じる」問題がありました
- 浮動小数点（FLOATING POINT）に変更することで対応しました、マニフェストファイルに出力される各 .ts ファイルの長さが、浮動小数点 → 整数に変換され切り上げられることでズレが生じているようでした

hls.js による HLS 動画の再生制御

MediaConvert により HLS 形式にエンコードされた動画を、Web ブラウザで再生するために必要なのが、hls.js です。

ref. video-dev/hls.js

実は HLS によるストリーミング配信は、現状 Safari など限られたブラウザでしかネイティブでサポートされていません。

ref. https://caniuse.com/http-live-streaming

この HLS 動画を Safari 以外の Google Chrome や IE11 などの主要ブラウザで再生可能にするため、hls.js が利用されています。内部的には、非対応ブラウザ環境において、ブラウザの MediaSource 拡張を使って HLS 動画を再生する仕様になっています。

Video.js との比較

似たようなライブラリに Video.js というものもあり、導入を迷ったのですが …

Video.js は UI もセットになった「 HLS に対応した再生プレイヤー」ライブラリ
- HLS 対応以外にも、字幕や章分けなど機能が豊富
hls.js はブラウザ標準の <video> タグで HLS に対応することだけを目的にした「 HLS クライアント」ライブラリ
- UI などはなく、動画再生プレイヤーはブラウザ標準のまま

…と、上記のように hls.js の方がシンプルにやりたいことを実現できるため、今回は hls.js を採用しました。

GitHub のスター数は先発の Video.js の方が多いのですが、hls.js も開発は活発で、日本ではグノシーさん、世界的には TED や Twitter でも採用されており、十分実績があるかと思います。

hls.js による実装

基本的には README の Getting Started の通りで実装できます。一部 README のサンプルコードから抜粋して解説すると…

var video = document.getElementById("video");
var videoSrc = "https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8";

if (Hls.isSupported()) {
  var hls = new Hls();
  hls.loadSource(videoSrc);
  hls.attachMedia(video);
  hls.on(Hls.Events.MANIFEST_PARSED, function () {
    video.play();
  });
}

上記 Hls.isSupported() の分岐で、HLS をネイティブサポートしていないブラウザの処理を実装しています。本来 <video> の src 属性にセットするべき .m3u8 ファイルの URL へ hls.loadSource() でアクセスさせ、クライアントから XHR リクエストを飛ばします。その後 hls.attachMedia() でインスタンスを DOM 上の <video> タグに紐づけています。

  else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    video.src = videoSrc;
    video.addEventListener('loadedmetadata', function() {
      video.play();
    });
  }

上記の分岐が iOS Safari など、HLS 動画をネイティブサポートしているブラウザ向けの処理です。単純に .m3u8 への URL を <video> タグの src へ付与しているだけですね。

（サンプルコードでは、マニフェストファイルのロード後に自動再生させるようになっているようです）

注意点・つまづいたポイント

hls.js クライアントが取得する HLS 動画ファイル群は、CORS ヘッダで GET リクエストを許可された環境に設置する必要があります
.m3u8 マニフェストファイルをアプリの API などから返却する場合、Content-Type を application/x-mpegURL にして渡す必要があります
iOS Safari などの hls.js 非対応ブラウザ向けの実装を意識する必要があります
- hls.js による制御が複雑になるケースでは、同じような制御を hls.js 非対応ブラウザ向けに実装できるか？をイメージできないと手戻りが発生しそうです

この他、フロントエンドでは <video> タグのブラウザ毎の挙動や、表示の違いに時間がかかりました。（ある程度予想はしていましたが、やはりメディアの取り扱いは難しい…）

hls.js 自体は導入も手軽で、サクッと HLS 動画のマルチブラウザ対応が実現でき、とても使いやすかったです。@types も存在するので、TypeScript 環境でも難なく実装できました。

SSR や HLS + AES-128 の再生にも対応しているので、興味のある方は一度公式ドキュメントを確認してみてください。

おわりに

従来、動画配信サービスを構築する場合、ffmpeg を載せたエンコードサーバや、ストリーミング配信サーバを別建てして、負荷に応じてスケールさせて…のような設計が必要だったかと思います。

今回、MediaConvert をはじめとした AWS サービスと hls.js を利用することで、手軽に、スケーラブルな動画エンコード／HTTP ストリーミング配信環境を構築することができました。

ジョブメドレーの動画選考はまだリリースしたばかりですので、今後反響を見ながら、さらなる改善を重ねていけたらと思います。最後までお読みいただきありがとうございました。

WEB 面接の裏側

Thu, 26 Nov 2020 10:01:03 GMT

株式会社メドレーのエンジニアの笹塚です。私が開発を担当しているジョブメドレーで、先月 10 月 23 日に WEB 面接・動画選考をリリースしました。

job-medley.com WEB 面接、動画選考ともに、昨今の非対面での就職活動ニーズに応えるべく開発しました。

リリースは 2 つの機能を同時ですが、今回は WEB 面接の裏側に絞ってご紹介します。

WEB 面接概要

WEB 面接とは、リアルタイムで事業者様と求職者様が、オンライン面接を行うことができる機能です。専用のアプリケーションは必要なく、PC、スマートフォンのブラウザから利用できます。

サービス選定

開発にあたり、いくつかの候補があがりましたが、最終的には自社内でも導入実績のある SkyWay を使用することにしました。

SkyWay とは

WebRTC（Web Real Time Communication）を使用したオンラインのビデオ通話を、サービスに導入できるマルチプラットフォーム SDK です。

2020 年 11 月時点で、JavaScript SDK、iOS SDK、Android SDK が提供されています。

シグナリングサーバなどの WebRTC に必要となるインフラ構築が不要です
使用上限つきの無料プランもあります
NTT コミュニケーションズが開発しています

webrtc.ecl.ntt.com

WEB 面接の対応ブラウザバージョン（2020 年 11 月時点）

プラットフォーム	対応バージョン
PC: Google Chrome	バージョン 84 以上
PC: Microsoft Edge	バージョン 84 以上
iOS: Safari	iOS12 以上
Android: Google Chrome	バージョン 85 以上 Andoid9 以上

SkyWay JavaScript SDK の動作確認ブラウザ、WebRTC の対応状況、利用者の利用傾向から対応ブラウザのバージョンを上記のように設定しました。

webrtc.ecl.ntt.com

SkyWay の接続モデル

SkyWay でビデオ通話を実装する場合、2 種類の接続モデルから選びます。

SkyWay 電話モデル

電話のように 1 対 1 でのビデオ通話を想定したモデルです。
Peer インスタンス(シグナリングサーバによって発行された一意の PeerID を持つ)同士で接続します。
接続するためには、相手の PeerID が必要になります。

SkyWay ルームモデル

同一ルーム内の全ての Peer でビデオ通話するモデルです。
ルーム名を使用して参加します。相手の PeerID を知る必要はありません。
ルーム名は API キー毎に独立しています。
ルームの接続タイプはフルメッシュか SFU の 2 種類から選べます。
参加者全員へのチャットなどのデータ送信もできます。

ジョブメドレーの WEB 面接では、今後の機能拡張を想定して、こちらのルームモデルを採用しました。

ルームの通信タイプ

ルームに複数人が参加している場合、それぞれの通信をどう行うかを、メッシュと SFU から選ぶことができます。

フルメッシュ

画像引用元: https://webrtc.ecl.ntt.com/skyway/overview.html#_4-sfu%E3%82%B5%E3%83%BC%E3%83%90

全員が相互に通信を行います。人数が増えると、人数分端末のエンコード負荷と通信量が増加します。

SFU

SFU の場合、上りの接続は 1 本になるので、メッシュよりも端末のエンコード負荷や、通信量の軽減が期待できます。

画像引用元: https://webrtc.ecl.ntt.com/skyway/overview.html#_4-sfu%E3%82%B5%E3%83%BC%E3%83%90

通信方式の違いは SkyWay が隠蔽してくれるので、joinRoom 時の mode を mesh から sfu に変更するだけで切り替わります。

peer.joinRoom(roomName, { mode: "mesh か sfu を指定", stream: mediaStream });

webrtc.ecl.ntt.com

ジョブメドレーの WEB 面接では、面接参加人数を考慮して mesh を使用しています。

実装イメージ

const peer = new Peer(peer_id, {
  key: api_key,
});

peer.once("open", () => {
  room.once("open", () => {
    // ルーム参加後に発生するイベント
  });

  room.on("peerJoin", (peerId: string) => {
    // ルームに誰か参加した場合に発生するイベント
  });

  room.on("stream", (stream: RoomStream) => {
    // stream を受けた場合に発生するイベント
  });

  room.on("data", ({ src, data }) => {
    // data を受けた場合に発生するイベント
  });
});

peer.on("error", (error: Error) => {
  // エラー発生時に発生するイベント
});

peer.joinRoom(roomName, { mode: "mesh", stream: mediaStream });

room.close();

peer.disconnect();

Peer を作成し

peer.joinRoom() でルームに参加
room.stream イベントで他の参加者の stream を受け取る
room.data() でチャットなど、データ送信もできる
room.close() でルームから退出が SkyWay の JavaScript SDK を使用した基本的な実装になります。

この実装に

navigator.mediaDevices.getUserMedia() で取得した stream を joinRoom で渡す
steam イベントで受け取った stream を video で再生する

を追加すれば、オンラインでのビデオ通話が可能になります。

スマートフォン対応

PC と同様のコードでほぼ動作しましたが、iOS や Android 端末で、機種依存と思われる挙動の調査と対応に時間がかかりました。その一部を紹介します。

タブを移動すると映像が映らない

発生した問題 iOS12、iOS13 などで

複数のタブをひらいた場合に、映像の取得ができなくなる
スクリーンロックからの復帰時に、映像が取得できなくなる

という問題が起きました。iOS14 ではタブ切り替え時に映像を取得できるようになっていましたが、スクリーンロックからの復帰時は映像を取得できないままでした。

対応

この対応は visibilitychange イベントで、タブの切り替えと、スクリーンロックからの復帰時のイベントを拾い

取得済の stream の track を stop する
stream を取り直す
SkyWay の room.replaceStream() で、WebRTC で使用している stream を差し替える

以上の実装により、対応しました。 __

document.addEventListener("visibilitychange", async () => {
  if (document.visibilityState !== "visible") {
    return;
  }

  localMedia.getTracks().forEach((track: MediaStreamTrack) => {
    track.stop();
  });

  const replaceStream = await navigator.mediaDevices.getUserMedia({
    video: true,
    audio: true,
  });

  room.replaceStream(replaceStream);
});

イヤホンの操作で映像が止まる

発生した問題

iOS12、iOS13 では起こりませんでしたが、iOS14 でオンライン面接途中にイヤホンをスマートフォンから外すと、相手側の映像が止まるようになりました。

対応

それまでは、相手の映像と音声を再生するために、video タグに stream を渡して映像と音声を再生していましたが

video : mute にして映像を再生
audio : 音声を再生

と、音声と再生を分けたところ、イヤホンを外しても停止することはなくなりました。

制約設定

getUserMedia で取得する MediaStream は、制約を設定することでデバイスの消費リソースを抑えることができます。

設定例:

navigator.mediaDevices.getUserMedia({ audio: true, video: true });

↓

navigator.mediaDevices.getUserMedia({ audio: true, video: { frameRate: 15 } });

制約が設定可能かどうかの確認:

getSupportedConstraints() で、対応している制約名を取得することができます。

const supportedConstraints = navigator.mediaDevices.getSupportedConstraints();

使用しているブラウザがその制約に対応しているかを確認し、対応している場合のみ設定を有効にします。

例えば、スマートフォンの場合に以下の設定をすれば、インカメラを使用し、フレームレートを 20 に抑え、320x320 の解像度に制限することができます。

const options = { facingMode: "user", frameRate: 20, width: 320, height: 320 };

指定した制限が必ず使用される保証はなく、機種依存の影響を受ける設定でもあるので、対象としている環境にあわせて検証と調整をする必要がある点には注意が必要です。

動作検証中に、機種依存と思われる挙動をした例を紹介します。

オプション	挙動
frameRate	指定すると一部 Android 端末で以下の挙動をした。 1. Android 端末で面接に参加する 2. iOS Safari で参加する 3. Android 側の映像と音声が Safari に送られない Safari で先に参加する場合には問題がない。
解像度指定	例: width: 320, height: 320 frameRate だけ指定していたときに上記の挙動をした Android、iOS Safari の組み合わせで問題が起こらなくなった。

解像度を指定するとインカメラではなく、リアカメラを使う Android 端末があった。

制約設定については、現在も調整中です。

参考情報

SkyWay Conference

conf.webrtc.ecl.ntt.com github.com

SkyWay のルーム機能を使用したデモ環境です。 GitHub にコードも公開されているので、ルームを使用した場合の挙動と実装方法を確認できます。開発をしていると、実装の問題なのか、SkyWay の SDK の仕様なのか、特定のデバイスで起こる問題なのかの切り分けに時間がかかるため、こちらの環境が参考になりました。

まとめ

SkyWay が WebRTC とグループでのビデオ通話の実装を統合して提供してくれるため、開発時は、自社サービスとしての WEB 面接の機能に集中することができました。

スマートフォンのブラウザ対応と調査に時間がかかることもありますが、今後も利用者からのフィードバックを得ながら改善していきたいと思います。

メドレーでは、ニーズにあわせた新機能の開発にも力を入れています。多くの利用者に実際に使われるサービスの開発をしてみたいと思った方、ぜひお気軽にお話しましょう！

GraphQL, TypeScript, React を用いて型安全に社内システムをリニューアルした話

Fri, 06 Nov 2020 09:02:08 GMT

こんにちは。メドレーのエンジニアの山田です。現在、医療介護求人サイト「ジョブメドレー」のチームで開発を担当しています。

今回、ジョブメドレーの社内スタッフが利用する社内システムをリニューアルした事例をご紹介します。

リニューアル対象はバックエンド領域も含まれますが、本記事ではフロントエンドの話を中心にご紹介します。

また、弊社デザイナー酒井が以前投稿したデザイナーがデザインツールを使わずに、React を使ってデザインした話も関連しているので、よろしければあわせてご覧ください。

リニューアルの背景

社内システムでは、求人サイト「ジョブメドレー」を利用する求職者に関する情報や求職者の応募状況を管理しています。

前回のリニューアルから時間が経ち、複雑性が高くなってきました。その複雑性に比例して、新機能の追加や改修するためのコストも高くなっていました。

そこで上記の課題を解決するため、状態管理がしやすく、テストコードも書きやすい、メンテナブルなアーキテクチャにすべくリニューアルを実施することにしました。

検証期間も経て、今回のリニューアルにあわせて新規に作成する API は、GraphQL によって実装することを決めました。

型システムを持つため画面に必要なデータを柔軟に過不足なく取得できる、手動でドキュメントに落とし込まなくてもスキーマが定義されていれば API の仕様を簡単に把握できる、等がメリットとして感じられました。

特に、GraphQL が持つ型システムが、TypeScript、Apollo、GraphQL Code Generator のライブラリを組み合わせることで、API に渡すパラメータや、レスポンスにも型が適用され、GraphQL スキーマの変更にクライアントの実装が比較的容易に追従できることが、大きなポイントでした。

フロントエンドの技術的なリニューアル内容

今回は特に、リニューアルに用いられたフレームワークやライブラリ、Apollo Client を用いた状態管理、テストコード実装における Tips 等をそれぞれ部分的にご紹介します。

採用したフレームワークと主要ライブラリ

採用ライブラリ	説明
Next.js	React 用のフレームワーク（ボイラープレート）
TypeScript	JavaScript のスーパーセットで、静的型付け言語
React	UI を構築するためのライブラリ（バージョン 16.8.0 でリリースされた hooks を全面的に使用）
Apollo Client	GraphQL API のクライアントで、アプリケーション全体の状態管理を実施
GraphQL Code Generator	GraphQL スキーマから定義ファイル（型、カスタム hooks 等）を生成
emotion + Styled System	CSS in JS として利用
formik + yup	フォームのビルダー + バリデーター
Jest + React Testing Library	テストコード実装用のツール群
ESLint + Prettier	ルールに基づいたコードの静的解析 + スタイリング

TypeScript

今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。

そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。

React

UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点から、新たに他のフレームワークを選択するメリットはほぼ無かったためです。しかし、その事を差し引いたとしても TypeScript と GraphQL との相性の良さで、React が優勢でした。

特に、React の場合は、GraphQL スキーマをベースに、GraphQL Code Generator によって型定義ファイルだけではなく、GraphQL API とのやり取りに使えるカスタム hooks も生成して利用できるという点が、大きな利点として考えられました。

Next.js

フロントエンド開発環境を素早く構築するため、ボイラープレートとして Next.js を採用しました。

Next.js の具体的な採用ポイントとしては、主に次の３点です。

webpack における、バンドルやコンパイル、ホットリロード等の設定に時間を費やすことなく、ビジネスロジックの実装に集中できる
- 必要があれば、next.config.js で設定を拡張できる
- CRA（Create React App）とは異なり、拡張性に優れている
pages 配下に置く React Component のディレクトリ構成が、自動的にルーティングとして定義される
- ルーティングに関する設計作業が不要になる
自動コード分割等によるパフォーマンス最適化をよしなに行ってくれる

React Component の分類

component は大きく２つに分類し、src/components/app/とsrc/components/ui/ それぞれのディレクトリに component を置いています。分類は以下の基準で行ないました。

app: 本アプリケーション固有で使用される想定のもので、再利用性が低く、具体的な component
ui: 本アプリケーション外でも使用可能な、再利用性が高く、抽象的な component

社内向けシステムではあるものの、Material-UI や Ant Design 等をはじめとする、外部の UI ライブラリは使用せず、カスタマイズがしやすいように、全て自前で作成しました。

app配下とui配下、どちらの component も基本的にはコロケーションの考え方でファイルを構成しています。

一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。この原則は、「コロケーション」と呼ばれます。

この考え方でファイルを構成することで、関連するファイルがまとまっていて、作業がしやすくなります。


src/
  components/
    app/
      partials/
        ${component 名}/
          apollo.cache.ts
          apollo.query.graphql
          index.tsx
          index.test.tsx
        ...

      screens/
        ${component 名}/
          apollo.cache.ts
          apollo.query.graphql
          index.tsx
          index.test.tsx

          ${子 component 名}/
            apollo.cache.ts
            apollo.query.graphql
            index.tsx
            index.test.tsx
            validation.ts

src/components/app ディレクトリ配下でさらに、partialsとscreensのディレクトリで component を分けています。

screensには、Next.js で route として扱われる src/pages 配下の component から import される component が配置されています。

画面のバリエーションが増える度に、このscreensにファイルが追加されていきます。

partialsには、app 配下で複数の component から利用される component（画面をまたいで共有されるもの等）を配置しています。

screensとpartialsそれぞれ直下の component で、必要であれば適宜、component を分割して子 component を持つ構成にしています。

apollo.cache.tsとapollo.query.graphqlについては後述の状態管理の話でご紹介します。

状態管理

アプリケーションの状態管理については、グローバルにアクセスできる状態の管理には Apollo Client の InMemoryCache による cache 機構で行い、特定の component 内に閉じている局所的な状態の管理にはuseState等の React Hooks を使って行っています。

状態管理の必要性が生じた際、アプリケーションの複雑性を上げないように、なるべく useState 等の hooks を用いた local state だけで済ませられないかどうかを検討します。

例えば、クリックするとドロップダウンリストが表示されるセレクトボックスの component で、ドロップダウンリストの表示状態をその component 内だけで扱いたいのであれば useState を用いた local state で十分であると考えられます。

親子関係ではない component 同士でのやりとりが必要になった時や、サーバのデータと関連する場合等で、ローカルのデータを一元管理しておいた方が良さそうなケースでは、Apollo Client の cache を利用します。

Apollo Client

Apollo に関連するファイルの構成については以下の通りです。

src/
  apollo/
    cache.ts
    client.ts
    types.ts
    withApollo.ts

cache.ts: Apollo における local state のinitialStateとresolverを全画面分このファイルでまとめて、最終的に Next.js のsrc/pages/_app.tsxに渡るようにする
- component 固有の local state に関するinitialStateおよび state の updater となるresolverは component 毎のapollo.cache.tsにて、別途定義
client.ts: Apollo Client のインスタンスを生成するファイル
types.ts: Apollo 関連の型定義ファイル
withApollo.ts: Apllo Client の <ApolloProvider /> でラップして返す Higher-Order Compoents(HOC)

実装については割愛しますが、client.ts と withApollo.ts に関しては、Next.js の example（with-apollo）等を参考にしました。

画面固有の Apollo の状態管理に関わるファイルはsrc/components/**/${component 名}/配下に置いています。

こちらもコロケーションの考え方で、component に関わる状態管理は該当の component と同じ場所に置くことを意識しています。

src/
  components/
    app/
      ${component 名}/
        apollo.cache.ts
        apollo.query.graphql
        apollo.schema.graphql

apollo.cache.ts: component 固有の Apollo における local state のinitialStateおよびresolverを定義するファイル
apollo.query.graphql: クエリを定義するファイル
apollo.schema.graphql: local state の GraphQL スキーマを定義ファイル

ファイルの命名について、ディレクトリ階層をできるだけ深くしたくないので、apollo等によるディレクトリは設けていませんが、Apollo 関連のファイル群として認識できるよう、ファイル名にapollo.のプレフィックスをつけて命名しています。

Query と Mutation の実行について

GraphQL Code Generator のプラグイン TypeScript React Apollo をインストールして、hooks を生成する設定にした上で、component 毎にそれぞれ GraphQL のスキーマとクエリが記述された.graphqlファイルをもとに、GraphQL Code Generator が生成するカスタム hooks を利用します。

こちらのカスタム hooks を React Component で利用することで、Apollo Client 経由で GraphQL API とローカルの Apollo cache に接続して、データのやり取りを行うことができます。

Query

Query の hooks は２種類あり、実行するタイミングによっていずれか適切な方を選んで実行しています。

API	実行タイミング
`useQuery`	Component が render されたらクエリ実行
`useLazyQuery`	任意のイベントをトリガーにしてクエリ実行

`use***Query`

通常であればuseQueryでクエリの結果を render しますが、GraphQL Code Generator を利用する場合は、それぞれのクエリをラップしたカスタム hooks が生成されるので、useQuery,useLazyQueryをそのまま使うことはありません。

query AllPosts {
  allPosts {
    id
    title
    rating
  }
}

↑ のようなクエリを用意するとsrc/__generated__/graphql.tsxに対して、次のようなカスタム hooks が型と一緒に生成される設定にしています。

// Apollo Client: 2.6.9、GraphQL Code Generator: 1.15.0 の場合の例
export function useAllPostsQuery(baseOptions?: ApolloReactHooks.QueryHookOptions&lt;AllPostsQuery, AllPostsQueryVariables>) {
  return ApolloReactHooks.useQuery&lt;AllPostsQuery, AllPostsQueryVariables>(AllPostsDocument, baseOptions);
}

export function useAllPostsLazyQuery(baseOptions?: ApolloReactHooks.LazyQueryHookOptions&lt;AllPostsQuery, AllPostsQueryVariables>) {
  return ApolloReactHooks.useLazyQuery&lt;AllPostsQuery, AllPostsQueryVariables>(AllPostsDocument, baseOptions);
}

React Component では生成されたカスタム hooks を次のように呼び出してサーバーから返ってくる結果を受け取って、データ出力、ローディング状態のチェック、エラーハンドリング等を行います。

const { data, loading, error } = useAllPostsQuery();

Mutation

データの書き込みはuseMutationで行います。

Query 同様、GraphQL Code Generatorによって生成されたカスタム hooks use***Mutation を使っています。

cache の更新

Mutation が複数エンティティの更新、エンティティの新規作成または削除の場合、Apollo Client の cache は自動更新されず、Mutation の結果が自動的に render されません。

このような場合でも、useMutation の update option を使えば、cacheオブジェクトを引数に取れる関数を設定できるので、この関数内で直接 cache を更新できます。

また、updateの代わりに refetchQueries の option を使って、任意の Query を実行して、シンプルに cache を更新することもできます。

但し、この方法だと Network 通信によるオーバーヘッドが発生します。

このオーバーヘッドを犠牲にしてでも、サーバーからデータ取得したい Query があるような場合には、このrefetchQueriesが有効です。

local state の管理

ここからは特定の component の状態管理を local state を使ってどのように管理しているかを、ご説明していきます。

@client を使った Query

Next.js のプロジェクトで、local state の管理を Apollo Client で行う場合の例としては、次の通りです。

スキーマ：

# src/components/app/Home/apollo.schema.graphql

type Home {
  currentPostId: Int!
}

extend type Query {
  home: Home
}

クエリ：

# src/components/app/Home/apollo.query.graphql

query HomeCurrentPostId {
  home @client {
    currentPostId
  }
}

キャッシュの初期値：


// src/components/app/Home/apollo.cache.ts

export const cache = {
  __typename: 'Home',
  currentPostId: 0,
  ...,
};


// src/apollo/cache.ts

const caches = {
  ...,
  home: home.cache,
};

export {
  ...,
  caches,
};


// src/pages/_app.tsx

export const cache = new InMemoryCache();

  ...

const client = new ApolloClient({
  link,
  cache: cache.restore(initialState || {}),
  resolvers,
  connectToDevTools: true,
});

cache.writeData({ data: caches });

GraphQL クエリとスキーマが定義されていれば GraphQL Code Generator がuse***Queryのコードを生成する設定にしています。

ローカルデータの場合、クエリで@clientディレクティブをつけてローカルデータであることを明示します。

@client を使った Mutation

local state の更新を GraphQL の Mutation として行う場合の例としては、次の通りです。

スキーマ：


# src/components/app/Home/apollo.schema.graphql

type UpdateCurrentPostId {
  currentPostId: Int!
}

extend type Mutation {
  updateCurrentPostId(id: Int!): UpdateCurrentPostId
}

クエリ：

# src/components/app/Home/apollo.query.graphql

mutation UpdateCurrentPostId($id: Int!) {
  updateCurrentPostId(id: $id) @client {
    currentPostId @client
  }
}

resolver：

// src/components/app/Home/apollo.cache.ts

const updateCurrentPostId: MutationResolvers["updateCurrentPostId"] = (
  _,
  args,
  { cache }
) => {
  cache.writeData({
    data: {
      home: {
        __typename: "Home",
        currentPostId: args.id,
      },
    },
  });

  return null;
};

export const Mutation = {
  updateCurrentPostId,
};

Query 同様に@clientディレクティブをつけてローカルデータであることを明示します。

実際の Mutation の処理自体はresolverの中にcache.writeData()を使って記述します。

Mutation の命名は、動詞+名詞の形式で可能な限り意味のある具体的な名前をつけることを意識しています。

Apollo を使った開発を便利にしてくれるツール

Apollo Client を使って開発する際は、ローカルの Apollo cache の状態や、クエリを試しに実行するためのツールとして、Google Chrome の拡張機能 Apollo Client Developer Tools が非常に便利です。

こちらの拡張機能を Chrome にインストールすると、Apollo Client を使って GraphQL API にアクセスするサイトに遷移した状態で Chrome Dev Tools を開くと Apollo のタブが表示されます。そこでクエリの実行や、API 仕様の確認、ローカルの Apollo cache の確認等を行うことができます。

GraphQL 関連のテストコードについて

Apollo Client を使った React Component の開発で、Query および Mutation 実行のテストを実施するには、テストフレームワークの Jest、react-testing-library とあわせて、Apollo 公式でも紹介されている MockedProvider を用いる方法が一般的かと思います。

クエリとクエリに対するレスポンスを組み合わせたモックデータを用意しておき、ApolloProvider の代わりに MockedProvider でテスト対象の component をラップすることで、API サーバーや Network 環境に依存せず、モックで指定したクエリがリクエストされると、モックでそれに対応するように用意したレスポンスデータが確実に取得できる仕組みを作れます。

その仕組みと react-testing-library を使って、component で render される UI 上の操作をトリガーにして実行される、クエリのテストを行うことができます。

Query だけではなく Mutation もモックすることができて、便利なツールではありますが、テストケース毎にモックデータは手動で作成しなければならない点が、なかなか骨が折れる作業です。

実際にアプリケーションを動かして、テスト対象の component を render し、Query に渡される variables やレスポンスの値を Console に出力し、ブラウザの Dev Tools 上で一個一個オブジェクトをコピーして、エディタに貼り付けしたりする作業が発生します。

AutoMockedProvider の作成

そこで、わざわざテスト作成やスキーマ変更の度に、手動でモックデータを用意しなくても、GraphQL スキーマで定義されている型を見て、自動でクエリに対するレスポンスをモックしてくれる AutoMockedProvider を、こちらの記事を参考にして作成しました。

MockedProvider の代わりに、AutoMockedProvider を用いてテスト対象の Component をラップすることで、MockedProvider を使ってテストしていた内容と同じテストが実施できます。

MockedProvider を使って毎回モックデータを用意し、テストを実施することに疲れている方は是非、お試しください。

（紹介先の記事では、graphql-toolsのmakeExecutableSchema()に渡すschemaSDLが json ファイルで定義されていますが、graphql-tagのライブラリを併用すれば、graphql ファイルでも同様にschemaSDLとして適用することも可能です）

リニューアルを振り返って

今回のリニューアルでは、GraphQL、TypeScript、React をセットで採用したことにより、フロント側では GraphQL Code Generator を使って、あらかじめ用意しておいた GraphQL スキーマから、TypeScript の型だけではなく、React の Hooks 関数まで生成して利用できたことが、開発効率の向上に非常に影響を与えたと思います。

GraphQL API のクライアントで、アプリケーション全体の状態管理を行う Apollo Client の cache 機構の使い方等を体得するまでに、学習コストは決してゼロではありませんでしたが、TypeScript と GraphQL の型システムの恩恵をフルに受け、Next.js のレールにのっかり、型安全な開発環境を手に入れることができました。

我々、開発者の体験だけではなく、今後のプロダクト全体への生産性にも良い影響を及ぼしてくれると確信しています。

さいごに

メドレーではエンジニア・デザイナーを積極募集しています。

「テクノロジーを活用して医療ヘルスケアの未来をつくる」というミッションに共感し、課題解決を行いたい方は是非、ご応募ください。

技術を使うための技術も大切というお話

Fri, 23 Oct 2020 09:19:24 GMT

初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません）

CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。

前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。

さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。

はじめに

「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通してお伝えできればと思います。

また、この考え方自体は「医療というテーマ」や「事業の背景（ベンチャー・ SIer）」を問わず必要とされる場面があるかもしれません。（自身も前職では様々な場面でお世話になりました…）

即効性のあるものではありませんが、じわじわ効いてくる内容ではないかと思います。よろしければお付き合いください。

本題

「技術を使うための技術」

みなさんはこの言葉から、何を思い浮かべるでしょうか。筆者が試しに Google で検索した際上位にヒットしたのは

AI エンジニア IoT

といった結果でした。なるほど。少し雑に解釈すると「技術（アルゴリズム等）を使うための技術（機械学習、家電等）」といった感じなのでしょうか。（この結果を拾ってきたというのも、いい意味で Google すごいなって感じました）

筆者が今回のテーマとして指しているのは、下記となります。

ロジカルシンキング推論

これらの 思考を整理する「手段」 とエンジニアの武器である 技術という「手段」 をかけ合わせることで、大きなテーマである「医療」に向き合っています。

手段を目的にしてはならない

先に挙げたとおり「思考の整理」も「技術」も 「手段」 に過ぎません。これらを用いて、適切な一手を指していく為には「目的」に対する解像度を高く描く必要があります。

筆者の発表から抜粋した「技術を使うための技術」の要素をイメージした図

整理力

目的を達成する為に必要な「情報」を取捨選択するための要素。

SaaS ✖️ toB の世界においては「プロダクトが解決すべき課題か否かを業務の本質を踏まえて取捨選択する」と言い換えられるかもしれません。

業務知識

目的の「解像度」を高めるための要素。

CLINICS においては、医療情報を扱う上での規制（3 省 2 ガイドライン）や、医療機関（医師・医事・診療科の特性）の業務、診療報酬についての知識、法改正、レセコン（ORCA）… と様々あります。

技術知識

目的を達成する為に必要な「指し手」を選択するための要素。

（エンジニアにとっては説明するまでもない内容であると思いますが）ここが欠けてしまうと絵に描いた餅で終わってしまいます。メドレーのエンジニアにおいても日々研鑽し、プロダクトに対してコミットを続けています。

行動力

目的を達成するための「推進力」を高めるための要素。

各種知識と整理した情報を推進力に変えていく為には、その時の状況に応じた動きをする必要があります。ステークホルダーとの調整は当然ですが、組織内連携といった「横の動き」も必要です。

想像力

これまで挙げたそれぞれの手段を適切に利用していくための要素としての土台が「想像力」であると考えています。

課題（Issue）への取り組み例

番号	概要
①	Issue に取り組む際に「本当に解決すべきこと」についての想像を働かせます。Issue に記載されていることが本当にプロダクトとして解決すべきことなのかを含めて考えます。これまでの運用が必ずしも正しいわけではない。という点がポイントです。
②	① について「想像のまま」で終わらせてはいけないので、業務知識と照らし合わせて確度を高めていきます。常勤医師やカスタマーサポートにヒアリングしながら、医療業務としてのあるべき形の解像度を上げていくプロセスです。
③	① 及び ② で高めた解像度は言葉の延長線上なので、関係者間の認識のギャップが発生しやすいです。プロトタイプを作成して、視覚・触感レベルでギャップを埋めていくことで、あるべき形に向けて洗練させていきます。
④	① 〜 ③ のタイミングを問わず、必要に応じて関係者と相談しながら進めていきます。エンジニアが立てた仮説をデザイナーの目線で評価・ UI/UX 最適化をして頂いたり、大きめの機能については、医療機関にパイロット運用のご協力を仰いだりすることもあります。

① 及び ② の項に作業のウェイトが偏っているように見えるかと思います。実際、課題を解決する為の半分以上をここに割いています。

理由は「１度作って公開した機能」は、その後１人歩きをして作成者の意図しない方向で利用をされることがあるからです。

そして、利用者がその運用を定着させてしまうと 誤った機能においても「削ぎ落とすことが困難」 です。これは「使われていない機能」よりも直接的な負債といった形でボディブローのように効いてきます。

「どのような使われ方をするか」について想像すること
その使われ方が、プロダクトの目指す世界と合っていること

エンジニアは技術を形にする上で、常に想像力を働かせて取り組む必要がある。 というのが筆者の持論です。

さいごに

執筆の締めにあたって CTO ブログを見返してみると、大事なことはここに詰まっていました。筆者は前職の SIer 時代に読んだのですが、この記事にすごく共感したのを覚えています。

toppa.medley.jp

メドレーでは医療ヘルスケアの未来を作るという大きな目標、そしてその未来を作る為に解決すべき課題に向かって、今回ご紹介したプロセスや考え方も含め試行錯誤しながら、事業部一丸でプロダクト開発を推進しています。

エンジニアの総合力を発揮して医療ヘルスケアの未来を一緒に作り上げていきたい！という方にお会い出来ることを楽しみにしております。

フロントエンド開発環境の継続的なリファクタリング

Tue, 20 Oct 2020 08:04:26 GMT

こんにちは、第二開発グループエンジニアの西村です。主にCLINICSの開発を担当しています。

はじめに

CLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。

モチベーション

プロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。

しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラリが出てしまいます。

CLINICS ローンチ当初はオンライン診療のみを提供していました。SPA で構成されていましたが、１つの package.json で効率的に開発できていました。他に、現在ほど TypeScript が主流ではなかったので JavaScript のコードがメインで実装されてました。

新たなアプリケーション（電子カルテや予約システムなど）を導入するタイミング、すなわちプロダクトが小規模から中規模に変遷するタイミングや、フロントエンドの時流によって、開発環境を改善できた部分もありますが、しきれていない部分も出てきました。

その改善しきれていない部分を残す状態が続くと Developer Experience(DX)の低下に繋がってしまいます。ですので、私たちは改善しきれていない部分を取り除いていき、よりモダンとされる開発環境へリファクタリングをしていこうと考えました。

DX を向上していくことで技術的なノイズに時間を取られないようになります。そして提供する機能そのものについて考える時間が増え、結果的に CLINICS をより良いプロダクトへ進化させていくのが当リファクタリングの目的です。

課題整理

改善していくためには、現状整理、課題整理を行わないことには何も始まりません。フロントエンド開発環境をメンテナンスするタスクは、プロダクトの機能（ユーザに提供される機能）に直接プラスの影響があるわけではありません。自ずと通常の機能開発や定常改善に比べ優先度は落ちるため、スキマ時間で改善をしていくことになります。こうしたスキマ時間を有効活用するためには、タスクの難易度の理解、タスクを適当に分割、フェージングの計画を行うことが極めて大事です。

そのように考慮した課題の中で、本記事で記載するのは以下の２つです。

ライブラリを定期的にアップデートする運用が固まってない

運用方式が固まっていないことで、放置されてしまいがちです。率先してアップデートするメンバーがいたとしても、属人化の課題が残ってしまいます
放置されてしまったことにより、最新版との差分が大きくなりアップデートするコストも大きくなってしまいます
結果的に、ライブラリのセキュリティフィックス対応や新しく提供された機能をすぐに適応できない環境になってしまいます

複数の SPA の依存を１つの package.json で管理している

電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られています
それらを１つの package.json で管理しているためそれぞれの SPA が同じ依存パッケージを使わなくてはなりません。小規模のときはこのような構成で十分でしたが、規模が大きくなるにつれて柔軟性が失われると共に、ライブラリのアップデートがもたらす影響範囲が広がってしまうため、容易にアップデートできなくなってしまいます

本記事では記載しませんが「Redux の書き方が混在している」「フロントエンドのテストが少ない」「網羅的に TypeScript 化できていなく JavaScript がまだ残っている」などの課題も挙げられました。

こういう課題は、どのプロダクトにも存在すると思います。それはローンチ当時の技術流行であったり、プロダクトの期待規模、少数メンバに適した設計など要因は様々あり、プログラムのリファクタリングと同様にプロダクトの成長に伴ってリファクタリングしていくことが正だと信じています。

モチベーションにて記載した通り、これら複数の課題は開発環境のノイズであり、除去することによって、より良い DX が得られると考えています。他にこのようなリファクタリングを行うことによって、プロダクトをより堅牢にできるという側面もあります。

上記の２つの課題に対してそれぞれ「ライブラリを定期的にアップデートする運用手段を設けた」「package.json を SPA 単位に分割した」話をこれからしていきます。

フロントエンド開発環境のリファクタリング

ライブラリの定期的なアップデートをする運用手順を設けた

手動アップデート

ライブラリをアップデートするにはコマンドを叩くだけだと考えていましたが、依存している別のライブラリに影響が本当にないかなど調査する必要があると知り、ライブラリのアップデート方法を模索するところから開始しました。

ライブラリではないですが、Node.js のアップデートをしようとすると、node-sass や Firebase が影響していたりして、芋づる式で根っこにあるライブラリのアップデートをする必要が出てきたりするので、一つ一つ問題がないか調査するのが大変でした。

何より、アップデート対象ライブラリのリリースノートに Breaking Changes が書かれていなかったり、semver が守られているかわからなかったりと、プロダクトに影響がないか調べる必要があり、問題の切り分け方が難しかったのです。

ここで得られたライブラリアップデートの安全性担保のプラクティスとして webpack によるビルド結果が変わらないケースと、QA テストによって担保するケースがあることがわかりました。前者は webpack による成果物が変わらないのであれば今回のアップデートが安全であるといえ、後者はエンジニアと QA エンジニアによってライブラリの影響範囲にハレーションがないことを確かめて安全であるといえるというものです。

renovate の運用開始

数カ月間は上記のようにライブラリのアップデートを手動で行っていましたが、確認工数が増えてしまい、他のタスクの時間を圧迫してしまうほどでした。

そこで、アップデートを自動化する renovate とdependabot を視野に入れました。renovate は、dependabot に比べて高機能でかつ、無料であるという理由で選定しました。

運用当初、renovate が Pull Request を作成してくれたり、diff によりライブラリの変更点が見やすかったりと、恩恵を感じていました。しかし、徐々に「アップデート対象が多く、それぞれがどういうライブラリで、影響範囲がどこなのか」ということの調査に時間が取られるようになってしまいました。

ここで得られた調査時間を短縮するプラクティスとして**「本番影響のあるもの」「開発向け」「ビルド周り」と renovate から来る Pull Request を整理する**ことです。このような整理を行うことで、本番影響のあるものに注力してレビューできるようになり、苦にならずにアップデートをできるようになりました。

結果

ライブラリアップデートの運用手順を設けることによって、今まで以上に堅牢な環境になりました。それから、renovate によって自動的に重要な（本番影響のある）ライブラリのみに集中してレビューを行うことによって、少ない工数でアップデートしていけるようになりました。

package.json を SPA 単位に分割

課題整理で記載した通り、電子カルテ・オンライン診療、社内管理 Web アプリ、患者 Web アプリはそれぞれ別の SPA として作られていますが、１つの package.json で管理しています。ですのでそれぞれの SPA が同じ依存パッケージを使わなければなりません。

弊害として package.json に対して１つの変更があったときにすべての SPA に影響が出てしまいます。ですので、この肥大化した package.json をそれぞれの SPA に分割しようとしました。

package.json を SPA 単位に分割することは責務分離という側面もあり、ライブラリだけでなく、共通していた定数、ロジック、コンポーネント、webpack.config.js、babel.config.js と tsconfig.json などすべてをそれぞれの SPA に依存のない形に閉じるようにしました。これらの分割する作業は非常に泥臭いもので、本記事に記載するほどのものではありませんが、得られた結果について記載していこうと思います。

結果

まず、責務分離ができたので、１つの SPA に対する変更があったときに、他の全ての SPA に対する影響が出なくなりました。よって、１つの SPA に対して新たな Web フレームワークやライブラリを試すことが容易になりました。他にも、１つの webpack ですべての SPA をシーケンシャルにビルドしていたのに対して、現在はパラレルでビルドできるようになりビルド時間が短縮されたため、今まで以上にコミットからデプロイまでのイテレーションが小さくなりました。

これらの結果からフロント開発環境の改善および DX 向上が果されました。

今後の課題

持続的なリファクタリングをする仕組み作り

「ライブラリの定期的なアップデートをする運用手順を設けた」はまさに持続的にライブラリをアップデートするための手段です。「package.json を SPA 単位に分割する」もそれぞれの SPA をメンテナンスしやすい環境作りとしては欠かせない作業でした。

しかし、このままリファクタリングを中断すれば、プロダクトの規模が大きくなるときやフロントエンドの時流によって再びメンテナンスしづらい環境になってしまいます。

なので、持続的なリファクタリングをするためには仕組み作りが欠かせないと考えています。そのためには、属人化によらない仕組みづくり、メンテナンスしやすい環境改善、エンジニアそれぞれのフロントエンド開発環境に対するリテラシを高める取り組みを行っていく必要があります。そのため、現在横軸勉強会などで CLINICS フロントエンドの実装背景や、リファクタリングしやすい書き方などのナレッジを共有しています。

まとめ

フロントエンド開発環境のメンテナンス・リファクタリング自体はあくまでもユーザに新しい機能を提供しているわけではなく、粛々と行っていくものです。しかし、課題を洗い出し、向き合って、解決していったことによって得られたプラクティスは多くあり、フロントエンドのエコシステムに対する理解も多く得られました。

これらのリファクタリングを行うことによって DX が向上していき、技術的なノイズに悩む時間が減り、エンジニアはよりプロダクトの機能開発に専念できるようになっていると信じています。

今回私たちが課題を解決したことによって、持続的にリファクタリングをしやすい土台作りをしたという側面もあると思います。今後の課題として、この土台を基にそれぞれのエンジニアが意識を持ってメンテナンスできるような仕組みづくりも行っていきたいと思います。

最後まで読んでいただきありがとうございました。

CLINICS(クリニクス)　オンライン診療・服薬指導アプリ

iOSDC Japan 2020 にメドレーが協賛しました

Fri, 02 Oct 2020 09:14:43 GMT

皆様こんにちは。インキュベーション本部エンジニアの濱中です。 9/19〜21 にiOSDC Japan 2020（以下 iOSDC）が開催されました。先日の記事の通り、メドレーは 2017 年より iOSDC に協賛しております。メドレーでは、Swift を利用してオンライン診療／服薬指導アプリ「CLINICS」iOS 版の開発をしています。

5 回目となる今回は、初のオンライン開催となり、主にニコニコ生放送、Discord 上で発表・コミュニケーションが行われました。私が iOS 版 CLINICS の開発に携わっている縁で、今回スポンサー枠として iOSDC に参加させていただきましたので紹介させていただきます。

イベント全体について

オンライン開催となったため、会場の様子や企業ブースなど、雰囲気の伝わる写真をお届けできないのが残念ですが、発表の主会場となったニコニコ生放送では、終始穏やかな雰囲気でありつつも活発にコメントがなされ、大いに盛り上がっていました。

前回同様、初日は day 0 として夕方から、2 日目以降は朝〜夕方まで、最大 5 つのチャンネルで並行して発表が行われました。セッションについては事前に録画したものを放送し、LT のみリモートにてリアルタイム発表という形式となっていました。

質疑応答については、各発表の終了直後に Discord チャンネルに発表者が待機して対応していました。初のオンライン開催ということで、イントロダクション動画をはじめとし、各所で積極的なフィードバック・コミュニケーションが奨励されていたように思います（なお、イントロダクション・スポンサー紹介の各動画はナレーションが声優の緒方恵美さん・三石琴乃さんと、とても豪華でした。生放送中のコメントや、18 年の弊社ブログを見る限りは毎年恒例のようですね。すごいです！）。

セッションについて

昨年 iOS13 とともに発表された SwiftUI への移行や、コード移行・モジュール分割等、プロジェクトの最適化についてのトピックが多かったように思います。

SwiftUI は、従来 Storyboard で設計していた UI をコードベースで記述できる画期的なフレームワークですが、SwiftUI を使ったアプリは iOS13 未満の端末では利用できなくなってしまうこともあり、アプリの公開対象を広めにもっておきたい場合はなかなか乗り換えづらい印象でした。2020 年 6 月現在で iOS13 のシェアが 9 割以上となったことで、ちょうど iOSDC での発表トピックを決めるころに導入作業を行った（かつ苦労した）というケースが多かったのかな、と思います。

以下、視聴したセッションのうち気になったものをいくつかご紹介いたします。

オープンソースの AltSwiftUI の発表

fortee.jp

楽天のエンジニアの方による、SwiftUI の提供するネイティブコンポーネントに対応しつつ、iOS11 以上で利用可能なオープンソースのフレームワークAltSwiftUI（公式 Doc）の開発についてのセッションでした。

iOS12 以下の対応を切らずに SwiftUI への乗り換えを進められる（かつ本家と違ってオープンソースである）便利さもそうですが、別途フレームワークが出来上がってしまうあたりに、SwiftUI への移行対応への苦労がしのばれる内容でもありました（ストアにある楽天提供の iOS アプリの数を考えると乗り換えコストが大変そう…）。

「それ、自動化できますよ」: note を支えるワークフロー大全

改修要望が上がってから、実際に改修を行ってアプリをリリースするまでの作業をできる限り自動化した、というセッションです。CLINICS でも、「証明書の有効期限確認、プッシュからのテスト、マージからのリリース準備」は Bitrise のトリガを利用して自動化しています。

上記のような、GitHub 上でのアクション（プッシュ、マージなど）をトリガとする自動化はよく聞く話ではあるのですが、Slack のポストに特定のスタンプつけると Issue 化、はちょっと目新しくて面白いなと思いました（気をつけないと表記揺れで同じような Issue が乱立しそうですが）。

Issue もきちんと管理しておかないとトラブルの起きやすい部分ですよね。起票者と実装者の間でボールが浮いてしまったり、プロジェクトに紐づいていなかったために対応から洩れてしまったり…。

また、このスライドですが終始手書きの挿絵がかわいくて、そういった意味でもコメント欄が盛り上がっていたのが印象的でした。

100 人でアプリをリファクタリングして見えてきた、最強の iOS アプリ設計に求められること

fortee.jp

アプリを長期に運用していくとほぼ必須となる課題でありながら、人ごとに基準が曖昧だったり、機能開発におされて対応が後手後手になったり…と、何かとつらい話をよく聞くソースコードのリファクタリングに関するセッションでした。

同じ状態のソースコードを多数のエンジニアがリファクタした結果を比較することで、「良いリファクタリングのための考え方」とは何か？を模索した内容です。

ビューとロジックの分割をしっかり行う、というのは PR レビューでエンジニアが口を酸っぱくしてよく言われることではありますが、「ロジックの中でも、アプリの仕様に依存するものとそうでない普遍的なものは分離すべき」というアイデアは個人的には眼から鱗が落ちるものでした。

また、これを説明するリバーシの具体例（「対戦相手が人間か AI か」はアプリ仕様に依存するロジック、「そこに石を置けるか」は普遍的なロジック＝リバーシのルールそのもの）も非常にわかりやすかったです。

そのほか、React / Redux でフロントエンド開発を行っている人にはお馴染みの Action / Reducer を使った単一方向のデータフローの導入なども紹介されています。

新規機能開発からモジュール分割を始めてみる

一つのアプリが長期間運用されていくなかで、複数の機能が統合されたスーパーアプリになることがあります。そうなった場合、ソースコードが肥大化 → ビルド・テストも長大化、となってメンテナンス性が低下するため、対策としてコードを分割してテストやビルドの単位を小さくする必要があります。

いきなりアプリ全体をモジュールに分割するのは時間がかかるため、本セッションではまず第一段階として新規に開発する機能を別モジュールとして実装し、その時得た知見について触れられていました。

「分割したモジュール側でのサードパーティ製フレームワークのリンク方法（※リンクを正しく行わないと、ビルドして動作はするのにアーカイブに失敗してリリースできなくなる）」などは、今後の開発にモジュール分割を取り入れていく際に参考になりそうです。

Swift で始める静的解析

Swift ソースコードからの構文木の生成、解析を行うライブラリ SwiftSyntax の紹介と、それを用いたソースコード重複検出機能の実装についてのセッションでした。

普段 Xcode を始めとした IDE で開発していると、コード重複、不要なローカル変数、型や Nullable の不一致に変数リファクタリング…等々の便利な機能を気軽に使えてしまいますが、その裏の動作を改めて一つずつ具体的に追っていくと、そのありがたみが身に染みます…。

静的解析そのものは Swift に限らず様々な言語のソースコードに対して適用できるトピックではあるのですが、普段何気なく使ってしまう IDE の機能について考えるよい機会になったため、紹介させていただきました。

まとめ

ちょうど業務でも iOS アプリ開発を担当していることもあり、興味深い知見が得られ、よい経験となりました。また、事前録画形式になったことで発表の構成がよく練られ、結果として聞きやすく（皆様かなり気をつけてゆっくり発声されていました）、個性のある発表が多かったように思います。

今回、初のオンラインでの開催ということで、運営委員会の皆様もいろいろと苦労されていらっしゃるようでした。ただ、その甲斐あってか当日の進行はスムーズで、会場はとても盛り上がっていました。関係者の皆様、本当にお疲れ様でした。

情勢を踏まえ、来年度の開催可否・形式は未定とのことでしたが、オンライン・対面のそれぞれの良さを取り入れつつ、より多くの人が参加できる形態になっているとよいなと思います。

公式 YouTube チャンネルで過去の発表を視聴できますので、ご興味のある方はぜひどうぞ（今年の発表分も一ヶ月ほどしたら公開されるとのことでした）。

またメドレーでは iOS / Android ネイティブアプリ開発エンジニアを募集しています。興味がある方、ぜひお気軽にお話しましょう!

2019 年度エンジニア新卒の研修について - Medley Developer Blog

2020 年度新卒エンジニア研修について

Fri, 25 Sep 2020 08:45:27 GMT

こんにちは。ジョブメドレーの開発チームでエンジニアをしている新居です。

はじめに

2020 年 4 月に、新卒エンジニア 3 名が入社しました。入社後は新卒エンジニア研修を実施し、先日 8 月 25 日の最終報告会をもって終了しました。

コロナウイルスの影響で入社間もなくフルリモート勤務となり、不慣れなところもありましたが、本年度の研修の取り組みを紹介します。

2020 年度新卒エンジニア

研修の概要

メドレーでは昨年度から新卒エンジニアを迎えており、合わせて研修も開始しました。

初めての研修をどのような視点で計画・実施したかについては、昨年平木がこちらにまとめています。

今年は人事部のご協力もいただきながら、昨年の内容を少しアップデートして行いました。

研修の目的は、新卒メンバーが同じ空間で互いに刺激し合いながら、社会人への思考転換をはかり、業務遂行に必要となる基礎知識とスキルを習得することです。

研修は以下の 4 つのフェーズに区切って行いました。

研修のフェーズ

研修の内容

ここから 4 つのフェーズ毎に内容を紹介します。

フェーズ 1：社会人&メドレー基礎研修

1. オリエンテーション

メドレーの事業や組織、大切にしている行動規範などの概要説明
セキュリティ研修とコンプライアンス研修

2. ビジネス研修

ビジネスマナー研修
ビジネススキル研修
ビジネススタンス研修（外部研修）

フェーズ 1 では「医療ヘルスケアの未来をつくる」メンバーの一員として大切にして欲しいことを学ぶフェーズでした。

社会人としての最低限のマナーやスタンスは勿論ですが、メドレーで働く上で土台となるマインドをここで学び、医療ヘルスケア分野の課題を解決する一員として共にプロダクトを作るためのベースを築けたと思います。

フェーズ 2：エンジニア基礎研修

1. 開発基礎 1

講義「メドレーが求めるエンジニアとは」
ジョブメドレーとCLINICSの事業・プロダクトについての概要説明
Ruby on Rails（以下 Rails）の基礎トレーニング

2. 開発実践

チーム開発体験

3. 開発基礎 2

書籍『Web を支える技術 -HTTP、URI、HTML、そして REST』の輪読会
ドキュメンテーション研修とプレゼンテーション研修
中間報告会の準備と実施

フェーズ 2 から開発の研修がスタートしました。

開発基礎 1

開発の研修に入る前に、エンジニアの執行役員田中から「メドレーが求めるエンジニアとは」というテーマで講義を行いました。メドレーがどういうエンジニアを求めているのか、目指すところの視点合わせを行い、これから行う研修に対する意識や取り組みの質を上げることを目指しました。

メドレーが求めるエンジニア像については CTO 平山の記事にも詳しく書いています。

メドレー平山の中央突破: THE エンジニア

その後ジョブメドレーと CLINICS の事業・プロダクトについての概要説明、Rails の基礎トレーニングを行いました。メドレーのプロダクトは Rails 製です。Rails やウェブアプリケーション開発に慣れていない新卒メンバーは、Rails の基礎トレーニングでRuby on Rails チュートリアルを使って基礎からみっちり学びます。

Ruby on Rails チュートリアルの進め方

ここで大切なことは、漠然とひたすら写経してチュートリアルを進めるのではなく、毎日のフィードバック会でしっかりその日の進捗や学びを共有し、不明点はメンターに質問してもらうようにすることです。

メンターは、新卒メンバーが理解が浅いまま進めてたり、理解していて欲しいところがいい加減になってたり、進め方や学びの方向性がズレてる場合などはアドバイスを入れて軌道修正することを心掛けました。

また「実際の開発ではこうだよ」といった実務を踏まえたアドバイスや、意識していることも伝えていきました。

20 新卒 S さんの感想

「毎日のフィードバック会の中で、その日学んだ技術がジョブメドレーではどのように利用されているのか、どういったことに留意して利用しているのかなどを確認できたので、現場の人の感覚を少しずつ知ることができた。」

新卒メンバーは毎日リズム良く進捗を出し、メンターは新卒メンバーのフォローと引き上げを意識し、成果を最大化できるよう努めました。

開発実践

続いて開発実践ではチーム開発を行いました。前回までは各自個別に進めていましたが、ここではジョブメドレーに関する課題解決を目的としたプロジェクトに対して、チームで向き合う研修でした。

開発実践の目的と達成すべきこと

実務ではチーム開発が基本となり、チームメンバーとの協働は必須です。学生時代に業務レベルのチーム開発を経験しているのは稀ですし、実務に入る前にチームでプロジェクト推進するとはどういうことかを知るのは、とても価値があると思います。

加えて、チームで課題をどう解決していくのかも、新卒メンバー同士で話し合って決める必要があるので、課題解決力も養われたと思います。

今回はプロトタイプを作って成果発表するところまででしたが、プロジェクト推進においてはスケジューリング、要件定義、各種設計、開発フローやコミュニケーションフローの整備、実装、テスト、などなど、やることは尽きません。

また、このプロセスの中で密なコミュニケーションが必要不可欠となるので、新卒メンバー間のチームワークも向上し、お互いのことを更に知ることができたと思います。

この段階で、チームでプロジェクトを推進することの全体感を知り、プロジェクト推進の苦悩苦闘を実体験できたのは大きな経験値になったと思います。

20 新卒 O さんの感想

「各機能の影響を互いに受けないためにブランチを細分化するブランチ戦略や GitHub を用いたコード管理について理解できた。一方で、UI を考える際にチームの各メンバーの認識のズレが生じたことや、序盤は各メンバーの進捗の詳細を把握できていなかったことから報・連・相の重要性を再認識した。」

20 新卒 T さんの感想

「初めてのチーム開発であったことから、実装の序盤は、どのファイルなら編集しても他のメンバーの作業に影響がないのか、動作確認のための画面を作るファイルは自由に作成して良いのか、どのテーブルから関係する他のテーブルの情報を含めた情報を取得をするかなどに悩んでいた。今になって振り返るとチーム内で話せば解決することに対して、技術的にも心理的にも難しさを感じた。」

###開発基礎 2

フェーズ 2 最後の開発基礎 2 では、書籍『Web を支える技術 -HTTP、URI、HTML、そして REST』の輪読会を行いました。もっと前のフェーズでの実施も検討しましたが、開発基礎 1 と開発実践を経た後の方が書籍の内容の納得感が高くなるだろうという判断で、この段階での実施となりました。

その後、中間報告会に向けたドキュメンテーション研修とプレゼンテーション研修を行いました。仕事を進めていく上では、背景や目的を正しくステークホルダーへ共有しながら進めていくことが必要で、伝えたいことを適切に文章として整理し、他者へ分かりやすく伝えていくことが求められます。中間報告会では、そういったことを意識しながらこれまでの研修でやってきたことや成果、学びをレポートにまとめ、プロダクト開発室の室長と副室長、メンター陣の前でプレゼンテーションして報告しました。

フェーズ 3：事業部 OJT

1.代表取締役医師豊田の講義

日本における医療制度の課題とそれに対するメドレーの位置付けについての講義

2.ジョブメドレー開発 OJT

ジョブメドレーの実際の開発 Issue に対応し、ジョブメドレーの開発プロセスを体験

フェーズ 3 の最初は豊田代表の講義を受けました。基礎的な研修を終え、ジョブメドレー開発 OJT に入る前にメドレー社の社会的意義などを改めて代表から伝えていただきました。

続いて、ジョブメドレー開発 OJT は以下の狙いを持って進めました。

ジョブメドレー開発 OJT の狙い

実際に行ったことは、手始めに小さい不具合系 Issue の対応に取り組んだ後、サーバーレスポンス改善の Issue に取り組むというものでした。

サーバーレスポンスの改善は、1 人 1 画面を担当し、「プロファイルツールで分析 → 改善できそうな箇所を調査 → 改善方針の検討 → 提案 → 実装 → レビュー → リリース」というサイクルを回しました。

1 つ目の Issue 対応でも心掛けたことですが、言われたものを実装するのではなく、ある課題を解決するためにどうしたら良いかを自分で主体的に考えることを重視しました。実装力と同じくらい課題解決力も大切にしているためです。

とはいえ成果が何も出せないというのは、精神衛生上良くないので、日々の朝会と夕会にて進捗や状況をしっかり確認しながら適宜フォローやインプットを行い、ヒントになりそうな過去 Issue のリンクを渡して参考にしてもらったり、メンターの適切なバックアップも必要です。

今回の OJT を通じて実務を知ることで、実際にエンジニアとして仕事をするイメージが沸き、同時に仕事をする上で足りないことも明確になります。自分の課題と向き合うことで、直近の自身の学習プランの軌道修正もできます。

課題は簡単なものではありませんでしたが、最終的に 1 人 1 つ以上のサーバーレスポンス改善 PR をリリースすることができました。

S さんの感想

「速度パフォーマンスの悪いコードに対する嗅覚、オブジェクトを生成しすぎていないか、無駄に通信を走らせていないかなどを学べた。」

O さんの感想

「Issue を本質的に解決するメドレーの開発姿勢について学んだ。Issue を表面的に解決するのではなく、背景や目的、関連するコードなどの不明点を調査し、十分に理解・納得した上で修正することの意識付けができた。また、Issue に関連する一部分のコードを修正すれば良いという狭い視野を持たず、修正による影響範囲を考慮した上で全体の最適化を考えることが重要であると学んだ。」

フェーズ 4：最終報告

1. 最終報告会

最終報告会の準備と実施

最後のフェーズ 4 では、これまでの研修でやってきたことや成果、学びをレポートにまとめ、役員陣の前でプレゼンテーションして報告しました。

役員陣の前なので緊張は最高潮になりますが、自分達が研修を通じて何を得てどう成長したか、今後どういうエンジニアを目指していくのか、などを役員陣の前でアピールする貴重な機会となりました。

1 人 10 分の枠内で役員陣にどういう情報をどういう表現でプレゼンテーションするかを考える機会にもなったので、情報整理力や表現力が培われる場にもなりました。

さいごに

2020 年度の新卒エンジニア研修も無事終了することができました。改めて、新卒メンバーのみなさん、関係者のみなさん本当にお疲れ様でした。

振り返ると、メドレー社員としてのマインドや開発の基本的なことをしっかりインプットしつつ、新卒メンバーが主体的に課題解決に取り組む研修ができたように思います。

必要な技術スタックを 1 から 10 まで懇切丁寧に資料に落とし込み、講義形式で行う研修も身になることは多いですが、メドレーの研修のような課題解決を実体験する研修はより実務に繋がる実践的な研修だと思います。

少しハードな面もあるかもしれませんが、このような研修を乗り越え、医療ヘルスケア分野の課題解決に取り組みたい学生エンジニアのみなさん、少しでも興味を持っていただけると幸いです。

もちろん中途エンジニアの方もぜひお気軽にお話をしましょう。

Fargate 上で動くコンテナアプリケーションに SessionManager で接続する

Fri, 18 Sep 2020 09:04:04 GMT

自己紹介

株式会社メドレーのエンジニア阪本です。

9 月に入っても暑い日が続く中、皆さんはいかがお過ごしでしょうか。

前回のブログでも書きましたが私は野球観戦（虎党）が趣味で、毎日の試合結果に一喜一憂しています。このブログの執筆時点ではセ・リーグは首位巨人にマジックが点灯し、残試合 50 を切った状況でのゲーム差 10。優勝を目指す阪神にとっては厳しい状況となりましたが、残り直接対決をすべて勝てば可能性は見えてくるはず。ここは諦めずに応援しようと思います。

次の記事を書く頃には何らかの決着が着いていると思いますので、その時には喜びのメッセージが書ける事を願っています。

はじめに

突然ですが、皆さんはFargateを使いこなしていますか？今まで ECS(EC2)での運用がメインでしたが、ジョブメドレーのシステムでも Fargate に触れる機会が増えてきました。筆者自身は初めての Fargate でしたが、EC2 の存在が無くなることに不思議な感覚を覚えつつも、管理するものが減って運用が楽になったと実感しています。

しかし、EC2 が無くなった事によりサーバ内にターミナルで入る手段を失いました。公式のガイドでは

質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？

こちら現状サポートしておりませんが、コンテナワークロードでは「同一の環境でしっかりテストを行う」ことや「ログを外部に全て出す」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。

と「事前にテストを十分に実施する」「ログは(S3 や CloudWatchLogs など)外部に出力する」さえ出来ていれば入る必要が無いはずと記載されているものの・・・心配性な自分は不測の事態が発生した時の事を考えてサーバに入る手段を求めてしまいます。

そこで代替手段を模索していた所、SessionManagerを使えば可能との文献を見つけました。すでに SessionManager 自体は EC2 に対して運用を行っていたため導入の敷居は低いと考え、この手段を採用することにしました。

Session Manager とは？

Session Manager とは AWS の Systems Manager サービスの 1 機能で、AWS 上で管理しているサーバ（マネージドインスタンス）に対してターミナルのアクセスを可能にするものです。

ターミナルへのアクセス手段は、よくある手段だと SSH がありますがこの方法は SSH ポートを外部に開放する必要があるため攻撃の対象になりやすく、あまり好ましくありません。

それに比べて Session Manager は SSH ポートの開放は不要でサーバから見てアウトバウンド方向の HTTPS 通信の確保で済む為、外部からの攻撃も受けず安全にアクセス経路の確保が実現できます。 ※通信経路の確保以外にも IAM ロールの設定などが必要となります。詳しくはこちらを参考

「AWS 上で管理しているサーバ」と先に記載しましたが、このサーバは EC2 インスタンスに限らないのが本記事の重要なポイントになります。オンプレミスなサーバも AWS 上で管理されているのであれば、SessionManager エージェントをインストールする事により管理対象に含めることが可能になるのです。

今回は EC2 で動いていた SessionManager エージェントを Fargate で動くコンテナにインストールする事によりコンテナ自体をサーバと見立ててマネージドインスタンスとし、SessionManager でアクセスする事を目指します。

対応

Systems Manager インスタンス枠をスタンダードからアドバンスドに変更する／ AWS コンソールでの設定

オンプレミスなサーバに SessionManager にてアクセスする場合、Systems Manager のオンプレミスインスタンスティアをスタンダードからアドバンスドへと変更する必要があります。

この変更作業は AWS コンソールから行う事になりますが、アドバンスドへの変更に当たって既存のマネージドインスタンスに影響することはありません。ただし、この逆の場合、スタンダードに戻す際には考慮が必要となるのでこちらを参照ください。

SSM Agent のインストール／コンテナに対する設定

ここからは実際に動くコンテナに対する設定になります。 AWS のドキュメント手動でインストール SSM エージェント EC2 で Linux のインスタンスを参考に、OS に合った方法で SessionManager エージェントのインストールを行います。

インストール作業には通信などの時間が必要となるので、事前にコンテナイメージにインストールする形としました。

コンテナをマネージドインスタンスとして登録する／コンテナに対する設定

コンテナをマネージドインスタンスとして登録するため、コンテナのスタートアップ(Entrypoint)にて下記スクリプトを実行します。

# 1. ハイブリッドアクティベーションの作成
SSM_ACTIVATE_INFO=`aws ssm create-activation --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances --registration-limit 1 --region ap-northeast-1 --default-instance-name medley-blog-fargate-container`

# 2. アウトプットからアクティベーションコード/ID の抽出
SSM_ACTIVATE_CODE=`echo $SSM_ACTIVATE_INFO | jq -r '.ActivationCode'`
SSM_ACTIVATE_ID=`echo $SSM_ACTIVATE_INFO | jq -r '.ActivationId'`

# 3. コンテナ自身をマネージドインスタンスへの登録
amazon-ssm-agent -register -code $SSM_ACTIVATE_CODE -id $SSM_ACTIVATE_ID -region "ap-northeast-1"

# 4. SessionManager エージェントの起動
amazon-ssm-agent &

これらのコマンドについては各行ごとに説明します

1.ハイブリッドアクティベーションの作成

マネージドインスタンス登録に必要なアクティベーションコード/ID 取得のため、ハイブリッドアクティベーションの登録を行います。後々 AWS コンソールにてインスタンスの識別ができるように、--default-instance-nameオプションにてmedley-blog-fargate-containerという名前を付与しています。

このコマンドのアウトプットにて下記のような JSON が返される為、一旦変数に格納しています。

{ "ActivationId": "<<アクティベーション ID>>", "ActivationCode": "<<アクティベーションコード>>" }

また--iam-roleオプションでサービスロール AmazonEC2RunCommandRoleForManagedInstances を使っています。このロールがまだ存在しない場合、AWS コンソールからハイブリッドアクティベーションから IAM ロール →「必要な権限を備えたシステムのデフォルトコマンド実行ロールを作成」により作成してください。

2. アウトプットからアクティベーションコード/ID の抽出

前項のアウトプットからアクティベーションコード/ID を個々の変数に分離しています。

3. コンテナ自身をマネージドインスタンスへの登録

取得したアクティベーションコード/ID を利用し、コンテナ自身をマネージドインスタンスとして登録します。環境変数AWS_DEFAULT_REGIONのように AWS の Credential にてデフォルトの Region 設定があった場合でも、このコマンドではオプションで Region 指定が必須となるのでご注意ください。

4. SessionManager エージェントの起動

最後に SessionManager エージェントを起動します。これにより AWS との通信が確立され、SessionManager が利用できるようになります。

この状態でマネージドインスタンス画面にて目的のインスタンスが「オンライン」であれば設定が完了です。

接続確認

設定が完了したので、実際に SessionManager にて接続してみます。 AWS コンソールのセッションマネージャからセッションの開始を選択し、名前が事前に登録したmedley-blog-fargate-containerであるものを選択します。外見は他の EC2 と変わらない表示ですが、この手段で登録したものはインスタンス ID がmiから始まる ID になります(通常の EC2 はiから始まる ID)。

後は普段通りにセッションを開始するとコンテナ内へのアクセスが開始されます。これで EC2 の無い Fargate 上のコンテナに対してもターミナルに入ることができました。

運用してみての感想

Fargate 上のコンテナに直接入ることにより、今まで出来なかった topコマンドによるプロセス状態の確認 dfコマンドによる Disk 容量の確認などの環境調査が出来るようになりました。利用頻度が多い訳ではありませんが、調査の選択肢を増やす事により有事の際の早期対応に繋げれられていると感じています。

注意点

ここからは運用に当たっての注意点について数点紹介します。

料金

EC2 での SessionManager と違い、この方法で登録したサーバへの SessionManager 通信は料金が発生します。正確には「SessionManager エージェントが起動し AWS と通信が確立している状態」での時間課金で SessionManager での接続有無は問いません。よって、常時必要ではない場合は SessionManager エージェントを止めて節約する方法を検討してください。

アクティベーションやマネージドインスタンスがリストに残る

コンテナ終了時でも AWS コンソールのハイブリッドアクティベーション一覧やマネージドインスタンス一覧に表示が残ってしまうようです。一覧の上限の記載は見つからなかったものの、無限に増えるとも思えないので適時 Lambda を使って削除しています。

SessionManager での操作について

EC2 インスタンスに対しての SessionManager と同様ですが、セッション開始直後のユーザは ssm-user 固定になるようです。特定ユーザでの操作が必要となる場合、suコマンドでのユーザ切り替えが必要になります。

さいごに

今回のようにメドレーでは新たな技術を取り入れつつ、サービスの安定を目的とした様々な施策を導入しています。こういった働き方に興味を持たれた方、まずは下記リンクからお気軽にお話しませんか？

iOSDC 2020 にシルバースポンサーとして協賛します

Mon, 14 Sep 2020 09:11:00 GMT

みなさん、こんにちは。エンジニア・デザイナー採用担当の平木です。

メドレーでは iOS 開発コミュニティに微力ながら還元したいと、2017 年より iOSDC に協賛をさせていただいておりますが、今年もシルバースポンサーとして協賛させていただくことになりました。

過去の参加レポート

entry/2018/09/13/175702

entry/2017/09/27/120000

iOSDC 初のオンライン開催

今年の iOSDC は初のオンライン開催ということで、例年とはまた違った楽しみ方ができそうです。

公式スタッフブログに記載されていますが、今年はノベルティグッズが配送されるとのことで、既に届いている方もいらっしゃるようです。弊社のパンフレットも同封させていただいてます。

今年のタイムテーブルも大変興味深い内容が多く、今から視聴が楽しみですが(スポンサーチケットを頂いてはいますが、筆者も自腹でチケット購入しています)ニコニコ生放送での視聴ということで、例年とは違い、コメントなどで盛り上がりがあるのではないかと、大変期待しています。

Ask the Speaker ではDiscordを使用するということで、対面とはまた違ったコミュニケーションが取れそうです。参考 URL や図などがすぐに出してもらえたりなど、さらに学びが深くなるのではないかと思っています。

最後に

今回は直接会場でみなさんとの交流はできませんが、弊社のエンジニアも参加予定ですので、一緒に楽しんでいきたいと思います。後日イベントレポートもこちらで公開したいと考えています。

また、メドレーではこうしたイベントにも興味をお持ちの iOS エンジニアを絶賛募集中です。お気軽に下記よりご連絡いただければ、カジュアルにお話をしたいです!

OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話

Fri, 21 Aug 2020 10:09:34 GMT

こんにちは、インキュベーション本部エンジニアの加藤です。主に CLINICS アプリの開発を担当しています。

はじめに

CLINICS アプリの開発では OpenAPI や gRPC を利用しています。 OpenAPI と gRPC の間には何の関係もないのですが、どちらも API の仕様をスキーマ言語で記述するという点では共通しています。今回はこの API スキーマが開発にもたらすメリットについて紹介していこうと思います。

API ドキュメントとしてのスキーマ定義

既存のコードに機能を追加する際や修正を加える際に気にすることの多い部分は API の仕様ではないかと思います。「リクエストやレスポンスはどのようなデータなのか」「この値は必須なのか、任意なのか」「データの型は数値なのか、文字列なのか」「フォーマットは決まっているのか」など、多くのことを把握する必要があります。

しかし、こういった API 仕様のドキュメントが整備されていないということも多いのではないでしょうか。また、ドキュメントはあるけれどリクエストとレスポンスのサンプル JSON が貼ってあるだけだったり、時間が経つうちに実装とドキュメントが乖離してしまいアテにならなくなってしまっている場合もあります。参考にできるドキュメントがない場合は、直接バックエンドの実装を見に行くこともあるのですが、目的のコードを探し出して読み解くのは意外と時間がかかります。特に自分以外のエンジニアが実装した機能の場合、API の仕様を実装から紐解くのはかなり骨が折れる作業です。

CLINICS アプリの開発ではこういった手間を減らすために OpenAPI や gRPC を利用しています。 REST API のスキーマは OpenAPI を使って記述しています。 gRPC を利用している部分は Protocol Buffers で RPC のインターフェースが記述されるため、これが API のスキーマになっています。 OpenAPI や Protocol Buffers の定義を参照することで API の仕様が容易に把握できるため、非常に便利です。

OpenAPI や Protocol Buffers などのスキーマ言語の良い点は、宣言的な DSL でスキーマを定義できる点です。実装言語に依存しない形での記述ができ、自然言語のような曖昧さもないためより正確に API 仕様を記述することができます。

ここからは OpenAPI や Protocol Buffers の実際に記述例を挙げながら、どういった形でスキーマを記述していくのか簡単に見ていきたいと思います。

OpenAPI

OpenAPI は REST API のインターフェースを記述する仕様です。エンドポイントのリクエストパラメータやレスポンスの構造などを JSON や YAML で記述していくことができます。かつては Swagger という名称だったため、そちらの名前で知っているという方もいらっしゃるかもしれません。

実際の OpenAPI の定義は以下のような形になります。

openapi: 3.0.2
info: { title: OpenAPI Sample, version: 1.0.0 }
paths:
  "/users/{user_id}":
    get:
      parameters:
        - name: user_id
          in: path
          required: true
          schema: { type: string }
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  id: { type: string }
                  name: { type: string }
                  age: { type: integer, nullable: true }
                required: [id, name, age]
        "404":
          description: Not Found
        "500":
          description: Internal Server Error

例としてユーザー ID からユーザーのデータを取得する API を記述してみました。上記の定義を見ると、

GET: /users/{user_id} というエンドポイントがある
ユーザーの ID (user_id) を string でパラメータとしてパスの中に埋め込む
レスポンスは 200, 404, 500 が返ってくる可能性がある

といったことが読み取れるかと思います。また、レスポンスは以下のような JSON が返ってくることもスキーマから読み取ることができます。

{
  "id": "12345678-1234-1234-1234-123456789abc",
  "name": "user name",
  "age": 25
}

ここでは OpenAPI の記述の仕方についてあまり深く触れませんが、この他にもデータのフォーマットや省略された場合のデフォルト値などの記述なども可能です。より詳しくはこちらを参考にしてみてください。これらをうまく使うことでより正確に API の仕様を記述することができます。

Protocol Buffers

Protocol Buffers は主に gRPC で用いられるデータのシリアライゼーション形式です。専用のスキーマ言語を用いてデータの構造や RPC のメソッドの定義を .proto ファイルに記述していきます。

実際の .proto ファイルは以下のような形になります。

syntax = "proto3";
package example.protobuf;

service UserService {
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
}

message GetUserRequest {
  string id = 1;
}

message GetUserResponse {
  User user = 1;
}

message User {
  string id = 1;
  string name = 2;
  int32 age = 3;
}

少し独特な見た目をしていますが、message として構造体のようなデータ構造が定義されていることが見て取れると思います。各メッセージにはフィールドが定義されており、型とフィールド名が宣言されています。

スキーマ言語を使うメリット

スキーマはドキュメントの代わりとして使えるだけでなく、他にもいくつか使い道があるので紹介していこうと思います。

スキーマからソースコードを自動生成できる

スキーマ言語による記述は人間にとって読みやすいだけでなく機械的に処理できる形式でもあるので、スキーマからソースコードを自動生成することも可能です。プログラミング言語や使っているフレームワークによらず、サーバー側ではリクエストのバリデーションを、またクライアント側ではレスポンスの JSON をクラスや構造体に詰めるような処理を書くことが多いのではないでしょうか。事前にスキーマ定義を書いている場合はスキーマを見ながらこういったコードを書き起こしていくことになるのですが、せっかく machine-readable な形のスキーマがあるのだから自動でコードを生成したくなるのが自然な考えでしょう。自動で生成してしまえば定型のコードを書く手間を減らせるだけでなく、手書きするとどうしても起こしがちな JSON のキー名を間違えるといったミスを防ぐこともできます。また、Web, iOS, Android などの複数プラットフォームでサービスを展開している場合でも、それぞれの実装が乖離しないように管理していくことも容易です。

gRPC の場合は Protocol Buffers からソースコードを生成するのがほぼ前提となっています。 protoc コマンドを利用すると .proto ファイルから各言語のサーバー・クライアントコードを生成することができます。

OpenAPI の場合、openapi-generator や swagger-codegen などのツールを利用することで各種言語のコードを自動生成が可能です。 openapi-generator や swagger-codegen には多くの言語とフレームワークのサーバースタブと API クライアントのジェネレータが用意されています。

既存のジェネレータを使うだけでも十分に強力なのですが、さらに自前でコードジェネレータを書けばプロジェクト固有のルールでコードを生成するといったことも可能です。 OpenAPI のドキュメント自体はただの YAML/JSON なので、パースしてスキーマ定義を再帰的に読んでいけばコード生成に必要な情報を集めることができます。 Protocol Buffers からコードを生成する場合は protoc のプラグインを書くのが簡単でオススメです。

モックサーバーを使ってクライアント開発を進められる

コードの自動生成の他にもスキーマからモックサーバを立ち上げるといった活用方法もあります。 Prism のようなスキーマ定義から固定のデータを返すモックサーバを立ち上げるツールを利用すれば、クライアント側の開発もしやすくなります。特にフロントエンドとバックエンドで担当が分かれているような場合は、開発初期はモックサーバーを使って開発を始め、バックエンドの実装ができてきた頃に結合するという流れを踏むことで、フロントエンドもより早いタイミングから開発に着手することができるようになります。

実際に Prism を使ってモックサーバーを立ち上げるとこんな感じになります。

スキーマファースト開発

このような開発スタイルはスキーマファースト開発・スキーマ駆動開発などと呼ばれています。明確な定義や出典があるわけではないのですが、スキーマファーストな開発は以下のような開発スタイル全般を指しています。

スキーマは実装言語によらない machine-readable な形で記述する
ドキュメントをスキーマから自動生成する
クライアント/サーバーのコードをスキーマから自動生成する

実際にスキーマファーストな開発を実践するためにはスキーマをメンテナンスするモチベーションを高く保つ必要があります。コードも書いた上でスキーマも書かないいけないとなるとおそらくスキーマが更新されなくなっていくので、可能な限りスキーマからコードを生成する努力が必要になります。一方、うまく実践すればスキーマという形で 100% 信頼できる API ドキュメントが手に入り、クライアント/サーバー間での齟齬も減らせるので、実践してみる価値はあるのではないかと思います。

まとめ

今回は CLINICS アプリの開発でのスキーマ言語の活用例について紹介しました。実際に開発の中でスキーマ言語を使うことで API 仕様について把握する労力が減り、エンジニア間のコミュニケーションも取りやすくなったと感じています。また、一部のクライアントコードは OpenAPI や Protocol Buffers から自動生成しているのですが、かなり手間が省けると同時に人間の手で書くと起こりがちなミスも防ぐことができています。 OpenAPI であれば既存の REST API の仕様を書き起こすところから使い始められるので、興味のある方はぜひ一度使ってみてはいかがでしょうか。

最後に

インキュベーション本部では「医療ヘルスケアの未来」をつくる新規事業の立ち上げに挑戦しています。そんな私たちと一緒に働いてみたいと思った方は、ぜひ以下の採用情報もチェックしてみてください。

CLINICS 開発チームで横軸の取り組みをした話

Fri, 14 Aug 2020 04:55:16 GMT

こんにちは、19 新卒の桶谷です。現在は CLINICS で検査周りの開発を担当しています。

最近は、私自身が基礎疾患持ちということもあり、社会情勢を考慮してフルリモートで業務に勤しんでいます。オンラインコミュニケーションは対面と比べ、意識しなければならない点が多く、慣れが必要であると日々感じています。少しでも対面に近い環境を実現するために、一眼レフカメラを Web カメラとして代用したり、ダイナミックマイクを使用してクリアな音声を届けられるように作業環境の改善に取り組んでいます。

今回は CLINICS 開発チームで課題となっていた「オンボーディングやキャッチアップに時間がかかる問題」を解決するために行った、横軸の取り組みについて紹介します。

はじめに

CLINICS 開発チームではクラウド診療支援システム「CLINICS」の機能として主に電子カルテ、オンライン診療、予約システムなどの機能の開発を行っています。医療システムの開発において医療業務知識は必要不可欠であり、例えば「会計」や「検査」といった医療機関で行われる業務に関する理解が要求されます。そのため、各々が日々キャッチアップに勤しんでいる一方、ひとつひとつの業務が複雑であるために、複数の機能を横断したプロダクト理解、全体把握が難しい課題がありました。そこで、この問題を解決するべく「横軸勉強会」と題して、CLINICS のドメイン知識共有会を行うことにしました。

ドメイン知識共有会の概要

ドメイン知識共有会は各々が携わった中で蓄積してきた業務知識や開発の背景を共有する会です。本会は毎週 1 時間トピックに沿ってオンライン(Google Meet)で実施します。あらかじめトピック、発表者、ファシリテーターを指定し、発表者には簡単な資料を用意してもらいます。加えて参加者には以下のことを意識してもらいました。

発表者は対話型の発表を意識しフラットな雰囲気をつくる
参加者はチャットを用いて思ったことをつぶやく

各トピックは医療システムを開発する上で必要なドメイン知識を切り口として、技術寄りの内容となっています。発表者によっては勉強会後の宿題が用意されたり、おすすめの本紹介があったりと多種多様です。発表形式をあえて定めないことで、各回ごとに発表者の個性が出るというのも面白みの一つだと思います。特に宿題があった回では、後日にフィードバック会が設けられ知識の定着に繋がりました。

実際に行ったトピック

実際の様子

ドメイン知識共有会を終えて

今回ドメイン知識共有会を通して、機能の実装背景や概要を幅広く知ることができました。「会計業務の複雑さ」や「受付から診察までの動線設計」などのこれまでは共有する機会がなかった個々が持っている知識・知見を学ぶことができ、チーム全体でドメイン知識に関する認識合わせをする良い機会となりました。

最後に勉強会の振り返りを行ったところ、以下のような意見がありました。

ドメイン知識共有会を通してチーム力が上がってきている
勘違いしていた知識を訂正できた
相互理解が深まりチーム全体としてコミュニケーションのハードルを下げることができた
各専門領域に関するドキュメントを一箇所にまとめることができた

ポジティブな意見が多く、取り組みの結果としてチームの基礎力向上にも繋がったと感じています。加えて、ドメイン知識共有会用に作成した資料はドキュメントとして残るため、オンボーディング資料などに活用ができそうです。しかしながら、以下のような問題もあります。

発表者の準備コストが高い
概要説明で終わってしまい即日業務で使用できる内容ではない
学んだことを深堀りできていないため知識の定着に繋がらない

上記については、例えば発表者を 2 人ペアにして準備コストを分散させたり、宿題を出して次回にフィードバックする、開発チーム以外も気軽に参加ができるようにライトなトピックを追加するなど、今後のドメイン知識共有会のなかで改善していきたいと思います。

さいごに

今回は CLINICS 開発チームで行った横軸の取り組みについて紹介させていただきました。

横軸でお互いをフォローしあうような「情報共有の場」を作ることで、より良い組織になっていくと感じています。今後、さらにプロダクトの機能が増えるとともに事業部全体として、関わるメンバーが増えるため、横軸での知識共有の仕組みは事業部を含めて必要であると考えています。開発チームに限らずに、プロダクトに関わるメンバーを巻き込み、組織コミュニケーションの改善を続けていきたいです。

最後までお読みいただきありがとうございました。

Terraform のテスト環境を Terraform Workspaces で構築した

Fri, 31 Jul 2020 07:59:05 GMT

株式会社メドレーのエンジニアの笹塚です。主にジョブメドレーのインフラを担当しています。

直近では、コンテナ化されていなかった環境の移行などをしていました。
休日は主にゲームをやっています。今は、日本語版がリリースされたばかりの「レムナント：フロム・ジ・アッシュ」に夢中です。

今回は Terraform のテスト環境を、Terraform Workspaces を使用して構築した事例を紹介します。

背景

ジョブメドレーにはいくつかのサービスがあり、Terraform によるコード化が進んでいるサービスと、Ansible、 itamae などで部分的にコード化はされているものの、Terraform の使用が遅れているサービスが混在しており、これらのサービスについても Terraform への移行を進めています。

Terraform への移行とあわせて、メンテナンスを担当するメンバーを増やす必要があるのですが

【作業担当】

Terraform のコードから、実際に稼働させる環境を作るのは慣れていても難しい。

【レビュワー】

Terraform のコードの差分だけで、内容をすぐに把握するのは難しい。

などの理由から、作業担当、レビュワーともにハードルが低いとは言えず、Terraform によるインフラの変更内容を事前に確認できる環境構築が必要だと感じるようになりました。

検討内容

事前に確認できる環境を作るにあたり、まず最初に検討したのは、各ステージのコードを共通化することでした。ジョブメドレーの関連サービスでは、大きくわけて 3 つのステージで構成しています。

Sandbox(個人の検証用) → QA(リリース前の検証用) → Production

この各ステージのコードを共通化できれば、Production には QA 環境までで確認済みのコードを apply することができます。

ですが、Sandbox 環境、QA 環境、Production 環境はそれぞれ似てはいるものの、全てが同じ構成ではありません。

Terraform の HCL では

if 構文がない( resource の作成を count で制御することはできる)
module 単位でのリソース作成の制御ができない(Terraform 0.13 から module でも count や for_each が可能になるようです)

などの制限があり、構造の差分をコードで吸収しにくく、共通化できたとしてもメンテナンス性を下げる可能性が高いです。また、すでに Terraform でコード化されている状態からの移行作業も楽ではないでしょう。

そこで、ステージごとのコードを共通化するのではなく、AWS Organizations で別アカウントを作り、各ステージのコードを試せる環境を作ることにしました。

<目標とする>

Terraform のコードをプロダクションアカウントで実行する前に、テストアカウントで実行し、設定した内容を AWS マネジメントコンソールや AWS CLI で確認することできる。

テストアカウント上で設定を確認した後、プロダクションアカウントに同じコードを apply することができる。
コストを抑えるため、テストアカウント上のリソースは、確認が終了したら destory することができる。

<目標としない>

テストアカウント上でサービスが稼働することは目標としない。
必要なデータセットの作成など用意するものが増えるので、目標には含めませんでした。

設定作業

必要な作業は大きくわけて 2 つです。

Terraform Workspaces の設定
アカウントごとに必要なコードの追加、修正

Terraform Workspaces の設定

Terraform と AWS provider の設定を変更することで、workspace を切り替えることができます。

以下が作業イメージです。

workspace の追加

$ terraform workspace new production
$ terraform workspace list
  default
* production

Terraform の環境変更

terraform {
 required_version = "= 0.12.28"
 backend "s3" {
   bucket               = "example-state"
   workspace_key_prefix = "workspace"
   dynamodb_table       = "terraform-state-lock"
   key                   = "example.tfstate"
   region               = "ap-northeast-1"
   profile              = "production"
 }
}

provider "aws" {
 region  = "ap-northeast-1"
 version = "= 2.70.0"
 profile = var.workspace_profile[terraform.workspace]
}

variable "workspace_profile" {
 type = map(string)
 default = {
   default    = "test"
   production = "production"
 }
}

この例では、default workspace はテスト環境、Production を実際にサービスが稼働する環境のアカウントになるように設定しています。それぞれ default は、aws config の test profile、Production は production profile を参照しています。

s3://example-state/example.tfstate がテスト環境、s3://example-state/workspace/production/example.tfstate が、プロダクション環境の state ファイルになります。

Terraform のコード内からは、現在の workspace 名を terraform.workspace で参照することができます。

ここまでの設定で

$ terraform workspace select [workspace 名]

で workspace を切り替えることができるようになりました。

あとは、アカウントごとに必要な変更をしていきます。

アカウントをまたいだ共通のリソースの定義

全アカウントでユニークにする必要があるリソース(S3 bucket、DNS など)の場合は、名称の分岐処理が必要です。テストアカウントでは、リソース名に prefix をつけて作成するようにしました。

# 定義
 variable "example_bucket_name" {
 type = map(string)
 default = {
   default    = "test-example-bucket"
   production = "example-bucket"
 }
}

# リソースでの参照時
resource "aws_s3_bucket" "example" {
 bucket = var.example_bucket_name[terraform.workspace]
 ..
}

テストアカウントで起動するインスタンスタイプや台数の変更

テストアカウントでは EC2 のインスタンスを起動させなくても良い場合には、台数を変更するようにしました。

resource "aws_autoscaling_group" "example_web" {
  name             = "example-web"
  max_size         = 12
  min_size         = 6
  desired_capacity = terraform.workspace == "production" ? 6  : 0
  …
}

インスタンスの起動が必要な場合も、同様の分岐でインスタンスタイプの変更を行っています。

コード化をしないリソースの扱い

プロダクションアカウントで一旦コード化を保留したリソースについては data source で参照しますが、テストアカウントにはリソースが存在しないため作成しなければいけません。テストアカウントのリソースは確認が終了した段階で destroy したいので

ステージ用の Terraform コードとは別に、必要なリソースを作成するコードを用意する
必要なリソース用のコード → ステージ用のコードの順に apply する

ようにしました。 data source で参照できれば良い範囲でのコード化なので、この追加のリソースも最小限のコストになるようにしています。

以上の設定で、同じ Terraform のコードを workspace を切り替えて plan、apply ができるようになりました。

運用してみて

プロダクションアカウントに apply する前に、テストアカウントで事前に apply することができるようになったので、作業中の試行錯誤もしやすくなりました。

レビュワーも、テストアカウント上で実際に apply された結果を確認することができるようになり、apply の差分だけではわかりにくかった変更内容を確認できるようになりました。

これなら新しく担当するメンバーの不安を、少しかもしれませんが解消できそうです。

まとめ

今回は Terraform のテスト環境を、Terraform Workspaces を使用して構築した事例を紹介させていただきました。テストアカウント上のリソースの自動 destroy や、 plan、apply の自動化については触れられていませんが、また別の機会に紹介できればと思います。

長らく運用しているサービスでは、サービスを稼働させたまま解決しなければいけない課題が数多くあります。それらの課題を、一つずつ着実に解決していくことに楽しさを見いだせる方、ぜひメドレーで一緒に働きましょう！

一休.com に Service Worker(Workbox)を導入しました

PWA, PRPL Pattern の概要と採用状況の調査

Fri, 17 Jul 2020 08:07:11 GMT

こんにちは。メドレーにてジョブメドレー開発エンジニアをしています、矢野と申します。

ジョブメドレーでは、主にバックエンド ( Ruby on Rails ) の改修を担当してます
直近では 「サイトパフォーマンス改善施策」 として、Rails コードのリファクタリングによる TTFB 高速化に取り組んでました
「もう絶対にコケないのが分かってる」ビルドやテストを、手元のコンソールで何度も叩いて「わー。ちゃんと通る！」っていう時間が好きです

今回は、上記の「サイトパフォーマンス改善施策」の文脈で調査した、PWA の実装パターンである PRPL Pattern という リソース提供の設計アーキテクチャ について紹介します。

PRPL Pattern とは

ref. Apply instant loading with the PRPL pattern - web.dev

PRPL Pattern は、Google I/O 2016 で提案された PWA - Progressive Web Application の構築・配信のための設計アーキテクチャです。

Web サイト・アプリケーションが、回線強度やスペックが高くないスマートフォンなどのデバイスでもストレスなく機能するよう、リソース配信とアプリ起動時のパフォーマンス ( = 高速化 ) に重点を置いています。

PRPL meanings

では具体的に「どうやって速くするの？」ということで、PRPL が提唱している 4 つのサイトレンダリング手法について見ていきます。

Push: <link preload> および HTTP/2 を使用して、初期 URL ルートの重要なリソースを Server Push する
Render: クライアントが初期ルートをなるべく早くレンダリングする
Pre-cache: 残りのルートをクライアントが Service Worker でプリキャッシュする
Lazy load: クライアントはオンデマンドで残りのルートを遅延読込みして作成する

PRPL は上記 4 つの頭文字をとったものですね。 PRPL は HTTP/2 の Server Push や、PWA の Service Worker など、Web プラットフォームの最新技術を駆使してサイトパフォーマンスをあげよう！というプラクティスです。

PWApps とは、最新の Web 技術を有効に活用し、漸進的（ Progressive ）に高度なユーザー体験を提供しようとする概念です。この PWApps の概念を具体化する一つの手法として、「 PRPL 」（パープル）と名付けられた開発・提供パターンが提案されました。

(中略)

Web Components や、 Service Worker、 HTTP/2 Server Push といった Web の最新技術をフルに活用し、レスポンス性の高いユーザー体験を提供しようというものです。

ref. Google が新たに提唱する Progressive Web Apps の新たな開発パターン「 PRPL 」とは？

周辺知識 - HTTP/2

まずは、周辺知識からおさらいしていきます。PRPL は HTTP/2 の Server Push を利用する、という話でした。そもそも HTTP/2 とはどんなものでしょうか。

Hyper Text Transfer Protocol と呼ばれる TCP 上の通信プロトコルの次世代バージョン
普段私たちが Web サイトを閲覧する際に利用しているプロトコル
HTTP/1.1 が 1997 年に策定され、2015 年にようやく /2 が標準化
Express, Apache, Nginx など各 Web サーバ、各ブラウザも対応してきている

ref. HTTP の進化

現行の一般的なバージョンは HTTP/1.1

HTTP は普段私たちが Web サイトを閲覧する際に利用する通信プロトコルです。HTTP/2 はその次世代バージョンになります。HTTP/1.1 には以下のような特徴があります。

ステートレスな通信
テキストベースで情報をやりとりする
原則 1 リクエストに対して 1 レスポンスである
→ 複数リソースを得るために何度もリクエストしてコネクションを貼り直す必要があり パフォーマンス上の課題がある

これに対して、1.1 の次期バージョンである HTTP/2 は以下のような特徴があります。

通信時にヘッダを圧縮し使い回す省エネ設計 = 一部ステートがある
バイナリベースで情報をやりとりする
ストリームという概念で、1 コネクション中で Request / Response を多重化できる
→ 1 コネクションの中で複数リソースを並行して Request / Response できる！
リソースの Server Push が可能

HTTP/2 自体が HTTP/1.1 の課題であった通信のオーバヘッドを改善する規格であることがわかりますね。また「 request / response の多重化」により、1.1 と比較してどの程度「速く」なるのかについては、以下 Akamai 社のブログサイトが参考になります。

HTTP/1.1

HTTP/2 ( request / response の多重化 )

ref. HTTP/2 を活用するパフォーマンス最適化 ADAPTIVE ACCELERATION

HTTP/2 の採用事例

ref. caniuse.com

上記対応状況からも分かる通り、モダンブラウザでは一通り対応しています。実際のプロダクションでも日本ではメルカリさん、世界的なサービスだと Twitter, Facebook, Instagram など SNS サービスや、Slack, Dropbox などが HTTP/2 に対応しているようです。

ジョブメドレーはまだ HTTP/1.1 でのサービス提供しか行っていませんが、ゆくゆくはバージョンアップ対応を行っていきたいと思っています。

周辺知識 - PWA

次に、PWA についておさらいします。PRPL は PWA の Service Worker を利用した実装パターンという話でしたが、そもそも PWA や Service Worker とはどんなものなのでしょうか。

PWA - Progressive Web Application

Web プラットフォームの新機能を使って「ネイティブアプリとウェブアプリのいいとこ取りした、UX の高いウェブアプリ」という概念
ウェブアプリの特性 ( Secure, Linkable, Indexable … ) を保ちつつ、ネイティブアプリの多機能さ ( インストール、プッシュ通知、オフライン動作 … ) を最新のブラウザ機能 = JavaScript API で実現する
必ずしも SPA であったり、最新機能の全てを使っている必要はなく、「斬新的に Web 新 API でネイティブな機能を取り入れていける」というコンセプト

ref. プログレッシブウェブアプリの紹介 - MDN

PWA を構成する新機能たち

HTTPS: HyperText Transfer Protocol Secure 、 SSL / TLS による通信の暗号化
Service Worker: Web ページで動作するスクリプトから独立したイベント駆動型の worker
Cache API: Request / Response オブジェクトのストレージキャッシュ
Push API / Notifications API: サーバーからアプリへの通知送信
マニフェスト: アプリストアを通さず Web アプリをホーム画面にインストール可能

ref. プログレッシブウェブアプリ - MDN

上記以外にも、PWA には様々な API ・機能が存在します。その中でも PWA の、そして PRPL アーキテクチャの中核を成す重要な機能が Service Worker です。

Service Worker とは

ブラウザのバックグラウンドプロセスとして動作する Worker
Web ページで動作するスクリプトとは独立して動作する
サーバサイドでいうところの Worker プロセスと同じような使い方ができる

ref. Service Worker の紹介

Web ページの JavaScript プロセスとは切り離された文脈で、予め登録しておいた処理を、様々なイベントに応じて発火させることができるイメージですね。

プッシュ通知など、いわゆる「ネイティブアプリのような機能」は、この Service Worker を利用することで実現しています。

PWA の採用状況

Google からの提唱当初 ( PWA も Google のプロジェクトです ) こそ、先進的すぎてなかなか受け入れられなかった PWA ですが、2020 年現在は各ブラウザの対応状況も少しずつ向上されています。

日本では SUUMO、日経電子版、一休.com、世界的なサービスだと Instagram などが PWA による Web サイトを提供しているようです。

特に、既にネイティブアプリで大成功している Instagram が、回線・端末スペックの低い新興国をターゲットとした PWA をリリースしているという点はプロダクト観点からもとても興味深いですね。

PRPL パターンの利点

さて、話を戻して PRPL パターンが HTTP/2 や Service Worker を使って、具体的にどのようにサイトパフォーマンスを向上するのか？という点を見ていきます。

Server Push + Service Worker による Pre-cache

PRPL の 4 要素を、改めてもう少しわかりやすく記載してみると以下のようになります。

Push
- 初回コネクションで HTTP/2 Server Push で必要リソースをまとめて Push
Render
- 上記で受け取った HTML リソースを元に初期画面をレンダリングする
Pre-cache
- 上記初期画面で利用されるリソースは、Server Push により非同期的に Service Worker が Pre-cache する
- また、今後利用しそうな追加リソースについても、非同期・投機的に Service Worker が事前に DL 、キャッシュする
Lazy load
- 初期画面以降で必要になった画像などのリソースを、画面スクロールなどを検知し、表示に必要になったタイミングで遅延読み込みする

上記の太字箇所を画像で説明すると、以下のようになります。

HTTP/2 ( Server Push )

HTTP/2 を活用するパフォーマンス最適化 ADAPTIVE ACCELERATION

HTTP/2 の Request / Response の多重化だけを利用したケースと比較すると、「ブラウザがページを解析して、必要リソースを Request する」よりも前に「サーバが必要リソースを強制的に Push 」しているのがわかります。

この Push されたリソースを Service Worker が受け取り → キャッシュ化することで 「ページ解析が終わった時点では既に必要リソースがブラウザにキャッシュされている」 状態となり、アプリの初回起動が速くなる、というのが Push & Pre-Cache の速度改善の仕組みです。

Service Worker で必要になりそうなリソースの事前キャッシュ

また、初期画面に必ず必要なリソース以外については、「このあと必要になりそう・なるはずの追加リソース」ということで、Service Worker に投機的に事前 DL → Pre-cache されることも可能です。

このあたりのキャッシュ戦略・導入事例は以下の一休さんの記事が詳しいです。

PRPL Pattern の採用状況

さて、そんなパフォーマンスに嬉しい PRPL Pattern ですが、HTTP/2、PWA 自体の普及率も高くなくまだまだプロダクションでの採用事例は少ない印象です。

Google I/O で日経電子版が事例として紹介された話
- PRPL パターンを参考にした Service Worker を使ったキャッシュ、HTTP/2 Push でのリソース配信などが採用されている
ライブラリでは有名どころだと Gatsby が標準対応、当たり前だが Google の Polymer ライブラリも PRPL パターンで実装されている

とはいえ、PWA 化している Web サイトであればパターンの適用はそこまで難しくありません。

また Next.js の PWA 化ライブラリ next-pwa では、Next.js 本体の Code Splitting 機能と連携した「 Service Worker での追加コード読み込み」をサポートするなど、このようなアーキテクチャパターンの潮流は今後も派生していくのかな？という気がしています。

まとめ - HTTP/2 + PWA + PRPL Pattern

まとめです。

PWA とは
- Web プラットフォームの新機能を使った「ネイティブアプリとウェブアプリのいいとこ取りした UX の高いウェブアプリ」という概念
PRPL パターンとは
- スマートフォンなど回線強度・スペックの低いデバイスのために、Google が UX 向上のために提唱する PWA の設計アーキテクチャ
- HTTP/2, Service Worker などを使って (リソースの) Server push, Pre-cache, Lazy load を行う
プロダクトで使えるのか
- Web サイトの PWA をする／しているのであれば、サーバの HTTP/2 化をして、リソースの Push、Pre-cache を導入するのはパフォーマンス観点で十分検討できるのでは
- 但し、SPA + SSR 構成のサイトでは、Next.js などフレームワークのコード分割に寄せるのが今の所無難そうではある

今回は調査のみで、プロダクトへの実践投入は行いませんでしたが、今後プロダクトの PWA 化が企画されるような場合は、ぜひ導入してみたい技術だなと感じました。

以上、ここまで読んでくださり、ありがとうございました。

ECS サービス間の通信を Amazon ECS サービスディスカバリで実現した話

Tue, 30 Jun 2020 08:53:36 GMT

株式会社メドレーのエンジニアの阪本です。

緊急事態宣言も開け、普段の生活を取り戻しつつあるこの時期、皆さんはいかがお過ごしでしょうか？

私は野球観戦（虎党）を毎日の楽しみとしています。今年はコロナ渦の影響で開幕予定が遅延したものの、自粛期間を経て 6 月中旬にめでたくシーズン開幕を迎えることができました。ここまでの「長い冬」が明け、テレビをつけると野球が見られる。これで私自身も 2020 年が開幕したなと実感しています。

今回は、私がインフラ開発時に直面した問題と解決までの事例について紹介させて頂きます。

背景

私はジョブメドレーのサービス開発を行っています。このシステムは多くの機能で構成された大規模なもので、AWS の Elastic Container Service(以下 ECS)にて稼働しています。

このシステムに対し既存機能のリプレース案件に携わる機会がありました。現在のシステムは多くの時間をかけて多くの機能を実装した結果、かなり大きなコードとなっています。これにより、一つの変更が及ぼす影響が甚大なものになり得る状況だったため、リプレース対象の機能を新システムとして別アプリケーションに切り出して開発することにしました。

しかし、別システムとして一部の機能を切り出すものの、この機能は既存システムとの連携が必要となります。そのため、この連携をシステム間の API リクエストで実現することにしました。

課題

ここで１つの問題が発生しました。システム間の通信が必要になりましたが、お互い ECS サービスで分離した構成となるためこのままではアドレスの解決が出来ないことに気づきました。

同一 ECS サービス内でかつ、ネットワークモードが awsvpc モードであればポート番号を分ける事により相互でアクセスが可能であるものの異なるサービスであればポート以前にアドレス解決ができません。

そのため、何らかの手段を持ってお互いの場所を認識できる状態にする必要があります。そこで、これを実現できる幾つかの方法を検討しました。

アプローチ

その１　全て１つの ECS のサービスにまとめる

上記の通り、既存システムが動いている ECS サービス/タスクに新システム（のコンテナ）を全て混ぜる方法です。この場合、全てのポートを個別に割り振ることで 127.0.0.1:port によるアクセスが可能となるため相互のリクエストも実現できることになります。

ただ、インフラ的には２つのシステムが１つの塊として構成される事になるためデプロイの単位やスケールの単位を常に双方共有することになります。

こうなると、せっかくアプリケーションを分けたにも関わらず運用の部分では何もメリットを得られないどころか制約が増えただけのようになりそうなのが問題です。

その２　内部 Application Load Balancer を経由する

VPC 内部に internal な Application Load Balancer（以下 ALB) を設置し、接続先となる既存システムを TargetGroup に登録します。この方法であれば、ALB のエンドポイントに向けてリクエストすることで配下の既存システムにアクセスする経路が確保できます。

また ECS サービスと TargetGroup が紐づくことにより既存システム側のデプロイやスケールが自動的に ALB 側にも連動することになるため、新システム側は既存システムのステータスを意識する必要は少なくなります。

これだと不自然な点も無くアプリケーション間の通信経路も確保できると期待しましたが・・・新たに問題が発生しました。

検証時に ALB/TargetGroup を新規作成。 ECS サービスについては後付けで TargetGroup 脱着はできない複数 TargetGroup の付与は AWS コンソールでは対応していないといった理由のために AWS CLI での作成作業を行ったのですが、下記エラーが発生してしまいました。

An error occurred (InvalidParameterException) when calling the CreateService operation: load balancers can have at most 5 items.

これは AWS による制限で、1 つの ECS サービスに関連付けることのできる TargetGroup は最大 5 つまでという事を表しています。つまり既存システムは多くの機能やコンテナが同居している ECS サービスとなっていたため、既に TargetGroup が 5 つ存在しており上限に達していたのです。

サービスで使用するロードバランサーを表すロードバランサーオブジェクト。Application Load Balancer または Network Load Balancer を使用するサービスの場合、サービスにアタッチできる 5 つのターゲットグループの制限があります。

Amazon ECS サービス定義パラメータ - Amazon Elastic Container Service

Amazon ECS サービスの実行方法を定義するサービス定義パラメータについて説明します。

docs.aws.amazon.com

この方法を取るなら不要な TargetGroup を削るかまとめるかの手を打つ必要がありますが、周辺環境に対する影響があまりにも大きい為に現実的ではありませんでした。そのため、新たな選択肢を探すことにしました。

その３ Amazon ECS サービスディスカバリを使用する

そんな中、ECS の機能としてサービスディスカバリ（サービス検出）というものを見つけました。

Amazon ECS サービスディスカバリ | Amazon Web Services

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが A […]

aws.amazon.com

これは ECS サービスと Route53 内部ホスト空間を紐付ける機能です。また ECS サービスの起動・停止・スケールといった対象が変動した場合にも、自動的にホスト空間のレコードを登録/解除し最新の状態に追従してくれるものです。

この場合、別々のサービス間でもお互い相手の名称を把握することができる上、 TargetGroup も新規に必要としないため、今回のニーズに適した方法になりそうです。

導入してみた結果

試しに ECS サービスにサービスディスカバリを導入し、疎通できるか試してみます。既に存在するサービスに後付でのサービスディスカバリは出来ないため、新規にサービスを作成することになります。

今回は初めてのサービスディスカバリとなるので、名前空間も同時に作成することになります。ひとまず名前空間を「medley-blog.local」、サービス検出名を「service-discovery」としてみます。

このまま ECS サービスを作成すると、Route 53 にて新たな名前空間「medley-blog.local」が作成されていることが確認できます。

この状態でサービスのタスクを 1 つ起動ししばらく待つと、サービス検出名.名前空間となる service-discovery.medley-blog.local に A レコードが追加されています。このレコードに紐づく IP アドレスこそ、ECS タスクに紐付けられている IP アドレスになります。

あとはこの名称で別環境から疎通できるか試してみます。 curlコマンドでservice-discovery.medley-blog.localで通信してみると、見事にレスポンスを受け取ることが出来ました。

※ここでは検証のため、接続先アプリケーションは Nginx コンテナを配置しています

これにより、異なる ECS サービス間での通信を実現することができました。

今後の予定

現段階では検証段階のため評価環境への導入のみとなりますが、今の所は大きな問題も発生せず順調に稼働しています。このまま特に問題無く稼働できれば、本番環境への導入も目指したいと思います。

さいごに

メドレーのエンジニアは大小問わず課題に対して真摯に向き合い、試行錯誤し、突破口を開く取り組みを常に続けています。そんな我々と一緒に働きたいと思った方、まずは下記リンクからご応募いただきカジュアルにお話しませんか？

デザイナーがデザインツールを使わずに、React を使ってデザインした話

Fri, 19 Jun 2020 10:45:58 GMT

メドレーのデザイナー酒井です。最近、JobMedleyからCLINICSに異動しました。自分はデザインはもちろん、HTML/CSS/JS 実装してプルリク送ったりしているちょっとフロントエンド実装領域に軸足が寄ったタイプのデザイナーです。

ここでは以前所属していた JobMedley 事業部の話をさせていただきます。

当時、JobMedley の社内システムのリニューアルプロジェクトにデザイナーとして参加していました。通常、デザイナーがデザインをするときには Skecth や Figma のようなデザインツールを利用するのが一般的かと思います。

弊社でも基本的にはデザインツールでデザインを行うことが多いのですが、プロジェクトによっては、よりリアルなモックアップが必要なため、デザイナー自身がコーディングでデザインを行い、ブラッシュアップしていくことがあります。その後、フロントエンド実装者が、デザイナーが作ったデザインを参考に、しっかりと設計されたもので作り直します。

今回のリニューアルプロジェクトのデザイン・モックアップの制作では、Figma や Sketch などのデザインツールは使用せず、React でコーディング行い、デザインを制作しています。ここが特殊な制作フローになると思うので、このエントリでは React をデザインツールとして使ったときの流れとメリット・デメリット、ちょっとニッチなポイントに絞ってお話していきます。

デザインの流れ

1.まずは React を勉強する

元々受託制作会社でデザイナーをやっていた時代に Vue.js での開発経験はありましたが、React は今回が初めてでした。そのため、一旦公式チュートリアルを一通り読み、Google などで調べつつ、基礎知識のインプットすることからはじめました。

2.ワイヤーフレームを作る

さすがにワイヤーフレーム無しでコード実装には入れないので、ここでは Figma などのツールを使います。ワイヤーフレームを作り、要件定義を進めていきますが、デザインに関してもある程度のあたりを付けていきます。

3.開発環境構築

今回は Next.js で制作を行っています。そもそも、プロダクトの実装で Next.js を使用することが決まっていたので、デザイン側も Next.js を採用しましたが、結果的に良かったなと感じています。

Next.js で作っておけば、めんどくさい router の設定やデザイナーが苦手な webpack の config を記述しなくてすみます。

また、next build && next exportで静的な HTML ファイルとして書き出されるため、サーバがあればすぐに共有が可能です。今回はエンジニアさんに、develop ブランチに merge されると、next build && next exportが走り、自動で Amazon S3 に静的ファイルをデプロイされるようにしてもらいました。

この時点でプロダクト側のフロントエンド設計も進んでいたため、ESLint やコンポーネント設計、ライブラリなどを流用し、デザインプロジェクト用に最適化させます。

4.Next.js の設計

実際にエンジニアがプロダクトを実装する際には色々なことを検討する必要があると思いますが、デザインツールとして使用する際には、逆にそこまでガチガチにしてしまうと実装に工数がかかりすぎてしまうので「割り切り」が必要になります。私が実装した際の環境は以下のようなものです。

TypeScript は入れない。要件が固まりきっていない状態で型定義をやり始めると修正に時間がかかりすぎるため。
非同期通信処理も入れない。データがほしければローカルに json ファイルを配置しておく。
デザイン側のソースコードの汚さはあまり気にしない。プロダクト版を作成するときにフロントエンドエンジニアがきれいに作り直してくれる。
コンポーネント設計を意識する。共通コンポーネントとして使用する汎用的なものは先に洗い出しておく。
テストコードは書かない。そこまでページ数が多くない上、上記のような割り切りをしているので複雑性も極端に上がらない。
Google Chrome 最新版のみ対応とする。他のブラウザは無視する。

（昨今のフロントエンド開発の流れと真逆、、、）

5.デザインルール設計

続いてデザインルールの設計を行います。

theme.js ファイルを作成し、以下を定義します。この時点で定義が完全にできていることは無いと思うので、分かる範囲で書いていきます。最終的に、不要なものを消したり、一緒にできるものは統合して定義を減らしていきます。

各コンポーネントで padding や margin の余白を数値で指定したり、色味のカラーコドをベタ打ちせず、必ず theme ファイルから値を引っ張ってくるようにします。そうすると、修正が容易になる上、あとからどこで何が使われているかを把握しやすくなります。

■theme 内に記述する内容のイメージ

fontFamily// fontFamily を定義
colors// カラーコードの一覧
spaces // 4/8/16 など余白に使う数字を定義。
fontSizes // fontSize を定義
lineHeight // lineHeight を定義
fontWeight // fontWeight を定義。
boxShadow // ドロップシャドウを使用するなら定義

6.コンポーネント設計

続いて、コンポーネントとコンポーネントに必要な props を洗い出します。

世の中には優秀な UI フレームワークが複数存在していますのでそういったものを参考にします。そういったものはほとんど同じようなコンポーネント設計になっているのでコンポーネントの分け方や受け取る props などを参考にすると作業が捗ります。

Ant Design https://ant.design/
Material-UI https://material-ui.com/
Element https://element.eleme.io/#/en-US

ここで気をつけたいのは、コンポーネントの数を極力減らすように努力することです。

同一機能の別コンポーネントが複数できてしまうと、今後の機能拡張時に、どのコンポーネントを使うか迷うことになります。ほとんどのエンジニアやデザイナーにとって、コンポーネント選びで迷うことは時間の無駄です。選択肢は極力減らす努力をし、減らせないようなら使用する場所を明確に定義する必要があります。

例えば

component/tab1/
component/tab2/
component/tab3/

のようにタブコンポーネントが複数あると、あとから見たときにどれを使えばいいかわからなくなりますよね。これを許容してしまうと、知らぬ間に

component/tab4/

ができあがっていることでしょう。

7.実装

まずは大枠のページテンプレートを制作します。その後、小さいコンポーネントから順に作り上げていき、ページテンプレートに配置していきます。コンポーネント化ができていれば、見た目の変更はあとから行えるので、まずは page 内に配置し、機能することを目指します。

この時点で、デザインを細部まで作り込んだとしても、結局全体を見渡してから細かく調整をかけていくと思うので、そこまでセンシティブにならずに行っていきます。

8.確認・ヒアリング・修正の繰り返し

見た目が完全にできていない状態で、確認観点を絞って、PM や、ディレクター、実際に業務で使う方々にチェックしてもらいフィードバックを受けます。徐々にブラッシュアップしていき、完成を目指します。

デザイン中には常に以下を意識して作業することで、無駄なものを介在させない設計を目指します。

コンポーネントを共通化できないか
色数を減らせないか
fontSize や lineheight などの定義を減らせないか

9.各種資料の作成

作っているデザインではエラー処理などすべてを表現しきれないので、補足資料として別途スプレッドシートなどにまとめていきます。

また、実際のコンポーネントと想定している props、実装時の注意事項などを記載した UI コンポーネント集ページを制作し、フロントエンドエンジニアと共有します。

Storybook での共有も検討しましたが、受け渡す props の想定、エンジニアへの指示、要件の補足を記載していくだけですので、Storybook ほどの機能は不要と考え、Next.js 内にシンプルな Page を作り、そこに記述する方法を選択しました。

また、デザインの設計ルールも資料化し、最終的には各種資料と、制作したコード、S3 にアップされている URL を成果物としてエンジニアに実装をしていってもらいデザインのフェーズを完了させます。

React でデザインした場合のメリット

忠実度の高いモックアップが制作できる

プロトタイプツールは数多くあれど、実装にまさる忠実度の高さなし。最近は Figma の AutoLayout や XD のスタックなど、便利な機能も登場してきていますし、プロトタイピングに関しても様々なアクションが設定できるので、非常に便利になってきました。ただ、それでも CSS や JS の表現力にはまだ届かない部分も多いかなと感じています。

ボタンを押したとき、特定の<select/>の<option/>が選択されたとき、複数条件下でのみ表示させるもの、ウインドウサイズが小さくなったときの表示など、デザインツールで実装するにはやや面倒な箇所も、コードベースなら対応可能で、デザインファイルと実装されたページでの印象差も起こりづらいです。

実際に操作できる環境を渡すことで高い精度のフィードバックをもらえる

様々なリテラシーのユーザーが使用するサービスであるからこそ、よりリアルなプロトタイプを使用し、ミスコミュニケーションを減らせました。

結果論ですが、新型コロナウィルスによって、コミュニケーションを取りにくい状況が続きましたが、挙動を忠実に再現しているので、精度の高い意見を聞けたのは良かったです。

プロダクト版のフロントエンドの実装時に、こちらの意図が伝わりやすい

fontSize や space、color を theme.js ファイルにまとめておき、そこからコンポーネント側では theme 側から読み込むようにしておけば、デザインルールが把握しやすくなります。また、CSS がすでに記述されているので、プロダクト版への移植も可能となり、「デザインファイルと実装でデザインが違う」が起こりにくくなります。

Git やエディタの恩恵をフルに受けられる

一旦別ブランチでデザイン案を作る、作ったブランチの commit から cherry-pick する、過去の log を見る、特定の commit に戻るなど、Git の恩恵をフルに受けられます。また、文字列の一括検索や置換が可能なので、色味を一気に置き換えたい、どこで使われているかを探したい場合などかなり重宝しました。

とはいえいいことばかりではなかった。。。

ちょっと要素の位置を変える、などはデザインファイルのほうが全然楽。コードベースだと CSS と HTML 構造自体を書き換えないといけない
React を理解していないと、動かなくなったりした時に、修正で時間を余計に使ってしまう
他のデザイナーに引き継ぎしずらい

など、通常のデザインファイルでは起こらないようなデメリットもありました。

結局の所プロジェクトによって向き不向きはあります。

個人的には社内の管理システム系のように、一般的なコンポーネントを組み合わせて、色々なデータを表示する必要があるサイト制作に向いているかなと思います。

逆に、特殊なコンポーネントを量産するケースや、LP のようにグラフィック要素が多くなってくるとデザインツールのほうがはかどります。

プロジェクトの性格に応じて最適なデザイン方法を選んでいきたいですね。

デザイナーだけどコードも書きたい方や、一緒にプルリク送ってくれるデザイナーの方いらっしゃれば、ぜひメドレーで一緒に働きましょう〜

「クラウド診療支援システム [CLINICS] | 受賞対象一覧 | Good Design Award」

メドレー知財担当がエンジニア・デザイナー向け社内勉強会で"特許"について発表しました

Fri, 22 May 2020 08:39:02 GMT

はじめに

こんにちは、メドレーのコーポレート本部法務コンプライアンス部で知的財産関連の業務を担当している鬼鞍です。コーポレート本部といっても、知財担当の仕事内容としてはエンジニア、デザイナーの方々としっかり協働することが一番大事なので、テックブログにも僭越ながら登場させていただきました。

先日、社内勉強会のテックランチにて、「特許」についてお話しする機会がありました。

今回の勉強会は、コロナウイルスの影響で全員オンライン参加という状況下でうまく伝えられるか心配だったのですが、予想以上に質問を頂いてそれなりに反響がありましたので、ここで紹介させていただこうと思います（厳密には特許権のことですがここでは説明の便宜上、以下特許と称することにします）。

みなさん、特許と聞いてどのようなイメージをもたれるでしょうか？

あなたが知財を仕事にしている人ではない限り、多くの方にとっては馴染みの薄い世界かもしれません。今回は、世間ではあまり表に出てこない特許という世界にスポットライトを当てつつ、少しでも特許の面白さみたいなものをお伝えできればと思います。

特許とは陣地に敷かれた地雷でもあり、身を守る鎧でもある

さて、秒で特許のイメージをつかんでいただくためにここでは極端な例えをします。

他人が取得した特許は陣地に置かれた地雷のようなものであり、この地雷を踏んでしまうと特許権侵害というリスクで怪我をしてしまいます。あまりいい例えではないかもしれませんが、これは特許が技術を独占的に実施し、他社が実施した場合には排他できるという側面を表現しています。

企業の知財部門は、地雷を踏まないように日々特許調査をし、地雷のない安全な道を探る、いわば道先案内人のようなものなのです。

また逆に、自分たちが取得した特許があれば、地雷を踏んで権利を主張されてもカウンターパンチを当てることができるので、身を守るための鎧にもなるわけです。

特許とはエンジニア、デザイナーの成果物である

ここで、特許について少し目線を変えて見てみましょう。

特許というものは、皆さんが努力・工夫した目に見えない技術的なアイディアが見える化された成果物である、という見方もできます。皆さんの頭の中にあるアイディアに知的財産権という形を与えることで、外部の人たちに明確に示すことができます。これによって、例えば投資家から高い評価を得たり、自分たちの技術力を PR するためのツールとして特許を用いることもできるのです。

特許権は国から与えられるグッドアイディア賞みたいなもの

特許については知らなくてもグッドデザイン賞についてはご存知の方が多いかもしれません。

メドレーのプロダクトであるクラウド診療システム「CLINICS」はグッドデザイン賞を受賞しています。

また、ISMS（情報セキュリティマネジメントシステム）についての認証も受けています。

「全社で本気になってリーンに ISMS の仕組みをつくった話」

なぜ、こんな話をしているかというと、グッドデザイン賞も ISMS も特許権も 1 つの共通点があるからです。それはいずれも客観的な審査を経て合格したものにだけ与えられてるものだという点です。

そして合格したものは、対外的に一定の信用を示すことができる、という機能を備えていいます。日本の特許庁の審査レベルは世界的に見ても高水準であると言われています。特許権というのは、その企業が技術的なアイディアに優れているという一定の信用を示すためのツールとしての性質も兼ね備えているのです。

特許に潜むリスク

先ほど特許は地雷であるという話をしました。より具体的に地雷を踏むとどんなリスクがあるのでしょうか？そのリスクは主に差し止め請求や損害賠償です。仮にこのような請求を受けてしまった場合は、大変な労力とコストが伴います。訴訟まで発展してしまうと、周囲の信用を失うことにもなりかねません。

このようなリスクを最小限にするために、知財担当の私が各プロダクトごとの開発定例に同席して自社の開発動向をキャッチアップし、他社権利の特許調査を行っています。

特許的な思考プロセスとは本質を考えること

さて、ここで「特許的な思考プロセス」を使って皆さんに少し頭の体操をしていただこうと思います。

知財関連ではよく例に取り上げられるのですが、鉛筆の発明を題材にして考えてみます。

あなたは断面が円形の鉛筆を使っていましたが、机の上を転がって下へ落ちてしまうという問題点に気がつきました。あなたは、鉛筆の断面形状に着目し、断面を五角形にすることにより、この問題を解決したとしましょう。そして、「断面が五角形の鉛筆」という内容を特許請求の範囲（特許権の権利範囲部分を決めるもの）に記載して特許権を得ることができたとします。

しかし、その後、あなたの断面五角形の鉛筆を見て他の業者が断面を三角形や四角形にした鉛筆を思いつき、それが市場に多く流通し、あなたの断面五角形の鉛筆の売り上げが下がってしまいました。あなたは特許請求の範囲に何と記載すべきだったのでしょうか？

そう、あなたは「断面が五角形の鉛筆」ではなく「断面が多角形の鉛筆」と書いていれば良かったのですね。

そうすれば、三角形や四角形などの類似品の流通を防ぐことができました。これは簡単です。

その後、あなたは断面が楕円形でも、机の上を転がりにくいという効果を生み出すことに気がつきます。では、多角形も楕円形も含めるためにはどのような表現がいいのでしょうか？ちょっと考えてみてください。

あくまで答えの一例ですが、「断面が非円形の鉛筆」とか、「断面がその中心からの距離である長軸と短軸とを有する鉛筆」などの表現であれば上記の全ての形状をカバーすることができます。

このように、いくつかの具体例から、効果を生み出すために必要最低限な要素は何なのか、共通点は何なのかを探し出すことが、アイディアの本質を捉えることになります。具体と抽象の間を行ったり来たりするプロセスです。

アイディアの本質を捉えるためには多くの具体例を出す発想力が必要です。

もしあなたが発想力豊かなエンジニアやデザイナーであれば強力な特許権が取得できるかもしれません。実際にプロダクトに生かされていない技術的なアイディアというのはあなたの頭の中に埋もれていることが多いものです。

エンジニアやデザイナーの成果が報われる土壌作りに貢献したい

知的財産権の生みの親はエンジニアやデザイナーの皆さんです。皆さんはあまり意識していないかもしれませんが、技術的なアイディアは日々の開発業務で生み出されていて、それが形になるものもあればならないものもあります。

メドレーでは、これまで検討された技術アイディアのうち、プロダクトとして実現化されたものや、そうでないものにかかわらず将来性を見込めそうなものについては、実際に特許出願をしてきました。

・ブロックチェーンを用いた電子処方箋の管理方法（特願 2018-078928）

・症状チェッカー（特願 2017-011444）

・患者統合基盤（特願 2019-233247）（出願中につき概念図を IR 資料より抜粋）

また、メドレーでは、エンジニア、デザイナーの方々の成果物がプロダクトだけでなく、知的財産としてもきちんと社内外で認められ、それが名誉となるような土壌作りをしていこうと考えています。

さいごに

メドレーは、テクノロジーを使って医療分野のデジタル化を推進し、医療ヘルスケアの未来をつくる会社です。そんなメドレーで生み出される素晴らしい技術やデザインを知的財産という分野で可能な限りバックアップしてきたいと思っています。少しでも特許の世界を感じて頂ければ幸いです。最後までお付き合い頂きありがとうございました！

Kotlin/Native を検証してみた

Fri, 08 May 2020 09:02:03 GMT

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。

インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。

Kotlin/Native - Kotlin Programming Language

さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。

Kotlin/Native について

Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。

現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。

仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。

サポートしているプラットフォームは下記のとおりです。

iOS (arm32, arm64, simulator x86_64)
macOS (x86_64)
watchOS (arm32, arm64, x86)
tvOS (arm64, x86_64)
Android (arm32, arm64, x86, x86_64)
Windows (mingw x86_64, x86)
Linux (x86_64, arm32, arm64, MIPS, MIPS little endian)
WebAssembly (wasm32)

コードの共通化について

Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。

作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。

Kotlin Playground: Edit, Run, Share Kotlin Code Online

通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。

commonMain の中に「expect」というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で「actual」というキーワードを使用してその内容を記述します。

// commonMain
expect fun platformName(): String

// androidMain
actual fun platformName(): String {
    return "Android"
}

// iOSMain
actual fun platformName(): String {
    return UIDevice.currentDevice.systemName() + " " + UIDevice.currentDevice.systemVersion
}

このチュートリアルには記載ありませんが、「expect」というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。

Platform-Specific Declarations - Kotlin Programming Language

また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。

こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。

Kotlin/Native の制約について

JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。

具体的にアプリを作成する際には下記の点に注意が必要でした。

Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する
iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある

Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが提供されておりそれらを利用することで問題を解決しました。

現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。

「suspend」関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある)
Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」や「swift_name」を参照する必要がある)
「companion object」や「object」などシングルトンの宣言に対してオブジェクトをフリーズするか「ThreadLocal / SharedImmutable」のアノテーションを付与する必要がある

こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。詳しくは下記の資料を参照ください。

Kotlin/Native as an Apple Framework - Kotlin Programming Language

kotlin-native/IMMUTABILITY.md

Kotlin/Native の利用例

まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。

まとめ

弊社では「CLINICS」というオンライン診察を行うことができるアプリをリリースしています。

CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。

まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

社内勉強会 TechLunch でジョブメドレーでの CircleCI の活用と改善について発表しました

Thu, 30 Apr 2020 10:39:50 GMT

こんにちは、メドレープロダクト開発室エンジニアの岸田です。

先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。

ジョブメドレーの開発で CircleCI をどのように利用しているか

ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。

ユニットテスト・構文チェック
デプロイ

デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。

そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。

3 つの Workflow を大まかに説明させていただきます。

ユニットテスト・構文チェック

ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。

この Workflow は 3 つのジョブで構成されています。

ライブラリのインストール
- bundle install・ yarn installなどを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています
RSpec の実行
- 2 コンテナを利用しての並列実行を行なっています
構文チェックと Jest の実行
- RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています

この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。

EC2 へのデプロイ

この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。デプロイには Ruby gem の Capistrano を利用しています。

下記のような 2 つのジョブで構成しています。

ライブラリのインストール
- 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です
ビルドとデプロイ
- Rails の assets:precompile やyarn buildなどの処理と、Capistrano を用いたデプロイを行なっています

この Workflow は特定のブランチでしか実行されないようになっています。

ECS へのデプロイ

この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。

ジョブは下記のように 4 つで構成されています。

npm package のインストール
フロントエンドのビルド
Gem のインストールと Rails の assets:precompile
Docker image の作成と Push

こちらの Workflow も特定のブランチでしか実行されないようになっています。

抱えていた課題と assets:precompile

ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。

特に時間がかかっていたのが、下記の 3 つでした。

「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ
「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ
「RSpec の実行」ジョブ
- RSpec の書き方などを改善することで短縮できるため、割愛させていただきます

これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。この点について原因と行なった改善を説明をさせていただこうと思います。

assets:precompile に時間がかかる

ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。これを実行する際に assets:precompile コマンドを利用しています。また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。

このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。

毎回 1 からコンパイルを行なっていた
コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する

毎回 1 からコンパイルを行なっていた

こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。こちらの解決策としては、CircleCI の公式ドキュメントでも例が載せられていますが、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（public/assets）を CircleCI でキャッシュさせることで対応しました。キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。

コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する

こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。

まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。

（1 ファイルもアップロードしていないが 6 分 20 秒かかっている）

そこで、asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。

数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。

この問題の解決策は下記の 2 つが考え得ると考えました。

不要なファイルを S3 バケットから削除する
前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする

1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。

asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。

2 つ目の方法はassets:precompileコマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。

manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（public/assets/）に同じように出力され、また、上記でpublic/assetsを CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。

assets:precompileの実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。この処理はasset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。

ただし検証が不十分なため、実運用に乗せることはまだできていません。

CircleCI のジョブ実行時間を短縮する小さな改善事項

上述の通り、各 Workflow で大きく時間を費やしているのはassets:precompileと RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。

コードのチェックアウト

CircleCI では組み込みのコマンドとして checkout コマンドがあります。これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。

そこでまずは、.gitディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。すると、checkoutコマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。

別の方法としてcheckoutコマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。

Docker image の作成

ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、docker buildコマンドの実行時間も可能な限り抑えたいと考えています。

短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。

詳しくは Docker のガイドに記載の通りではありますが、DOCKER_BUILDKIT=1 を指定してdocker buildを実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。

まとめ

今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。

ご覧いただきありがとうございました。

社内勉強会 TechLunch で CLINICS を取りまく監視ツール群について発表しました

Fri, 10 Apr 2020 10:29:19 GMT

皆様こんにちは。プロダクト開発室エンジニアの濱中です。

新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、コロナウイルス関連の特集が組まれていますのでぜひご覧ください。

さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。

CLINICS の概要と、サービスにおける監視の立ち位置について

公式ページで「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。

このうち、電子カルテシステムは、「日医標準レセプトソフト ORCA」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。

当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。

電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。

そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。

監視ツールあれこれ

ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。

Sentry

Application Performance Monitoring & Error Tracking Software

Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. Get started at sentry.io.

sentry.io

弊社の他プロダクト（「ジョブメドレー」、「介護のほんね」）でも利用している監視ツールです。

基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。

CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。

Mackerel

Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム

Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。

mackerel.io

GUI で簡単に監視設定が可能なサービスです。

前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。

現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。

AWS CloudWatch & Lambda

APM Tool - Amazon CloudWatch - AWS

Amazon CloudWatch は、DevOps エンジニア、デベロッパー、サイト信頼性エンジニア (SRE)、IT マネージャー、および製品所有者のために構築されたモニタリングサービスです。

aws.amazon.com

サーバーレス関数、FaaS サーバーレス — AWS Lambda — AWS

AWS Lambda は、サーバーのプロビジョンや管理をすることなくコードを実行するためのサーバーレスコンピューティングサービスです。料金は、コンピューティングに使用した時間に対してのみ発生します。

aws.amazon.com

どちらも AWS の提供するツールです。

CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。

Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。

Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。

それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。

対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。

CLINICS では、上記アラート通知のほか、SessionManager経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。

New Relic

思考するオブザーバビリティ

New Relic、New Relicオブザーバビリティ、New Relicソフトウェアオブザーバビリティ、New Relicオブザーバビリティプラットフォーム

newrelic.co.jp

New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。

メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。

医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。

このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。

Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。

Firebase Crashlytics

Firebase | Google's Mobile and Web App Development Platform

Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。

firebase.google.com

Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。

CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。

Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。

その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。

PagerDuty による監視集約

PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社

PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。

ja.pagerduty.com

CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。

導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。

また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。

まとめ

CLINICS で利用している監視ツール+α を紹介させていただきました。

これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。

ご覧いただきありがとうございました。

2020 年、プロダクト開発合宿に行ってきました！＠伊東

Fri, 27 Mar 2020 09:46:23 GMT

こんにちは、インキュベーション本部の加藤です。 2019 年に新卒でメドレーに入社し、間もなく 1 年が経とうとしています。

少し時間が経ってしまったのですが、今回は 1 月に行われたプロダクト開発合宿の様子をお届けします。

プロダクト開発合宿の目的

メドレーでは「1 年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。

合宿の恒例行事となっている「1 年間のプロダクト開発の指針」を CTO 平山がプレゼンし、全員で共有する大切な機会です。また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。

アクティビティの紹介

そば打ち体験

今年の合宿のアクティビティは、そば打ち体験でした。「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。

今回お世話になった観音亭さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。

石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。

生地が薄くなりすぎると破れてしまうことも…！

伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。

自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。

城ヶ崎海岸を散策

そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。

バーベキュー

夕方には宿泊先に到着し、バーベキューを開始！お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。

2020 年キックオフ！

バーベキューの後は CTO 平山から 2020 年に向けてのキックオフです。

まず、2019 年の振り返りから。

昨年はメドレーにとってもプロダクトにとっても大きな変化のある 1 年でした。

会社としては創業 10 周年を迎え、東証マザーズへ上場を果たしました。ジョブメドレーの大幅なデザインリニューアルや CLINICS のグッドデザイン・ベスト 100 の受賞など様々なことがあった 1 年でした。

続いて 2020 年について。詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTO からのメッセージを全員で確認する良い機会となりました。

普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。

まとめ

今回はメドレーのプロダクト開発合宿の様子をお届けしました。

私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。また、これからの 1 年について考える時間ともなり、2020 年、より良い 1 年にしていきたいです。

最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました！

2019 年度新卒エンジニア研修について

Mon, 16 Dec 2019 07:59:47 GMT

こんにちは。エンジニアの平木です。

メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。

現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。

2019 年度新卒入社メンバー

新卒研修を決めるまでやったこと

研修の大枠決定

カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。

決めたことは、以下３点です。

入社後の導入部分
- 社会人としてのビジネスマナーや考え方の基礎を学ぶ
- プロダクト開発をする上で必要になる基礎を学ぶ
- 会社の事業内容を理解する
OJT をメインとした各チームへの仮配属
新卒社員へのフォローアップ
- メンターや部長との定期報告会
- 半年後に役員陣への成果報告会

エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。

こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。

toppa.medley.jp

情報収集

社内エンジニアへのヒアリング

前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。

ヒアリングしたポイントは

研修の期間
研修全体の流れ
各研修メニューの内容
OJT はどういった形で受けたか
研修を受けての感想

など。各社・各年代で個性が出るなという印象を持ちました。

やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。

ネットでの情報収集

ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。

しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。

そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。

研修資料まとめ.md

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

研修メニュー決定

研修の詳細メニュー

ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。

結果として、以下のメニュー構成でいくことになりました。

オリエンテーション
- **[座学]**社会人研修や会社全般の知識の習得を目的にする
開発基礎研修
- **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする
開発実践研修
- **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする
開発部 OJT
- **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする
事業部 OJT
- **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする

特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。

メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。

新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験してもらうために、この事業部 OJT をメニューに組み込みました。

研修期間

研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。

オリエンテーション・開発基礎研修・開発実践研修
- 2 ヶ月
- 期間中、午前：開発基礎、午後：開発実践
開発部 OJT ・事業部 OJT
- 4 ヶ月
- 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施

メンター

研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。

最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。

メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。

研修メニュー内容

各研修内容のご紹介です。

オリエンテーション

オリエンテーションは

外部ビジネス研修
コンプライアンス研修
セキュリティ研修
開発環境の整備
開発ツールの解説

がメインです。

Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。

オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらうことができました。

開発基礎研修

大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。

もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。

メドレーについて

こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。

その後は、ジョブメドレー・CLINICS・介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。

メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。

この段階でまずこうしたメドレーでエンジニアとして働くとはどういうことなのかという知識や考え方を新卒メンバーに勉強してもらいました。エンジニアとは何かエンジニアの価値は何かプロエンジニアとは何かエンジニアではない職種との違いは何かといった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるかメドレーのエンジニアとして求めたいことは何かといった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。

導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。

輪読会

座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのはドワンゴさんの 2016 年の研修の記事です。

輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。

「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。

議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすることを狙いとしています。

最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。

対して「Go ならわかるシステムプログラミング」については新卒メンバーに章を割り当てて、各自講師をしてもらいました。

元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、他人へ伝える力を養うことをサブ目標にしています。

さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。

開発実践

開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。

実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。

題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますがブログに書いてました)。

メドレーでの業務開発と同じ形式で

ユーザーからの要望をヒアリング
要件定義
開発計画の策定
システム設計
チームで分担してながらの開発
ベータ版としてリリースしたものをブラッシュアップ
実稼働するための環境整備をしながらリリースする

という一連のプロセスで開発しました。

「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。

新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。

チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。

途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという開発のリアルを経験できたのは次の OJT に活きたと思います。

余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり基本は大事だな、と思った次第です。

開発部 OJT

基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。

ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。

メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。

事業部 OJT

開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。

**どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。

研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。（ありがとうございます！）

実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。

この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。

レポート発表

それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。

ひたすら研修内容をこなしていくという形になりがちなので、振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したいという目的です。

また、メドレーではドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。

レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。

最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的です。

最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。

まとめ

メドレーで初の新卒研修は以上のような形で終わることができました。

かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。

来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。

長々とお付き合いいただきありがとうございました。

社内勉強会 TechLunch で Badging API について発表しました

Tue, 27 Aug 2019 08:42:56 GMT

みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。

Badging API とは

Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。

ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。

この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリを用意しているので、そこで確認することができます。

WICG（The Web Incubator Community Group）は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。

提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。

badging/explainer.md at main · w3c/badging

Badging API. Contribute to w3c/badging development by creating an account on GitHub.

Badgeをwindowオブジェクトのメンバとして持つ
Badgeには 2 つのメソッドが存在する
- Badge.set()
- Badge.clear()
Badge.set(5)のようにset()に整数を渡してバッジ上に数字を表示する
単にBadge.set()で呼び出すとフラグとしてバッジを表示する
Badge.set(5, { scope: ‘/baz’ })のようにオプションを渡して特定のスコープ配下で表示されるように指定できる
- オプションでスコープが指定されてない場合、スコープは/になる

ローカル環境で試す

実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境（macOS 10.14、Chrome76）で試してみました。

API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。

インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。

最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする（#enable-experimental-web-platform-features）かのいずれかを行う必要があります。

今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。

実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、window.Badgeとして利用可能になっているのではなく、Origin Trials の段階ではBadgeではなくExperimentalBadgeとして提供されています。

次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。

$ yarn init

$ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin

webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。

const path = require("path");

const HtmlWwebpackPlugin = require("html-webpack-plugin");

module.exports = {
  mode: "development",

  devServer: {
    https: true,
  },

  entry: {
    app: ["./src/js/app.js"],
  },

  output: {
    path: path.resolve(__dirname, "./dist"),
  },

  plugins: [
    new HtmlWwebpackPlugin({
      template: "src/index.html",
    }),
  ],
};

次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。

https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。

{

  "name": "badging-api-playground",

  "short_name": "badge",

  "theme_color": "#5B5CFD",

  "background_color": "#5B5CFD",

  "display": "standalone",

  "orientation": "portrait",

  "prefer_related_applications": false,

  "Scope": "/",

  "start_url": "/",

  "icons": [

    {

      "src": "images/icons/icon-72x72.png",

      "sizes": "72x72",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-96x96.png",

      "sizes": "96x96",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-128x128.png",

      "sizes": "128x128",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-144x144.png",

      "sizes": "144x144",

      "type": "image/png"

    },

    ….

  ],

  "splash_pages": null

}

webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。

const path = require('path')

const HtmlWwebpackPlugin = require('html-webpack-plugin')

+ const CopyPlugin = require('copy-webpack-plugin')



module.exports = {

  ….

  plugins: [

    ….

+     new CopyPlugin([

+       {

+         from: 'src/manifest.json',

+         to: '',

+       },

+       {

+         from: 'src/images/icons',

+         to: 'images/icons/'

+       },

+     ]),

  ],

}

ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。

アプリをインストール可能な状態にするにはいくつかの基準があり、service worker が必要になります。今回はWorkbox の webpack プラグインで対応します。

yarn add --dev workbox-webpack-plugin

workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。

const path = require('path')

const HtmlWwebpackPlugin = require('html-webpack-plugin')

const CopyPlugin = require('copy-webpack-plugin')

+ const { InjectManifest } = require('workbox-webpack-plugin')



module.exports = {

  ….

  plugins: [

    ….

+     new InjectManifest({



+       swSrc: path.resolve(__dirname, 'src/sw.js'),

+     }),

  ],

}

app.js の方で service worker の登録がされるように記述しておきます。

if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("./sw.js")
      .then((res) => {
        console.log(res);
      })
      .catch((err) => {
        console.error(err);
      });
  });
}

service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。

インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。

window.ExperimentalBadge.set()を呼び出すと、フラグとしてバッジがつきます。

window.ExperimentalBadge.set(1)のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。

window.ExperimentalBadge.clear()でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。

非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。

なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。

まとめ

近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。

API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。

最終的にどのように課題が解決されていくか注目したいと思います。

Google Cloud Next '19 in Tokyo にて、App Maker の活用事例を紹介しました

Mon, 26 Aug 2019 05:24:57 GMT

はじめに

こんにちは、コーポレートエンジニアの若林です。

普段はいわゆる社内 SE 的な領域を担当していますが、その名の通りエンジニアの視点も持ったコーポレート機能という立ち位置で、社員の働く基盤や事業の発展を支えています。過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。

今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。

今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒントについて、セッションでお伝えした内容を含めたレポートを書きたいと思います。

Google Cloud Next ‘19 in Tokyo について

Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催）

日程；7/30(火) - 8/1(木)
会場：東京プリンスホテルおよびザ・プリンスパークタワー東京
イベントサイト：Google Cloud Next ‘19 in Tokyo

メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。

なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・

会場の雰囲気

東京タワーとの一枚

登壇の様子（背景と同色なのは偶然です）

セッション内容について

Google Apps Script / AppMaker 最新アップデートと活用のヒント

今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。

まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。

それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。

App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。

しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。

ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。

Google App Maker とは

一言で言うと…

G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール

です！

主に以下のような特徴があります。

バックエンドのデータストアとして、RDB（Cloud SQL）が利用される
開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である
G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である
UI のカスタマイズの容易さと高い自由度がある

メドレーでの社内活用事例

メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。

今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方はセッション動画をご覧下さい）

App Maker を使ったアプリケーション開発の流れと開発 Tips

App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。

データモデルの定義
UI 作成
ビジネスロジック記述

1. データモデルの定義

はじめに、GUI ベースで RDB のメタデータを定義していきます。

モデル（テーブル）の主な設定項目

FIELDS：モデルのフィールド情報を定義
DATASOURCES：データベースでいうところのビューに近い概念の設定
RELATIONS：モデル間のリレーションを定義
EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義
SECURITY：モデルに対する権限を制御

データモデルの定義における開発 Tips

EVENTS の挙動：MODEL の設定項目なので一見データベーストリガーと思いがちですが、このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。（クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。
データベースへの更新反映タイミング：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。
細かな権限制御：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。

2. UI 作成

次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。

一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更にはリッチなポップアップ、ダイアログ等も利用可能です。

スタイルに関しては、バリアントを利用することで、統一感のあるスタイル適用が容易に可能になっています

UI 作成における開発 Tips

組み込みのマテリアルデザインアイコン：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（文字列とアイコンの対応表）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。

3. ビジネスロジック記述

最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要）

Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。

google.script.run.ServerSideFunction();

ビジネスロジック記述における開発 Tips

外部公開できない：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します）
ローカルの開発環境と上手く連携できない：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。
定期実行トリガーを GUI で設定できない：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。

ScriptApp.newTrigger("functionName").timeBased().at(date);

App Maker をこれから始める人向けの情報

なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。

知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。

アプリ作成の一連の流れを掴む

実際に触ってみる

情報共有プラットフォームを活用する

まとめ

今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。

App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。

なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています）

GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。

最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。

メンバーのストーリー家族や友人が病気になった時に救いの手を差しのべる医療の力。...

メンバーのストーリー | 株式会社メドレー