> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # 確信度が速度と品質を決める > 「確信度が速度と品質を決める」は、問題と解決策への確信度で速さと品質の配分を決める原則です。起源、使い方、限界を学びます。 **カテゴリ**: 原則
**タイプ**: 意思決定原則
**起源**: Brandon Chu、『Product Management Mental Models for Everyone』、2018年
**別名**: 速度対品質のトレードオフ、Confidence–Speed–Quality Rule **先に答えると** — **確信度が速度と品質を決める**（Confidence Determines Speed vs. Quality）は、速さとこだわりをどれだけ交換するかを決めるルールです。Brandon Chu が 2018 年に述べました。問題の重要さと、解決策の正しさへの確信度が、その配分を決めるべきです。実務上の洞察は単純です。問題が本物か確信できないなら、速く学ぶ。問題も解決策も長く残ると確信できるなら、近道をしない。 ## 確信度が速度と品質を決めるとは？ **確信度が速度と品質を決める**（Confidence Determines Speed vs. Quality）は、意思決定の原則です。問題と解決策にどれだけ確信があるかが、速さを最適化するか、品質を最適化するかを決めるべきです。 > あなたが持つ確信度、すなわち（1）解いている問題の重要性と（2）つくっている解決策の正しさが、プロダクトづくりにおいて速度と品質をどれだけ引き換えにするかを決めるべきである。 — Brandon Chu、2018年 料理にたとえるとわかります。一度もつくったことのない料理なら、控えめな材料で小さな鍋から始めます。五十回つくったウェディングケーキで即興はしません。[プロダクト思考](/ja/thinking/product-thinking)は、その成果がつくるに値するかを問います。この原則は次の問いを立てます。いま分かっていることを前提に、今回の試みはどれほど磨き込むべきか。 Chu のルールは気圧計です。「速く動け」や「粗悪品を出すな」というスローガンではありません。このスペクトルには 3 つの基本姿勢があります。問題が重要だという確信度が低いなら速度を優先する。問題と解決策の両方に確信度が高いなら品質を優先する。問題には確信があるが解決策にはないなら、両方のバランスを取る。短周期で回し、証拠が来たら基準を上げます。 ### 確信度が速度と品質を決める：3つの深さ * **入門**: 投資する前に「この問題が本物だと、どれほど確信しているか」と問う。正直な答えが「あまり」なら、最初の版は安く速くして学ぶ。 * **実務**: 問題の重要性と解決策の正しさを、証拠つきで 1 から 5 で採点する。問題が低いならテストを出す。両方高いなら品質基準を上げる。問題は高く解決策は低いなら、どちらかの点数が動くまで短い[反復と改善](/ja/principles/iterate-and-improve)のサイクルを回す。 * **上級**: このトレードオフは、今回の賭けの作り込みについてであり、デリバリーシステム全体の話ではない。テストが雑で復旧が遅いチームは、機能で「品質を選ぶ」資格がない。波及効果にも注意する。未検証の問題に高品質を積むと、本当の解決策を拒む既存資産ができる。 ## 起源 確信度が速度と品質を決めるという名前は、当時 Shopify のプロダクトリーダーだった **Brandon Chu** が付けました。2018 年 8 月のエッセイ『Product Management Mental Models for Everyone』は、メンタルモデルをプロダクトマネージャーだけでなく、つくる人のための格子として扱います。その 6 番目がこのルールです。 Chu は 1 年前に同じスペクトルを描いていました。2017 年 3 月の『Ruthless Prioritization』では、速度と品質の配分はプロダクトの仮定に従うべきだと論じています。問題が仮定かもしれない、解決策が仮定かもしれない、どちらでもないかもしれない。2018 年のエッセイが、この気圧計に残る名前を与え、両軸を顧客検証された確信度に結びました。 思想的な親戚はもっと古いです。1990 年代末に Kent Beck らが広めた Extreme Programming の [YAGNI](/ja/principles/yagni-principle)（You Aren't Gonna Need It）は、使わない柔軟性を先につくるなと戒めます。Eric Ries の『The Lean Startup』（2011年）は、検証されていない飛躍的仮定があるとき、最初の版の仕事は磨きではなく証拠だとしました。Chu の貢献は、確信度を問題と解決策の 2 問に分け、それぞれの組み合わせがどの配分を意味するかを明示したことです。 同じ 2018 年の文章で Chu は、実験・機能・プラットフォームも区別しています。実験は学習が仕事なので粗くてよい。プラットフォームは他の仕事が乗るので安定が要る。 ## 要点 この原則には 4 つの動く部品があります。2 つの確信度の問い、3 つの既定姿勢、証拠のルール、そして「今回の賭け」と出荷システムを混同するなという警告です。 曖昧な「自信はあるか」は聞かない。別々に聞く。第一に、この問題は仕える人にとってどれほど重要だと確信しているか。第二に、この解決策が正しいとどれほど確信しているか。痛みは正しく、直し方は間違っている、ということはよく起きます。学生はスキルの必要性には確信があっても、どの講座が教えるかはまだ推測かもしれません。2 つの点数を書き、静かに 1 つの気分へ溶けないようにします。 問題が重要だという確信度が低いなら、速さを最適化します。Chu の例は、まだ存在しない機能のランディングページで関心だけを測ることです。問題と解決策の両方に確信度が高いなら、近道をしない。顧客はこの仕事と長く暮らすからです。問題は高く解決策は低いなら、速さと品質を両立し、短いサイクルで証拠に基準を上げさせます。確信度はスイッチではなく目盛りです。出力はスローガンではなく配分です。 気分は確信度ではありません。Chu の高品質側は「顧客を通じて検証された」確信度を求めるので、点数は勘ではなく証拠に置きます。創業者が「市場がこの機能を欲しがると知っている」と言うとき、それは希望です。有料の予約が 5 件、待機リストの急増、失敗したフェイクドアテストが証拠です。テストのたびに点数を変えます。[フェイルファスト](/ja/principles/fail-fast) はここで効きます。弱い問題を速く殺し、強い問題に品質を使います。 未検証の賭けで速さを選ぶことは、テストやバックアップ、ロールバックを省略する許可ではありません。Nicole Forsgren、Jez Humble、Gene Kim は『Accelerate』（2018年）で、高性能な技術組織はリリースが速く、システムも安定している傾向があるとまとめました。DORA の 2019 年 *Accelerate State of DevOps Report* では、エリート層のデプロイ頻度は低パフォーマンス層の 208 倍、変更失敗率は 7 分の 1 でした。この原則は、特定の賭けの作り込みを決めるために使う。工学的な品質は、速い賭けを可逆に保つために使う。 ## 応用場面 チームや家庭、公共の場が「より速く」対「より良く」をアイデンティティのように議論し始めたら、確信度が速度と品質を決めるを使います。点数の話に戻すためです。 キックオフで、問題の重要性と解決策の正しさを 1 から 5 で採点し、証拠を名指しする。問題が 2 なら、フェイクドア、コンシェルジュ、1 週間の原型であり、プラットフォームの作り直しではない。決済フローが 5/5 なら、デザインの磨きと負荷試験を入れ、「v2 で直す」は禁止する。 キャリアの転換が自分に本物か確信できないなら、最初に 2 年制の学位代を払わない。夜学、短いプロジェクト、ボランティア——速さの姿勢です。3 か月接してもその仕事が重要なら、次の投資の品質を上げます。 新しい放課後の活動、食事の計画、ケアの手順は、確信度の低い問題であることが多い。この家庭に合うかがまだ分からないからです。安い版で 2 週間試す。学校の変更、大規模な改修、医療機器のような高くて戻しにくい版は、必要性も適合もすでに明らかなときに残す。これは[可逆性の原則](/ja/principles/reversibility-principle)の助言でもあります。 バス専用レーンが効くか確信できない都市は、勘で縁石を作り直す前に仮のラインを塗り、乗車数を測るべきです。問題が重要だと示されたら、品質は恒久設計に属する。排水、標識、アクセスです。地域のプログラムも同じで、6 週間の試験運用のあと、人員の入ったサービスにします。 ## 事例 ### Dropbox のデモ動画（2011年の報告） 2000 年代末、Drew Houston は Dropbox をつくっていました。欲しくなりやすく、仕上げるのに高いファイル同期です。端末をまたぐ同期、衝突処理、違和感のないフォルダは、品質を先に求めると何年もの工学になります。開いていた問いは「つくれるか」だけではありません。「この問題を気にする人が、丁寧につくる理由になるほど多いか」でした。 Houston のチームは、磨き込んだ公開プロダクトを待って答えませんでした。Eric Ries がのちに『The Lean Startup』と 2011 年 10 月 19 日の TechCrunch 抜粋で記したところでは、Houston は約 3 分の動画をつくり、製品が「こう動くはずだ」という姿を見せました。Digg の初期採用者向けで、その層が気づくネタを盛り込みました。 > ウェブサイトに何十万人もが流れ込んだ。ベータの待機リストは 5,000 人から 75,000 人へ、文字どおり一夜で跳ねた。完全に度肝を抜かれた。 — Drew Houston、Eric Ries による引用、2011年 Houston は、24 時間以内にその動画が 10,000 を超える Digg を得たとも述べています。待機リスト 75,000 と、1 日 10,000 Digg。この 2 つの数字は、フォーカスグループでは見えない規模で問題が重要だと示す証拠でした。そのあと、高品質な同期エンジンに工芸を注ぐことは、需要についての推測ではなく、すでに人を集めた問題への作り込みになりました。 教訓は、確信度が速度と品質を決めるにきれいに重なります。問題の重要性への確信度はまだ稼がれている途中だったので、最初の公開物は生産仕上げではなく学習の速さを最適化しました。境界もあります。Houston にはすでに動く原型があり、動画は「目に見える」価値仮説を試せます。市場の信頼や規模の物流のように、実際の利用でしか現れない問題は試せません。 ## 限界と失敗パターン 確信度が速度と品質を決めるは、特定の賭けに対する作り込みのルールです。雑でよいという万能の免罪符ではなく、速さと品質が常に逆方向だという約束でもありません。 1. **影響半径が大きいとき、「速さ」の点数は譲る。** 実験が患者、子どもの安全、給与、都市の水を害しうるなら、問題が未検証だから粗悪品を出してよいことにはなりません。サンドボックス、志願者、ごく小さな切片で試す。[ハードチョイス・モデル](/ja/models/hard-choice-model) がここで効きます。確信度が低くても影響は高くなり得て、高影響はなお慎重さを求めます。 2. **デリバリーシステムの品質は、同じトレードオフではない。** 『Accelerate』と DORA の研究では、エリートチームはより速く、かつより安定して出すことが多い。パイプラインが脆いなら、機能で「速さを選ぶ」は障害に漏れます。速い賭けをロールバックできるようシステムを直し、そのうえで Chu の気圧計を賭けそのものに使う。 よくある誤用は **姿勢の凍結** です。かつて速く学ぶ必要があったチームが、問題も解決策も証明されたあとも、決済・認証・プライバシーを粗いまま出す。逆のチームは、「品質」がアイデンティティだからと何ヶ月も資料を磨き、問題は推測のままです。2 つの問いはプロジェクト開始時だけでなく、カレンダーで採点し直します。 ## よくある誤解 「速さ対品質」を初めて聞いた人が踏み外す誤りは、おおむね次の 3 つです。 1 つの賭けでは、しばしばトレードオフです。磨きを増やすと時間がかかることが多い。システム水準では、常にそうではありません。DORA の研究がここでの注意です。小さなバッチ、自動テスト、速いロールバックは、デプロイの速さと安定の両方を上げることがあります。Chu のルールは、いまある証拠を前提に、この問題とこの解決策へどれだけ工芸を積むかの話です。工学的な規律が任意だという話ではありません。 高い確信度は、品質の基準を上げる理由になります。地図を凍らせる理由にはなりません。市場は動き、昨日検証した問題は薄れることがあります。5/5 の賭けでも、安い探針は残す。利用データ、サポート票、隣のジョブへの小さな実験です。確信度は今の点数であり、トロフィーではありません。 ここでの速さは、間違えるコストを下げることであり、ユーザーを侮辱することではありません。ランディングページ、コンシェルジュ、狭い原型は、明快で誠実で安全であり得ます。省くのは、使わない設計、投機的な磨き、まだ稼いでいない規模です。最初の版が欺瞞的または有害なら、原則を使ったのではありません。捨てたのです。 ## 関連概念 これらの考えは、確信度が速度と品質を決めるの隣にあります。何をつくるかを教えるものも、最初の版をどれほど可逆に、単純にするかを教えるものもあります。 つくるに値するユーザー成果から始める。この原則は、次の試みをどれほど磨くかを決める。 必要にならないものをつくらない。問題や解決策の確信度がまだ低いときに省く品質です。 間違った問題や間違った修正をすぐ表面化する。速さの姿勢の目的そのものです。 問題は本物だが解決策はまだ稼いでいないときの既定の動き。 双方向の扉を好み、速い賭けを取り消せるようにする。一方通行なら基準を上げる。 プロセスを選ぶ前に決定を分類する。確信度は低くても影響が大きいときに特に有用。 ## 一言で言うと **問題が重要だという確信度と、解決策が正しいという確信度を採点し、その 2 つの点数に配分を任せなさい。推測しているあいだは速く学び、すでに分かっているときには近道を拒む。** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.