個人開発で題材に迷うと、先に使いたい技術を探してしまう。 新しいAPI、面白いフレームワーク、作れそうな画面。 それらは始める理由にはなるが、使われ続ける理由にはなりにくい。
私が題材を考えるときは、作れるかどうかより、同じ不便に何度も出会っているかを見直す。 一度だけの面倒は、手で済ませればよいかもしれない。 何度も繰り返され、そのたびに誰かが少し困っているなら、そこには観察する価値がある。
困りごとは、作業の途中に現れる#
「こんなアプリがあればいい」と言われる場所だけを探す必要はない。 困りごとは、作業を止めた瞬間や、説明をあきらめた瞬間にも現れる。
たとえば、同じ数字を複数の場所から集めている、設定方法を毎回説明している、便利な手段があっても難しそうで使われない。 こうした場面では、機能不足より前に、手間や不安が利用を止めていることがある。
観察するときは、次の三つを分けて記録すると考えやすい。
- 繰り返し：誰が、どの頻度で、何をやり直しているか
- ためらい：途中で何を不安に思い、どこで止まるか
- 代替手段：今は何で済ませていて、何が負担になっているか
困りごとの言葉だけを集めるより、その前後の行動を見るほうが、作るべき範囲を小さくできる。
価値は、機能を増やすことではなく負担を減らすことにある#
既存のサービスと同じ目的を持つことは、失敗の証拠ではない。 利用者が同じ目的を、より少ない判断や不安で達成できるなら、そこに違いが生まれる。
個人開発では、すべての人に必要な機能を揃えるより、特定の利用者が最初の一歩を踏み出すまでの負担を減らすほうが現実的だ。 入力項目を減らす、初期設定をなくす、結果の読み方を先に示す。 小さな変更でも、利用者の仕事が一つ終わるなら価値になる。
先に、支払う理由より使い続ける理由を確かめる#
価格を決める前に、使い続ける場面を想像する。 初回だけ便利な機能は、無料でも継続しにくい。 一方で、定期的に確認したい情報、毎回面倒な手順、失敗すると困る作業は、戻ってくる理由になりやすい。
最初に得る小さな対価は、金額そのものよりも、「この負担を減らすことに意味がある」と誰かが判断した記録になる。 その記録を急いで一般化せず、どの場面で使われたかを聞き直すと、次の改善が見える。
作る前に、手作業で一度だけ届ける#
題材が見えても、すぐに大きな機能を作らない。 まずは、同じ結果を手作業で一度届けられるかを試す。 手作業で説明できない価値は、画面にしても伝わりにくい。
この段階で分かるのは、実装の難しさだけではない。 利用者が本当にほしい結果、途中で不安になる点、こちらが勝手に重要だと思っていた機能が見えてくる。
題材は、ひらめきを待つだけでは増えない。 生活や仕事のなかで繰り返される小さな不便を、途中の行動ごと観察する。 その観察を続けることが、作れるものを探す時間より、長く使われるものに近づくと思っている。
