Mackerel Advent Calendar 4 日目の記事です。
はじめまして。
id:RyuGoo と申します。今はプロダクトマネージャー（PdM）としてソフトウェアプロダクトのプロダクトマネジメントを職業としています。
- 2011 - 2013：不動産情報ポータルの運営企業で研究開発
- 2013 - 2024：ビジネスチャットの運営企業でソフトウェアエンジニア → PdM
- 2024：Mackerel チームのサブディレクター（PdM）
このようなキャリアを積んできました。今日は PdM 目線で見た Mackerel の面白さを紹介します。
プロダクトマネージャーの仕事
PdM の仕事の中身は本当に色々とあります。組織によって担う役割の大小、濃淡はあると思いますが、私が考えるプロダクトマネージャーの仕事の柱は事業者とユーザーの間で価値を交換するシステムを作ることです。
事業者はユーザーが抱える問題を見つけて解決のための適切な課題を解き、便益を提供し、ユーザーはそれに価値を覚えるから対価を支払ってくれるわけです。事業者が営利企業であれば、対価は金銭です。
なので、便益の提供と金銭を交換できるシステムを作ることが、PdM の仕事ということになります。
PdM 目線で見た Mackerel の面白さ
ここまでの Mackerel
Mackerel は Software as a Service（SaaS）の形でシステムのモニタリングを提供するプロダクトです。 SaaS の形態としては業種に特化した Vertical SaaS で、システムの運用や管理を行う人をターゲットにしています。
株式会社はてなの運用のノウハウを詰め込んで生まれたプロダクトで、多くのシステムをサービスやロールという概念で整理することで分かりやすさや利便性を提供しています。
自社のノウハウが元になっているので、プロダクトアウトの形態でプロダクトは進化してきました。プロダクトアウトを非常に簡略化して説明すると、自社が作った方がいいと思うものを作り、売る方法論です。
mackerel-agent のような簡単に始められて、すぐにダッシュボードでシステムの状態が見られる仕組みも提供することで、Mackerel を使い始めるお客様にとってもメリットがありつつ、プロダクトとしても魅力的なものになっています。
また、こうした業界のプロダクトは海外製のものも多く、特に SaaS 型となると純日本製のものは Mackerel を筆頭に数は少なくなります。国産のサービスを選びたいというケースで選択されうることも面白さの一つだと考えております。
Mackerel には CRE（Customer Reliability Engineer）というチームも存在しており、お客様の声を拾いつつ共に伴走していける体制が整っていることも特徴の一つです。Mackerel というプロダクトを開発するチームのサイズは決して大きくないなかでこうした動きが取れているのは、実際にお客様が触れるものを越えて提供できる価値となっています。
そしてこれから
ここまでの Mackerel では、自分たちのノウハウを元に整理された形でプロダクトを形作り、簡単に使える・始められる仕組み（mackerel-agent や CRE といった伴走体制）がプロダクトを魅力的に見せるポイントとしてその価値を発揮してきました。
この価値は Mackerel のコアとしてきっとこれからも磨き込んでいく部分であると同時に、世の中のトレンドや、より高度になっていくシステムに Mackerel 自体が対応していく必要があります。
対応していく必要がある概念の一つが「オブザーバビリティ」です。これまで Mackerel が提供した価値は「モニタリング」です。モニタリングは事前に決めておいた何らかのルールに従って条件を満たしたときにアラートを発報したり、継続的に数値を見ていくことで「何か」問題が起きていないかに着目します。
シンプルなシステムでは何か問題が起きたときに、例えば事前に設定しておいたアラートを確認することでなぜその問題が発生したのかを推測することは比較的容易だと思います。しかし、例えばたくさんのコンテナで構成されているようなアプリケーションや、多数のシステムが連携するような分散システムではアラートを見てもその推測は容易ではありません。
この問題に対応するためにシステムに「なぜ」問題が発生したのかをきちんと追えるようにしようという概念が「オブザーバビリティ」です。さらにシステムのオブザーバビリティを高めるためのデータを作成・収集・管理・エクスポートの標準化やツールキットの提供を行っている OpenTelemetry という取り組みも存在します。
PdM 目線では、これは Mackerel にとって大きな変革のときであると見えています。なぜならば、これまでプロダクトアウトの形態で進化をさせてきたモニタリングを主としてきたプロダクトが、オブザーバビリティに対して OpenTelemetry という標準化された形の上でどうしていくのか？と問われているからです。
例えば OpenTelemetry では OpenTelemetry SDK や OpenTelemetry Collector といった仕組みを提供しており、これをシステムに組み込むことで OpenTelemetry に対応したオブザーバビリティ・バックエンド（つまり、Mackerel のような）にテレメトリデータ（メトリックやトレース、ログなど）を送信できます。
これはつまり、プロダクトとしてはシステムの情報を集めて処理して送るところまでは OpenTelemetry 側で面倒を見てくれるから、送られてきた情報をどう取り扱い、どう見せるのか？という部分での勝負となってきます。
OpenTelemetry が提供するカスタムコレクターの仕組みを使ってカスタム版の OpenTelemetry Collector を提供することで、収集の部分にもバックエンド側が一定の手を入れることは可能だとは思いますが、それでも基本は見せ方勝負だと思います。
では、何をどう見せるのか？に対してはこれまでのプロダクトアウトの形だけでは良い回答を作れないのではないか？というのが私の PdM としての考えです。
例えば「簡単に使える・始められる仕組み」はオブザーバビリティプロダクトとしての Mackerel でも必要で重要な価値だと思っていますが、OpenTelemetry を土台にしている以上、SDK や Collector からは簡単には抜け出せません。これらをお客様にセットアップしていただくのは、mackerel-agent だけを入れて始められた、これまでの Mackerel の簡単さからは離れたものになってしまいます。
これが問題であると仮定した場合、どのような課題を解くと解決したと言えるのか？は、お客様の声からもニーズを見極める必要がありそうです。もしも無限の開発リソースがあれば、OpenTelemetry そのものにコミットメントしたり、SDK や Collector をラップした独自の仕組みを提供しつつ、OpenTelemetry 側の変化に追従し続けていくという方法も取れますが、先に述べたようにチームのサイズは決して大きくないので今は現実的ではありません。
私たちができる範囲とお客様が望む範囲をきちんと見極めていき、スイートスポットを見つけていく動きが必要です。これは恐らく、オブザーバビリティに対応するプロダクトとして Mackerel が進化していく上では常に必要になってくる動きだと思います。
これはまさにプロダクトマネジメントの仕事でもあります。プロダクトのビジョンと達成するためのロードマップを描きつつ、お客様の声を聞きながら軌道修正していく仕事です。短期から長期まで様々な時間軸で考えていく必要があります。
そして、最初に述べた PdM の仕事である便益の提供と金銭を交換できるシステムを作るという点においても、オブザーバビリティプロダクトとして Mackrerel を進化させていき便益を届けるという目的を達成するための手段として OpenTelemetry への対応を選択しているため、同じ土台を持つ競合と比較してどのような便益を提供できたらユーザーさんや Mackrerel にとっての価値となり、それぞれが価値交換を行うに値するシステムとして成立するのか？を考える必要があります。ワクワクしますね。
要は PdM 目線で見ると、Mackerel というプロダクトが面白くなってくるのはこれから！ということですね。ご期待ください。
ところで、 Mackerel では CRE を大募集中です。私個人の意見として、CRE という働き方は Mackerel にとっても凄く大事だし面白いと思います。Mackerel というプラットフォームの上で、お客様と向き合ったときに出てくる課題を技術でどう解決するのか？に真正面から向き合えるポジションです。ご興味がある方は是非ともご応募ください。
明日の Mackerel Advent Calendar 2024 は CRE の 
id:kmuto の記事です。お楽しみに！
