Translate

2026年4月30日木曜日

第16回:既存サービスとの差別化は、本当に十分なのか

 1. はじめに

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

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、課題、リスク、投資判断、AI活用、プロジェクト管理については記録している。

今回は、既存サービスとの差別化について書く。

新しいサービスを作る以上、必ず考えなければならないのが、既存サービスとの差である。

すでに似たようなサービスがある中で、なぜ自分のサービスを使ってもらえるのか。
なぜ時間を使ってもらえるのか。
なぜお金を払ってもらえるのか。
なぜ継続してもらえるのか。

ここを曖昧にしたまま開発を進めるのは危険である。

今回のプロジェクトでも、既存サービスとの差別化については考えている。
そして、その対策もいくつか入れようとしている。

ただし、正直に言うと、その差別化がどこまで効果的なのかは、まだ分からない部分もある。

ここは大きな懸念であり、リスクでもある。


2. 既存サービスがあること自体は悪いことではない

まず、既存サービスがあること自体は、必ずしも悪いことではない。

むしろ、既存サービスがあるということは、そこに需要がある可能性がある。

誰もやっていない領域は魅力的に見えるが、実際には需要がないだけかもしれない。
逆に、すでに誰かがやっている領域は、ユーザーが存在し、課金や利用習慣が成立している可能性がある。

だから、既存サービスがあること自体は問題ではない。

問題は、その中で自分のサービスが選ばれる理由を作れるかどうかである。

既存サービスと同じようなものを、後から出すだけでは厳しい。
ユーザーはすでに慣れているものを使い続ける。
よほど大きな理由がなければ、乗り換えてくれない。

だからこそ、差別化が必要になる。


3. 今回考えている差別化

今回のプロジェクトでも、既存サービスとの差別化はかなり意識している。

具体的な内容はまだ伏せるが、方向性としては、単に同じ機能を後追いで作るのではなく、体験そのものを変えることを考えている。

機能数で勝負するだけではない。
画面の見た目だけで勝負するわけでもない。
価格だけで勝負するわけでもない。

ユーザーが使ったときに、

  • こちらの方が分かりやすい

  • こちらの方が続けたくなる

  • こちらの方が楽しい

  • こちらの方が自分に合っている

  • こちらの方が参加している感覚がある

  • こちらの方が記録や成果が残る

  • こちらの方が愛着を持てる

と感じてもらえるかどうか。

ここを重視したい。

今回の対策は、既存サービスに対する単なる機能追加ではなく、体験設計、継続性、参加感、記録性、運営の見せ方などを含めた差別化にしたいと考えている。


4. ただし、差別化が本当に効くかは分からない

一方で、ここには大きな不確実性がある。

自分では「これは差別化になる」と思っていても、ユーザーがそう感じるとは限らない。

作り手が面白いと思っているポイントと、ユーザーが価値を感じるポイントはズレることがある。

自分では重要だと思っている機能が、ユーザーには伝わらないかもしれない。
自分では強みだと思っている世界観が、ユーザーには分かりにくいかもしれない。
自分では既存サービスにない魅力だと思っていても、ユーザーには違いが見えないかもしれない。

これはかなり怖い。

差別化は、作り手が宣言するだけでは成立しない。
ユーザーが実際に違いを感じて初めて成立する。

だから、現時点では、差別化の方向性はある。
対策も考えている。
しかし、それが本当に効くかは、まだ検証が必要である。


5. 差別化が伝わらないリスク

差別化で怖いのは、機能として存在していても、ユーザーに伝わらないことである。

たとえば、裏側ではかなり工夫している。
データ設計も凝っている。
継続利用の仕組みもある。
ユーザーごとの体験差も考えている。
将来的な拡張性も持たせている。

しかし、初めて触ったユーザーがそれを理解できなければ、意味が薄い。

ユーザーは最初から設計思想を読んでくれるわけではない。
長い説明を全部読んでくれるわけでもない。
裏側の複雑な仕組みを理解してくれるわけでもない。

最初の数分、最初の数画面で、何かを感じてもらう必要がある。

ここが難しい。

差別化は、仕様書の中にあるだけでは足りない。
画面、文言、導線、初回体験、結果表示、通知、演出、継続導線に落ちていなければならない。


6. 既存サービスに勝つ必要はあるのか

もう一つ考えたいのは、既存サービスに正面から勝つ必要があるのか、という点である。

既存サービスを完全に置き換える必要はないかもしれない。

既存サービスとは違う楽しみ方、違うユーザー層、違う利用シーンを狙うこともできる。

たとえば、既存サービスがすでに強い領域があるなら、そこに真正面からぶつかるのではなく、少し違う角度から入る。

  • 既存サービスが重いなら、こちらは分かりやすさを重視する

  • 既存サービスが競技性重視なら、こちらは継続体験を重視する

  • 既存サービスが効率重視なら、こちらは物語性や愛着を重視する

  • 既存サービスが上級者向けなら、こちらは初心者導線を重視する

  • 既存サービスが単発利用なら、こちらは長期的な記録を重視する

このように、正面衝突ではなく、別の軸を作ることも重要だと思っている。

差別化とは、必ずしも「既存サービスより全部優れている」という意味ではない。

違う理由で選ばれることも差別化である。


7. 別の強みを考えられないか

現時点で考えている差別化対策はある。

ただ、それだけで十分かは分からない。

だから、さらに別の強みを考えたい。

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

7.1 継続したくなる仕組み

一度使って終わりではなく、また見たくなる、また触りたくなる仕組みを作れるか。

日々の変化、履歴、通知、ランキング、成長、記録、イベントなど、継続利用につながる要素をもっと考えたい。

7.2 ユーザーが語りたくなる要素

サービスは、使われるだけでなく、語られる必要がある。

SNSで共有したくなる。
友人に話したくなる。
ブログや動画で取り上げたくなる。
自分の成果や記録を見せたくなる。

そういう要素を作れないか。

7.3 初回体験の強さ

どれだけ奥が深くても、最初に伝わらなければ離脱される。

初回ユーザーが、すぐに「これは何か違う」と感じる導線が必要である。

最初の画面、最初の説明、最初の操作、最初の結果表示。
ここをもっと強くできないか。

7.4 運営そのものの魅力

サービスの機能だけでなく、運営の見せ方も強みになる可能性がある。

開発過程を公開する。
改善の過程を見せる。
ユーザーの声を反映する。
プレオープンから一緒に作る雰囲気を出す。

これは大手サービスにはない強みになるかもしれない。

7.5 個人開発ならではの熱量

個人開発は、規模では大手に勝てない。

しかし、熱量では勝てる可能性がある。

作り手の思い、改善の速さ、細部へのこだわり、ユーザーとの距離感。
こうしたものを強みにできないか。


8. 差別化は機能だけではない

今回、改めて考えたいのは、差別化を機能だけで考えすぎないことだ。

機能は重要である。
ただ、機能だけなら、いずれ真似される可能性がある。

差別化には、もっと複数の層がある。

差別化の層内容
機能何ができるか
体験どう感じるか
導線迷わず使えるか
継続性また使いたくなるか
世界観愛着を持てるか
運営参加している感覚があるか
記録性自分の成果や履歴が残るか
コミュニティ他の人と関わりたくなるか
価格支払いやすいか
信頼安心して使えるか

既存サービスとの差別化を考えるなら、この複数の層で考える必要がある。

単に「この機能があります」だけでは弱いかもしれない。


9. 差別化はリリース前に完全証明できない

ここも重要である。

差別化が本当に効くかどうかは、リリース前には完全には分からない。

いくら考えても、最終的にはユーザーに触ってもらわなければ分からない。

だから、今後は限定公開やプレオープンを使って、差別化が伝わっているかを確認したい。

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

  • 既存サービスとの違いを感じるか

  • 何が面白いと感じたか

  • どこが分かりにくいか

  • また使いたいと思うか

  • 他人に勧めたいと思うか

  • お金を払う価値を感じるか

  • 最初の数分で魅力が伝わるか

このフィードバックを見て、差別化の方向性を修正する必要がある。

最初から正解を出すのではなく、反応を見ながら磨く。

これが現実的だと思っている。


10. 現時点の懸念

現時点での懸念は以下である。

懸念内容
差別化が伝わらない作り手の意図がユーザーに届かない可能性
既存サービスとの差が弱いユーザーが乗り換える理由にならない可能性
機能過多になる差別化のために機能を増やしすぎるリスク
初回体験が弱い奥深さがあっても最初に離脱される可能性
価格との整合性課金する価値が伝わらない可能性
継続性不足一度触って終わる可能性
検証不足自分の思い込みで進めてしまう可能性
大手との差体力・認知・開発速度で負ける可能性

これらはかなり重要なリスクである。

特に、自分だけが「これは面白い」と思っている状態は危険である。

ユーザーに伝わるか。
使い続けてもらえるか。
お金を払ってもらえるか。

そこまで見なければならない。


11. 今後考えたいこと

今後は、差別化についてさらに考えたい。

特に、以下を詰めたい。

  1. 既存サービスと比較したときの明確な違い

  2. 初回ユーザーに最初に伝えるべき強み

  3. 継続利用につながる仕組み

  4. ユーザーが語りたくなる要素

  5. 課金したくなる理由

  6. 大手にはできない個人開発ならではの強み

  7. プレオープンで確認すべき質問

  8. 差別化が伝わっているか測る方法

  9. 既存サービスに正面衝突しないポジショニング

  10. 今ある対策以外の別軸の強み

ここは、もう少し考えたい。

むしろ、今考えるべき重要テーマの一つだと思っている。


12. 今回の結論

既存サービスとの差別化については、今回のプロジェクトでも対策を考えている。

ただし、それがどこまで効果的かは、まだ分からない。

ここは大きな懸念であり、リスクである。

自分では強みだと思っていても、ユーザーに伝わらない可能性がある。
既存サービスとの差が十分に感じられない可能性もある。
奥深い仕組みを作っても、初回体験で伝わらなければ離脱されるかもしれない。

だから、差別化はもっと考える必要がある。

機能だけではなく、体験、継続性、初回導線、記録性、運営の見せ方、ユーザーが語りたくなる要素、個人開発ならではの熱量。

こうした別の強みをさらに探したい。

月商1000万円を目指すなら、作るだけでは足りない。
既存サービスがある中で、なぜこれを使うのか。
なぜ続けるのか。
なぜお金を払うのか。

この問いに答えられなければならない。

現時点では、答えの方向性はある。
しかし、まだ十分とは言い切れない。

だから、もう少し考える。
作りながら考える。
ユーザーに触ってもらいながら磨く。

差別化は、リリース前に一度決めて終わりではない。
サービスを育てながら、何度も見直していくものだと思っている。

第15回:AIの待ち時間に、何をするか問題

1. はじめに

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

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、スケジュール、体調管理、日常生活とのバランスについては記録している。

前回は、AIに仕事をさせていると待ち時間が多くなり、その間に椅子で寝落ちしてしまうことが増えてきた、という話を書いた。

今回は、その続きとして、AIの待ち時間をどう過ごすかについて考えたい。

AIを使うと、作業はかなり進む。
ただし、AIが作業している間、人間側には待ち時間が発生する。

この待ち時間をどう使うかが、意外と重要になってきた。


2. AIに任せている間、完全に暇になるわけではない

Cursorに作業を依頼する。
ChatGPTに整理を頼む。
ビルドやテストを走らせる。
GitHubへの反映状況を確認する。

こうした作業には、どうしても待ち時間がある。

ただし、この待ち時間は完全な自由時間ではない。

数分後には結果を確認する必要がある。
エラーが出たら判断する必要がある。
Cursorが止まったら次の指示を出す必要がある。
テストが失敗したら原因を見る必要がある。

つまり、完全に離席できるほど長くはないが、ずっと画面を見続けるには少し長い。

この中途半端な時間が難しい。


3. 最近の待ち時間の過ごし方

最近は、AIの待ち時間にいろいろなものを見たり聞いたりしている。

たとえば、以下のようなものだ。

  • Netflix

  • Amazon Prime Video

  • radiko

  • 三四郎のラジオ

  • オードリーのラジオ

  • ドキュメンタリー系の番組

  • 最近だとNetflixで細木数子関連の作品も見た

こうしたコンテンツを流しながら、Cursorの作業やテスト結果を待つことがある。

特にラジオは相性がよい。

画面を見なくてもよい。
耳だけで聞ける。
作業中でも邪魔になりにくい。
少し気分転換にもなる。

三四郎やオードリーのラジオは、開発の待ち時間にちょうどよい。
真剣に見続けなくてもよく、笑えるし、少し肩の力が抜ける。

一方で、NetflixやAmazon Primeは、画面を見てしまうので、場合によっては集中を持っていかれる。

待ち時間のつもりが、気づいたら普通に見入っていることもある。

これはこれで問題である。


4. 待ち時間を全部「作業」にしようとすると疲れる

最初は、AIの待ち時間も全部有効活用しようとしていた。

Cursorが作業している間に、ChatGPTで次の指示文を作る。
ビルド待ちの間に、残課題を整理する。
テスト待ちの間に、ブログ記事を書く。
回答待ちの間に、ドキュメントを読む。

これは確かに効率は良い。

しかし、ずっとこれをやっていると疲れる。

AIが働いている間も、人間が別の作業をし続ける。
結果として、休む時間がなくなる。

AIは疲れない。
しかし、自分は疲れる。

だから、待ち時間をすべて作業で埋めるのは危険だと思うようになってきた。

待ち時間は、作業時間にもできる。
でも、休憩時間にもしてよい。

この切り替えが大事だと思っている。


5. ラジオはかなり相性が良い

待ち時間の活用として、今のところラジオはかなり相性が良い。

理由は単純で、画面を奪われないからである。

開発では、画面を見て確認する必要がある。

Cursorの差分を見る。
ブラウザで画面を見る。
テスト結果を見る。
エラー内容を見る。
Gitの状態を見る。

そのため、動画を見てしまうと、目が持っていかれる。

一方、ラジオなら耳だけで楽しめる。

作業に戻るのも簡単である。
エラーが出たらすぐ画面を見られる。
Cursorが止まったらすぐ対応できる。

三四郎やオードリーのようなラジオは、深刻になりすぎた頭をほぐす意味でもよい。

開発はどうしても真面目になりがちである。
仕様、課題、バグ、スケジュール、費用、体調、売上。
考えることが多い。

その中で、少し笑える時間があるのは大事だと思う。


6. 動画は気分転換になるが、注意も必要

NetflixやAmazon Primeも、待ち時間の気分転換にはなる。

特に、少し長めの処理や、すぐには戻らなくてよい作業のときは、動画を見るのも悪くない。

最近はNetflixで細木数子関連の作品も見た。

自分の開発とは直接関係ないが、こういうものを見ると、人生、家族、仕事、成功、失敗、人間関係などについて、何となく考えることもある。

ただし、動画には注意も必要である。

見始めると、普通に続きが気になる。
待ち時間のつもりが、開発の方が止まる。
気分転換のつもりが、集中が切れる。

だから、動画は使いどころを選びたい。

短い待ち時間には向かない。
長めの待ち時間、あるいは今日はもう確認だけでよいという時間帯ならよい。


7. PS5でゲームするのが一番の趣味だった

もともと、自分の一番の趣味はPS5でゲームをすることだった。

ゲームは本当に好きである。

仕事が終わった後にゲームをする。
休日にゲームをする。
新作を楽しみにする。
オンラインで遊ぶ。
そういう時間は、自分にとってかなり大事だった。

しかし最近は、ゲームをほとんど休止している。

理由は単純で、開発が楽しいからである。

今は、ゲームをするよりも、このプロジェクトを進める方に気持ちが向いている。

これは自分でも少し不思議である。

普通なら、仕事が終わった後はゲームで息抜きしたい。
でも今は、ChatGPTと壁打ちしたり、Cursorに指示を出したり、仕様を考えたり、ブログを書いたりする方が楽しい。

ある意味、開発そのものがゲーム化しているのかもしれない。


8. 開発が「趣味」になっている

このプロジェクトは、月商1000万円を目指している。

だから、単なる趣味ではない。
本気で収益化したい。
生活を良くしたい。
妻を喜ばせたい。
マンションのローンも払いたい。
いつかサラリーマンを辞める選択肢も持ちたい。

ただ、その一方で、今の開発はかなり趣味に近い楽しさもある。

アイデアを考える。
仕様に落とす。
AIに指示する。
画面ができる。
課題が整理される。
GitHubに積み上がる。
少しずつ形になっていく。

これは、ゲームの育成要素やシミュレーションに近い感覚もある。

自分がプレイヤーであり、プロジェクトが育成対象であり、AIが仲間であり、GitHubがセーブデータのようなものになっている。

そう考えると、開発が楽しいのも自然かもしれない。


9. ゲームをやりながら開発してもよいのか

待ち時間が多いなら、PS5でゲームをやりながら進めてもよいのではないか。

そう思うこともある。

Cursorに作業を投げる。
その間にPS5を少し進める。
結果が出たら戻って確認する。
また指示を出す。
またゲームに戻る。

理論上はできる。

ただ、今は何となくそれをしていない。

理由は、こちらに専念したい気持ちが強いからだと思う。

ゲームを始めると、どうしても意識がゲーム側に持っていかれる。
特にPS5のゲームは没入感が高い。

少しだけのつもりが、普通に1時間、2時間と遊んでしまう可能性がある。

それ自体は悪いことではない。
趣味としては最高である。

ただ、今はこのプロジェクトを前に進めたい気持ちが勝っている。

だから、ゲームは少し休止している。


10. 待ち時間の活用にも分類が必要

今後は、AIの待ち時間をもう少し分類して使いたい。

たとえば、以下のように分ける。

待ち時間過ごし方
1〜3分画面のまま待つ、軽くメモする
5〜10分ラジオを聞く、次の指示を考える
10〜30分ブログ下書き、仕様整理、軽い動画
30分以上休憩、食事、風呂、犬猫の世話、場合によってはゲーム
夜遅い時間無理に待たず、寝る
疲れている時作業を切る、布団に行く

大事なのは、待ち時間を全部同じ扱いにしないことだと思う。

短い待ち時間に動画を見ると、戻りにくい。
長い待ち時間に画面をじっと見ていると、疲れる。
夜遅い待ち時間に無理して確認すると、椅子で寝落ちする。

待ち時間にも適切な過ごし方がある。


11. 休憩もプロジェクトの一部

最近、少しずつ思うようになった。

休憩もプロジェクトの一部である。

開発を進めるためには、頭が必要である。
判断力が必要である。
継続力が必要である。

疲れた状態で判断すると、ミスが増える。
眠い状態で差分を見ると、見落とす。
体調が悪いと、続かない。

だから、待ち時間にラジオを聞くことも、動画で少し気分転換することも、場合によっては必要である。

ただし、休憩がそのまま長時間の逃避になってしまうと、プロジェクトは進まない。

このバランスが難しい。

休む。
でも戻る。

これが大事である。


12. 現時点の課題

今回整理した課題は以下である。

課題内容
AI待ち時間Cursorやテストの待ち時間が多い
待ち時間の使い方作業、休憩、娯楽の切り分けが必要
動画視聴気分転換になるが、集中を持っていかれる
ラジオ活用作業との相性が良い
PS5休止中一番の趣味だったが、今は開発に専念気味
開発の趣味化楽しいが、休息とのバランスが必要
寝落ち問題待ち時間に椅子で寝てしまうリスク
体調管理アラフィフとして無理は禁物

13. 今後の方針

今後は、待ち時間を以下のように使い分けたい。

  1. 短い待ち時間は、すぐ戻れる状態で待つ

  2. 少し長い待ち時間は、ラジオを聞く

  3. 集中が切れている時は、軽い動画で休憩する

  4. 夜遅い時間は、無理に待たず寝る

  5. PS5は完全禁止ではなく、時間を決めて再開してもよい

  6. ただし、今は開発優先で進める

  7. 待ち時間に次の指示文を作る時と、休む時を分ける

  8. 体調が悪い時は、開発より回復を優先する

  9. 椅子で寝そうなら、作業を切って布団に行く

  10. 開発を長く続けるために、娯楽も適度に使う


14. 今回の結論

AIを活用して開発していると、待ち時間が発生する。

その待ち時間をどう使うかは、思った以上に重要である。

最近は、Netflix、Amazon Prime、radiko、三四郎やオードリーのラジオなどを使って、待ち時間を過ごしている。
ラジオは作業との相性が良い。
動画は気分転換になるが、集中を持っていかれることもある。

もともとはPS5でゲームをするのが一番の趣味だった。
しかし今は、開発が楽しくて、ゲームはかなり休止中である。

ゲームをやりながらAIの作業を待つこともできるかもしれない。
ただ、今は何となく、このプロジェクトに専念したい。

それだけ、この開発が面白い。

月商1000万円を目指す道のりは長い。
だからこそ、作業時間だけでなく、待ち時間、休憩時間、娯楽時間も含めて、うまく付き合っていく必要がある。

AIは働いてくれる。
でも、自分の集中力と体力は有限である。

待ち時間を活用する。
休む時は休む。
戻る時は戻る。

このバランスを作りながら、少しずつ前に進めていきたい。

第14回:AIに仕事をさせているのに、待ち時間で寝落ちしてしまう問題

1. はじめに

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

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

今回は、少し泥臭い話を書く。

AIに仕事をさせていると、意外と待ち時間が多い。

ChatGPTで方針を整理し、Cursorに実装指示を出し、Gensparkでデザインや資料を検討する。
一見すると、AIによってどんどん作業が進んでいるように見える。

実際、進んではいる。

ただ、その裏側には、AIの処理を待つ時間、Cursorの作業完了を待つ時間、ビルドやテストを待つ時間、結果を確認する時間がある。

最近は、その待ち時間の間に、椅子に座ったまま寝てしまうことが増えてきた。

これは少しまずいかもしれない。


2. AIに任せても、人間の待機時間はなくならない

AIを使えば、人間がすべて手作業するよりは明らかに速い。

自分一人では何時間もかかるような作業を、Cursorがかなりの速度で進めてくれる。
ChatGPTも、仕様整理や指示文作成、課題の棚卸しをかなり助けてくれる。

ただし、AIを使っているからといって、人間の待ち時間がゼロになるわけではない。

実際には、以下のような待ち時間が発生する。

  • Cursorが実装している間の待ち時間

  • コード生成が終わるまでの待ち時間

  • lint / build / test の完了待ち

  • E2Eテストの実行待ち

  • 差分確認の待ち時間

  • commit / push の結果確認

  • AIの回答生成待ち

  • 次の指示を考えるまでの待ち時間

AIに仕事をさせているのに、こちらはただ待っている時間がある。

この時間をうまく使えればよい。
次の指示文を考えたり、別の課題を整理したり、ブログ記事を書いたりできる。

ただ、疲れていると、そこで意識が飛ぶ。


3. 連続的にCursor指示を入れて、止まらないようにはしている

最近は、Cursorに対して、なるべく連続的に作業指示を入れるようにしている。

一つの作業が終わったら、次に何をやるか。
詰まった場合は、どの作業に切り替えるか。
ドキュメント更新だけで終わらず、実装に進めるか。
作業後には、進捗率や残課題を報告してもらうか。

こうした指示をあらかじめ入れて、Cursorができるだけ止まらないようにしている。

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

  • 作業範囲を明確にする

  • 完了条件を明確にする

  • 詰まったら別タスクに移る

  • 実装可能なものを優先する

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

  • 最後に次の作業候補を出してもらう

  • 進捗率と残り見通しを報告してもらう

これはかなり効果がある。

AIに対しても、プロジェクトマネジメントが必要である。
人間のメンバーではなくても、役割、作業範囲、完了条件、報告内容を決めないと、作業は止まりやすい。


4. それでも、たまに止まる

ただし、どれだけ指示を工夫しても、AIの作業はたまに止まる。

理由はいろいろある。

  • エラーで止まる

  • 判断が必要になる

  • 仕様が曖昧になる

  • テストが失敗する

  • ファイルの影響範囲が大きくなる

  • コマンド実行待ちになる

  • こちらの確認待ちになる

  • 次の指示が不足している

この「たまに止まる」が地味に効いてくる。

人間側としては、AIが止まっていないかを見ておく必要がある。
止まったら、確認して、判断して、次の指示を出す必要がある。

つまり、AIに仕事をさせている間も、完全に放置できるわけではない。

この状態は、少しだけ運用監視に近い。

Cursorが実装担当だとすると、自分はプロジェクトマネージャーであり、レビュー担当であり、判断者であり、運用監視者でもある。

AIを使っているから楽になる部分は大きい。
しかし、AIを動かし続けるための管理負荷もある。


5. 待ち時間に寝てしまう問題

最近、一番気になっているのは、待ち時間に寝てしまうことだ。

Cursorに作業を依頼する。
少し待つ。
結果を見ようと思う。
気づいたら椅子に座ったまま寝ている。

これが増えてきた。

正直、あまり良くない。

単純に疲れているのだと思う。

普段はサラリーマンとして働いている。
そのうえで、夜や休日にこのプロジェクトを進めている。
さらに、通勤中、犬の散歩中、室内サイクルマシンでのトレーニング中にもChatGPTと壁打ちしている。

つまり、頭のどこかがずっとプロジェクトに向いている。

楽しい。
前に進んでいる。
月商1000万円を目指したい。

それは本当である。

ただし、体は正直である。


6. アラフィフとして、体調面は軽視できない

自分はアラフィフである。

若い頃のように、多少寝なくても何とかなる、という年齢ではない。

睡眠不足は翌日に残る。
疲労も抜けにくい。
集中力も落ちる。
肩や腰にもくる。
無理をすれば、仕事にも家庭にも影響する。

個人開発で一番怖いのは、途中で燃え尽きることだと思う。

短期的に無理をして、数日だけ頑張ることはできる。
しかし、このプロジェクトは月商1000万円を目指している。

それは、数日で終わる挑戦ではない。

一人用確認版、限定公開、初期サービスイン、初売上、月商10万円、100万円、300万円、1000万円。
長い道のりである。

長い道のりだからこそ、体調を壊す進め方は危険である。


7. 「AIがあるから無理できる」は危険

AIを使うと、できることが増える。

一人でも、かなり大きなプロジェクトを進められる。
ChatGPTが整理してくれる。
Cursorが実装してくれる。
Gensparkがデザイン案を出してくれる。
GitHubで状況も追える。

だから、つい思ってしまう。

「これなら、もっと進められる」
「もう少しだけやろう」
「待っている間に次の指示を作ろう」
「寝る前にもう一つだけ投げよう」

この積み重ねが危ない。

AIがあるからこそ、人間側が止まれなくなる可能性がある。

昔なら、一人でできる作業量には自然な限界があった。
しかし今は、AIに任せれば深夜でも作業が進む。

これは強力だが、危険でもある。

AIは疲れない。
しかし、自分は疲れる。

ここを忘れてはいけない。


8. 今後は「待ち時間の使い方」も管理する

今後は、AIの待ち時間をどう使うかも管理したい。

ただ待つのではなく、待ち時間を以下のように分類する。

待ち時間の種類使い方
短い待ち時間差分確認、次の指示メモ、軽い整理
長い待ち時間ブログ下書き、仕様整理、休憩
ビルド・テスト待ち結果確認に備える、無理なら休む
夜遅い待ち時間無理に待たず、翌朝確認する
疲れている時作業を止めて寝る

特に重要なのは、夜遅い時間である。

深夜にCursorの結果を待ち続けるのは危ない。
眠い状態で差分確認しても、品質確認の精度は落ちる。

むしろ、夜は指示だけ出して、結果確認は翌朝に回す方がよい場合もある。


9. 連続稼働より、継続稼働が大事

月商1000万円を目指すなら、短期集中も必要である。

ただし、それ以上に大事なのは、継続することだ。

一晩で無理をして、その後数日動けなくなるより、毎日少しずつでも進めた方がよい。

今後は、以下を意識したい。

  • 深夜の無理な確認を減らす

  • 椅子で寝落ちしそうなら作業を切る

  • Cursorに投げたら翌朝確認でもよい

  • 通勤中や散歩中は壁打ち中心にする

  • 実装確認は集中できる時間にやる

  • 週単位で稼働量を見る

  • 休む日も計画に入れる

これは、甘えではない。

プロジェクトを長く続けるための戦略である。


10. 体調管理もプロジェクトマネジメントの一部

PMP的に考えても、これは資源管理やリスク管理の話である。

自分自身は、このプロジェクトにおける最大のリソースである。

ChatGPTもある。
Cursorもある。
Gensparkもある。
追加PCもある。
GitHubもある。

しかし、最終判断をするのは自分である。
方向性を決めるのも自分である。
何を作るか、何を捨てるか、いつ公開するかを決めるのも自分である。

その自分が倒れたら、プロジェクトは止まる。

だから、体調管理は単なる私生活の話ではない。
プロジェクトマネジメント上の重要課題である。

特にアラフィフで、本業があり、妻がいて、犬と猫もいる。
無理を前提にした計画は破綻しやすい。


11. 今後の対策

現時点で考えている対策は以下である。

11.1 夜の作業終了ラインを決める

まず、夜の作業終了ラインを決めたい。

たとえば、一定時刻を過ぎたら新しい実装指示は出さない。
出すとしても、確認は翌日に回す。

深夜に判断が必要な作業をしない。

これはかなり重要だと思う。


11.2 Cursorへの指示は「翌朝確認前提」にする

夜にCursorへ指示を出す場合は、最初から翌朝確認前提にする。

つまり、

  • 作業完了後に結果を整理する

  • 実施内容を箇条書きで報告する

  • 変更ファイルを示す

  • テスト結果を示す

  • 残課題を示す

  • 次に確認すべき点を示す

ところまで依頼しておく。

そうすれば、翌朝に状況を把握しやすい。


11.3 待ち時間は休憩にしてよいと決める

AIが作業している待ち時間に、必ず別作業をしようとすると疲れる。

待ち時間は休憩にしてもよい。

むしろ、AIが働いている間に人間が休む、という考え方も必要である。

AIに仕事を任せているのだから、その間に自分が少し休むのは合理的である。


11.4 椅子で寝る前に布団へ行く

これは単純だが大事である。

椅子で寝るくらいなら、作業を切って布団へ行く。

椅子で寝ても疲れは取れない。
体も痛くなる。
翌日のパフォーマンスも落ちる。

眠いなら寝る。

これは、今後かなり意識したい。


11.5 週単位で稼働と体調を振り返る

毎日厳密に管理する必要はないが、週単位では振り返りたい。

  • 何時間くらい作業したか

  • 何日寝落ちしたか

  • 体調はどうだったか

  • 進捗はあったか

  • 無理した割に進まなかった作業はないか

  • AI待ち時間をうまく使えたか

  • 休むべき日を休めたか

これを見れば、無理な進め方に気づきやすい。


12. 現時点の課題

今回整理した課題は以下である。

課題内容
AI待ち時間Cursorやテストの待ち時間が意外と多い
作業停止連続指示していても、たまにAI作業が止まる
監視負荷AIが止まっていないか人間が見る必要がある
寝落ち椅子に座ったまま寝てしまうことが増えている
体調不安アラフィフとして睡眠不足や疲労が心配
夜間判断眠い状態で確認・判断すると品質が落ちる
継続性短期的な無理より、長く続ける体制が必要

13. 今回の結論

AIを活用すると、開発はかなり進む。

ChatGPTで整理し、Cursorで実装し、Gensparkでデザインを考え、GitHubで履歴を管理する。
この流れは非常に強力である。

ただし、AIに仕事をさせていると、待ち時間も発生する。
そして、その待ち時間に椅子で寝落ちすることが増えてきた。

これは、少し危険信号だと思っている。

自分はアラフィフである。
本業もある。
妻もいる。
犬と猫もいる。
マンションのローンもある。

月商1000万円を目指すからこそ、無理をしすぎてはいけない。

AIは疲れない。
でも、自分は疲れる。

この当たり前のことを忘れないようにしたい。

今後は、AIを止めない工夫だけでなく、
自分を壊さない工夫も必要である。

待ち時間をどう使うか。
どこで作業を切るか。
いつ確認を翌日に回すか。
どこからは寝るか。

これも、プロジェクトマネジメントの一部である。

月商1000万円までの道のりは長い。
だからこそ、短距離走ではなく、長距離走として進めたい。

無理はする。
でも、壊れるほどはしない。

AIを働かせながら、自分もちゃんと休む。
そのバランスを作ることが、今後の大きな課題である。

第13回:アイデアは通勤中、犬の散歩中、トレーニング中に生まれている

1. はじめに

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

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、プロジェクト管理、費用、課題、進捗については記録している。

今回は、今の自分の開発スタイルについて書く。

最近の進め方を一言で言うと、こうである。

日常のすき間時間でChatGPTと壁打ちし、アイデアや課題を整理し、Cursorへの指示文に落とし込み、実装とドキュメント更新につなげる。

この流れが、かなり自分に合っている。


2. アイデアは机の前だけで生まれるわけではない

プロジェクトのアイデアや課題整理は、必ずしもPCの前だけで行っているわけではない。

むしろ、最近は以下のような時間に考えが進むことが多い。

  • 通勤中

  • 犬の散歩中

  • 室内の自転車サイクルマシンでのトレーニング中

  • ちょっとした移動時間

  • 家の中で少し頭が空いた時間

こうした時間に、ChatGPTと壁打ちをしている。

昔なら、ふと思いついたことはメモアプリに書いて終わりだった。
あるいは、頭の中だけで考えて、後で忘れてしまうことも多かった。

しかし今は、思いついた瞬間にChatGPTへ投げられる。

「こういう機能が必要ではないか」
「この課題は後回しにしてよいのか」
「この仕様は今作るべきか」
「Cursorにはどう指示すべきか」
「この内容をドキュメントに反映するなら、どう整理するか」

こうした壁打ちを、その場でできる。

これはかなり大きい。


3. ChatGPTは単なるメモ帳ではない

ChatGPTを使っていて大きいのは、単なるメモ帳ではないという点である。

メモ帳なら、思いついたことを記録するだけで終わる。
しかしChatGPTは、そこから整理してくれる。

たとえば、自分が雑に話した内容を、以下のように変換してくれる。

  • アイデアの整理

  • 課題の棚卸し

  • 優先度の整理

  • 実装方針の整理

  • 懸念点の洗い出し

  • 対策案の整理

  • Cursorへの指示文作成

  • ブログ記事化

  • ドキュメント化

  • 残課題一覧への反映案

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

頭の中にある断片的な考えを、そのままプロジェクトで使える形に近づけられる。

特に、通勤中や散歩中は、PCを開いて細かい作業はできない。
しかし、考えることはできる。
話すこともできる。
その内容をChatGPTに整理してもらえる。

これにより、机の前に座っていない時間も、プロジェクトを前に進める時間に変わっている。


4. ChatGPTとの壁打ちからCursor指示文へ

今の開発フローでは、ChatGPTとの壁打ちで終わらせないことを意識している。

最終的には、Cursorに渡せる指示文にする。

たとえば、次のような流れである。

  1. 通勤中や散歩中にアイデアを思いつく

  2. ChatGPTに話す

  3. ChatGPTと壁打ちして、課題や仕様を整理する

  4. 実装すべきか、後回しにすべきかを判断する

  5. 必要ならドキュメント反映用の文章にする

  6. さらにCursor向けの作業指示文に変換する

  7. Cursorに実装・修正・ドキュメント更新を依頼する

  8. 結果を確認し、必要なら追加指示を出す

この流れがかなり重要である。

アイデアを思いつくだけでは、サービスは完成しない。
アイデアを仕様にする。
仕様を作業にする。
作業を実装にする。
実装を確認する。
確認結果をまた課題に戻す。

この循環を作る必要がある。


5. ドキュメント化までつなげる

ChatGPTとの壁打ち内容は、その場限りの会話で終わらせないようにしている。

重要な内容は、できるだけドキュメント化する。

具体的には、以下のような形で残す。

  • 要件定義書への追記

  • 機能仕様書への追記

  • 画面仕様書への追記

  • データ設計書への反映

  • 残課題一覧への追加

  • 後回し機能一覧への追加

  • 開発ルールへの反映

  • Cursorへの実装指示文

  • ブログ記事としての記録

これにより、思いつきが消えずに残る。

特に今のプロジェクトは、要件も仕様も残課題も非常に多い。
頭の中だけで管理するのは無理である。

だから、ChatGPTで整理し、Cursorに渡し、ドキュメントに残す。

この流れを作ることで、アイデアをプロジェクト資産に変えている。


6. GitHubとの連携も大きい

開発状況の管理では、GitHubも重要になっている。

GitHubには、コードの変更履歴、コミット、プッシュ状況が残る。

ChatGPTからもGitHubに接続している。
これがかなり大きい。

なぜなら、ChatGPTが最新状況やコミット・プッシュ状況を把握しやすくなるからである。

たとえば、

  • どこまで実装済みか

  • どの変更がコミット済みか

  • pushされているか

  • 直近で何が変更されたか

  • どの作業が残っているか

  • 次に何を指示すべきか

こうした確認を、ChatGPT側でも扱いやすくなる。

これは、単に相談するだけのChatGPTとはかなり違う。

プロジェクトの現状を把握しながら、次の指示や判断につなげられる。
この点は非常に大きい。


7. コミットとプッシュはCursorの方がスムーズな印象

一方で、実際のコミットやプッシュについては、今のところCursorから行う方がスムーズな印象がある。

Cursorはコード編集の流れの中で、変更内容を確認し、必要に応じてコミット・プッシュまで進めやすい。

実装して、差分を見て、チェックして、コミットして、プッシュする。
この一連の流れがかなり自然である。

もちろん、ChatGPTがGitHubとリンクできていることも大きい。
ただ、実際の開発作業の手触りとしては、Cursorの方が「さらっとコミット&プッシュしてくれる」感覚がある。

そのため、今の役割分担としては、以下のようになっている。

役割主に使うもの
アイデア壁打ちChatGPT
課題整理ChatGPT
Cursor指示文作成ChatGPT
ドキュメント化の下書きChatGPT
実装Cursor
コード修正Cursor
コミット・プッシュ主にCursor
最新状況の把握ChatGPT+GitHub
進行管理ChatGPT+ドキュメント

この分担が、かなり現実的で使いやすい。


8. 日常時間がプロジェクト時間に変わる

この開発スタイルで大きいのは、日常時間がプロジェクト時間に変わることである。

もちろん、常に仕事をしているような状態になるのは良くない。
休む時間も必要である。

ただ、通勤中や犬の散歩中、トレーニング中に自然と考えが浮かぶことは多い。

その時間を、ただ頭の中で流して終わらせるのではなく、ChatGPTとの壁打ちに使う。

すると、机の前に戻ったときには、すでに以下ができていることがある。

  • 課題が整理されている

  • 優先度が見えている

  • Cursorへの指示文がある

  • ドキュメント反映案がある

  • 記事の下書きがある

  • 次にやるべきことが明確になっている

これはかなり効率が良い。

アラフィフで、普段はサラリーマンで、家族もいて、犬と猫もいる。
限られた時間で進めるには、このすき間時間の活用が重要になる。


9. ただし、アイデアが増えすぎる問題もある

一方で、この流れには問題もある。

それは、アイデアが増えすぎることである。

ChatGPTと壁打ちすると、考えがどんどん広がる。
課題も見えてくる。
改善案も出てくる。
仕様も深くなる。

これは良い面もあるが、同時に危険でもある。

要件が増えすぎる。
残課題が増えすぎる。
ドキュメントが増えすぎる。
実装範囲が広がりすぎる。

その結果、一人用確認版やサービスインが遠くなる可能性がある。

だから、ChatGPTとの壁打ちでは、広げるだけではなく、絞ることも必要になる。

  • 今やるもの

  • 後でやるもの

  • やらないもの

  • ドキュメントだけ残すもの

  • Cursorにすぐ依頼するもの

  • いったん保留するもの

これを分ける必要がある。

AIはアイデアを広げるのが得意である。
だからこそ、人間側がスコープを管理しなければならない。


10. 今の自分に合っている開発スタイル

今の自分には、この開発スタイルがかなり合っている。

通勤中に考える。
犬の散歩中に壁打ちする。
トレーニング中に課題を整理する。
ChatGPTに文章化してもらう。
Cursorへの指示文を作る。
PCの前に戻ったらCursorで実装する。
GitHubで変更を管理する。
またChatGPTで進捗を整理する。

この流れにより、時間の使い方が変わってきた。

以前なら、PCの前に座ってから「何をやろうか」と考えていた。
今は、PCの前に座る前に、ある程度作業内容が整理されている。

これは大きい。

限られた時間で開発するには、PCの前に座っている時間だけで勝負してはいけない。

考える時間、整理する時間、指示を作る時間、実装する時間を分ける。
そして、それぞれにAIを活用する。

この形が、今の自分の開発体制になっている。


11. 今後の課題

この開発フローにも、今後の課題はある。

課題内容
アイデア過多壁打ちで要件が増えすぎる
指示文の精度Cursorに渡す指示が曖昧だと手戻りになる
ドキュメント更新会話内容をどこまで正式文書に反映するか
GitHub連携ChatGPTとCursorで最新状況の認識を合わせる必要がある
コミット粒度変更が大きくなりすぎないようにする
作業範囲複数PC運用時に同じファイルを触らないようにする
優先順位今やるべきことと後でよいことを切り分ける
休息すき間時間を使いすぎて休めなくなるリスク

特に注意したいのは、すき間時間を全部プロジェクトに使いすぎないことだ。

犬の散歩は犬との時間でもある。
トレーニングは体を整える時間でもある。
通勤中も、休む時間は必要である。

プロジェクトを進めることは大事だが、生活を壊してはいけない。


12. 今回の結論

今の開発では、ChatGPT、Cursor、GitHubの組み合わせがかなり重要になっている。

ChatGPTとは、通勤中、犬の散歩中、トレーニング中にも壁打ちしている。
そこでアイデアや課題を整理し、対策案を考え、Cursorへの指示文を作る。
その後、Cursorで実装し、必要に応じてドキュメント化し、GitHubで変更を管理する。

特に、ChatGPTがGitHubとリンクできているのは大きい。
最新状況、コミット、プッシュ状況を把握しながら相談できるため、単なる会話ではなく、プロジェクトの進行管理に近い使い方ができる。

一方で、実際のコミットやプッシュは、今のところCursorから行う方がスムーズな印象がある。

それぞれのツールに役割がある。

ChatGPTは、考えを整理する相棒。
Cursorは、実装を進める開発者。
GitHubは、履歴と状態を管理する基盤。

この3つをうまく組み合わせることで、限られた時間でもプロジェクトを前に進められている。

月商1000万円を目指すには、ただ頑張るだけでは足りない。
限られた時間をどう使うか。
日常の中で生まれたアイデアをどう逃さないか。
それをどう実装につなげるか。

今の自分にとって、その答えの一つが、
ChatGPTとの壁打ち、Cursorへの指示、GitHubでの管理という開発フローである。

第12回:まだ計算できていない最大のコストは、自分自身の稼働かもしれない


1. はじめに

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

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

ここまで、PC購入費用、ChatGPT、Cursor、GensparkなどのAIツール費用、開発環境、ドキュメント、テスト計画について整理してきた。

しかし、まだきちんと計算できていない大きなコストがある。

それは、自分自身の稼働コストである。


2. ツール費用は見えるが、自分の時間は見えにくい

PCを買えば、金額が分かる。
CursorやChatGPT、Gensparkに課金すれば、月額費用が分かる。
サーバーやドメインを使えば、それも費用として見える。

しかし、自分自身の時間は見えにくい。

平日の夜に作業する。
休日に仕様を考える。
通勤中にアイデアを整理する。
ChatGPTに記事を書かせる。
Cursorへの指示文を作る。
進捗を確認する。
ドキュメントを読む。
残課題を棚卸しする。

これらは全部、時間を使っている。

ただ、今のところ、その時間をきちんと金額換算できていない。

これは、今後ちゃんと向き合うべき課題だと思っている。


3. 普段はサラリーマンである

自分は普段、サラリーマンとして働いている。

つまり、このプロジェクトは本業の勤務時間外で進めている。

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

専業で朝から晩まで開発できるわけではない。
平日は本業があり、仕事が終わった後の時間や休日を使って進めている。

だから、単純に「やる気があれば進む」というものでもない。

疲れている日もある。
仕事で頭を使い切っている日もある。
夜に少ししか時間が取れない日もある。

その中で、月商1000万円を目指すプロジェクトを進めている。

ここは、かなり現実的に見なければならない。


4. 家族も生活もある

自分には妻がいる。

さらに、犬と猫も飼っている。

つまり、プロジェクトだけにすべての時間を使えるわけではない。

家族との時間もある。
犬や猫の世話もある。
家のこともある。
日々の生活もある。

個人開発というと、寝る間を惜しんで作るようなイメージもあるかもしれない。

もちろん、短期的に集中する時期は必要だと思う。
ただ、長期的に続けるなら、生活を壊してはいけない。

妻との時間を犠牲にし続ける形では続かない。
体調を壊しても意味がない。
家の中が荒れても、結局プロジェクトは続かない。

月商1000万円を目指すと言っても、生活の上に成り立つ挑戦である。


5. アラフィフという現実

自分はアラフィフである。

若い頃のように、無限に体力があるわけではない。

徹夜すれば翌日に響く。
集中力にも限界がある。
健康も無視できない。
家族や住宅ローンなど、背負っているものもある。

一方で、アラフィフだからこその強みもあると思っている。

これまでの仕事経験がある。
プロジェクト管理の経験がある。
PMPの資格も持っている。
失敗しそうな進め方もある程度分かる。
仕様、課題、リスク、品質、コストを意識して進められる。

若さで突っ走るのではなく、経験とAIを使って進める。

それが今の自分に合った戦い方だと思っている。


6. 自分の稼働をコストとして見る必要がある

今後は、自分の稼働をもっと冷静に見たい。

たとえば、1時間をいくらとして見るのか。

本業の時給換算で見るのか。
副業としての期待単価で見るのか。
外注した場合の単価で見るのか。
それとも、趣味としての時間だからゼロ円にするのか。

この考え方によって、プロジェクトの見え方は大きく変わる。

仮に自分の稼働を1時間3,000円、5,000円、1万円として見るなら、これまで使った時間はかなり大きな投資になる。

一方で、趣味の一つとしてやっている面もある。

ゲームをする時間、映画を見る時間、飲みに行く時間と同じように、自分が好きで使っている時間でもある。

だから、すべてを厳密に人件費として計上する必要はないかもしれない。

ただし、月商1000万円を本気で目指すなら、いつかは自分の稼働コストも見なければならない。


7. 趣味であり、事業でもある

このプロジェクトは、今のところ趣味の一つでもある。

考えていて楽しい。
作っていて楽しい。
構想が膨らむのも楽しい。
AIと一緒に進めるのも面白い。

ただ、単なる趣味で終わらせるつもりもない。

現実的に本当に目指せるのであれば、月商1000万円を達成したい。

いや、達成する。

そのためには、趣味としての楽しさと、事業としての厳しさの両方を持つ必要がある。

楽しいだけでは続かない。
厳しいだけでも続かない。

自分が面白いと思えるものを作りながら、現実的に収益化できる形に持っていく。

これが今の目標である。


8. 儲かったら、サラリーマンを辞められるかもしれない

もし本当にこのプロジェクトが伸びて、十分な収益が出るようになれば、将来的にはサラリーマンを辞める選択肢も出てくるかもしれない。

もちろん、今すぐ辞めるつもりはない。

売上が立っていない段階で、勢いだけで本業を辞めるのは危険である。
家族もいるし、住宅ローンもある。

だから、現実的には段階が必要である。

  • まずサービスを完成させる

  • 初期ユーザーを獲得する

  • 売上を立てる

  • 継続収益を確認する

  • 月商10万円を超える

  • 月商100万円を超える

  • 月商300万円を超える

  • 安定性を確認する

  • そのうえで働き方を考える

月商1000万円を一度達成しただけで、すぐ会社を辞めるという判断にはならないと思う。

大事なのは、売上の継続性である。
一時的な売上ではなく、継続して収益が出るか。
運営できるか。
税金を払った後に手元に残るか。
生活費をまかなえるか。
将来の不安を減らせるか。

そこまで見て判断したい。


9. マンションのローンも支払いたい

現実的な話として、マンションのローンもある。

このプロジェクトで儲かったら、ローンの支払いにも充てたい。

これはかなり大きなモチベーションである。

夢だけではなく、現実の生活を良くしたい。

住宅ローンの負担を減らせれば、生活はかなり楽になる。
将来の不安も減る。
家族に対しても、より安心を提供できる。

月商1000万円という目標は大きいが、自分の中では単なる数字ではない。

妻を喜ばせたい。
生活を良くしたい。
ローンの不安を減らしたい。
将来の選択肢を増やしたい。

そのための目標でもある。


10. 税金のことも考えなければならない

もし本当に収益が出るようになったら、税金のことも考えなければならない。

売上がそのまま手取りになるわけではない。

経費、税金、社会保険、事業形態、確定申告、法人化の検討など、考えるべきことは多い。

幸い、税理士の友人がいる。

今すぐ大きな相談をする段階ではないかもしれないが、相談すべきボリュームまで、早く突き進みたいと思っている。

つまり、税理士に相談する価値があるくらいの売上、利益、取引量まで持っていきたい。

その段階まで行けば、このプロジェクトはかなり現実味を帯びてくる。


11. 自分の稼働管理も必要になる

今後は、自分自身の稼働も少しずつ管理した方がよい。

厳密な勤怠管理までは不要かもしれない。
ただし、最低限、以下は見える化したい。

  • 週に何時間使っているか

  • どの作業に時間を使っているか

  • 実装に使った時間

  • 仕様整理に使った時間

  • ドキュメントに使った時間

  • ブログに使った時間

  • AIへの指示作成に使った時間

  • テスト確認に使った時間

  • 無駄に悩んでいる時間

これを見れば、自分の時間の使い方が分かる。

もしドキュメントに時間を使いすぎているなら、実装に戻す。
もし判断に時間がかかりすぎているなら、基準を作る。
もしAIへの指示が雑で手戻りが多いなら、指示文を改善する。

自分の稼働を測ることは、自分を縛るためではない。
プロジェクトを前に進めるためである。


12. 家族に応援してもらえる進め方にしたい

このプロジェクトは、自分一人の挑戦ではある。

しかし、生活の中で進めている以上、家族への影響はある。

だから、妻に応援してもらえる進め方にしたい。

ずっとPCに向かっていて、家族との時間がなくなる。
疲れて機嫌が悪くなる。
お金だけ出ていく。
いつまでも成果が見えない。

そうなると、続けるのは難しくなる。

だからこそ、進捗を見える化したい。
費用も整理したい。
スケジュールも置きたい。
どこまで進んでいるかを自分でも把握したい。

そして、成果が出たら妻を喜ばせたい。

それはかなり大事なモチベーションである。


13. 現時点の課題

今回整理して、現時点の課題は以下だと思っている。

課題内容
自分の稼働コスト未計算実際にどれだけ時間を投資しているか見えていない
本業との両立平日夜・休日中心のため、体力と集中力に限界がある
家族とのバランス妻、犬、猫との生活時間も大切にする必要がある
年齢・健康アラフィフとして無理しすぎない進め方が必要
固定費増加AIツール、PC、開発費用が増えている
収益化時の税務売上が出たら税理士相談が必要
退職判断本業を辞めるかどうかは継続収益を見て慎重に判断
ローン返済収益を生活改善や住宅ローンにもつなげたい
継続性趣味として楽しみつつ、事業として成立させる必要がある

14. 今後の方針

今後は、以下を意識して進めたい。

  1. 自分の稼働時間をざっくり記録する

  2. 週単位で作業時間と成果を振り返る

  3. 家族との時間を完全に犠牲にしない

  4. 体調を壊すような進め方はしない

  5. AIと追加PCで作業効率を上げる

  6. ドキュメントだけで止まらず実装を進める

  7. 税理士に相談すべき規模まで早く持っていく

  8. 収益が出ても税金・継続性を見て判断する

  9. 住宅ローンや生活改善につながる収益を目指す

  10. 妻を喜ばせられる成果を出す


15. 今回の結論

これまで、PC代、AIツール代、開発環境費用などは整理してきた。

しかし、本当に大きいコストは、自分自身の稼働かもしれない。

普段はサラリーマン。
妻がいる。
犬と猫もいる。
アラフィフである。
マンションのローンもある。

その中で、月商1000万円を目指すプロジェクトを進めている。

これは簡単ではない。

ただ、現実的に本当に目指せるのであれば、達成したい。
いや、達成する。

趣味として楽しい。
でも、趣味で終わらせない。
生活を良くしたい。
妻を喜ばせたい。
住宅ローンの不安も減らしたい。
いつか、本業を辞める選択肢も持ちたい。

そのためには、自分の時間も投資として見なければならない。

月商1000万円までの道のりは、開発費用だけでなく、自分の人生の時間をどう使うかという話でもある。

だからこそ、無理をしすぎず、でも甘えすぎず、前に進める。

まずは一人用確認版。
次に限定公開。
そしてサービスイン。
その先に、売上を作る。

税理士に相談すべきボリュームまで、とっとと突き進みたい。

月商1000万円、達成するぞ。

第11回:すでに使っているE2Eテストと、これから詰めるべきテスト計画


すでに使っているE2Eテストと、これから詰めるべきテスト計画

1. はじめに

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

このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、スケジュール、品質管理、課題については記録している。

今回は、現状のテスト自動化と、今後のテスト計画について書く。

サービス開発では、機能を作るだけでは足りない。
作ったものが正しく動くか、ユーザーが迷わず使えるか、データが壊れないか、スマホでも問題なく使えるかを確認する必要がある。

特に今回のプロジェクトは、単なる静的ページではなく、ユーザー操作、データ更新、管理者機能、履歴、ランキング、通知、将来的な運用まで関わる。

そのため、テストはかなり重要なテーマになっている。


2. PlaywrightによるE2Eテストはすでに使っている

現時点で、E2Eテストにはすでに Playwright を使っている。

つまり、「これからE2Eテストを導入するかどうか」という段階ではない。
すでに、画面操作ベースで主要な導線を確認する方向には進んでいる。

Playwrightを使うことで、ブラウザ上で実際のユーザー操作に近い形の確認ができる。

たとえば、以下のような確認が対象になる。

  • 画面が表示されるか

  • ボタンやリンクが機能するか

  • 主要導線を通れるか

  • 入力・保存・表示が成立するか

  • 画面遷移が想定通りか

  • エラーで落ちないか

  • スマホ相当の表示で大きく崩れないか

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

単体テストでは、個別の関数や処理は確認できる。
しかし、実際にユーザーが画面を操作したときに流れが成立するかは、E2Eテストで確認した方が分かりやすい。


3. ただし、E2Eテストを増やしすぎる問題もある

一方で、E2Eテストは便利だが、増やしすぎると重くなる。

これはすでに意識している課題である。

E2Eテストは、実際のブラウザ操作に近い確認ができる反面、以下のような問題もある。

  • 実行に時間がかかる

  • テストが増えるとメンテナンスが重くなる

  • UI変更でテストが壊れやすい

  • テストコード自体の修正が必要になる

  • 本質的でない表示変更で失敗することがある

  • 開発スピードを落とす可能性がある

そのため、何でもPlaywrightで自動化すればよいとは考えていない。

重要なのは、どの導線をE2Eで守るかである。


4. E2Eで守るべきもの

現時点で、Playwrightで優先して守るべきなのは、サービス全体に影響する主要導線である。

具体的には、以下のようなものを優先したい。

優先度E2Eで確認したい対象
新規登録・ログイン後の主要導線
メイン画面が表示されること
基本操作の一連の流れ
重要画面で致命的なエラーが出ないこと
データ作成・更新・表示の基本流れ
管理者画面の基本操作
スマホ幅での主要導線
空データ時の表示
エラー時の最低限の復帰導線
細かい文言・装飾・演出

E2Eテストは、サービスの骨格を守るために使う。

逆に、細かい文言やデザインの微調整までE2Eで厳密に見ると、テストが壊れやすくなる。
そこは人手確認やレビューで補う方がよい。


5. 自動化できるものと、人手で見るべきもの

テスト自動化は重要だが、すべてを自動化できるわけではない。

Playwrightで確認しやすいのは、主に以下である。

  • 画面が開く

  • ボタンが押せる

  • 入力できる

  • 保存される

  • 遷移できる

  • エラーが出ない

  • 表示要素が存在する

  • 権限によって表示が変わる

一方で、人手で見た方がよいものもある。

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

  • 画面の雰囲気が伝わるか

  • 情報量が多すぎないか

  • 操作していて楽しいか

  • 文言が自然か

  • スマホでストレスがないか

  • サービスの魅力が伝わるか

  • また使いたいと思えるか

このあたりは、自動テストでは判断しにくい。

E2Eテストは「動くか」を見るには強い。
しかし、「使いたいと思うか」「分かりやすいか」「面白いか」は、人間が見る必要がある。


6. 現状の課題

現時点でのテスト面の課題は、主に以下である。

6.1 E2Eテストの対象範囲を広げすぎないこと

Playwrightを使っているからこそ、どこまで自動化するかを慎重に決める必要がある。

何でもE2Eに入れると、開発が重くなる。

そのため、まずは以下に絞りたい。

  • 壊れると致命的な導線

  • 毎回手動確認すると大変な導線

  • リリース判定で必ず確認したい導線

  • データ破損や権限ミスにつながる導線

逆に、頻繁に変わるUIや、体験の良し悪しに関わる部分は、人手確認を併用する。


6.2 テストデータの整備

E2Eテストでは、テストデータも重要になる。

データがない状態、データがある状態、権限が違う状態、管理者状態、通常ユーザー状態などをどう用意するか。

ここが曖昧だと、テストが安定しない。

今後は、以下を整理する必要がある。

  • E2E用のテストユーザー

  • 管理者テストユーザー

  • 初期データ

  • 空データ状態

  • 複数データ状態

  • 異常系データ

  • テスト後のクリーンアップ方針

E2Eテストは、シナリオだけでなく、データ設計もセットで考える必要がある。


6.3 スマホ確認の扱い

今回のサービスでは、スマホ対応が重要になる。

Playwrightでも、ビューポートを変えてスマホ相当の確認はできる。
しかし、実際のスマホでの操作感までは完全には分からない。

そのため、スマホについては以下を組み合わせる必要がある。

  • Playwrightでスマホ幅の主要導線を確認する

  • PCブラウザのレスポンシブ確認を行う

  • 実機スマホで人手確認する

  • プレオープンで実ユーザーの端末でも確認する

スマホは、画面サイズだけでなく、指で押しやすいか、スクロールしやすいか、情報量が多すぎないかも重要になる。

ここは人手確認がかなり重要になる。


6.4 AI生成コードの確認

AIを使って開発しているため、AIが生成したコードが意図通りかを確認する必要がある。

E2Eテストは、その確認にも役立つ。

ただし、E2Eが通ったからといって、すべて正しいわけではない。

  • 内部ロジックが本当に正しいか

  • 権限チェックが十分か

  • 想定外の操作に耐えられるか

  • データ整合性が保たれるか

  • 将来拡張に耐えられるか

こうした部分は、コードレビューや仕様確認も必要になる。

つまり、Playwrightは重要だが、品質保証の一部であって全部ではない。


7. プレオープンをテスト計画に組み込む

正式公開前には、プレオープンのような形で、少人数に触ってもらうことも考えている。

これは単なる宣伝ではなく、テストの一部として位置づけたい。

プレオープンで確認したいのは、以下である。

  • 初回ユーザーがどこで迷うか

  • どの画面で離脱するか

  • どの説明が足りないか

  • どの操作が分かりにくいか

  • スマホで問題なく使えるか

  • 想定外の使い方をされないか

  • 不具合報告が上がるか

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

  • 継続利用したいと思うか

作っている本人は、仕様を知っている。
だから、自然に操作できてしまう。

しかし、初めて触る人は違う。

そのギャップを確認するために、プレオープンは重要になる。


8. 今後詰めるべきテスト計画

今後は、テスト計画をさらに具体化する必要がある。

特に整理すべきなのは、以下である。

8.1 フェーズ別のテスト基準

一人用確認版、限定公開版、初期サービスイン版では、求める品質水準が違う。

フェーズテストの目的
一人用確認版自分が通しで触り、中心体験が成立するか確認
限定公開版少人数が迷わず使えるか、致命的不具合がないか確認
初期サービスイン一般ユーザーが使っても破綻しないか確認
収益化段階課金・運用・問い合わせ対応まで含めて確認

最初から正式公開レベルの品質を求めすぎると、開発が止まる。
ただし、致命的な不具合を放置したまま公開するわけにもいかない。

フェーズごとに、どこまで確認するかを決める必要がある。


8.2 自動テストと人手テストの分担

自動テストと人手テストの役割分担も明確にしたい。

確認内容方法
主要導線が通るかPlaywright
重要画面が落ちないかPlaywright
データ保存・更新が成立するかPlaywright+必要に応じて手動確認
権限チェックが効くかPlaywright+コード確認
スマホ幅で大きく崩れないかPlaywright+実機確認
初回ユーザーが迷わないか人手確認
文言が自然か人手確認
魅力が伝わるか人手確認
継続したいと思えるかプレオープン

この分担を決めておくことで、テスト自動化に過度な期待をせず、必要な人手確認も計画に組み込める。


8.3 不具合報告の導線

プレオープンや限定公開を行うなら、不具合報告の導線も必要になる。

最低限、以下を受け取れるようにしたい。

  • どの画面で起きたか

  • 何をしようとしたか

  • 何が起きたか

  • 使用端末

  • ブラウザ

  • 発生日時

  • スクリーンショット

  • 再現手順

最初から大きなサポートシステムを作る必要はない。
ただし、報告を受け取れる導線は必要である。


9. 現時点の方針

現時点でのテスト方針は、以下である。

  1. PlaywrightによるE2Eテストはすでに活用している

  2. ただし、E2Eの対象は主要導線に絞る

  3. テストを増やしすぎて開発を重くしない

  4. テストデータとテストユーザーを整理する

  5. スマホはPlaywright確認と実機確認を併用する

  6. UI/UXの良し悪しは人手確認を重視する

  7. プレオープンを実ユーザーテストとして活用する

  8. 不具合報告導線を整備する

  9. リリース判定チェックリストを作る

  10. 最終的な品質判断は人間が行う


10. 今回の結論

E2Eテストは、すでにPlaywrightを使っている。

その意味では、テスト自動化は未着手ではない。
すでに、画面操作ベースで主要導線を守る方向には進んでいる。

ただし、今後の課題は多い。

どこまでE2Eで確認するのか。
どこから人手で見るのか。
テストデータをどう作るのか。
スマホ実機確認をどう組み込むのか。
プレオープンをどうテスト計画に入れるのか。
リリース判定をどう行うのか。

これらを詰める必要がある。

自動テストは重要である。
しかし、自動テストだけでは、ユーザー体験の良し悪しは判断できない。

最終的には、Playwrightによる自動確認、人手による操作確認、プレオープンでの実ユーザー反応を組み合わせる必要がある。

月商1000万円を目指すなら、作るだけでは足りない。
安心して使えること、迷わず使えること、また使いたいと思えることが必要になる。

そのために、今後はテスト計画も本格的に詰めていきたい。

第10回:AIを活用するほど、プロジェクトマネジメントが重要になる


AIを活用するほど、プロジェクトマネジメントが重要になる

1. はじめに

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

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

今回は、AI活用とプロジェクトマネジメントの関係について書く。

最近は、ChatGPT、Cursor、GensparkなどのAIツールを使うことで、個人でもかなり大きなプロジェクトを進められるようになってきた。

実際、自分もAIをかなり活用している。

  • 企画整理

  • 要件定義

  • 仕様書作成

  • 開発指示

  • コード実装

  • デザイン検討

  • ブログ記事作成

  • 課題管理

  • 進捗整理

かなり多くの作業にAIを使っている。

ただ、使えば使うほど感じることがある。

それは、AIを使うほど、プロジェクトマネジメントが重要になるということだ。

自分はPMPの資格を持っている。
そのため、プロジェクトを進めるときに、スコープ、スケジュール、コスト、品質、リスク、コミュニケーション、ステークホルダー、変更管理などを意識する癖がある。

AIを活用する今の開発でも、この考え方はかなり役に立っている。

むしろ、人間のチームではなくAIを使うからこそ、プロジェクトマネジメントの重要性はさらに高まっていると感じている。


2. AIは優秀だが、勝手にプロジェクトを成功させてはくれない

AIは非常に優秀である。

文章も書ける。
コードも書ける。
仕様も整理できる。
デザイン案も出せる。
バグの原因も調査できる。
改善案も出せる。

しかし、AIは勝手にプロジェクト全体を成功に導いてくれるわけではない。

AIに何を任せるのか。
どこまで任せるのか。
どの順番で作業させるのか。
成果物をどう確認するのか。
どの判断を人間が行うのか。

これを決めるのは、結局プロジェクトを管理する側である。

AIは強力な実行者になり得る。
しかし、プロジェクトの目的、優先順位、制約条件、品質基準を理解させなければ、期待した成果は出ない。

つまり、AI活用とは、単に便利なツールを使うことではない。

AIという作業者を、どうプロジェクトに組み込むかという話である。


3. AIにも役割定義が必要

人間のチームでプロジェクトを進めるときは、役割分担を決める。

プロジェクトマネージャー、開発者、デザイナー、テスター、業務担当、運用担当。
それぞれの役割が曖昧だと、作業が重複したり、漏れたり、責任範囲が不明確になる。

AI活用でも同じである。

AIだからといって、何でも雑に投げればよいわけではない。

自分の中では、AIツールごとに以下のような役割を持たせている。

ツール主な役割
ChatGPT企画整理、要件整理、PMO、議事録、壁打ち、記事作成
Cursor実装、コード修正、既存コード調査、ドキュメント反映
Gensparkデザイン案、LP案、チラシ案、外向け表現の検討
追加PC実装・検証環境
既存PC思考・整理・指示文作成環境

このように役割を分けることで、AIを使いやすくなる。

ChatGPTには、抽象度の高い整理や判断の壁打ちを任せる。
Cursorには、具体的なコード実装や修正を任せる。
Gensparkには、見せ方やデザイン案を任せる。

役割が明確になると、指示も明確になる。

逆に、役割を決めずにAIを使うと、すべてが中途半端になる。


4. AI活用に必要なのは、指示の密度と精度

AIを使っていて強く感じるのは、指示の密度と精度が成果物の品質を大きく左右するということだ。

雑な指示を出せば、雑な結果が返ってくる。

たとえば、以下のような指示は危ない。

いい感じに直して
使いやすくして
不具合を直して
管理画面を作って
デザインを整えて

これでは、AIは何を基準に判断すればよいか分からない。

一方で、良い指示には、以下が含まれる。

  • 目的

  • 背景

  • 対象範囲

  • 触ってよいファイル

  • 触ってはいけないファイル

  • 完了条件

  • 優先順位

  • 制約条件

  • テスト観点

  • ドキュメント更新要否

  • 既存仕様との整合性

  • 失敗時の対応方針

ここまで書くと、かなりプロジェクト管理に近い。

つまり、AIに良い仕事をしてもらうには、プロジェクトマネジメント的な指示設計が必要になる。

AIは魔法ではない。
AIは、与えた前提と指示の中で動く。

だから、指示の密度と精度が重要になる。


5. スコープ管理がないと、AIは広げすぎる

AIは非常に多くの提案をしてくれる。

それ自体は便利である。

しかし、AIの提案をすべて採用していると、スコープがどんどん広がる。

今回のプロジェクトでも、要件はかなり増えている。
AIとの壁打ちによって、良い案もたくさん出てきた。
ただ、そのすべてを初期リリースに入れようとすると、永遠に完成しない。

ここで必要になるのが、スコープ管理である。

  • 今やるもの

  • 後でやるもの

  • 今はやらないもの

  • 実装しないもの

  • 要検討として残すもの

これを分ける必要がある。

AIはアイデアを広げるのが得意である。
しかし、プロジェクトを前に進めるには、広げるだけでなく絞る必要がある。

この「絞る判断」は、人間側のプロジェクトマネジメントで行う必要がある。


6. WBS的に分解しないと、AIにも任せにくい

大きな作業をAIにそのまま投げると、失敗しやすい。

たとえば、

サービスインできる状態にして

という指示では、範囲が広すぎる。

これを分解する必要がある。

  • 初回登録導線

  • メイン画面導線

  • 管理者画面

  • データ登録

  • 履歴表示

  • 通知

  • ランキング

  • スマホ対応

  • エラー表示

  • テスト

  • ドキュメント更新

さらに、それぞれを作業単位に分ける。

この考え方は、まさにWBSに近い。

AIを使う場合でも、大きな成果物を小さな作業に分解し、順序を決め、完了条件を設定する必要がある。

AIは作業を速く進めることはできる。
しかし、作業をどう分解するか、どの順序で進めるかを考えないと、成果物はバラバラになる。


7. 品質管理も人間側の責任

AIが出した成果物は、そのまま正しいとは限らない。

コードが動くように見えても、仕様とズレているかもしれない。
セキュリティ上の懸念があるかもしれない。
既存仕様を壊しているかもしれない。
画面は整っていても、ユーザー導線が悪いかもしれない。
ドキュメント更新が実装と矛盾しているかもしれない。

そのため、AI活用では品質管理が非常に重要になる。

自分が意識しているのは、以下である。

  • 実装後に差分を確認する

  • 既存仕様との矛盾を確認する

  • ビルドやテストを実行する

  • 画面で実際に確認する

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

  • 不要な変更が入っていないか確認する

  • 次の作業に影響がないか確認する

AIに任せたからといって、品質責任がAIに移るわけではない。

最終的な品質責任は、人間側にある。

これは、人間のチームでも同じである。
メンバーが作業しても、プロジェクトとして品質を担保する必要がある。

AIを使う場合も、そこは変わらない。


8. コミュニケーション管理も必要になる

AI相手でも、コミュニケーション管理は必要である。

むしろ、AI相手だからこそ、文脈管理が重要になる。

人間なら、前後の会話や空気で補ってくれることがある。
しかし、AIは文脈が不足していると、前提を取り違えることがある。

そのため、以下を明確にする必要がある。

  • 現在のプロジェクト状態

  • 今回の作業目的

  • 参照すべきドキュメント

  • 守るべきルール

  • 変更してよい範囲

  • 変更してはいけない範囲

  • 作業後に報告してほしい内容

  • 判断が必要な場合の扱い

これは、AIとのコミュニケーション設計である。

人間のプロジェクトでも、会議体、議事録、課題管理、進捗報告が必要になる。
AI活用でも同じように、指示、成果物、判断、残課題を記録する必要がある。

AIだから記録しなくてよい、ということにはならない。


9. AIを使うほど、変更管理が重要になる

AIを使うと、実装速度が上がる。

これは大きなメリットである。

しかし、実装速度が上がるということは、変更量も増えるということだ。

変更量が増えると、以下のリスクも増える。

  • 仕様と実装のズレ

  • ドキュメント更新漏れ

  • 既存機能の破壊

  • Git差分の肥大化

  • テスト不足

  • 影響範囲の見落とし

  • 不要なリファクタリング

  • 作業範囲の逸脱

だからこそ、変更管理が重要になる。

AIに作業させる場合でも、以下を管理したい。

  • 何を変更したのか

  • なぜ変更したのか

  • どのファイルを変更したのか

  • どの仕様に基づく変更なのか

  • テストは何を実施したのか

  • 残った課題は何か

  • 次にやるべきことは何か

AIによって変更速度が上がるほど、変更管理の重要性も上がる。


10. リスク管理も必要

AI活用には、リスクもある。

便利だからこそ、過信すると危険である。

現時点で意識しているリスクは、以下である。

リスク内容
仕様逸脱AIが意図と違う実装をする
過剰実装必要以上に機能を追加する
品質ブレコード品質や設計品質が安定しない
ドキュメント不整合実装と仕様書がズレる
セキュリティ懸念権限チェックや入力検証が不足する
依存しすぎ人間側が判断を放棄する
コスト増AIツール費用が膨らむ
作業競合複数PC・複数作業でGit競合が起きる

これらは、AIを使わなければ発生しないリスクもある。

だから、AI活用は単なる効率化ではなく、リスク管理もセットで考える必要がある。


11. PMPの考え方はAI活用にもかなり効く

PMPで学ぶプロジェクトマネジメントの考え方は、AI活用にもかなり効くと感じている。

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

  • スコープ管理

  • スケジュール管理

  • コスト管理

  • 品質管理

  • リスク管理

  • コミュニケーション管理

  • 資源管理

  • 変更管理

  • ステークホルダー管理

  • 統合管理

これは、人間のチームだけに使うものではない。

AIを使う場合でも、かなりそのまま使える。

AIは人ではない。
しかし、プロジェクトの中で成果物を生み出す存在である以上、管理対象になる。

人を管理するのとは違う。
ただし、役割を定義し、作業を割り当て、成果物を確認し、品質を担保し、変更を管理するという意味では、プロジェクトマネジメントの対象である。


12. AI時代のPMは、指示者ではなく編集者でもある

AI時代のプロジェクトマネジメントでは、PMの役割も少し変わると思っている。

従来のPMは、人に作業を依頼し、進捗を確認し、課題を管理し、リスクに対応する役割が中心だった。

AIを使う場合は、それに加えて、編集者のような役割が必要になる。

AIが出した案を、そのまま採用するのではなく、

  • 何を採用するか

  • 何を捨てるか

  • どこを修正するか

  • どこを深掘りするか

  • どこで止めるか

  • どの成果物を正式版にするか

を判断する。

AIは大量に出力できる。
だからこそ、取捨選択が重要になる。

この取捨選択こそ、AI時代のPMに必要な能力だと思う。


13. AIに任せる部分と、人間が握る部分

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

AIに任せやすいもの

  • 文章のたたき台

  • 仕様整理の初稿

  • コード実装

  • 既存コード調査

  • バグ原因の仮説出し

  • テスト観点の洗い出し

  • デザイン案の作成

  • ブログ記事の構成案

  • 課題一覧の整理

人間が握るべきもの

  • 最終的なサービス方針

  • 優先順位

  • 初期リリース範囲

  • 収益化判断

  • 品質基準

  • ユーザー体験の最終判断

  • 費用判断

  • リスク許容度

  • 公開タイミング

  • 何を捨てるかの判断

AIは優秀な補佐であり、実行者である。

しかし、プロジェクトの意思決定まで完全に委ねるのは危険である。

AIを活用するほど、人間側の判断軸が重要になる。


14. 今回の結論

AIを使えば、個人でも大きなプロジェクトを進められる可能性がある。

これは本当に大きな変化である。

しかし、AIを使えば勝手に成功するわけではない。

むしろ、AIを使うほど、プロジェクトマネジメントが重要になる。

  • 役割を定義する

  • スコープを管理する

  • 作業を分解する

  • 優先順位を決める

  • 指示の密度と精度を上げる

  • 成果物を確認する

  • 品質を管理する

  • 変更を管理する

  • リスクを把握する

  • コストを見直す

これらをやらなければ、AIを使ってもプロジェクトは散らかる。

自分はPMPの資格を持っている。
その知識や考え方は、今のAI活用型開発でもかなり役に立っている。

AIは人ではない。
しかし、プロジェクトの中で成果物を生み出す存在である以上、管理が必要である。

これからの個人開発では、単にAIを使えるかどうかだけではなく、
AIをプロジェクトの中でどう管理し、どう成果につなげるかが重要になると思っている。

月商1000万円を目指すこのプロジェクトでも、AIは重要な戦力である。

ただし、AIを使うだけでは足りない。
AIを活かすためのプロジェクトマネジメントが必要である。

今後も、PMPで培った考え方を活かしながら、AIを単なる便利ツールではなく、プロジェクトの一部として管理していきたい。

第9回:膨大な要件、膨大な仕様、膨大な残課題と向き合う

1. はじめに

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

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

今回は、膨大な要件、膨大な仕様、膨大な残課題について書く。

正直に言うと、今のプロジェクトはかなり大きくなってきた。

最初は、もう少し小さく始められると思っていた。
まず動くものを作り、そこから少しずつ広げればよいと考えていた。

しかし、考えれば考えるほど、必要な機能が増えていく。
ユーザー体験を考えると、この機能も必要になる。
運営を考えると、この管理画面も必要になる。
将来の拡張を考えると、このデータ設計も必要になる。
公開後のトラブルを考えると、このチェック機能も必要になる。

気づけば、要件も仕様も残課題も、かなり膨大になっていた。


2. 要件が膨らむのは悪いことではない

まず、要件が膨らむこと自体は、必ずしも悪いことではない。

むしろ、プロジェクトの解像度が上がってきた証拠でもある。

最初はぼんやりしていたものが、具体的に考えるほど、

  • どんなユーザーが使うのか

  • 最初に何を見せるべきか

  • どこで迷いそうか

  • どんな管理機能が必要か

  • どこで不正や不整合が起きそうか

  • どんなデータを残すべきか

  • どこまで自動化すべきか

  • どこに楽しさを作るべきか

が見えてくる。

その結果、要件が増える。

これは、プロジェクトが現実に近づいているということでもある。

ただし、問題はそこからである。

要件が増えたからといって、全部を今すぐ実装できるわけではない。
全部を初期リリースに入れようとすれば、いつまでも公開できない。

つまり、要件が膨らむこと自体よりも、膨らんだ要件をどう扱うかが重要になる。


3. 仕様が増える理由

要件が増えると、当然仕様も増える。

一つの機能を考えるだけでも、決めるべきことは多い。

たとえば、具体的な企画内容は伏せるが、一般的なWebサービスでも以下のような仕様が必要になる。

  • 誰が使えるのか

  • どの画面に表示するのか

  • どのボタンから操作するのか

  • 入力項目は何か

  • 入力チェックはどうするのか

  • 保存先はどこか

  • 編集できるのは誰か

  • 削除できるのか

  • 履歴を残すのか

  • 通知するのか

  • ランキングや集計に影響するのか

  • 管理者は修正できるのか

  • エラー時はどう表示するのか

  • スマホではどう見せるのか

  • 将来拡張できるのか

一つの機能でも、これだけ考えることがある。

そして、機能が10個、20個、50個と増えると、仕様は一気に膨らむ。

だから、仕様が膨大になるのは自然なことだと思っている。

問題は、仕様を頭の中だけで管理しようとすることだ。

それをやると、ほぼ確実に破綻する。


4. 残課題は増え続ける

さらに厄介なのが、残課題である。

残課題は、実装していない機能だけではない。

以下のようなものも残課題になる。

  • 仕様がまだ決まっていないもの

  • 実装方針を決める必要があるもの

  • 優先度を判断する必要があるもの

  • デザイン反映が必要なもの

  • スマホ対応が必要なもの

  • 管理者機能が必要なもの

  • テスト観点を追加する必要があるもの

  • ドキュメント更新が必要なもの

  • 一度実装したが改善が必要なもの

  • 後回しにしたが忘れてはいけないもの

つまり、残課題は単なるToDoリストではない。

プロジェクトの未確定部分、未完了部分、将来の改善候補、判断待ち事項がすべて集まる場所である。

この残課題が増え続けると、精神的にもかなり重くなる。

「まだこんなにあるのか」と思ってしまう。
「いつ終わるのか」と不安になる。
「これを全部作らないと公開できないのでは」と感じてしまう。

しかし、ここで大事なのは、残課題が多いこと自体を恐れすぎないことだと思っている。

残課題が見えているということは、少なくとも問題を認識できているということでもある。

本当に危険なのは、残課題がないことではなく、残課題を把握していないことである。


5. すべてを初期リリースに入れない

膨大な要件、仕様、残課題に向き合ううえで、今一番大事にしているのは、すべてを初期リリースに入れないということだ。

これは当たり前のようで、実際にはかなり難しい。

作っている本人からすると、どの機能も重要に見える。

「これがないと体験が弱い」
「これも最初からあった方がよい」
「これを後回しにすると後で手戻りになる」
「これがないと運営できないかもしれない」

そう考えているうちに、初期リリースの範囲がどんどん広がっていく。

だから、機能を以下のように分ける必要がある。

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

この分類がないと、すべてが重要に見えてしまう。

そして、すべてが重要に見えると、何も終わらなくなる。


6. ただし、後回しにしすぎても危険

一方で、最近感じているのは、後回しにしすぎても危険だということだ。

最初は、リリースを早めるために「これは後でよい」と判断することが多かった。

しかし、後回しにしたものの中には、実は先に作った方が効率がよいものもある。

たとえば、以下のようなものだ。

  • 後から入れるとデータ構造を変える必要がある機能

  • 他の多くの画面に影響する共通機能

  • 管理者が最低限確認するために必要な機能

  • 初回ユーザーの迷いを減らす導線

  • テストや確認を楽にする機能

  • 後の実装の前提になるデータ項目

これらを後回しにしすぎると、短期的には楽になる。
しかし、後で大きな手戻りになることがある。

だから、最近は単純に「初期リリースに必要か」だけでは判断しないようにしている。

次の観点も見る。

今作ることで、後工程が楽になるか。
後回しにすると、後で構造変更が必要になるか。
今やらないと、確認やテストが難しくなるか。

これを考えると、後回しリストの中から、前倒しすべきものが出てくる。


7. ドキュメントがなければ破綻する

ここまで要件や仕様が増えてくると、ドキュメントなしでは管理できない。

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

  • 企画概要

  • 要件定義書

  • 機能仕様書

  • 画面仕様書

  • データ設計書

  • ロジック設計書

  • API設計書

  • 管理者機能仕様

  • テスト観点一覧

  • リリース判定チェックリスト

  • 残課題一覧

  • 後回し機能一覧

  • 開発ルール

  • ユーザーマニュアル

  • 管理者マニュアル

個人開発としては、かなり多いと思う。

ただ、ここまで作らないと、もう管理できない規模になってきている。

特に、AIツールを使って開発している場合、ドキュメントは重要である。

AIに対して、
「この仕様に従って実装して」
「この残課題を解消して」
「この画面仕様に沿って修正して」
と依頼するには、前提となる資料が必要になる。

AIを使うほど、ドキュメントの重要性は上がる。


8. それでもドキュメント作成が目的化してはいけない

ただし、ドキュメントを作っていると、別の問題も起きる。

それは、ドキュメント作成そのものが目的化することである。

仕様書をきれいにする。
残課題一覧を整理する。
設計書を更新する。
ルールを整える。
チェックリストを作る。

これらは全部大事である。

しかし、ドキュメントをいくら整えても、サービスは動かない。

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

だから、最近は以下のルールを意識している。

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

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

  • 細かい表現修正に時間を使いすぎない

  • 残課題を整理したら、次の実装につなげる

  • ドキュメント更新後は、必ず「次に作るもの」を決める

ドキュメントは地図である。
地図を描くだけでは目的地に着かない。

地図を見ながら、実際に進む必要がある。


9. AIに任せるには、残課題の質が重要

今回のプロジェクトでは、CursorやChatGPTなどのAIツールをかなり使っている。

AIに作業を任せるうえで、残課題の書き方はとても重要である。

悪い残課題は、たとえばこういうものだ。

  • 画面をよくする

  • 管理機能を作る

  • スマホ対応する

  • いい感じに直す

これでは、AIに渡しても作業しにくい。

一方で、良い残課題は、以下が明確になっている。

  • 何を直すのか

  • どの画面か

  • どのファイルに関係するか

  • 完了条件は何か

  • 触ってはいけない範囲はどこか

  • テスト観点は何か

  • ドキュメント更新が必要か

AIに作業を任せるためには、残課題を単なるメモではなく、実行可能な作業単位にしていく必要がある。

これは地味だが、かなり重要な作業である。


10. 膨大な要件に押し潰されないために

膨大な要件、仕様、残課題を前にすると、正直、圧倒されることがある。

「これ、本当に完成するのか」と思うこともある。

しかし、全部を同時に見ると重すぎるだけで、分解すれば進められる。

今は、以下のように考えるようにしている。

  1. 全体像はドキュメントに逃がす

  2. 今やるべきことだけをP0に絞る

  3. 後でやることは後回し一覧に入れる

  4. 定期的に棚卸しする

  5. 実装しやすいものは前倒しする

  6. 迷ったら一人用確認版に必要かで判断する

  7. それでも迷ったら、サービスインに近づく方を選ぶ

重要なのは、全体の重さに押し潰されないことだ。

全部を今日終わらせる必要はない。
でも、今日進めるべき一つは決める必要がある。


11. 現在の一番大きな課題

現時点で一番大きな課題は、完成条件を明確にすることである。

要件が膨大になるほど、「完成」の定義が曖昧になる。

一人用確認版として何ができれば完成なのか。
限定公開版として何ができればよいのか。
初期サービスインとして何が必要なのか。
月商10万円を目指す段階では何を強化すべきなのか。

これを分けなければならない。

すべての要件を完成させることをゴールにすると、ゴールは永遠に遠ざかる。

だから、今は以下のように考えている。

すべてを完成させるのではなく、次のフェーズに進める状態を作る。

これが大事だと思っている。


12. 今回の結論

今のプロジェクトには、膨大な要件がある。
膨大な仕様がある。
膨大な残課題がある。

これは、正直かなり重い。

ただし、それはプロジェクトが現実に近づいてきた証拠でもある。

最初は見えていなかったものが、今は見えている。
だからこそ、要件が増え、仕様が増え、残課題が増えている。

問題は、それらを全部一気に終わらせようとすることではない。
問題は、それらを管理せずに進めることである。

今後は、以下を徹底したい。

  • 要件は捨てずに記録する

  • ただし初期リリースには入れすぎない

  • 仕様はドキュメント化する

  • 残課題は実行可能な単位にする

  • 後回し機能は定期的に棚卸しする

  • 実装に直結するものを優先する

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

  • ドキュメントだけで止まらず、実装を進める

月商1000万円までの道のりは、派手なアイデアだけでは進まない。
むしろ、こうした地味で膨大な要件、仕様、残課題と向き合い続けることが必要になる。

今はまだ、その途中である。

ただ、少なくとも、何が大変なのかは見えてきた。
そして、見えているものは、整理できる。
整理できるものは、少しずつ進められる。

まずは、目の前の一人用確認版を完成させる。
膨大な要件のすべてではなく、次の一歩に必要なものから形にしていく。

第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か月だけ試す価値はあるかもしれない。

フォロワー