技術的負債と内製化とDXと

1995年7月、Amazon.comは、オンライン書店としてのサービスを開始しました。その後、Amazon.comは、様々な商品をオンラインで販売するだけではなく、書籍コンテンツを配信するKindle、音楽や映画の配信、さらには独自の番組作りも行い、メディア×エンターテイメント企業としても存在感を示しています。

また、高級食料品店大手Whole Foodsを買収し、Amazon Goでリアル店舗での小売事業も自ら手がけています。さらには、Amazon CashやAmazon Lendingなどの金融事業にも乗り出しています。

また、配送事業も自ら手がけており、Amazon Logisticsは、2020年に42億個の小包を発送しており、米国における小包配送量の21％を占め、これはUSPS（38％）やUPS（24％）には劣るものの、FedEx（16％）を抜き去る規模にまで成長しています。

AWS（Amazon Web Services）は、クラウド事業のさきがけであり、Microsoft Azure（19%）、Google Cloud（7%）を凌ぐトップシェアを誇っています。

このようなAmazonの成長は、創業者であるJeff Bezosの卓越した見識と行動力に寄るところが、大きいわけですが、その根底にあるのは、「テクノロジー・カンパニー」であることを貫いてきたことにあります。

彼は、1986年に、プリンストン大学を卒業し、電気工学と計算機科学で学位を取得しています。そんな知識と感性を活かし、様々なビジネスを、ITを前提に再定義し、圧倒的な競争力を生みだしています。つまり、これまでの当たり前に拘らず、テクノロジーの進歩を前提に「車輪の再発明」をしているのです。それが、いまのAmazonが、既存の産業秩序を破壊し、成長し続ける力を生みだしているわけです。

AppleやGoogle、AlibabaやTencent など、時価総額でグルーバルの上位を占める企業は、Amazon同様に、テクノロジーを武器に、新しいビジネスの競争原理を生みだし、自らが作り上げた競争原理の中で、他社を圧倒しています。

遅ればせながら、日本企業もこの現実に気付き、自分たちもまた「テクノロジー・カンパニー」としてIT×ビジネスで、競争力を生みだそうと動き始めています。ユーザー企業の内製化が、これまでにない勢いを持ち始めているのは、こんな事情が背景にあるのだと思います。

では、なぜ内製化が、「テクノロジー・カンパニー」になるために必要なのでしょうか。

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

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

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

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

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

先に紹介した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の常識が前提にあってこそ、成り立つのです。

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

このような内製化支援によって、お客様の内製力を高め、圧倒的なビジネス・スピードをもたらすことが、「共創」です。そんな「共創」によって、IT×ビジネス、つまり「テクノロジー・カンパニー」としての企業の文化を根付かせることが、「お客様のDXの実践を支援する」ことなのです。

ITベンダーが、「お客様のDXパートナーになる」や「DXの実践を支援する」という看板を掲げるのなら、このような圧倒的な技術力を提供できなくてはなりません。

言葉だけでDXという魔法の杖を振り回したところで、ビジネスが変革するわけではありません。RPAやAIを使っても企業の文化は変えられません。

そもそも、DXなどという言葉を使う必要もありません。お客様が、「テクノロジー・カンパニー」としてIT×ビジネスで、競争力を高めるためには、自分たちには何ができるかを真摯に突き詰めてゆくべきです。それが上手くいけば、結果として、DXの実践事例になるのです。

「SIビジネスを再発明する」くらいの覚悟が必要です。過去の常識に囚われていては、お客様に、やがては愛想を尽かされてしまいます。自らもまた、時代の最先端を駆使して「共創」できる「テクノロジー・カンパニー」として、事業の再構築をすべきではないでしょうか。

ITビジネス・プレゼンテーション・ライブラリー