思いついたら、さっさと作れ!

思いついたら、さっさと作れ!

思いついたら、さっさと作れ!

個人開発にニーズ調査はいらない。「準備」と称して企画に延々と時間をかけるのは無駄

本記事は “Why Needs Assessment is Not Necessary For Your Niche Product” の日本語訳です。

こんにちは、TAKUYAです。InkdropというMarkdownノートアプリを一人で開発しています。このアプリは一人で企画から運用までやって、先月の売上は40万円を超えました。以前、ローンチさせて最初の売上を得るまでの話を書きましたが、その中で個人開発としてどんなアプリを作るとよいのかという話をしました。毎日感じるちょっとした問題を見つける、というものです。本稿ではこの話についてもう少し掘り下げて書きたいと思います。

沢山のユーザに使ってもらえるサービスを考えるのは簡単ではありません。それを事前に知るのはほぼ不可能です。でも僕は多くの人が「これ、欲しいと思う?」と聞いて回るのを見ました。彼らは失敗を恐れているように見えます。自分の時間と努力を無駄にしたくないようです。もし解決したい問題を見つけたなら、それに今すぐ取り組むべきです。周りがそれをどう思うかなんて気にする必要はありません。その理由について説明します。

Inkdrop — Jot down your daily hacking endeavors.

周りの意見は信じなくていいです。

僕はInkdropを作っている時に、友人にその話をしました。でも彼らの答えは「別にいらない」でした。しかも僕が抱えている問題を理解すらしてもらえませんでした。僕は間違っていたのでしょうか?そんなことはありません。Markdownエディタやノートアプリはすでに巷にあふれていましたが、僕はそれに満足していませんでした。UIデザインやシームレスなデータ同期、シンプルさ、パフォーマンスなど、そのこだわりを理解してもらうのが難しかったのです。自分と同じ問題を抱えていない限り、簡単には深く理解してもらえません。

僕のアイデアを理解してもらえないというのは寧ろ良い事です。もし理解できたなら、僕の問題を解決してくれるアプリはすでに存在していたでしょう。僕は数年間探し続けましたが、見つけられませんでした。それは別に、僕と同じような人が一人もいないという意味ではありません。だって自分は特別でもなんでもなく、普通の人間だからです。ただ単に、他の人達がその問題に気付いていないか、気付いているけど技術的なハードルが高いのです。

If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. — DHH訳: もしあなたが何か問題を抱えているなら、そこには何百何千もの人が同じように悩んでいる可能性が高い

まだ存在しないサービスを想像するのは難しいです。あなたが誰かに自分のアイデアを話すと、だいたい「え、本気で言ってる?」というような反応を示すでしょう。なぜならそのアイデアは洗濯機や冷蔵庫みたいな製品とは違うからです。ニッチ製品はほとんどの人にとって奇妙に聞こえるものです。現にInkdropをリリースしたら、「これが正に自分の求めていたものだ!」と何人かに言われました。彼らはやっと僕の問題を理解したのです。

もしそれがあなたの問題を解決するのなら、人が言ってることなんか無視して作業を続けて下さい。もちろん、彼らの言う通り沢山の人には使われないかもしれません。でも同様に使われる可能性だってあるのです。それはリリースするまで誰にも分かりません。

ブログはその事が知れる良い例です。ブログは記事を公開するまでバズるかどうか分かりません。どれだけ入念に徹底してライティングの成功法則に倣って書いたとしても、バズるかどうかは依然として分かりません。先日、自分の書いた記事がHacker Newsで話題1位になりましたが、それは全くの予想外の出来事でした。

ブログの記事は贈り物です。記事がいつも誰かにとって有益で、シェアしてもらえるとは限りませんし、期待もできません。それは全て読者次第です。ただやれる事は、記事を書き続けることです。MVPを素早く作ってとにかくリリースして何が起こるか見ろ、と成功者が口を揃えて言っているのは、まさにそれが理由です。

Start by making something clean and simple that you would want to use yourself. Get a version 1.0 out fast, then continue to improve the software, listening closely to users as you do.— Paul Graham, from “Hackers & Painters: Big Ideas from the Computer Age”訳: 簡潔で簡単で、自分が使いたいモノをまずは作れ。バージョン1.0をさっさと出して、それを改善し続けて、ユーザの声を親身に聞け。 — ポール・グレアム

繰り返しますが、同じ問題を抱えた人は一定数います。そこを心配する必要はありません。ただ、ニッチ製品は人々に見つかるまでに時間がかかります。Inkdropは最初の正式リリースから成長し始めるまでに一年かかりました。以下のStripeの売上レポートでその様子を見ることが出来ます:

月間売上レポート

製品をリリースしてすぐに何も起こらなくても、気にしなくていいです。誰も気付いていないだけだからです。すぐに見切りを付けるのはやめましょう。製品が知られ始めるまでにやれることは、以下に示す3つがあります。

自分が欲しいから作っている。だとすれば、その製品が目指すイメージはあなたの頭の中にあるはずです。それに近づけましょう。開発していると、自分が何を解決したいのかがより具体的になります。そして自分自身がヘビーユーザになりましょう。毎日使うのです。もしそんな気分にならないのなら、問題が実際に解決できていないか、もしくはそれほど大きな問題ではなかった可能性が高いです。

ユーザはあなたと同じ問題を抱えた仲間です。彼らは他にも似た人を知っている可能性が高いです。そんな彼らに口コミで広げてもらえるように、ファンになってもらうのです。以前書いた通り、それは大企業が出来ないようなユーザサポートをすることで可能です:

Inkdropのユーザ流入のほとんどは僕自身のブログからです。あなたは自分の製品に関連する話題について沢山ネタを持っているはずです。僕がなぜInkdropを作ったかと言うと、自分の生産性やクリエイティビティへの意識が高かったからです。だからそういった話題についてなら書けることが沢山ありました。そうして書いた記事が、アプリを知ってもらえるきっかけを作るわけです。もちろん昨今ではブログだけでなくYouTubeやポッドキャストなどいろいろ情報発信手段は揃っているので、好きなものを使うと良いでしょう。

もし失敗が怖くてしょうがない場合は、次に挙げるような問題を抱えている可能性があります。

もしモノを作る理由が人気者になりたいという事なら、それが恐怖の原因です。なぜなら、もし失敗すればあなたは人気者になるほどの価値がないという証明になってしまうからです。つまり自分自身が怖いのです。他人に自分の幸せを委ねています。そしてその内面は製品に表れてユーザに伝わります。「私はすごい!私を褒めて!」というように。もし心当たりがあるなら、自分のモチベーションについて見つめ直したほうが良いです。

もし好きな事なら、他人がどう思うかなんて気にならないはずです。なぜなら、それをやってる時点であなたはすでに楽しくて幸せだからです。もちろん良い製品を作るのは大変です。でも、興味のない領域で良い製品を作るのはもっと大変です。これはサイドハッスルです。もっと楽しみましょう。

失敗は沢山の学びをくれます。失敗から学ぼうという姿勢があれば、それは無駄ではありません。次はもっと上手くやれます。トライしてトライしまくるのです。そしたら成功率は徐々に上がります。賢い人は過去に沢山の失敗を積み重ねているから賢いのです。

あなたはすでに幸せです。だってやりたい事があるんですから。それを「準備」と称して無駄にしないで下さい。今やりましょう。

Read more

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6.0.0 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山 こんにちはTAKUYAです。 v6.0.0 の最初の Canary バージョンをリリースしました 😆✨ v6では、アプリのコア機能の改善がたくさん盛り込まれています! * リリースノート(英語): https://forum.inkdrop.app/t/inkdrop-desktop-v6-0-0-canary-1/5339 CodeMirror 6 ベースの新しいエディタ フローティングツールバー v5ではツールバーがエディタの上部に固定されており、使っていないときもスペースを占有していました。 v6では、テキストを選択したときだけ表示されるフローティングツールバーに変わりました。 GitHub Alerts 構文のサポート Alerts の構文が正しい色と左ボーダーでハイライトされるようになりました。 ネストされたアラートや引用にも対応しています。 また、アラートタイプの入力を支援する補完機能も追加されました。 スラッシュコマンド 空行で /

By Takuya Matsuyama
AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった こんにちは、TAKUYAです。日本語ではお久しぶりです。僕はInkdropというプレーンテキストのMarkdownノートアプリを、デスクトップとモバイル向けにマルチプラットフォームで提供するSaaSとして、かれこれ9年にわたり開発運営しています。 最近、その開発にClaude Codeを導入しました。エージェンティックコーディングを可能にするCLIのAIツールです。 最初の試行は失敗に終わったものの、徐々に自分のワークフローに馴染ませることができました。そして先日、アプリ開発がまた「楽しい」と感じられるようになったのです。これは予想外でした。 本稿では、自分がエージェンティック・コーディングをワークフローに取り入れた方法と、それが個人開発への視点をどう変えたかを共有します。 * 翻訳元記事(英語): Agentic coding made programming fun again 自分のアプリに技術的負債が山ほどあった ご想像のとおり、9年も続くサービスをメンテするのは本当に大変です。 初期の頃は新機能の追加も簡単で

By Takuya Matsuyama
個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR * 最初はとにかく最速でリリースする事を最優先する * 迷ったら「ときめく方」を選べ * 程よいところで切り上げて開発を進める * 使っているモジュールがdeprecatedされるなんてザラだと覚悟する * 古いから悪いとは限らない * シンプルにしていく * 老舗から継続の秘訣を学ぶ * 運ゲー要素は排除しきれない 最初はとにかく最速でリリースする事を目標に技術選定する 開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多い

By Takuya Matsuyama
子育て中の個人開発者の一日

子育て中の個人開発者の一日

子育て中の個人開発者の一日 どうもTAKUYAです。 久しぶりに生活まわりの事を書きたい。自分はInkdropというMarkdownノートアプリを売って生きている。 子供も無事順調に成長しており、あと数ヶ月で3歳になるというところで、イヤイヤ期もやっと終わりが見えてきた。 生活パターンもなんとなく定着しつつあるので、ここで一旦どんなルーティンなのか書き出してみる。ちなみに当方今年で40歳。 平日の1日の流れ * 06:30 妻と子供起床、朝食 * 07:10–30 俺起床、朝食 * 07:40 布団を畳んで子供を着替えさせる。妻はその間に化粧や通勤の準備 * 08:00 ストレッチと軽い筋トレ(腕立て50回、スクワット100回) * 08:10 妻と子供を見送る。15分前後瞑想 * 08:30 散歩 * 09:00 作業開始(カフェまたは家) * 11:00 昼飯 * 12:00 ダラダラする * 12:30 作業再開(だいたい家)

By Takuya Matsuyama