メイカーの資産、コードが消えても残るもの

コードは6か月でレガシーになるが、メイカーの資産は一生続く。

最初のコードは消えたのに資産は10倍になった理由

イ・ジュノさんの最初のMVPのコードは、今やほぼ読めません。リリース後6か月経ったとき、彼は自分の書いたログイン関数を見て独りごちました。「これは何だ? 自分でこんなに複雑に書いたのか?」

でも逆説的に、彼の資産はその期間で10倍以上に増えました。

最初のMVPで得た5人の有料ユーザーは、今や信頼できるアドバイザー。自動化スクリプトは「これは次にやらない」というルールに。最初はわからなくて時間を浪費したSupabase、Vercel、Linearの組み合わせは、手に馴染んだワークフロー。何より、「二度作ってみた人」になって得た信用と経験が、彼をコミュニティで目立つ人にしました。

コードは古びて消えるかもしれません。でもこの資産たちは残り、次をとても速くしてくれます。

メイカーの5つの資産

資産1. コード:動いたパターンの地図

コード自体はレガシー。でもコードが残したものは違います。「この技術はこんなふうに動く」というパターン自体が資産です。

イ・ジュノさんの極端な例。最初のMVPで体験した「多言語処理バグ」が、まったく違うドメインの2回目のプロジェクトでも同じ形で現れました。最初に6時間かかったデバッグが、2回目では30分で終わった。パターンをすでに見ていたからです。

資産2. 関係:信頼できる人のネットワーク

最初のMVPリリース後、パクさんをDMで探した人は100人。アクティブ30人。本当に大切だったのは5人。毎週フィードバックをくれて、機能を一緒に考え、自分のネットワークにパクさんを紹介してくれました。

2年後、パクさんが5本目のMVPを企画するときいちばん最初にしたことは何か? この5人へメッセージ。3人がすぐ反応、2人がテストを名乗り出る、1人が友達紹介。すでにあなたを信じている人がいるのです。

冷たく集めた顧客100人の月3回以上アクティブ率は37%。コミュニティで温かく紹介された顧客40人のアクティブ率は68%。

資産3. ノウハウ:罠の地図と迂回路

パクさんは最初のMVPでデータベーススキーマを過剰設計しました。カラムを3回修正、マイグレーションに2日浪費。振り返り文書:「次回はMVP段階で『必要不可欠なもの』だけ入れて、ユーザーフィードバック後に追加しよう。」

2回目のMVPで同じ過程を繰り返しませんでした。最初から「フィードバック後に追加」と「今絶対必要」を区別。初期スキーマは50%シンプル、マイグレーションコストは最低限。

資産4. ツールとワークフロー:検証済みの組み合わせ

ほとんどのメイカーは2回目でも「もっと良いツールがあるかも」とまた試して3〜5日を浪費。パクさんは違いました。最初で「この組み合わせは本当に動く」と知っていたから、2回目も同じツール。設定は再利用。Figmaライブラリ満載、Supabaseすぐ接続、Cursor設定自動ロード。

さらに、パクさんは最初で「このツールは自分のワークフローに合わない」ことも学びました。最初に計画していた管理ツールをやめ、2回目は最初からLinearだけ。選択肢が減って集中力が上がった。

資産5. 習慣と評判:メイカーとしての信用

5年で3つのMVPを作ったという事実自体が資産。コミュニティでの信用に変換されます。クォン・ドオン氏がDisquiet 3年振り返りで言ったように、「結局メイカーとしての信用が次のチャンスをもたらす」。

1回作ってみた人より、2回、3回作ってみた人のアドバイスのほうが説得力があります。あなたがメンターになり、ネットワークがもっと大きくなります。

意識して資産を積み上げる方法

5つの資産は自動では積み上がりません。意識的な記録と観察が必須です。

パクさんは最初のMVP開発中、毎晩10分で3つを記録しました。

1. 今日何が動いたか:「API連携成功」「ログインフロー完成」
2. 何が詰まったか:「スキーマ設計に2時間」「Figmaフィードバック1時間」
3. 次に違うふうにすること:「フィードバック前にスキーマ確定」「プロトタイプ前にデザイン同意」

運用中も記録を続ける。「この機能は誰も使わない」「この部分3回変えた」「ここがバグがいちばん多い」こうしたデータが次のMVPのチェックリストになります。

「資産積み上げはMVPが終わったあとでいい」と思うとダメ。いちばんいい記録は開発中に作られます。あとでは記憶がぼやけます。

資産が次のMVPを5倍速くするシミュレーション

1年投資:210時間(最初のMVPだけを繰り返したら400時間)。

でももっと大事なのは時間短縮ではなく、5つの「累積された資産」。あなたの信用は5倍、ネットワークは25人の信頼できる人で満たされます。

コード vs 資産、6か月 vs 一生

コード:

• 技術変化で古くなる(React → Vue、Node → Rust)
• 自分でも読めなくなる
• 次のプロジェクトに物理的に貼り付けられない

資産:

• 時間が経つほど価値が高くなる
• ドメイン知識とパターン認識はいつでも有効
• あなたの働き方に染み込む(自動化された習慣)

パクさんが5年後10本目のMVPを作るときも、最初のMVPのコードは使えないでしょう。でも最初で学んだ「良い企画は時間を食べ、悪い企画は開発中に時間を買う」というノウハウは今も有効です。

コードは資産ではありません。コードが残した経験、パターン、関係、信用が資産です。

資産積み上げチェックリスト

コードとパターン

• もっともよく使ったライブラリTop 3
• 次に再利用するアーキテクチャ
• 避ける設計パターン

関係とネットワーク

• もっとも役立った初期ユーザー5人
• 紹介できるコミュニティ2つ
• 協業者

ノウハウ

• もっとも無駄になった時間(理由、次は)
• もっとも修正した部分
• 誰も使わなかった機能

ツールとワークフロー

• 最終ツールスタック
• 使わないツール
• 設定スクショの保存有無

信用と評判

• ProductHunt/コミュニティの反応
• フォロワー増加
• 次のチャンスの扉

まとめ

メイカーの資産は見えませんが、いちばん確実です。コードは消えても、あなたの経験と信用は残ります。

でも注意することがあります。資産が多ければ多いほど、あなたを自己欺瞞させることもある。「もう経験したから今回は違ってもいい」という考え。次の記事では1年、3年、10年を続けるメイカーの違いを扱います。

前の記事:各MVPのライフサイクル
次の記事:1年・3年・10年、メイカーで生き残る方法

登場人物(パク・ソヨン、イ・ジュノ)について
登場人物はフェイルスクールが作った架空のペルソナです。ただしDisquiet、クォン・ドオン氏の振り返り、GitHub生産性レポートはすべて実在のものです。

キム・ミンチュル、Freeive CEO、フェイルスクール