「共創」が個人も企業も成長させる

加速するビジネス・スピードと急速に膨らむ「技術的負債」

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

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

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

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

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

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

ところが、日本企業では、月に一回でも改善できればいい方で、半年に1回、1年がかりというのも珍しくありません。それは、関連部署との調整や稟議決済、IT部門への説明やITベンダーへの発注と購買手続き、開発チームと運用チームとの連携などのコミュニケーションに膨大に時間や手間をかけているからです。このような暗黙の前提があるのですから、システムのアーキテクチャーや開発手法は、モノリシックやウォーターフォールにならざるを得ません。

結果として、「技術的負債」がどんどんと積み上がります。IT×ビジネスに必要なスピードを獲得することなど、できるわけがありません。

「技術的負債」をなくすための「内製化」

中長期にわたって未来を予測できない以上、目前の変化に即座に対応できる圧倒的なスピードが、事業を継続させ、成長させるための必須の条件です。だから、事業部門の配下にITを使いこなせるチームを配置し、ビジネス・チームとシステム・チームのコミュニケーション・コストをなくし、両者を同期させて、システムを作る「内製化」が拡大しています。

彼らは、「技術的負債」を生みださないために、次のようなことに取り組んでいます。

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

XP（eXtream Programing）やスクラムなどによるアジャイル開発、マイクロ・サービス・アーキテクチャは、有効な方法論です。インフラやプラットフォームもまた、このスピードに同期させなくてはなりません。だから、サーバーレスやコンテナを前提に、ソフトウェアの本番環境へのデプロイに際して、安定稼働を保証しながら、高頻度で行えるようにしなくてはなりません。クラウドの活用やDevOpsは、そのために必要となります。

その前提として、心理的安全性が担保された自律したチームに大幅に権限委譲し、現場を最もよく知る人たちに即決、即断、即実行を期待しなくてはなりません。

クラウドサービスの利用拡大、チームの働き方の多様性を担保しなくてはならず、VPAやファイヤーウォールに頼らないセキュリティの考え方であるゼロトラスト・ネットワークも前提となります。

「作らないための技術」を駆使して、できるだけ少ないコードでビジネス目的を達成する

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

ユーザー企業は、このような取り組みに、ITベンダーの支援を期待していますが、この期待になかなか応えてくれません。だから、ユーザー企業は、自分たちでやるしかなく、上記のような「作らないための技術」を持つ人材を自分たちで採用しなくてはならないのです。それでも足りないという企業は、既存社員を自分たちで教育し、モダンITへのリスキリングに務めています。

「内製化支援」と「共創」ビジネス

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

IT×ビジネスの拡大の勢いを考えると、ユーザー企業の内製化は、ますます、拡大してゆきます。しかし、そのためのスキルを持った人材は、不足しています。だから、「内製化支援」すなわち「共創」ビジネスの需要は、拡大してゆくでしょう。

新しいことに興味がないヒトのために

これをビジネス・チャンスととらえ、これからの成長の原動力に変えるためには、「SIビジネスを再発明する」くらいの覚悟が必要です。「工数×人数」を売る過去の常識に囚われていては、お客様に、愛想を尽かされてしまいます。「技術力×人数」へと売り物を変えなくてはなりません。そのためには、自らもまた、時代の最先端を駆使して「共創」できる「スキルを磨き」自らの事業の再構築をすべきです。

「共創」への挑戦が切り拓く、新たな成長の機会

「DX」ということばが、世間を賑わしています。「IT×ビジネス」は、そんな勢いに押され益々拡がってゆくでしょう。だからといって、ITベンダーが「お客様のDXの実践に貢献します」と看板を掲げても、ここに紹介したような、技術やスキルを提供できなければ、誇大広告になってしまいます。ならば、世間の大騒ぎから一歩身を引き、ITベンダーの本来の役割である「技術力でお客様の事業を支える」ことに、改めて真摯に目を向けるべきです。

そのためには、いま必要とされている「作らない技術」を磨き、「共創」できるようになることです。ただ、その機会を、既存の仕事の中に、あるいはその延長線上に見出すことはできません。積極的に新たな需要を生みだす挑戦が必要です。

挑戦に成功の保証はありませんが、成長は保証されています。

挑戦を繰り返し、新たな機会を切り拓くべきなのです。そんな挑戦の積み上げが、個人も企業も成長させてゆくのです。

次期・ITソリューション塾・第41期（2022年10月5日 開講）の募集を始めました。