はじめに
In many companies, IT has long been treated with an implicit assumption: “Use it for as long as possible, maintain what you’ve built, and keep adding without breaking it.” However, looking back at IT for growth-stage businesses, this very assumption has created significant confusion. This article starts from the premise that “IT for speed” and “IT for permanence” have fundamentally different design philosophies, and clarifies why conflating the two leads to failure.
速度を出すITは「仮説検証装置」である
The purpose of IT for speed is clear: to quickly test market hypotheses, obtain customer feedback rapidly, and identify successful patterns. For this type of IT, the ability to build fast, change fast, and discard fast is paramount. The speed of learning becomes more valuable than quality or consistency.
残すITは「判断を固定する基盤」である
On the other hand, the role of IT for permanence is the exact opposite. It exists to make decisions reproducible, to fix the meaning of operations and data, and to ensure the same decisions can be made even as the organization changes. For this IT, stability, readability, and semantic consistency are top priorities. The very fact that it does not change frequently becomes its value.
両者は最適化指標がまったく違う
IT for speed and IT for permanence are often lumped together under the same term “IT,” but their optimization metrics are polar opposites. IT for speed is optimized for “the lower the cost of change, the better,” while IT for permanence is optimized for “the higher the cost of change, the better.” Ease of change is an asset in the learning phase but becomes a risk in the operational phase.
混同が始まる瞬間
Problems arise in many companies at the moment they start using IT built for speed as a permanent foundation. Designs intended for hypothesis testing, person-dependent decisions, and provisional rules gradually become fixed as the “official system.”
「捨てる前提」が共有されていなかった
The problem with IT for speed is not its inherent nature. The issue lies in the fact that management never shared answers to critical questions: “When will we discard it?” “What will we keep?” “From where will we rebuild?” IT built without a shared assumption of eventual disposal will inevitably remain and inevitably become a burden.
残すITに速度を期待してしまう
The opposite confusion also frequently occurs: the moment business speed is demanded from core systems (IT for permanence). At this moment, exceptions increase, temporary workarounds are introduced, and stability is compromised. As a result, the IT meant to be permanent can no longer be preserved.
経営判断として分けるべき問い
To separate IT for speed from IT for permanence, the questions management must own are simple: “Is this IT for learning something?” and “Is this IT for fixing something?” Proceeding without answering these questions creates contradictory demands: “Make everything fast, make everything stable, and keep everything.”
分けなかったことの帰結
Failing to separate the two leads to the following state:
- Technical debt accumulates,
- Chronic personnel shortages become the norm,
- Fear of modification halts decision-making.
This is not a technical problem; it is the consequence of a management failure to define roles.
次に進むための前提
Separating IT for speed and IT for permanence is not a discussion about technical design. It is a management judgment regarding the business phase: “What is considered an experiment?” and “What is considered the foundation?” In the next article, we will address “Who should stop business-driving IT?” and clarify who should own this switching decision and when.
Comments