「ロックイン」は悪なのか？：「不真面目」DXのすすめ

IT部門が嫌う「ロックイン」はユーザー企業にとって本当に“悪”なのでしょうか。ロックインのリスクを冷静に考えるべく、筆者は評価方法を考案しました。たどりついた結論とは。

[甲元宏明，株式会社アイ・ティ・アール]

この連載について

　この連載では、ITRの甲元宏明氏（プリンシパル・アナリスト）が企業経営者やITリーダー、IT部門の皆さんに向けて「不真面目」DXをお勧めします。

　「不真面目なんてけしからん」と、「戻る」ボタンを押さないでください。

　これまでの思考を疑い、必要であればひっくり返したり、これまでの実績や定説よりも時には直感を信じて新しいテクノロジーを導入したり――。独自性のある新しいサービスやイノベーションを生み出してきたのは、日本社会では推奨されてこなかったこうした「不真面目さ」ではないでしょうか。

　変革（トランスフォーメーション）に日々真面目に取り組む皆さんも、このコラムを読む時間は「不真面目」にDXをとらえなおしてみませんか。今よりさらに柔軟な思考にトランスフォーメーションするための一つの助けになるかもしれません。

筆者紹介：甲元 宏明（アイ・ティ・アール　プリンシパル・アナリスト）

三菱マテリアルでモデリング／アジャイル開発によるサプライチェーン改革やCRM・eコマースなどのシステム開発、ネットワーク再構築、グループ全体のIT戦略立案を主導。欧州企業との合弁事業ではグローバルIT責任者として欧州や北米、アジアのITを統括し、IT戦略立案・ERP展開を実施。2007年より現職。クラウド・コンピューティング、ネットワーク、ITアーキテクチャ、アジャイル開発／DevOps、開発言語／フレームワーク、OSSなどを担当し、ソリューション選定、再構築、導入などのプロジェクトを手がける。ユーザー企業のITアーキテクチャ設計や、ITベンダーの事業戦略などのコンサルティングの実績も豊富。

　

　ユーザー企業のIT部門が嫌うことは数多く存在します。この連載でいろいろ検証したいと考えていますが、まず今回は「ロックイン」を俎上（そじょう）に上げます。

　IT部門の方々とお話しする際に頻繁に登場する単語が「ロックイン」です。これは単一のITベンダーや製品、テクノロジーに囲い込まれることを指します。ロックインの結果、自社購買力が低下し、価格やサポートなどについてITベンダーが主導権を取ることをIT部門は嫌うのです。

　この文章だけ見れば、「ロックインは悪に決まっている」ように思われるかもしれませんが、本当にそうなのでしょうか。

　ユーザー企業でもITベンダーでもなく、常に第三者の立場でITコンサルティングを行っている筆者がロックインについて冷静に語りたいと思います。

ユーザー企業はなぜ「ロックイン」を嫌うのか

　商品の特性や仕様に大きな差がない消費財や食料品は、購買側の意思で自由に商品を選択できます。しかし、IT製品は独自仕様を持つ場合が多く、採用した製品を自由に入れ替えることができません。

　製品の「中身」がブラックボックスである多くのITベンダーの製品だけでなく、オープンソースであっても機能や仕様は独自であることが多いのです。ロックインされるのがITベンダーではないだけで、オープンソースもロックインリスクがあることは変わりません。

　ロックインを完全に回避するためにはどうすればよいのでしょうか。

　ハードウェアとソフトウェアを全て自作するしかありません。もちろんこれは非現実的ですが、全てを自作してもなお、プログラム言語にロックインされるのです。

クラウドロックインを気にし過ぎるユーザー企業

　前述の通り、ロックインのリスクはあらゆるIT領域に存在しています。最近、IT部門が気にしているのが、クラウドサービスのロックインです。「Amazon Web Services」 （AWS）や「Microsoft Azure」といったメガクラウドは、提供するサービスの強力さ故に世界だけでなく日本でも大きなシェアを獲得しています。

　しかし、1つのクラウドサービスにロックインされることを嫌うIT部門は多く存在します。その結果、複数のクラウドサービスを利用するマルチクラウドが主流になっています。

　筆者は本連載で「自分がワクワクするような新しいことを始めてみよう」とか「会社や組織をスケープゴートにせず、まず自分で面白いと考えるアプリケーションをプログラミングしてみよう」などと書いてきました。このようなDX的姿勢を進めるためにクラウドサービスは欠かせません。思いついたらすぐにプログラミングでき、完成したアプリケーションは誰でも世界中に展開できるのですから。

　しかし、こうした行動を取るためにはクラウドサービスを理解する必要があります。先進的なテクノロジーやサービスが次々と登場するメガクラウド全てを熟知するのは不可能ですし、複数のクラウドサービスに精通するのも至難の業です。ロックイン回避だけのためにマルチクラウドを選択している企業は、その是非を再考すべきです。

ロックインを冷静に評価し、ベンダーを味方にしよう

　筆者が考案したロックインリスク評価方法を説明します。

ロックインリスク評価方法（出典：筆者による作成図）

　前述の通り、ロックインをゼロにすることは現実的ではないため、まずロックイン発生可能性（以下、ロックイン可能性）を評価します。

　プロプライエタリ（独自仕様）製品やベンダーが知財権を持っている独自開発アプリケーションはロックイン可能性が高いと考えます。ロックイン時に受ける影響が非常に小さければ、ロックインを気にする必要はありませんので、ロックイン可能性とロックイン時の影響度の積をロックインリスク評価指標とします。

　ロックイン時の影響度は「サステナビリティ」（継続可能性）、「市場シェア」「ポータビリティ」（稼働環境の多様性）の3要素から評価します。詳細は割愛しますが、これらの項目について明確な評価基準を作るのは容易ではないため、図のように「高」「中」「低」の3段階で評価することをお勧めします。

　この図を作るときに参照したのは、筆者が実際にコンサルティングした国内企業のケースです。ロックインリスクの指標値となる4要素の積が「50〜81」の場合は「ロックインリスク：高」とし、ロックインされている製品が開発終了となった際の対策を早急に検討する方針を立てました。サステナビリティの低いインテグレーターが開発した独自アプリケーションはおおむねここに属します。

　指標値が「1〜9」の場合は「低」とし、継続利用することにしました。メガクラウドはここに属するため、この企業はマルチクラウドではなくシングルクラウドを採用し、単一のメガクラウドを駆使してDXアプリケーションを数多く開発しています。

　このようにロックインの自社定義を明確にして評価しているユーザー企業は少なく、多くの企業はイメージだけでロックインを嫌っています。

　ITがビジネスにあまり貢献しない時代であれば、ロックインを嫌悪しても問題にはならなかったでしょう。しかし、ITがビジネスに必須になった現代はロックインリスクよりもベンダーやテクノロジー、サービスを活用して得られる価値を重視すべきです。

　ITベンダーは敵ではなく、ビジネスやDXを推進するためのパートナーと見なすべきだと筆者は考えています。

「『不真面目』DXのすすめ」のバックナンバーはこちら。