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