接触確認アプリ COCOAにおけるベンダーロックインのリアル
そもそも本稿含む一連のCOCOA記事では「無償の民間ボランティアチームと喧伝したCOVID-19Radarオープンソースプロジェクトは実際はマイクロソフト・ファミリーによる営業活動ではないか」とともに「マイクロソフト Azureプロダクトによる囲い込み = プロプライエタリなベンダーロックインではないか」とも主張してきた。
この「マイクロソフト Azureによるプロプライエタリなベンダーロックイン」の部分について、主にマイクロソフト関係者の方々から「何をもってベンダーロックインというのか」「いずれのパブリッククラウド使おうと何らかのロックインはある」「そんなにロックインが嫌ならオンプレミスで運用しろ」「たとえCOVID-19Radarではなくコード・フォー・ジャパン(CfJ)のまもりあいJapanをしたところでロックインの部分はあった」「クラウドではロックインは完全に排除などできない」などの意見を頂いた。
部分的に納得できる意見もあるものの、これらの意見にはことCOCOAにおいては明確に誤っているとの姿勢を示さないといけないと思っている。
民間会社の1プロジェクトなら好きなプロダクトでどれだけプロプライエタリ(“利用者の持つ権利を制限的にすることで自身や利用者の利益およびセキュリティを保持しようとするソフトウェアを指す。制限には法的手法や技術的手法など様々な方法がある”)なベンダーロックインに陥ってもらってもいいだろう。各社の自由にまたマイクロソフト・ファミリーは大いに喧伝すればよい。
しかしCOCOAは「公共事業」である。この事実は幾つ言葉を重ねても消えることは無い。
接触確認アプリ COCOAの仕様書においても当然にして、中立性に関する事項における「いわゆるベンダーロックインの解消」はしっかりと掲げられている。
では接触確認アプリ COCOAでのベンダーロックインへの対応とはどうなっているのか。
実はこの点についてはCOVID-19RadarオープンソースプロジェクトのGitHubリポジトリに明快な答えが掲載されている。下記にAzureで(つまりサーバーサイドで)使用されているプロダクトを抜粋しよう。
- FrontDoor
- ロードバランサ兼アプリケーションゲートウェイ
- Functions
- サーバーレス・アプリケーション
- Application Insights
- ログやメトリクス監視
- Cosmos DB
- NoSQLデータベース(恐らく今回はドキュメント型(コアSQL))
- Blob Storage
- オブジェクトストレージ(AWSで言えばS3)
- CDN
- Key Vault (HSM)
- マネージドIDやモバイルアプリのデプロイに必要な秘密鍵など各種キーを保管するPaaS型HSM(セキュアストレージ)
- GitHub
- Azure DevOps
- モバイルアプリ含めたアプリケーションCI/CDツール。ビルドやテスト・デプロイなどの一連のリリース作業を自動化する
- App Center
- モバイルアプリケーション用のビルドやテスト・デプロイまたアプリストアへの公開などの一連のリリース機能をAzure DevOpsと連携して行う(モバイルアプリのパフォーマンス評価などの機能もあるが今回は使っていない模様)
注釈を入れさせてもらったが、採用プロダクトの「全てが」マイクロソフト社独自のプロダクトばかりで選定されているのには驚かされる。
マイクロソフト社独自プロダクトと書いたが、念のため書き添えると、これらの製品はAzureクラウドでしか提供されておらず、他のAWSや独自のオンプレミス環境などへそのまま移行することは出来ない。
ここがクラウドにおけるベンダーロックインの肝である。
FrontDoorやCDNなどはアプリケーションコードが直接関わるところでは無く、また各クラウドベンダーごとに別製品であっても実際のところ提供する機能に大きな差異は無いのであまり問題にはなりにくい。
しかしCosmosDBなど独自のDBの場合は専用のSDKを使用するため、もし将来他の環境へ移行したいとなると、当然他の種類のDBを選定する必要がある。それに応じてソースコード全体を修正するのは大仕事だろうし、またそもそもDB設計からして見直しを迫られる可能性も高い。
サーバーサイドアプリケーションはFunctionsに置かれており、Dockerコンテナを使用する(またはFunctions環境自体がコンテナにも出来る)とのことだが、構成上一般的なコンテナオーケストレーションツール(kubernetesなど)へそのまま移行できるような柔軟性があるとは思わず、また一般的にはKey Vaultから認証情報を取得するインターフェースを実装していたりBlob Storageなどのストレージへの保管なども必要であるなら代替を考えやはりコードは大きく修正することになるだろう。
何よりも実は影響が大きいと思われるのはAzure DevOpsやApp CenterといったCI/CDツールだ。
今日のサーバーサイドアプリケーションはコードを作れば終わり、というものでは無い。アプリケーションのための各種テストケースやリリースのためのビルドといったオートメーションツールでも一種のコードを記述する必要があり、これはCI/CDツールごとに大きく異なる。
CI/CDツールは現在では個別のクラウドに(大きく)依存しないサードパーティーツールも非常に数多いが、Azure DevOpsやApp CenterはもちろんAzure内のアプリケーションにしか適用できない。
サードパーティーツールへ移行するにせよ、恐らく全てを作り直す必要に迫られるだろう。
いかがだろうか。これが(Azureに限らず)「クラウドベンダー独自のプロダクトのみで構成されたシステムで現場が味わうベンダーロックインのリアル」である。
いかに「逃げにくくなっているか」おわかり頂けるだろうか。
接触確認アプリ COCOAでは、モバイルアプリのプラットフォームであるXamarinとC#については「iOSとAndroidで標準的なSwiftとKotlinならオープンソースへ貢献したい開発者がもっと多いのに」などよく嘆かれているが(個人の観測範囲)、実のところもっと深刻なのはサーバーサイドアプリケーションなのである。
これが、コンテナオーケストレーションツールとしてkubernetes(AzureでもAKSというマネージドkubernetesサービスがある)を、DBとしてMySQLでもPostgreSQLでもまたはCassandraやMongoDBといったNoSQL DB(実はCosmosDBでも内部的にはCassandraやMongoDBに対応可能である。が今回はコアSQLと呼ばれるマイクロソフト独自のドキュメント型DBが採用された)であれば、アプリケーションとしての主要な部分はそのままどの環境へでも移行できるはずだ。
例えばマルチクラウド対応としてそうした想定を最初から行うケースも最近では珍しくない。
しかしそうはならなかった。
逆に「意識的にマイクロソフトのプロプライエタリなプロダクトのみ選んだ」「仕様書で言うところの市場において容易に取得できるオープンな標準的技術又は製品はわざと排除した」とさえ思える。
まさしく接触確認アプリ COCOAのシステムは、教科書に載せられるほど典型的な、パブリッククラウドとオープンソースを隠れ蓑にしたクラウドベンダーによるロックインの好例と化している、ということだ。
ベンダーロックインは何故マズいのか
こと同じくして、マイナポイント・サイトへのマイナカードでのPCからのログインが未だにIE11にしか対応していない(iOSやAndroidのモバイル機器では端末のNFC機能を用いて著名ブラウザから可能)時代遅れも甚だしい仕様に利用者の不満が続出し、政府CIO補佐官でもある楠正憲氏がその赤裸々な「理由」を説明する騒ぎがあった。
本稿ではこの話題には深く触れない。
しかしこの話からの学びは「選択肢(オプション)を失った瞬間、システムはオワコン化しレガシーとなる」という点だろう。
ベンダーロックインとは「特定ベンダーが囲い込むことによる競争原理の阻害」「経営視点からは(当初のプラットフォームコストが高騰し別のプラットフォームへ移行する際の)スイッチングコスト」の問題として語られることが多い。
と同時に今回は政府調達案件での「税金の使われ方の妥当性」とも捉えることが出来る。
ユーザー企業でIT戦略に関わることが多い方々にとっては税金ではないにせよ、「選択肢が奪われる」問題は、大変身近な懸念ではないだろうか。
まさしくこの一点において、マイナポータルでの問題と接触確認アプリ COCOAでのベンダーロックイン問題は同じ軸線上にあることが分かる。
前項でも述べた通り、将来へ向けて「移行可能な選択肢を確保する」見通しを阻害することが、プロプライエタリなベンダーロックインの典型的な悪質性の本質なのだ。
接触確認アプリ COCOAは現代の新たなベンダーロックインの類型だ
先に指摘しておくが、ここに及んでも「それでも開発期間の無い中で可能な技術で駆使するのが悪いのか」「何年も使うことの無いシステムならたとえロックインされても大きな問題にはならない」という意見は根強く残るだろう。
ここで先の楠氏のブログ記事から一部引用しておこう。
普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、
何故お役所ってオワコンIEが大好きなの？
政府調達案件において短期間で簡単にシステムの更改は行えないし、まさにそれ故にマイナポータルに限らず、官公庁システムは十分な将来可能性とオプションを最初に確保し、残し続けていくことが肝要であることがわかる。
はっきり言えば、「開発期間が短いならしょうがない」「現場の苦労を考えろ」「そういう状況でのベンダー依存は許容される」といった意見は、発注側・ユーザー企業のためではなく、結局のところベンダー側へ利しているに過ぎない。
短納期は全く別に解決されるべき問題であって、発注側・ユーザー企業は詭弁に誤魔化されてはいけない。
「ベンダーによる囲い込み」問題は特に目新しい話題では決して無い。
コンピュータ黎明期を除けば、ここ何十年もそれぞれの時代において様々なベンダーによる囲い込み戦略が跳梁跋扈してきたのがIT業界であったと理解している。
そこに「ようやく」風穴を開けられる、ベンダーでは無くユーザー主導でのシステム戦略を組み立てる足がかりとなったのが、いわゆるオープンシステムの潮流であったとも理解している。
オープンソースであることや民間活力が必ずしも必須で無いことには注意したい(それらを否定しているのでは無い)。本質的な「選択肢を確保する」ことに繋がらないのであれば、ただただ将来へ向けてレガシーシステムを量産し続けるだけだということだ。
そう考えると、接触確認アプリ COCOAでのベンダーロックインの仕組みはよく出来ている。
昭和の頃からの伝統的な、寡占プロダクトでユーザーを囲い込むのではなく、「パプリッククラウド」「オープンソースプロジェクト」「民活」など役所にも社会にも綺麗に説明可能な要素が絶妙に忍び込まれている。
同時にクラウドではプロプライエタリなプロダクトとベンダーロックインの仕組みを備え持つ。
まさしく、昭和の時代から綿々と続くベンダー囲い込みの伝統は途絶えること無く、パプリッククラウドの時代においても、新たなロックイン手法を生み出し続けているのである。
この話、まだまだ新たな展開はあるのだが、続くかどうかは気が向いたら書く、多分…。
(7/26 07:30 修正) 中盤の何故ロックインが起きるかの箇所に説明が足りないと思えたため、がっつり追加しました。また一部表現などを見直しています。
別にAzureだけの話じゃないよ
https://www.atmarkit.co.jp/ait/articles/1912/05/news026.html
＞まだまだ新たな展開はあるのだが、続くかどうかは気が向いたら書く
期待してます！