目次
はじめに
俺得記事(就活の自己分析によって生まれた副産物記事)です。
この2年半の間に私が個人開発で作ろうとし、頓挫したものの一部を紹介します。
そしてなぜ完成できなかったのかについても触れていき、これからの個人開発完成率の高さを目指していきます！
アイデアは無限に出てくるし、実装しよう！ってところまでもある程度は残ります。
でも実際に完成して継続して動いているものは片手で数えられるほどしかありません……
完成までいかなかったもの
こもよみ
サービス概要：名言を管理するサービス 失敗理由：Notionで完全に需要を満たしていた & 本質以外に時間を掛けすぎた 教訓：計画時に同様のサービスがないかを調べるだけでなく別種のサービスで代替できないかを調べる、MVP(Minimum Viable Product)からやっていく
「こもよみ」は名言管理サービスといいつつ、素敵なキャッチフレーズや広告コピーなども含めた「心が動いたワンフレーズ」を保存しておけるサービスを目指していました。
でもこれ、完全にNotionでカバーできるんですよ。
汎用性や将来性という側面でも勝てずに断念しました。
デザインとプロダクト名にこだわりすぎたことも敗因です。
最初の熱をそこで完全に使い果たしました……
ロゴにはヒエログリフを使ったり、「こもよみ」というプロダクト名は万葉集から来ていたりします。でもそういうこだわりって本質じゃないんですよ……付加価値なんですよ……
そしてデザイン楽しくなっちゃって止まらなくなります。
既存サービスの有無はもちろん事前調査しています。
ただ名言管理という点ではたしかに既存サービスが無くても、CRUDに毛が生えたようなサービスではNotionのような汎用サービスで代替できてしまいうる点を見逃していました。
なによりデザイン楽しいーーーーのフェーズに行くとそんなこと考えもしなくなり、デザインを考える手が止まらなくなってしまいます。
なので教訓としては同様のサービスだけでなくより広い視野で代替できるサービスがないかを調べた上で、最初はMVP(Minimum Viable Product)の実現を意識することです。
よく言われることですが、最初はそのサービスを満たす最低限の動くものを作ることが大事だと痛感させられます。知ってることとできることはイコールじゃないですね……
furosiki
サービス概要：データを梱包して送れるサービス 失敗理由：スタートのモチベが微妙であり、社会的な意義も見いだせず終わった 教訓：誰に何を提供するものなのかを最初に具体的にしっかり記録する
ギガファイル便などを始め、データを送れるサービスはありますが、現実で贈り物をするようにデータを包装して送れると素敵だなとか思っていました。
そこで出てきたのが「furosiki」。風呂敷のように汎用的なもの(データ)を包装して送れることを目指しました。
ただこれ……気づいたら熱が冷めてて放置されてたんですよね……
ちゃんと考えれていない部分もあって、特定の誰かに送るデータを包装したいのか、それともソフトウェア配布みたいな多数の人に向けて配布するデータのダウンロードページを素敵にしたいのか……どっちなんだいってところとか。
結局これもペルソナが明確じゃなく、なんとなくあったらいいなを実現しようとしてしまった側面があります。
正直アイデアは素晴らしいものだと自負しているので、欠けていたのはきちんと誰に何を提供するものなのかを具体的に考えれていなかったことです。
kotohazi.me
サービス概要：シンプルさと効率を重視したアンケートフォーム
失敗理由：別件で開発を中断した結果、その後再開しなくなった
教訓：最低限できてから中断する("作りかけのものを作るモチベ" > "新規で別のものをつくるモチベ" となるところまで作っておく)
勉強会のアンケートなどは5段階評価とひとことあるだけで十分だと思っていました。こういったものをGoogleFormで毎回作るのめんどう！数クリックで作れる簡単フォームサービスを作って解決しようと思って作りかけたサービスです。
とにかくシンプルなアンケートフォームが作れるサービスを目指していました。
ドメインまで取りページの公開までしていますが、未完成のままです。
ちょうど夏インターン争奪戦などなどの就活戦争で一度開発中断する必要が出てきました。
で、走り出したら止まらないけど、止まりだしたら走らないんですね。
既にMVPでも完成していたら再開のハードルは低いのですが、ほとんどまだこれからの段階で止まったものを再開することは難しいのです。
微妙に作りかけの昔考えたサービスより、最近思いついた新しい別のサービスをやりたいって心は動きます。
名刺の裏にもリンクのQRコードがあったり、ドメインを取ったりと、そこまで逃げれない状態を作ってもだめだったわけですね……笑
かどで日記1,2
サービス概要：日記管理サービス 失敗理由：実装ができず挫折した 教訓：新サービスの開発で技術的な挑戦をしすぎない、自身が毎日不満に感じる課題を解決するサービスを作る
今公開・運用しているかどで日記は「かどで日記3 ver3系」ですが、かどで日記も1,2では完成せず終わっている3度目の正直サービスです。
かどで日記は日記の管理サービスで、私が欲しくてたまらなかったものを詰め込んだ日記サービスです。
結果として1,2と頓挫した上で「かどで日記3」ではうまくいったのは2つ理由があります。
自身が毎日不満を感じる課題の解決という不動のモチベーションと技術スタックをすでに自分が経験あるものに変更したことです。
まず自身の課題解決という点です。
日記アプリ使ってるけど、PCでも日記書きたい。でもいい感じに自分の需要を満たすサービスが存在しない！というのが開発の動機としてありました。
これがかなり深刻で毎日日記を書くときに不満に感じていました。
毎日不満を感じるということは、たとえ開発のやる気が下がっても毎日上がる機会があったんです。
何度か挫折をしても復活できたのは、毎日自分が不満に感じている部分を解決するサービスだったという点が大きいです。
逆にかどで日記1,2と失敗したのは技術スタックを挑戦しすぎたことが原因です。
かどで日記1では素のReactを使ったろ！ってして挫折し、かどで日記2ではNext.jsとFirebaseで作ったろ！って感じで挫折しました。
新しい技術を使う時って認証周りどうするんだっけとか、本質じゃないところで詰まりがちです。
一方で新しいサービスに際して、新しい技術を使うのはとても良いことだと考えており、よくやります。
でも完成しなかったら共倒れで、二兎を追う者は一兎をも得ずといった状態です。
サービスも完成しないし、技術の習得もできない。
残されたのは自己嫌悪ですね。
結果としてかどで日記3ではLaravel+Bladeという、個人開発ですでに採用事例が豊富な技術スタックにしました。
現在この技術選定によるリファクタリングに追われている訳ですが……逆に言えば後でリファクタリングできるので、最初は作り切ることが大事という方針もすごく納得が行くようになりました。
ポートフォリオに載っけてるけど本来の機能を有していないもの
musubineru
サービス概要：プロダクト名の作成を補助するサービス 失敗理由：気づいたら今になっていた 教訓：最初にこだわりすぎない、初めて触る技術はフロントかバックのどちらかのみにする
個人開発などでプロダクト名を考える時、どういう名前にするかめちゃくちゃ悩みます。
普段私は和歌を引っ張ってきたり、関連する単語の別言語での読みを探したりしてサービス名を生み出すのですが、この過程をサービスにしちゃえば社会も自分も役に立つんじゃないかと考えたのが原点です。
そしてこれは正直まだ諦めてないです……！
ハッカソンで短期間で作ろうとしたものですが、技術的な挑戦をたくさんしていました。
初めて本格的にDenoとGoを使うというバックエンドもフロントエンドも自身初となる技術を使っていました。
で、同じパターンなのですが、見た目は整えて完成はしていないんですよね……
しかも一番肝心のデータベースから適切な単語を引っ張り出すしくみが未実装なんです。
この反省を踏まえて、これ以降は技術的な挑戦はフロントとバックのどちらかだけ！っていうのを鋼の意思としています。
最近作ったRAWPもフロントエンドは馴染み深いNext.jsを用いている一方で、初挑戦としてRustとWASMにしたって形です。
またこれも過去の事例と同じですが、デザインが楽しくて止まらなくなっちゃったパターンですね。人間は失敗を繰り返す……
しののめ
サービス概要：朝に特化した朝専用SNS 失敗理由：利用者を獲得してから色々考えようと思ったが、そもそもそこまでいかず挫折 教訓：自身の立場や影響力をわきまえる
大学1年の夏休みに作った朝専用のSNSです。
有史以来課題となる朝起きれない問題って、夜でもいつでもしちゃうSNSによって解決できるのでは！？っと思ったことが開発動機です。
ユーザーを獲得してから朝のみに時間制限をしようと考えていましたが、そもそもユーザーが集まらないんですよね……
SNSなんて星の数ほど競合がある中で朝しか使えないという一点の付加価値どころか、どこの馬の骨かもしらない個人開発サービスを使おうとはならないんです。当たり前なんですけど、当事者は忘れちゃいがちです。
一方でフルスタックフレームワークのおかげもありMVP自体は完成できていて、ソーシャル認証や投稿といいねのDB構成など、そういった仕組みを学習できたのは良い経験だと思っています……！
言の葉HTML
サービス概要：文字をインターネットで手紙のように送るサービス 失敗理由：技術不足 教訓：ロードマップを作る
業務連絡も大切な言葉も同じツールで送るのって味気なくない？って思ったのが動機です。
文香や添え花を選ぶことができ、ゆくゆくはそれに合わせた立地なアニメーションも作りたいと思っていました。
そしてこれは私が初めて作ったWebサービスです。大学1年夏の教習所合宿中にリリースしました。
MVPとしては十分な機能がありつつ、付加価値の部分が全く実装できずに時が過ぎてしまいました……
当時は「JS is 何」「CSS is 何」状態でリッチなアニメーションをする技術力がなかったことが根本的な敗因ですが、技術力不足を見越した実装の算段が取られていないことも原因です。
適切なロードマップを作って、うまく自身の学習ペースと組み合わせられると希望がありました……
U-laniwa
概要：サークル向け内部システム 失敗理由：部員が本当に必要だったものではなかった、縦割り組織で開発してしまった 教訓：ペルソナを考えた上で機能検討をする、チームでフルサイクル開発をする
サークル内で共同開発して作ったサービスで、サークル向け内部システムと題し、サークルメンバーの情報はもちろん、イベント時のQRコード発行による認証やプロジェクトの参加有無、サークル入退部の事務処理等を実現するサービスを目指していました。
リーダーの私の責任なのですが、そもそもMVPで完成したものが顧客が本当に必要だったものでなかったことが原因です。
最初のユーザー登録時は部員の多くが登録してくれましたが、アクティブユーザーは残りませんでした。
ユーザーが使ってくれないのにサービスを充実させていこうとするのは気持ち的に大変難しいものがあります。必要とされていないならなおさらです……
そして何よりメンバーごとに役割を縦割りしてしまったことも新規機能開発の障壁となってしまいました……
チームメンバーをフルサイクル開発でなくバックエンド、フロントエンド、デザイン……のように明確に区切りをつけました。当時は縦割りによって個々の役割が明確になり、将来何かを作るときの自信やガクチカになると思って、明確に意味を持って縦割りにしていました。
ですが機能をちょっと追加するだけでも全員の稼働や承諾を取る必要が出てきます。
フルサイクル開発を導入すべきだったと反省しています。
さらに完成間際で焦り、PHPDocの定義が雑になっている箇所や一瞬だけjQueryを使っている箇所など、技術的にあまりよろしくないものが残っていることも開発意欲を下げる原因となってしまっています……
まとめ
失敗していく原因
モチベーションの低下
- ふわふわした状態で始め、動機を見失う
- 本質以外の部分にこだわり、本質に辿り着く前に力尽きる
事前準備の甘さ
- ペルソナが定まっていなかったり具体的でなかったりする
- 技術的な挑戦のバランスが取れていない
開発
- 本質以外の部分でこだわりはじめ、MVPを忘れる
- チーム開発で縦割りしてしまう
どうすれば続けられるのか
ペルソナとロードマップを適切に最初に作り、MVPから作っていくことかと思われます。
よく言われている、なんら新規性のない結論ですがね……
あとは最初の熱はあえて冷ますことも最近は心がけています。
アイデアを思いついた時一度アイデア帳にスタックをします。
それによって後で冷静に見返すことができます。
そしてしばらく練ってもモチベーションが維持されていたら実装に進めるみたいな形です。
思い立ったらすぐ実行するのも大事ですが、息の長いサービスにおいては必ずしもそうとも言えない気がします。
また全てのサービスに言えないことになりますが、なにか個人開発をする時、毎日不満に感じている部分を解決するサービスだと一時的にモチベーションが下がっても続きやすいというのもありますね。
根底
色々それっぽい理由を述べてますが、根源は私の飽きっぽさだと思います。
そして本質以外にこだわり、問題の本質に時間を割けていないことが原因な気がします。
逆にずっと続いている「かどで日記」は一番のヘビーユーザーが私であることが要因として大きく、そういった意味では自然に本質を突けていたのかなと思いました。
自分が熱心なユーザーになることはきっと解のひとつですね。
有象無象の失敗から得られたこと
ソフトスキル面で得たものはほとんど無い気がします。
失敗はすごく大事ですが、上で挙げた失敗はどれも似通ったようなものなので、良い失敗とはいえません。
改善するか完成するか良質な失敗でないと得られるものがあまりない気がします……
ハードスキル面としては環境構築の速度向上は得られました。
デプロイ環境までを整えるのが爆速です。といっても技術スタック的にLAMP系ばかりなので、素のUbuntuからインターネットに公開できるところまで持っていくのが早いくらいで、現代主流のクラウド社会ではあまり通用していません……し、そもそもIaCすべきですね。
最後に
ここで挙げたのは、たかだがWebプログラミングに出会ってから2年半の人間の話に過ぎないので、再現性があるかも微妙で、そもそも万人に役に立つレベルまで抽象化ができているとも言えませんので、ご了承ください。
この振り返りをして、実は自分がしたいのは開発というより仮説を実現することなのかなって思ったりしています。