既存システムリプレイスの話

今回は社内システム開発をやっていると、たまに当たるシステムリプレイスの四方山話です。

2019年あたりに「2025年の崖」というセンセーショナルな言葉を経産省が発表してから、DXやIoTという言葉が世間を賑わせてしばらく経ちますね。

この辺りは私は前職に勤めていたのですが、やはりそのような世相に合わせて私の勤めていた企業でも、システムの新造だったりリプレイスの話というのは持ち上がりました。

そんな中で私が感じたことを色々と書いていきたいと思います。

なんで全部変えようとすんの？

システムリプレイスを考えるときに、既存のシステムを置き換えるという言葉の感じ方からかいきなり
「既存システムを置き換えるといくらかかる！」
「コストが高くつく！」
「リスクは誰が拾うんだ！」
という議論が始まって、全然案件として立ち上がってすらいかないことって、皆さん経験したことありませんか？

20年も30年も稼働してきたシステムですから、いきなり全部置き換えようとすればそりゃぁ処理もデータも複雑化しています。
当時のエンジニアの能力としても今ほどオブジェクト指向設計とか継続的インテグレーションなんていう物は普及していませんでした。
それらのことを思えば突然全取り換えをしようとすれば莫大な時間とお金がかかるのは当然のことなのです。

ただ、
「それだけのお金をかけてもやらなければならない」
もしくは
「それだけお金をかけるのは無理なんだからやらない」
というこれらの両面の主張に対しては私は疑問を持っています。

現実に安定して稼働し続けているシステムなのであれば、急に全とっかえする必要はないわけですし、かといって業態とシステムのミスマッチが増えていくのを放置するのは、どう考えても緩やかな滅亡への道です。

この問題に折り合いがつかないのは、「既存システム全て」という対象で議論してしまうからです。
ですから、このような議論が生まれないようにしてリプレイスを案件として成立させるためには、「既存システム全て」という論点を捨ててしまえばいいのです。

まずは小規模から

巨大なシステムをリプレイスする場合のアプローチとして取るべきは、リソースを集中しての大規模置き換えではなく、小規模なシステムを新造してそれを育て、数年後には気づいたら旧システムは使われなくなっていて、最終的には置き換わっているという、漸進的なアプローチだと私は思っています。

それがどれぐらい小規模かというと、C#やjavaを目安に語るのであれば、一人頭コード一万行で収まるくらいのサクッとできる程度です。
私自身、とある中堅企業や小企業のシステムリプレイスを数年ずつで実現した経験があってこのような考えに至っています。

具体的にどうやるのか

具体的にどうするのかというと、まずは既存のシステムからそのくらいの開発で同等の機能が実現できそうなソースコードで構成された機能を選定します。
この時のポイントは三つあります。

• 既存のシステムとの連携を考えておくこと
  新しく作るシステムは、何らかの入力を受け付けて、新しい使いやすい情報を吐き出すはずです。
  しかし、いくらそちらの利便性が高かったとしても既存システムへの情報の入力が必要なくなるわけではありません。
  なので、新しい情報を古い情報に変換して旧システムに入力する仕組みは必要になります。
  それはEatherNetを使用した直接連携等という高度なものでなくて構いません。
  CSVで吐き出して流し込むとか、RPAを使用して自動で画面入力させるとか、出来るだけ簡単な方法で構わないのです。
  むしろ人の手が介在していた方が、運用開始後にチェック機能が働くので、運用しながら品質改善も図れて良いとさえ言えます。

• 処理は徹底して抽象化、データは徹底して正規化した上で開発すること
  徹底して抽象化された処理は、使いまわしが非常に効くライブラリとして実装することができます。
  意味論的に徹底した切り分けを行い、一つ一つのテーブルが十分に分割されて設計されたデータベースは、テーブル同士を組み合わせてかなり柔軟に導出表を形作ることができます。
  漸進的なアプローチでシステムリプレイスを進行するということは、仕様変更や仕様追加を従来の開発よりも多く受け入れるということですので、
  たとえ工数がかかったとしても柔軟性に振り切った設計を行った方が、後々に発生するコストを防げます。

• 出来るだけ小さい社内組織が著しく困っている機能を選ぶ
  複数の部署が絡む機能の場合、あちらを立てればこちらが立たず、結果何も進まないという状況に陥りがちです。
  ですから可能な限り使用する部署が少なく、また困っている部分をどう改善するかに集中します。
  そうすることで自然と開発規模も抑えられるため予算獲得や案件の提案が通りやすく、また開発完了後に別の機能のリプレイスに移る際には、受益した組織が自分たちの後ろ盾になってくれます。

次にこれらのポイントをしっかり押さえつつ、遅滞なく開発を走り切ります。過去の経験を基に言えば、案件として小規模に抑えているので、スケジュールを順守することはそれほど難しくありません。
また規模的にも半期でどうにかなってしまう程度ですので、上期下期の人事評価のタイミングで、目に見える成果として報告しやすいという利点もあります。

最後に、そのような小規模な成功を盾に、次の新たな小規模機能の置き換えを、新システムへの機能追加案件として提案、通します。
これを繰り返しているうちに、社内システム開発の置き換えに対する経営側の見方、考え方も変わっていきますので、あとは場合によっては全体をこの繰り返しで置き換えるという計画を提案するなり、そのような小規模開発の繰り返しを定常業務として部署に定着させるなり、全体の置き換えが走り切るまでのアプローチを組織の風土に合わせて根付かせるだけです。

さいごに

ここに書いたのは、私が経験して実績を残した勝ちパターンを基にしたアプローチです。
「可及的速やかにシステムを刷新しなければならない！」といった風土には合いませんし、ITリテラシーの高い企業ではこんなアプローチはそもそも取る必要がない場合もあります。

ですがこれまでの経験上、「やりたいけど出来ていない」といった具合に停滞してしまっている企業では、非常に有効なアプローチだと感じていますので、社内システムの刷新におかれましては、頭の隅に置いてみてもらえれば幸いだと感じます。