なぜ、大きな投資をして作ったシステムが、数年後に「作り直し（リプレース）」になるのか。経営者なら、一度はこの問いに向き合ったことがあるのではないか。
せっかく作ったはずのシステムが、気づけば「使いにくい」「改修できない」状態になっている。現場から不満の声が上がり、開発会社に相談するたびに高額な見積もりが返ってくる。やがて「もう限界です、作り直しましょう」となり、また多額の費用をかけてリプレースに着手する。今度こそ将来を見据えた設計にしようと理想のシステムを作り上げるが、完成した頃には要件が変わっており、数年後にはまた同じことが繰り返される。
こうしたリプレースの繰り返しを止めるためには、経営レベルでのシステム戦略から見直しが必要となると考えている。その肝は、一過性のシステム開発とするのではなく、継続的に安定して動くよう保守を繰り返し、必要に応じて持続的な拡張（エンハンス）を続けていく戦略である。
従来の理想を描いて一気に作る考え方を「ビッグバン戦略」、それに対してシステムを育て続ける考え方を「エンハンス戦略」と呼ぶこととする。この記事では、エンハンス戦略とその実践事例について紹介する。
リプレースが繰り返される本当の理由
システム開発で繰り返されるリプレースの根本原因は、「ビッグバン戦略」と呼ぶべき考え方にあると考えている。
ビッグバン戦略とは、数年後の「理想の姿（To-be）」を先に描き、現状（As-is）とのギャップを埋める形でシステムを設計・構築する考え方だ。大規模なシステム導入などで広く採用されてきた。
しかし、「未来の理想を先に描く」という発想が、設計・心理・経済の三つの問題を引き起こす。
まず、設計の問題。未来を描いた時点から開発が完了するまでの間にも、ビジネスは変化し続ける。数年かけて完成したシステムが稼働する頃には、当初描いた「理想」がすでに古くなっていることは珍しくない。
次に、心理の問題。「理想の未来」を起点に設計すると、「将来必要になるかもしれない」という不安から、本当に欲しいかどうかもわからない機能まで盛り込んでしまいがちだ。「どうせ作るなら一度で全部やってしまおう」という心理も働き、要件はどんどん膨らんでいく。そして大きな投資をした後は「失敗できない」というプレッシャーが生まれ、途中で方向を修正することが難しくなる。
そして、経済の問題。膨らんだ要件の中には、稼働後に使われない機能が少なくない。使われなかった機能の開発費は、純粋な損失だ。さらに、大きく作るほど内部の複雑さが増し、改修コストが上がっていく。投資するほど身動きが取れなくなるという逆説。リプレースを検討しようにも、移行コストが読めないために判断が遅れ、傷口がさらに広がっていくことになる。
こうした問題が重なり合った結果、システムは「改修できないもの」になっていく。本当の課題は、バグやパフォーマンス不足ではなく、時間の経過とともに改修・保守のコストが増大し続けることにある。改修できなくなったとき、リプレースという選択肢を取らざるを得なくなる。こうして、同じことが繰り返される。
システムは「負債」にも「資産」にもなる
経営者の視点からすれば、システムへの投資は本来、資産形成のはずだ。しかし現実には、多くのシステムが時間の経過とともに「負債」として積み上がっていく。
改修のたびにコストがかかり、触れるほどに複雑さが増す。開発会社に相談するたびに高額な見積もりが返ってくる。「使い続けているのに、なぜこんなにお金がかかるのか」。その感覚こそ、システムが負債化しているサインだ。
一方で、システムが「資産」として機能している状態とはどういうものか。業務に使い続けるほどデータが蓄積され、そのデータをもとに意思決定ができる。新しい機能を加えるたびに、システム全体の価値が上がっていく。事業の変化にシステムが柔軟に対応できる。そうしたシステムこそが、競争力の源泉になる。
同じ「システムへの投資」でも、戦略次第で資産にも負債にもなる。ビッグバン戦略は、意図せずシステムを負債化させやすいと感じている。エンハンス戦略は、システムを資産として育てていくための考え方である。
エンハンス戦略とは何か
システムの負債化とリプレースの循環を断ち切るための考え方が、エンハンス戦略となる。エンハンス戦略の核心は、「理想の完成形を先に作らない」ことにある。代わりに、「今の業務に完全にフィットした最小構成を作り、継続的に育てていく」という姿勢をとる。
ビッグバン戦略に対し、エンハンス戦略は「将来にわたってリプレースしない」ことを目指す戦略だ。完成させることがゴールではなく、動き続けることがゴールだ。
| ビッグバン戦略 | エンハンス戦略 | |
|---|---|---|
| 設計思想 | 数年後の理想状態を描いて作る | 今の業務を小さくシステム化する |
| 開発スタイル | 大きく作ってリリース | 小さく作って継続的に育てる |
| リリース後 | 保守フェーズへ移行 | エンハンスを繰り返す |
| 数年後 | リプレースが必要になりやすい | リプレースなく拡張できる |
この戦略においてもっとも大切なのは、「仕掛品を作らない」ことだ。要件定義書や設計書が積み上がっている状態は、製造業でいえば倉庫に眠る在庫と同じで、価値を生まない。常に「動くシステム」として出荷し続けることが、無駄をなくすもっとも確かな方法だと考えている。
小さく始めて、動く状態を維持しながら育てていく。「それはアジャイルと同じではないか」と感じるかもしれない。重なる部分はある。ただ、アジャイル開発が「どう作るか」という開発の進め方の話であるのに対し、エンハンス戦略は「どう投資するか」という経営判断の話だ。
アジャイル開発を採用していても、経営が「2年後までに理想のシステムを完成させる」と決めていれば、それはビッグバン戦略の中でアジャイルに作っているに過ぎない。完成形を定義せず、継続的に育てていくと決めること。エンハンス戦略は、その経営の意思決定から始まる。
なぜエンハンス戦略は機能するのか
エンハンス戦略が実際に機能するのは、システムをプロジェクトではなくプロダクトとして捉えているからだ。プロジェクトには完了があるが、プロダクトに完了はない。だからこそ、小さく始めることが大切になる。
「理想の未来」を描いてから作ると、使われるかどうかわからない機能まで盛り込んでしまう。しかし実際のところ、何が本当に必要かは、動かしてみるまでわからない。小さく作って動かすことで、初めて現場の反応が得られ、何を次に作るべきかが見えてくる。
そして、動く状態を維持したまま、少しずつ拡張していくことがエンハンス戦略の要だ。システムは常に本番で動いている。その上で、一つひとつのエンハンスを積み重ねていく。一度に大きく変えようとするほどリスクが高まる。小さな変更を継続的に重ねることで、リスクを抑えながら確実に育てていける。
この育て方を支えるのが、システムの構成要素の「寿命」の序列を意識することだ。建物に喩えれば、土地にあたるのがデータモデル、構造にあたるのがアーキテクチャ、内装にあたるのがプログラミング言語やフレームワークだ。寿命もこの順に長い。この序列に従い、まずデータモデルを整え、その上でアーキテクチャを固める。言語やフレームワークは必要に応じて部分的に入れ替えればいい。それは「リプレース」ではなく「エンハンス」だ。
ただし、この戦略は開発プロセスの工夫だけでは成り立たない。経営としての判断も必要になる。
まず、チームを継続させなければならない。プロジェクト型の開発では、完成とともにチームが解散する。エンハンス戦略では、システムの文脈を知っているエンジニアが継続的に関わることで初めて、小さな変更を安全に積み重ねられる。内製のチームもしくは内製に準じるような形で人材を抱え続ける判断も欠かせない。
加えて、コードの読みやすさや技術的負債のない構造を保つことへの投資も欠かせない。内的品質、つまりユーザーからは見えないがシステムの変更しやすさを左右する品質への投資は、エンジニアの仕事に見えるが、経営の判断でもある。ここを惜しむと、エンハンスのたびにコストが増し、やがてエンハンス戦略は成り立たなくなる。
そしてもう一つ、ビジネスと開発を分離させないことだ。受発注の関係になると、要件を固めてから発注し、完成品を受け取るサイクルになる。エンハンス戦略では、ビジネスの変化に開発がすぐに対応できる距離感が欠かせない。パートナーとして協働できる関係を、経営として構築することが大切だ。
実証：クラシコムでの実践
エンハンス戦略には、すでに実践の裏付けがある。私が取締役CTOを務めるクラシコムで、まさにこの戦略を実践している。
クラシコムの運営する「北欧、暮らしの道具店」は、単なるECサイトではなく、独自のコンテンツや多様なチャネルを組み合わせたライフカルチャープラットフォームである。それを支えているのが内製で育て続けてきたシステムだ。年商100億規模の上場企業がこれほどのシステムを内製で、しかも10数人のメンバーで作り続けている。
昨年からは、ソニックガーデンが「納品のない受託開発」でシステム開発に加わり、私が経営目線でシステム戦略を検討していく立場として関わっている。エンハンス戦略で大切なのは、内製かどうかよりも、システムの文脈を知ったチームが継続的に関わり続けることだ。納品して終わりではなく、パートナーとして一緒に育てていく関係があるからこそ、この戦略が成り立っている。
クラシコムの内製システムは10年以上の歴史がある。事業が成長していく中で、機能追加をしたり現場の要望に応えたりしていく中で、見通しの良いデータやアーキテクチャにはできない部分が出てきた。これまでの対応は間違いだったというわけではなく、その時々での最善だったとは思うが、どうしてもシステムの保守と拡張を同時に進めることが難しくなっていた。
エンハンス戦略はすべてのリプレースを否定するものではない。土台がしっかりしていない状態では、エンハンスを積み重ねることはできないからだ。
クラシコムの場合も、まずECの根幹となる受注管理システムの部分的なリプレースから始めた。ただし、その際に優先したのは「理想の完成形を作ること」ではなく、「もっとも寿命の長いデータモデルをしっかり整えること」だった。受注から仕入までの一連の流れをデータモデルとして定義し直すことで、業務の実態をソフトウェアで把握できる状態を作った。
このリプレース自体も、エンハンス戦略の考え方に従って進めた。最初から全機能を作り切るのではなく、まず最小限で動く状態を作ることを優先した。新システムと現行システムを並行稼働させながら、新システム側はエンハンスを続けていく。「完成してから切り替える」のではなく、「動く状態を保ちながら育てていく」という進め方。これはまさに、エンハンス戦略を置き換えの場面でも実践したものだと考えている。
この取り組みを通じて、エンハンス戦略で進めてよいという手応えを得た。小さくてもデータモデルが整ったことで、現場からのフィードバックを受けての改修速度が明らかに上がった。この先は、ソフトウェアを前提として業務全体とデータの流れをつかめるようになっていくだろう。
そして今まさに取り組んでいるのが、アーキテクチャの統合だ。複数の技術でバラバラに作られたシステムを、一つの統一された構成へ移行している。統合が進むほどに全体の見通しが良くなり、次に何を作るかのロードマップも立てやすくなる。データモデルを整えてから、アーキテクチャを統合する。この順番が、今回のエンハンス戦略を機能させるための正しい道筋だったと、実践を通じて感じている。
補足：「AIで安くリプレースすればいい」という考えについて
AIの登場で、コードを生成するコストは大きく下がった。「AIで安くリプレースすればいい」という発想が出てくるのはわかる。
ただ、コードが生成できても、それが業務ロジックとして正しいかどうかは別の話だ。テストを自動生成したとしても、そのテスト自体が正しいかどうかを確かめるのは、最終的に人間の仕事だ。膨大に生成されたコードを本番環境に適用するには、相応の検証コストがかかる。
加えて、データベースに蓄積されたデータには、コードには現れない「暗黙のルール」が宿っている。過去の業務上の例外処理や、長年の運用の中で育ってきた経緯がそこにある。AIはコードを変換できても、データの裏側にある文脈までは解釈できない。膨大なデータを一括移行するリスクは、ビジネスの停止につながりかねない。
全体リプレースは、一度でも相当なコストと覚悟が必要な出来事だ。それを数年おきに繰り返す前提でシステムを持つことは、経営として合理的ではないと感じている。
一方で、AIはエンハンス戦略との相性がとても良いと思っている。小さな改善を継続的に積み重ねるエンハンスの場面では、AIはとても頼もしいパートナーになる。既存のコードを読み解きながら変更点を提案したり、テストを補助したり、ドキュメントを整えたりと、日々の改善の質とスピードを上げてくれる。リプレースのためではなく、継続のためにAIを使う。そういう使い方の方が、システムを資産として育てていく考え方と自然に合うのではないかと思っている。
エンハンス戦略を広めていきたい
ビッグバン戦略に代わる考え方として、エンハンス戦略という言葉を多くの人に、特に経営者の判断指針として使ってもらえるようになれば嬉しい。
エンハンス戦略という言葉は私の造語だが、実践としてはすでに10年以上の裏付けがある。ソニックガーデンの「納品のない受託開発」での取り組みは、すべてがエンハンス戦略のもとに行われており、稼働から10年以上エンハンスし続けて事業成長を続けている事例もある。クラシコムでの実践が、さらにその確度を高めてきている。
エンハンス戦略で手に入るのは、事業や業務にとって過不足のないフィットした状態のソフトウェアなのだ。
ビジネスは変化し続けるものだ。その変化に寄り添い続けられるシステムを持つことが、これからの時代の競争力になっていくのではないか。エンハンス戦略という考え方が、一つの選択肢として定着していくことを願っている。
エンハンス戦略の背景にある、ソフトウェア開発の本質的な問題については、拙著『人が増えても速くならない』でより詳しく論じている。この記事と合わせて読んでいただけると嬉しい。
