Evernoteはなぜダメなのか

--

みなさんこんにちは。
チャットボット開発のスタートアップでプロダクトマネージャー兼エンジニアをやっている福本です。

今回は、全世界で2億人以上ものユーザーを抱えるクラウドサービス『Evernote』を(恐れ多くも)題材にして、プロダクトマネジメントについて語っていきたいと思います。

Evernoteの旧アイコン(個人的にはこっちの方が好きでした)

ちなみにこの話は、僕が仕事でお世話になっている方から頂いた話を元にしていて、そこから自分なりに色々と調べたり解釈を加えたものになります。まぁ要するにほとんどポエムってことです。

最近、自分の役割であるプロダクトマネージャー(以下PM)を説明する時に、Evernoteなら多くの人が知っているので例としてよくこの話をします。なので、「細かい話はこれ読んで」ってこの記事を投げつけられるとラクかなっていうのもあります。DRY原則ですね。

僕自身ブログで初めてPMっぽいことを書くわけですが、まぁこんな考えもあるんだなと生暖かい目で見守って頂ければと思います。

ここがダメだよEvernote

さて、さっそく吹かしてますが、ダメな理由を結論から言うと『Evernoteの使い方を10人に聞いたら、ほぼ全員が違う使い方をしているから』です。

“Evernote 使い方” でググれば分かりますが、本当に色んな使い方や設定についてレクチャーされています。ざっと以下こんな感じ。

- テキストエディタ・メモ帳(Markdown有/無)
- Web記事のクリップ
- 名刺の保存・管理
- チームでのプロジェクト共有
- クラウドストレージ
- ToDoリスト
- 画像の編集 (Skitch)

僕の周りでEvernoteを使っている人も大体こんな感じですし、肌感的としてもそんなに間違ってないと思います。ちなみに、僕自身もEvernoteユーザー(有料)でChrome拡張機能を使ったWeb記事のクリップにサービスを利用させてもらっています。

じゃあこの状態の何がまずいのかというと、「開発において選択と集中が全くできない」というところです。

イメージすると、10個くらいあるサービスの各主要機能に、それぞれ等しく10%ずつユーザーが張り付いている感じです。冒頭でEvernoteのユーザーが世界で約2億人いると言いましたが、各機能に2千万人ずつユーザーが居ると思ってください。

各機能ごとに分散するユーザー達(イメージ)

これでは、どんな優先順位でどの機能の開発に圧を掛けて進めれば良いのか判断できないですね。

また、「1つの機能に尖らせて開発する」という意思決定をすると、その機能のユーザー以外の1億8千万人を切り捨てることになります。これ、誰が責任取れるんですかね?

このヤバい状態が、今のEvernoteの現状なんじゃないかと考えています。

今後Evernoteはどうなるか

現状のEvernoteを踏まえて今後どうなるかという話ですが、「それぞれの機能に特化したサービス達にどんどん抜かれていく」んじゃないかなぁと思ってます。

実際に、僕自身はWebクリップ以外の機能は使っておらず、テキストエディタは『Boostnote』を、名刺管理は『Eight』を使っていたりします。ググってみると、Evernoteから他サービスに乗り換えたユーザーはたくさん居そうですね。

当たり前の話ですが、リソースを分散させて開発しても磨きのかかったプロダクトはなかなか作れません。

そして、1つのサービスの上に複数の機能が乗っていると、コード間の影響範囲や依存関係が大きくなるため、技術的負債は当然大きくなります。そうなればバグが起きる可能性は高まりますし、開発スピードは落ちることになります。

ここまでをまとめると、Evernoteは適切なプロダクトマネジメントが行われてこなかったため、「機能を広げすぎて、プロダクトの成長速度が上がらない」かつ「ユーザーを既に抱えてしまっており、機能を切り捨ることができない」という疑似ロックインのような状況が出来上がってしまったことになります。

これはPMとして絶対に避けなければならない状態です。裏を返せば、この状態にさせないために汗をかき地べたを這いずり回ることが、PMの仕事だと言えるでしょう。

どうすれば良いのか

「じゃあどうすれば良いんだよ」ていう声が聞こえますが、そもそもこういう状況を作ってしまってはいけないという話なので、今から打てる手といえばマルチデバイスを展開したいどこぞのプラットフォーマーに、ユーザーをぶら下げてサービスを売り飛ばすくらいしかないんじゃないでしょうか。

こうなってからお茶を濁すために「マイクロサービスだ!」と言い出して、ピタゴラスイッチよろしく複雑怪奇な製品アーキテクチャを作り上げるのはサービス開発ではよくある話です。

う〜ん、今から打てる手があまり浮かばない…頭のいい人達ならどう考えるのか気になります。売却するにしても、めぼしい候補のGoogleには既に『Google Keep』が、Appleには『memo.app』とかがあるからなぁ。

PMがEvernoteから学ばなければならないこと

以上、PMがEvernoteから学ぶことはたくさんありますが、プロダクトマネジメントとは突き詰めればプロダクトの”What””Why”を作り上げることです。

なので、ユーザーが(表面的に)求めているものをどこまで突き詰めて考えられるか、そして時に「No」を言えるかが重要だと思います。考え抜いて出された「No」の数は、いわば「どれだけ集中して開発したか」を表す数値だと言えるでしょう。

「プログラミングは魔法」だと言われますが、その魔法は誰にかけるものか、そしてそれはなぜなのかをPMは常に考えなければなりません。会社でその責任を明確に担っているのがPMなのです。

たくさんの人を少しだけ幸せにするより、少数の人を本当に幸せにするほうが良い。-ポール・ブックハイト(Yコンビネーター)
It’s better to make a few people really happy than to make a lot of people semi-happy. -Paul Buchheit(Y Combinator)

--

--

福本 晃之 | Teruhisa Fukumoto

Web Developer at Smartround.inc / Computer Science Student at Teikyo Univ / Kotlin(ktor), TypeScript(Vue), Ruby(Rails), Terraform, Python etc...