| @雑談

1 月

根子岳と祖母山

正月早々、山に登った。二年連続阿蘇山。砂千里側から登って仙酔峡に下山した。北面は日が当たらず凍っており、傾斜の急なバカ尾根を下るのは怖かった。

ブログには書いていないが確か正月の初売りで Mac mini の M2 Pro モデルを買った。 Apple Silicon の速い Mac を手に入れたので Whisper CPP を使って Castro を作っていた Supertop の Podcast の文字起こしをしてブログに書こうとしていたが、未完のまままだ公開できてない。年末年始で書き上げたい。

仕事はアプリのダウンロード数をどうやったら増やせるかを延々考えていた。開発をしてダウンロードを増やすなんて無理ゲーだろうと思ってたが、頭を使って何個か施策を考えた。あとは企業向けの機能をテコ入れしていた。

2 月

多良岳から見る雲仙方面の山

熊本城マラソンに出てる。サブフォーを狙っていたが練習不足で果たせなかった。一人で出て誰も知り合いのいない熊本城マラソンは孤独だった。来年雪辱を果たしたい。

中旬のやたら寒い時期に佐賀と長崎県境の多良岳・経ヶ岳に登山に行った。パラパラと落ちてくる樹氷の下を歩くのは楽しかった。花粉がやたらきつくて寒かったけど楽しい登山だった。

仕事はやたらネットワーク効果について考えてたが、まだ思考が甘かった。その後ハイパー起業ラジオを聞いたり本を読んだりしてネットワーク効果についての知見を深めていく。

3 月

今津湾

3 月から 6 月にかけてはブログ記事がない( 3 月に熊本城マラソンの記事を書いているが、それ以外は何もない)。

3 月の頭に糸島であったトレランのレースに出た。ショートレースであまりパッとしない成績だった。まだ 300km も走ってないアルトラのトレランシューズ Outroad が破れて悲しかった。

仕事は新規ユーザーの継続率を伸ばすための A/B テストをやってた。

4 月

長垂海岸

平尾台のトレランレースロングに出た。雨降りでコンディションが悪く、関門タイムギリギリのゴールだった。このときからギリギリグセが付いている。

家の近くの山で有名なトレランチームの人たちを招いて緩い練習会をやった。グループ位置共有を宣伝できてよかった。

仕事はどうやって EC を伸ばすかを考えていた。やはり基本はネットワーク効果だと思って、ユーザーがレビューを書ける機能の土台を作っていた。日の目を見るのはだいぶ先のことになる。

あと、ユーザー登録数を劇的に増やす施策をリリースして、毎月の新規ユーザー数をかなり上積みできた。

5 月

退勤からの都市高速

南畑里山トレイルというトレランのレースに出た。楽しかったがショートレースは出し惜しみをしてしまう。レース後、体力が有り余っていた。

仕事ではこの頃から組織変更が計画されていて、自分の役割がちょっと変わりつつあった。

顧客起点を本格的に取り入れることになり、 N1 インタビューをやったりもしてた。

6 月

久住三俣山

仕事で久住に登山に行った。ミヤマキリシマ終わったあとの平日の久住は静かでよかった。

組織変更の荒波に揉まれたり、 EC のシステムをどうするかを考えたりしてた。もはや単なるプロダクトマネージャーではなくなりつつあった。

7 月

通勤風景

キリエビのロングに出た。こちらも関門 10 分前のギリギリゴール。最後の 15km くらいを近くにいた人たちと励まし合いながら一緒に走った。とても良い思い出。

仕事はなんと平社員からいきなり部長になってしまった。やることが大きく変わり、隣の部長から厳しいご指摘を賜りながら歯を食いしばって働いた。

この頃からハイパー起業ラジオを聴いて積読していたネットワーク効果の本をちゃんと読むようになった。

8 月

阿蘇山

脊梁ピストントレイルというトレランのレースに出たが、初めてリタイヤした。登りが急で、また水場がなく、とても消耗するレースだった。折り返し地点の関門時刻に間に合わず、失格となってしまった。めっちゃ悔しい。まだまだ自分は雑魚だと思い知らされたレースだった。来年は完走したい。

仕事では相変わらず EC のシステムをどうするかとネットワーク効果について考えていた。ユーザーインタビューではなく、山を歩いている人に話しかけて話を聞かせてもらうというのもやった。山を歩いてる人たちはほとんど自社アプリを使ってくれているのではないかと思っていたがそうでもなくてショックを受けた。

9 月

長垂海岸の夕焼け

PayPay ドームリレーマラソンに出た。リレーマラソン前の二週くらいは休みの日の朝に大濠公園に集まってみんなで練習したりしてた。大濠公園から西公園や南公園に走りに行った。

仕事は相変わらずゴタゴタの整理をしていた。この頃はあまり戦略的な動きができず、目の前の仕事に右往左往していた。

10 月

七ツ釜

翌月の福岡マラソンに向けて 30km 走を 2 回やりたかったが 1 回しかできなかった。しかし、初めて一人で大濠公園で 30km 走をやったのは自信になった。一人だと諦めないか心配だったけどちゃんと最後まで走れた。

仕事は相変わらずゴタゴタ処理。この頃から MAU を自分たちの力でどれくらい伸ばせるかにチャレンジすることになって、年末に怒涛の機能リリースをすることに。仕込みを始めた。

11 月

南阿蘇外輪山

オアシス再結成の報を受けてオアシスをよく聞くようになってた。その流れでアンディー・ベルがオアシス加入前にやってたバンド RIDE の曲を聞くようになった。 Vapour Trail めっちゃよい。

ランニングは福岡マラソンに出てきた、ネットタイムではあるかサブフォーをギリギリ達成した。 8 秒差。

また 11 月から会社の人たちと週に 1 回大濠公園を走るようになった。部活みたいで楽しい。

仕事ではリリースする機能の狙いや目的を社内で共有するのが難しくて難儀した。プロダクトマネージャー間で認識をそろえるのも難しいし、他部署の人と認識をそろえるのも難しかった。

12 月

会社からの景色

11 月に引き続き宮崎であった青島太平洋マラソンに出たが、記録更新はならなかった。初めてレース中にうんこしてしまった。最悪。そもそも想定外に福岡マラソンでサブフォーできてしまったせいでその後のランニングのモチベーションが落ちてしまって全然走れてなかった。

仕事は仕込んでいた機能が次々リリースされた。炎上した割に期待した効果が得られない機能や、そもそも使ってもらえない機能もあったが、一つは結構当たって成果を出せた。加えて失敗のリカバリーで出した機能も大きな成果につながった。例年、 12 月になると利用が落ち込むが、 MAU を自分たちでコントロールすることは出来なくはないということがわかったのは収穫だった。いままで大雑把に捉えていた MAU を細かく分解して、それぞれの要素ごとの継続率なんかを分析してる。まだこれといった施策はないが、来年はこの知見を活かしてさらにサービスを成長させていきたい。

2025 年の抱負

仕事

去年のふりかえりでは「何者にもなれない人生だった」と書いていた(2023 年のふりかえり)が、いきなり部長になってしまった。

プロダクトマネジメントとピープルマネジメントは別物と本には書いてあるけど、人に頼んで何かやってもらうという点ではあまり変わらないとも思う。人から信頼してもらい、自分の言葉や考えを信じてもらって行動してもらうという点は変わらない。

それを言い始めたらエンジニアだろうが営業職だろうが同じかもしれない。仕事をしていく上で人から信頼してもらうことは重要だ。そんなの誰でも知ってそうだけど、意外とそれができない。

たまたま年末に買った『プロダクトマネジメントの教科書』という本が良くて、この辺のスキル(人から信頼される、リーダーシップやオーナーシップを発揮する)ことについて実践的な内容が書かれていた。

役割に応じた働きができるよう、もうちょい戦略的に動きたい。

ランニング

ランニング実は去年に比べて距離が伸びていない。これまで毎年距離を伸ばせていたが、今年は夏くらいから走る距離が短くなっている。毎月 200km は走りたいのに、部長になってからみるみる前年同月比の走行距離が落ちている。

年間走行距離

ただ、ランニングのペース(スピード)は上がっている。去年だったらできなかったような、キロ 5 分を切るペースで 20 分間走をやれたりはしてる。なので練習の質は上げられていると思う。

来年こそは距離を伸ばして、月間 200km をコンスタントに超えていきたい。できればマラソンで 3 時間 45 分くらいでゴールできるようになりたい。少なくとも 2 月の熊本城マラソンではサブフォーを再現したい。

ブログ

2024年のブログ執筆状況

実はこの記事を含めても 11 記事しか書けていない。もう少し気負わずに日記感覚で気楽に書きたい。クソみたいな記事でも書かないよりは書いた方がマシ。書かなければ何も残らないしふりかえることすらできない。

Twitter が X になったり、 Threads や mixi2 が登場したりしたけど、セルフホストのブログが一番表現力が高く自由度も高い。死ぬ間際に Twitter や Instagram を見返すより自分のブログを見返した方が良いと思える状況にしておきたい。

| @労働

アプリの使い方がわからないというユーザーがいっぱいいると、「 UI がクソだからに違いない」というご指摘をされることがある。

しかし、アプリの特性上、どうしても使い始めるまでのステップ数が多くなることはあるし、たまにしか使わなくてなかなか使い方を覚えられないアプリもある(自分はいまだに世界で 15 億人以上が使っている Instagram の使い方が覚えられない)。利用頻度が低いせいでなかなか使い方を覚えられないだけなのに、 UI のせいにされてしまって延々 UI を改善すべしとなってしまうとつらい。

継続率を限りなく上げるべしというのも危険。『ネットワーク・エフェクト』という本で「ユーザーの 8 割は離脱する」と書いてあった。

テクノロジーブログ「テッククランチ」に「ユーザーの約4人にひとりは、アプリを1回利用しただけで離脱している」という記事が掲載された。3万7000人分のデータを調べたところ、多くのユーザーは1回試しただけで使うのをやめていたという。残念ながら、私が実施した調査でも同様の結果だった。私はグーグルプレイの元プロダクトマネジャーであるアンキット・ジェインとともに「モバイルユーザーの80%を失うのは普通」という記事を書いている。 — アンドリュー・チェン『ネットワーク・エフェクト』

でも継続率が 2 割しかないと聞いて「けしからーん」と怒る人たちがいて、継続率を限りなく 100% に近づけろという話になったりする。「けしからーん」と言ってる当人だってインストールしたアプリ全部を毎日は使ってないはず。毎日使うアプリは LINE とか Instagram とかマンガアプリとか PayPay くらいじゃないだろうか。

分析調査会社混むスコアのデータによると、人々はたった3つのアプリに80%の時間を費やしている。 — アンドリュー・チェン『ネットワーク・エフェクト』

現実的な観点で継続率とか利用率の目標を置けたらいいけど、割と勘とか理想論で数値目標が決まったりする。絶対達成できない目標掲げて仕事するのめっちゃつらいので、まずは現状の利用状況調べて妥当な目標を設定するべきだと思ってる。むしろアプリを使う全ユーザーにこちらがやってほしい行動をやらせようとするのは虫がよすぎるというか、傲慢なのではないか。

ユーザーすべてが作り手と同じような頻度、気持ちでアプリを使ってくれる訳じゃないことを前提とした上で UI とか継続率は考えていけたらいいと思う。絶対に一人も脱落させない UI やオンボーディング体験を作ることは難しい。

| @労働

可也山.jpg

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

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

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

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

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

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

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

| @労働

雷山千如寺 五百羅漢

今年はよくユーザーアンケートをとった。アンケート、最初は手探りだったけど最近は知見が貯まっていい感じにできるようになってきたのでノウハウをまとめたいと思う。ポイントは以下。

  1. 問いの設定
  2. Google Form の機能を駆使して誰が回答しているのかをわかるようにする
  3. Big Query と Looker を使った集計・ビジュアライズ

正しくアンケートをやってユーザーの声を聞けば、イチロー並みかそれ以上の打率で機能をリリースすることができるという気がしている。

問いの設定

アンケートで聞くべきは何か。いつも課題を聞くようにしている。やってはいけないのは「欲しい機能は何ですか?」と聞くことだ。良く言われることだがユーザーは自分が欲しい機能をわかっていない。だから課題に感じていることを聞く。

「課題と言っても何を聞けばいいのかわからない」と思う人もいるだろう。自分はいまある程度規模が大きくなってきたプロダクトの PM をやっているので、ユーザーの課題は何となくわかる。問い合わせやユーザー要望、ユーザーの利用データなどから何となくこの辺が課題だろうなというのは見えてくる。課題はこれらを確認することでわかってくるので課題リストにストックしておく。

次にどんな機能を開発すか検討するときに課題リストの中から「これを解決すると良いのでは(ビジネスインパクトが大きいのでは)」というのを見繕って、「〇×にどのくらい課題を感じますか?」という形でアンケートを送るようにしている。回答選択肢は三択で「とてもそう思う」「そう思う」「そう思わない」くらいにする。いくつかの課題を並べて聞き、「とてもそう思う」という回答の割合が一番高いものがペインが大きいと認定し、その課題を解決する機能の開発に取り組むようにしている。

Google Form の機能を駆使して誰が回答しているのかをわかるようにする

アンケートのシステムには Google Form を使っている。一時期は自前でアンケートシステムを作ろうかと考えたが、 Google Form ほどの柔軟性を持ったアンケートシステムを作るのは工数がかかるし、マーケティングチームの人もアンケートを多用していて Google Form に慣れているので Google Form で行くことにした。

ただ、ちょっと使い方を工夫していて、ペライチのページを作って iframe で Google Form を自ドメイン内のページに埋め込むようにしている( Google Form は iframe での埋め込みをサポートしている)。こうすることで以下のメリットがある。

  • アンケートページの URL がサービスと同じドメインになり怪しさがない
  • ログイン後のページに配置することで自ドメインで作成されたクッキーにアクセスできるようになり、ユーザー ID を取得できるようになる

Google Form はクエリパラメーター付きで https://docs.google.com/forms/d/e/XXX/viewform?entry.0000=value とすることでフォームに値を埋め込むことができる。アンケート依頼はアプリへのプッシュ通知で送ることが多いので、その場合には value の部分にユーザー ID が入るようにしていた。しかし一括送信するメールやアプリ内のバナーへリンクを設置する際にこのやり方は使えなかった。サービスのドメイン内にログイン必須のペライチページを作ってフォームを埋め込むようにしたことで、どんな導線からアンケートページに辿りついてもほぼほぼ確実にユーザー ID を取得できるようになった。

ユーザーアンケートは誰が回答しているのかを知るのが超重要だ。プロダクトのヘビーユーザーの回答なのか、ライトユーザーの回答なのかわからないと、次に作るべき機能を検討するときに判断材料として使えない。ライトユーザーの課題を解決する機能を開発しようとしているときに、誰が回答したのかわからないアンケートデータをもとに意思決定をするのは困難だ。

アンケートでユーザー ID を取得する際のデメリットとして、匿名回答ができないことでアンケートの回答率が下がることが懸念されるが、上述の通りどんな属性の人が回答したのかわからないアンケートはデータとしてあまり価値がないのでその部分は割り切ることにしている。また匿名の回答はサービスへのネガティブ感情が強い人からの回答が集まりがちで、自由入力欄の罵詈雑言で集計時に精神的にダメージを受けることもあるのでそれらを避けるという意味でもユーザー ID 必須のアンケートにしてしまって良いと思う。

BigQuery と Looker を使った集計・ビジュアライズ

集まったアンケートの回答は一旦 Google Spreadsheet 形式に変換する( Google Form の機能を使うだけで簡単にできる)。スプレッドシートの機能を駆使すればクロス集計したりグラフを作ったりできるが、折角取得したユーザー ID との掛け合わせができない。なので Google Spreadsheet のデータを BigQuery に取り込んでいる(詳しいやり方は Google スプレッドシートを BigQuery のテーブルとして扱う - べにやまぶろぐ 参照)。勤務先では BigQuery にデータウェアハウスが構築されているので、 Production DB のレプリカとアンケート回答を JOIN することで、どんな属性の人がアンケートにどんな風に回答しているかがわかるようになる。さらに幸運なことに勤務先では Looker を使えているのでこの辺の分析がとてもしやすい。こんな感じでアンケート結果をビジュアライズしている。

アンケートの集計

このやり方をとるようになって、リリース後に「大きく外した」ということがなくなった。少なくとも機能をリリースするときにユーザーに受け入れられるかどうか不安に思うことがなくなった。イチローになったような気分でプロダクト開発することができるのでおすすめです。


この記事は YAMAP エンジニアのカレンダー | Advent Calendar 2021 9 日目の記事でした。明日は @t-yng さんの「僕がフロントエンドのコードレビューをする時に意識していること」です。

| @労働

夕刻の今津湾

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-shaped people

プロダクトマネージャーにふさわしい人物像として、プロダクトマネージャーは 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 版.

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

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

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

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

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

日米受託開発の割合

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

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

エンジニアとプロダクトマネージャーの職能の分離

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

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

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

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

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

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

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

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

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

役割の戦略性 - 初期状態

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

役割の戦略性 - プロダクトマネジメント導入

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

役割の戦略性 - 戦略寄りのプロダクトマネジメント

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

役割の戦略性 - 戦術寄りのプロダクトマネジメント

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

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

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

役割の戦略性 - プロダクトマネージャーの役割分担

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

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

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

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

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

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

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

プロダクト関連の役割における戦略、運営、戦術の仕事の割合(10人以上のチームの場合)

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

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

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

まとめ

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

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

長垂海岸の夕焼け


  1. アメリカは受託の割合が半分強なのに対して、日本は 9 割弱が受託開発。アメリカはシステムを内製する傾向にあるので、内製システム開発も含めると受託の割合はさらに下がりそう。 

  2. 大規模なプロジェクトではどうか知らない。自分が以前勤めていた Web デザインに毛が生えたようなシステム会社では受託者側が要件定義書を作って顧客の承認をもらっていた。 

| @労働

仕事をしていると問題点と解決策の分離の大切さを強く感じる。しかし人間は愚かな生き物なので、問題点と解決策を分離することができず、解決策ベースで話を進めてしまう。ある問題点に対して、最初に思いついた解決策が正しいとは限らないのに、その解決策を実行することが目的化してしまう。本当にやらなければならないのは解決策の正しさの検証なのに、解決策を実行したところで満足してしまう。蓋を開けてみると解決策を用意したのに問題点は解決していなかったということになりがち。

実行プロセスの前の、半期目標設定のような状況でも解決策に目が行きがちだ。ここで重要なのは解決すべき問題点は何かということなのに、「(問題点はさておいて)どの解決策がクールか」という議論になりがち。期初のマネージャーミーティングで解決策の細かい部分について議論するのは不毛で、解決すべき問題は何か、その問題を解決することでどれだけのインパクトが出せるかだけにフォーカスし、どうやって問題を解決するかは別の会議やチームで対応した方が良い。

多くの人はこれらのことを説明するとその場ではわかってくれる。しかしやはり人間という生き物は愚かなので、解決策なしには問題点を議論できず、解決策ファーストで行動してしまう。どうしたら問題点と解決策を分離して話ができるようになるのだろう。

| @WWW

最近、エンジニアの求人の広告を見るといかにもテック企業のものが減っていると感じる。 10 年くらい前、ウェブ系のソフトウェアエンジニアの求人といえば受託をしている会社(ウェブ制作会社)か、自社でウェブサービスを開発している会社のものしかなかったと思う。自分は最初はウェブ制作会社に入り、その後自社でウェブサービスを開発している会社に転職した。さらにその後はデジタルマーケティングの SaaS / プラットフォームを作っている会社に移った。すべてソフトウェアでしかできないことをやっている会社で、インターネットがあるから事業が成り立つというような会社だった。一方で最近のソフトウェアエンジニア求人の中には、インターネットがなくても成り立つ事業領域をインターネットで効率化しようというものが散見される気がする。

もちろんこれらの企業も広義では「インターネットがあるから事業が成り立つ」と言えるのだろうけど、対象としている市場自体はインターネット以前から存在していたし、つい最近までそれで問題なく回ってきた市場だ。そういった昔ながらの市場にテクノロジーで殴り込みをかけて利益をかっさらおうというようなビジネスモデルだ。言語化が難しいのだけど、 2000 年代くらいまでの IT ベンチャーは IT が核だった。まずテクノロジーがあって、それで何をやるかを考える。 HOW の部分(ソリューション)が先にあって後から WHAT (プロブレム)を考える感じだ。一方で最近の IT ベンチャーは、まず対象とする事業領域( WHAT )があって、そこをいかにインターネットを使って効率化し革新するか( HOW )、というタイプが多い。プロブレムが先にあって、ソリューションが後から付いてくる感じだ。わかりやすい例を出すと Evernote や Dropbox は前者(インターネットがなければ成り立たない市場を対象とする)で、 Uber や Airbnb は後者(配車サービスも民泊もインターネットが生まれる以前から市場として存在した)だろう。

ソフトウェアエンジニアに求められる技術はどちらでも同じだと思うが、その企業の会社概要や経営者のプロフィールを見ると 2000 年代の会社や経営者と結構毛色が違っていて、元々ソフトウェア業界ではないところにいた人がそれまでの経験を活かして起業した、というパターンが多い気がする。リーンスタートアップやプロダクトマネジメントの観点からすると WHAT が先にあって HOW は後から考えるというフローが正しいのだけど、これらの新手の IT ベンチャーは特定・専門の領域に特化しすぎていてやっていることがイメージしづらいし地味な印象を受ける( Uber や Airbnb は C 向けなので例外的に目立ってる)。何よりわくわく感をあまり感じない。中卒のプログラマーが天才的なひらめきでソフトを作って一発当てて金持ちになる、みたいなのの方が夢があると思う。