個人開発だからこそ出来るユーザサポートがある

個人開発だからこそ出来るユーザサポートがある

個人開発だからこそ出来るユーザサポートがある

この記事はHacker Noonに寄稿した「Personal Developer Can Beat Big Company with User Support」の日本語訳です。

個人開発者は大企業にあらゆる面で常に負ける。果たして本当にそうだろうか。大企業はその大きさゆえにとにかく遅い。でも小さなプロダクトは小回りがきく。個人開発者はとりわけユーザサポートで、大企業に勝る素質がある。

自分はフリーランスをしながらInkdropというMarkdown好きのためのノートアプリを開発している。最近、その売上で家賃の半分が賄えるようになった。アプリを購読してくださっているユーザさんもそれを喜んでくれている様子で嬉しい:

自分がどうやって彼らを惹きつけているか、ユーザサポートの観点でその方法をシェアしたい。

ユーザはサポートの返事があるまで何日も待たされることに慣れきっている。大企業のユーザサポートを受けたことがある人なら分かると思う。電話で待たされ、たらい回しにされ、数日後にやっと回答が得られる。だからメールを送信する時、すぐに返事がもらえるなんてそもそも期待なんかしない。

そんな退屈なサポートが当たり前だと思っている人にもし90分以内に返事が来たら、彼らは間違いなく驚く。彼らの不満げな態度はそれだけで180度変わる。自分はもしサポートメールを受け取ったら、その時やっていた作業を可能な限りすぐに中断して返信するようにしている。早い時は数分程度で。するとユーザさんはこう返事してくれる 。 “Thank you for the quick response”と。

もしすぐに回答できないような問い合わせが来ても、とにかく何か返事をする。明確な答えが出るまで保留にするのは良くない。だって相手はその間ひたすら待たされているんだから。つまり即レスを心がけるだけで、ユーザに確実に好印象を与えられる。

たとえ個人開発であっても、アプリは自分一人で作っているわけではない。ユーザのフィードバックがあるお陰で気付かなかったバグが直せたり良いアイデアをもらえたりする。だから、貢献してくれたユーザを称えるのは当然のことだ。もし自分の報告したバグが直って、さらに作者がその事を賞賛してくれたらすごく嬉しい。でも残念なことに、ほとんどのサービスは実践していない。なぜなら、大企業ではそれをやるにはキリがないほど沢山の顧客がいるから。

自分はInkdropの新しいバージョンをリリースした時、リリースノートに必ず貢献してくれたユーザの名前を記載するようにしている:

自分がもともと予定していた機能だろうが、既に気づいていたバグだろうが関係ない。ユーザが何かしらその改善に関わっていれば、賛辞を末尾に付記する。この手法はとても効果的。

この手法はお金がかからない上に簡単に出来る。しかも、ユーザの立場からすると自分がサービスに貢献できた証拠になる。まるでオープンソースに貢献できた時みたいに嬉しいし、周りに自慢したくなる。その上、サービス側はちゃんとユーザの声を取り入れているというアピールにもなる。

もちろんこれはユーザの声に迎合しろという意味ではない。この記事で書いたように、自分が本当に必要だと思った機能だけを検討するべきで、そう思えなければどんどん断っていい。

できない約束はしない。それは周りの人間関係でもそうだろう。ユーザに機能要望を受けた時、 “It’s coming soon..” とつい言いたくなるけど、それは本当に対応の目処が立っている時しか言うべきじゃない。誠実で友好的な態度は、ユーザがプロダクトを信じやすくしてくれる。悪意のない嘘でもつくのはやめよう。

参考になれば嬉しい。

Read more

ノート駆動AIコーディング術の提案

ノート駆動AIコーディング術の提案

どうもTAKUYAです。みなさんはAIエージェントを普段のコーディングで活用されていますか。ちょっと面白いワークフローを思いついたのでシェアします。それは、ノート駆動のエージェンティック・コーディング・ワークフローです。最近Claude Codeのプランモードを使っていたら、ターミナル内で生成されたプランを読むのが辛かったんです。それで、じゃあMarkdownノートアプリであるInkdropをプランの保存先バックエンドとして使えば解決するんじゃないかと思って、 試してみました。こちらがそのデモです(英語): こちらがClaude Codeの設定ファイル群です: GitHub - inkdropapp/note-driven-agentic-coding-workflow at devas.lifeComplete Claude Code configuration collection - agents, skills, hooks, commands, rules, MCPs. Battle-tested configs from an Anthropic hackathon w

By Takuya Matsuyama
2025年個人開発活動の振り返り

2025年個人開発活動の振り返り

どうもTAKUYAです。もう1月も半ばに差し掛かっているけど、2025年の自分の活動の振り返りをしたい。去年を一言で言うなら、本厄を満喫した年だった。 厄年とは、人生の節目にあたって、体調不良や災難が起こりやすいと経験的に言われる年齢のこと。数え年で42歳、確かにもう若さに任せた事は出来ないなと痛感した年だった。(ところであなたの国ではこのような年はありますか?) 夏に体調を崩して2~3ヶ月動けなくなった 暖かくなり花粉が飛び出した頃に、持病のアトピーが悪化しだして、まともに生活出来なくなってしまった。酷さで言うと、2019年に脱ステした時と同じぐらい。 脱ステに無事成功したから、この地獄は二度と味わうことはないだろうと高を括っていたが、まさか7年後にまた味わうとは思わなかった。当時の独身時代と違い、妻も子供もいる中で、周りに多大な迷惑をかける事となった。夏の子供との思い出が全く無い。悲しい。 現在はQoLもほとんど元の状態まで復活できた。写真を撮って症状の変化を記録したので、機会があればシェアしたい。食事療法など色々試したが、結局歩くのが一番自分に効いた。それ以来、一日一万歩

By Takuya Matsuyama
書いて、歩け!なぜノートアプリはシンプルで充分なのか

書いて、歩け!なぜノートアプリはシンプルで充分なのか

どうもTAKUYAです。今回はノートやメモから新しい発想を生むための考え方についてシェアします。 自分はシンプルさをウリにした開発者向けのMarkdownアプリInkdropを作っています。なので、どうしても「ノートアプリの作者」としてのポジショントークが含まれてしまいますが、逆に言えば、「ノートアプリを約10年間作り続けてきた人間が、どうやってアイデアを生み出しているのか」 という実際的な体験談として読んでもらえれば幸いです。 結論から言うと、僕は「アプリ上でノート同士を連携させる必要はない。繋げるのはあなたの脳だ」と考えています。本稿では、ノートアプリの機能に溺れずユニークなアイデアを考え出すために僕が実践している事をシェアします。 TL;DR * ノート整理に時間をかけるな。グループ化で充分だ * すごい人はアイデアが「降りてくる」のを待つ * プログラミング × 料理動画 という有機的な掛け合わせ * ノートは「忘れる」ために書く * 歩け! ノート整理に時間をかけるな。グループ化で充分だ 巷ではZettelkastenなどが流行っているようですね。これ

By Takuya Matsuyama
貫禄を捨てて愛嬌で生き延びろ!40代オッサンの生存戦略

貫禄を捨てて愛嬌で生き延びろ!40代オッサンの生存戦略

どうもTAKUYAです。 つい先週(11月19日)に誕生日を迎え、41歳になりました。40代と言うのは若い頃には想像もしなかった年代で、どう生きれば良いのかというイメージがあまり具体的に湧かない、曖昧な年齢ではないでしょうか?自分の父親を想像するも、日中はいつも仕事でいなかったのであまり参考になりません。 自分は個人開発で生計を立てていて20代、30代で積み上げて来たものが上手く実を結んだおかげで今の生活があります。育児にも、いわゆるサラリーマンよりかは柔軟に参加できていて、子供との時間も沢山取れています。ママ友も出来ました(迷惑かけっぱなしですが)。 本記事では、そんなライフスタイルを送る自分が40代で大事にしたいことについて書きたいと思います。タイトルにもある通り、結論から言うとそれは「愛嬌」だと思います。以下、中年男性の愛嬌の重要性について説明します。 TL;DR * 「貫禄が出てきたね」と言われたら注意 * 笑顔を作れ。オッサンがムスッとしてたら普通に怖い * 謙虚に振る舞え。実績を積むと周りが萎縮する * ギャップ萌えを活用しろ 「貫禄が出てきたね」と言わ

By Takuya Matsuyama