プロダクトマネージャーは攻守の要(ボランチ)だと思う
決勝戦はフランスの勝利。その裏にいた立役者
4−2というスコア以上にポグバの活躍がフランスの強さを支えたと思う。ボールを持ったときのエムバペの怖さがクローズアップされがちだが、フィールドを縦横無尽に動き、相手の攻撃の目を潰し、攻めてはパスをつなぎ、時としてエムバペに長距離のパスを何度か成功させた。そして自らもゴールを決めている。
彼の活躍ぶりはプレー時間を示したヒートマップにも現れていた。これはポグバがボールに絡んだエリアを色の濃淡で示したもの。
(ソースはスポーツデータサイエンスで有名な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日後にまたフォローアップすればいいんじゃ?と考える人もいると思いますが、実はこの時点であなた自身とメッセージの受け手の生産性を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の何がすごいのか(後編)
前回の記事をご覧になっていなければ↓からどうぞ。
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にしてください。期間としては1年分はほしいところ。
機械学習のキモ
機械学習というと、慣れていない人からすると何をしているのかよくわからないという人もいると思います。ですが、実はやっていることは大きく分けて下の5つのステップだけ。
1. 元データを取り込む
2. データを整形する
3. 機械学習モデルの選択
4. モデルに学習させ、精度をテスト
5. できあがったモデルを使う
精度が悪ければ3と4を繰り返し、必要に応じてチューニングします。
こう見ると難しくないですよね?至極真っ当なことをしてるだけです。
FB Prophetを実際に使ってみる
上の5ステップに従ってコードを書くとどうなるか見てみます。
ステップ1
モジュールのインポートと、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')
ステップ2
次にデータを整形します。
test_df['y'] = np.log(test_df['y'])
これはy列の数字が大きな値だったり大きく変動している場合、予測にかけると未来の値がとてつもなく大きくなってしまう場合があります。そうなると見づらいので対数をとって見やすくするのがこの一文です。
ステップ3
モデルを選びます。といってもfbprophetは一つしかないのでこのまま書くだけ。
model = Prophet()
ステップ4
学習させます。
model.fit(test_df,algorithm='Newton')
model.fitの関数が上のtest_dfを取り込んでいるわけです。
ステップ5
実際に走らせます。
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
コインチェック問題をプロダクトマネジメントの観点で眺めてみる
Problem = Opportunity
コインチェックのニュースを見るたびに、もしこの会社がもっとプロダクトマネジメントをちゃんと実践していれば・・とつくづく思う。もちろん被害者に対して然るべき返済はあって当然。だが、この件でスタートアップは脆いな・・と一概にとらえて思考停止に陥るのは最も避けるべきこと。この事例から何を学び、次にどうするか、その積み重ねが日本のスタートアップ文化を育む。「問題」は、次の進化への「機会」と捉えるほうが意味がある。
コインチェック事件のシリコンバレー的受け止め方
今回の事件をうちの同僚のプロダクトマネージャー達に話してみた。そして共通して聞かれたことがある。それはこの会社はCTO=PMで成長ステージを爆走してしまったこと。もちろん会社がアーリーステージ(40〜50人以下)で小さいうちはそれで何も問題ない。具体的にはProduct Market Fitが確立されるまではCTOがPMを兼任することはシリコンバレーでもあたりまえ。
コインチェック(以下CC)の場合、仮想通貨のドメインで初心者ユーザーが使いやすいUI/UXを作り込み、取り扱える通貨を増やして差別化要因にした。結果、利用者数が昨年の7倍の6万9000人へ増え、多いときは一日1200人の登録、NEMの利用者数が26万人、月間の取引高も日本最大ということで、Product Market Fitは見つけるステージは乗り越えていたと言っていい。
なので、CCはGrowthステージ真っ只中にいる会社だ。0から1を作れたのなら、次は1を100に、1000にしていく。0->1とは全く異なるスタンスが必要になる。ということは求められる人やスキルが変わってくるということであり、CTO含む、創業メンバーも仕事のしかたを変える必要がある。
コインチェックにおけるプロダクトマネジメントの軽視
あくまで外側から見える情報でしか判断できないが、コインチェックではおそらくプロダクト開発体制をステージに合わせて整えることに重きを置いていなかったように見える。例えば、以下の求人サイトで和田氏自らが語る言葉を見て、そう思わざるを得なかった。
このサイトの中ほどに、以下の発言がある。
ウチにはまだ「ディレクター」という役割の人間がいません。ディレクターがいなくても、エンジニアとデザイナーでどんどん機能追加や改善を進めてくれるので。
ここで言う「ディレクター」とはおそらくプロダクトマネジャーに相当する人のことを指していると思われる。自分から言わせればこれは危険きわまりない。
例えばコインチェックのサイトを見ると、以下のプロダクトラインがある。
おそらくここから想像するに、チームは取引所、決済、モバイルアプリ、付帯サービス系、バックエンドといった感じで5チームに別れていたはず。(もし別れていなかったら、統率が取りづらくロードマップも定まらない。少ないリソースでは進むべき方向に一点集中すべきなのに、焦点が分散して非常にまずい。)
CCは社員数71名。スタートアップの典型的な社員構成で考えるとR&Dリソースがおそらく35〜47名。だとすると1プロダクトラインでエンジニア、QA、デザイナーが合わせて7−9名ほど。残りは営業、マーケ、カスタマーサポート、バックオフィス、管理部門となる。
スタートアップとて、これだけプロダクトが別れ、人が分散すると自分の所属しているチーム以外が何をしているのか、見えなくなる瞬間がでてくる。また全体としてどこに向かうのかを常に照らす必要もでてくる。ところがCCには明確なPMがいない。ということは当然CTO=PMという体制になってくる。
Growthステージにおける、CTO = PMの弊害
このレベルの組織になってくると、本来なら各プロダクトライン担当のPMが打ち手をデザインしていくことが求められる。そして、ライン間でプライオリティーやリソースの調整が発生する。もしこれがCTOに全ての権限が集中していたらどうなるか。あまりに検討要素が多すぎて、そこに合理的な議論や判断のプロセスが抜け落ちてしまうのだ。そしてとにかく短期的なGrowthに貢献するものを最優先するようになる。最後は、CTOの「好み」で最終的にプライオリティーづけされてしまう。無論、全ての意思決定においてとは言わない。しかし、この規模の組織になってくると正直1人のPMで全てのプロダクトの行く末を決めることは不可能だ。
スタートアップCTOにはもちろんPM以外の仕事もあるわけで、グロースステージに行けば当然イグジットを視野に入れた開発も取り入れなければいけない。例えばセキュリティーや法規制対策、その他マクロ要因に付随するもの。なぜならIPOには厳密な監査プロセスがあり、プロダクトの作り込みや見通しが甘いとあれやこれや指摘され、急遽作り直さないといけない事態になる。特にこうした金融系のスタートアップの場合、この辺がゆるいとビジネスの根幹をゆるがす。
例えば、グローバルにビジネスを展開しようとする場合、今年5月に施行されるGDPRというEUの法規制に直面することになる。これはEU域内で有効になるプライバシー情報の扱いに対する法律だ。日本ではEUにおける「忘れられる権利」が保護されるということで以前少しニュースになった。もし何も対策をしていない、少なくとも対策を進めていないと制裁金2000万ユーロ(約26億円)か、年間収益の4%のどちらか大きい方を徴収という罰則規定がある。下手をするとスタートアップの収益が吹き飛びかねない。
こうしたマクロ環境への対応はCTOがどのタイミングで開発を始め、いつリリースするのかを率先して決めて、PMとすり合わせをしないといけない。個別の開発で満足している場合ではないということ。CCの場合は「エンジニアとデザイナーでどんどん機能追加や改善を進めてくれる」とのことだが、はたしてその中にどれだけマクロの観点から議論されていたかは疑問だ。
個別のPMも、当然広い視野、長短両方の時間間隔は必要だが、ことCTOは長期的な視野で見ないといけない立場。CCの場合グロース優先で視野狭窄に陥り、イグジットという観点から見た必要なプロダクト開発を置き去りにしたのだろう。それがセキュリティーの欠陥という形で利用者に迷惑をかける事態になった。
成長ステージに必要なのは自由と規律、短期と長期のKPIのバランス。
CCの問題はアーリーステージからグロースステージへの進化に失敗したスタートアップの事例だと考えている。エンジニアやデザイナーに自由度をもってもらうことは私も反対しない。しかし、以前のブログでも書いたように成長ステージではPM一つとっても様々なタイプが必要だし、シリコンバレーで成功しているスタートアップで、CCのような体制で成長ステージを切り抜けた会社はないといっていい。CTO1人でPMをこなせるものでもなければ、エンジニアとデザイナーの裁量だけにまかせるのも間違っている。このステージに必要なのは、トップマネジメントとPM、開発チーム、デザイナー、バックエンドといったプロダクトチームの健全なテンションだ。自由と規律、短期と長期のKPIのバランスをどうとるかは会社しだい。どちらか一方では破綻する。
今スタートアップを展開している方たちには、ぜひこれを機にプロダクト開発体制を見直してみることをおすすめする。
2017年にアメリカで最も売れたビジネス書、"Life and Work Principles" には良質な問いかけが満載
Bill Gatesも一目置く、Ray Dalio
I always learn a lot from my friend @RayDalio. His new book #Principles is a remarkable look at his life and career: https://t.co/2A4EREQLYU
— Bill Gates (@BillGates) September 29, 2017
Bridgewater Associatesという名前はヘッジファンド業界以外の人にはあまりピンとこないかもしれない。この会社はRay Dalio氏が立ち上げた、世界一のヘッジファンドだ。2位のAQR Capital, 3位のJPMorgan Asset Managementを足しても追いつかないくらい巨大な存在だ。ファンドの規模は12兆円。その彼の著作である"Life and Work Principles"には、投資哲学を始め、彼の生活・仕事・組織において最大限のアウトプットを出すための原理原則がまとめられている。彼がどのように考え、どのようにBridgewater Associatesを育ててきたかが浮き彫りにされているのだ。