SECTION 01
個人開発の要件定義は「何を捨てるか」を決める作業
要件定義と聞くと、大企業の分厚いドキュメントを連想する人が多いと思います。仕様書をきっちり書いて、レビューを通して、承認をもらって…。個人開発でそれをやると、書くだけで疲れて実装が止まります。
自分がこれまでサービスを何十個も作ってきた中で気づいたのは、完成率を分けるのは「何を作るか」ではなく「何を捨てるか」の判断だということです。機能を積み上げるほど完成から遠ざかります。
思いついた案をそのまま実装しようとする人は多いですが、頭の中だけで進めると必ず肥大化します。「これもあったら便利」「あれも入れたい」が止まらなくなり、着手した瞬間から工数が見えなくなるのです。
だから個人開発における要件定義は、機能リストを増やすことではなく、思いついた案をどこまで削れるかの判断作業です。削ることを設計の中心に置けるかどうかで、完成率が大きく変わります。
要件定義を「重い工程」ではなく「一人で完成率を上げるための削る技術」として捉え直す。これが、個人開発でMVPを出し切るための第一歩になります。
SECTION 02
作る前に決めるのは3つだけ：最小要件の判断軸
要件を決めるとき、最初に言語化すべきことはたった3つです。「誰の」「どんな問題を」「どう検証するか」。これだけを明確にしてから手を動かします。
多くの人が機能一覧から考え始めますが、それだと「誰にとって何が解決されるか」が曖昧なまま進んでしまいます。完成しても使われないプロダクトになるパターンの大半が、ここに原因があります。
最小要件を決めるときに自分が使っている問いがあります。
- 「ログイン不要で成立するか」を問うと、初期に不要な機能が自然に落ちる
- 「なくても最初は動くか」で全機能を仕分けられる
- 「これが売れる理由はあるか」を要件段階で確認できているかが分岐点になる
特に「ログイン不要で始められるか」は強力な判断基準です。摩擦の少ない体験を最初から要件に組み込むことで、何を捨てるかの判断に一貫性が出ます。認証機能、管理画面、通知設定…ログインが前提の機能は初期から全部落とせることが多いです。
「売れるプロダクトに必要な何か」が入っているかを要件定義の段階で問えているかどうか。これは自分が何十回も開発してきた中でたどり着いた確信です。機能を足したり削ったりする前に、そもそもの方向が合っているかを確認する場が、要件定義なのです。
SECTION 03
MVPで残す機能・捨てる機能の線引き方法
機能の取捨選択は「なくても最初は動くか」という問いをすべての機能に対して投げかけることから始まります。答えが「はい」ならMVPから外す。シンプルですが、これだけで初期スコープは大きく絞れます。
ここで注意したいのは、完成形を初期に盛り込む誘惑です。「いずれ必要になるから」「あとから追加するより最初から入れたほうが楽」という判断は、ほぼ間違いなく失敗につながります。
自分自身、要件の軸がズレたまま実装を進めてしまった経験があります。「何を作るか」の判断がブレたまま走った結果、方向転換を強いられました。着手前に判断を変えるコストと、完成してからズレに気づいて修正するコストでは、後者が圧倒的に大きいです。
完成形を盛り込みたくなったときに使える問いリストがあります。
- その機能がなくても、ユーザーはコアの価値を体験できるか
- その機能は「あったら便利」と「ないと成立しない」のどちらか
- その機能を後から追加するコストは、本当に今入れるより高いか
この問いを一つずつ通すだけで、初期に入れる機能は驚くほど減ります。残った機能がMVPの本体です。削ったものはリストとして残しておけば、公開後に必要性が確認できたタイミングで戻せます。
SECTION 04
アプリ開発向け・軽量要件定義テンプレート
自分の要件定義の起点は、Google Keepへの断片メモです。アイデアが浮かんだらとりあえず短く書き出す。頭の中だけで整理しようとしても絶対に漏れるし、全部を同時に考えようとすると何も決まりません。
外に出して並べてから「これって本当に初期から必要か？」を一個ずつ問い直す。これが自分にとっての要件定義の実態です。どこかに書かないと思考が内側でぐるぐる回るだけで、削る判断ができません。
設計書は書きません。代わりにこの5項目だけ埋めるようにしています。
- 誰の問題か：ターゲットを一文で書く
- 何を解決するか：課題を一文で書く
- どう検証するか：公開後に何を見て判断するかを決める
- MVP機能リスト：最小限の機能を箇条書きにする
- やらないことリスト：意図的に外した機能とその理由を書く
特に「やらないことリスト」が重要です。なぜ外したかの理由を書いておくと、あとから「やっぱり入れようかな」と迷ったときに立ち戻れます。理由なく削ると、同じ議論を何度もやり直すことになります。
また、要件定義を一人で進めるのが難しいと感じる方には、自分が作った無料サービスDoc Builderもおすすめです。AIが質問を投げかけてくれるので、対話形式で答えていくだけで抜け漏れなく仕様を整理できます。一人だと見落としがちな観点も、質問されることで自然と考えが及ぶようになります。
AIに要件整理を手伝わせるのは有効ですが、AIが出した要件をそのまま採用すると危険です。AIは「あったら便利」な機能をどんどん提案してくるので、むしろスコープが広がりやすい。AIには壁打ち相手として問いを投げてもらい、最終的な取捨選択は自分でやるのが安全です。
AIを使うなら「この要件リストから削れるものを指摘して」という使い方がおすすめです。足す方向ではなく、削る方向で使うとスコープの膨張を防げます。
SECTION 05
要件定義と技術選定、どちらを先に決めるか
原則は要件が先、技術は後です。何を作るかが決まっていないのに技術を選ぶと、技術の都合に要件が引きずられます。「この技術を使いたいから」という理由で不要な機能が増えるのは、よくある落とし穴です。
ただし個人開発では、「自分が速く書ける技術」が正解になる場面もあります。チーム開発なら最適な技術を選ぶべきですが、一人なら開発速度がすべてです。使い慣れた技術で最速で出すほうが、理想の技術スタックで未完成のまま放置するよりずっといい。
判断の順番としては、こう考えています。
- まず要件を最小限に絞る
- その要件の複雑さに対して、自分が最速で実装できる技術を選ぶ
- 要件が複雑なら技術もそれに合わせるが、MVPの段階ではほぼ使い慣れたもの一択
要件がシンプルなのに重厚な技術スタックを選ぶのは明確なアンチパターンです。逆に、要件が複雑なのに無理にシンプルな技術で押し通そうとするのも破綻します。要件の複雑さと技術の複雑さのバランスを取ることが大事です。
個人開発においては技術選定に時間をかけすぎないこと自体が重要です。技術の比較検討に数日かけるくらいなら、使い慣れたもので作り始めたほうが結果的に早い。技術選定は要件が固まったあとに、最短で判断します。
SECTION 06
出してから育てる：公開後に要件を更新する回し方
要件は最初に全部決めるものではありません。動かしながら更新するものです。だから初期の要件定義はできるだけ薄くして、出してから学んで足す、というサイクルを回すほうが合っています。
自分が運営していたMENTA（メンターとメンティーをつなぐマッチングサービス）がいい例です。コミュニティ機能やフリーランス月額契約機能は、最初の要件には入っていませんでした。動かしながら「これがあればもっと使われる」という仮説が生まれ、そこから追加しました。
公開後のフィードバックを次の要件に反映するときの判断基準は、こう整理しています。
- その要望は複数のユーザーから出ているか、一人だけの声か
- その機能を足すことでコアの価値が強まるか、ただの便利機能か
- 今の開発リソースで無理なく追加できるサイズか
一人のユーザーの強い要望に引っ張られて機能を足すと、プロダクトの方向性がブレます。複数の声が重なったときに初めて検討する、くらいの慎重さがちょうどいいです。
初期要件を薄くすることに不安を感じる人もいると思いますが、出してみないと分からないことのほうが圧倒的に多いです。机上で完璧な要件を作ろうとするより、最小構成で出して実際の反応を見るほうが、結果的に正しい要件にたどり着けます。
SECTION 07
アプリ開発で止まらないタスク分解の粒度
要件が決まったら、次はタスク分解です。個人開発では1回あたりの作業時間が短いことが前提になります。まとまった時間が取れない中で進めるには、タスクの粒度が鍵を握ります。
自分が意識しているのは、1回30分で手が動くサイズに分解することです。「ログイン画面を作る」では大きすぎます。「メールアドレスの入力フォームを1つ置く」くらいまで刻むと、30分の隙間時間でも確実に進みます。
中断・再開が多い開発で迷わないためのタスク設計のポイントはこうです。
- タスク名を見ただけで何をすればいいか分かる粒度にする
- 完了条件を一文で書けるサイズにする
- 前回どこまでやったか思い出す時間がゼロになるように分ける
タスクが大きいと、再開するたびに「どこまでやったっけ」を思い出す時間がかかります。この思い出しコストが積み重なると、やる気が削がれて手が止まります。粒度を細かくするだけで、このコストはほぼゼロになります。
もう一つ大事なのは、途中で捨てる判断をいつ下すかです。作り始めてから「これは思ったより大変だ」と気づくことはよくあります。そのとき、完成にこだわるか、損切りするかの判断を先延ばしにしない。判断基準は「あと何時間で出せるか」が見えるかどうかです。
SECTION 08
スコープが膨張するタイミングと防ぎ方
要件を決めてタスクに分解しても、実装中にスコープが膨張することがあります。コードを書いていると「ここ、もうちょっと良くしたい」「この機能もついでに入れよう」という誘惑が次々に湧いてきます。
スコープが膨張しやすい危険なタイミングは決まっています。
- 実装がノッてきて気持ちよくコードを書いているとき
- 他のプロダクトの良い機能を見て刺激を受けたとき
- ユーザーから最初のフィードバックをもらって興奮しているとき
どれも前向きな感情のときに起きるのが厄介です。「良いアイデアだから入れるべき」という気持ちと、「今入れるべきか」という判断は別物です。良いアイデアでも、MVPの段階で入れるべきとは限りません。
自分がやっている対策は、思いついた機能は全部「やらないことリスト」に一旦入れるというルールです。実装中に浮かんだアイデアは、メモに残して今は手を出さない。公開後に本当に必要だと確認できてから取り出します。
「あとで追加するのは大変だから今やろう」はほぼ嘘です。今入れて完成が遅れるコストのほうが、あとから追加するコストよりはるかに高い。MVPの最大の敵はスコープの膨張であり、それを防ぐ仕組みを要件定義の段階で作っておくことが大事です。
SECTION 09
AIを使った要件整理の実践と注意点
最近はAIとの対話で機能一覧やユーザーストーリーを作る人が増えています。要件整理の心理的ハードルが下がったのは間違いなく良い変化です。一人で壁打ちするより、AIに問いを投げてもらうほうが思考が整理されやすい。
ただし、AIが出力した要件を無批判に採用すると危険です。AIは「あったほうがいい機能」を網羅的に出してくるので、そのまま受け取るとスコープが一気に広がります。AIの出力は「全部入り」の状態なので、そこから削る作業が本番です。
AIを要件整理に使うときの効果的な使い方はこうです。
- 自分が書いた要件に対して「削れるものはどれか」を聞く
- 「この機能がないと成立しない理由は？」と問い返してもらう
- ユーザーストーリーを出してもらい、本当に初期から必要なものだけ選ぶ
足す方向ではなく削る方向でAIを使うのがポイントです。「他に必要な機能はある？」と聞くと際限なく増えます。「このリストから外せるものは？」と聞くと、自分では気づかなかった不要な機能に気づけます。
先ほど紹介したDoc Builderも、この「AIに問いを投げてもらう」アプローチで作ったサービスです。自分から要件を書き出すのではなく、AIから質問される形式なので、抜け漏れなく仕様を考えていけます。要件定義が苦手な人でも、質問に答えていくだけで自然と整理が進みます。
AIは優秀な壁打ち相手ですが、最終判断は必ず自分でやる。これが個人開発の要件定義でAIを使うときの鉄則です。判断を外注した瞬間に、プロダクトの方向性のコントロールを失います。
SECTION 10
最小構成で出し切るための要件定義まとめ
個人開発の要件定義は、削る技術です。何を作るかより、何を捨てるかの判断が完成率を決めます。頭の中で考え続けるのではなく、外に出して一つずつ問い直すプロセスが必要です。
最小要件を決める判断軸を改めて整理します。
- 「誰の・どんな問題を・どう検証するか」の3つだけを言語化する
- 「ログイン不要で成立するか」で不要な機能を落とす
- 「なくても最初は動くか」で全機能を仕分ける
- 「やらないことリスト」を作って、スコープの膨張を防ぐ
設計書は要りません。5項目のテンプレートを埋めるだけで十分です。誰の問題か、何を解決するか、どう検証するか、MVP機能リスト、やらないことリスト。これだけ埋めれば、あとは手を動かすだけです。
初期要件は薄くていい。出してから育てるのが個人開発の正解です。MENTAで公開後に機能を追加して成長させた経験が、「最初に全部決めなくていい」という結論を裏付けています。
要件定義に時間をかけすぎるのも、まったくやらないのも間違いです。最小限の判断を、最短でやる。それが個人開発で完成率を上げるための要件定義のあり方です。
