常に待つ方が良いですか？
このコンセプトに名前と統合された理論があるのではないかと思っていました。
ソフトウェアをビルドする必要があるが、今は必要ない場合は、将来的にテクノロジが向上するため、待機することをお勧めします。
私はそれが本当だと確信しています：
- IT技術は時間とともに改善されてきています。より優れたソフトウェア、より優れたライブラリ、より優れたIDEなど...
- したがって、開発はより安価になります（市場の状態などの他の要因を考慮しない...）
- 結果として得られる製品は、速度、堅牢性、ルックアンドフィールの点で優れています...
しかし、私はこの概念の理論や名前を見つけることができません。私を正しい方向に向けることができますか？
編集
すべての回答は興味深いですが、トピックから少し外れているため、いくつかのことを明確にしたいと思いました。
- このソフトウェアは私のビジネスの重要な部分をカバーしているので、将来このソフトウェアが必要になることはわかっています。これは内部で使用するためのものであり、時代遅れの技術に依存していてユーザーが好まない既存のものを置き換えます。
- 同意はありません
- 私は最先端のテクノロジーについて話しているのではありません。それは普通の開発です。この通常の開発者は、時間が経つにつれて改善され、簡単になると想定されています。現在も将来も、「アーリーアダプター」としての資格を持つテクノロジーを使用する予定はありません。
- つまり、数年後に主流になるものが現在の主流になるよりも優れているという事実を利用するという考えです。
用語については、「アーリーアダプターのペナルティ」または「リードのペナルティ」を探していると思います。それは、少なくとも100年間認識されてきたコンセプトです。
ソフトウェアに関するあなたの主張が真実であるかどうかに関しては、それは完全に別の問題です。また、組織がテクノロジーを採用するのが遅すぎる「ラグガードペナルティ」の概念もあります。
あなたが参照している原則は、可能な限りアーキテクチャの決定を延期することです。後でより良いオプションがあるのでそれほどではありませんが、後でより多くの情報に基づいた決定を行うことができるためです。アーキテクチャ上の決定は、間違いを犯した場合、当然ながら最も高価な決定になるため、これは重要です。
多くの場合、企業はいくつかのテクノロジーを多額のお金で購入しますが、その後、それが適切であるかどうかに関係なく、あらゆる種類のアプリケーションに使用するための議論になります。その後、投資収益率が上がるまでこれを続ける必要があります（開始するのに優れた方法ではなかったため、しばらくかかる場合があります）。
私はこの種の愚かさには目を引く名前はありません。いつものようにビジネスですか？
[編集]
私はあなたが尋ねていたものとは少し異なる質問に答えただけだと知っています。私たちの分野（ソフトウェアエンジニアリング）との関連性が高いためです。しかし、ちょうどあなたがテーブルに持ってきている現象のための完璧なオランダの表現があることに気づきました：
https://en.m.wikipedia.org/wiki/Law_of_the_handicap_of_a_head_start
そしてどうやら誰かがそれを翻訳する手間をかけました。オランダ人として、私はこの翻訳に全く満足していません。私はむしろそれを「ブレーキングリードの法則」と呼びたいと思います。これは、あなたがパックよりも先であり、以前に始めたものではないという事実をより強調するかなり文字通りの翻訳です。重要なのは、後でパーティーに参加した人々がしないレガシーに対処する必要があるということです（少なくとも、あなたのレガシーの種類に対処する必要はありません）。これは彼らにあなたを追い越す機会を与えます。
ソフトウェアをビルドする必要があるが、今は必要ない場合は、将来的にテクノロジが向上するため、待機することをお勧めします。
これが本当なら、私たちは前進することは決してないでしょう。ではなく、この理論に名前を付けて、より良い理論を紹介します。
コードではなく機能を評価する。
コードはあなたを過去に結びつけるものです。コードに何をすべきかについての意見を持たせないでください。より良い方法を見つけたらすぐに古いコードを捨ててください。
これを保持し、新しいアイデアを調査することは、あなたがそれを維持する義務がないので、はるかに安価です。
コア機能が維持されている限り、どの方向に進むかを決定するときに、将来の機能が出入りする可能性があります。
そのように作業すれば、人々が持っていたことさえ知らなかったニーズを解決できます。
はい、技術は将来的に良くなります。しかし、テクノロジーはどこかで始まる必要があります。遊んで、何がうまくいくかを調べてください。
これはソフトウェア経済学のきちんとした質問です。ソフトウェアを開発するためのコストは（ある程度）固定されています。 （米国のバブルの外でのエンジニアリング給与は、インフレに追いついています。）大まかに言えば、MVPのスコープは固定されています。これは変わらないと思いますが、時間の経過とともに（競合他社に注意）
そのコストはMと言えます（絶対値は関係ありません）。
M =ハードウェアのコスト+ソフトウェアのコスト（X）+ソフトウェアを複製するコスト
ソフトウェアを複製するためのコストは、一般的にゼロまたはほぼゼロです。
ほとんどの経済とは異なり、ソフトウェアを実行するシステムの価格（一般的に言えば）は、おおよそ-7％で下降傾向にあります。 2020年頃（ウィキペディア、ムーアの法律を確認）
したがって、システムコストにはデフレがあります。
顧客あたりのソフトウェアのコストはXです。ここで、X =開発コスト/顧客数です。
さて、あなたの顧客数が100万人を超えると、Xはゼロに向かう傾向があります。
現在、デフレ圧力の下で、後で安くなるため、投資を延期する強い動機があります。 （ウィキペディア、デフレをチェック）
したがって、100万人の顧客を対象とする場合、M（翌年）= M * 0.93です。
現在、MVPの一部の部分は、今日の実装が難しい場合があります。たとえば、画面の更新に2ミリ秒のレイテンシが必要な場合は、非常に高速です。あなたは高価な技術に頼らなければならないかもしれません、そして、ハードウェアはその性能を得ます。
今、私たちは5年待ちます。
2ミリ秒の遅延要件は、ムーアの法則や友人たちによって食い止められています。必要なハードウェアの総コストは、現在の約70％です。
M（5）〜= 0.70 M
これで、システム開発コストはおそらく7％スケールファクターよりも速くスケールダウンします。これは、より簡単な手法で回避できるためです。たとえば、10年前のコンピューターでelectronアプリを実行してみてください。また、ソフトウェア（および開発ツール）が依存しているすべてのものが7％で安くなるという肯定的なフィードバックループもあります。つまり、70％は実際にははるかに少なくなります。これを測定することは、読者のための演習として残します。
さて、もしあなたがそうなら、おそらく誰かが電話やPCで実行するためのソフトウェアを販売していて、顧客はハードウェア自体に料金を払っています。
したがって、より多くの電話でアプリを実行できるようになるため、顧客のプールは毎年大きくなります。
ですから、時々待つことは経済的に意味があります。
悲しいことに、すでに製品を持っている場合、とにかく同じことが起こります。製品を複製するためのコストも毎年低下します。**
逸話の時間：私はシニアエンジニアのスタートアップを見て、1999年に風景の3Dグラフィックレンダリングを最適化するのに2年間費やしました。通常のエンジニア年の仕事について、そのすべてのIPは、今ではゼロの市場価値を持っていました。
注：ムーアの法則とその友人たちは最近少し横ばいになり、現在の7％は以前の25％と比べてひどいものになっています。たぶんソフトウェアを書く時がきたのかもしれません。
**製品に多くの機能がある場合、競合他社のMVPは...すべての便利な機能です。古典的な失敗は、MS Wordと競合するワードプロセッサを作成しようとすることでした。相互運用のためにファイル形式を読み取るだけでは、法外なコストがかかります。オープンソースのソフトウェアとライブラリは、ソフトウェアのコスト分析の興味深い場所にゼロを置くことができます。
@Steveは、これが「早期採用者のペナルティ」であると考えています。しかし、私はあなたの質問の文字通りのタイトルである根本的な主張に対処したいと思いました：
常に待つ方がいいですか？
いいえ。
待つというあなたの主張は、時間とともに改善するテクノロジーに基づいていますが、ユーザーの期待は固定されています。最後の部分はあなたの推論の欠陥です。
証拠はプディングにあります。テクノロジーが常に期待よりも速く進歩した場合、すべてのソフトウェア開発は時間の経過とともに短くなり、10年前よりもソフトウェア開発者（プロジェクトごと）が少なくて済みます。明らかに、そうではありません。
確かに、過去数十年でWebテクノロジーは大幅に改善されており、複雑なWebサイトを構築するのは当時よりも簡単です。ただし、ユーザーの期待も変化しています。今日では、90年代スタイルのウェブサイトをすぐに立ち上げることができますが、ユーザーにあなたのウェブサイトのようにさせたい場合、今日の市場で90年代スタイルのウェブサイトを逃れることはできません。
ユーザーの期待は技術の進歩に少し遅れていますが（新しい技術が一般的になるには時間がかかるため）、同じ速度で進歩します。同じ速度で運転している2台の車のように考えてください。どれだけ長く待っても、車の距離は常に同じであるため、一方が他方に出会うのに必要な労力は同じになります。
ですから、それはゼロサムゲームであり、期待と技術の進歩が互いに打ち消し合うゲームだと思うでしょう。 それはほとんど正しいです。
しかし、期待が高まると、期待に応えるために必要なテクノロジーが superlinear 増加する場合もあります。ビデオゲームはここでの良い例です。
時間の経過とともにグラフィックの品質が向上したため、ビデオゲームの総開発時間は、より大きな部分をビジュアルとグラフィックの忠実度に充てています。
昔に戻ると、グラフィックスは開発時間の50％未満でした。ここで極端な例としてPongを取り上げます。
これをPongを今日同様の高い市場魅力を持つ新しいゲームとしてリリースする場合と比較し、顧客を誘惑するために必要なグラフィックスの量を検討してください。ゲームの仕組みを拡張する必要がないと仮定しても、ビジュアルは元のPongの場合よりもはるかに時間がかかります。
これは極端な例を使用した単純な例にすぎませんが、最新のゲーム開発を詳しく調べると、どこにでも同じパターンが出現することがわかります。開発チームは、ゲーム関連の役割よりも、グラフィック関連の役割の増加に大きくシフトしています。
つまり、ゲームを開発したいが手段が限られている場合は、1年後ではなく、今すぐゲームを作成したほうがよいでしょう。 １年後より。