「作る技術」から「作らない技術」への転換にどう対処すればいいのか

「社会環境が複雑性を増し将来の予測が困難な状況」

私たちはいま、このようなビジネス環境に置かれています。

計画通り物事が進まない、あるいは、計画の根拠となる変化を見通すことができない。そんなVUCAの時代にあっては、変化に俊敏に対応できる能力なくして、事業を継続することはできません。

ではなぜ、「デジタル」を使えば、「変化に俊敏」になれるのでしょうか。その答えは、「レイヤ構造化と抽象化」にあります。こちらの詳細については、以下のブログに詳述致しましたので、よろしければご覧下さい。

【図解】デジタルの真価は「レイヤー構造化と抽象化」

【図解】デジタルの真価は「レイヤー構造化と抽象化」

DXの本質を理解する上で、この概念は極めて重要です。本記事では、デジタル・テクノロジーの動向と重ね合わせて、改めて整理することにしましょう。

DXとはデジタルの本質をビジネスに組み入れること

このチャートに描いたように、デジタル化の本質は、複雑な現実世界の業務をレイヤ構造化し、さらには、その機能を抽象化された単純な要素へと分解することにあると言ってもいいでしょう。

社会の変化が緩やかな時代であれば、個別最適化された縦割りの機能組織や、属人化した個人のノウハウは、大きな問題にはなりませんでした。緩やかに、時間をかけて、社会の変化に合わせて変えていくことができたからです。しかし、いまやそのような悠長なことを言っている余裕はありません。冒頭で述べたようにVUCA時代にあっては、圧倒的なビジネス・スピードを手に入れ、変化に即応することが、事業を継続するための前提となったのです。

そのためには、業務プロセスや、これを構成する機能が、組織や個人に固定化しておくことは、変化への即応性を阻害します。そこで、アナログな業務プロセスをデジタルに置き換えることが、有効な対策となります。

デジタル化によって、アプリケーション、業務共通基盤、統合データベースといった階層構造に整理し直します。さらには機能をコンテナやマイクロサービスといった単純な要素に分解することで、それらの組み替えや新たな組合せが容易にできるようになります。

また、このようにしておけば、高度に専門化された企業が提供するクラウド・サービスを、APIを介して利用できるようになります。何でも自前主義で進める必要はなく、自分たちだけでは実現できない最新のテクノロジーとノウハウを、自分たちのビジネス・プロセスに容易に組み入れることができるようになります。

このようなレイヤ構造化、抽象化された業務の機能を、アジャイル開発やDevOpsによって、俊敏に組み替え、あるいは、新たな組合せ作ることができれば、変化への即応力を手に入れることができます。

このようなデジタルの本質を企業活動のメカニズムに組み入れることをデジタル・トランスフォーメーションと考えることは、妥当な解釈といえるでしょう。

いまだ世間では、DXで業務を改善するとの言説は多く、AIやデータを活用した新規事業を立ち上げることといった話もあります。それが間違っているわけではないのですが、それがDXの本質ではありません。「レイヤ構造化と抽象化」のメカニズムをビジネスに組み入れることか、本質なのです。

DXにおける経営の役割はアーキテクチャーの構築と改善にある

さらに経営という視点で、考えてみましょう。

業務プロセスをデジタル化するには、既存の業務プロセスのムダを洗い出し、効率の良い業務の流れに整流することが必要です。これについては、様々な方法が提案されていますが、そのひとつであるECRS［Eliminate（排除：取り除く）・Combine（結合：つなげる）・Rearrange（交換：組み替える）・Simplify（簡素化：単純にする）の頭文字を並べたもの］は、広く知られています。

このような業務プロセスの整理、あるいは再定義を前提に、ソフトウェアとして実装しなくてはなりません。その際、どこまでか個別であり、どこまでか共通なのかを、階層化して整理しておく必要がります。具体的には、業務アプリケーション層、共通業務基盤層、共通データ活用・連携基盤層、統合データベース層といったことです。

ソフトウエアの役割は、このような階層を経て、データを変換する機能を提供することだと言えるでしょう。

業務の効率化や最適化、顧客の行動予測や故障診断など、データは様々な価値を創出してくれるわけですが、そのためには、このロジックを適切に設計しなくてはなりません。しかし、想定したロジックが、全て思惑通りに機能するとは限りません。また、ビジネス環境の変化に応じてデータとロジックの関係をダイナミックに変化させることもできなくてはなりません。だからこそ、デジタル化によって業務プロセスをレイヤ構造化し、機能やデータの抽象度を高めておくことで、組合せや入れ替えを高速かつ柔軟にできるようにしておくことが大切になるのです。このようなメカニズムをビジネスに組み入れることで、変化に俊敏に対応できるのです。

このような階層化された構造とソフトウエアによるデータ変換のメカニズムを１から設計し作り上げることは容易なことでありません。そこでそのための雛形を提供しようとしているのが、ERPパッケージです。つまり、ERPパッケージを利用するとは、レイヤ構造化と抽象化を経営にいち早く取り入れるための手段と言えるわけで、個々の業務システムの開発生産性を高めるパーツであるとか、そのためのツールではないことを理解しておく必要があるでしょう。

アナログで複雑な個々の業務プロセスをデジタルによってレイア構造化し、次第に抽象化された要素へと分解すれば、それらは特定の業務に依存する必要はありません。例えば、統合データベース上の「顧客データ」は、それを販売管理業務、経理業務、保守・サポート業務で利用できます。しかし、業務個別にシステムを作り、それぞれのシステム個別に顧客データを管理すれば、それらの整合性を担保することは容易なことではなく、管理負担も増大します。また、新たにオンライン販売をはじめようとした場合に、顧客データを再利用すること、あるいは、オンライン決済やオンラインでのプロモーション機能を組み込むことは、容易なことではないでしょう。

レイヤ構造化と抽象化を推し進めておけば、このような新たな業務ニーズに、容易に対処できるわけです。GAFAやBATが業界の枠組みを超えて、容易に参入でき、圧倒的な競争力を発揮できるのは、このデジタルの本質的メカニズムを高度に実現しているからからでしょう。

この構造とプロセスを定めたのがアーキテクチャです。言葉を換えれば、「データから価値を生みだす基本構造を定義したもの」です。

経営者の役割は、このアーキテクチャを事業戦略に合わせて定義し、改善を続けながら常に社会や顧客にとって、さらには、自社の収益にとって、最適な状態を維持することにあります。

システムの実装や運用は、それぞれのエキスパートに任せることはできますが、データAをいかなるデータBに置き換えることが、企業価値に結びつくかを定義することは、経営者にしかできません。まさにそれこそが、経営者の役割です。

これまでの話しを改めて整理してみましょう。まずDXに取り組むとは、「デジタルがもたらすレイヤ構造化と抽象化をビジネスに組み入れること」です。そこでの経営者の役割は、「事業の価値に結びつけるためのデータ変換の全体構造、すなわちアーキテクチャーを定め、経営環境の変化に合わせて、これを改善すること」であると言えます。

CDO(Chef Digital Officer)の役割は、CEOを補佐して、このアーキテクチャーを作り、常に最適な状態を維持することにあります。これは、一般的なCIOの役割とも被るのも事実ですが、米国の進んだ企業であれば、もはやCIOがいない企業もあると聞きます。それは、CDOが示したアーキテクチャーに従って、各事業部門が自律的にシステムを内製しているからでしょう。

そのためには、現場のデジタル・リテラシーを高めることは当然のことですが、現場に大幅に権限を委譲した自律したチームを構成単位とする組織のあり方を模索する必要があるでしょう。それを前提に、内製化によるシステムの構築と運用を目指すべきです。

SI事業者は「作る技術」から「作らない技術」の専門集団になるべき

ただ、現実の問題として、事業部門が主導で、内製化を行うことは、既存のシステム開発や運用の常識を前提にすれば、容易なことではありません。そこで、「作らない技術力」を磨くことによって、この課題を解決する必要があります。

既に述べたように、VUCA時代に事業を継続させるための必須要件は、「変化に俊敏に対応するための圧倒的なビジネス・スピード」です。そのために、業務プロセスを徹底してデジタル化し、「レイヤ構造化と抽象度」を高めなくてはなりません。そうしておけば、自分たちでシステムを作る、作らないにかかわらず、機能やプロセスの新たな組合せや組み替えを容易に行うことができます。

現実的なシナリオを考えれば、ERPパッケージを全体システムの骨格に据え、クラウドに用意されているサービスと組み合わせれば、かなりの範囲を自分たちで１から作ることなく実装できます。かつてとは異なり、様々な業務機能やデータ管理、セキュリティなどは、もはや自前で作るよりは、遥かに優れた機能が提供されており、その運用管理も任せられるわけですから、「圧倒的なビジネス・スピードを獲得する」には好都合です。

まずは、作らないことを前提に、既にあるものを目利きし、既存のサービスやパッケージの最適な組合せを考えることですが、それでも、できないことがあるはずです。これこそが、自分たちで作るべき「ストラテジック・アプリケーション」です。具体的には、次のような要件を満たすものです。

• 事業の競争力あるいは差別化のために
• 既存とは異なる新しいビジネス・プロセスあるいはビジネス・モデルを実現するための
• 独自性の高いシステム

上記要件を満たさないシステムについては、徹底して既存のサービスやパッケージを使うことです。そして、必要とあれば仕事のやり方を変える、あるいは、最低限のUIや帳票のみに限定してアドオンを開発すべきでしょう。

また、ストラテジック・アプリケーションにしてもマイクロ・サービス化して、最新のプラットフォーム・サービスやサーバーレス、コンテナを駆使して構築しておくことで、市場やユーザーの変化に、柔軟に対処できます。また、ローコードやノーコードなどの開発ツールを駆使することで、現場が迅速に改善に取り組めるようにしておくことも大切です。

このような新しい技術は、ことごとく「作らない技術」です。ですから、これらを「作る技術」を前提にした事業モデルに適用することには無理があります。

例えて言えば、手紙を携えて江戸から大阪へ向かう飛脚にスマートフォンを持たせて、彼らの位置情報をWebで確認できるようにするのと同じです。そんなことをするよりは、メールやチャットを使うべきが、顧客の価値であることは、言うまでもないことです。

「作らない技術」を徹底して磨くことで、事業の最前線での内製化を実現することが、DXを実践する基本になるでしょう。

「作る技術」を前提に事業を行ってきたSI事業者にとっては、事業戦略の大きな転換を迫られることになります。組織力を駆使し工数を揃えることを事業価値としてきたわけですから、ユーザー企業のDXへの取り組み、すなわち事業部門が主導する内製化は、競合です。まずは、この前提に立たなくてはなりません。その上で、何ができるかを考える必要があります。

既存の作る技術を前提としたビジネス・モデルが、直ちに消滅することはないにしても、その取り組みの延長線上に、お客様のDXに貢献するシナリオは描けません。この前提に立って、２つの戦略シナリオを平行して薦める必要があります。

１つのシナリオは、既存のビジネスの高収益化です。作業プロセスの効率化や業務プロセスの再定義を行い、徹底した効率化を図ることで、収益率の拡大を図るべきでしょう。また、既存システムのクラウド化や自動化、モダナイゼーションといった「過渡期戦略」もまたビジネスのチャンスです。

一方、もうひとつのシナリオは、「作らない技術」を前提とした「共創」です。組織力で工数を拡大し売上を増やすのではなく、個人力で圧倒的な技術力を武器に、お客様の内製化チームに参加し、かれらの「作らない技術」力を支えることです。

後者のシナリオで、短期的に工数を拡大させることは難しいでしょう。しかし、ユーザー企業がDXを標榜する以上、前者の「作る技術×組織力×工数」は、やがては需要を減らします。ここで稼げるうちに、後者の「作らない技術×個人力×高利益」で経営を維持できるように、経営戦略や組織体制、人材育成戦略やビジネス・モデルの変革を進めておくことが、もはや唯一の選択となるはずです。

＊追加開催決定！９月1日（火）

「最新ITトレンド・１日研修」につきまして、追加開催することと致しました。新入社員以外もご参加頂けます。詳しくは、上記バナーをクリックの上、ご覧下さい。

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