ただしいリリース予定とバッファの積み方
前提として
以下のような企業を想定しています
- SaaS提供しているスタートアップ
- SaaSプロダクトはガチの0→10段階ではなく、10→100段階をイメージしています
- SaaSプロダクトを内製開発してます
- VCから資金調達をしています
- VCに対して説明責任があります
御社はVCに事業計画と今年の数値目標を説明しなければいけません
VCは御社に資金を出資しています。
そのため定期的に取締役会が開かれ、VCの人の前で今期は売上がこれこれで、費用はこれこれで、KPIは〜という説明を行います。
売上やKPIの伸びについて根拠を説明しなければいけません。
「おぼろげながら浮かんできたんです。ARR+200%という数字が」
みたいなことを言ったらVCの人にグーパン食らった挙句、出資の全額引き上げを宣告されます。
悪い例
御社はロードマップをVCに公開しなければいけません
では根拠とは何でしょうか？
オーガニックではこれこれこれだけ伸びているので、あとはこの機能とこの機能をリリースしてターゲットとなるこの企業に食い込んで、単価これだけ、企業数これだけでARRをこれだけ伸ばします、みたいな話が根拠となります。
半ば皮算用ですが、これを提出せずに許してくれるVCはほぼありません。
つまり今年中にこういう機能をリリースします。
この機能の開発にはこれだけ時間がかかります。
機能開発のロードマップはこれです、と言ってガントチャートもVCに見せなければいけません。
スタートアップの開発チームにとって、次期どんな機能をリリースするのか、その機能の開発にどれだけ時間がかかるのかを期が始まる前に見積もり、計画できることとそこに責任を持つことは義務も同然です。
しかしこのガントチャートベースの計画作りがいくつものスタートアップをギブアップに追い込んできました。
ガントチャートのアンチパターンその1、正直ベースの積み上げ
年間でリリースする機能を決める前に、候補となる機能ごとに「コストはおいくら万円かかって、リターンはおいくら万円になるのか」を見積もります。
Web企業の場合、SIerのように気軽に増員ができないのでコストと開発期間はほぼ比例します。
つまり開発チーム側の計画作りとは、「候補となる機能単位の開発期間の見積り」に他なりません。
たとえば機能Aは開発に2ヶ月かかり、機能Bは0.75ヶ月かかり、機能Cは1ヶ月かかり...と見積もっていきます。
最も愚かな企業はリリース予定の機能の見積を合計すると12ヶ月になります。
次に愚かな企業はバッファが積まれるために、リリース予定の機能の見積を合計すると9ヶ月前後になります。
これらの企業の共通点は、かならず「リリース予定だった機能」を全てリリースすることができず、毎回目標未達でVCに怒られたり、弥縫策によって期中に忙殺されることになります。
理由は極めて簡単です。
「解像度が低い状態の見積は必ず楽観的になる」「着手前に正確な見積を行うことはできない」という2つの理由によるものです。
前者については経験則で理解できるかと思います。
後者については不確実性コーンでググってください。着手前に見積もった結果は実際の工数のより最大4倍ズレる、というやつです。
ガントチャートのアンチパターンその2、バッファの積み上げ
期初に行う開発着手前の見積が大きくずれることはわかりました。
ではバッファを積めばいいのでしょうか？
たとえばリリース予定の機能の見積の合計が6ヶ月や4ヶ月になるようにすればいいのでしょうか？
つまり最初の見積の2倍や3倍の工数をバッファも含めて積むわけです。
これだけたっぷり余裕があれば必ず期限までに開発完了しそうな気がしますね。
でもそれは間違いで、よくある勘違いです。
パーキンソンの法則についてはご存知でしょうか。
バッファを積めば積むほど開発スピードは低下します。
そして開発が完了しないリスクはそれほど低下しません。
わざわざ倍のコストを払って開発が完了しないリスクがそのままの施策を経営陣はいつまでも許してくれるのでしょうか？
VCの機嫌が悪くなるたび「俺たちは開発チームを甘やかしすぎたんじゃないか？ もっとケツをぶっ叩いてやった方が良かったんじゃないか？」という誘惑を経営陣は感じるでしょう。
多分何度目かのタイミングで、その誘惑に従うことになるでしょう。
そしてアンチパターンその2の組織はアンチパターンその1の組織に変身するわけです。
ではどうすればいいのか
開発チームを甘やかすべきでしょうか？ それともケツをぶっ叩くべきでしょうか？
甘やかすと開発スピードが落ちる、ケツをぶっ叩くと開発が終わらない。
パラドックスに陥ってしまいましたね。
ここで提案があります。
VCに見せるガントチャートと、開発チームに見せるガントチャートを2つ作ってみてはどうでしょうか。
つまりVCに見せるガントチャートにはバッファをたっぷり積んで、開発チームには正直ベースのガントチャートでケツをぶっ叩くわけです。
開発チーム向けのガントチャートの締切をオーバーランされたところで、VCに見せた締切にはまだ余裕がありますからなんとかなるわけです。
これで問題は出ないのでしょうか？
実は出ます。
開発チームのメンバーはバカではありません。
締切が二重になっていることに気づいて、開発チーム向けのガントチャートの締切をぶっちぎったところで全く平気なことをすぐに見抜くでしょう。
開発チーム向けのガントチャートに書かれた締切までに終わる見込みがなくてもヘラヘラ笑いながら定時で帰っていきます。
困ったことになるのは明白です。
誰も彼もが開発チーム向けのガントチャートや締切を、3歳児が描いた落書き同然にみなすようになります。
締切前日もSlackには先週発売されたゲームの感想であふれるでしょう。
ケツをぶっ叩いてダメなら餌で釣ってみる
要するに開発チームに対して、VC向けの本当の締切を隠して、ケツぶっ叩き用の嘘の締切を見せるのがよくないのです。
ではVC向けの本当の締切を公開した上で、「本当の締切までに機能開発が終わるなら、残りの時間はプロダクトの価値を高めるために好きに使っていい」と開発チームに言ってみるのです。
最終的に肉になるなら、それまでの時間は牛が寝ようが草を食おうが牛に任せてやるという考え方です。
ただしこのやり方が成り立つには前提があります。
モチベーション3.0という本はご存知でしょうか。動機の内面化が必要になります。
つまり開発チームのメンバー自身が自分たちが開発するSaaSプロダクトに興味があり、その価値を自分たちの手で高めることを誘因やインセンティブとして感じていること
できるだけ短い時間で「ノルマ」である押しつけられた機能の開発を終わらせて、残りの時間で自分たちで決めた機能の開発を行うことを「楽しいこと、よいこと」と感じることが前提です。
開発メンバーの動機の内面化ってそんな面倒なことしないといけないの？
そうだよ（迫真）
末端のメンバーまでの動機の内面化は自律的に動く組織やメンバーにとっての必須要素の１つです。
メンバーが自律的に動かないなら
- 事前に幹部だけでできるだけ精度の高い見積と計画づくりを行い（不可能ですがとにかくやりきってください）
- あとは指示した人員と締切(≒コスト)に加えてスコープを固定した状態でケツをぶっ叩きまくるプロジェクトマネジメント（CDSを固定なんて無理ゲーすぎる！)をやり切る
という不可能なことが分かっている無理ゲーをやり続けることになります。
しかし組織が拡大して破綻が大きくなっていきます。
でもやりきってください。
でないとどこかでVCや株式市場から見捨てられます。
ほかになんかもっといい手はないの？
それ知ってたら私コンサルタントに転職してると思うんですよね。
なにしろ今SaaS企業を見回してもその「もっといい手」とやらが見当たらないので。
Discussion