「実装しない」機能の決め方

Share
「実装しない」機能の決め方

「実装しない」機能の決め方

個人開発のアプリはシンプルさが肝要。AdobeやMicrosoftのような巨大企業でない限り、機能で勝負しても負けるのは火を見るより明らか。難しいことは他に任せて、自分が解決したい問題にだけ集中する。作りたいアプリ像がはっきりしていれば、機能の取捨選択は簡単にできる。

拙作のInkdropというMarkdownノートアプリも、無駄な機能を付けないように努めている。そのためならユーザの要望も遠慮無く断る。今このアプリにお金を払ってくれている人は、そのシンプルさを買ってくれていると断言できる。ユーザさんにヒヤリングした時、以下のようなメッセージを貰った:

My suggestion would be to try to keep the app clean and simple, focus on supporting developers primarily and not to over-complicate things (like basically all the other note-taking systems out there). — Inkdrop user

では具体的にどのようにしてInkdropはそのシンプルさを保っているのか、その事について共有したい。

アプリをシンプルに保つには、どの機能を「付けないか」という判断が全て。一度付けてしまったら後戻りは出来ない。機能を削ればたちまち批判の嵐が巻き起こるから。

自分はこの付けない機能を判断するために、数年前に読んだ以下の記事を今も参考にしている:

付けない機能を判断するには、まず機能を重要度によって以下の3つに分類する:

  1. Core — アプリの主要な機能。これがないと成立しないもの。
  2. Important — アプリを特徴付ける機能。
  3. Nice to have — あれば便利な機能。

LINEアプリを例に考えると、Coreに当たるのはメッセージを送る機能や友達リスト、Importantはスタンプや通話機能、Nice to haveはタイムラインや暗号化機能などが当てはまる。

アプリが未成熟の段階では、このNice to haveは全て却下するべき。「あるとよい」は「なくてもよい」と同じだから。CoreとImportantだけでまずは作ってみて、本当に問題が解決出来ているかを確かめる。そこにNice to haveの機能があると、解決できているかどうかが分かりづらくなる。Markdownノートアプリはエディタが重要なのに、PDFが添付できます!とかどうでもいいのと同じ。

ここで一番悩むのが、ImportantかNice to haveかという判断。迷った時、そこには「機能は多いほうがよい」という思い込みがある。ユーザは神様だ、顧客の声を汲み取り、製品にどんどん反映すべきだという信条。じゃあその声を余すこと無く取り入れて機能を沢山つけるとどうなるか。

まず開発の観点から言うと、機能が増えれば増えるほどプログラムは複雑化する。複雑なプログラムはバグが生まれやすくメンテコストが高まる。そして変更が難しくなって、開発スピードがどんどん落ちる。

自分が使いもしない機能を付けると、バグがいっそう起きやすい。いつの間にか壊れていて、それに気づかず放置していたなんて事はよくある。そんな機能、付けても意味ない。

Adobe製品やMicrosoft Office製品を見て欲しい。とても参考書無しに使える代物ではない。機能が多すぎると、その分使いたい機能に気づかなかったり使い方が分からない事が増える。使い方を覚えるコストを払ってまで個人開発のアプリを使おうと思う人は少ないだろう。

経験的に言ってユーザの要望は99%、他のアプリでも出来るものを投げてくる。そういう声ばかり取り入れていると、特色は失われ、誰に向けたアプリなのか分からなくなる。だから自分が別に要らないと思ったら積極的にその意見を切り捨てて問題ない。

手を動かして実装してると、なんだか進んでいる気がして安心する。でも要らない機能を付けたところで何も状況は好転しない。Brewdog創設者のジェームズ・ワットは著書「ビジネス・フォー・パンクス」で以下のように述べている:

ブランド力は常に、守備範囲の広さに反比例する。つまり、カミソリのように薄く狭い領域に集中し、最高の商品を仕上げる必要があるということだ。 — ジェームズ・ワット

機能を絞り込んで、自分の限られたリソースをそれに集中させる。それでやっと最高のアプリが作れるんだと思う。参考になれば嬉しい。

Read more

信念を貫け!1年半の開発と3ヶ月の燃え尽きから学んだAIコーディングの教訓

信念を貫け!1年半の開発と3ヶ月の燃え尽きから学んだAIコーディングの教訓

お断り: 元の記事は英語で書き、壊れた文法はAIで直しました TL;DR * アプリの新バージョン開発に費やした1年半(3ヶ月の燃え尽き期間を含む)で学んだこと * AIは常に人生の二の次であるべき。過去には二度と戻れない * 5年後に振り返ったとき、Fableがどうだったとか完全にどうでもいい * シングルタスクをキープしろ。エージェントの数は関係ない * 頭の中のコンテキストスイッチが次のボトルネック * 理解があるからこそ、次のアイデアが生まれる * 自分を本当に幸せにするものを知れ – 僕は自分が欲しいものを作る * SaaSを10年以上運営するのは、同じ作品を何年も描き続ける漫画家のようだ * 自分の信念を築けるのは、自分だけ Inkdrop v6の開発に1年半費やした どうもTAKUYAです。英語圏でかれこれ10年個人開発をしています。先日投稿した通り、予てから作っていた新バージョンのMarkdownノートアプリをやっとリリースしました。繰り返しになるので、リンクだけ貼っておきます: Inkdrop is an AI-native Markd

By Takuya Matsuyama
Inkdrop v6リリースしました

Inkdrop v6リリースしました

どうもTAKUYAです。日本語でもお知らせします。 Inkdrop v6を正式リリースしました!1.5年がかりの大改修となり、大変お待たせしました。本バージョンでは、新しいMarkdownエディタや、最近のエージェント型コーディングワークフローに最適化された新しいAI連携機能など、根本から作り直した改善が盛りだくさんです。それでいて、気が散らないシンプルでクリーンなUXはそのまま維持しています。 まずはじめに、既存のユーザの皆様に大きな感謝を述べたいと思います。開発期間中に辛抱強く待って下さった事、そしてCanaryテストで多くのフィードバックをくれたことに心から感謝します。皆さんのサポートなしには実現できませんでした。 ウェブサイトもv6に合わせて完全に作り直しました。アプリのUIをそのまま使ってライブデモを構築したので、アプリをDLせずとも新しいエディタを試せるようにしました。ぜひ触ってみてください: Inkdrop is an AI-native Markdown note app for developers — smooth context flow between

By Takuya Matsuyama
個人開発と生活

個人開発と生活

朝、娘をバス停まで送り出す。前にちらっとみかけた田村淳の相槌術が面白そうだったので、ママ友との雑談で早速実践してみたら効果てきめんだった。その方法は単純に、職業病で癖になっている批判的思考を完全オフにし、相槌に全神経を注ぐ、というものだ。「へぇ」「うん」「うーん」「なるほど〜」と、相手の話にどんなバリエーションで返そうかという所に集中する。騙されたと思って試してみて欲しいんだが、このお陰で相手の話がよく理解できて、自然なフォローアップの質問やリアクションが浮かぶようになる。こちらから頑張って面白い話をひねり出す必要が無いので、気が楽になった。話の結論も何もいらなくて、「そうなんですね」「いいですね」「ほんじゃお疲れ様です〜」みたいな感じで締めくくる。反応に困ったらとりあえず「いいですね」まじで便利!男相手の会話でも有効。インタビューにも応用が利きそうだ。 天気が悪くてだるいので、やる気が出るまで部屋でレシートの撮影などの単純作業をして過ごした。レシートを撮ったら事務代行さんに投げる。そのうちAIに代替させたい。レシートは基本カフェばっかりである。 ユーザフォーラムをチェックしたら、

By Takuya Matsuyama
個人開発で日本から海外へ、10年間の歴史 — ひろしさんとの対談(前編)

個人開発で日本から海外へ、10年間の歴史 — ひろしさんとの対談(前編)

数週間前、ひろしさんのポッドキャストにゲストで出演しました。お互いの長い個人開発の経験について語り合いました。英語版を作成する過程で、日本語でも綺麗に整形した書き起こしが出来たので、こちらに掲載します。お楽しみください。 ※ギアアイコンをクリックして、音声と字幕を日本語に変更できます。 00:00 イントロ:TAKUYAさんようこそ 01:32 TAKUYAさんの自己紹介:WalknoteからInkdropまで 04:54 独立への踏み切り方:慎重派と勢い派 06:51 個人開発がフリーランス案件につながった 09:17 Inkdropで食えるようになるまで 12:15 なぜ最初から海外市場を狙ったのか 14:54 AI登場前、英語コピーに苦戦した話 16:18 AIバイブコーディング時代をどう見ているか 17:24 全てのコードを一行ずつレビューする使い方 21:06 AIは新幹線:速さの先にあるもの 25:53 AI時代に「感性」が大事になる 27:

By Takuya Matsuyama