第1回　待ったなしのレガシーシステム対応を前に急ぐべき人材育成

目次

1.レガシーシステムを取り巻く現状

2.これからのプロジェクトキーマンに求められるスキル

1.レガシーシステムを取り巻く現状

阻害要因は「複雑化したシステム」

2023年5月に新型コロナウイルスが「5類」に移行し、「withコロナ」から「afterコロナ」へ転換したことから、日本国内では市場経済がコロナ以前の状態へ戻ることへの期待が高まっています。
また、内閣府からその後に発表されたさまざまな指数も高い水準であり、物価上昇の懸念はあるものの景気は持ち直していくとの見方もあります。

VUCAの時代といわれ、企業はますます予測困難な未来を想定しなければなりませんが、これからのビジネスチャンスを逃すまいとするビジネス活動もますます活発化していくことでしょう。
そして、この激動の波を乗り切るためのIT投資、特にDXを主導していくための戦略的な投資に対しても、これまで以上に注目が集まるものと思われます。

そのいっぽうで、コロナ禍の数年間を挟んで10年以上も先送りしてきたレガシーシステム周辺の問題は手つかずのままとなっています。
導入から20年を超え、基幹システムなどの古いシステムの多くは過去の技術（当時は先端であった仕組み）で構築されており、一般的にはレガシーシステムと呼ばれています。
1980年代に多くの企業が導入していたメインフレームやオフコン（オフィスコンピュータ）と呼ばれるシステムなどもこれに該当しますが、これらのシステムの刷新や見直しは簡単ではありません。

一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2023 ユーザー企業のIT投資・活用の最新動向（2023年度調査）」によれば、レガシーシステム刷新の阻害要因の1位は「複雑化したシステム」（59.3%）とあります。

また、レガシーシステムの維持以外の「攻め」の領域となる、データドリブン経営の実現を目指す戦略的なシステムに対しては、多額の費用と推進体制の構築が必要となるため、2位以降は「IT投資の増加、予算確保」（48.8%）、「要員確保」（44.3%）といった回答が続いています。

システムの業務仕様や運用の共通理解が必要

人材確保の問題もあります。
多くの調査資料によると、日本のIT人材の不足は深刻であり、その数は2022年には30万人以上、2030年には45万人へと膨れ上がると予測されています。

しかも、レガシーシステムを抱える日本企業では、
「古いシステムのドキュメントが更新されていない」
「業務ナレッジが継承できていない」
「ベテランの退職によってトラブルへの対処すらできない」
といった声もよく聞かれます。

ベンダーに保守・運用業務の多くを任せている企業では業務やシステムに精通している社員が少ない、あるいは不在のため、仮に問題に気づいたとしても自分たちだけでは身動きが取れません。

また、ベンダー側も企業の広範囲かつ細かい業務について熟知していないために、迅速な対応が困難となっているのです。

そのような状況下でのシステム刷新プロジェクトでは、新しい要件やビジネス要求は採り入れない、つまり「基本的な業務要件は今と同じ。」という前提でスタートするケースもよく見かけます。

にも拘わらず、失敗するプロジェクトが後を絶たないのはなぜでしょうか。
「今と同じ」としたとしても、ベンダー側はもちろん、当事者である企業側が編成したプロジェクトの中で、そもそも現状に対する共通の理解、認識を持てていないからです。

最近ではプログラミング言語を変更するなどのマイグレーションに着手する企業が増えていますが、旧システムの業務仕様や運用の詳細が不明のまま、テストやデータ移行のフェーズに進んでしまった結果、エラーが多発しているプロジェクトも後を絶たないようです。
比較的順調にマイグレーションが進んだとしても、中身がブラックボックスであることに変わりはないのです

2.これからのプロジェクトキーマンに求められるスキル

阻害要因は「複雑化したシステム」

「システムとして何をつくってきたのか」、「どのような実装手段を採用してきたのか」は、仕様書を参照すれば、だいたいのことはわかります。
が、そもそも設計書などのドキュメント類が最新の状態に更新されていないことに加え、当時のプロジェクト関係者が不在の今、「どうしてこうなっているのか」「なぜこのようにつくったのか」がまったくわからないシステムを多くの企業は抱えているのです。
そのため、レガシーシステムを刷新するプロジェクトに業務に精通したプロジェクトリーダをアサインしたはずなのに、前章でお話しした業務要件の理解の違いや調整不足による“手戻り”が発生しがちです。

プロジェクトでは当然のことながら自然言語によるコミュニケーションだけではなく、それを補足するホワイトボードのチャートや概要図、議事録による情報伝達も行われていますが、十分ではありません。
全体の工数の中で業務要件を詰めていくコミュニケーションの時間は、実は60～70%を占めるといわれているにもかかわらず、その部分の改善はほとんど見過ごされているのです。

総論賛成・各論反対の中、大規模整合性を保ちつつ、業務要件定義を進めなければならないこれからのプロジェクトキーマンに求められるのは、以下のスキルです。
①システムとビジネス（業務）に精通すること
②高いコミュニケーション能力をもつこと

このようなスキルを持つリーダーとメンバーで構成される『スキルの高い上流設計チーム』を多くのプロジェクトとそのマネージャが切望しています。
要件定義工程のミスや見落としがあった場合に、その不備を後ろの工程で取り返すことは非常に困難だからです。
しかしながら、「顧客企業の体制に現状業務やシステムの全貌がわかる人がいない。設計仕様書が古い。肝心な事実に限って後になってから顕在化する。確認しようにも現業部門へのヒアリング調整ができない。」…など、システムインテグレーターや、新しい基盤となるパッケージ導入を進めるベンダーからの悩みの声は、今も昔も変わらず聞こえてきます。

次号では、現状業務の可視化と問題の共有方法についてお伝えいたします。