大学生が個人開発をするうえで実感したドメイン理解の重要性

個人開発を始めた経緯

大学に入ってからプログラミングの勉強を始め、最初に個人開発として自分の趣味であるポケモンのランクマッチと関係のある題材としてポケモンのダメージ計算Webアプリを作ろうと考えました。

当時は

• Next.jsのレンダリング手法の違いが分からない
• Reactのpropsやstate, componentの切り方もよく分からない
• DBを使うべきかどうかも分からない

という状態でしたが、一旦手だけは動かしていました。 最初は自分が遊んでいた当時の最新作であるスカーレット・バイオレット向けに作り始めました。一番人が多いプラットフォームであれば、アクセスを稼ぎやすいと思ったからです。

技術的には完成したが、アクセスはほぼなかった

一応デプロイしてドメインを買って紐づけるところまではやったのですが、冷静に市場を観察すると、

• 技術力の高い現役エンジニア、デザイナーが対戦勢の監修のもとに作った完成度の高いダメージ計算Webアプリ
• すでにユーザーを抱えていたモバイルアプリ
• 企業が提供するSEOを最適化した攻略サイト

などが乱立していました。「動くものを作れた」という達成感はありましたが、アクセスが増える未来はあまり見えませんでした。

プラットフォームをずらす判断

そんな中初めてのインターンに入って学習メンバーをやっていたころにその会社の代表に

これを金ネジキ版で作ってみれば？

と言われました。

金ネジキとは、ポケモンの対戦施設「バトルファクトリー」の通称です。自分のポケモンではなくレンタルされたポケモンで戦うのですが、**「運要素が極めて強く、難易度が理不尽なほど高い」**ことで有名で、

• たまに配信者が触って一気に検索需要が増える
• 10年以上前のゲームにもかかわらずコアなファンが存在する
• 上記のような需要に対して攻略サイトはレガシーなHTML/CSS/バニラJSで構成されているサイトが主

という特徴がありました。SV版で作った内部のロジックやコンポーネントを流用してポケモンや道具・タイプのシステムなどだけを差し替えて出来るだけコストをかけずに2週間くらいで以下のWebアプリをデプロイしました。

https://www.nejiki-calculator.com/

Google Search Consoleから見た、想定と違うユーザーの行動

リリースから1,2か月後、毎日のアクセスが100前後で安定してきました。

ここでGoogle Search Consoleを見ていて、一つ面白いことに気づきました。

ダメージ計算ページよりも、ポケモンの種類や型をまとめたサブページの方がアクセスが多かったのです。以下はGoogle Search Consoleのスクショですが、トップページであるダメージ計算のページより/poke-searchというポケモンの一覧検索ページの方がアクセス数が8倍弱多かったです。

ここで初めて、ユーザーは厳密な計算よりも情報整理を求めているのでは？ という仮説が生まれました。

ドメインに合ったユーザー体験を考える

金ネジキは、

• 運要素が強い
• 対人戦ではない
• エンジョイ勢が多い

という特徴があります。

つまり、

• 厳密な最適解を求めるより手探りで攻略する過程を楽しみたい

ユーザーが多いのではないか、という仮説に至りました。

そう考えると、

• 高機能なダメージ計算
• 技術的に凝った実装

よりも、

• 情報の見やすさ
• 思考を邪魔しないUI
• 攻略を考える余白

の方が良いユーザー体験につながる可能性が高いです。ここでプロダクトの本質的な課題は技術力不足ではなくまずドメイン理解だったと感じました。

上記を踏まえた改善点

今回の個人開発を振り返ると、技術的な未熟さよりも「そもそも何を解決すればよいか」という課題設定が曖昧だったと感じています(もちろん技術は未熟ではあるのですが...)。

ドメイン理解の不足

私は対人戦が好きで、NPCとの対戦コンテンツである金ネジキを実際に深くプレイした経験がなく、YouTubeの配信で少し視聴したことがある程度でした。

そのため、

• ユーザーがどこで詰まり
• 何を面白いと感じ
• 何を補助してほしいのか

といった点を十分に想像できないまま、「ダメージ計算が出来れば役に立つだろう」という自分都合の仮説でプロダクトを作り始めてしまいました。

この点については、リリース後に実際に自分で金ネジキを10時間ほどプレイしてみました。

金ネジキは勝利後に相手のポケモンと自分のポケモンを入れ替えられるゲーム性があり、プレイ中に「強いポケモンを複数ストックしてローテーションできたら、毎回ステータスを覚えておく必要がなくて楽なのに」という課題に気づきました。

そこで、複数体のポケモンをストックできる「スペア機能」を追加実装しました。

定量的な改善効果は測定できていませんが、実際に自分でプレイすることで「ダメージ計算」以外のユーザーの課題が見えた点が大きな学びでした。

他にもポケモンのゲームの進行度による細かい数値ずれが反映出来ていないなどの課題が発見できたのでそれらも今後修正していきたいです。

技術選定について

技術選定に関しても当時アルゴ式の学習メンバーの課題で触っていた Next.js x Shadcn/ui をほぼそのまま流用していました。

結果として開発はスムーズでしたが、今振り返ると

• 静的なデータがメインなのでSSGで十分だったページをSSRにしていた
• 状態管理が不要な部分でも useState を多用していた
• コンポーネントの責務分離が曖昧で、再利用性が低かった
• シンプルに実装できる部分で不要な依存を入れている

といった技術的な粗さが多くありました。

おわりに

今回の個人開発を通して「技術力が足りなかったから上手くいかなかった」という単純な話ではないことに気づきました。

むしろ、

• ユーザーは誰か
• どんな文脈で使われているのか
• 何を助けると価値になるのか

といったドメイン理解が不十分なまま、技術で解決しようとしていたことが、本質的な課題だったと感じています。

エンジニアとして、意思決定をするのに十分な技術力があった上で、ユーザーの目線を考えられることが重要だと学びました。