はじめに
多くの企業において、ITは「暗黙の前提としてできるだけ長く使い、一度作ったら維持し、壊さずに積み上げるもの」として扱われてきました。しかし、成長期の事業ITを振り返ると、この前提そのものが数多くの混乱を生んでいます。本稿では、「速度を出すためのIT」と「残すためのIT」はそもそも設計思想が異なるという点を起点に、なぜ両者を混同すると破綻するのかを整理します。
速度を出すITは「仮説検証装置」である
速度を出すITの目的は明確です。市場仮説を素早く試し、顧客反応を早く得て、成功パターンを見つけることです。このITでは、早く作れること、早く変えられること、早く捨てられることが最重要であり、品質や整合性よりも学習速度が価値になります。
残すITは「判断を固定する基盤」である
一方、残すITの役割は正反対です。判断を再現可能にし、業務とデータの意味を固定し、組織が変わっても同じ判断ができるようにすることです。このITでは、安定性、可読性、意味の一貫性が最優先され、頻繁に変わらないこと自体が価値となります。
両者は最適化指標がまったく違う
速度を出すITと残すITは同じ「IT」という言葉で括られがちですが、最適化指標は真逆です。速度を出すITは「変更コストが低いほど良い」ものであり、残すITは「変更コストが高いほど良い」ものです。変更しやすさは、学習フェーズでは武器ですが、運用フェーズではリスクになります。
混同が始まる瞬間
多くの企業で問題が起きるのは、速度を出すために作ったITを、そのまま基盤として使い続ける瞬間です。仮説検証用の設計、人依存の判断、暫定ルールが、いつの間にか「正式な仕組み」として固定されてしまうのです。
「捨てる前提」が共有されていなかった
速度を出すITが問題になるのは、それ自体の性質ではありません。問題は、「いつ捨てるのか」「何を残すのか」「どこから作り直すのか」が、経営として一度も共有されなかった点です。捨てる前提が共有されていないITは、必ず残り、必ず重荷になります。
残すITに速度を期待してしまう
逆の混同も頻繁に起きます。基幹システム（残すIT）に事業スピードを求める瞬間です。この瞬間、例外対応が増え、暫定処理が入り、安定性が損なわれます。結果として、残すためのITが残せなくなってしまうのです。
経営判断として分けるべき問い
速度を出すITと残すITを分けるために、経営が引き取るべき問いはシンプルです。「これは何を学ぶためのITか？」「これは何を固定するためのITか？」。この問いに答えずに進めると、「すべてを速く、すべてを安定させ、すべてを残そうとする」という矛盾した要求が生まれます。
分けなかったことの帰結
両者を分けなかった結果、以下のような状態に陥ります。
- 技術的負債が蓄積し、
- 人手不足が常態化し、
- 改修が怖くなり判断が止まる。
これは技術の問題ではなく、役割を定義しなかった経営判断の帰結です。
次に進むための前提
速度を出すITと残すITを分けることは、技術設計の話ではありません。「どこまでを実験とみなすのか」「どこからを基盤とするのか」という、事業フェーズに対する経営判断です。次稿では、「事業推進ITは誰が止めるべきか」を取り上げ、この切り替え判断を誰がどのタイミングで引き取るべきなのかを整理します。
