Edited at 2017-12-01

Livesense - 自 Advent Calendar 2017 Day 1

個人プロダクト開発で、困った時にどうするか

Introduction

Webエンジニアであれば、「自分達の手で0から作ったプロダクトで世の中を変えられたらな、それで食べてけたらなー」と夢見ることがあるのではないでしょうか。
私たちは、夫婦2人で、プライベートの時間でアプリ開発と運営をしています。その過程でぶつかった壁がとてもたくさんありました。

全てのプロダクトで当てはまることではなく、あくまでも特定のケースなのでなかなか一般的な手法として展開しずらい事例が多いですが、これらの困った体験が何かのお役に立てればと思い書きました。
実際に起こったこともあれば、起こってはないが、経験から推測するとこのケースはこう対処すればいいのかもしれないと思ったこと、の両者を記載しています。本やブログなどで得た知識をそのまま紹介するというよりは、実体験に基づいた内容になっています。

人が集まるまで

作る時間が無い

困った

たくさん機能開発したいが、普段働いてるため時間が足りない
そもそも集客・開発・ユーザー対応の全てをカバーするのは、とても時間がない
自分のプライベートの時間も楽しみたい

対処

集客は一旦やめて、機能開発に集中
- プロダクト方針やマネタイズ方法が固まってきてから集客
設計を時間をかけてきれいに作りすぎない
- はじめは流行るかもわからない

プロダクトが良ければユーザーが0にはならないので、まずは人を集めるための施策を捨てて、機能検討に集中しました。
具体的な方針を決めるためには、機能導入後のユーザーの動きをみる必要があるため、というのもあります。

コード品質よりもスピード

プロダクト品質に関しては、初回リリース時期はプロダクト品質は度外視し、DAUが1000を超えてきたあたりから、オペレーションを失敗しないような工夫を入れていっています。

勤め先でのコードレビューでは、比較的細かくみてるのですが、個人プロダクトにおいてはコード品質よりもProduct / Solution Fit(後述します)を追求しています。ユーザーが求めているものが曖昧な、成長が読めないプロジェクトにおいては、コードが無駄になるリスクが十分あるためです。
もしプロダクトが流行ってきたら、少しずつリプレイスするか、フルスクラッチできればと考えてます。

ユーザーが来ない

困った

公開はしたが使ってくれる人がなかなか増えない
このまま人が増えなくて、最終的には0ユーザーになるのではないか・・
広告を出すとお金がもったいない

対処

良いプロダクトには自然と人が集まる (ある程度は)
いくらプロダクトを良くしてもユーザーが0では、諦めもつく
逆に1人でも大ファンがいる場合、諦めるのはまだ早い

プロダクトの作り始めは、人を集めたくてしょうがなくて、SNSの活用・ストアの見せ方の検討などに、始めは力を入れていました。今では集客に力を注ぐよりも、まずはユーザーに愛されるアプリを考えることに力を入れています。

集客が成功したとしても、継続率向上や収益化に成功していないと、最終的にプロダクトクローズになってしまう未来を感じます。
人を集めて、結局価値が見いだせず倒れていくプロダクトよりも、価値を確立し、自然と多くの人に広まっていく流れの方が理想です。

もし1人でも大好きで使ってくれてる人がいるならば、何かしらの価値を持っているプロダクトなので、その価値を誰のためにどうやって強めていくかを考えるとよいでしょう。

集客をしないのであれば広告費もかかりません。自分で開発ができさえすれば初期コストもほとんどかからないため、手元の資金が0、そして限りある時間を有効に使えさえすれば、いつでも誰でも世の中にプロダクトを出すことができます。
唯一ランニングコストとしてさくらのレンタルサーバー代(約1000円/月)のみかけています。(さくらの古いプランなので、今は料金プランが変更されているかもしれません)

流入推移については、短期間で見ると流入の上下があり一喜一憂してしまいますが、数ヶ月スパンで見るとある程度上り坂か下り坂か、は見えてくると思います。経験則に過ぎませんが、価値があるプロダクトは長期的に上り坂になるはずです！

話が広がりますが、愛されるプロダクトになることを目指すと、自分の満足度も上がります。プロダクトで救われたという声だったり、プロダクトが好きです！というレビューを見ると、作ってよかったなーという気持ちになります。

集客で試したSNS

集客をがんばろうと思ってた頃は、SNSを利用していました。
SNSを無料の範囲で運用するならば、プロダクトの性質や対象ユーザーにもよりますが、Twitter、Facebook、Instagram、Amebaブログ、に同じ投稿をする場合、圧倒的にInstagramでの反応が良かったです。(いいね！の数だけ見ると)
今ではまだ、どのSNSもあまり運用していません。

作った機能が使われない

困った

これは喜ばれる、と信じてた機能が使われなかった
せっかく作ったのに...時間がもったいなかった

対処

ユーザーのどんな課題を解決しているのかを調べる
- 愛用者へのインタビューを実施
その課題をもっと解決する機能を作る
作った機能を評価する
- ユーザーの声を聞く(定性評価)
- 行動ログを見る (定量評価)
思考バイアスに気付き、自分が作りたいものを作らない
- 自分の仮説を信じたい気持ちは無意識に強くなってしまう
- 「これは効果あるはず」という仮説を、「これは効果あるので絶対やる」に脳内で置き換えない

使ってくれている多くのユーザーはどう課題解決されて満足してて、他にどんな要望を持っているのかを知るのが大切です(後述の「Problem / Solution Fit」を目指すため)。
まだ定義できていない満足感や要望を掴むための1つの方法として、ユーザーインタビューがあります。対面でやるのがベターですが、今回はメールで行いました。

アプリ起動回数が一定を越えたアプリの愛用者に対し、インタビュー依頼(空メール送信を依頼している)をモーダルで出します。
使ってて満足する瞬間はどんなときか、何故代わりのプロダクトを使わないのか、等をインタビューします。
起動回数を多めに設定しているにも関わらず、思ったよりも依頼に答えてくださる方が多かったため、プロダクトの強みが分かってきたところで一旦募集を停止しました。

定量調査も必要ですが、「全体的にユーザーは何を感じているのか？」の感覚をつかむことは、プロダクトの方向性を決めるのにとても役に立ちます。大多数の見えない満足感が、プロダクトの大きな原動力になっていると感じたりもします。

要望については自発的な問い合わせによって判明しますが、どう満足しているかという内容は、自ら届けてくれることは稀なので、こちらから取りに行くことが大切です。

調査をしていくうちに、「ユーザーはきっとこれが好きで、こう使ってくれるはず」という考えが、ただの妄想に過ぎないことが分かってきます。
「これは絶対使われるはず」という予測が外れることもありますが、一方「まさかこの機能がこんな使われ方をするなんて...」という体験もよくあります。ユーザーの声をたくさん聞いて、仮設を立てて、検証を繰り返すことが大切ですね。

普段のコミュニケーションのように、プロダクトの機能と向かい合うよりも、使ってくれている人とコミュニケーションを取ることを想像すると、全く使われない機能にはなりにくいと思います。

※ちなみに、インタビューしてくれたユーザーにアプリレビュー依頼をすると、快諾してくれる方が多いので、アプリレビューが欲しい場合は頼んでみるのもよいでしょう。

直帰してしまうユーザーが多い

困った

見てはくれたが、ほとんど使わずにいなくなってしまうユーザーが多い

対処

直帰した理由を探す
- 期待外れだったかもしれない
- 「最高！」という体験が出来ることに気付かなかったかもしれない
直帰してしまったユーザーの声を聞く
- プロダクトに何を期待していたか
- 何か不満はあったか

Google Playアプリに関しては、『期待外れだったかもしれない』場合は、ストア情報にプロダクトの実態をなるべく記載する、『「最高！」という体験が出来ることに気付かなかったかもしれない』場合は、初回起動時のユーザー体験を適切なものにする、といった対策をとります。

「最高！」という感覚は、「アハ体験」に近いと思います。アハ体験は、こちらの投稿が分かりやすかったです。

機能開発

作りたい/やりたいことが多く、優先順位が分からない

困った

作りたい機能はたくさんある、でもどの機能を付け足して良いのか分からない
ユーザーからの要望も多く、どれから手をつければいいか分からない

対処

ユーザーの声をさらに聞く
- 問い合わせ内容
- NPS(ネット・プロモーター・スコア)の評点と、その点数を付けた理由
ある程度は直感に頼る
- スピード早く動けるのは個人プロダクト開発の強み

ユーザーの課題が分かったとしても、その課題を解決するために様々なアプローチがあると思います。
そのために、もっと課題を分類したり、その中の課題のうちどれが「解決したい」という温度感が高いのか、というのをつかむために、さらにユーザーの声を聞くようにするとよいです。

また、課題よりももう少し具体的である「要望」については、問い合わせなどで顕在されてるとは限らず、多くの人が微妙に困っているだけで、問い合わせするほどでもない潜在的な要望も潜んでる可能性があります。目に見える要望と、潜在的な要望も、両者含めて全体感を把握していくのがベターです。

NPSとは

NPS (Net Promoter Score) とは、どれくらいのユーザーがプロダクトを愛用してくれているのかを知ることができる指標です。

「あなたはこの製品を友人や同僚に薦める可能性は、どのくらいありますか？」と聞き、0-10点の11段評価から選んでもらいます。
転職会議やSoundCloudやTreasureData等、多くのプロダクトで取り入れており、皆さんも一度は目にしたことがあるかもしれません。

NPSは事業成長と高い相関関係にあると言われているため、ウォッチすべき指標の1つです。
NPSを取得すると同時に、フリーテキストで点数の理由を求めるようにすると、この意見はどのくらいの評点と紐付いているかが分るようになり、とても参考になります。

アプリをわずか10分間利用した人から、NPSとその理由を聞いています。比較的早いタイミングで聞くことで、プロダクトのことを気に入らなかった離脱前のユーザーも、答えてくれるようになります。

NPSの数値変動に対して理由や対処を考えることももちろん大切ですが、NPSと同時にフリーテキストで意見を拾うことが一番の目的だったりします。
機能が多いプロダクトであればNPSの要因推測が結構難しく、時には何もしなくてもNPSが変動したりします。
Google Playのアプリの特徴でもあるかもしれませんが、例えば週に1000くらいのユーザーからNPSを取得したとしても、何もしなくても+/-10ポイントは翌週にて変動していることもあります。

それぞれの点数には、以下の意味が付いています。

推奨者：10、9点。＜プロダクト名＞のファン。全く同じものがあったとしても＜プロダクト名＞を使う。
中立者：8、7点。満足はしているが受け身。競合になびきやすい。
批判者：6〜0点。自分の扱われ方に失望している。否定的な口コミを流す。

参考書籍: ネット・プロモーター経営〈顧客ロイヤルティ指標 NPS〉で「利益ある成長」を実現する

機能が増えて、分かりづらくなってきた

困った

プロダクトに機能を盛り込み過ぎて、UIが分かりづらくなってきた

対処

ユーザー体験フローの見直し
- UIを丸ごと作り変える
もしくは細かい改善
- 使ってほしい機能を、より使いやすいポジションへ
- 利用頻度が低い機能は、プロダクトの奥の方にまとめる

機能追加を続けていけば、ユーザーの目先の満足に繋がります。
しかし機能追加が積み重ねると、プロダクトが肥大化し、どの機能も消せなくなり、全ユーザーの8割は全機能の2割しか使わないような、何を目指してるか分からないプロダクトになる可能性があります。

一貫したプロダクトデザインとして、課題解決のためにユーザーにしてほしい行動を定義すると、強化したい機能や、削ってもよい機能が明確になったりします。

希望通りの機能を作り過ぎず、ターゲットユーザーの課題を解決することに注力します。

ユーザーから強めの要望がある

困った

あるユーザーから強い要望をいただいたが、少数意見なのでその機能を入れていいものか迷う
対応するとしても、機能作成に時間がかかり、すぐには対応できない
- 心理的に焦る

対処

定義している課題を前提に、ユーザーが何を望んでいるかを見極める
ユーザー満足最大化の方針が決まったら、割り切る

大多数のユーザーから現在望まれている、そして今後望まれることが明確になってくると、要望の強さに関わらず信じたものを作ることができます。

ユーザーから具体的な機能の提案がある中では、以下の選択肢がある思います。

ユーザー提案の機能をそのまま作る
ユーザー提案内容とアプローチは異なるが、ユーザーの要望が満たされる機能を作る
ユーザー提案・要望は無いが、ユーザーの課題がより解決されるための機能を作る

もし、「ユーザー提案の機能をそのまま作る」だけをし続けると、プロダクトの方向性がぶれやすく、気づかぬうちに今までのファンが減ってしまうこともあるかもしれません。意見は参考にしながらも、できるだけ「3.」のアプローチを目指し、ターゲットユーザーが満たされるための機能を作ることにフォーカスします。

機能を大きく変えすぎると、ユーザーが困るかもしれないのでやりたくない

困った

機能を変えると、ユーザーからの問い合わせが増える
大きく変えるのはリスクで、逆に使いにくくなるかもしれない
批判も増えてしまうのが怖い

対処

今使いづらくなったとしても、それでプロダクトの方向性が修正されるならば、将来のユーザーにとって良い改修といえる
使い慣れたものを変更されれば、一旦は必ず使いにくくなる

指標

急激に成長しない (常にじわじわ)

困った

改善を続けてはいるが、なかなか急激に成長しない

対処

要望を超えた欲求を予測し、ドラスティックに機能追加・変更する
予測は当たる可能性が低いため、予測が正しいかどうかを少ない工数で試す方法を考える(MVP)

秩序が保たれた今のプロダクトを壊し、色々な意見が届くことは認識しながら、ドラスティックな修正を重ねていかないと、もう一段階上の成長は狙えません。

何もしてないのに、数値が・・・ (Google Playの場合)

困った

何もリリースしていないのに、継続率が下がった
原因が分からない

対処

Google Playが流すユーザー属性を変えている可能性
年代が結構変わる

継続率に限らず、直帰率やCVRも謎の動きをすることがあります。ユーザー属性がどう変わったかを見ると、説明が付くことがあります。

急にダウンロード数が増えたと思ったら、また下がってしまった (Google Playの場合)

困った

ダウンロード数が急に3倍になったが、数日後にまた元に戻った
元に戻ってしまったし、これ以上成長しないのかもしれない

対処

ダウンロード数は、Google Playのさじ加減によるところが大きい
特に機能を変えなくても、急に上がったり下がったりする
ダウンロード数が落ち着いてしまっても、成長する可能性は全然ある
気にせずユーザーにとって良いプロダクトを作り続けることが大切

Google Playのアルゴリズムを推測していくことは割に合わないので、「おすすめされたり、似たアプリとしてレコメンドされているんだな」くらいの認識でやり過ごしています。何かの変更とダウンロード数の因果関係を結びつけるのは割と難しいと感じます。

ちなみに5000インストールを超えた頃からdailyインストール数が急激に伸びる傾向があるらしく、私のアプリもそうでした。当時は嬉しかったですが、また下がりました(しかもそのあとまた上がってそのままステイしている)。こういったことがあるので、気にするべきところはダウンロード数ではないと今は感じてます。

悪い評価が付いてしまった (Google Playの場合)

困った

まだ評価が少ないにも関わらず、悪い評価やレビューが付いたのは痛く、「わざわざ何故...」という気持ちになる
今後のレビューも、悪い評価に影響されるかも・・・

対処

悪いレビューも正当な評価
悪い評価が悪い評価を呼ぶことは、長期的(数ヶ月単位)で見たら無かった

悪いレビューは嫌がらせではなく、呼び込んだユーザーとプロダクトのミスマッチによる正当な評価のため、もやもやせずに努力の方向を変えるとよいです。今後悪いレビューを防ぎたいのであれば、呼び込むターゲットユーザーのニーズとプロダクトをマッチさせることに注力すればOKです。
アプリ公開当初、レビュー数が二桁台だった時に★1が付き、とても落ち込みましたが、今では★4.8を維持できています。

閑話休題: 指標、成長に関する用語

DAU/WAU

Daily Active User/Weekly Active User。
アプリの機能が少ない時は、総合DAU/WAUは参考になりますが、
アプリが多機能化してくると、総合的なDAUだけでは分からないことが出てきます。
機能が増えてきたら、それぞれの機能のDAU/WAUを測るとよいかもしれません。

継続率

今最も上げたい指標です。「穴あきバケツの成長モデル」の話を参考にしています。

プロダクト固有の指標

例えば、私のプロダクトには投稿機能があるため、

新規ユーザーの投稿率
新規ユーザーの1日後継続率（投稿・非投稿別）
7日後継続率（投稿・非投稿別）

というような指標を見ています。プロダクト固有の指標ですね。

Problem / Solution Fit (PSF)

リーン開発の概念の1つで、ターゲットユーザの課題(Problem)と、その課題の解決策(Solution)が、適合(fit)している状態のことです。
後述する「Product / Market Fit」と対になる指標です。

極端な話、何をするにもまずはPSFを完了させることに集中し、それ以外のことにはなるべく時間をさかないようにしています。これまで記載してきたユーザー課題の明確化やユーザーの満足度などの話は、PSFを達成するための手段です。

ターゲットユーザーの課題とは？
それに合う解決策とは？
PSFの完了定義は？

PSFを目指すには、まずこれらを明らかにします。
完了定義は定量化し、仮説とグラフを一緒に見えるようにしておくと、何に時間を使うべきかに立ち戻ることができます。

Product / Market Fit (PMF)

リーン開発の概念の1つで、最適な市場(Market)に、最適な解決方法(Product)が、受け入れられている(Fit)状態のことです。
PMF到達は、スタートアップにとっては何よりも大切なことと言われていますが、到達までのプロセスにはPSF達成が伴ってくることもあります。

例えば、今私たちが提供しているアプリは、AndroidのみでiOS対応はしていません。
Androidアプリのユーザーにある程度受け入れられているため、iOS対応をすることによって、ユーザーが倍以上になることは予想できます。
しかしユーザーを増やしてしまうと、プロダクトの変更コストが上がり、変更によるリスクも大きくなるので、PSFを確立させた後の方がより安心して集客できます。

参考書籍: リーン・スタートアップ

検索順位 (Google Playの場合)

Androidアプリの場合、Google Play内での検索順位は見ておきたい指標になります。

しかし、Google Playではビッグワードで検索順位が1位になっても、インストール数がそこまで変わりませんでした。
例えば「ポエム」というワードでで10位、5位、1位と検索順位が上がったにも関わらず、ダウンロード数がそれに応じて伸びたようにはあまり見えません。
ダウンロード数がはねた際も、Google Playの検索順位はそれほど変化はありませんでした。

ではなぜダウンロード数が急増したかというと、おそらく「あなたへのおすすめ」や「類似コンテンツ」に多く表示されるようになった、という推測をしています。ユーザーインタビューの結果から見ても、あなたへのおすすめからの流入ユーザーが多いなと感じました。

各指標の見かた

DAU、WAUは毎日見てますが、だいたいの指標は、アイディアを出したいときや、大きく改修したときの変動をチェックするために見ています。
一般的な平均値も分かりませんし、継続率を除いては、「この指標をあげよう」といった施策もそこまで力を入れてません。

マネタイズ

マネタイズ方法が分からない

困った

マネタイズしたいが、何から手を付ければいいのか…
自分のプロダクトは収益化に向いていない

対処

ファンがいれば、マネタイズ手段は必ずある
広告でマネタイズできなそうでも、課金や提携、バイアウトという方法も
ユーザーからの要望を恐れずに、マネタイズ手段をPDCAする

アプリを継続したい場合、マネタイズ戦略の検討は後回しにせず、なるべく早めに着手することをオススメします。

マネタイズ戦略よって、作るものもだいぶ左右されると思いますし、収益構造を作っておくと、それを軸にして機能を考えることになるためです。

逆にいうと、マネタイズ施策を入れてしまったために、プロダクトの質を下げるにも関わらず収益構造を壊すことができない、というデメリットもあるので注意は必要です。

マネタイズしようとしたら、ユーザーから反対意見が出た

困った

有料機能を付けたら、今まで全て無料で使っていたユーザーからの要望・問い合わせが増えた
問い合わせが増えるため、有料機能を付けるのに二の足を踏んでしまう

対処

ユーザーが増える前に、早い段階でマネタイズ方法を確立する
要望・問い合わせが増えるのは当たり前と考える
プロダクト継続とユーザー価値最大化のために、ボランティアではなくマネタイズが必要と考える

どんなにアプリを気に入ってもらえても、マネタイズを考えないとプロダクトが自然消滅しやすくなります。
この先使ってくれる人のためを思えば、問い合わせに対応しつつマネタイズを考えられる心の余裕ができます。

収益が上がらない

困った

課金システム、広告導入、色々試しているが、なかなか収益が上がらない

対処

(まだそこまで収益化できてないが・・・)
とりあえず様々なビジネスモデルを果敢に試す
モノを売る場合は、モノ自体の価値を高める以外の付加価値も検討する

モノの価値を高めるのと同時に、同じモノを売るとしてもどうやって「買いたい」という気持ちにさせるかも重要だと思います。
情報や物を売る場合、同じモノを売るとしても、「モノを買う体験」にストーリー性を持たせることによって、付加価値を付けることが出来ます。

自分のプロダクトで生計を立てたい

困った

このペースだと、自分のプロダクトで生活できるようになるまでいけるとは到底思えない

対処

成長は線形とは限らず、指数関数的に伸びることもある
地道な作業が実を結び、突然数字が上がるのを信じる

プロダクト成長のためには地味な作業を地道に行うことが実を結ぶ、という心持ちを大事にして続けています。
アイディアも豊富にありはしますが、同じアイディアを考えてる人は必ずいますし、どれだけ実行できるかが勝敗の分かれ目だと思います。

マインドセット等、その他

作った機能が使われないどころか、批判の声があり心が折れる

困った

期待をかけて作った機能に対して、批判的な声が上がった
その機能は、「喜んでくれるかな」と期待して頑張って作った機能だった
組織で働く場合は間接的な成果を出せばよい一方、努力の分だけ報われるわけではないと感じる
大きなチームで作っているのならまだしも、個人プロダクトなのでまるで自分が否定されたかのように思う時も・・・

対処

逆にそれくらい使ってくれている人が多いということ
喜んでくれる人に目を向ける
個人の否定では決してなく、寧ろわざわざ声を上げてくれたことは非常にありがたいこと

真似されたらどうしよう

困った

人は集まって来たが、資金力のある法人が同じプロダクトを出してきたら、一瞬で終わるのでは…

対処

そもそも、そうそう真似されない
上辺だけ真似されても大丈夫
メディアに取り上げられるのを避ける
先行者優位を築こう
個人プロダクトだからこその強みを活かす

webやアプリのプロダクトは特に、ほぼノーコスト(開発時間と僅かなサーバー代だけ)で世に出せ、収益が入るという算段がつくまで、時間が許す限りいくらでもテストをすることができます。
その分ライバルも多いため、上手く市場やニーズを見つけ出せないと、既存プロダクトからユーザーは移ってこないですし、見つけ出せたとしても先行者優位を獲得しないとヒットしても真似されるかもしれません。

しかし、自分では流行ってると感じるかもしれないけれど、相当流行らないと多分企業は見向きもしないので、個人でやってる限りは真似される心配はあまりしなくていいと思います。

また、時間をかけてみつけたユーザーの本当の課題と、それに対応する改善プロセスがあるため、上辺だけ真似されたとしても追い越されはしないのではと思います。

それでも心配であれば、なるべくメディアに出さないようにしましょう。そのメディアを見ているユーザーが、プロダクトの対象ユーザーでなかったり、投資を受けることを考えていない場合は、メディアに出すメリットをあまり感じません。

また、先行者優位を築ければ真似されることへの心配がさらになくなります。
営業が大切になってくるtoBだと、市場を取りきるのは難しいかもしれませんが、toCだと必ずしも営業が必要ないので、「たくさんの人が使ってるからこそ、そのプロダクトを使い続けたい」という理由を上手く作ってあげましょう。

個人の強みと、企業の強み

個人での開発は、大企業に負けない強みを確実に持っています。
企業では人を雇っており、従業員の生活を支えていかないといけないため、開発にかけた時間をなるべく収益に繋げる必要があります。成功するかどうかわからない開発ほど、慎重になります。

一方、個人的な開発は一切失敗を気にしなくてよくて、極端な話「これを変えてみよう、なんとなく。」という自分の感覚だけに頼って開発を進めても一向に構いません。自身のさじ加減で次々と機能を変えていけるというスピード感は、個人プロダクト開発の明らかな強みです。

しかし、企業はある意味専門家の集合ですし、チームは個の力の総和よりも大きな力を引き出せるため、企業は企業でプロダクト開発の強みを持っています。

個人と企業、どちらで働くかで何を活かすかが変わってきます。

個人で開発する場合、切り分けて考えないといけないのは、必ずしも自分のさじ加減が次々上手くいくとは限らないということです。
自分の感覚で好き放題やるよりも、人や本などからの情報を絶えず取り込んで、自分の選択を洗練化させていくほうが、プロダクト成功により近づけるはずです。

問い合わせが多すぎて返答しきれない

困った

問い合わせが多すぎて返信する時間がない
すぐ返答したいのに、心苦しい

対処

ある程度は返信文をテンプレート化
丁寧さよりも、早さを重視
人が足りず、返信に時間がかかる旨を、正直にユーザーに伝える
具体的にどれくらい返事に時間がかかるかを、明示する
FAQ活用

はじめは丁寧に返答文を書いてましたが、問い合わせする立場に立ってよくよく考えてみると、「多少丁寧でなくてもよいから、早く返してほしい」と思うことに気付き、それからは丁寧さよりも早さを重視してメール返信をしています。

サービスの性質やユーザー層にもよりますが、丁寧なよりも、多少チャット的な文章に寄せた方が、親しみやすく好感が持てることもあります。

問い合わせへの返信スピードを上げるだけでなく、問い合わせの数を減らす工夫も必要です。
例えば、メーラーで新規作成画面を開いた際に、最も多いFAQをメッセージの中にデフォルトで記載しており、問い合わせを送る直前に必ず気付けるようにしています。

また、問い合わせへ返答をする際は、ユーザーが得る情報が非対称にならないように注意しています。情報開示は公平にしないと、一部のユーザーからの信頼を失うことになるかもしれません。

サイト落ちすぎてやばい

困った

最近よくサイトダウンする

対処

(その時のケースだと) MySQLクエリチューニングであっさり解決した
- インデックス戦略に任せず、クエリによって利用するインデックスを指定
メモリ使いすぎのケースもあった
ケースに応じて対処は異なるので、まずはLoad Average、空きメモリ、CPU使用率などを調べていく

副業できない

困った

会社が副業禁止

対処

副業OKの会社はたくさんあります

【完全版】副業・兼業OK・Wワーク歓迎な有名企業39選

弊社リブセンスも副業OKですリブセンスの副業への考え方についてはこちらの記事が参考になります。

「会社の仕事はするけれど、同時に副業でお金を稼ぐというスタイルも当たり前になってくると思うんです。自分で書いたスマートフォンアプリが当たればすごい収入が得られる時代に、副業禁止の原則はありえない。実際、雑誌の記事執筆やメディア運営などを個人で行っているエンジニアがうちにもいますからね。当社も副業のガイドラインを策定して、その対応をしようと考えています」

おまけ: 恋人との開発

レアケースですが、パートナーと共にプロダクト開発をすることになった場合、様々な困難が待ってるかもしれません。
夫とは結婚前から今に至るまで、協働でプロダクト開発しており、その時に得た知見がありました。

彼/彼女が最近協力してくれない

困った

はじめは意気投合していた恋人が、最近あまり手伝ってくれない
恋人とはあんまり言い争いたくない

対処

相手のモチベーションに合わせて頼む
「自分の時間を自由に使いたい」という気持ちは自分にもあることに気付く
プロダクト開発を通して達成したいことを話し合う

個人のプロダクト開発はプライベートの時間を使います。
「もっと成長させたい」というモチベーションの波はお互いそれぞれ違っていて、相手のモチベーションを感じながら協働していくとよいです。

自分のモチベーションが高いときは、自分でやってしまえばよいのです。例えばプログラミングが出来なかったら少しづつ勉強して、相手に質問したりして頑張っている姿を見せるうちに、お互いのモチベーションがまた高まってくることもあります。

彼/彼女とプロダクト方針で喧嘩になる

困った

プロダクト方針が恋人とすり合わない
明らかに自分の案の方がユーザーを増やせて、相手にとっても得なはずなのに分かってくれない
本当は、別のプロダクトを一緒に作りたいな・・・

対処

どんなプロダクトを使いたいかを決めるのはユーザーなので、自分の案が100%正しいとまだ決めることはできない
予想外の反応をするのがユーザーであるので、ユーザーに聞けば良い (MVP、インタビュー、など)
目一杯楽しめないならば、無理して協力しない

人によって、プロダクトの作り方は異なります。
例えば私たちの例だと、

夫: 理論重視。プロダクト過去・現在・未来の状態を定義し、各々のプロダクト成長手法から最適な方法論を適用する。
私: 感覚重視。ユーザーの思いがなんとなく高まってきていると感じたら、それを満たしてあげたくなる。

といったように考え方のクセがあります。

「自分の案の方がよいのに…」ともし思ったとしても、正解は誰にも分からないので、相手の意見を否定しないで傾聴して、相手のプロダクト作りへの考え方を考慮に入れてコミュニケーションすると、よい議論が出来るはずです。
(自分の案に誘導しないように注意する)

またお互いのこだわりポイントも異なり、夫はプロダクトでコミュニティを作りたいということにこだわりがあり、私は「個人で」というところにこだわりがあるため、同じ志向ではないからこそ良いチームワークが築けることもあると感じます。
「プロダクトを成長させたいのは何故か？」を共有し合うと、協働がスムーズになるのではないでしょうか。

意見が異なることがあるのは当たり前で、理論的過ぎても、感覚的過ぎてもいけないのを、お互いに分かっているから、それぞれの得意技を活かせるのかもしれません。