🪞 過去の自分のために作ったアプリ

エッセイを書きます。 アプリをリリースした夜、Lilyは少し不思議な気持ちになっていました。達成感はたしかにあったのに、どこかに「もう遅いかもしれない」という感覚が混じっていたんです。 そのアプリが解決しようとしていた問題を、リリースした時点の自分はもう抱えていなかったからです。一年近くかけて作ったもので救おうとしていた「あの頃の自分」は、もうどこにもいませんでした。 それがすごく悲しいような、でも不思議と清々しいような気持ちで。この文章は、そのときのことを整理するために書いています。同じように「かつての自分のために作った」経験のある方と、そのしんどさと豊かさを、少しだけ共有できたらと思っています。

作るきっかけは、いつも「あのとき困っていた自分」

一年前の課題メモ

Lilyが最初にそのアプリのアイデアを思いついたのは、一年ほど前のことです。当時のLilyは、個人プロジェクトのタスク管理にひどく困っていました。毎朝「今日何から始めるか」で30分悩んで、気づいたら一番やりたいことを後回しにしている、という日が続いていました。

既存のツールをいくつか試してみましたが、どれもしっくりきませんでした。「だったら自分で作ってしまおう」と思ってメモ帳に書き留めたのが始まりです。そのメモは今でも残っていて、見ると少し胸が痛くなります。「毎朝5分以内に今日やることが決まる仕組みがほしい」と書いてありました。あのときのLilyは、それだけで満足できるはずだと信じていたんです。

作っている間に、問題は静かに消えていった

開発を始めてしばらくすると、不思議なことが起きました。作っているうちに、Lily自身の習慣が変わっていったんです。

アプリの設計を考えることで、「自分が何にぶつかっているのか」を言語化する機会が自然と増えました。UIを設計しながら「このボタンを押すときのユーザーはどんな状態か」を考えることが、そのままLilly自身の問題整理になっていました。気づいたら、あれほど悩んでいた朝のぐるぐるがずいぶん減っていたんです。

それ自体はいいことです。でも、リリースの日が近づくにつれて、なんとなくざわざわした感覚も湧いてきていました。

リリース当日の、ちょっと奇妙な感情

完成品を見て、Lilyが最初に感じたのは「これ、今の私には要らないかも」でした。

アプリは丁寧に作れていました。一年かけて少しずつ積み上げたものが、ちゃんと形になっていました。でも使い始めようとしたとき、自分がもうそのフローを必要としていないことに気づきました。問題が消えたのではなく、作っている間に別のやり方が自分の中に根付いていたからです。

「これって意味があったのかな」と、一瞬だけ思いました。正直に言うと、もう少し長く落ち込んでいたかもしれません。でも公開ボタンを押してから数時間後に届いた最初のフィードバックが、そのもやもやへの答えになりました。

「これ、まさに今の私の悩みです」という言葉

届いたメッセージ

最初のコメントはとても短いものでした。「これ、まさに今の私の悩みです。毎朝ずっとこれで困ってました」。

読んだ瞬間、なんとも言えない感覚がありました。Lilyが一年前に感じていた「あのざわざわ」を、今まさに誰かが感じている。自分が作ったのは「今の自分のためのツール」ではなかったけれど、「かつての自分と同じ状態の誰か」にとっては、まさに今必要なものだったんです。

タイムラグは欠点じゃなかった

そのメッセージをもらって、Lilyは少し見方が変わりました。

作っている間に自分の問題が解決されてしまうのは、決して無駄なことじゃない。むしろ、それだけ深くその問題に向き合い続けたということの証拠でもあります。一年間、その問題を「自分ごと」として考え続けたから、作れたものがある。もし最初から「ユーザーのために」と抽象的に考えていたら、あそこまで細部にこだわれなかったと思います。

「かつての自分を救うために作る」というのは、結果として「かつての自分と同じ状況にいる誰か」を救うことになる。そのタイムラグが、個人開発のひとつの静かな強みかもしれないと、はじめて感じた夜でした。

失敗したな、と思ったこと

解決済みの問題を、他人事として語ってしまった

ただ、正直に書くと、失敗もありました。

リリース後の紹介文を書くとき、Lilyはもうその問題から少し遠い場所にいました。だから文章がどこか他人事になってしまったんです。「こういう人に便利です」「こんな課題を解決します」という説明は書けても、「あのときの焦り」「朝起きて最初に感じる憂鬱」のような具体的な感情が抜けていました。

最初のフィードバックをもらってから、紹介文を書き直しました。「一年前の自分が感じていたこと」を素直に書いたら、その後の反応がずっと変わりました。小さな気づきでしたが、Lilyにとってはこれが一番大きな学びだったかもしれません。

「もう解決した」人が書く言葉の限界

もう一つ気づいたのは、問題を「卒業してしまった人」が書く言葉には、どこかに熱量の差があるということです。

困っているど真ん中で書く言葉には、必死さがにじみます。でもリリースのタイミングでは、Lilyはもうその必死さがなかった。それを補うために、開発中につけていたメモや、最初にアイデアを書いたときのメモを読み返して、「あのときの自分の声」を引っ張ってきました。過去の自分が最大の一次情報提供者でした。

あのメモを読み直したとき、一年前の自分が本当に困っていたことを思い出して、少し胸がつかえました。ちゃんと向き合っていたんだな、と思ったんです。

「誰かのために」より「かつての自分のために」

個人開発を始めたばかりの頃、Lilyは「ユーザーのことを考えて作れ」というアドバイスをよく目にしました。それは間違いではないと思います。でも、最初から架空のユーザー像を設定するのが苦手なLilyには、なかなかピンときませんでした。

「かつての自分」は、ユーザー像の中でいちばん具体的な一人です。困っていた状況も、感情も、どんな解決策を試して失敗したかも、全部知っています。インタビューしなくていい、アンケートをとらなくていい。ただ正直に「あのときの自分に何が必要だったか」を問えばいい。

それに気づいてから、Lilyは最初に「誰かのために」と考えることをやめました。代わりに「あのときのLilyが使いたかったものを作る」という問いから始めるようにしました。そのほうが、迷ったときに立ち返れる場所がある気がしています。

リリースした後に見えてくること

作っている間に、自分も変わっていく

長い開発期間を経てリリースするとき、必ずどこかにズレが生まれます。最初の設計と今の実装がずれていることもあれば、自分の課題認識が変わっていることもある。それを「失敗」と捉えてしまうと、リリースのたびに自己否定が積み重なっていきます。

でも別の見方をすると、開発期間の長さは「その問題と向き合っていた時間の長さ」でもあります。Lilyは一年間、タスク管理という問題をいろんな角度から考え続けました。その積み重ねが、完成品の解像度になっています。

リリース時に「もう自分には要らない」と感じるとしたら、それはその問題を十分に理解したということかもしれません。

「もう解決した」は「深く理解した」に読み替えられる

もちろん、すべてがそうとは言えません。でもLilyにとっては、この読み替えがずいぶん楽にしてくれました。

作りながら問題が解決するのは、作業の副産物としてよく起きることです。コードを書きながら設計を考え、設計を考えながら問題の構造を整理し、整理しているうちに解決の糸口が見える。個人開発は、ある意味で問題への「長期インタビュー」のようなものかもしれません。その結果として、アウトプット（アプリ）と自分の変化が同時に起きているだけで、どちらかが無駄というわけじゃない。そう思えるようになってから、作ることへの向き合い方がすこし軽くなりました。

過去の自分の先にいる誰かへ

Lilyがこの文章を書こうと思ったのは、「もう手遅れかも」と思いながら公開ボタンを押した夜のことを、正確に記録しておきたかったからです。

あのとき感じた「ちょっと変な達成感」は、今思うと大切なものでした。自分の問題意識が変化するほど長く、何かに向き合ったという証拠だったからです。そしてその記録が、今まさに同じ問題の中にいる誰かに届くことがある。個人開発のタイムラグは、失敗じゃなくて、そういう仕組みなのかもしれません。

もし今、「これって意味あったのかな」と思いながら公開ボタンの前に立っている方がいたら、押してみてください。かつての自分は、もうそこにいなくても、同じ場所で立ち止まっている誰かが、ちゃんと受け取ってくれることがあります。

過去の自分のために作ったものが、今の誰かのためになる。Lilyはそれが、個人開発のいちばん静かで確かな意味だと思っています。

Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています

• 制作物・記事は bokuwalily.com にまとめています🖥️

• OSS: github.com/bokuwalily 🐙

• 最新情報・お問い合わせは X @bokuwalily へ🌍