そんなレガシーシステムで大丈夫か?

さった1月に開催された BSIA 例会で、経済産業省が公開して話題を呼んでいる DX レポートについて中野課長よりご講演をいただきました。

bsia.or.jp


私も大変興味深いテーマであり、直接、お話を伺えてよかったです。エンタープライズ開発に携わっている人へは是非とも今の時期に一度、聞かれることをおすすめします。宣伝になりますが、きたる4月24日に予定されている超高速開発コミュニティ第6回総会の記念講演に中野課長がお話されることになりました。ご都合のつく方はこの機会をお見逃しなく。今がまさに旬のテーマです。

www.x-rad.jp


さて本題です。さきの例会で、会場から次のような質問がありました。

今、レガシーシステムを運用しているが、特に問題を感じていない。レガシーシステムがすべて悪い、ということではないのでは?

まったく同感です。古いアーキテクチャや過去の技術だからダメ、ということではないはずです。
では、問題のないレガシーシステムとはどういうものか。私の視点では「変更の容易性」が担保されているなら大丈夫というものです。

DXレポートが想定している、エンタープライズ(いわゆる基幹系)が目指すべき変更容易性の指標があります。それは「サービス追加にかかるリリース作業にかかる期間 = 数日間」というものです。ちなみに現状を数ヶ月ととらえており、それを数日間にするという数値目標です。現在の(レガシー)システムがこの指標を達成しているなら、経営陣は安心して DX に取り組めます。

しかし私の限られた営業活動で見聞しているところでは、かなり難しい指標ではないかと感じています。その理由は次のとおりです。

  • 対象システムの設計情報(ドキュメント)が存在しない、または信頼できない。そのため変更に対する影響分析に時間を要する。
  • 変更仕様を理解し、適切なテストが行えるシステムエンジニアまたはプログラマが近くにいない。
  • システムの入れ替えに関する影響が大きすぎる。

もしくは、指標は達成しているものの、

  • その環境を維持するために、莫大なコストがかかっている。
  • 適切なセキュリティを確保できているかどうかは疑わしい。社内システムだから…という前提に甘えている。

ということであれば、隠れた問題になっています。

この数値目標はあくまでも結果であり、その達成のために少なくとも次のような配慮を行う必要がある、と解釈した方がいいでしょう。

  • 設計情報(ドキュメント)と、目の前で稼働しているシステムは完全に同期しているということを(人間の努力に依存するのではなく)仕組みとして担保できるようにすること。
  • 少人数で大規模なシステムを運用かつ改変する、いわゆる DevOps 体制を敷くこと。
  • システムの部分的入れ替えを可能とし、かつそれを頻繁に行えるような仕組みを備えること。

今、DXレポートのおかげでエンタープライズの解体と再構築に注目が集まっているようですが、目の前のコストだけをみて再開発に着手するのではなく、上に記したようなことを実現できるような仕組みを備えることを意識した方がよいです。少なくとも何年か前の営業活動で散見されたような(中身のよくわからない)システムリプレース提案や、オフショアで開発コスト削減といった観点で捉えているようでは DX レポートの意図を理解できていない、といわざるをえません。

その意図を汲み取らずに再構築してしまったシステムは、結局のところ作り直す前と本質的に同じ問題を抱えているため、すぐに「いつぞやのレガシーシステムと同じ」扱いになってしまいます。発注側(お客様)は再開発を提案する SIer に対して、このような視点をどう提案してくるか、をご確認いただくと良いかと思います。