この記事が良かったら
Lily さんへの応援になります
シェア
🧱 制約が、アプリをよくした
去年の夏、わたしはあるアプリのリリース日を3回延期しました。理由は毎回同じで、「もう少し機能を足したい」でした。その「もう少し」が積み重なって、気づけば半年が過ぎていました。 そのとき心の奥で思っていたのは、「制約のせいでアプリが中途半端になっている」ということでした。時間が足り…
約10分で読めます0
去年の夏、わたしはあるアプリのリリース日を3回延期しました。理由は毎回同じで、「もう少し機能を足したい」でした。その「もう少し」が積み重なって、気づけば半年が過ぎていました。 そのとき心の奥で思っていたのは、「制約のせいでアプリが中途半端になっている」ということでした。時間が足り…
この記事が良かったら
Lily さんへの応援になります
去年の夏、わたしはあるアプリのリリース日を3回延期しました。理由は毎回同じで、「もう少し機能を足したい」でした。その「もう少し」が積み重なって、気づけば半年が過ぎていました。 そのとき心の奥で思っていたのは、「制約のせいでアプリが中途半端になっている」ということでした。時間が足りない。お金が足りない。技術が足りない。全部のせいにしながら、でも全部を克服しようとして、結果としてどれも中途半端なまま立ち止まっていました。 いまは少し違う考え方をしています。制約は、わたしのアプリの敵じゃなかった。むしろ、それがなかったら今の形には辿り着けなかった、とすら思っています。今回は、その話を書かせてください。
個人開発を始めたころ、わたしには一種の万能感がありました。自分一人で全部決められる。デザインも、機能も、リリースのタイミングも。チームの合意なんて必要ない。最高じゃないか、と思っていました。
でも実際に手を動かしてみると、その「全部」が重くなっていきました。画面のデザインを決めかけたら、機能の設計が気になる。機能の設計をしていたら、そもそものコンセプトが揺らいでくる。決める人間が一人しかいないということは、迷う人間も一人しかいないということでした。
最初のアプリを作ったとき、わたしがリストアップした「やりたいこと」は38項目ありました。ユーザー管理、通知機能、ソーシャルログイン、ダークモード、多言語対応……。全部、いつか使う人のためだと信じていました。でも実際にリリースできたのは、その半分以下でした。
時間とお金と技術の話をするとき、わたしは長い間それを「足りないもの」として見ていました。もし副業でなくフルタイムで開発できたら。もし外注できるだけの予算があったら。もし使いこなせていない技術を習得できていたら。
でも「もし」は続きません。わたしには本業があり、睡眠もいります。お金は限られています。知らない技術を習得する時間も、リリースまでに間に合わせるには足りない。それが現実でした。
あるとき、深夜1時すぎに作業していて、突然やる気が切れました。作りかけの画面を見ながら、「これ、本当に全部いるんだろうか」と思ったのです。
翌朝、冷静になってリストを見直しました。38項目のうち、「これ、自分が一番最初に使いたいか？」という軸で絞ると、残るのは7つでした。ほかは「あったら便利かもしれない」「使う人がいるかもしれない」という想像上のニーズでした。
削るのは怖かったです。「これを外したら、使ってもらえないかもしれない」という不安がありました。でも、わたしには時間がなかった。技術的にも難しかった。だから削るしかなかった。
その「しかなかった」が、転機でした。
7つに絞ったとき、アプリの輪郭が急に鮮明になりました。「このアプリは、何をするためのものか」が、自分の中でようやく言語化できたのです。
それまではぼんやりしていたキャッチコピーも、この段階で初めて一行で書けました。機能のリストを削ることで、コンセプトが残ったのです。
わたしが作ったアプリのひとつに、リアルタイム通知を入れようとしたものがあります。でも当時のわたしには、その実装が難しすぎました。調べれば調べるほど深みにはまる。時間も限られている。結果として、「通知は非リアルタイムでいい」という決断をしました。
ところが後から、ユーザーからこんな声をもらいました。「通知が来すぎないのがいい。見たいときに見に行ける感じが好き」と。
わたしが技術的にできなかったことが、結果として「静かなアプリ」というキャラクターを生んでいました。意図せずして、差別化になっていたのです。
デザインにお金をかけられないとき、わたしが頼ったのは「シンプルにする」という方法でした。装飾を減らすと、実装のコストも下がる。操作の手順が減ると、説明しなくてもわかる画面になる。
「お金がないからシンプルにした」と言うと、妥協のように聞こえるかもしれません。でも、後から見返すと、そのシンプルさがアプリの長所になっていました。追加したかった装飾より、削られた余白のほうが、ずっと正直な表現になっていました。
制約を受け入れることは、諦めとは違います。でも、わたしはしばらくそれを区別できていませんでした。
「できない」と言うのが怖かったのです。個人開発をしていると、周りのすごいものを見てしまいます。短期間でリリースして、きれいな画面で、機能も豊富で。「自分も同じくらいにならないといけない」という感覚が、じわじわとプレッシャーになっていました。
でもあるとき気がつきました。わたしが羨ましいと思っていた作品の多くは、見た目はすごくても、使ってみると自分が作りたいものとは違う。そして、わたしが作りたいものは、わたしの制約の中でしか生まれない、とも。
制約を「受け入れる」というのは、「その範囲で最善を尽くす」ということでした。降参とは全然違います。むしろ、戦う場所を正しく決めることでした。
今は、新しいアプリを作り始めるとき、最初に「やらないことリスト」を作るようにしています。やりたいことを書き出す前に、「今回の範囲では絶対にやらないこと」を決めます。
これが思いのほか効きます。「やらないことが決まっている」と、迷いが減ります。機能を追加したくなったとき、「これはリストに入っていないから次の機会に」と判断できる。意思決定のコストが下がるのです。
お気に入りの考え方があります。制約を「足りないもの」ではなく「このゲームのルール」として見る、というものです。
制限時間があるゲームのほうが、燃えることがあります。使えるパーツが少ないほど、工夫が生まれることがあります。それと同じで、「○○は今回できない」というルールは、「じゃあどうする？」という思考を生みます。その「どうする？」の積み重ねが、個人開発の面白さのひとつだと、今は思っています。
このエッセイを書きながら、わたしは当時のことを振り返っていました。深夜1時のあの瞬間、リストを削った翌朝、「通知が来すぎないのがいい」というメッセージを読んだとき。
どれも、当時は苦しかったり、不安だったり、ちょっとだけ悔しかったりしました。でも今は、そのどれもが「あってよかった」と思えます。
制約は、作るものを縛るだけじゃなかった。作る理由を、もっとクリアにしてくれていました。
個人開発を続けていると、「なんでこんなことしてるんだろう」と思う夜があります。わたしはあります。そういうとき、「できないことを受け入れたら、逆によくなった」という経験が、小さい燃料になっています。
完璧じゃなくていい。全部できなくていい。今のわたしにできる範囲で、ちゃんと作る。それが、長く作り続けるためのやり方なのかもしれません。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
🎁 最後まで読んでくれたあなたへ、無料の特典があります
LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― マーケ組織50名規模を統括するCMOを経て、いまは個人でiOSアプリやWebサービスを作っています。集客・導線設計と、AI導入・業務自動化の相談を受けています
🖥️ 制作物・記事 → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 最新情報・お問い合わせ → X @bokuwalily
