技術的負債: 組織はどう対峙すべきか

こんにちは、ALIS CTOの石井(@sot528)です。

ALISのエンタープライズ向け事業として、日々クライアント企業様のDX(デジタルトランスフォーメーション)をお手伝いする中で得られた知見を、今後ALIS DXブログとして、こちらでアウトプットしてゆきます。

今回は技術的負債についてです。

非エンジニアの方にはなかなかわかりにくいこの概念。DXへ取り組む方へ、なぜDXにおいて技術的負債の理解が重要となるかをご説明してゆきます。

目次:

・目的
・前提
・結論
・技術的負債とは何か？
・組織における技術的負債
・まとめ

目的

本記事の目的は以下の通りです。

・「技術的負債とは何か」をわかりやすく説明

・組織が技術的負債にどのように向き合うべきかを提示

本記事の目的ではないこと

・具体的なHowの提示。

長くなるので、これはまた別記事を書きます。

前提

本記事は経産省のITシステム「2025年の崖」 で示されるような、典型的なレガシーシステムを抱えた企業像を想定して記載します。業種や企業のポジションにより状況は異なりますが、普遍的な内容なので多くの企業に当てはめるられるかと思います。

結論

まず先に結論を提示します。本記事の結論は次の通りです。

技術的負債は組織課題であり、組織は生存を賭して技術的負債に対峙すべきである。

少々挑戦的な文言ですが、なぜこの結論が妥当と言えるのかを本記事を通してご説明してゆきます。

技術的負債とは何か？

DXの文脈で目にする機会も多い「技術的負債」とは、そもそも何でしょうか。経済産業省のDX 推進ガイドラインから引用いたします。

IT システムの中には、短期的な観点で IT システムを開発し、結果として、長期的に運用費や保守費が高騰している 状態のものも多い。これは、本来不必要だった運用・保守費を支払い続けることを意味し、一種の負債ととらえることができる。こうした負債は「技術的負債」(Technical Debt)と呼ばれている

ここでは、技術的負債が溜まると、本来なら不要なコストがかかり続ける、つまり「技術的負債が溜まると余計なお金がかかる」と説明されています。

これだけだと「何がどうなって、どうお金がかかるのか？」がよくわからないかと思いますので、本記事ではもう少し掘り下げます。またコスト面だけでなく、技術的負債の様々な悪影響についても書きます。

技術的負債の具体例

本記事の主題は「組織は技術的負債にどのように向き合うべきか」です。しかしまずは具体例を示すために、組織内の1システムにおける技術的負債がいかなるものかをご説明します。技術的負債とは、具体的には以下のようなものを表します。

技術的負債の例:
不適切なアーキテクチャ設計、不適切なDB設計、属人性の高い実装・構成、機能要件と実装の乖離、書かれないテストコード、存在しないコーディング規約、時代遅れの設計思想・ミドルウェア、微妙なベンダーロックイン、etc.. etc..

いろいろ書きましたが、これらはごく一部です。こうした技術的負債が溜まったものを、いわゆるレガシーシステムと呼びます。

このようなレガシーシステムと、そのシステムを改修・開発・保守してゆくプロジェクトには、可視化したり定量化することが難しい色々な問題が発生することとなります。

技術的負債が招く負のスパイラル

端的に言えば、そういったプロジェクトは負のスパイラルとでも言うべき状態に陥ります。(図がイマイチなのはご容赦ください。5〜6年前に作成した資料からの抜粋です)

上の図の要素をひとつひとつ見てゆきましょう。

開発スピードの低下

技術的負債が溜まると開発スピードが低下します。レガシーシステムでは迅速な開発は困難です。

システムの品質低下

技術的負債が溜まるとシステムの品質が低下します。レガシーゆえに品質を担保するのが困難であり、かつ品質を高めても評価されないからです。システムの品質はシステムに詳しくない人には判断できません。技術に精通した優秀なリーダーがいれば話は別ですが、そうでなければシステムの品質が評価されることは稀です。(そして後述しますが、レガシーシステム関連のプロジェクトにはそういったリーダーを含め、優秀な人材は集まりにくいです)

その結果、システムの品質は下がり続け、セキュリティを含む問題も蓄積します。何か新しいことをやりたいと思っても、システムが足を引っ張ってそれができないか、あるいは長い期間と高いコストがかかります。システムが組織のお荷物になっている状態です。

そのようなシステムが動き続けていて、事故が起こっていないとしたら、それは「単に運が良いから」です。早晩、問題を起こすでしょう。

エンジニアのモチベーションが低下する

優秀で向上心のあるエンジニアにとって、レガシーシステムの改修・保守・運用に関わるのは最低の体験です。頑張っても報われない、賽の河原で石を積むような作業です。レガシーシステムにはデスマーチが付きものです。学びが少ない、高稼働、みんな目が死んでる。残念ながら、そのようなプロジェクトは世の中にあふれています。(ちなみに、本記事の記載は全て私の実体験に基づいています..)

慢性的にリソース不足となる

エンジニアは、良かれ悪しかれ常に売り手市場です。優秀で向上心のあるエンジニアにとって、いつまでもレガシーシステムに関わる理由はありません。組織やプロジェクトに技術的負債への哲学や知識が無く、それを解消しようという動きが無いなら、さっさと転職や移動をして別プロジェクトに関わるのが最適解となります。

逆にレガシーシステムに違和感なく適応できるのは、技術的負債に意識を払わないエンジニアです。意識を払わなければ技術的負債は蓄積し続けます。優秀な人材はそのようなシステムを避けるため、採用も困難になります。エンジニアが足りない、あるいは無駄に人数は居るが優秀な人材はいないという、これも非常によくありがちな状態になってしまいます。

プロジェクトの雰囲気が悪くなる

技術的負債が溜まってゆくとプロジェクトの雰囲気が悪くなります。いわゆるスーツとギーク問題も発生します。非エンジニアは技術的負債を理解できないので「なぜこんなに開発が遅く品質が低いのか。うちのエンジニアは能力不足では」と考えてしまいます。これは声に出さなくても、態度でチームへ如実に伝わります。

エンジニアとしては、負債が溜まり苦しい状況で頑張っているのに、組織や上司の無理解により評価が低いことにうんざりします。「あいつら何もわからず勝手なこと言いやがって」という感情を持ちます。お互いがお互いを信用できない残念な構図ですね。

身動きが取れなくなる

それぞれの要素は互いに影響し合って、どんどん悪い方向への力学、負のスパイラルが働きます。そして身動きが取れない状態となります。

こうなると、ここからチームとシステムを立て直すには時間がかかります。そして残念なことに、このようなプロジェクトは極めて一般的に存在します。

組織における技術的負債

ここまでは、組織内の1システムにおける技術的負債について書きました。それでは、そのような技術的負債は組織にはどのような影響を及ぼすでしょうか？

箇条書きにしましたが、これは一般的な企業に存在するごくありふれた諸問題と言えるでしょう。昨今、盛んにDXの必要性が語られるのはこのような背景があるからです。本記事では、上記のような状態を組織にとっての「身動きが取れない状態」と表現します。

それでは、なぜこのような事態に陥ってしまうのでしょうか？

コンウェイの法則

その根本原因はコンウェイの法則と呼ばれるものです。

システムを設計する組織は、組織のコミュニケーション構造をコピーした構造の設計を生み出す - How Do Committees Invent?

この法則はソフトウェア業界でよく言及されており、つまりは「システムにとって不適切な組織構造なら、不適切なシステムしか構築できない」と主張しています。そして情報システムが明らかに企業の命運を分ける昨今において、組織の情報システムが不適切であれば事業の存続すら危機にさらされると言っても過言ではないでしょう。

この法則はただの経験則ではありますが、15年以上システムに携わる私の肌感覚としては、まるで物理法則のように強固な現実と感じます。情報リテラシーが低い組織には残念なシステムしか構築できない。そう断言できます。

そして、組織構造を変えるにはトップの覚悟が不可欠です。トップのコミット無しではDXは極めて高い確率で失敗するでしょう。

《経営トップのコミットメント》

2.DX を推進するに当たっては、ビジネスや仕事の仕方、組織・人事の仕組み、企業文化・ 風土そのものの変革が不可欠となる中、経営トップ自らがこれらの変革に強いコミッ トメントを持って取り組んでいるか(経済産業省: DX 推進ガイドライン)

日本を代表する経営者の一人であるユニクロ柳井会長の言葉をお借りすれば「デジタル革命は経営者の使命」です。部下や一部署へ丸投げすることはできないのです。

「我が社のシステムには課題がありDXが必要」とお考えの経営者の方も多いかと思います。しかし、それが「完全に経営者の責任である」とまで認識できている方はまだ少ないように見受けられます。しかし残念ですが、トップの情報リテラシーが低ければ、そのレベルに見合ったシステムしか持てません。 

組織構造がどのように技術的負債を生み出すか？

それでは、組織構造が不適切なシステムを生み、技術的負債が蓄積してゆく仕組みを見てゆきましょう。

上の図はごく一例です。外部ベンダに丸投げし過度に依存すれば、システムを自社のビジネスへ伴走させてゆく能力を失います。そしてもはやデジタルが大前提となった昨今、それは組織の競争能力の放棄に近しい行為です。技術的負債が考慮されない評価制度であれば、当然の帰結として技術的負債は溜まります。システムに精通していない者が責任者という組織構造もよくありがちですが、その組織構造はそのままシステムに反映されるので、どだいまともなシステムは作れません。システムをベンダー・部署・部門・部下に丸投げで組織的なデジタル戦略不在であれば、それにふさわしい残念なシステムができあがります。今日であっても、いまだに意識的にしろ無意識的にしろ「ITは自社の主戦場ではない」と考えている組織も多く見受けられます。それは現実逃避以外の何物でもありません。

他にも、組織構造の問題は山ほどあります。そして、そのような組織の欠陥の帰結として、多くの技術的負債が生み出されます。データのサイロ化、無駄なコスト、セキュリティ問題、更新されない無駄なドキュメント、機能不全の社内ルール・制度、属人化・ブラックボックス化、etc... etc...。

組織に技術的負債が溜まった状態とは？

組織に技術的負債が溜まると、当たり前ですが数々の問題が発生します。

とにかくシステムの開発・修正スピードが遅い。すぐシステムが落ちてなかなか復旧できない。できたシステムの品質が低い・セキュリティ懸念。自社データなのに連携できない・活用できない。開発、運用、データ利用、すべてに過剰な費用と長い期間がかかる。社外ベンダや特定個人に確認しないと何もわからない。情シスも、情シスを相手にする人達も皆疲れてうんざり。優秀な人が見切りをつけて辞めてゆく。優秀な人を採用できない。組織としての自信の喪失(我々はITに弱い)。また個人情報保護の流出で即死の危機という事態も普通に起こりえます。

結果として、デジタルを強みに業界へ攻め入る「ディスラプタ」に対抗できない事態となります。今後、デジタル化の波はすべてを飲み込んでゆきます。今まで安全だった業界も例外ではありません。だからこそDXが喧伝されているのであり、経産省がITシステム「2025年の崖」 で「もしDXが進まなければ2025年以降、最大で年間12兆円の経済損失が生じる可能性がある」とまで警告しているのです。

まとめ

まとめます。本記事の目的は以下の通りでした。

・「技術的負債とは何か」をわかりやすく説明

・組織は技術的負債にどのように向き合うべきかを提示

そして、組織における技術的負債とはいかなるものかについて記載しました。

技術的負債とは、溜まると身動きできなくなる技術的な問題であり、システムはコンウェイの法則により組織構造を反映する以上、技術的負債は組織の課題である。そして一般的な組織構造においては技術的負債は溜まり続ける。技術的負債が溜まれば、身動きが取れなくなる。身動きが取れなくなると、競合他社への大きなディスアドバンテージとなる。つまり、技術的負債の放置は組織にとって致命的となり得る。したがって、本記事の主張である冒頭の結論となります。

結論

技術的負債は組織課題であり、組織は生存を賭して技術的負債に対峙すべきである。

-----

長い記事をお読みいただきありがとうございました。

本記事ではDX文脈で頻出する割に、とっつきづらい印象のある技術的負債について、これまで散々技術的負債と格闘してきた経験を元に書きました。

技術的負債はその文言から、「単にシステム的な課題なのだな」と捉えられがちです。しかし深掘りすれば、組織の命運を握るほど重要な概念であり、かつ、結局のところ組織構造と不可分の課題です。本記事でその観点をお持ち頂けましたら幸いです。

技術的負債の調査・可視化・定量化、継続的な数字ベースでの監視、改善方法など、「じゃあ技術的負債をどうやって解消してゆけば良いのか？」というHowの部分に関してはまた別記事を書ければと思います。

ALISでは企業のDX推進をお手伝いしております。プライドを持ったプリンシプルに基づき、貴社のデジタル企業化(=DX推進)を全力で支援いたします。お気軽にお問い合わせください。

-----

・ALIS CTO 石井（@sot528）
・本記事はCC-BYライセンスです。帰属を掲示していただければご自由に利用・改変が可能です
・この記事は、運営による記事のためいいねによるトークン配布はありません