プログラミングの世界では、 ソースコードレビューがかなり一般化されたように思う。モダンな開発手法を取り入れている現場では、どこも プルリク → レビュー → マージ → リリース という手順を踏んでいるんじゃないだろうか。
進化したコードレビューと比較して、ほったらかしなのが Excel である。
私は仕事がら、事業計画書をしょっちゅう作る。
↓ こういうやつだ。
作った事業計画は経営者や上司、投資家などのチェックに回るのだが、この中にある数式をきっちりレビューする人を、ほとんど見たことがない。
一見それっぽい上記のグラフだが、セルの中身をがどうなっているかというと、売上が毎月100万円増えると "計画上、決めている" 。ビジネスとしては「んなアホな」と思われるだろうが、事実、売上計画が定数決め打ちになっている事業計画は山程ある。
また、広告費は売上の20%で "逆算している" 。売上は増えることになっており、広告費は売上からの逆算であるから利益が出るのは当然、ということになる (あくまで計画上)。
この例では、例えばPMFが見えるまで売上は広告費と相関しない点や、マーケティングの効用は逓減する点、効率のよいセグメントが見つかったとしてもやがてサチる事実は隠蔽されている。
事業計画は「数値」ではなく、「数式」を見る
センスのよい投資家は、事業計画から「売上」のような絶対値ではなく「ビジネスの構造」を見る。
広告効率が粗利を下回れば規模のビジネスに発展させることができる「プッシュ型」ビジネスなのか、ネットワーク効果が最大化すれば広告投資対効果が指数関数的に改善する「ネットワーク型」のビジネスなのか、LTVが総コストを上回れば単月赤字でも成長できる「サブスクリプション型」なのか、そのビジネスの「型」を、事業計画から理解する。
収益性改善には「KPI」ではなく「変数」に注目する
アイデアはよいが、計画上お金が回らないビジネスがある。そのような場合は、計画を構成する「変数」を改善する。例えば、物販だったら仕入原価、メディアだったら人件費、SaaSビジネスだったら開発費と営業コスト。
APPUやROASのようなKPIは、計画時点では改善できずあくまで見込みであるため議論をしても時間の無駄だ。また、KPIはサービスの認知率や事業ステージによってドラスティックに変化する。二次関数的な事業計画は、サービスがローンチされればすぐに使い物にならなくなるだろう。
グラフや数字ではなく、「数式」をレビューして欲しい
先ほど挙げた例はごく簡単なものだが、実際に現場で使われる事業計画はもっと重厚長大で難解なものだ。それゆえ、表面的な数値がどう算出されているかはブラックボックス化され、承認する側は右肩上がりのグラフを見ながら気になったポイントだけをチェックするようなレビューになりがちだ。
だが、きちんと調べてみるとロジックに明らかなバグがあることも少なくない。事業の是非を判断する重要なソースに、瑕疵があることは許されるべきではないだろう。
意図的に隠蔽されている情報
人が作るロジックには意図が含まれる。そこには、様々な利害が入り込む余地をレビューする人間は理解しておくべきだろう。
金融機関が、壮大なExcelをわざわざ紙で印刷して持ってくることがある。なぜ紙でなければならないのか。単なる親切心であればよいが、全く別な意図である可能性は潰して置かなければならない。
部下が、スマートな成長曲線を示してきた。本来ビジネスはそんなに簡単には右肩上がりにならないが、そこに込められた思いを信じて賭けるのか、リジェクトするのか。
人が作るロジックには意図があり、交錯するビジネスマンの意図がプロダクトを、サービスを作り出す。
金を出す人間は、そのことにもっと自覚的になるべきであり、絶対に手を抜いてはならない。
