portal shit!

最も優れたポッドキャストアプリ

ポッドキャストアプリは Castro を使っているということを以前書いた。

Castro はポッドキャストマニアがポッドキャストマニアのことを考えて作ったアプリで、ヘビーリスナーのかゆいところに手が届くような作りになっている。自分は 2018 年にサブスクリプションに登録してからずっと有料契約を続けている。

Castro の特徴

Castro の特徴は以下の通りだ。

ほかのポッドキャストアプリにはない特徴的で美しい UI デザイン

• 音楽プレーヤーの UI をそのまま引き継いだのではない、ポッドキャストの再生に最適化された UI デザイン

キュー（ Queue ）とインボックス（ Inbox ）の仕組み

• エピソードの受信箱（＝インボックス）があり、どのエピソードを次に再生するか選べる（キューの仕組み）
• 基本的にはキューに入っているエピソードを上から順番に聞いていく使い方
• お気に入りの番組は常にキューの先頭に入れる、などの設定もできる

Local search

Our first update of 2019 introduces local search:

- use the search bar in Archive to find podcasts
- tap the search icon on a podcast screen to search its episodes
- integrates with Spotlight to search from your homescreen

Get it now on the App Store: https://t.co/v5ZJTCNirt pic.twitter.com/JJyUpWwljC

— Castro Podcasts (@CastroPodcasts) January 30, 2019

• 購読しているエピソードの概要を検索できる仕組み
• 購読しているポッドキャストの過去エピソードを聞きたいときにとても便利

Sideloading

• 動画ファイルから音声を抜き出してポッドキャスト化できる
• YouTube 動画のほか、会社のミーティングの録画をポッドキャスト化してあとで聞くこともできる

プッシュ通知

• 購読しているポッドキャスト番組の新着エピソードがあるときにプッシュ通知で知らせてくれる（いまはほかのアプリにもあるかもしれない）

不調

このようにポッドキャスト再生アプリとして非常に完成度が高い Castro なのだが、実は 2023 年の年末から 2024 年の年始にかけてサーバー障害を起こしてサービス停止状態に陥ってしまい、一時はほぼ死んだ状態になってしまっていた。

サービス運営を引き継ぐ会社が現れて復活したが、最も優れたポッドキャストアプリがなぜこういうことになってしまったのかを、自分の所感を交えながら書いてみたい。

---

Castro のストーリー

Castro は立ち上げ以来、 Supertop という会社（インディーデベロッパー）によって運営されてきた。彼らは Padraig と Oisin というアイルランド生まれのプログラマーとデザイナーのコンビだった。 App Store が始まって間も無い頃からアプリを出していた古参デベロッパーで、他の会社の仕事を手伝うかたわらで自社制作のアプリを作っていた。

App Store が始まった頃は無料アプリが中心で、サブスクリプションはなく¹、有料アプリの値段はべらぼうに安くて 100 円とか 300 円という売価が中心だった²。儲けを出すのはかなり大変だったみたいだ。

2016 年に App Store でサブスクリプションの対象範囲が拡張されたが³、 Castro もようやくサブスクリプション対応バージョンをリリースしようというタイミングの 2018 年に、 Padraig と Oisin は Tiny という投資会社にアプリを売却している。二人は Tiny のスタッフとして開発を行なうことになった。

投資会社だがベンチャーキャピタルではない Tiny

Tiny という会社はデザイン会社の MetaLab を創業した Andrew Wilkinson によって経営されている投資会社で、ベンチャーキャピタルというよりインディーデベロッパーのビジネスを買い取って成長させることをビジネスモデルとしているようだ。

MetaLab はスタートアップ界隈では有名なデザイン会社で、初期の Slack のデザインを請け負って成功を収めたらしい。

なお Andrew Wilkinson は MetaLab を始める前はカフェでバリスタとして働いていたようで、その縁かコーヒーメーカーの Aero Press にも投資しているようだ。

しかしこの Andrew Wilkinson という人が曲者っぽくて、 Castro を買収したり、ポッドキャスト配信者がリスナーに課金するためのポッドキャストプラットフォーム（ Supercast ）を作ったりしておきながら、Twitter に「ポッドキャストというものは心を不安定にさせるので電話からポッドキャストアプリを削除した」と書いていたりする。

A few weeks ago I removed podcasts from my phone.

ポッドキャストs are mostly people repeating ideas you already agree with or talking about things that trigger anxiety (current events/problems triggers).

This has me reading audiobooks (net-new learning) 24/7.

10% happier, for sure.

— Andrew Wilkinson (@awilkinson) February 20, 2021

なぜそんな妙な奴がやってる会社に Castro を売らなければならなかったのか。 Castro 創業者の Padraig と Oisin がやっていたポッドキャスト Supertop Podcast で買収時のことを話していたので聞いてみたが、かなりお金に困っていたようだった。聞いていて切なくなるほどだ。

• 金がなさ過ぎて正しい判断ができなかった
  • CarPlay 対応しなければと思っていたが、 CarPlay 対応のカーナビを買う金がなかった
    • 友達に検証してもらいながら開発するしかなかった（一回の動作検証に 4 日くらい時間がかかった）
    • たった 500 ドルか 600 ドルすら節約していたが、さっさとカーナビを買って開発を進めるべきだった
  • WWDC に行きたかったが金がなくて行けなかった
    • 行った方がネットワーキングや Apple の開発者たちに質問ができて有意義なはずなのに行くという判断ができなかった
    • 買収の条件に WWDC に行けることを盛り込んだ
• 買収によってお金のことばかり考えなくてよくなった
  • 毎月決まった日に給料がもらえるのがとにかく嬉しい、お金のために受託開発をする必要がなくなった
  • 短期的なキャッシュのために機能を作っていたが、これで長期的な視点で開発ができる

買収直後に収録されたエピソードでは↑のような話を繰り返ししている。加えて Andrew Wilkinson のことをいい奴だと何度も述べているが、なんだか自分たちに対して言い聞かせてるみたいだった。

Xcode に戻りたい

彼らは 2018 年の 12 月に Tiny に Castro を売ったが、 Padraig は 2019 年の 7 月に Tiny を辞めて Castro の開発から離れてしまった。

After 6 years working on Castro, I've decided that it's time for a change. I'm finishing up in a few weeks. Thanks so much to everyone who supported my work on this over the years, it's been an adventure!

Castro is in great hands and I'm excited to see where it goes next. 🐙

— padraig (@Padraig) June 24, 2019

彼は Castro を売却したときはマネタイズやサポートなどの開発以外のことに時間を使うことにうんざりしていたので、開発に集中するために Tiny に身売りしたのだと話していた。

しかし Padraig が Castro を離れる際に収録されたエピソードでは、マネジメントや分析、マネタイズばかりやってきて疲れてしまったと話していた。開発に集中するために Castro の所有権を手放したのに、結局開発以外のタスクで疲弊してしまったようだ。表立って言いはしないけれど Tiny との折り合いも悪かったのかもしれない。

iOS Developer から愛されていた Padraig と Oisin

この最終エピソードは次々に彼らの友人がメッセージを寄せていて、無名な人から有名な人まで多くの人からのメッセージが収録されている。 Mac のソフトウェア開発で有名な Panic の面々や、競合ポッドキャストアプリの開発者たちもコメントを寄せている。 Pocket Casts の創業者 Russell Ivanovic や、あの Overcast の Marco Arment のコメントも聞ける。 Marco は Castro が Overcast にない機能を実装しているのを見つける度に悔しい思いをしていたと話している。彼らは競合ではあったが、同じ iOS Developer として情報共有をしていて、友だち同士でもあったみたいだ。

最終エピソードでコメントを寄せている人々の人数は数十人にもおよび、いかに開発者コミュニティで Padraig と Oisin 、そして Castro が愛されていたかがわかる。

Padraig が離れたあともしばらくは機能アップデートが続いていたが、 2022 年の 10 月に Oisin も Tiny を離れ、ほとんど機能アップデートされないようになってしまった。

Post by @prendio2@mastodon.social

View on Mastodon

Castro の死と再度の身売り

Oisin が Tiny を辞めてしばらく経った 2023 年の秋から様子がおかしくなり始めた。 Castro には購読中のポッドキャストに新規エピソードが追加されたときにプッシュ通知をしてくれる機能があるが、その通知が来なくなり、新着エピソードがあるのかどうかは自分で個別ポッドキャストのエピソード一覧の画面を開いて 2, 3 回手動でリロードしなければならないという感じになってしまった。

そうこうするうちについにはサーバーが全く動かなくなってしまい、新しいエピソードを聞くことすらできなくなってしまった。

iPhone 用 Podcast プレーヤーの Castro 、めっちゃよくできてるんだけどサーバーの障害を 4 日間くらい放置してるっぽくてユーザーがめっちゃ怒ってる（）。あと 2 ヶ月でシャットダウンするという根拠不明の噂を流してる人もいる。https://t.co/RDOR9fTD34

— morygonzalez (@morygonzalez) November 28, 2023

一時はサービス閉鎖も噂されるほどで、ほぼ死んだ状態になってしまっていた。

Twitter には「金を返せ」とか「許せない」といった怒号が飛び交い、 Reddit には Castro の代替を探すスレッドが立っていた。

利用者めっちゃ怒っててサブスクリプション解約したと言ってる。11月の障害のときに「あと2ヶ月でシャットダウンする」という噂あってCastroチームは否定してたけど、障害は金曜から起きてたのに一切案内なしで、この状態だとみんな不安になって他のアプリに移って本当にサ終になってしまいそう。 https://t.co/BoNoT51det

— morygonzalez (@morygonzalez) January 8, 2024

Castro alternatives?
byu/berniestormblessed inpodcasts

自分も Castro の代わりになるものを探してみたが、これというものは見つけられなかった。

他のポッドキャストアプリも色々試したけどしっくりこなかった。PocketCasts評判良いけどPremiumが高い。OvercastはMarco Armentが作ってるから有名だけどアプリとしての出来はCastroの方が良い（InboxやQueueの仕組み）。良いアプリが身売りして変なところに買われてポシャるの本当に残念。

— morygonzalez (@morygonzalez) January 8, 2024

障害が発生してからも何もアナウンスはなく、一週間程度経ってからようやくサービスは復旧したが、 Twitter には「 Castro は2ヶ月後にシャットダウンする」と元スタッフが投稿しており、ユーザーの間に不安が広がった。

Update: Castro is being shut down over the next two months.

— ❝Mohit Mamoria❞ (@mohitmamoria) November 28, 2023

Castro は公式ブログで Tiny からはじき出され、次の引受先を探していることを認めた。

Castro は結局 11/30 に復旧して謝罪文と今後についてのブログ記事が書かれてた。https://t.co/eM1HwV2uNj
- Castro は Tiny の手を離れて新しいオーナーを探してる
- シャットダウンはしないが今後どうなるかはわからない

— morygonzalez (@morygonzalez) December 6, 2023

そんな中、 2024 年の 1 月再度障害を起こしてしまい、ユーザーの不満は最高潮に達して離脱する人が続出した。

ポッドキャスト アプリの Castro 、また使えなくなった。 https://t.co/x14RreZdQD に接続できなくなってる。この前ブログに謝罪文書いてたのに。やっぱりサービス終了なのかな？ https://t.co/c67tE79bWj

— morygonzalez (@morygonzalez) January 6, 2024

救世主

このまま買い手が見つからずにサービス終了するのではととても心配になっていたが、 2024 年の 1 月末に買い手が決まり、サービスシャットダウンの危機は免れた。

Castro 、身売り先が決まったらしい。 Android のポッドキャストアプリ作ってる会社に買われるとのこと。 https://t.co/N44pDAFDuo

— morygonzalez (@morygonzalez) January 31, 2024

買収したのは Instagram の元エンジニアで、いまは個人で Android のポッドキャストアプリ Aurelian Audio を作っている Dustin Bluck という人物（正確には Bluck Apps という開発会社）。買収時のいろいろをポッドキャストの The Changelog で語っている。

レストラン規模の買収額

他に買いたい人がおらず、金額は 6 桁で、スタートアップというよりレストラン規模の買収金額だったようだ。数千万円から一億円の間で買い取ったのだろう。 Instagram で働いていて Meta のストックオプションがあれば個人でもそのくらい用意できるのかもしれない。

買収後はアプリはどんどん良くなってきている。正直なところ最近の UI はあまり好みではないが、サーバー側がきちんとてこ入れされていて、新着エピソードがあればちゃんとプッシュ通知が届くし、何も問題はない。

サブスクリプション価格のてこ入れなんかも行われていて、 Supertop 運営時代にサブスクリプションに加入したユーザーは年間 950 円で利用できていたが（自分もその一人）、比較的最近サブスクリプションに登録したユーザーは 4500 円くらいかかっていたはず。これは不公平ということで全ユーザー一律 3500 円に価格改定された。自分としては高くなるが、いまどきサブスクリプションが年間 950 円というのは安すぎるので 3500 円への価格改定は妥当だと思う。

---

なんとも言いようのないさみしさ

Castro が復活したこと自体は喜ばしいし、新しいオーナーの Dustin Bluck という人はポッドキャストとポッドキャストアプリのことが好きで Castro というサービスを買い取ったようだ。

ただ Padraig と Oisin がインディーで作っていた頃の輝きは失ってしまったように思う。 Castro はあの Marco Arment も一目置いていたアプリだったのだ。

自分は職業プログラマーになる前、 Hog Bay Software の Jesse Grosjean や Coda を作っていた Panic に憧れていて、あんな風にソフトウェアを作って暮らしたいと思っていた。

Padraig と Oisin もきっと同じだったのだろう。 Supertop Podcast の Episode 38 で「二人が暮らしていくのに十分な収入があれば、それ以上は求めていなかった」⁴と述べている。

なぜ Castro は身売りしなければならなかったのか

Supertop と Castro はなぜこんな末路をたどってしまったのだろう。 Padraig と Oisin はどうすれば良かったのか。

受託以外でソフトウェアビジネスを営むなら、会社のタイプは二つしかない。インディー型か、スタートアップ型かだ。それぞれでコスト構造が異なるし、ビジネスモデルが異なる。それぞれのコスト構造にあった技術戦略とビジネス戦略、プロダクト戦略が必要になる。

Castro の創業者二人は規模拡大を望んでいなかった（インディー型）。にもかかわらずフリーミアムのビジネスモデル（スタートアップ型）を採用したことにより、ユーザー規模を大きくせざるを得ず、規模拡大のコストだけ払ってその果実を収穫できなかった。この希望と戦略のミスマッチが悲劇を招いた。

サービスのランニングコスト（技術戦略）

Castro は UI/UX のよさを売りにしたアプリだった。 UI/UX の良さはデザインだけで決まるものではなく、サーバー側のシステムも必要だ。プッシュ通知、端末間の同期などなど。

このアプリの UX はサーバーサイドのシステムとセットで成り立っていた。サーバーがあるということは、ユーザーが増えればシステム投資をしないとスケールしなくなってしまうということだ。

しかし Castro は買い切りのビジネスモデルで始まり、サブスクリプションを始めたときも年間 950 円という低価格だった。これではサービス維持のためにバックエンドの投資をしたり、エンジニアを採用したりということは難しかっただろう。

フリーミアムモデルの採用（ビジネス戦略）

おまけに有料アプリをやめてフリーミアムモデルに移行したことで無料ユーザーの数が増え、 Padraig がポッドキャストのエピソードで話しているとおり、ユーザーからの問い合わせメールに返信するのに忙殺されるようになって開発を進めることができなくなってしまった。⁵

新しいユーザーはほとんど無料ユーザーで、無料ユーザーが増えても全然儲からない構造だったのに、フリーミアムモデルを選択したことはインディー路線とはミスマッチだっただろう。フリーミアムを採用するなら、広告などユーザー数が増えることが収益増につながるような補助輪が必要だった。

Castro にも一応広告出稿機能はあったが、広告主となり得るのはポッドキャストの配信者のみで、ポッドキャストの検索画面や Inbox の上にバナー掲載してもらうための枠しかなかった。

ポッドキャストの配信者はほとんどが個人なので、マーケティング予算なんてないだろう。非常にニッチな市場向けに広告メニューを用意してしまっていた。

ネットワーク効果をうまく使えなかった（プロダクト戦略）

Castro はフリーミアムにしてユーザー規模を増やす選択をしたのに、ネットワーク効果を生かすような設計になっていなかった。ユーザーが聞いているポッドキャストのエピソードを集計・集約して「いまこのポッドキャストが話題」のような機能や、レコメンデーションなどのソーシャルリスニング的な側面を打ち出していけばプロダクトの価値をより一層高められたと思う。フリーミアムモデルを取るならそういう方法でユーザー規模を価値に変えるしかなかった。

Castro は Tiny 買収後に TopPicks という機能を出している⁶。 Inbox にある未聴エピソードのうち、ユーザーが最も興味があると思われるものを推薦する機能だ。しかし説明によればこの機能は完全にローカルで稼働し、サーバーにユーザーのリスニング履歴データは送られないので安心して欲しいと説明している。

しかしローカル稼働では大したアルゴリズムもなく、データ量が少ないため推薦の精度は決してよいものではないだろう。実際、自分の Inbox は決して聞きたいと思えるものではない（めっちゃ古いエピソードが表示されたりする）。

ユーザー規模をプロダクト価値に反映することよりも、プライバシー保護の方を優先するという判断をしてしまった。プライバシーを守りながらネットワーク効果を生かすというやり方もないわけではなかったと思う。

---

Castro の問題は、よいプロダクトを作れなかったことではない。

むしろ逆で、プロダクトとしては優れすぎていた。Push 通知や同期のようなサーバーサイドの仕組みに支えられた UX を目指しながら、創業者たちはインディーデベロッパーとして、二人が無理なく暮らしていける規模の事業を望んでいた。 Castro の末路が教えてくれるのは、技術戦略、ビジネス戦略、プロダクト戦略を最初から噛み合わせて考えなければならないという、ごく当たり前で難しいことだ。

それでも、自分にとって Castro が最も優れたポッドキャストアプリだったという事実は変わらない。だからこの話は、教訓として正しいだけでなく、どうしようもなくさみしい。

プロダクトマネージャーになって 5 年ちかくが経った。最初の 2 年くらいはエンジニア気分が抜けず、 Vim を開いて何かやったりということがあった。ただ 3 年目くらいからはエンジニアっぽいことは一切やらず、プロダクトマネジメントだけをやるようになってきたと思う。ようやく自己紹介をするときによどみなく「プロダクトマネージャーです」と言えるようになってきた。

現在は登山アプリ・サービスの会社で仕事をしていて、割と頻繁に山に行ってドッグフーディングしている。なのでユーザー（山に登る人）の課題感が大体わかっているつもりだ。

もしいまの環境を変えることになったとして、自分は登山アプリ以外のプロダクトマネジメントができるのだろうかとふと思った。山が好きだから（ドメイン知識があるから）できているのか、それともプロダクトマネジメントのスキルが身についてきているのか。

これまで B2C 、 C2C 、 B2B2C など様々なサービスの開発に関わってきた。正直 ATI （圧倒的な当事者意識）が高い方ではなかった。なのでそんな自分がプロダクトマネジメントできるとは思ってもみなかったが、登山アプリの会社に就職して登山を好きになり、当事者意識が高まってプロダクトマネジメントを生業とするに至った。なのでいまの環境を離れてしまえばプロダクトマネジメントはできない可能性がある。趣味と仕事が重なる領域以外でも自分のプロダクトマネジメントスキルが活かせるのかが気になっていた。

しかしそもそも自分はソフトウェア（デジタルプロダクト）自体が好きなのだということに気がついた。あのプロダクトはこういう戦略で成長したとか、ソフトウェアの背景にある作り手の思想とか、そういうことを考えるのが好きだ。

ベンチャー企業のなかには、そのプロダクトがユーザーのどんな問題を解決しているのか作っている側も分からないまま突っ走っていることがあるのではないかと想像する。いまの職場でも、ユーザーがどの部分に最も価値を感じているのかを理解するまでにはだいぶ時間がかかった。

ある程度のシェアを獲得して、今後さらに規模を拡大したいというフェーズでは、ユーザーがプロダクトのどの部分に最も価値を感じているのか、ユーザーがプロダクトに期待している価値は何かをはっきりと理解する必要がある。ひょっとすると作り手の思い込みでユーザーが必要としていない機能を作っているかもしれない。プロダクトの価値を再定義し、機能を整理する必要性が出てくる。 0 → 1 のプロダクトマネジメントはではなく、 1 → 10 のプロダクトマネジメントだ。自分はこのような役回りが好きだし、こういった仕事もプロダクトマネージャーの気づかれにくい重要な役割の一つだと思う。

2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。

---

プロダクトマネージャーになった理由

ソフトウェアエンジニアだったとき、プロダクトマネージャーが不在のプロジェクトにアサインされたことがあった。機能コンセプトと画面デザインはあったが明確な仕様ドキュメントはなく、未確定の仕様をつまびらかにしつつ、関係者の合意を得ながらコードを書いていく必要があった。エンジニアだった頃の自分は機能的な仕様は誰か他の人に決めてもらって、自分は技術的な仕様を考えてコードを書くことに集中したかった。

このときは正直とてもつらくて、結局機能をリリースすることもできずプロジェクトはぽしゃってしまった。このような経験を自分はもうしたくないし、他の人にもさせてはいけないと思った。ビジネス的に成功するためだけでなく、エンジニアやデザイナーが不幸にならないためにも、きちんと作るものを定義してくれるプロダクトマネージャーが極めて重要だと思った。

その後しばらく時間が経ち、転職した職場でエンジニア・デザイナーが増えるにつれて専任のプロダクトマネージャーが存在しないことによる課題が露呈するようになった。プラットフォーム間での仕様の食い違いや、勘や憶測に基づく機能開発など。このままではプロダクトが間違った方向に進みかねないし、かつての自分のようにデザイナーやエンジニアが苦労をすることになると思った。誰か一人が専任のプロダクトマネージャーとなって交通整理をする必要があるだろうと考え手を挙げた。

プロダクトマネージャーの役割

プロダクトマネージャーの役割や定義については様々あるが、自分は「ユーザーに必要とされる製品を定義し、ビジネス的な成功を達成すること」だと考えている。プロダクトマネジメントについての本を何冊か本を読んだが、その中で最も感銘を受けた『 Making It Right 』という本にはこのように書いてある。

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.17). Smashing Magazine. Kindle 版.

この本を読んだ後に書いた記事ではこの部分を以下のように訳している。

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

— プロダクトマネージャーの Job Description - portal shit!

この記事の内容はいささか抽象的ではあったが、いま見てもそんなに違和感はない。記事内で引用した Dan Olsen の図から特に重要な部分を抜き出すと以下だろう。

上図の赤枠で囲われた部分、ユーザーのニーズとプロダクトをマッチングさせ、売れる製品を作ってユーザーの問題を解決すること（ Product/Market Fit ）がプロダクトマネージャーの役割だ。ユーザーの課題を解決する画期的な製品を作ることが出来たとしても、収益性が悪ければプロダクトマーケットフィットしたとは言えず（ Solution/Problem Fit に過ぎない）、プロダクトマネージャーの役割を果たしているとは言えない。

プロダクトマネージャーにふさわしい人物像として、プロダクトマネージャーは I 型人間であるべきと述べられている。再び同書から引用する。

First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically.

日本語訳: プロダクトマネージャーは雲の上に頭を置いておく必要がある。未来を見越すリーダーであり、戦略的な思考が求められる。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.22-23). Smashing Magazine. Kindle 版.

But good PMs also have their feet on the ground. They pay attention to detail, and they know their products inside out. They are the product’s biggest users — and its biggest fans and critics.

日本語訳: しかし同時に、良いプロダクトマネージャーは地に足を付けていなければならない。良いプロダクトマネージャーは細かいところまで注意を払い、プロダクトの表と裏を知っている。良いプロダクトマネージャーはプロダクトの最大のユーザーである。最大のファンであり、批評家でもある。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.23-24). Smashing Magazine. Kindle 版.

Most importantly, PMs know how to ship. They know how to execute and rally a team to get products and improvements out in the world where the target market can use them and provide feedback.

日本語訳: 最も大事なこととして、プロダクトマネージャーは製品のリリース方法を知っている。開発チームをとりまとめて開発プロジェクトを遂行し、製品を求めフィードバックを与えてくれる外の世界（＝対象とする市場）に届ける方法を知っている。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.24). Smashing Magazine. Kindle 版.

雲の上から俯瞰して戦略的にものごとを考えることも出来るし、地に足を付けていてプロダクトの細かいところも把握している。ユーザーの課題を発見するところから始まり、課題を解決する方法をとりまとめて世に送り出し、フィードバックを得るところまでできるのがプロダクトマネージャーにふさわしい人物像ということだろう。

具体的な仕事内容を挙げると以下のような感じではないだろうか。

1. 何がユーザーの問題かを特定する

• ユーザーインタビューやユーザーアンケートを実施する
• アクセス解析や利用ログに基づく定量的な分析を行う
• 競合製品と自社製品の機能比較を行う

2. その問題を解決する製品を定義する

• 要件定義・仕様書の作成
• ユーザーストーリーの作成
• カスタマージャーニーマップの作成

3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる

• プロダクトロードマップ（リリース計画）の作成
• プロジェクトの推進（プロジェクトマネジメント）
• 他部署（セールス、マーケティング、サポート）との調整

4. 製品が「正解」であったかの評価を行う

• 利用状況の調査やユーザーアンケートを実施し、プロダクトがユーザーの問題を解決したか評価する
• 1 に戻り、製品を継続的に改善する

実際になってみてのギャップ

本から得た知識をもとに、意を決してプロダクトマネージャーになってみたものの、想定と現実の間には大きなギャップがあり苦しんだ。具体的には、作るべき製品を定義するのがプロダクトマネージャーの仕事だと思っていたがそうではなかった。

エンジニアは作りたいものを作りたいし、プロダクトマネージャーが作るべきものを定義するまでもなく機能は開発されていく状態だった。開発すべきものがわからないのではなく、開発したい機能が多すぎて困っているという状態だった。

自分が思い描いていたのは以下のような役割分担だった。プロダクトマネージャーが必要な機能と要件・機能仕様をまとめ、デザイナーがデザインに落とし込み、エンジニアが機能を実装する。

しかし実際は以下のような感じで、機能のアイディアを出す企画段階からエンジニアが担当し、プロダクトマネージャーは他のプロジェクトチームや営業、マーケティングチームとの調整が主な役どころだった。製品の仕様に関われるのは既存機能の不具合対応のときくらいで、後は開発チームによって作られたソフトウェアを受け入れるだけの存在だった。

エンジニアが機能の企画・要件定義も行う体制では人手が足りず実装に十分な時間を割けないので、企画・要件定義を担当するエンジニアとは別に実装者のエンジニアがアサインされるようになった。企画・要件定義を担当するエンジニアがプロジェクトリーダーとなって実質的なプロダクトの責任者となる。プロダクトマネージャーは外部や経営陣との橋渡しをするだけの調整役になってしまった。

上図のプロジェクトリーダーと呼ばれるロールこそが自分の中ではプロダクトマネージャーだという認識だったが、このロールはプロダクトマネージャーのものではなかった。

プロダクトマネジメントの認知度が原因？

なぜ期待と現実のずれが生じたのか。当時の自分は、プロダクトマネジメントというものへの認知が不足しているからだと思っていた。

プロダクトマネージャーという職能が日本で一般的に認識されるようになったのは伊藤直也さんや Higepon さんが Rebuild ポッドキャストで話していた 6 年くらい前からでないかと思う。その後 antipop さん達がプロダクトマネージャーの Slack コミュニティなどを作り、一時期プロダクトマネージャー界隈が盛り上がっていた。

しかし、一般的な日本のソフトウェア企業でその存在が認知されるようになってからはまだ日が浅い。プロダクトマネージャーという役割に対する理解は圧倒的に足りていない。それが自分の役割に苦しんだ最大の原因だと考えた。

本に書かれているプロダクトマネージャーのロールを押し通そうとして軋轢を生んだこともあった。『 Making It Right 』にも以下のように書いてある。

Common objections to the role include:

• “We have different people in the organization who fulfill each of these functions as part of their roles.”
• “I don’t see how the role will make us more money.”
• “Product managers will just slow us down.”
• “I don’t want to relinquish control of the product to someone else.” (OK, that one is usually thought without being said out loud.)

プロダクトマネージャーという役割に対する反対意見の例:

• 「うちの会社にはプロダクトマネージャーの役割を部分的に果たす人々がすでに存在してるんだ」
• 「プロダクトマネージャーとやらが会社を儲からせてくれとは思えないな」
• 「プロダクトマネージャーって連中は開発チームのスピードを下げるだけの存在だよね」
• 「プロダクトについての決定権を手放したくないんだよ」（通常、声を大にして言われることはない）

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.19-20). Smashing Magazine. Kindle 版.

プロダクトマネージャーが存在しない組織では、プロダクトマネジメントのロールをデザイナー、エンジニア、カスタマーサポートなど様々なロールの人々が少しずつ分担しながら製品が作られていく。そこに突然プロダクトマネージャーが現れて「それ僕の仕事なんで僕がやりますよ」と言うと反感を買ってしまう。

プロダクトマネージャーの存在が認知される以前から、ソフトウェアの仕様を固めたり、ステークホルダーと調整したりする仕事自体は存在していて、大体はエンジニアの中のリーダーがその役割を受け持っていたのではないだろうか。少なくとも自分がこれまで勤めてきたプロダクトマネージャーのいない職場ではそうだった。ビジネスサイドから提示された大まかなビジネス要件を元にエンジニア（もしくはデザイナー）のリーダーが機能要件をまとめていた。

同じような話が伊藤直也さんのプロダクトマネジメントについてのブログにも書かれてある。

一体型のソフトウェア開発と分業型のソフトウェア開発

なぜこのような慣習が出来たのかを考えると、日本のソフトウェア産業の構造が響いているような気がする。受託開発が中心だった日本のソフトウェア産業¹では、ソフトウェア開発はひとまとまりに開発者（ソフトウェアを作る側）の仕事ということになっている。受託開発であったとしても受託者側で作るシステムの要件定義を行うケースがほとんどではないだろうか²。

総務省｜平成30年版 情報通信白書｜日米のICT投資額の推移

このため作るべきものの定義と作る作業の境界が曖昧なのだと思う（一体型のソフトウェア開発）。一方でシリコンバレーではジョブデスクリプションが明確で役割分けに敏感なので、作るべきものの定義とその結果に責任を持つ人（プロダクトマネージャー）と、作ること自体に責任を持つ人（エンジニア・デザイナー）が明確に区別されているのだろう（分業型のソフトウェア開発）と推察する。

したがって、プロダクトマネージャーの役割の認知が広がらない限りはこの問題は解決できないと思うようになっていた。半ば諦めというか、自分では解決できない問題に立ち向かわなければならないようで、とても苦しく悶々とした日々を過ごした。

しかし一方で、プロダクトマネージャーの役割は会社によって異なると良く言われる。『逆説のスタートアップ思考』の馬田さんが書かれている記事には以下のように書いてある。

組織のリソースが豊富な場合はプロダクトの仕様を策定するだけの PM なのかもしれません。スタートアップのようにまったくリソースのない組織の場合は、全部の機能を一人がやらなければいけないのかもしれません。人を採用して少しリソースが増えたら、また PM に求められるバランス感が変わってきます。

組織の今の状況に応じて PM はその役割を変えますし、同じ組織においても時間が過ぎれば役割が変わっていくと認識しておくほうがよいのでしょう。

— プロダクトマネジメントトライアングルと各社の PM の職責と JD | by Taka Umada | Medium

当時の自分はこの観点が抜け落ちていた。もっと柔軟に振る舞って、どうすれば良いプロダクトをユーザーに届けられるかという視点に立ち、所与の環境でどういう働きをすべきかが考えられていなかった。

プロダクトマネジメントのない組織にプロダクトマネジメントを浸透させる方法

自分の失敗経験を踏まえ、一人目のプロダクトマネージャーとしてどう動けば良かったのかを振り返ってみる。

まず、プロダクトマネージャーが存在しない初期状態が以下だ。経営陣が戦略を、開発チームが戦術を担当する。

そこにプロダクトマネジメントの仕組みが導入されるとこうなる。プロダクトマネージャーは戦略と戦術の両方を股にかける動きをする。 What の領域に主眼を置きつつも、 Why や How にも関わる。

自分がプロダクトマネージャーになったとき、会社はプロダクトマネージャーに戦略性の高い領域を守備範囲とすることを期待していた。

しかしそれに反して自分自身は機能仕様の策定など、戦術的な領域を守備するつもりでいた。

この認識の違いのせいで会社、開発チームとの軋轢が生じ、仕事のやりづらさや違和感につながったと考える。

本で読んで得ていたプロダクトマネージャー像はどれも中規模以上の、プロダクトマネージャーが何人かいる組織でのものだった。なので一人目のプロダクトマネージャーとしてどう動くべきかという観点での参考資料にはなり得なかったのだろう。その点は自分の反省点だと思う。

一方で、組織が大きくなってプロダクトマネージャーの数が増えると、以下のように役割を分担できるようになる。

戦略性の強い仕事を上級のプロダクトマネージャーが担当し、戦術領域に関してはジュニアなプロダクトマネージャーが担当すればよい。

少し前に読んだ『プロダクトマネジメント』という本では、以下のような説明がなされていて納得感があった。

　プロダクトマネージャーの戦術的な仕事では、機能を作って世に出すという短期的な行動に焦点を当てます。次にすべきことを決めるのに使うデータを処理したり、日々、開発者やデザイナーと一緒に作業を分解してスコープを決めたりすることも含まれます。

　戦略的な仕事では、マーケットで勝利して目標を達成するためにプロダクトや会社のポジショニングを考えます。プロダクトや会社の将来像や、そこに至るために必要なことに着目します。

　運営の仕事では、戦略を戦術的な仕事に結び付けます。プロダクトマネージャーは、プロダクトの現状と将来像をつなぐロードマップを作り、チームはそれに沿うように仕事を進めます。

— Melissa Perri 『プロダクトマネジメント』オライリー・ジャパン

以下の図もわかりやすい。

自分がプロダクトマネージャーの役割だと思っていたのは図中で言う「アソシエイトプロダクトマネージャー」か「プロダクトマネージャー」だったのだと思う。しかし会社は「プロダクト担当ディレクター」か「プロダクト担当 VP 」相当の存在を求めていた。戦術の領域はエンジニア・デザイナーに任せ、プロダクトマネージャーは戦略と運営にフォーカスするような働きが期待されていた。一方で自分は戦術にフォーカスしたプロダクトマネージャー像を持っていたため、組織のニーズにマッチできていなかった。

スタートアップのような小さな組織では常に人手が足りていないので、いくつかのロールを兼任することが求められる。小さな組織でプロダクトマネージャーが一人しかいないときには、戦術はある程度手放してエンジニアとデザイナーに丸投げし（エンジニア・デザイナーにプロダクトマネジメントのロールを兼任してもらう）、プロパーのプロダクトマネージャーは運営と戦略にフォーカスすべきだったのかも知れない。自分はそれができなくて、戦術に拘泥して失敗してしまったのだろう。

ただし、『プロダクトマネジメント』では、経営陣が期待するアウトカムではなく特定の機能（ HOW ）の実装を開発チームに要求し、一貫した戦略が存在しないためビルドトラップに陥る、ということも書かれている。プロダクトマネジメントの仕組みを整えるには、 CEO をはじめとした経営陣も一定程度戦術（どんな機能を作るか）からは手を引き、プロダクトマネージャーに権限を委譲していく必要がある。もちろん、なかなか簡単には HOW の領域から手を引いてもらえない（「プロダクトについての決定権を手放したくないんだよ」）ので、プロダクトマネージャーはうまい具合に立ち回って経営陣には戦略策定に特化してもらい、プロダクトについてのイニシアチブを自分で獲得していく必要があるだろう。

まとめ

• プロダクトマネージャーの役割を明確に
  • 会社はあなたに何を期待しているのかを明確にする
    • 戦略なのか？ 戦術なのか？ 運営なのか？
  • 本に書いてあること = 会社が求めているプロダクトマネージャー像ではない
    • 会社のステージによってプロダクトマネージャーに求められることは変わる
• プロダクト開発のイニシアチブをとる
  • 経営陣から特定の機能の開発（ HOW ）を要求されたきたとき、それは何を目的としているのか（ WHY ）、どんな結果をもたらすのか（アウトカム）を問う
  • 経営陣には期待するアウトカムと戦略の策定にフォーカスするよう促す
    • 機能開発を一任してもらえるように信頼を獲得する
• 開発チームからの信頼を得る
  • 自分が関与する必要がないところからは手を引き、信頼してお願いする
    • 「船を作りたいのであれば、木を集めさせたり船の作り方を指示するのではなく、果てることがない広大な海への熱情を説く」

---

今年の前半に取り組んだプロジェクトで、プロダクトマネージャーになったときに自分のミッションだと思っていた Product Market/Fit を達成することが出来た。ユーザーがお金を払っても欲しいと思うものを考え、健全なマネタイズ手法を提案してリリースするところまで成し遂げた。これまで苦しんだ 2 年間だったけれども、ようやく自信を持って「プロダクトマネージャーやってます」と言えるようになった気がする。

※初出は HEY World の https://world.hey.com/hitoshi.nakashima/post-8214d314 です

ソフトウェアで万人に響く機能はない。なのでサブスクリプションのソフトウェアサービスでフルセットのプランだけを作ってそれを売るとユーザーから値引き要求がくる。フルセットのプランのうち、機能 A だけ必要であとはいらないので負けろと言われる。

ソフトウェアは限界費用が限りなくゼロに近いので、使える機能の多寡で価格を変えるのは売り手からすると合理的ではないし、複雑な商品メニューの維持管理、サプスクリプションのプラン変更によるアップグレードやダウングレード、決済プラットフォームの移行などを考えると極力支払いプランはシンプルにしておきたい。この辺りを複雑にすることで肝心なソフトウェアの機能開発スピードが落ちてしまったら本末転倒だ。

多分有償のソフトウェアは、コアとなる売りの機能があって、そいつを支えるサブ機能を追加していく戦略が正しいのだと思う。コア機能への従量課金だけを行い、あとはコア機能をもっと使いたくなるサブ機能を開発してそれらは無料にしてしまう。フリーミアム戦略を取るなら、フリーユーザーはフリーで使える分量を使っていると、コア機能をもっと使いたくなるサブ機能の魔力によってコア機能をついつい使い過ぎてしまい、お金を支払わざるを得なくなってしまう。こういう構造が美しいし、ユーザーからも納得してお金を払ってもらえる。

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの PM が書いたもの）でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。

以下は HTML バージョン

---

プロダクトマネージャーの役割

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

ビジネス上の成功とは何か？

Product/Market Fit

※図は Dan Olsen のスライドから引用

Product/Market Fit とは何か？

良い市場を見つけ、市場の要求を満たすプロダクトを作る

なぜ Product/Market Fit が重要か？

すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから

なぜプロダクトマネージャーが必要か？

• Market Driven な製品開発
  Market Driven でプロダクトを作っている会社の方が 31% 儲かりやすい
• 組織のゴールが明確になり、プロダクトのリリースと収益化が迅速化される

（良い） プロダクトマネージャーは何をするのか

• 何が作る価値があるものか、何がそうでないかを明らかにする
• すでに市場（ユーザー）で価値の検証が済んでいるものだけを作る

エンジニア・デザイナーとどう違うのか

• エンジニア・デザイナーは解決空間を担当
• プロダクトマネージャーは問題空間を担当する

具体的な役割

• ユーザーヒアリング
• 解決すべき課題の定義
  すでに存在する問題だけではなく、ユーザー自身も気づいていない問題も定義する
• 作るものの定義
  機能要件、スコープ
• 成功の定義とメトリクスの計測

※図は Making It Right から引用

プロダクトマネージャーが扱うデータについて

• データ分析チームとは異なり、ありのままの現実を調べる
  線形解析とか難しい統計とか機械学習などは担当しません

まとめ

• Product/Market Fit がミッション（ Objective ）です
• どうやったら Product/Market Fit したかを含め、成功そのものを定義します
• 成功するプロダクトを作ることに注力します（ Engineering からは身を引きます）

参考ページ

• Amazon.co.jp: Making It Right: Product Management For A Startup World (English Edition)
• Mastering the Problem Space for Product/Market Fit by Dan Olsen at Mind the Product San Francisco 2018 on Vimeo