なぜ「痒いところに手が届く」のか？ - エンジニアに10年選ばれ続けるMackerelの"らしさ"を探る【前編】

はてなが開発・運用するオブザーバビリティプラットフォーム「Mackerel（マカレル）」は、2014年9月17日に正式リリースして以来、10年にわたり多くのエンジニアに選ばれ続けてきました。

これまでサーバー監視・管理の領域に力を入れてきたMackerelは、より複雑な問題やシステムの変化に対応していくため、「始めやすくて奥深い、可観測性プラットフォーム」としてオブザーバビリティ領域の開発に力を入れることを宣言し、2025年5月1日（木）にはMackerelのAPM（アプリケーションパフォーマンスモニタリング）機能を正式リリースしました。

技術の進化による環境の変化の中で、Mackerelが変わったところや変わらないところ、この先の展望などについて、Mackerel プロデューサーの id:wtatsuru にインタビューしました。聞き手は Mackerel エバンジェリスト id:Soudai です。インタビュー記事は前後編でお送りし、本記事は前編となります。

プロフィール

渡辺起（id:wtatsuru） / Mackerel プロデューサー
2011年にインフラエンジニアとしてはてなに入社。インフラ基盤チーム責任者、Mackerelプロダクトマネージャーを経て、2023年1月からMackerelプロデューサーとして事業全体の運営に携わる。

曽根壮大（id:Soudai） / 合同会社 Have Fun Tech 代表社員、株式会社 Linkage CTO
数々の業務システム、Webサービスなどの開発・運用を担当し、2017年に株式会社はてなにMackerelのCRE（Customer Reliability Engineer）として入社。退職後、株式会社オミカレの副社長/CTOなどを経て、合同会社 Have Fun Techを起業。その後、LinkageのCTOとしてJOINし、Have Fun Techの経営と二足の草鞋を履きこなしている。Mackerelエヴァンジェリスト。

時代が変わっても、変わらない運用の本質とは？

Soudai：今日はよろしくお願いします。 id:wtatsuruさんは、はてなでのキャリアでMackerelをユーザーとして使い始め、その後のMackerelの様々な変革を経て、2023年からはプロデューサーとしてMackerelチームの事業責任者をされていますよね。Mackerelを使う側の立場と、実際に開発チームにジョインされてからとで、感じ方に変化はありましたか？

wtatsuru：使う側の立場だと、「こういう機能があったらいいな」「自分たちの環境だったらこうしてほしいな」と、割と気楽に要望を考えますよね。でも、作る側になると、もっと広い視野で、自分たちとは異なるお客様も含めて「世の中がどう変化しているか」をより強く意識するようになりました。

Soudai：僕がはてなにいたのは7年ほど前ですが、世の中もずいぶん変わってきましたよね。特に、id:wtatsuruさんがプロダクトの中の人になってから「ここは変わったな」と感じる点はありますか？

wtatsuru：技術を見る際も、「自分たちで使う視点」と「世の中でこれから何が来るか」という視点では、見方が全然違いますね。例えばメトリックを取ると言っても、1分に1回で十分なのか、それとも秒単位で見たいのかという話がありますよね。最近はより短い粒度で見たいというニーズが増えました。

はてなのようなWebアプリケーションの場合は、1分単位で十分だと感じていましたが、短期間のスパイクを多く経験するような方々は、もっと高解像度な情報を見たいと考えるだろうな、と。

Soudai：広告のシステムとかはそうですね。はてなが運用するようなWebサービスだけじゃなくて、ユーザー全体となると、最大公約数を取る難しさが出てくるところですね。

いろいろなニーズがある中で変わってきた点はたくさんあると思いますが、逆にMackerelとして「ここは変わらない良さだな」と感じるのはどこですか？

wtatsuru：私がインフラ部門にいた経験から、監視・運用には二つの向き合い方があると感じています。一つは「とりあえず形だけできていればいい」というもの。もう一つは、開発チームを含めた全員が主体的に運用できるよう、深く考えて仕組みを広めていくという姿勢です。この「どうすれば主体的に運用してもらえるか」という考え方は、社内の開発チームへの働きかけも、Mackerelのお客様へのサービス提供も、本質的に共通していると思います。結局、監視や運用は改善サイクルが回らなければ意味がありません。アラートが放置されたり、本当に必要な情報が見過ごされたりすれば、いざという時に対応できず、監視の意味が失われます。だからこそ、「どうあるべきか」という理想を追求し、改善を続けること。そして、その重要性を社内外の関係者にしっかり伝えていくことは、Mackerelにとって変わらない重要な部分であり、そこが面白いと感じています。

Soudai：僕もはてなの外に出て、いろんな監視ツールを使ってみて思いますが、MackerelはやっぱりMackerelを使っている人たちが、Mackerelを作っているということが、いろんなところに出ているなと思うんですよね。使いやすさを考えると、多機能が必ずしも最善とは限らない。最近だとテレビが高機能になってボタンだらけのリモコンも多いですが、それがかえって使いにくくなる場合もあります。その点、Mackerelはまるでエアコンのリモコンのようです。機能はオン/オフや温度調整などシンプルですが、誰が見ても直感的に操作できるUIになっています。この「誰もが分かるシンプルさ」こそが、Mackerelの変わらない良さで、機能の星取表だけでは表現できないものだなと思っています。

wtatsuru：ユーザーが「どう使うか」を常に考えながら開発しています。例えば、Slackにグラフ画像を投稿するボタンは、グラフを共有しながら会話する場面を想定しています。ユーザーの「欲しいもの」を深く考えて作るのがMackerelの文化ですね。

Soudai： Mackerelのアラートにはメモが書けますよね。そのメモが通知と一緒に届き、SlackだとMarkdownもきちんと反映されてURLがリンクになるのがすごく好きなんです。メモにRunbookのリンクを貼れば、例えばサーバー再起動の手順を直接指示できる。こういうものこそ星取表では表現できない。これは本当に運用している人ならではの、痒いところに手が届く機能ですね。

MVVのアップデートとユーザー像の広がり

Soudai：「Mackerelの変わったところ」についてですが、これまでのプロデューサーやプロダクトオーナーの変遷の中で、Mackerelの方向性も変化してきたと思います。id:wtatsuruさん自身が特に意識して変えた点や、変えていこうとしている点はありますか？

wtatsuru：自分がずっと苦しんで、頑張ってやってきたのは、今のMackerelの良さの再定義でした。漠然とみんながMackerelらしさだと思っている「インストールしたらすぐにグラフが出せるのが良い」とか「チームで監視に取り組む入り口として使って欲しい」などの言葉を紐解いて、何がMackerelが目指す方向性なのかを、チームメンバーと丁寧に言語化しました。ユーザーニーズや世の中の変化の中で、一時期「Mackerelの良さって何だろう？」と迷子になりそうな時期もありました。そこで、Mackerelらしい運用方法とは何かを改めて定義することに尽力しました。

Soudai：それは、2018年頃に作ったMackerelのMVV（Mission, Vision, Value）*1を、現代版に再構築したという話ですよね。

wtatsuru：そうですね。歴代のプロダクトオーナーがそれぞれ強い思想を打ち出してきた中で、例えば「Infrastructure as Codeだ！」といった考え方も、今や時代的に当たり前になってきていて。それは良いことですが、Mackerelが広めてきたことが一般的になった今、「Mackerelが次に何を大事にするか」を立ち止まって考えた時期でもあります。

Soudai：冒頭の「ニーズが変わってきた」という話にも繋がりますが、サービスが成長してきてユーザー層にも変化があった頃でもありますよね。ローンチ当初は、はてなと距離の近い、Webサービスやゲームを運営する会社がユーザーに多かった記憶ですが、最近はエンタープライズ企業も増えてきていますよね。何か印象的な変化はありましたか？

wtatsuru： 監視機能の拡充だけでは不十分になったのが一番大きな変化です。細かい点では、この2、3年でUIの日本語化に注力し、徹底的に英語表示をなくしました。これが非常に好評で、SaaSのサーバー監視プロダクトを使う層が広がってきたんだなと実感しています。「英語のUIがかっこいい」というだけでは、「分かりにくい」「社内共有しにくい」といった声が増えたため、設定も含め丁寧に日本語化しました。

これはMackerelの色を大きく変えずに分かりやすさを向上させた良い点ですね。これはビジネスメンバーからのフィードバックでしたが、自分には元々ない感覚だったので、なるほどなと思いました。

Soudai：以前は「Service」「Role」といった英語をそのまま使っていましたが、今はかなり丁寧な日本語表現に変わってきていますよね。国産であることもMackerelの強みだと思いますが、日本の多様な業種へMackerelのユーザーが広がっているのは面白い変化です。最近は、ブログやドキュメントも以前より充実してきたと思いますが、これも意識的に取り組んでいるのでしょうか？

wtatsuru：はい、それはかなり力を入れました。以前はプラグインのドキュメントがGitHubのREADMEや個人のブログ記事に頼りがちでしたが、公式のヘルプドキュメントとして徹底的に整備しました。「こんな使い方が便利」「ここが躓きやすいポイント」といった、テクニカルサポートメンバーの知見も盛り込み、プラグイン単位で情報を提供しています。

Soudai：ユーザーがアクセスしやすい場所に情報が揃っているのは、とても良いことですね。

手軽にはじめて気づけば上達、Mackerelの“監視レシピ”

Soudai：ユーザーの変化は大きなトレンドで、監視がSREだけのものではなくなり、より「簡単さ」や「分かりやすさ」が重要になると思います。 Mackerelも5月にAPM機能を正式リリースし、現状はトレースが中心ですよね。トレースは確かに便利ですが、オブザーバビリティの文脈で、トレースだけを使いたいのに、その前段で覚える知識が多いのが課題だということはよくあります。僕はMackerelをレシピが付いた料理キットに例えるのですが、麻婆豆腐を作るのにスパイスから揃えたくはない、手軽なキットで十分という感覚です。Mackerelの良さは、料理キットのように手軽さがありながら、味をカスタマイズして「料理を楽しむ」余地も残っている点です。仕事の成果とエンジニアとしての楽しみのバランスが良い。Mackerelでオブザーバビリティに取り組むというのは、そうした概念に近いと思います。そこで、今年APMを本格展開していく中で、id:wtatsuruさんはどのようなイメージで進めていこうと思っていますか？

wtatsuru：面白い表現ですね。まさにその体験をAPMでも提供したいと思っています。「オブザーバビリティは必要だ」と言われていて概念としても広まっていますが、一方でそこを適切に整えるスキルを持つ人は希少です。目の前の障害原因が分からず困っている人ももちろん多く、そこに必ず専門家が必要という状況は健全じゃないと思っていて。みんなが必死に勉強しなくても、Mackerelの方法に従って使い始めたら、「なんか便利だ」「問題解決できた」といって、価値を感じられる。ここまでを最速・最短・最小ステップで提供したいと考えています。サーバー監視では提供できた「インストールしたらすぐにグラフが見られた」のような体験をオブザーバビリティ領域でも実現していきたいですね。

Soudai：僕はAPMの文脈で言うと、リクエスト数、エラー率、レイテンシといったメトリックや、トレースをそもそもどう見たらいいのか分からないという人は結構いると思うんですよね。

ある程度インフラの知識があってメトリックを見てきた経験のある人なら、グラフの重なりでN+1を察知したり、トレースのバーの長さでボトルネックを特定したりできますが、コードを書くのが主体のアプリケーションエンジニアは、普段グラフを見慣れていないので、勘が働きにくい。そこを、教えてくれるというか、育ててくれるというか、教育してくれるというか、成長できるスキームとしてのMackerelというあり方にもすごく期待しています。

MackerelはOSやミドルウェアのプラグインを導入したら、必要なメトリックが自動で増えるので、Mackerelが追加したメトリックをじっくり見ることで、MySQLやインフラの知識、SREとしての能力も伸びていくという経験が結構ある。APMやトレースでも同じことが起こるだろうなと思いますし、そこをどのようにデザインするかが大事になってきますね。

wtatsuru：いいですね。例えばグラフが跳ねてる、グラフが頭打ちになっているなどはインフラの人からすると「これはやばい！」みたいな兆候ですけど、アプリケーションエンジニアをしている方は、分からないことが多いだろうし、問題が起きたときも、グラフよりログを必死に追うケースが多いと思います。

Soudai：あるある、ですね。

wtatsuru：ログを何箇所も見て、情報が足りなければデバッグログを出して…と原因調査を進め、最終的に該当ログに監視を入れる、というプロセスになりがちです。しかし、トレースを導入すれば全く違います。どのリクエストで、どこに時間がかかり、どのエラーが出ているかが視覚的に直接分かる。このように客観的なデータに基づいた問題解決ができるようになるのが、オブザーバビリティ導入の大きなメリットです。

見るものや見方が変わることでプロセスも変化する。障害対応だけじゃなく、日々のエラー解決を通じてサービス品質が底上げされて、全体としても世の中で良いとされるやり方に繋がっていくのが理想です。その時に、「この情報を参照すると良いですよ」というやり方をMackerelが示すことで、画面の操作をしながら「なるほど、こういう観点があるのか」「ここから深掘りすればいいのか」と理解が深まって、結果対応する人のスキルアップに繋がる。Mackerelがそういう存在になれるとすごくいいですね。