portal shit!

新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。

1. システム構成図を描く

どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。

2. 誰が何をやるかを明確に

タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。

3. リリース日を決める

リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース日を動かして調整する。

4. 確認環境・デモ環境を作る

ローカルではなく、本番と似た環境で動作確認できる環境をまず作る。ローカルで動いたけど本番で動かないをなくす。本番サイトを非公開にできるならリリース前からガンガンデプロイしてもいい。CSSが当たってなかったり、APIがモックでもいい。動くものを関係者間で共有し、早い段階でイメージのズレを補正することが超重要。

CI/CD の仕組みまで初期に整えておけるとなおいい。

5. リスクの高いところから開発する

システムの処理の中で重要かつ難易度が高い、もしくは実現できるかわからない（不確実性が高い）部分から開発する。簡単なところから先にやって不確実性（リスク）の解消を先送りにするのは超危険。

6. APIのJSONのフォーマットを先に決める

こうしておくことでバックエンドとフロントエンドがパラレルで開発できるようになる。誰かの作業が進まないと他の人の作業が進まないというような依存関係を作らない。

7. コードはこまめにリポジトリにプッシュ

他の人が作業状況をわかるようにする。小さくプルリクエストを作ってマージしていくとかは今更言わなくても常識ですよね？

8. 朝会か夕会をやる

超ラフにコミュニケーションしてお互いの進捗を共有する。可能ならオフラインで話す。一緒に寿司を食べるのも効果的。

---

↑は作るものが決まってからの話なので、作るものが合ってるか（正しいか）はまた別の話（プロダクトマネジメント）。

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

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

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

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

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

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

プロダクトマネージャーになって 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 必須のアンケートにしてしまって良いと思う。

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

集まったアンケートの回答は一旦 Google Spreadsheet 形式に変換する（ Google Form の機能を使うだけで簡単にできる）。スプレッドシートの機能を駆使すればクロス集計したりグラフを作ったりできるが、折角取得したユーザー ID との掛け合わせができない。なので Google Spreadsheet のデータを Big Query に取り込んでいる（詳しいやり方は Google スプレッドシートを BigQuery のテーブルとして扱う - べにやまぶろぐ 参照）。勤務先では Big Query にデータウェアハウスが構築されているので、 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 型人間であるべきと述べられている。再び同書から引用する。

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 年間だったけれども、ようやく自信を持って「プロダクトマネージャーやってます」と言えるようになった気がする。

仕事でなんか問題があったときにとりあえずミーティングすると大抵うまくいかない。事前に何が問題なのかを見極め、正しくアジェンダを設定しないとただ集まっただけになり、生産的な議論ができない。

一方で問題があったときにとりあえずミーティング招集してうまく行く人もいる。瞬発的に何が問題なのかを察知しアジェンダ設定できるのだろう。あとは断言力ともいうべきか。これが問題なんじゃおりゃ、と言い切って断定することでうまくまとまったような印象を与えられる側面もあると思う。これは人間性に依存する部分が多いので誰しもが使えるテクニックではない。

自分は基本的に自信がないので常におどおどしていてなかなか「おりゃ」と物事を断言できない。なのでノープランでミーティング召集するとグダグダになって参加者から不満が噴出してしまう。

ミーティングを段取るスキル、学校では教えてもらえないけど極めて重要なスキルだと思う。コミュニケーション能力が低い人でもうまくミーティングを段取りできるような、実践的なミーティングテクニックを学んでみたい。

DHH が Twitter で言及していた記事がおもしろかったので著者の許諾をもらった上で翻訳しました。

Paying remote workers differently solely depending on their zip code is immoral. If you can afford to hire from both San Francisco and St Louis, you can afford to pay both the same for the same work. If you can't afford SF rates, that's fine too! https://t.co/A1nJkPlimG

— DHH (@dhh) May 25, 2020

Salesforce の Product Manager 、 Blair Reeves さんの記事。

---

僕は自分のテクノロジー業界でのキャリアのすべての期間をリモートワーク擁護者として過ごしてきた。それは自分自身のリモートワークの経験から始まった（ありがとう IBM ！）。以前も書いたことがあるが、リモートワークというものは破壊的なテクノロジーでその優位は揺るぎない。このことは自明なのでここでは労力を割かない。

今週、 Facebook が一部の従業員に対して好きなところに住んでリモートワークすることを認めた（訳注: Zuckerberg says employees moving out of Silicon Valley may face pay cuts ）ことで、これまでたびたび論争になっていたリモートワーカーへの報酬についての議論が再燃した。この問題は究極的にはリモートワーカーにいかに "公平に" 支払うか、ということだ。このことが報酬についての議論を難しくしている。たくさんの会社がこの件に悪戦苦闘しているが、それはよこしまな理由からではない。

とはいえ、正しい議論と間違った議論があると思う。現実主義によって多少脚色されている。

現実的な観点では、テック部門の人件費をサンフランシスコやニューヨーク以外のレートに切り詰めるということだ。たとえば Facebook の Product Marketing Manager の初任給から 20% 削減された金額だとしても、ウィンストン・セーレムやジャクソンビル、リトル・ロック、ブルーミントン（訳注: すべてアメリカの地方都市）に住んでる人には魅力的に思えるだろう。多くの雇い主が給与額で競争するような状況が我々にとっては望ましい。機会が増えることは常に望ましい。だからどんどんやって欲しい。

上記を踏まえた上で主張するが、生活コストに応じた給与額の調整はとても不公平だしよくない習慣だと思う。同じ仕事をして同じ価値を発揮している人には同じ給料を支払うべきだ。

何が変わったか

最近までフルリモートで働くことは多くの人にとって選択肢になかった。もし X 社で働きたいと思ったなら、 X 社のオフィスがある大都市に引っ越す必要があった。それが取引だった。

しかしこれまで自分が働いてきたソフトウェア企業では、ほとんどの人の仕事はオンラインかつリモートでこなすことが可能だったし、実際にそうしていた。そう、すべてだ。プロダクトマネジメント、エンジニアリング、デザイン、オペレーション、マーケティングなどなど。リモートワークに懐疑的な人でさえ心の底ではこのことはわかっている。そしていま、（訳注: コロナウイルスの影響でリモートワークをするようになり）長い間信じられてきたリモートワークの優位性が実際に証明されてしまった。リモートワークで問題ないのだ。リモートワーク懐疑主義者達が間違っていたことが完全に証明された。

言い換えれば、従業員を大都市圏に住まわせることのビジネス面での合理性は崩壊したということだ。多くの人がニューヨークのような大都市に住みたいと思っているが、大都市に住むことは会社の成功にとって重要ではないし実際には無関係だ。ソースコードの善し悪しにどこで書かれたかは関係ない。ユーザーストーリーも、デザインモックアップも、販促資料もだ。テンペ（訳注: アリゾナ州の人口 16 万人の都市）でできることはメンロパーク（訳注: Facebook の本社があるシリコンバレーの都市）でもできる。

（ここはインターネットなのであら探しが好きな人もいるから捕捉しておくと、確かにある種の人たちは実際にビジネス上の理由で特定のエリアに住む必要があるだろう。具体的には顧客対応が必要な仕事、営業やカスタマーサクセスだ。これらの職種は希な例外としておく）

生活コストベースの報酬の理論的根拠が生活費が高い大都市に住む従業員への配慮なのだとしたら、もし雇用者が大都市の労働者を好まなくなったとしたらどうなるだろう？ 違う言い方をしてみよう。「なぜ生活費が安い場所に住んでる連中が必要以上のお金を欲しがるんだ？」という問いをひっくり返すと「なぜ会社はサンフランシスコに住んでる連中が必要なんだっけ？」になる。

生活費が高い/安い場所で、労働者がゆとりのある生活を送るために必要な報酬はいくらだろう、というのはよく議論の的になる。ただ、こういう問いの立て方は問題に対する間違ったアプローチで、どのくらいの生活費がかかる場所に住むかというのは完全に個人の問題だ。もしサンフランシスコに住んでる人が自分の収入の大半をサンフランシスコに住むために使いたいとしたら、それは結構なことだし、その人自身の選択だ。一方でもしサンマテオ（訳注: シリコンバレーの街。 YouTube の創業地）でリモートワークをしている（あるいはオフィスで働いている）人が、 リトル・ロック（訳注: アーカンソー州の人口 18 万人の街）に住んでいる同僚と全く同じ働きをしているとして、どうして一方は給料を優遇されてもう一方は減額されないといけないのだろうか？ もしリトル・ロックの従業員には子どもがいて年老いた親の面倒も見ていたとしたら？ 一方でサンマテオの従業員は独身で単身者だったとしたら？ 必要な額を考慮するとき、こういった個人の家庭の事情は考慮されないのはどうしてだろう？ つまり、生活コストによる給与の調整は、従業員はこういう風にお金を使うべきという本質的に不適切な思い込みに基づいて行われている訳だ。生活費の高い大都市に住むことは価値のある選択で、そうでない選択は価値がないと言っているに等しい。

例えば GitLab はこんな風に公言している。

もしみんなが標準的な給料を受け取ったら、所得の高いエリアに住んでる人たちは所得の低いエリアに住んでいる人たちに比べて可処分所得が少なくなってしまう。

えーっと、はい。これがポイントだ。

住む場所の選択によって発生する生活コストの違いは不可避的に、誰かにとっては補助金的なものであり、誰かにとってはペナルティのようなものなのだ。多くの人が住みたがる、生活コストの高い大都市に住む人に対して企業が高い給料を払う義理はないのだ。どこに住むかというのは、これまでもこれからも消費選択の問題に過ぎない。その選択の問題が今日、よりくっきりと明らかになったのだ。

インターネット全体で労働力の供給と需要が行われる

生活コストを報酬の決定に加味する件に関してよく言われることの一つに、労働力の需要と供給の問題がある。すなわち、市場メカニズムが地域ごとに異なる給与額を規定するので、企業はその地方の基準に従って支払うしかないのだと。 GitLab のような、完全にリモートで従業員を採用している会社がよくとるアプローチだ。彼らは報酬調整の式を公開している。

この方法の問題点は、 "労働力供給" の定義だ。オフィスへの出社を求める企業にとって、潜在的な労働力というのは会社の半径 20 マイルに住んでいる人々のことだ。しかしリモート企業では、 "インターネット全体" が潜在的な労働力だ。（もっと実務的な言い方をすると、裁判所の管轄権の及ぶ居住者全体だ。あとで詳しく述べる。）これらの観点から、フォート・ウェイン（訳注: インディアナ州の人口 25 万人の街）に住んでいる労働者にとって、彼女の住んでいる街には "競争相手" がいない（企業側からしても、労働者側からしても）。メンフィスやスポーケン、シュリーブポートあたりの人だってそうだ。企業が市場経済の仕組みによって給料を減額調整しようとするのは、本当のところ仕事ぶりとは無関係に懲罰的に給料を下げようとしているということと同じなのだ。ある従業員の地理的選好によって補助金を出すのは、組織としてビジネス的に意味のないひいきをしていると表明しているのと同じだ。

ある人はこのモデルを "底辺への競争" （訳注: 規制緩和でかえって経済全体が貧しくなること。底辺への競争 - Wikipedia）と見るだろう。僕は違う。機会の拡大だと捉えている。もしどこか別の場所により少ない給料で与えられた仕事を完璧にこなす人がいたとしたら、その人に仕事をしてもらうのが合理的だ。これは Menlo Park で働き一年で 50 万ドルを稼ぎ出す Facebook のエンジニアにとって驚異だろう。ほとんどのリモート企業が希少な才能を必要としていることを考えると、バンガー（訳注: メーン州の街）やリノ（訳注: ネバダ州の街）で仕事をしている人にとっては、幾ばくか値切られたとしてもリモートワークの報酬は充分によい、中の上レベルの給与になるだろう。

ではここで質問だ。このやり方はどこまで認められるだろう？

慎重な反論を紹介しよう。論理的に考えれば、世の中のテック系の仕事がすべてリモートワークへ移行すると、アメリカ中から条件のよい仕事はなくなってしまって、すべて外国に奪われてしまうだろう。結局のところ、ハイデラバード（訳注: インドの大都市）やキエフ（訳注: ウクライナの首都）、ラゴス（訳注: ナイジェリアの旧首都）に住んでる連中も充分に賢くて、アメリカのテック企業で必要とされる水準の働きをするだろう。文字通り 1990 年代にはソフトウェア産業でエンジニアリングの領域はオフショアの波に呑まれてしまうだろうと言われていた（ 90 年代後半にはマジで大問題だと認識されていた）。しかしそうはならなかったどころか、アメリカ国内のエンジニアや頭脳労働者の求人は拡大する一方だ。恐らくこの傾向は続くだろう。主にアメリカで使われることを想定したプロダクトを作っている会社はアメリカ人の労働者を重要視する。リモートでの雇用は国境ほどには州境を気にしない。精々法規制や税金のことくらいだ。

（政策決定の観点からすると、アメリカのリーダーたちは、高給の仕事を大規模にオフショアすることを規制すべきだ。代替案のないグローバリゼーションがいかにアメリカの労働者階級の雇用を悪化させたかという興味深い議論がある。しかしこの議論は別の投稿で行うとしよう。いまは企業レベルの話をしている。）

報酬の話になると、多くのアメリカ人がバンガロール（訳注: インドの IT 産業の中心地）に住んでいる Puja やイズミル（訳注: トルコの大都市）に住んでいる Mustafa に、パロアルト（訳注: シリコンバレーの街。スタンフォード大学やヒューレット・パッカードがある）に住んでいるプロダクトデザイナーと同額の給料を払うのは不合理だと言うだろう。僕はこういうのは自己中心的だと思うし、 Puja や Mustafa も同意しないだろう。彼らが確実に同じ価値を会社に対して提供しているのなら、同じ額の給料を支払うのが正しいはずだ。もし Puja と Mustafa が王様や女王様のような暮らしをしたとしても気にする必要はない。それでいいじゃないか。ひどく安い給料でオフショアの人々を雇うのは、本人の意思で決めることができない生まれた場所に基づいて労働者にペナルティを与えているようなもので、自分の意思で住む場所を決めた人に対して給料の調整を行うのよりももっと正当化できない。

人件費が高くなりすぎやしないかって？ さぁ、どうだろう。確かに人件費は高くなるだろう。しかし例えば GitLab は 5 億ドルも VC から調達している。従業員に公平に支払う余裕はあるはずだ。じゃあ Microsoft や IBM のような、何千人も雇っていて物価の安い国ではアメリカでの給料よりも低い給料で従業員を雇用している会社はどうだろう？ 僕には答えがわからない。ただ、正しいことは常に正しい。人は国籍によらず平等に給料を支払われるべきだ。バンガロールで雇われてる人がアメリカ人よりも給料が少なかったとしても、バンガロールの標準的な給料に比べたらずっといいじゃないか、という現実主義的な反論があるのはわかってる。審判を下せる問いではない。でもこれって公平かな？ いや、まったく公平じゃない。

Day one

企業が従業員に特定の場所に居住してもらう必要がある場合には、その土地に応じた給料を支払うことが正当化できる。でもそうでない場合には — 多くのソフトウェア開発の仕事が当てはまる — 労働市場ってのはかつてなく広がっていて深さもある。

この数ヶ月、もしくは数年でこの激震の勝者と敗者がはっきりするだろう。どういう結末になるかは誰にもわからない。しかし給料の良いテック企業で働くには西海岸か東海岸に住まなければならないという制約は崩壊し、我々の社会と産業は随分よくなるだろう。リモートワークは会社にとってもチームにとってもよい。従業員にとっても、その家族やコミュニティーにとってもよい。みんながリモートワークを好きになれるわけじゃないが、オフィスで働くのだってそうだ。（リモートがよいかオフィスがよいかについて、これまで個人の好みが問題になったことはないはずだ）

リモートワークは津波のように我々の上にのしかかったわけではない。近い将来に関していうと、いくつかの企業はリモートワークを躊躇し続けるだろう。僕はコロナ禍がリモートワークを推し進めるだろうと楽観しているが、油断はできない。僕の考えは間違っているかもしれないが、大躍進ではなくとも小さな一歩を踏み出すことになるだろう。ところで確信していることもある。僕がシリコンバレーで長期の商業ビルの賃貸契約をすることは決してないだろう。

---

リモートワークをしていて、地方に住んでいるからという理由で給料を少なくされたらやっぱりいい気もちはしない。同じ仕事をしているのに、自分だけコンビニの 100 円コーヒーで我慢しないといけなくて、同僚はスターバックスのコーヒーを飲んでる、という状況を想像してみて欲しい（自分にはそういう経験がある）。会社の中で所得の格差がありすぎると、ただでさえリモートワークでは同僚と雑談する機会が少なくて打ち解けにくいのに、より一層個人個人の間に壁を作ってしまって会社やチームになじむことができないと思う。日本国内では居住地による所得格差はアメリカほどには大きくないかもしれないが、コロナウイルスの影響でリモートワークが普及するにつれ、同じような問題に直面するケースが出てくるかもしれない。そのとき、リモートワーカーは決して安い給料に甘んじてはいけないと思う。