第1回：プロジェクト計画を公開用に整理する

1. はじめに

このブログでは、現在進めている新規プロジェクトについて、企画の中身そのものは公開せず、月商1000万円を目指すまでの進行記録を残していく。

扱うのは、以下のような内容である。

• プロジェクト計画

• 開発進捗

• 課題管理

• 意思決定の記録

• 仕様変更への対応

• リリース判断

• 収益化に向けた準備

• 運用体制の整備

いわば、公開できる範囲でのプロジェクト議事録であり、自分自身の思考整理、進捗確認、振り返りのための記録でもある。

プロジェクトの具体的な企画内容、サービス名、機能詳細、差別化要素などは、正式公開できる段階までは伏せる。
ただし、プロジェクトをどう計画し、どう進め、どこで悩み、どう判断していくかは可能な限り記録していく。

---

2. 目標

本プロジェクトの大きな目標は、月商1000万円を達成することである。

ただし、いきなり月商1000万円を目指すのではなく、段階的に到達する。

売上目標の段階

フェーズ	目標
フェーズ1	サービスの一人用確認版を完成させる
フェーズ2	限定ユーザーに使ってもらえる状態にする
フェーズ3	初期ユーザーを獲得する
フェーズ4	月商10万円を達成する
フェーズ5	月商100万円を達成する
フェーズ6	月商300万円を達成する
フェーズ7	月商1000万円を達成する

現時点では、売上そのものよりも、まずはサービスとして成立する土台を作ることを優先する。

---

3. プロジェクトの基本方針

今回のプロジェクトでは、最初から完璧なものを作るのではなく、以下の方針で進める。

3.1 小さく動くものを作る

最初から全機能を完成させようとすると、いつまでもリリースできない。

そのため、まずは最低限の流れが動く状態を作る。
ユーザーが登録し、基本操作を行い、サービスの価値を体験できる状態を優先する。

3.2 ドキュメントと実装を並行する

仕様書、設計書、残課題一覧、テスト観点などは重要である。
ただし、ドキュメント更新だけで満足してしまうと、サービスインには近づかない。

そのため、今後は以下を徹底する。

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

• 不要なドキュメント更新で止まらない

• 後回しにしすぎている機能は定期的に棚卸しする

• 実装可能なものは前倒しで進める

3.3 仕様変更を前提にする

新規サービスでは、途中で要件が変わることは避けられない。

大事なのは、要件変更をゼロにすることではなく、変更があってもプロジェクトが崩れないようにすることだと考えている。

そのため、以下を重視する。

• 変更理由を記録する

• 影響範囲を確認する

• 優先度を見直す

• 残課題一覧に反映する

• すぐ実装するものと後回しにするものを分ける

---

4. 現時点の重点テーマ

現在の重点テーマは、以下の通り。

4.1 一人用確認版の完成

まずは、管理者が細かく操作しなくても、最低限の流れを一人で確認できる状態を目指す。

この段階では、商用サービスとして完璧である必要はない。
しかし、サービスの核となる体験が確認できる必要がある。

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

• ユーザー登録後の基本導線

• 初回説明・ヘルプ導線

• 主要画面の流れ

• ゲームまたはサービス進行の基本サイクル

• 自動進行・手動進行の確認

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

• 最低限のランキング・通知・結果表示

4.2 サービスイン最短ルートの整理

全機能を完成させてから公開するのではなく、サービスインに必要な最短ルートを整理する。

今後は、機能を以下のように分類する。

区分	意味
P0	サービス成立に必須
P1	初期リリース時にかなり重要
P2	リリース後に強化
後回し	現時点では実装しないが、忘れないよう管理

ただし、後回し機能であっても、実装が簡単でサービス価値が高いものは前倒しする。

4.3 進捗率の見える化

今後は、作業完了時に以下を確認する。

• 現在地は全体の何％程度か

• 一人用確認版まであとどれくらいか

• 初期サービスインまであとどれくらいか

• 月商1000万円までのボトルネックは何か

感覚だけで進めるのではなく、進捗率と残作業を定期的に見直す。

---

5. 開発・運用ルール

現時点での開発ルールは以下の通り。

5.1 作業範囲を明確にする

複数の作業を同時に進める場合、作業範囲が重なると混乱する。

そのため、作業開始時には以下を明確にする。

• 今回触るファイル

• 今回触らないファイル

• 変更目的

• 完了条件

• テスト対象

• ドキュメント更新の有無

特に今後は、PCを複数台使った並行開発も視野に入るため、作業範囲の宣言や競合回避ルールが重要になる。

5.2 ドキュメントを更新しすぎない

ドキュメントは重要だが、更新作業だけで時間を使いすぎないようにする。

ドキュメント更新は、以下の場合に優先する。

• 仕様が変わった

• 実装方針が変わった

• 残課題が増えた

• 後で迷いそうな判断をした

• テスト観点に影響がある

逆に、実装に影響しない細かな表現調整は、必要以上に時間をかけない。

5.3 コンパイルチェックの要否を分ける

コード変更がある場合は、原則としてビルドやチェックを行う。

一方で、ドキュメント変更や素材フォルダの整理だけで、コンパイルに影響しないことが明確な場合は、毎回フルチェックしない運用も認める。

時間をかけるべきところと、省略してよいところを分ける。

---

6. 現時点の課題

現時点での大きな課題は、以下である。

6.1 要件が広がり続けている

プロジェクトを考えるほど、追加したい機能や改善案が増えている。

これは悪いことではない。
サービスの解像度が上がっている証拠でもある。

ただし、すべてを初期リリースに入れようとすると、リリースが遠のく。

今後は、以下を徹底する。

• 重要な構想は捨てずに記録する

• ただし初期リリース範囲は絞る

• 実装しやすいものは前倒しする

• 重いものは後回しにする

• 後回しにした理由を残す

6.2 ドキュメント作業が増えすぎるリスク

仕様整理を重視しているため、ドキュメントが増えている。

しかし、ドキュメントが増えるほど、更新漏れや重複も起きやすくなる。

今後は、ドキュメントの役割を整理し、以下を避ける。

• 同じ内容を複数ファイルに重複記載する

• 実装に使われない文書を作りすぎる

• 残課題が分散する

• 最新情報がどこかわからなくなる

6.3 完成基準が曖昧になりやすい

新規サービスでは、「どこまで作れば完成か」が曖昧になりやすい。

そのため、今後は以下の完成基準を分けて考える。

• 一人用確認版の完成

• 限定公開版の完成

• 初期サービスイン版の完成

• 収益化開始版の完成

• 本格拡張版の完成

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

---

7. 今後の進め方

今後は、以下の流れで進める。

7.1 まず一人用確認版を完成させる

最優先は、一人でサービスの基本体験を確認できる状態にすること。

ここでは、完成度よりも、流れが通ることを重視する。

7.2 次に限定公開できる状態を作る

一人用確認版ができたら、次は少人数に触ってもらえる状態を目指す。

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

• 初回説明

• ユーザー導線

• 不具合報告導線

• ヘルプ

• 最低限の運用管理

• データ破損や不正操作への対策

• スマホでの最低限の見やすさ

7.3 その後、収益化導線を検討する

サービスとして使える状態になった後、収益化を検討する。

収益化の方法は、現時点では固定しない。
ユーザー体験を壊さず、継続的に運営できる形を検討する。

---

8. 今回の決定事項

今回の整理で、以下を決定した。

1. 月商1000万円までの進行記録をブログに残す

2. 企画内容そのものは公開しない

3. ブログでは、プロジェクト計画・進捗・課題・判断を扱う

4. まずは一人用確認版の完成を最優先にする

5. ドキュメント更新だけで止まらず、実装を前に進める

6. 後回し機能も棚卸しし、実装しやすいものは前倒しする

7. 進捗率と残作業を定期的に見える化する

8. 開発作業の範囲宣言・競合回避ルールを整備する

---

9. 次回までのアクション

次回までに確認・整理したいことは以下である。

• 一人用確認版の完成条件を明文化する

• 現在の進捗率を見積もる

• P0 / P1 / P2 / 後回し機能を再整理する

• サービスイン最短ルートを作る

• 並行開発時の作業ルールを整理する

• ブログ公開用の進捗テンプレートを作る

---

10. 最後に

月商1000万円という目標は簡単ではない。

ただ、いきなり大きな売上を狙うのではなく、まずはサービスとして成立するものを作る。
そのうえで、ユーザーに価値を届け、改善し、運用し、収益化していく。

このブログでは、その過程をできるだけ正直に記録していく。

成功した判断だけでなく、迷ったこと、失敗したこと、後回しにしたこと、やり直したことも残す。

これは単なる開発記録ではなく、
月商1000万円を目指すプロジェクトの進行議事録である。