フラスタ・楽屋花のSakaseru

デザイナー選びや
予算について
スタッフに
無料相談!
[リリース・運用編(最終回)]webサービスの作り方

[リリース・運用編(最終回)]webサービスの作り方

2020年09月11日

こんばんは。
Sakaseru代表の小尾です。

「3人でクラウドファンディングのサイトを作った」コラムの連載、今回が最後になります。
連載を読んで下さっている皆様、本当にありがとうございます。

こちらが、全5回の流れとなっています。
どのコラムも、webサービスを作るにあたって必要な事ですので、今後webサービスを作ってみたい!と思われる方は、是非読んで頂ければ嬉しいです。

全5回の流れ
はじめに

着想・構想編

デザイン・プログラミング編

収益編

本番リリース〜運用編(いまここ)

前回までのコラムで、作ったwebサービスでどの様に収益を出すか、ミンサカを例にご紹介させて頂きました。
今回のコラムでは、作ったプロダクトをリリースしてから、運用するまでのご紹介をさせて頂きます。

webサービスを作ったものの、運用の仕方が分からない。実際の運用の様子を知りたい。
そういった読者の方におすすめの記事です。

運用の仕方はサービスの数だけあると思いますので、Sakaseruはこんな風に運用しているのだな、と一例として捉えて頂ければ幸いです。

それでは早速本番リリースから運用の事までご紹介いたします。



プロダクトをリリースする



沢山の想いを込めて作ったプロダクトを世の中にリリースする時は、いつだって少しの不安と沢山の希望に溢れています。
いうなれば、我が子を外の世界に出す、そんな心境です。

そんな心境の中、ミンサカの場合、既にプロダクトは本番の環境にアップロードされていましたので、お客様の導線を設定し、知らせてあげることがリリース作業でした。
作業は次の3つでした。
1. 既存のサービスにバナーを設置する。
2. 既存のお客様にメール配信してお知らせする。
3. Twitterでお知らせする。

既にアクセスのあるサイトに、新サービスの導線を設置することで、サイトに訪れ興味を持って頂いたお客様にプロダクトを見て頂く。
メールやTwitterなど、お客様と接点のある方法で、お知らせをする。
ということです。

既にあるサイトも、お客様との接点も無いよ。という方もいらっしゃると思いますので、その場合は、事前にTwitterの運用をしておく、或いは、身の回りの方に連絡をして、プロダクトが良かったら他の方にも知らせて頂く等も良いかもしれません。

晴れて、プロダクトリリースをすることが出来ました。



プロダクトはリリースしてからが始まり



大変な想いをしてプロダクトをリリースすると、達成感を覚えます。
これはとても嬉しいことですし、よくやったと、自分を含め、関わってくれた方全員に強い感謝の想いを感じます。
そして、実はここからが本番だったりします。

プロダクトのリリースを、例えば0を1にする作業だとすると、その後待ち受ける運用の作業は1を10にしていく作業になります。

特に0から1にする作業が得意な方は、1を10に向けて成長させて行くことが苦手な場合があります。
このコラムを書く僕がそういったタイプです。

苦手なので、Sakaseruでは仕組み化しました。



お客様の声を伺える仕組みを作った



サービスを開発運営していると、まっさらな気持ちで自分のサービスを見ることは、ほとんど不可能になってきますので、お客様からのご意見は貴重です。
Sakaseruでは、ご注文の商品を発送して、手元に届く位のタイミングで、お客様に評価頂くメールを配信する仕組みを作りました。NPSと呼ばれる指標を取り入れていて、家族や知人におすすめしたいか0〜10点で決めて頂き、その理由を伺っています。
NPSにご回答頂くことで、サービスへの改善点が日々届きます。
低い点数から高い点数まで、その全てが宝で、サービス改善の源になります。



改善したらお客様に伝えるようにした



先程のNPSで改善点を修正したら、改善点を下さったお客様に、改善の報告と御礼の連絡をしています。
そうすることで、「この運営は言ったことを聞いてくれるんだな。」と思って頂けることで、更に改善点を頂ける場合があります。

サービスを使って頂く

改善点を伺う

改善する

お客様に伝える

この循環の仕組みが出来ると、日々サービスの質は上がっていきました。
改善点を聞き出すことを、手動で行うと大変ですから、プログラムで自動化すると楽でした。
その代わり、Sakaseruでは改善できたご連絡とお礼は、全てメールを手書きしてお客様にお伝えしています。



お客様の動きを見る



webサービスの場合、google analyticsを導入すると、サイト内のお客様の動きが数字として把握出来ます。
特に、商品販売を伴うwebサービスであれば、google analyticsのe コマース測定設定を済ませておくと、ページの価値や、収益も見ることが出来ます。
Sakaseruの場合、ページの価値で降順にソートし、価値の高いページを重点的に改善して数値を伸ばしたり、逆に収益性の低いページは、導線やコンテンツの内容を改修して収益を出すように運用しています。
昔言われた言葉で印象に残っているのが、次の言葉です。

「ドリルを求める人は、高性能なドリルを求めているんじゃない。穴を求めているんだ。」

要はお客様の求めている価値を提供しよう。ということなのですが、これが実際に運営する立場になると見失うことが往々にしてあります。



お客様に直接インタビューした



お客様の求める価値を見失っているかも、或いは見つけられないという場合はインタビューをしました。
インタビューの良いところは、求める価値の詳細から経緯まで聞けることです。
また、インタビューすることで、サービスを使って下さる対象の方の輪郭も、自分の中ではっきりしてきます。
お客様にパソコンやスマートフォンで操作して頂き、迷っている部分があればそれを記録して、画面を修正する。
自分たちのサービスを選んで頂いた理由から、他のサービスを検討しているかなども、一緒に聞く。
その方の一日の生活の中に、自分のサービスがどの様に入り込んでいるかも確認する。
Sakaseruでは、この様な事をインタビューで聞いています。



取り入れる意見とそうでない意見を切り分けた



改善のご意見が来た場合、その全てを改修するかと言えば、そんなこともありません。
改修するかしないかの判断は、「他のお客様も望んでいる改修なのか」を重点的に判断します。
例えば、100人のお客様がいたとして、たった一人のお客様だけが満足する改修であった場合、ご意見を頂いたお客様には申し訳ないのですが、改修はしない。という判断をします。
改修にはコストが掛かりますし、その改修をすることで残り99人のお客様が使いづらくなってしまう可能性もあったりしますので、よく検討するようにしています。
とは言え、リリースしたてのプロダクトの場合、不具合や使いづらい部分は多々ある事が多いので、改善のご意見は、ほとんど取り入れ、改修するようにしています。



課題解決ノートを作った



NPSやインタビューを経て、お客様から頂戴した意見は、課題解決ノートに記録しているようにしています。
スプレッドシートで管理をしているのですが、次の項目を設定しています。

・優先度
・開発工数
・課題
・解決方法
・解決後に得られるメリット

お客様がどんな事で不便を感じていて、僕たちがどの様に解決できるのか、その方法。
解決したあかつきには、お客様、そして僕たちにどんなメリットがあるのかをまとめるようにしました。

優先度に関しては、例えば、プロダクトがまともに使えない等のクリティカルなものであれば優先度が高いですし、画面が少し崩れているなどの軽微なものであれば、優先度は低くなります。

同時に開発工数も割り出して、優先度・開発工数を比べながらプロダクトを改善していきます。

大切にしている事は、課題解決ノートのリストを枯渇させないように、お客様の声に良く耳を傾け、改善したら改善したと伝えるようにしていることです。



継続するモチベーションを見つけた



僕の場合、どれだけ苦労して世の中に出したwebサービスであっても、運営途中に飽きてしまうことがありました。
飽きてしまう問題を解決するために、自分が何が得意かを並べてみました。得意なことであれば継続出来ると考えたからです。
「好きなこと」で無いのは、好きなことが必ずしもサービス運営の継続と重ならないからでした。
得意なことは、次の2つでした。

・お客様に喜んで頂けるサービス作りをすること
・プログラミング

上記2つの内、プログラミングをするためには、先程の課題解決ノートが必要になって来ます。
コードを書く目的が必要だからです。
つまり、その目的を絶やさない為に、課題解決ノートを常に更新していくことが、結果的に継続するモチベーションなのだと気付くことが出来ました。

人によっては、デザインすることであったり、Twitterでフォロワーの方とコミュニケーションをとること、或いは沢山お金を稼ぐことかもしれません。



連載の最後に



連載を最後まで読んで下さり、本当にありがとうございます。

今回の連載を書く時に気をつけたのは、出来るだけ「僕はこうした」といった伝え方にしたことです。
「こうすべき」「こうしましょう」といった伝え方は、webサービスを作るにあたって、物事の選択肢を狭めてしまうと考えました。

webサービスを作る目的、コードの書き方、プログラミング言語の選び方、モチベーション。
全て自由です。自らwebサービスを作ったのであれば、自由を全うするための責任だって、僕たちが決めることが出来ます。

連載を通じて、少しでも自分でサービスを作ってみようと思って頂ける方が一人でもいらっしゃったら、それはとても嬉しいことです。
その際は、是非連絡を下さい。僕も連載してよかったなと思うことが出来ます 笑
連絡先 : ryutaro.obi@sakaseru.jp

一人でも多く、サービスの開発者が増えることを楽しみにしています。

SNSでシェア

関連するコラムを読む