拡張しやすい中古オークションアプリの構成をどう考えたか

この個人開発では、中古オークションをテーマにしたアプリを作っています。 ただ、今回の開発で特に重視したのは、単に動くものを作ることではありませんでした。 あとから直しやすいこと、機能追加しやすいこと、そして構成の意図を自分の言葉で説明できることを強く意識して進めました。 個人開発では、まず見た目を整えて、それらしく動くものを早く作りたくなります。 自分も以前はその考え方に寄ることが多くありました。 しかし実際には、アプリを少し育てようとしただけで、設計の甘さがそのまま修正コストとして返ってきます。 管理画面を足したい、記事機能を足したい、権限を分けたい、導線を整理したい。 こうした自然な追加をしたときに全体が崩れないかどうかで、最初の設計の質がはっきり出ると感じました。 そこで今回のアプリでは、フロントエンドとバックエンドの責務を最初から分ける方針を取りました。 フロントエンドには Next.js、バックエンドには Rails API を使っています。 この構成にした理由は、流行りの技術を採用したかったからではありません。 画面表示とデータ管理の責務を分けておいたほうが、変更の影響範囲を小さくしやすいと考えたからです。 Next.js 側には、画面表示、導線設計、ユーザー体験の責務を持たせています。 一覧画面や詳細画面の見せ方、レイアウト、コンポーネント分割など、利用者が直接触れる部分はこちらで担います。 一方で Rails 側には、認証、権限、データ管理、永続化、API の責務を寄せています。 この分離によって、UI を改善したいときにバックエンド内部まで大きく触らずに済みますし、API 設計を調整したいときにもフロント全体を壊しにくくなります。 この考え方は、将来的な機能追加を見据えたときに特に効いてきます。 今回は利用者向け画面だけで終わる構成にはしたくありませんでした。 途中から管理画面を足したり、記事機能を持たせたり、権限に応じて触れる範囲を変えたりといった拡張まで視野に入れていました。 そのため、最初から「今必要なもの」だけでなく、「後から自然に足したいもの」に耐えられる構成を目指しました。 管理機能を考えるときに重要だったのは、認証と権限を分けて考えることです。 ログインしているかどうかだけでは、一般ユーザーと管理者の違いは表現できません。 そこで users には role を持たせ、誰がどこまで操作できるのかを最初から整理しやすい形にしました。 この判断によって、利用者向け画面と管理者向け画面を明確に分ける土台ができました。 早い段階で role を持たせておくと、後から無理やり権限を追加するよりも自然に構造を育てていけます。 また、このアプリでは posts テーブルを独立して持たせ、記事機能も組み込めるようにしています。 これも単なるおまけ機能ではなく、ポートフォリオとしての伝え方を考えた上での判断でした。 個人開発では、完成した画面や動作だけを見せることはできます。 ただ、それだけでは「何を考えて設計したのか」「どこで悩み、どう改善したのか」が伝わりにくいことがあります。 記事機能を持たせることで、実装だけでなく思考の流れや設計意図も残せるようにしました。 これは自分の中でかなり大きな変化でした。 以前は、まず形にすることを優先していて、後から説明を足そうとする考え方に寄っていました。 しかし今回は、作るものそのものの中に説明のための場所も組み込みたいと考えました。 アプリと記事が別々に存在するのではなく、一つのプロジェクトの中で「作品」と「考え方」がつながっている状態を目指しました。 この方針は、全体設計にも影響しています。 今回の構成では、まずコアとなる機能を成り立たせつつ、そこに追加機能を差し込みやすい余白を残すことを意識しました。 最初からすべてを作り込もうとすると、構造が複雑になりやすく、何を優先すべきかも見えにくくなります。 一方で、必要最低限だけに寄せすぎると、少しの機能追加でも全体を作り直すことになります。 そのため今回は、今すぐ必要な機能と、将来的にほぼ確実に必要になる機能の中間を狙う設計を意識しました。 実際、開発を進める中で感じたのは、拡張性というのは機能をたくさん入れることではないという点です。 むしろ大切なのは、責務を混ぜないことでした。 画面の責務、データの責務、認証の責務、管理の責務、発信の責務を無理に一つへ詰め込まない。 それぞれを分けておくことで、ある一箇所を改善したいときに、他の部分まで大きく巻き込まずに済みます。 この観点で見ると、Rails API と Next.js の分離も、管理画面を見据えた role 設計も、記事機能の独立も、すべて同じ方向を向いています。 それは「アプリを後から育てられる形にしておく」ということです。 個人開発では、公開した時点で一区切りになりがちです。 しかし自分は、公開後に改善し続けることまで含めて開発だと考えています。 そのため、最初から将来の変更を拒む構造ではなく、変更を受け入れやすい構造にしておくことが重要でした。 また、この設計を考える中で強く感じたのは、見た目の完成度だけではアプリの価値は決まらないということです。 もちろん UI は重要です。 ただ、使いながら機能を足したり、問題を直したり、運用の都合に合わせて構造を変えていくには、内部の責務分離ができていないとすぐに限界が来ます。 今回はその限界をなるべく先送りするのではなく、最初から向き合っておきたいと考えました。 個人開発の良さは、自由に作れることです。 その一方で、自由だからこそ設計の判断に考え方がそのまま出ます。 今回のアプリでは、単に機能を並べるのではなく、 どの責務をどこへ置くか、 どの拡張を今の段階で見据えるべきか、 何を独立させると後から効いてくるか、 そうした点を一つずつ考えながら組み立てました。 この開発で自分が一番伝えたいのは、作った機能の数そのものではありません。 むしろ、あとから育てやすい構成を意識して、責務分離と拡張性を両立させようとしたことです。 Rails API と Next.js を分けたこと、 role を持たせて管理機能を見据えたこと、 posts を独立させて設計意図まで伝えられるようにしたこと。 これらはすべて、一時的に動くものではなく、継続して改善できるアプリを目指した結果です。 個人開発では、まず形にする力が大切です。 ただ、その次の段階では、どう育てる前提で作ったかがより重要になると感じました。 今回のアプリでは、その土台づくりに一番力を入れました。 だからこそ、この構成そのものが自分の設計姿勢を表すものになっていると考えています。