Mackerelのプロダクトマネージャーとしてミッション・ビジョン・バリューを策定した昔話

このエントリはMackerel Advent Calendar 2021の3日目の記事です。

最初にお断りしておくと、この話は4年以上前の昔話であり、私は既にMackerelチーム、はてな社から離れています。なので、ここで書くミッション・ビジョン・バリュー(MVV)はあくまで当時のものであり、今は別の形になっているでしょう。ですので、ここで書く話はただの昔話です。現在のMackerelに変に影響を与えたくはないと思っていることを予め書いておきます。

以前MVVの話を友人とした時に興味深く聞いてもらい、ユニークだとも言ってもらえたことがあったので、それらを決める過程の話や、浸透させようとした方法を書いてみるのも誰かの参考になるかもしれないと思い、これを書いています。

プロダクトマネージャー就任とMVV

私はMackerelのプロダクトマネージャーになった最初の頃に、MVVの策定に取り組みました。私は当時、Mackerelは自分のプロダクトだという意識を持っていました。また同様にそのような強いオーナシップを持っているメンバーも既に存在しました。そして、チームメンバー全員にそういうオーナーシップを醸成したいし、方向性も揃えたいと考え、MVVの策定に取り組んだのです。

その少し前、はてな社の上場期の頃、社長の id:chris4403 さんが、はてな社のミッションを踏まえ、バリューズを策定していました。

創業社長の id:jkondo さん時代からのミッションをしっかりと踏まえ、バリューズが定められたことで、会社の輪郭がくっきりとしたような感覚を持ったのを覚えています。メッセージングの大事さを改めて感じた瞬間でもありました。

話を戻し、当時のMackerelはMackerel創始者の id:stanaka さんと事業責任者が相次いで抜けた状況であり、引き継ぐ立場の自分としては id:chris4403 さんがはてな社でおこなったように、MackerelでもMVVを定め、プロダクトの輪郭を改めて社内外にくっきりと示す必要性も感じていました。それができるのは、リリース当初からプロダクトに関わっている自分しかいない、とも。

そこで、社内のはてなグループ上にMVVを定めたいという想いを記事に書き、チームメンバーや過去に関わったメンバーからの想いや意見を募り、それを踏まえて、以下のような、ミッション・ビジョン・バリューを策定しました。

ミッション
- 「クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」
ビジョン
- DevOps中核サービスのデファクトとして進化しつづける
- サービス監視・運用の価値を高め、面白くする
- 顧客のサービス成長を加速させる
バリュー
- Infrastructure as Codeを体現する
- devops文化を根付かせる
- ドッグフーディング
- エンジニアをワクワクさせる
- OSSエコシステムと共生する

これをどのように策定したかについて少し書いていきます。

ミッション

「クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」

これは、はてな社がバリューズを定めた時と同様に、id:stanaka さんがプロダクト立ち上げ当初に掲げたミッションから変更を加えませんでした。

別にミッションは変えても良いとは思っていました。Mackerelは同名の社内ツールをルーツとしています。命名の由来が「サーバー → サバ → Mackerel」という駄洒落になっている通り、Mackerelはサーバー管理の側面も強く持つツールでした。

なので「クラウド監視」と限定せず、インフラ管理の側面を強めても良いのではないか、思ったこともあったのですが、「クラウド監視」にフォーカスすることがむしろ大事だろうと考えなおしたのです。

この議論を社内でおこなう中で面白かったのは、チームで長く使われてきたこのミッションの中の「クラウド監視」という言葉に対する解釈のブレが思ったより大きかったということです。

Mackerelがインストール型の監視ソフトウェアではなく、SaaSのクラウド型の監視サービスであるということを「クラウド監視」だと解釈している人が結構いたのです。

もちろんそれも一つの側面ではあるのですが、むしろ「ペットから畜牛へ」の流れに併せ「サーバー監視からクラウド監視へ」という転換を起こす必要があり、そこでの新しい価値提案をすることこそがミッションであると私は捉えていました。

SaaSであることはあくまで手段であり、それも今の時代にソフトウェアビジネスをやる上での当たり前の選択肢でしかない。つまり、新規性がある話でもないのでミッションにそぐわない、とも。

なので「クラウド監視」とは「クラウド的なものを監視するという新しい価値提案」という側面が強い、という話をして、チーム内で認識の合わせ直しをしました。

このように、チーム内で当たり前に使っていた言葉でも認識のズレがある、ということに気づいたのは面白い発見でしたし、このようにプロダクトについて考える機会を持つことの重要性を改めて認識しました。

しかし、ここに「クラウド監視」という言葉をMackerel構想段階の2013年頃から当てはめていた id:stanaka さんの先見の明には驚かされます。

ビジョン

DevOps中核サービスのデファクトとして進化しつづける
サービス監視・運用の価値を高め、面白くする
顧客のサービス成長を加速させる

ビジョンは上記の3つでしたが、これは「自分たち」「世の中」「お客様」それぞれが、どうあって欲しいか、将来的にどうなって欲しいか、という三方良しの形を意識して決めたものです。

社内のとある役員からは「監視サービスが成長を加速させるのか？」などと疑問も呈されたのですが、私は当然そう思っていましたし、今もそう思っています。それに、掲げるビジョンは野心的でなくてはいけません。

バリュー

Infrastructure as Codeを体現する
devops文化を根付かせる
ドッグフーディング
エンジニアをワクワクさせる
OSSエコシステムと共生する

バリューは、プロダクトやチームの大事な価値観や行動指針となるものです。チームから募った色々な意見も踏まえ、100個以上書き出してから苦労して5項目に絞り込みました。はてな社のバリューズも5項目だったことや、ミッション:ビジョン:バリューで1:3:5なのもバランス的にも良いと考え、5項目としました。

バリューはチームに浸透させる必要があります。なので、ミッション・ビジョンも含めて、何故こうしたのかを社内ブログ記事で説明し、その中で、各バリュー項目に対応する参考図書を示すことにしました。それらを読んでもらって理解を深めてもらうと共にチームの議論のベースになるような共通言語を醸成したいと思ったからです。それが以下の5冊です。