「2025年の崖」に挑む、日本企業に待ったなしのレガシー刷新レガシーシステム刷新は「Must」

「2025年の崖」では“IT人材”、“ITシステム”、“IT予算”のそれぞれに問題があると指摘されている。つまり“ヒト”、“モノ”、“カネ”のことである。既存システムをこのまま放置しておくと、2025年以降、年間最大12兆円もの経済損失が生じると言われているが、各企業においてはどのような問題があるのだろうか。ディスカッション第一回では「2025年の崖」問題を具体的に深掘りする。
2020.04.21

対談者紹介

※50音順

エグゼクティブ・パートナー 内田  秀一

独立系ITコンサルティングファームを経て現職。
金融、流通小売業を中心に、IT戦略立案、業務改革、ITガバナンス強化、大規模プロジェクトマネジメント等のプロジェクトに従事。

エグゼクティブ・パートナー 鳥羽々 充英

国内ITベンダーを経て現職。
金融、流通・小売、商社などにおいてITを中心とした戦略立案から実行支援まで幅広いテーマに従事。特にIT戦略・企画立案、大規模システム開発マネジメントプロジェクト等のプロジェクトを多く手掛けている。

エグゼクティブ・パートナー 山本 将之

株式会社 野村総合研究所を経て現職。
流通小売、製造業を中心に、IT戦略立案、業務改革、人材育成、PM/PMO、ITA設計などの支援に従事。
ICT活用ビジネス立上げ、案件化、プロジェクト推進まで、幅広い領域の知見と経験を有する。
共著書に「デジタル化を勝ち抜く新たなIT組織のつくり方」。

レガシーシステムをこのまま放置しておくと、どんな問題があるのか?

―― 「2025年の崖」でレガシーシステムが問題視されていますが、大きな要因である “IT人材”についてどう考えていますか?

鳥羽々 人材不足でよく話題に上がるのは、古いプログラム言語を用いた開発だ。例えば、基幹システムの多くはCOBOLを中心としたバッチシステムで支えられており、2000年代から人材不足が問題視されてきたが、未だ解決できていない。過去からCOBOLシステムの開発を担ってきた人材が定年を控えている一方で、若い世代はより新しいテクノロジーを学びたいと考え、COBOLのような古いプログラム言語で開発することを敬遠する。加えて若い世代は、かつてベテランが作りあげた基幹システムを自分ごととして作り替えることにモチベーションが持てないのだ。

内田 基幹システムの中身の仕様を理解できていないことが重大な問題だ。仕様を知らないために、懸命な調査が必要となり、費用や期間が余計にかかってしまうのが現状で。

山本 本来はCOBOLやJavaといった言語の違いは関係なく、ビジネス要件に対して論理的に設計していけば、あるべき成果物ができあがるもの。しかし現状は、「古びた言語はやりたくない」という心理的障壁があるように感じる。もしCOBOLを扱える人材の給料などの待遇が上がっていけば、開発人材が増えていく可能性はあるだろう。
 
(参考)2025年の崖とは
出典:経済産業省「DXレポート」をもとに、ベイカレントにて編集
―― 古いプログラム言語を学ぼうとする若手がいないのであれば、昔からのベテランSEが中心となってレガシー刷新を進めていけば良いのでしょうか?

鳥羽々 ベテランだけが中心となって議論するべきではなく、若手人材をどうレガシーに関わらせていくかが重要な課題だ。ベテランだけでは過去の知識に引っ張られてしまい、未来のグランドデザインを描けない可能性がある。

山本 確かにレガシー刷新におけるベテランの関わり方は課題だろう。どういう風にマイグレーションするか、ダウンサイジングするかは、ITシステム構築の醍醐味であるにも関わらず、やりたいと思う若手人材が足りていない。このままではグランドデザインの検討のような最上流を担える人材は、ますます不足していくであろう。

―― 若手人材が日本にいないのであれば、例えば海外の人材を活用することが効果的な手段となるのでしょうか?

山本 確かに古いプログラムの開発人材をオフショアに頼っている事例は多いが、その際の論点は、如何に言語や文化の違うオフショア人材をマネジメントし、品質を担保する仕組みを作れるかがポイントになる。日本側のSI企業がその管理ノウハウを持てるならば、開発人材はオフショアに頼っても良いと考えている。

鳥羽々 とはいえ、オフショア開発の品質が悪く問題になる事例は後を絶たない。なぜオフショアで失敗するのかというと、設計書がなくブラックボックス化しているシステムを、日本のエンジニアが十分に理解しないままオフショア企業に依頼してしまうところに端を発する。レガシーシステムには日本企業の長年のノウハウが独自のカスタマイズとして詰っており、そのようなノウハウまではオフショア側で担保はできない。つまり、日本のIT企業が、オフショアを適切に活かすブリッジSEとして機能できていないことが問題である。

―― 日本のSE人材の能力低下こそが大きな課題とのことですが、ではなぜ能力が低下していったのでしょうか? 年収が低いことも大きな要因ですか?

山本 関係していると思う。世の中のSEに対する評価が低いことも原因だが、年収が低いためにSEを目指す人材が少なくなっている。

鳥羽々 年収を上げれば一定の優秀な人材を獲得できるはずだが、IT企業がユーザー企業の要件を着実に構築するだけの受託型企業となっていることも大きな問題であり、ここを変えないと能力低下は止まらない。

山本 ユーザー企業の業務要件を細分化し、あるべきシステムを実現するためには高い設計能力が必要だ。本来、高い設計能力があれば、開発言語に関係なく対応できるはず。突き詰めるとSEのレベル低下の原因は、設計能力に行きつく。システム保守をIT企業に丸投げしてきたことで、管理不能なブラックボックスが出来上がっており、システム改修時はブラックボックスの修正を避けて、似て非なる新たな仕組みを追加するという悪循環が生まれている。これが、システムの不要な肥大化を生む温床になっている。

内田 設計能力が低下していった背景には、2000年前後にシステム開発が標準化と効率化へシフトし、「いかにリスクを取らずにシステムを作るか」を追い求めるようになった変化がある。そして「知っている人に任せる」というアプローチになり、自身で新しいものを作るチャレンジが生まれず、学ぶ環境が無くなっていった。現在はIT人材を成長させるためのアプローチができていない。

鳥羽々 今のレガシーシステムを刷新しなければならない時は必ず来る。その時に設計能力の低いSEしかいないとなると大問題になる。増築を繰り返した巨大なシステムの刷新は、構築当初の難易度を遥かにこえているからだ。

―― SE能力、特に設計能力の低下もあって、企業はなかなかレガシー刷新に踏み出せない現状にあることがわかってきました。ではそのレガシーシステムは経営上どのような意義を持つのでしょうか?

鳥羽々 日本企業の基幹システムの特徴として、多くの独自カスタマイズがあり、それがシステムの複雑化をもたらしている。ERPをカスタマイズして導入しているために、バージョンアップに対応できず、未だに5年前のバージョンを使い続けているといった事例もある。だが一方で、日本企業にとってカスタイマイズは必須とも言える。かつて2000年代には、カスタマイズを無くすために業務をシステムに寄せることも検討されたが、結局断念する結果となった。

山本 差別化する必要のない業務であればカスタマイズは不要だろうが、基本的にはカスタマイズをやめるとビジネスの強みがなくなると考えた企業が多かった。レガシーシステムの多くは遺産であり、顧客や従業員に対して必要な機能を網羅的に提供しているのは事実。有りもののパッケージに乗せると失うものがたくさんある。

鳥羽々 IT部門の立場では、ASPに乗せたほうが安くて保守も楽になるためメリットが大きいが、事業部門からすると他社と差別化が図れないという課題を抱えることになる。

山本 会計や人事といった、どの会社でも変わらないシステムについてはASPに乗せても良いが、他社と差別化したい部分においては、ビジネスに寄与する工夫がなされているため、カスタマイズによって価値が出ている。

―― カスタマイズされノウハウの詰まったシステムは、下手に刷新するとその価値を失ってしまう、ということですが、それならば果たして本当に刷新する必要はあるのでしょうか?

鳥羽々 基幹システムを全て一気に刷新するのは難しいが、このまま放置する選択肢は残されていない。基幹システムの多くは複雑化したことによるブラックボックスの問題を抱えており、新しいビジネスを創出する際の足かせとなっている。スピード感のあるビジネスをするためには、昔ながらのシステムでは間に合わない。そのため足かせは早く取り払っていくべきである。何十年もかけているほど時間の猶予はない。本気でやらなければ企業のビジネスは破滅する。

山本 レガシーシステムを一括りにしてはいけない。レガシーシステムの中でも設計の汚いものは筋が悪く、今後大きく変化するビジネス環境に対応していく足枷となるため、早急刷新の検討を行うべきだ。

鳥羽々 レガシーシステムの多くはホストで動いており、性能は悪くないものが多い。下手にオープン系に変えてしまうと性能が劣化する可能性もある。レガシーをこのままの状態で残すべきかは常に論点となり、方針によって答えは変わる。しかし、基本的には古いものに囚われない方が良い。古いものがデジタル化の足かせになって、未来に繋がらない可能性が高くなる。

レガシーシステムは「老朽化」、「肥大化」、「ブラックボックス化」いずれかに該当するもの

―― レガシーシステムには問題が山積みのものもあれば、遺産と言えるものもあるという整理はできました。しかし総じて古いことによる弊害はつきもの。レガシーシステムは「老朽化」、「肥大化」、「ブラックボックス化」のいずれかに該当すると考えるのですが、この観点でどのような問題が考えられますか?

山本 レガシーシステムの多くは、事業の拡大に合わせて増築・拡張することで、似て非なるプログラムが量産されてきた。このような戦略なき「肥大化」によってレガシー対応は益々ややこしいものになっている。

鳥羽々 戦略なき「肥大化」によって、複数の機能が同じような情報を持ってしまい、整合性を取るためにシステム機能の追加/改修を場当たり的に繰り返す。その結果、更に複雑怪奇なブラックボックスになる悪循環が発生している。

内田 悪循環によって、基幹システムの中枢よりも末端の機能ほどスパゲッティ化している。肥大化は長年使い続けると仕方なく起こるものであるが、刷新時の現行調査に膨大な時間がかかる。プログラムを1行直すだけでも影響調査だけで、手間と時間とコストがかかってしまう。ドキュメントに業務とシステムの相関関係や、システム機能間のつながりが整理されていればブラックボックス化は一定防げるかもしれないが、現実としては人の頭の中にノウハウが詰まっていることが多い。そのノウハウを持つ人材が社内に残っている間に、刷新に踏み出さなければならない。

デジタル・イノベーション・ラボによる総括

経産省が警鐘を鳴らす日本企業のレガシーシステムについて、このまま放置するとどんな問題があるかがディスカッションを通して見えてきた。大きく“ヒト”=IT人材、“モノ”=ITシステム、“カネ”=IT予算の問題があるのに加えて、デジタルがもたらすビジネス機会も逸する可能性が高まる。

レガシーシステムは「老朽化」、「肥大化」、「ブラックボックス化」のいずれかに該当するものであり、どの観点からも刷新することはMustと言えるが、一方で日本企業の基幹システムには遺産とも言える数々の独自カスタマイズが残っているため、刷新への取り組みは非常に難航するものである。

次回はレガシーシステムを刷新することが何故難しいのかについて、ディスカッションを通して明らかにしていく。

We use cookies to enable website functionality, understand the performance of our site, and serve more relevant content. We may also place cookies on our and our partners' behalf to help us deliver more targeted ads and assess the performance of these campaigns. For more information, please review our Privacy Policy(Japanese).

当サイトでは、サイト機能の有効化やパフォーマンス測定、関連性の高いコンテンツ表示といった目的でCookieを使用しています。また、メールマガジンを始めとした当サイトによるキャンペーン実施やその効果測定のためにCookieを使用する場合があります。詳しくはプライバシーポリシーをご参照ください。

×