現状維持は選択肢ではない:技術的負債のローンを返済してイノベーションを加速する

< 1 分(想定読了時間)
現状維持は選択肢ではない:技術的負債のローンを返済してイノベーションを加速する

経済産業省の~ITシステム「2025年の崖」の克服とDXの本格的な展開~をみても、「レガシーシステムの中には、短期的な観点でシステムを開発し、結果として、長期的に運用費や保守費が高騰している状態のものも多い。これは、本来不必要だった運用・保守費を 支払い続けることを意味し、一種の負債ととらえることができる。こうした負債は「技術的負債」(Technical Debt)と呼ばれている。技術的負債を抱えているということは、将来にわたってDXの実行のために必要となる攻めのIT投資に資金・人材を振り向けることが困難 となっていることも意味している。」※1と技術的負債の問題点が記載されています。

今日のデジタル経済がますます激しくなる中で、競争は激しくなっています。現在のビジネスモデルとテクノロジーに固執すると、多くの企業が競合他社に打ち負かされます。現状維持は選択肢ではありません。しかし、過去の決定によって生じた技術的負債のコストは、成長と革新に対する障壁を生み出します。では、どのようにして技術的負債を解決して、資金を解放してイノベーションを推進すればいいのでしょうか?

なお、技術的負債とは、1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行ったもので、「最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。オブジェクト指向は、こうした作業を許容可能にしてくれる。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。」と定義している※2プログラム開発から来ています。

技術の変化は増加していますが、コストも高くなってきています。

企業は、顧客の期待が増え続けており、より迅速に、より頻繁に変化することが求められています。そのために、新しいテクノロジーと新しいビジネスモデルを採用しなければならないと感じています。顧客が体験しているすべてが繋がった世界は、企業が自身を改革する原因となっています。 ほとんどの場合は、他社が模倣できないようなイノベーションの実現は安くはありません。革新をサポートするためのデジタル投資を行うと、予算に大きな課題が生じる可能性があります。多くの場合、CIOはIT予算の90%を継続的な運用と機能強化に費やし、競争上の優位性と成長という中期計画に乗っ取った目標をサポートする新しいテクノロジーとイノベーションへの投資に予算の10%しか残しません。このような予算モデルはもはや持続可能ではありません。

技術的負債は技術の変化を複雑にし、コストを増加
技術的な負債は、すぐに使用可能なソリューションから逸脱することで発生する可能性があり、ソフトウェア(コードの負債)、ハードウェア、およびサポート環境に適用されます。インターフェイスとカスタマイズは明らかな例です。あまり表にでないものとしては、新製品リリースへの強制アップグレードとへの移行であり、ビジネスプロセスの改善は最小限ですが、必ずしも戦略的イニシアチブにマッピングされるとは限りません。
技術的な負債が時間とともに蓄積されると、ソリューションの複雑さが増し、改善されたテクノロジーを活用してビジネスの変化に迅速に適応することができなくなります。それは、業績に重大なマイナスの影響を与える障害となる可能性があります。ほとんどの企業は少なくともいくらかの技術的負債を抱えており、多くの企業はかなりの負債金額を抱えています。

エンタープライズアプリケーションでは、多くの技術的負債が蓄積されている
技術的負債の主な原因は、ソフトウェアベンダーのポリシーとサポートモデルです。これを「ベンダー主導のロードマップ」と呼びます。これらは多くの場合、ライセンシーではなくソフトウェアベンダーに利益をもたらすように設計されています。 SAP社とOracle社のERPを例にとると、それらの主力製品の基礎は30〜40年前のものであり、ソフトウェアは非常に成熟しており、製品を見る限り機能強化と更新でもたらされるイノベーションは多くないと思います。それでも、ソフトウェアベンダーは、顧客が年間保守コストと更新に、非常に少ないROIで潜在的に数千万、数億円を費やすことを期待しています。「技術的な負債を制限または排除する」とのベンダーからのアドバイスは、実際は、「ベンダーのロードマップ税を支払う必要があり、最新かつ最高のリリースをすべて実装する必要がある」との状況となるのではないでしょうか。ただし、これによって技術的な負債を返済するのは、非常に高価な方法です。ローンをローンで返済するようなものです。そのことで、企業が成長と競争優位性を促進できないプロジェクトに限られた予算、リソース、時間を費やすことにより、イノベーション、成長、競争優位性に大きな障害を実際にもたらす可能性があると考えます。この種の技術的負債は、資金を革新のために再利用できるように大幅に削減できる潜在的な節約領域です。

技術的負債の大部分は、水面下で発生します
これは、70社以上のリミニストリートクライアントを調査した結果から算出しています。例として、年間保守料金が2億円のERPを使用すると、大まかなアップグレードは年間メンテナンス料金の2倍、つまり4億円がかかり、5年ごとに実行されます。つまり、年間8千万円の年間コストです。これに、ベンダーでは行わないカスタムコードを維持するコストを追加します。残念ながら、ここには、カスタムコードが破損した場合のコストは含みません。この例では、カスタムコードの修正に年間6千万円かかります。最後に、ベンダーから修正プログラムが提供されるたびに、別のソフトウェアリリース、サポートパック、または拡張パックにその修正プログラムがバンドルされ、不要な回帰テストでさらに6千万円が発生します。したがって、実際の費用は年間2億円+ 8千万円+ 6千万円+ 6千万円で、合計4億円となります。これらの水面下に隠れたコストをすべて取り除けば、何億円もの予算と人的なリソースイノベーションのために解放することができます。

ビジネスの目標と目的に貢献するアプリケーションの更新は、エンタープライズアプリケーションのロードマップに含める必要があります。ただし、ベンダーが指示したアップグレード、拡張、再実装、または統合に費やされたコスト、時間、およびリソースは、実際に機会費用を通じて技術的負債を増加させる可能性があり、注意が必要です。 技術の変化を緩和するために既存の技術的債務を克服する
変更の影響を軽減し、運用からイノベーションへの投資の不均衡をシフトする、潜在的にインパクトある方法は、現在のエンタープライズアプリケーションに付随する技術的負債の額を減らすことです。上記の例を使用すると、アプリケーションの「水面下」のコストを削除することで、技術的負債のかなりの部分を排除できます。さらに節約するために、信頼性、使いやすさ、パフォーマンス効率、保守性、移植性、セキュリティ、互換性などの他のアプリケーション領域に注目してください。 例としてパフォーマンス効率を上げると、6台のサーバーで2,000人の同時ユーザーをサポートする当初の計画が、プロジェクトの完了時には20台のサーバーが必要な場合に、技術的な負債が発生します。保守性の分野の例として、多数のカスタマイズがあります。それぞれのカスタマイズは、コアシステムに変更が適用されるたびに分析および再テストする必要があります。 これらの各アプリケーション領域を調べることで、技術的負債がどの程度あり、継続的なコストの程度、および負債を完全に削減または排除できる可能性がある場所を判断できます。

技術的負債を克服し、アジャイルビジネスを可能にするもう1つの方法は、統一されたサポートモデルを採用することです。このようなモデルは、継続的な運用とサポートを統合して、統合された最高のアプリケーションのサービスを最適化するのに役立ちます。統合されたサービスモデルは、ERPアプリケーション管理の結果も改善します。また、パブリッククラウドおよび顧客やユーザーと連携するシステムを介して、エンタープライズソフトウェアの寿命と価値を延長できる近代化の取り組みをサポートします。

※1 DXレポート ~ITシステム「2025年の崖」の克服とDXの本格的な展開~(本文)14ページ ※2英語原文https://dl.acm.org/doi/10.1145/157709.157715, Oopsla92 P.30: 和訳はウィキペディアを一部参照

リミニストリートオンラインセミナー登録受付中

競争優位性と成長を支えるための第3者保守サービスの活用方法 ~エンタープライズソフトの保守費用を最大90%削減~

開催日時:2020年5月21日(木)14:30 – 15:00(30分)

登録はこちらから

https://info.riministreet.com/JP-Webinar-ERP_Support_Cost_Save_for_BDR_Registration-0521.html

トピック: