はじめに
しくみ製作所 代表の車です。
今年から自分の考えや社内での取組み等をまとめていきましょうということで、社内向けではありますが、「つぶやき」と題し、書いております。
今回は、一部資料もご紹介しながら、プロダクト作りで自分が考えていることをまとめてみたいと思います。
プロダクトとは
辞書には下記のようにあります。
- 製品を指す言葉である
- その製品により、もたらされる便益を強く意識させる言い方である
- 広義では、製品に付随するサービスをも含める
プロダクトは抽象的な概念で、ソフトウェアで作られた「システム」よりも広義の意味で使おうと考えており、複数のシステムや複数のサービスを組み合わせた、ユーザーに対する価値提案するシステム群を「プロダクト」と定義して話をしています。
つまり、プロダクトは、宣伝ページ・価格・サポート・保証など含めた形での、顧客に価値提供する全体を指す言葉として定義し、システムはプロダクトの一部を形成するためのソフトウェアを意味した用語として普段使っています。
結果的に、以下のように定義します。
- プロダクト設計は、ユーザーに対してどのように価値を提供するのかを設計すること
- システム設計は、プロダクトが提供する価値の一部をどのようにシステム化していくかを設計すること
プロダクト設計で考えていること
良いプロダクトを突き詰めると「シンプル」に尽きると考えています。
「シンプル」とは、プロダクトの価値提案を実現するためのコンセプトをストレートに表現しており、各機能・UIなどがそれぞれどれ一つとってもコンセプトの表現・実現に不可欠な状態を指していると思っています。
結果、良いプロダクトとは3つで構成されると思っています。
- コンセプト
- シンプル
- ストーリー
コンセプト
- プロダクトを表現する「言葉」であり「イメージ」
- 人に伝播するためにも、言語化しキーワード（KW）にする
- ユーザーがプロダクトを触る目的も明確になり、ユーザー自身がこのプロダクトを使って、何を実現するかを、ユーザー自身が設計しやすくなる
シンプル
- コンセプトを実現するために必要最低限であること
- シンプルにすることで、ユーザーに対しても価値を伝えやすい状態になる
- ムダな機能を削り、コアに集中することで、ユーザー価値に対して投資も集中することができる
ストーリー
- ユーザー1人1人の具体的なイメージになる
- モデリング（ペルソナ）をして、各ユーザーがどのようなストーリーでこのプロダクトと接点を持ってもらうかを、映画のようにストーリーを作っていく
- ユーザーの行動だけではなく、ユーザーの思考をトレースしたストーリーを作っていく
シンプルについてもう少し
パレートの法則
イタリアの経済学者ヴィルフレド・パレートが発見した冪乗則。経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとしました。
80:20の法則、ばらつきの法則とも呼ばれます。
Webサイトは、2割のページにサイト全体の8割のアクセスが集中する
売上げの８割は、全体の２割の顧客で占めている
売上げの８割は、全体の２割の製品で占めている
あるソフトウエアの利用者の8割は、全体の2割の機能しか使っていない
勤務時間の2割で、その日のアウトプットの8割を実現しているユーザーが触るのは主要な2割の機能
ユーザーは2割の重要な機能しかほぼ触らないということです。
つまり、2割の重要な機能に重点的にリソースを投資することで、プロダクトを良いものだと感じてもらえるケースが多いということにもなります。この2割にリソースを集中できるかがプロダクト作りのポイントですね。
裏を返すと、メインストーリーをなぞる作業は2割で終わるので、残りの8割は細かなエッジのストーリーになります。そして、この8割のエッジのストーリーをどう処理するかが、プロダクト戦略の大きな部分です。
この辺りを図示すると下記のような感じで、一部の人がたまに使う機能に多くのコストが割かれることが多いと思っています。
エッジ処理
残り2割の枝葉の剪定については、いくつか方法論があります。
切り落とす
「シンプル」を本当に突き詰めるとこのコンセプトになりますが、結果、ユーザーの要望も切り捨てることになるので、「卒業」を覚悟する強い気持ちが必要ですね。
シンプルなプロダクトを謳っているものはこの方針を取る事が多いとも思います。
設定化する
ある程度は助けてあげようということで、ユーザーに対する設定を用意するのもいいでしょう。サポートしすぎると異常に難しいシステムが完成することもありますが、それでも使いたいというケースも多くあると思っています。
どこまでを設定にするかはPOの腕の見せどころになりますね。
設定を増やすと、積でパターンができるので、QAの工数が膨大になると思っていて、設定数 × 機能 のコストを毎回のリリースで支払っても良いという強い気持ちが必要になります。
抽象化（カスタマイズ権を委譲）する
設定化の上位概念で、ユーザー側にコントロール権をかなり渡すというのもあります。例えば、NotionであればDBなど含めてユーザー側が自由に触れるところ。
ヘビーユーザーには歓迎されますが、ライトユーザーにとっては難しいという印象を与えるケースが多いこともあります。それでも、ヘビーユーザーを育て、一緒にライトユーザーにとって使いやすいプロダクトをつくろうという協力関係が築ければ一番良い方法だと感じます。
こちらもヘビーユーザーを育てていく方針を取るという強い気持ちが必要です。
おすすめのエッジ処理
どの方針でエッジを処理するかが、POの腕の見せどころと言っても過言ではないし、ある意味哲学が入るところになるとも思います。とはいえ、ユーザーに使ってもらえないと意味はないので、このプロダクトで届けたい価値やユーザーの特性を見極めて、エッジ処理のキワの処理を実施していきたいものです。
私個人は、「切り落とし」or「抽象化」が良いと思ってます。
製造観点になってしまうかもしれませんが、「設定化」による条件分岐のQAは常時発生するので、バグの温床になりやすいです。また、設定化はある意味「分岐」になるので、そもそもエッジケースに対して「分岐」を設けるとさらに利用ケースが減るので、あまり使われない機能に対して更にパターンを増やし、投資のコスパがどんどん悪化していくと思っています。
サンクコスト効果（学習と捨てる勇気と再構築）
プロダクトの開発・改善を続けていくと、どんどんそのプロダクト・ユーザーの理解が深まり、コンセプトが深まっていくケースが多いと思うのですが、その場合に、これまでせっかくやってきたのに大きく作り直すのもな・・・という感じで、作り直すか？このまま継続するか？の二者択一なケースになることがあります。
一般的に、事業や行為に投下した資金・労力のうち、事業や行為の撤退・縮小・中止をしても戻って来ない資金や労力のことを「サンクコスト（埋没費用）」と呼びます。
私個人の経験論でいくと、プロダクトの本筋に関わるコンセプト・コンセプトに関わる主要なデータ構造など、プロダクトの核になる部分については、サンクコストがどんなに大きくても捨てる勇気を持ったほうが後々は良いケースが多かったと感じています。
プロダクトの核が必ず良くなると信じられるのであれば、サンクコストなんて無視して作り直して、周囲からその時は怒られた方が良いんじゃないかなと思っています。
ただ、実際に再構築をしてみると、初期構築よりも驚くほど早く製造が回ったりもします。
人間は絶対に失敗するので、そこからどう切り返すかを考えて動くという強い気持ちが必要ですね。
POに必要な強い気持ちを持つには
強い気持ちを持つのもいくつか方法論がありますね。
コンセプト・構造（あるべき論）に基づく
- コンセプトやシステムをシンプルに保つためにはこれしかないということも結構ある
- これはシステムやコンセプトを守るためには必ず必要なので、絶対に必要な措置として主張しやすい
ファクト（データ）に基づく
- ユーザーのデータなどに基づき発言できる
- データは強い気持ちを手に入れるためにも取っておくと意思決定が楽になる
理想に基づく
- 最後はここかもしれない
- 結局、自分がどうしたいのか？ということに尽きそう
まとめ
実はこの文章、半年以上前に殆ど書いており、今自分が読むと、できていないなというものも結構あります。強い気持ちを持って、プロダクトがよくなると信じてやっていかないとなと思いました。
次回は「プロジェクト管理」について書いてみたいと思います。