「サイボウズ Office」の企画書、こっそり見せます　製品の価値を定義し、開発の承認をもらうまでの道程

人が書いた「生の企画書」を見てみたい

河合真知子氏：よろしくお願いします、サイボウズの河合です。今日は私が担当している「サイボウズ Office」の社内稟議……「開発をしますよ」という企画を出したときに、実際に役員会のようなところへ提出した企画書の生の状態を、なるべく隠さないでお見せしようかと思います（笑）。

私は、サイボウズでプロダクトマネージャーとして、グループウェア「サイボウズOffice」、「デヂエ」、「メールワイズ」といったSMBマーケットに対しての製品を全部担当しています。

キャリアとしてはエンジニア経験はなくてマーケティング、営業など、直接サポートではないCSに近い畑から、PMになりました。新規のお話が多いのですが、死んでいく製品というのもあって、けっこうサービスをクローズしているので、社内の一部の人には「剛腕クローザーだね」と言われています。

人が書いた「生の企画書」を見てみたいというのがあって……一体どんなことを書いていたり、どういう思考で作っているのかというのに、けっこう興味があったんですが、なかなかたくさんはないというところで。自分が先陣切ってお見せしたら、ほかの人がどんな感じでやっているのかという情報も得られるかと思って、今日はこういうタイトルにしてます。

製品の価値を定義し、開発の承認をもらうまでがPMの重要な役割

サイボウズの中でプロダクトマネージャーは、今お見せしているところ（スライドを指して）のフローをだいたい全般的にやって、製品をお客様にデリバリーするところ全体のマネジメントもします。製品の価値を定義して「これを作るよ」という承認をもらうまでがすごく重要な役割になります。

今日お見せする資料は、事業戦略会議で発表した生の資料になります。事業戦略会議は、社長、本部長、あとは各部署の一部マネージャーが出席して……Officeに限らず全製品の大きな開発の方向性を企画するときは、開発のプロダクトマネージャーが起案して、承認されたら「じゃあ開発スタートしていいですよ」となるものです。

これ以外にも、大きな製品ごとのマーケプランや、新規事業を企画するときも必ず起案して、承認を得てからスタートするという流れになっています。

わりと新しい企画書をお見せしたい気持ちはあったんですが……ちょっと生々しい数字だったり競合の分析があるので（笑）……5年くらい前に出した「サイボウズ Office 10」というパッケージソフトをメジャーバージョンアップしたときのものになります。

開発としては、お客様にパッケージソフトもお渡しするオンプレミス版と……この2年前に自社のSaaSを始めて、SaaS版を合わせて開発したときの資料になります。だいたい10～15分くらいもらって役員に対して説明しました。

自社SaaSの利用で、どれくらい使われているかもデータとして取れるように

（スライドを指して）これが2013年に作った、「ビジネスプラン」という資料です。実際にまずビジネス方針を定義して、ターゲットを大きく2つに分類しています。

3C分析では、市場の動向を定義して、競合を分析して。このときはアンケートの定量データを使ったり、実際の競合の情報をわかりやすくまとめて紹介するようにしました。

自社の分析として、売上の状況やお客様の状況にどういうものがあるかというのを、定量・定性データ……（スライドを指して）こんな感じでアンケートなどを使ってやりました。ここでけっこう大きく変わったのが、クラウドサービスを始めたので、お客さんがどのように利用しているかという情報が初めて（得られるようになりました）。

それまではお客さんにソフトをばらまいていたので、KPIとしてはダウンロード数とインストール数までは取れたんですが、そのあとなにがどれくらい使われているのか、という数字は、一切取ることができなかったんです。

でも自社のSaaSを始めたことによって、具体的な生の数字が得られるようになったので、その数字を取って、ちゃんと実際のデータとしてもこういう確証が出ているというのを初めて示せた……という大きな変化がありました。

企画書に盛り込んだ項目の具体例

3Cをまとめて市場機会を定義して、注力するターゲットのセグメントを分けてこんな感じで定義をして……ちょっと具体的な数字はお見せできないんですが（笑）……。（スライドを指して）こんなふうに分けて。その当時、既存のお客様も100万人以上いたので、新規も取るけど既存も取る、というような相反したことをやらなければならなかったです。

なので、セグメントを分けて、セグメントごとに「どんなお客さんだよね」というところを定義して。顧客セグメント別に、プロダクトの価値をより提案すべきところを定義しました。

プロダクト全体としてはこんな構造の進化をさせるといいのかなというのを紹介して……ここからは承認するところの肝ではないんですが、具体的にどんなことをやるのか、興味がある人が多いので（笑）。「こんな機能を、こんな優先順位でやろうと思っています」という紹介を入れたり。

デザインプロトがある場合には、実際に動画でも紹介するようなケースもあります。でも実際には、1個1個の機能について「これを作ります」という承認をもらうのではなく、あくまでこちらの方向性だけを承認してもらいます。

最後に4Pの、プロダクト以外のプロモーションやチャネル、値段など3つの定義と4Cの定義をして。並行でいろいろ同じようなメンバーで開発していました。さらに開発メンバーとスケジュールの期間について、ロードマップ出ますよ、というスケジュールのリリース計画を見せて。最後に開発費用がこれくらいです、というのをまとめて承認をもらいます。

チームのメンバーは、そんなに多くはなくて。エンジニアがだいたい4.5人とか、途中から入って6人くらいのすごく小さなチームで開発をしていました。

以上になります。

（会場拍手）