文脈に則さないマイクロサービスを構築してしまうようなケースしかり、将来発生するかもしれない「もしかしたら」を過大評価し備えすぎるみたいなのも似ているかもしれない。
本来、「悪いことの発生する確率 x インパクト」の期待値で見るべき話であるが、相場観がないと、1%程度しか発生しないことを100%発生すると思い込んでしまう。
しかし、書籍で得られる方法論は、前提として100%発生する側の視点で書かれていることもある。それは前述の図の通り、その問題が発生した状況を解決するための方法論であれば、その世界においては正しい。しかし、現実世界ではその状況になるかどうかは場合による。
When capital for startups is readily available at scale, it makes more sense to go big, fast and make mistakes than it does to search for product/market fit.
The amount of customer discovery and product-market fit you need to do is inversely proportional to the amount and availability of risk capital.
また、付け加えると、「見積もりは予測であり約束ではないのである」とか正しい理屈を説いても基本的に意味がなくて、期日守るからリリース日遅くなる or 期日なしでリリース日早まるけど確度80%、のようなトレードオフの形にして選択可能な状態にすることが重要である。レバーとして実装できればあとは選ぶだけであり、「見積もりは〜予測で〜」のような開発の正義みたいなものを説いて理解していただくような労力すら必要なくなる。
おまけ. 小難しい理屈は「全員が」理解している必要はない
合わせて、フロー効率やリソース効率みたいな開発としての正義のようなものも同様である。そういう小難しい理屈を関係者全員が理解している必要はなく、その考え方が染み込んで浸透した状態の選択肢をいくつか用意出来れば良い。結果的にフロー効率がよくなる構造 or リソース効率が良くなる構造を作れれば良いわけで、何を捨てて何を取るかという状態になっていることが実行性が高い状態である。しかしながら、なぜか、小難しい理屈を我々は説明したくなってしまうのである。合気道すべきところを何故か正拳突きをしてしまうのである。そんなこと知らなくても良いのに。
思想みたいなものはあえて声高に説明するのではなく構造の中にそっと織り込んでなじませておけば良くて、そうすれば無意識下におかれ自然とスケールする。思想を理解しないと適用できないみたいな状態だと理解出来る人にしかスケールしないため効率が悪いのである。しかし、、、、、、方法論者は、その小難しい理論が如何に正しいか・素晴らしいかを説明してしまうのである。という自戒を込めて。
Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.[2]
Overengineering differs from Planned Obsolescence which seeks to alter a design to produce an artificial limit on a product's lifespan or otherwise make it unfashionable. Overengineering is often identified with design changes that increase a factor of safety, add functionality, or overcome perceived design flaws that most users would accept.
Overengineering can be desirable when safety or performance is critical (e.g. in aerospace vehicles and luxury road vehicles), or when extremely broad functionality is required (e.g. diagnostic and medical tools, power users of products), but it is generally criticized in terms of value engineering as wasteful of resources such as materials, time and money.
