コインチェック問題をプロダクトマネジメントの観点で眺めてみる
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名。だとすると１プロダクトラインでエンジニア、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のバランスをどうとるかは会社しだい。どちらか一方では破綻する。
今スタートアップを展開している方たちには、ぜひこれを機にプロダクト開発体制を見直してみることをおすすめする。
