現時点で考えているシステム構成と懸念点
1. はじめに
月商1000万円を目指して、新規プロジェクトを進めている。
このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、どのような考え方で開発しているか、どんなシステム構成を想定しているか、どこに不安があるかは記録していく。
今回は、現時点で考えているシステム構成について整理する。
まだ正式リリース前なので、構成は今後変わる可能性がある。
ただ、今の段階である程度整理しておかないと、後から作り直しが大きくなる。
特に今回のプロジェクトは、単なる静的サイトではない。
ユーザー登録、データ管理、管理者機能、進行管理、通知、ランキング、履歴、将来的な収益化などを考える必要がある。
そのため、最初からある程度、拡張できる構成にしておきたい。
2. 現時点の大まかな構成
現時点では、以下のような構成を想定している。
| 領域 | 想定している役割 |
|---|---|
| フロントエンド | ユーザーが操作するWeb画面 |
| バックエンド | データ処理、認証、権限管理、各種ロジック |
| データベース | ユーザー情報、履歴、マスタ、進行データなどを管理 |
| ストレージ | 画像・素材・添付ファイルなどの管理 |
| 管理者画面 | 運営側がデータや設定を管理する画面 |
| バッチ・定期処理 | 定期的な集計、状態更新、通知など |
| ログ・監査 | 不具合調査、操作履歴、運営確認 |
| テスト環境 | 動作確認、自動テスト、リリース前確認 |
| AI開発支援 | ChatGPT、Cursor、Gensparkなどを活用 |
構成としては、Webアプリを中心にしたフルスタック構成で考えている。
スマホアプリを最初から作るのではなく、まずはスマホでも使いやすいWebアプリとして作る。
正式なアプリ化は、必要になった段階で検討する。
3. フロントエンド
フロントエンドは、ユーザーが直接触る部分である。
ここでは、以下を重視している。
スマホで使いやすいこと
初回ユーザーが迷わないこと
主要導線が分かりやすいこと
画面遷移が自然であること
将来的に画面追加しやすいこと
デザイン改善を後から入れやすいこと
現時点では、PCよりもスマホ利用をかなり意識している。
もちろん開発中はPCで確認することが多い。
ただ、実際のユーザーはスマホで見る可能性が高い。
そのため、最初からスマホ対応を後回しにしすぎると危険だと考えている。
フロントエンドで特に懸念しているのは、画面数が増えすぎることだ。
機能が増えると、自然に画面も増える。
画面が増えると、導線が複雑になる。
導線が複雑になると、初回ユーザーが迷う。
そのため、画面設計では、単に機能を並べるのではなく、
最初に何を見せるか、次に何をしてもらうかを重視したい。
4. バックエンド
バックエンドでは、認証、データ取得、データ更新、権限管理、各種ロジックを扱う。
今回のプロジェクトでは、見た目以上にバックエンド側の処理が重要になる。
たとえば、以下のような処理が必要になる。
ユーザーごとの状態管理
権限チェック
データ更新時の整合性確認
履歴保存
ランキング集計
通知対象の判定
管理者操作の反映
定期的な状態更新
不正操作の防止
フロント画面だけ作っても、裏側のデータ処理が弱いとサービスとして成立しない。
特に怖いのは、最初は小さく見えていた処理が、後から複雑化することである。
そのため、バックエンド側では、できるだけ以下を意識したい。
データ更新ルールを明確にする
重要な処理は画面側だけに寄せすぎない
権限チェックを確実に入れる
後から監査できるよう履歴を残す
手動運用でしか回らない処理を減らす
5. データベース
今回のプロジェクトでは、データベース設計がかなり重要になる。
単純な投稿サイトやLPではなく、ユーザーごとの状態、履歴、マスタ情報、集計データ、管理者操作など、多くのデータを扱うことになる。
大きく分けると、以下のようなデータが必要になる。
| データ種別 | 内容 |
|---|---|
| ユーザーデータ | アカウント、プロフィール、権限など |
| マスタデータ | システム側で管理する基本情報 |
| 進行データ | ユーザーごと、または全体で変化する状態 |
| 履歴データ | 操作履歴、結果履歴、更新履歴 |
| 集計データ | ランキング、統計、サマリー |
| 管理データ | 運営側が操作・確認する情報 |
| ログデータ | 不具合調査や監査に使う記録 |
ここでの懸念は、データ構造を雑に作ると、後からほぼ必ず苦しくなることだ。
最初は「とりあえず動けばいい」と思っても、後から集計したくなったり、履歴を見たくなったり、管理画面で修正したくなったりする。
そのときに、データの持ち方が悪いと、大きな手戻りになる。
一方で、最初から完璧なデータ設計を目指しすぎると、今度は実装が進まない。
このバランスが難しい。
現時点では、以下の方針で進めたい。
主要なデータ構造は先に設計する
ただし細部は実装しながら調整する
履歴と現在状態を分けて考える
管理者が後から確認できる形にする
将来の集計に必要な項目を極端に削らない
6. 管理者画面
管理者画面も、最初からある程度必要だと考えている。
個人開発では、管理者画面を後回しにしがちである。
しかし、運営型のサービスでは、管理者画面がないとかなり厳しい。
運営側がデータを確認したり、修正したり、状態を変更したり、問い合わせに対応したりできないと、サービス公開後に詰まる。
管理者画面で必要になりそうなのは、以下である。
ユーザー管理
マスタデータ管理
進行状況確認
各種データ修正
通知・お知らせ管理
問い合わせ対応
不具合調査
集計確認
操作履歴確認
もちろん、最初から完璧な管理画面を作る必要はない。
ただし、最低限の管理機能がない状態で外部公開するのは危険だと思っている。
特に、何か問題が起きたときに、DBを直接触らないと直せない状態は避けたい。
7. バッチ・定期処理
このプロジェクトでは、定期的な処理も重要になる。
ユーザーの操作だけで完結するサービスであれば、画面操作に応じて処理すればよい。
しかし、一定のタイミングで集計したり、状態を進めたり、通知したりする処理が必要になる可能性が高い。
想定している定期処理は、以下のようなものだ。
定期集計
状態更新
ランキング更新
通知生成
古いデータの整理
イベントや期間の切り替え
不整合チェック
ここでの懸念は、バッチ処理が失敗したときの扱いである。
定期処理は、普段は見えにくい。
しかし、失敗するとサービス全体に影響する。
そのため、将来的には以下も必要になる。
実行ログ
成功・失敗の記録
リトライ
手動再実行
管理者への通知
二重実行防止
最初は簡単な処理でよい。
ただし、後から運用できるように、ログだけは残せる設計にしたい。
8. 画像・素材・ファイル管理
今回のプロジェクトでは、画像や素材も重要になる可能性がある。
画面の雰囲気、説明資料、LP的な表現、ユーザーに見せるビジュアルなど、画像要素はサービス体験に関わる。
そのため、素材管理も軽視できない。
懸念としては、画像ファイルが増えたときに、どれが最新か分からなくなることだ。
今後は、以下を整理したい。
素材フォルダのルール
ファイル名のルール
使用中・未使用の区別
デザイン案と本番素材の区別
画像サイズや形式
圧縮方針
著作権・利用権の確認
特に、AIで生成したデザイン案や画像は、便利な一方で管理が雑になりやすい。
将来的に公開する素材については、利用範囲や権利面も確認が必要になる。
9. テストと品質管理
システム構成を考えるうえで、テストも重要である。
現時点では、一人用確認版をまず完成させたい段階である。
そのため、最初から大規模な自動テストを作り込みすぎる必要はない。
ただし、最低限の通し確認は必要である。
特に確認したいのは、以下である。
新規登録から主要画面まで進めるか
主要な操作ができるか
データが正しく保存されるか
更新後に表示が崩れないか
権限が正しく効いているか
スマホで最低限使えるか
エラー時に復帰できるか
管理者操作が最低限できるか
将来的には、PlaywrightのようなE2Eテストも使いたい。
ただ、現時点ではテストを重くしすぎるより、まずはサービスの中心体験を通すことを優先したい。
テストは大事だが、テスト整備だけで開発が止まらないようにする必要がある。
10. 開発環境とAI活用
開発環境としては、PCを追加し、既存PCとの2台体制にする予定である。
また、AIツールとしては以下を活用している。
| ツール | 役割 |
|---|---|
| ChatGPT | 企画整理、仕様整理、議事録、記事作成、指示文作成 |
| Cursor | 実装、修正、コード調査、ドキュメント反映 |
| Genspark | デザイン案、LP案、資料、外向け表現 |
この構成は、かなり強力だと感じている。
ただし、AIを使うほど、指示の質が重要になる。
AIに雑な指示を出すと、雑な結果になる。
逆に、ドキュメントや作業範囲を整理して渡すと、かなり高い精度で作業してくれる。
そのため、システム構成そのものだけでなく、
AIにどう作業を依頼するかも開発体制の一部になっている。
11. 現時点での大きな懸念
現時点での懸念を整理すると、以下である。
11.1 構成が複雑になりすぎること
作りたいことが多いため、システム構成も複雑になりやすい。
複雑な構成にすると、後から拡張しやすくなる面もある。
しかし、最初から複雑にしすぎると、一人で管理できなくなる。
まずは、シンプルに動く構成を優先したい。
11.2 データ設計の手戻り
データ設計は後から直すのが大変である。
特に履歴、集計、ランキング、管理者操作に関わる部分は、最初に雑に作ると後で苦しくなる。
ここは慎重に進めたい。
11.3 管理者機能不足
ユーザー向け画面だけを作っても、運営できなければ意味がない。
管理者機能を後回しにしすぎると、公開後にトラブル対応ができなくなる。
最低限の管理者画面は、早めに整備したい。
11.4 スマホ対応の遅れ
PCでは見やすくても、スマホでは使いにくいということはよくある。
今回のサービスでは、スマホ対応はかなり重要だと考えている。
最初からスマホでの見え方を確認しながら進めたい。
11.5 AI任せによる品質ブレ
AIは強力だが、万能ではない。
実装されたコードが本当に正しいか、設計と矛盾していないか、セキュリティ的に問題がないかは、人間が確認する必要がある。
AIを使うほど、レビューと確認の重要性は増える。
11.6 固定費の増加
AIツール、PC、クラウドサービスなど、開発にかかる費用は増えてきている。
まだ売上が立っていない段階なので、固定費の増加には注意が必要である。
ただし、必要な投資を避けすぎると、開発が遅れる。
ここは、引き続き効果を見ながら判断したい。
12. 現時点の方針
現時点では、以下の方針で進めたい。
まずは一人用確認版を完成させる
システム構成はシンプルに保つ
ただし将来の拡張を完全には潰さない
データ設計は慎重に行う
管理者機能を後回しにしすぎない
スマホ対応を初期から意識する
バッチ・定期処理はログを残す前提で考える
AI生成コードは必ず確認する
テストは重くしすぎず、まず主要導線を確認する
費用対効果を見ながら開発体制を強化する
13. 今回の結論
現時点で考えているシステム構成は、Webアプリを中心に、認証、データベース、管理画面、定期処理、ログ、テスト、AI開発支援を組み合わせたものになる。
まだ最終形ではない。
今後、開発を進める中で変わる部分もある。
ただし、今の段階で見えている懸念も多い。
データ設計、管理者機能、スマホ対応、定期処理、AI任せによる品質ブレ、固定費増加。
これらを軽視すると、後から苦しくなる。
一方で、最初から完璧を目指しすぎると、いつまでも公開できない。
だから、今の方針はこうである。
最初はシンプルに作る。ただし、後から運用できない構成にはしない。
月商1000万円を目指すなら、アイデアや画面だけでは足りない。
その裏側にあるシステム構成、データ設計、運用設計まで含めて、少しずつ土台を固めていく必要がある。
今はまだ、その土台を作っている段階である。
0 件のコメント:
コメントを投稿