IT戦略では「何を作らないか」も設計する

ソフトウェア開発やDXの話では、

• 新しいシステムを作った
• 新しい機能を追加した
• AIを導入した
• 新しいツールを採用した

といった「何を作ったか」が成果として語られやすいように感じます。

もちろん、新しく作ることで大きな価値を生み出せるなら、作るべきです。

一方で私は、企業のIT戦略では、

何を作るかと同じくらい、何を作らないかを判断することも重要

だと考えています。

私は現在、レガシーを含む既存ソフトウェアについて、

• どう楽に与件変更へ対応できるようにするか
• 何を残すか
• 何を変えるか
• 何を他システムへ移すか
• 最終的にどう安全に終わらせるか

という、ソフトウェアライフサイクル全体を考えることが増えています。

その中で感じるのは、

世の中はソフトウェアを「作ること」に重きを置きすぎているのではないか

ということです。

「作った」という成果は見えやすい

新規開発は成果として分かりやすいものです。

新しいシステムが稼働した。 新機能が追加された。 新しい技術を導入した。

プロジェクトとして計画しやすく、予算も設定しやすい。

一方で、

この要求には新しいシステムを作らない

という判断は、成果として見えにくいものです。

何も作らなかったように見えるからです。

しかし実際には、

• 不要なシステムを増やさなかった
• 将来の保守対象を増やさなかった
• システム間連携を増やさなかった
• 新しい技術負債を作らなかった

という価値が生まれている可能性があります。

問題は、

「作らなかったことで回避した将来コスト」は非常に見えにくい

ことです。

ソフトウェアを作ることは、将来の維持責任を引き受けること

ソフトウェアは、リリースしたら終わりではありません。

むしろ、その後の方が長い場合があります。

作る
↓
運用する
↓
変更する
↓
モダナイズする
↓
移行する
↓
終わらせる

新しいソフトウェアを作れば、その瞬間から、

• 保守
• 障害対応
• セキュリティ対応
• 仕様変更
• テスト
• 利用者サポート
• 他システムとの連携
• 技術更新
• データ移行
• 最終的な廃止

という責任が発生します。

初期開発費だけを見れば、小さなシステムに見えるかもしれません。

しかし企業は、そのソフトウェアが存在する限り面倒を見続けなければなりません。

だから新規開発を判断するときに重要なのは、

作れるか

だけではなく、

このソフトウェアを将来にわたって面倒を見る価値があるか

ではないかと思っています。

ソフトウェアは、終わらせるにもコストがかかる

さらに難しいのは、

不要になったからといって、簡単には終わらせられない

ことです。

一度ソフトウェアが業務に組み込まれると、

• 利用者がその機能を前提に仕事をする
• データが蓄積される
• 他システムが連携する
• 運用手順が作られる
• そのシステムを前提にした業務ルールが生まれる

といった依存関係が増えていきます。

その状態で、

明日から停止します

とはできません。

役割を終えたシステムを廃止するためには、多くの場合、

そのシステムが担っていた役割を引き受ける代替手段

が必要になります。

例えば、

• 後継システムを作る
• 既存システムへ機能を統合する
• SaaSへ移行する
• データを別システムへ移す
• 業務プロセス自体を変更する
• 一部を手作業へ戻す

といった対応です。

しかし当然ながら、

その代替手段を用意するにもコストがかかります。

つまり、一度作ったソフトウェアには、

開発コスト
↓
維持・変更コスト
↓
移行コスト
↓
廃止コスト

というライフサイクル全体の支出が発生します。

ここが、新規開発時には見えにくいところです。

「作る費用」はプロジェクト予算として見えます。

一方、

将来そのシステムを終わらせるために必要になる費用

は、作る時点ではほとんど意識されないことがあります。

終わらせたいのに、終わらせられない

この構造が積み重なると、

古いシステムだから廃止したい

と思っても、簡単には消せなくなります。

廃止するには後継機能が必要になる。 後継を作るには予算が必要になる。 移行には時間が必要になる。

しかし、今動いているシステムを残しておけば、少なくとも今日の業務は止まりません。

すると、

今すぐ困っていないので、もう少し残そう

という判断が合理的に見えてきます。

その結果、さらに数年使われ、 依存関係が増え、 ますます終わらせにくくなる。

私は、この循環がレガシーシステムを生む要因の一つだと思っています。

だから、単純に

古いシステムをなくせばよい

という話でもありません。

終わらせるには、終わらせるための投資が必要

です。

要求があることと、新しく作る必要があることは別

こう考えると、新規開発の判断も少し変わってきます。

業務上の要求が発生したからといって、

では新しいシステムを作ろう

とすぐに決める必要はありません。

要求を満たす方法には、

• そもそもその業務をやめる
• 業務プロセスを簡素化する
• 既存システムの機能を使う
• 設定変更で対応する
• SaaSや市販ツールを利用する
• 他システムへ統合する
• 利用頻度が低ければ手作業として残す
• 要求そのものを見直す

という選択肢があります。

AIも同じです。

「AIを活用する」という目標から始めるのではなく、

この業務上の問題をどう解決するか

から考える。

既存ツールで十分なら、AIを使う必要はありません。

逆に、AIを使うことで大きな価値が出るなら使えばよい。

重要なのは、

技術を先に決めるのではなく、目的から手段を選ぶこと

だと思っています。

作りやすさが選択を難しくする

AIでコード、文書、テストなどの候補を作りやすくなっても、確認・保守・運用に使える時間が同じ速度で増えるとは限らない。生成できる候補が増えるほど、どれを採用し、何を既存の仕組みへ統合し、何を作らないかの判断が必要になる。

AIは候補の調査や比較にも利用できるが、生成量を成果とせず、利用価値と維持する負担から選ぶ。

新規開発をデフォルトの答えにしない

私は、システム企画では次のような順序で考える方が自然だと思っています。

業務上の目的
↓
その業務自体をなくせないか
↓
簡素化できないか
↓
既存機能で対応できないか
↓
設定変更・SaaS・市販ツールで対応できないか
↓
他システムへ統合できないか
↓
それでも必要なら新しく作る

これは「作るな」という話ではありません。

むしろ、

新規開発を必要性の確認なしにデフォルトの答えにしない

という話です。

新しく作ることが最も大きな価値を生むのであれば、当然作るべきです。

ただし、その判断には、

• 作った後に維持する
• 変更し続ける
• 最終的に代替手段を用意する
• 移行する
• 廃止する

という責任まで含める必要があります。

「作らない」は消極策ではない

「作らない」という判断は、

技術力がないからでも、投資を避けているからでもありません。

企業が持っている、

• 人
• 予算
• 保守能力
• 開発能力
• システム全体で許容できる複雑性

には限界があります。

一つシステムを追加すれば、管理対象が一つ増えます。

一つ連携を追加すれば、依存関係が一つ増えます。

一つ技術を追加すれば、その技術を理解し維持できる人材が必要になります。

そして将来、

そのシステムを終わらせる仕事も一つ増えます。

だから、

何をしないかを決めることも戦略

だと考えています。

「作らない」は何もしないことではありません。

限られた資源をどこへ使うかを選ぶこと

です。

作るなら、終わらせ方まで考える

検討した結果、

これは新しく作る価値がある

と判断することも当然あります。

その場合でも、私は

どう作るかだけではなく、最後にどう終わらせるか

まで考えたいと思っています。

将来を完全に予測することはできません。

しかし、

• コンポーネントを交換可能にする
• 外部依存を明確にする
• データを移行可能な形で保持する
• 利用状況を把握できるようにする
• 後継システムへ役割を移しやすくする
• 廃止判断に必要な情報を残す

といった工夫によって、

将来の選択肢を失いにくくする

ことはできます。

特に重要なのは、

このシステムを終わらせるとき、代わりに何が必要になるのか

を考えておくことです。

完全な後継システムが必要なのか。 別システムへ機能を移せるのか。 そもそも、その業務自体をなくせるのか。

終焉時の選択肢が多いほど、 将来の移行コストを抑えられる可能性があります。

システムの終焉は、廃止するときに初めて考えるものではありません。

作る段階から、すでに始まっている

と思っています。

Coding Agentによって初期実装の費用を抑えられる場合も、この判断は変わりません。作る候補が増えるほど、限られた保守能力をどこへ使うか、何を統合し、何を終えるかを選ぶ必要があります。生成に掛かる費用だけでなく、採用後の確認・運用・保守まで見て判断します。

ソフトウェアは作った後の方が長い

私は今、レガシーシステムについて、

どう楽に変えられるようにするか

そして、

どう安全に終わらせるか

を考えています。

その経験から、新しいシステムを見るときにも、

これを作った後、誰が面倒を見るのだろう

5年後、10年後に変更するときはどうするのだろう

役割を終えたとき、何を代替手段にするのだろう

その代替手段を作る費用まで含めると、本当に作る価値があるのだろうか

と考えるようになりました。

優れたIT戦略とは、たくさんシステムを作ることではないと思っています。

作る価値があるものを選ぶ。

作る必要のないものには、

「作らない」と判断する。

そして作ったものについては、

変更・移行・終焉まで含めて最後まで面倒を見る。

新規開発をデフォルトの答えにせず、

作る・変える・統合する・残す・やめる

という複数の選択肢から判断する。

ソフトウェアは、作るだけでもコストがかかります。

維持するにもコストがかかります。

そして、

終わらせるためにもコストがかかります。

だからこそ、

「作る」という判断そのものに慎重になること。

それもIT戦略の重要な役割なのではないかと考えています。