2026年5月1日金曜日

第27回:初回の利益回収まで、あとどれくらい遠いのか

 1. はじめに

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

ここまで、ChatGPT、Cursor、Genspark、新PC、Playwright、GitHub、二台体制などを使いながら開発を進めてきた。

そして最近、Cursor Ultraにも月額200ドルを支払った。



これで開発体制はかなり強化された。
BOSGAME P3 PLUSを開発専用機にし、Surfaceをテスト専用機にする分担も見えてきた。
Cursor Ultraにしたことで、使用量にも余裕ができた。

ただ、ここで改めて考えなければならないことがある。

初回の利益回収まで、あとどれくらい遠いのか。



開発は進んでいる。
一人用確認版も近づいている。
でも、品質には不安がある。
Cursorの報告では初期サービスイン79%という数字も出ているが、それをどこまで信用してよいのかも分からない。

今回は、現時点の投資額、今後かかるコスト、そして初回の利益回収までの距離を整理したい。


2. ここまでの累計投資額

まず、現時点で見えている累計投資額を整理する。

確定している円建ての支払いは以下である。

項目金額
BOSGAME P3 PLUS87,900円
ChatGPT Plus3,000円
円建て小計90,900円

次に、ドル建ての支払いである。

項目金額
Cursor 初期プラン$20
Cursor Pro+$60
Cursor Ultra$200
Genspark Plus$27.49
ドル建て小計$307.49

為替をざっくり1ドル150〜160円で見ると、ドル建て分は約46,000〜49,000円程度になる。

つまり、現時点の累計投資額は、概算で以下になる。

区分概算
円建て確定分90,900円
ドル建て円換算約46,000〜49,000円
累計投資額目安約137,000〜140,000円

現時点で、すでに約14万円前後を投資している。

まだ売上は立っていない。
つまり、現時点では完全に持ち出しである。


3. 今後の月額コスト

次に、今後の月額コストを見ておく。

Cursor Ultraを契約したことで、毎月の固定費は明確に重くなった。

項目月額
Cursor Ultra$200
Genspark Plus$27.49
ChatGPT Plus3,000円
合計$227.49 + 3,000円

ドル部分を1ドル150〜160円で見ると、$227.49は約34,000〜36,400円程度である。

そこにChatGPT Plusの3,000円を足すと、AIツール系だけで毎月おおよそ、

約37,000〜40,000円前後

かかる計算になる。

これはかなり大きい。

もちろん、Cursor Ultraは開発加速のために必要だと判断して払った。
ただし、毎月4万円近い固定費が発生するなら、利益回収までの距離を真剣に考える必要がある。


4. 初回の「利益回収」とは何か

ここで、利益回収という言葉を分けて考えたい。

利益回収には段階がある。

段階意味
初回売上初めて誰かがお金を払う
月額固定費の回収毎月のAIツール・運用費を売上でまかなえる
累計投資額の回収ここまで払った約14万円を回収できる
自分の稼働込みの回収自分の作業時間も含めて回収できる
生活改善レベル住宅ローンや生活費に効く
退職検討レベルサラリーマンを辞める選択肢が出る

現時点で目指すべき最初の回収ラインは、いきなり生活費や退職ではない。

まずは、

  1. 初回売上を立てる

  2. 月額固定費を回収する

  3. 累計投資額を回収する

この順番で考えるべきである。


5. いくら売れたら回収が始まるのか

一番最初の回収は、もちろん初回売上で始まる。

たとえば、500円でも1,000円でも、誰かが実際に支払えば、売上は立つ。

しかし、それはまだ「回収開始」であって、「回収完了」ではない。

現時点の累計投資額が約14万円前後だとすると、単純には以下のようになる。

売上規模意味
1,000円初回売上。需要の最初の証明
1万円支払う人が複数いる可能性が見える
5万円月額固定費の一部をまかなえる
10万円月額固定費をかなり吸収できる
15万円累計投資額の回収ラインに近づく
30万円初期投資回収後の再投資が見える
50万円クラファン・限定公開・外注検討が現実的になる
100万円事業として本格的に考える段階

つまり、現時点の支払いだけを見るなら、15万円前後の売上で初期投資の回収ラインに近づく。

ただし、実際には手数料、税金、追加費用、今後の月額固定費がある。
そのため、感覚としては、

まずは月商10万円で固定費を吸収し、累計30万円前後で初期投資の回収感が出てくる

くらいに見た方が現実的だと思う。


6. 本当の損益分岐点はもっと遠い

ただし、これはあくまで「現金で払った費用」だけを見た場合である。

本当は、自分の稼働コストがある。

通勤中、犬の散歩中、トレーニング中にChatGPTと壁打ちしている。
夜にCursorへ指示している。
休日に画面を確認している。
ブログを書いている。
仕様を考えている。
課題を棚卸ししている。

この時間をすべて金額換算したら、投資額は14万円どころではない。

ただ、今は趣味として楽しい部分もある。
だから、自分の稼働を最初から厳密に人件費計上する必要はないと思っている。

しかし、将来的に事業として見るなら、自分の時間もコストである。

現金支出の回収ラインは15万円〜30万円。
自分の稼働込みの本当の回収ラインは、もっと先。

ここは冷静に見なければならない。


7. Cursorの進捗報告はどこまで信用できるのか

今回、Cursorからは以下のような報告が出ている。

  • 初期サービスインを100%とした現在地:約79%

  • 正式サービスインを100%とした現在地:約33%

  • 初期サービスインまで数日〜1週間弱

  • 今回の作業で初期サービスイン +1pt

一見すると、かなり進んでいるように見える。

しかし、ここは慎重に見たい。

今回の実装内容は、管理画面の共通ナビに /help へのリンクを追加したことが中心である。
もちろん、これは意味のある改善である。
管理者がヘルプへ戻りやすくなるのは、初期サービスイン時の確認や運用に役立つ。

ただ、それだけで初期サービスインが79%と言われると、少し違和感もある。

なぜなら、別途一人用確認版を触ったときには、デザイン品質・機能品質にかなり不安があったからである。

つまり、Cursorの進捗率は、以下のように見るべきだと思う。

実装タスク消化率としては参考になる。
しかし、ユーザー体験品質やサービスとしての完成度をそのまま表しているわけではない。


8. 79%という数字は楽観的かもしれない

初期サービスイン79%という数字は、作業管理上の目安としては使える。

しかし、それをそのまま信じて「もうすぐ公開できる」と考えるのは危険である。

理由は以下である。

  • Surfaceの実機UIテスト報告が未記入テンプレだった

  • 実際のP0/P1指摘がまだ十分に上がっていない

  • 一人用確認では品質がかなり低く見えた

  • smoke testは3本だけで、広い品質保証ではない

  • レース詳細・ダッシュボードなど主要画面の改善が残っている

  • one-player regressionの証跡もまだ次作業に残っている

  • デザイン品質・体験品質はE2Eだけでは測れない

つまり、79%という数字は、コードとチェックの進捗としては参考になるが、サービスイン品質としてはかなり割り引いて見るべきである。

自分の感覚としては、初期サービスインまで本当に近いかどうかは、まだ見えない。

前倒しで行ける可能性はある。
ただし、品質改善が想定より重ければ、簡単には行けない。


9. 前倒しで行ける可能性はあるのか

前倒しで行ける可能性はある。

理由はある。

  • BOSを開発専用機にした

  • Surfaceをテスト専用機に分けた

  • Cursor Ultraで使用量に余裕ができた

  • ChatGPTで指示文と課題整理ができる

  • Playwright E2Eがすでにある

  • GitHub連携で状況把握ができる

  • 一人用確認で品質課題が見えた

体制としては、かなり強くなっている。

ただし、前倒しで行くには条件がある。

それは、新機能追加ではなく、品質改善に集中することである。

今やるべきことは、機能を増やすことではない。

  • 主要画面を見やすくする

  • 初回導線を分かりやすくする

  • 機能詳細・ダッシュボードを改善する

  • 空データ・エラー表示を統一する

  • Surfaceで本当にテストを実施する

  • スマホ・タブレット表示を確認する

  • one-player regressionを通す

  • 人が触って不安にならない状態にする

これが進めば、前倒しはあり得る。

逆に、Surfaceがまたテンプレだけ作る、Cursorが小さなナビ改善だけを積み重ねる、品質改善が進まない、という状態なら前倒しは難しい。


10. 初回売上までの現実的な距離

では、初回売上まではどれくらいか。

現時点では、まだ近いとは言い切れない。

理由は、売上を立てるには「使える」だけでなく「払いたい」と思ってもらう必要があるからである。

最低限必要なのは以下である。

  • 一人用確認版が成立する

  • 見せられる画面がある

  • 何が面白いか伝わる

  • 初回体験が分かりやすい

  • 不安になる品質ではない

  • 支援・課金・クラファンの導線がある

  • できること/できないことが明確

  • 現金換金性がないことなど注意事項が整理されている

この状態になって、ようやくクラウドファンディングや先行支援、限定参加などを考えられる。

初回売上だけなら、小規模クラウドファンディングや支援枠で早めに作れる可能性はある。
ただし、品質が低いままだと逆効果になる。

だから、利益回収の第一歩は、まず品質改善である。


11. 現時点の回収シナリオ

現実的には、以下のような段階で考えたい。

段階目標意味
Step 1一人用確認版の品質改善自分が触って納得できる
Step 2見せ場画面を作る外部に説明できる
Step 3小規模支援・クラファン準備初期ファンを集める
Step 4初回売上需要の最初の証明
Step 5月商5万円AIツール費用の一部回収
Step 6月商10万円月額固定費の回収感が出る
Step 7累計30万円初期投資の回収感が出る
Step 8月商100万円本格事業化の検討
Step 9月商1000万円最終目標

今すぐ月商1000万円を考えるより、まずは初回売上。
そして月商5万円、10万円。
そこから累計投資回収。

この順番で見る方が現実的だと思う。


12. 今回の結論

現時点での累計投資額は、概算で約14万円前後
さらに、Cursor Ultra、Genspark、ChatGPTにより、今後は毎月約37,000〜40,000円前後の固定費が発生する見込みである。

つまり、初回の利益回収までの距離は、確実に意識しなければならない段階に入った。

単純な現金支出だけなら、15万円〜30万円程度の売上で初期投資回収の感覚が出てくる。
ただし、自分の稼働コスト、税金、手数料、今後の追加費用を考えると、本当の回収ラインはもっと先である。

Cursorは初期サービスイン79%と報告している。
しかし、それをそのまま信用するのは危険である。

実装タスクとしては進んでいる。
でも、品質はまだ不安がある。
Surfaceのテストもまだ十分に機能していない。
一人用確認では、デザイン品質・機能品質の低さが見えている。

前倒しで行ける可能性はある。
ただし、それは品質改善に集中できた場合だけである。

今やるべきことは明確である。

機能追加より、品質改善。
進捗率より、実際に触ったときの納得感。
売上計画より、まず人に見せられる状態。

初回の利益回収は、まだ遠い。
でも、道筋は見えてきた。

まずは、一人用確認版を「動く」から「見せられる」に引き上げる。
そこから、小さな支援、初回売上、月額固定費回収へ進む。

月商1000万円までの道のりは長い。
ただ、その前にまず回収すべき最初の壁が見えてきた。
約14万円の初期投資と、毎月4万円弱の固定費。

これをどう回収するか。

ここからは、開発だけでなく、事業としての現実も見ながら進めていく必要がある。

第26回:テスト専用機のはずのSurfaceが、なかなかテストしてくれなかった話


1. はじめに

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

ここ最近、開発体制をかなり見直している。

BOSGAME P3 PLUSを開発専用機にする。
Surfaceをテスト専用機にする。
ChatGPTで方針や指示を整理する。
Cursorで実装を進める。
GitHubで状態を管理する。
PlaywrightでE2Eテストも回す。

この体制がうまく回れば、一人開発でありながら、かなり本格的な開発・テスト分業に近づけるのではないかと考えていた。

しかし、実際にやってみると、そう簡単ではなかった。

特に苦労したのが、Surface側のテスト実施である。

Surfaceをテスト専用機として使いたかったのに、なかなか実際のテストをしてくれない。
テストをしてほしいのに、なぜかファイル作成やドキュメント整備ばかりしてしまう。
こちらの意図と違う方向に進んでしまう。

これは、かなり苦労した。


2. Surfaceに期待していた役割

Surfaceに期待していた役割は明確だった。

Surfaceには、開発ではなく、確認・テスト・指摘をしてほしかった。

具体的には、以下のような役割である。

  • GitHubから最新状態を取得する

  • 実際に画面を開いて確認する

  • UIの崩れを見る

  • ユーザー目線で分かりにくい箇所を指摘する

  • PlaywrightなどのE2Eテストを実行する

  • 手動確認観点を消化する

  • スクリーンショットを撮る

  • 結果を報告する

  • BOSGAME側へ修正指示を渡す

つまり、Surfaceは「作る側」ではなく「見る側」である。

BOSGAMEが開発担当。
Surfaceがテスト担当。
Surfaceの指摘を受けて、BOSGAMEが直す。

この分担にしたかった。


3. 実際には、ファイル作成ばかりしてしまった

しかし、実際にSurface側へ指示を出してみると、期待通りにはいかなかった。

テストをしてほしい。
画面を見てほしい。
実際に動かしてほしい。
UI観点で確認してほしい。

そう依頼しているつもりだった。

ところが、Surface側はなぜか、

  • テスト報告書のひな形を作る

  • チェックリストのスケルトンを作る

  • ドキュメントの行を追加する

  • 運用ルールに追記する

  • 報告ファイルを作る

  • まだ実施していない確認結果の枠を用意する

といった方向に進んでしまった。

もちろん、ドキュメント自体は重要である。
報告書も必要である。
チェックリストも必要である。

しかし、今回やってほしかったのは、そこではなかった。

まず実際にテストしてほしかった。


4. 「テスト準備」と「テスト実施」は違う

今回の苦労で、改めて感じたことがある。

それは、テスト準備とテスト実施はまったく違うということだ。

テスト準備とは、たとえば以下である。

  • チェックリストを作る

  • 報告書のフォーマットを作る

  • テスト観点を整理する

  • 結果記入欄を作る

  • ドキュメント構成を整える

これは重要である。

しかし、これだけでは品質は上がらない。

本当に必要なのは、その後のテスト実施である。

  • 実際に画面を開く

  • ボタンを押す

  • 導線を確認する

  • 表示崩れを見る

  • エラーが出るか確認する

  • スマホ幅で見る

  • ユーザー目線で違和感を拾う

  • スクリーンショットを残す

  • 再現手順を書く

  • 改善指示につなげる

この実作業がないと、テストをしたことにはならない。

Surface側では、この「準備」と「実施」の区別がうまく伝わっていなかった。


5. AIは「それっぽい成果物」を作るのがうまい

今回かなり感じたのは、AIは「それっぽい成果物」を作るのがうまいということだ。

たとえば、テスト報告書のフォーマットを作る。
チェックリストを作る。
ドキュメントに項目を追加する。
作業したように見える文章を書く。

これは得意である。

しかし、それだけでは実際のテストにはならない。

怖いのは、ファイルが増えると、何か進んだように見えてしまうことである。

報告書ができた。
チェックリストができた。
ドキュメントが更新された。
GitHubにcommitされた。

これだけ見ると、作業したように見える。

しかし、中身を見ると、実際の画面確認はされていない。
スクリーンショットもない。
操作結果もない。
不具合の再現確認もない。
UIの実機確認もない。

これでは、品質改善にはつながらない。


6. こちらの指示にも問題があった

ただし、これはSurface側だけが悪いという話ではない。

こちらの指示にも問題があったと思っている。

「テストしてほしい」と言ったときに、AI側はそれを広く解釈する。

テスト準備もテストの一部。
テスト観点整理もテストの一部。
報告書作成もテスト作業の一部。

そう解釈されてしまった。

だから、今後はもっと明確に言う必要がある。

たとえば、

新しいMarkdownファイルを作らない。
チェックリストのひな形を作らない。
まず実際にアプリを起動する。
ブラウザで画面を開く。
指定画面を操作する。
スクリーンショットを撮る。
実際の確認結果だけを書く。
未確認の項目を確認済みのように書かない。

ここまで言わないと、AIは「安全で形にしやすい作業」に逃げる可能性がある。

つまり、AIにテストをさせるには、作業の成果物ではなく、実施行為を明確に定義する必要がある


7. 「ファイルを作るな」と明示する必要があった

今回、かなり強く感じたのは、AIには「何をするか」だけでなく、何をしないかも明示する必要があるということだ。

Surface側には、かなり明確に言う必要があった。

  • 新規の指示書Markdownを作らない

  • スケルトンだけの報告書を作らない

  • 実施していないテスト結果を書かない

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

  • 既存ルールの追記で満足しない

  • テスト未実施のままcommitしない

  • まずアプリを起動して実画面を確認する

これを明示しないと、AIはドキュメント作成に流れてしまう。

ドキュメント作成は、AIにとってやりやすい。
コードを動かすより安全に見える。
実機確認より失敗しにくい。
報告としても形にしやすい。

だからこそ、人間側が「今回の目的はテスト実施である」と強く縛る必要がある。


8. テスト専用機に必要なのは、確認結果である

Surfaceをテスト専用機にするなら、最終成果物はドキュメントの数ではない。

必要なのは、確認結果である。

たとえば、以下のようなものである。

必要な成果内容
実行環境どのブランチ・どのcommitを確認したか
起動確認アプリが起動したか
画面確認どの画面を見たか
操作結果何を押して、何が起きたか
スクリーンショット実際の画面証跡
不具合何が問題か
再現手順どうすれば再現するか
重要度P0/P1/P2など
BOS向け指示何を直すべきか

これがなければ、テスト専用機として働いたとは言いにくい。

単に「テスト報告書.md」を作っただけでは意味がない。
中身に実施結果が必要である。


9. 二台体制の難しさ

BOSGAMEとSurfaceの二台体制は、かなり期待している。

ただ、今回の件で、二台体制には運用設計が必要だと痛感した。

BOSGAMEは開発専用機。
Surfaceはテスト専用機。

この分担自体は良い。

しかし、Surfaceがテストではなくファイル作成に流れてしまうと、役割分担が崩れる。

BOSGAMEは実装を進める。
Surfaceはテストの準備だけする。
実際の確認はされない。

これでは、BOSGAME側の開発が品質改善につながりにくい。

二台体制を成立させるには、Surface側の仕事をもっと具体化する必要がある。


10. 今後のSurface向け指示は変える

今後、Surface側には、繰り返し使える強い指示が必要だと思っている。

方針としては、以下である。

Surfaceへの基本指示

  • あなたは開発担当ではなく、テスト担当である

  • 新規機能の実装はしない

  • 新規の指示書Markdownを増やさない

  • まずGitHubから最新を取得する

  • アプリを実際に起動する

  • ブラウザで実画面を確認する

  • 指定された画面を操作する

  • スクリーンショットを保存する

  • 確認結果を docs/surface-output/ に残す

  • BOSGAMEがそのまま修正できる粒度で指摘する

禁止事項

  • テスト未実施の報告書作成

  • スケルトンだけのファイル作成

  • 確認していない項目を確認済みにすること

  • ドキュメント更新だけで終了すること

  • 実装作業に入ること

  • 作業範囲外のファイルを触ること

これくらい明確にする必要がある。


11. Surface側の報告フォーマットも固定したい

Surface側の報告は、以下のような形に固定したい。

## Surface実機テスト結果

### 確認対象
- branch:
- commit:
- URL:
- 実行日時:

### 実施した確認
- 画面A:
- 画面B:
- 操作:

### 証跡
- screenshot:
- 動画:
- ログ:

### 発見した問題
- 問題ID:
- 画面:
- 内容:
- 再現手順:
- 重要度:
- BOSGAME向け修正指示:

### 確認できなかったこと
- 理由:
- 次回確認事項:

こうしておけば、報告が空っぽになりにくい。

「確認したこと」と「確認できなかったこと」を分ける。
「実施したこと」と「これからやるべきこと」を分ける。
「感想」ではなく「修正指示」まで落とす。

これが必要である。


12. 今回の苦労から得た教訓

今回のSurface問題から得た教訓は大きい。

12.1 AIには役割定義が必要

開発担当なのか、テスト担当なのか、PMOなのか。
役割を曖昧にすると、AIはやりやすい作業に流れる。

12.2 成果物ではなく行動を指定する必要がある

「報告書を作る」ではなく、
「実際に画面を開いて確認する」ことが必要。

12.3 禁止事項を書く必要がある

AIには、やってほしくないことも明確に書く。
特に、ファイル作成だけで終わることは禁止する必要がある。

12.4 テストは証跡が重要

スクリーンショット、URL、commit、操作結果、再現手順。
これがないと、テストとして弱い。

12.5 二台体制は運用がすべて

PCが2台あるだけでは効率化しない。
役割、ルール、報告、連携が必要である。


13. 今回の結論

Surfaceをテスト専用機にしようとしたが、最初はかなり苦労した。

こちらはテストをしてほしかった。
しかし、Surface側はファイル作成やドキュメント整備に流れてしまった。

テスト報告書のひな形を作る。
チェックリストを作る。
ドキュメントに追記する。
しかし、実際の画面確認は十分に進まない。

これはかなりつらかった。

ただし、この苦労で分かったこともある。

AIに仕事をさせるには、役割定義が必要である。
開発担当とテスト担当を明確に分ける必要がある。
「何をするか」だけでなく「何をしないか」も書く必要がある。
テストでは、ファイル作成ではなく、実施結果と証跡が必要である。

今後は、Surfaceには徹底してテスト担当として動いてもらう。

BOSGAMEが作る。
Surfaceが実際に触る。
Surfaceが証跡付きで指摘する。
BOSGAMEが直す。

このループを作る。

今回の苦労は大きかったが、二台開発体制を本当に機能させるために必要な失敗だったと思う。

AI活用は、ツールを増やせば勝手にうまくいくわけではない。
AIにも、役割、作業範囲、禁止事項、成果物の定義が必要である。

Surfaceがようやく本当の意味でテスト専用機として働けるようになるか。
ここが、次の開発効率化の大きなポイントになる。

第25回:BOSは開発専用機、Surfaceはテスト専用機へ。ようやく分担が見えてきた

1. はじめに

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

ここまで、新PCの導入、Cursor Ultraへのアップグレード、PlaywrightによるE2Eテスト、ChatGPTとの壁打ち、GitHub連携などを使いながら開発を進めてきた。

そして最近、ようやくPC2台体制の使い方が見えてきた。

結論から言うと、
BOSGAME P3 PLUSを開発専用機、Surfaceをテスト専用機として分担させる形が一番分かりやすい

以前は、両方のPCに開発をやらせることも考えていた。

しかし、実際に進めてみると、両方で開発すると連携に無駄が出る。
どちらがどのファイルを触っているのか、どのブランチで作業しているのか、どちらの変更が最新なのか、確認コストが増える。

その結果、2台あるのに、かえって管理が難しくなる可能性があった。

そこで、役割を分けることにした。


2. BOSは開発専用機

BOSGAME P3 PLUSは、開発専用機として使う。

役割はかなり明確である。

  • Cursorで実装する

  • コードを修正する

  • 新機能を追加する

  • UIを改善する

  • E2Eテストを追加する

  • lint / format / build を実行する

  • commit / push まで行う

  • mainやfeatureブランチの作業を進める

つまり、BOSは作る側である。

新PCを買った目的は、まさにここにある。

実装、ビルド、E2E、commit / pushまでを安定して回す。
開発作業を止めない。
Cursorを本格的に使う。

この役割にBOSを集中させることで、かなり分かりやすくなった。


3. Surfaceはテスト専用機

一方で、Surfaceはテスト専用機に寄せる。

Surfaceでは、BOSが実装したものを確認する。

役割としては、以下である。

  • GitHubから最新を取得する

  • mainまたは指定ブランチを確認する

  • UI観点で画面を見る

  • Playwrightや手動確認を行う

  • スマホ・タブレットに近い見え方を確認する

  • Surface側の確認結果をドキュメント化する

  • BOS向けの次回指示を作る

  • docs/surface-output/ に確認結果や改善指示を置く

つまり、Surfaceは見る側・試す側・指摘する側である。

この分担にすると、非常に分かりやすい。

BOSが作る。
Surfaceが見る。
Surfaceが指摘する。
BOSが直す。

この流れにできれば、開発とテストが自然に分かれる。


4. 両方に開発をやらせると無駄があった

最初は、BOSもSurfaceも両方開発に使えば、単純に2倍速くなるのではないかと思っていた。

しかし、実際にはそう単純ではなかった。

両方で開発すると、以下の問題が出る。

  • 同じファイルを触るリスクがある

  • ブランチ管理が複雑になる

  • どちらの作業が最新か分かりにくい

  • pull / rebase / merge の確認が増える

  • 作業宣言が重くなる

  • Git競合のリスクが高まる

  • 片方の成果をもう片方が把握するまでに時間がかかる

  • 結局、連携確認に時間を使う

つまり、2台で同時に開発すると、開発速度が上がるどころか、調整コストが増える可能性がある。

特に今は、まだ一人用確認版の品質改善が重要な時期である。
この段階でGit競合やブランチ混乱に時間を使うのは避けたい。

だから、役割を分ける方がよい。


5. 開発とテストを分けると、確認観点も整理される

BOSを開発専用、Surfaceをテスト専用にすると、確認観点も整理しやすい。

BOS側では、実装者目線になりやすい。

  • コードが通るか

  • buildが成功するか

  • E2Eが通るか

  • エラーが消えたか

  • commitできるか

これは重要である。

しかし、ユーザー目線とは少し違う。

Surface側では、実装者ではなく確認者として見る。

  • 画面が分かりやすいか

  • デザインがひどくないか

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

  • ボタンの位置は自然か

  • 文言は分かりやすいか

  • スマホやタブレットで見づらくないか

  • 一人用確認版として触れるか

  • 人に見せられる品質に近づいているか

この分担はかなり重要である。

最近、一人用確認版を見て、デザイン品質・機能品質の低さにかなり不安を感じた。
だからこそ、Surface側でユーザー目線・テスト目線の確認を強める必要がある。


6. Cursor Ultraにしたことで、開発側の余力は増えた

さらに、CursorはUltraにアップグレードした。



現在のプランは、Cursor Ultra $200/月

使用量はリセットされ、現在は以下のような状態になっている。

項目状況
プランCursor Ultra
月額$200/月
次回リセット5月31日
Total使用量1%
Auto + Composer1%
API0%
API枠少なくとも$400分含む

これまでのPro+では、Total 90%以上、API 100%まで到達していた。
そこからUltraに上げたことで、かなり余裕が出た。

これは大きい。

今後は、Cursorの使用量制限を気にしすぎず、BOS側で開発・修正・品質改善を進めやすくなる。

ただし、Ultraにしたからといって、無駄に使ってよいわけではない。

月額200ドルを払っている以上、成果に変えなければならない。


7. Ultraでやるべきことは、機能追加より品質改善

今の最重要課題は、単なる機能追加ではない。

一人用確認版を実際に見た結果、品質への不安が大きくなった。

  • デザイン品質が低い

  • 機能品質が弱い

  • 画面のつながりが悪い

  • 初回体験が弱い

  • 人に見せるにはまだ怖い

  • E2Eが通っていても体験品質が足りない

だから、Cursor Ultraでやるべきことは、機能をむやみに増やすことではない。

むしろ、以下を優先したい。

  • 主要画面のUI改善

  • 一人用確認版の通し導線整理

  • 空データ・エラー表示の統一

  • スマホ・タブレット表示改善

  • 操作後のフィードバック改善

  • 人に見せられる画面の品質向上

  • Surface指摘の反映

  • E2Eと手動確認の組み合わせ

  • P0残課題の集中消化

Ultraは、量を増やすためだけではなく、品質を上げるために使う

ここを間違えないようにしたい。


8. 自動実行で分業できる期待

今後は、BOSとSurfaceの両方で、ある程度自動実行させることを考えている。

BOS側では、開発タスクを連続的に実行する。

  • 実装

  • 修正

  • E2E追加

  • build確認

  • commit / push

  • 作業報告

Surface側では、テスト・確認タスクを連続的に実行する。

  • 最新取得

  • 画面確認

  • UI観点チェック

  • E2Eまたは手動確認

  • 不具合・改善点整理

  • BOS向け指示作成

  • docs/surface-output/ への保存

この形がうまく回れば、かなり効率が上がる可能性がある。

BOSが作っている間に、Surfaceが確認する。
Surfaceが指摘をまとめている間に、BOSが次の実装を進める。
SurfaceのアウトプットをBOSが次回優先して読む。

このループができれば、かなり開発体制らしくなる。


9. 今後の理想フロー

理想としては、以下の流れで進めたい。

  1. ChatGPTで方針・課題・指示文を整理する

  2. BOSに実装指示を出す

  3. BOSがCursorで実装・E2E・build・commit / pushを行う

  4. Surfaceが最新を取得してテスト・UI確認を行う

  5. Surfaceが確認結果を docs/surface-output/ にまとめる

  6. BOSがSurfaceの指摘を読み、次の修正に入る

  7. ChatGPTで進捗・課題・記事化を行う

この流れが定着すれば、かなり強い。

一人で進めているが、実質的には、

  • ChatGPT:PMO・壁打ち・議事録

  • BOS + Cursor:開発担当

  • Surface:テスト担当

  • GitHub:状態管理

  • Playwright:自動確認

という体制に近づく。

これは、AI時代の個人開発としてかなり面白い形だと思っている。


10. 懸念もある

もちろん、懸念もある。

BOSとSurfaceで分担したからといって、すべてが解決するわけではない。

主な懸念は以下である。

懸念内容
Surface側の確認品質テスト専用機として十分な観点で見られるか
指摘の粒度BOSが実装しやすい形で指摘できるか
docs/surface-output運用確認結果を安定して保存・参照できるか
Git運用最新取得・ブランチ確認を徹底できるか
Cursor Ultraの浪費使用量が増えても成果につながらないリスク
品質改善の優先度新機能追加に流れてしまうリスク
自動実行の停止AIが途中で止まり、人間の確認待ちになるリスク

特に重要なのは、Surface側のアウトプット品質である。

「見た」だけでは意味がない。
BOSがそのまま修正に入れるように、具体的な指摘として残す必要がある。


11. 一人用確認版への影響

この分担がうまく回れば、一人用確認版への到達はかなり現実的になる。

これまでの見立てでは、一人用確認版の到達度はおおよそ50%前後。
ただし、実際に触ってみると品質面に大きな不安が出た。

つまり、今後の進捗は単純な機能実装率ではなく、品質改善率で見る必要がある。

BOSを開発専用、Surfaceをテスト専用にすることで、以下が期待できる。

  • 品質指摘が増える

  • UI改善の優先度が上がる

  • 通し導線の不具合に気づきやすくなる

  • スマホ・タブレット観点を拾いやすくなる

  • E2Eだけでは拾えない違和感を拾える

  • 開発と確認のループが早くなる

これにより、一人用確認版の完成時期は少し現実的になる。

ただし、品質が想定より低かったため、楽観はできない。

5月中の一人用確認版を目指す方針は維持したいが、
「動く」ではなく「触って次に進める品質」 を基準に見直す必要がある。


12. 今回の結論

BOSを開発専用機、Surfaceをテスト専用機に分けることで、ようやく2台体制の使い方が見えてきた。

両方に開発をやらせると、連携に無駄が出る。
ブランチ管理やファイル競合、作業範囲の確認に時間を取られる。

それよりも、役割を分けた方がよい。

  • BOSは作る

  • Surfaceは見る

  • Surfaceが指摘する

  • BOSが直す

この形が分かりやすい。

さらに、Cursor Ultra $200/月にアップグレードしたことで、BOS側の開発余力は大きく増えた。
現在の使用量はTotal 1%、Auto + Composer 1%、API 0%。
これまでの制限ギリギリの状態から、一気に余裕ができた。

ただし、重要なのはここからである。

Ultraにしたからといって、無駄に機能を増やしてはいけない。
今やるべきことは、品質改善である。

一人用確認版を確認して、デザイン品質・機能品質に不安が出た。
だからこそ、BOSとSurfaceの分担を活かして、開発とテストのループを早く回す。

この体制がうまく回れば、かなり効率化できるはずである。

ようやく、AIと複数PCを使った個人開発体制が形になり始めた。

ここからは、投資した分を成果に変えるフェーズである。

第24回:ここまでの累計投資額を整理する

1. はじめに

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

ここまで、ChatGPT、Cursor、Genspark、新PC、GitHub、E2Eテスト、ドキュメント整備などを使いながら開発を進めてきた。

前回は、Cursor Ultraに月額200ドルを払ったことを書いた。

今回は、月額費用ではなく、ここまでの累計投資額を整理する。

毎月いくらかかるかも重要だが、今の段階で知りたいのは、
結局、ここまでこのプロジェクトにいくら突っ込んだのか
ということだ。


2. 累計投資額として見る理由

これまでは、月額費用として整理していた。

  • ChatGPT Plus:3,000円/月

  • Genspark:$27.49/月

  • Cursor:$20 → $60 → $200

  • Cursor Ultra:$200/月

  • 開発用PC:87,900円

月額で見ると、それぞれの負担感は分かる。

ただ、プロジェクトとして本当に見たいのは、月額だけではない。

重要なのは、売上が立つ前に、どれだけ投資しているかである。

月商1000万円を目指すなら、投資は必要である。
しかし、支出を把握しないまま進むのは危険である。

そのため、今回は「累計投資額」として整理する。


3. 現時点で確認できている支払い

現時点で分かっている支払いは以下である。

区分項目金額状態
一時費用BOSGAME P3 PLUS87,900円支払い済み
AIツールChatGPT Plus3,000円支払い対象
AIツールGenspark Plus$27.49支払い対象
AIツールCursor 初期プラン$20支払い済み想定
AIツールCursor Pro+$60支払い済み想定
AIツールCursor Ultra$200支払い済み
合計円建て確定分90,900円PC + ChatGPT
合計ドル建て分$307.49Cursor + Genspark

ここで注意したいのは、Cursorの$20と$60については、実際の請求履歴で日割り調整やクレジット調整が入っている可能性がある点である。

ただ、自分の認識としては、$20 → $60 → $200 と段階的に支払いが発生している。

そのため、現時点の累計投資額としては、いったんこの前提で整理する。


4. 円建てで確定している投資額

まず、円建てで分かっている金額は以下である。

項目金額
BOSGAME P3 PLUS87,900円
ChatGPT Plus3,000円
円建て小計90,900円

開発用PCだけで87,900円。
さらに、ChatGPT Plusが3,000円。

この時点で、円建てだけでも 90,900円 を投資している。

PCは一時費用だが、かなり大きい。
ただし、新PC導入後は実装、E2E、build、commit / pushの流れがかなり回しやすくなった。

その意味では、87,900円は単なるガジェット購入ではなく、開発体制への投資である。


5. ドル建てで発生している投資額

次に、ドル建てで発生している費用を整理する。

項目金額
Cursor 初期プラン$20
Cursor Pro+$60
Cursor Ultra$200
Genspark Plus$27.49
ドル建て小計$307.49

ドル建てでは、現時点で $307.49 が発生している計算になる。

このうち、Cursor Ultraの$200がかなり大きい。

Cursorについては、最初は$20から始めた。
その後、開発量が増えて$60のPro+に上げた。
そして、使用量が限界に近づき、最終的に$200のUltraを契約した。

ここまで来ると、Cursorは単なる補助ツールではなく、実装担当に近い存在になっている。


6. 円換算するとどれくらいか

ドル建て分は、為替レートやカード手数料によって最終的な円請求額が変わる。

そのため、正確にはカード明細で確認する必要がある。

ただし、ざっくり感を見るために、仮に1ドル150円〜155円で計算すると、以下のようになる。

前提レートドル建て分 $307.49 の円換算
1ドル150円約46,124円
1ドル155円約47,661円

これを円建て確定分90,900円に足すと、以下になる。

前提レート累計投資額の目安
1ドル150円約137,024円
1ドル155円約138,561円

つまり、現時点での累計投資額は、ざっくり 13.7万円〜13.9万円程度 になっている可能性がある。

ただし、これはあくまで概算である。

実際には、Cursorのアップグレード時の調整、カード会社の為替レート、手数料、Gensparkの円請求額によって変わる。


7. 累計投資額として見ると、かなり現実味が出る

月額で見ると、ひとつひとつは判断しやすい。

ChatGPT Plusの3,000円は、かなり使っているので納得感がある。
Gensparkの$27.49も、デザインや資料作成に使うなら許容範囲に見える。
Cursorの$60も、実装が進むなら必要経費だと思える。
Cursor Ultraの$200も、開発加速として考えれば検討できる。
PCの87,900円も、開発効率が上がるなら投資だと思える。

しかし、累計で見ると印象が変わる。

すでに 13万円台後半 くらいは投資している可能性がある。

これは、もはや「無料で気軽に試している個人開発」ではない。

まだ売上は立っていない。
それでも、すでにお金を使っている。

この現実は、ちゃんと見ておく必要がある。


8. この投資は無駄なのか

では、この累計投資は無駄なのか。

現時点では、そうは思っていない。

それぞれの支出には役割がある。

投資役割
BOSGAME P3 PLUS実装・E2E・build・二台開発の効率化
ChatGPT Plus企画整理、議事録、記事化、Cursor指示文作成
Cursor実装、調査、不具合修正、E2E、docs更新
Gensparkデザイン案、LP案、外向け表現の検討
Cursor Ultra開発速度維持、制限回避、品質改善の加速

特に、新PCとCursor Ultraは、ここからの品質改善に効いてくるはずである。

一人用確認版を触ってみて、デザイン品質や機能品質にかなり不安が出た。
だからこそ、ここからは機能追加よりも品質改善が重要になる。

Cursor Ultraを使って、主要画面のUI改善、導線整理、スマホ対応、E2E整備を進める必要がある。


9. ただし、投資した以上は成果が必要

投資したこと自体に満足してはいけない。

PCを買った。
Cursor Ultraにした。
ChatGPTを使っている。
Gensparkも使っている。

それだけでは意味がない。

重要なのは、この投資によって何が進んだかである。

見るべき成果は、以下である。

  • 一人用確認版に近づいたか

  • デザイン品質が上がったか

  • 機能品質が上がったか

  • E2Eテストが強化されたか

  • 開発速度が上がったか

  • 待ち時間や制限が減ったか

  • 人に見せられる画面が増えたか

  • クラウドファンディングに向けた見せ場が作れたか

  • 初期サービスインの見通しが良くなったか

累計投資額を整理する理由は、節約するためだけではない。

投資に対して成果が出ているかを見るためである。


10. 今後さらに増える可能性がある費用

現時点で13万円台後半程度の投資になっている可能性があるが、今後さらに費用は増える。

想定されるのは以下である。

  • Cursor Ultraの継続

  • Gensparkの継続

  • ChatGPT Plusの継続

  • サーバー・DB費用

  • ドメイン費用

  • 素材制作費

  • LP・動画制作費

  • クラウドファンディング準備費

  • デザイン改善費

  • 税理士相談費

  • 外注費

特に、今後クラウドファンディングを検討するなら、見せ場となる画面、動画、LP、説明画像が必要になる。

つまり、開発費用だけでなく、見せ方の費用も発生する可能性がある。


11. 現時点の累計投資額まとめ

現時点の累計投資額をまとめると、以下である。

種別金額
円建て確定分90,900円
ドル建て分$307.49
ドル建て円換算目安約46,124円〜47,661円
累計投資額目安約137,024円〜138,561円

つまり、現時点では、概算で 約14万円弱 を投資している。

まだ売上はゼロである。

しかし、ここまで投資したからには、何としても形にしたい。


12. 今回の結論

ここまでの累計投資額を整理すると、プロジェクトはすでにかなり現実味を帯びてきた。

PC代、ChatGPT、Cursor、Genspark。
そしてCursor Ultra。

すべてを合わせると、現時点で 約14万円弱 の投資になっている可能性がある。

これは小さくない。

ただし、月商1000万円を目指すなら、この程度の投資で怖がってばかりもいられない。

問題は、投資額そのものではない。

問題は、その投資によって、どれだけ前に進めるかである。

今後は、月額費用だけでなく、累計投資額を定期的に記録する。

そして、そのたびに確認する。

この投資は、一人用確認版に近づいているか。
この投資は、品質改善につながっているか。
この投資は、初期サービスインを早めているか。
この投資は、月商1000万円への道を開いているか。

まだ売上はない。
しかし、投資は始まっている。

だからこそ、ここからは成果で返していく。

まずは、一人用確認版の品質改善。
次に、限定公開。
そして、初期サービスイン。

累計投資額をただの支出で終わらせない。
月商1000万円に向けた、最初の本気の投資として回収していく。

第23回:Cursor Ultraに月額200ドルを払った


1. はじめに

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

ここまで、ChatGPT、Cursor、Genspark、新PC、PlaywrightによるE2E、GitHub連携などを使いながら開発を進めてきた。

そして今回、ついに Cursor Ultra を契約した。

金額は、月額200ドル

正直、軽い金額ではない。

個人開発で、まだ売上が立っていない段階で、月額200ドルの開発ツールに課金する。
日本円にすると為替次第では毎月数万円になる。

それでも、今の開発状況を考えると、ここで開発速度を落とす方がリスクだと判断した。


2. Cursor Ultraの支払い内容

今回契約したのは、Cursor Ultra

支払い画面では、以下のように表示されていた。



項目内容
プランCursor Ultra
月額$200.00 / 月
請求1か月ごと
小計$200.00
税金$0.00
今日期日の合計額$200.00

年次払いにすれば月額換算で $160/月 になり、年間 $480 節約できる表示もあった。
ただし、今回は月額契約にした。

理由は、まだ効果測定の段階だからである。

いきなり年額で固定するのではなく、まずは1か月使って、どれだけ開発速度が上がるかを見る。


3. なぜ払ったのか

一番大きい理由は、現在のCursor利用量が限界に近かったからである。

これまで使っていたPro+では、すでに使用量がかなり高くなっていた。

開発では、Cursorを単なる補助ツールではなく、かなり本格的な実装担当として使っている。

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

  • 実装

  • 既存コード調査

  • 不具合修正

  • UI改善

  • E2Eテスト追加

  • 回帰テスト更新

  • ドキュメント更新

  • README更新

  • lint / format / build確認

  • commit / push前の整理

  • 作業報告

ここまで任せていると、使用量が増えるのは当然である。

そして今は、一人用確認版に近づいている重要なタイミングである。
ここでCursorの制限に引っかかって作業が止まるのは避けたい。

だから、月額200ドルを払ってでも、開発速度を維持する判断をした。


4. これは贅沢ではなく、開発加速投資

月額200ドルという数字だけ見ると高い。

ただ、自分の中ではこれは贅沢ではなく、開発加速投資である。

もし人に実装を依頼すれば、数万円どころでは済まない。
1画面、1機能、1修正だけでも外注すればかなりの費用がかかる。

それに対して、Cursor Ultraによって、

  • 実装待ちが減る

  • 制限を気にせず作業できる

  • E2Eまで含めて依頼しやすくなる

  • 1セッションあたりの作業量が増える

  • 一人用確認版への到達が早まる

のであれば、月額200ドルは投資として成立する可能性がある。

もちろん、払っただけで成功するわけではない。

Cursorに何を依頼するか。
どこまで任せるか。
どう確認するか。
どの作業を優先するか。

そこを間違えれば、200ドルを払っても無駄になる。


5. 今の課題は、機能追加より品質改善

ちょうど最近、一人用確認版を確認して、品質面にかなり不安を感じた。

デザイン品質が低い。
機能品質も弱い。
画面のつながりもまだ不十分。
E2Eが通っていても、ユーザー体験としてはまだ見せられる状態ではない。

この状況で必要なのは、単純な機能追加ではない。

必要なのは、品質改善である。

Cursor Ultraを契約したからといって、むやみに機能を増やしてはいけない。

むしろ、今後は以下に使うべきだと思っている。

  • 主要画面のUI改善

  • 初回導線の整理

  • 空データ・エラー表示の統一

  • スマホ表示の改善

  • 一人用通し確認の障害除去

  • E2Eの品質向上

  • 残課題のP0整理

  • 既存実装の見直し

  • 見せ場となる画面の改善

Ultraの価値は、作業量を増やすことだけではない。

人に見せられる品質へ近づけることに使わなければ意味がない。


6. 費用整理上の影響

これで、現時点の開発費用はさらに増えた。

確定している支払いとしては、以下になる。

項目金額状態
BOSGAME P3 PLUS87,900円購入済み
ChatGPT Plus3,000円/月契約中
Genspark Plus$27.49/月契約中
Cursor Pro+$60/月利用済み
Cursor Ultra$200/月契約済み

Cursorについては、これまで $20 → $60 → $200 という流れで上げてきた。
実際の過去請求については明細確認が必要だが、少なくとも今回から Cursor Ultra $200/月 は実支払いとして発生する。

これはかなり大きい。

月商1000万円を目指すとはいえ、まだ売上がない段階での固定費増加である。

だからこそ、効果測定が必要になる。


7. 1か月で何を見るか

今回のCursor Ultra契約は、まず1か月の開発加速期間として見る。

この1か月で確認したいのは、以下である。

確認項目見たいこと
一人用確認版到達時期が早まったか
品質改善デザイン・機能品質が上がったか
実装量1セッションあたりの作業量が増えたか
E2E回帰テストや主要導線の確認が増えたか
待ち時間制限による停止が減ったか
精神面制限を気にせず開発できたか
費用対効果月額200ドルに見合う成果があったか

特に重要なのは、一人用確認版の品質である。

単に「たくさん実装した」では足りない。

実際に触って、
「これなら次の段階に進める」
と思える状態に近づいたかどうかを見る。


8. 年額ではなく月額にした理由

支払い画面では、年次払いにすれば $480 節約できる表示があった。

月額換算では $160/月。

かなり魅力的ではある。

ただ、今回は月額にした。

理由は、まだこの投資がどれだけ効くか分からないからである。

Cursor Ultraが本当に開発速度を上げるのか。
一人用確認版の品質改善に直結するのか。
自分の運用スタイルに合うのか。
月額200ドルを払う価値があるのか。

これは1か月使ってみないと分からない。

効果が明確なら、継続する。
必要であれば年額も検討する。
効果が薄ければ、戻す。

まずは実験である。


9. 今回の結論

Cursor Ultraに、月額200ドルを払った。

これは、個人開発としてはかなり大きな判断である。

ただ、今は一人用確認版が近づいている重要な時期であり、同時に品質の低さにも不安が出てきている。

ここで開発速度を落とすより、1か月だけでも開発加速に投資する方がよいと判断した。

ただし、払っただけでは意味がない。

Cursor Ultraは、魔法ではない。
使い方を間違えれば、ただ固定費が増えるだけである。

この1か月でやるべきことは明確である。

  • 機能を増やしすぎない

  • 品質改善に集中する

  • 一人用確認版の通し体験を整える

  • 主要画面を人に見せられる水準へ近づける

  • E2Eと人手確認を組み合わせる

  • 残課題をP0中心に整理する

  • 5月中の一人用確認版到達を現実にする

月額200ドルを払った以上、成果を出す。

これは支出ではある。
しかし、月商1000万円へ向けた開発投資でもある。

ここから1か月、Cursor Ultraを使って、どこまで品質を引き上げられるか。

かなり重要な勝負期間に入った。

第22回:一人用確認版を見て、正直かなり不安になった


1. はじめに

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

ここまで、AI活用、開発用PCの導入、Cursorによる実装、PlaywrightによるE2Eテスト、ドキュメント整備、クラウドファンディング構想などについて書いてきた。

そして最近、一人用確認版にかなり近づいてきたと感じていた。

進捗率としても、だいたい50%前後まで来ているという見立てをしていた。
E2Eテストも増えてきた。
新PCによって開発効率も上がってきた。
実装、テスト、commit、pushの流れも回るようになってきた。

しかし、実際に一人用確認版として触ってみると、正直かなり厳しかった。

デザイン品質が低い。
機能品質も低い。
画面のつながりも弱い。
使っていて楽しい以前に、触っていて不安になる部分が多い。

これは、かなり心配になってきた。


2. 「動く」と「使える」はまったく違う

今回、改めて痛感したのは、動くことと、使えることは違うということだ。

E2Eテストが通る。
buildが通る。
lintが通る。
画面が表示される。
ボタンを押せる。
データが保存される。

これらはもちろん重要である。

しかし、それだけではサービスとして成立しない。

実際に触ってみると、

  • 何をすればいいか分かりにくい

  • 画面が見づらい

  • 情報の優先順位が分からない

  • デザインに統一感がない

  • 操作していて気持ちよくない

  • 画面ごとの品質差が大きい

  • 一人用の体験としてつながっていない

  • そもそも楽しいと感じる前に不安になる

という問題が見えてきた。

これはかなり大きい。

コード上は動いていても、ユーザー体験としてはまだ弱い。
むしろ弱いどころか、このままでは人に見せるのが怖いレベルかもしれない。


3. デザイン品質への不安

特に気になったのは、デザイン品質である。

今回のプロジェクトでは、世界観や体験をかなり重視している。
ただ機能を並べるだけではなく、ユーザーがその世界に入り込み、継続して触りたくなるようなサービスにしたい。

しかし、現時点の一人用確認版を見ると、そこまで到達していない。

画面として最低限表示されているだけで、体験としての魅力が弱い。
UIとしても、情報設計としても、見せ方としても、かなり改善が必要だと感じた。

特に問題なのは、デザインの荒さが、そのままサービスの信頼感を下げてしまうことである。

ユーザーは中身のロジックまでは見ない。
最初に見るのは画面である。

画面が雑だと、
「本当にこのサービスは大丈夫なのか」
「ちゃんと作られているのか」
「続けても意味があるのか」
と感じてしまう。

これは、かなり危険である。


4. 機能品質への不安

デザインだけでなく、機能品質にも不安がある。

個別には実装されている機能がある。
テストが通っている部分もある。
ドキュメント上では仕様も整理されている。

しかし、実際に一人用として触ると、機能が自然につながっていない。

たとえば、一般論として、確認版では以下が重要になる。

  • 最初に何をすればよいか分かる

  • 次の操作が自然に提示される

  • 画面遷移に迷わない

  • データがない時も意味が分かる

  • エラー時も不安にならない

  • 主要な体験が一連の流れになっている

  • 管理者操作なしでも最低限進行できる

  • 結果や履歴が納得感を持って表示される

ここが弱いと、一人用確認版としても成立しにくい。

今の状態は、部品は増えてきたが、体験としてまだつながりきっていない印象がある。

これは、単なるバグ修正だけでは解決しない。
画面導線、UX、機能の優先順位、初回体験を見直す必要がある。


5. E2Eテストがあっても安心できない理由

PlaywrightによるE2Eテストはすでに使っている。
これは大きな前進である。

ただし、今回の確認で分かったのは、E2Eテストが通っても、サービス品質が高いとは限らないということだ。

E2Eテストは、以下の確認には強い。

  • 画面が落ちない

  • ボタンが押せる

  • 遷移できる

  • 要素が表示される

  • データの基本的な保存・表示ができる

  • 空データやエラー状態が最低限表示される

しかし、以下はE2Eでは判断しにくい。

  • 画面が魅力的か

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

  • 触っていて楽しいか

  • 世界観が伝わるか

  • 説明が自然か

  • 情報量が適切か

  • 継続したくなるか

  • 人に見せたい品質か

つまり、E2Eは必要だが、それだけでは足りない。

今回の問題は、テスト不足だけではなく、UX品質・デザイン品質・体験品質の不足である。


6. 進捗率の見方を修正する必要がある

これまで、一人用確認版への到達度を48〜55%程度と見ていた。

しかし、実際に触った印象を踏まえると、この数字は少し楽観的だったかもしれない。

実装量としては50%前後でも、体験品質としてはもっと低い可能性がある。

ここは、見方を分ける必要がある。

観点現在地の見方
実装部品の量ある程度進んでいる
E2E・回帰確認積み上がってきている
ドキュメント整備かなり進んでいる
一人用体験のつながりまだ弱い
デザイン品質かなり改善が必要
人に見せられる品質まだ不安
限定公開の準備まだ早い

つまり、単純に「何%できた」と言うのが難しくなってきた。

実装進捗と体験品質は別物である。

ここを分けて見ないと、判断を誤る。


7. クラウドファンディングどころではない可能性

最近、クラウドファンディングの活用も考え始めていた。

一人用確認版、レトロ風の演出、初期ファン集め、テスター募集。
うまく使えば、かなり意味があると考えていた。

しかし、現時点の品質を見ると、クラウドファンディングを急ぐのは危険かもしれない。

クラウドファンディングでは、支援者に見せる画面や動画が必要になる。
「これは面白そう」と思ってもらえる見せ場が必要になる。
少なくとも、信頼できる開発状況に見える必要がある。

今のデザイン品質・機能品質のまま出すと、逆に不安を与える可能性がある。

つまり、クラウドファンディングはまだ可能性として残すが、タイミングは慎重に見直すべきである。

まずは、一人用確認版の品質を引き上げる。
その後に、見せられる画面と動画を作る。
クラウドファンディングはその後でよい。


8. 今の課題は「機能追加」ではなく「品質改善」

ここで重要なのは、次に何をするかである。

今の状態で、さらに新機能を足しても、問題は解決しない可能性が高い。

むしろ、画面や導線がさらに複雑になり、品質が悪化するかもしれない。

今必要なのは、機能追加よりも品質改善である。

特に優先すべきは以下だと思う。

  1. 初回導線の整理

  2. 主要画面のデザイン改善

  3. 一人用での通し導線の整理

  4. 空データ・エラー表示の統一

  5. 操作後のフィードバック改善

  6. スマホ表示の確認

  7. 画面ごとの情報優先度の整理

  8. 見せ場となる画面の品質向上

  9. E2Eでは拾えない人手確認項目の追加

  10. 一人用確認版の合格基準の見直し

これは、かなり重要な方針転換である。

「作る」から「整える」へ。
「機能を増やす」から「体験を成立させる」へ。

ここに切り替えないと、人に見せられる状態にはならない。


9. AI開発の弱点も見えてきた

今回の品質問題は、AI開発の弱点でもあると思っている。

Cursorはかなり実装してくれる。
ChatGPTは仕様や指示文を作ってくれる。
E2Eテストも追加できる。
ドキュメントも整備できる。

しかし、AIに任せると、部品単位では進む一方で、全体体験が弱くなることがある。

画面はある。
機能もある。
テストもある。
でも、実際に触ると微妙。

これは、AIに任せる範囲と、人間が見るべき範囲を改めて考える必要があるということだ。

AIには実装を任せられる。
しかし、体験品質の最終判断は人間がしなければならない。

特に、今回のようなサービスでは、ユーザーがどう感じるかが重要である。

そこは、AI任せにしてはいけない。


10. 不安になったことは悪いことではない

一人用確認版を見て不安になった。

これは正直、しんどい。

ここまでかなり時間もお金も使っている。
PCも買った。
Cursorにも課金している。
ChatGPTも使っている。
Gensparkも使っている。
ドキュメントもかなり作っている。
E2Eも増やしている。

それでも、実際に触った品質が低いと、かなり不安になる。

しかし、不安になったこと自体は悪いことではない。

むしろ、この段階で気づけてよかった。

もしこの品質のまま限定公開やクラウドファンディングに進んでいたら、もっと危なかった。

今ならまだ直せる。
今ならまだ方向転換できる。
今ならまだ、一人用確認版の品質基準を見直せる。

これは痛いが、必要な気づきだと思う。


11. 今後の対応方針

現時点での対応方針は以下である。

11.1 一人用確認版の合格基準を見直す

単に画面が動くことを合格にしない。

以下も見る。

  • 初回ユーザーとして迷わないか

  • 画面が最低限見やすいか

  • 主要導線が自然につながっているか

  • エラーや空データ時に不安にならないか

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

  • 触っていて続きを見たいと思えるか

11.2 デザイン改善をP0に近づける

これまでデザイン改善は後回しにしがちだった。

しかし、現時点の品質を見ると、主要画面のデザイン改善はP0に近い。

少なくとも、一人用確認版で触る主要画面については、最低限の見栄えと情報設計が必要である。

11.3 通しプレイ観点で確認する

画面単位ではなく、ユーザー体験単位で確認する。

  • 開始する

  • 説明を見る

  • 主要操作を行う

  • 結果を見る

  • 次に何をするか分かる

  • 履歴や状態を確認する

この流れで見る。

11.4 機能追加を一時的に絞る

新機能を増やす前に、既存部分の品質を上げる。

特に、人に見せる可能性がある画面、クラウドファンディング用の見せ場になる画面は優先的に整える。

11.5 AIへの指示を品質改善型に変える

Cursorへの指示も、単なる実装追加ではなく、品質改善に寄せる。

  • UI/UX改善

  • 画面導線整理

  • 空データ表示統一

  • スマホ表示改善

  • 操作フィードバック追加

  • 一人用通し確認の障害除去

こうした指示に切り替える必要がある。


12. 現時点の結論

一人用確認版を確認して、正直かなり不安になった。

デザイン品質が低い。
機能品質も低い。
画面のつながりも弱い。
サービスとしての魅力がまだ伝わらない。

これは厳しい現実である。

ただし、ここで気づけたのは大きい。

今の段階で必要なのは、さらに機能を増やすことではない。
一人用確認版として、人間が触って「最低限成立している」と思える品質まで引き上げることである。

E2Eが通っているから安心、ではない。
buildが通っているから完成、でもない。
ドキュメントがあるから品質が高い、でもない。

実際に触って、分かりやすく、破綻せず、少しでも面白さが伝わること。
そこまで持っていく必要がある。

月商1000万円を目指すなら、ここは避けて通れない。

今回の確認は、かなり苦い。
しかし、必要な現実確認だった。

ここからは、機能追加ではなく、品質改善に本気で向き合う。

一人用確認版は近づいていると思っていた。
しかし、本当に必要なのは、単に「一人で動かせる状態」ではなく、
一人で触って、これなら次に進めると思える状態である。

そこまで引き上げる。
ここが、次の大きな課題である。

第21回:クラウドファンディングを活用できないか考え始めた


1. はじめに

独力+AI活用で月商1億円を目指している。

ここまで、ChatGPT、Cursor、Genspark、新PC、GitHub、自動テスト、ドキュメント整備などを活用しながら、新規Webサービスの開発を進めてきた。

開発は少しずつ進んでいる。
一方で、費用も確実に増えている。

開発用PCを購入した。
ChatGPT Plusを使っている。
Cursorも上位プランへ上げた。
Gensparkも利用している。
今後は、サーバー費用、素材制作費、UI改善費、テスト環境費、外部向けページ制作費なども必要になる可能性がある。

そこで、少し考え始めたことがある。

クラウドファンディングを活用できないか。

これは単なる資金調達の話ではない。

初期ユーザー、応援者、テスター、発信協力者を集める手段として、クラウドファンディングを使えないかという話である。


2. クラウドファンディングは選択肢になるのか

結論から言うと、クラウドファンディングは検討する価値があると思っている。

ただし、やるなら慎重に設計する必要がある。

特に重要なのは、寄付型や投資型ではなく、購入型に寄せることである。

支援してくれた人に対して、金銭的なリターンを返すのではなく、先行利用権、支援者向け特典、クレジット掲載、限定レポート、開発状況の共有などを提供する形が現実的だと考えている。

逆に、以下のような打ち出し方はしない。

  • 売上を分配する

  • 利益を分配する

  • 配当を出す

  • 元本を返す

  • 投資家として参加してもらう

  • 将来の収益を約束する

このプロジェクトは、あくまでWebサービス開発である。
クラウドファンディングを使う場合も、支援者には金銭的リターンではなく、サービス利用や開発参加感に近いリターンを提供する形にしたい。


3. 目的はお金だけではない

クラウドファンディングというと、まず資金調達をイメージする。

もちろん、資金面の意味は大きい。

たとえば、以下のような費用に充てられる可能性がある。

  • UI改善

  • ビジュアル素材制作

  • 外部向けページ制作

  • 紹介動画制作

  • テスト環境整備

  • サーバー・DB・ドメイン関連費用

  • 説明資料の整備

  • 初期利用者向けサポート体制

ただ、それ以上に重要なのは、初期ファンを集めることだと思っている。

支援してくれる人は、単なる利用者ではない。
開発段階から応援してくれる人である。

まだ完成していない段階で関心を持ってくれる人。
先行して触ってくれる人。
分かりにくい点を教えてくれる人。
改善案をくれる人。
周囲に紹介してくれる人。

そういう人たちと早い段階で出会えることは、資金以上に価値があるかもしれない。

クラウドファンディングは、資金調達であり、需要検証であり、初期コミュニティ作りでもある。


4. いきなり大きく狙いすぎない

もしクラウドファンディングを行うなら、最初から大きく狙いすぎない方がよいと思っている。

いきなり数百万円規模を目指すと、準備も重くなる。
リターン設計も大変になる。
達成できなかった場合の見え方も悪い。
支援後の対応負荷も大きくなる。

そのため、最初は小さく試すのが現実的だと思う。

たとえば、第1弾は 30万〜100万円程度 の小規模な挑戦にする。

目的は、巨大な資金調達ではない。

  • コンセプトが伝わるか

  • 支援してくれる人がいるか

  • どのリターンに反応があるか

  • 外部向け説明が分かりやすいか

  • 先行利用者が集まるか

  • SNSで反応があるか

これを確認する。

第1弾で反応があれば、第2弾として、より大きな開発費・改善費・運用費を集めることも考えられる。

まずは、小さく出して反応を見る。
これが現実的だと思っている。


5. 第1弾の目標金額イメージ

第1弾をやるなら、目標金額は 50万円前後 が現実的ではないかと考えている。

まだ仮ではあるが、使い道のイメージは以下である。

用途金額目安
ビジュアル素材・UI素材制作15万円
サーバー・DB・ドメイン・検証費5万円
自動テスト・開発環境強化5万円
初期確認版のUI改善10万円
外部向けページ・説明画像・紹介動画制作10万円
手数料・予備費5万円

もちろん、クラウドファンディングでは手数料がかかる。
集まった金額がそのまま使えるわけではない。
また、税金やリターン提供にかかる費用も考える必要がある。

そのため、50万円を集めたとしても、実際に自由に使える金額はそれより少なくなる。

ここは、実施前に必ず最新の手数料や規約を確認する。


6. リターン案

リターンは、慎重に設計する必要がある。

現時点で考えられる案は以下である。

支援額リターン案
1,000円開発応援、支援者限定レポート
3,000円先行利用権、支援者向け特典
5,000円初期確認版の先行利用枠、クレジット掲載
10,000円支援者向け特典、プロフィール装飾、開発レポート
30,000円サービス内名称・記念掲載枠の候補採用権
50,000円コンテンツ名称候補の優先採用、支援者紹介枠
100,000円創設支援者枠、記念ページ掲載、特別クレジット

ここで重要なのは、金銭的なリターンにしないことである。

支援に対して、売上分配、利益分配、配当、元本返還などは行わない。
また、換金性を想起させるリターンも避ける。

リターンはあくまで、先行利用、記念掲載、支援者向け特典、開発レポート、クレジット掲載などに寄せる。


7. 外部向けの訴求軸

クラウドファンディングで重要なのは、単に「Webサービスを作っています」と言うことではない。

なぜ作るのか。
何が新しいのか。
なぜ支援してほしいのか。
支援者は何に参加できるのか。

ここを伝える必要がある。

現時点で考えている訴求軸は、以下である。

昔、自分が本当に楽しいと思った体験を、現代のWebサービスとして再構築したい。
単なる便利ツールではなく、ユーザーが継続して関わり、自分なりの記録や体験を積み重ねられるサービスを作りたい。
AIを活用しながら、独力でどこまで大きなサービスを作れるのかに挑戦している。
その最初の支援者、先行利用者、開発過程を一緒に見守ってくれる人を集めたい。

これは、ただの資金募集ではない。

一緒に初期サービスを育ててくれる人を集めるという打ち出し方がよいと思っている。


8. 必ず明記すべき注意事項

クラウドファンディングを行うなら、誤解を避けるための注意事項はかなり重要である。

公開ページには、少なくとも以下のような説明を入れる必要がある。

本プロジェクトは、実在の人物・団体・サービス・取引を対象にしたものではありません。
サービス内で扱う内容は、すべて独自に設計されたコンテンツです。

支援に対して、売上分配、利益分配、配当、元本返還などの金銭的リターンは行いません。

また、サービス内の表示・特典・ポイント等は、現金、暗号資産、電子マネー等へ換金できません。

リターンは、先行利用権、支援者向け特典、クレジット掲載、開発レポート等の購入型リターンとして設計します。

本サービスは現在開発中であり、仕様、提供時期、画面構成、機能内容は変更される可能性があります。

これはかなり重要である。

支援者に期待を持ってもらうことは大事だが、過度な期待を持たせてはいけない。

できること。
まだできないこと。
変更される可能性があること。
金銭的リターンではないこと。

ここは明確に書く必要がある。


9. いつ実施するべきか

クラウドファンディングは、今すぐ公開するより、もう少し見せられる状態になってからの方がよい。

現時点では、まだ品質に不安がある。

一人用の確認では、デザイン品質や機能品質に課題が見えている。
この状態のまま外に出すと、支援どころか不安を与えてしまう可能性がある。

そのため、クラウドファンディングを実施するなら、最低限以下が必要だと思っている。

  • 初期確認版の主要導線が通る

  • 外部向けに見せられる画面がある

  • 何が面白いのか説明できる

  • 30〜90秒程度の紹介動画がある

  • 支援金の使い道が明確である

  • リターン内容が現実的である

  • 提供時期とリスクを説明できる

  • できること/まだできないことを明記できる

つまり、文章だけで出すのではなく、一定の画面・動画・説明資料が必要である。


10. 想定スケジュール

現時点で考えるなら、以下のような流れが現実的だと思っている。

時期内容
2026年5月前半初期確認版の主要導線と見せ場を整える
2026年5月中旬クラウドファンディング本文・リターン・FAQ案を作る
2026年5月下旬外部向けページ・説明画像・紹介動画を準備する
2026年6月小規模クラウドファンディングを検討する
2026年6月以降支援者向け先行利用・限定レポートを開始する
2026年7〜8月初期公開へ接続する

ただし、これはかなり攻めたスケジュールである。

品質改善が想定より重ければ、後ろ倒しにする。
無理に早く公開して、信頼を落とす方が危険である。


11. リスク

クラウドファンディングにはメリットだけでなく、リスクもある。

リスク内容
支援が集まらない需要が弱いように見えてしまう
準備が重い本文、画像、動画、FAQ、リターン設計が必要
リターン履行負荷支援者対応が増える
開発遅延約束した時期に提供できない可能性
誤解サービス内容やリターンの意味を誤解される可能性
期待値管理支援者に過度な期待を持たせるリスク
品質不足見せた画面の品質が低いと逆効果になる

特に大きいのは、品質不足である。

今の段階では、まだ人に見せるには不安な部分がある。

だから、クラウドファンディングを検討する前に、まずは初期確認版の品質を上げる必要がある。


12. 自分にとっての意味

自分にとってクラウドファンディングは、単なるお金集めではない。

それは、プロジェクトを外に出す最初の大きな一歩になる。

これまでは、自分の中で考え、ChatGPTと壁打ちし、Cursorで実装し、GitHubに積み上げてきた。

しかし、クラウドファンディングを行うなら、外部の人に説明しなければならない。

  • なぜ作るのか

  • 何が面白いのか

  • どこまでできているのか

  • 何にお金を使うのか

  • いつ届けるのか

  • どんな人に支援してほしいのか

  • 何がまだ未完成なのか

これを言語化する必要がある。

これは大変だが、プロジェクトにとって大きな意味がある。


13. 現時点の結論

クラウドファンディングは、かなり検討してよい。

ただし、目的はお金だけではない。

むしろ、初期ファン、先行利用者、開発過程を見守ってくれる人を集めることが大きい。

やるなら、購入型に寄せる。
金銭的リターンは出さない。
先行利用、支援者向け特典、クレジット掲載、開発レポートなどをリターンにする。

最初は50万円前後の小規模クラウドファンディングでよい。

まずは、支援してくれる人がいるかを確認する。
反応があれば、次の展開を考える。

ただし、今すぐ出すのはまだ早い。

まずは、初期確認版の品質を上げる。
外部に見せられる画面と説明資料を作る。
できること、まだできないこと、リスクを正直に書ける状態にする。

クラウドファンディングは、資金調達であり、宣伝であり、需要検証であり、初期コミュニティ作りでもある。

このプロジェクトを本当に月商1億円まで持っていくなら、どこかの段階で外部の人を巻き込む必要がある。

その最初の手段として、クラウドファンディングは有力な選択肢だと思っている。

注目の投稿

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

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