番外コラム ～ Multi-platform って難しい…

はじめに

そろそろ桜も散ったころかな…
今日は 4/1 です。折角なのでちょっと脱線しての番外コラムです。しかし嘘はなしでいきますね。
前回投稿の記事で、.NET MAUI というテクノロジーセットを試してみました。これ、同じコードセットで、Windows だけでなく、iOS、Mac、Android で動く GUI 付きアプリケーションができるよっていう、いわゆる、”Multi-platform”に対応することをモチベーションとしたテクノロジーセットです。Multi-platform というキーワードに関する思い出と、それから想起した様々な Knowledge ＆ Experience について、今回は書いていこうと思います。一部、不適切かもしれない（？）記述も出てくるかもしれませんが、ご容赦。

～ All roads lead to Conceptual Modeling ～

Multi-platoform

私がマイクロソフトに Developer Evangelist としてジョインしたのは2006年9月でした。ちなみにロールの正式名は World Wide Embedded Developer Evangelist、全世界に8人だけの希少ロールでした。マイクロソフトに入りたくてしょうがない人たちには申し訳ないんだけど、この職を得たのは、もう、偶々というか、タイミングとしか言えません。当時、MFC による GUI アプリ開発とか OLE による Excel や Access プログラミングとか、SQL Server なんかは使っていたけど、特にマイクロソフトの技術にはそれほど興味もなかったしね。私がジョインするまでの代理が、Windows XP で動くビルゲイツのサインが書かれたキティちゃんだったり、採用面接時、「オーディエンスは日本人だから英語はできなくてもいいよ」と言われた割には、ロールオーナーがドイツ人で同じロールの社員が全員海外だったのには面喰いましたが。
それはさておき、マイクロソフトジョイン後に本格的にマイクロソフトの製品や開発技術を本格的にキャッチアップしたわけですが、その中で、印象深かったコンテンツが、”マルチプラットフォーム対応開発に関する一連のドキュメント”でした。

組込み機器開発におけるマルチプラットフォーム対応

マイクロソフトにジョインする前、私は、1989年からずっと、プリンターや FAX、複合機の制御ソフトウェアを開発する、いわゆる、”組込みソフトウェア”の技術屋さんで、2006年ぐらいは機器の OS として、組込み制御系専用のリアルタイム OS にするか Linux でもいいんじゃないかなんて議論する時代でしたが、90年代は、HW や リアルタイム OS の進化は今以上に激しく、何がデファクトになるのかも確定的でない時代であり、ちなみに80年代後半から90年代初頭は OS っぽい機能（当時は”モニター”と呼んでいた）は手作りしてましたが、流石に製品機能も大規模化複雑化し、ネットワーク対応にもなっていたので、新しい製品シリーズの開発を始めるときは、どの OS を選択するかが大問題だったわけです。なぜなら、下手な OS を選択すると、製品シリーズ開発期間中に、その OS が無くなってサポートや OS レベルの機能追加拡張が受けられなかったり、ライセンス料が高かったりしてしまい、開発効率・品質・コストが影響を受けてしまうからでした。妥当と思われる OS を選択できたとしても、OS 自体もアップデートされていくので、それへの対応も必要です。
OS が変われば、システムコールなどの API はすべて変わってしまいます。製品を制御するソフトウェアはそれに合わせて変更しなければならなくなります。しかし、OS や HW が変わっても、エンドユーザーからみた OA 機器の機能は変わりませんよね。以降、OS や HW など機能を動かすための基盤の部分を実行プラットフォームと総称することにしますね。
当たり前の話ですが、装置の機能を実現するプログラムコード群は、実行プラットフォームが変わっても、なるべくそのまま使えるようになっている方がよいわけです。ネットワーク対応の複合機のコード量は、当時で数百万行というかなり大規模なものでした。そんな大量はコードをはじめから作るのは大変なので、なるべくそうなるように、装置制御のソフトウェアのアーキテクチャを設計することになります。”実行プラットフォームが変わっても同じコードセットが使える”＝”マルチプラットフォーム対応”です。
というわけで、複合機クラスの組込み制御機器においては、マルチプラットフォーム対応を考慮した設計が必要だったわけです。

Windows だけなのに、何故マルチプラットフォーム対応？

2006年といえば、Windows Vista がリリースされた年です。今や、マイクロソフトのアプリやサービスが Linux でも Mac でも Android でもなんでも動き、CEO のサティアが ”I Love Linux”と公言するマイクロソフトに生まれ変わりましたが、2006年当時は、大事なことは3回繰り返すバルマーが CEO で、「OS といったら Windows でしょ！」って時代だったわけです。
そんな Windows 一色な実行プラットフォームなのに、なんで、マルチプラットフォーム対応？というのが当時の私の素直な感想だったわけです。
しかし、私の認識は甘かった。
Windows Vista が出た2000年代中期を振り返ると、PC/AT がデファクト化はしていたものの、まだ PC98系も生き残っていたり、PC の HW は、各社ごとに装備されている周辺機器はばらばら、グラフィックアクセラレータが搭載され始めたり、OS は、デスクトップ系の Windows XP、サーバー系の Windows NT、さらにはそれ以前の Windows OSもまだまだ現役、稼働する OS や CPU アーキテクチャごとに対応した API として Win16、Win32、Win64 の混在、バージョン多数の DirectX など、案外混沌としていて、一言に Windows といっても、多くの PC で動かしたいビジネスアプリ開発者にとっては、 マルチプラットフォームといっても良い状況だったわけです。
私が見つけたドキュメントは、このような状況を考慮しつつ、アプリケーション設計に関する指針を解説したものでした。
1990年代後半なんか、ネットワークプリンタ向けのプリンタドライバーは、アプリケーション毎、ネットワークプロトコル毎に開発してたんですよねそういえば。
Windows 11 がリリースされている、今現在、いまだに Win32 API 等は残っていますが、.NET Framework を使ってアプリケーションを書けば、一つのコードセットで、どんなメーカーが製造販売している PC においても、サーバー上でも、また、Docker コンテナーでも、さらには、Intel・AMD 系だけでなく Arm CPU でも動作し、かつ、Linux や iOS、Mac、Android 上でも動くようになっているわけで、20年近く前の状況と比較すれば、ずいぶん進化したなというのが私の感想です。
.NET Framework といえば、MBED でも動く、.NET Micro Framework（マイクロソフトで最初にオープンソースになった）もありましたが、消えてしまったのがちょっと残念。
ジョインした当初は、特にマイクロソフトに関する思い入れは強くなかった私ではありますが、その後、紹介した Windows PC のマルチプラットフォーム設計対応指針や、Windows Vista で取り入れられたマイクロカーネルアーキテクチャや様々なフレームワーク、Windows 8 のメトロアプリの考え方、Microsoft Azure としてリリースされている統一されたアーキテクチャを前提として設計・実装された様々なクラウドサービス、強力な開発能力を有する Visual Studio と一連の自動生成ツール、そして、超先進的だったけどその時代の開発者には受け入れられなかった各種技術に触れれば触れるほど、案外、マイクロソフトの（巨大な）開発組織の設計・開発ポリシーと、私のそれとの親和性を感じるようになった次第。その辺も踏まえて、”Essense of Software Design”を再読してくれるとありがたし。

マルチプラットフォーム対応戦略

さて、組込み機器制御ソフトウェアと、昔の Windows PC におけるマルチプラットフォーム対応を紹介しました。

違いを吸収する中間層

実行プラットフォームの違いとは関係なく、エンドユーザー向けに提供する機能（アプリ層と呼びます）が同じという当たり前の状況を実現する最も自然で、多分、多くの組織が採るであろう戦略は、