速度を出す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は誰が止めるべきか」を取り上げ、この切り替えの判断を、誰がどのタイミングで引き取るべきなのかを整理します。