ローコードツールから Playwright 移行への道 2025

エンジニアリンググループ GM 兼 QA チームリーダーの窪田です。 本日はマネジメントチームブログリレー4日目として、現在取り組んでいる自動テストを Playwright で構築するチャレンジについてお話しします。

アクセント学: "エムスリー"のアクセントは-3型なのか平板型なのかの謎に迫る

こんにちは、CTOの大垣です。 このブログはマネジメントチームブログリレー 3日目の記事です。前回は岩佐さんの、リモートワークを自作ルーター(OpenWrt)で支える でした。リモートワークで必要な3種の神器、キーボード・机・ルーターは自作するの楽しそうですよね(?)

さて、今日のテーマは打って変わって、"アクセント"です。 普段皆さんが何度も口に出していてほしい"エムスリー"という名前、皆さんどういうアクセントで呼んでますか？エムスリー？そうですよね！

さて、今回はCTOとして、"エムスリー"はどういうアクセントで読むのが正しいのか、について技術的に決着をつけに来ました。 今回のブログを読んで、エムスリーをエムスリーって読むんだよと言う話で盛り上がり、エムスリーの名前が医療従事者とエムスリー社員以外にも広くたくさん呼ばれるようになると嬉しいです。

※とは言ってもこのアクセントが今後もエムスリーの公式見解になるかは特に決まってないのであしからず。あくまでも私の意見です。 また、筆者は機械学習エンジニアであり、音声合成のためにアクセント学をかじった程度の知識なので、調査内容に誤りがあったらすみません。

リモートワークを自作ルーター(OpenWrt)で支える

週末に訪れたゴルフコース

はじめに

M3の岩佐(@bloody_snow)です。 最近は M3 Technologies にてM3グループ各社のエンジニアリング支援をメインで担当しています。エムスリーキャリア株式会社と株式会社イーウェルで取締役を勤めていますので、興味のある方はこれらの会社もよろしくお願いいたします。

M3ではリモートワークをメインとしているため、ネットワークの品質が業務効率に直結します。長らく市販のルーターを用いていたのですが、同時接続台数が増えるとパケットロスや通信速度低下が発生するなど、安定性に課題を感じていました。 もちろん最新のハイエンド家庭用ルーターに買い替えれば手っ取り早く解決します。ただ、せっかくなのでこの機会にそこそこの性能を持つシングルボードコンピュータをルーター化し、Wi-Fi は専用の Wi-Fi 7 アクセスポイントに任せる構成にチャレンジしてみました。 当時の光回線は1ギガ契約だったため、LAN 構成も 1GbE 前提で設計しています。現在は光回線の契約を10ギガに切り替え、LAN構成も 10GbE 化へ向けて順次機器を入れ替え中なので、そのあたりのアップグレードについても今後触れていく予定です。

今週11/21（金）にpmconf 2025 大阪に登壇します！という話など。

皆さんこんにちは、こんばんは。今年も冬キャンプにベストなシーズンになってウキウキしている取締役CPO/CAIOの山崎です。 最近お気に入りのキャンプギアはSoomloomのIGTハーフ対応の焚き火台と、同じくSoomloomの円形のアイロンストーブです。 ということで、本日はマネジメントチームブログリレー1日目の記事を担当することになりました。

11月でもタープ泊のストロングスタイル。シュラフはEnlightened Equipmentの30F対応キルト。むしろ暑すぎました。

アドホック分析を「資産」に変えるアプローチ

エムスリーUnit9でプロダクトマネージャーをしている北島です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー6日目の記事です。

私が所属するUnit9では、データプロダクトの提供やデータの社内活用を行い、データを通じた価値創出をすることをミッションとしています。そのため、日々多くの分析依頼を受けています。

アドホックな分析依頼は、その場限りの対応になりがちではないでしょうか。急ぎの案件が多かったり、依頼ごとに要望される分析ロジックが違うことなどが理由として挙げられます。ただ、単発での対応を続けると、依頼の増加とともにに担当者が対応に追われてしまう、過去分析の要件が不明で再現に時間がかかる、といった課題が発生してしまいます。

私たちのチームも過去に同じ課題に直面しました 。そこで現在、「アドホック分析を資産に変え、それを土台として分析のセルフサービス化を推進する」取り組みを始めています。結果として分析者の生産性を底上げし、より本質的な価値創出に向き合えるようになっています。本記事ではこの取り組みについてご紹介します。

Oracleのクエリ実行履歴を網羅的に収集するための実践的アプローチ

エムスリーエンジニアリンググループ、データ基盤チームの石塚です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー5日目の記事です。前回は三浦さんの 「SQL課題：月の集合を連続した期間の集合にまとめてください」でした。

エムスリーが提供するサービスの中には、今も一部でオンプレミス環境のOracleを活用しているシステムがあります。私たちは、これらのシステムについてもコスト効率やメンテナンス性をさらに向上させるため、Oracleへの依存を段階的に減らしていくプロジェクトを進めています。

このプロジェクトを推進する上で、「そもそも、どのシステムがどれくらいOracleを参照しているのか？」という実態の正確な把握が大きな課題となりました。特に、SQLを解析してどのテーブルに、誰が、いつアクセスしたかを観測し、Oracleへの依存度を正確に測定する必要がありました。プロジェクトの進捗を可視化したり、各担当チームに具体的なデータをもって協力をお願いしたりするためにも、この参照記録は不可欠な情報でした。

そこで私たちは、Oracle上で実行された参照クエリを詳細に記録し、分析するための仕組みを構築することにしました。

ところが、いざ進めてみると「昨日実行したはずのクエリがない！？」という思わぬ壁にぶつかります。本記事では、その原因だったv$sqlareaの揮発性の仕様と、私たちがどのようにしてその課題と向き合い、v$sqlstatsなどを組み合わせてクエリの収集率を向上させていったか、その試行錯誤の道のりをご紹介します。

SQL課題：月の集合を連続した期間の集合にまとめてください

データ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー 4日目は、SQLプログラミングのお話をお届けします。Unit9エンジニアの三浦[記事一覧 ]です。昨日は木田さんの『巨大テーブルにインデックスを追加したい、Flywayで』でした。

今回の課題はタイトル通り、月の集合（たとえば、ユーザーがアクティブであった月の集合）から「何年何月から何年何月まで連続していた（アクティブだった）」という期間の集合に変換せよというものです。連続した期間ってのがまとまっていると判定で便利な局面があるんですよね。具体的にどう役に立つかは後述しますが、大変に実用を意識したデータ基盤プログラミング課題であります。

さて私自身がややこしいコードの書かれた記事を見るとコード部分を読み流してしまいがちなので偉そうなことが言えないのですが、やはりプログラミング課題の解説はコードを精読してこそです！　もし今精読する時間が取れないということでしたら、「後で読む」ブックマークしていただけるのももちろん嬉しいのですが紙にプリントアウトする方をよりおすすめしておきます。