このコラムは、株式会社エル・ティー・エスのLTSコラムとして2019年4月から連載を開始した記事を移設したものです。
当コラムの最新の内容は、書籍『Business Agility これからの企業に求められる「変化に適応する力」（プレジデント社、2021年1月19日）』でご紹介しております。
ライター
「ソリューション」とは本来問題解決のための全ての手段を指し、デジタルソリューションだけでなくBPOのような人的ソリューションや設備の更新、組織改訂やルール変更といった問題解決策は全てソリューションとなります。
自社を支える仕組みは、自分たちでしっかり考える
「アジリティ」という言葉を最もよく聞くのはこのデジタルソリューション界隈でしょう。環境変化に迅速に対応できる基盤としてクラウドサービスや最新のデジタル技術の活用を薦めるコラムなどはよく見ます。ただこのような「アジリティは最新のテクノロジーを活用すれば高まる」といった類の論説は本当でしょうか。そのあたりから考えてみたいと思います。
会社によって異なるソリューションの活用方針
以下に二つの会社のデジタル基盤の構造（ITアーキテクチャ）を示します。左側の製造業はパッケージソフトウェアやクラウドサービスを最大活用している一方で、右側の流通業は基幹部分をほぼ自社開発（スクラッチ開発）しており、外部のソリューションを活用しているのは経理などの一部の管理領域にとどまります。皆さんはこの二つのどちらの会社がよりアジリティの高いITアーキテクチャを採用していると考えるでしょうか。
結論から言えばこの両社のITアーキテクチャはどちらも高いアジリティを実現していると言えます。
まず左側の製造業の事例はITアーキテクチャを可能な限り市販のパッケージソフトウェアやクラウドソリューションで実現し、しかもこれらのカスタマイズやアドオンを極力避けています。これはビジネスプロセスを極力シンプルに保つことを意図した構成です。以前はこの会社でもシステムは各事業部門の要望を細かく聞いて、個別化されたプロセスを構築していたそうです。しかしそれぞれの事業の要望を基に個別最適化されたプロセスは、新しい製品を投入する際にうまく適合しないことがあります。そうなると時間をかけて新たなプロセスを構築しなければなりません。また個別最適化されたプロセスが増えると、ITアーキテクチャ全体がどんどん複雑化し、それが既存のプロセスの保守や新たなプロセスの実装をさらに難しいものするという悪循環に陥ります。このためこの会社では、せっかく企画した製品の市場投入が遅れるというケースが目立つようになってしまいました。今の製造業の環境では新製品投入の遅れは致命的です。
これに対して経営から「自社の強みは製品そのものの魅力で創出するので、プロセスは標準化を徹底し製品投入の迅速性を重視せよ」という指示が下りました。この方針に沿って構築したのがこのITアーキテクチャです。プロセスを事業部門の要望で一から構築することをやめ、IT部門が標準として用意したプロセスに製品のサプライチェーンや流通を適合させる方針としました（仮に改修が必要な際もIT部門の主導の下、最小限の改修にとどめます）。これにより迅速な製品投入が可能で、かつどこかの仕組みが老朽化しても速やかに新しいソリューションに交換することが可能なITアーキテクチャとしたのです。プロセスが標準的なものでかまわないのであればパッケージ・クラウドの活用は必然です。もちろん、このような考え方だとビジネスプロセスの自由度は制約を受けますし、事業部門としては当初希望したプロセスを構築できないケースもあるでしょう。しかし、前述のように自由度の高いプロセスの代償として製品投入が遅れてチャンスを逃しては意味がありません。このITアーキテクチャの裏側にはこのような明確な意図があったのです。
一方で右側の流通業の事例では、どのような会社でも差異が出ることが少ない管理系のプロセスを除いて、ほぼスクラッチ開発でITアーキテクチャを構築しています。この会社ではもともとパッケージソフトウェアを活用していましたが、ベンダー依存のアーキテクチャ運営で保守費やバージョンアップの費用がかさんだ上、複数のパッケージソフトウェアで機能が重複するといった無駄も目立っていました。このため、全ての機能を自社で設計する独自のITアーキテクチャを構築する方針に切り替えたのです。この際にオフショア開発など外部の力も積極的に活用する一方で、システムの要件定義やプロジェクトマネジメントはベンダーに依存せず、自社の人材を中心に進めるよう体制を見直しました。自社人材を中心に事業上必要な機能をしっかり吟味した結果、更新した基幹システムは旧システムと比べて運用費で6割、開発費で8割ものコスト削減を達成し、ビジネス部門の要望を迅速に叶えることができる余地も大きく向上したそうです※2。なお、2000年代のIT動向としては、スクラッチ開発は全てを一から開発しないといけないため負荷が高く、敬遠される流れにありました。しかし2010年以降、「ローコード開発ツール」と言われるような開発支援ツールや、開発環境の進化により以前よりも効率的に自由度の高いシステム開発が可能になっています。
『日経コンピュータ 2017年2月16日号』より。
ソリューション活用の鍵は事業への理解とオーナーシップ
両社は異なるITアーキテクチャの方針を選択しましたが、これはそれぞれの会社が自社の事業戦略や、業界の特性を考慮した結果です。例えば製品に強みを見出しビジネスプロセス自体はシンプルで構わないとした製造業に対して、流通業はその名の通り流通や販売のプロセスこそが業態としての核であり、妥協できない部分もあるでしょう。またこの事例における製造業は様々な製品事業を展開している多事業体であったのに対して、流通業は単一事業会社に近い業態で、事業間でのプロセスの標準化を考慮する必要性も異なります。
最終的には自社の強みをどこに見出すかはその会社次第です。今回の事例でもあくまで、登場した二社はそのように考えたというだけで、同じ業界のライバル企業でも事業の状況が違えば同じ方針が望ましいとは限りません。「環境変化が激しい」と一言でいってもその変化の程度や受ける影響は、それぞれの組織の置かれた環境で異なります。例えば事業がまだ立ち上げ段階で、素早い基盤の導入が必要な一方で、事業の先行き次第で撤退の可能性もあり得る場合には“導入しやすく、捨てやすい”クラウドソリューションは合理的な選択肢となります。一方で、事業がある程度安定し拡大のフェーズに入ってくると、プロセスの大きな軌道修正よりも、お客様の細かい要望に応えるためのプロセスのチューニングが重要となってきます。このような小改善を迅速に積み上げたい場合は、自由度が高いローコード開発（スクラッチ開発）を考慮してもよいでしょう。
全く異なるアーキテクチャの方針を採用した両社ですが、事業戦略や業務をしっかり理解した上で自社の強みを最大化するIT基盤を考え抜き、その構築を自社で主導しているという点は共通しています。もちろんどちらの例でもソリューションベンダーやソフトウェア開発会社といった外部の力を利用していますから完全内製というわけではありません。しかし、事業や業務の理解、ソリューションに対する仕様（要求）の明確化、そしてプロジェクトマネジメントといった中核となる作業は自社主体で行っています。製造業の事例のお話を担当者の方に伺った際に、ソリューションのブラックボックスの部分は立ち入れないとしても、その周辺の理解可能な部分は徹底的に自社メンバーで理解し、運用・保守も自社内で全て行っていると聞いて驚きました。結局のところ、理解していないものを迅速に変化させることなどできないわけですから、本来これは当然なのでしょう。
ITベンダーとの関係は仕事を任せる先から、外部の知見を学ぶ先へ
しかし、これが日本のIT部門の姿として “当然”ではないことは、この世界に身を置いている方なら誰しもご存じでしょう。日本は90年代からのITの導入過程においてITベンダーに頼った結果、自社のIT基盤を自社で語れなくなる“ベンダーロックイン”という症状が起きてしまった会社が多くあります。ビジネスのデジタル技術への依存度が加速度的に上がる中、これではアジリティどころではありません。
このような中で、高いアジリティを志向する企業ではITベンダーとの関係性に変化が見られます。過去の日本企業のITベンダーへの期待は「IT機能の一部、または全部を任せる」というものでした。しかし、今は「自社に必要な外部の技術やノウハウを取り込むための連携先」という考え方にシフトしています。私は以前にJUAS(日本情報システム・ユーザー協会)の研究会活動で、さまざまな自動車会社のIT部門の幹部にインタビューさせて頂いたことがあります。この際、インタビューした全ての会社の方が、今はデジタルソリューションの企画・開発をベンダーに任せるのではなく、技術力のあるベンダーからそのノウハウを吸収するといった手法に移行していると仰っていました。このために、お金を払ってでも必要な文書を残してもらったり、所属の異なるさまざまな専門性を持ったメンバーが円滑にコミュニケーションをとれるようにワークスペースに投資をしたりしているそうです。
またお付き合いするベンダーも、大手ベンダーばかりとは限らなくなっています。日本企業のIT部門では、これまで大手のITベンダーに多くのプロジェクト運営やシステムの保守・運用を任せてきました。大手のITベンダーをトップにその配下に何重もの下請け構造が連なる姿は「ITゼネコン」などと揶揄されたものです。このような構造から外部の情報の入手先も大手のITベンダー経由ということが多かったのが事実です。
ところが、現在の技術はさまざまなところで生まれます。それは必ずしも大手とは限りません。スタートアップ企業であったり、大学の研究室であったりします。また地理的にも日本国内や北米とは限らず、アジアや東欧といったこれまであまり接点のなかった地域でさまざまな組織が日々、新たな技術を生み出しています。このような技術を大手ベンダーを通して“又聞き”していても情報が不正確な上に、余計な時間もかかってしまいます。このため興味のある技術があれば、もはや相手企業の地理や規模、歴史にはこだわらず直接接触して情報を得るという考え方にシフトしています。これからは自社に居て出入りのベンダーに話を聞くということだけではなく、自社の外に積極的に出て（時には海外に出て）、技術の発信源に直接アクセスするという能動的な姿勢が大切になります。
最新のテクノロジーを活用することがアジリティ向上につながるとは限らない
ここまでの説明で分かるように、アジリティの観点から見ると活用するテクノロジーが最新だとか、高度なものであるかどうかはあまり重要な事項ではありません。そもそも最新テクノロジーの話題自体がビジネスアジリティのコミュニティで、さほど優先順位の高い議論事項ではないのも事実です。例えばオーストラリアに拠点のあるビジネスアジリティのコミュニティ「Business Agility Institute」の提唱している「Domains of Business Agility※3」でもテクノロジーは主要な観点としては登場していませんし、同じくビジネスアジリティのコミュニティでイギリスに本拠地がある「Agile Business Consortium」の年次カンファレンスに私が参加した時も人や組織の在り方が主要な議論テーマで、テクノロジーそのものはほとんど取り上げられていませんでした。決してテクノロジーを軽視しているわけではないのですが、そこには自分の（自組織の）在り様をしっかり考えて必要なテクノロジーを活用できれば、それがデジタルソリューションであろうとアナログなソリューションであろうと、そして最新の技術であろうと枯れた技術であろうとかまわないという考え方があります。ですから、世の中が“デジタルトランスフォーメーション”と、デジタル活用に必要以上に前のめりになっているようにも見える中において、アジリティを議論するコミュニティでは、意外にもこれらに対しては冷静な立ち位置をとっているのです。
ビジネスアジリティを語る際の観点を図示しており、「カスタマー」を中心に「経営」「従業員」「オペレーション組織」といったさまざまな観点を提示しています。それぞれの観点は成熟度（Maturity）が設定されており、いわゆる「成熟度モデル」の形式をとっています。
この「最新のテクノロジーならアジリティは向上するのか」ということについて、あるお客様企業のIT部門の方とおもしろい議論をしたことがあります。その担当の方は自身の経験として「クラウドソリューションだからといって必ずしも“導入しやすく、捨てやすい”とは限らない」と仰っていました。クラウドソリューションは“導入しやすく、捨てやすい”を売りにしていることもあり、「アジリティ向上のためにクラウドを」という宣伝文句はよく聞く言葉でもありますが、そうとは限らないと言うのです。
その会社では社内のさまざまなワークフローの基盤としてあるクラウドソリューションを採用しました。しかし、導入を進めてみるとさまざまなトラブルにぶつかり思ったように進みません。一つひとつトラブルを解決してソリューションの特性をしっかり理解していくと、徐々にソリューションを使いこなし、さまざまな業務の自動化に寄与するようになりました。このようなソリューションの理解にかかる時間とコスト（＝学習コスト）は決して安くはありません。ですからクラウドソリューションだからといってコロコロと新しいソリューションに乗り換えられるわけではなく、活用すると決めたソリューションは“使い倒す”という発想がないとむしろ無駄になるということでした。
確かにクラウドソリューションの小規模導入時の初期費用が小さくてすんだり、セットアップが迅速だったりといった特徴は、ビジネスアジリティを高める効果があります。その一方で、クラウドソリューションやパッケージソフトウェアは、その機能が自社の業務に完全一致することは稀で、どうしてもソリューションに自社の仕組みを合わせる必要が生じます。その際に、ちょっと想定と違ったとか、思ったような効果がでなかったといってソリューションを乗り換えてばかりいてもなかなか前には進めず、結局時間だけが過ぎてしまいます。自社の何を強みとして、どの業務をどこまでソリューションに対して合わせるのかという意思がなければ、ブームや外部事例に促されるままにクラウドソリューションを導入しても、意図した効果を出すことはできないのです。この時の会話は結局のところ、アジリティの根幹は人と組織に宿るものなのだということを再確認した会話でした。
現実には新しいデジタルソリューションが登場すると、それらのソリューションの導入を急ぎ、導入自体が目的化したプロジェクトが乱立するのも事実です（AIやRPAのブームが良い例です）。このようなプロジェクトではソリューションの試験導入で思った成果が出ず、本格導入前に活動が頓挫する“PoC倒れ”と言われる症状に陥るケースが大半です。これも事業や業務の目指す姿をしっかり考えず、効果の創出を安易に流行りのソリューションに頼ってしまっていることの現れでしょう。結局のところ、クラウドかスクラッチかといった実現手段そのものにアジリティが宿るわけではなく、自社の置かれた状況をしっかり考えた上でソリューションに明確な方針をもって臨むことが技術活用におけるアジリティの第一歩です。
ビルディングブロックの理解が大切であるという原則は同じ
ここまでをまとめると、「自社を支える仕組みだから、自分たちの頭でしっかり考える」という当たり前の姿勢がビジネスアジリティの根幹です。前回のコラム（第4~6回）で紹介した「ビルディングブロックの理解」という原則はここでも同じです。アプリケーションの各機能やデータ、さまざまなインフラといった「ビルディングブロック」をしっかり管理し、自社の事業に沿った“ブロック“の構成の在り様を考え抜き、絶え間ない交換作業を続けていく必要があります。このビルディングブロックの管理を怠ると、IT導入を内製化できている企業でも壁にぶつかります。各事業（業務）部門の要望をかたっぱしから実現した結果、システム構成が理解できないほどに複雑化（カオス化）してしまい、自社で作ったはずのITアーキテクチャが理解できなくなってしまっている会社は少なくありません。このような内製でシステムを構築している会社では“ベンダーロックイン”ではなく、システムの詳細が各開発担当者に属人化してしまう“メンバーロックイン”とも言える現象が起きます。その意味でITアーキテクチャのカオス化は決してベンダー依存からのみ起きるわけではありません。
このような自社のビジネスからデジタルテクノロジーの関係性を理解し、最適な構造を維持し続けるための方法論がエンタープライズアーキテクチャ（EA）です。EA自体は日本でも提唱されるようになってから30年以上の歴史があり、ご存じの方は多いかもしれません。ビルディングブロックとはこのEAから来た概念です。そして、このビルディングブロックをなるべく細かい単位で管理し、機能やデータの重複を排除した無駄のないアーキテクチャを志向する思想を突き詰めていくと、これもかつて提唱されたSOA（Service Oriented Architecture）の考え方に行きつきます。近年よく聞く「マイクロサービス」という考え方も、このSOAの一種です※4。EAにしてもSOAにしても提唱された当時よりも、むしろビジネスアジリティが求められる今の方がその重要性を増しているように思えます。このようなアーキテクチャマネジメントの方法論についても今後は理解を深めていく必要があるでしょう。
SOA（Service Oriented Architecture）とは業務上のある処理に必要なソフトウェア機能を一つの“サービス”として提供する考え方です。社内のさまざまなビジネスプロセスで登場する特定の処理に対して特定の一つのサービスを提供するという正規化された構造を持ち、かつこれらの機能を連携させることで大きなシステムアーキテクチャを構成します。この結果、あるサービス（つまりビルディングブロック）に変更が生じた際に、特定の機能を置き換えることで素早くシステム全体を最適化することができます。マイクロサービスとは、このSOAの構造の中で提供される最小単位のサービスを指します。
以上までが「ビジネスアジリティにおける“デジタルソリューション”」の前編となります。後編では、企業がデジタル活用を実現していくために、デジタル技術やリテラシをIT部門だけでなく企業全体として向上していく必要性について紹介します。
