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. 膨大な要件に押し潰されないために
膨大な要件、仕様、残課題を前にすると、正直、圧倒されることがある。
「これ、本当に完成するのか」と思うこともある。
しかし、全部を同時に見ると重すぎるだけで、分解すれば進められる。
今は、以下のように考えるようにしている。
全体像はドキュメントに逃がす
今やるべきことだけをP0に絞る
後でやることは後回し一覧に入れる
定期的に棚卸しする
実装しやすいものは前倒しする
迷ったら一人用確認版に必要かで判断する
それでも迷ったら、サービスインに近づく方を選ぶ
重要なのは、全体の重さに押し潰されないことだ。
全部を今日終わらせる必要はない。
でも、今日進めるべき一つは決める必要がある。
11. 現在の一番大きな課題
現時点で一番大きな課題は、完成条件を明確にすることである。
要件が膨大になるほど、「完成」の定義が曖昧になる。
一人用確認版として何ができれば完成なのか。
限定公開版として何ができればよいのか。
初期サービスインとして何が必要なのか。
月商10万円を目指す段階では何を強化すべきなのか。
これを分けなければならない。
すべての要件を完成させることをゴールにすると、ゴールは永遠に遠ざかる。
だから、今は以下のように考えている。
すべてを完成させるのではなく、次のフェーズに進める状態を作る。
これが大事だと思っている。
12. 今回の結論
今のプロジェクトには、膨大な要件がある。
膨大な仕様がある。
膨大な残課題がある。
これは、正直かなり重い。
ただし、それはプロジェクトが現実に近づいてきた証拠でもある。
最初は見えていなかったものが、今は見えている。
だからこそ、要件が増え、仕様が増え、残課題が増えている。
問題は、それらを全部一気に終わらせようとすることではない。
問題は、それらを管理せずに進めることである。
今後は、以下を徹底したい。
要件は捨てずに記録する
ただし初期リリースには入れすぎない
仕様はドキュメント化する
残課題は実行可能な単位にする
後回し機能は定期的に棚卸しする
実装に直結するものを優先する
一人用確認版の完成条件を明確にする
ドキュメントだけで止まらず、実装を進める
月商1000万円までの道のりは、派手なアイデアだけでは進まない。
むしろ、こうした地味で膨大な要件、仕様、残課題と向き合い続けることが必要になる。
今はまだ、その途中である。
ただ、少なくとも、何が大変なのかは見えてきた。
そして、見えているものは、整理できる。
整理できるものは、少しずつ進められる。
まずは、目の前の一人用確認版を完成させる。
膨大な要件のすべてではなく、次の一歩に必要なものから形にしていく。
0 件のコメント:
コメントを投稿