技術的負債の解消
企業が技術的負債に投じる費用は今後10年間で5兆ドルに達する見込みです。機会の損失はそれ以上に大きいかもしれません。技術的負債を解消し、その先のビジネスへ
詳細を見る
このWebサイトは日本語に翻訳されています。翻訳がないコンテンツは英語で提供されます。
技術的負債とは
「技術的負債」とは、主に企業が品質よりスピードを選んだ代償として後から負担しなければならなくなる時間的、金銭的、リソース的な負債のことです。
今日の「新しい生活様式」に対応するため、企業はテクノロジーやサービスを改良し、新たなデジタルインインタラクションチャネルを顧客に提供しようとしています。一方で、多くの科学技術者が技術的負債の影響とビジネス継続性を論じています。
実のところ、アプリケーションをスピード重視で作成すると、最終的に大量のリソース、時間、エネルギーを投入して「破綻したコード」の保守や書き直しを行わなければならなくなり、新しいアイデアの開発に手が回らなくなるという事実があるのです。
技術的負債とは
技術的負債とはソリューションの手直しにかかるコストを指す言葉です。容易ではあるものの制約のあるソリューションを選択することで発生します。
複雑な技術的負債がもたらす最も深刻な影響としては、企業の競争力や革新力の低下が挙げられます。また、リソース、時間、エネルギー、革新力、適応力、成長力も奪われます。
技術的負債は、把握や管理が難しく、回避することはさらに難しいのです。
技術的負債の原因
ソリューションの開発においては、誰もが多くのことを予測し、プロジェクトの計画やコードの仕上げに時間をかけるものです。しかし、どうしても管理できない要素はあります。技術的負債は、そこから生まれてきます。
- 時間的制約: 厳しいスケジュールに間に合わせるため、開発チームは機能が不完全であったり重要な機能が欠けたりしていても、アプリケーションをそのままリリースしてしまうことがあります。市場へのリリースを急ぐあまり、性能や品質といった面で妥協してしまうケースもあります。
- 絶えず変化する環境: 昨今のビジネス環境では、フル機能のアプリケーションを期限内に完成させたとしても、市場にリリースした時点ですでに時代遅れになってしまうことすらあります。高まり続ける顧客の期待、新たな市場機会やサイバー脅威の出現、開発者の入れ替わりなど、ITリーダーは常に課題を抱えています。
- 時代遅れのテクノロジー: 先進的なアプリケーション開発で一般に利用されているコーディング言語や開発フレームワーク、ライブラリの中には、時代遅れになるものや、サポート終了となるものが毎年のようにあります。今日のPythonも、明日にはVisual Basicと同じ道をたどるかもしれません。
ローコードのパフォーマンスをご体感ください。
無償トライアル一般的に「技術的負債」という言葉は古いレガシー製品を指すことが多いですが、実は技術的負債は製品リリースの時点で発生するものです。新しいプロジェクトの計画段階において、特定の要件を所定の期間内に満たせないと気づいたことはありませんか？
もちろん、後から変更することはできます。ただ、この時点では後で時間が取れるものと考えて対処しなかったとします。
残念ながら、新しいプロジェクトは次から次へと発生し、そのたびに締め切りに追われることになるものです。いったん要件を先送りにするといつまでも完了せず、技術的負債になってしまうことがよくあります。
技術的負債の例
ここ2年間の出来事から、技術的負債の事例を見ていきましょう。大手小売業者の多くはすでにオンライン店舗を展開していましたが、開発の際、多数の同時ユーザーに対応するための拡張性は優先されていませんでした。拡張性を考慮して開発を行うと時間が余計にかかるからです。そのため、要件を先送りにしました。当時はオンラインストアに多数の同時ユーザーが一度にアクセスするなど誰も想定していなかったため、それでよしとなりました。しかしその後、パンデミックが発生しました。
多くの小売業者のWebサイトは拡張性の要件を満たしておらず、仮想キューなどの応急的な対応を行わざるを得なくなりました。顧客の多くはそれを待ちきれず、優れた拡張性やパフォーマンスを備えた他のオンラインストアへと流れてしまいました。最初から時間をかけて最適な開発を行ってきた企業（Amazon、eBay、AliExpressなど）は、他の多くの企業が2020年を問題の解消につぎ込んでいる間に、努力の成果を味わうことができたのです。
技術的負債の様々なタイプ
スピードを追求するために技術的負債を発生させることは、どのような場合でもよくないのでしょうか。この疑問の答えを出すには、Martin Fowler氏の「技術的負債クアドラント」が参考になります。このクアドラントは、目的やコンテキストに基づいて技術的負債のタイプを分類したものです。
このクアドラントを念頭に置くと、技術的負債は以下のように分類されます。
- 慎重で意図的。技術的負債が膨らむことを把握しながらもリリースを優先し、後で影響に対処することをチームが選んだ場合です。リスクが十分抑えられている場合や、早くリリースすることで技術的負債のコストを上回るメリットが得られる場合は、許容できる判断です。
- 無謀で意図的。この先どうなるかも、それを避ける方法も知ってはいるものの、チームが品質よりスピードを優先する場合です。
- 慎重で不注意。チームがソリューションをどのように実装すべきだったかを実装後に学習した場合です。
- 無謀で不注意。チームに経験がなく、ソリューションを無分別に実装した場合です。チームは自ら窮地に陥ったことにさえ気づいていません。
このクアドラントの左側に入ることは、極力避けるべきです。
スピードと品質の適切なバランスの見極め
ソフトウェアの品質とパフォーマンスは優れたユーザーエクスペリエンスを実現するうえで最も重要なものです。しかし、ビジネス目標を予定どおりに達成するためにはスピードも不可欠です。技術的負債を管理するには、品質とスピードのバランスをとる必要があります。迅速な回避策をとれば期限に間に合わせることができるかもしれませんが、その代償はしっかり把握しておく必要があります。技術的負債は一見無害に見えるかもしれませんが、確認しないままでいると、どこかの時点で組織からスピードやアジリティを奪い去ります。
経験の浅い開発者は、負債が天高く積み上がるまではその存在に気づかないふりをしていたいと思うこともあります。負債の把握や修正が難しくて手が出ないという場合もあるでしょう。組織がリリースサイクルの短縮に重点を置き、本職でない開発者（シチズンデベロッパー）による業務アプリケーションの作成を奨励するようになってきていることもあり、技術的負債のリスクは高まっています。
どのようなケースであれ、技術的負債を減らし、管理することは可能です。
技術的負債の管理・削減方法
技術的負債への対応にあたって欠かせないのが、時間、品質、コストのバランスの確保です。同時に、ガバナンスモデル、ツールセット、そしてソフトウェアを作成する人の考え方にも留意しなければなりません。うまくバランスをとることが重要なのです。必須というわけではありませんが、適切なテクノロジーも役立ちます。
ローコード開発プラットフォーム などの最新テクノロジーに移行することで、技術的負債という場当たり的な対応から脱却し、差別化された独自のソリューションをデリバリーする企業が増えています。
OutSystemsも、こうしたテクノロジーのひとつです。
ＯutSystemsで作成したアプリケーションは標準のアーキテクチャやフレームワークに基づいているため、特定のコンポーネント、ランタイムエンジン、インタープリタは必要ありません。そのため、開発に入る前から技術的負債の発生を抑えることができるのです。
OutSystemsは、自動化、AI、分析を併用してデプロイプロセス全体を調整し、アーキテクチャのエラー、ロジックの欠陥、壊れた依存関係を開発中にリアルタイムで特定します。
技術的負債の削減を実現するために、OutSystemsは以下のような機能を備えています。
技術的負債の発生を最初から減らす方法の詳細については、「OutSystemsによる技術的負債への対応」をご覧ください。このホワイトペーパーでは、OutSystemsを活用して開発中に発生する技術的負債を減らし、さらにベストプラクティスに基づくアーキテクチャを構築して将来的な技術的負債に効率的に対処する方法を紹介しています。
