システムやソフトウェアの開発・機能追加が積み重なることで発生する「技術的負債」。システムの複雑さによって引き起こされるこの技術的負債は、企業のDX推進を妨げる大きな要因の1つになっています。とはいえ技術的負債は、どうしても生じてしまうもの。自社の負債状況を把握し、返済の対策をしっかりと講じることが重要です。

そこで今回は、「DX推進を妨げる技術的負債は、組織構造の見直しによって解消できるか？」というテーマで、技術的負債の根本原因を考察。「技術・開発体制の見直し」に加えて「組織全体の変革」という観点からも、解消のヒントを考えます。

組織のDX化を妨げる「技術的負債」は、最大12兆円の経済損失をもたらす？

近年、企業のDX推進の機運が高まる中、技術的負債の問題に注目が集まっています。技術的負債とは、システムの開発時、またはその後の改修において「効率」だけを重視した結果、システムが複雑になり、運用・保守にかかるコストや開発工数が肥大化してしまった状況のことです。

つまり、システムのメンテナンスに負荷が増していくことを「技術的な借金」に例えたものが「技術的負債」。機能を追加すればするほど利息が高く積み上がるのと同じように、システム改修の負担が増えていく、というわけです。

技術的負債が生まれる原因として、ビジネスの現場で求められるマーケティングスタイルなどが次々に変化した結果、それに対応するべく技術が場当たり的に組み合わされ、システムが構築されてきたという背景があります。つまり構築当初はシンプルでも、時間の経過とともにシステムがどんどん複雑化してしまうことが往々にしてあるのです。

経済産業省による2018年の「DXレポート」でも、既に技術的負債の問題について言及されています。このレポートによるとシステム刷新などを行い、レガシーシステム（技術的負債の対象となるシステム）による負債をなくしていかなければ、2025年以降、最大12兆円／年の経済損失が生じると予想されており、この問題は「2025年の崖」と呼ばれ、国を挙げての支援が進められています。

上記のレポートによれば、約8割の企業がレガシーシステムによる技術的負債を抱えており、約7割の企業が、「レガシーシステムがDX推進の足かせだと感じている」ことも分かっています。では企業によっては、年間何兆円ものマイナス成長をもたらすとされる技術的負債について、どのように解決を図ればよいのでしょうか。

時間の経過とともに増殖する技術的負債。効果的な返済方法とは？

技術的負債の解消方法を探る前に、まずは、技術的負債が起こる代表的な要因を見ていきましょう。多くの場合はさまざまな原因が絡み合って負債が膨らんでいくものですが、大きく分けて以下3つの原因が考えられるでしょう。

原因1：開発工程での「検討不足」によるもの

システムやソフトウェアの開発時、必要な要件定義や開発期間、テストが不十分だったために、のちのち負債をこじらせてしまうケース。

原因2：システム開発特有の「不可視性」によるもの

ソフトウェアの言語はもちろん、システムの状況もエンジニア以外が把握するのは難しい専門性の高いものです。そのため、営業や企画など他部門のメンバーは負債の実態を把握しにくく、自部門のニーズだけを一方的に伝えてしまいがち。そうしたニーズにエンジニアがひたすら応えているうちにシステムのズレが積み重なり、気が付いたら手遅れという事態になっていることも多いようです。

原因3：システム開発特有の「可変性」によるもの

前章でもお伝えしたように、企業がビジネスの現場で使うソフトウェアは、自社の業務や組織構造、商習慣、CX設計などさまざまな条件に対応するため、「作って終わり」ではなく、完成後も変化し続ける必要があります。IT技術やビジネス環境の変化に追いつくため、機能をたびたび追加していくと、時間が経つにつれていびつな拡張が目立つようになり、負債が膨らむケースもあります。

「負債」というとどうしてもネガティブなイメージがつきまといますが、これらの原因を見ても分かるように、技術的負債は絶対的な悪ではありません。開発や実装当時は、それが最適解だったことがほとんどではないでしょうか。しかし時間が経つにつれ、どんどんシステムとして適さなくなっていくことが多いのです。

これらの諸問題を解決するためには、複数のシステムをリアルタイムに連携する「API（Application Programming Interface）」や「クラウド活用」のような技術的対処、開発担当者と運用担当者が連携し、フレキシブルかつスピーディーに開発を行う「DevOps（デブオプス：Development and Operationsの略語）」のような体制的対処が考えられます。

例えば、D2C事業を展開するある企業では、開発当初は多くの機能を集合させた巨大な単一アプリケーションとしてシステムを構築していました。ところが、プラットフォーム内で機能同士が絡まり合うようになり、次第に技術的負債が増加。それに伴って開発スピードが落ちていき、事業多角化の足を引っ張るようになってしまいました。

そこで、一枚岩のような構成のシステムを機能ごとに細分化して独立させることに。その結果、各機能を担当する開発チームは開発効率を追求できるようになったのです。

技術的負債を返済するために、どのような対処法を選択するかは各企業に委ねられています。場合によっては技術や体制の見直しのみならず、組織構造の見直しも必要となるかもしれません。

技術的負債を引き起こす「3つの壁」こそが、DX推進を妨げる真の課題

ではここからは、組織変革の側面から技術的負債の返済の道筋について考えていきます。技術的負債をいかに返済するか対策を練る中で、企業によっては「組織的負債」が浮き彫りになるかもしれません。そうしたケースにおいては「技術的負債」と「組織的負債」を分けて考えると、現在自社が直面している真の課題が見えてくるでしょう。

前章では、システム開発に特有の「不可視性」によって、技術的負債が起こり得るとお伝えしました。開発部門と営業や企画などを行うそれ以外の部門とでは、システムやソフトウェアに対して見えている世界も使う言語も異なります。そのためにコミュニケーションの齟齬や分断が起こりやすくなり、次第にそれが組織内の大きな壁となって立ちふさがることも。こうした組織風土そのものは「組織的負債」と呼ばれ、技術的負債と同様に、企業のDX化を阻害する要因だと考えられています。

この組織的負債を引き起こす主な原因を「3つの壁」に分解して見ていきましょう。

・1つ目の壁「偏見の壁」

組織内に蓄積する技術的負債を「いけないもの」と捉えてしまうと、負債の中身を直視するのを避けるようになります。これを本記事では「偏見の壁」と呼ぶことにします。

・2つ目の壁「不明の壁」

システムが複雑になると、技術的負債の実態がつかめずブラックボックス化してしまいます。この何が起こっているか分からない状態を、ここでは「不明の壁」とします。

・3つ目の壁「断絶の壁」

組織内で、開発部門と他部門のメンバーがコミュニケーション不全に陥ることがしばしば起こります。これは「断絶の壁」と表しましょう。この壁が立ちはだかると、開発部門・他部門の双方とも、連絡窓口である担当者を決めることすらせず、意思疎通のラインが途絶えてしまう場合もあります。

これら3つの壁を解消するにはどうすれば良いのでしょうか。壁の解消に取り組んだ結果、技術的負債を返済した企業の例を見ていきましょう。

ECサイトを運営するこの企業では、スピードを重視して通常よりもはるかに短い期間で突貫開発を行いました。そのため読みにくいソースコードでのコーディングなど技術的負債が山積みに。サイト改修や新機能追加に大幅なリソースが割かれてしまう状況に陥っていました。

1. 「偏見の壁」の解消

負債の実態をつかむため、「偏見の壁」を取り除くとともに綿密なリサーチを実施。その結果、「ゼロから作り直す」と「小さな改善を積み重ねる」という2つの解消法のうち、よりリスクの少ない後者を選択することに。

2. 「不明の壁」の解消

ブラックボックスと化した技術的負債を丹念に洗い出しながら、OSやミドルウェアなどレガシーシステムの構成を見直し。「不明の壁」を取り除いた結果、誰が見ても把握できる仕組みへとアップデート。

3. 「断絶の壁」の解消

技術的負債のネガティブな側面など、抱えている問題を経営層と共有。説得を続け、「断絶の壁」解消の努力を重ねた結果、負債返済のためにヒト・モノ・カネといったリソースを投入する約束を取り付けることができました。

組織的負債を解消するために最もポイントとなるのは、3つ目の「断絶の壁」の解消にあたる組織構造の変革でしょう。一見、高く見える壁ですが、部門を超えた社内コミュニケーションと相互理解を促す組織づくりに取り組むことで、技術的負債を返済するだけでなく、負債を放置しない組織文化の醸成にもつながります。そして、それがさらなる変革の追い風となり、「DXの向上」「ユーザーエクスペリエンスの向上」「事業の成長」の全てがうまく回るサイクルへと乗せられるかもしれません。

2025年には最大で12兆円／年もの経済損失につながると言われている、技術的負債。これまで見てきたように、技術的負債は正しく向き合うことで解消できます。根本的な解決を目指すなら、「偏見の壁」「不明の壁」「断絶の壁」の解消に取り組むことが肝心。そしてせっかく取り組むのなら、「マイナスの負債をゼロに」という消極的な発想ではなく、「マイナスの負債をゼロに、さらには大きなプラスへと転換する」という攻めの発想を持ち、組織の成長やDXの加速など、多角的・重層的な効果を狙ってみてはいかがでしょうか。