【徹底検証】「100点満点中30点で一度Done→ブラッシュアップ」は「Done is better than nothing」の最強実践法なのか？

結論：かなり「アリ」。むしろ「Done is better than perfect」を現実世界で運用するなら、最初から60点・80点を狙うより「まず30点で完成させる」という設計は非常に合理的である。

ただし重要なのは、30点をゴールにするのではなく、30点を「改善可能なスタート地点」にすることだ。

1. 「Done is better than nothing」は、実はかなり強い

よく知られる「Done is better than perfect」は、単なる精神論ではない。

Facebookでこの考え方を実践していたと語ったシェリル・サンドバーグも、「素早く動いて反復する」「まず出して、フィードバックを得て改善する」という文脈で説明している。

つまり本質は、

100点の完成品を一発で作る
↓
30点でも実物を作る
↓
現実からフィードバックを得る
↓
40点、50点、70点……と改良する

という反復型の成長にある。

実際、「30点くらいをまずDoneにする」という発想そのものを論じた実践例も存在する。最初から高得点を狙うことで挫折して0点になるくらいなら、30点でも完成させる方が成果につながる、という考え方だ。

2. 「30点→ブラッシュアップ」は数学的にも強い

例えば、100点のものを作るまで公開しない人を考えてみよう。

戦略	初回	その後	結果
完璧主義型	100点を目指す	公開されない	場合によっては0点
30点Done型	30点で公開	改善する	30→50→70→85点……

ここで重要なのは、30点は「完成度」ではなく「フィードバックを得られる状態」だということ。

完成品を100点に近づけるためには、実際に使ってみないと分からない問題が大量に存在する。

何が不要なのか
どこが分かりにくいのか
ユーザーが本当に欲しいものは何か
どこに時間を掛けるべきなのか

これらは机上だけでは分からない。

だから30点で外に出すこと自体が情報収集になる。

3. 「30点」は低すぎないのか？

ここが最大の論点である。

結論から言えば、30点でも「核心部分が成立している」ならアリ。

逆に、核心部分が壊れている30点は「Done」ではない。

例えばブログ記事なら、

タイトルがある
主張が分かる
最低限の根拠がある
読者が読める
致命的な誤情報がない

ここまで出来ていれば、デザインや表現が30点でも「公開可能な30点」と言える。

一方で、医療・法律・金融・安全関連など、間違いによる損害が大きい領域では「30点で公開」は危険だ。

「Done is better than perfect」は万能原則ではなく、事故のコストが高い領域では最低限の検証を先に済ませる必要がある。

4. 最も重要なのは「30点」の定義

実は「30点で出そう」という戦略には落とし穴がある。

30点という言葉を「適当でいい」と解釈してしまうこと。

これは全然違う。

正しい意味は、

「完成度を上げる作業」と「完成させる作業」を分離する。

つまり、

30点＝最低限成立している完成品

であって、

30点＝未完成品を放置

ではない。

5. 「30→50→70→90」の階段方式が強い

実践するなら、このような段階設定がかなり使いやすい。

段階	目的
30点	とにかく形にする
50点	致命的な欠点を潰す
70点	普通に人へ見せられる品質へ
85点	強みを伸ばす
95点	細部を磨く
100点	原則として存在しない

この方式のメリットは、「100点になるまで完成しない」という罠から脱出できることだ。

さらに、30点から改善するときには「何を改善すれば点数が上がるか」が見えやすくなる。

6. 30点を出した後に「ブラッシュアップしない」という罠

ここも重要。

「Done is better than perfect」を間違えると、

「とりあえず出した！　Done！　終了！」

になってしまう。

しかし本来は逆だ。

Doneは終了ではなく、Iteration 1の終了である。

つまり、

30点完成
↓
公開・実行
↓
反応を見る
↓
問題を発見
↓
40～50点へ改善
↓
再び反応を見る

というループを回す。

MVP（Minimum Viable Product）思想でも、重要なのは単に粗いものを出すことではなく、現実のフィードバックを得て学習することだとされる。

7. 「30点→ブラッシュアップ」が特に強い分野

① ブログ・記事

これはかなり相性がいい。

まず記事を公開し、検索流入・読了・反応などを見て、後からタイトル、構成、説明、内部リンクなどを改善できる。

記事を書き始めたまま永遠に公開しないより圧倒的に実践的だ。

② プログラミング

最初から完璧なアーキテクチャを設計するより、まず動く最小版を作り、実際の問題を確認してから改善する方が合理的なケースが多い。

③ コンテンツ制作

YouTube、音楽、イラスト、動画、SNSなども同様。

初作品から完成形を目指すより、作品を出して「何がウケたのか」を知る方が次の作品に繋がる。

④ 勉強・資格

「全部理解してから問題を解く」のではなく、30点しか取れなくても一度試験形式に触れる。

すると、自分の弱点が可視化される。

これは30点を「診断テスト」に変換する戦略である。

8. 実は「30点で出す」と、ブラッシュアップの優先順位が分かる

100点を目指している段階では、細部が全部重要に見える。

しかし30点で一度出してみると、

本当に直すべきところ
意外と問題ではなかったところ
誰も気にしていないところ
むしろ伸ばすべき長所

が分かってくる。

つまり30点Doneは、品質を下げるための戦略ではなく、改善対象を発見するための戦略なのである。

9. 「30点→ブラッシュアップ」は、実はPDCAよりも「試行→学習」に近い

この戦略の本質は、

作る → 出す → 観測する → 改善する

というフィードバックループだ。

シリコンバレー的な「Done is better than perfect」も、単なる雑な仕事の推奨ではなく、「早く出して学習し、改善する」という文脈で語られている。

したがって、より正確な言い換えは、

Done is better than nothing.
ただし、
Done is the beginning of improvement.

だろう。

10. ただし「30点主義」にも重大な副作用がある

何でも30点で出してしまうと、当然ながら信用を失う可能性がある。

特に、

安全性
正確性
法令遵守
個人情報
金銭
重大な意思決定

に関係するものは、「30点で出して後で直せばいい」では済まない。

したがって最適解は「常に30点」ではない。

失敗しても取り返せる部分は30点で出し、取り返せない部分は先に品質を確保する。

11. 最強の実践ルールは「30点Done＋致命傷ゼロ」

ここまでをまとめると、非常に強い運用ルールが見えてくる。

① 核心機能を作る
② 致命的なミスを潰す
③ 30点でも一度完成扱いにする
④ 外に出す・実際に使う
⑤ フィードバックを取る
⑥ 点数を上げる

これなら「雑」と「迅速」を区別できる。

12. 最終判定

評価項目	判定
行動開始のしやすさ	★★★★★
完璧主義対策	★★★★★
改善効率	★★★★★
フィードバック獲得	★★★★★
品質維持	★★★★☆
高リスク分野への適用	★★☆☆☆

結論：「30点で完成」は、30点を目指す思想ではない

今回のオタクくん理論、

「Done is better than nothingを実践するなら、まず100点満点中30点で完成させ、その後ブラッシュアップすればいい」

これはかなり正しい。

ただし、さらに正確に言うなら、

「30点で完成させる」のではなく、「30点で完成扱いにして、改善ループを開始する」

のである。

100点を目指して一歩も動けない人にとっては、30点は「低品質」ではない。

30点とは、0点から脱出するための発射台。

そして、50点、70点、85点と上げていけばいい。

最初から100点を狙って「永遠の未完成」になるより、30点で世に出して現実から答えをもらう。

これこそが、

「Done is better than nothing」→「Done → Feedback → Improve」

という、かなり実戦的な進化形なのである。

判定：◎　「30点Done→ブラッシュアップ」は、Done思想の正しい実践法。ただし「30点で妥協」ではなく「30点を起点にする」のがミソ。

Sources

シェリル・サンドバーグによる「Done is better than perfect」の実践・反復についての説明
30点程度から始めるDone戦略についての実践的考察
MVPと迅速な反復改善の考え方
「Done」を万能原則にしてはいけないという品質・リスク面からの検討