2026年4月30日木曜日

第8回:結局、ゴールはいつなのか


1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、費用、スケジュール、課題、システム構成、判断の過程については記録している。

ここまで、プロジェクト計画、費用、開発状況、ドキュメント、追加PC、システム構成について整理してきた。

では、結局のところ、ゴールはいつなのか。

今回は、その問いについて整理する。


2. ゴールは一つではない

まず前提として、このプロジェクトのゴールは一つではない。

最終的な大目標は、もちろん月商1000万円である。

ただし、そこだけをゴールにすると、あまりにも遠すぎる。

月商1000万円を達成する前には、いくつもの中間ゴールがある。

現時点では、ゴールを以下のように分けて考えている。

ゴール意味
第1ゴール一人用確認版を完成させる
第2ゴール限定公開できる状態にする
第3ゴール初期サービスインする
第4ゴール初めて売上を立てる
第5ゴール月商10万円を達成する
第6ゴール月商100万円を達成する
第7ゴール月商300万円を達成する
最終ゴール月商1000万円を達成する

つまり、いきなり月商1000万円を狙うのではなく、段階的に到達していく。


3. 直近のゴールは「一人用確認版」

現時点で最も重要なゴールは、一人用確認版の完成である。

これは、一般公開版ではない。
まだユーザーを集める段階でもない。

まずは自分自身が、最初から最後までサービスを触り、基本体験が成立しているかを確認できる状態にする。

一人用確認版で確認したいのは、以下である。

  • 新規ユーザーとして開始できる

  • 初回説明を受けられる

  • メイン画面に進める

  • 基本操作が一通りできる

  • データが作成・更新される

  • 結果や履歴を確認できる

  • 最低限の通知やランキングが見える

  • 手動進行または自動進行が成立する

  • スマホでも最低限確認できる

  • 致命的なエラーで止まらない

ここまでできれば、まずは一人用確認版として区切れる。

今の直近ゴールは、ここである。


4. 一人用確認版の目標時期

では、一人用確認版はいつまでに作るのか。

現時点の目標は、2026年5月中である。

もちろん、これは確約ではない。
まだ要件は増えているし、実装すべきことも多い。
デザイン、スマホ対応、管理機能、テスト、ドキュメント更新もある。

それでも、期限を置かないと永遠に完成しない。

そのため、まずは以下のように置く。

2026年5月中に、一人用確認版を通し確認できる状態にする。

この時点で完璧である必要はない。

細かいデザイン、追加演出、細部の作り込みは後でもよい。
重要なのは、サービスの中心体験が破綻せずに通ることである。


5. 限定公開版の目標時期

一人用確認版ができたら、次は限定公開版を目指す。

限定公開版では、自分以外の少人数に触ってもらう。

ここで必要になるのは、機能の多さではなく、最低限の安心感である。

  • 初回ユーザーが迷わない

  • 何をすればよいか分かる

  • 不具合が起きても報告できる

  • 管理者が最低限対応できる

  • データが壊れない

  • スマホで使える

  • ヘルプやガイドがある

  • サービスの価値が伝わる

限定公開版の目標は、2026年6月中に置きたい。

ここでは、完璧な正式版ではなく、少人数に触ってもらい、反応を見ることを重視する。


6. 初期サービスインの目標時期

限定公開で手応えを確認したら、初期サービスインを目指す。

現時点では、初期サービスインの目標は、2026年7月〜8月頃と考えている。

ただし、これはかなり重要な判断になる。

公開を急ぎすぎると、品質不足で失敗する可能性がある。
一方で、作り込みすぎると、いつまでも公開できない。

そのため、初期サービスインでは、以下の状態を目指す。

  • 初回ユーザーが最低限迷わない

  • 主要導線が通っている

  • 致命的な不具合がない

  • スマホで最低限使える

  • 運営側が最低限管理できる

  • 不具合報告導線がある

  • 継続利用する理由がある

  • 収益化の入口を検討できる

最初から完成形を出す必要はない。
ただし、「触っても何をすればいいか分からない」状態では公開しない。


7. 売上目標の時期

サービスイン後は、売上目標を段階的に置く。

現時点のざっくりした目標は以下である。

時期目標
2026年5月一人用確認版
2026年6月限定公開版
2026年7〜8月初期サービスイン
2026年内月商10万円
2027年前半月商100万円
2027年中月商300万円
2027年末〜2028年月商1000万円

かなり挑戦的なスケジュールである。

特に、月商100万円以降は、開発だけでは到達できない。
ユーザー獲得、継続率、課金導線、運営、コンテンツ、コミュニティ、SNS発信、改善サイクルが必要になる。

つまり、初期サービスインまでは開発の勝負。
その後は、サービス運営と事業化の勝負になる。


8. 月商1000万円はいつ達成するのか

では、最終ゴールである月商1000万円はいつ達成するのか。

現時点では、2027年末から2028年頃を目標に置きたい。

これは、かなり大きな目標である。

月商1000万円を達成するには、単にWebサービスを公開するだけでは足りない。

必要になるのは、以下である。

  • 継続利用される強い体験

  • 課金したくなる仕組み

  • ユーザー同士の広がり

  • 定期的なイベントや更新

  • SNSで話題になる要素

  • 安定したシステム

  • 運営体制

  • サポート体制

  • データ分析

  • 改善サイクル

  • ブランド化

月商1000万円は、機能を作っただけでは届かない。

サービスそのものが、ユーザーの日常や習慣に入り込む必要がある。


9. ゴールを早める要因

もちろん、目標時期は変わる可能性がある。

ゴールが早まる可能性がある要因もある。

  • AIツールを活用して開発速度が上がる

  • 追加PCにより並行作業が進む

  • Cursorの上位プランで実装速度が上がる

  • 一人用確認版の範囲を適切に絞れる

  • 後回し機能の判断がうまくいく

  • デザイン反映がスムーズに進む

  • 初期ユーザーの反応が良い

  • SNSやブログで認知が取れる

  • 収益化導線が早く見つかる

特に、AI活用と作業範囲の整理は大きい。

AIにうまく作業を任せられれば、一人開発でもかなり進められる可能性がある。


10. ゴールを遅らせる要因

一方で、ゴールが遅れる要因も多い。

  • 要件が増え続ける

  • 完成条件が曖昧になる

  • ドキュメント更新に時間を使いすぎる

  • データ設計で手戻りが出る

  • スマホ対応が遅れる

  • 管理者機能が不足する

  • テスト不足で不具合が増える

  • AI生成コードの品質確認に時間がかかる

  • PC2台運用でGit競合が起きる

  • 固定費が増えて精神的負担になる

  • 初期ユーザー獲得が想定より難しい

特に注意すべきなのは、要件が増え続けることである。

良いアイデアが出るほど、作りたいものは増える。
しかし、それを全部入れていたら、リリースは遠のく。

今後は、
「今必要なもの」
「後でよいもの」
「今作った方が後工程が楽になるもの」
を冷静に分ける必要がある。


11. 本当のゴールは「リリース」ではない

ここで大事なのは、リリースはゴールではないということだ。

リリースは、あくまでスタートである。

本当のゴールは、ユーザーに継続して使われ、価値を感じてもらい、収益が生まれ、運営し続けられる状態を作ることだ。

その意味では、ゴールは段階的に変わっていく。

最初のゴールは、一人用確認版。
次のゴールは、限定公開。
その次は、初期サービスイン。
その次は、初売上。
その次は、月商10万円。
そして、月商100万円、300万円、1000万円。

ゴールは遠い。
ただし、次に登る山は見えている。

今は、まず一人用確認版である。


12. 今回の結論

結局、ゴールはいつなのか。

現時点の答えは、こうである。

一人用確認版は2026年5月中。
限定公開版は2026年6月中。
初期サービスインは2026年7月〜8月。
月商10万円は2026年内。
月商100万円は2027年前半。
月商300万円は2027年中。
月商1000万円は2027年末〜2028年。

これはまだ暫定である。

今後の開発状況、ユーザー反応、費用、AIツール活用、生活状況によって変わる可能性はある。

ただし、期限を置くことに意味がある。

期限がなければ、いつまでも作り続けてしまう。
期限があるから、何を削るか、何を優先するかを判断できる。

月商1000万円までの道のりは長い。

けれど、今日やるべきことは明確である。

まずは、一人用確認版を完成させる。
そのために、今週、今月、何を作るべきかを決める。

大きなゴールは遠くに置きながら、目の前のゴールを一つずつ達成していきたい。

第7回:現時点で考えているシステム構成と懸念点


現時点で考えているシステム構成と懸念点

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. 現時点の方針

現時点では、以下の方針で進めたい。

  1. まずは一人用確認版を完成させる

  2. システム構成はシンプルに保つ

  3. ただし将来の拡張を完全には潰さない

  4. データ設計は慎重に行う

  5. 管理者機能を後回しにしすぎない

  6. スマホ対応を初期から意識する

  7. バッチ・定期処理はログを残す前提で考える

  8. AI生成コードは必ず確認する

  9. テストは重くしすぎず、まず主要導線を確認する

  10. 費用対効果を見ながら開発体制を強化する


13. 今回の結論

現時点で考えているシステム構成は、Webアプリを中心に、認証、データベース、管理画面、定期処理、ログ、テスト、AI開発支援を組み合わせたものになる。

まだ最終形ではない。
今後、開発を進める中で変わる部分もある。

ただし、今の段階で見えている懸念も多い。

データ設計、管理者機能、スマホ対応、定期処理、AI任せによる品質ブレ、固定費増加。
これらを軽視すると、後から苦しくなる。

一方で、最初から完璧を目指しすぎると、いつまでも公開できない。

だから、今の方針はこうである。

最初はシンプルに作る。ただし、後から運用できない構成にはしない。

月商1000万円を目指すなら、アイデアや画面だけでは足りない。
その裏側にあるシステム構成、データ設計、運用設計まで含めて、少しずつ土台を固めていく必要がある。

今はまだ、その土台を作っている段階である。

第6回:本日届く追加PCに期待していること

 

本日届く追加PCに期待していること

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、投資判断、課題、費用、スケジュールについては記録していく。

今回は、本日届く追加PCについて書く。

ここまで、ChatGPT、Cursor、GensparkなどのAIツールを使いながら開発を進めてきた。
そして本日、開発用に新しいPCが届く予定である。

これは単なるガジェット購入ではない。
自分の中では、かなり大きな意味を持つ開発投資である。


2. なぜ追加PCを買ったのか

今回、追加PCを購入した理由は、単純に「新しいPCが欲しかったから」ではない。

目的は、開発を止めないことである。

現在の開発では、1台のPCで多くの作業を同時に行っている。

  • Cursorで実装する

  • ChatGPTで仕様や指示文を整理する

  • ブラウザで動作確認する

  • ローカルサーバーを起動する

  • ドキュメントを確認・更新する

  • Gensparkでデザイン案を検討する

  • 画像や素材を確認する

  • テストを実行する

  • Gitの差分やコミット状況を確認する

こうした作業をすべて1台で行うと、どうしても画面も頭も散らかる。

ブラウザを開き、Cursorを開き、ターミナルを開き、ChatGPTを開き、ドキュメントを開き、さらに動作確認もする。
この状態が続くと、PCの性能だけでなく、自分の集中力も削られていく。

追加PCを導入することで、この負荷を分散したい。


3. 既存PCと追加PCの役割を分ける

追加PCが届いたら、既存PCと新PCを何となく使い分けるのではなく、役割を明確にしたい。

今考えている使い分けは、以下である。

PC主な役割
既存PCChatGPT、ブログ作成、仕様整理、ドキュメント確認、進行管理
追加PCCursor、ローカル開発、実装、ブラウザ確認、テスト実行

もちろん、実際に使ってみて調整する必要はある。

ただ、基本方針としては、既存PCを思考・整理用、新PCを実装・検証用に分けたい。

これにより、ChatGPTで方針を整理しながら、もう一方のPCでCursorに実装を進めてもらうような運用がしやすくなる。


4. 2台体制で期待している効果

追加PCによって期待している効果はいくつかある。

4.1 開発作業の待ち時間を減らす

1台だけだと、ビルド中、インストール中、テスト実行中、ローカルサーバー起動中に、他の作業がしにくくなる。

2台あれば、一方で実装やビルドを進めながら、もう一方で次の指示文を作ったり、仕様を確認したりできる。

これは小さな違いに見えるが、積み重なるとかなり大きい。

開発では、待ち時間そのものよりも、待っている間に集中が切れることが問題になる。
2台体制にすることで、集中を切らさずに次の作業へ移りやすくなる。


4.2 画面確認がしやすくなる

Webサービス開発では、実装だけでなく画面確認が重要である。

実装した機能が実際にどう見えるか。
ボタンの位置は分かりやすいか。
スマホサイズで崩れていないか。
導線が自然か。
エラー表示は適切か。

こうした確認を、Cursorやターミナルと同じ画面で行うと、どうしても狭くなる。

2台あれば、一方でコードを開き、もう一方でブラウザを表示し続けられる。
これだけでも、かなり確認効率が上がるはずである。


4.3 ChatGPTとの壁打ちを止めずに済む

このプロジェクトでは、ChatGPTをかなり使っている。

使い方は、単なる質問ではない。

  • プロジェクト計画の整理

  • Cursorへの指示文作成

  • ブログ記事作成

  • 課題の棚卸し

  • 仕様の言語化

  • 優先度判断

  • 開発方針の壁打ち

こうした作業を、開発と並行して行っている。

1台だけだと、Cursorで作業している途中にChatGPTを見たり、ブラウザで確認したり、ドキュメントを開いたりして、画面の切り替えが多くなる。

2台になれば、片方のPCではChatGPTを常に開いておき、もう片方で実装を進められる。
これはかなり大きい。

自分にとってChatGPTは、開発中のPMO、議事録係、壁打ち相手に近い。
その相手を常に見える状態にしておけるのは、開発効率に直結すると思っている。


5. 並行開発にはルールが必要

ただし、PCが2台になるからといって、何も考えずに並行作業をすると危険である。

一番怖いのは、同じファイルを別々のPCで触ってしまうことだ。

たとえば、片方のPCで画面Aを修正し、もう片方でも同じ画面Aに関わるファイルを修正すると、Gitの競合や認識ズレが起きる。

そのため、2台体制では、開発ルールが必要になる。

今後は、作業前に以下を明確にしたい。

  • どちらのPCで作業するか

  • 今回触るファイル

  • 今回触らないファイル

  • 作業目的

  • 完了条件

  • テスト対象

  • commit / push のタイミング

  • もう一方のPCで並行してよい作業

PCが増えると、できることは増える。
しかし、管理しないと混乱も増える。


6. 作業範囲の宣言を導入したい

2台体制で特にやりたいのが、作業範囲の宣言である。

たとえば、作業開始時に以下のように決める。

追加PCでは、画面Aと関連コンポーネントのみ修正する。
既存PCでは、ドキュメント整理と次のCursor指示文作成のみ行う。
同じコードファイルは触らない。

このように分けることで、作業の衝突を避けやすくなる。

さらに、必要であればプロジェクト内に「現在作業中の範囲」を記録するファイルを置くことも考えている。

たとえば、以下のような内容を残す。

現在作業中の範囲

PC1:
- ドキュメント整理
- ブログ記事作成
- 次回指示文作成

PC2:
- 実装作業
- ローカル確認
- ビルド確認

触らないファイル:
- 共通設定ファイル
- 認証関連
- データ設計関連

注意:
- 同じ画面を両PCで同時に修正しない
- commit前に必ずgit statusを確認する

こうしたルールは少し面倒に見える。
ただ、後から競合を直す方がもっと面倒である。


7. AIツールとの相性も良くなるはず

追加PCは、AIツールとの相性も良いはずである。

現時点で使っている主なAIツールは、ChatGPT、Cursor、Gensparkである。

それぞれ役割が違う。

ツール役割
ChatGPT方針整理、仕様整理、議事録、ブログ、Cursor指示文
Cursor実装、修正、調査、コード反映
Gensparkデザイン案、LP案、チラシ、外向け表現

1台のPCで全部を切り替えるよりも、2台で役割を分けた方が使いやすい。

たとえば、以下のような流れが考えられる。

  1. 既存PCでChatGPTに仕様を整理させる

  2. その内容をCursor向け指示に変換する

  3. 追加PCでCursorに実装させる

  4. 追加PCでローカル確認する

  5. 既存PCで結果を見ながら次の判断を整理する

  6. 必要に応じてGensparkで画面や素材を検討する

この流れが安定すれば、開発スピードはかなり上がる可能性がある。


8. 期待しすぎないことも大事

もちろん、PCを増やしただけで開発が一気に進むわけではない。

PCはあくまで道具である。

開発が進むかどうかは、最終的には以下にかかっている。

  • 何を作るかが明確か

  • 優先順位が決まっているか

  • Cursorへの指示が具体的か

  • 作業範囲が衝突しないか

  • 実装後に確認できるか

  • ドキュメント更新だけで止まらないか

  • リリースに近づく作業を選べているか

道具を増やしても、方針が曖昧なら効率は上がらない。

だから、追加PCを導入するタイミングで、開発ルールも一緒に整備したい。


9. 今後の使い方

追加PCが届いたら、まずは開発環境を整える。

想定している作業は以下である。

  • Cursorのインストール

  • GitHubからリポジトリ取得

  • Node.jsやパッケージ環境の準備

  • ローカル開発サーバーの起動確認

  • ブラウザでの画面確認

  • 既存PCとの作業分担確認

  • Git運用ルールの整理

  • どちらのPCで何を担当するか決める

このとき、既存PCから無理にファイルをコピーするのではなく、基本的にはGitHub上のリポジトリを取得して環境を作る。

その方が、最新状態を保ちやすく、余計なファイル混入も避けやすい。


10. 今回の結論

本日届く追加PCには、かなり期待している。

ただし、期待しているのは「新しいPCだから快適」というだけではない。

期待しているのは、開発体制そのものが変わることである。

これまでは、1台のPCで考え、書き、実装し、確認し、整理していた。
これからは、既存PCと追加PCを併用して、役割を分けながら進めたい。

  • 既存PCでは、思考、整理、記事、指示文、進行管理

  • 追加PCでは、実装、確認、テスト、ビルド

この分担がうまく機能すれば、開発スピードは上がるはずである。

一方で、2台体制には競合や混乱のリスクもある。
そのため、作業範囲の宣言、Git運用、commit前確認、並行作業ルールを整備していく。

月商1000万円を目指すなら、単にアイデアを考えるだけでは足りない。
開発環境、作業ルール、AI活用、進行管理まで含めて、少しずつ事業に近い形へ整えていく必要がある。

追加PCは、そのための一歩である。

第5回:個人開発でも、ドキュメントはかなりちゃんと作っている


個人開発でも、ドキュメントはかなりちゃんと作っている

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、プロジェクトをどう進めているか、どのように計画しているか、どんな課題に向き合っているかは記録していく。

今回は、ドキュメント管理について書く。

個人開発というと、思いついた機能をすぐ実装して、動いたら次に進む、というイメージがあるかもしれない。

もちろん、それも悪くない。
小さなアプリや試作品なら、その方が早いこともある。

ただ、今回のプロジェクトは、月商1000万円を目指している。
単なる思いつきの実験ではなく、最終的には継続運営できるサービスにしたい。

そのため、かなり早い段階からドキュメントを作っている。


2. なぜドキュメントを作るのか

ドキュメントを作る理由は、きれいな資料を残したいからではない。

目的は、主に以下である。

  • 仕様のブレを防ぐため

  • 後から判断理由を思い出せるようにするため

  • AIに正しく実装してもらうため

  • 要件変更の影響範囲を把握するため

  • 後回し機能を忘れないため

  • テスト観点を整理するため

  • サービスインに必要な条件を明確にするため

  • 将来、人に引き継げる状態にするため

特に大きいのは、AIに正しく作業してもらうためである。

今の開発では、ChatGPTやCursorのようなAIツールをかなり使っている。
AIは強力だが、前提が曖昧だと、こちらの意図と違う方向に進むことがある。

そのため、プロジェクトの方針、仕様、優先度、残課題、実装ルールをドキュメント化しておくことが重要になる。

AIに任せるためには、AIに渡せる文脈が必要である。


3. 作っているドキュメントの種類

現時点では、かなり多くのドキュメントを作っている。

具体的な企画内容は伏せるが、種類としては以下のようなものがある。

ドキュメント目的
企画概要プロジェクトの目的・コンセプト・方向性を整理する
要件定義書必要な機能・前提条件・制約を整理する
機能仕様書各機能の内容、入力、表示、操作を整理する
画面仕様書画面構成、ボタン、リンク、導線を整理する
データ設計書扱うデータ、項目、関連性を整理する
ロジック設計書内部処理や判定ルールを整理する
API設計書画面とデータ処理の接続部分を整理する
管理者機能仕様運営側が操作する画面や管理項目を整理する
ユーザーマニュアル将来ユーザーに説明する内容を整理する
管理者マニュアル運営時の手順を整理する
テスト観点一覧何を確認すべきかを整理する
リリース判定チェックリスト公開前に満たすべき条件を整理する
残課題一覧未対応事項、判断待ち事項を管理する
後回し機能一覧今はやらないが、将来必要な機能を管理する
開発ルール実装・ドキュメント更新・確認のルールを整理する

こうして並べると、個人開発としてはかなり重い。

ただ、今回のプロジェクトは途中で要件がかなり増えている。
そのため、頭の中だけで管理するのは難しい。

ドキュメントを作っていないと、後で確実に混乱する。


4. 特に重視しているドキュメント

すべてのドキュメントが同じ重要度ではない。

現時点で特に重視しているのは、以下である。

4.1 要件定義書

まず重要なのは、要件定義書である。

何を作るのか。
何を必須とするのか。
何を後回しにするのか。
どのような前提でサービスを作るのか。

ここが曖昧だと、開発がどんどんズレていく。

今回のプロジェクトでは、途中でアイデアが増え続けている。
だからこそ、要件定義書に残しておかないと、何が正式な方針なのか分からなくなる。


4.2 残課題一覧

次に重要なのが、残課題一覧である。

新しいアイデア、未解決の仕様、あとで対応する不具合、判断待ちの項目などを、残課題として管理している。

これがないと、頭の中にタスクが溜まり続ける。

残課題一覧があることで、以下ができる。

  • 今やることと後でやることを分けられる

  • 重要なアイデアを忘れない

  • AIに次の作業を依頼しやすい

  • 後回しにした理由を残せる

  • 進捗確認がしやすい

個人的には、残課題一覧はかなり重要だと思っている。


4.3 後回し機能一覧

後回し機能一覧も作っている。

ただし、最近はこの扱いが難しくなってきた。

最初は、後回し機能は単純に「今は作らないもの」として整理していた。
しかし、進めていくうちに、後回しにしすぎると逆に開発効率が悪くなるケースがあると分かってきた。

本当は先に作った方が、後工程が楽になる機能もある。

そのため、後回し機能一覧は、単なる保留リストではなく、定期的に棚卸しする対象にしている。

後回しにしたものでも、以下に当てはまる場合は前倒しする。

  • 実装が軽い

  • ユーザー体験に大きく効く

  • 後から作ると手戻りが大きい

  • 他の機能の前提になる

  • サービスイン判断に関わる

「後回し」と書いたからといって、永久に後回しにするわけではない。


4.4 テスト観点一覧

テスト観点一覧も重要である。

個人開発では、テストが後回しになりやすい。
ただ、サービスとして公開するなら、最低限確認すべきことは整理しておく必要がある。

今後確認すべき観点としては、以下のようなものがある。

  • 新規登録後の流れ

  • 初回説明の表示

  • 主要画面への遷移

  • データ登録・更新・削除

  • エラー時の表示

  • スマホでの見え方

  • 管理者操作

  • 通知

  • 履歴

  • ランキング

  • 自動処理

  • 権限チェック

  • 不正操作防止

特に、一人用確認版、限定公開版、正式公開版では、必要なテスト水準が異なる。

そのため、今後はテスト観点もフェーズごとに分けて整理していきたい。


5. ドキュメントを作るメリット

実際にドキュメントを作っていて、メリットはかなり大きい。

5.1 判断が残る

新規プロジェクトでは、毎日のように判断が発生する。

  • この機能は今作るのか

  • 後回しにするのか

  • どの画面を優先するのか

  • どの課金ツールを使うのか

  • どの仕様を採用するのか

  • どこまでを初期リリースに入れるのか

判断を記録していないと、数日後には理由を忘れる。

ドキュメントに残しておけば、後から見返せる。
これはかなり大きい。


5.2 AIへの指示が正確になる

AIに実装を依頼するとき、前提が曖昧だと期待通りにならない。

しかし、ドキュメントがあれば、AIに対して以下のような指示ができる。

  • この要件定義書に従って実装してほしい

  • 残課題一覧を更新してほしい

  • 後回し機能一覧と照合してほしい

  • 画面仕様書に沿ってボタンを配置してほしい

  • データ設計書と矛盾がないか確認してほしい

  • テスト観点に沿って確認してほしい

これはかなり便利である。

AIを使う開発では、ドキュメントは単なる記録ではなく、AIに作業を引き継ぐための入力情報になる。


5.3 要件変更に強くなる

今回のプロジェクトでは、要件変更がかなり多い。

ただ、ドキュメントがあることで、要件変更の影響を確認しやすくなる。

たとえば、新しい機能を追加したいと思ったときに、

  • 要件定義書に追記が必要か

  • 画面仕様に影響するか

  • データ設計に影響するか

  • 管理者機能が必要か

  • テスト観点が増えるか

  • リリース範囲に入れるか

を確認できる。

これを頭の中だけでやると、ほぼ確実に漏れる。


5.4 リリース判断がしやすくなる

サービスを公開するタイミングでは、何をもって「公開可能」とするかが重要になる。

そのために、リリース判定チェックリストを作っている。

ここには、たとえば以下のような観点を入れる。

  • 主要導線が通っているか

  • 致命的なエラーがないか

  • ユーザーが迷わないか

  • スマホで最低限使えるか

  • データが破損しないか

  • 不具合報告導線があるか

  • 管理者が最低限対応できるか

  • 利用規約や注意事項が整っているか

リリース判断は感覚だけでやると危険である。

チェックリストがあることで、公開前に冷静に確認できる。


6. ドキュメント作りの問題点

ただし、ドキュメントを作ることには問題もある。

一番の問題は、作りすぎると実装が進まないことである。

実際、最近はドキュメント整理が増えすぎて、開発のスピードが落ちる懸念も出てきた。

ドキュメントは大事。
しかし、ドキュメントを書くだけではサービスは完成しない。

そのため、最近は以下のルールを意識している。

  • ドキュメント更新だけで作業を終わらせない

  • 実装に直結しない細かい表現修正は後回しにする

  • 同じ内容を複数ファイルに書きすぎない

  • 残課題は一箇所に集約する

  • 重要な判断だけを確実に残す

  • 実装完了後に必要最小限の更新をする

ドキュメントは必要だが、ドキュメント作成が目的化してはいけない。


7. 個人開発なのに、ここまでやる理由

正直、ここまでドキュメントを作る個人開発は少ないかもしれない。

ただ、自分としては必要だと感じている。

理由は、今回のプロジェクトが単純な小規模アプリではないからである。

機能が多く、運用もあり、ユーザー体験も重要で、将来的には収益化も考えている。
さらに、AIを使って開発を進めているため、AIに渡す前提情報も必要になる。

そして何より、月商1000万円を目指している。

月商1000万円を目指すなら、思いつきだけで進めるのは危険である。

もちろん、計画しすぎても動けなくなる。
だから、理想は以下である。

作りながら書く。書きながら作る。

計画だけでもダメ。
実装だけでもダメ。

両方を回しながら、サービスインに近づけていく。


8. 今後のドキュメント運用

今後は、ドキュメント運用も改善していく。

特に意識したいのは、以下である。

  1. ドキュメントの役割を明確にする

  2. 重複記載を減らす

  3. 残課題一覧を常に最新にする

  4. 後回し機能を定期的に棚卸しする

  5. リリース判定チェックリストを強化する

  6. テスト観点をフェーズ別に整理する

  7. AIに渡しやすい形式で書く

  8. 実装後の更新漏れを減らす

  9. ドキュメント更新だけで満足しない

  10. 最終的には運用・引き継ぎにも使える状態にする

特に、AIに渡しやすい形式にすることは、今後さらに重要になる。

AIを活用する開発では、ドキュメントの品質がそのまま開発効率に影響する。


9. 今回の結論

今回のプロジェクトでは、個人開発としてはかなりしっかりドキュメントを作っている。

企画概要、要件定義、機能仕様、画面仕様、データ設計、ロジック設計、API設計、管理者仕様、マニュアル、テスト観点、リリース判定、残課題、後回し機能、開発ルール。

こうしたドキュメントを整備しながら進めている。

これは遠回りに見えるかもしれない。

しかし、プロジェクトが大きくなるほど、ドキュメントがないことによる手戻りは大きくなる。

特に今回は、AIツールを活用している。
AIに正しく働いてもらうためにも、仕様や方針を残しておくことはかなり重要である。

ただし、ドキュメントだけで満足してはいけない。

最終的に必要なのは、動くサービスである。

だから今後も、
ドキュメントで整理し、実装で前に進める。
このバランスを取りながら進めていきたい。

月商1000万円までの道のりは、派手な機能や売上だけでなく、こうした地味な土台作りの積み重ねでもある。

第4回:現在の開発状況を整理する


1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発状況、進捗、課題、投資判断、スケジュールについては、できるだけ記録していく。

今回は、現時点の開発状況を整理する。

正直に言うと、当初想定していたよりも、作るべきものはかなり増えている。
最初は「まず最低限動くものを作る」というつもりだったが、考えれば考えるほど、サービスとして成立させるために必要な要素が見えてきた。

ただし、それは悪いことではない。

むしろ、プロジェクトの解像度が上がってきた結果だと思っている。


2. 現在の開発フェーズ

現時点では、まだ正式リリース前である。
外部ユーザーに広く公開する段階ではない。

現在の位置づけは、一人用確認版の完成に向けた開発フェーズである。

一人用確認版とは、自分自身がユーザーとして最初から最後まで触り、サービスの基本体験が成立しているかを確認するためのバージョンである。

ここで確認したいのは、主に以下である。

  • アカウント登録後の導線

  • 初回説明

  • メイン画面への遷移

  • 基本操作の流れ

  • データ作成・更新

  • 結果表示

  • 通知・履歴・ランキングなどの周辺要素

  • 自動進行または手動進行

  • スマホで最低限使えるか

  • 管理者が細かく操作しなくても流れが成立するか

つまり、今の目標は、完成品を作ることではない。
まずは、サービスの中心体験を自分で通し確認できる状態にすることだ。


3. 進捗感

現時点の進捗をかなり大まかに表現すると、以下のような感覚である。

区分進捗感
企画・構想整理かなり進んでいる
要件整理かなり増えてきたが、整理は進行中
基本設計骨格は見えてきている
実装一部進行中
一人用確認版まだ完成前
限定公開版これから
収益化まだこれから

数字で表すなら、現時点では以下のような感覚である。

到達目標現在地
一人用確認版約40〜50%
限定公開版約20〜30%
初期サービスイン約15〜25%
月商1000万円まだ入口

もちろん、この数字は厳密なものではない。
ただ、今の肌感覚としては、まだ「完成間近」ではない。

一方で、単なるアイデア段階はすでに抜けている。
構想、計画、ドキュメント、実装方針、開発体制はかなり具体化してきた。


4. 進んでいること

現在、特に進んでいるのは以下である。

4.1 プロジェクト計画の整理

まず、プロジェクト全体の計画をかなり整理している。

単に「作りたいものを作る」のではなく、以下のような観点で整理している。

  • 目的

  • スコープ

  • 開発フェーズ

  • 優先度

  • リスク

  • コスト

  • 品質

  • スケジュール

  • コミュニケーション

  • ドキュメント管理

  • リリース判断

個人開発ではあるが、かなりプロジェクト管理寄りに進めている。

これは少し重く見えるかもしれない。
ただ、今回の目標は月商1000万円である。

趣味の範囲で終わらせるつもりなら不要かもしれないが、事業として成立させるなら、最初からある程度の計画性は必要だと思っている。


4.2 ドキュメント整備

仕様書、設計書、残課題一覧、テスト観点、運用ルールなどのドキュメントも整備している。

ただし、ここは少し課題もある。

ドキュメントを作ること自体は重要だが、ドキュメント作成に時間を使いすぎると、実装が進まない。

最近は、以下の方針に切り替えている。

  • 実装に直結するドキュメントを優先する

  • 判断に迷いそうなことだけ記録する

  • 同じ内容を複数ファイルに重複させない

  • 後回し機能も放置せず、定期的に棚卸しする

  • ドキュメント更新だけで作業を終わらせない

ドキュメントは必要。
ただし、ドキュメントは目的ではなく、サービスインのための手段である。


4.3 画面イメージとデザイン検討

機能だけでなく、画面の見せ方も検討している。

ここでは、GensparkなどのAIツールも使っている。

開発初期は、どうしても機能中心で考えがちである。
しかし、ユーザーが触るサービスである以上、最終的には画面の分かりやすさ、雰囲気、導線、見た目の楽しさが重要になる。

現在は、主要画面について、どのような方向性にするかを少しずつ固めている。

ただし、デザインを作り込みすぎると、これもまたリリースが遠のく。

そのため、まずは以下を優先する。

  • ユーザーが迷わないこと

  • 主要導線が分かりやすいこと

  • サービスの世界観が少しでも伝わること

  • スマホで最低限使えること

  • 後から改善できる構造にすること

完璧なデザインは後でよい。
まずは、使える画面を作る。


5. 苦戦していること

順調に進んでいる部分もあるが、苦戦している部分も多い。

5.1 要件が増え続けている

一番大きいのは、要件が増え続けていることだ。

考えれば考えるほど、「これも必要」「これも入れたい」「これがないと体験が弱い」というものが出てくる。

これは、プロジェクトの可能性が広がっているという意味では良い。
ただし、すべてを初期リリースに入れようとすると、永遠に完成しない。

今後は、要件を以下のように分ける必要がある。

区分意味
P0一人用確認版に必須
P1限定公開までに必要
P2初期サービスイン後に強化
後回し記録するが今は実装しない

ただし、最近気づいたのは、後回しにしすぎると逆に効率が悪くなることもあるという点である。

本当は先に作った方が全体が整理される機能を後回しにすると、後からやり直しが発生する。
そのため、単純に「後でいい」と判断するのではなく、今作る方が後工程が楽になるかも見て判断する必要がある。


5.2 一人開発の判断負荷が大きい

このプロジェクトは、現時点では基本的に一人で進めている。

AIツールを活用しているとはいえ、最終判断は自分がする必要がある。

  • 何を優先するか

  • どこまで作るか

  • どこを後回しにするか

  • どのツールに課金するか

  • どの画面を先に作るか

  • どこで公開するか

  • どの段階でユーザーに見せるか

こうした判断が日々発生する。

一人開発の難しさは、作業量だけではない。
判断量が多いことだと思う。

そのため、ChatGPTを壁打ち相手として使い、判断や議事録を残すようにしている。


5.3 開発速度と費用のバランス

開発速度を上げるために、AIツールへの投資も増えてきた。

現在は、ChatGPT、Cursor、Gensparkなどを使っている。
さらに本日、開発用PCも購入した。

特にCursorについては、現在のプランでも使用量がかなり高くなっており、上位プランに上げるかどうかを検討している。

これは単なるツール課金の話ではなく、開発体制の問題である。

AIツールにお金を払えば、開発はかなり進みやすくなる。
一方で、まだ売上が立っていない段階で固定費を増やしすぎるのは怖い。

今後は、以下の考え方で判断したい。

  • サービスインが早まる投資か

  • 実装速度が上がるか

  • 判断や作業の詰まりが減るか

  • 1か月単位で効果を見直せるか

  • 惰性で継続していないか

費用は増えてきた。
ただし、ここで必要な投資をしないと、逆に完成が遠のく可能性もある。


6. 現在の優先事項

現時点で最優先すべきことは、以下である。

6.1 一人用確認版の完成条件を明確にする

まずは、一人用確認版で何ができれば完成なのかを明確にする。

これが曖昧なままだと、作業が広がり続ける。

完成条件としては、以下を想定している。

  • 新規ユーザーとして開始できる

  • 初回説明を受けられる

  • メイン画面に迷わず進める

  • 基本操作を一通り試せる

  • 結果や履歴を確認できる

  • 自動進行または手動進行ができる

  • 主要画面の最低限のデザインがある

  • スマホでも最低限確認できる

  • 致命的なエラーで止まらない

この条件を満たしたら、まずは一人用確認版として区切る。


6.2 P0機能に集中する

次に、P0機能に集中する。

今は魅力的な追加案が多い。
しかし、P0ではないものに時間を使いすぎると、一人用確認版が遠のく。

そのため、今後は毎回の作業で以下を確認する。

  • これは一人用確認版に必要か

  • 今やることで後工程が楽になるか

  • 後回しにしても破綻しないか

  • 実装コストに見合うか

  • ユーザー体験の核に関係するか

ここを基準にして、優先度を切る。


6.3 実装を止めない

最近は、仕様やドキュメントの整理が増えていた。

これは必要な作業ではあるが、実装が止まるとサービスインには近づかない。

そのため、今後はCursorへの指示でも、以下を強める。

  • ドキュメント更新だけで終わらない

  • 実装可能なものは実装する

  • 詰まったら別の実装可能タスクへ移る

  • 作業後に進捗率を報告する

  • 残課題を更新する

  • 次にやるべき実装を明示する

とにかく、サービスが動く方向に進める。


7. 現時点の課題一覧

現在見えている主な課題は以下である。

課題状況
要件が増え続けている優先度整理が必要
一人用確認版の完成条件明文化が必要
後回し機能の扱い棚卸しが必要
ドキュメント過多実装優先へ調整中
デザイン反映主要画面から順次対応
スマホ対応初期から考慮が必要
AIツール費用効果測定が必要
並行開発作業範囲の衝突回避ルールが必要
テスト最低限の通し確認が必要
サービスイン判断リリース基準の明確化が必要

こうして見ると、まだ課題は多い。

ただし、課題が見えていること自体は前進である。
問題は、課題を見ないふりして進めることだと思っている。


8. 次にやること

次にやるべきことは、かなり明確になってきた。

直近では、以下を進める。

  1. 一人用確認版の完成条件を確定する

  2. P0機能を再整理する

  3. 後回し機能を棚卸しする

  4. 主要画面の導線を確認する

  5. デザイン反映の優先順位を決める

  6. Cursorへの作業指示を明確化する

  7. PC2台体制での作業ルールを作る

  8. 開発費用と進捗率を定期的に記録する

  9. 実装を止めずに進める

  10. 一人用確認版の通し確認を目指す

特に重要なのは、一人用確認版を区切ることである。

この区切りがないと、いつまでも「まだ足りない」と感じてしまう。


9. 今回の結論

現在の開発状況は、まだ完成直前ではない。

しかし、単なるアイデア段階はすでに抜けている。

プロジェクト計画、要件整理、ドキュメント、開発体制、デザイン検討、AIツール活用、費用管理はかなり具体化してきた。

一方で、要件が増え続けていること、ドキュメント作業が増えていること、固定費が増えていること、一人で判断する負荷が大きいことは課題である。

現時点の最重要テーマは、明確である。

一人用確認版を完成させること。

まずは、自分自身が最初から最後まで触って、サービスの中心体験を確認できる状態にする。

そこから、限定公開、初期ユーザー獲得、収益化へ進める。

月商1000万円まではまだ遠い。
ただし、道筋は少しずつ見えてきた。

今は、壮大な目標を語るよりも、まず動くものを作る段階である。
そして、その過程を記録し続けることも、このプロジェクトの大事な一部だと思っている。

第3回:月商1000万円までのスケジュールを考える

月商1000万円までのスケジュールを考える

1. はじめに

月商1000万円を目指して、新規プロジェクトを進めている。

このブログでは、プロジェクトの具体的な企画内容は公開しない。
ただし、プロジェクトをどう進めているか、どこで悩んでいるか、どのように計画を立てているかは記録していく。

今回は、月商1000万円までのスケジュールについて整理する。

正直に言うと、現時点で完璧なスケジュールがあるわけではない。
要件は増えているし、作りたい機能も多い。
途中で「これは後回しにできない」と判断した機能も出てきている。

そのため、最初に立てた予定通りに一直線で進むというより、
ゴールを見失わないように、段階ごとに到達点を決めて進めることが重要になっている。


2. いきなり月商1000万円を目指さない

月商1000万円という目標は大きい。

ただし、最初から月商1000万円を前提にすべてを作り込もうとすると、いつまでもリリースできない。

そのため、現時点では以下のように段階を分けて考えている。

フェーズ目標
フェーズ1一人用確認版を完成させる
フェーズ2限定公開できる状態にする
フェーズ3初期ユーザーを獲得する
フェーズ4小さく課金・収益化を開始する
フェーズ5月商10万円を目指す
フェーズ6月商100万円を目指す
フェーズ7月商300万円を目指す
フェーズ8月商1000万円を目指す

今の最優先は、月商1000万円そのものではない。
まずは、サービスとして成立する体験を作ることである。


3. 現時点の最初のゴールは「一人用確認版」

まず目指しているのは、一人用確認版である。

これは、一般公開版ではない。
まだユーザーを集める段階でもない。

自分自身が一人のユーザーとして最初から最後まで触り、
「このサービスは本当に成立するのか」
「基本導線は破綻していないか」
「面白さや価値の核は感じられるか」
を確認するためのバージョンである。

一人用確認版で確認したいことは、主に以下である。

  • アカウント登録後の流れ

  • 初回説明やヘルプ導線

  • メイン画面への導線

  • 基本的な操作サイクル

  • データ作成・更新・履歴確認

  • 結果表示

  • ランキングや通知

  • 自動進行または手動進行

  • スマホでも最低限確認できること

この段階では、デザインが完璧である必要はない。
すべての機能が揃っている必要もない。

ただし、サービスの中心体験が確認できることは必須である。


4. 一人用確認版までのスケジュール感

現時点では、一人用確認版までは短期集中で進めたい。

大まかな感覚としては、以下のように考えている。

期間目標
今すぐ残課題と優先度の整理
直近1〜2週間一人用確認版に必要なP0機能を集中実装
その後通しプレイ・導線確認・不具合修正
次段階限定公開版に必要な機能整理

ただし、これはまだかなり粗い。

実際には、要件変更や追加機能があるため、予定通りには進まない可能性が高い。
特に、作ってみて初めて気づく不足機能がある。

そのため、日付だけで管理するよりも、
**「一人用確認版で何ができれば完了か」**を明確にすることを優先する。


5. サービスインまでの考え方

一人用確認版ができたら、次は限定公開版を目指す。

限定公開版では、自分以外の少人数に使ってもらうことを想定する。

この段階で必要になるのは、機能の多さではなく、最低限の安心感である。

  • 初回ユーザーが迷わない

  • 何をすればよいか分かる

  • データが壊れない

  • 不具合報告ができる

  • 運営側が最低限対応できる

  • スマホで確認できる

  • ヘルプやガイドがある

  • 途中で詰まっても復帰できる

ここまで来て、ようやく「外部の人に触ってもらえる」状態になる。

本格的なサービスインは、その後でよい。


6. 月商10万円まで

最初の収益目標は、月商1000万円ではなく、月商10万円にする。

なぜなら、月商0円から月商10万円にする過程には、重要な検証が詰まっているからである。

月商10万円を達成するには、以下が必要になる。

  • お金を払ってもらえる価値があること

  • 課金導線があること

  • 継続利用する理由があること

  • 初期ユーザーが離脱しないこと

  • サービス内容を説明できること

  • 運営側が最低限回せること

月商10万円は、金額としては大きくないかもしれない。
しかし、誰かが実際にお金を払うサービスになったという意味では、とても大きい。

ここを超えるまでは、派手な拡大よりも、サービス価値の検証を優先する。


7. 月商100万円まで

月商10万円を超えたら、次は月商100万円を目指す。

この段階では、単なる個人開発ではなく、少しずつ事業として考える必要が出てくる。

必要になるのは、以下である。

  • 継続率の確認

  • 課金率の改善

  • ユーザー獲得導線

  • SNSやブログでの発信

  • LPや説明資料の改善

  • サポート体制

  • 不具合対応の速度

  • 運用ルールの整備

月商100万円は、事業としての最初の大きな壁だと思っている。

ここに到達できれば、単なる趣味や実験ではなく、継続的に伸ばす価値のあるサービスとして見えてくる。


8. 月商300万円まで

月商300万円を目指す段階では、サービスの質だけでなく、運営体制が重要になる。

一人で全部を見るのは難しくなってくる可能性がある。

この段階で必要になるのは、以下である。

  • 自動化

  • 管理画面の強化

  • 問い合わせ対応の仕組み

  • 障害発生時の対応手順

  • ユーザーコミュニティの設計

  • 継続イベントやキャンペーン

  • コンテンツ更新の仕組み

  • データ分析

月商300万円は、個人開発から小さな事業へ移行するラインだと考えている。

ここまで来ると、機能追加だけでなく、
どう運営し続けるかが重要になる。


9. 月商1000万円まで

月商1000万円を達成するには、かなり高いレベルで複数の条件を満たす必要がある。

単にサービスを公開するだけでは難しい。

必要になるのは、以下のような要素だと思っている。

  • 強いコンセプト

  • 継続利用される仕組み

  • 課金したくなる理由

  • ユーザー同士の広がり

  • SNSで話題化する要素

  • リテンションの高さ

  • 運営イベント

  • コンテンツ更新

  • 安定したシステム

  • 問い合わせ・不具合対応

  • 広告または紹介導線

  • ブランドとしての認知

月商1000万円は、機能を作っただけでは届かない。
サービスとしての熱量、運営、コミュニティ、収益導線が必要になる。

だからこそ、今の段階では焦って売上だけを追うのではなく、
長く続けられる土台を作る必要がある。


10. 現時点のスケジュール案

現時点の大まかなスケジュールは以下である。

時期目標
現在一人用確認版に向けたP0機能の整理・実装
短期一人用確認版の通し確認
次段階限定公開版の準備
初期公開少人数ユーザーで検証
収益化初期月商10万円を目指す
成長初期月商100万円を目指す
拡大期月商300万円を目指す
本格成長期月商1000万円を目指す

このスケジュールは、まだ確定ではない。

むしろ、今後の進捗、開発速度、ユーザー反応、費用、AIツール活用状況によって変わっていく。

ただし、重要なのは、
今どの段階にいるのかを見失わないことである。


11. スケジュールを遅らせる要因

現時点で、スケジュールを遅らせる可能性がある要因も見えている。

主に以下である。

  • 要件追加が多い

  • 後回し機能を避けすぎると逆に非効率になる

  • ドキュメント更新に時間を使いすぎる

  • 実装範囲が広い

  • デザインも必要

  • スマホ対応も必要

  • テストや確認も必要

  • 一人で判断するため迷いが出る

  • AIツールの利用制限に引っかかる

特に、要件追加は大きい。

良いアイデアが出るほど、作りたいものは増える。
しかし、全部を初期リリースに入れると、いつまでも公開できない。

今後は、
作るべきもの、後でよいもの、今作ると効率が良いもの
を分けて判断していく必要がある。


12. スケジュールを早めるためにやること

逆に、スケジュールを早めるためにできることもある。

現時点では、以下を重視したい。

  1. 一人用確認版の完成条件を明確にする

  2. P0機能に集中する

  3. 実装可能な後回し機能は前倒しする

  4. ドキュメント更新だけで止まらない

  5. Cursorへの指示を具体化する

  6. ChatGPTで仕様・判断を整理する

  7. Gensparkでデザイン検討を効率化する

  8. PCを2台活用して作業を分散する

  9. 毎回、進捗率と残作業を確認する

  10. 迷ったら、サービスインに近づく選択を優先する

特に重要なのは、完成条件を明確にすることである。

何をもって一人用確認版完成とするのか。
何をもって限定公開可能とするのか。
何をもって収益化開始可能とするのか。

ここが曖昧だと、スケジュールは必ず伸びる。


13. 今回の結論

月商1000万円までのスケジュールは、まだ確定していない。

ただし、段階は見えてきた。

まずは、一人用確認版。
次に、限定公開版。
その後、初期ユーザー獲得。
そして、月商10万円、100万円、300万円、1000万円へ進む。

今はまだ、最初の山である。

しかし、ここで焦って雑に進めると、後で大きく崩れる。
一方で、考えすぎてリリースが遅れすぎても意味がない。

だから今後は、
計画しながら作る。作りながら計画を更新する。
この進め方を徹底したい。

月商1000万円までの道のりは長い。
ただし、最初に必要なのは壮大な売上計画ではなく、
まず動くものを作り、誰かに触ってもらえる状態にすることである。

次回以降は、一人用確認版の完成条件と、現在地の進捗率について整理していきたい。

第2回:ここまでにかかった費用を整理する

ここまでにかかった費用を整理する

Cursorの費用が、いよいよ経営判断になってきた



開発では、AIコーディングツールとしてCursorを使っている。

最初は最安プランから始めたが、開発量が増えるにつれて上位プランが必要になり、現在は Pro+ の月額$60プラン を利用している。

ただ、現時点で使用量を見ると、すでにかなり消費している。

現在の状況は以下の通り。

項目状況
現在のプランCursor Pro+
月額$60 / 月
使用量Total 82%
Auto + Composer83%
API80%
次回リセット5月25日
On-Demand UsageDisabled
アップグレード候補Ultra $200 / 月

まだリセットまで日数が残っている状態で、すでに使用量が80%を超えている。

これは、想定以上にCursorを使っているということでもある。
同時に、今の開発スタイルでは、$60プランだけでは足りなくなる可能性が高いということでもある。


$200プランに上げるかどうか

Cursorには、さらに上位の Ultra $200 / 月 がある。

画面上では、Ultraは現在のプランよりも大きな使用量上限があり、より本格的にAIコーディングを使うためのプランとして提示されている。

ここで悩んでいる。

月額$200は、個人開発の固定費としてはかなり重い。
日本円にすると、為替にもよるが毎月数万円規模になる。

ただし、現在の使い方を見る限り、Cursorは単なる補助ツールではなく、かなり開発の中心に近い存在になっている。

具体的には、以下のような作業をCursorに任せている。

  • 実装

  • 不具合修正

  • 既存コード調査

  • ドキュメント更新

  • 画面改善

  • テスト観点整理

  • デザイン反映

  • 作業結果の整理

  • commit / push 前の確認

つまり、Cursorはもはや「ちょっと便利なエディタ」ではなく、開発担当者に近い役割になっている。

そう考えると、$200プランは高いが、人件費と比べればかなり安い。
一方で、まだ売上が立っていない段階で固定費を増やす怖さもある。


現時点のAIツール月額費用

現時点で使っているAIツール費用を整理すると、以下になる。

現在の状態

ツール月額用途
Cursor Pro+$60実装・コード修正・調査
Genspark Plus$27.49デザイン案・LP・資料作成
ChatGPT月額課金企画整理・仕様整理・記事作成
合計$87.49 + ChatGPT分AI開発体制の基盤

CursorをUltraにした場合

ツール月額用途
Cursor Ultra$200実装・コード修正・調査
Genspark Plus$27.49デザイン案・LP・資料作成
ChatGPT月額課金企画整理・仕様整理・記事作成
合計$227.49 + ChatGPT分より本格的なAI開発体制

Cursorを$60から$200に上げる場合、差額は 月額+$140 になる。

この+$140をどう判断するかが、かなり重要になってきた。


判断基準

CursorをUltraに上げるかどうかは、感覚ではなく、以下の基準で判断したい。

  1. 使用量制限で開発が止まっているか

  2. $60プランのままだと作業速度が落ちるか

  3. Ultraにすることでサービスインが早まるか

  4. 1か月で差額$140以上の価値を生むか

  5. 上げた後に、実装量が明確に増えるか

特に重要なのは、サービスインが早まるかどうかである。

もしUltraにすることでサービスインが1週間でも2週間でも早まるなら、月額$200は十分に検討価値がある。

逆に、プランを上げても作業方針が曖昧なままで、実装が進まないなら意味がない。

つまり、上位プランにするなら、同時に以下も必要になる。

  • Cursorに渡す作業指示を明確にする

  • 作業範囲を区切る

  • 後回し機能と優先機能を整理する

  • 毎回、進捗率を報告させる

  • 実装完了条件を明確にする

  • ドキュメント更新だけで止まらないようにする

AIツールにお金を払うだけでは、プロジェクトは進まない。
AIに任せるための指示設計も含めて、開発体制を作る必要がある。


現時点の結論

Cursorについては、すでに$60プランでもかなり使い込んでいる。

使用量が80%を超えている以上、$200プランへのアップグレードは、単なる贅沢ではなく、現実的な選択肢になってきた。

ただし、すぐに継続前提で契約するのではなく、まずは以下の考え方にする。

Ultraに上げる場合は、1か月限定の開発加速期間として扱う。

この1か月で、以下を確認する。

  • 一人用確認版にどれだけ近づいたか

  • 実装完了機能がどれだけ増えたか

  • 不具合修正がどれだけ進んだか

  • 画面確認がどれだけ進んだか

  • サービスイン予定が前倒しになったか

効果があれば継続する。
効果が薄ければPro+に戻す。

固定費を増やすこと自体が目的ではない。
目的は、月商1000万円に向けて、サービスインまでの距離を縮めることである。



今回、Cursorの使用量を確認したところ、月額$60のPro+プランでもTotal 82%まで到達していた。まだリセットまで日数が残っていることを考えると、今の開発ペースでは上位プランの検討が現実味を帯びてきた。月額$200は重いが、サービスインを早めるための投資と考えれば、1か月だけ試す価値はあるかもしれない。

注目の投稿

第3回:月商1000万円までのスケジュールを考える

月商1000万円までのスケジュールを考える 1. はじめに 月商1000万円を目指して、新規プロジェクトを進めている。 このブログでは、プロジェクトの具体的な企画内容は公開しない。 ただし、プロジェクトをどう進めているか、どこで悩んでいるか、どのように計画を立てているかは記録して...