初めての個人開発で得た学び

2025/10/21 チャリチャリLT会 #6 登壇資料

Transcript

1. 初めての 個人開発で 得た学び チャリチャリLT会 #6
2. 初の個人開発をやった中で得た学びについて、 技術的な部分以外を主にお話します
3. 開発したもの Webブラウザ向けオンライン対戦ゲームで、 ゲーム性としてはポケモンによく似たものになってます。 最大の特徴としてはキャラクターの名前によって 全てのステータスが一意に決まるところです。 よかったらぜひ右下のQRコードから遊んでみてください （ベータ版ですのでご了承ください） Magic Battle Ω
4. 周囲に公言することの 怖さ・大切さ
5. 周囲に公言することの怖さ・大切さ モチベーション維持のため、FBを得るため、 単純に使ってもらうためなどの目的で、 開発前後問わず「こういうものを作ろうと思ってる」or 「作ったよ！」と公言・発信することは非常に重要です。
6. 周囲に公言することの怖さ・大切さ しかし「それ何が面白いの？」 「しょうもないもん作ってるなー」 など、たとえ口にはしなかったとしても 内心ではそう思われるんじゃないかという不安から プロダクトを他人に勧めることのハードルの高さを感じました。 （もちろん自分ではいいものだと思ってます）
7. 周囲に公言することの怖さ・大切さ 実際に周囲の人に紹介して、 「面白い」 「すごい」といった言葉をもらうことは 想像していた以上に励みになりましたし、 良いFBも得られてそれを取り入れることにも繋がりました。 宣言することで、やらなければという気持ちにもなり、 公言した方がいいことを改めて実感しました。
8. 周囲に公言することの怖さ・大切さ 人の作ったものは積極的に褒めましょう（自戒も込めて） 。 好きでやっているとは言え、その裏には多大な労力があります。 そもそも個人開発とかやってるだけでえらい！
9. 機能面以外で 良くすることもできる
10. 機能面以外で良くすることもできる Magic Battleを友人と遊ぶ際に、独自ルールを提案してみました。 具体的には、山手線ゲームのような感じで お題と制限時間を決め、時間内にお題に沿った名前で キャラクターを探して戦うというものでした。 結果的にはこれが非常に好評でした。
11. 機能面以外で良くすることもできる 実装にはコストがかかります。 機能は変えずにまずはアイデアで価値を測ったり 試したりすることができれば、その効果を素早く検証できます。 この例では実際にその威力を実感しました。
12. ミニマムで作ることの 難しさ
13. ミニマムで作ることの難しさ スクラムにはMVPという言葉があります。 日々の業務における開発では、エンジニアとして常々 最小単位での機能リリースで素早く検証することを目指し、 PdMに口酸っぱく「あったらいいなは削りましょう」 「この機能なくても使えますよね」 「まずは価値検証だ」 などと偉そうなことを言っています。
14. ミニマムで作ることの難しさ しかし、いざ個人開発となると 「やりたいこと無限にあるわ」 「これあった方が面白いっしょ」 「ここでリリースしても面白いと思ってもらえないよなー」 といった感じで、見事に欲の塊と化していました。
15. ミニマムで作ることの難しさ 時間もモチベーションも有限のものです。 リリースされなければ、世間的にはそのプロダクトは 作ってないのと変わりません。 好きなように作れるのは個人開発の良いところですが、 リリースしたいという強い意志があるのであれば 簡単でいいのでロードマップを引きましょう（次はやります） 。
16. ミニマムで作ることの難しさ そもそもリリースしてからが勝負だからな！
17. 技術負債を無視し続ける ことによるコスト
18. 技術負債を無視し続けることによるコスト 技術負債はどうしても生まれますし、それ自体は悪いことではありません。 計画的に返済していくことが大事です。 放置した負債は雪だるま式に膨れ上がり、 やがて開発が立ち行かなくなっていきます。 よく聞く話で、実際そうだと思って業務では気を付けているつもりです。
19. 技術負債を無視し続けることによるコスト Magic Battleでも開発初期から放置し続けてきた技術負債があります。 ある時、コードが読み辛く実装にめっちゃ時間かかるなと 感じることがありました。 あ、これは後でやろうで放置し続けてきた負債のせいだなと。 しかも、コード量が増えるに従って修正のコストは高まり、 億劫になります。こういうことかと痛感しました。
20. 技術負債を無視し続けることによるコスト 個人開発では、他人がコードを読むわけではないので まあいっかとなってしまいがちです。 しかし、自分が書いたコードでも1ヶ月経ったら それは他人が書いたコードと同じです。 全てを自由にやれるからこそ、その結果の責任は全て自分に返ってきます。
21. プロダクト開発の 大変さ
22. プロダクト開発の大変さ 現職では、フルサイクルエンジニアという職種として、 開発だけではなく、企画から運用まで プロダクト成長のライフサイクル全てに責任を持つという 立場で業務を行っています。 そのため、プロダクト全体について考え、意見することは 常に念頭に置いています。
23. プロダクト開発の大変さ しかし、最終的にプロダクトの方針を決めるのはPdM、 プロダクトとエンドユーザーとの接点をデザインするのはデザイナー、 エンドユーザーとの直接的なコミュニケーションを行うのはCS といったように、職種による役割の違いは当然存在します。
24. プロダクト開発の大変さ 全てを1人で担うことで、あくまでほんの一部ではありますが 他業種の方々の苦労を少しでも知ることができたのは 良いことだったと思います。
25. プロダクト開発の大変さ また、Magic Battleについては収益化は目的としていませんが、 世の個人開発のプロダクトについて、ランニングコストをペイするだけでも かなり難しいことなんだなということを実感しました。 コーヒー買ってくれ！（飲めない）
26. 今回お話したことは全て、 「こうするべき」ということや 「こういう話がある」ということ自体は もともと知っていたことでした。
27. しかし、 「知っている」のと「経験したことがある」のでは 大きく違うなと改めて実感するとともに 視野が広がったと感じます。
28. 個人開発はいいぞ
29. ご清聴ありがとうございました！ やってます