個人開発の「維持するための労働力」「インフラ費」をどう抑えるか　活動歴7年の開発者が語る、楽に長続きさせるための仕組み

ke-ta氏の自己紹介

ke-ta氏：では、発表を始めます。今回は「個人開発を『継続』する　小さくはじめて、長くつづける」というタイトルで発表します。よろしくお願いします。

まずは自己紹介です。名前はke-taと言います。2022年に大学を卒業して企業に就職していたのですが、個人開発の時間を作りたいという理由から、4月に退職して独立しています。

なので今は個人開発メインで活動しているのですが、空いた時間にほかの会社の開発を手伝うことも少しあるので、それ用にYmdkitという別の法人を設立しています。

ふだんはTwitter（現X）とかでよくつぶやいています。だいたい個人開発に関連するつぶやきをしているので、よかったらフォローしてもらえるとうれしいです。

テスト勉強用アプリ「暗記メーカー」

次にサービス紹介です。先ほどの名人さんとサービスの内容がすごく被っているのですが、テスト勉強用アプリ「暗記メーカー」というアプリを制作しています。

タイトルのとおりで、問題集の作成、解答、共有ができるようになっていて、テスト勉強中の学生や、資格習得を目的とした社会人を支援するアプリになっています。

（スライドを示して）現状の技術スタックはここに書いてあるとおりで、「Flutter」や「Next.js」や「Firebase」など、個人開発だとよくある構成なのかなと思っています。

今の累計ダウンロード数はだいたい90万ぐらいで、100万ダウンロードが見えてきたところもあり、それを目指して日々試行錯誤しています。

このアプリ自体は、もともと高校生の時に自分のテスト勉強用に作ったツールみたいな感じで、当時リリースはぜんぜん考えていなかったのですが、学生時代の趣味、仕事の傍らでやる副業、今は個人事業としての本業みたいな感じで、関わり方が変化しつつも7年が経過していて、すごく息の長いサービスになっているかなと思います。

今日話すのは「低コストで個人開発を続ける仕組み」

今回のLTでは、1つのサービスを長く開発してきた経験をもとに、低コストで個人開発を続ける仕組みについて話せればなと思います。

ここでいう「低コストで」というのは、維持するための労働力という手間や、インフラ費という費用をどれだけ抑えられるのかということを表しています。

自分自身、今でこそ本業で取り組んでいますが、かつては学業だったり仕事の傍ら、開発したい時だけ開発するスタイルだったので、義務感をどれだけなく開発できるのかが大事なのかなと思っています。

最初から本業としてリソースを割く場合はまた話が変わってくるのかもしれないのですが、今回のテーマはあくまで「小さくはじめて、長くつづける」なので、肩の力を抜いて聞いてもらえるとうれしいです。

（スライドを示して）目次はこんな感じですね。技術選定の部分から集客面まで、満遍なくTipsを話せたらいいなと思います。

個人開発ではメジャーな技術を採用する

まずは技術面の話です。これは、やって良かったというよりかは、もっと早くやっておけばよかったという自戒でもあります。

学生時代は「記事を見て気になった」とか「インターン先で使っていた」みたいな理由で、好奇心で技術選定をすることが多かった感じです。その時自体はすごく楽しいのですが、2、3年後にその機能をアプデしようとして戻ってくると、そのライブラリが更新停止していたり、メジャーバージョンが上がりまくっていて、そのまま使えないような感じになっていて、だいたい自分の首を絞めていました。

これが仕事、週5でおもりできるソフトウェアだったら別に問題ないと思うのですが、実際、個人開発はそうではないというのを強く感じましたね。

あと、サービス提供者の観点では、使っている技術の新しさや難しさは、ユーザーに与える価値とはイコールではないので、同じことを実現できるのであれば、もっとスタンダードな方法を使うべきなのかなと思うようになりました。

特に最近では「ChatGPT」だったり「GitHub Copilot」というツールもあって、こういうツールは、学習データの母数が多いほうが有利だということもあるので、そういった意味でも、メジャーな技術の採用は、良いことなのかなと思っています。

とはいえ、自分もエンジニアの端くれなので、新しい技術は触りたい思いもあるし、今は目新しい技術かもしれないけれど、それが今後スタンダードにもなるかもしれないので、あくまでそれは依存の少ない枝葉の機能とかで試すようにしています。

具体例を挙げると、最近はLLMが流行ってきていて、ちょっと取り入れてみたいかなという思いはありました。それを、例えば問題作成の補助ツールで、文章を入れたらいい感じにその問題と答えを抽出してくれるみたいなものを入れてみて。メインは手入力なので、最悪LLMがうまくいかなかったらその機能ごと消せばいいというところに、新しい技術を積極的に取り入れるようにしています。

“必要に応じて”クロスプラットフォームを採用する

もう1個、技術面で出すとすると、必要に応じたクロスプラットフォームの採用ですね。開発当初は、クロスプラットフォームで選択肢もあまり多くなくて、「Kotlin」と「Swift」はそれぞれ別で書いていました。しかし、やはり同じ機能を2回も実装するのはつらいのと、実務でたまたまFlutterを触る機会があったので、独立してからですが、半年前に2、3ヶ月かけてフルリプレイスを行いました。

移行自体につらい部分はあったものの、1回移行を終えてしまえば、その後の機能追加はコード量的にも、同じものを2回書かなくてもいいというモチベーション的にもだいぶ加速して、かつての2、3倍の速度でアプデを繰り返せるようになりました。なにか新しくモバイルアプリを作るんだったら、Flutterは、今は第1候補になるんじゃないかなと思います。

「WebのほうにもFlutter、いけるかな？」と思ってちょっと試してみたのですが、いろいろあって現状は採用を見送っています。自分が思ったのは、共通化できるメリットよりもいろいろとハマりどころが多かったり、既存のWeb資産を利用できないデメリットのほうが大きいと感じました。

先ほどもメジャーな技術という話をしたのですが、あくまでサービスを提供するという観点では「Flutterを使うこと」は目的ではないので、WebではNext.jsを使っています。

デザインはガイドラインに追従する

（スライドを示して）もう1つはデザインですね。「『こだわりのないデザイン』へのこだわり」と書いています本職がデザイナーだったらこだわれると思うのですが、エンジニアの人が、自分も含め、エンジニア上がりであまりデザインのことを知らない状態で作ると、余計に手を加えたがためにチープになってしまうことがありがちなので、我を出さずになにかしらのガイドラインに追従するのがいいのかなと思います。

もう1つの理由としてあるのは、パラメーターにない凝ったカスタマイズをすると、OSやフレームワークの更新でよく壊れます。これは特にiOSに多かったかなと思います。これを経験してきて思ったことは、「まず、用意されているものを組み合わせて、モノを作れないか？」ということですね。

いろいろガイドラインはあると思いますが、最近だと、デジタル庁のデザインシステムがおすすめかなと思います。入力フォーム周りについてのデザインが一通りまとまっていて、シンプルでわかりやすくて、自分としてはすごくありがたかったです。

日々のルーティンワークを楽にするために情報を一元化する

次は情報の一元化です。これは、日々のルーティンワークをいかに楽にしておくかという話です。例えば「Googleアナリティクス」のような分析ツールだったり、なにかしらのSaaSのセットアップをして、しばらくは数字を見るのが楽しいからアクセスしているけれど、だんだん見にいくのが億劫になってくるということはないでしょうか？　少なくとも自分はめちゃくちゃありました。

なので、これを解決するために取った方法としては、自分用の「Slack」のワークスペースを作って情報を集約するという感じですね。

SlackはWebhook経由で気軽に情報をポストできるので、ユーザーからの問い合わせやアナリティクスの日次レポートをとりあえずSlackに流し込んで、自動的に情報を見られるようにしておきました。最初に設定しておけば勝手に情報が集まってくるので、情報を見る癖はすごくついたのかなと思います。

ランニングコストを増やすことなく70以上の言語へローカライズ

次はローカライズですね。流入を増やすという意味では、ローカライズはするに越したことはないとは思っています。しかし、機能追加のたびに機能にある文言を全部ローカライズするのは面倒くさくて、もともとは、だいたい2、3言語ほどしかローカライズできていなかったです。

しかし、最近はChatGPTなどの便利なツールの登場によって、少ないコストでも多言語対応は可能になったのかなと思っています。

具体的な手順としては、アプリ内の文言やストアの文言をまずファイルで管理して、その後にChatGPTに指示して、全部ローカライズしてもらいます。

加えて、これを差分実行します。差分実行なので、例えば途中の行からの実行も可能にした上でコマンドを1つ叩けば、新しく作った機能の文言だけを全部ローカライズすることが可能になります。

このおかげで、70以上の言語へのローカライズをランニングコストを増やすことなく実現できました。実際のところ、ダウンロード数の4割が今は海外からなので、これはだいぶコスパのいい改善だったのかなと思います。

ローカライズ自体にOpenAIの料金はかかりますが、海外のユーザーが例えば1人サブスク契約してくれれば元が取れるので、やるに越したことはないんじゃないかなという感じですね。

インフラ費については無料枠から使用する

もう1個はランニングコストで、インフラ費の話ですね。長く続けるためにもここはすごく重要なところなのかなと思います。実際、赤字を発生させながらサービス開発を続けることはなかなかしんどいです。

それを実現させるために必要なこととして、まず前提としてFirebaseの無料枠を使うことで、もう1つ、自分が大事だと思っていることは、ユーザーにとって便利である機能と、それがサービスとして持続できるかどうかをセットで考えることなのかなと思っています。

せっかくサービスがバズっても、APIの利用料金やサーバー代でサービスが終了するのはすごく寂しいので、そこは意識したいなと思います。

自分がやっている具体例でわかりやすいところでいうと、ドキュメント数の制限ですね。例えば、「何件以上問題を登録したい場合は有料プランに登録してください」としたり、最近だと生成AIの機能で問題生成をやっていて、それは便利なのですが、使われすぎるとインフラで破産するので、待ち時間にリワード広告のような長い動画広告を流して、生成料金と広告の収益で広告収入がプラスになるようにしています。

もう1個は、オフラインモードを有料で提供することです。通勤・通学中に勉強する上でオフラインモードは便利だと思いつつも、これを全ユーザーに開放すると、機内モードとのコンボで広告収益がゼロになる可能性が考えられたので、こういった機能は便利とは思うのですが、有料で提供しています。

認知向上のための「アプリ名」と「宣伝に使える材料を増やす」工夫

ここからは集客ですね。自分がやっているのがツール系なので、新しい価値を提供するというよりは、勉強したい人がいる上で、その人にどうやって認知してもらうかという話ですね。

1つ目にやっていることとしてはアプリ名ですね。サービス名の紹介でも出てきたのですが、サービス名が「暗記メーカー」というそのままの名前なので、「暗記」や「テスト勉強」で検索すると、とりあえず検索上位に出てくる状態になっています。

作る時にかっこいいカタカナの名前や英語の名前も考えたんですが、使えるものは全部使おうという精神で、アプリ名はわかりやすいものにしています。

もう1個意識しているのは、「『スペック』ではなく『シナリオ』を」ということです。先ほどの施策で検索結果には出てくるのですが、そこからインストールをしてもらえるかはわからないので、どういった機能があるかを羅列するだけではなく、それによって何が実現できるか。例えば通勤・通学中に勉強しようと思っている人だったら、そういうシナリオベースで文言を書くことによって、インストール率を上げるようにしています。

実際、自分自身はアプリを知り尽くしているのでその想像力は働くのですが、アプリを初見で見るユーザーは、たぶんそうじゃないだろうなということで、ChatGPTと壁打ちしながらいろいろキャッチコピーを試しました。

もう1個はコンテンツによるユーザー流入です。アプリのメインの機能として問題集というものがあって、問題集そのものに価値があるものなので、友人間や先生と生徒の間で共有できる機能をちゃんと作ることで、口コミじゃないですが、「問題集を作ったからこのアプリを入れて一緒に勉強しようよ」みたいな感じでユーザーが広がるようにしています。実際、今の新規の流入のうちだいたい10パーセントがここから集まっています。

ここを強化するいいところとしては、運営側のランニングコストが不要だというところです。こちら側でコンテンツを入稿したりしなくていいので、ほったらかせば勝手にコンテンツというか、宣伝に使える材料が増えていくことです。

こういうのは長く運営すればするほど効果が出ます。ちょうど最近、大学生で自分のアプリを使ったことがある方にお会いしたのですが、その時に聞いたのは、たまたまアプリを入れて、自分の大学の講義の名前で検索したら、1、2年前にその講義を勉強した人の過去問が出てきたから助かったみたいな話で、これは長く運営すればするほどサービスの価値が上がる最たる例だなと思いました。

長続きさせる上では「いかに楽に続けるか」を考えるのが大切

という感じでいろいろ話しましたが、まとめとしては、アプリのリリースも1つのマイルストーンではありますが、そこからサービスを改善していくという意味では、スタートラインなのかなと思っています。

とはいえ、ランニングコストが大きいと続けることも億劫になってしまうので、いかに楽に続けるかを考えるのが、長続きする上では大切なのかなと思います。

7年続けてきたといっても、たかだか7年とも言えるので、10年、20年続くようなサービスを目指して、今後も開発を続けていきます。