週末48時間でMVPを作る｜会社員のための副業プロダクト設計術
金曜の夜から日曜の夜まで、48時間。これで最初のプロダクトを世に出すことができる。
平日は会社の仕事で手一杯で、帰宅すれば子どもの世話や家事が待っている。副業で何か作りたい気持ちはある。ずっとある。けれど、まとまった時間が取れない。気がつけば半年が経ち、一年が経ち、「いつか作る」が口癖になっている。そういう会社員は、驚くほど多い。
私が知っているある個人事業主は、会社員時代に最初のプロダクトを週末2日間で作ってリリースした。完璧ではなかった。コードは汚かったし、デザインも粗かった。それでも、公開した瞬間から世界の見え方が変わったと話していた。
この記事で伝えたいのは、根性論ではない。48時間という枠の中で、何を決め、何を捨て、何を作るかという設計の話だ。限られた時間で最初の一歩を踏み出すための、具体的な手順を書いていく。
この記事の前提
図: 48時間MVPの考え方
読者として想定しているのは、副業で何か自分のプロダクトを作りたいと思っている会社員だ。平日は9時から19時まで本業があり、通勤も含めれば自由に使える時間は夜の2時間程度。土日は家族との時間や家事もあり、副業にフルで使えるわけではない。
この記事のスタンスをはっきりさせておく。48時間でMVP(Minimum Viable Product、必要最小限の機能だけを備えた試作品)を作るというのは、完璧な製品を作ることではない。ユーザーが一人でも使える状態のものを世に出し、反応を見る。それだけを目的にする。
8割の完成度で出すのではない。3割の完成度で出す。その代わり、その3割は「本当に必要な3割」でなければいけない。ここの見極めが、48時間プロダクトの成否を決める。
もうひとつ。この記事は技術論ではなく設計論だ。コードを書ける人もそうでない人も読めるように書く。非エンジニアでも、ノーコード(コードを書かずにアプリを作れる仕組み)ツールを使えば48時間でプロダクトは作れる時代になった。
なぜ48時間という制約が必要なのか
時間が無限にあるプロジェクトは、ほぼ確実に失敗する。逆説的だが、これは副業プロダクトにおける鉄則だと思っている。
理由は三つある。
ひとつ目。時間が無限にあると、人は完璧を求めてしまう。機能をひとつ足し、さらにひとつ足し、デザインを三回やり直し、ロゴを二日考える。その間、ユーザーは一人も使っていない。フィードバックはゼロだ。
ふたつ目。副業の時間は、本業の疲れと戦いながら捻出する時間だ。気力が続くのは、せいぜい2〜3ヶ月。その間に何も形にならなければ、熱は冷める。熱が冷めたプロジェクトは、墓場に入る。
みっつ目。48時間という制約は、機能の削ぎ落としを強制する。「これも欲しい」「あれも欲しい」という誘惑を、時間がないという物理的な壁が遮断してくれる。制約は、創造性の敵ではなく味方だ。
ある個人事業主が私に話してくれたことがある。彼は最初の副業プロダクトを3ヶ月かけて作った。リリース時には機能が20個あった。実際に使われた機能は、そのうち2個だけだった。残り18個の開発時間は、ほぼ丸ごと無駄だったということになる。もし彼が最初に2個の機能だけで出していたら、3ヶ月ではなく1週間で世に出せたはずだ。
これが、48時間という縛りを自分に課す最大の理由だ。
48時間プロダクトの全体像
図: 48時間の時間割
具体的な時間割に入る前に、48時間の全体像を示しておく。
金曜の夜は、準備の時間だ。ここでは何も作らない。環境を整え、頭を空にして、翌朝からの48時間に備える。酒は飲まない。早めに寝る。本業の疲れを引きずったまま土曜の朝を迎えると、判断力が落ちる。
土曜の朝4時間は、決める時間だ。何を作るかではなく、何を作らないかを決める。ここが最も重要なフェーズだと言ってもいい。
土曜の午後6時間は、設計の時間だ。画面遷移、データ構造、使う道具の選定。手を動かし始める前に、地図を描く。
土曜の夜は休む。これも大事だ。徹夜は絶対にしない。判断力が落ちた状態でコードを書くと、日曜の午前中にすべて書き直すことになる。
日曜の午前6時間は、実装の時間だ。土曜に描いた地図に沿って、ひたすら手を動かす。
日曜の午後6時間は、仕上げとローンチの時間だ。バグを潰し、説明文を書き、最初のユーザーに届ける。
合計すると、正味の作業時間は22時間程度。睡眠と食事と家族の時間を差し引いた、現実的な時間配分だ。
土曜朝の4時間で決めること
多くの副業プロダクトが失敗するのは、コードを書き始める前の段階だ。土曜の朝、コーヒーを淹れ、ノートを開き、以下の四つを決めていく。
誰の、どんな困りごとを解くのか
対象ユーザーは、一人に絞る。「フリーランスのデザイナー」では広すぎる。「副業で月5万円稼ぎたい、子育て中のWebデザイナー」くらいまで狭める。
困りごとも、ひとつに絞る。「請求書管理が大変」ではなく「毎月末に5社分の請求書を手作業で作るのに2時間かかる」くらい具体的にする。
このとき、自分自身がユーザーだと最も強い。自分が使いたいものを作る。他人のために作ったプロダクトより、自分のために作ったプロダクトのほうが、続けられる確率が圧倒的に高い。
最小機能を三つに絞る
作りたい機能を全部書き出す。20個出てくるはずだ。そこから、絶対に必要な三つだけを残す。残りの17個は、別のノートに書き写して、目の前のノートからは消す。
三つの選び方には基準がある。この三つがなければ、ユーザーが困りごとを解決できないもの。つまり、これを削ると製品として成立しないもの。あったら便利、ではなく、なければ成立しない機能だけを残す。
課金するかしないかを決める
MVPの段階で課金機能を入れるべきか。答えはケースバイケースだが、私の意見としては、最初から100円でもいいから課金する仕組みを入れたほうがいい。
理由は、無料で使ってくれる人の数と、お金を払ってくれる人の数は、まったく別物だからだ。「無料なら使う」という人が100人いても、有料化した瞬間に99人が消える。これは副業プロダクトに限らず、どんなビジネスでも同じだ。最初から有料で出せば、1人でも払ってくれた瞬間にプロダクトが成立したことになる。
成功の定義を数字で決める
48時間後の日曜夜、何があれば「成功」と言えるのか。これを数字で決めておく。
たとえば、登録ユーザー1人。有料ユーザー1人。友人からのフィードバック3件。どれでもいい。数字で決めておかないと、終わった後に「これは成功だったのか失敗だったのか」が判断できなくなる。
私が知っているある人は、最初の副業プロダクトの成功基準を「知らない人から1円でも受け取ること」と決めていた。48時間後、彼は300円を受け取った。彼にとって、それは成功だった。
土曜午後の設計
朝4時間で方向が定まったら、昼食を取り、午後は設計に入る。
画面遷移を紙に描く
いきなりデザインツールを開かない。A4の紙とペンを用意し、画面を手描きする。四角を描き、その中にボタンや入力欄を描き、矢印で遷移を繋ぐ。
MVPの画面数は、3〜5画面に収める。トップ画面、機能を使う画面、結果を表示する画面。これで3画面。認証が必要ならログイン画面を足して4画面。それ以上増えるなら、機能を削りすぎていない証拠なので、朝のフェーズに戻って削り直す。
データ構造を決める
どんなデータを保存するか。これも紙に書き出す。ユーザー、投稿、タグ、コメント。それぞれのデータがどんな項目を持つか。箇条書きで十分だ。
ここで時間をかけすぎないこと。MVPのデータ構造は、後から必ず作り直すことになる。完璧を目指さず、動けばいい。
使う道具を決める
48時間で作るなら、道具選びは重要だ。新しいツールを学ぶ時間はない。すでに使ったことがあるものだけを使う。
フロントエンド(ユーザーが見る画面側)は、使い慣れたフレームワークで。データベース(情報をためておく倉庫)は、Supabaseのような無料枠で始められるものが便利だ。決済を入れるならStripeの決済リンクだけで十分で、複雑な実装は要らない。
AIを使ったプロダクトなら、Claude APIやOpenAI APIを直接叩く。独自にモデルを学習させようなどと考えない。既存の賢いAIの力を借りて、プロンプト(AIへの指示文)の工夫だけで価値を出す。これが現代の副業プロダクトの最短ルートだ。
ランディングページの構成を決める
実はプロダクト本体より、ランディングページ(サービスを紹介する1枚のページ)のほうが重要だったりする。どんなにいいプロダクトでも、伝わらなければ使われない。
ランディングページの構成は、昔からある型を踏襲する。見出し、サブ見出し、スクリーンショット、三つの価値、使い方、価格、問い合わせ。これだけでいい。ここに凝りすぎない。
参考になる事例
48時間、あるいはそれに近い超短期間でプロダクトを世に出した事例を、いくつか紹介する。
海外の個人開発者が72時間で作った家計簿アプリ
ある海外の個人開発者が、72時間で家計簿アプリを作って公開した話がある。機能はたったひとつ。レシートの写真を撮ると、AIが自動で金額と品目を読み取って記録する、というものだ。
彼が偉かったのは、この機能以外のすべてを切り捨てたことだ。カテゴリ分類、予算管理、グラフ表示、共有機能、どれもない。ただ撮るだけ。ただ記録するだけ。
公開初日のユーザーは50人。1ヶ月後には3,000人を超え、有料プラン(月額約600円)への移行者も現れ始めた。機能を絞ったからこそ、彼の本業の合間でもメンテナンスができた。これが副業プロダクトの理想形だと思う。
国内のフリーランスエンジニアが週末に作った請求書作成ツール
国内の事例もある。あるフリーランスエンジニアが、自分のために週末で作った請求書作成ツール。PDFを1枚出力するだけのシンプルなものだ。
彼は自分が月末に使うために作った。会計ソフトは多機能すぎて、自分の用途には重かったからだ。作ってみたら、同じような不満を持つ仲間が周りにいた。ツイートしたら、見知らぬ人から「使いたい」という反応が来た。
彼はそのツールを月額480円で公開した。1年後には数百人のユーザーが使っていた。彼はもともと副業のつもりだったが、本業の傍らで月数十万円の収入源になったそうだ。
自分の困りごとを解くために作ったものが、他人にも刺さる。これは副業プロダクトでよく起きる現象だ。ある個人事業主も同じことを言っていた。自分のかゆいところを掻くために作ったら、同じ場所がかゆい人が100人いた、と。
土日で作られたニッチな計算ツール
もうひとつ、土日の2日間だけで作られた計算ツールの話。ある分野の専門家が、自分の業務で使う計算式をブラウザ上で動くツールにした。数式を入力すると結果が出る、それだけのものだ。
同業者しか使わないので、ユーザー数は多くない。数百人規模だ。けれど、その数百人にとってはなくてはならないツールで、月額1,200円でも喜んで払う人たちだった。
ニッチだからこそ、大手は参入してこない。競合がいない。これが個人の副業プロダクトの勝ち筋だ。大勢に使われる必要はない。少数の人に深く刺されば、それで事業として成立する。
日曜午前の実装
土曜に設計ができていれば、日曜の実装は淡々とした作業になる。
最初の1時間は環境構築に使う
プロジェクトを新規作成し、使うライブラリを入れ、データベースに接続する。この1時間は、作るものの構造を指が覚え直す時間でもある。焦らず、丁寧に。
次の4時間で機能を作る
三つの機能を順番に作る。ひとつの機能が動いたら、次に進む。動かないまま次に行くと、あとでどこが原因でバグっているのか分からなくなる。
ここでClaude Codeのような開発補助ツールを使うと、体感3倍くらい速くなる。やりたいことを日本語で伝えるだけで、下書きが出てくる。副業エンジニアの時間を守る最強の味方だ。
非エンジニアなら、ノーコードツール(BubbleやGlideなど)を使う。同じことが、マウス操作だけでできる。道具は何でもいい。時間内に動くものが出れば勝ちだ。
最後の1時間でデプロイする
完成した機能を、インターネット上に公開する。VercelやNetlifyのような無料のホスティングサービスを使えば、数分で世界中からアクセスできる状態になる。
ここまでで日曜の午前が終わる。昼食を取り、少し散歩をする。頭を冷やす時間を必ず作ること。
日曜午後の仕上げとローンチ
午後は作る時間ではなく、届ける時間だ。
バグ潰しは2時間まで
ローンチ前にバグを見つけると、あれもこれもと直したくなる。そのまま日曜の夜が来て、結局ローンチできなかった、というのが最悪のパターンだ。
バグ潰しは2時間と決める。時間内に直せないバグは、既知の不具合としてリストに入れて、そのまま公開する。完璧を目指さない。動く、それだけを目指す。
ランディングページを書く
土曜に決めた構成に沿って、文章を流し込む。ここで時間をかけすぎる人が多いが、1時間で書ききる。文章は後からいくらでも直せる。
書き方のコツは、機能を説明しないこと。機能ではなく、ユーザーが得る結果を書く。「レシートをAIが読み取ります」ではなく「月末の家計簿が10分で終わります」と書く。ユーザーは機能を買うのではなく、変化を買うのだ。
最初の一人に届ける
公開したら、最初の一人に届ける。これが最も大事な仕上げの作業だ。
誰に届けるか。知り合いではない人がいい。知り合いは気を使って「いいね」と言ってくれる。それでは本当の反応が分からない。
私が知っているある人は、関連するオンラインコミュニティに顔を出して「こういうものを作りました、使ってみてフィードバックをもらえませんか」と丁寧に書き込んだ。3人が反応し、そのうち1人が有料プランに登録した。48時間の仕事が、1人の顧客という形で報われた瞬間だった。
日曜の夜に振り返る
ローンチが終わったら、ノートを開いて振り返りを書く。よかったこと、うまくいかなかったこと、次にやるべきこと。この3つを書くだけでいい。
ここで書いたメモが、翌週からの改善の種になる。48時間プロダクトは終わりではなく始まりだ。ここから本当の仕事が始まる。
よくある失敗・落とし穴
図: 失敗する人と成功する人
48時間プロダクトでよく見る失敗を、いくつか挙げておく。
ひとつ目は、土曜の午前に調べ物をしすぎることだ。どのツールがいいか、どのフレームワークが流行っているか。そんなことは48時間の中で決めることではない。普段から使っているものをそのまま使う。調べ物に午前を丸ごと使って、午後には何も進んでいない、という人を何人も見てきた。
ふたつ目は、デザインに時間を使いすぎること。色、フォント、余白、ロゴ。全部後回しでいい。動くことが先だ。白背景に黒文字でいい。機能が刺さるプロダクトなら、デザインがダサくてもユーザーは使う。
みっつ目は、認証機能に時間を使いすぎること。ログイン、サインアップ、パスワードリセット、メール認証。これらを自作すると半日消える。認証は、Supabaseなどのサービスが用意している機能をそのまま使う。もしくは、最初のMVPでは認証自体を入れない。URLを知っている人だけが使える、という形でも十分だ。
よっつ目は、完成した瞬間に満足して、公開しないこと。これが最も多い失敗だ。動くものができた、テストも通った、でも公開ボタンが押せない。誰かに見られるのが怖い。この心理的な壁を越えられないと、プロダクトは永遠に世に出ない。
いつつ目は、公開した翌日にプロダクトをいじり始めてしまうこと。48時間が終わったら、最低1週間は機能追加をしない。その間、ユーザーの反応を観察する。観察しないで次の機能を足すと、また17個の使われない機能を作る罠にはまる。
むっつ目は、家族との時間を無視すること。土日を全部プロダクトに使うと、家族から見放される。48時間のうち、家族の時間と食事と睡眠を差し引けば、実際に作業できるのは20時間そこそこだ。その制約の中でやりくりするのが、副業プロダクトのリアルだ。無理に24時間×2日を使おうとすると、続かない。
明日からやる3つのこと
最後に、この記事を読んだ人が明日から始められる3つのことを書いておく。
ひとつ。次の週末の48時間を、カレンダーで確保する。今週末が難しければ来週末でいい。家族にも「この週末は副業プロダクトを作る」と事前に伝えておく。宣言することで、逃げ場がなくなる。
ふたつ。自分が最近困ったことを、ノートに10個書き出す。家事のこと、仕事のこと、趣味のこと、何でもいい。その中から、自分が一番困っていて、かつ週末で解決できそうなものを一つ選ぶ。それが、あなたが作るべきプロダクトの種だ。
みっつ。まだ使ったことがないなら、Claude CodeやCursor、あるいはBubbleなどのノーコードツールのどれかを、平日の夜にインストールして触っておく。本番の48時間でツールの使い方を学ぶのは時間の無駄だ。平日のうちに指を慣らしておく。
会社員の副業に与えられた時間は、残酷なほど少ない。けれど、少ないからこそ集中できる。少ないからこそ、言い訳ができない。
48時間で作ったものは、たぶんダサい。たぶんバグだらけだ。それでも、作らなかった何百時間より、作った48時間のほうが尊い。公開した瞬間、あなたはもう「いつか作る人」ではなくなる。「作った人」になる。
来週の金曜の夜、酒を控えて早く寝てほしい。土曜の朝、ノートを開いてほしい。そして、48時間後に、最初のプロダクトを世に出してほしい。
そこから先の景色は、作った人にしか見えない。
