プロダクトマネージャーがすべきプライオリティーづけについて

 PMが開発要件に関して「全て大事」と言ってきた。

本当に迷惑ですよね。そのプロダクトを作る際に何が一番大事かを知りたいのに、「全部大事」と言ってくるプロダクトマネージャー。困るんですよ、開発する側から言わせると。当然コストも時間もかかるし、クオリティーを担保するのも一大事。ゴールがとてつもなく遠く見えてしまう。プロダクトチームとしてビジョンに一向に近づかない、枝葉にとらわれて森を見ず、何も進まないという状況に陥ります。PMが「全て」という言葉を使いだしたら、それはそのPMが思考停止していると言ってもいい。こういうことはシリコンバレー企業ではまず起こりえません。それはなぜか？

PMがすべき大事な仕事、それはプライオリティーづけ

プロダクトマネージャーはプロダクトの運命を決める人であり、ユーザーエクスペリエンスとそこからあがる収益に責任を持つ人です。それは最初のプランニングから、リリースしてユーザーが定着して収益がついてきて、最終的には次期バーションにユーザーを載せ替えるところまでも場合によっては考えます。

そのEnd to Endのサイクルは短いと数週間、長いと年単位の期間になるもの。当然開発する側からするとサイクルが短かろうが長かろうがScope of Workが適切でなければ作れるものも適切に作れなくなる。GAFAクラスの企業でもなければ潤沢なリソースがないので、必ずどこにフォーカスするのかを決めなければ、プロダクトチームのメンバーも会社自体も「一体PMはどこに向かっているのか？」という疑問を持つことになります。こういう空気が出てきてしまうのはPMとしては負けです。シリコンバレー企業ではPMのこのプライオリティーづけがスタートアップから大企業まで徹底しています。ここをうまくできないPMは評価されない。

だからこそPMは「全て大事」などと軽々しく言うのは間違い。プロダクトチームおよび、会社に対して、その期間はプロダクト開発のどこにフォーカスして何にプラオイリティーを置くかをクリアに伝えなければいけない。

プライオリティーづけでPMが意識すること

では「全て大事」と言ってしまうPMの何が問題か？それは「判断の軸」がないこと。優先度を決めるということは個別のアイテムを比べてどちらが上か下かを決めることであり、そのためには判断の軸がなければ無理。自分がこの地でPMを経験してきてひしひしと感じるのは、軸とは「インパクト」につきる。これを分解すると、

1. 短期・長期的に会社として達成したいことへのインパクト
2. ユーザーへのインパクト（UI/UX的に。Customer Wow Factorと呼んだりもする。）
3. KPIに対するインパクト（ユーザー継続率や収益性など、どのくらいKPI向上に効果ありそうか）
4. フロントエンド・バックエンドへのインパクト（開発負荷・運用負荷という点で）

が代表的な軸。

PMはこうした軸を使ってプラスのインパクトとマイナスのインパクトのそれぞれの大きさを評価していく。当然マイナスのインパクトが大きければ、対策をするというよりも、一歩引いてそもそもなぜそんなにマイナスのインパクトがあるのかを考える。その結果として開発スコープを変更したり、狭めたりするなどしてインパクトのコントロールを行う。

PMがするプライオリティーづけはアートとサイエンスの掛け算である。

上の1,3,4に関して、もし社内でデータ化ができていないのならまずは会社としてこうした部分を数値化することを始めてください。この地のスタートアップも大企業もどの会社もPMがプロダクトに関するデータを自由に取得できる状態です。なのでSQLを叩いてデータ取得して、Pythonで加工してビジュアライズとかも自分も普通にやります。語るならデータなしには語ってはならないというのが徹底しています。

上で言うCustomer Wow Factorは計算で求められるものではないものの、PMがデザイナーと議論して1(low) - 10 (high)の間で感覚でスコアを決める。ここは完全にアートの世界。PMとしてのユーザーに対する理念やセンスが問われるところ。

従いプライオリティーづけは1,3,4のサイエンスの部分と、2のアートの部分の 「掛け算」。どちらかがゼロだとそのプライオリティーづけは裏付けがなくなってしまい、後々なぜそのプライオリティーづけで良かったのか（悪かったのか）きちんとトラックできなくなってしまう。4つの軸がなければどう決めてよいかわからず「全て大事」となるわけだ。

PMの仕事の面白さは0->1を作るだけではない。作ったプロダクトを不確実性の中で進化させ、チームや会社のサポートを正しい方向に導く指揮者となる部分にもある。このプライオリティーづけは多様な知識と経験、アートとサイエンスな洞察力をミックスして行うもの。今までなんとなくプライオリティーを決めていたのであれば、ぜひ上の軸を意識してやってみてください。ステークホルダーの納得感が変わり、何をすべきかがより明確になります。

Silicon Valley Workersさんにインタビューしていただきました

サンフランシスコにある音楽系アプリのスタートアップ『Smule』にて、シリコンバレーでも数少ないPrincipal Product Managerの称号を持つ曽根原さん (@Haruki_Sonehara) に、プロダクトマネージャーのあり方についてお伺いしました！
IT系の人は必見です！https://t.co/Ufm4uxPE2y via @SVWorkers

— 中屋敷量貴@シリコンバレー (@Kazuki19911230) July 26, 2018

Silicon Valley Workersというウェブメディアがあるんですが、そこでインタビューされた記事が公開されました。日本からやってきてどのようにシリコンバレーの外資の中でPMになり、現地のスタートアップでどんなことを考えてプロダクトマネジメントをしているのかが垣間見れます。グローバルにキャリアを展開してきた一つの事例として読んでみてください。

プロダクトマネージャーは攻守の要（ボランチ）だと思う

決勝戦はフランスの勝利。その裏にいた立役者

４−２というスコア以上にポグバの活躍がフランスの強さを支えたと思う。ボールを持ったときのエムバペの怖さがクローズアップされがちだが、フィールドを縦横無尽に動き、相手の攻撃の目を潰し、攻めてはパスをつなぎ、時としてエムバペに長距離のパスを何度か成功させた。そして自らもゴールを決めている。

彼の活躍ぶりはプレー時間を示したヒートマップにも現れていた。これはポグバがボールに絡んだエリアを色の濃淡で示したもの。

（ソースはスポーツデータサイエンスで有名なOpta社のデータが出ていたサイト。） 

今大会を見ていて、つくづくプロダクトマネージャーってのが攻守の要ボランチとスタイルが一緒だな〜と思わせることがたくさんあった。実はこのメタファーこそPMの理想的な動きを表す一つの格好の事例なのではないかとも思う。今日はそのことについて。

期待はずれどころか、悪い意味で期待通りなアルゼンチン

メッシは選手として好きだが、アルゼンチンには期待していなかった。彼に任せておけば大丈夫という空気が蔓延していたからだ。

アルゼンチン代表はロシアW杯の予選18試合で19ゴール。そのうち1/3はメッシで、残りは他のメンバーだが誰一人3ゴール以上あげたものはいない。（ディマリアが唯一2ゴール。FWのアグエロに至ってはケガもあってゴールなし。）代表124キャップで6度もハットトリックを達成していれば、監督だってチームだって彼に任せたくなる気持ちは当然ある。(Source: Forbes)

だが、今回のW杯の結果を見ての通り、スーパースターが率いるチームは、彼の好不調もしくは相手チームによる封殺や寸断によってチーム力がガタッと落ちてしまうのだ。

なぜなら他のメンバーが自律的に動けず、つねにメッシを探しているから。今回のグループリーグ敗退は順当負けだったのかも知れない。

同じことがPMの世界に起こったらどうなるか？

PMは仕事柄、会社のいろんな部署の人と話すし各々やっていることが見える。いろんな情報にアクセスできるし、おのずと集まってくる。それがPMとして全能感に陥り過信になったときが一番危ない。そのPMのやることなすこと当たりまくり、そのPMの言うことに従ってプロダクトを作っていれば大丈夫、そんな「当たっている」ときは良い。だが、外れた時、不調になった時に悲惨になる。自律性を失ったチームはいつまでも不機嫌・不調なPMの顔色をうかがい、どうすべきかクリエイティブな答えを自分たちで見つけ出してチームで議論するということができなくなる。やがてプロダクトチームの誰もPMを信じなくなり、会社の競争力を大きく削ぐことになる。それこそアルゼンチンの二の舞。

スタートアップとしては命取りだ。

だからこそあえて言いたい。PMをスター扱いする必要もないし、逆にPMだからといって一方的に上から目線はやめたほうが良い。あくまでプロダクトチームの一人という姿勢は崩さない。キャプテンマークを巻く程度の感覚。PMの成功はプロダクトチームが連動して動き、ユーザーに喜びを提供することであるはず。決めるべきときは率先して決めるが、基本はチームプレイ。

PMと攻守の要（ボランチ）の共通点 

そんな姿は日本代表のボランチ柴崎にも重ねて見て取れる。日本の多くの人が感動したベルギー戦。柴崎は攻守に渡ってチームに貢献した。彼の動きを示したヒートマップを見てほしい。

（ソースは同じくこのサイトから）

そして、彼が出したパスの位置と受け手のデータ。フィールド全体を使い、様々なポジションにパスを出す視野の広いプレースタイルが見て取れる。

パス＝PMにとってのコミュニケーション

PMの動きもこれに重なる。ある時はマーケとプロダクトのLaunch戦略を、ある時は法務とGDPR対策を、ある時は上層部と長期的なロードマップを、ある時は財務とプロダクトのROIを、PMはボールの受け手（コミュニケーションの受け手）が受け取りやすいパス（=メッセージ）を常に出さなければいけない。

パスをもらった相手が次に動きやすくなければいけないのだ。サッカーで例えるなら、前を向いてボールをもらえる、ポストプレーしやすいように足元に落とす、といったところか。PMで言えば、メッセージをもらった側がその人のポジションの中で何をするかが明確ということ。そのボールをもらって次にどうしろと・・と思われるようではPM失格だ。

また、ポグバや柴崎のようにフィールドのどこかに偏るのではなく、試合の状況に応じていろいろなところに顔を出しては味方を助けたり、自分でゴールへ向かう。PMとて同じ。プロダクトチームのメンバーを、そしてサポートしてくれる人たちを孤立させてはいけない。自分が前に出るときは出るし、誰かに出てもらうときにはしっかり後方支援する。

これまでの日本代表の中で一番よくボールが周り、ゴールにつながり、チームとしてまとまっていた裏にはこの柴崎の動きが強いアクセントになっていたのは間違いない。そうしたポグバや柴崎の働きに、PMが機能したときのプロダクトチームの躍動感がかなり重なると思った次第でした。

イニエスタクラスのボランチともなると「フィールドの皇帝」と呼ばれるように、PMは「製品のCEO」。そのパフォーマンスはプロダクトチーム全体に、ひいては会社全体に影響する。

PMってどんな動き方をするのが理想？と思ったときに今回の記事が一つの参考になれば幸いです。 

それ何の話だっけ？と言われた人に効く、会話の効率を上げる4つの視点

身近で起こっている働き方改革の足かせ: コミュニケーション

ここ数年ビジネスの世界では、ChatworkやSlack, Skypeなどチャットを使ったコミュニケーションが当たり前になってきました。手軽に会話できるのは良いのですが、同時にチャットだけだと話がこじれてしまう場合もあります。

ことプロダクトマネージャーのような役割だと関わる人が増える一方、自分のコミュニケーションスタイルがそのまま相手にも同じように通用するとは限りません。あるときはほとんど関わったことのない別チームのエンジニアだったり、法務部門や財務部門の非技術系、常に時間のないエグゼクティブなど様々です。

こういう時サクっとチャットで「これお願いします」といったところで、聞いてくれることは殆どいないでしょう。返事がなければ２，３日後にまたフォローアップすればいいんじゃ？と考える人もいると思いますが、実はこの時点であなた自身とメッセージの受け手の生産性を2−3日分失ったことと同じ。「それ何の話しだっけ？」と言われておしまいです。そんなことが毎日どこかで、仮に全社員の50%以上で起こっているとしたら・・・これでは働き方改革どころではありません。

会話の効率を上げる4つの視点

プロジェクトがグローバル化してくると、ここに時差や文化の違いが絡んできてさらにコミュニケーションがうまくいかなくなる場面がでてきます。こうした問題にどう立ち向かうか？

会話の効率を上げる抑えるべき4つの視点とは、

Time
Place
Control
Information processing

です。

この4つの軸には目盛りがあります。

Time軸は相手のチャンネルが最もオープンな時を選ぶ

Time軸で考える際に必要なのは、相手が最も話しを聞いてくれる時間帯はどこかということです。その人は朝方でオフィスに来るのか、遅出で10:30過ぎないとこないのか、夜は社内に残る方かそうでないか、などです。相手が受け取りやすい時間帯でないと、後回しにされます。

Place軸は残したいメッセージのインパクトに応じて決める

どうしても相手に理解しておいてもらいたい、ならばメールを送って済ますのはやめましょう。ちゃんと電話やビデオ会議を予定すべきです。（対面が可能な場合はそれもありです）チャットはしょっちゅうやりとりしている人たちであれば最速で効率は抜群ですが、こちらはとても重要だと思っているのに、相手が同じレベルで感じてくれない、インパクトが残らない可能性があります。またあまり顔見知りでない人、込み入った話しの場合は一度はPlace軸のレベルをあげましょう。（メール・チャットより電話会議、ビデオ会議より対面といった形）

Control軸は「仕切りたい」度合いの差

何かをお願いする時に、「それ自分に預けてもらえますか？」というケースと、「一緒にやりましょう」、もしくは「そちらでやってしまってOKです」といった「仕切り」の度合いが異なる場合がある。仕事の性質上だけではなく、その人のキャラ的にその仕切り度合いが変わってくることもあるのだ。抱えたい人、サボりがちなのでこっちでやったほうが（コントロールした方が）良い人など様々です。このあたりの見極めを間違えると、余計に時間がかかってしまうことになります。

Information Processing軸は相手の情報処理能力の速さ

コミュニケーションする相手がどれだけ情報処理能力がある人なのかも重要な要素。例えば相手がプリントアウトしてじっくり読んでからでないと反応できない人なのか、ランチオンミーティングで諸々説明したらすぐに分かってくれるような人なのか、もしくはチャットで少し話せばすぐに答えてくれるのか、情報処理能力の速さは、単に頭の回転という意味だけではなく、相手と共有している文脈の多寡も影響してきます。

ゴールはCommunication Costを最小化し、インパクトを最大化すること

 ごく当たり前に行っているビジネス活動も、コストの上に成り立っています。全てのコストが悪いということはありませんが、プロフェショナルとして働くのなら少なくとも無駄なコストを最小化する行動はあって然るべきです。

コミュニケーションは当たり前のように行われるがゆえに、簡単に見落としがちなもの。実は無駄が簡単に発生しやすいのです。そのおかげでお互いの生産性が下がるということはコミュニケーションコストが高いということ。

しかし上記4点の視点を意識すれば、明日からでもコミニケーションコストがどんどん下がり、仕事が効率よく周る（仕事のインパクトが上がる）ようになるはずです。ぜひやってみてください！

知らないと痛い目にあう、5Gを使ったアプリ開発 - Part 2

5G時代を見据えたByton社のConnected car (Autoweekより)

5Gの何がすごいのか（後編）

前回の記事をご覧になっていなければ↓からどうぞ。

questpm.hatenablog.com

5G以前のネットワークアーキテクチャーだと遅延やデータロスの影響をモロに受けるという話しをしました。では5G以降はどうなるか？早速下の図を見てみましょう。

 5G後

お気づきになったと思うが、5Gの無線施設のそばにエッジコンピューティングサイトができている。これこそが5Gのキモ。エッジコンピューティングサイトはある種の小規模データセンターです。通信キャリアにとって5Gを導入するといのは、こうしたサイトをアプリ開発者や利用者のために準備するということでもある。逆に言えば5Gを利用したアプリというのはこうしたエッジコンピューティングサイトでアプリのバックエンドを動かすことにほかならない。ユーザーからすれば、この存在のおかげで遠く離れたデータセンターやクラウド環境へアクセスする頻度は少なくて済むということ。（その分体感速度は大幅に上がる）

ちなみに実際のエッジコンピューティングサイトは以下の写真のような感じ。 

奥の塔が5Gの電波塔、手前がVaporIO社のエッジコンピューティング施設 (Datacenter Knowledgeサイトより）

従って5G以前と比べてこのアーキテクチャーのなにが優れているかというと、ユーザーの端末から上の図の右端のデータセンターやクラウドサービスへのアクセスで発生する遅延やデータロスを大幅に減らせるというところになる。

5Gを使ったアプリを作るために知っておくべきこと

モバイルアプリ開発者にとって魅力的に見える5Gだが、重要な制約条件がある。それはエッジコンピューティングサイトから端末までの距離だ。あくまでこの距離と5Gで対応可能な電波の範囲でパフォーマンスが決まる。

例えばUSの通信キャリアは都市圏にいくつかのエッジコンピューティングサイトを設けるようなので、そこを勘案するとそのサイトから50−100キロ圏内が5−10−100の5Gのパフォーマンス範囲ということになる。

逆に言うと5Gだ、10Gbpsだと盲目的に信じたところで日本からインド、日本からUSが5ms以下の遅延になるわけではない。地球の裏側のいるユーザーとリアルタイムで高解像度なVRアプリを動かすのは、5G環境になったとしてもかなりコストのかかる話なのは変わりはないのだ。

ドイツテレコムの事例 - ヒトの体に医療情報をリアルタイムで表示

先月末に行われたMobile World Congressでは各キャリアが5Gのユースケースを展示。上の写真はドイツテレコムによる医療現場で使われるユースケースの例。マネキンに対して5G端末をかざすと、その患者の身体内の情報が4Kの解像度でリアルタイムで配信される。

端末は体の3次元座標をカメラから認識し、この位置情報を送信。エッジコンピューティング側で画像をレンダリングし、端末へ高精細画像を送り返している。ネットワークの遅延が極端に低いので背中側にまわれば背中側からみた情報がきっちり表示され、ゆらしても素早く動かしても残像がでることはなく常に高画質だった。要は手元の端末が、ハイスペックなマシンと直接つながっているようなイメージ。

4Gから5Gへの進化が意味するもの - Experience Divide

5G時代を迎えるにあたってもう一つアプリケーション開発をする側が意識しておくべきことがある。それは「5Gデバイスを持つ者」と、「持たざる者」におこるユーザーエクスペリエンスの大きな差だ。私はこれをExperience Divideと呼んでいる。2回にわたって解説したように、5Gはアプリケーションのユースケースに大きな変化をもたらす。だが、それにアクセスできるのは当然5G端末を持っている人だけだ。

そのアプリが対象とするマーケットにもよるが、もしグローバルにアプリを展開するとなると、当然5Gデバイスを手に入れられないセグメントがでてくる。だがそういうユーザーも自社にとっては大切なユーザーには変わりない。そうなった時にアプリ開発側として5Gを持つものと持たざる者、そして持つものへと移行していくユーザーに対してどうユーザーエクスペリエンスを定義していくかは、ユーザーに使い続けてもらうアプリになるために重要な視点。

今年末から2019年にかけてUSや中東では5Gが商用化される。一方日本は2020年。まだ「先の話し」とたかをくくっていると、先行するUSの企業にまたしても市場を席巻されてしまいかねない。そうなっては遅い。今のうちから議論を始めておくことをおすすめします。

知らないと痛い目にあう、5Gを使ったアプリ開発 - Part 1

5Gの何がすごいのか

昨年から今年にかけておそらく5Gに関するニュースを見たり聞いたりしたことがある人は多いはず。ただ5G の何が今までと比べてすごいのか、5Gを利用するにあたって何に気をつけなければいけないのかをきちんと理解しているアプリ開発者は意外と少ないと感じた。なので今回はそのあたりをプロダクト開発の視点で2回に分けて解説します。

"5-10-100"  5Gの特徴3つ

5Gの特徴は大きく分けて3つ。低遅延・広帯域・同時接続性です。

遅延は5ms以下、帯域は最大10Gbpsまで、最大同時接続数は100万台サポート可能。
これだけだとピンとこない人がいるかもしれないので例をあげます。

例えばブルーレイDVDは1枚25ギガバイト分の動画容量あるが、5G対応デバイスはこれを3秒以内にダウンロードを終えてしまうことになる。これを4G/LTEでやろうとすると1時間以上かかってしまう。(実際にダウンロードするユースケースがあるかどうかは別です。）

次に遅延。使っているストリーミングサービスが海外サーバーへアクセスしていると、ひどい時は動画が止まってしまったり、画像と音声にズレがでたり、ローディングの画面からなかなか先に進まない、という経験をされたことはあるはず。これはネットワーク上の遅延が大きく関わっている。例えば日本からカリフォルニアにあるサーバーにアクセスしようとすると、それだけで120 - 200ms程度の遅延が発生する。低遅延というのはこうしたデータ転送のずれがほぼなくなり、データの出し手と受け手の時間の差がゼロに近づくということだ。

最大同時接続数は、一つの電波施設で処理できる端末の数。4Gだと4000台が限界だが、これが5Gになると100万台に一気に増加。ま、100万台全てが同時に25GBのダウンロードをすることは想定していないものの、これまでより高速でサクサクアプリが動くネットワーク環境を、多くのデバイスが同時に使えるとは言える。

なぜ低遅延、広帯域が実現できるのか？

上の3点の優位性がなぜ可能になったのか、モバイルアプリ開発の上で5Gの仕組みを理解しておくことはテクノロジーを正しく使うために重要。なぜなら往々にして優位性は制約条件とのトレードオフであることが多いから。その部分を正しく理解せずして5Gを使いこなすことはできない。なのでまずは5G前と5G後で何がどう変わるのかを比較してみます。

5G前

5G以前は、スマホでモバイルアプリを使ったり、ウェブサイトにアクセスするときにはキャリア側のネットワークやデータセンター、そこから別のインターネットを経由してAWSやGCPなどでホストされているサービスを使うことになる（下の図参照）。この場合アクセス先の距離によって、直接遅延やデータロスの影響を受けることになる。

もちろん遅延の影響を最小化する工夫をアプリ上で仕込むことは可能。（オンラインゲームはその典型）だが、もともと4Gは通常でもダウンロードで2−12Mbps、最大でも45-50Mbpsでれば上等というレベル。（Verizonの調査より）5Gのベスト時と比べれば1/200くらいのパフォーマンスしかない。

下のグラフは、もともと45Mbpsの帯域が4G環境で使えたとして、そこに遅延やデータのロスが発生した場合体感速度がとこまで落ちるかを表したもの。ここでは、縦軸のMaximum Throughputが体感速度とここでは思っていただいていい。50msの遅延とデータ送受信の際にロスが0.01%発生しただけで体感速度は半分以下に。200msだとおよそ1/9まで落ちる。 

(Aryaka社のサイトより)

なので上の5G以前のアーキテクチャーだと、遅延やデータロスの影響を直に受けることになり、例えばVRベースのアプリを8Kレベルの解像度のストリーミングで流すといったことは、ネットワークがボトルネックとなり非常に開発が困難なのだ。

こうした遅延やデータロスの影響をなくすために、5Gではアーキテクチャーのどこを変えたのか、そしてそれがどうモバイルアプリ開発に影響してくるかを次回解説します。

驚くほど簡単に予測できる！Facebook Prophetを使ってみた

プログラミングとプロダクトマネージャー

PMになりたい人と話していると、よく出てくるのが「プログラミングは必要か？」という質問。自分は「必須ではないが、できると仕事の幅が間違いなく広がる」と答えるようにしている。

自分は決してGeekなプログラマーではありません。あくまで趣味ベースでPythonを書ける程度のレベル。ですが少しでもできると、今回紹介するような機械学習を使った時系列データの予測が簡単にできるようになります。

まずは何を予測したいか決める

Data Drivenな会社であれば、おそらくユーザーがどのようにプロダクトを使っているのか何らかの形でログをとっているはず。例えばあなたがソーシャル系アプリのPMだとして、ユーザーがどのくらいコメントを投稿するかを時系列で予測したいとしよう。

今回はFacebook ProphetというFacebookがオープンソース化している予測モジュールをPythonで使います。

データを集める

FB Prophetは取り込むデータの形式について決まりがあり、下のような感じの時系列データを用意してください。

ds,y
...（省略）...
10/18/17,5149823
10/19/17,5045734
10/20/17,5212312
10/21/17,5350494
10/22/17,5245749
10/23/17,5142039
10/24/17,5098498
10/25/17,5012391
10/26/17,5043982
...（省略）...

CSV形式でdsがタイムスタンプ、y列の部分が日毎のトータルコメント数です。（数字はすべてダミーです。）ラベルは必ずds, yにしてください。期間としては１年分はほしいところ。

機械学習のキモ

機械学習というと、慣れていない人からすると何をしているのかよくわからないという人もいると思います。ですが、実はやっていることは大きく分けて下の5つのステップだけ。

1. 元データを取り込む
2. データを整形する
3. 機械学習モデルの選択
4. モデルに学習させ、精度をテスト
5. できあがったモデルを使う

精度が悪ければ３と４を繰り返し、必要に応じてチューニングします。

こう見ると難しくないですよね？至極真っ当なことをしてるだけです。

FB Prophetを実際に使ってみる

上の５ステップに従ってコードを書くとどうなるか見てみます。

ステップ１

モジュールのインポートと、Python PandasでCSVファイルのインポートを行い、test_dfとしておきます。

from fbprophet import Prophet
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt

test_df = pd.read_csv('./csv/daily_data.csv')

ステップ２

次にデータを整形します。

test_df['y'] = np.log(test_df['y']) 

これはy列の数字が大きな値だったり大きく変動している場合、予測にかけると未来の値がとてつもなく大きくなってしまう場合があります。そうなると見づらいので対数をとって見やすくするのがこの一文です。

ステップ３

モデルを選びます。といってもfbprophetは一つしかないのでこのまま書くだけ。

model = Prophet() 

ステップ４

学習させます。

model.fit(test_df,algorithm='Newton') 

model.fitの関数が上のtest_dfを取り込んでいるわけです。

ステップ５

実際に走らせます。

future_data = model.make_future_dataframe(periods=12, freq = 'm')
forecast_data = model.predict(future_data)

model.make_future_dataframeの部分はどこまで先の未来を予測するかを定義しています。periods=12, freq = 'm'の部分で「12ヶ月先」と定義しているわけです。もしくはperiods=100, freq = 'd'とすれば100日先の予測となります。

model.predict(future_data)で実際に走らせます

グラフに表してみる

model.plot(forecast_data)
plt.show()

自分のMacbook Proだと、1年先くらいのデータだと1分もかからず処理が終了。model.plotでグラフを作り、plot.show()でグラフを画面に出力します。

すると、こんな感じで表示される。

機械学習のコードを自分で作り上げると大変だが、fbprophetを使えばたった10行ほどでできてしまう！

PMとしてFB Prophetを使う時に考えるべきこと

上のサンプルでは一次元データで予測を行ったが、もちろん他の因子を追加することも可能。例えば上の元データにLikeの数を追加して予測したい場合は、add_regressorというメソッドがあるのでこれを加えればOK。詳しくはドキュメントを参考に。

予測は予測にすぎず、確実に起こる未来ではありません。プロダクトマネージャーとして大事なのは、目をつけているKPIが先々どのように変わりそうか、その振る舞いの意味することは何か、大きいほうに触れた場合インフラ的にさばき切れるのか等々、様々な論点を抽出するところにある。

データサイエンスチームを巻き込んで、さらに突っ込んで分析してみるのもアリ。あいまいな状態からいかにクリアな議論へと昇華させていくのは、PMとしての腕のみせどころ。ちなみにUSではこのような姿勢を"Move the conversation forward"という言い方をします。

こうした予測を活用すると、今気づいていないことを前倒しで気づけるということが可能になってきます。後々「こんなはずでは・・」という事態を最小化できるので、ぜひ使ってみてください。またPMへの活用の仕方がイマイチわからない、もしくはこのようなケースにつかえるのか？等々ご質問があれば、遠慮なくご連絡を。

今回のコードはこちら。
github.com