前回、「SONR.の根幹となるコンセプト」が決まり、
いよいよ開発コード「Manets」の開発がスタートしました。
仕様を確認しながら、何度もディスカッションを重ね、改善を図っていきます。

インターフェースを担当したのが女性デザイナーということもあって、他にないシンプルな業務システムへの土台となりました。こうして現在のプロダクトポリシー「もっともシンプルでもっとも簡単な」に少しずつ近づいていきました。

当初の仕様は、WEB制作会社が自由にクライアントを招待し情報が共有できるというものでした。
つまり制作会社のみが課金対象であり、そこに紐づく取引先企業はあくまでも、制作会社との連絡ツールという広がりのないものでした。

しかし、開発の第2段階となるプロトタイプから製品版にリプレースするにあたって、この課金対象、つまりターゲットを「制作会社のみ」から「全ての企業」に変更することになりました。利用者はすべて横一列となり、利用者同士で個別につながっていくという形です。販売は難しくなりますが、マーケットは大きく広がります。

そこで起こった当時のもっとも紛糾したテーマは、「このツールは個人で利用するものか？組織で利用するものか？」でした。

「最近のツールは個人利用が中心」「個人が利用し、必要に応じてグループになり、そこに課金する」というモデルが、世の中のトレンドです。しかし、ここには大きなリスクがあります。
・資源の少ない我々がお金を生まずにただただユーザーが増加して負担だけが増えるツールを持ったとしたら、結果としてそれを維持するために受託をしまくることになるのではないか？
・無料のビジネスツールに課金させるのはかなりハードルが高いのではないか？
・無料でユーザーを拡大して後からマネタイズするモデルは非常に障壁が高い
・機能による価値で勝負して堂々と料金を頂けるビジネスにしたい
・企業単位で導入してきちんと課金できれば、スイッチングコストが高くなり他社の障壁になるはずだ

など、いろいろな視点でディスカッションを繰り返しました。

そして、現在の仕様に大きく変化していきました。

・SONR.は企業単位で利用するもの
・利用企業同士でコミュニケーションを取ることができる
・ターゲットは、ようやくIT化が進み始めた中堅、中小企業

この結果、大きな取捨選択が行われ、多くの機能が幻となりました。

仕様というのは「単に機能がどうあるか？」ということではありません。そのサービスが大切にしている想い、何を大切にし、何を捨てるのかといったコンセプトそのものがすべてのスタートにならなければいけません。

そして、そのコンセプトとサービスの一貫性が、その品質や機能を大きく左右することを、開発を進める中でメンバー全員が実感していきました。