技術的負債とSIビジネス

「技術的負債」という言葉があります。ソフトウェア開発における概念で、システム開発においても技術的な借金があり、借金をすると利子を払い続けなければならないのと同じように、システムを構築すると利子としてシステムを改修し続けなければならず、それが負債のように積み上がることの比喩として、使われています。

最初は丁寧に、整然と設計され、その通り実装されたシステムでも、ビジネス環境やユーザーのニーズが変われば、それに対応して改修しなければなりません。それは、事業を維持するためには必要なことです。しかし、改修が積み上がる過程で、システムは複雑性を高め、カオスに向かってゆきます。その結果、改修は難しさを増し、改修のスピードは落ちてゆきます。そのうちにニーズの積み上がるスピードに、改修が追いつかなくなってしまいます。つまり、借金をして利子が積み上がり、利子さえも返せなくなって債務超過に陥ってしまうというわけです。

その理由のひとつが、ソフトウエアの「不可視性」です。つまり、ソフトウェアは、エンジニアには読めても、ビジネス・パーソンには読めないということです。ですから、事業に責任を持つビジネス・パーソンが、自分たちのニーズをエンジニアに伝え、かれらは、それを理解してソフトウェアに仕上げなくてはなりません。そのためのコミュニケーションに相当の手間と時間かがかかるからです。

そもそもビジネス・ニーズを完全に伝えることはできません。また、それを文章として仕様書にする過程で、情報は欠落し、できあがったシステムは、ビジネス・ニーズを完全には満たすことはできません。そこで、できあがった現物を見てフィードバックし、また、作り直すことを繰り返します。リリース前の段階で、もはや「技術的負債」を膨らましているわけです。

不確実性が高まり、正解が分からない時代になって、事業を継続し、成長させるには、圧倒的なビジネス・スピードで、変化への対応が求められます。ソフトウェアもまた、このスピードに対応できなければ、あっという間に「技術的負債」が膨れあがってしまいます。

例えば、Amazonでは、このような「技術的負債」を回避するために、1時間に1000回以上も様々なシステム改善を行っているそうです。Amazonと同じとはいきませんが、そんなスピード感覚が、いまのIT×ビジネスに求められています。

ところが、日本企業では、月に一回でも改善できればいい方で、半年に1回、1年がかりというのも珍しくありません。それは、関連部署との調整や稟議決済、IT部門への説明やITベンダーへの発注と購買手続き、開発チームと運用チームとの連携などのコミュニケーションに膨大に時間や手間をかけているからです。

いまの時代にあっては、このようなやり方では、「技術的負債」がどんどんと積み上がります。ビジネスに必要なスピードを獲得することなど、できるわけがありません。

中長期にわたって未来を予測できない以上、目前の変化に即座に対応できる圧倒的なスピードが、事業を継続させ、成長させるための必須の条件です。だから、事業部門の配下にITを使いこなせるチームを配置し、ビジネス・チームとITチームのコミュニケーションの負荷を減らし、両者を同期させて、システムを作っていくことが必要とるわけです。また、現場に権限を委譲し、現場の判断で対処できる自律したチームで運営することもスピードを速められます。だから、内製化なのです。

また、「技術的負債」を発生させないためには、次のようなことに取り組まなくてはなりません。

• ビジネスの成果に貢献するコードに絞り込み、できるだけ作らないことを目指す。
• システムは、業務のプロセスの最小単位に分解して、その単位でテストし、実装する。
• それぞれは、少ないコードなので、バグは排除され高品質になり、しかも独立した業務プロセス単位にメンテナンスができますから、変更への即応力も担保される。
• 可読性の高いコードを目指すことで、マニュアルなどのドキュメントがなくても機能が理解できるので、システムの属人化を排除できる。

XP（eXtream Programing）やスクラムなどによるアジャイル開発、マイクロ・サービス・アーキテクチャは、これらのための有効な方法論です。

また、インフラやプラットフォームもまた、このスピードに同期させなくてはなりません。だから、サーバーレスやコンテナを前提に、ソフトウェアの本番環境へのデプロイを、安定稼働を保証しながら、高頻度で行えるようにしなくてはなりません。クラウドの活用やDevOpsは、そのために必要となるのです。

この趣旨に照らし合わせれば、システム内製は、アジャイル開発やDevOps、コンテナやサーバーレスなどを使うためのクラウド、さらにはPaaSやSaaS、ローコード開発ツールなどの「作らないための技術」を駆使して、できるだけ少ないコードでビジネス目的を達成することを追求することになります。

そうやって、システムは、「技術的負債」を膨らませることなく、変化に即応できる圧倒的なスピードを手に入れることができるのです。

このようなことをITベンダーに期待できるならいいのですが、それができないから、ユーザー企業は、自分たちでやるしかありません。そこで、上記のようなモダンITスキルを持つ人材を自分たちで採用し、内製しなくてはならないのです。

経産省が、2019年に発表した「DXレポート」の中で、「老朽化や複雑化、ブラックボックス化している既存の基幹システム（レガシーシステム）」に多くのコストや人的リソースが費やされることで、新しいデジタル技術などにIT予算などの資源を投資できなくなり、企業のグローバル競争力を低下させていると指摘しています。つまり、レガシーシステムが、膨大な「技術的負債」を抱えていて、身動きがとれない状態だから、これをまずは何とかしよう。だから、DXを実践するには、まずはレガシーシステムを改修せよというわけです。

しかし、私は、これは、必ずしも良いやり方ではないと思います。

これほどテクノロジーの変遷が激しいのに、過去のレガシーITの常識を土台に作り上げた膨大なシステム資産を改修しても、「技術的負債」をさらに増やすだけです。ならば、いまのテクノロジーや方法論を使って、システムを再設計、再作成すべきです。

アジャイル開発であれば、本当に必要なプログラムのみを作成するので、かつてのような大規模開発の必要は、全くありません。開発のスピードを上げて回転数を高めれば、従来の常識の何分の1、あるいは何十分の１のコストと期間でシステムが作れますし、高品質で可読性が高く、構造もシンプルですから保守性も高く、「技術的負債」を抑えこみながら、高速に改善することもできます。

圧倒的なビジネス・スピードが必至のシステムに取り組む内製は、このようなモダンITの常識が前提にあってこそ、成り立つのです。

そんなお客様の内製を圧倒的な技術力で支えることが、「内製化支援」です。これは、組織力を駆使して工数を集めれば、何とかなる類ではありません。圧倒的な技術力を持った人材を、お客様の内製チームに送り込み、チームの一員として、一緒に仕事をし、技術面でお客様の模範であり教師となって、内製に必要とされるスキルをトランスファーするビジネスです。

このような内製化支援によって、お客様の内製力を高め、圧倒的なビジネス・スピードをもたらすことが、「共創」です。そんな「共創」によって、「お客様のDXの実践を支援する」ことこそが、いま必要とされています。

ITベンダーが、「お客様のDXパートナーになる」や「DXの実践を支援する」という看板を掲げるのなら、このような圧倒的な技術力を提供できなくてはなりません。「DX」という魔法の呪文を唱えたところで、ビジネスが変革するわけではありません。

ITベンダーは、「SIビジネスを再発明する」くらいの覚悟が必要です。過去の常識に囚われていては、お客様に、やがては愛想を尽かされてしまいます。自らもまた、時代の常識を駆使して、お客様の「共創パートナー」になれるだけの圧倒的技術力を磨くことです。そんな自分たちのDXを棚上げして、お客様のDXをとやかく言うのは、いかがなものかと思います。

11月11日(土) 10:00〜「ワーケーションを体験しよう」

8MATOで、ワーケーションを楽しむための実践ノウハウをご紹介するイベントを開催します。11月11日（土）10:00からとなります。8MATOでも、オンラインでもご参加頂けますので、是非、ご登録下さい。

ワークもライフも諦めない。どちらも最高でありたい。そのための手段のひとつが、ワーケーションです。もちろん、それ以外の手段も沢山ありますが、森や山の自然が好きなら、森でのワーケーションは１つの選択肢になるはずです。

神社の杜のワーキング・プレイス 8MATO

目次

• 第1章　コロナ禍が加速した社会の変化とITトレンド
• 第2章　最新のITトレンドを理解するためのデジタルとITの基本
• 第3章　ビジネスに変革を迫るデジタル・トランスフォーメーション
• 第4章　DXを支えるITインフラストラクチャー
• 第5章　コンピューターの使い方の新しい常識となったクラウド・コンピューティング
• 第6章　デジタル前提の社会に適応するためのサイバー・セキュリティ
• 第7章　あらゆるものごとやできごとをデータでつなぐIoTと5G
• 第8章　複雑化する社会を理解し適応するためのAIとデータ・サイエンス
• 第9章　圧倒的なスピードが求められる開発と運用
• 第10章　いま注目しておきたいテクノロジー