優先順位付けと仮説検証で、最小リソースでの企画・開発を

僕は、株式会社クレイの代表として受託開発を行う傍ら、自社サービスであるドキュメント共有ツール「DocBase（ドックベース）」の開発に、プロダクトオーナー※として携わっています。

※プロダクトオーナーとは、スクラム開発においてプロダクトの価値を最大化させる役割を持つ人。

弊社はエンジニアだけの会社なので、プロダクトを開発することはできます。ただ、システム開発をクライアントから受託しているので、自社サービスにあまりリソースを割けないのが課題で…。

そのため、ユーザーを満足させる機能や体験を、最小のリソースで探り当てるにはどうすべきかということを考え、工夫してきました。

ユーザーを満足させる機能を最小のリソースで探るにあたり、僕達が重視しているのは、「実装の優先順位づけ」と「ユーザーインタビューを通じた仮説検証」です。

はじめに開発すべきは「魅力的品質（Want）」

弊社では「実装の優先順位づけ」を、品質ベースで考えるんです。どういうことかというと、実装する機能を「魅力的品質」「一元的品質」「当たり前品質」の3つに分類して、新規事業のフェーズごとに、どの品質を満たすべきかを考え、必要最低限の実装を行っています。

▼「魅力的品質」「一元的品質」「当たり前品質」に分類

それぞれの品質についてですが、「魅力的品質」は、あったらうれしいが、なくても不満にならない品質のことで、サービスを特徴づける要素になります。

「一元的品質」は、あったらうれしく、ないと若干不満な品質で、増えれば増えるほど満足度が上がるものです。パソコンのスペックのような感じで「スペックが高ければ高いほど満足する」というものが、これにあたります。

「当たり前品質」は、あって当たり前で、ないと大きな不満につながる要素になります。

新規事業を開発する時によく、機能をWant（魅力的品質）とMust（当たり前品質）に分けて、初期はMust（当たり前品質）を開発することがあると思います。

ただ、例えばログインや通知機能など、細かいMust（当たり前品質）をすべて実装しようと思うと時間がかかってしまうんです。さらには、すべて実装した結果、ユーザーにそのプロダクトの尖り部分が刺さらなければ、目も当てられません。

それよりは、初期はMust（当たり前品質）を実装せず、Want（魅力的品質）だけ実装した、尖った未完成のプロトタイプをもとに、限られたユーザーだけに見せてフィードバックをもらう。そして、プロダクトの尖りを探ることが重要だと考えています。

特にBtoBのプロダクトの場合は、ユーザーに刺さる尖りが見つかった後に、「当たり前品質」を実装していき、多くのユーザーに向けてリリースしたほうが、リスクが少ないと考えています。

プレスリリースを作って「魅力的品質」を明確に

DocBaseの開発当初は、このように「魅力的品質」を支える最小限の機能を探っていきました。具体的にはまず、プレスリリースを書いたんです。

▼Amazonを参考にした「プレスリリース」の一部

これはAmazonが社内でしているのを参考にしたんですが、プロダクトの価値を、A4一枚のプレスリリースのフォーマットに沿って整理します。すると、プロダクトの尖り、つまり「魅力的品質」が一目瞭然になるので、議論がしやすくなるんです。

このようにしてプレスリリースを作った結果、「社内で共有された情報の質をメンバーが評価でき、質に応じて情報の順番が変わる」という「魅力的品質」の仮説ができました。

これは、例えばJavaScriptなどの技術情報をあげた時に、みんなが有益だと評価すればどんどん上に上がってきて、評価が悪ければ消えていくようなものです。

「魅力的品質」がユーザーに刺さるかを、プロトタイプで見極める

仮説を出した後は、1週間ほどでプロトタイプを開発し、ユーザーインタビューに行きました。ここで実装したのは、本当に一部の機能だけなんですけど、「これが一番価値があるんじゃないか」と思っている、尖り部分だけを作りました。

この段階でのアイデアは、あくまでも仮説でしかなく、間違っている可能性もあるので開発に時間はかけません。

品質としては、顧客候補の前でプロダクトが動き、相手が価値をイメージできれば十分です。バグも沢山ありましたが、気にしませんでした（笑）。

6社にインタビューに行き「組織の情報共有の問題はここで、自分たちはこういう解決策を考えてるが、どう思いますか？」という話をしました。

▼尖り部分だけを実装したプロトタイプ画面

結果として「閲覧権限による情報管理ができていない」という課題にはみなさん共感してくれたんですが、ソリューションについては、6社中4社から「興味がない」と言われてしまったんです。

そもそも上がってきた情報に、マイナス評価をつけることができない、という話になって（笑）。あとは、情報の順序が、その質によって自動的に入れ替わるのは厳しいということもわかりました。

今考えると当たり前に思えますが、企画段階では中々気づけないので、プロトタイプをして良かったと思っています。

また、ネガティブなフィードバックをいただけたことも逆に良かったです。そこで、自分たちの解決策がイマイチであることに気づけました。「どうしたらいいのか」や「どこに興味を感じないか」を深掘りすることで、改善への道筋が見えたんです。

道筋が見えてからは、次のバージョンを3ヶ月ほどで開発しました。メンバーは、他の仕事をやりながら開発をし、工数としては1人×3ヶ月程度になります。ここでようやく、今のDocBaseの原型が生まれました。

▼当時のDocbaseと現在との比較

クローズドでの公開時には、最低限の「当たり前品質」を

DocBaseの原型は、2014年8月、10社に限定公開しました。この10社は、最初にインタビューさせてもらった6社のうち興味を持ってくれたところと、他に試してもらえそうな会社に声をかけた感じです。

この段階でやっと「魅力的品質」に加えて「当たり前品質」を実装しました。

「魅力的品質」は、権限を設定して情報を公開できる機能などです。始めのプロトタイプでNGとなった、情報が質によって並び替えられる部分は、小さな情報をまとめられる機能や、権限、タグ、作成者から簡単に探せるように修正しました。

「当たり前品質」でいえば、使ってもらうために最低限必要なのはセキュリティだったので、共有される情報を暗号化しました。この段階でもバグはまだまだあるんですが、ここは完璧な状態にはしません。

導入していただいた10社には、僕がインタビューに向かい、フィードバックをいただいていました。当時は社内でも、DocBaseが上手く機能するイメージがまだまだ湧いていなかったので、改善の「ヒント」が欲しかったんです。

課金を早く開始しプロダクトの真の価値を理解すべき

その後、10月からクローズドβ、12月からオープンβ、そして、2015年7月から課金をスタート（本リリース）しました。

▼Docbaseの開発フロー振り返り

少しずつ「当たり前品質」を拡充していき、課金しても問題ないという自信ができてから課金しました。クレイは受託開発の会社なので、品質を高くしてからでないと課金したくない、という気持ちがあったんです。

ただ、今思えば、もっと早くから課金しておけばよかったなあと…。

課金をはじめる前、いろんな会社さんが使ってくれていたんですが、課金がはじまるとなった瞬間、一定数の離脱が起こったんです。

これって、当時のサービスが、その人達にとって「お金を使ってでも使うサービスではない」ということだったんだと思います。つまり、課金をすることでプロダクトの真の価値がわかる。

もちろん、課金をして離脱されるのはショックでしたが、現実と向き合うことで、初めてプロダクトを改善していけます。実際に解約の時、ユーザーの方からご連絡をいただいたこともあって、そのときに解約の理由を話してくれました。

課金を始めると、プロダクトはやっと成長段階に入ります。成長段階においては、スピーディーに「当たり前品質」を拡充していくことが重要です。

特にB2Bのサービスだと、「魅力的品質」について興味を持っていただいても、「当たり前品質」がそろっていないと、導入できないということがよくあります。例えば、「シングルサインオン」に対応してないと、入れたくても入れられないといったことが発生します。

プロダクトオーナーはオフィスの外に出るべき

このようにして、ユーザーが満足する機能や体験を最小リソースで探ってきました。僕のようなプロダクトオーナーが新規事業の初期フェーズですべきことは、オフィスの外に出て、ユーザーインタビューを通じて徹底的に仮説検証をすることだと考えています。

開発初期、5、6社にプロトタイプを見せて「魅力的品質」を探り当てて行ったように、とにかくオフィスの外に出ることが重要だと思います。そして、正しかった仮説、間違っていた仮説を受け止め、ユーザーが満足する機能を考え、次の実装の意思決定をします。

課金開始後の成長フェーズでは、カスタマーサポートに徹することが重要になります。徹底的にユーザーの声を聞き、自分たちでは気づけない「魅力的品質」と「当たり前品質」に気づくことで、プロダクトを改善していくことが、成長につながると思います。

DocBaseで、今後も組織成長を促進していきたい

今後は、ユーザーの要望として挙がっている「当たり前品質」を満たしつつ、もっと使いたくなるような「魅力的品質」を組み込んで、DocBaseを成長させていきたいですね。

情報共有の活性化を通じて、たくさんの組織の成長に貢献できることを、心から願っています。（了）