Quest PM

米系スタートアップで働くプロダクトマネージャー(PM)の姿をサンフランシスコから

GAFAやシリコンバレー企業とランドロイド。そこにある決定的な差 - プロダクト・ランドスケープ思考

Image result for ã©ã³ãã­ã¤ã

セブン・ドリーマーズ・ラボラトリーズ社のランドロイド

ここが「真空地帯」

何気なくこれはおもしろいな〜と思ってつぶやいたものが先日バズった。

 


ひと目でUberAirbnb的なビジネスモデルで狙うならどこが真空地帯かがわかる。この図がもたらす価値は大きかったようだ。ただ一つ心配だったのは、「よ〜し、おれもこの部分で勝負するぞ!」と勇んで飛び込もうとしていた人たちが結構いたこと。

この心意気は大いに買う。だが、自分の狙ったドメインで展開するプロダクトが本当にマーケットにフィットするかどうかを考える作業はある程度しておかないと、あとで痛い目にあってしまう。なので今日はそのためのツールについてお話したい。

おそらく起業や新規事業開発について関わっているなら、すぐにProduct Market Fit (PMF) と思いつくと思う。PMFについては結構いろんな方が話されているので、このブログではあらためて触れません。特に下記はシリコンバレーでも神VCの一人、マーク・アンドリーセンがPMFについて語ったものでこちらでも語り継がれています。以下はその日本語訳です。

growiz.us

 

Product Landscapeという考え方

今回ご紹介したいのはプロダクト・ランドスケープ(Product Landscape)という考え方。

プロダクトは単純に「それだけ」で存在するものではなく、使うユーザーの環境が外部要因として存在する。それは場所であったり、ユーザーが置かれた状況によって行動も変わるし、ユーザーが普段どんな人と交流しているかにも依存してきたりする。

Product Landscapeはこうした「外部要因」を4象限で浮き彫りにすることで、ぼんやりしたアイデアからプロダクトの輪郭が見えてくるようになる。もしくはどんな質問や仮説に答えないとプロダクトとして成立しないかがわかる。プロダクトマネージャーとしてふんわりした提案をして周りを悩ませるよりかは、こうしたプロセスを経て少しでも輪郭がクリアな方が議論は弾む。どちらかというとPMFの前段階という位置づけ

その4象限 (Four Quadrants)とはこんな感じ。

 

f:id:questpm:20190419143201p:plain

 

例として、先日破産してしまったセブン・ドリーマーズ・ラボラトリーズ社のランドロイドを例にプロダクトランドスケープを考えてみよう。

People & Network Quadrant
このプロダクトによって影響を受ける人とは?

補足すると単にプロダクトを使う人という意味だけではなく、そのプロダクトを使ったら誰に話をシェアしそうか(口コミ)、はては自動洗濯畳みによって影響受けそうな業界などといった意味。例えばUberにとってのタクシー業界、Airbnbにとってのホテル業界など。その場合業界との境界線をどう侵食していくのか。この象限では人と人のつながりの観点でプロダクトを考える。

例えばこんな質問が思いつく。

- 共働き夫婦、主婦、一人暮らし、子持ち世帯、 介護世帯、体の不自由な人、ビジネスとして成り立つ形で最も刺さりそうな自動洗濯畳みユーザーは誰か?

- こうした人々が比べることになるだろう別のサービスやプロダクトは何か?

- プロダクトとユーザーの間にどんな3rd partyがどのように入ってきそうか?

- サービス提供側と受益者側、そしてその外側にいる未ユーザーや非ユーザー、影響を受ける人々との間で考慮すべきことは?

 

ランドロイドが解決しようとした洗濯物畳みの手間と時間の問題は、日本だけでなく世界中に存在する。ペインポイントは明確だし、それがちゃんと解決されるならおそらく喜んでくれるユーザーは間違いなくいる。ただ、ランドロイドはユーザーをちゃんと見ていたかと言うとかなり疑問だ。

プロダクトの価格が200万円程度とのことだが、これはB2CなのかB2Bなのか?公開されている写真などを見るとB2Cっぽいのだが、この手の値段を出せる家庭となるとおそらく既にお手伝いさん、家事代行サービス等でまかなったほうが、畳むこと以上(洗濯・乾燥・アイロンがけ・畳み+空き時間で掃除など)のことをしてくれるのでコスパがいいと感じるかもしれない。


Technology & Trend Quadrant
コアとなる価値を最速で届ける方法とは?

この象限では向こう12〜18ヶ月のテクノロジートレンドの中で、プロダクトのコアとなる価値を最も感じてもらう最速の方法として、どんな手段が使えそうかを考える。

- People象限で見えてきたユーザー像からして、価値が感じられる瞬間とはどのようなものか?(よくUSでは"Ah-ha moment"と呼ばれる)

- 「先端のテクノロジー」にこだわることが、「価値を最も感じる経験」と「最速で届ける」ことにどのくらい寄与できるのか?(そのテクノロジーはMust haveかNice to haveか?)

- ユーザーがコントロールできる範囲は何か?


ランドロイドの場合 AIによる画像認識が特徴の一つにあがっている。しかしユーザーにとって

「自分が畳む」=「ランドロイドが畳む」

という価値が等式になるのは最低限のこと。仮にうまくたためない、時間がかかる、エラー発生といったことが起ると

「自分が畳む」>「ランドロイドが畳む」

という価値の不等式になってしまい、すぐに使われなくなってしまう。そこにAIがどうたらは関係ない。

つまり、「畳むことだけ」に価値を置いてしまうと、よほどテクノロジーでうまくやれる自信がないとすぐに価値を毀損する爆弾になってしまう。そんなプロダクトが200万円だった場合、リスクを取ってでも価値を感じて買うアーリーアダプターとはどんな人だろうか?

 

Place & Organization Quadrant
場所・シチュエーションのユニークさ

このプロダクトが使われる場所やシチュエーションに、どんなユニークさがあるかをあぶり出す。

- 子育て家庭か、共働き家庭か、一人暮らしか、介護世帯か、場所やシチュエーションでプロダクトの価値の感じ方はどう変わりそうか?

- B2Bプロダクトとして使う場合、それがどんな場所なのか?(工場、店舗など)
toBユーザーが感じるプロダクトの価値と、toCの場合の価値と何が変わるか?場所のユニークさは大きくプロダクトに影響する。


例えばランドロイドの想定ユーザーが子育て家庭だったとしよう。まずランドロイドは日本の住宅事情に沿う物理的な大きさになっていない。ただでさえ場所を取る冷蔵庫や洗濯機があるのに、ブログ冒頭の写真のようなランドロイドを置くとなるとさらに家の中に冷蔵庫が1台増えるようなもの。そのスペースがある家庭というのはどのくらいあるのか?

仮にランドロイドがB2Bで使われることを想定した場合、そのtoBとは誰なのか?その法人がランドロイドに期待していたことは、おそらく単に畳むことだけではないはず。なぜならtoBプロダクトの場合、その提供価値が顧客のビジネスのプロセスの中の一部として入り込まないとまず定着しないからだ。畳む+α の価値と言い換えても良い。


Activity & Touch point Quadrant
ユーザーの「自然な行動」とは?

People象限で見えてきたユーザーが、そのプロダクトを自然に使うためにとるアクションとはどんなものか?その時何のアクションが暗黙のうちに期待されてそうか?
(例えば「目の不自由な人でも使えるために、ボイスコントロールが必要?」など)

- Attention Span (人が何かに集中できる時間) が短いユーザーの場合、プロダクトを迷わず使ってもらうためのシンプルさとは?


洗濯後、乾燥機がない場合一旦外干しや部屋干しをしなければならない。仮に洗濯機とランドロイドが1階、ベランダとタンスやクローゼットが2階にあるとすると、洗濯機(1F) -> ベランダ(2F) -> ランドロイド(1F) -> クローゼット(2F)と1階と2階を無駄に往復しなければなくなる。例えば家族4人分の洗濯物を2階に運んで干すことは既に大変なのに、一度取り込んだものをまた下におろし、たたまれたものをまた2階に運ぶ、というのは家庭ユーザーにはおそらく受け入れられない。畳むことは面倒だが、慣れてしまえばベランダで取り込んだあと、さっさと自分で畳んで直接タンスにしまったほうが結局早いと考える人は当然でてくる。

 

洗濯物を畳むことは時間も手間もかかるが、実は畳む前後にも手間と時間が発生している。仮にプロダクトのスコープが「洗濯プロセス」だとすると、ユーザーが真に喜ぶのはこうした洗濯物プロセスにまつわる一連の時間と手間をどれだけ省けるかだし、そのビジョンのもとにランドロイドを位置づけないとただの高い家電で終わってしまう。もしくは全く逆に「そもそも洗濯しなくていい素材・服」という常識をひっくり返すアプローチもあるかもしれない。
 

こうしてそれぞれの象限を往復しながら考えると、プロダクトの輪郭を明らかにするためのいろいろな質問や仮説が浮かび上がってくるのがおわかりいただけたと思う。

特にキモとなるのは以下4つ。

- 依存関係や相関してることは?

洗濯物を畳むというのは、ユーザーの日常生活に深く結びついている。ただ単に「畳む」部分を切り取るのではなく、その前後の行動の依存関係もかなり重要なファクターだ。

- 潜在的リスクは?

畳めなかった瞬間に訪れるがっかり感は、ユーザーにとってかなり大きい。そのインパクトをどうプロダクトの内外で吸収するのか? "Pain relief (痛みを無くす)"のはずのプロダクトが、"Grow pain(痛みの増幅)"になってしまっては本末転倒。


- (気づいてなかった) ビジネス機会はあるか?

B2Cでなければいけないのか?B2Bでまずは小さく始める方法もあるのでは?

- 他に理解が足りてないところはどこか?

家庭で使うことを想定するなら、洗濯物前後の家事も体験してみないことには、本当のペインポイントを見失ってしまう。

 

プロダクトランドスケープで考えてみると、作ろうとするプロダクトが社会の中でどのように存在するのかが見えるようになる。逆に、会社のミッションやゴールとつきあわせて見直してみると「これ以上考えなくて良い範囲」も見えてくる。もしランドロイドを構想段階でプロダクトランドスケープに当てはめて考えていたら、おそらく今回のような失敗はしていなかったかもしれないし、105億円もの調達額も無駄にはならなかったはず。

日経ビジネスの記事を読んでいて気になったのは、

完全な製品を世に出したいと考えるパナソニックは、この点を重く受け止め、発売に難色を示した

のくだり。リリース時期がずれにずれていたこと、これまでの投資額を鑑みて投資サイドからある程度のクオリティーを求めたくなる気持ちはわかる。 だが、スタートアップに「完全な製品」を求めるのはさすがに酷というもの。それよりも、*最小限の機能だがユーザーに愛されるプロダクトをつくり、そこから継続的に改善する道筋を作ったほうが成功する可能性は高かった。もし投資家サイドもプロダクトランドスケープの議論を早い段階で行えていたら違った結果になっていただろう。

*最近だと同じMinium Viable Product (MVP)という言い方をしても、中身はMinium "Love-able" Product (MLP)という考え方にシフトしてきている

 

プロダクトランドスケープの使い方

勘の良い方は、プロダクトランドスケープ思考とUser Journey MapEmpathy mapは似てるとこあるかも?と思われるかも知れない。確かにかぶっている部分があるが、違いとしてこれらのマップは上記の4象限を別の軸で整形したものとなる。User Journey Mapは時間軸を使ってアクションから次のアクションへと移る「遷移」を、Empathy mapはプロダクトに触れた時にユーザーが思う「感情」の部分に焦点をあてている。Product Lanscapeとは切り口が違うのだ。

Product Landscapeはあくまでズームアウトして全体を俯瞰するもの。User Journey MapやEmpathy mapはズームインでミクロにユーザーの思いを理解するという感じで使い分けるとお互いに補完しあえて良い。

そしてこのツールは思考を発散させて、仮説や本質的な質問をいろいろ導き出すために使うのがベスト。あくまで「俯瞰」に力点が置かれてるので、ここで導き出された仮説にプライオリティーをつけて、次のステップとしてユーザーインタビューなどを通して検証していくのが大事。

シリコンバレー企業とて、失敗しているところもたくさんある。が、うまくいっている会社はたいていこのプロダクトランドスケープが成長ステージごとによく見えている。だからこそ果敢にピボットもするし、別の会社を買収して補ったりする。最初に決めた勝ち筋が未来永劫正しいわけでもなく、それだけで行くことが必ずしも正解ではないのだ。


こちらにシートを用意したので、ぜひアイデアのブラッシュアップに試してみて下さい!また、うちのプロダクトランドスケープ分析を手伝ってほしい、という方はquestpm.info@gmail.com まで遠慮なくご連絡ください。 

docs.google.com

 
【お知らせ】

シリコンバレーで発展し、新しいモノづくりの形として日本ではテック系スタートアップを中心に採用が進んでいるプロダクトマネジメントという考え方。Udemyでプロダクトマネジメント入門講座を公開しており、今やビジネススキル・マネジメント部門でベストセラーです。ぜひ学んでみて下さい。

ブログ読者割引クーポンはこちらから!👇

https://www.udemy.com/introduction-to-pm/?couponCode=QUESTPM_LANDROID

f:id:questpm:20190429122026p:plain

ビデオ会議の雄、ZoomがIPO - 愛されるB2Bプロダクトに見る強さの秘密

f:id:questpm:20190422063748p:plain

IPO後、株価が81%上昇

ZoomIPOしました。初値$36が終わってみれば$65と81%上昇。すごすぎです。ZoomのS-1ファイリングによれば、5万社にわたるカスタマーをかかえ、直近の収益は366億円。前年度比118%増と、今年に入ってIPOしている会社の中ではしっかり利益を出している。

一方でLyftは$78でIPOしたものの、現在$58と鮮やかな上場ゴールを披露。今ではLyftの最初の株価は不当に値段が釣り上げられていたとして、投資家の不満は爆発。裁判沙汰になっています。

www.cnet.com


ということでIPO悲喜こもごもがあるわけですが、今回Zoomはなぜこんなにうまく行ったのか、このB2Bプロダクトの裏側にある強さを引き出してみます。

圧倒的な使いやすさと高品質なビデオ会議

ビデオ会議をする時、こんなイライラを経験したことないだろうか?例えば以前自分がUKのチームとビデオ会議する時に、こんなことがあった。

- 動画と音声をビデオ会議アプリ上にすると音声がグダグダになるので、ビデオとは別に電話でジョイン。ビデオは音声をミュート。

- International dial in number -> どこに書いてある?え、別のページに行ってわざわざ検索しろと?

- Conference ID(9桁)を手入力 -> 時間ギリギリで始めなければ行けないケースだとたいてい打ち間違える。

- パスコードを(4桁)を手入力 -> え?パスコードいるの?そんなのインバイトに書いてあったっけ?

- Attendee ID -> は? ジョインしたら口頭で名前告げればよくないか?

- プラグインのバージョンが古い -> わざわざページに飛び、ダウンロードしてインストール -> 相手待たせてんだけど!?

と、いざビデオ会議を始めるのにもかなり面倒なUXになっていた。ところが、Zoomはこれを極限まで簡単にしている。例えば電話での参加の場合、以下の部分をワンタップするだけで勝手に電話がかかり、ID周りも自動で処理してくれる。

f:id:questpm:20190420075804p:plain 

事前にZoomのアプリをインストールしておくと、ビデオでの参加の場合インバイトにあるURLをクリックするだけでアプリが勝手に立ち上がりサクッと参加できる。モバイルのUXも同様。ビデオの画質も音声品質も問題になったことはなく、上記のようなストレスは一度も感じたことがない。

例えばUI周りなどCitrixのGotomeetingと比べるとZoomのシンプルさが一目瞭然だ。

 

f:id:questpm:20190422043923p:plain


  

f:id:questpm:20190422044029p:plain


こうした使い勝手の良さはフリーアカウントでも十分に感じることができる。(つまりZoomのビジネスモデルはフリーミアムモデル)以下のようにグループミーティングの場合は参加者100人までかつ40分間無料。1対1のミーティングであれば時間無制限。ビデオ会議の回数には上限なし。しかもサポートつき。

f:id:questpm:20190420075834p:plain

 

ということで、タッチポイントがシンプルでユーザーの意図したとおりに動く。できの良いB2Cアプリのような体験をビデオ会議に持ち込んだのがZoomなのだ。

 

Viral enthusiasm (熱狂の連鎖)

ZoomのS-1ファイリングを読んでいくと、

Our mission is to make video communications frictionless.
(我々のミッションはビデオコミュニケーションをヌルサクにすること)

とある。Zoomの創業者Eric Yuanさんは、もともとWebexというビデオ会議の創業メンバーの一人でVP of Engineeringだった。後にこの会社はCiscoに買収され、一時期Cisco Webexは業界を席巻。ところがプロダクトとユーザーの肥大化、シスコ製品との統合で使い勝手が低下。

そこで、ニューヨークにある投資銀行の驕奢な会議室から、中国でのキッチンテーブルに至るまで、どこでもシンプルに、ちゃんと動作するものを作ろうと思ったのが始まり。そもそもなぜ人が、面倒なビデオ会議アプリケーションに振り回されねばならないのか、という強い疑問があったようだ。

そして、この強い思いがプロダクトに現れます。ZoomはこのS-1ファイリングの中で、"Viral enthusiasum (熱狂の連鎖)"という言葉をなんと8回も使っている。Zoomの圧倒的な使いやすさを、ビデオ会議ユーザーにどんどん口コミで広げてもらうということを最初から念頭においていたのだ。


そして以下の指摘もかなり本質を突いている。

Viral enthusiasm begins with our users as they experience our platform – it just works. 

(熱狂の連鎖は「シンプルに、かつ確実に動く」という当たり前を、我々のプラットフォームで実感してくれたユーザーから始まる。)

  

熱狂を引き起こした土壌

たかがビデオ会議、されどビデオ会議。なぜZoomのプロダクトは「熱狂」に至ったか?そこには長年マグマのように溜まったB2Bプロダクトユーザーの「鬱憤」があったからだ。Zoomはそこをつついた。

G2Crowd というリサーチ会社があり、Software Happiness Reportというのを出している。

learn.g2crowd.com

これによると、おおよそ人が仕事に捧げる時間は人生のうち9万時間以上(おそらく日本だともっと長い)。従い、仕事で使うツールの使い勝手や生産性は究極的にはその人の人生にも影響してくるわけです。適切でないツールを従業員に使わせていると、下記のように62%もの人が「自分の力を発揮できていない」と感じてしまう。

  

f:id:questpm:20190420075820j:plain

 
これからのB2Bプロダクトの常識: Consumer Grade UX

Consumer Grade UXとは、B2Cプロダクトで消費者が体験する良質なプロダクトのUXと言い換えてもらっていい。考えてみると、B2Bプロダクトのユーザーは、実は同時にB2Cプロダクトユーザーでもある。そうすると仕事中の合間にツイッターやLINE、メルカリのように洗練されたUXで作られたプロダクトを日々目にする人も多いだろう。

そして仕事に戻った時イラつくUXのB2Bプロダクトが現れたらどう思うだろうか。そこにあるのはかなりの「がっかり感」のはずだ。もはやそれが当たり前過ぎて麻痺してしまっているかもしれないが、本来そうではないはずだ、B2BプロダクトだってB2CのようになめらかなUXがあっていい、と訴えるのがConsumer Grade UXの考え方。

シリコンバレーでは"Frictionless (摩擦のない) UX"という言葉で表現することもある)

Zoomは、ビデオ会議をスケジュールする、始める、参加してもらう、会議進行を助ける、こうしたシンプルな機能をパーフェクトに研ぎ澄まし、余計な機能は省いた。その結果ビデオ会議のUXはかなりエレガントにしあがっている。

 

こうしてB2BプロダクトでB2CのようにUXが研ぎ澄まされてくると、B2Bプロダクトを使うこと自体も楽しくなるし、「このツールだと仕事が捗る」と思ってもらえる状態になる。これまでの社内で使うアプリやツールのUXがどうしようもなくひどかった場合、この差は体感としてかなり大きく感じるし、鬱憤から開放されたユーザーが嬉々としてViral Enthusiasmへと発展していくのだ。

 

もちろん単にUXが良いだけで売れるようになるわけではないが、一旦採用されればB2Cと比べて長期間使われるものだし、ユーザーが日々触るものとなれば使い心地の良さはNPS(Net Promter Score)や継続率にも直結する。ということで、B2Bプロダクトに携わる人こそ、Consumer Grade UXという観点でプロダクトを見直していくと大きな支持を得られる可能性がグンと上がるのはおわかりいただけるはず。ぜひ自社プロダクトを良くするのに取り入れてみて下さい!

 

<お知らせ>
最近上場したZoomPinterestUberLyftその他シリコンバレーのスタートアップでどんなプロダクトマネジメントがされているか興味ありませんか?今年公開したシリコンバレー流プロダクトマネジメント入門講座 は、多くの注目を集めており今では、Udemyのマネジメント部門でベストセラー、受講者100名を超えても高評価をいただいています!ぜひ2019年のスキルアップにご活用ください。

  

f:id:questpm:20190513065557p:plain

 

料理は至高のPMエンタメ! 身近でできる疑似プロダクトマネジメント体験

f:id:questpm:20190113233826j:plain


1/1にPM入門講座をリリースして以来、いろいろと相談をいただくようになった。多いのが、「どうしたらPMになれますか?」、「自分はXXというバックグラウンドがあるんですが、PMに合っていますか?」というもの。まずは「僕の講座で思いっきりカバーしていますんで、ぜひ受けてみてください」とはご案内するものの、ふともっと身近にPMを体験できることがあるじゃないかと気がついた。今日はそれをまとめてみます。


料理はPMだ

先日何気なくツイートしたことがプチバズした。

 
多くの共感があったこのツイート。自分がこういう結論に至ったのには、実際に各々の役割を兼任したりして、試行錯誤の繰り返しがあった。この一連のプロセス、実行は上記のプロフェッショナル達に任せるものの、プランニングの段階ではPMもかなり絡む。そして、実は面白いことに「料理」でこの流れを追体験できる。各々のステージでPMが考えていること、そのステージを誰かに任せるということはどういうことかが、体験として透けて見えてくる。

具体的には、

 

Why: なぜ料理をつくるのか?

腹減った(けど食べに行くのが面倒)。持ち寄りパーティーに参加する。彼の胃袋掴みたい。彼女に料理男子ぶりをアピールしたい。

なぜ料理を作るのか、料理を通して何を達成したいのか?まずPMとしてWhyに対して明確な答えを用意する必要があります。


次にWhat

料理を作る目的を決めたのなら、次は「何を」作るのか。
和食、中華、イタリアン、大皿料理、小鉢、一汁三菜などいろいろあります。

ここで「誰に食べてもらうのか」という観点が必要になってきます。そう、PMの世界でいう「ユーザー」です。作った料理(プロダクト)は食べてもらう人(ユーザー)に満足してもらってナンボです。そうなって初めてプロダクトとしての価値を理解してもらえることになる。


When

その料理をいつまでに作るのか。それは今日の夕飯?週末のイベントとして?
タイムラインを決めないと、いつまでたっても料理たるプロダクトは出来上がらない。


How much

冷蔵庫の中のものですますのか、買い出しに行く必要があるのか、予算はいくらまで出すのか、オーブン料理(USのほとんどはガスオーブン)だとガス代かかるし、煮込むなら圧力鍋を使ったほうが1時間も煮続けるより経済的。

Who

自分で作るのか、誰かと作るのか、外注するのか。シリコンバレーではよく"Build or Buy"と言ったりします。


How

どのレシピを参考にして作るか、レシピ通りにつくるのか、アレンジするか、それとも独自にレシピを考案するか。盛り付けはどうするか?作り手のスキルレベルや、食べ手の期待値、要求の高さ、予算やタイムラインの関係でこのあたりが決まってきます。


いざ調理開始!

これで料理(プロダクト)のScope of work (SOW)が決まりました。いよいよ作っていきます。決められた時間内で作るのはスプリントと一緒。

スプリントが走り出すといろいろな障害にぶつかります。それはバグであったり見積もり違いであったり、ビジネス要件の変更であったり。料理で例えるなら、調味料の分量を間違えたり、レシピ通りにつくったのになぜか薄味、といった感じです。

期待してた食材がイメージと違ってた時なんかは、3rdパーティーAPIが期待どおりに動かなかった時のがっかり感とそっくりだ。

また、時間が決まっているため複数のことを同時並行で進めなければいけない。パスタを作る時、お湯を沸かし麺を茹でている間にソースを作るというように。かといって、茹ですぎてしまってはおいしくなくなる。

プロダクトマネージャーとしてはこうした困難に直面しても逃げられない。何をして、何をしないか決断をする必要がある。プロダクト開発と料理の関係でいうと、

バグを直す -> 作り直す
Workaroundを当てる -> 調味料や別の食材を追加して味を調整する
Backlogにして後回しにする -> 今回はあきらめ、次回再チャレンジ
運用で回避 -> 完成後、食べる直前に何かを一味加える、つけダレやソースでなんとかする。

当然それぞれのオプションにはPro/Conがあり、PMならばどの選択肢が失敗のリスクを最小化しベネフィットを最大化するかについて頭をめぐらさないといけない。


そして実食

こうして様々なプランと実行の積み重ねでできあがった料理を食べてもらうことになります。食べた人から「おいしい(これは便利)」と言ってもらえればPMとしてはひとまず及第点。「また食べたい(また使いたい、誰かに薦めたい)」と言わせて初めてナンボです。これはUser retentionやNet Promoter Scoreの考え方と同じ。

料理にはプロダクトマネジメントのエッセンスがつまっている。もちろん料理ができるからといってPMにすぐなれるわけではないが、少なくともPMがどんなことを気にしながらプロダクトを作っているのかを疑似体験できる、至高のエンタメだ。


実際には

冒頭で紹介したツイートのように、本当のプロダクト開発となると一人ではなく多くの人と連携しながらおこなうことになる。PMとしてWhy/Whatをどう決めるかは会社の命運すら左右する決断。Why/Whatが決まるためには、ユーザーだけでなく、会社の上層部やマーケ、営業、サポート、BizDevといった部署とも話しビジネス要件を決めなければいけない。一度決まればPJMやエンジニアリングマネージャーと議論してどう作っていくかを決める。一人で料理を作る時にはなかった、他のプロフェッショナル達との高度なコミュンケーション能力やビジネスセンス、取捨選択の決断力が要求されることになる。

(また、子育て家庭や共稼ぎで忙しい家庭では、正直言っていちいちこんなことは考えていられない。あくまでPMという観点で料理を噛み砕くと、という記事なのであしからず。)

 

料理教室イベントはチームビルディングに最適!

シリコンバレーのスタートアップ界隈でも実はCooking Classがチームビルディングのイベントとしてよく行われたりしています。 複数名でやると、PMの観点だけでなくチームプレイの観点も入ってきてなかなか頭使うんですよね。Googleだとビルによっては社員食堂にCooking Classの施設があって、社員なら自由にスケジュールして使えたり。

これまでPMってどんなことを考える人なのかわからなかった、という人にこの記事を通して伝われば幸いです!

新年だからこそ、もう一度意識したい”Bar"の高さ

f:id:questpm:20190107122024p:plain


自分を高める言葉の力

「言葉の力」はなかなかあなどれない。気分が落ち込んだ時、落ち着かない時、良い言葉を知っていると、自分の中で反芻することでどのような状況でも自分をコントロールすることができるようになってくる。なので、自分は本や会話の中でよい言葉や表現に会うと、決まった場所に残すという習慣を続けている。わりとそういうことが10代のころからあったりして、USに移り住んでからは自分を高める英語の表現を集めている

当然場所柄、「おお、英語でこんな表現があったのか」という瞬間に立ち会うとちょっとうれしい。そうした言葉は、日本の英語教育システムの中で10年も英語を勉強していたのに、なんと一度も出会うことのなかった言葉なのだ。そういう「教わらない」英語が日本の外では普通に日常で使われていて、時として強烈に自分を刺激した。

Raise the Bar High

「いつかは本場でPMへ」と志を胸に2006年にシリコンバレーに渡米した時、最初の仕事はカスタマーサポートエンジニアだった。当時外資の社内転籍で日本からUSへ来る人間など珍しく、日本人など同じチームにもビルにすら一人もいない。完全に現地採用だ。4年ほどそのチームで奮闘し、やがてテックリードになってちょっと自信をつけた自分は、PMへの社内転職を試みる。日本人でPMを名乗る人など当時はほとんど誰もいなく、全てが手探り。

当然うまくいかなかった。ビザの関係上社外への転職はできなかったため、社内転職でPMを狙うしかない。でもなかなか手がとどかない。キャリアの方向性で行き詰まり、胃の痛い日々が続いたある日、VP of PMをランチに誘い出して思い切って相談した。その時相手に言われた言葉、それが"Raise the bar high"

通常は「他のだれも打ち出すことののなかった、新しいスタンダードを作る」といった意味で使われる。ただ、このVPと話していて、実はそんな単純な意味で使っていたのではないことに気づく。ちなみにこの"bar”は棒高跳び走り高跳びの"bar"を意味している。棒高跳びというのはルールとして、1試技成功することに、5cm高さが変わっていく。(走り高跳びの場合は2cm)

実はこの上げ幅にミソがある。今自分がギリギリ飛べている高さの30cm上でもなければ1cmでもない。5cmなのだ。もし30cmなら、おそらく今やっていることを一旦ストップして(もしかしたらリセットして)、全く別のアプローチをしないといけないだろう。1cmならば、運がよければちょっとだけがんばればできてしまう可能性が高い。(そして自分の実力と勘違いしてしまうかもしれない。)

「5cm上」となると、30cmと1cmのちょうどハイブリッド的なアプローチが必要になる。今の自分の努力のしかたをそのまま足し算にしていく線形的なアプローチと、ちょっとやり方を変えてみる、今までノーマークだった部分も視野に入れてみて、そこから考えると何に自分が足りないのか、とかそういう非線形なアプローチの両方が必要なのだ。

当時の自分はとにかくPMになりたいがゆえ、誰に頼まれるでもなくPRD(今考えればひどいクオリティー・・)を書いてはPMに送りつけてみたり、プロダクトのダメ出しをふっかけてみたりと、かなり無茶苦茶していたと思う。このVPは自分にRaise the bar highの精神でアプローチのしかたを変えて、自分の新しいスタンダードを作ることを教えてくれたのだ。

その後自分は直接PMを狙うのではなく、一旦テクニカルマーケティングチームへの社内転職に挑む。なんとかチャンスを掴み、PMの右腕としてマーケ観点で日々サポートする立ち位置で働けることになった。その後PMにたどり着く。

これまで4年もカスタマーサポートチームでPMになろうともがいていたが、アプローチを変えたらPMへの道を開くのにかかった時間は1年半だった。

うまくいかないのなら、Barの上げ方に問題があるかも

もし今目標に向かって努力してるはずなのに・・なんかうまくいかない、近づいているように感じないことがあったら、この"Barの高さ”に意識してみると何か別の視点が開けてくる。

今の自分に高すぎると感じたら、一旦少し下げて確実にそこを乗り越えられるようになってからあらためてBarを上げればいい。あと少しなのに・・と感じるなら、きっとそれはあと5cmの部分だ。線形と非線形の努力という視点で自分の力の入れ方を見直せばクリアできる可能性はあがる。新年だからこそ自分の目標の高さをもう一度確認することをおすすめします。

 

 

Netflixだって失敗から学ぶ。世界のPM達が注目した10個の教訓

Image result for netflix logo

シリコンバレーのプロダクトマネージャー(PM)界隈で、大御所の一人として有名なGibbson Biddleさん。元はNetflixのVP of productで現在のNetflixの成長の原動力を作った人です。彼のブログは勉強になることが多く、世界のPM達からも一目おかれています。

昨年暮れに投稿された記事は今では2000以上のLikeがつき、日本のPMの皆さんにもぜひ読んでもらいたいと思いました。ツイッター上でGibbsonさんに翻訳していいかと聞いたらあっさり「いいよ」と答えてくれたので、今日はそれについて書きます。

読了目安: 8分  5000字につき長文注意

Image result for netflix gibson biddle
Gibbson Biddleさん

 

私はNetflixを例に多くのプロダクト開発戦略について、これまでいろいろなところで書いてきました。他の会社にNetflixの成功と失敗を学んでほしいからです。よく私がお伝えするのは、Netflixで行われる試みの半分は成功していますが、実は残り半分は失敗しているということです。

こうした失敗事例は多くのプロダクトマネージャーにとって、プロダクトローンチやスタートアップを成功させることがいかに難しいかを教えてくれる教訓です。加えてアートとサイエンスをうまく組み合わせて、作るべきプロダクトを見つけ出すのがいかに難しいかを我々に強調しています。

 

なぜ、Netflixはそんなにも失敗が多いのでしょうか?理由は2つあります。

1. 多くの人間が介入することで生まれるバイアスの多さ

2. うまくいかないプランにこだわってしまう(本当はそんなプランはすぐに諦めて、別の勝ちプランを見つけてそちらに集中すべき。良し悪しを見極める判断力がキモ。)

Netflixの友達機能について

Netflixは2004年に友達機能(Netflix FriendsもしくはCommunityと呼ばれた)を始めました。この時Facebookがユーザーを100万人から600万人に増やした頃です。この華々しい成長の結果、シリコンバレーのVC達は「あなたの会社のSocial Startegyは何か?」とよく聞くようになりました。

 
Netflix’s Friends, 2004–2010.
Screenshot: Wesley Fryer/Flickr/CC BY-SA 2.0


この友達機能で、Netflixは競合が真似できず、利益率の高い状態でユーザーを喜ばせることができると信じていました。Netflixの加入者は映画の良し悪しを友達から得られることを喜び、ユーザー同志で強固なネットワークができあがり、映画のレコメンドが友達経由で次々になされることで、レコメンド自体の効率があがると考えたのです。

Netflixがユーザー定着率(Retention)の改善を望んていた一方で、計測できるメトリックとして、「少なくとも一人の友だちとつながるメンバーの割合」を採用していました。

友達機能がリリースされたとき、この機能を使ったユーザーの割合は全体の2%、4年後に8%。そして2010年(すでに私はCheggという会社に移っていましたが)、Netflixはこの友達機能をやめてしまいました。この機能を継続するためには20%のユーザーに使ってもらう必要があったのです。この閾値を超えない限りはユーザー継続率の改善はみこめません。6年にもわたる努力をもってしても、ゴールには全く届かなかったわけです。

なぜNetflixはそんなに長くこだわったのか?

 

ここで賢明なみなさんなら思うでしょう。「なぜそんなに長くこだわったのか?」それには理由があります。

CEOによるサポート

CEOのReed Hastingはこの機能に大変自信を持っていました。こうなってはCEOが諦めない限りなかなかやめることはできません。

 

戦略として、ソーシャルな機能は意味があった

「机上の戦略」としてはソーシャル機能になんの不備もありませんでした。ユーザーを喜ばせ、競合による模倣が難しく、利益率の高い機能だからです。全てのチェックボックスを「机上では」満たしています。

 

"Small wins"が判断を曇らせた

友達機能をリリース後、メトリック自体は順調に伸びていました。問題は、Netflixがその成長率が目標には届かないと早い段階で認識できなかったことにあります。

 

プロダクトマネージャー達が楽観的すぎ

PMは避けることの出来ない挑戦に打ち勝たないといけません。このような状況下ではPMは往々にして楽観的になりがちで、ネガティブな要素を無視してしまうことがあります。ただ、こうした性質は成功するPMの資質として自然なもので、むしろ必要なバイアスとも言えます。

 

イデアに問題があったのではなく、実行に問題があったと考えた

この友達機能はFacebookがそのソーシャルネットワークを外部に公開する前にリリースされました。そしてNetflixは業界特有の問題に多く直面することになりました。その結果実行部分でかなりの苦労がともなったのです。例えば、U.S. Video Privacy Protection Actは、DVDのレンタル履歴を他者にシェアする場合、ユーザーから*オプトイン許可が必要になります。これは友達機能のUXとしては大変問題です。
(*ユーザーが自主的に情報開示を認めることを、約款を表示の上明示的に許可をもらうこと)

こうした問題の対応に注力してしまうと、Netflixとしてそもそもソーシャル戦略をどうするのかという評価から焦点がずれてしまいます。

逆説的だが、過去の「小さな成功」がシャットダウンを難しくしてしまった

Netflixの仕事はユーザーを喜ばすこと。友達機能をやめてしまうことはその原則の逆をいってしまうことになると考えるようになっていました。この背景には、2009年、Netflixはユーザーの*プロファイル画面の機能をやめたときの経験があります。この決断はユーザーから大きな反発を受けました。全ユーザーのたった2%しかつかっていないにもかかわらずです。
(*複数のNetflixユーザーが同一の画面で使う場合、アカウントをスイッチできる)

明らかになったのは、その2%のユーザーは本当にこの機能を大切だと思っていました。もしプロファイル機能でアカウントがわけられないと、1つのアカウントを複数のユーザーで使うことになります。これが発端で離婚にいたってしまうユーザーもいたのです!Netflixは後にこの機能を復活させました。(そういえば、Netflixのボードメンバーのほぼ全員がプロファイル機能をつかっていたこと、話しましたっけ?)

失敗から得られた教訓

 

それでは今回のようなNetflixの失敗事例から重要な学びを抽出してみます。

1. アイデアの出どころではなく、アイデア自体に注視する

友達機能は社内でも時間と投資がかなり割かれました。CEOがバックについていたからです。ですがCEOが間違っていました。こういうことは起こりえます。この場合NetflixのPMはアイデア自体とそのメリットについて冷静に評価すべきでした。

 

2. 社会・社内通念にとらわれていないか注意する

シリコンバレーのThought Leader(思想的な指導者)達は、ソーシャル戦略の価値を強調していました。この"ソーシャル"というのは音楽の分野には親和性が高いものでした。(映画とあまり大差ないように見えますが。)しかしNetflixは次第にユーザーは自分が見た映画の情報を公開するなんてだれも望んでいないと学んでいったのです。さらに大事なのは、映画の趣味趣向は驚くほど個々人で別れています。こうした多様性が強い状況下では下手をすると「あなたの友達は自分には全く興味のない映画を気に入っている」という、どうでもいいことをユーザーは知ることになります。そこに価値はないですよね。

3. プロダクトに対する行き過ぎたプライドを和らげる

PMは作り手として、当然作ることが大好きです。誰もプロジェクトをやめることを望んでいません。ただ高ぶる情熱と期待は判断能力を曇らせます。

4. クリアな目標を定める

Netflixはユーザーの行動を見るための指標を設定しています。しかし、友達機能の時はゴールに到達する際のタイムラインを設けていませんでした。(2年以内に10%のユーザーエンゲージメントを増やすといったもの)

こうしたクリアなゴールを設定することは、「次の四半期にはどうにかなる」といったゆるい期待をしてしまうことに対するガードになります。これは私が好きな、Noon time turnaround ルールと同じです。(エベレスト登山をする登山家が、頂上まであと100メートルであったとしても時間が正午になったら引き返す。なぜなら午後になると酸素量の変化や、天候、日照の条件も急激に変わり登山家の判断を狂わすから。)

5. ブラインダーを開ける(データに対して目を見開け)

PMはゴールにフォーカスするあまり、進めべき方向変えるような新しいデータに対して盲目的になってしまうことがある。ユーザーが良いアイデアと思ってくれるのなら、多少機能に不足があっても熱狂的に受け入れられたりする。こうして成功するプロダクト開発はモメンタムをすばやく形成できるもの。しかし友達機能の時、トンネルにいるような視界だったNetflixには失敗を受け入れられなかった。

 

6. サンクコストは無視せよ

「私達は多くの時間と労力を投入した。今さらギブアップはできない」こんな言葉が何度もあった。過去の資金やリソースの投入量だけで未来の投資判断をしてはいけない。自分自身に冷静に問いかけてほしい。「今日自分達が知っていることをもとに、どこまでリソースを投入し続けるべきか?」

7. より良いアイデアに対してはオープンに

Netflixは最終的に友達機能を開発したチームを他のチームに移しました。そのためには、偏見をもたないエグゼクティブが彼らの目を覚まさせ異動を後押ししていました。新しいアイデアやプロジェクトにオープンになってもらったのです。

8. 辛い判断でもあなたの役割上貫徹すべき

リーダー・マネジメント職やエグゼクティブの立場の人にとって、一番の仕事はバイアスのかかっていない判断を提供すること。その判断はプロダクトへのプライドや情からは離れたものであるべきです。5年にわたる努力をやめさせることを言い伝えるなんて、誰もやりたくありません。しかし、立場上やらざるを得ません。言わなくてはならないものは全うしましょう。

9. やめるべきプロダクトを適切にシャットダウンさせる

プロダクトをシャットダウンさせることは非常に難しいです。規律に沿った形で実行されるのはなかなかまれでしょう。Netflixは友達機能を「安楽死」させるアプローチをとりました。ユーザーにはかなり前からこの機能をやめることを通達し、なぜやめるかを説明し、どのようにユーザーがこの機能から離れられるかパスを提示し、同様のコンテクストで何度も説明しました。その結果、ユーザーからは大きな反発はありませんでした。

10. 失敗の遺産を既存のプロダクトに残さない

Netflixが友達機能をやめた時、サイトから当該機能を抹消しました。こうした徹底的な排除に失敗してしまった会社は、コーナーケースに遭遇するたびに本来のプロダクト開発の動きを遅くしてしまいます。シンプルで使いやすいUXを作り続けるために、実はこうした機能の排除(Sunsetting)が適切にできることが求められます。

 
The year 2010 brought about the end of Netflix Friends.
What barnacles should you scrape?
Screenshot: Tech-media-tainment


あなたのプロダクト開発は大丈夫ですか?

巧みなプロダクトマネジメントは、人・ビジネス・プロダクトについて、いかにベストな判断ができるかに依存しています。そのためには、Consumer science(データや定性的なリサーチやインタビュー、A/Bテストなどで仮説を構築検証するプロセス)を使えるだけでなく、使いこなすためにある程度の直感も必要です。市場で成功できる、消費者向けテックプロダクトを作るというのは本当に難しいものなのです。


プロダクト開発に携わった時、あなたの人間性は時として判断を曇らせてしまうことがあります。上層部の強い押し、社会・社内通念から距離を置きましょう。達成すべきゴールを設定し、あくまでそれに向かうことに集中。あなたの中で高まるプロダクトへのプライドを落ち着けて、自分に問うてください。

過去の自分達の時間・資金・労力の投入量にかかわらず、今日自分たちは何に力を向けるべきか?

 

もし自分がこのままでは失敗してしまうプロダクト開発のただ中にいるのなら、あえて声をあげましょう。そして失敗の産物を全て削ぎ落としましょう。こうした失敗によって研ぎ澄まされていったあなたのプロダクトセンスは、プロダクトマネージャーとしての成功確率を劇的に高めることになります。

 

編集後記

いかがでしたでしょうか?Gibbson氏があげた教訓はどのようなプロダクト開発に関わるPMであっても意味のあるもの。今プロダクト開発に関わる方は自分たちのPMを見て、また現在PMの人は今自分が行っていることをこうした教訓と照らし合わせてみて、どこを修正するとよさそうかぜひ冷静に見直してみてください。自分のPMレベルを一段ひきあげる良いきっかけになるはずです!

 

<お知らせ>
NetflixFacebookGoogleやその他シリコンバレーのスタートアップでどんなプロダクトマネジメントがされているか興味ありませんか?今年公開したシリコンバレー流プロダクトマネジメント入門講座は、多くの注目を集めており今では、Udemyのマネジメント部門でベストセラー、受講者100名を超えても高評価をいただいています!ぜひ2019年のスキルアップにご活用ください。

f:id:questpm:20190513065557p:plain



シリコンバレー流プロダクトマネジメント入門講座をリリースしました

f:id:questpm:20190103133321p:plain

 

本格的なPM入門講座をUdemyで。

明けましておめでとうございます!年明け初日に昨年度から作ってきたプロダクトマネジメント入門講座をUdemyでリリースしました。ツイッター上で以下のようにアナウンスしたところ、

 

 

プチバズしました。

f:id:questpm:20190103133601p:plain

 

多くの方がプロダクトマネージャーという仕事について興味を持っていただいていることをあらためて感じています。

 

講座を作ろうと思った理由

プロダクトマネージャーという仕事が日本で注目されている割には、経験者が体系的に説明している講座がないな〜 と思ったのがきっかけです。PM本として日本語訳の本がいくつか出ていますが、僕から言わせると一長一短で、「それを読めばOK」にはとてもならないですね。例えばよく日本のPMの話題がでるとよく参照されるInspired 第1版は10年以上前に書かれたもので、もはや参照するには古すぎる感があります。(日本語版は2015年に出版。今は原書で第2版がでています。)

questpm.hatenablog.com

 

ということで、シリコンバレーで日々PMとして戦う中で体得してきた「今のPMの姿」をよりタイムリーにお見せして、「PMってこういうことするんだ」という気づきをたくさんの人にお伝えしたいというのがモチベーションです。

 

興味を持ったら

1/6まで$30オフにてご提供していますので、年初のお休みのうちにぜひチェックしてみてください。ひとセッションが3分程度の動画で細切れにしてありますので、隙間時間や移動中に気軽に見ていただけます。リンクは↓

https://www.udemy.com/introduction-to-pm/?couponCode=OEIDFW

以下がイントロダクション動画です。


シリコンバレー流 プロダクトマネジメント入門講座 イントロ

 

「エンジニアのためのマネジメントキャリアパス」をPMの観点で読み解く

f:id:questpm:20181015134014p:plain


及川さん(@takoratta)さんに先日お会いした時におすすめしていただいたこの本。「エンジニアのための」とあるものの、PMの観点で読んでも読み応えがありました。学びのあった部分を一部紹介します。(ちなみに翻訳前のバージョンで読んでいるので洋書ベースの書評になります。)

Strategies for Saying NO (NOというための戦略)

PMは多岐にわたるステークホルダーと仕事をする以上、なんでもYesと言ってしまう八方美人では何も決まらず物事が進まない。Noと言わなければいけない場面も往々にしてある。そんな時どのようにうまくNoというかは非常に需要なコミュンケーションスキルの一つ。本書ではいかのオプションを提示しています。

 

 "Yes, and.."

まずは相手の意向を「Yes」で受け取る。その後に逆説的な表現でYesであるための意味を伝える。例えば、

"Yes, we can do this, and all I need to do is to delay the start of this other project which is currently on the roadmap."

というような表現。訳すと「それならできますよ。自分がしないとけないのはロードマップにある他のプロジェクトのスタートを全て遅らせることです。(-> それはかなり難しいですよね?ちゃんと他のステークホルダーにも相談しました?という裏の意味を含んでいる)」

 

Create policies

Noと言わなければいけない場面が多いのは、その裏返しとしてチームや会社としての「決まりごと」がないとも言える。例えば営業チームが「顧客AがXという新機能を必要としている」からといって、基本的なWhy/Whatや見込める収益も定義せずに提案していては当然PMからNoと言われて致し方ない。

リクエストがあるのなら、それが有効だと理解してもらえる情報群をしっかり集める。どんな情報群が最低限必要なのか、PMによる定義(もしくは会社による定義)がポリシーとなる。一旦これができれば、基本的にリクエストする側もまずはポリシーで決められた情報を集めなければいけない。PMが「XとYとZという情報が集まってから議論しましょう」とリクエストのたびに言う必要がなくなる。

 

"Help me say yes"

これは上のポリシーに近いかもしれない。自分としてはNoと言いたくないけど、Yesと言うためにはあまりにロジックや裏付けが弱いよ、というシグナルを伝えるための表現。そんな時にこの言い方が使える。ただ、その場合PMはYesというための基準がなんなのかを説明する必要があります。

 

Appeal to bugdet

PMがかかわるプロダクトチームの稼働状況について時間的・人的リソースの状況がいかにタイトかを伝えることで、"Not right now"(今はムリ)というシグナルを送るという方法。

逆に、PMから「今はムリ」と言われた側は「いつなら可能なのか」、「リソースをどこからか用意できれば可能なのか」をフォローアップすべし。PMのプライオリティーに関する意思決定を助けてあげれば、Yesと言わせることも可能。

 

Let's work as a team

自分一人でNoと言うより、チームとしての意思決定プロセスを経て決めようというリクエストのリダイレクト。

 

Don't *prevaricate(*言葉を濁す)

Noと言わなければならないのなら、後回しにしない。とはいえ、あまりに先走ってNoと言ってしまったらそれはあとで謝らないといけないケースもあります。ただ、時間価値を考えれば全ての決断マターに時間をかけていくわけにも行かない。であれば、その場を濁して、相手がどうしていいかわからない状況にしてしまうのだけはやめましょう。

 

”Say No"を使いこなすのはPMとしての一つのスキル

同じNoと言うにしても、一方的にはねつけるのではなく相手がアクションしやすいようにNoと言うほうがお互いのためになる。上記以外にも表現のしかたはあると思うが、大事なのは、"Responding positively but articulrating the boundary." 「ポジティブに反応しつつも、どこがYesの境界線なのかしっかり伝える」ということ。PMは「良い人」であるよりも「芯の強さと頭の柔らかさがある人」でいたほうが信頼されるし、結果的に関わる人の生産性があがるのだ。

 

(Strech goal) ぜひ洋書版にもチャレンジを

今回Management Pathを洋書で読んだが、読みやすい英語で書かれていてページ数も200ページくらいと薄い本。なのでそこそこ英語の読解力がある人なら、ちょっと自分にストレッチをかけるだけで読めるはずです。洋書と聞いて「そんなの無理」と避けてしまう前に、部分的に触るだけでもいい。筆者の生の声が読める原書は和訳とは違った学びがあります。つねに広い視野を要求されるPMとして、洋書を読めるようになると自分の知性の世界観が広がりますよ。

 

 日本語版   

 

洋書版