こうすれば良い！ プロダクトマネジメント
さて、そんな状況に陥ったSaaSベンダーは一体どんな解決策を講じる必要があるでしょうか。課題解決の基本にならえば、そんなに難しい話ではありません。まず、現状を把握し、解決すべき場所を特定する。そして、解決策を立案して、実施し、その結果を確認、評価する。簡単に言ってしまえば、それだけのことです。
具体的に実施したのは、大きく分けで下記の5つのステップでした。
- ①「開発要望を収集しよう」
- ②「対応する優先順位をつけるルールに合意しよう」
- ③「投資対効果を客観的に比較できるようにしよう」
- ④「確かな技術的見通しのもと、スケジュールどおり開発しよう」
- ⑤「リリースしたら、その後は効果をモニタリングしよう」
項目ごとに、少し詳しくご紹介します。
まず、①からしていきなり「言うは易く行うは難し」なのですが、開発への要望は実にさまざまな場所に存在しています。
- 営業メンバーが主に使う、顧客開拓と対応をするためのCRMシステム
- ヘルプデスクが主に使う対応履歴DB
- 開発チームが主に使うバグチケット管理システム
- さまざまな導入コンサルティングプロジェクトの振り返り資料
- 開発チームの考える開発計画
- 経営的な開発ビジョン、対外的な説明資料
- 経営会議の議事録
- 散発的にさまざまな場所で作られる「要望一覧」系のEXCELデータ
- 障害発生時の振り返り、反省に基づく今後の開発体制や開発推進標準、開発計画
- 時々開催される合宿やロングミーティングの成果としての開発計画
このように、実にさまざまな記憶領域に、さまざまな情報が散在してしまうものです。これらを統合することは極めて困難であり、だからこそ「どこから手を付けたらいいものやら」という漠然とした状態を引き起こします。CTOや開発チームのリーダーのもとにはさまざまなチャネルで情報が届けられ、あるものは着手され、あるものは棚にあげられたままになる。
プロダクトマネジメントの不在によって引き起こされる極めて強い痛みの発生源は、「なぜそれが開発・リリースされたのか？」という説明が分かりにくい、ということです。
顧客か社内かを問わず、その製品に関わる人達は必ずその製品に対して、開発要望を持ちます。あれがほしい、これはいらない。もっとこうしてほしい。人間の欲望は無限大であり、言うだけはタダです。そして多くの場合、専用のフォームやヘルプデスク、営業担当など、意見を届ける窓口があり、意見を発信することもあります。
そこまでは問題ありません。問題はその後です。さまざまな声を受けて実際に新たな機能が開発され、リリースされると、願いがかなって幸せな要望者も生まれるわけですが、その他大勢の心のなかに「自分の要望が優先されなかった」「いつまで待っても要望がかなえられない」という失望も少なからず発生させます。
開発方針についての一貫性のある説明をすることで、失望を納得に変えることも不可能ではありませんが、スタートアップやベンチャー企業の経営的なスピード感では、そのような説明が後手に回ることがしばしばであり、だからこそ、モヤモヤとした不満が組織全体に広がりやすいところがあります。
王道を愚直にやってみた、筆者の「プロダクトマネジメント体験談」
筆者がやってみたのは、一度、全部の要望を各システムから吸い出して、まとめてみたらどうなるだろうか、ということでした。1か月ほどかけて作業してみたら、個別のバグから新機能開発まで、粒度の大小はさまざまですが、800件程度の要望になりました。
次に実施したのが、マーケ、営業、開発など、重要な役割を担っているマネージャを全員集めて一緒に考えてみる、ということでした。開発要望には必ず理由があり、問題は、なぜその要望が優先されるかの理由付けの不在だったからです。マネージャに不満がたまり、その先のメンバーにもそれが伝わってしまうとか、最前線のメンバーの疑問にマネージャがこたえられず、経営陣の考えを代弁できない、ということは、組織にとってよろしくない状況です。
そこを解決するためには、しっかりと時間をとって話し合いの場を持つのが重要と考え、多忙を極めるマネージャ陣を1人ずつ説得し、隔週程度の間隔で、半日ないし丸一日のミーティングの場を作りました。
そこで、上記のリストに対して、下記のような観点で客観的な尺度でスコアをつけていく、ということを実施しました。
その開発を要望する理由
- 新規顧客の獲得が期待でき、売上の増加が見込める
- 既存顧客の不満が解消でき、継続率の向上が見込める
- 導入コンサルティングの生産性が高まり、売上回収までのリードタイムが短縮できる
- 先端的な技術領域での取り組みであり、話題性と期待感が醸成できる
- 長期的なシステム保守や開発の効率化など、内部組織的な観点から必要
実現可能性についての見解
- 機能の改修や新規追加をするとして、仕様は決めやすいか
- その開発案件のボリューム、難易度はどの程度か
- その領域を得意とするエンジニアのアベイラビリティはあるか
開発優先度とは、これらの各要素の掛け算によって決まります。資源が有限である以上、ない袖は振れませんが、どうしてもやるべきテーマがあれば、資源をどうにかして調達してでも、やらなければいけません。
こうしたことは、事業規模が小さい間は簡単に意思疎通できても、一定以上の規模になって、関係者が増えると、とたんに課題の組み合わせ爆発が発生してしまいます。
当時は、そもそもこうした大項目における優先度がマネージャの間でしっかりと議論され、腹落ちしていなかったために、組織感情が悪化し、業務が非効率になってしまっていたのだと考えていました。
3か月ほどかけて精査した原案をもとに、投資対効果を算出し、経営陣から最終的な了承を得て、「今年一年はこれこれを開発します、リリース時期は毎月一回、社内、社外問わず公表し、約束して開発を進めていきます」という体制を作ることに成功したのでした。
こうした活動を成功させる前段階としては、自分自身が入社してから製品や顧客について理解する時間、実際の業務で成果を出して社内の信用を得る時間も必要であったわけで、振り返ってみると、ここまで到達するまでに、3年半の時間をかけて、ようやく全社的な開発サイクルを定着させることに成功した、という感じでした。
- 転職してカスタマーサクセスを立ち上げ、実際にサービス提供しながら製品知識や顧客知識を得るのに2年
- 製品開発の全組織的な合意形成が必要だというメッセージを発し始め、受け入れられるのに1年
-
全マネージャを巻き込んで、すべての要望を取り込んで開発改善の方針を策定するのに半年
（事前準備とマネージャ陣の説得に1か月、会議そのものに3か月、経営陣への提案と了承、本格GO準備に2か月）
