Featurs

【第3回】レガシー刷新を待ち受ける「受難の連続」

Featruesテーマ別特集

SHARE

膨大なコストを許容できないカネの障壁

 

―― レガシー刷新には膨大なコストがかかるため、“カネ”が障壁となって刷新が進まないことも多いと思われます。社内の賛同を得られず、刷新が進まないケースも見受けられますが、具体的にはどんな問題が起こりえるでしょうか?

鳥羽々 レガシー刷新は高いコストがかかるにもかかわらず、刷新しても現行システムと同じ機能に過ぎないという見え方になってしまう。ユーザーである事業部門はメリットを感じないため、刷新コストに対する反論が出やすくなる。それが難点だ。また事業部門は現行通りの機能保証を求めるため、レア業務の機能まで残そうとしてしまい、事態を更にややこしくする。全ての機能を漏れなく刷新しようとした結果、コストが膨れ上がってしまうのだ。レア機能は思い切って捨てて、事業部門にとってもメリットのある新たな要件を実現した方が、賛同の得やすい取り組みとなるだろう。

内田 現行プログラムを解読し、新システムに載せ替えるだけであれば、ITベンダーだけでも対応できる。しかし、ITベンダーでは業務を深く理解できないので、「この仕様は本当に正しいのか?」、「本当に使う機能なのか?」という判断ができないケースは多いだろう。大規模な刷新プロジェクトはマルチベンダーの体制を組むが、ITベンダーは自社の担当領域しか見ないため、業務全体を俯瞰することは難しい。全体を俯瞰して、整理しながら取り組んで行かねば、コストは跳ね上がる一方であろう。

鳥羽々 IT部門も業務を深く理解できていないため、事業部門の協力無くしては刷新することは難しい。しかし事業部門は通常業務が忙しいため、なかなか協力を得られない場合が多い。過去に刷新が上手くいった事例では、経営層のトップダウンで通常業務から人を切り離していた。事業部門をシステムのFit&Gapの段階から巻き込むことが重要であり、一緒に検討することがコストの圧縮や、高額コストに対する社内理解にもつながっていくはずだ。

―― ITプロジェクトは、どうしても投資対効果の説明を課されることが多くなります。しかしレガシー刷新の場合、効果を出すことが最優先ではないため、投資に対する社内の理解を得られないこともあるはずです。この点についてはどう考えますか?

内田 レガシーを放置しておくとH/WやS/Wの保守料が上がるだけでなく、保守できなくなるという事実を突き付けられると良い。例えばH/Wの保守を際限なく延長すると、部品が無くなり保守自体ができなくなることもある。ベンダー側の特別対応で延長してもらえたとしても、個社対応による費用増加は必然だ。そのようなリスクも考慮し、刷新すべきか検討する必要がある。

鳥羽々 「将来のリスクを見据えて切り替えていくべき」という議論は良い。IT企業の言いなりにならずにコストをコントロールするためには、システムの仕様/移行方式などをユーザー企業側も一定理解しておく必要がある。

―― 社内理解を得られたとしても、かけられるコストには限界もあるでしょう。コストの削減を迫られることが多いと思われますが、社内で納得してもらえる費用感まで下げても刷新することは現実的でしょうか?

鳥羽々 出来なくはないが、大概上手くいかない。コストを下げる場合、事前の仕様調査やドキュメント作成を省略しがちだが、その際は“テストで品質を担保すればよい”となることが多い。しかし上流工程で明確にすべき点を曖昧にしてしまうと、品質担保するためにテスト工程の手戻りが膨大になり、後から発生したコストが当初計画の範囲を超えてしまうことも起こり得る。実際にテストフェーズで発生する問題を数多く見てきたが、大半は当初の仕様がドキュメントに落ち切っていないことから発生したものであった。ただ一方で、レガシー刷新プロジェクトで最も無駄なのは、現行プログラムを調査した成果物とも言われる。既存の機能に対してどこまで完璧な成果物を作る必要があるのかという議論は必ず起きる。今後発生しうるリスクまで含めてコストを整理し、適切な落としどころについて議論しておく必要がある。

IT人材の能力不足が露呈しているヒトの障壁

―― 現行調査を全てドキュメント化することは無駄ということですが、ではいかに無駄を排除するかを検討できる人がいれば、コストの問題が解決する可能性はあるでしょうか?

山本 可能性はあるが、スキル面がネックで難しい場合が多い。最もネックになるのはITアーキテクト(ITA)人材の枯渇であろう。ITAとは最上流からシステムのグランドデザインができるスキルをもった人材だ。まずは業務要件の全体像を把握し、適切にブレイクダウンしながら細分化していくことが求められる。一方で、何十年に渡ってシステムの増改築を繰り返してきたシステムは、難解で管理不能なブラックボックスが出来上がっている場合が多い。その長年の保守運用の中で、希少なITAのような人材は保守運用部門には残っていない。つまり、問題の本質はレガシーシステム特有のブラックボックス化したプログラム自体ではなく、適切に業務の全体像からシステムに落とす設計能力をもった人材の枯渇である。また、ITA人材は市場価値が高く、転職などで社外に流出しやすいことも枯渇する要因である。

―― 前回の議論からも若手人材のSE能力低下が問題視されていましたが、レガシー刷新を行ううえでは具体的にどのような問題があるでしょうか?

鳥羽々 基幹システムを1から作った経験のある若手人材はごく少数で、大規模なシステムに部分的に携わってきた人材がほとんどであるため、全体を俯瞰して見ることが難しい。そのため、レガシー刷新において重要なグランドデザインを描く能力を備えていないのだ。

山本 優秀な人材を抱えるITベンダーは、かつてシステムや言語に関係なく“良いレガシー”を作ってきた。どんな古い言語を使っていても、適切にプログラム分割され、可読性のあるシステムに作り上げていれば、特に問題は発生しない。適切に設計されたシステムであれば、業務ノウハウはプログラムの奥深くではなく、各プログラムを繋ぐジョブフローなどに表れ、保守性の高いシステムが出来上がる。しかし残念ながら、優れたシステムを設計・構築できる人材があまり育っていない現状がある。その一端として、SI業界の待遇が、欧米諸国と比べて見劣りしていることに起因すると考えている。

―― ではシステムを一から作った経験のあるベテラン人材であれば、グランドデザインを描けるということになるでしょうか?

山本 どんな巨大なシステムも最初に構築された時は規模が小さく、時と共に徐々に拡張していったものばかりである。つまり、ベテラン人材が特に優秀だったわけではなく、当初はシステム規模がさほど大きくなかったため、グランドデザインから設計・構築を担えたという見方もできる。

鳥羽々 何十年という歴史の中で増改築を繰り返して肥大化した今のシステムは、誰にも全貌が見えなくなっている。その為、これから描くグランドデザインは、かつて1から作ったものとは大きく異なるため、ベテラン人材に期待すれば良いというものではない。

―― 設計能力以外でも話を聞きたいのですが、大規模プロジェクト特有のマルチベンダー体制を管理する能力も乏しいのではないでしょうか?

内田 新システムに乗せ替えるだけであればITベンダーで対応できるが、マルチベンダー体制の全体感を見るのはユーザー企業でなければならない。ITベンダーは自社の担当領域しか見ないため、業務全体を漏れなく俯瞰することは難しい。

鳥羽々 ある程度のプロジェクト規模になるとマルチベンダー体制となる。どんな天才であっても基幹システム全体を見るのは無理があるため、ITベンダーを束ねていく人材が必要となる。

内田 ユーザー企業に潤沢な人材リソースがある訳ではないので、我々のようなユーザー企業の目線でご支援できるITコンサルが、マルチベンダー体制のマネジメントを行うことが多く、プロジェクトを成功に導くために重要な役割を担わせてもらっていると感じる。

現行踏襲という魔の言葉に踊らされるシステムの障壁

―― 増改築を繰り返した結果、現行のシステムは非常に複雑化していますので、仕様通りに刷新することが難しいのではないでしょうか? 

鳥羽々 現行踏襲は本当に難しい。言うは易しだが、プログラムを読んだだけでは何の処理かを理解できないものが多い。しかし事業部門は業務に支障がないことを大前提に要求するため、発生頻度の低いレアな業務まで現行通りの仕様を追求することになる。複雑化したあらゆる業務を漏れなく設計・構築しようとすれば、コストと工数が肥大化し、投資対効果が下がっていく。そうならないために、事業部門と合意を取りながら刷新する機能を削っていくことも、成功における重要なポイントだ。

内田 現行踏襲にはデメリットが多く、レガシー刷新を難しくさせている元凶でもある。言語が変われば全く同じ仕様で実現することが出来ないことも、ユーザー企業側が理解せねばならない。

―― 現行のドキュメントが無いという問題もありますが、どの程度のダメージが想定されますか?

鳥羽々 システム全体を整理した資料がないと厳しい。プログラムを保守するために必要な細かいドキュメントしか残っておらず、全体像はIT人材の頭の中にしかないというケースも多い。設計書が揃っていない状態でプログラムから現行調査するとなると膨大なコストがかかる上、正しくドキュメント化できるかもわからない。

山本 90年代より前に作られたシステムは、ドキュメントが手書きの紙であることもあり、今では残っていないことも多い。その場合は現行プログラムから設計書をリバースして作っていくことになるが、難解なプログラムであればあるほど難しい作業になる。また詳細仕様の棚卸しができても、業務目線を加える基本設計作業が更に難しい作業となる。プログラムレベルで詳細処理を見える化しても、それが業務上何の意味を持つかまで明確に出来ないことが多いからだ。レガシー刷新では、このようなケースが山ほどあるため、膨大な時間と工数がかかってしまう。

経営層の決意をにぶらせるリスクの障壁

―― これまでの議論からもレガシー刷新は非常に難しく、リスクが大きい取り組みであることは明白でした。では、そんなリスクを拒むことも刷新の足かせになっているのではないでしょうか? 

鳥羽々 日本のITシステム開発の構造に問題がある。プロジェクトで問題が発生した際には、ユーザー企業は開発側であるITベンダーの責とすることが多い。そしてITベンダーは問題の要因を、二次請けや三次請けの会社に追及していくケースもある。

内田 会社の組織風土として、「リスクを取りたくない」、「責任を取れるレベルではない」といった考えから、「今まで通りの方が得策」と考える傾向もある。

鳥羽々 崖を越えるための議論が、定年退職の近い会社の上位層だけで行われると、自分たちがいる間はあえて大きなリスクを冒さなくても良いと考えてしまうこともあるだろう。その繰り返しで、刷新がどんどん後回しになって現在に至っている企業は多い。

―― リスクとは具体的にどのようなものが想定されますか? 

鳥羽々 例えば金融業界ではトラブルを起こしたら金融庁に報告する必要があり、担当者は退場してしまう恐れもある。

山本 レガシーシステムに手を入れたら多少のトラブルはつきもの。リスクを恐れるのであれば刷新しない手もあるが、それでは攻めに転じることはできず崖に着実に近づいて行く。

内田 金融庁を始めとして、国が攻めに転じる企業を支援すると良いかもしれない。それによって背中を押されて動き出す企業もいると思う。大規模な刷新プロジェクトとなると、どれだけ綿密な準備をしてもどこかで問題が発生する。事前に「問題発生時はこういう体制で対処する」といった合意をしておくと金融庁などの理解も得やすいかもしれない。

鳥羽々 ただ実際は甘くなく、金融庁のお叱りを受けることでビジネス機会を喪失することもある。そこまで想定したうえで、企業が覚悟を決められるかというと難しいと思う。失敗したら大惨事だからこそ、今までの失敗を踏まえて、同じ失敗を繰り返さないようにどうすべきかを考え、レガシー刷新を前に進めるしかない。

―― レガシー刷新のリスクが消えることはないため、覚悟を持って進めなければならないということでしょうか?

山本 レガシー刷新プロジェクトに限らずシステム開発にはトラブルがつきものだが、リスクを恐れすぎていることも問題だ。一切のトラブルなくシステムを刷新することは不可能であり、それを理解しなければレガシー脱却は進まない。システムに限らず、新しいものに作り替えたら必ず至らない点は出てくる。それを見つけ、改善しながらブラッシュアップしていくことで良いものに仕上がっていく。チャレンジにはリスクマネジメントが必要不可欠である。現行機能は保証されて当然と思っているような場合は、その考えが間違いであることに気付いておかねばならない。

鳥羽々 リスクを恐れてレガシーを放置して、自然に問題が解決されていくというシナリオはありえない。基幹システムの多くは老朽化・複雑化・ブラックボックス化したレガシーシステムで、新しいビジネスを創出する際の足かせとなって自由度が奪われている。スピード感のあるビジネスをするためには、昔ながらのシステムでは間に合わない。今のレガシーシステムをどうにかしなければならない時は必ず来る。これから20年以内に全て切り替えるとすると、時間の猶予がない。今、本気でやらなければ必ず破滅と覚悟を決めることが必要だ。

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

レガシー刷新が難しい理由を、“ヒト”、“モノ”、“カネ”と“リスク”に分けて議論してきた。様々な障壁があるが、整理してみると下図のようになる。

必要なのは障壁を正しく認識し、壁を越えるために必要な対策を考えておくことだ。
次回は極めて難しいレガシーシステムの刷新プロジェクトを成功に導くために、効果的な対策となる行動指針について、ディスカッションした結果を公開する。

対談者紹介

※50音順

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

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

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

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

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

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

SHARE