thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます&いつもすみません。僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。いう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じることが多いです。思いつくがままに挙げると、例えば以下のようなことを疑問に感じたことがあります。ライブラリやフレームワークを採用するにあたり、その将来性を何年程度のスパンで評価すればいいのかstruts1は「技術的負債」node.jsのexpressは技術的負債になろうとしているウェブサービスを開発するにあたり、最初からシャーディングの機能を作り込むことは正しいのかそれとも、サービスが当たってからシャーディング機能を実装するほうが利益は大きいのかプロトタイピングにおいて、きれいな実装を行うべきなのか、それとも汚くても早期に実装できたほうがいいのかプロトタイプのコードをサービスインする確率によって答えは変わるはずだが、その確率の閾値はいくらなのかこれらの例からもわかるように、ライブラリ等の部品を選定する際の評価や、規模拡大や拡張を前提とした作り込みの程度を決定するには、「技術的負債」についての定性評価ではなく定量評価が必要です。kentaroさんによる「割引率」という概念の導入は、それを可能にするという点で、僕には興味深く感じられます。期間毎の割引率に「技術的負債」の解消に必要なコストを掛けて積分したものが、予測されるTCO予測されるTCOを最小に抑えるのが、正しい技術的選択のような形として、定量的に評価し、現時点において正しい選択を取るためのツールとして「技術的負債」を使うことが可能になるのではないか。「これからはnode.jsでしょ」とか「サービスがヒットしたら必要になるから、シャーディング機能は作り込むべき」といった感覚論ではなく、技術的判断をサポートする定量評価手法として「技術的負債」を使えればいいなと思う次第です。ありがとうございます。スライドでは詳しく書けなかったんですが、彼らは定量評価のためのモデルを提案しています。