ja.mackerel.io 2025-09-02 オブザーバビリティプラットフォームの 企画からリリースまで ──PO・TLから見るMackerelの裏側 TECH DRIVERS Day1「UX設計とアプリ開発」 株式会社はてな Mackerel開発チーム サブディレクター・テックリード 朝倉 一希 (id:arthur-1) 

自己紹介 朝倉 一希 ASAKURA Kazuki 株式会社はてな Mackerel開発チーム サブディレクター・テックリード オブザーバビリティ関連機能の開発を担当 ポケモンカードが得意です id:arthur-1 @Arthur1__ @Arthur1 2 

Mackerel: 監視・オブザーバビリティSaaS 3 https://ja.mackerel.io/ 

ラベル付きメトリック機能のリリース 4 

APM機能のリリース 5 

2つの立場でMackerelに関わっています as プロダクトオーナー（PO） 事業計画からプロダクトの方向性を精緻化し、取り組む課題 の優先順位付けをする as テックリード（TL） POとして実現したいプロダクトの技術面を支える 現在だと、企画した機能が高速に開発・リリースされること に注力している 6 

今日の話題 PO・TLという2つの立場から、Mackerelの企画→開発→ リリース→検証の一連の流れと、そこで行っている工夫に ついて説明します ＞ ドメインや提供形態ならではの話を！ 様々な職種・業種の方に聞いていただくことを想定し、薄 く広く触れるつもりです ＞ 詳しく聞きたい方はぜひ質疑応答パートで 7 

仮説検証型アジャイル開発 8 検証 評価 検証 計画 仮説 立案 MVP 特定 スプリント レトロスペク ティブ スプリント プラン ニング MVP 検証 開発 計画 スプリント レビュー スプリント 開発 価値探索 アジャイル 開発 選択の幅 市谷聡啓. 正しいものを正しくつくる: プロダクトをつくるとはどういうことなのか、あるいはア ジャイルのその先について. ビー・エヌ・エヌ. 

① 企画 9 

開発サイクルに比重 ● APMにおいてMackerelは後発（相対的に機能がまだ出 揃っていないフェーズ） ● 生成AIエージェント利用によって、定型的な開発のス ピードが上がっている 現時点では企画する方がボトルネックになるので、価値探 索ループは薄めにどんどん作り始めていく 重い探索イテレーションに拘らず、直感も信じる 10 

一度リリースした機能はやめづらい あるユーザーの課題を解決できる機能を素早く企画して作っ た結果、将来足枷になるかもしれない とはいえ、ユーザーのシステム運用と紐づいたサービスなの で、足枷になったからと廃止するのは難しい 提供しようとする機能が、多くのユーザーの課題を解決でき ているか、将来拡張できる余地を残しているかを考える 11 

MVPを特定してPBIに 価値が出る小さな単位に分割し てProduct Backlog Item（PBI） として起票 やらなくて良いことを明記して いるのがポイント 守りたいところと諦めても良いと ころをハッキリさせて、期待する 速度・品質でモノができるように 12 

dogfooding 自分たちのシステムの監視を、自分たちで作ってい るMackerelで行っている 開発・運用者でありながら、利用者でもある目線で 改善のアイデアが出せる Mackerelチームだけでなくはてなの各開発チームで も使ってもらい、フィードバックを集めている 13 

ユーザーからのヒアリング ユーザーとの商談やフォローミーティング時に、エン ジニアやデザイナーも同席してヒアリングすることも 「何が欲しいか」ではなく「どんな課題を解決したい のか」を聞く 遠回りせずにベストな解決策を提示したい 14 

標準規格の変化を追っていく オブザーバビリティデータの生成・投稿の標準化を目指し たOpenTelemetryというフレームワーク・ツールキット がある 最近のMackerelの機能はOpenTelemetryに準拠しており、自 分たちで仕様決めを担う範囲を減らしている OpenTelemetryの仕様やツール群の変化を定期的にキャッ チアップする場を作り、機能開発の参考にしている 15 

② 開発 16 

デザイン PBIを起票する段階で、POがイメージの絵を描く これをもとにデザイナーがFigmaに起こす 17 

デザインの難しさ(1) ● 技術的な制約から、ユーザインタフェースとしてベストなデザイ ンや仕様にできないこともある 例）大量のデータをクエリするのに計算コストがかかるため、短 時間に多数回の読み込みが可能なUIでは提供しづらい →現時点では一定の妥協で提供しつつ、将来技術で解決を見込む ● B2Bのエンジニア向け業務ツールなので、デザイナーにとってドメ イン知識のキャッチアップが難しい →より知識のあるPO・エンジニアと厚めに会話して解決 18 

デザインの難しさ(2) ● より良くするためだとしても、破壊的なリニューアルはしづらい ユーザーのシステム運用と紐づいたサービスなので、急に変わる と運用に支障が出てしまう可能性がある →事前にユーザーに告知する、段階的にリリースするなど、影響 を減らす取り組みをしている 19 

フロントエンド開発 Mackerelチームではデザイ ナーがReactのコードを書く 機会も多い よく使うUIパーツはデザイン コンポーネントとして用意し ている StorybookからReactのコー ドを出力できる 20 

フロントエンドプレビュー環境 とはいえ、デザイナーがローカルでWebサーバを立てて動作確認す るのは難しい Pull Requestを開くと自動でプレビュー環境が立ち上がるように 21 

サーバーサイドとフロントエンドのやりとり Mackerel APMの開発ではGraphQLを利用している スキーマを決めたら、サーバサイドとフロントエンドを並行 して開発でき、リソース効率が良い TypeScriptで型がついたclientが利用できるのも嬉しい 22 

Mackerelのシステムの特徴 write-heavyであること ● 毎秒・毎分いろんなサーバからテレメトリーが送られてくる ● 直近のデータはすぐ増えて結果が変わるのでキャッシュしづらい ある程度古いデータは不変であること ● テレメトリーは時系列データで、後から古い値を変える要求がない ● 古いデータの集計はキャッシュできる 23 

大量のデータを素早く検索・集計するために 大量のテレメトリーデータを素早く・かつスケールして検索・集計 できるように工夫している： ● オンライン分析処理に特化したデータベースを利用する ● パーテーションを利用して、古いデータの削除を効率的に行う ● 投稿から時間が経ったテレメトリーデータは事前集計し、カー ディナリティを圧縮して保持しておく ○ これ以上要素が増えることがない それでもまだまだ技術的には伸びしろあり 24 

③ リリース 25 

デプロイ頻度 監視サービスなので、ユーザーが求める可用性も高い 一方で、多くのコンポーネントで毎日1回デプロイ 昔は金曜日のデプロイは避けていたが、やめた →可用性を担保したまま、開発物の価値をより速く届ける ● Binary Pushが原因の障害が一般と比較して少ない ● 監視やロールバック手順の整備が行われている 26 

デプロイフロー デプロイ頻度が高まったのはフローが簡便になったことが理由 アプリケーションサーバはAmazon ECSで動いている GitHub Actionsとecspressoを組み合わせた、Issueのクローズ やPull Requestのマージだけでデプロイが行える仕組みがある 27 

スプリントレビュー 実際に出来上がった動くものを触って、ユーザーにリリー スできる状態か確認する レビュー時にはフィーチャーフラグを使って社内向けだ けに新機能を公開 リリース可能とPOが判断したら、フラグを変えて全体に 公開 28 

フィーチャーフラグの効能 リリースしたものをとりやめたい時に、影響範囲を絞るこ とができる コンテナイメージを前のrevisionに差し替えるロールバックをす ると、同時にデプロイした他の機能も戻ってしまう 巨大で長命なFeature Branchを回避する（トランクベー ス開発） 大きなPRはコンフリクトしやすくrevertも大変 29 

スプリントレビューとAIエージェント レビューで使い勝手について指摘すると、会議の裏でエンジ ニアがAIエージェントに指示を出している 会議が終わるころには修正のPull Requestができている これにより、素早くリリース可能な状態へと持って行けるよ うになった 30 

④ 検証 31 

インタラクティブ要素の操作数を可視化 ユーザーの行動を計測し、追加した機能がユーザーにどれだ け使われているかを検証できるようにしている ある属性をインタラクティブ要素に付与すると、Google Analyticsのカスタムイベントが送信されるような仕組み 開く 32 

データ基盤 他にも、様々な利用状況をデータ基盤（BigQuery）に集約 し、分析できる状態にしている ETLツール： Embulk / Airbyte 可視化ツール： Looker Studio / Google Spread Sheet 33 

ユーザーからの声を集める セールスやCREを経由して、あるいはMackerelが主催・協賛 するイベントを通じて、リリース物に対するユーザーの反応 を集めている Mackerelは国産サービスであることから、開発者に声を届 けやすいことを特長としている 34 

まとめ 35 

まとめ Mackerelの開発を取り上げ、企画→開発→リリース→検証の一 連のフローにおいて、ドメインやシステムの特性を生かして取 り組んでいる様子をご紹介しました また、プロダクトに携わるエンジニアのキャリアとしてプロダ クトと技術のマネジメントを両立する道もあるんだということ も伝われば幸いです 36 

参考資料 ● [Mackerel APM] アプリケーションの中身が見える！Mackerel APMの全貌と展望 / Mackerel APMリリースパーティ https://speakerdeck.com/mackerelio/mackerel-apm-release-party ● [仮説検証サイクル] 仮説検証サイクルでユーザーの声を 高速に叶える「キカク組」の取り組み / Mackerel Drink Up #11 https://speakerdeck.com/arthur1/mackerel-drink-up-number-11-arthur-1 ● [デプロイフロー] はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025 https://speakerdeck.com/cohalz/fujiwara-tech-conference-2025 ● [フィーチャーフラグ] AWS AppConfigとOpenFeatureで手早く機能フラグを導入する[LT size] / CloudNative Days Winter 2024 船上LT会 https://speakerdeck.com/arthur1/cloud-native-days-winter-2024-lt ● [フィーチャーフラグ] Scalaから始めるOpenFeature入門 / Scalaわいわい勉強会 #4 https://speakerdeck.com/arthur1/scala-waiwai-openfeature 37 

ご清聴いただき ありがとうございました 38